4.1 我不写代码，为什么仍要对交付负责
我第一次把云枢科技的“商机到回款”项目交给 AI 全栈工程师时，它问我：“你想要哪些页面？”
我差点顺着这个问题回答：销售首页、客户详情、风险提醒、项目交接单。可这些只是我脑中最容易想象的界面，不是公司真正要改变的工作。
如果我把页面列完，工程师很可能很快做出一个像样的系统。等销售真正使用时，我们才会发现：谁应该在什么时候打开它、哪些资料可以相信、什么情况不能继续、谁有权确认客户承诺，全都没有说清楚。
那样的失败不能怪工程师。是我把经营问题伪装成了页面需求。
我先说清楚自己到底负责什么
FDE 不一定亲自写代码，但要对系统进入真实经营以后是否有用负责。
在这条价值流里，我需要说清六件事：
- 公司为什么要改变这项工作；
- 现在的问题依据哪些订单和数据；
- 未来销售、售前、项目、财务和 AI 分别做什么；
- 哪些事实可信，哪些动作需要批准；
- 正常、缺失、冲突和越权时分别应该怎样表现；
- 上线后用什么结果判断值得继续。
AI 全栈工程师负责把这些要求变成能够运行的系统。它选择怎样组织程序、怎样连接现有系统、怎样测试和部署，也负责说明技术限制、成本和风险。
我们不是“提需求的人”和“接需求的人”。我们分别对经营判断和工程实现负责。
| 事情 | 主要决定人 | 不能被替代的责任 |
|---|---|---|
| 为什么要做、先改哪条工作 | FDE 与业务负责人 | 用经营证据说明价值 |
| 人和 AI 怎样分工 | FDE 与岗位负责人 | 客户承诺和例外必须有人负责 |
| 采用什么实现办法 | AI 全栈工程师 | 说明技术选择、限制与代价 |
| 哪些资料能读、哪些动作能写 | 业务、数据和风险负责人 | 授权不能由工程师自行扩大 |
| 什么叫完成 | 业务负责人、FDE、工程师 | 业务行为与工程质量都要通过 |
一次含糊的交付让我看见责任不能外包
在早期试验里，我只对工程师说：“帮助销售在签约前发现项目风险。”
工程师做出的第一版会读取销售纪要，并根据其中的词语给出风险提示。演示时看起来很聪明，但我们拿一笔延期订单测试，它把销售写下的“客户原则上同意提供接口”当成了已经确认的客户条件。
项目经理马上指出：“原则上同意和合同条件不是一回事。”
工程师没有做错我写下的要求，因为我从来没有说明销售笔记、客户邮件、方案和合同的可信程度不同，也没有说明 AI 只能提示，不能确认客户已经履行条件。
我重新承担起自己的部分：把事实来源、确认人和允许动作写清楚。工程师则重新设计系统，让原始资料、AI 整理和负责人确认的结论分开显示。
这次经历让我明白，不写代码并不会减少 FDE 的责任。恰恰相反，我必须把那些代码无法替公司决定的事情说明白。
我也不能替工程师作技术决定
划清责任不是让我控制所有细节。
我不会指定每个按钮放在哪里，也不会因为听说某个模型热门，就要求工程师必须使用它。我更不会用一句“要实时、要准确、成本还要低”代替取舍。
我会说明真实约束。例如，销售在客户通话前最多能等多久；合同资料不能进入哪些外部服务；财务系统每天什么时候更新；一个错误承诺可能造成什么损失。
工程师依据这些约束选择方案。如果它告诉我，要同时满足速度、质量和成本不现实，我需要和业务负责人一起决定先保护什么，而不是要求技术把矛盾变没。
我们用“复述”代替直接开工
每次交付开始前，我都请 AI 全栈工程师先回来复述：
- 它理解公司现在发生了什么问题；
- 第一批使用者是谁，他们在什么时刻使用；
- AI 可以准备什么，人必须决定什么；
- 它需要读取哪些资料、写入哪些系统；
- 资料缺失、相互冲突或系统不可用时会怎样；
- 它还缺哪些答案，准备怎样证明第一版做对了。
复述不是形式。工程师说错的地方，往往就是执行包仍然含糊的地方。
有一次，工程师把“生成待确认交接单”复述成“自动创建项目”。只差几个字，权限却完全不同。我们在建设前发现，总比上线后再追查谁创建了错误项目便宜得多。
遇到矛盾时，工程师必须能停下来
AI 全栈工程师不是只负责完成任务，也要负责暴露无法完成的地方。
如果合同要求与任务书冲突、现有系统没有所需资料、权限不足以留下审计记录，或者一个验收要求技术上无法稳定实现，它必须把问题交回来。
我也不能把这种提问理解为“不配合”。工程师越早指出矛盾，FDE 越有机会组织正确的人决定。
我们约定了一个简单原则：工程实现可以由工程师决定，经营含义、权限扩大和风险接受必须回来确认。
我怎样判断这条边界真正成立
我不会用“双方都说清楚了”作为证据。我会做三次检查。
第一次，请工程师用自己的话讲一笔订单未来怎样走。第二次，请业务人员拿一个异常订单追问系统会怎样停下。第三次，临时改变一条业务规则，看团队是否知道谁决定、谁修改、谁重新验收。
如果每次变化都只能来找 FDE 口头解释，边界还没有写进执行包。如果工程师能够独立选择实现方式，又不会越过业务责任和权限，合作才真正成立。
这次交付最终怎样分责
| 事项 | 最终决定人 | 必须提供的证据 | 必须停下来升级的情况 |
|---|---|---|---|
| 灯塔目标、范围和继续投入 | 价值流负责人，重大资源由 CEO 决定 | 订单损失、基线、过程与风险变化 | 目标改变或收益假设不再成立 |
| 人机分工、状态和业务规则 | 销售与交付负责人 | 顺利、延期和边界订单的经营解释 | 负责人之间无法确认同一事实 |
| 技术方案、建设、部署和工程质量 | AI 全栈工程师 | 可复现的测试、限制、成本和运行证据 | 所需权限或资料超出执行包 |
| 客户、合同、项目和财务事实 | 对应数据、法务、项目和财务负责人 | 权威来源、版本、可见范围和故障表现 | 来源冲突或无法留下审查记录 |
| 业务验收和进入试点 | FDE 组织，各业务判断人确认 | 真实输入、预期、禁止结果、失败与恢复 | 高风险案例失败或恢复无法完成 |
“共同负责”只保留在销售与交付共同承担商机到回款结果这一层；具体到 18% 折扣、非标准接口、合同主体或系统恢复时，都有单独的最终决定人。
这张表成为 已填写执行包 的交付边界。下一节把目标蓝图和诊断证据压缩成工程师第一次复述时必须理解的一页业务任务书：我怎样把经营问题写成任务书。