4.2 我怎样把经营问题写成任务书
销售负责人最初给我的要求只有一句话：“做一个销售 AI 助手。”
这句话听起来很明确，实际上什么都没有决定。它没有告诉我销售在哪件事上遇到麻烦，没有说明公司为什么愿意为此改变流程，也没有告诉工程师什么结果算做成。
我没有马上改写功能，而是拿出上一卷抽查过的一笔延期订单。
我从一笔已经付出代价的订单开始
这笔订单签约时，销售以为客户只需要标准接口。售前在个人文档里写过“旧系统可能要额外适配”，但没有进入合同评审。项目经理接手后才发现，客户使用的是第三方系统，接口权限也不在客户自己手里。
项目因此晚了六周。云枢科技投入额外顾问时间，客户推迟验收，尾款也没有回来。
如果把问题写成“销售记录不完整”，工程师可能会增加必填项。如果写成“缺少风险提醒”，工程师可能会生成更多提示。可这两种做法都没有抓到真正的经营后果。
真正要改变的是：在方案发给客户以前，让需求、产品能力、客户条件和合同承诺之间的差异能够被发现，并交给有权的人决定。
我把任务名称从“销售 AI 助手”改成了“签约前承诺核对”。
任务书第一段先回答为什么现在要做
我在任务书开头写下四类事实：
- 最近十二个月有多少订单在签约后发生范围变化；
- 这些变化带来多少返工、延期和额外成本；
- 哪些问题在签约前已经有人知道，却没有进入共同判断；
- 如果什么都不改，公司继续承担什么损失。
这些数字不一定一开始就完整。没有确认的地方，我会写“还不知道，需要在试点中继续测量”，而不是编一个漂亮的收益。
任务书必须让工程师知道，它建设的不是一个展示 AI 能力的工具，而是在保护项目毛利、客户承诺和回款。
我把目标写成可以观察的变化
“提高销售效率”“减少风险”都不能直接验收。
我和销售、售前、项目负责人一起把目标改成三件能看见的事：
- 方案发出前，关键客户条件和非标准要求能够被列出；
- 超出标准能力的承诺会交给指定负责人决定；
- 签约后，项目和财务拿到同一份已确认的交接材料。
这些目标不承诺所有项目都不延期。它们只承诺先把能够在签约前发现的问题提前暴露出来。
目标越诚实，后面的验收越有意义。
我只选择第一批真正会使用的人
第一版不是给全体员工。
我选择四名销售、两名售前、两名项目经理和一名财务人员。他们既包含愿意试用的人，也包含对新流程有疑问的人。
我写清他们会在什么时刻使用：
| 使用者 | 真实时刻 | 他需要完成的决定 |
|---|---|---|
| 销售 | 客户需求初步明确后 | 目标、决定人和客户条件是否齐全 |
| 售前 | 方案准备前 | 要求是否属于标准能力 |
| 负责人 | 出现额外承诺时 | 接受、拒绝、报价或延后 |
| 项目与财务 | 合同确认后 | 是否具备启动、验收和付款条件 |
如果一个角色在真实工作里没有明确动作，就不要因为“以后可能有用”先把他放进范围。
“这次不做什么”决定了第一版能否交付
销售希望第一版顺便自动写方案、生成报价、预测赢单率、同步客户邮件。我没有全部接住。
首批范围只包括整理资料、发现缺失、比较差异、提示责任人和生成待确认交接单。
第一版明确不做：
- 不自动向客户发送任何内容；
- 不批准价格和折扣；
- 不接受合同条款；
- 不把尚未发布的能力写成可交付；
- 不修改财务和项目完成事实；
- 不给员工做绩效排名。
“不做事项”不是给工程师设障碍，而是在保护试点能够小范围、低风险地验证。
我把真实样本和任务书放在一起
只写理想流程，工程师会自然地按照理想情况建设。
我附上正常、延期、亏损和逾期四类订单，并标出哪些资料可信、哪些说法存在分歧。敏感信息先按公司规则脱敏。
这些样本让工程师看见：客户名称可能在两个系统里不同，销售纪要可能没有日期，合同可能附带补充协议，项目启动后才出现的新信息不能倒过来冒充签约前已经知道。
真实样本不是用来训练一个完美答案，而是让任务书里的边界变得具体。
开始建设前，工程师先交回一份理解
我要求 AI 全栈工程师先回答：
- 你理解的经营问题是什么？
- 第一版改变谁的哪一步工作？
- 你需要哪些资料，目前缺什么？
- 哪些动作只能建议，哪些允许写入？
- 遇到资料冲突、系统失败和越权请求时怎样停下？
- 你准备拿哪些真实情况证明做对了？
如果它只是把我的原话换一种说法，说明理解还不够。好的复述会指出隐含矛盾，例如“合同确认”和“项目可以启动”是不是同一个状态。
云枢科技的一页任务书已经填成这样
| 项目 | 已确认内容 |
|---|---|
| 任务名称 | 签约前承诺核对与签约后共同交接 |
| 要改变的问题 | 非标准要求没有在对客承诺前形成能力、工作量、客户条件和价格的共同决定 |
| 经营证据 | YS-24-017 实际毛利约 19%，比计划少 11.5 万元成本空间，尾款 21 万元晚 49 天；YS-24-009 提供顺利反例 |
| 公司基线 | 销售周期 92 天、验收 118 天、应收周转 76 天，41% 项目出现未充分计价的范围变化 |
| 首批使用者 | 4 名销售、2 名售前、2 名项目经理、1 名财务人员 |
| 第一阶段包含 | 整理来源、指出缺失、比较标准与非标准、分派例外、生成待确认交接材料 |
| 第一阶段禁止 | 对客发送、价格和合同批准、接受非标准承诺、项目和财务事实写入、员工绩效判断 |
| 要验证的变化 | 关键缺失能否更早暴露，例外是否交给正确负责人，项目与财务是否收到同一组确认事实 |
| 不能承诺 | 十二周内一定提高利润或回款；多数订单可能还没有走到验收和付款 |
工程师第一次复述时，把“生成待确认交接材料”说成“自动创建项目”。这次偏差让任务书增加了禁止写入项目事实，也让后续状态表把“交接待接收”和“可以启动”分开。
完整任务摘要和根因竞争解释保存在 执行包第 1—3 节。下一节继续把一页任务拆成具体角色、触发事件和业务状态，直到另一位项目经理不用听口头说明也能走完整笔订单：我怎样把使用过程说到没有歧义。