Skip to Content

Draft-Final 模式

草稿先行,AI 完善方案,精准生成代码

使用占比

约 36% — 团队中使用最多的模式

模式概述

Draft-Final 模式是我们团队最推荐的复杂任务处理方式。核心流程:

  1. Draft(草稿) — 开发者编写粗糙的需求描述
  2. Final(方案) — AI 基于上下文检索、Rules、MCP 工具,完善成详细的技术方案
  3. Code(代码) — AI 按照 Final 方案生成代码

这种模式让开发者在生成代码前就拥有全局视野,可以调整方案后再生成代码。

流程图

适用场景

场景说明
需求→设计→实现完整的开发工作流
编码前更多控制审查方案后再生成代码
复杂功能开发大型功能的系统性实现
团队协作Draft 记录思路,Final 作为技术方案

为什么是最推荐的模式

对比 Document 模式

维度Document 模式Draft-Final 模式
方案来源开发者手写完整方案AI 基于 Draft 生成方案
适合场景方案清晰、技术熟悉方案不确定、领域不熟悉
AI 参与度仅实现代码参与方案设计 + 代码实现
学习价值较低高(可学习 AI 的方案设计)

Draft 的价值

为什么要保留 Draft?

Draft 记录了开发者的原始思路和需求理解,这对团队有重要价值:

  • 📚 新人可以学习前辈的需求分析思路
  • 🔄 方案变更时可以追溯原始需求
  • 👥 团队成员可以理解功能的来龙去脉

效率优势

在我们的实践中,使用 Draft-Final 模式:

  • 平均 3 次 request 即可完成一个复杂任务
  • 减少返工 — 在 Final 阶段发现问题,比代码阶段发现成本更低
  • 提高一致性 — Final 方案确保实现符合预期

完整示例

步骤 1:编写 draft.md

# 订单导出功能 ## 需求 用户希望能够导出订单列表为 Excel 文件 ## 初步想法 - 支持按时间范围筛选 - 支持选择导出字段 - 大量数据时需要异步处理 - 导出完成后邮件通知 ## 问题 - 不确定用什么库生成 Excel - 不确定异步任务怎么处理 - 需要考虑导出权限

步骤 2:生成 final.md

specs/001-order-export/draft.md
基于这个需求草稿,结合项目现有的技术栈和代码结构,
生成详细的技术方案,输出到 specs/001-order-export/final.md

AI 会自动检索项目上下文,生成类似这样的 final.md:

# 订单导出功能 - 技术方案 ## 技术选型 - Excel 生成:使用 exceljs(项目已有依赖) - 异步任务:使用现有的 Bull 队列 - 文件存储:复用现有的 S3 配置 ## 数据模型 ### ExportTask 表 ​```sql CREATE TABLE export_tasks ( id SERIAL PRIMARY KEY, user_id INTEGER REFERENCES users(id), status VARCHAR(20) DEFAULT 'pending', file_url TEXT, created_at TIMESTAMP DEFAULT NOW() ); ​``` ## API 设计 ### POST /api/orders/export 创建导出任务 **请求:** ​```json { "startDate": "2024-01-01", "endDate": "2024-01-31", "fields": ["orderId", "customerName", "amount"] } ​``` **响应:** ​```json { "taskId": "export_123", "status": "pending" } ​``` ### GET /api/orders/export/:taskId 查询导出任务状态 ## 实现步骤 1. 创建 ExportTask 数据模型 2. 实现导出任务创建接口 3. 实现 Bull 队列消费者 4. 实现 Excel 生成逻辑 5. 实现文件上传到 S3 6. 实现邮件通知 7. 实现前端导出按钮和进度显示 ## 权限控制 - 复用现有的 @middleware/auth.ts 认证中间件 - 添加 'order:export' 权限检查 ## 注意事项 - 单次导出最多 10000 条记录 - 文件保留 7 天后自动删除 - 失败任务自动重试 3 次

步骤 3:审查并调整 Final

在生成代码前,开发者可以:

  • 审查技术选型是否合理
  • 调整 API 设计
  • 补充遗漏的边界情况
  • 修改实现步骤的顺序

步骤 4:生成代码

specs/001-order-export/final.md
按照这个方案,先实现第 1-3 步:数据模型、API 接口和队列消费者

最佳实践

Draft 编写技巧

✅ 好的 Draft # 功能名称 ## 需求背景(为什么做) ## 核心功能(做什么) ## 初步想法(怎么做的思路) ## 不确定的点(需要 AI 补充) ❌ 不好的 Draft - 太简单:只有一句话 - 太详细:写成了完整方案(那就直接用 Document 模式)

Final 审查要点

  • 技术选型是否符合项目规范
  • API 设计是否符合 RESTful 规范
  • 数据模型是否合理
  • 实现步骤是否可执行
  • 边界情况是否考虑完整
  • 权限和安全是否处理

文件组织

specs/ ├── 001-order-export/ │ ├── draft.md # 原始需求草稿 │ ├── final.md # AI 完善的技术方案 │ └── api-spec.json # 可选:详细 API 规格 ├── 002-user-auth/ │ ├── draft.md │ └── final.md └── ...

常见问题

Q: Final 生成的方案不满意怎么办?

可以继续对话调整:

specs/001-order-export/final.md
这个方案中的异步任务处理改用 Redis 而不是 Bull,更新方案

Q: 什么时候用 Document 模式而不是 Draft-Final?

当你已经有清晰、完整的技术方案时,直接使用 Document 模式更高效。Draft-Final 模式的价值在于让 AI 帮你完善方案。

Q: Draft 需要多详细?

Draft 应该包含:

  • 需求的核心目标
  • 你的初步思路
  • 不确定的点

不需要包含完整的技术细节,那是 Final 的工作。

下一步

我们的 Draft-Final 工作流体现了规范驱动开发(SDD)的原则,而无需依赖外部框架。了解更多关于为什么不用 Spec 框架以及我们如何将这些原则适配到企业级场景中。

然后,让我们看看如何将所有模式整合到完整的工作流实践中。

最后更新于: