跳到主要内容
← 交付方法总览
方法论可泛化原则

核心原则(Core Principles)

横切

21 条交付原则的权威主文。它们不是价值观宣言,而是在具体场景下用来裁决的判据——尤其是当两条正确的诉求互相冲突、必须有人拍板的时候。

什么时候需要它

  • 两个方向都说得通,需要一个不靠职级的裁决依据
  • 评审时想判断某个做法是不是走了捷径

核心内容

它决定什么

  • 顺序类原则

    先业务结果、先证据后假设、先验收后实现、先源头真相后模型推理。共同点是把「容易被跳过的前置动作」显式排在前面。

  • 分治类原则

    结构层用确定性契约、LLM 行为用 Eval;通用方法论与项目适配层必须分离。用错工具或混淆层次是质量崩塌的常见起点。

  • 修复类原则

    先根因后兜底、先责任层后改码、先单 Case 后全量、先稳定复现后优化、独立验证优先于自报完成。它们共同定义了「一个修复算不算完成」。

  • 沉淀类原则

    生产反馈必须变成 Eval 资产、可强制的规则变成测试或护栏、文档需要出处与版本、Handoff 是一等交付物。另有两条反向约束:不要把每条经验都写成文档,能固化就固化;不要把历史决策当成当前最佳实践。

  • 横切类原则

    安全与权限边界是交付要求而非加固项;模型变更是生产变更;流程完成不等于用户拿到可用交付物;通过率提高但评判标准被削弱则毫无意义。

怎么判断它真的到位

  • 安全权限边界与源头真相被当作硬底线,任何时候不让渡
  • 证据优先、责任层优先、独立验证优先于速度诉求——宁可慢,不可把退化发布出去
  • 「先业务结果」只用于裁掉不推进结果的工作,不用于跳过验收或稳定复现
  • 剩余分歧有明确的升级路径和人工决策条件,而不是不了了之

常见误区

  • 把原则贴在墙上但从不在评审里真正引用
  • 用「业务着急」压过验收与复现,把退化直接发到生产
  • 把某个历史项目的决策当成当前最佳实践,不复核前提是否还成立

这套方法怎么落到你的项目

这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时,从 AI Agent 生产就绪审查与路线图 入手,或先用 生产上线前深检 定位薄弱环节。