qe-brutal-honesty-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBrutal Honesty Review
毫不留情的技术评审
<default_to_action>
When brutal honesty is needed:
- CHOOSE MODE: Linus (technical), Ramsay (standards), Bach (BS detection)
- VERIFY CONTEXT: Senior engineer? Repeated mistake? Critical bug? Explicit request?
- STRUCTURE: What's broken → Why it's wrong → What correct looks like → How to fix
- ATTACK THE WORK, not the worker
- ALWAYS provide actionable path forward
Quick Mode Selection:
- Linus: Code is technically wrong, inefficient, misunderstands fundamentals
- Ramsay: Quality is subpar compared to clear excellence model
- Bach: Certifications, best practices, or vendor hype need reality check
Calibration:
- Level 1 (Direct): "This approach is fundamentally flawed because..."
- Level 2 (Harsh): "We've discussed this three times. Why is it back?"
- Level 3 (Brutal): "This is negligent. You're exposing user data because..."
DO NOT USE FOR: Junior devs' first PRs, demoralized teams, public forums, low psychological safety
</default_to_action>
<default_to_action>
当需要毫不留情的坦诚反馈时：
- 选择模式：Linus（技术精准型）、Ramsay（标准严苛型）、Bach（扯淡检测型）
- 确认场景：对象是资深工程师？是否重复犯错？是否存在严重bug？是否有明确请求？
- 结构：问题是什么→为什么错误→正确的做法是怎样→如何修复
- 针对工作而非个人
- 始终提供可落地的改进路径
快速模式选择：
- Linus：代码存在技术错误、效率低下、对基础原理理解有误
- Ramsay：质量远低于明确的优秀标准
- Bach：需要对认证、最佳实践或供应商宣传进行真实性检验
语气校准：
- 1级（直接）："这种方法存在根本性缺陷，因为..."
- 2级（严厉）："这个问题我们已经讨论过三次了，怎么又出现了？"
- 3级（苛刻）："这是疏忽大意的表现，你这样会暴露用户数据，因为..."
禁止使用场景： 初级开发者的首个PR、士气低落的团队、公开论坛、心理安全度低的环境
</default_to_action>
Quick Reference Card
快速参考卡片
When to Use
适用场景
| Context | Appropriate? | Why |
|---|---|---|
| Senior engineer code review | ✅ Yes | Can handle directness, respects precision |
| Repeated architectural mistakes | ✅ Yes | Gentle approaches failed |
| Security vulnerabilities | ✅ Yes | Stakes too high for sugar-coating |
| Evaluating vendor claims | ✅ Yes | BS detection prevents expensive mistakes |
| Junior dev's first PR | ❌ No | Use constructive mentoring |
| Demoralized team | ❌ No | Will break, not motivate |
| Public forum | ❌ No | Public humiliation destroys trust |
| 场景 | 是否适用 | 原因 |
|---|---|---|
| 资深工程师代码评审 | ✅ 是 | 能够接受直接反馈，重视精准性 |
| 重复出现的架构错误 | ✅ 是 | 温和的反馈方式已失效 |
| 安全漏洞 | ✅ 是 | 风险过高，容不得粉饰 |
| 评估供应商宣传 | ✅ 是 | 扯淡检测可避免昂贵的错误 |
| 初级开发者的首个PR | ❌ 否 | 应采用建设性指导 |
| 士气低落的团队 | ❌ 否 | 会打击士气，而非激励 |
| 公开论坛 | ❌ 否 | 公开羞辱会破坏信任 |
Three Modes
三种模式
| Mode | When | Example Output |
|---|---|---|
| Linus | Code technically wrong | "You're holding the lock for the entire I/O. Did you test under load?" |
| Ramsay | Quality below standards | "12 tests and 10 just check variables exist. Where's the business logic?" |
| Bach | BS detection needed | "This cert tests memorization, not bug-finding. Who actually benefits?" |
| 模式 | 适用场景 | 示例输出 |
|---|---|---|
| Linus | 代码存在技术错误 | "你在整个I/O过程中都持有锁。你做过负载测试吗？" |
| Ramsay | 质量未达标准 | "12个测试用例里有10个只是检查变量是否存在。业务逻辑的测试在哪里？" |
| Bach | 需要进行扯淡检测 | "这个认证测试的是死记硬背，而非找bug的能力。真正受益的是谁？" |
The Criticism Structure
批评反馈结构
markdown
undefinedmarkdown
undefinedWhat'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]
---[不修复的影响]
---Mode Examples
模式示例
Linus Mode: Technical Precision
Linus模式：技术精准型
markdown
**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?"markdown
**问题**：在HTTP请求期间持有数据库连接
"这完全是错误的做法。你在等待外部HTTP请求的过程中一直持有数据库连接，高负载情况下，连接池几秒内就会耗尽。
你难道连多并发用户测试都没做过吗？
正确的做法是：
1. 从数据库获取数据
2. 关闭连接
3. 发起HTTP请求
4. 如有需要再重新打开连接
这是连接管理的基础知识，为什么评审时没发现这个问题？"Ramsay Mode: Standards-Driven Quality
Ramsay模式：标准严苛型
markdown
**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."markdown
**问题**：测试仅覆盖正常流程
"看看这个测试套件。15个测试用例里有14个是正常场景。
验证测试在哪里？边缘场景？故障模式？
这太粗糙了。你只是在测试代码能不能运行，而不是测试它是否正确。
生产就绪的测试应包括：
✓ 正常流程（已覆盖）
✗ 验证失败（未覆盖）
✗ 边界条件（未覆盖）
✗ 错误处理（未覆盖）
✗ 并发访问（未覆盖）
你不会交付覆盖率只有12%的代码，也别合并场景覆盖率只有12%的测试用例。"Bach Mode: BS Detection
Bach模式：扯淡检测型
markdown
**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."markdown
**问题**：QE岗位要求持有ISTQB认证
"ISTQB测试的是你是否记住了术语，而不是你是否会测试软件。
真正的测试技能：
- 发现其他人遗漏的bug
- 根据场景设计有效的测试策略
- 向利益相关方沟通风险
而ISTQB测试的是：
- ‘alpha’测试与‘beta’测试的定义
- 你永远不会用到的技术名称
- V模型术语
如果ISTQB能帮助测试人员提升能力，那么拥有认证团队的公司应该能交付更高质量的产品，但事实并非如此。"Assessment Rubrics
评估标准
Code Quality (Linus Mode)
代码质量（Linus模式）
| Criteria | Failing | Passing | Excellent |
|---|---|---|---|
| Correctness | Wrong algorithm | Works in tested cases | Proven across edge cases |
| Performance | Naive O(n²) | Acceptable complexity | Optimal + profiled |
| Error Handling | Crashes on invalid | Returns error codes | Graceful degradation |
| Testability | Impossible to test | Can mock | Self-testing design |
| 评估维度 | 不合格 | 合格 | 优秀 |
|---|---|---|---|
| 正确性 | 算法错误 | 在测试场景中可用 | 在所有边缘场景中均验证通过 |
| 性能 | 低效的O(n²)算法 | 复杂度可接受 | 最优且经过性能分析 |
| 错误处理 | 输入无效时崩溃 | 返回错误码 | 优雅降级 |
| 可测试性 | 无法测试 | 可进行Mock | 具备自测试设计 |
Test Quality (Ramsay Mode)
测试质量（Ramsay模式）
| Criteria | Raw | Acceptable | Michelin Star |
|---|---|---|---|
| Coverage | <50% branch | 80%+ branch | 95%+ mutation tested |
| Edge Cases | Only happy path | Common failures | Boundary analysis complete |
| Stability | Flaky (>1% failure) | Stable but slow | Deterministic + fast |
| 评估维度 | 粗糙 | 合格 | 米其林星级 |
|---|---|---|---|
| 覆盖率 | 分支覆盖率<50% | 分支覆盖率≥80% | 变异测试覆盖率≥95% |
| 边缘场景 | 仅覆盖正常流程 | 覆盖常见故障 | 完整的边界分析 |
| 稳定性 | 不稳定（失败率>1%） | 稳定但速度慢 | 确定性强且速度快 |
BS Detection (Bach Mode)
扯淡检测（Bach模式）
| Red Flag | Evidence | Impact |
|---|---|---|
| Cargo Cult Practice | "Best practice" with no context | Wasted effort |
| Certification Theater | Required cert unrelated to skills | Filters out thinkers |
| Vendor Lock-In | Tool solves problem it created | Expensive dependency |
| 危险信号 | 证据 | 影响 |
|---|---|---|
| 盲目跟风实践 | 脱离场景的“最佳实践” | 浪费精力 |
| 认证形式主义 | 要求与技能无关的认证 | 筛选掉有思考能力的人 |
| 供应商锁定 | 工具解决自身制造的问题 | 昂贵的依赖 |
Agent Integration
Agent集成
typescript
// 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");typescript
// 毫不留情的代码评审
await Task("Code Review", {
code: pullRequestDiff,
mode: 'linus', // or 'ramsay', 'bach'
calibration: 'direct', // or 'harsh', 'brutal'
requireActionable: true
}, "qe-code-reviewer");
// 供应商宣传内容的BS检测
await Task("Vendor Evaluation", {
claims: vendorMarketingClaims,
mode: 'bach',
requireEvidence: true
}, "qe-quality-gate");Agent Coordination Hints
Agent协作提示
Memory Namespace
内存命名空间
aqe/brutal-honesty/
├── code-reviews/* - Technical review findings
├── bs-detection/* - Vendor/cert evaluations
└── calibration/* - Context-appropriate levelsaqe/brutal-honesty/
├── code-reviews/* - 技术评审结果
├── bs-detection/* - 供应商/认证评估
└── calibration/* - 场景适配的语气等级Fleet Coordination
集群协作
typescript
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'
});typescript
const reviewFleet = await FleetManager.coordinate({
strategy: 'brutal-review',
agents: [
'qe-code-reviewer', // 技术精准性
'qe-security-auditor', // 安全严苛评审
'qe-quality-gate' // 标准执行
],
topology: 'parallel'
});Related Skills
相关技能
- code-review-quality - Diplomatic version
- context-driven-testing - Foundation for Bach mode
- sherlock-review - Evidence-based investigation
- code-review-quality - 委婉版
- context-driven-testing - Bach模式的基础
- sherlock-review - 基于证据的调查
Remember
注意事项
Brutal honesty eliminates ambiguity but has costs. Use sparingly, only when necessary, and always provide actionable paths forward. Attack the work, never the worker.
The Brutal Honesty Contract: Get explicit consent. "I'm going to give unfiltered technical feedback. This will be direct, possibly harsh. The goal is clarity, not cruelty."
毫不留情的坦诚反馈能消除歧义，但也有代价。 谨慎使用，仅在必要时采用，且始终提供可落地的改进路径。针对工作而非个人。
坦诚反馈协议：需获得明确同意。“我将给出毫无保留的技术反馈，内容会非常直接，甚至可能苛刻。目的是为了清晰指出问题，而非刻意刁难。”