figure-it-out

Figure it out

当任务不符合任何操作手册时，就设计一套。编写任何代码之前，先交付工作流本身：一系列与任务规模相匹配的阶段，遵循科学方法，并留下决策记录，供人类离开一段时间后审查。

Start

创建一个待办清单，第一项是阅读 boring-mode 技能的 Principles 部分。然后将以下阶段添加为待办事项。

Phase A：明确问题

先充分了解情况，再做决定。在能够明确说明以下内容之前，不要开始执行：

• 将完成定义为可证伪的判定条件（prove-it-works 原则技能）。
• 量化范围：大致的工作量单位和所需精力，以及通过梳理发现的阻碍。
• 确定严谨程度，倾向于从严。不可逆的决策和影响范围大的事项需要更严格；可逆且风险较低的步骤则可以宽松些。严谨意味着设置关卡并产出记录，而不是“更加努力”。

在承诺进行长时间执行之前，先说明问题框架和权衡。可逆的工作照常推进（never-block-on-the-human 原则技能），但耗时数小时的执行需要设置一个检查点。

Phase B：设计工作流

将工作拆解为原子化、可独立落地的单元。优先处理风险最高的未知因素。脚手架和验证应先于功能实现（foundational-thinking 原则技能）。

• 在开展工作前构建验证工具，并从变更前的状态记录基线，以便检查能对比“旧值与新值”。
• 对不可逆的设计决策，运行 architect 技能（它会运行 arena）。如果是形态已明确的机械性工作，则跳过。对已经确定的设计再运行一次 arena，属于过度设计（laziness-protocol 原则技能）。
• 决定哪些工作需要并行展开。仅在明确的边界上并行，并为每位工作者分配独立的 worktree 或分支（separate-before-serializing-shared-state 原则技能）。不要过度并行。
• 写下设计好的阶段清单。人类要审查的就是这份清单。

然后执行设计。将具体步骤作为待办事项添加到清单中，放在 Phase C 条目之后、Phase D 之前。每一步都遵循 Phase C 的循环纪律，并在这些步骤中穿插记录 Phase D 日志：每完成一步就记录一行，而不是等到最后才补齐全部过程。

Phase C：循环执行

每个单元都是一次实验。提出假设，做最小改动，根据真实产物上的判定条件进行测量；如果有进展就保留，否则就回滚。 遵循 sequence-verifiable-units 原则技能：每完成一个单元就验证，再开始下一个，而不是等到最后再批量检查。

• 通过检查产物进行验证，绝不依赖自我报告。如果某件事轻易就通过了，先怀疑观察方法，再怀疑系统。
• 委派工作时配备评审者。如果工作者钻门槛的空子，就重置并强化约定。如果门槛本身有问题，就在单独的变更中修正门槛，而不是绕过它。
• 结论为 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE。INCONCLUSIVE 不算通过。不要掩盖负面结果。

Phase D：保留审计记录

通过 show-me-your-work 技能记录执行过程。figure-it-out 的工作通常足够宏大，因此通常应提交这些记录，让审查者能在 PR 中阅读。记录与差异一起，能让人类日后回来时仍信任这项工作。

Phase E：验证并交接

针对 Phase A 的判定条件，在真实产品上检查整体结果，而不只是验证工具。将反复出现的修正编码为门槛、lint 规则、检查项或脚本（encode-lessons-in-structure 原则技能）。

**回复：**你设计的操作手册、严谨程度及原因、决策记录的路径、根据判定条件已验证的内容，以及仍未解决的问题。