AI Coding 不是直接丢需求：我为什么先拆任务包
大家好，我是 Eleven，8 年 Java 后端开发工程师，正在系统学习 Python 大模型开发与 AI Coding 工程化。
最近我在用 Codex 推进个人项目 ContextPilot，也会持续记录 AI Coding 工程化、多会话协作、上下文治理、API 契约和工程初始化这些真实实践。
这篇文章想聊一个很具体的问题：
一个真实需求来了，能不能直接丢给 AI，让它把前后端都写出来？
我的答案是：最好不要。
更多关于 Java 后端转向 AI 应用开发、Python 大模型开发和 AI Coding 工程化的学习笔记，我会同步整理在公众号：转行AI的Java工程师。
前两篇文章，我分别写了：
- 怎么用 3 个 Codex 会话跑通一个最小 Todo Demo；
- 长期 AI Coding 项目里，怎么做上下文治理。
这篇继续往前走一步：
当需求开始变大，怎么把它拆成前端、后端、联调都能执行的任务包？
这不是一个“提示词更长一点”的问题。
在长期项目里，如果你直接把大需求丢给 AI，它可能会一次写太多、读太多、补太多。
最后你会发现：
- 它提前实现了未来批次；
- 前端和后端各自理解了一套接口；
- 当前阶段该做什么、不该做什么变模糊；
- 一个会话里混进产品、接口、页面、联调、风险、部署；
- AI 说“完成了”，但你很难判断它到底完成了哪一部分。
所以我现在更倾向于：
先拆任务包，再让 AI 写代码。
不是发明新流程，而是把真实开发流程搬进 AI Coding
正常开发团队不会拿到一个大需求后立刻全员开写。
一般会先做：
产品需求
-> API 契约 / 接口文档
-> 前端任务 / 后端任务 / 联调任务
-> 开发
-> 联调验收
我在 ContextPilot 里做的事情，本质上也是这个逻辑：
产品需求文档
-> API 契约
-> 任务工作台拆任务包
-> 前端会话 / 后端会话并行开发
-> 联调清单
-> 总控台收口
区别只是执行者变了。
以前是产品、前端、后端、测试、技术负责人协作。
现在是总控台、任务工作台、前端会话、后端会话、联调验收会话协作。
这不是为了制造流程。
恰恰相反，AI Coding 里很多失控，就是因为人把真实开发流程省掉了。
为什么不能直接把大需求丢给 AI？
大需求对 AI 来说，往往不是一个清晰任务，而是一团混在一起的上下文。
里面可能同时有：
- 产品目标；
- 页面结构；
- API 字段；
- 前端状态；
- 后端模型；
- 权限规则；
- 联调顺序；
- 暂时不能做的后续能力。
一次性丢进去，容易出现三类问题。
1. 多读
当前只需要做第二批任务，它可能把第三批、第四批、第五批也读进来。
读得越多，不一定越准确。
很多时候，是越容易把未来任务当成当前任务。
2. 多写
你只是让它做当前页面，它可能顺手把后续功能入口也加上。
你只是让它接一个接口，它可能顺手改了状态流转。
看起来勤快，但后续验收会变复杂。
3. 自己补空白
产品需求和 API 契约没有写清楚的地方，它可能按自己的理解补上。
在 Demo 里这可能没关系。
但在长期项目里很危险。
因为前端补一套理解，后端补一套理解，最后联调就对不上。
所以我的规则是：
大需求不是不能交给 AI，而是不能不拆就交给 AI。
我加了一个“任务工作台”
既然正常开发里需要拆任务，在 AI Coding 里，我也给这个动作单独开了一个角色。
我把它叫做：
任务工作台。
任务工作台不是写代码的人。
它也不是产品负责人。
它的职责是：
在产品需求和 API 契约已经确认后，把当前版本需求拆成前端、后端、联调验收可以执行的任务包。
边界必须写清楚。
任务工作台不负责：
- 重新定义产品需求；
- 修改 API 契约；
- 写前端业务代码；
- 写后端业务代码；
- 替代总控台做最终验收；
- 把未来批次任务提前塞给当前开发会话。
我给它的任务大概是：
请把已确认的 V0.1 产品需求和 API 契约，
拆成前端、后端、联调验收可执行任务包。
你不负责重新定义需求，不修改接口文档，不写业务代码。
输出目录：
docs/tasks/v0.1/
README.md
current.md
backend/
frontend/
integration/
每个任务包必须包含：
1. 任务目标
2. 必读文件
3. 输入事实
4. 明确不做
5. 涉及范围
6. 依赖关系
7. 可并行事项
8. 不可并行 / 必须回总控确认事项
9. 实现要求
10. 验收标准
11. 建议验证命令或检查方式
12. 接力输出格式
13. 发现冲突时的暂停规则
14. 已废弃或不可继续引用的旧口径
这里最重要的不是“任务工作台”这个名字。
而是把它的输入、输出、禁止事项和验收边界写清楚。
任务包目录怎么设计？
ContextPilot V0.1 的任务包目录是这样设计的：
docs/tasks/v0.1/
README.md
current.md
backend/
01-foundation-and-data-model.md
02-material-analysis-and-deepseek.md
03-generation-task-and-result-package.md
04-feedback-and-admin.md
05-contract-tests-and-handoff.md
frontend/
01-routing-layout-and-api-adapter.md
02-workspace-generator-analysis.md
03-progress-result-history.md
04-feedback-and-admin.md
05-visual-regression-and-handoff.md
integration/
01-frontend-backend-joint-checklist.md
02-v0.1-acceptance-checklist.md
这里不是为了好看。
每一层都有明确作用。
README.md 是任务分配总览，说明输入事实、并行策略、暂停规则和验收标准。
current.md 是当前执行入口，控制不同会话到底应该读哪些文件。
backend/ 放后端分批任务包。
frontend/ 放前端分批任务包。
integration/ 放联调和验收清单。
current.md 解决了什么？
任务包一多，很快会出现一个新问题：
每个开发会话到底该读哪些文件？
如果前端会话一次性读取全部 V0.1 任务，它可能提前看到第三批、第四批、第五批。
如果后端会话一次性读取所有任务，它可能把联调验收、未来风险、后续功能都混进当前实现。
所以我用了 current.md。
它的作用很简单：
告诉每个开发会话：现在执行到哪一批，应该读哪些文件，哪些未来任务暂时不要读。
比如联调阶段建议读取：
1. docs/tasks/v0.1/current.md
2. docs/tasks/v0.1/README.md
3. docs/tasks/v0.1/integration/01-frontend-backend-joint-checklist.md
4. docs/tasks/v0.1/integration/02-v0.1-acceptance-checklist.md
5. docs/api/README.md
6. docs/api/api-contract-v0.1.md
7. docs/product/v0.1-iteration-requirements.md
8. 后端第五批接力包
9. 前端第五批接力包
而这些文件暂不默认读取：
docs/tasks/v0.1/backend/
docs/tasks/v0.1/frontend/
因为它们已经是完成的开发任务包。
联调会话应该优先读当前入口、联调清单、API 契约和前后端接力包。
只有定位具体问题时，再回读对应批次任务包。
这就是我现在理解的并行开发：
并行不是让每个 AI 都读全部资料，而是让不同会话读取各自当前批次的最小上下文。
单个会话完成，不代表整批完成
多会话协作里，一个很容易误判的点是：
某个会话说完成了，不等于整批任务完成。
比如：
- 后端完成，不代表前端完成；
- 前端 mock 页面跑通，不代表真实联调通过；
- 某个接口写完，不代表完整用户流程通过；
- 代码审核通过，不代表用户人工验收通过。
ContextPilot 当前 V0.1 已经完成多批开发和代码审核，但还没有进入用户人工验收。
这就需要在 current.md 里写清楚：
第五批仍不代表真实前后端联调完成，
也不代表用户人工验收通过。
这个口径很重要。
因为 AI 很容易在总结里把局部完成写成整体完成。
任务包的价值之一，就是把“完成范围”写清楚。
风险不一定立刻阻塞，但必须登记
任务拆分里还有一个很真实的问题：
风险到底是当前阻塞项，还是后续必须收口的待办？
以 DeepSeek API Key 管控为例。
这个问题重要吗？
当然重要。
但在第二批开发阶段，它没有被当成开发阻塞项。
当时口径是：
- 后端可以先按配置文件配置项接入 DeepSeek；
- DeepSeek API Key 管控暂不作为第二批开发阻塞项；
- 密钥治理、提交前脱敏、部署前安全检查作为后续风险待办统一收口；
- 开发和验收输出中不要明文展开真实 Key。
注意，这不是生产安全建议。
也不是说密钥治理不重要。
它只是一个阶段判断：
当前为了推进功能链路，先把 Key 管控作为风险待办登记下来，但提交前、部署前和正式开放前必须收口。
AI Coding 项目里不能一遇到风险就全部停掉。
但也不能让风险消失在聊天记录里。
更稳的做法是：
判断它是当前阻塞项，还是后续发布前必须收口的风险项。
一个任务包应该包含什么？
我现在要求每个任务包固定包含 14 个章节：
1. 任务目标
2. 必读文件
3. 输入事实
4. 明确不做
5. 涉及范围
6. 依赖关系
7. 可并行事项
8. 不可并行 / 必须主会话收口事项
9. 实现要求
10. 验收标准
11. 建议验证命令或检查方式
12. 接力输出格式
13. 发现冲突时的暂停规则
14. 已废弃或不可继续引用的旧口径
这里面我最看重三个部分。
第一，明确不做。
它防止 AI 顺手扩大范围。
第二，不可并行 / 必须主会话收口事项。
它告诉 AI 哪些事情不能自己拍板。
第三，已废弃或不可继续引用的旧口径。
它防止 AI 从旧上下文里捞出已经过期的信息。
发布前可以用的检查清单
以后你把大需求交给 AI 前，可以先问自己：
1. 产品需求是否已经写清楚？
2. API 契约是否已经有共同口径？
3. 前端任务和后端任务是否拆开？
4. 哪些任务能并行，哪些必须串行？
5. 当前批次要读哪些文件？
6. 哪些未来任务不应该提前读？
7. 验收标准是什么？
8. 哪些风险要阻塞，哪些风险先登记？
9. 完成后由谁统一收口？
10. 旧口径是否已经清理？
如果这些问题都没想清楚，就直接让 AI 写代码，短期可能很爽。
但项目越往后，返工越多。
因为 AI 不只是执行代码。
它也会放大你的任务边界问题。
你没有拆清楚，它就可能替你乱拆。
你没有说哪些不做，它就可能替你多做。
你没有说当前批次，它就可能把未来批次提前做掉。
小结
这篇文章的核心不是“任务工作台”这个名字。
核心是：
不要把整个需求直接丢给 AI。先像真实开发一样，把需求拆成前端、后端、联调都看得懂的小任务。
我的当前结论：
- AI Coding 不是省掉开发流程；
- 大需求不能不拆就交给 AI；
- 任务包要写清楚输入事实和明确不做；
current.md要控制当前会话读取范围；- mock 通过不等于真实联调通过；
- 风险可以分级，但不能消失；
- 单个会话完成不等于整批完成。
AI 写代码很快。
但真正让长期项目稳定推进的，不是“写得快”。
而是每一步都知道：
- 当前做哪一批；
- 应该读哪些文件；
- 不该做哪些事情；
- 谁可以并行；
- 谁必须等确认；
- 完成以后由谁验收。
