Back to Details

eng-agent-task-breakdown

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Agent Task Breakdown

Agent任务分解

Break architecture into executable tasks. Build them one at a time with AI agents.
将架构拆分为可执行任务，通过AI Agent逐一完成。

Phase 1: Task Decomposition

第一阶段：任务分解

Task Format

任务格式

markdown
undefined
markdown
undefined

Task [N]: [Title]

任务[N]：[标题]

Depends on: [Task numbers this requires, or "None"]
Outcome: [What exists when done - one sentence]
Why: [What this unblocks]
Acceptance: [How to verify - specific test, expected result]
Human action: [External setup needed, if any]
undefined
依赖： [所需的任务编号，或“无”]
成果： 完成后达成的目标（一句话描述）
原因： 该任务能解除哪些阻塞
验收标准： 如何验证任务完成（具体测试方法、预期结果）
人工操作： 所需的外部配置或操作（如有）
undefined

Sizing Rules

任务规模规则

Right size:
  • Changes ONE testable thing
  • 5-30 min agent implementation time
  • Failure cause is obvious and isolated
Split if:
  • Multiple independent things to test
  • Multiple files for different reasons
  • Acceptance has multiple unrelated conditions
合适的规模：
  • 仅修改一项可测试内容
  • Agent实现时长在5-30分钟之间
  • 失败原因清晰且独立
需拆分的情况：
  • 包含多个独立的可测试内容
  • 因不同原因需修改多个文件
  • 验收标准包含多个无关条件

Content Rules

内容规则

Outcomes, not implementation.
Bad: "Create users table with id, email, created_at using Prisma" Good: "Database stores user records with unique emails and timestamps"
Bad: "Install React Query and create useUser hook" Good: "User data fetches efficiently with caching"
The agent knows their tools. Define success, not steps.
Risk-first ordering.
Put uncertain/complex tasks early. Fail fast on hard problems. Don't save integrations and edge cases for the end.
Typical flow: setup > risky core logic > database > API > UI > integration
Dependencies explicit.
Every task lists what it needs. Enables parallel work and failure impact analysis.
聚焦成果，而非实现步骤。
错误示例："使用Prisma创建包含id、email、created_at的用户表" 正确示例："数据库可存储包含唯一邮箱和时间戳的用户记录"
错误示例："安装React Query并创建useUser钩子" 正确示例："用户数据可通过缓存高效获取"
Agent熟悉自身工具，只需定义成功目标，无需指定实现步骤。
风险优先排序。
将不确定/复杂的任务放在前面。尽早排查高难度问题的风险，不要将集成工作和边缘案例留到最后处理。
典型流程：环境搭建 > 高风险核心逻辑 > 数据库 > API > 界面 > 集成
明确依赖关系。
每个任务都需列出所需依赖，支持并行工作和失败影响分析。

Output Structure

输出结构

markdown
undefined
markdown
undefined

[Project] Tasks

[项目名称]任务列表

Prerequisites

前置条件

[External setup: accounts, keys, env vars]
[外部配置：账号、密钥、环境变量]

Tasks

任务列表

[Ordered task list with dependencies]
[带依赖关系的有序任务列表]

Out of Scope

范围外内容

[What's NOT in this MVP]
undefined
[本MVP不包含的内容]
undefined

Validation Checklist

验证清单

Before starting execution, verify:
  • Every task has exactly ONE acceptance test
  • No task depends on something not yet defined
  • Risky/uncertain work is front-loaded
  • All external config is in Prerequisites, not buried in tasks
  • A junior dev could verify each acceptance criteria
  • No task requires unstated knowledge to complete
开始执行前，需验证以下内容：
  • 每个任务都对应唯一的验收测试
  • 没有任务依赖未定义的内容
  • 高风险/不确定的工作已排在前面
  • 所有外部配置都已列在前置条件中，而非隐藏在任务里
  • 初级开发者可独立验证每个验收标准
  • 完成任务无需额外的未说明知识

Anti-Patterns

反模式

Too big: "Build the auth system" - This is 5+ tasks disguised as one.
Too small: "Create the Button component" then "Add onClick to Button" - Combine unless genuinely separate concerns.
Hidden dependency: Task 8 needs an API key not mentioned until Task 8. Put it in Prerequisites.
Vague acceptance: "User flow works correctly" - Works how? What's the test?
Implementation-as-outcome: "Use Redux for state management" - That's a how, not a what.
任务过大： "构建认证系统"——这其实是5个以上任务的集合，不应合并为一个。
任务过小： "创建Button组件"然后"为Button添加onClick事件"——除非是完全独立的关注点，否则应合并为一个任务。
隐藏依赖： 任务8需要一个API密钥，但直到任务8才提及——应将其放在前置条件中。
验收标准模糊： "用户流程运行正常"——具体如何正常？测试标准是什么？
将实现方式作为成果： "使用Redux进行状态管理"——这是实现手段，而非成果目标。

Phase 2: Task Execution

第二阶段：任务执行

Before Starting

开始执行前

  1. Read architecture doc fully
  2. Read task list fully
  3. Understand the end state before writing code
  4. If ANYTHING is ambiguous, ask. Don't assume.
  1. 完整阅读架构文档
  2. 完整阅读任务列表
  3. 在编写代码前明确最终目标
  4. 若有任何模糊不清的地方，务必询问，不要自行假设

Per-Task Protocol

单任务执行流程

  1. State which task you're starting
  2. Write minimum code to pass acceptance
  3. State exactly what to test and expected result
  4. STOP. Wait for confirmation.
  5. Pass → commit, announce next task
  6. Fail → fix the specific issue only, don't expand scope
  1. 说明即将开始的任务编号
  2. 编写满足验收标准的最简代码
  3. 明确说明测试内容及预期结果
  4. 停止操作，等待确认
  5. 测试通过→提交代码，宣布下一个任务
  6. 测试失败→仅修复具体问题，不要扩大范围

Coding Rules

编码规则

DO:
- Write absolute minimum code required
- Focus only on current task
- Keep code modular and testable
- Preserve existing functionality

DO NOT:
- Make sweeping changes
- Touch unrelated code
- Refactor unless task requires it
- Add features not in current task
- Optimize prematurely
- Assume - ask instead

WHEN HUMAN ACTION NEEDED:
- State exactly what to do
- State which file/value to update
- Wait for confirmation before continuing
需遵循：
- 编写满足要求的最简代码
- 仅专注于当前任务
- 保持代码模块化、可测试
- 保留现有功能

禁止：
- 进行大范围修改
- 触碰无关代码
- 除非任务要求，否则不要重构
- 添加当前任务未包含的功能
- 过早优化
- 自行假设，有疑问就问

需人工操作时：
- 明确说明需要执行的操作
- 说明需更新的文件/值
- 等待确认后再继续

When Stuck

遇到阻塞时

  1. State what's blocking
  2. Propose smallest modification to unblock
  3. Wait for approval
Never silently skip acceptance criteria. Never reinterpret the task.
  1. 说明阻塞点
  2. 提出最小化的修改方案以解除阻塞
  3. 等待批准
不要悄悄跳过验收标准，不要自行重新解读任务。

Scope Change Protocol

范围变更流程

If you discover a missing requirement:
  1. STOP current task
  2. State what's missing and why it's needed
  3. Propose where it fits in task order
  4. Wait for PM to update task list
  5. Resume only after task list is updated
Don't improvise new requirements into existing tasks.
如果发现遗漏的需求：
  1. 立即停止当前任务
  2. 说明遗漏的内容及其必要性
  3. 提出该任务在任务列表中的合适位置
  4. 等待项目经理更新任务列表
  5. 仅在任务列表更新后再继续执行
不要在现有任务中自行添加新需求。

PM Feedback Format

项目经理反馈格式

When reporting test results:
Task [N]: PASS | FAIL | BLOCKED

[If FAIL]: What broke, error message, steps to reproduce
[If BLOCKED]: What's preventing test
Keep it tight. Agent needs signal, not narrative.
报告测试结果时：
任务[N]：通过 | 失败 | 阻塞

[若失败]：问题内容、错误信息、复现步骤
[若阻塞]：阻碍测试的原因
反馈需简洁。Agent需要明确的指示，而非冗长描述。

Example

示例

markdown
undefined
markdown
undefined

Todo App Tasks

待办事项应用任务列表

Prerequisites

前置条件

  • Supabase project with URL + anon key in .env.local
  • Resend API key in .env.local
  • 已创建Supabase项目，且.env.local文件中配置了URL和匿名密钥
  • .env.local文件中配置了Resend API密钥

Tasks

任务列表

Task 1: Scaffold

任务1：项目初始化

Depends on: None Outcome: Next.js app runs with Supabase client configured Why: Foundation for all features Acceptance: 
npm run dev
shows page, console logs "Supabase connected"
依赖： 无 成果： 配置好Supabase客户端的Next.js应用可正常运行 原因： 为所有功能提供基础环境 验收标准： 执行
npm run dev
后页面正常显示，控制台输出"Supabase connected"

Task 2: Signup

任务2：用户注册

Depends on: 1 Outcome: Users create accounts via email/password Why: Unblocks all authenticated features Acceptance: Submit signup form → user appears in Supabase Auth → confirmation email sent
依赖： 1 成果： 用户可通过邮箱/密码创建账号 原因： 解除所有认证相关功能的阻塞 验收标准： 提交注册表单→用户出现在Supabase Auth中→发送确认邮件

Task 3: Login + Protected Routes

任务3：登录与受保护路由

Depends on: 2 Outcome: Users log in and access protected pages Why: Unblocks task management UI Acceptance: Login → redirect to /dashboard. Visit /dashboard logged out → redirect to /login
依赖： 2 成果： 用户可登录并访问受保护页面 原因： 解除任务管理界面的阻塞 验收标准： 登录后重定向至/dashboard；未登录时访问/dashboard会重定向至/login

Task 4: Tasks Table + RLS

任务4：任务表与RLS

Depends on: 1 Outcome: Database stores tasks per user Why: Unblocks task CRUD Acceptance: Insert task via Supabase dashboard with user_id, title, due_date, completed. Query as different user returns empty.
依赖： 1 成果： 数据库可按用户存储任务 原因： 解除任务增删改查功能的阻塞 验收标准： 通过Supabase仪表板插入包含user_id、title、due_date、completed字段的任务；以其他用户身份查询时返回空结果

Task 5: Create Task

任务5：创建任务

Depends on: 3, 4 Outcome: Users create tasks from UI Why: Core feature Acceptance: Submit form → task in DB → appears in list without refresh
依赖： 3, 4 成果： 用户可通过界面创建任务 原因： 核心功能实现 验收标准： 提交表单→任务存入数据库→无需刷新即可在列表中显示

Out of Scope

范围外内容

  • Social auth
  • Task sharing
  • Mobile app
undefined
  • 社交账号登录
  • 任务分享
  • 移动端应用
undefined