3.7 一次 AI 动作怎样变成经营闭环

YS-P-001 的资料助手第一次运行时，正确指出“第三方接口授权尚未取得”。销售看到了提示，在会议群里问了客户，却没有改变订单状态。第二天，AI 又生成同一条提示。

如果我们只统计识别正确率，这次运行是成功的；如果看经营结果，什么也没有改变。

我追的不是提示，而是下一件真实动作

我问销售：“客户回复以后，这笔订单会在哪里变成可以继续，或者不能继续？”他指了指聊天记录。售前不知道客户已经回复，交付也不知道授权只覆盖测试环境，报价仍在向前准备。

问题不在 AI 没发现风险，而在公司没有为发现后的工作安排状态、负责人和完成证据。一个准确建议落进群聊，仍然会变成新的信息孤岛。

我把这次提示改成“待事实确认”状态。AI 保留客户原话、缺失资料和来源；销售负责向客户确认；售前判断授权是否满足能力条件；两人完成决定后，订单才能回到“待能力确认”或被停止。系统记录的不只是“已读”，而是确认了什么、谁确认、下一步是什么。

环节	YS-P-001 中发生什么	谁负责	留下什么
目标	在客户承诺前暴露并处理非标准条件	销售与交付负责人	承诺质量和等待目标
证据	会议原话、第三方授权、产品能力和历史订单	AI 整理，员工确认来源	带版本和时间的资料
判断	当前授权不足，不能写成“接口已确认”	AI 指出缺失，售前解释边界	判断与未知分开
决定	补充正式授权、改变范围、调整价格或停止	销售与交付负责人	有负责人和期限的决定
行动	更新订单状态和对客方案，通知下游	系统连接，销售确认对客内容	新状态和发送版本
结果	客户是否补齐条件，项目是否减少签后返工	价值流负责人复核	进入后续订单比较的结果

这六步中任何一处写成“相关人员处理”，循环都会断开。AI 可以持续提醒，但它不能替销售取得客户承诺，也不能替交付接受工作量。

YS-P-001 如果最终签约，不能直接说明提示有用；客户可能只是预算充足。它如果输单，也不说明提示有害；也许公司及时拒绝了一笔无法盈利的业务。

十二周内，我们先看三类较近的证据：缺失从出现到被负责人认领用了多久；订单是否在未知条件下错误前进；人工纠正是否让下一次整理使用了正确来源。项目毛利、验收和尾款要等订单走过更长周期，再与类似订单比较。

真实更正也不能不经判断就“喂回 AI”。如果销售把一项高风险要求误改成标准能力，那是一条待复核的更正，不是新的公司规则。产品、售前或数据主人先确认资料含义，再决定它应更新规则、对象关系，还是只属于这笔订单。

销售负责人拥有从有效商机到承诺确认的周期与质量，交付负责人拥有非标准范围、交接和返工，财务负责人观察价格与尾款风险。我负责让三个结果沿同一订单连接，AI 全栈工程师负责状态、记录、提醒和故障恢复。

系统不可用时，销售维护带时间的最小人工记录；恢复后由系统主人和销售核对补录。负责人休假时，例外送给已经指定的替补，不能让持续运行的 AI 把任务交给一个无人处理的账号。

我会让团队沿 YS-P-001 回答：提示出现以后谁认领，客户回复进入哪里，售前怎样确认，超时谁收到升级，订单为什么继续或停止，结果如何进入下一次复核。工程团队不能只演示 AI 输出页面。

蓝图 0.7 因此增加了结果状态和经营复核。完整填写内容见这不是一个只会给建议的系统。当一条循环跨过销售、交付、财务和共同系统，下一项问题就出现了：身份、日志和系统连接由中心团队建设，客户资格和承诺规则又由谁决定？下一节处理这个组织边界：平台团队和业务团队谁说了算。