Plan 阶段：AI 辅助开发的起点，需求澄清与计划制定
2026/7/20大约 5 分钟
如何让 AI 真正理解你的需求？
Plan 阶段：需求澄清与计划制定
三份文档：项目规范、事实信息、开发需求 Spec
杜绝歧义，确保开发方向与用户预期完全对齐
来源：AI 辅助开发流程实践
问题背景
传统软件开发的需求澄清困境：
┌─────────────────────────────────────────────────────────┐
│ 传统软件开发的需求澄清困境 │
├─────────────────────────────────────────────────────────┤
│ │
│ 典型场景： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. 需求理解偏差 │ │
│ │ · 用户说「我要一个简单的登录功能」 │ │
│ │ · 开发理解成「用户名密码登录」 │ │
│ │ · 用户实际需要「支持微信、GitHub、手机号登录」 │ │
│ │ · 开发方向与用户预期不一致 │ │
│ │ │ │
│ │ 2. 需求细节不明确 │ │
│ │ · 用户说「要支持高并发」 │ │
│ │ · 开发不知道具体是「1000 QPS」还是「10000 QPS」 │ │
│ │ · 技术方案选择困难 │ │
│ │ · 开发过程中反复调整 │ │
│ │ │ │
│ │ 3. 约束条件不清晰 │ │
│ │ · 用户说「要快速上线」 │ │
│ │ · 开发不知道是「一周」还是「一个月」 │ │
│ │ · 资源分配不合理 │ │
│ │ · 进度不可控 │ │
│ │ │ │
│ │ 4. 优先级不明确 │ │
│ │ · 用户说「要做很多功能」 │ │
│ │ · 开发不知道先做哪个、后做哪个 │ │
│ │ · 开发顺序不合理 │ │
│ │ · 关键功能延期 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 传统解决方案的局限： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. 开发前会议 │ │
│ │ · 需要大量时间沟通 │ │
│ │ · 信息容易遗漏 │ │
│ │ · 没有结构化记录 │ │
│ │ · 后期难以追溯 │ │
│ │ │ │
│ │ 2. 需求文档 │ │
│ │ · 编写耗时 │ │
│ │ · 容易过时 │ │
│ │ · 与实际开发脱节 │ │
│ │ · AI 无法有效理解 │ │
│ │ │ │
│ │ 3. 反复沟通 │ │
│ │ · 效率低下 │ │
│ │ · 容易产生新的歧义 │ │
│ │ · 没有统一的事实依据 │ │
│ │ · 开发方向容易偏航 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘解决方案：Plan 阶段
需求澄清与计划制定
┌─────────────────────────────────────────────────────────┐
│ Plan 阶段 │
├─────────────────────────────────────────────────────────┤
│ │
│ 核心定位： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Plan 阶段是用户与 Agent 交互的起点 │ │
│ │ │ │
│ │ 核心目标： │ │
│ │ · 准确理解需求 │ │
│ │ · 制定可执行的开发计划 │ │
│ │ · 为后续 Coding 阶段输出标准化的输入文档 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 详细流程： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. 用户与 Agent 交互 │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ 用户提出初始需求 │ │ │
│ │ │ （例如：「我想做一个 XXX 功能」） │ │ │
│ │ │ │ │ │
│ │ │ Agent 通过多轮对话不断澄清需求细节： │ │ │
│ │ │ · 业务目标 │ │ │
│ │ │ · 使用场景 │ │ │
│ │ │ · 约束条件 │ │ │
│ │ │ · 优先级 │ │ │
│ │ │ · 技术方案 │ │ │
│ │ │ · 验收标准 │ │ │
│ │ │ │ │ │
│ │ │ 确保双方理解一致 │ │ │
│ │ │ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 2. Agent 的核心职责 │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ · 任务理解与拆解 │ │ │
│ │ │ · 制定开发计划 │ │ │
│ │ │ · 指派 Agent │ │ │
│ │ │ · 进度跟踪与协调 │ │ │
│ │ │ · 合并结果与验收 │ │ │
│ │ │ · 决策是否继续迭代 │ │ │
│ │ │ · 最终交付与收尾 │ │ │
│ │ │ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 阶段结束标志： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ · 三份文档（规范、事实、Spec）已完成并评审通过 │ │
│ │ · 用户或项目管理者确认计划无误 │ │
│ │ · 正式移交至 Coding 阶段 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘产出物：三份核心文档
为 Coding 阶段提供唯一事实依据
┌─────────────────────────────────────────────────────────┐
│ 产出物：三份核心文档 │
├─────────────────────────────────────────────────────────┤
│ │
│ Plan 阶段结束时会生成以下三份标准化文档， │
│ 作为 Coding 阶段的唯一事实依据： │
│ │
│ 第 1 份：项目规范 (Project Conventions) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 定义开发过程中的所有规范： │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ · 代码规范 │ │ │
│ │ │ - 命名规范 │ │ │
│ │ │ - 格式规范 │ │ │
│ │ │ - 注释规范 │ │ │
│ │ │ │ │ │
│ │ │ · 架构规范 │ │ │
│ │ │ - 分层原则 │ │ │
│ │ │ - 模块划分 │ │ │
│ │ │ - 依赖关系 │ │ │
│ │ │ │ │ │
│ │ │ · 目录结构规范 │ │ │
│ │ │ · 依赖管理规则 │ │ │
│ │ │ · 提交规范（Commit 格式） │ │ │
│ │ │ · 测试规范（单元、集成测试要求） │ │
│ │ │ · 文档规范 │ │ │
│ │ │ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 第 2 份：事实信息 (Ground Truth) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 定义项目的技术事实： │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ · 技术栈及版本号 │ │ │
│ │ │ - 语言版本（如 Python 3.11） │ │ │
│ │ │ - 框架版本（如 Django 5.0） │ │ │
│ │ │ - 数据库版本（如 PostgreSQL 16） │ │ │
│ │ │ - 中间件版本（如 Redis 7.0） │ │ │
│ │ │ │ │ │
│ │ │ · 接口文档 │ │ │
│ │ │ - 现有 API 定义 │ │ │
│ │ │ - 请求/响应格式 │ │ │
│ │ │ - 认证方式 │ │ │
│ │ │ │ │ │
│ │ │ · 数据结构 │ │ │
│ │ │ - 数据库表结构 │ │ │
│ │ │ - 消息格式 │ │ │
│ │ │ - 缓存键值 │ │ │
│ │ │ │ │ │
│ │ │ · 现有系统行为 │ │ │
│ │ │ - 已知功能 │ │ │
│ │ │ - 性能基线 │ │ │
│ │ │ │ │ │
│ │ │ · 历史数据 │ │ │
│ │ │ - 样本数据 │ │ │
│ │ │ - 迁移记录 │ │ │
│ │ │ │ │ │
│ │ │ · 业务规则和限制 │ │ │
│ │ │ - 权限规则 │ │ │
│ │ │ - 合规要求 │ │ │
│ │ │ - SLA 要求 │ │ │
│ │ │ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 第 3 份：开发需求 Spec (Specification) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 定义要开发的内容： │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ · 需求描述 │ │ │
│ │ │ - 业务背景 │ │ │
│ │ │ - 目标用户 │ │ │
│ │ │ │ │ │
│ │ │ · 用户故事（User Stories） │ │ │
│ │ │ - As a...I want to...So that... │ │ │
│ │ │ │ │ │
│ │ │ · 功能清单（Feature List） │ │ │
│ │ │ - 功能点列表 │ │ │
│ │ │ - 优先级排序 │ │ │
│ │ │ │ │ │
│ │ │ · 详细设计 │ │ │
│ │ │ - 模块职责 │ │ │
│ │ │ - 交互流程 │ │ │
│ │ │ │ │ │
│ │ │ · API 设计 │ │ │
│ │ │ - 新接口定义 │ │ │
│ │ │ - 请求/响应示例 │ │ │
│ │ │ │ │ │
│ │ │ · 验收标准 │ │ │
│ │ │ - 功能测试用例 │ │ │
│ │ │ - 性能指标 │ │ │
│ │ │ │ │ │
│ │ │ · 边界条件 │ │ │
│ │ │ - 异常处理 │ │ │
│ │ │ - 容错机制 │ │ │
│ │ │ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘核心思想
文档驱动 + 人工参与
┌─────────────────────────────────────────────────────────┐
│ 核心思想 │
├─────────────────────────────────────────────────────────┤
│ │
│ Plan 阶段的中心思想： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. 以澄清为起点 │ │
│ │ · 杜绝歧义 │ │
│ │ · 确保开发方向与用户预期完全对齐 │ │
│ │ │ │
│ │ 2. 全局决策层 │ │
│ │ · Plan 阶段不涉及具体编码 │ │
│ │ · 只负责规划、分配和验收 │ │
│ │ · 起到「指挥部」作用 │ │
│ │ │ │
│ │ 3. 文档驱动 │ │
│ │ · 所有后续开发依赖的标准、事实和需求 │ │
│ │ 都以结构化文档形式固化 │ │
│ │ · 保证信息一致性和可追溯性 │ │
│ │ │ │
│ │ 4. 人工参与 │ │
│ │ · 需求澄清环节保留人工介入 │ │
│ │ · 保证业务理解的准确性 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 这就是 Plan 阶段的核心价值： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 以澄清为起点，文档驱动，人工参与 │ │
│ │ 为 Coding 阶段提供唯一事实依据！ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘收尾金句
- 如何让 AI 真正理解你的需求？
- Plan 阶段：需求澄清与计划制定
- 三份文档：项目规范、事实信息、开发需求 Spec
- 杜绝歧义，确保开发方向与用户预期完全对齐
Plan 阶段：AI 辅助开发的起点，需求澄清与计划制定！
以澄清为起点，文档驱动，人工参与，为 Coding 阶段提供唯一事实依据！
"