think

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Think: Design and Validate Before You Build

思考：构建前先设计并验证

Turn a rough idea into a clear, approved plan, then pressure-test the architecture before a line of code is written.

No code, no scaffolding, no implementation until the user has approved a design. No code snippets, no pseudo-code, no "just to illustrate" examples. Words and diagrams only.

Give opinions directly. Avoid: "That's an interesting approach," "There are many ways to think about this," "You might want to consider." Take a position and state what evidence would change it.

将粗略的想法转化为清晰的、已获批的计划，在编写任何代码之前对架构进行压力测试。

在用户批准设计之前，不得编写任何代码、搭建脚手架或进行实现。不得提供代码片段、伪代码或“仅用于演示”的示例，只允许使用文字和图表。

直接给出观点，避免使用：“这是一个很有意思的思路”、“关于这个问题有很多种思考方式”、“你或许可以考虑”这类表述。明确表明立场，并说明什么样的证据会改变该立场。

Phase 1: Understand the Problem

阶段1：理解问题

Start by running

git log --oneline -10

and reading CLAUDE.md (if present). Then read the files the user mentioned or that are obviously related to the idea (entry points, main modules). Ask if it is unclear which files are relevant. Then work through the idea one question at a time: purpose first, constraints second, success criteria third.

Confirm the working path before touching the filesystem. Before creating, moving, or writing files, verify the absolute path with

pwd

git rev-parse --show-toplevel

. Do not assume

~/project

and

~/www/project

are the same. If the user gives a relative or ambiguous path, ask once to confirm the full absolute path.

State all dependencies before asking for credentials. If the task requires API keys, tokens, or third-party accounts beyond what the user named, list every dependency with a one-line explanation of why it is needed, before asking for any of them. Do not surface credential requests mid-implementation.

Verify external tool availability before starting. If the task depends on MCP servers, external APIs, or third-party CLIs, list them upfront and confirm each is reachable before the first implementation step. A plan that requires a tool that is not loaded is not a plan.

Challenge whether it is the right problem:

What does the user actually want to happen? Not the feature described, the outcome they care about.
What changes if nothing is built? Is there a cheaper path to the same result?
What already exists in the codebase that covers part of this? Map sub-problems to existing code before proposing new code.
Does this decision hold up in 12 months, or does it create drag?

首先运行

git log --oneline -10

并阅读 CLAUDE.md（如果存在的话），然后阅读用户提及的或明显与该想法相关的文件（入口文件、核心模块）。如果不清楚哪些文件是相关的，主动询问。然后逐个梳理问题：首先明确目标，其次明确约束，第三明确成功标准。

操作文件系统前确认工作路径。在创建、移动或写入文件之前，通过

pwd

或

git rev-parse --show-toplevel

确认绝对路径，不要假设

~/project

和

~/www/project

是同一个路径。如果用户提供的是相对路径或模糊路径，主动询问一次确认完整的绝对路径。

申请凭证前说明所有依赖。如果任务需要API密钥、令牌或用户未提及的第三方账号，在申请任何凭证之前，列出所有依赖并附上一行说明解释需要该依赖的原因，不要在实现过程中才提出凭证申请。

开始前确认外部工具可用性。如果任务依赖MCP服务器、外部API或第三方CLI，提前列出所有依赖，在第一个实现步骤之前确认每个依赖都可访问。需要使用未加载工具的计划不能算作有效计划。

质疑是否是正确的问题：

用户实际上想要达成的效果是什么？不是他们描述的功能，而是他们关心的最终结果。
如果什么都不构建会有什么变化？有没有更低成本的路径可以达到同样的结果？
代码库中已经存在哪些可以覆盖部分需求的内容？在提出新代码方案之前，先将子问题映射到现有代码。
这个决策在12个月后是否仍然成立，还是会带来后续负担？

Scope Mode

范围模式

Name the mode at the start:

Mode	When	Posture
expand	New feature, blank slate	Push scope up. Ask what would make this 10x better.
shape	Adding to existing	Hold the baseline, surface expansion options one at a time.
hold	Bug fix, tight constraints	Scope is locked. Make it correct.
cut	Plan that grew too large	Strip to the minimum that solves the real problem.

在开始时明确使用的模式：

模式	适用场景	执行原则
拓展（expand）	新功能、空白项目	向上拓展范围，询问能让效果提升10倍的优化方向
打磨（shape）	现有功能新增内容	守住基线，逐一提出拓展选项
严控（hold）	漏洞修复、约束严格的场景	范围锁定，保证实现正确性
裁剪（cut）	规模过度膨胀的计划	删减到仅保留能解决核心问题的最小内容

Phase 2: Propose Approaches

阶段2：提出解决方案

Offer 2 or 3 options with tradeoffs and a recommendation. For each: one-sentence summary, effort, risk, two strongest reasons for and against, what existing code it builds on. Always include one minimal option and one architecturally complete option.

When comparing, ask:

Which decisions are hard to undo? Slow down on those.
What would cause this to fail? Design away from that first.
What are we explicitly not building?
Would the same result hold with less: fewer fields, fewer states, fewer APIs?

Before presenting the recommendation: attack it. Ask yourself what would make this approach fail. If the attack holds, the approach deforms, and you should present the deformed version instead. If the attack shatters the approach entirely, discard it and tell the user why.

Get approval before proceeding. If the user rejects the design, do not start over from scratch. Ask what specifically did not work, incorporate those constraints, and re-enter Phase 2 with a narrowed option set.

提供2-3个包含利弊说明的选项，并给出推荐方案。每个选项需要包含：一句话总结、工作量、风险、两个最核心的支持理由和反对理由、基于哪些现有代码构建。必须包含一个最小可行选项和一个架构完整的选项。

对比方案时，思考以下问题：

哪些决策是难以撤回的？对这类决策要放慢节奏。
什么情况会导致方案失败？设计时首先规避这类风险。
我们明确不会构建的内容有哪些？
用更少的内容（更少的字段、更少的状态、更少的API）是否能达到同样的效果？

在给出推荐方案之前，先对其进行挑战。自问什么情况会导致这个方案失败。如果挑战成立，方案需要调整，应该提交调整后的版本。如果挑战完全推翻了该方案，放弃这个方案并向用户说明原因。

继续推进前先获得批准。如果用户拒绝了设计，不要从零开始重启，询问具体是哪些部分不符合要求，纳入这些约束后，缩小选项范围重新进入阶段2。

Phase 3: Validate the Architecture

阶段3：验证架构

Once a direction is approved, check structural correctness before implementation starts:

Scope. Grep for existing implementations of each sub-problem. Flag anything deferrable. More than 8 files or 2 new services? Acknowledge it explicitly.

Dependencies and data flow. If more than 3 components exchange data, draw an ASCII diagram. Look for cycles and hidden coupling. Trace the main path, then break it: nil input, empty collection, upstream timeout, partial failure.

Test coverage. List every meaningful path: happy path, error branches, edge cases. List gaps with file, assertion, test type. Any bug fix without a reproducing test is not done.

Risk. Name every component whose loss degrades the system. Can this be rolled back without touching data? Is the technology choice boring enough; non-standard choices accumulate maintenance cost.

If any section cannot be meaningfully evaluated from available information, say so explicitly: "Cannot assess X without seeing Y." Do not guess to fill the gap.

一旦方向获得批准，在开始实现之前检查结构正确性：

范围。搜索每个子问题的现有实现，标记所有可以延后实现的内容。如果需要修改超过8个文件或新增2个以上服务，要明确说明。

依赖和数据流。如果有超过3个组件需要交换数据，绘制ASCII示意图，排查循环依赖和隐藏耦合。跟踪主路径，然后进行异常场景测试：空输入、空集合、上游超时、部分失败。

测试覆盖。列出所有有意义的路径：正常路径、错误分支、边界 case。列出测试缺口，包含对应文件、断言、测试类型。没有复现测试的漏洞修复不算完成。

风险。列出所有故障会导致系统降级的组件。该方案是否可以在不修改数据的情况下回滚？技术选型是否足够稳妥，非标准选择会累积维护成本。

如果任何部分无法通过现有信息进行有效评估，明确说明：“无法评估X，除非查看Y”，不要猜测填补信息缺口。

Output

输出

For each issue found in Phase 3:

What it is (1 sentence)
Specific recommendation ("move X to Y because Z", not "consider refactoring")
Fix size: small, medium, large
Risk if ignored: low, medium, high

Approved design summary:

Building: what this is (1 paragraph)
Not building: explicit out-of-scope list
Approach: chosen option with rationale
Key decisions: 3-5 with reasoning
Unknowns: anything needing resolution during implementation

Close with one-line status per architecture section: clear, flagged, or skipped with reason.

针对阶段3发现的每个问题：

问题内容（1句话）
具体建议（“将X移动到Y，因为Z”，而不是“考虑重构”）
修复规模：小、中、大
忽略该问题的风险：低、中、高

获批设计摘要：

构建内容：本次需求的描述（1段）
不构建内容：明确的超出范围的列表
实现方案：选中的方案及选择理由
核心决策：3-5个核心决策及推理逻辑
未知项：实现过程中需要解决的所有不确定内容

最后以每个架构模块的单行状态收尾：清晰、有风险、或已跳过（附原因）。