十方对抗审

单人编码的三个老问题

让一个 AI 独立写代码，最常见的翻车场景不是语法错误，而是"看起来能跑，但没人发现它其实在错误地工作"。后端逻辑漏了边界条件、前端还原度与设计稿偏差、API 契约改了前端没同步——这些 bug 不会让编译失败，也不会让测试变红，它们会安静地上线，然后在生产环境里爆炸。

另一个问题是审查流于形式。如果你让 AI"检查一下这段代码"，它很可能扫一眼就回复"看起来没问题"。这不是因为 AI 懒惰，而是因为缺少对抗机制——没有正方和反方的对立，没有明确的审查维度，"通过"就成了默认答案。

十方对抗审怎么运作

这个技能把每次任务拆成十个角色的协作：需求创造师定义问题、项目经理管排期和资源、后端正方和前端正方负责实现、后端反方和前端反方负责对抗审查、UI 设计师出方案、QA 和体验方做双重验收、Arbiter 做最终技术裁决。

核心机制是反方五轮强制审查。每次代码变更，后端和前端的反方必须独立完成五个维度的审查，每轮聚焦一个点：

• 第 1 轮：逻辑正确性（条件分支、循环边界、返回值）
• 第 2 轮：边界与异常（空数组、undefined、并发、网络失败）
• 第 3 轮：架构与规范（项目架构风格、命名、文件大小）
• 第 4 轮：安全与隔离（注入风险、API Key 硬编码、日志脱敏）
• 第 5 轮：性能与资源（内存泄漏、定时器清理、复杂度、缓存策略）

审查输出有硬性格式要求：必须附带 [文件:行号] 或代码片段，必须标注严重程度（P0/P1/P2），禁止只说"通过"。P0 必须修复才能通过，P1 必须回应（修复或说明不修理由），P2 可以记录后续处理。

PM 和 Arbiter 的分工也有明确边界：PM 拍板"做不做、什么时候做、谁来做"，Arbiter 拍板"怎么做、做到什么程度"。如果两人意见冲突，整理双方观点提交用户裁决。

适用边界

这套流程的前提是调用者愿意接受"诚实高于一切"的审查文化。如果反方说"看起来没问题"，那不是通过，那是最危险的信号。

对于小改动——改个文案、修个样式、加个简单接口——这套十人流程显得过重。它更适合中大型功能开发、涉及前后端协作的任务、或者对质量有严格要求的生产级代码。

另一个注意点：前端反方审查时会对照设计方案，任何偏差都视为 P1 问题。这意味着前端正方不能在设计稿出来之前开始编码（纯后端任务除外），顺序不能乱。