我不再让 Codex 一口气改完整个页面：前端需求这样拆，才真正可验收
上一篇解决的是“信息怎么分层”，这篇继续往下走：需求已经讲清楚之后，怎样把它拆成 Codex 可以逐步完成、我也能逐步验收的小任务？
很多人听到“拆任务”，第一反应是按文件拆：
先改页面文件。
再改接口文件。
然后改类型定义。
最后补样式。
这种拆法对安排修改顺序有帮助，但它有一个明显问题：每一步都只是完成了某个文件，不能证明某个用户行为已经可以工作。
页面文件改完了，查询不一定能用；接口文件改完了，参数不一定正确；样式写完了，窄屏下也不一定真的能操作。
我现在更倾向于按“可观察的行为变化”拆任务。每完成一小块，都能回答三个问题：用户得到了什么新能力？我用什么方式验证？如果出错，影响范围在哪里？
先明确：小任务不是把大任务切碎成代码清单
一个合格的小任务，至少应该具备四个特征：
只有一个主要结果：完成后能用一句话描述变化。
有清楚的输入和边界：知道会影响哪些行为，不会影响哪些行为。
能够独立验证：不必等整页全部改完，当前结果就能检查。
失败容易回退：方向不对时，不需要从一堆混合改动中找问题。
所以，“修改UserList.vue”不是一个结果，“状态筛选条件能够正确进入列表请求，并在重置后恢复默认值”才是。
前者描述代码位置，后者描述业务行为。
用一个后台列表需求演示怎样拆
下面仍然是一个演示场景，不代表我的真实项目：
在现有订单列表中增加订单状态和下单时间筛选，完善重置行为，增加导出入口，同时不能破坏现有分页和权限逻辑。
如果把它整个交给 AI，它可能一次修改页面、接口、类型和样式。最后我们面对的是一大块差异：筛选、分页、导出和权限只要有一项不对，就要在所有改动里找原因。
我会先把它拆成下面几个阶段。
任务 0：只理解现状，不改代码
目标：画出当前列表的数据流，找到查询条件、分页、权限和接口分别由哪里负责。
要求 Codex 输出：
相关文件和各自职责。
从点击查询到数据渲染的调用路径。
重置和翻页时状态如何变化。
导出能力是否已有相近实现。
最容易被本次修改影响的位置。
验收方式：我能根据这份说明指出“筛选条件应该在哪里增加”“分页状态由谁维护”“权限逻辑不能在哪里绕开”。
这一阶段很容易被嫌慢，但如果连现状都没看清，后面的拆分只是在猜。
Codex 官方给出的代码库理解用例也强调，修改前应先梳理模块职责、数据流、校验位置、隐藏依赖和需要执行的检查。对我来说，这不是额外步骤，而是后续任务边界的来源。
任务 1：只建立筛选状态，不连接请求
目标：页面能够正确维护订单状态和时间范围，并按照项目现有方式完成展示、清空和默认值处理。
暂时不做：
不改接口参数。
不实现导出。
不调整分页。
验收方式：打开页面、修改筛选项、点击重置，观察页面状态是否符合约定；类型检查没有新增错误。
有人可能觉得这一步太小，但它把“表单状态问题”和“请求参数问题”分开了。后面如果查询不对，我可以先确认页面状态是否正确，不用同时怀疑所有环节。
任务 2：把筛选条件接入查询闭环
目标：点击查询后，筛选条件按照接口约定转换为请求参数；查询行为与现有分页规则保持一致。
需要明确：
点击查询是否回到第一页。
空条件是否发送。
时间范围如何转换。
请求失败后筛选条件是否保留。
验收方式：检查请求参数，并分别验证有条件查询、空条件查询和请求失败三条路径。
完成这一步时，用户已经真正获得了一个可使用的新能力。即使导出还没做，筛选功能也可以独立判断对错。
任务 3：单独修正重置与分页状态
目标：重置筛选、切换页码、修改每页数量时，页面状态与请求参数保持一致。
这部分看起来属于任务 2，但我通常会在状态比较复杂时单独拆出来。因为查询能用，不代表连续操作一定正确。
验收路径可以写成：
设置筛选条件并查询。
切换到第二页。
点击重置。
确认筛选条件清空、页码回到第一页、请求参数恢复默认。
再次改变每页数量，确认页码和列表数据同步更新。
前端页面很多问题，只有按顺序操作才会出现。把验收路径写出来，比一句“保证分页正常”可靠得多。
任务 4：把导出当成独立业务流程
目标：在保留现有权限判断的前提下，使用当前筛选条件发起导出，并正确处理等待、成功和失败状态。
为什么导出不应该顺手塞进查询任务？因为它通常有不同的请求方式、等待时间、返回结果和错误处理。有些项目是直接下载文件，有些项目会先创建任务再轮询结果。
在没有看清现有实现之前，AI 很容易按照自己熟悉的方式补一个下载逻辑。
验收方式至少包括：
有权限时显示入口，无权限时行为符合项目约定。
导出参数与当前筛选条件一致。
导出期间不能重复触发。
成功、失败或取消后，按钮状态能够恢复。
任务 5：最后做联合回归，不再新增功能
目标：把筛选、重置、分页、权限和导出连起来验证，清理无关改动。
这一阶段不应该继续“顺手优化”。它只做三件事：
查看完整代码差异，确认没有越界修改。
运行项目已有的检查。
按用户操作路径做页面回归。
如果此时发现新的重构机会，我会记录成后续任务，而不是继续扩大当前差异。
好的拆分顺序，应该让风险逐步暴露
上面的拆分不是唯一答案，但顺序有一个基本逻辑：
理解现状 → 建立局部状态 → 接入单一行为 → 补齐连续状态 → 增加独立流程 → 联合回归
每一步都以前一步的已验证结果为基础。
如果任务 1 的筛选状态就不对，不需要等导出做完再返工；如果任务 2 的请求参数不对，也不会把问题误判成分页组件故障。
这就是小步修改真正节省时间的地方：不是每一步写得更快，而是错误更早出现、更容易定位。
我不会按文件拆，而会按“行为切片”拆
可以用下面这张表快速区分：
| 不够有效的拆法 | 更容易验收的拆法 |
|---|---|
| 修改页面文件 | 筛选状态能够正确设置和重置 |
| 修改接口文件 | 查询参数与页面条件一致 |
| 修改分页组件 | 查询、翻页和重置时页码规则一致 |
| 增加导出方法 | 导出完整覆盖等待、成功和失败路径 |
| 调整样式 | 在约定宽度下按钮可见、内容不遮挡 |
文件仍然要列，但它应该是影响范围，不应该是任务目标。
每个小任务都要带一张“验收卡”
我会要求每个任务至少写清下面六项：
## 小任务目标 - 本次只产生什么行为变化： ## 前置条件 - 已确认的项目现状： - 依赖哪个已完成任务： ## 修改范围 - 允许修改： - 禁止修改： ## 本次不做 - 明确排除的功能和优化： ## 验收步骤 1. 2. 3. ## 完成证据 - 修改文件及原因： - 已运行的检查： - 页面验证结果： - 未验证项和剩余风险：
“完成证据”很重要。它能把“我认为写完了”变成“这些检查已经通过，那些部分仍然未知”。
拆到多小才合适？看验证成本，不看代码行数
任务不是越小越好。
如果一个改动只有三行，却必须等另一个改动完成后才能观察结果，硬拆成两个任务只会增加沟通成本。反过来，一个改动即使涉及多个文件，只要共同完成同一个行为，而且能一次独立验收，也可以保留在一个任务里。
我通常用下面几个信号判断是否还要继续拆：
同一个任务里出现两个以上彼此独立的用户结果。
不同部分需要不同的验证方式。
某一部分失败时，其他部分仍然可以成立。
任务同时包含功能新增和大范围重构。
无法用三到五步描述完整验收路径。
满足其中两三项，我就会认真考虑继续拆分。
最后保留一个“停下来”的节点
我现在不喜欢让 AI 拿到计划后无条件一路执行到底。
在影响范围不清、现有实现与需求冲突、需要修改公共能力或无法运行关键检查时，应该停下来报告，而不是自行扩大假设。
这个暂停点不是降低效率。真正拖慢开发的，往往不是多确认一次，而是 AI 已经沿着错误方向改完十几个文件，我们才开始追第一处判断是怎么错的。
到这里，Day 2 的两篇文章就形成了一个完整链条：上一篇把长需求的信息分层，这一篇再把主任务拆成可验收的行为切片。
下一篇会进入 Day 3：提示词为什么不是越复杂越好。我要继续拆开“提示词”和“项目上下文”这两个经常被混用的概念，并给出前端任务真正值得提供的上下文清单。
本系列持续更新。后面会把这些方法逐步应用到 Vue3 列表、Element Plus 表单、页面调试和真实验收流程里。
参考资料
Codex 官方用例：修改前先理解代码库、数据流与风险点
Codex 官方用例：通过可评估结果持续迭代复杂任务