企业官网建设流程全解析

使用 Codex 修改项目时，很多人都遇到过一种情况：

明明已经让它读取了整个项目，也把报错信息发给了它，但修改完成后才发现，它动了不该动的文件，甚至把原本正常的模块也改坏了。

例如只是让它修复登录接口，最后却同时修改了用户模块、数据库配置、公共请求方法和依赖文件。问题虽然暂时消失了，项目里却多出一堆新的隐患。

这不一定是 Codex 没有读懂代码，更常见的原因是：任务边界没有说清楚。

项目越大、目录越多、历史代码越复杂，越不能只说一句“帮我修一下”。下面这5个项目边界，最好在 Codex 开始修改前明确告诉它。

一、没有说明允许修改的目录

最常见的问题，就是只描述了目标，没有限制修改范围。

比如：

帮我修复用户登录失败的问题。

对于开发者来说，我们可能默认问题就在src/user目录。但对 Codex 来说，登录失败也可能与请求封装、路由、数据库、环境变量甚至依赖版本有关。

如果没有限制，它就可能沿着调用链一路修改下去。

更稳妥的说法是：

本次只允许检查和修改src/user与src/auth目录，其他目录只能读取，不能修改。

这样可以明显减少无关文件被改动的情况。

二、没有指定真正的入口文件

不少项目中会同时存在多个相似入口。

例如：

• login.ts
• login.service.ts
• user-login.ts
• legacy/login.js
• test/login.mock.ts

人可以根据经验判断哪个文件正在使用，但 Codex 可能会根据文件名、引用关系或局部代码，选择一个看起来最相关的入口。

如果项目里还保留了旧版本代码，它就更容易从错误文件开始排查。

因此，提交任务时最好直接说明：

当前登录功能的入口是src/auth/login.controller.ts，请从这个文件开始分析。

不要让 Codex自己猜入口，入口判断错了，后面的修改通常都会偏离。

三、测试目录和正式代码混在一起

有些项目为了方便，会把测试文件、模拟数据和正式代码放得很近。

例如：

src/ user/ user.service.ts user.mock.ts user.test.ts

当报错信息不完整时，Codex可能先修改测试数据，让测试暂时通过，但真实业务问题并没有解决。

还有一种情况是，它根据测试用例理解业务逻辑，但测试用例本身早已过期，最终反而把正式代码改成了旧逻辑。

所以要提前说明：

测试文件只能用于理解和验证，不允许为了通过测试而修改测试用例，除非确认测试本身存在错误。

测试通过不等于业务正确。尤其是旧项目，不能把现有测试当成绝对标准。

四、历史代码没有标明是否还在使用

很多项目里都会留下这些目录：

backup/ legacy/ old-version/ temp/ deprecated/

开发者知道它们已经停用，但 Codex只看到一组结构完整、功能相似的代码。

如果旧代码写得更完整，注释更多，它甚至可能优先参考旧版本，再把旧逻辑重新带回当前项目。

比较稳妥的做法，是在任务中明确标注：

legacy和backup目录已经停用，只能查看，不能引用、复制或修改其中的实现。

如果条件允许，还可以直接把废弃代码移出当前工作区，减少无关上下文对判断的干扰。

五、没有明确禁止修改的内容

只告诉 Codex“可以改什么”还不够，还要告诉它“绝对不能改什么”。

常见的高风险内容包括：

• 数据库表结构；
• 公共接口参数；
• 依赖版本；
• 环境变量；
• 权限逻辑；
• 支付和订单状态；
• 其他模块正在调用的公共方法。

例如，一个类型报错本来只需要调整局部参数，Codex却可能直接修改公共接口类型。当前文件不报错了，其他模块却全部受到影响。

因此，任务里可以增加一句：

禁止修改数据库结构、依赖版本、环境配置和公共接口。如确实需要调整，请先说明原因，不要直接执行。

我现在常用的任务说明

在让 Codex修改代码前，我通常先发下面这段：

请先读取项目目录和相关文件，不要立即修改。
本次只允许修改src/user目录，其他目录只能读取。
当前入口文件是src/user/user.controller.ts。
禁止修改数据库结构、依赖版本、公共接口和环境配置。
请先列出准备修改的文件、修改原因以及可能影响，确认方案后再开始执行。

这段话看起来多了几行，但通常比让 Codex直接修改更省时间。

结语

Codex改错文件，很多时候并不是它完全看不懂项目，而是项目里存在太多相似路径，而用户没有划定清晰边界。

在中大型项目中，至少要提前说清楚四件事：

修改哪个目录、从哪个文件开始、哪些代码已经废弃、哪些内容绝对不能动。

先让 Codex列出修改计划，再查看实际文件差异，最后运行测试和人工复查。把修改范围控制住，往往比反复要求它“重新修一次”更有效。