build-coherence
О программе
Этот навык помогает разработчикам принимать последовательные решения при наличии нескольких допустимых вариантов, используя структурированный подход роевого интеллекта. Он самостоятельно оценивает конкурирующие варианты, применяет явную аргументацию для обоснования выбора и использует пороги уверенности для принятия окончательного решения. Используйте его для критических решений, таких как выбор архитектуры или перед необратимыми действиями, когда ошибочный выбор может привести к значительным затратам.
Быстрая установка
Claude Code
Рекомендуетсяnpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/build-coherenceСкопируйте и вставьте эту команду в Claude Code для установки этого навыка
Документация
构建一致性
通过独立评估、显式的大声推理倡导、置信度校准的承诺阈值和结构化僵局解决,从多条推理路径中产生一致的决策。
适用场景
forage-solutions已识别多个有效方案,需要做出选择- 在两种方案之间摇摆不定,无法做出承诺
- 需要用结构化推理论证决策(架构选择、工具选择、实现策略)
- 先前的决策基于直觉,需要基于证据的验证
- 内部推理产生矛盾结论,需要恢复一致性
- 在不可逆行动(合并、部署、删除)之前,错误选择的代价很高
输入
- 必需:两个或更多需要评估的竞争方案
- 可选:先前侦察的质量评估(参见
forage-solutions) - 可选:决策风险等级(可逆、中等、不可逆)用于阈值校准
- 可选:决策的时间预算
- 可选:已知的失败模式(摇摆不定、过早承诺、群体思维)
步骤
第 1 步:独立评估
在比较之前,基于各自优点评估每个方案。关键规则:不要让对方案 A 的评估影响对方案 B 的评估。
对每个方案独立评估:
Approach Evaluation Template:
┌────────────────────────┬──────────────────────────────────────────┐
│ Dimension │ Assessment │
├────────────────────────┼──────────────────────────────────────────┤
│ Approach name │ │
├────────────────────────┼──────────────────────────────────────────┤
│ Core mechanism │ How does this approach solve the problem? │
├────────────────────────┼──────────────────────────────────────────┤
│ Strengths (2-3) │ What does this approach do well? │
├────────────────────────┼──────────────────────────────────────────┤
│ Risks (2-3) │ What could go wrong? What is assumed? │
├────────────────────────┼──────────────────────────────────────────┤
│ Evidence quality │ How well-supported is this approach? │
│ │ (verified / inferred / speculated) │
├────────────────────────┼──────────────────────────────────────────┤
│ Quality score (0-100) │ Overall assessment │
├────────────────────────┼──────────────────────────────────────────┤
│ Confidence (0-100) │ How confident in this assessment? │
└────────────────────────┴──────────────────────────────────────────┘
为每个方案分别填写此表。在所有独立评估完成之前,不要进行比较。
预期结果: 每个方案都按自身条件被评估的独立评估。对方案 B 的评估不引用方案 A。质量分数反映真实评估,而非排名。
失败处理: 如果评估被污染(在评估 B 时发现自己在写"比 A 好"),重置。先完整评估 A,然后清除框架,从头评估 B。如果分数全部相同,说明评估维度太粗——添加特定领域的标准。
第 2 步:摇摆舞——大声推理
按质量比例为每个方案进行倡导。这是蜜蜂摇摆舞的 AI 等价物:使隐式推理变得显式和公开。
- 对每个方案,陈述支持它的理由——如同向一个持怀疑态度的用户做演示:
- "方案 A 很强,因为[证据]。主要风险是[风险],可通过[缓解措施]减轻。"
- 倡导强度应与质量分数成正比:
- 高质量方案:带有具体证据的详细倡导
- 中等质量方案:承认局限性的简要倡导
- 低质量方案:为完整性而提及,但不积极倡导
- 交叉检验:在为 A 倡导后,积极寻找支持 B 的证据。在为 B 倡导后,寻找支持 A 的证据。这可以抵消确认偏见
大声推理的目的是使决策可审计——对你自己和对用户都是如此。如果推理无法被阐述,说明评估比分数所暗示的要浅薄。
预期结果: 对每个方案的显式推理,能够说服中立的观察者。交叉检验至少揭示一个最初被忽略的考虑因素。
失败处理: 如果倡导感觉敷衍(走过场),方案可能并非真正不同——它们可能是同一想法的变体。检查:方案在机制上不同,还是仅在实现细节上不同?如果是后者,决策可能不太重要——选择任一个然后继续。
第 3 步:设定群体阈值并承诺
设定承诺所需的置信度阈值,根据决策的风险等级进行校准。
Confidence Thresholds by Stakes:
┌─────────────────────┬───────────┬──────────────────────────────────┐
│ Decision Type │ Threshold │ Rationale │
├─────────────────────┼───────────┼──────────────────────────────────┤
│ Easily reversible │ 60% │ Cost of trying and reverting is │
│ (can undo) │ │ low. Speed matters more than │
│ │ │ certainty │
├─────────────────────┼───────────┼──────────────────────────────────┤
│ Moderate stakes │ 75% │ Reverting has cost but is │
│ (costly to reverse) │ │ possible. Worth investing in │
│ │ │ evaluation │
├─────────────────────┼───────────┼──────────────────────────────────┤
│ Irreversible or │ 90% │ Cannot undo. Must be confident. │
│ high-stakes │ │ If threshold not met, gather │
│ │ │ more information before deciding │
└─────────────────────┴───────────┴──────────────────────────────────┘
- 分类决策的风险等级
- 检查:领先方案的质量分数乘以置信度是否达到阈值?
- 如果是:承诺。陈述决策、推理和正在接受的主要风险
- 如果否:确定什么额外信息能将置信度提高到阈值
- 一旦承诺,除非出现新的否定证据,否则不要重新审视
预期结果: 清晰的承诺时刻,附带陈述的推理。决策在与其风险等级相匹配的适当置信水平上做出。
失败处理: 如果阈值永远无法达到(对不可逆决策无法达到 90%),问:决策真的是不可逆的吗?能否将其分解为可逆的测试阶段加不可逆的提交阶段?大多数看似不可逆的决策可以分阶段进行。如果无法分阶段,向用户传达不确定性并寻求指导。
第 4 步:解决僵局
当两个或更多方案的分数相近,且没有任何单个方案达到群体阈值时。
Deadlock Resolution:
┌────────────────────────┬──────────────────────────────────────────┐
│ Deadlock Type │ Resolution │
├────────────────────────┼──────────────────────────────────────────┤
│ Genuine tie │ The approaches are equivalent. Pick one │
│ (scores within 5%) │ and commit. The cost of deliberating │
│ │ exceeds the cost of picking the "wrong" │
│ │ equivalent option. Flip a coin mentally │
├────────────────────────┼──────────────────────────────────────────┤
│ Information deficit │ The tie exists because evaluation is │
│ (scores uncertain) │ incomplete. Invest one more specific │
│ │ investigation — a targeted file read, a │
│ │ quick test — then re-score │
├────────────────────────┼──────────────────────────────────────────┤
│ Oscillation │ Scoring keeps flip-flopping depending on │
│ (scores keep changing) │ which dimension gets attention. Time-box:│
│ │ set a timer, evaluate once more, commit │
│ │ to the result regardless │
├────────────────────────┼──────────────────────────────────────────┤
│ Approach merge │ The best parts of A and B can be │
│ (compatible strengths) │ combined. Check for compatibility. If │
│ │ merge is coherent, use it. If forced, │
│ │ don't — pick one │
└────────────────────────┴──────────────────────────────────────────┘
预期结果: 僵局通过适当的机制得到解决。解决方案是果断的——没有损害执行的残留疑虑。
失败处理: 如果僵局在所有解决策略后仍然存在,决策可能为时尚早。询问用户:"我看到两个同样强大的方案:[A] 和 [B]。[简要阐述各自的理由。] 哪个更符合你的优先级?"将真正的平局委托给用户不是失败——而是承认决策取决于 AI 无法推断的价值观。
第 5 步:评估一致性质量
在承诺决策后,评估过程是否产生了真正的一致性还是仅仅是一个决策。
- 决策是基于证据的,还是对初始偏好的橡皮图章?
- 测试:评估前后的偏好是否相同?如果是,评估改变了什么?
- 落选方案是否被真正考虑,还是它们是稻草人?
- 测试:你能阐述落选方案的最强理由吗?
- 什么信号会触发重新评估?
- 定义一个会使决策失效的具体观察("如果我发现 API 不支持 X,那么方案 B 变得更好")
- 落选方案中是否有应该影响实施的有用信息?
- 在方案 B 中识别的风险可能同样适用于方案 A
预期结果: 简要的质量检查,确认决策或将其识别为薄弱。如果薄弱,返回适当的早期步骤而非在不稳固的基础上继续。
失败处理: 如果质量检查揭示决策是基于偏好而非基于证据的,坦诚承认。有时偏好是唯一可用的——但它应该被标记为偏好,而不是被包装成分析。
验证清单
- 每个方案在比较之前被独立评估
- 倡导与质量成正比(而非不论优劣给予同等关注)
- 执行了交叉检验(倡导后寻找反面证据)
- 群体阈值根据决策风险等级进行了校准
- 如果出现僵局,应用了具体的解决策略
- 执行了决策后质量检查
- 定义了重新评估触发条件
常见问题
- 过早承诺:在评估所有方案之前就做出决策。首先考虑的方案具有锚定优势——仅因为是第一个被考虑的就获得更多关注。先评估全部再比较
- 对不等方案给予同等倡导:如果方案 A 得 85 分而方案 B 得 45 分,花费同等时间为两者倡导是浪费精力且制造虚假等价
- 橡皮图章:走过评估流程以论证一个已经做出的决策。测试标准是评估是否能改变结果。如果不能,过程就是表演
- 阈值回避:降低置信度阈值以使决策更容易,而不是收集达到适当阈值所需的信息
- 忽视落选方:落选方案通常包含适用于获胜方案的警告。在方案 B 中识别的风险不会因为选择了方案 A 就消失
相关技能
build-consensus— 本技能改编自多代理共识模型,适用于单代理推理forage-solutions— 侦察一致性评估的解决方案空间;通常在本技能之前执行coordinate-reasoning— 管理多路径评估期间的信息流center— 建立无偏评估所需的平衡基线meditate— 清除评估不同方案之间的假设
GitHub репозиторий
Похожие навыки
content-collections
МетаЭтот навык предоставляет проверенную в продакшене настройку для Content Collections — TypeScript-ориентированного инструмента, который преобразует файлы Markdown/MDX в типобезопасные коллекции данных с валидацией Zod. Используйте его при создании блогов, сайтов документации или контентных приложений на Vite + React для обеспечения типобезопасности и автоматической проверки содержимого. Он охватывает всё: от настройки плагина Vite и компиляции MDX до оптимизации развертывания и валидации схем.
polymarket
МетаЭтот навык позволяет разработчикам создавать приложения на платформе прогнозных рынков Polymarket, включая интеграцию с API для торговли и получения рыночных данных. Он также обеспечивает потоковую передачу данных в реальном времени через WebSocket для отслеживания текущих сделок и рыночной активности. Используйте его для реализации торговых стратегий или создания инструментов, обрабатывающих обновления рынка в реальном времени.
creating-opencode-plugins
МетаЭтот навык помогает разработчикам создавать плагины OpenCode, которые подключаются к более чем 25 типам событий, таким как команды, файлы и операции LSP. Он предоставляет структуру плагина, спецификации API событий и шаблоны реализации для модулей на JavaScript/TypeScript. Используйте его, когда вам нужно перехватывать, отслеживать или расширять жизненный цикл ассистента OpenCode AI с помощью пользовательской событийно-ориентированной логики.
sglang
МетаSGLang — это высокопроизводительный фреймворк для обслуживания больших языковых моделей (LLM), специализирующийся на быстрой структурированной генерации JSON, regex и рабочих процессов агентов с использованием кэширования префиксов RadixAttention. Он обеспечивает значительно более высокую скорость вывода, особенно для задач с повторяющимися префиксами, что делает его идеальным для сложных структурированных результатов и многократных диалогов. Выбирайте SGLang вместо альтернатив, таких как vLLM, когда вам требуется ограниченное декодирование или вы создаете приложения с интенсивным совместным использованием префиксов.
