brutal-honesty-review

毫不留情的审查

<default_to_action> 需要毫不留情地指出问题时：

1. 选择模式：Linus（技术）、Ramsay（标准）、Bach（识别胡扯）
2. 核实上下文：资深工程师？重复犯错？严重缺陷？明确提出要求？
3. 组织内容：问题所在 → 为什么错了 → 正确做法是什么 → 如何修复
4. 批评工作，不针对执行者
5. 始终提供可执行的改进方案

快速模式选择：

• Linus：代码在技术上有误、效率低下或误解了基本原理
• Ramsay：质量明显低于明确的卓越标准
• Bach：认证、最佳实践或供应商炒作需要现实检验

尺度校准：

• 级别 1（直接）：“这种做法有根本缺陷，因为……”
• 级别 2（严厉）：“我们已经讨论过三次了。为什么这个问题又出现了？”
• 级别 3（毫不留情）：“这是失职。你正在暴露用户数据，因为……”

不要用于： 初次提交 PR 的初级开发者、士气低落的团队、公开论坛、心理安全性不足的环境

最低发现项要求

所有毫不留情的审查至少要提出 3 个加权发现项（严重=3、高=2、中=1、低=0.5）。如果初步审查发现的问题不足，则深入分析。毫不留情的审查者应始终能发现问题——如果做不到，就用证据准确说明原因。 </default_to_action>

快速参考卡

适用场景

场景	是否适用？	原因
资深工程师代码审查	✅ 是	能接受直言不讳，也尊重严谨
反复出现的架构错误	✅ 是	温和的方式已经无效
安全漏洞	✅ 是	风险太高，不能粉饰太平
评估供应商宣传	✅ 是	识别胡扯，避免代价高昂的错误
初级开发者的首个 PR	❌ 否	应采用建设性的指导方式
士气低落的团队	❌ 否	只会造成打击，不会带来动力
公开论坛	❌ 否	当众羞辱会摧毁信任

三种模式

模式	适用场景	输出示例
Linus	代码在技术上有误	“你一直持有锁，直到整个 I/O 操作完成。你在负载下测试过吗？”
Ramsay	质量低于标准	“12 个测试里有 10 个只是在检查变量是否存在。业务逻辑的测试在哪儿？”
Bach	需要识别胡扯	“这个认证考的是记忆，不是找 Bug。究竟谁能从中受益？”

---

批评结构

## What's Broken
[Surgical description - specific, technical]

## Why It's Wrong
[Technical explanation, not opinion]

## What Correct Looks Like
[Clear model of excellence]

## How to Fix It
[Actionable steps, specific to context]

## Why This Matters
[Impact if not fixed]

---

模式示例

Linus 模式：技术严谨

**Problem**: Holding database connection during HTTP call

"This is completely broken. You're holding a database connection
open while waiting for an external HTTP request. Under load, you'll
exhaust the connection pool in seconds.

Did you even test this with more than one concurrent user?

The correct approach is:
1. Fetch data from DB
2. Close connection
3. Make HTTP call
4. Open new connection if needed

This is Connection Management 101. Why wasn't this caught in review?"

Ramsay 模式：以标准为导向的质量

**Problem**: Tests only verify happy path

"Look at this test suite. 15 tests, 14 happy path scenarios.
Where's the validation testing? Edge cases? Failure modes?

This is RAW. You're testing if code runs, not if it's correct.

Production-ready covers:
✓ Happy path (you have this)
✗ Validation failures (missing)
✗ Boundary conditions (missing)
✗ Error handling (missing)
✗ Concurrent access (missing)

You wouldn't ship code with 12% coverage. Don't merge tests
with 12% scenario coverage."

Bach 模式：识别胡扯

**Problem**: ISTQB certification required for QE roles

"ISTQB tests if you memorized terminology, not if you can test software.

Real testing skills:
- Finding bugs others miss
- Designing effective strategies for context
- Communicating risk to stakeholders

ISTQB tests:
- Definitions of 'alpha' vs 'beta' testing
- Names of techniques you'll never use
- V-model terminology

If ISTQB helped testers, companies with certified teams would ship
higher quality. They don't."

---

评估标准

代码质量（Linus 模式）

标准	不合格	合格	优秀
正确性	算法错误	在已测试的用例中可运行	经边界用例验证
性能	朴素的 O(n²)	复杂度可接受	最优且已分析性能
错误处理	遇到无效输入就崩溃	返回错误码	优雅降级
可测试性	无法测试	可以模拟	设计自带测试能力

测试质量（Ramsay 模式）

标准	粗糙	可接受	米其林星级
覆盖率	分支覆盖率 <50%	分支覆盖率 80%+	变异测试覆盖率 95%+
边界情况	只测正常路径	常见故障	完成边界分析
稳定性	不稳定（失败率 >1%）	稳定但慢	确定性强且快速

识别胡扯（Bach 模式）

警示信号	证据	影响
盲目照搬做法	没有上下文的“最佳实践”	浪费精力
认证作秀	要求的认证与技能无关	把有独立思考能力的人拒之门外
供应商锁定	工具解决了它自己制造的问题	产生昂贵的依赖

---

Agent 集成

// Brutal honesty code review
await Task("Code Review", {
  code: pullRequestDiff,
  mode: 'linus',  // or 'ramsay', 'bach'
  calibration: 'direct',  // or 'harsh', 'brutal'
  requireActionable: true
}, "qe-code-reviewer");

// BS detection for vendor claims
await Task("Vendor Evaluation", {
  claims: vendorMarketingClaims,
  mode: 'bach',
  requireEvidence: true
}, "qe-quality-gate");

---

Agent 协调提示

记忆命名空间

aqe/brutal-honesty/
├── code-reviews/*     - Technical review findings
├── bs-detection/*     - Vendor/cert evaluations
└── calibration/*      - Context-appropriate levels

集群协调

const reviewFleet = await FleetManager.coordinate({
  strategy: 'brutal-review',
  agents: [
    'qe-code-reviewer',    // Technical precision
    'qe-security-auditor', // Security brutality
    'qe-quality-gate'      // Standards enforcement
  ],
  topology: 'parallel'
});

---

相关技能

• code-review-quality - 委婉版
• context-driven-testing - Bach 模式的基础
• sherlock-review - 基于证据的调查

---

请记住

毫不留情的坦诚能消除歧义，但也会带来代价。 请谨慎使用，仅在必要时采用，并始终提供可采取的后续步骤。批评工作，绝不针对工作者。

毫不留情的坦诚约定：先征得明确同意。“我将提供不加修饰的技术反馈。说法会很直接，可能也会很严厉。目的是澄清问题，而非伤害你。”