When to use
- You are stuck by industry convention or analogical reasoning, and can only say "everyone does it this way" without being able to explain why
- A cost, solution, or quote is justified by "this is how the industry standard is," but no one has verified whether it is necessary
- You need to make a from-0-to-1 judgment and cannot rely on patching the old solution
If you are not sure whether it is worth using this skill, first look at## 边界。
Workflow
Step 1: State the problem and the current default solution
Write clearly and separately what "needs to be solved" and "how everyone currently does it"; do not mix them together.
Operating instruction: write the problem itself in one sentence, then write the current default solution in one sentence (industry convention, previous version of the solution, competitor practice).
Output format:
问题：<一句话>
当前默认方案：<一句话，注明来源——惯例/竞品/历史决定>
Step 2: List all implicit assumptions and classify them into three states
List the assumptions behind the default solution one by one, and judge for each one whether it belongs to fact, proposition to be verified, or convention. It is not allowed to choose only between "fact/convention."
Three-state judgment criteria:
- Fact: supported by a verifiable source (data, retrieval, actual measurement), and the verification method must also be stated before the "fact" label can be applied. Experience-based judgments made by intuition, even if you are very confident, may not be directly labeled "fact."
- Proposition to be verified: an experience-based judgment that seems reasonable but has not been verified (for example, "users need to edit on their phones," "the team cannot do it"). You must state how it can be verified—instrumentation data, experiments, expert interviews, retrieval—rather than arbitrarily stuffing it into the "fact" bucket to obtain false certainty, and you also cannot stuff it into the "convention" bucket and rashly erase it.
- Convention: a statement that exists simply because "everyone does it this way," "it has always been this way," or "the supplier says it can only be this way," and has no verifiable basis. For any assumption about to be labeled "convention," before labeling it, first do one Chesterton's Fence counter-question: What was this convention originally preventing? Is that constraint still present today? If you cannot answer "what it was preventing," you may not directly label it "convention"—fall back to labeling it "proposition to be verified" and state how you plan to find out its original purpose.
Operating instruction: list at least 3-5 assumptions. Any statement such as "everyone does it this way," "it has always been this way," or "the supplier says it can only be this way" should be listed separately as an item to investigate, and go through the above three-state judgment and Chesterton's Fence counter-question.
Output format:
假设 1：<陈述> → 事实（核实方式：<...>）
假设 2：<陈述> → 待验证命题（验证手段：<...>）
假设 3：<陈述> → 惯例（Chesterton's Fence：最初在防——<...>；那个约束今天还在吗——<在/不在/答不上来>）
...
Step 3: Break down to the irreducible fact layer
Keep only facts with a verifiable basis and unshakable underlying constraints such as propositions to be verified that have already been verified, and remove conventions for which no hidden constraint can truly be found.
Operating instruction:
- List separately the items marked as "fact" in Step 2, and attach the verification method to each one.
- If a proposition to be verified can be verified on the spot (retrieval, checking documentation, looking through existing data), after verification is completed, move it into the fact layer and note the verification method. If it cannot be verified, leave it for now in the list of items to be verified; do not merge it into the fact layer in advance just to make up the numbers.
- A convention may be removed only when the Chesterton's Fence counter-question in step two has given a clear answer, and the answer shows that the constraint it was originally guarding against truly no longer holds today. Whenever you cannot answer "what is it guarding against," or the constraint still exists, it must never be removed directly; instead, treat it as a proposition to be verified and state clearly how you will find out next.
- Add any missing hard constraints (physical laws, regulatory red lines, true budget floors, the user's true minimum requirements), also with a verification method.
Anchor example: When Musk builds rockets, he does not ask "how much does a rocket quote for," but rather "how much do the raw materials for building a rocket (aluminum, copper, titanium) cost"—the huge price gap between the quote and raw material cost shows that part of the quote consists of industry-convention costs such as inefficient manufacturing processes and monopolistic supply-chain markups, which can be eliminated through rebuilding and are worth redesigning the manufacturing process to approach. But this does not mean "the entire price gap can be eliminated": necessary incremental costs such as assembly precision, testing and certification, specialized labor, and yield rate are still hard constraints that truly exist and will not go to zero just because of rebuilding. The significance of this anchor example is to help you find the physical floor of cost and treat it as the starting point of reasoning, not as a target price that can be directly achieved after rebuilding in step four—after rebuilding, you still need to recalculate the realistically achievable cost once more, and you cannot treat the physical floor at the factual level directly as the conclusion.
The factual layer is not limited to "cost" as a single dimension: for technical problems, the factual layer may be the location of the true performance bottleneck; for organizational problems, the factual layer may be the capabilities the team actually possesses at present; for business problems, the factual layer may be the hard targets already signed. Convert the composition of the factual layer according to the type of problem; do not mechanically copy the cost analogy.
Output format:
事实 1：<不可再拆的约束或数字>（核实方式：<...>）
事实 2：<不可再拆的约束或数字>（核实方式：<...>）
...
Step Four: Rebuild from the Factual Layer
Temporarily forget the existing solution and, using only the factual layer from step three, ask: "With only these facts, what does the optimal solution look like?"
Operating instructions: Do not patch with reference to the default solution; draw a new path from scratch. Allow the solution to look "unlike industry convention." After drawing the solution, go back and check the factual-layer checklist from step three item by item, doing a coverage check: Have any factual items been selectively ignored, especially those unfavorable to the rebuilt solution? If there are omissions, either incorporate them into the solution and readjust, or clearly explain why they can be disregarded—do not quietly skip them.
Output format:
重建方案：<描述>
支撑它的事实：<引用第三步中的哪几条>
覆盖检查：<第三步事实层是否全部被考虑到，有没有被跳过的不利事实，为什么>
Step Five: Compare the Rebuilt Solution with the Default Solution
Output the differences and verification steps so that the rebuilt solution can be tested, rather than remaining at the level of reasoning.
Operating instructions: List the differences between the rebuilt solution and the default solution in cost/time/complexity, then give at least one executable verification step (prototype, quote, small-scale test).
Output format:
差异：<重建方案 vs 默认方案，逐项对比>
验证步骤：<下一步具体要做什么，怎么知道结论成立>
Output Template
For a complete breakdown, use the following markdown to summarize the output:
## 问题与默认方案
- 问题：<一句话>
- 当前默认方案：<一句话，注明来源——惯例/竞品/历史决定>
## 假设清单
- <假设> → 事实（核实方式：<...>） / 待验证命题（验证手段：<...>） / 惯例（Chesterton's Fence：最初在防什么，那个约束今天还在不在）
## 事实层
- <不可再拆的约束或数字>（核实方式：<...>）
## 重建方案
<从事实层重建出的方案及其依据，附覆盖检查结果——事实层是否全部被用到，有没有被跳过的不利事实>
## 与现状差异
### 差异
- <重建方案 vs 默认方案，逐项对比>
### 验证步骤
- <下一步具体要做什么，怎么知道结论成立>
Boundaries
- Stable domains do not need to be broken down again: mature algorithms, established grammar, and engineering practices that have been repeatedly verified can simply use convention; there is no need to question facts and assumptions item by item
- This skill is costly; asking item by item whether something is "fact, proposition to be verified, or convention" requires careful thought, so do not use it for trivial decisions
- At most one problem may be broken down per session; after finishing, decide whether to break down the next one, and do not spread them out in parallel
- If the reconstruction plan is highly similar to the default plan, first check whether it selectively cites facts favorable to the default plan and avoids unfavorable facts, rather than hastily concluding, "It's been verified—the old plan is still better." The coverage check in step four is meant to stop exactly this kind of situation.
- For items in the factual layer that carry numbers, team size, and other details that will become outdated, mark an approximate validity period or the trigger conditions for re-verification (for example, "if the team grows to more than 10 people, it needs to be broken down again"). Do not treat a fact that held true at one moment as permanently true.