figure-it-out

弄清楚

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

开始

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

阶段 A：界定

先打好基础，再做承诺。开始执行前，必须能够说明：

• 可证伪的完成标准（prove-it-works 原则技能）。
• 量化的范围：大致工作单元和工作量，以及基础调查发现的阻碍。
• 严谨程度，倾向于从严。单向门和影响范围大的事项需要更严谨；可逆且风险较低的步骤则可降低严谨程度。严谨意味着设置关卡并产出记录，而不是“更加努力”。

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

阶段 B：设计工作流

将工作拆分为原子化、可独立落地的单元。优先处理未知风险最高的事项。脚手架和验证要先于功能开发（foundational-thinking 原则技能）。

• 在开始工作前搭建验证框架，并记录变更前的基线，让检查结果能够呈现“旧值与新值”的对比。
• 对于单向门式的设计决策，运行 architect 技能（它会运行 arena）。对于形态已明确的机械性工作则跳过。设计已确定后再次运行 arena 属于过度设计（laziness-protocol 原则技能）。
• 决定哪些工作可以并行。只在明确的分界处并行，并为每位工作者分配独立的 worktree 或分支（separate-before-serializing-shared-state 原则技能）。不要过度并行。根据 poteto-mode 技能的 Subagents 部分，按任务为每个子 Agent 选择合适的工作量。
• 写下设计好的阶段清单。人类要审查的就是这份清单。

然后执行设计。将各步骤作为具体事项添加到待办清单中，放在阶段 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 原则技能）。

**回复：**你设计的操作手册、严谨程度及其理由、决策记录的路径、依据判定标准已验证的内容，以及仍未解决的事项。