过去的软件开发中，需求不够清楚，程序员通常会在编码过程中逐渐发现问题。

接口定义不完整。
业务规则存在冲突。
异常场景没有说明。
验收标准无法量化。

开发速度相对较慢，很多问题会在讨论、编码和测试过程中暴露出来。

但当ChatGPT开始帮助分析需求，Codex可以快速读取项目、修改代码并运行测试，Pro开始支撑更长、更复杂的任务后，开发节奏发生了变化。

AI可能在几分钟内完成过去需要几小时甚至几天的代码修改。

这时，一个更加关键的问题出现了：

AI写代码越快，错误需求被实现的速度也越快。

真正限制AI开发效率的，正在从代码生成能力转向需求定义能力。

这背后对应的是软件开发中一直存在、却在AI时代变得更加重要的一项能力：需求工程。

一、AI可以快速实现，但不会自动判断目标是否正确

开发者向Codex提交一个任务：

优化用户查询接口，提高响应速度。

AI可以快速分析代码、修改查询方式、增加缓存并补充测试。

最终接口确实变快了。

但这并不能证明任务真正完成。

因为需求中可能还隐藏着其他限制：

• 返回数据不能减少；
• 权限校验不能被绕过；
• 缓存必须及时失效；
• 旧客户端仍需兼容；
• 查询结果必须保持实时；
• 不能增加新的基础设施成本。

如果这些条件没有明确写进任务，Codex只能根据当前代码和常见实践进行推断。

它可能高效完成了一个技术目标，却破坏了更重要的业务目标。

AI擅长回答：

怎样实现。

但开发者必须先确认：

究竟应该实现什么。

二、需求模糊时，模型越强，影响范围可能越大

面对模糊任务，普通代码补全工具可能只生成一个函数。

但具备工程执行能力的Codex，可能进一步：

• 读取多个模块；
• 调整接口结构；
• 修改共享组件；
• 增加新依赖；
• 重写测试；
• 更新配置；
• 清理它认为无用的代码。

执行能力越强，模糊需求产生的影响范围越大。

例如一句：

重构认证模块，让代码更简洁。

其中至少存在几个没有回答的问题：

• 重构的核心目标是什么；
• 是否允许改变接口；
• 是否保留历史兼容逻辑；
• 是否可以调整令牌格式；
• 是否允许修改数据库；
• 怎样证明重构以后更好；
• 哪些风险不可接受。

如果这些问题没有解决，所谓“让代码更简洁”只是一个主观方向。

AI可能删除重复代码。

也可能删除看似重复、实际承担兼容职责的逻辑。

所以，AI编程时代最危险的任务，不一定是复杂任务。

而是看起来简单、实际上没有被定义清楚的任务。

三、什么是AI需求工程

AI需求工程，不是把需求写得更长。

也不是在提示词中加入更多背景。

它的核心是把一个模糊目标，转化成AI能够理解、执行和验证的任务规格。

完整链路可以表示为：

业务问题
↓
用户目标
↓
功能需求
↓
非功能约束
↓
修改边界
↓
验收标准
↓
Codex工程执行
↓
结果验证

它至少需要回答五个问题：

1. 真正需要解决的问题是什么；
2. 哪些结果必须实现；
3. 哪些条件不能被破坏；
4. AI可以修改到什么范围；
5. 怎样证明任务已经完成。

需求工程不是AI执行之前的一段说明。

它决定了整个任务应该向哪个方向运行。

四、第一层：区分问题和解决方案

开发者经常直接把解决方案当成需求。

例如：

给接口增加Redis缓存。

这实际上不是需求，而是一个技术方案。

真正的问题可能是：

用户列表接口在高峰期响应超过三秒。

缓存只是可能的解决方式之一。

其他方式还可能包括：

• 优化数据库索引；
• 减少重复查询；
• 调整分页逻辑；
• 合并外部请求；
• 修复资源竞争；
• 降低序列化成本。

如果直接要求Codex增加缓存，AI会围绕缓存执行。

但缓存未必是最合适的方案，还可能引入一致性和失效问题。

更可靠的任务应该先说明问题，再允许ChatGPT和Codex分析方案。

当前接口在高峰期响应超过三秒，需要在不改变返回结构和数据实时性的前提下降低响应时间。先定位主要耗时，再提出修改方案。

问题定义正确，AI才有机会选择正确路径。

五、第二层：补充非功能需求

很多AI生成的代码能够实现功能，却难以进入真实系统。

原因是任务只描述了“能不能用”，没有描述“应该怎样运行”。

非功能需求通常包括：

• 性能；
• 安全；
• 稳定性；
• 可维护性；
• 兼容性；
• 可观测性；
• 可回退性。

例如实现文件上传功能，只说明“用户能够上传文件”远远不够。

还需要明确：

• 文件大小限制；
• 支持的格式；
• 权限要求；
• 超时处理；
• 恶意文件检测；
• 存储失败后的状态；
• 日志和审计要求。

功能需求决定系统做什么。

非功能需求决定系统是否能够长期可靠地做这件事。

六、第三层：把禁止项写进需求

很多开发者只告诉AI应该做什么，却没有说明不能做什么。

但在真实工程中，禁止项往往比目标更重要。

例如：

• 不修改数据库结构；
• 不改变公开接口；
• 不新增第三方依赖；
• 不删除兼容逻辑；
• 不扩大当前任务范围；
• 不触碰生产配置。

这些限制可以防止Codex为了完成局部目标，采用影响范围更大的方案。

AI不会天然知道项目中的所有底线。

如果某项约束非常重要，就不能依赖模型自行推断。

必须明确写入任务规格。

七、第四层：定义可验证的验收标准

“优化完成”“代码更好”“结构更清晰”都不是可靠的验收标准。

它们缺少可验证条件。

更有效的标准应该类似：

• 接口平均响应时间降低到指定范围；
• 原有测试全部通过；
• 新增异常场景测试；
• 公开接口保持不变；
• 不增加高风险依赖；
• 输出完整变更文件和风险说明。

没有验收标准，Codex只能根据自己的判断决定什么时候完成任务。

而AI认为“已经完成”，往往只代表它已经执行了计划中的动作。

不代表结果已经符合真实目标。

八、ChatGPT与Codex在需求工程中的分工

ChatGPT：需求澄清与规格设计

ChatGPT适合帮助开发者：

• 识别模糊表达；
• 发现相互冲突的要求；
• 补充遗漏场景；
• 区分问题和方案；
• 设计验收标准；
• 把自然语言整理成结构化任务。

它负责把“我想做什么”，转化成“系统应该满足什么”。

Codex：根据规格执行工程任务

Codex更适合：

• 读取项目结构；
• 定位相关模块；
• 根据明确边界修改代码；
• 运行测试；
• 检查变更影响；
• 输出执行结果。

需求越明确，Codex越不需要在执行过程中猜测。

猜测越少，工程结果越稳定。

九、Pro提高的是执行规模，不会自动补全真实需求

Pro可以支撑更长的分析、更复杂的项目和更持续的协作。

但更多上下文和更强推理，并不等于AI能够自动知道所有业务要求。

有些信息不存在于代码中：

• 团队当前的优先级；
• 项目的历史原因；
• 外部客户的兼容要求；
• 组织内部的风险偏好；
• 尚未写入文档的业务规则。

Pro可以帮助分析已提供的信息。

却不能保证补全从未提供的信息。

模型越强，越容易给出完整、合理的方案。

但方案看起来完整，不代表需求已经完整。

十、程序员正在从代码描述者转向目标设计者

AI降低了代码生成成本。

但它也提高了目标定义的重要性。

未来开发者需要更加擅长：

• 识别真正的问题；
• 区分需求和解决方案；
• 明确功能与非功能目标；
• 设置执行边界；
• 定义验收标准；
• 判断哪些信息仍然缺失。

过去，一个模糊需求可能造成几天返工。

未来，一个模糊需求可能在几分钟内生成大量错误代码、测试和文档。

执行速度越快，需求错误的代价越高。

结语

ChatGPT可以帮助澄清目标和整理任务规格。

Codex可以根据明确需求进入项目执行修改。

Pro可以支撑更长、更复杂的人机协作。

但AI编程真正的起点，不是代码生成。

而是把问题定义清楚。

需求正确，自动化才能放大效率。

需求错误，自动化只会更快地放大偏差。

未来程序员的重要能力，不只是告诉AI怎样写代码。

而是准确说明：

什么问题值得解决。
什么结果才算完成。
哪些边界不能突破。
哪些风险必须提前控制。

AI负责快速实现。

需求工程决定实现的究竟是不是正确的东西。