企业官网建设流程全解析

最近用 Codex 改项目时，我遇到过一个比“不会写代码”更麻烦的问题：它有时会改得太积极。明明只是修一个按钮，最后连接口命名和无关样式也一起动了。

后来我把流程固定成下面 4 步，返工少了很多。

1. 先让 Codex 读，不要马上改

第一次接触一个项目，我会先让它看目录结构、启动方式和相关文件，只要求它说明当前实现，不执行修改。

我一般会这样写：

先阅读项目结构和与这个问题相关的文件，说明入口、数据流和测试位置。暂时不要修改任何文件。

这一步看起来慢，其实是在确认它有没有找对地方。尤其是老项目，文件名相似、历史代码多，直接开改很容易走偏。

2. 把修改范围说清楚

“帮我优化一下”对人和对 AI 都太宽了。我会提前写明允许改哪些文件、不能碰哪些部分，以及完成后应该看到什么结果。

比如：

• 只修改列表页和它对应的样式文件；
• 不改接口协议，不调整数据库结构；
• 搜索只过滤当前已经加载的数据；
• 清空输入后恢复原列表；
• 修改完成后补一条相关测试。

范围越清楚，后面看 diff 越省时间。

3. 先要方案，再让它动手

如果任务涉及多个文件，我通常会多加一步：先列出准备修改的文件和做法，等我确认后再执行。

这不是为了限制它，而是给自己留一个发现误解的机会。很多“改偏”不是代码写错，而是它理解的目标和我想要的结果不一样。

4. 改完一定要验证

代码改完不等于任务完成。我会让 Codex 继续运行项目已有的测试、类型检查或构建命令，并把执行结果写出来。

如果项目没有自动化测试，至少手动确认几个关键路径：页面能不能启动、按钮状态是否正常、空数据和异常输入会不会报错。

我现在常用的完整顺序是：

1. 读项目并复述理解；
2. 明确修改边界；
3. 先给方案；
4. 小范围修改；
5. 看 diff；
6. 跑测试或做手动验证。

还有哪些地方要自己把关

涉及账号、权限、删除数据、支付和正式发布时，我会把最后一步留给自己。业务逻辑复杂的项目，也不能只看“测试通过”，还要检查它有没有改变原来的业务规则。

Codex 适合参与真实项目，但它更像一个执行力很强、刚接手项目的同事。你需要先把背景和边界交代清楚，再检查它实际做了什么。

如果你刚开始用 Codex，可以先拿一个小 bug 试试这套流程：先读，再改，再验证。用过几次之后，通常就能找到适合自己的节奏。