# Action 的保存规则与协作场景

Action 可以是简单的命令，也可以是复杂的脚本。复杂、稳定且需要复用的行为更建议沉淀成脚本，但不要求每个 Action 对应一个脚本文件。

例如 `npm run build` 可以直接登记为构建 Action；启动服务如果包含检查环境、处理本项目的旧进程、启动进程和等待就绪，适合调用维护好的 `start.sh` 或 `start.ps1`。已有脚本可以直接使用，不需要再包一层。Action 在命令之外保存用途、适用项目、执行条件和验收方式，让 Jev 知道何时选择它。

## 写给主模型的维护规则

1. **主动维护有用的操作。** 用户明确要求时保存；发现步骤稳定、适合重复的开发操作时也主动考虑登记，不必等待用户再说“记住”。一次性探索、未知 Bug 的修复和开放式设计通常继续由主模型处理。用户明确禁止保存时遵守该要求。
2. **先查库，再决定新增。** 已有同用途、同项目且仍有效的操作先复用；不要每次对话新建一个同义 Action。不同项目可共用用途定义，分别绑定自己的命令。
3. **选择合适粒度和载体。** 简单操作直接保存命令；复杂操作优先复用或编写脚本。用户会独立请求、需要单独判断的步骤才拆开；已经可靠的整套启动脚本可以作为一个 Action。
4. **描述必须足够做选择。** 说明做什么、何时适用、前提、作用范围与副作用，以及怎样确认完成。启动、重启和停止不能混用。当前版本只能复用固定命令及其项目绑定，需要新的自由参数时交给主模型。
5. **实际验证后再复用。** 验收检查真实效果，如服务健康、产物与当前输入一致，而不只是打印成功。优先先建草稿、再用 validate 执行任务。若已经执行，运行时可以沿用本轮精确匹配的成功工具证据，只验收并激活，避免为了入库再次回滚或发布；证据存在未知修改时不直接采用。
6. **区分实现与输入。** 脚本和决定执行方式的配置变化需要复核；测试针对的源码、生成器读取的 schema 和报表数据通常属于运行输入。输入变化后仍可选择原 Action，以当前输入重新验收。修改 recipe 时创建新版本并验证，替代当前激活版本。
7. **声明重做策略。** 测试、构建、生成、确保服务启动/停止等可安全重复的操作用 `if_not_satisfied`：同一请求再次选择时复查，结果失效才重做。发布等不能自动重复的副作用使用默认的 `once_per_request`。

模型负责依照策略登记和修订；代码负责存储、指纹、权限与验收；Jev 负责选择下一步。描述中的适用条件由模型理解，不能当作硬性权限控制。当前尚无自动清理、归档或按使用次数淘汰 Action 的机制。

对应运行时注入规则见 [action-authoring.md](../prompts/action-authoring.md)。

## 混合任务示例

下列是说明机制的目标交互，前提是相关 Action 已经登记并验证。它们不是已经测得的 Jev 成功轨迹；实际选择是否正确需要实测。

| 用户请求 | Jev 与主模型的分工 | 需要保留的判断 |
|---|---|---|
| “启动项目，把首页价格卡片改成三列；窄屏保留一列，改完检查构建。” | Jev 启动并验收 → 主模型修改页面 → Jev 执行构建 Action → 主模型解释结果 | 启动成功后还有修改任务，不能 DONE；构建通过也不代表视觉效果已经检查 |
| “用最新数据重跑报表，分析这个月收入下降的原因。” | Jev 生成并验证报表 → 主模型读取结果、分析原因 | 文件生成成功只完成了准备工作 |
| “按当前接口定义重新生成客户端，再把登录页面接到新接口上。” | Jev 运行生成 Action → 主模型完成接入 → Jev 执行已有测试 | 生成过程可复用，页面接入仍需理解业务与代码 |
| “给导出接口增加日期筛选，更新接口定义并生成客户端，最后检查类型。” | 主模型修改接口与定义 → Jev 生成客户端、执行类型检查 → 主模型汇报 | Action 可以在任务中间进入，不只在入口执行 |
| “修一下 CSV 解析；改完运行回归测试并重新打包。” | 主模型定位和修复 → Jev 测试、打包 → 主模型说明修复 | 失败日志必须进入共同历史，不能用旧成功记录替代当前检查 |
| “跑完这个问题的排查后，把本项目的开发服务停掉。” | 主模型排查 → Jev 停止并验证 → 主模型说明发现 | 停止服务不能替代用户要求的诊断结论 |
| “把当前版本发布到约定的本地演示目录，并总结本次修改。” | Jev 选择测试、构建、发布 Action → 主模型总结修改 | 发布对象和范围应来自当前请求；保存过命令本身不构成发布授权 |
| “只把前端起起来，后端已经在跑，不要重启它。” | Jev 选择前端启动 Action → 检查结果 → 满足完整请求后可 DONE | 有条件地复用已有状态，避免无意义地重启整套服务 |

## 交接发生在哪里

每个后续模型请求之前，Loop 都有机会让 Jev 选择 Action、LLM、ASK 或 DONE。主模型工具的结果、Action 的执行观察和用户要求进入同一份组装后的历史。Jev 可以执行准备操作后交给主模型，也可以在主模型工具调用之后接手已知步骤。

它不能在主模型正在生成一段回复时随意抢占，也不会在主模型最终回复已经结束 turn 后自动追加一个步骤。完整任务的语义完成仍可能被误判，因此验收某个 Action 成功不等于整件任务完成。

当前规则是：纯 Action 请求可以由 Jev 直接结束；主模型已经参与的请求，由主模型完成最终收尾，Jev 仍能执行中间操作。这样，主模型能拿到结果、维护 Action，并完成用户要求的解释。

同一用户输入内可重复状态操作依赖 verifier 判断旧结果是否仍有效，因此可以支持“测试、修改、再测试”。默认副作用操作仍至多成功执行一次；新用户输入可以再次执行。verifier 若不检查当前输入，就可能错误复用旧结果，不能依赖一条固定成功字符串来判断。执行失败会交给主模型处理。展示示例时应区分机制设计、本地确定性测试和真实 Jev 实测结果。

首轮开发者实测已有“Jev 启动后交给主模型修改”的真实轨迹；同时暴露了自主保存、依赖选择和最终总结的问题，详见 [结果解释](../reports/developer-workflows/ANALYSIS.md)。上表中其他理想协作顺序仍需逐一验证。