实际案例

理解 OME 最快的方式，是看一次真实的 prompt-time recall。这个案例用 /goal / 创建目标 做例子，因为它能说明 OME 和常驻规则文件的核心区别： 不是把所有要求都塞进入口规则，而是在任务真的需要时召回对应经验。

案例：/goal 触发完整闭环交付模式

假设你的 active 经验库里有一张已经审核过的目标执行卡。首次初始化后，OME 会内置一张 英文 starter 卡：Enter full-closure delivery mode when a goal starts。它的使用标准是： 当 /goal、创建目标 或 开干 启动真实执行任务时使用；如果只是文档示例、功能解释 或业务目标讨论，就忽略。

当用户发出：

创建目标并开干：在 /tmp/ome-todo-demo 里做一个小型单页 Todo 应用。
它需要支持新增、完成、删除、清空已完成、剩余数量、localStorage 保存，并通过真实浏览器验证。

OME 会先把这段 prompt 拆成 task envelope。它会识别出 goal 执行意图、明确执行意图、 真实验证要求，然后把这张卡列为 high-risk、must-use 的待判断经验。命中不等于已经使用； Agent 还要根据这张卡的工作流含义判断它是否真的适用于当前任务，再读取并应用完整规则。

Agent 看到的关键提醒

在 Agent 开始行动前，OME 会把相关经验作为紧凑提醒交给它。用户不需要关心底层命令 怎么跑，只需要知道 Agent 此时看到了哪条经验：

OME 召回：
Enter full-closure delivery mode when a goal starts

Agent 仍然要判断这条经验是否真的适用于当前任务。如果适用，它再读取完整规则，并用这条 经验约束自己的执行方式。

这会改变什么

没有 OME 时，这类任务很容易变成：只写一个目标标题、先做第一个可见切片、跑一点局部检查， 然后过早报告完成。有了 OME，Agent 会在行动前看到这条真实规则：

当用户说 `/goal`、`创建目标`、`使用 goal`、`开干`、`开始执行目标`、`跑长任务`，或要求把一批需求压进目标推进时，必须把这视为执行启动协议，而不是普通目标文案。默认执行规则如下：

1. 启动前先明确目标、范围、非范围、真实完成标准和逐项验收清单；如果目标被切得太小，先指出范围风险并把用户已确认的一批需求纳入同一目标。
2. 按完整计划系统推进，锚定 source of truth、story、roadmap、设计方案或用户原话；执行中不能方向漂移，不能只做第一个可见切片。
3. 所有计划内功能点都要完整闭环，不交半成品；禁止只做 happy path、UI 壳、接口半截、placeholder、fake route、隐藏测试入口、内存替代、假外部动作或 fallback 制造两套真相。
4. 实现时同步保证可维护性、可扩展性、稳健性和鲁棒性：模块按真实边界拆分，职责清楚，必要时清理直接相关的脏逻辑和死代码；不要为了假想未来做空泛抽象。
5. 验证必须走真实入口和真实用户路径；命令、功能、状态、文档或证据要逐项覆盖。工具成功、局部 smoke、代码写完都不能单独代表完成。
6. 对复杂或高风险目标，完成后主动做自检；必要时 dispatch 外部模型或 review 流程，重点检查方向是否漂移、功能是否完整、实际可用性、架构质量和可维护性。
7. 完成判断必须 fail closed：只要还有计划功能未做完、验收未通过、证据缺失、环境阻塞未说明或风险未交代，就不能把目标标记为 complete；应继续修复或明确 blocked。
8. 最终交付要面向用户说明体验变化、已验证证据、风险限制和待确认项。

结果是：Agent 不会每轮都背着这段长规则，而是在用户真的说 /goal、创建目标、开干 这类执行启动话术时，才把它作为待判断经验处理。

用户最终看到什么

如果 Agent 确实采用了这张经验，最终回复可以带一行跟随用户语言的使用披露：

已完整完成 /tmp/ome-todo-demo 里的 Todo 应用，验证了新增、完成、删除、清空已完成和本地保存，并列出剩余风险。

**本次使用的 OME 经验卡：1** Enter full-closure delivery mode when a goal starts

如果用户只是讨论业务目标、OKR，或者只是问 /goal 是什么，这张卡会被忽略，也不会出现 在最终使用披露里。