← 交付方法总览
方法论可泛化原则
角色定义与 RACI
横切
把 Agent 交付里最容易扯皮的六件事——业务口径、验收标准、数据权限、发布放行、生产事故、经验回写——各自钉死一个唯一负责人。它消灭的是三类高频事故：没人决定、多人各自决定、决定了但没人执行。
什么时候需要它
- 同一个问题在两次会议上得到两个相反结论
- 上线前找不到能拍板放行的人
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
六件事各有唯一 Owner
业务口径、验收标准、数据与权限边界、发布放行、生产事故、经验回写。每件事只能有一个最终负责人，其余角色是被咨询或被通知。
业务口径归业务方
「逾期怎么算」「哪些单据算有效」这类定义只能由业务侧裁定，工程侧负责把裁定结果固化成可测的判据，而不是自己发明定义。
数据与权限边界归数据/安全侧
Agent 能访问哪些表、哪些字段、以谁的身份访问，是交付要求而不是上线前的加固项。这条不能由实现方自行放宽。
发布放行需要独立验证
自报完成不构成放行依据。放行人应当能看到独立跑出来的证据，而不是开发者的口头结论。
经验回写要有人盯
缺陷修完之后谁负责把它变成 Eval 用例或护栏，必须落到具体的人身上，否则学习闭环永远断在最后一米。
怎么判断它真的到位
- 六件事各写得出唯一姓名，且当事人本人知道
- 最近一次上线的放行依据是独立跑出的结果，不是开发自述
- 口径变更有记录，能追到是谁在什么时候改的
常见误区
- 把「大家一起负责」当成协作，实际是无人负责
- 工程方替业务方定义口径，上线后被推翻
- 权限边界留到上线前才谈，导致返工或临时放宽
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。