很多开发者最近使用Codex，会遇到一个非常矛盾的现象。

让AI写一个函数。

效果越来越好。

让AI补一个测试。

基本可以直接使用。

让AI解释一段代码。

甚至比很多新人理解得更快。

但是，一旦进入真实项目：

尤其是：

老项目。

大型Repository。

多人维护系统。

情况开始变化。

同样是修改代码。

简单任务：

AI非常稳定。

复杂项目：

却容易出现：

• 改动范围扩大
• 修改方向偏离
• 技术方案正确，但业务结果错误
• 测试通过，但上线风险增加

很多人第一反应：

“是不是模型还不够强？”

但实际上，问题可能恰恰相反。

因为：

AI已经足够强，开始进入过去只有工程师经验才能处理的问题领域。

而真实项目最大的难点，从来不是：

“代码怎么写。”

而是：

为什么这个系统现在必须这样运行。

---

一、为什么AI写新代码越来越准？

先看AI最擅长的场景。

例如：

让Codex实现一个排序算法。

或者：

写一个接口。

补一个工具函数。

这种任务为什么效果很好？

因为问题边界非常明确。

AI需要处理的信息主要是：

输入。

输出。

逻辑。

规则。

这是一个典型的：

局部代码生成问题。

而现在模型在这方面已经非常强。

它拥有大量代码模式经验。

能够快速推断：

应该使用什么结构。

应该调用什么方法。

应该如何组织代码。

所以：

代码生成正在逐渐成为基础能力。

---

但真实项目不是这样。

真实项目的问题通常不是：

“这段代码怎么写？”

而是：

“这里为什么这样设计？”

这两个问题完全不同。

---

二、真实项目里，代码只是冰山上面的一部分

很多开发者低估了一个事实：

一个运行多年的项目，真正重要的信息并不全部存在代码里。

代码只是表面。

下面还有大量隐藏信息。

例如：

一个字段为什么一直存在？

可能因为：

旧客户端依赖它。

一个接口为什么设计得不优雅？

可能因为：

历史版本必须兼容。

一个模块为什么没有重构？

可能因为：

风险太高。

这些东西：

不是技术问题。

而是：

系统约束。

---

举一个简单例子。

你让Codex优化一个用户系统。

AI分析以后发现：

用户表结构存在冗余。

于是提出：

拆分字段。

优化模型。

代码质量提高。

测试全部通过。

从技术角度：

这是一个优秀方案。

但是业务团队可能告诉你：

不能改。

因为：

过去几年已经有多个系统依赖这个结构。

这时候问题在哪里？

不是AI不会写。

而是：

AI不知道这个决定背后的历史。

---

三、AI进入真实项目后，最大的挑战是Context

很多人认为：

让AI读取更多文件。

它就会更理解项目。

但真实情况更复杂。

项目Context不是文件数量。

而是：

AI需要理解多少隐藏关系。

一个真实项目通常包含四种Context。

---

1. 代码Context

这是最容易理解的。

例如：

函数调用关系。

模块结构。

文件依赖。

这一层现在AI已经越来越强。

---

2. 架构Context

例如：

为什么这个服务独立存在？

为什么这个逻辑放在这里？

为什么不能直接调用另一个模块？

这些属于系统设计。

---

3. 历史Context

这是最容易被忽略的。

很多代码存在的原因：

不是因为现在最好。

而是因为过去必须这样。

例如：

一个旧接口。

一个废弃字段。

一个特殊判断。

如果不知道历史：

AI会认为：

“这里可以优化。”

但工程师知道：

“这里不能动。”

---

4. 业务Context

这是最高难度。

技术上正确。

不代表业务正确。

例如：

AI优化退款流程。

代码更简洁。

速度更快。

但是：

某些特殊用户类型的退款规则被改变。

程序没错。

业务错了。

---

所以真实项目里的AI挑战是：

从：

“生成代码。”

变成：

“理解系统。”

---

四、为什么模型越强，进入真实项目后这个问题越明显？

这是一个很有意思的变化。

很多人认为：

模型越强。

应该越不容易出错。

但在大型项目里，情况并不完全如此。

原因是：

模型能力越强，它能处理的任务范围越大。

以前：

让AI修改20行代码。

现在：

让AI分析整个Repository。

以前：

解决一个函数问题。

现在：

让Agent完成完整Feature。

任务规模扩大以后：

AI接触的信息更多。

它发现的优化空间更多。

同时：

它影响的范围也更大。

于是新的风险出现：

局部最优，不等于系统最优。

AI可能找到一个技术上更好的方案。

但不是当前项目最合适的方案。

---

五、为什么Agent时代，这个问题会越来越重要？

因为未来AI不会只负责：

“回答问题”。

而会越来越多参与：

• 分析项目
• 修改代码
• 运行测试
• 提交变更
• 持续维护

也就是说：

AI从工具变成协作者。

工具时代：

你问。

它答。

Agent时代：

它行动。

而行动意味着：

它必须理解边界。

必须知道：

什么应该改变。

什么不应该改变。

---

所以未来开发者和AI之间的区别，不再只是：

谁写代码快。

而是：

谁能让AI更准确理解：

这个系统真正需要什么。

---

六、如何判断自己的项目是不是已经进入高复杂度阶段？

这里可以建立一个简单指标：

项目Context复杂度

它不是看代码行数。

而是看：

一次修改需要理解多少隐藏约束。

可以通过几个问题判断。

---

第一：

修改一个功能，会影响多少地方？

低复杂度：

一个模块。

一个服务。

影响明确。

高复杂度：

多个服务。

多个接口。

多个团队依赖。

---

第二：

项目里有多少“看起来应该改，但不能改”的地方？

例如：

旧字段。

旧接口。

特殊逻辑。

兼容代码。

越多：

Context复杂度越高。

---

第三：

新人加入项目，需要多久才能真正理解系统？

如果：

几天可以理解。

复杂度低。

如果：

几个月才能掌握关键规则。

复杂度高。

---

当你的答案越来越偏向后者：

说明AI面对的问题已经不是代码生成。

而是：

系统理解。

---

七、先降低Context压力，而不是马上追求更强AI

很多人在遇到AI改偏以后：

第一反应：

换更强模型。

但很多时候：

真正的问题是项目没有给AI足够信息。

可以先做几个优化。

---

第一：明确修改边界

不要：

“优化订单模块。”

应该：

“优化订单查询接口，只允许修改查询逻辑，不改变数据结构，不影响接口格式。”

---

第二：补充项目规则

把隐性经验变成显性规则。

例如：

哪些目录不能动。

哪些接口必须兼容。

哪些模块风险最高。

---

第三：大型任务先规划

不要直接：

“重构这个系统。”

先让AI说明：

准备怎么做。

影响范围。

风险在哪里。

如何验证。

---

第四：建立验证流程

AI修改越多。

越需要：

测试。

Diff检查。

人工Review。

不要让一次大修改直接进入生产。

---

八、项目Context复杂度低：Plus通常够用

如果你的工作主要是：

个人项目。

小型应用。

局部功能开发。

Bug修复。

简单优化。

那么AI主要解决：

执行效率。

你的核心需求：

是更快完成任务。

这种情况下：

Plus通常已经可以满足。

因为你的瓶颈不是：

AI理解不了系统。

---

九、项目Context复杂度高：Pro才开始匹配

另一类用户：

每天面对：

大型Repository。

复杂业务系统。

多个服务。

长期维护。

大量历史约束。

你的问题已经不是：

“AI能不能写代码。”

而是：

“AI能不能持续参与复杂工程。”

如果：

你已经优化了项目规则。

任务边界。

验证流程。

但仍然需要AI长期处理复杂系统级任务。

那么更高强度的使用方式才开始体现价值。

---

最后：AI Coding真正的竞争，不只是生成能力，而是理解能力

未来代码生成会越来越容易。

真正拉开差距的是：

谁能让AI理解：

代码背后的系统。

规则背后的原因。

设计背后的历史。

业务背后的目标。

所以判断自己的AI阶段，可以问：

我的Codex问题，是因为AI不会写，还是因为AI还不了解这个系统？

如果只是：

写代码。

修小问题。

局部修改。

Plus通常够用。

如果每天需要AI参与：

复杂项目。

跨模块修改。

长期工程协作。

那么更高强度方案才更符合你的工作方式。

未来AI开发的核心，不只是：

让AI写更多代码。

而是：

让AI在真正理解系统以后，做出正确修改。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。