把我们怎么干活这件事，完整摊开讲一遍

先把业务讲清楚，再谈技术。这一步不写代码，只做访谈和梳理。

• 分别和管理层、一线业务人员聊，看两边对同一件事的描述差在哪
• 把客户从哪来、怎么跟进、怎么交付这条链路完整画一遍
• 标出哪些环节靠个人经验支撑、一旦人不在就断

这一步的产出一份业务断点清单，按影响面和可动手难度排好优先级。

把散在个人脑子、聊天记录和临时文档里的经验，收拢成可维护的结构。

• 整理服务边界、常见问题、话术和交付流程
• 统一口径：同一个问题，不同人回答不能是两套说法
• 确定谁负责维护、多久更新一次

这一步的产出企业自己的知识栈：流程文档、FAQ、话术库、交付 SOP。

用真实发生过的场景去试，而不是拿理想案例做演示。

• 取历史真实咨询和订单，看智能体能不能接住
• 找出会答错、答不了、不该由 AI 答的情况
• 明确划出人工必须介入的边界

这一步的产出一份验证记录：哪些可以自动化、哪些必须人工、边界写在哪。

落到具体的东西上 —— 官网、经营系统、智能体或工作台，而不是一份方案文档。

• 按前面定下的优先级，先做第一个能跑通闭环的模块
• 配套写操作说明，保证不依赖开发也能日常使用
• 留出后续扩展的接口，不做一次性交付

这一步的产出可用的系统，加上你团队看得懂的使用文档。

上线不是终点。没有复盘的系统，半年后就没人用了。

• 按周期看使用数据和一线反馈
• 把新出现的问题补进知识栈
• 根据业务变化调整下一轮优先级

这一步的产出下一轮的改进清单，以及知识栈的更新记录。