过去一段时间，我在做一个本地自动化工具，把办公网站里的常用能力封装成 AI Agent 可以调用的命令。
现在的合作方式已经很成熟：我告诉 Codex 一个功能点，带它看一次页面；Codex 负责分析请求、实现代码、补测试和文档。真正写代码的人不是我，单个功能的接入也已经足够高效。
但我还是开始疲惫。
问题不是实现太难，而是每天都要由我回答：
下一个应该封装什么？
今天提一个列表，明天提一个详情，后天再想起某个筛选。Codex 很能干，但它一直在等我点菜。我仍然是唯一的需求发现者、产品经理和启动按钮。
这不是编码疲惫，而是持续发起任务的疲惫。
从点菜变成审核
现在的流程是：
我想起一个功能
→ 告诉 Codex
→ Codex 分析并实现
→ 等我想起下一个
下一阶段应该改成：
我指定一个站点或业务范围
→ Codex 主动盘点页面和现有能力
→ 找出缺失的列表、详情、筛选和关联查询
→ 生成候选清单，标注价值、风险和成本
→ 我集中审核
→ Codex 批量实现
交互单位不再是一个按钮，而是一个页面或一段工作流。我的职责也从“每天想需求”变成“偶尔定方向、审候选”。
候选从哪里来
Codex 可以从几个地方主动发现下一步：
- 一次页面探索中尚未接入的筛选、分页、详情和关联入口。
- 使用频率高、但需要多次拼接才能完成的现有能力。
- 对话中反复出现的临时网页操作。
- 页面功能与已注册能力之间的缺口。
候选项需要说明用途、预期收益、读写属性、实现成本，以及仍需我确认的问题。
主动发现不等于自由扩张。写操作仍需逐项批准；查询型 POST 仍需判断副作用；运行时不能开放任意 URL；凭据和敏感数据不能进入候选记录、测试或日志。
下一步
不必一开始就建设复杂平台。先做三件事：
- 建立候选能力清单，记录来源、价值、风险和待确认问题。
- 每次探索页面时，默认盘点完整只读工作流，而不只实现当次点名的功能。
- 定期根据使用记录和重复对话生成候选项，让我一次审核一组。
Codex 已经能够很好地分析和实现能力。现在真正缺少的，是一套不再依赖我逐个发起任务的演进机制。
我希望自己从每天点菜的人，变成偶尔确定方向和审核边界的人。