figure-it-out

Figure it out

当任务不符合任何操作手册时，就设计一套。编写任何代码之前，交付物必须是工作流本身：一系列阶段，其严谨程度与任务相匹配，遵循科学方法，并留下决策记录，以便人类离开后仍能审计。

开始

创建一份待办列表，第一项是阅读 poteto-mode 技能的 Principles 部分。然后将以下阶段添加为待办事项。

阶段 A：界定

先打好基础，再作出承诺。在能够明确说明以下内容之前，不要开始执行：

• 将完成定义为可证伪的判定条件（prove-it-works 原则技能）。
• 量化范围：估算工作量和工作单元，并列出基础调研发现的阻碍。
• 严谨程度，倾向于高。单向门和影响范围大的步骤需要更严格的流程；可逆且风险较低的步骤则可以少些。严谨体现在关卡和产物上，而不是“更加努力”。

在投入长时间执行之前，先说明界定结果和权衡。可逆的工作继续推进（never-block-on-the-human 原则技能），但耗时数小时的执行应设置一个检查点。

阶段 B：设计工作流

拆解为原子化、可独立落地的单元。优先处理风险最高、未知最多的部分。脚手架和验证先于功能（foundational-thinking 原则技能）。

• 先于工作构建验证框架，并采集变更前的基线，这样检查结果就能呈现为“旧值与新值”的对比。
• 对于单向门设计决策，运行 architect 技能（它会运行 arena）。对于方案已明确的机械性工作，可跳过。对已确定的设计再次运行 arena 属于过度设计（laziness-protocol 原则技能）。
• 决定哪些工作需要分散执行。只在边界清晰的部分并行处理，并为每位工作者分配独立的工作树或分支（separate-before-serializing-shared-state 原则技能）。不要过度拆分。
• 写下设计好的阶段列表。人类要审查的就是这份列表。

随后执行设计。将具体步骤作为待办事项添加到待办列表中，放在阶段 C 条目之后、阶段 D 之前。按照阶段 C 的循环纪律逐项执行，并将阶段 D 的日志贯穿其中，每完成一步就记录一行，而不是等到最后才补齐全部记录。

阶段 C：运行循环

每个单元都是一次实验。提出假设，进行最小改动，针对真实产物按判定条件测量；若有进展则保留，否则回滚。 遵循 sequence-verifiable-units 原则技能，在开始下一个单元之前验证当前单元，而不是把所有检查留到最后。

• 通过检查产物来验证，绝不依赖自我报告。如果某项检查过于轻易就通过，应先怀疑观察方法，而不是系统本身。
• 委派工作时配备评审者。如果工作者钻门槛的空子，就重置并强化约定。如果关卡本身有误，就通过单独的变更修正关卡，而不是绕过它。
• 结论只能是 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE。INCONCLUSIVE 不算通过。不要隐瞒负面结果。

阶段 D：保留审计记录

通过 show-me-your-work 技能记录执行过程。figure-it-out 的工作通常足够复杂，值得提交记录，让评审者能在 PR 中查看。记录和差异共同帮助人类之后重新审视并信任这项工作。

阶段 E：验证并交接

针对真实产品，依据阶段 A 的判定条件检查整体结果，而不只是验证框架。将任何反复出现的修正编码为关卡、lint 规则、检查或脚本（encode-lessons-in-structure 原则技能）。

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