← 交付方法总览
方法论可泛化原则
反模式目录（Anti-Pattern Catalog）
横切
把交付里反复出现的坏做法集中列出来，每条写清楚它长什么样、为什么诱人、代价在哪、正确做法是什么。它的用途是评审时快速对照，而不是事后复盘时才想起。
什么时候需要它
- 评审一个方案，想知道它有没有踩已知的坑
- 团队在讨论一个「先这样、以后再改」的方案
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
Demo 驱动交付
用演示效果代替可行性判断。Demo 用挑好的输入跑通，生产面对的是真实措辞和脏数据，两者之间的差距通常远大于预期。
兜底掩盖失败
用一句「暂时无法回答」把真实失败吞掉，指标好看但用户拿不到结果。兜底应当在根因修复之后作为最后防线，不能替代修复。
Prompt 万能论
遇到任何问题都往系统提示词里再加一条规则。规则叠加会拉低单条遵从率，越加越不可控。
改到测试变绿
不定位责任层，直接调整实现或放宽断言，直到流水线通过。同类问题会换个入口重新出现。
批量修复
一次性调整一大批失败样本，改完之后无法判断哪次改动起了作用，也无法定位新引入的回归。
自报完成
以开发者自己跑通为完成标志。独立验证之所以必要，是因为构造条件的人往往会不自觉地绕开难点。
口径靠猜
工程侧替业务侧定义业务术语，上线后被推翻。口径必须由能裁定的人确认并留痕。
怎么判断它真的到位
- 评审时能逐条对照，明确说出方案没有踩哪几条
- 近期修复里没有出现「只加兜底不查根因」的情况
- 每次修复都能指向一个具体的责任层与单个稳定复现的 case
常见误区
- 把反模式清单当成事后复盘材料，评审时从不拿出来
- 承认踩了坑但以「这次特殊」为由继续
- 只识别技术类反模式，忽略口径与责任类反模式
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。