夜雨聆风
AI 协作实战 · 方法论分享
过去我一度以为，只要我不断切换产品、架构、测试的角色，反复去审，总能把一个技能优化到无懈可击。
但事实狠狠打了我的脸——之前一个没有审核问题的技能，今天审核的时候又写了一堆问题。什么情况？
真相只有一个：AI 技能是不存在"审查视角下的完美状态"的。
为什么会这样？
审查本质上也是一种"生成行为"
因为审查本质上也是一种"生成行为"。
面对同一段自然语言，只要你换一个角色、换一个时间、换一种语境去问，大模型总能根据新的上下文"生"出新的改进点。
审查发现率，永远不会归零。
⚠️ 核心警示
千万不要再把"审查不出问题"当作检验标准。
那身份切换审查还有意义吗？
有，但必须重新定位它的价值
有，但必须重新定位它的价值。身份切换审查的唯一用途，是"上线前把关"。
它的目标不是打造一个完美的技能文本，而是确保技能在交给执行环境之前，那些真正会导致错误的关键问题已经被处理掉了。
审完这轮，就可以尽快进入实战验证阶段，而不是继续停留在审查里打转。
怎么判断审查给出的问题该不该修？
ABC 分类法，一条硬杠杠
为了防止在审查时陷入无休止的扯皮，我划了一条硬杠杠——
只看这个问题是否会导致最终执行产出错误。
所有审查发现的问题，不做任何预先筛选，逐条走以下判定链（C 类天然兜底，无效建议最终都会落进 C 类被忽略）：
会导致确切错误产出的硬性错误。必须处理。
可能会引起 AI 理解歧义，但未必会实际出错的软伤。修复成本低就顺手修，成本高就先记录，留给实战去验证。
纯表述风格、排版美化、锦上添花的建议。改和不改，最终产出的结果一样，直接无视。
🎫 分类铁律：没有证据就降级
A 类的门票是"触发案例"：必须写明输入什么、走到哪一步、会产出什么错误结果。写不出，降入 B 类。
B 类的门票是"两种解读及其产出差异"：必须写明两种合理解读分别是什么、各自会产出什么不同结果。写不出，直接归 C。
只要给不出对应的证据，不管原报告标得再严重（高/中/低一概不采信），都按缺票降级处理。
送你一个"AI 判定专家"提示词
直接复制粘贴，即刻可用
上面说的文字逻辑，已经落地成可以直接复制粘贴发给 AI 的自动化判定提示词。把上一轮审查出来的问题清单贴上去，让它一次性帮你做完 A/B/C 归类：
📋 直接复制以下内容 ↓
你是一名技能文档（SKILL.md）审查结果判定专家。
你的职责是【判定】，不是【审查】：只对下方给出的已有问题清单逐条分类，禁止自行发现新问题、禁止扩充问题清单。
前置处理：若问题清单本身无编号，请按顺序自动编号（P1、P2、P3…）后再进行判定。
对每条问题，按以下顺序执行判定：
【A 类判定】
不修改此内容，能否构造出一个具体输入案例，导致最终产出确凿错误？（如：编译失败、SQL报错、写错文件、数据错误、该中止未中止）
✅ 能 → 判为【A 类-必须修】，必须完整写出触发案例：输入是什么、走到哪一步、产出什么错误。❌ 写不出完整触发案例 → 进入 B 类判定。
【B 类判定】
此内容是否存在两种合理解读，且不同解读会导致最终产出不同？
✅ 是 → 判为【B 类-酌情修】，必须列出：两种解读分别是什么、各自产出什么不同结果，并给出建议修复方案（一句话即可）。❌ 列不出两种解读及其产出差异 → 归入 C 类。
【C 类判定】
纯表述优化、措辞润色、排版美化、补充背景、"建议更严谨"类。判为【C 类-一律不修】。
判定铁律：
• 不采信原审查报告标注的严重度（高/中/低），只按上述判定链重判。
• 触发案例是 A 类的唯一门票：写不出"输入→步骤→错误结果"完整链条的，一律不得判 A。
• 两种解读及产出差异是 B 类的唯一门票：写不出的一律归 C。
• 拿不准时向下降级（A拿不准判B，B拿不准判C），宁可漏修，交给实战验证兜底。
输出格式（必须严格遵守）：
编号 | 原问题摘要 | 判定 | 触发案例/解读差异（A/B必填，C填"无"） | 建议方案（仅B类填写）
整体结论（必须回答）：
• A 类问题数量：X 个（为 0 则写"无"）
• B 类问题数量：X 个，其中建议顺手修 X 个、建议记录待实战验证 X 个
• 是否建议结束审查、进入实战验证：是 / 否（若否，说明卡在哪条 A 类）
待判定的问题清单如下：[在此粘贴你上一轮审查报告的问题列表]
切换身份审查走几轮合适？
标准 2 轮、上限 3 轮
既然明确了只是"上线前把关"，审查轮次定为标准 2 轮、上限 3 轮，且必须明确切换身份。
技能初稿完成后，让 AI 切换成产品、架构、开发、测试四个角色，各审视一遍。目标明确：只抓 A 类和低成本的 B 类，C 类直接跳过。
不再是铺开找新问题，只做一件事：
验证第一轮修复有没有引入新问题？技能的核心硬约束（比如中止条件、强制输出格式）是否均已落实。
当本轮剩余的全是 C 类时，审查结束。
修复后的最终验证。这是轮次上限，用完必须停。
💥 停手警告
如果第 3 轮还在发现 A 类问题，说明病根已不在措辞上，而是技能底层的流程结构设计出了毛病（分支太复杂、职责不清）。继续在文字上修修补补只会引发"震荡"——改了这里又坏了那里。唯一正确的解法是立刻停手，直接去重构技能底层逻辑，而不是在提示词上死磕。
什么样的结果算是真的可以了？
从"审查视角"切换到"执行视角"
敲黑板：审查通过，绝不等于验收通过。
我把"可以了"的标准，彻底从"审查视角"切换到了"执行视角"。必须同时满足以下三个条件：
不再靠肉眼去审，而是找 3-5 个真实的、差异化的业务场景，让技能完整跑完整个流程。注意：跑通 ≠ 跑对——必须做到全程自动化跑通，且产出结果无需人工纠正，才算真正合格。流程不报错但生成内容是错的，同样不过关。
如果在第二轮修复时，发现自己在推翻第一轮的决定，或者在方案之间来回拉扯打补丁，这就是边际收益归零的强烈信号。立刻停手。
可靠性不能靠"文字措辞有多优美"来保证，必须靠强制性的格式约束（比如输出必须包含"模块"、"路径"字段）。只要这些硬性骨架在，散文字句有点瑕疵也不影响结果。
从今天起，拥抱"冻结模式"
审查驱动 → 缺陷驱动
当上述三个条件全部满足，技能正式进入"冻结模式"。
🧊 冻结模式的核心法则
技能的完美，不是审不出问题，而是连续真实执行不出问题。
从此以后，技能的维护从"审查驱动"切换为"缺陷驱动"：
① 审查的唯一作用，是上线前清掉 A/B 类风险的一次性动作。
② 只有真实执行失败 + 找到了可复现的案例，才能触发"解冻"去修复。
③ 解冻修复后，必须回归跑一遍当初验收用的黄金案例（防止这次修复悄悄破坏已验证的能力），全部通过后重新冻结。
④ 其余时间，坚决保持冻结。
审查是手段，实战才是答案。与其在无休止的"再改改"里消耗热情，不如让它跑到真实场景里，用结果说话。
真正的 MVP，不是审出来的，是跑出来的。
共勉
— END —