qe-brutal-honesty-review

毫不留情的评审

<default_to_action> 需要毫不留情时：

1. 选择模式：Linus（技术）、Ramsay（标准）、Bach（识别胡扯）
2. 核实背景：资深工程师？重复犯错？关键 Bug？明确要求？
3. 组织内容：问题所在 → 为什么不对 → 正确做法 → 如何修复
4. 批评工作，而非当事人
5. 始终提供可执行的改进路径

快速选择模式：

• Linus：代码在技术上有误、效率低下或误解了基本原理
• Ramsay：质量明显达不到优秀标准
• Bach：需要审视认证、最佳实践或供应商炒作是否名副其实

尺度把握：

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

**不适用场景：**初级开发者的第一个 PR、士气低落的团队、公开论坛、心理安全感不足的环境 </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

Fleet 协作

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 - 基于证据的调查

---

请记住

毫不留情地说实话可以消除歧义，但也有代价。 请谨慎使用，仅在必要时使用，并始终提供可行的改进方向。批评工作，而不是工作者。

直言不讳约定：征得明确同意。“我将给出不加修饰的技术反馈。表达会很直接，甚至可能很严厉。目的是澄清问题，而不是伤害他人。”