使用 ChatGPT、Codex Agent 改项目时，有一种情况特别让人困惑：
代码明明已经改好了，页面当时也能看到效果，但只要重新 Build，一切修改又没了。
常见表现包括：
- Agent改完页面后，刷新可以看到变化；
- 重新执行构建命令后，文件又恢复原样；
- 本地开发环境正常，正式打包后修改消失；
- Agent反复修改同一个文件，每次Build都会被覆盖；
- Git里能看到改动，但下一次生成代码后又变回去。
这时候问题往往不是：
ChatGPT、Codex没有成功修改文件。
而是：
Agent改错了“代码源头”。
一、先理解什么叫Source of Truth
很多现代项目里，你看到的文件不一定是真正应该修改的文件。
例如项目中可能同时存在：
- src
- dist
- build
- generated
- public
- 自动生成的API Client
- ORM生成代码
- protobuf生成文件
其中有些文件只是：
由其他源文件生成出来的结果。
真正决定最终内容的，是上游那个源文件。
这个源头通常可以理解为：
Source of Truth。
二、为什么Agent很容易改到生成文件？
ChatGPT、Codex Agent在搜索项目时，通常会根据：
- 文件名；
- 关键词；
- 当前调用位置；
- 搜索结果；
判断应该修改哪个文件。
问题在于生成目录里的代码往往：
更完整、更直接、更容易搜到。
例如页面报错出现在：
dist/app.js
Agent搜索到以后，可能直接修改这个文件。
当时当然可以生效。
但下一次Build时：
src
重新生成：
dist
刚才的修改自然就被全部覆盖了。
三、最典型的就是dist和build目录
很多前端项目都会经历类似流程：
src → 编译 → dist/build
如果Agent直接修改：
dist
那么它修改的是：
构建结果。
而不是：
源代码。
所以重新运行：
npm run build
之后，dist会重新生成。
之前手动修改的内容就不存在了。
这也是为什么有时候你会觉得：
Codex刚才明明已经修好了，怎么一打包又坏了？
其实不是修复失效，而是修复根本没有落到正确源文件。
四、Codegen项目更容易出现这种问题
还有一类更加隐蔽：
代码生成。
例如：
- OpenAPI生成Client；
- protobuf生成代码；
- GraphQL Codegen；
- ORM Schema生成Model；
- SDK生成器；
- 配置文件生成类型定义。
这种情况下，Agent可能直接修改生成出来的代码。
短期可以工作。
但下一次执行：
generate
所有修改又会被覆盖。
所以看到类似目录或文件头时要特别警惕：
- generated
- auto-generated
- do not edit
- codegen
- generated by …
这些通常意味着：
这里不是最终应该改的地方。
五、有时候真正要改的不是代码，而是配置
例如API Client是根据：
openapi.yaml
生成的。
Agent发现请求参数不对，于是直接修改生成后的Client。
这样看起来问题解决了。
但真正应该修改的可能是：
OpenAPI定义
然后重新生成Client。
否则下一次Codegen一运行：
问题又回来。
所以排查时要问：
这个文件是谁生成的？
而不只是：
这个Bug出现在哪个文件？
六、Git也能帮你判断文件是不是生成产物
如果某个目录：
- 平时不提交Git；
- 出现在 .gitignore；
- Build后自动生成；
- 删除以后重新执行命令就能恢复；
那它大概率不是应该长期维护的源文件。
另外还可以观察：
文件是否每次Build都会大量变化。
如果是，就应该继续往上找：
到底哪个输入文件生成了它。
七、Agent修改前最好先做一次“文件归属判断”
以后让 ChatGPT、Codex Agent 修改代码前，可以先要求它判断：
这一步看起来多了一点时间。
但实际上可以避免：
改完 → Build → 消失 → 再改 → 再消失
这种重复返工。
八、不要因为页面立即生效，就认为改对了
这是很容易误判的一点。
如果Agent改的是当前正在运行的产物文件，页面当然可能立即发生变化。
但这只能说明：
当前运行环境读取到了这个修改。
不能证明：
这个修改可以永久保留。
真正有效的验证应该多一步：
重新执行Build，再检查修改是否仍然存在。
如果Build后消失，就应该立即怀疑：
Source of Truth找错了。
九、这类问题最适合按这个顺序检查
如果 ChatGPT、Codex Agent 改完代码后，一Build修改就没了，可以这样排查：
第一步：确认被修改文件所在目录。
是不是 dist、build、generated。
第二步：确认文件是否自动生成。
查看文件头、构建脚本和package配置。
第三步：找到上游源文件。
确认真正应该修改哪个 src、schema或配置文件。
第四步：重新修改源头。
不要继续改生成结果。
第五步：重新Build验证。
确认构建以后结果仍然保留。
十、可以直接这样让ChatGPT、Codex Agent检查
以后遇到这种情况，可以直接告诉它：
请不要继续修改当前生成文件。先判断这个文件是否属于dist、build、generated或其他Codegen产物，检查它是由哪个源文件、Schema或配置生成的。找到真正的Source of Truth后修改上游源文件，再重新执行Build或Codegen验证修改是否仍然存在。
这样比反复说：
为什么我刚改好的代码又没了？
更容易直接定位问题。
最后
ChatGPT、Codex Agent 改完代码以后，一Build修改就消失，很多时候真正的问题不是：
修改失败。
而是：
修改落在了一个会被重新生成的文件上。
真正需要确认的是：
源文件在哪里 → 谁生成了当前文件 → Build会不会覆盖 → 应该修改哪一个Source of Truth。
以后看到：
“刚改好，一Build又恢复”
第一反应不要继续重复改同一个文件。
先检查：
这个文件到底是不是应该被直接修改的那个文件。
持续更新 ChatGPT、Codex Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。
