01项目概览
DingDong 是我从 DBA 的日常工作出发，逐步构建的一套 AI 工作流自动化系统。它以钉钉作为交互入口，把运维请求、业务数据、受控工具和消息投递连接起来。
已实现核心流程，部分能力持续验证中。
本页展示问题拆解、工具约束与流程设计，案例使用模拟请求。功能实现与实际场景适用性需要分别验证。
重点是让重复的信息收集和整理有迹可循，让 AI 在证据与权限边界内辅助判断。自动化分析建议仍需要人来确认，不能视为故障已经修复。
02起点与演进
起点是运维告警：收到问题之后，往往还要查询资产、收集指标、执行检查、整理诊断，再把结果交给合适的人。重复工作分散在多个入口，处理状态也容易割裂。
- 先连接告警与证据。 用固定检查流程和只读查询补充上下文，由 AI 整理分析建议。
- 再把能力放进日常对话。 经授权的用户在钉钉发起资产、指标、知识库、备份、排班查询和日志分析。
- 延伸到文档与提醒。 结合当前资产和备份信息生成材料，把需要处理的事项按规则提醒。
- 统一底座，保留业务边界。 共用消息与基础能力，通过明确的模块边界组织业务流程。
演进的重点不是扩大 AI 的执行权限，而是把入口、过程、结果和人工接手点逐步说明白。
03能力模块
01 ／ 持续验证中告警处理
- 问题与入口
- 从告警工单和受支持的告警邮件进入，减少重复收集资产和诊断证据的工作。
- 过程 · AI 的作用
- 按策略筛选，查询资产与历史指标，通过固定 Playbook 和只读 SQL 获取证据；AI 形成结构化分析与联系建议。诊断不会让 AI 自主执行任意修复。
- 结果
- 保留分析、来源和各渠道投递状态，生成诊断通知。管理台支持查看历史与分析质量，人工确认、纠正或拒绝结果；策略管理用于规则与版本控制。
- 人工边界
- 证据不足时明确降级，人工判断根因和处理措施。规则与通知对象的调整需要人工确认；经复核的内容才能作为知识沉淀。
- 验证范围
- 核心流程已有实现与离线验证。分析质量和规则适用性需要按场景评估。
02 ／ 核心流程已实现AI 对话与受控工具
- 问题与入口
- 授权用户在钉钉用自然语言提问，减少来回切换查询系统的成本。
- 过程 · AI 的作用
- AI 理解请求并选择有权限的工具；业务层再次校验用户、目标和输入。工具包括受控只读检查、资产查询、监控指标、知识库、备份及排班。
- 结果
- 返回查询结果和必要解释。备份、排班等确定性结果直接返回，避免模型改写业务事实。
- 人工边界
- 缺少目标、日期或其他必要信息时要求补充；越权或不符合只读边界的请求被拒绝。用户根据证据决定下一步操作。
- 验证范围
- 对话与工具调用流程已有实现；各工具的权限、输入校验和结果准确性需要分别验证。
03 ／ 核心流程已实现后台日志分析
- 问题与入口
- 经授权的钉钉自然语言请求或日志分析命令触发，支持 Linux 与 Windows。
- 过程 · AI 的作用
- 请求先持久化，再由后台任务进行有界采集；检查采集来源、完整性和截断状态后，把精简日志交给 AI 分析。
- 结果
- 异步返回分析、空窗口提示或明确的失败说明；任务状态支持中断后的恢复。
- 人工边界
- 日志截断时提示采集不完整；无权限、不可达或平台不支持时明确失败。分析供人工排查使用，不代表系统已恢复。
- 验证范围
- 已有隔离集成验证，覆盖不同平台、任务恢复和异常处理；验证结论仅适用于所覆盖的场景。
04 ／ 核心流程已实现变更文档生成
- 问题与入口
- 授权用户在钉钉提交目标与变更名称，减少重复填表和沿用过时资料的风险。
- 过程 · AI 的作用
- AI 理解请求，必要时确认标准名称。确定性流程查询当前资产、业务资料和备份，选择历史或默认模板，填充已支持的字段。
- 结果
- 输出 Word 变更申请与 Excel 风险评估，并说明模板匹配、备份情况、资料差异和填充范围。
- 人工边界
- 第一期不生成新的操作步骤。历史操作、验证和回退步骤必须人工复核；生成材料不等于审批通过，更不代表已执行变更。
- 验证范围
- 历史模板兼容已有离线回归与样本版式检查；每次生成仍须检查字段、格式及实际适用性。
05 ／ 核心流程已实现运维提醒
- 问题与入口
- 定时读取变更、待签收／待确认、审批和超期／临期事项，减少遗忘与重复提醒。
- 过程 · AI 的作用
- 由确定性规则判断时间窗口、负责人、状态与去重条件；这一模块的提醒调度不依赖 AI 推断业务状态。
- 结果
- 向对应人员或群发送待处理提示，保存投递与完成状态，失败不直接记为成功。
- 人工边界
- 提醒不会代替签收、审批或实际处理；负责人解析失败及异常事项需人工核查。
- 验证范围
- 提醒流程已有实现，规则与状态恢复有离线验证；提醒效果需要按场景评估。
04流程示例
下面展示已支持的业务流程，请求均为模拟样例，不包含真实目标、人员或业务数据，也不代表实际效果统计。
从文件系统告警到可复核的建议
收到一条文件系统使用率告警 → 查询资产与历史指标 → 固定只读检查收集目标文件系统证据 → AI 整理可能原因与联系建议 → 将分析结果交给人工核查。数据缺失时说明缺口，不把建议写成修复结果。
“分析这台测试主机最近十分钟的日志”
授权与目标校验 → 持久化后台任务 → 在限定窗口采集 Linux 或 Windows 日志 → 检查完整性 → AI 分析 → 异步回送。若窗口为空，直接提示无日志；若截断，结果明确说明证据不完整。
“为这个测试目标生成变更材料”
补齐目标与名称 → 确认标准名称 → 查询当前资产与备份 → 选择历史或默认模板 → 生成 Word 和 Excel 附件。用户仍需检查保留的操作步骤、风险、验证与回退安排，再进入正式审批。
05简化系统设计
把“理解请求”“受控执行”和“确认结果”分开，使单个工具或投递失败能够被识别和追踪。
- 入口钉钉对话、告警来源与定时业务查询
- 业务处理权限校验、参数确认、固定规则、持久化任务与状态
- 证据与 AI资产／指标／知识库／备份／排班，固定检查与只读查询；AI 辅助理解和分析
- 结果与投递分析建议、查询结果、文档和提醒，经统一消息投递链路送达
- 人工复核核查证据、审阅材料、决定处理动作；告警管理台保留审核与追溯
消息队列连接业务处理与结果投递，状态存储记录任务进度与处理结果；耗时操作由后台任务完成。模块通过明确的输入、输出和失败状态协作。
重试不能抹掉不确定性：证据缺失时降级；明确失败时有限重试；邮件正文已经发送但最终响应未知时，保留“待核查”，避免盲目重复投递。
06当前进展与后续方向
核心流程已有实现，部分能力持续验证中。
核心流程已实现围绕分析、查询、文档生成和提醒，串联请求理解、受控工具与结果反馈。已有实现不等于适用于所有场景。
持续完善继续关注证据质量、异常处理、结果可追溯性和人工复核体验。
实践积累
- 异步日志分析：有界采集、完整性检查与任务恢复。
- 邮件投递：区分明确失败与结果未知，约束重试行为。
- 文档生成：处理历史内容残留与不同模板结构。
07开发记录
整理实践中的问题拆解、处理方法与验证边界，省略具体环境、内部时间线和运行数据。示例单独标注，不包含原始业务日志。
技术复盘 ／ 时间一致性与重试边界
登录成功，为什么请求仍返回 JWT 422？
从通用状态码追到 Token 时间校验，识别节点时间偏差；有限重试降低故障概率，但不能代替服务端时钟修复。
阅读排查记录 →
技术复盘 ／ 投递状态与异常处理
邮件超时，不一定意味着没有投递
按 SMTP 阶段区分明确失败与结果未知，避免来源轮询器把待核查的邮件反复重发。
阅读处理记录 →
技术复盘 ／ 文档结构与样本验证
历史 Word 模板：保留步骤，清理旧证据
旧内容不只在段落中，也藏在图片、表格和内容控件里；兼容空区间，同时保留严格的关键锚点校验。
阅读兼容记录 →
持续更新：重要功能落地、完成验收、设计变化或代表性问题解决时，手工更新项目说明。文章保留发布日期与更新日期，验证结论保持适用范围。
更多数据库与工具实践，可阅读我的 51CTO 博客 ↗。