3.11 我为云枢科技画出的目标蓝图

设计结束时，我没有向 CEO 展示一套庞大的技术架构。我用未来检验订单 YS-P-001 讲完云枢科技怎样工作。

这张图不是愿景海报。它把第 2 卷发现的承诺断点、资料冲突、责任缺失和回款等待，逐一对应到未来工作。任何新增能力若找不到它要改变的断点，就不进入第一阶段。

证据边界：YS-P-001 是虚构的未来检验情境。蓝图说明公司准备怎样工作和怎样验收，不表示这些改变已经在真实客户中取得结果。

一笔订单未来怎样走

客户被销售确认成有效商机后，AI 整理公司背景、历史联系和缺失问题；销售确认客户目标；售前对照标准能力和额外要求；价格、范围与责任由对应负责人批准；签约后，项目和财务接收同一份交接材料；实施、验收和付款风险持续被发现并送到明确的人。

AI 不直接向客户承诺，不修改已确认合同和财务事实。每个建议保留来源，每个动作使用独立身份，每类异常有负责人。

在 YS-P-001 中，客户会议结束后，AI 整理十二周上线、旧会员系统接入、历史迁移和 18% 折扣，同时指出第三方授权缺失。销售修改错误事实，数据主人区分集团与签约主体，售前确认能力，超出标准的范围与折扣分别交给交付和财务。条件齐全后报价才能对客，项目和财务在签约后接收同一组事实。

若客户名称无法确认、资料来源冲突、承诺越界或负责人不在线，订单停在对应状态。员工能看到缺什么、找谁、何时升级。系统不可用时保留最少人工交接，恢复后补齐记录。

这条异常路线与正常路线一样重要。没有它，蓝图只能解释演示，不能解释公司怎样经营。

目标蓝图经历了十次修订。第一版只有订单入口和理想路径；责任迁移加入例外队列；AI 形态选择限制自主范围；共享事实区分集团与法人；独立身份和动作分级控制访问与发送；经营循环把提示连接到结果；最后由联邦责任、转型小队和前置治理把决定落实到组织。

任何一项单独存在都不够。只有共享事实没有负责人，冲突会一直等待；只有批准按钮没有动作分级，员工会机械点击；只有日志没有业务对象，事故后仍找不到哪些订单受影响。

客户、产品、合同、项目和指标形成共享上下文；身份、权限、日志、评测和模型接入由中心团队提供；销售到回款的流程与经营结果由价值流负责人拥有。

转型小队每周处理订单、证据和失败，经营层每月决定授权扩大、保持、缩小或暂停。

平台团队不拥有销售规则，销售团队也不能自行绕过身份与资料边界。价值流负责人决定经营目标和采用，数据主人确认客户与合同事实，专业岗位处理风险，AI 全栈工程师维护实现和运行。

我在图上把每个交界面写出输入、输出、负责人和失败处理，避免一个“共享平台”方框掩盖所有责任。

诊断基线仍然是销售周期 92 天、验收周期 118 天、应收周转 76 天，41% 项目出现未充分计价的范围变化。十二周先观察非标准要求是否更早暴露、资料退回与等待、人工接管、双录和风险错误；毛利、验收和尾款需要等新订单走完更长周期。

指标沿同一条价值流连接。签约更快但项目返工上升，说明问题只是向后移动；自动完成增加但员工仍维护旧表，说明采用没有成立；成本下降但客户资料越界，也不能扩大。

经营层每月根据证据选择扩大、保持、缩小或停止。蓝图描述目标方向，不保证所有部分一次实现，也不把一个过程指标变好直接归因于 AI。

第一类是普通非标准订单，检查最短路径；第二类是第三方授权缺失，检查 AI 是否停下；第三类是 18% 特殊折扣，检查批准；第四类是 CRM 故障，检查人工恢复；第五类是错误版本已经发送，检查影响追踪和纠正。

销售、项目、财务、风险和一线岗位共同走图，工程师记录需要实现的状态与控制。任何人发现职责与现实不符，都先改蓝图，不让工程师用技术细节掩盖业务空白。

检验事件	AI 应该怎样表现	人必须作什么决定	蓝图何时算通过
普通非标准订单	找齐获准来源，准备差异与交接	销售、售前和交付按责任确认	项目收到同一组已确认事实
第三方授权缺失	保留客户原话并明确说未知	销售补问，售前判断能否继续	未补齐前不能形成可发送报价
18% 特殊折扣	准备合同价值、服务成本和相似订单	销售与财务接受、拒绝或附条件批准	没有批准就不能发送
CRM 故障	停止正式读写并显示最后更新时间	销售维护最小记录，系统主人恢复	恢复后核对补录，无重复或丢失
错误版本已发送	暂停同版本动作并列出可能受影响订单	销售处理客户，风险决定通知	影响、纠正和恢复证据完整

下一卷不会提供源码，也不要求读者写代码。我们会把蓝图拆成一组业务任务、用户、触发、状态、资料、权限、验收和运行要求，组成可以交给 AI 全栈工程师的执行包。

工程师可以使用 AI 从零建设，但不能自行发明客户承诺、审批和责任。蓝图是业务与工程之间共同确认的起点。

完整填写版保存在云枢科技已填写 AI 目标蓝图。它不仅展示最终表，还保留 0.1 到 1.0 的修改原因、七个业务状态、六类对象、独立 AI 身份、动作权限、异常恢复、组织责任、指标和未决事项。

下一卷会继续使用 YS-P-001，把“未来应当怎样工作”拆成 AI 全栈工程师可以建设和业务团队可以验收的任务资料。正文依然不提供源码，也不要求读者写代码，但不能让工程师猜测用户、触发、状态、权限和失败处理。下一步进入：AI 交付工程。