figure-it-out

自行设计方案

当任务不符合任何现有操作手册时，就设计一套。编写任何代码之前，交付物必须是工作流本身：一系列阶段，根据任务规模调整严谨程度，遵循科学方法，并留下决策轨迹，方便人类离开后审计。倾向于更严谨。做错东西的代价远高于谨慎行事的代价。

不要重新设计已有的操作手册。符合 Bug 修复、性能优化、功能开发、视觉一致性、评估或多阶段计划的单一任务，应按对应手册执行。但如果是其中某项规模很大或影响面很广的版本（例如跨多个调用点的迁移，或包含多个部分的大型改动），或是用户离开后还需要审查的工作，就属于这里，即使其单一任务版本本应归为功能开发也是如此。严谨性和审计轨迹才是重点。

开始

先创建待办清单，第一项是阅读 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 原则技能）。不要过度并行。
• 写下设计好的阶段列表，供人类审查。

然后开始执行设计。将各步骤作为具体待办事项添加到清单中，放在阶段 C 条目之后、阶段 D 之前。每一步都遵循阶段 C 的循环纪律执行，并贯穿其中记录阶段 D 的日志：每完成一步就记录一行，不要等到最后才补齐整条轨迹。

阶段 C：执行循环

每个单元都是一次实验：陈述假设，做最小改动，针对真实产物和判定谓词进行测量；如果改动有推进作用就保留，否则就回退。 应用 sequence-verifiable-units 原则技能：每个单元完成后都要验证，再开始下一个，而不是把所有检查都留到最后。

• 通过检查产物进行验证，绝不依赖自我报告。某项检查通过得过于轻易时，应先怀疑观测方法，而不是系统。空白截图也能轻易通过宽松的检查。
• 委派工作时应配备评审者，并在信任委派结果前亲自审计其产物。如果工作者钻了检查的空子，就重置并加强约定。如果检查机制本身有误，应通过单独的改动修正检查机制，而不是绕过它。
• 结论只能是 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE。结论不确定不算通过。不要掩盖负面结果。

阶段 D：保留审计轨迹

使用 show-me-your-work 技能记录运行过程，为每项决策和每个单元各保留一行，整理成唯一的标准 TSV，证据以链接形式提供。figure-it-out 的工作通常足够重要，值得提交这份轨迹，以便审核者在 PR 中查看；当需要展示可信度时，就提交它。优先使用已提交脚本生成的证据，以便审核者可以重新运行。轨迹加上差异，就是让人类能够回过头来信任这项工作的依据。

阶段 E：验证并交付

在真实产品上依据阶段 A 的判定条件检查整体结果，而不只是测试框架。将任何反复出现的修正编码为门禁、lint 规则、检查项或脚本，避免成果悄然回退（encode-lessons-in-structure 原则技能）。

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