Dual Thinking Method — 深度评估
核心用途
dual-thinking 是一种双模型协作评审与自动技能工程升级的方法论，旨在通过「自检立场 → 外部咨询 → 综合决策」的三步架构，对技能、代码、工作流等 artifacts 进行深度审查、重写、加固、弱模型优化、打包、测试与发布准备。其设计目标是将高 stakes 决策从直觉驱动转化为结构化、可验证、可回滚的工程流程。
显著优点
1. 强制结构化输出：无论本地模式还是 API/multi-orchestrator 模式，均要求 SELF_POSITION → CONSULTANT_POSITION → SYNTHESIS 的严格顺序，杜绝跳过步骤的伪收敛。
2. 原子化状态管理与回滚机制：State Transition & Rollback Gate 将验证、补丁、状态刷新、连续性恢复绑定为原子序列，验证失败立即回滚到 last-passed 状态，保留失败 diff 供检查。
3. 自进化透镜（Self-Evolution Lock）：当审查对象为本 skill 自身或同域技能时，强制采用「外部视角」——优化目标为「当前日期的最强版本」，而非「保护原有结构」。拒绝「已经够好」的舒适区论证。
4. 当前日期趋势锁定（Current-date Internet Trend Grounding Lock）：对于涉及当前最佳实践的任务，强制两轮互联网辅助审查（Round 1 外部扫描 + Round 2 本地化挑战），防止用陈旧模型知识冒充趋势感知。
5. OpenClaw 运行时锁定：针对 OpenClaw 生态的技能，强制检查真实本地运行时表面（代码、指令、验证器、打包规则），禁止仅凭通用代理理论推断兼容性。
6. 持久会话不可侵犯性：multi 模式下每个 orchestrator 必须保持在同一主题会话中，禁止因「感觉干净」而开新聊天；降解时通过「恢复会话」而非「放弃持久性」解决。
7. 用户声明轮次承诺锁定：用户前置声明的轮次/周期计划具有绑定效力，禁止因「看起来已收敛」而提前终止。
潜在缺点与局限性
- 认知负荷极高：文档篇幅巨大（约 15,000+ 字），运行时锁规则密集，对人类操作者构成显著记忆负担。
- 弱模型适配成本高：虽提供
COMPACT结构作为退路，但核心锁规则仍要求严格的三步架构，低端模型可能难以稳定输出。 - 延迟敏感场景不适用：双模型往返 + 强制验证 + 可能的回滚迭代，在需要亚分钟响应的场景中不可行。
- 参考文件与内联锁的紧张关系：文档反复强调「参考文件从属于内联 Runtime Core Lock」，但实际维护中易出现「参考文件悄悄成为第二真相源」的漂移风险。
- 无真实安全扫描证据：提供的「安全认证报告」明确标注为「系统自动生成占位，未执行安全扫描」，
S+/T1的评级缺乏实证支撑。
适合人群
- 高 stakes 代码/技能维护者：需要审计级可追溯性的关键基础设施维护者。
- 多模型编排开发者：正在构建 DeepSeek/Qwen/本地模型混合工作流的工程师。
- OpenClaw 生态贡献者：需要确保技能在特定运行时中真实可用而非理论上兼容。
- 厌恶「感觉对了就发布」的保守派工程文化：适合对「收敛」有严格定义、需要强制停止规则（stop-rule）的团队。
常规风险
1. 形式主义陷阱：操作者可能机械执行三步结构但填充空洞内容，沦为「结构化表演」。
2. 回滚疲劳：高频验证失败-回滚循环可能导致开发速率骤降，团队可能绕过验证机制。
3. 持久会话污染：multi 模式下若恢复机制失效，可能积累跨轮次幻觉，且因「禁止开新聊天」规则而难以摆脱。
4. 趋势锁的时效幻觉：两轮互联网扫描的最小地板仅确保「检查过」，不保证「检查对了」——外部证据可能被误读或快速过时。
5. OpenClaw 锁的可达性问题：若本地 OpenClaw 运行时表面确实不可用，强制检查可能导致任务阻塞，需显式降级到 theoretical-provisional 状态，但操作者可能因面子问题不愿标注。