oh-my-hermes的核心哲学为什么Evidence before claims让AI编码更可信【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermesOMH是 Hermes Agent 的 All-in-One 插件提供编码智能、长期记忆系统和模型优化的工作流包。它的核心设计哲学是Evidence before claims先证据后结论OMH 把每个请求转化为清晰的能力、有用的下一步以及一份诚实记录实际发生了什么的档案——绝不让准备完成冒充真正完成。这篇文章带你理解这套证据边界体系如何让 AI 编码更可信。一、为什么AI编码需要证据先行用过 AI 编码助手的同学大概都有过这样的困惑模型自信地说测试已全部通过但 CI 结果还没回来它说代码已写好其实只是生成了提示词还没派发给执行器计划清单上的 ✅ 打满了可真正验证的步骤一步没走。这就是 AI 编码最大的信任缺口声明claim和事实evidence之间出现了裂缝。️oh-my-hermes 的回答不是让模型更诚实而是用一套确定性的证据边界体系从机制上杜绝无证据的结论。它的自我定位写得很直白Planning, research, creation, coding handoffs, operations, and project memorywith explicit evidence boundaries. —— README.md二、OMH的证据体系三层关键机制1️⃣ Prepared已准备≠ Observed已观察OMH 在术语层面就划清了红线见项目词表 CONTEXT.md记录类型含义状态值Prepared handoff预备交接一份编码执行者之后可以执行的载荷prepared_not_observed已准备、未观察Observed evidence观察证据记录到某事真正发生派发、执行、验证、评审、CI、合并唯一可作为完成结论依据的记录关键点准备一份交接不是派发、执行、评审或合并的证据。任何报告里的完成声明只有背后有 observed evidence 才能成立——这就是 Evidence before claims 的字面落地。2️⃣ Claim Boundary声明边界每个记录自带免责声明OMH 写入的每一个元数据工件都附带一句claim boundary——明确声明这条记录不是什么的证据。比如连接器操作员卡片本身不等于 API 调用成功除非有观察到的连接器结果记录支撑。这让 AI 工作流的每一步都带上了可审计的边界而不是靠自觉。3️⃣ 双轴证据标签连显示都不允许撒谎最精妙的设计在 src/evidence/labels.py证据状态被拆成正交的两个轴——阶段轴PhaseRoute / Plan / Code / Setup / Test / Review / Ship置信度轴Confidencenot run / running / partly seen / reported done / seen / failed / verified渲染出来就是Code · reported done、Test · verified这样一行可读的状态。几个设计细节值得品味阶段词只用名词Code 而不是 Coding因为 Coding 扫一眼会被误读成有人正在写代码reported done专门用来标记执行器自报的完成和门禁验证过的verified严格区分——自报成绩与实测成绩在屏上永远不会长得一样连 ready 都不被允许出现在状态字段里因为它会被 OMH 自己的守卫判定为无观察支撑的声明。三、证据状态在终端里的样子在真实的编码工作会话中OMH 会把运行中和已验证分开呈现——你永远能看到哪些是观察到的事实哪些只是已准备的声明这种诚实的 HUD意味着当 AI 编码流程跑到哪一步、证据到了什么置信度你看到的和它知道的一样多不多不少。四、这套哲学对新手意味着什么你可以放心让 AI 跑长任务状态面板上的verified是观察证据支撑的结论而不是模型的口头承诺交接不再黑盒OMH 的 Maestro 模式只准备交接给选定的编码 CLI绝不假装它执行过——准备与执行是两条分明的车道记录可回溯每个编码 run 都会在$OMH_HOME/runtime/runs/id下累积交接、观察与效果回执审计时有据可查。更多工作流与角色定义可参考 docs/WORKFLOWS.md。五、快速上手三步体验证据驱动编码安装clone 仓库https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes后运行安装脚本详见 docs/INSTALLATION.md配置执行omh setup完成交互式模型配置体检用omh doctor验证安装状态上手后你只需要记住一句话在 oh-my-hermes 的世界里我说了完成了永远不等于它完成了——只有被观察到的证据才算数。这恰恰是它让 AI 编码更可信的全部秘密。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-hermes的核心哲学：为什么Evidence before claims让AI编码更可信
oh-my-hermes的核心哲学为什么Evidence before claims让AI编码更可信【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermesOMH是 Hermes Agent 的 All-in-One 插件提供编码智能、长期记忆系统和模型优化的工作流包。它的核心设计哲学是Evidence before claims先证据后结论OMH 把每个请求转化为清晰的能力、有用的下一步以及一份诚实记录实际发生了什么的档案——绝不让准备完成冒充真正完成。这篇文章带你理解这套证据边界体系如何让 AI 编码更可信。一、为什么AI编码需要证据先行用过 AI 编码助手的同学大概都有过这样的困惑模型自信地说测试已全部通过但 CI 结果还没回来它说代码已写好其实只是生成了提示词还没派发给执行器计划清单上的 ✅ 打满了可真正验证的步骤一步没走。这就是 AI 编码最大的信任缺口声明claim和事实evidence之间出现了裂缝。️oh-my-hermes 的回答不是让模型更诚实而是用一套确定性的证据边界体系从机制上杜绝无证据的结论。它的自我定位写得很直白Planning, research, creation, coding handoffs, operations, and project memorywith explicit evidence boundaries. —— README.md二、OMH的证据体系三层关键机制1️⃣ Prepared已准备≠ Observed已观察OMH 在术语层面就划清了红线见项目词表 CONTEXT.md记录类型含义状态值Prepared handoff预备交接一份编码执行者之后可以执行的载荷prepared_not_observed已准备、未观察Observed evidence观察证据记录到某事真正发生派发、执行、验证、评审、CI、合并唯一可作为完成结论依据的记录关键点准备一份交接不是派发、执行、评审或合并的证据。任何报告里的完成声明只有背后有 observed evidence 才能成立——这就是 Evidence before claims 的字面落地。2️⃣ Claim Boundary声明边界每个记录自带免责声明OMH 写入的每一个元数据工件都附带一句claim boundary——明确声明这条记录不是什么的证据。比如连接器操作员卡片本身不等于 API 调用成功除非有观察到的连接器结果记录支撑。这让 AI 工作流的每一步都带上了可审计的边界而不是靠自觉。3️⃣ 双轴证据标签连显示都不允许撒谎最精妙的设计在 src/evidence/labels.py证据状态被拆成正交的两个轴——阶段轴PhaseRoute / Plan / Code / Setup / Test / Review / Ship置信度轴Confidencenot run / running / partly seen / reported done / seen / failed / verified渲染出来就是Code · reported done、Test · verified这样一行可读的状态。几个设计细节值得品味阶段词只用名词Code 而不是 Coding因为 Coding 扫一眼会被误读成有人正在写代码reported done专门用来标记执行器自报的完成和门禁验证过的verified严格区分——自报成绩与实测成绩在屏上永远不会长得一样连 ready 都不被允许出现在状态字段里因为它会被 OMH 自己的守卫判定为无观察支撑的声明。三、证据状态在终端里的样子在真实的编码工作会话中OMH 会把运行中和已验证分开呈现——你永远能看到哪些是观察到的事实哪些只是已准备的声明这种诚实的 HUD意味着当 AI 编码流程跑到哪一步、证据到了什么置信度你看到的和它知道的一样多不多不少。四、这套哲学对新手意味着什么你可以放心让 AI 跑长任务状态面板上的verified是观察证据支撑的结论而不是模型的口头承诺交接不再黑盒OMH 的 Maestro 模式只准备交接给选定的编码 CLI绝不假装它执行过——准备与执行是两条分明的车道记录可回溯每个编码 run 都会在$OMH_HOME/runtime/runs/id下累积交接、观察与效果回执审计时有据可查。更多工作流与角色定义可参考 docs/WORKFLOWS.md。五、快速上手三步体验证据驱动编码安装clone 仓库https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes后运行安装脚本详见 docs/INSTALLATION.md配置执行omh setup完成交互式模型配置体检用omh doctor验证安装状态上手后你只需要记住一句话在 oh-my-hermes 的世界里我说了完成了永远不等于它完成了——只有被观察到的证据才算数。这恰恰是它让 AI 编码更可信的全部秘密。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考