为了少付几轮返工费，我让智能体一次只改一件事

先把能运行的代码存成检查点

让编码智能体修改项目，最怕的不是它写错，而是改完之后，你已经分不清哪些地方原本正常。接着让它反复修补，既可能扩大问题，也会增加请求费用。

Git 是一种版本管理工具，可以记录代码的变化。你可以把一次提交理解为一个带说明的检查点：哪些文件变了，为什么变，都能留下记录。提交保存在本地，不等于已经上传到远程仓库。

开始前，先确认项目能完成最基本的操作，再保存当前版本。如果项目已经有问题，也要把问题告诉智能体，避免它把旧故障当成自己的修改造成的。

分支可以理解为同一个项目的一条独立修改路线。主分支保留已经确认的成果，任务分支用来尝试新改动。比如修改搜索结果排序，就为这件事建立一个分支，不要顺便重做登录页面。

分支不是完整备份，也不会隔离程序运行时产生的所有影响。它主要帮助你组织代码变化。对初学者来说，一次只让一个智能体处理一个任务分支，比让多个智能体同时修改同一份文件更容易掌控。

“帮我优化整个项目”很难验收，也容易引来大量无关修改。更实用的要求是说明具体问题、预期结果，以及哪些内容不要动。例如，只修复空搜索没有提示的问题，保持现有页面布局不变。

动手前，可以先让智能体解释准备修改什么。你确认方向后再继续，通常比它写完一大批代码之后才发现理解错误更省事。计划不必很长，能看懂修改范围即可。

智能体说“完成”，不代表任务已经通过检查。先查看修改前后的差异，确认它没有删除必要功能、改动无关文件，或者加入你不认识的依赖。

再运行项目已有的相关测试，并亲自试一次目标功能。即使不完全理解代码，你也可以检查页面是否正常、输入是否得到预期结果，以及原有操作是否还能完成。没有测试的项目，至少重复走一遍修改涉及的操作流程。

确认后再提交，说明这次解决了什么。不要把几件无关的工作塞进同一次提交。这样以后发现问题，更容易找到对应变化。

如果修改越修越乱，先暂停请求，查看最近一次正常的检查点。尚未提交的改动，可以在确认没有需要保留的内容后放弃；已经分享给别人的提交，通常更适合通过新增撤销提交来抵消，而不是直接改写共同历史。

不要让智能体未经确认就清空修改或重置版本。恢复操作也可能丢失你的工作。先看清影响范围，再决定保留、拆分还是撤销。

版本管理不会直接降低模型单价，但清楚的检查点和任务边界，可以减少重复解释与无效返工。换一个任务时，只提供相关背景和必要变化，不必每次都要求智能体重新梳理整个项目。

如果你通过 MyRelay 使用编码工具，可以结合每次请求的用量和费用记录，观察哪些任务容易反复重试。你可以创建一个 MyRelay 账户，把不同模型的调用放在同一份个人预算里管理。

先留检查点，一次改一件事，检查通过再合并回主分支。这套习惯不复杂，却能让你更清楚地知道：代码为什么变了，下一笔请求费用是否值得花。