Atomise - 思维原子推理
Atomise 是一个用于结构化推理的技能，核心思路是“思维原子”（Atom of Thoughts, AoT）：把复杂问题拆解为最小、可验证的“原子”，而不是像思维链那样线性推进、逐步累积错误。它把每一步都视为可以独立核验的单元，并在置信度下降时进行回溯。
用途
适用于：安全分析、架构决策、复杂调试、多步证明。 不适用于：简单问题、琐碎计算、信息查找。
调用方式
/atomise "<problem>" [--light | --deep] [--math | --code | --security | --design]
核心循环
- DECOMPOSE（拆解）-> 分解为原子子问题（每个 1-2 句话）
- SOLVE（求解）-> 先回答叶节点，再向上传播
- VERIFY（验证）-> 检验每个假设（反例、一致性、领域检查）
- CONTRACT（压缩）-> 用 2 句话总结已核实状态（丢弃历史）
- EVALUATE（评估）-> 足够确信？结束。不确定？回溯并尝试另一条路径。
重复直到确信或所有路径耗尽。
原子
每个原子都是一个最小单元：
{id, type, content, depends_on[], confidence, verified}
类型与起始置信度：
- premise（前提）：给定事实，1.0
- reasoning（推理）：逻辑推断，从父节点继承
- hypothesis（假设）：待检验主张，验证前最高 0.7
- verification（验证）：测试结果，基于测试结果
- conclusion（结论）：最终答案，沿链条传播
置信度传播：子节点的置信度不能高于其最不自信的父节点。
置信度（诚实的说明）
这些数值是启发式的，不是经校准的概率。它们用于跟踪相对确定性，不适用于实际风险评估。
阈值含义：
-
0.85：足以得出结论
- 0.6 - 0.85：需要更多验证
- < 0.6：进一步拆解或回溯
- < 0.5：回溯——此路径行不通
验证会调整置信度：
- 确认 -> 维持或略微提升
- 部分 -> 降低约 15%
- 被反驳 -> 大幅降低，很可能回溯
模式
深度：
- --light：快速，最多 3 层，置信度阈值 0.70
- （默认）：标准，最多 5 层，阈值 0.85
- --deep：彻底，最多 7 层，阈值 0.90
领域（调整验证风格）：
- --math：算术检查、证明验证、边界测试
- --code：类型检查、不变式验证、测试生成
- --security：威胁建模、攻击面、对抗性思考
- --design：权衡分析、约束满足、可行性
输出
ANSWER: {result} CONFIDENCE: {0.0-1.0} - {why}
KEY CHAIN: P1 -> R1 -> H1 -> V1 -> C1
ATOMS:
| id | type | content | conf | verified |
|---|---|---|---|---|
| P1 | premise | Given: ... | 1.0 | Y |
| R1 | reasoning | Therefore: ... | 0.95 | Y |
| ... | ... | ... | ... | ... |
RISKS: {what could change this}
添加 --verbose 输出完整轨迹，--quiet 只输出答案。
执行指南
阶段 0：准备
- 用一句话重述问题
- 把前提抽取为原子（给定事实 = 1.0，假设 = 0.6）
- 草拟方法：直接求解？拆解？换框？选最佳。
阶段 1 及以后：迭代
- 原子性关卡：能否从已核实的原子回答？能 -> 求解。不能 -> 拆解。
- 拆解：构建原子子问题的依赖树
- 求解 + 验证：先叶节点，再向上传播。每个假设都需要验证。
- 压缩：用不超过 2 句话总结。丢弃其余内容。
- 评估：
- 确信？-> 终止
- 不确定但可行？-> 继续
- 低置信度？-> 回溯，尝试替代方案
回溯
当某条路径在验证后置信度低于 0.5：
- 剪枝该分支
- 恢复到最近一次压缩后的状态
- 从初始草稿尝试替代方案
示例
复杂调试
/atomise "Why does this function return null on the second call?" --code
安全审查
/atomise "Is this authentication flow vulnerable to session fixation?" --security
架构决策
/atomise "Should we use event sourcing for this domain?" --deep --design
快速决策（轻量模式）
/atomise "Redis vs Memcached for this cache layer?" --light
反模式
BAD: /atomise "What's 2+2?" -> 直接回答即可 BAD: /atomise "Rewrite this function" -> 那是实现，不是推理 BAD: 在低置信度下强行得出结论 -> 应让其回溯 GOOD: 对真正存在不确定性、需要结构化拆解的问题使用 /atomise
记住
- 原子 = 最小。每个原子 1-2 句话。
- 验证一切。假设需要测试。
- 积极压缩。只保留下一步所需内容。
- 自由回溯。低置信度意味着尝试另一条路径。
- 置信度是启发式的。用于组织结构，而非实际概率。