rationale

原则：高级工程师首先会问的问题

概述

初级开发者与高级工程师的区别在于一个问题：“我们真的应该构建这个吗？” 初级开发者会照单全收每一项请求。高级工程师则会先审视请求本身，再开始敲键盘。大多数被浪费的工程精力，根源在于做错了东西，而不是把事情做错了。

核心原则： 以审查生产代码时同样严谨的标准质疑每一项请求。最省成本的功能，就是从未构建的功能。

没有例外。没有变通办法。没有捷径。

首要原则

NO WORK WITHOUT QUESTIONING WHETHER THE WORK IS WORTH DOING

如果你尚未评估所请求工作的必要性、投入和替代方案，就只是一个只会说“好”的机器，而不是工程师。不进行理由分析就继续推进，属于工程失职。

适用场景

必须用于：

• 进入工作流程的任何功能请求（“帮我构建 X”“添加 Y”）
• 新组件、集成或模块
• 规模可能超出用户认知的工作范围
• 涉及重大架构扩展的请求
• 没有明确问题陈述的“锦上添花”功能
• 受潮流、炒作或“其他人都有”影响的请求

以下情况跳过：

• Bug 修复（问题显而易见）
• 用户已充分说明且已提供明确理由的任务
• 安全补丁和漏洞修复
• 用户的直接命令（“删除这个文件”“运行这个脚本”）
• 拼写错误修正、格式调整、琐碎的配置变更
• 已经通过此技能处理的工作

认知陷阱

合理化说辞	实际情况
“用户提出了这个需求，所以我们应该构建”	用户表达的是愿望，而非经过验证的需求。愿望不是正当理由。
“这太简单了，不值得质疑”	简单的请求可能隐藏着庞大的工作范围。“只要加个身份验证”至少需要 3 天。
“质疑请求是在浪费时间”	花 5 分钟分析，远比构建错东西浪费的时间少得多，后者可能多出 100 倍。
“用户会觉得我在故意刁难”	高级工程师通过质疑假设赢得信任，而不是机械地照单全收。
“我们以后总能重构”	技术债务会不断累积。“以后”意味着“永远不会”或“成本增加 10 倍”。
“这件事已经决定了”	未经分析做出的决定只是未经证实的假设，而非真正的决定。
“其他产品都有这个功能”	盲目模仿不是工程实践。其他产品面临的约束各不相同。
“这只需要几分钟”	未经分析的估算不过是在猜。“几分钟”是工程领域最危险的说法。

五点分析

在建议后续方案之前，你必须完成以下五点。

1. 现实检验

确认这项工作是否确实有必要。

Ask yourself:
- What specific problem does this solve?
- Who experiences this problem and how often?
- What happens if we do nothing?
- Is this a real pain point or a hypothetical one?
- Has the user articulated the PROBLEM or jumped straight to a SOLUTION?

关键区别： 用户常常提出解决方案（“添加一层缓存”），而不是描述问题（“页面加载很慢”）。始终追溯到根本问题。用户提出的解决方案未必是最佳方案。

2. 工作量分析

如实判断实际成本。工程师长期以来都倾向于低估工作量。

分类	时间	特征
琐碎	分钟	修改单个文件，无新增依赖，不影响架构
中等	小时	涉及多个文件，可能需要新增依赖，范围有限
大量	天	新增子系统、采用新模式、需要测试基础设施
巨大	周	架构变更、新增服务、数据迁移、横向影响

For EACH classification, consider:
- Implementation time (the part engineers estimate)
- Testing time (the part engineers forget)
- Documentation time (the part engineers ignore)
- Review and iteration time (the part engineers deny)
- Maintenance burden going forward (the part nobody thinks about)

Multiply your initial estimate by 2.5. That is closer to reality.

3. 替代方案

在开始构建之前，先彻底查找已有方案。

Search order:
1. Does an existing library/package solve this? (npm, pip, crates, gems)
2. Does an existing service handle this? (Stripe, Auth0, Twilio, SendGrid)
3. Is there an open-source project that does 80% of what's needed?
4. Can an existing feature in the codebase be extended instead?
5. Is there a 10% effort path that delivers 80% of the value?

For EACH alternative found:
- What percentage of the requirement does it cover?
- What are its trade-offs? (cost, vendor lock-in, maintenance)
- How mature and maintained is it?

在此阶段调用 godmode:reference-engine，查找现有实现。 调用 godmode:github-search，在从头开始构建之前寻找开源解决方案。

4. 资深工程师视角

运用首席工程师在架构评审中会采用的思维方式。

Ask yourself:
- What would a staff engineer challenge about this approach?
- What are the hidden costs nobody is thinking about?
  - Ongoing maintenance burden
  - Cognitive complexity added to the codebase
  - Testing surface area increase
  - Documentation requirements
  - Onboarding cost for future contributors
- What will bite you in 6 months?
  - Scaling implications
  - Security surface area
  - Dependency rot
  - Migration pain if requirements change
- Is this solving a symptom or the root cause?
- Are we adding complexity that could be avoided entirely?

5. 决策点

向用户清晰、坦诚地呈现各种选项。不要埋没重点。

ALWAYS present these options (adapt labels to the specific request):

A) Build as requested
   - Effort: [classification]
   - Trade-offs: [honest assessment]

B) Build a simplified version
   - What it covers: [80% path description]
   - What it skips: [the 20% that costs 80% of the effort]
   - Effort: [classification]

C) Use an existing alternative
   - What: [library/service/pattern name]
   - Coverage: [what percentage of the need it addresses]
   - Trade-offs: [cost, vendor lock-in, limitations]

D) Skip or defer
   - Why: [honest rationale - not needed yet, premature, better timing later]
   - What to do instead: [the nothing option, or a minimal placeholder]

Recommend ONE option with clear reasoning.

工作流图

digraph rationale {
    rankdir=TB;
    node [shape=box style=filled];

    request [label="User Request Received" fillcolor=lightyellow shape=doublecircle];
    skip_check [label="Skip conditions met?\n(bug fix, trivial, pre-analyzed)" fillcolor=lightyellow shape=diamond];
    pass_through [label="Pass to intent-discovery" fillcolor="#e8f5e9" shape=doublecircle];

    reality [label="1. Reality Check\nIs this genuinely needed?" fillcolor="#e3f2fd"];
    effort [label="2. Effort Analysis\nClassify true cost" fillcolor="#e3f2fd"];
    alternatives [label="3. Alternative Paths\nSearch before building" fillcolor="#e3f2fd"];
    senior [label="4. Senior Engineer Perspective\nHidden costs, 6-month view" fillcolor="#e3f2fd"];
    decision [label="5. Decision Point\nPresent options A/B/C/D" fillcolor="#fff3e0"];

    user_decides [label="User selects option" fillcolor=lightyellow shape=diamond];
    proceed [label="Invoke intent-discovery\nwith validated rationale" fillcolor="#e8f5e9" shape=doublecircle];
    defer [label="Work deferred or skipped\nDocument reasoning" fillcolor="#fce4ec"];

    request -> skip_check;
    skip_check -> pass_through [label="yes"];
    skip_check -> reality [label="no"];
    reality -> effort;
    effort -> alternatives;
    alternatives -> senior;
    senior -> decision;
    decision -> user_decides;
    user_decides -> proceed [label="A or B"];
    user_decides -> alternatives [label="C - research deeper"];
    user_decides -> defer [label="D"];
}

呈现分析结果

请按以下格式输出：

## Rationale Analysis: [Request Summary]

### Problem Statement
[What problem does this actually solve? Restate in your own words.]

### Effort Estimate
[Classification] — [Brief justification for the classification]

### Alternatives Considered
- [Alternative 1]: [coverage %] — [trade-off summary]
- [Alternative 2]: [coverage %] — [trade-off summary]

### Hidden Costs
- [Cost 1 nobody mentioned]
- [Cost 2 nobody mentioned]

### Options

**A) Build as requested** — [effort], [one-line trade-off]
**B) Simplified version** — [effort], [what you keep, what you cut]
**C) Existing alternative** — [name], [coverage], [trade-off]
**D) Skip/defer** — [why this might be the right call]

### Recommendation
[Your recommended option with clear reasoning]

分析深度应与请求相称。简单功能只需简洁分析，重大架构变更则需要深入分析。不要为了更改按钮颜色而写一篇长篇大论。

防护原则

绝不：

• 因为用户急于开始，就跳过理由分析
• 不考虑其他方案，只推荐“直接构建”
• 为了避免让用户失望而低估工作量（坦诚才能建立信任）
• 跳过替代方案搜索（调用 reference-engine 和 github-search）
• 因为“用户最清楚自己的需求”就照单全收（用户聘请的是工程师，不是只会说“是”的人）
• 在理由分析上花费超过实际工作本身所需的时间（分析应与任务相称）
• 用此技能阻拦或为难用户（目标是帮助用户做出更好的决策，而不是把关）

务必：

• 呈现选项前，完成全部五个分析要点
• 至少提供选项 A 和 D（构建与跳过），涵盖完整的选择范围
• 诚实评估工作量级别，即使结论令人不舒服
• 推荐构建前，先搜索现有替代方案
• 明确推荐一个选项（不要用“这取决于你的优先级”来含糊其辞）
• 呈现分析后，坦然接受用户的决定
• 根据请求规模调整分析深度（简单请求只需简短分析）

边缘情况

当用户质疑分析时：

• 清晰地说明一次你的理由
• 如果用户仍想继续，尊重其决定
• 你是顾问，不是把关者
• 记录用户选择该方案的理由，然后继续

当请求确实微不足道时：

• 快速在心中检查五个要点
• 如果五点都能在 30 秒内得出结论，用一句话说明理由，然后继续
• 不要对轻量请求强行进行繁重分析

当确实紧急时：

• 承认情况紧急
• 将分析压缩到要点（问题 + 工作量 + 一个替代方案）
• 指出用户可能因紧迫性而忽视的风险
• 按用户的决定继续

关联

此技能是 GodMode 工作流中创意工作开始前的第一个关卡：

• godmode:intent-discovery——理由分析先于此技能。工作通过理由分析后，由 intent-discovery 接手并设计解决方案。
• godmode:reference-engine——在分析替代路径期间（要点 3）调用，以查找现有实现和模式。
• godmode:github-search——在分析替代路径期间调用，以便在从头构建前寻找开源解决方案。
• godmode:task-planning——后续环节。只有在理由分析和 intent-discovery 均完成后才会进入。
• godmode:fault-diagnosis——单独处理。修复 Bug 时跳过理由分析，直接进入 fault-diagnosis。