When to use
- You're stuck on industry convention or analogical reasoning, and all you can say is "everyone does it this way" without being able to explain why
- A cost, solution, or quote is justified by "that's just the industry standard," but no one has verified whether it's necessary
- You need to make a from-0-to-1 judgment and can't rely on patching the old solution
Not sure whether it's 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; don't mix them together.
Action instruction: Write the problem itself in one sentence, then write the current default solution in one sentence (industry convention, previous version, competitor approach).
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 whether each one is a fact, a proposition to be verified, or a convention. You are not allowed to choose only between "fact/convention."
Three-state judgment criteria:
- Fact: Supported by a verifiable source (data, search, 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" or "the team can't do it"). You must state how it can be verified—tracking data, experiments, expert interviews, search—rather than arbitrarily stuffing it into the "fact" bucket to gain false certainty, and you also must not stuff it into the "convention" bucket and dismiss it lightly.
- Convention: A claim 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," with no verifiable basis. For any assumption about to be labeled "convention," before labeling it do a Chesterton's Fencecounter-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.
Action instruction: List at least 3-5 assumptions. Any statement like "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, going through the three-state judgment and the Chesterton's Fence counter-question above.
Output format:
假设 1：<陈述> → 事实（核实方式：<...>）
假设 2：<陈述> → 待验证命题（验证手段：<...>）
假设 3：<陈述> → 惯例（Chesterton's Fence：最初在防——<...>。那个约束今天还在吗——<在/不在/答不上来>）
...
Step 3: Break down to the irreducible layer of facts
Keep only unshakable underlying constraints such as facts with a verifiable basis and propositions to be verified that have already been verified, and remove conventions that truly have no hidden constraint after investigation.
Action 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 (search, check documentation, look through existing data), after verification move it into the fact layer and note the verification method. If it cannot be verified, leave it on the to-be-verified list for now; do not merge it prematurely into the fact layer just to pad 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 is indeed no longer valid today. Whenever you cannot answer "what is it guarding against," or the constraint still exists, you must not remove it directly; instead, treat it as a proposition to be verified and write down how you will find out next.
- Add any omitted hard constraints (laws of physics, regulatory red lines, real budget floors, the user's true minimum requirements), also with a method of verification.
Anchor example: When Musk builds rockets, he does not ask "how much does a rocket quote cost," 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 is industry-convention cost such as manufacturing process inefficiency and supply chain monopoly markups, which can be eliminated through rebuilding, and it is worth redesigning the manufacturing process to approach that. 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 still exist as real hard constraints and will not go to zero just because of rebuilding. The significance of this anchor example is to help you find the physical lower bound of cost and use it as the starting point for reasoning, not as the 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 must not directly treat the physical lower bound at the factual layer as the conclusion.
The factual layer is not limited to "cost" as a single dimension: the factual layer of a technical problem may be the location of the real performance bottleneck, the factual layer of an organizational problem may be the capabilities the team actually has at present, and the factual layer of a business problem 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 ask using only the factual layer from step three: "With only these facts, what does the optimal solution look like?"
Operating instruction: Do not patch by referring 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: Are any factual items 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 instruction: List the differences of the rebuilt solution relative to 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, summarize the output using the following markdown:
## 问题与默认方案
- 问题：<一句话>
- 当前默认方案：<一句话，注明来源——惯例/竞品/历史决定>
## 假设清单
- <假设> → 事实（核实方式：<...>） / 待验证命题（验证手段：<...>） / 惯例（Chesterton's Fence：最初在防什么，那个约束今天还在不在）
## 事实层
- <不可再拆的约束或数字>（核实方式：<...>）
## 重建方案
<从事实层重建出的方案及其依据，附覆盖检查结果——事实层是否全部被用到，有没有被跳过的不利事实>
## 与现状差异
### 差异
- <重建方案 vs 默认方案，逐项对比>
### 验证步骤
- <下一步具体要做什么，怎么知道结论成立>
Boundaries
- Stable domains do not need to be broken down again: mature algorithms, established syntax, 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 relatively costly; asking item by item whether something is "a fact, a proposition to be verified, or a 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; do not spread them out in parallel
- If the reconstruction plan and the default plan are highly similar, first check whether facts favorable to the default plan were selectively cited and unfavorable facts were avoided, rather than rushing to conclude, "It's been verified, and the old plan is still better"—the coverage check in step four exists precisely to stop this kind of situation.
- For entries in the facts layer that contain numbers, team size, and similar details that will become outdated, mark an approximate validity period or the trigger conditions for re-verification (for example, "once the team expands to more than 10 people, it needs to be split again"), and do not treat a fact that held true at one moment as permanently true.