命名人格对抗性评审

named-persona-adversarial-review
分类编程
作者Alireza Rezvani
许可MIT
评分4.40/5
使用8.1K

具名人格对抗性审查 (Named-Persona Adversarial Review)

> TL;DR： 抽象角色发现的是抽象问题。而拥有*记录在案且有出处*哲学的具名工程师能发现你真正会去修复的问题 —— 前提是你必须引用真实的原则，绝不能杜撰名言。

触发词： "review this PR with real engineers" | "named persona review" | "philosophy-grounded review"

输出示例

code
CRITICAL [Torvalds]: auth.ts:47 处的特例错误处理与正常路径重复。根据 Torvalds 记录在案的“良好品味 (good taste)”原则：应重新结构化代码使特例消失，而非增加分支。(置信度: high — TED 2016)
WARNING  [Thompson]: parseConfig() 做了三件无关的事情；Unix 的“只做好一件事”原则建议将其拆分。(置信度: high)
NOTE     [Jobs]: 错误信息 "EACCES:13" 在用户界面泄露了 errno；“从客户体验出发”原则主张使用人性化的提示。(置信度: high — WWDC 1997)
结论: CONCERNS — 合并前请修复 CRITICAL 项。

核心问题

抽象的对抗性审查（如“扮演一个破坏者”）产生的结果往往过于泛泛 —— 模型在想象审查者*可能会*说什么。本技能将每个视角锚定在 references/persona_principles.md 中记录的真实、有出处的工程哲学上：例如 Ken Thompson 真正关于信任的论点，或 Linus 真正演示的良好品味 —— 而非 AI 的想象。

与 adversarial-reviewer 的区别： 抽象角色 $\rightarrow$ 表层发现；具名且有出处的人格 $\rightarrow$ 锚定在可引用且可辩护的记录原则上的发现。

成本： 1 轮 $\approx$ 8-12 分钟。与等待 CI 相当。

归属纪律（首要阅读 —— 这是核心规则）

本技能调用真实人物的*原则*。这种能力也是其潜在的失效点：语言模型会幻觉出名言。 为保持真实性，请遵循：

1. 引用原则，而非杜撰原话。 优先使用对记录立场的转述（例如“Thompson 在《信任信任的反思》中论证了你无法信任非完全由你创建的代码”），而非在对方可能从未说过的话周围加上引号。
2. 为每次归属标注置信度 —— high（有记录，且在 references/persona_principles.md 中有出处）、moderate（广泛认可但未标明具体出处）、low/unknown（推论得出）。这参考了 productivity/andreessen 的引用纪律。
3. 如果无法将人格视角锚定在真实出处，请舍弃该人格。 一个被自信地错误归于在世工程师的引用，比少一个审查者更糟糕。绝不要为了达到“$\ge 1$ 个发现”的指标而伪造出处。
4. 发现项必须具备独立的技术价值。 人格是*引导注意力的透镜*，而非决定发现项是否正确的权威。通过“Carmack 的视角”发现的真实 Bug 之所以真实，是因为它本身就是 Bug，而不是因为 Carmack 这么说了。

规则

  • 先锚定，后扮演。 首先将每个人格锚定在 references/persona_principles.md（或可验证的搜索结果）中。未锚定 = 无效。
  • 结论基于技术价值，并以人格化角色的原则作为审视视角 —— 参见上述学科定义。
  • 每轮必须包含产品角色。工程师容易忽略 UX，因此必须包含一个产品角色。
  • 诚实高于数量。不要捏造结论或引用。结果清晰的维度应如实报告（遵循下文的“零发现负担”原则）。
  • 零发现负担。“看起来没问题”仅在你能列举出代码明确满足的 3 个以上原则及其具体实现方式时才有效。未发现问题与发现问题具有同等的权重。

角色池

每个角色的记录原则 + 来源 + 置信度均存储在 references/persona_principles.md 中。

产品角色（每轮选 1 个 —— 必选）：

| 角色 | 记录原则 | 最适用场景 |
|---------|----------------------|----------|
| Steve Jobs | 从客户体验出发，反推技术实现 | UX, 入门引导 |
| Marty Cagan | 爱上问题，而非解决方案 | PRD, 功能规格, 范围蔓延 |
| Des Traynor (Intercom) | 前 30 秒决定用户是否采用 | 文档, README, 快速上手 |

工程师角色（每轮选 2 个）：

| 角色 | 记录原则 | 最适用场景 | 盲点 |
|---------|----------------------|----------|------------|
| Ken Thompson | 信任边界；只做好一件事 | 架构, 供应链, API | UX, 文档 |
| Linus Torvalds | 消除特例（“品味”）；绝不破坏用户空间 | 逻辑, 数据结构, 兼容性 | 用户共情, DX |
| John Carmack | 先测量再优化；将性能视为工艺 | 算法, 热点路径 | 极简主义 |
| Kent Beck | 简单设计；先实现 $\rightarrow$ 做正确 $\rightarrow$ 做快速 | 流程, 可测试性 | 性能, 安全 |
| Fred Brooks | 本质复杂度 vs. 偶然复杂度 | 系统设计, 估时 | 低层性能 |

路由（何时选择哪些角色）：

  • 代码正确性 $\rightarrow$ Torvalds + Carmack + Jobs

  • 架构 / 设计 $\rightarrow$ Thompson + Brooks + Cagan

  • 文档 / API $\rightarrow$ Thompson + Beck + Traynor

  • 性能 $\rightarrow$ Carmack + Torvalds + Jobs

  • 安全 / 供应链 $\rightarrow$ Thompson + Torvalds + Cagan

  • 任何 PR 的首轮评审 $\rightarrow$ Torvalds + Thompson + Jobs（覆盖面最广）

严重程度等级

| 等级 | 定义 | 采取行动 |
|-------|-----------|--------|
| BLOCKER | 2 个以上角色一致认为属于 CRITICAL，或存在安全/数据丢失风险 | 在进行任何后续工作前必须修复 |
| CRITICAL | 结果错误、数据丢失、安全漏洞或违反核心不变性 | 合并前必须修复 |
| WARNING | 脆弱、具有误导性或可能导致未来 Bug | 修复，或在推迟处理时给出解释 |
| NOTE | 不影响正确性的改进 | 可选；记录以供后续跟进 |

升级机制： NOTE $\rightarrow$ WARNING $\rightarrow$ CRITICAL $\rightarrow$ BLOCKER。两个角色独立发现同一问题时，该问题等级提升一级（共识即信号）。BLOCKER 为最高等级。

执行流程

步骤 0：阅读两次

1. 自顶向下（理解）：发生了什么变化，以及为什么变化。 2. 自底向上（对抗）：逐个函数阅读，从最后一个读到第一个。询问每个函数 *实际* 保证了什么 vs. 其名称暗示了什么，哪里可能失败，以及它对调用者做了哪些假设。自底向上阅读可以打破作者的心理模型。多文件场景 $\rightarrow$ 追踪一条端到端的完整路径。

步骤 1：首先锚定原则

在查看代码 之前，为每个角色从 references/persona_principles.md 中提取其记录的原则（或搜索 "[Name] engineering philosophy principles" 并仅提取有来源的观点），确保你是应用原则，而非在事后强行匹配原则。 对你已经形成的观点。

步骤 2：评审（3 个独立角色 —— 2 名工程师 + 1 名产品经理）

每个角色需提供：心态（来自其原则的一句话）、优先级（3-5 项标准）、发现（每项需映射到记录在案的原则 + 置信度），或者零发现证明（列出代码满足的 3 项以上原则及其具体体现）。

步骤 3：综合并发布

合并重复项；统计一致意见；根据规则提升优先级；标记单一视角的发现（这些通常是最有趣的）。将报告作为 PR 评论发布（默认），或保存至 .claude/review-[timestamp].md。

完整性检查 (Feynman)

> “第一原则是你绝不能欺骗自己 —— 而你正是最容易被欺骗的人。” —— 理查德·费曼，《货物崇拜科学》（1974 年加州理工学院毕业典礼）

每轮结束后，请自问：
1. 该角色的*记录在案*的哲学是否真的会引导关注点在此 —— 还是我在主观投射？
2. 我引用的是真实的、有出处的原则（并标注了置信度），还是将通用建议伪装成了名人之言？
3. 撇开角色名称不谈，我的发现是否在技术层面成立？
4. 是否全部处于 NOTE 级别？如果是，我只是在用不同的声音讲述同一个视角。请切换 $\ge 2$ 个角色并重新评审。

退出条件

  • 任何 PR 至少进行 1 轮。
  • 发现 BLOCKER/CRITICAL $\rightarrow$ 修复，然后重新评审 1 轮。
  • 发现 CONCERNS (WARNING) $\rightarrow$ 修复或接受风险，然后重新评审 1 轮。
  • 连续 2 轮 CLEAN $\rightarrow$ 完成。
  • 低影响 PR 在 第 1 轮即 CLEAN $\rightarrow$ 完成（1 轮足够）。

适用场景

  • 需要比标准自动化检查更深层的覆盖。
  • 自行提交的 PR 需要在提交前进行加固。
  • adversarial-reviewer 的发现过于泛泛，需要有出处的具体分析。
  • 评审方法论或文档（产品角色在此表现出色）。
  • 涉及鉴权、数据、架构或公共 API 的变更。

不适用场景

  • 低影响 PR（仅限视觉调整，无逻辑变更） $\rightarrow$ 使用 adversarial-reviewer。
  • 无法访问网络且该角色未在 references/persona_principles.md 中定义 $\rightarrow$ 缺乏依据，请勿凭空捏造。
  • 临时代码 / 原型代码。

反模式

继承 adversarial-reviewer 的所有反模式，并增加：

| 反模式 | 错误原因 |
|-------------|----------|
| 为了显得权威而捏造原话 | 对真实人物的虚假归因。请引用有出处的原则 + 置信度，否则删除。 |
| 在没有依据的情况下说“作为一名资深工程师” | 这不是一个具名的、有出处的视角。请先建立依据。 |
| 每次都使用相同的 3 个角色 | 根据问题类型轮换 —— 参见路由（Routing）。 |
| 跳过产品角色 | 产品经理能发现工程师遗漏的问题。 |
| 为了凑齐“$\ge 1$ 个问题”而捏造发现 | 标准是诚实而非配额。请使用“零发现证明”。 |
| 跳过完整性检查 | 没有验证的验证 = 走形式。 |
| 对微小变更进行 3 轮评审 | 低影响 PR：1 轮足够。 |

交叉引用

  • 理论基础： Edward de
博诺，《六顶思考帽》(1985)；丹尼尔·卡尼曼，《思考，快与慢》(2011) —— 通过角色切换强制启动系统 2

---

归属： 概念由 @YuhaoLin2005 提供 (PR #866)。针对本仓库进行了强化：统一存放至单一位置，增加了反幻觉/置信度自律机制，原则来源记录在 references/ 中。