“让 AI 顺手优化一下”，最后却改了十几个文件；刚修好的问题，下一轮又出现了。你也遇到过这种情况吗？

用 AI 编程时，最容易获得成就感的阶段，是第一版界面很快跑起来。真正考验协作的，往往是之后几十轮修改：加一个功能、修一个错误、保留原有行为，再把它交给其他人使用。

我在和 Codex 协作开发项目时，逐渐把注意力从“怎么写一句更强的提示词”，移到了几个更具体的问题上：它知道当前代码是什么状态吗？这次修改的范围清楚吗？我们准备拿什么证明做对了？

这篇文章整理一套我更愿意采用的工作方法。它不是效果对比实验，也没有“效率提高多少倍”的结论；重点是让每轮修改更容易检查和接手。 文中的 PPT 导出场景经过简化，用来展示方法，不能当作某次真实故障的完整复现。

01　先看清：越改越乱，常常乱在这四个地方

现象	先检查什么	可以怎么调整
修 A，顺便改了 B、C	本轮目标是否包含太多可选项	写清一个主要结果，把顺手优化移出本轮
同一条要求反复解释	长期约定是否只留在聊天里	把稳定规则放进简短的 AGENTS.md
AI 说完成，实际没解决	是否只检查代码，没有复现用户操作	为目标写出可观察的验收条件
换个聊天又从头摸索	当前事实、决定和待办是否混在一起	留一份准确、简短的进度记录

这些不是所有问题的原因。模型能力、工具权限和代码复杂度都会影响结果，但协作信息缺失，是我们可以先修正的一部分。

OpenAI 官方文档也建议：任务说明要包含目标行为、相关代码或复现步骤、重要约束，以及验证方式。官方 Prompting 指南

02　把“帮我优化一下”换成一张任务卡

“优化导出功能”听起来很明确，实际可能同时包含性能、排版、错误提示、文件名和版本选择。

我会先缩小成一个用户能观察到的变化，例如：用户选中页面的新版本后，导出的文件也使用这个版本。

下面这份模板可以直接复制，再替换里面的业务内容：

本轮目标：
修复“预览选中新版，导出仍使用旧版”的问题。

上下文：
- 先阅读现有项目说明、导出入口和页面版本选择逻辑。
- 复现步骤：选择新版 → 预览 → 导出 → 打开文件比对。
- 如果无法复现，先报告观察到的结果，不假定原因。

修改边界：
- 保持导出格式、页面顺序和历史版本记录的原有约定。
- 优先在现有流程里修复，不附带改版或依赖升级。
- 发现必须扩大范围的依赖问题时，说明原因和影响。

完成标准：
- 导出内容与本轮选中的版本一致。
- 页数、顺序正确，原有正常导出路径仍可用。
- 给出修改文件、实际检查和未验证事项。

这里的关键，是把期望写成行为，把验证写成结果。“代码更优雅”难以共同判断，“导出文件与选中版本一致”则有明确的检查对象。

也别把任务卡写成每一步都要确认的审批表。范围清楚、已经授权的小修改，可以直接完成并报告；涉及部署、收费调用或范围明显扩大的动作，再明确处理。

03　长期规则写进 AGENTS.md，别把聊天记录全部搬进去

任务卡解决“这次做什么”，AGENTS.md 更适合放“这个项目长期怎么做”。

按照官方说明，Codex 启动时会发现并组合适用的指令，包括全局说明，以及项目根目录到当前工作目录路径上的说明。AGENTS.override.md 等覆盖规则也会影响实际加载结果。它不是把仓库里所有同名文件递归读一遍。 AGENTS.md 官方说明

一个小项目可以先从这样的精简版本开始：

# 项目工作约定

## 项目定位
- 这是演示文稿工具，沿用当前前端、后端和数据存储方案。
- 修改前阅读 README，并确认工作目录与已有未提交改动。

## 实现习惯
- 优先复用现有模块；本轮目标之外的重构单独记录。
- 保留既有接口约定、用户文件和历史版本。
- 不把密钥、真实配置或用户数据写入源码和日志。

## 验证与交接
- 从项目配置和现有 CI 确认实际可运行的检查命令。
- 根据修改范围执行相关检查；行为修复补必要的回归验证。
- 报告已运行的命令、结果与未验证事项。
- 部署、外部写入和收费操作按本轮授权执行。

这是说明结构的示例，不需要原样覆盖你已有的项目规则。框架、目录和命令都应该以实际仓库为准。

我建议分清三类信息：

信息	放在哪里更合适	例子
稳定工作约定	AGENTS.md	框架边界、关键目录、验证习惯
本轮具体任务	当前任务说明	修复哪种行为、如何复现
当前进度与证据	项目已有的计划或进度文档	哪项通过、哪项待查、下一步是什么

如果项目已经有进度文档，就继续维护它，不必再建三份同类文件。普通进度 Markdown 也不是 Codex 内置的特殊配置文件，需要在任务里明确让它阅读。

AGENTS.md 保持简短、准确，比堆满“你必须专业、你必须认真”更容易维护。改动后，可以在合适的新会话中让 Codex 列出它实际读取的指令来源，核对规则是否被加载。

04　拆任务：每一步都能单独判断对不对

拆分不等于“前端一个任务，后端一个任务，测试再一个任务”。对于跨层问题，这样拆有时会把接口和行为割裂开。

我更偏向按一个完整、可验证的行为来拆。还是用导出场景举例：

1. 定位问题：复现现象，追踪页面选中版本到导出读取的路径。
2. 做最小修复：让选中版本正确进入导出流程，保持已有接口约定。
3. 验证和审查：复跑原步骤，检查正常路径和相关边界，再读 diff。

复杂、模糊的改动可以先进入计划阶段；已经明确的一处样式修正，就没必要套上完整流程。官方最佳实践同样建议按任务复杂度决定是否先做计划。官方最佳实践

这里还要区分两个概念：工具调用能同时发起，不等于工作可以由多个智能体独立修改。

让两个审查者分别检查文件权限和页面交互，可以有明确边界；让两个执行者同时改同一个接口的数据结构，就需要先约定接口和文件归属。并行会带来协调与合并工作，不应该只因为任务“看起来很多”就展开多人修改。

05　验证写在前面，完成报告才不会变成一句“已修复”

一份有用的完成报告，应该能让人快速核对：改了哪里、解决了什么、检查过什么、还有什么不确定。

以导出场景为例，我会要求覆盖：

• 目标行为：选择新版后，导出确实包含新版。
• 相邻正常路径：未切换版本时仍能正常导出。
• 相关边界：选中版本对应文件不可读时，返回明确错误，避免静默混入旧内容。
• 回归范围：页数、顺序、文件类型等约定没有因为这次修复被意外改变。

这是本例建议的检查设计，不代表这些情况已经在某个仓库全部执行通过。

自动化测试适合重复检查明确行为；实际打开文件或走一遍用户路径，则能发现测试未覆盖的问题。选择与这次修改相称的验证方式，比每次都跑一遍所有检查更实际。

另一个我很在意的区分是：

静态阅读：从代码推断行为，尚未实际运行。
隔离测试：在受控输入、模拟依赖下检查逻辑。
真实路径：实际走过目标环境里的用户操作。

它们都能提供证据，覆盖的范围却不同。模拟导出测试通过，不能直接写成某个桌面软件已经打开验收；本地页面正常，也不能直接写成线上发布成功。

06　让 Codex 再审查一次：提具体问题，比“看看有没有 bug”更有效

实现阶段容易沿着“怎么把它做成”思考；审查阶段可以换一个问题：这次修改会在什么条件下失败？

我会使用这样的审查提示词：

审查本轮改动，先不继续修改代码。
对照本轮目标、适用项目规则和实际 diff，重点检查：
1. 用户选中版本是否真正进入导出，是否有静默回退。
2. 异常路径是否保留明确错误，是否会覆盖历史产物。
3. 修改是否触及本轮不需要调整的接口或文件。
4. 现有验证是否真的覆盖上述行为。

发现问题时，给出文件位置、触发条件和用户可见的影响。
区分确定的问题与待验证假设，不为了凑数量增加建议。
若未发现问题，说明审查范围和仍未验证的边界。

这个模板把“检查什么”和“怎么报告”都说清楚了。审查后是否继续修复，再按发现的问题处理，避免审查过程又扩成一轮无边界的优化。

需要强调的是，同一个模型自审仍可能重复原来的判断盲点。它可以补充检查，不能保证发现所有错误；关键逻辑还需要测试、真实路径或人工判断一起支撑。

07　换聊天、暂停之前，留下能直接接手的状态

长任务里，最昂贵的一种重复劳动，是重新解释已经做过什么。

我会在合适的里程碑留下一段简短交接，而不是复制整份聊天：

目标：本轮要解决的行为。
已完成：实际修改与已确认结论。
验证：执行了哪些检查，结果和证据位置是什么。
未完成：失败、未运行或仍待确认的部分。
当前状态：分支、未提交改动；必要时记录运行版本。
下一步：从哪里继续，有哪些前置条件。

尤其注意，昨天记录的服务状态、额度或部署版本，今天可能已经变了。交接记录帮助定位，继续工作前仍要核对会影响操作的当前状态。

代码改动也应该有清楚边界。开始前确认已有改动的归属；每个完成阶段检查实际 diff；在合适的里程碑保存版本。不要为了获得“干净状态”随手丢弃别人的修改。

---

如果今天只准备调整一件事，我建议从下一次任务开始，多写这四行：目标、上下文、边界、验证。

等某条规则需要反复提醒，再把它写进项目说明；等某类工作已经稳定重复，再考虑做成可复用工作流。工具和文档都随着实际需要增加，项目会更容易持续维护。

你和 AI 协作时最常遇到哪种返工：擅自扩大范围、忘记原要求，还是代码看着正确但操作不通？欢迎把具体场景留在评论区。

参考资料

• OpenAI：Prompting Codex
• OpenAI：Custom instructions with AGENTS.md
• OpenAI：Best practices

文中配图为原创方法示意；模板是可调整的协作建议，不会代替实际工具权限、代码审查和项目验收。