← 交付方法总览
方法论可泛化原则
核心原则(Core Principles)
横切
21 条交付原则的权威主文。它们不是价值观宣言,而是在具体场景下用来裁决的判据——尤其是当两条正确的诉求互相冲突、必须有人拍板的时候。
什么时候需要它
- 两个方向都说得通,需要一个不靠职级的裁决依据
- 评审时想判断某个做法是不是走了捷径
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
顺序类原则
先业务结果、先证据后假设、先验收后实现、先源头真相后模型推理。共同点是把「容易被跳过的前置动作」显式排在前面。
分治类原则
结构层用确定性契约、LLM 行为用 Eval;通用方法论与项目适配层必须分离。用错工具或混淆层次是质量崩塌的常见起点。
修复类原则
先根因后兜底、先责任层后改码、先单 Case 后全量、先稳定复现后优化、独立验证优先于自报完成。它们共同定义了「一个修复算不算完成」。
沉淀类原则
生产反馈必须变成 Eval 资产、可强制的规则变成测试或护栏、文档需要出处与版本、Handoff 是一等交付物。另有两条反向约束:不要把每条经验都写成文档,能固化就固化;不要把历史决策当成当前最佳实践。
横切类原则
安全与权限边界是交付要求而非加固项;模型变更是生产变更;流程完成不等于用户拿到可用交付物;通过率提高但评判标准被削弱则毫无意义。
怎么判断它真的到位
- 安全权限边界与源头真相被当作硬底线,任何时候不让渡
- 证据优先、责任层优先、独立验证优先于速度诉求——宁可慢,不可把退化发布出去
- 「先业务结果」只用于裁掉不推进结果的工作,不用于跳过验收或稳定复现
- 剩余分歧有明确的升级路径和人工决策条件,而不是不了了之
常见误区
- 把原则贴在墙上但从不在评审里真正引用
- 用「业务着急」压过验收与复现,把退化直接发到生产
- 把某个历史项目的决策当成当前最佳实践,不复核前提是否还成立
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时,从 AI Agent 生产就绪审查与路线图 入手,或先用 生产上线前深检 定位薄弱环节。
