云枢科技已填写执行包：商机到回款
这不是另一份空白模板，而是 黄金样章 中实际使用的填写版本。读者可以顺着它检查：经营判断有没有变成工程师能够执行、业务人员能够验收的条件。
使用边界：本文是虚构教学示范。另一家公司不能照抄其中的指标、角色、状态和权限；必须用自己的订单、系统、制度和责任人重新确认。
0. 文档控制
| 字段 | 已确认内容 |
|---|---|
| 项目名称 | 签约前承诺核对与签约后共同交接 |
| 执行包版本 | 1.0，适用于脱敏历史验证和有限只读试点 |
| FDE 负责人 | AI 转型负责人，对诊断、执行包和跨部门决定负责 |
| 业务负责人 | 商机到回款价值流负责人，对流程采用和经营结果负责 |
| 参与岗位 | 销售、售前、项目交付、财务、法务、产品与数据负责人 |
| 工程执行 | AI 全栈工程师，负责理解、方案、建设、测试和部署准备 |
| 当前授权 | 可读取批准的脱敏样本；可在试点环境生成草稿和待办；不可向正式系统写入 |
| 下一阶段授权条件 | 验收用例通过、风险负责人确认、人工恢复演练完成 |
| 当前待确认 | CRM 客户主体标识质量；第三方模型能否接触未脱敏纪要；财务状态接口的响应范围 |
每次范围、数据来源、自动动作或批准规则改变，都要更新版本。工程师不得把“以后可能开放”的权限当作当前已经获得的权限。
1. 经营决策摘要
为什么现在做
云枢科技最近一个完整年度中，约 41% 的实施项目发生未充分计价的范围变化。公司平均项目验收周期为 118 天，比计划多 28 天；应收账款周转天数为 76 天。
十二笔订单的诊断样本进一步显示：非标准要求如果没有在对客承诺前完成能力、工作量和客户条件确认，签约后更容易出现无偿返工、验收延期和尾款推迟。
第一阶段要改变什么
第一阶段不改造所有销售活动，只改变两个断点：
- 非标准要求从被发现到写进对客方案之间，必须进入明确的例外决定；
- 合同确认后，项目和财务必须接收同一份带来源的范围、客户条件、验收和付款材料。
经营层需要作出的决定
| 决定 | 建议 | 理由 |
|---|---|---|
| 是否进入脱敏历史验证 | 进入 | 不接触生产写入，可以验证主要判断 |
| 是否开放自动发送报价 | 不开放 | 价格、范围和客户承诺仍需有权岗位批准 |
| 是否让所有订单增加项目审批 | 不增加 | 标准订单走快速通道，避免形成新瓶颈 |
| 是否立即承诺 ROI | 不承诺 | 验收和付款周期较长，十二周内可能尚未看到现金结果 |
需要保护的底线
- 不把未经确认的客户说法写成事实；
- 不把未发布能力写成公司能够交付；
- 不自动批准价格、合同、付款和客户承诺；
- 不用 AI 生成内容覆盖合同、财务和项目系统中的已确认记录；
- 不让一位员工因为“先点了按钮”就承担原本不属于他的责任。
2. 业务现状与证据
2.1 当前流程
| 当前步骤 | 主要责任人 | 实际使用的信息 | 当前输出 | 已观察到的等待或返工 |
|---|---|---|---|---|
| 客户需求沟通 | 销售 | 会议纪要、聊天和个人笔记 | CRM 商机记录 | 客户条件常以转述形式存在 |
| 方案准备 | 售前 | 产品资料、历史方案和个人经验 | 对客方案 | 非标准判断没有稳定入口 |
| 报价与合同 | 销售、财务、法务 | 报价表、方案和合同文档 | 已签合同 | 范围、成本和客户条件可能使用不同版本 |
| 项目交接 | 销售、项目 | 合同和销售交接单 | 项目任务 | 项目重新访谈客户并补问条件 |
| 实施与验收 | 项目、客户 | 项目计划、问题记录和验收材料 | 验收结果 | 范围争议导致返工和延期 |
| 开票与回款 | 财务、销售 | 合同节点、验收和应收记录 | 收款状态 | 财务较晚才知道项目风险 |
2.2 经营基线
| 指标 | 当前值 | 口径 | 来源 | 责任人 | 可信度 |
|---|---|---|---|---|---|
| 平均销售周期 | 92 天 | 合格商机进入至合同确认 | CRM 与合同台账 | 销售负责人 | 中，部分早期状态缺失 |
| 未充分计价的范围变化 | 41% 项目 | 签约后增加且未充分收费的工作 | 项目复盘与财务成本 | 项目、财务负责人 | 中高 |
| 平均验收周期 | 118 天 | 合同生效至客户验收 | 合同与项目系统 | 项目负责人 | 高 |
| 应收账款周转天数 | 76 天 | 以财务统一口径计算 | 财务 ERP | 财务负责人 | 高 |
| 项目交接后重新访谈 | 尚无公司级口径 | 项目为补齐签约事实再次访谈 | 试点开始记录 | 项目负责人 | 待建立 |
“尚无口径”不会被填成一个好看的估计值。试点可以先建立记录，再决定它是否值得成为长期指标。
2.3 关键样本
| 样本 | 用途 | 已确认事实 |
|---|---|---|
| YS-24-017 延期订单 | 还原第一次断点 | 售前已发现接口风险，但没有进入方案与合同决定 |
| YS-24-009 非标准顺利订单 | 寻找反例 | 对客前开过技术确认会，客户条件进入合同附件 |
| YS-24-028 标准延期订单 | 防止过度归因 | 延期来自客户负责人变更，不是非标准承诺 |
| 其余九笔对照订单 | 观察重复模式 | 五笔未确认的非标准订单均在签约后改变范围 |
订单明细、六份原始记录的教学摘录以及初步判断，见 黄金样章。在真实企业中，执行包应连接到受权限保护的原始记录，而不是复制全部客户资料。
3. 问题定义与根因假设
问题陈述
当一笔订单包含非标准要求时，云枢科技没有在方案发给客户以前，把产品能力、额外工作、客户准备条件和报价交给明确的人共同决定。未经确认的说法因此进入方案、合同或交接，签约后才变成范围变化、项目返工、验收延期和回款推迟。
根因分层
| 层级 | 已观察结论 | 仍需验证 |
|---|---|---|
| 目标与指标 | 销售关注签约，项目关注交付，财务较晚看到成本与回款风险 | 是否需要调整非标准订单的销售评价方式 |
| 流程与责任 | 非标准要求没有统一进入例外决定 | 各类例外的最终决定人和答复时间 |
| 数据与系统 | 同一客户、范围和条件散落在多个文档 | 客户主体标识和合同附件能否稳定关联 |
| 制度与权限 | “售前看过”经常被误认为“公司已经批准” | 哪些标准情况可以预先批准 |
| 人员与能力 | 判断依赖少数售前和项目负责人 | 标准能力清单由谁维护、多久更新 |
| AI 适配性 | AI 适合整理来源、比较差异和准备待办 | 对含糊客户语言的误判率和人工检查成本 |
本阶段不采纳的解释
- “销售不认真”：样本说明顺利订单也依赖明确条件，不能用岗位评价代替流程诊断；
- “项目团队效率低”：第一次断点发生在项目接手以前；
- “客户不配合”：客户确有义务，但公司没有在承诺前把义务说成可核对条件；
- “上一个更强模型即可解决”：模型不能替公司指定责任和承担承诺。
4. 目标人机协作流程
4.1 目标步骤
| 目标步骤 | AI 负责准备 | 人负责决定 | 输出状态 | 升级条件 |
|---|---|---|---|---|
| 确认客户目标 | 汇总客户原话、来源和缺失项 | 销售确认目标、决定人和时间要求 | 客户目标已确认 | 来源冲突或主体不明 |
| 核对方案能力 | 对照标准能力清单并标出差异 | 售前确认标准或非标准 | 能力已核对 | 清单过期或无法判断 |
| 决定额外承诺 | 整理工作量、客户条件、成本和合同影响 | 项目、财务、法务按责任决定 | 接受、拒绝、另行报价或延后 | 超出预先规则或答复超时 |
| 确认合同条件 | 比较方案、报价和合同的差异 | 销售及审批岗位确认最终版本 | 合同条件已确认 | 主体、价格、范围或责任不一致 |
| 准备共同交接 | 生成带来源的交接材料 | 项目和财务确认接收 | 交接已接收或退回补充 | 客户条件、验收或付款缺失 |
| 判断可以启动 | 展示未完成条件和等待对象 | 项目负责人确认是否启动 | 可以启动 | 关键条件未完成或系统无法确认 |
4.2 人工恢复
系统不可用时，员工使用经过批准的最小交接表继续工作。恢复后由原责任岗位补录已经发生的决定，AI 不根据聊天记录自动补写批准。任何状态无法确定时保留原状态，并显示“需要人工核对”。
5. 范围与边界
| 类型 | 本阶段内容 |
|---|---|
| 包含 | 会议纪要整理、来源保留、缺失识别、标准与非标准比较、例外分派、交接草稿和试点记录 |
| 不包含 | 自动撰写并发送最终报价、自动批准折扣、接受合同、承诺交期、判断员工绩效 |
| 首批订单 | 新进入的 B2B SaaS 与实施组合订单；优先覆盖带接口、迁移或额外服务的非标准订单 |
| 首批角色 | 4 名销售、2 名售前、2 名项目经理、1 名财务人员 |
| 依赖条件 | 标准能力清单、客户主体映射、批准的脱敏资料、试点账号、业务与风险负责人可按时答复 |
| 禁止动作 | 对外发送、价格和合同批准、覆盖权威事实、跨客户访问、生产批量修改 |
| 后续候选 | 经确认的信息写回 CRM、与项目和财务系统的有限状态同步 |
6. 业务对象、状态与决定规则
6.1 需要保持一致的对象
| 业务对象 | 公司认定的权威来源 | 为什么重要 |
|---|---|---|
| 客户与合同主体 | 客户主记录及已确认合同主体 | 集团名称相似不能证明由同一公司承担合同和付款 |
| 商机 | CRM | 记录客户目标、负责人和销售阶段 |
| 产品能力 | 产品团队发布的标准能力清单 | 个人经验不能代表公司已经承诺的能力 |
| 方案与报价 | 经批准的文档版本 | 对客版本必须能追溯批准和修改 |
| 合同 | 合同管理记录 | 范围、责任、验收和付款以确认版本为准 |
| 项目 | 项目管理系统 | 保存启动、交付、风险和验收事实 |
| 应收与收款 | 财务 ERP | AI 和 CRM 不得自行修改财务事实 |
6.2 核心状态
| 状态 | 进入条件 | 允许的下一动作 | 不能继续时怎样处理 | 状态责任人 |
|---|---|---|---|---|
| 客户目标待确认 | 商机进入有效沟通 | 补充来源并由销售确认 | 保持状态，列出缺失 | 销售 |
| 方案能力待核对 | 客户目标已确认 | 售前判断标准或非标准 | 交给产品或高级售前 | 售前 |
| 额外承诺待决定 | 发现至少一项非标准要求 | 接受、拒绝、另行报价或延后 | 按例外类型升级 | 对应业务负责人 |
| 合同条件待确认 | 方案和报价准备完成 | 审批最终范围、价格和责任 | 保持状态，不生成“可签署” | 销售、财务、法务 |
| 交接待接收 | 合同已经确认 | 项目和财务接收或退回 | 写明缺失和责任岗位 | 项目、财务 |
| 可以启动 | 交接条件全部成立 | 建立项目并开始实施 | 未成立条件继续可见 | 项目负责人 |
6.3 决定规则
| 规则 | 条件 | 系统表现 | 必须由谁确认 | 无法判断时 |
|---|---|---|---|---|
| R-001 | 要求完全属于当前标准能力 | 标记为标准并保留依据 | 售前 | 转产品负责人核对 |
| R-002 | 出现特殊接口、迁移、服务或验收 | 进入额外承诺待决定 | 项目或产品负责人 | 保持原状态并升级 |
| R-003 | 额外工作影响价格或毛利 | 展示成本信息并等待决定 | 财务和有权业务负责人 | 不进入最终报价 |
| R-004 | CRM 客户与合同主体不一致 | 停止合并并展示两份来源 | 销售、法务 | 不自行选择名称 |
| R-005 | 财务系统不可用 | 显示财务事实无法确认 | 财务 | 保留最近确认时间，不显示“无风险” |
| R-006 | 用户要求直接发送报价或合同 | 保留草稿并指向批准流程 | 对应批准人 | 拒绝自动发送 |
7. 数据、系统与权限
| 来源 | 可以读取 | 可以写入 | 权威程度 | 主要保护 |
|---|---|---|---|---|
| CRM | 客户、商机、会议纪要和负责人 | 试点后仅写已批准的有限状态 | 商机权威，合同与财务非权威 | 只能访问本人或试点范围客户 |
| 产品能力清单 | 已发布能力、限制和更新时间 | 不写入 | 产品能力权威 | 过期时必须提示，不能沿用个人记忆 |
| 方案与报价文档 | 已批准版本和修改记录 | 仅生成草稿，不覆盖原文 | 以批准版本为准 | 对客发送必须走原批准流程 |
| 合同记录 | 主体、范围、责任、验收和付款 | 不写入 | 合同权威 | 敏感条款只向有权限岗位展示 |
| 项目系统 | 启动、风险、验收与变更 | 试点第一阶段不写入 | 项目事实权威 | 不把 AI 判断写成项目完成事实 |
| 财务 ERP | 应收、开票和收款确认结果 | 不写入 | 财务权威 | 不展示超出岗位权限的价格和回款信息 |
所有 AI 整理结果都与原始资料、人工确认结果分开保存。员工能看见内容来自哪里、何时产生、谁确认过。客户资料只进入公司批准的环境；是否允许外部模型接触未脱敏资料，在风险负责人书面确认前默认为不允许。
重复点击、网络重试或页面刷新不能造成重复状态变更。试点开放有限写入后，每个动作都要保存操作者、时间、原状态、新状态和依据；失败时保持原业务状态。
8. 交给 AI 全栈工程师的任务
总任务
为首批九名业务用户建设一条受控的“签约前承诺核对与签约后共同交接”流程。系统帮助他们整理来源、发现缺失、比较标准与非标准要求、分派例外决定并生成待确认交接材料；不能替他们作价格、合同、客户承诺和财务决定。
开始建设前必须交回
- 用自己的话复述经营问题、第一阶段范围和禁止动作；
- 列出理解任务仍缺少的资料与规则，不得自行补齐；
- 用 YS-24-017 说明系统在哪一步停下、把问题交给谁；
- 说明每个数据来源的读取范围、权威程度和无法访问时的表现；
- 说明如何证明正常、边界、失败和高风险情况都符合预期；
- 说明试点失败后，员工怎样回到原流程且不丢失业务状态。
可以自主完成
- 在已批准的脱敏资料和试点环境内提出方案并建设；
- 根据执行包拆分任务、测试和修复缺陷；
- 设计页面和交互，只要不改变已确认的业务状态与权限；
- 整理每次验收的输入、表现、结果和限制；
- 准备监控、人工接管、恢复和部署资料。
必须暂停并请求 FDE 决定
- 两份业务规则互相冲突或责任人无法确认；
- 需要扩大客户、系统或生产权限；
- 需要改变价格、合同、财务、项目完成或员工权益事实；
- 验收样本无法达到预期，或修复需要改变目标流程；
- 发现客户资料越权、错误对客承诺或无法恢复的状态变化。
阶段交付
| 阶段 | 工程师交付 | 业务和 FDE 审查 | 通过后获得什么授权 |
|---|---|---|---|
| 理解 | 问题复述、缺口、数据与权限清单 | 是否误解经营规则 | 进入方案设计 |
| 方案 | 用户过程、状态、异常、恢复和计划 | 是否符合责任边界 | 使用脱敏样本建设 |
| 历史验证 | 十二类以上用例、失败记录和修正证据 | 是否达到有限试点条件 | 进入只读新订单试点 |
| 有限试点 | 使用、接管、错误、成本和业务过程记录 | 是否可以有限写入 | 另行审批，不自动获得 |
9. 验收用例
每次验收都保存使用的脱敏输入、系统显示、状态是否变化、人工判断和失败后的处理。下面是首批核心用例，不是只有标题的分类清单。
第 3 卷的未来检验订单 YS-P-001 不另建一套测试。它包含的第三方授权缺失、集团与法人冲突、18% 特殊折扣、直接发送请求和系统故障，分别落入 AC-03、AC-05、AC-06、AC-08 与 AC-12；付款来源不可用时再使用 AC-07。这样目标蓝图和执行包使用同一组经营边界。
| 编号与情况 | 关键输入 | 预期表现 | 禁止结果 | 判断人 |
|---|---|---|---|---|
| AC-01 标准订单 | 客户目标完整，能力属于标准清单 | 整理来源，生成待确认材料 | 自动发送给客户 | 销售、售前 |
| AC-02 缺少决定人 | 有需求，无客户决定人和采购时间 | 列出缺失问题，保持客户目标待确认 | 猜测客户已经准备购买 | 销售 |
| AC-03 第三方接口未确认 | 客户转述可接入，第三方无书面确认 | 标出来源差异，停在能力核对 | 写成接口已经具备 | 售前、项目 |
| AC-04 未发布能力 | 客户要求当前版本没有的能力 | 进入额外承诺待决定 | 写成公司可以交付 | 产品、项目 |
| AC-05 客户主体冲突 | CRM 为集团，合同为子公司 | 停止合并，展示两份来源 | 自行选择相似名称 | 销售、法务 |
| AC-06 特殊折扣 | 折扣超出预先批准范围 | 指向财务与有权负责人 | 自动批准或隐藏毛利影响 | 财务、销售负责人 |
| AC-07 财务系统不可用 | 无法取得最新应收状态 | 显示“无法确认”及最后确认时间 | 显示没有逾期风险 | 财务 |
| AC-08 直接发送请求 | 用户要求绕过批准发报价 | 保留草稿，拒绝自动发送 | 对外发送或伪造批准 | 销售负责人 |
| AC-09 资料越权 | 用户尝试读取非试点客户合同 | 拒绝访问并留下记录 | 用相似客户资料补充答案 | 数据、安全负责人 |
| AC-10 重复提交 | 同一确认动作被连续提交两次 | 只保留一次有效状态变化 | 生成两个决定或两个项目 | 工程师、业务负责人 |
| AC-11 负责人拒绝接收 | 项目认为客户条件不完整 | 保持交接待接收并说明缺失 | 把销售提交视为完成 | 项目负责人 |
| AC-12 系统中断 | 生成交接材料时服务不可用 | 保留原状态并显示人工路径 | 显示交接已经完成 | 工程师、业务负责人 |
AC-05 曾在第一次验收失败：系统根据名称相似度选择了集团主体。修正后，任何主体冲突都必须停止合并。这条失败记录保留为后续版本的固定检查。
10. 试点、升级与恢复
| 阶段 | 订单与权限 | 观察重点 | 进入下一阶段的条件 |
|---|---|---|---|
| 第 1—2 周 | 10 笔历史脱敏订单，只读 | 能否找到已知断点，是否保留来源 | 核心历史错误被识别，禁止动作未发生 |
| 第 3—6 周 | 少量新订单，只生成草稿和提醒 | 员工是否愿意使用，人工检查成本 | 业务行为正确，人工接管有完整上下文 |
| 第 7—12 周 | 经批准后写有限状态 | 重复写入、权限、恢复和流程采用 | 状态变化可追溯，恢复演练通过 |
| 后续扩大 | 另行决定客户和团队范围 | 经营结果、成本、风险和采用 | 经营层依据完整证据作决定 |
立即停止条件
- 错误范围、价格或能力被发送给客户；
- 用户访问了不属于其权限的客户资料；
- AI 生成内容覆盖合同、财务或项目权威事实；
- 系统显示业务已经完成，但实际动作失败；
- 故障后无法判断订单处于什么状态。
恢复动作
价值流负责人宣布暂停新流程；员工使用批准的最小交接表继续工作；工程师保留故障前状态和受影响订单；相应数据负责人核对是否存在错误写入；恢复后由业务责任人决定哪些记录补录。系统不得根据推测自动“修好”业务事实。
11. 经营结果与投入观察
| 类型 | 指标 | 基线 | 十二周试点怎样看 | 责任人 |
|---|---|---|---|---|
| 过程 | 非标准要求在对客前有决定记录 | 尚未统一记录 | 每笔试点订单都检查 | 价值流负责人 |
| 返工 | 项目接收后重新追问范围 | 试点前建立对照样本 | 记录次数和原因，不只记录是否发生 | 项目负责人 |
| 周期 | 合格商机到合同确认 | 公司平均销售周期 92 天 | 按标准和非标准订单分别比较 | 销售负责人 |
| 质量 | 未充分计价的范围变化 | 41% 项目 | 等订单进入交付后再判断 | 项目、财务负责人 |
| 现金 | 验收与回款时间 | 验收 118 天，应收 76 天 | 未走到付款终点前不宣布改善 | 财务负责人 |
| 采用 | 新订单经过目标流程的比例 | 0 | 同时记录绕过原因和人工负担 | 业务负责人 |
| 风险 | 错误承诺、越权和人工接管 | 尚未统一记录 | 每次事件保留来源、影响和处理 | 风险负责人 |
| 投入 | 建设、模型、资料整理和人工检查 | 试点开始记录 | 每周汇总，不只计算模型费用 | FDE、工程师 |
只有收益和投入都进入观察，才可以讨论 ROI。节省准备时间、减少无偿返工和加快回款可能构成收益；建设、模型使用、资料治理、人工检查和岗位改变都属于投入。
十二周结束时，如果大多数订单尚未验收和付款，经营层只能说过程指标是否改善，不能把预测中的现金收益写成已经实现。
12. 最终证据清单与下一次决定
已经具备
- 经营层授权与灯塔价值流选择；
- 一笔延期订单的六份冲突记录；
- 十二笔顺利、延期和反例订单的对照；
- 经销售、售前、项目和财务确认的问题定义；
- 六个目标业务状态和六条主要决定规则；
- 首批数据来源、读取范围和禁止动作；
- 十二条正常、边界、失败和高风险验收用例；
- 分阶段试点、停止和恢复方法。
进入有限写入前仍需补齐
- 风险负责人确认未脱敏资料允许进入的环境；
- 数据负责人确认客户与合同主体的稳定关联方法；
- 财务负责人确认可以读取的应收状态和故障表现；
- 工程师完成重复提交、权限拒绝和中断恢复证据；
- 九名试点用户完成一笔真实订单的走查并确认职责。
下一次经营层只能作四种决定
| 决定 | 适用证据 |
|---|---|
| 扩大 | 业务行为正确、员工持续使用、风险可控，并出现值得扩大观察的经营变化 |
| 保持 | 过程方向改善，但样本、时间或现金结果仍不足 |
| 缩小 | 局部有价值，但人工负担、数据质量或风险高于预期 |
| 停止 | 错误承诺、越权、不可恢复或经营价值假设不成立 |
这份执行包的目标不是把所有未知消灭，而是让未知、责任、权限和下一步决定都看得见。
返回 黄金样章：我怎样改造商机到回款，或查看可迁移使用的 FDE 执行包空白模板。