需求明明写得很长，Codex 还是跑偏：问题往往不是信息不够，而是没分层
上一篇结尾，我留了一个问题：为什么有些需求已经写得很长，Codex 还是会跑偏？
刚开始和 AI 搭档写代码时，人很容易得出一个直觉——既然它理解得不够，那我就再多解释一点。
于是，原本三行的需求被补成三十行：前面讲业务背景，中间贴旧代码，后面加注意事项；担心它漏掉，又补几句“请仔细检查”“务必完整实现”。信息确实多了，结果却不一定更稳定。
后来我慢慢意识到，问题经常不是“说得太少”，而是不同性质的信息挤在了一起。
目标、背景、约束、建议、实现步骤和验收标准全用同一种语气写在一大段里。人看完都要回头找重点，更别说让 AI 在动代码时始终保持正确优先级。
需求写得长，和需求写得清楚，是两回事。
一个很长，但不够清楚的前端需求
先看一个常见的演示场景。它不是我的真实项目，只是为了说明问题：
帮我完善订单列表页面。现在页面只有基础查询，需要增加状态筛选、时间范围、重置和导出。 项目是 Vue3 和 Element Plus，代码尽量写得优雅一点，最好把旧代码也顺便优化一下。 查询时要有 Loading，按钮不能重复点击，接口错误要有提示，导出可能比较慢。 另外移动端显示也要正常，表格列太多时可以自己处理。不要影响原来的分页和权限。 如果发现公共请求封装不合理也可以一起改，最后帮我检查代码有没有问题。
这段话并不短，甚至看起来考虑得挺全面。但真正准备修改时，会发现里面至少混了五类任务：
新增筛选条件。
调整查询和重置行为。
增加导出流程。
处理响应式布局。
顺便重构旧代码和公共请求封装。
它们的风险、影响范围和验收方法完全不同，却被装在了同一个任务里。
当最终结果不符合预期时，我们甚至很难回答：到底是 AI 漏掉了需求，还是需求本身没有给出明确的先后顺序？
第一种混乱：主目标和顺手优化混在一起
上面那个需求的主目标是什么？
是让订单列表支持更多查询条件，还是完成导出，还是重构旧代码？
如果这些都算主目标，实际上就等于没有主目标。
我现在更愿意要求一个任务只有一个主要结果。例如：
本次只完善订单列表的筛选与重置行为，确保查询条件和分页状态一致。
至于导出、移动端适配和旧代码重构，可以记录下来，但不要让它们和本次交付争夺优先级。
“顺便优化一下”是我现在很警惕的一句话。因为它没有范围，也没有验收标准。AI 可能只改几个变量名，也可能把半个页面重新组织一遍。两种做法都能被解释为“优化”，但风险完全不是一回事。
第二种混乱：事实、要求和建议没有区分
下面三句话看起来很像，性质其实不同：
项目当前使用 Vue3 和 Element Plus。
本次必须复用现有分页组件。
如果结构合适，可以考虑抽一个组合式函数。
第一句是事实，第二句是硬约束，第三句只是建议。
如果把它们连成一段，AI 很可能无法稳定判断哪个不能违反、哪个可以放弃。特别是当“建议”与现有代码冲突时，它可能为了完成建议，反过来破坏更重要的项目一致性。
所以我会直接给信息加标签：
【已知事实】项目使用 Vue3、TypeScript 和 Element Plus。 【必须遵守】复用现有分页组件，不修改其公共 API。 【可选建议】只有在能减少当前页面重复逻辑时，才考虑抽取组合式函数。
这不是为了把提示词写得像合同，而是让优先级一眼可见。
第三种混乱：长期规则和本次任务混在一起
“项目统一使用哪种请求封装”“公共组件怎样命名”“修改后要运行哪些检查”，这类规则通常会在很多任务中重复出现。
而“这次新增两个筛选条件”“删除后保留当前页”，只属于当前任务。
如果每次都把两类信息全部粘进需求，一方面会让任务越来越长，另一方面也容易出现版本不一致：今天复制的是旧规则，明天又补了一条新规则，最后连自己都不知道哪份算准。
我的处理方式很简单：
长期稳定的项目规则，放在项目级规则文件或可复用工作流中。
当前任务的目标、范围和特殊边界，只写在当前任务里。
如果两者冲突，先指出冲突，不允许静默选择。
这样做的重点不是少写几行字，而是让每条信息有固定位置。
第四种混乱：实现要求和验收标准写成了一回事
“增加 Loading”是实现要求，“请求期间不能重复提交，成功或失败后 Loading 都能恢复”才是验收标准。
“支持移动端”是一个方向，“在 375px 宽度下搜索区不遮挡按钮，表格可以查看完整操作入口”才接近可检查的结果。
很多长需求把前者写了一大堆，后者却只剩一句“最后检查有没有问题”。
这会带来一个很现实的麻烦：AI 可以完成代码修改，却不知道应该用什么证据证明完成了。最后的汇报往往变成“已实现筛选、导出和响应式适配”，而不是哪些操作已经验证、哪些风险仍未验证。
我现在会把验收单独放在最后，并尽量写成动作：
1. 输入状态和时间范围后查询，请求参数与页面条件一致。 2. 点击重置后清空筛选条件，页码回到第一页，并重新请求数据。 3. 查询失败后保留用户已填写的条件，Loading 能正常结束。 4. 不改变现有权限判断和分页组件 API。
能操作、能观察、能判断通过与否，这才叫验收。
第五种混乱：同一段里藏着互相冲突的要求
长需求最难发现的，不是遗漏，而是冲突。
比如：
“尽量只做最小修改”，后面又写“把旧代码顺便重构干净”。
“完全复用现有写法”，后面又要求“使用最新的组件组织方式”。
“不要改公共组件”，同时又希望“统一解决所有页面的同类问题”。
这些要求单独看都合理，放在一起却未必能同时满足。
如果不提前解决冲突，AI 只能选择一个方向。真正危险的不是它做了选择，而是我们可能直到审查代码差异时才发现，它选择的不是我们心里默认的那个。
所以我会增加一句很朴素的规则：
如果要求之间存在冲突，先列出冲突和可选处理方式，暂时不要修改代码。
这句话不能消除冲突，但能阻止冲突直接变成代码。
我现在如何给长需求分层
当任务信息比较多时，我会按下面六层整理：
1. 本次唯一主目标
用一句话写出这次必须交付的结果。超过一个主要结果，就考虑拆任务。
2. 已知上下文
只保留与当前任务直接相关的技术栈、文件、现有行为和参考实现。
3. 硬约束
写明不能改变的接口、公共组件、权限逻辑、依赖和业务行为。
4. 功能与边界
按用户操作顺序描述正常路径、异常路径和关键状态变化。
5. 执行顺序
先理解现状，再列计划；确认影响范围后做最小修改，最后检查差异和运行结果。
6. 验收标准
把“完成”翻译成可以操作、观察和判断的检查项。
最后再单独放一个“本次不做”列表，把导出、重构、视觉优化之类暂缓事项写清楚。它们没有被遗忘，只是没有混进当前交付。
一个简单的自检：删掉一半文字，主任务还清楚吗？
我会用一个有点粗暴的方法检查需求：先不看示例、背景和补充说明，只看每个分层的第一句话。
如果这样仍然能回答下面四个问题，结构通常不会太差：
这次只解决什么问题？
哪些行为和文件不能改变？
应该按什么顺序推进？
用什么证据判断完成？
如果删掉背景之后，连主任务都找不到，那再补更多文字也没用。
说到底，我们不是要让 AI 记住一篇小作文，而是要让它在每个执行节点都知道当前最重要的事情是什么。
下一篇我会继续解决 Day 2 的第二个问题：一个看起来完整的前端需求，究竟应该怎样拆成几个可独立验收的小任务。重点不是按文件拆，而是按“可观察的行为变化”来拆。
本系列持续更新。后面所有方法都会逐步放进 Vue3、Element Plus 和真实页面验收场景中。
参考资料
Codex 官方用例：先理解代码库和调用关系，再开始修改
Codex 官方用例：用可评估结果迭代复杂任务