任务编排实战：从需求到依赖分析的完整链路
这篇解决什么问题
拿到一个模糊需求后，怎么一步步把它变成可编排、可并发的原子任务？核心就一件事：画对依赖图。
但依赖图不是凭空画的——它依赖于前面的拆解质量。这篇文章用博客项目的"点赞功能"走一遍完整链路：五步拆解法从头走到尾，重点展开 Step 4 的依赖图分析。每一步给出可复用的操作方法。
一、接到需求
需求通常就是这样来的——一句话，模糊，没有细节：
用户可以给文章点赞，再点一次取消，显示点赞数
接下来要做的事：把这句话翻译成 AI 能理解的结构化信息。用"找名词→找动词→找条件"三步，把模糊需求变成结构化清单：
找名词（数据实体）：
| 实体 | 说明 |
|---|---|
| 点赞关系 | 哪个用户对哪篇文章点了赞 |
| 文章点赞数 | 文章的累计点赞计数 |
找动词（用户操作）：
| 操作 | 交互 | 触发条件 |
|---|---|---|
| 点赞/取消 | 点击红心图标 | 已登录 |
找条件（业务规则）：
| 规则 | 前端 | 后端 |
|---|---|---|
| 必须登录 | 未登录点击 → 跳转登录页 | 接口需 Guard 鉴权 |
| 防重复 | 同一篇文章只有一个红心状态 | 联合唯一索引防重复记录 |
| 数据一致 | 乐观更新后用后端返回值校正 | 关系表和计数必须在同一事务中更新 |
| userId 来源 | 前端不传 userId | 从 Token 中获取，禁止前端传参 |
到这一步，一句话需求已经变成前后端都能理解的结构化清单。这是五步拆解法的输入。
二、Step 1：顶层业务域解耦
把大项目切成独立模块——这是三层分工中"领域拆分层"的落地，由人类决策。
不要一上来就让 AI 面对整个项目。先把项目按业务闭环维度切成独立、无强耦合的模块。以博客系统为例：
| 模块 | 核心职责 | 独立性 |
|---|---|---|
| 内容消费 | 首页列表、分类筛选、文章详情 | 可独立开发 |
| 搜索发现 | 关键词搜索、热门词 | UI 和逻辑独立 |
| 用户认证 | 注册、登录、Token 刷新、登出 | 完全独立的服务 |
| 互动功能 | 点赞切换、点赞状态校正 | 依赖文章和认证，但事务逻辑独立 |
为什么必须先切？AI 一次只能处理有限上下文。整个项目丢给它 → 上下文过载 → 逻辑混乱 → 输出不可控。切完后，AI 每次只聚焦一个模块，思维清晰，输出稳定。
点赞功能属于"互动功能"模块，依赖认证模块（获取当前用户）和文章模块（文章数据），点赞逻辑本身独立。
三、Step 2：三大前置锚定
模块开工前，锁死硬约束，消除 AI 幻觉——这是三层分工中"宏观编排层"的落地，由人类定义模块间的规则和依赖。
① 重要事项锚定（技术硬规范、不可修改的标准）：
- 点赞接口必须通过 RemoteJwtAuthGuard 获取 currentUserId，禁止前端传 userId
- ArticleLikes 和 Articles.likes 必须在同一事务中更新
- 前端 Token 使用 HttpOnly Cookie，禁止 localStorage 存储
② 影响面分析锚定（上下游依赖、数据流转规则）：
- Token 刷新涉及前端 axios 拦截器 → backend 代理转发 → auth-service 校验 → Redis 存储，整条链路必须提前理清
- 多请求并发 401 时，只刷新一次，其他请求排队等待
- 刷新失败需跳转登录页，并携带 redirect 参数
③ 边界规则锚定（触发条件、禁止触碰的边界）：
- 未登录用户点击点赞 → 跳转登录页，不调用接口
- 数据库字段下划线（cover_url），DTO 字段驼峰（coverUrl），禁止混用
- password_hash 绝不出现在任何 DTO 中
三大锚定完成后，输出一份清单文档，AI 每次执行任务前都必须读取。这就是它的"行为边界"。
四、Step 3：模块内线性流程拆解
模块内部按开发流水线拆成线性递进的子阶段——这是三层分工中"微观执行层"的入口，AI 主导，人 Review。
| 阶段 | 做什么 | 谁主导 |
|---|---|---|
| 准备 | 梳理接口入参/出参、枚举映射、事务规则 | 人 |
| 静态 | 组件 UI 绘制、样式实现 | AI 主导 |
| 动态 | 接口对接、状态判断、事件处理 | AI 执行，人审核 |
| 适配 | 跨页面集成、跨模块数据传递 | AI 执行，人审核 |
| 兜底 | 复杂边界场景、体验细节打磨 | 人 |
关键原则：先静态后动态，先基础后复杂，先 AI 执行后人工兜底。
以点赞功能为例：
- 阶段 1（准备）：梳理 POST /article/toggle-like 的请求/响应结构 + 事务规则
- 阶段 2（静态）：LikeButton 组件 UI 绘制（红心图标 + 计数显示）
- 阶段 3（动态）：对接接口，乐观更新 UI，后端返回后校正
- 阶段 4（适配）：首页/详情页集成，请求 user-likes 校正点赞状态
- 阶段 5（兜底）：未登录跳转、文章不存在提示、网络异常兜底
五、Step 4：原子任务颗粒度 + 依赖图分析
这是整套方法论中最关键的一步——把流程阶段拆成 AI 可直接执行的原子任务，然后画依赖图确定执行顺序。
5.1 拆出原子任务
交给 AI 的每个任务，必须满足三个条件：单目标 + 明确输入 + 可校验的验收标准。
点赞功能
├── 原子任务 1：ArticleLikes Prisma Model + 联合唯一索引
├── 原子任务 2：ToggleLikeRequestDto / ToggleLikeResponseDto
├── 原子任务 3：ArticleService.toggleLike（事务：关系增删 + 计数更新）
├── 原子任务 4：ArticleController.toggleLike（Guard + 参数校验）
├── 原子任务 5：前端 LikeButton 组件 UI 绘制
└── 原子任务 6：前端接口定义 DTO 及页面调用接口
对比一下错误拆法和正确拆法：
| ❌ 错误 | ✅ 正确 |
|---|---|
| 实现点赞功能 | 新增 ArticleLikes Model + 联合唯一索引，迁移成功即可 |
| 处理 Token 过期 | 实现 axios 401 拦截器：接口返回 401 且非刷新请求时，调用 /auth/refresh，成功重试原请求，失败跳转 /login?redirect=当前地址 |
| 做点赞接口 | 实现 ArticleService.toggleLike：查询→增删→计数更新，$transaction 保证原子性 |
禁止开放式需求。如果你自己都写不出验收标准，AI 更不可能做对。
5.2 画依赖图
方法很简单：逐个任务问"这个任务要读谁的产出？"
| 任务 | 我要读谁的产出 | 谁要读我的产出 |
|---|---|---|
| 任务 1：Model | 无 | 任务 2、3 |
| 任务 2：DTO | 任务 1（Model 字段结构） | 任务 3、4、6 |
| 任务 3：Service | 任务 1、2 | 任务 4 |
| 任务 4：Controller | 任务 2、3 | 无 |
| 任务 5：前端组件 UI 绘制 | 无 | 任务 6 |
| 任务 6：前端接口定义 DTO 及页面调用接口 | 任务 2、5 | 无 |
5.3 依赖的三种类型
| 依赖类型 | 含义 | 点赞案例 |
|---|---|---|
| 数据依赖 | 下游要读上游产出的数据结构 | 任务 2 要读任务 1 的 Model 字段才能定义 DTO |
| 调用依赖 | 下游要调用上游的函数/接口 | 任务 4 要调用任务 3 的 Service |
| 逻辑依赖 | 下游的业务逻辑依赖上游的决策 | 任务 6 要按 DTO 定义来定义前端接口类型 |
注意：依赖不等于顺序。任务 3 和任务 5 都没有互相依赖——它们可以并发。任务 1 和任务 5 也没有任何依赖——它们也可以并发。
5.4 依赖的两个方向
- 上游依赖：我必须等谁先完成 → 决定我能不能开始
- 下游影响：谁在等我完成 → 决定我完成后谁会被解锁
上游依赖为空的任务，可以立即启动。任务 1 和任务 5 都没有上游依赖，所以它们可以同时开始。
5.5 标记并发可行性
| 任务 | 上游依赖 | 可并发 | 执行策略 |
|---|---|---|---|
| 任务 1：Model | 无 | ✅ 可并发 | 独立启动 |
| 任务 2：DTO | 1 | ❌ 等 1 | 跟任务 1 串行 |
| 任务 3：Service | 1、2 | ❌ 等 1、2 | 跟任务 2 串行 |
| 任务 4：Controller | 2、3 | ❌ 等 2、3 | 跟任务 3 串行 |
| 任务 5：前端组件 UI 绘制 | 无 | ✅ 可并发 | 与任务 1 同时启动 |
| 任务 6：前端接口定义 DTO 及页面调用接口 | 2、5 | 🟡 DTO 完成后即可 | 等任务 2 + 任务 5 完成后执行 |
5.6 从依赖图推出执行顺序
依赖图画完，执行顺序是自然推出来的，不是拍脑袋定的。两条规则：
规则 1：无依赖的任务可以并发
规则 2：有依赖的任务必须串行
后端链路 Model → DTO → Service → Controller 是一条依赖链，顺序推进。
关键并发点有两个：
- 启动时并发：任务 1（Model）和任务 5（前端 UI 绘制）无依赖，两个窗口同时开工
- DTO 分叉点并发：任务 2（DTO）完成后，窗口 A 继续推进 Service → Controller，窗口 B 开始任务 6（前端接口定义）——DTO 就是前后端的契约，契约一定，前端就能按契约定义接口并接入页面
后端链路：任务 1 → 任务 2 → 任务 3 → 任务 4
↓ DTO 完成
前端链路：任务 5 → 任务 6（等 DTO + 任务 5）
时间线：
窗口 A: [1 Model] → [2 DTO] → [3 Service] → [4 Controller]
窗口 B: [5 UI 绘制] → ↑ DTO 完成 → [6 接口定义 + 页面调用]
任务 2（DTO）是并发分叉点：DTO 之后前后端同时推进。
六、逐条生成提示词：四要素
把原子任务翻译成 AI 可直接执行的提示词，每个提示词包含四要素：目标 + 需求功能 + 完成标准 + 约束。
原子任务 1：ArticleLikes Model + 索引
| 要素 | 内容 |
|---|---|
| 目标 | 新增点赞关系的数据库模型 |
| 需求功能 | 新增 ArticleLikes 模型（id, article_id, user_id, created_at），联合唯一索引 @@unique([article_id, user_id])，Articles 模型添加 likes 字段 |
| 完成标准 | npx prisma migrate dev 迁移成功，无类型错误 |
| 约束 | Model 用 PascalCase，数据库字段用下划线命名 |
原子任务 2：DTO
| 要素 | 内容 |
|---|---|
| 目标 | 创建点赞接口的请求/响应数据结构 |
| 需求功能 | ToggleLikeRequestDto（articleId + 校验装饰器），ToggleLikeResponseDto（articleId, likes, isLiked），统一导出 |
| 完成标准 | DTO 类型完整，校验装饰器齐全，tsc 编译无错误 |
| 约束 | 禁止 any，可选字段加 @IsOptional，数字字段加 @Type |
原子任务 3：Service 事务
| 要素 | 内容 |
|---|---|
| 目标 | 实现点赞/取消的核心业务逻辑 |
| 需求功能 | 查询 ArticleLikes 是否存在记录，已点赞→删除+计数减1，未点赞→创建+计数加1 |
| 完成标准 | 点赞/取消都走通，关系表和计数始终一致 |
| 约束 | 必须在 Prisma $transaction 中执行，保证原子性 |
原子任务 4：Controller
| 要素 | 内容 |
|---|---|
| 目标 | 新增点赞/取消点赞的 API 端点 |
| 需求功能 | POST toggle-like 端点，UseGuards(RemoteJwtAuthGuard)，从请求获取 currentUserId，参数用 ToggleLikeRequestDto |
| 完成标准 | 路由可访问，Guard 鉴权生效，Swagger 文档正确显示 |
| 约束 | Controller 不写业务逻辑；userId 从 Guard 获取，禁止前端传参 |
原子任务 5：前端 LikeButton 组件 UI 绘制
| 要素 | 内容 |
|---|---|
| 目标 | 绘制点赞交互组件的 UI 部分 |
| 需求功能 | LikeButton 组件 UI 绘制（红心图标、点赞数展示、点击动效），Props 预留 isLiked, likes, articleId, onToggle |
| 完成标准 | 组件渲染正常，点击动效流畅，Props 类型显式定义 |
| 约束 | 使用 useObserver 包裹渲染；Props 类型必须显式定义；暂不接入接口调用，只做 UI |
原子任务 6：前端接口定义 DTO 及页面调用接口
| 要素 | 内容 |
|---|---|
| 目标 | 定义前端接口类型并接入页面调用 |
| 需求功能 | 按后端 DTO 定义前端 ToggleLikeRequest/Response 类型，实现 api.article.toggleLike 调用，在 LikeButton 中接入接口调用（乐观更新 + 后端校正） |
| 完成标准 | 接口类型与后端 DTO 一致，乐观更新流畅，后端返回后状态校正正确 |
| 约束 | 接口类型必须与后端 DTO 严格对齐；禁止组件内直接使用 axios；未登录点击跳转登录页 |
四要素的作用
| 要素 | 作用 |
|---|---|
| 目标 | 让 AI 知道"做这个任务是为了什么" |
| 需求功能 | 告诉 AI"具体做什么" |
| 完成标准 | 让 AI 知道"做到什么程度算完成" |
| 约束 | 划清"不能做什么" |
四要素齐全，AI 执行基本一次到位；缺任何一个，AI 就要猜，猜就是翻车的开始。
七、Step 5：测试验证闭环 + 执行节奏
执行节奏
按依赖图推导的执行顺序，逐条给 AI 执行，结合原子化开发的 /clear 策略：
- 任务 1-4（后端链路 Model→DTO→Service→Controller）→ 上下文关联，AI 正常 → 不 clear，连续推进
- 任务 5-6（前端链路 UI 绘制→接口定义）→ 上下文关联，AI 正常 → 不 clear，连续推进
- 任务 5 可与任务 1 同时启动（不同窗口）
- 任务 6 等任务 2（DTO）+ 任务 5（UI）完成后执行
- 如果任何任务跑偏 → 立即 /clear，带四要素重新开始
/clear 的判断标准：上下文是否被污染，而不是任务是否完成。
逐任务验收清单
每个原子任务配套验证方案，做完即验，不等最后：
| 任务 | 验收点 |
|---|---|
| 1 | Schema 正确 + 迁移生成成功 |
| 2 | DTO 类型完整 + 校验装饰器齐全 + 导出正确 |
| 3 | 事务逻辑正确 + 点赞/取消都走通 + 计数一致 |
| 4 | 路由可访问 + Guard 生效 + 参数校验正常 |
| 5 | 组件渲染正常 + 动效流畅 + Props 类型正确 |
| 6 | 接口类型与 DTO 对齐 + 乐观更新流畅 + 后端返回校正 |
全部通过 → 提交代码。
八、编排模板：可复用的五步法
把这个案例抽象成通用模板，下次拿到任何一组原子任务都能直接套：
| 步骤 | 做什么 | 方法 |
|---|---|---|
| 1. 顶层解耦 | 把大项目切成独立模块 | 按业务闭环维度划分 |
| 2. 三大锚定 | 锁死硬约束 | 重要事项 + 影响面分析 + 边界规则 |
| 3. 模块内流程 | 按开发流水线拆阶段 | 准备→静态→动态→适配→兜底 |
| 4. 原子任务 + 依赖图 | 拆到 AI 可执行的颗粒度，画依赖图 | 单目标+明确输入+可校验标准；逐个问"我要读谁的产出" |
| 5. 验证闭环 | 每个任务配套验收方案 | 做完即验，不等最后 |
编排的本质：没有依赖的任务可以并发，有依赖的必须串行。前端 UI 绘制往往没有后端依赖，可以和后端链路同时启动；DTO 是最常见的并发分叉点——契约一定，前端接口定义和后端 Service/Controller 可以并行推进。
一句话收束
任务编排的核心不是"怎么执行"，而是画对依赖图。但依赖图的前提是任务已经被正确拆解——五步拆解法就是从需求到原子任务的完整链路。画依赖图的方法就一句话：逐个任务问"我要读谁的产出"，答案就是依赖关系。 从依赖关系到执行顺序，是自然推导，不是拍脑袋决定。
