案例

业务问题

客户 Brief 经常以聊天记录、邮件或文档形式进入团队，预算、平台、地区、KPI、交付周期和禁忌项并不完整。项目负责人需要先读懂、补字段、追问客户，再生成达人筛选条件和内部启动摘要。

方案设计

• 规则层负责字段校验、预算区间、平台枚举和必填项缺失判断。
• LLM 层负责语义提取、摘要、追问清单和外联话术草稿。
• 人工层负责确认预算、达人名单和最终客户沟通口径。

结果与复盘

第一版只覆盖“Brief 输入到项目启动摘要”这一段，不碰合同、付款和完整 CRM。这个取舍让 Demo 可以在一周内被业务人员试用，也暴露出最关键的问题：AI 不是替代负责人，而是先减少漏字段、重复整理和无效追问。

业务问题

技术支持团队常见问题不是“没有文档”，而是文档分散、命名不一致、告警和工单语言不统一。新人无法快速判断应该看哪份 SOP，资深同事则不断重复解释同类问题。

方案设计

• 先把 SOP 拆成“适用条件、排查步骤、风险提示、升级条件”四类字段。
• 工单进入后先做问题分类和关键信息抽取，再检索相关 SOP。
• 输出不是最终答案，而是排查路径、缺失信息和可复制的客户回复草稿。

结果与复盘

这类工具的核心不是一次回答正确，而是减少一线从“模糊问题”到“下一步动作”的时间。验收指标应该放在首响准备时间、重复问答次数、升级质量和 SOP 更新频率上。

业务问题

发布依赖手工操作时，真正的问题不只是慢，而是责任边界不清：谁改了配置、变更有没有审核、失败后如何回滚、线上状态是否和 Git 一致，都很难被追踪。

方案设计

• 用 Git 作为配置事实源，把环境差异收敛到模板和 overlay。
• CI 阶段做语法校验、镜像标签检查和基础策略检查。
• CD 阶段由 ArgoCD 同步并保留差异、状态和回滚记录。

结果与复盘

GitOps 的价值不是“自动发布”四个字，而是让发布变成可讨论的流程资产。对于 AI 工具交付，这段经验也很关键：Demo 最终要进入团队流程，就必须有版本、回滚、监控和责任边界。

业务问题

订单、发货、退款和结算数据来自不同来源，字段命名不一致。人工对账时最耗时的不是计算，而是判断异常来自缺字段、时间差、金额差还是业务规则差异。

方案设计

• 先把不同表格映射成统一字段，再做金额、数量、状态和时间窗口校验。
• 规则引擎输出确定性异常，LLM 只负责把异常解释成业务人员能看懂的摘要。
• 所有高风险结果必须进入人工确认清单，不能直接写回生产系统。

结果与复盘

这类场景非常适合 AI 参与“解释”和“整理”，但不适合让 AI 直接做财务判断。第一版的价值应该是减少查漏项时间，而不是承诺完全自动对账。