这套方法解决什么问题

企业 AI 项目经常从一个令人印象深刻的 Demo 开始，却在接入真实流程时暴露出数据、权限、责任和采用问题。本 Playbook 用七步把“客户说想要什么”转化为“生产系统可以安全做什么”。每一步都要留下证据；如果关键前提不成立，就缩小范围、回到上一步或停止。

七步交付路径

第一步：定义业务结果与责任人

写清楚要改善的业务结果、当前基线、目标用户、业务 Owner 和观察窗口。不要把“做一个 Agent”当作结果，也不要在没有 Owner 的情况下进入开发。

产出：一页问题定义、基线指标、Owner 和不做范围。

第二步：画出真实工作流

跟随用户完成一次完整任务，记录触发条件、输入、判断、系统动作、人工交接和异常分支。把用户口中的“自动处理”拆成可以验证的步骤。

产出：流程图、角色清单、异常分支和现有系统边界。

第三步：盘点数据与系统

确认数据来源、更新频率、字段含义、权限、质量和部署位置，再确定 Agent 需要读取哪些数据、调用哪些工具。数据拿不到或责任不清时，不要用 Mock 数据掩盖阻塞。

产出：数据与系统清单、访问责任、数据风险和最小可用范围。

第四步：冻结动作与控制边界

把 Agent 的能力写成动词，并为每个动作标注只读、可逆、需审批或禁止。涉及外部沟通、资金、权限和不可逆变更的动作必须先设计人工确认、审计和回滚。

产出：动作矩阵、最小权限方案、审批路径和回退方案。

第五步：构建生产形状的最小切片

不要只做一个漂亮的聊天窗口。选一条边界清晰的真实流程，接入真实数据子集、权限、日志、错误处理和人工兜底，让技术验证尽量接近未来生产约束。

产出：可运行切片、调用日志、已知限制和部署说明。

第六步：用证据灰度发布

先在小范围、低风险用户和明确观察窗口内运行。分别记录任务质量、系统稳定性、人工接管、用户采用和业务指标；Go、Pivot、Stop 条件必须在观察前冻结。

产出：评测报告、用户反馈、故障清单和灰度决策。

第七步：运营、交接和反馈

上线不是交付终点。明确谁处理异常、谁更新规则、谁复核指标、何时回滚以及 FDE 何时退出。将重复出现的问题进入修复队列和产品反馈，而不是留在个人聊天记录中。

产出：运营责任表、交接记录、复盘结论和可复用资产候选。

三个必须停止的信号

  • 没有业务 Owner，或 Owner 不愿意为结果和风险负责。
  • 数据、权限或合规存在硬阻塞，却试图用 Demo 结果直接宣布成功。
  • Agent 的关键动作不可审计、不可停止或不可恢复。

如何判断真的进入了 Production

Production 不是部署到服务器的同义词。至少要有真实用户、真实流程、明确的业务指标、持续运营 Owner、异常处理和回滚路径。若项目只证明了技术可行，应诚实标记为 POC；若只在小范围观察，应标记为 Pilot。

完成七步后，团队应能回答四个问题：业务改善了什么？Agent 改变了哪些状态？出现错误谁能接管？下一次交付可以复用什么？答不出来时，继续扩大范围通常会放大风险，而不是加快落地。