上一篇解决的是“信息怎么分层”这篇继续往下走需求已经讲清楚之后怎样把它拆成 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 官方用例通过可评估结果持续迭代复杂任务