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
评估 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
// 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 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."
直言不讳的反馈能消除歧义，但也有代价。 仅在必要时使用，且始终提供可执行的改进路径。针对工作本身，绝不针对个人。
直言不讳协议：需获得明确同意。“我将给出毫无保留的技术反馈，可能会比较直接甚至尖锐，目的是为了清晰指出问题，而非刻意刻薄。”