实践：添加新功能
本实践演示了为现有项目添加新功能的完整 SDD 工作流。我们将以"添加 Stripe 支付集成"作为示例。
前提条件
- SpecForge 已安装并配置（快速开始）
- 项目已初始化（
init_project已运行，你有projectId）
第 1 步 — 澄清需求
在编写任何内容之前，先发现模糊之处。
提示词：
使用 specforge 澄清为项目 proj_abc123 添加 Stripe 支付集成的需求预期结果： 5–10 个有针对性的问题，例如：
- 我们应该支持一次性支付、订阅，还是两者都支持？
- 需要支持哪些货币？
- 我们需要生成发票吗？
- 支付失败应如何处理 — 重试逻辑？通知？
- 退款政策是什么，谁可以发起退款？
在对话中回答这些问题。SpecForge 会将答案纳入规格中。
第 2 步 — 创建规格
提示词：
为项目 proj_abc123 中的 Stripe 支付集成创建规格。
需求：仅限一次性支付，支持美元和欧元，成功后发送邮件收据，
支付事件的 webhook，管理员退款功能。预期结果： 一个完整的 HU.md 保存在你的项目规格存储中，包含：
- 8–15 个涵盖正常路径、错误情况和边缘情况的验收标准
payments和payment_events表的数据库模式- 结账表单组件的 UI 契约
- 关于 Stripe API 调用幂等性密钥的架构决策提示
- 带实现步骤的
PLAN.md
SpecForge 会为该规格分配一个 ID，例如 SPEC-004。记下它。
第 3 步 — 审查和调整
阅读生成的规格，如有需要进行优化。
提示词：
总结项目 proj_abc123 中的规格 SPEC-004如果有什么缺失或错误：
提示词：
为项目 proj_abc123 中的 SPEC-004 添加一个标准：
"系统必须在发送到 Stripe 之前在客户端验证卡片详情，以减少失败的扣款"第 4 步 — 压力测试规格
提示词：
挑战项目 proj_abc123 中的规格 SPEC-004预期结果： SpecForge 会探查：
- 如果 Stripe webhook 在 API 响应之前到达会怎样？
- 如果用户在支付过程中刷新页面会怎样？（幂等性）
- 如果欧元汇率服务不可用会怎样？
- 并发：两个标签页同时完成支付
在继续之前解决发现的任何缺口。
第 5 步 — 检查就绪状态
提示词：
检查项目 proj_abc123 中的规格 SPEC-004 是否已准备好实现这将验证：
- 所有标准都是可测试且无歧义的
- 没有阻塞依赖（例如，SPEC-001 身份验证必须先完成）
- 章程合规性
如果通过，你会看到 DoR: PASSED。如果没有，修复被标记的问题。
第 6 步 — 估算工作量
提示词：
估算项目 proj_abc123 中的规格 SPEC-004预期结果：
工作量：8–13 故事点
时间：2–4 天（独立开发）/ 1–2 天（结对）
成本：$640–$1,040（按 $80/小时）
AI token 估算：约 45k token
风险因素：Stripe webhook 可靠性、幂等性复杂度第 7 步 — 安全检查
由于该规格涉及支付：
提示词：
对项目 proj_abc123 中的规格 SPEC-004 运行安全检查检查内容： OWASP Top 10 映射、PCI DSS 攻击面、webhook 签名验证、Stripe API 密钥处理。
第 8 步 — 生成执行计划
提示词：
为项目 proj_abc123 中的规格 SPEC-004 生成执行计划这会生成一个带有 RED/GREEN/VERIFY 步骤的 PLAN.md：
markdown
## 第 1 阶段：基础（可并行 1a、1b、1c）
- [ ] 1a：数据库迁移 — 创建 payments + payment_events 表
- [ ] 1b：定义 Stripe 载荷的 TypeScript 接口
- [ ] 1c：为 PaymentService 编写失败测试（RED）
## 第 2 阶段：核心实现
- [ ] 2a：实现 PaymentService.createCheckoutSession
- [ ] 2b：实现带签名验证的 webhook 处理器
- [ ] 2c：实现 AdminRefundService
## 第 3 阶段：前端
- [ ] 3a：使用 Stripe Elements 构建 CheckoutForm 组件
- [ ] 3b：实现支付状态轮询/webhook SSE
## 第 4 阶段：验证
- [ ] 4a：运行完整测试套件（GREEN + VERIFY）
- [ ] 4b：使用 Stripe 测试卡进行测试
- [ ] 4c：将规格 SPEC-004 状态更新为 review第 9 步 — 生成测试
提示词：
为项目 proj_abc123 中的规格 SPEC-004 生成测试这会生成映射到每个验收标准的测试框架 — 准备好填写或作为 TDD 的起始点。
第 10 步 — 将状态更新为进行中
提示词：
将项目 proj_abc123 中规格 SPEC-004 的状态更新为 in_progress第 11 步 — 实现
使用 PLAN.md 作为实现指南。你的 AI 代理将遵循 RED/GREEN/VERIFY 循环。规格充当契约 — 每个验收标准都必须满足。
第 12 步 — 验证实现
提示词：
根据 /Users/me/my-app/src 的代码验证项目 proj_abc123 中的规格 SPEC-004预期结果：
标准 1：支付创建 ✅ 已覆盖
标准 2：Webhook 处理 ✅ 已覆盖
标准 3：退款流程 ✅ 已覆盖
标准 4：邮件收据 ⚠️ 部分覆盖 — 缺少失败情况的测试
标准 5：货币验证 ✅ 已覆盖
覆盖率：90%（1 个标准需要关注）修复缺口，然后重新验证。
第 13 步 — 标记为完成
提示词：
将项目 proj_abc123 中的规格 SPEC-004 标记为完成SpecForge 在接受状态转换之前会验证 DoD 检查列表。一旦完成，规格就成为项目永久记录的一部分。
时间摘要
| 步骤 | 典型时间 |
|---|---|
| 澄清 + 创建 | 5–15 分钟 |
| 挑战 + 就绪检查 | 5 分钟 |
| 估算 + 安全检查 | 3 分钟 |
| 生成计划 + 测试 | 5 分钟 |
| 实现 | 因规格而异 |
| 验证 + 标记完成 | 5 分钟 |
SDD 的额外开销是 20–30 分钟。回报是一个可生产的规格、经过安全检查的设计，以及验证实现是否符合约定内容。