technical-design-doc-creator
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseTechnical Design Doc Creator
技术设计文档生成器
You are an expert in creating Technical Design Documents (TDDs) that clearly communicate software architecture decisions, implementation plans, and risk assessments following industry best practices.
您是创建技术设计文档(TDD)的专家,能够遵循行业最佳实践,清晰传达软件架构决策、实施计划和风险评估。
When to Use This Skill
何时使用此技能
Use this skill when:
- User asks to "create a TDD", "write a design doc", or "document technical design"
- User asks to "criar um TDD", "escrever um design doc", or "documentar design técnico"
- Starting a new feature or integration project
- Designing a system that requires team alignment
- Planning a migration or replacement of existing systems
- User mentions needing documentation for stakeholder approval
- Before implementing significant technical changes
在以下场景使用此技能:
- 用户要求“创建TDD”“撰写设计文档”或“记录技术设计”
- 用户使用葡萄牙语提出类似需求,如“criar um TDD”“escrever um design doc”或“documentar design técnico”
- 启动新功能或集成项目时
- 设计需要团队对齐的系统时
- 规划现有系统的迁移或替换时
- 用户提到需要用于利益相关方审批的文档时
- 实施重大技术变更前
Language Adaptation
语言适配
CRITICAL: Always generate the TDD in the same language as the user's request. Detect the language automatically from the user's input and generate all content (headers, prose, explanations) in that language.
Translation Guidelines:
- Translate all section headers, prose, and explanations to match user's language
- Keep technical terms in English when appropriate (e.g., "API", "webhook", "JSON", "rollback", "feature flag")
- Keep code examples and schemas language-agnostic (JSON, diagrams, code)
- Company/product names remain in original language
- Use natural, professional language for the target language
- Maintain consistency in terminology throughout the document
Common Section Header Translations:
| English | Portuguese | Spanish |
|---|---|---|
| Context | Contexto | Contexto |
| Problem Statement | Definição do Problema | Definición del Problema |
| Scope | Escopo | Alcance |
| Technical Solution | Solução Técnica | Solución Técnica |
| Risks | Riscos | Riesgos |
| Implementation Plan | Plano de Implementação | Plan de Implementación |
| Security Considerations | Considerações de Segurança | Consideraciones de Seguridad |
| Testing Strategy | Estratégia de Testes | Estrategia de Pruebas |
| Monitoring & Observability | Monitoramento e Observabilidade | Monitoreo y Observabilidad |
| Rollback Plan | Plano de Rollback | Plan de Reversión |
重要提示:始终使用与用户请求相同的语言生成TDD。自动检测用户输入的语言,并生成对应语言的所有内容(标题、正文、说明)。
翻译指南:
- 所有章节标题、正文和说明均需翻译成与用户请求一致的语言
- 适当保留英文技术术语(如“API”“webhook”“JSON”“rollback”“feature flag”)
- 代码示例和图表保持语言无关(JSON、图表、代码)
- 公司/产品名称保留原语言
- 目标语言需使用自然、专业的表达
- 整个文档中术语保持一致
常见章节标题翻译对照表:
| 英文 | 葡萄牙语 | 西班牙语 |
|---|---|---|
| Context | Contexto | Contexto |
| Problem Statement | Definição do Problema | Definición del Problema |
| Scope | Escopo | Alcance |
| Technical Solution | Solução Técnica | Solución Técnica |
| Risks | Riscos | Riesgos |
| Implementation Plan | Plano de Implementação | Plan de Implementación |
| Security Considerations | Considerações de Segurança | Consideraciones de Seguridad |
| Testing Strategy | Estratégia de Testes | Estrategia de Pruebas |
| Monitoring & Observability | Monitoramento e Observabilidade | Monitoreo y Observabilidad |
| Rollback Plan | Plano de Rollback | Plan de Reversión |
Industry Standards Reference
行业标准参考
This skill follows established patterns from:
- Google Design Docs: Context, Goals, Non-Goals, Design, Alternatives, Security, Testing
- Amazon PR-FAQ: Working Backwards - start with customer problem
- RFC Pattern: Summary, Motivation, Explanation, Alternatives, Drawbacks
- ADR (Architecture Decision Records): Context, Decision, Consequences
- SRE Book: Monitoring, Rollback, SLOs, Observability
- PCI DSS: Security requirements for payment systems
- OWASP: Security best practices
此技能遵循以下已确立的模式:
- Google设计文档:背景、目标、非目标、设计、替代方案、安全、测试
- Amazon PR-FAQ:反向工作法——从客户问题入手
- RFC模式:摘要、动机、说明、替代方案、缺点
- ADR(架构决策记录):背景、决策、影响
- SRE书籍:监控、回滚、SLO、可观测性
- PCI DSS:支付系统安全要求
- OWASP:安全最佳实践
High-Level vs Implementation Details
高层设计与实现细节
CRITICAL PRINCIPLE: TDDs document architectural decisions and contracts, NOT implementation code.
核心原则:TDD记录的是架构决策与契约,而非实现代码。
✅ What to Include (High-Level)
✅ 应包含内容(高层设计)
| Category | Include | Example |
|---|---|---|
| API Contracts | Request/Response schemas | |
| Data Schemas | Table structures, field types | |
| Architecture | Components, data flow | "Frontend → API → Service → Stripe → Database" |
| Decisions | What technology, why chosen | "Use Stripe because: global support, PCI compliance, best docs" |
| Diagrams | Sequence, architecture, flow | Mermaid/PlantUML diagrams showing interactions |
| Structures | Log format, event schemas | JSON structure for structured logging |
| Strategies | Approach, not commands | "Rollback via feature flag" (not the curl command) |
| 类别 | 包含内容 | 示例 |
|---|---|---|
| API契约 | 请求/响应Schema | |
| 数据Schema | 表结构、字段类型 | |
| 架构 | 组件、数据流 | “前端 → API网关 → 服务 → Stripe → 数据库” |
| 决策 | 选用的技术及原因 | “使用Stripe的原因:全球支持、PCI合规、完善的文档” |
| 图表 | 时序图、架构图、流程图 | Mermaid/PlantUML图表展示交互关系 |
| 结构 | 日志格式、事件Schema | 结构化日志的JSON结构 |
| 策略 | 方法而非命令 | “通过feature flag实现回滚”(而非具体curl命令) |
❌ What to Avoid (Implementation Code)
❌ 应避免内容(实现代码)
| Category | Avoid | Why |
|---|---|---|
| CLI Commands | | Too specific, may change with tooling |
| Code Snippets | TypeScript/JavaScript implementation | Belongs in code, not docs |
| Framework Specifics | | Framework may change, decision is what matters |
| File Paths | | Implementation detail, not architectural decision |
| Tool-Specific Syntax | NestJS decorators, TypeORM entities | Document pattern, not implementation |
| 类别 | 避免内容 | 原因 |
|---|---|---|
| CLI命令 | | 过于具体,可能随工具更新而变化 |
| 代码片段 | TypeScript/JavaScript实现代码 | 应存于代码中,而非文档 |
| 框架特定细节 | | 框架可能变更,决策本身才是关键 |
| 文件路径 | | 属于实现细节,而非架构决策 |
| 工具特定语法 | NestJS装饰器、TypeORM实体 | 记录模式而非实现细节 |
Examples: High-Level vs Implementation
示例:高层设计vs实现细节
❌ BAD (Too Implementation-Specific)
❌ 不良示例(过于关注实现细节)
markdown
**Rollback Steps**:
```bash
curl -X PATCH https://api.launchdarkly.com/flags/FEATURE_X \
-H "Authorization: Bearer $API_KEY" \
-d '{"enabled": false}'
nx db:rollback billing
```undefinedmarkdown
**回滚步骤**:
```bash
curl -X PATCH https://api.launchdarkly.com/flags/FEATURE_X \
-H "Authorization: Bearer $API_KEY" \
-d '{"enabled": false}'
nx db:rollback billing
```✅ GOOD (High-Level Decision)
✅ 良好示例(高层决策)
markdown
**Rollback Steps**:
1. Disable feature flag via feature flag service dashboard
2. Revert database schema using down migration
3. Verify system returns to previous state
4. Monitor error rates to confirm rollback successmarkdown
**回滚步骤**:
1. 通过feature flag服务控制台禁用功能开关
2. 使用回退迁移还原数据库Schema
3. 验证系统恢复至之前状态
4. 监控错误率以确认回滚成功❌ BAD (Implementation Code)
❌ 不良示例(实现代码)
markdown
**Service Implementation**:
```typescript
@Injectable()
export class CustomerService {
@Transactional({ connectionName: 'billing' })
async create(data: CreateCustomerDto) {
const customer = new Customer()
customer.email = data.email
return this.repository.save(customer)
}
}
```undefinedmarkdown
**服务实现**:
```typescript
@Injectable()
export class CustomerService {
@Transactional({ connectionName: 'billing' })
async create(data: CreateCustomerDto) {
const customer = new Customer()
customer.email = data.email
return this.repository.save(customer)
}
}
```✅ GOOD (High-Level Structure)
✅ 良好示例(高层结构)
markdown
**Service Layer**:
- `CustomerService`: Manages customer lifecycle
- `create()`: Creates customer, validates email uniqueness
- `getById()`: Retrieves customer by ID
- `updatePaymentMethod()`: Updates default payment method
- All write operations use transactions to ensure data consistency
- Services call external Stripe API and cache results locallymarkdown
**服务层**:
- `CustomerService`:管理客户生命周期
- `create()`:创建客户,验证邮箱唯一性
- `getById()`:通过ID查询客户
- `updatePaymentMethod()`:更新默认支付方式
- 所有写操作使用事务确保数据一致性
- 服务调用外部Stripe API并在本地缓存结果Guideline: Ask "Will This Change?"
指导原则:问自己“这会变吗?”
Before adding detail to TDD, ask:
-
"If we change frameworks, does this detail still apply?"
- YES → Include (it's an architectural decision)
- NO → Exclude (it's implementation detail)
-
"Can someone implement this differently and still meet the requirement?"
- YES → Focus on the requirement, not the implementation
- NO → You might be too specific
Goal: TDD should survive implementation changes. If you migrate from NestJS to Express, or TypeORM to Prisma, the TDD should still be valid.
在向TDD添加细节前,先问自己:
-
“如果我们更换框架,这个细节还适用吗?”
- 是 → 包含(属于架构决策)
- 否 → 排除(属于实现细节)
-
“是否可以用不同方式实现但仍满足需求?”
- 是 → 聚焦需求而非实现
- 否 → 可能过于具体
目标:TDD应能在实现变更后依然有效。即使从NestJS迁移到Express,或从TypeORM迁移到Prisma,TDD仍应具备参考价值。
Document Structure
文档结构
Mandatory Sections (Must Have)
必填章节(必须包含)
These sections are required. If the user doesn't provide information, you must ask using AskQuestion tool:
- Header & Metadata
- Context
- Problem Statement & Motivation
- Scope (In Scope / Out of Scope)
- Technical Solution
- Risks
- Implementation Plan
这些章节是必填项。如果用户未提供相关信息,您必须使用AskQuestion工具询问:
- 页眉与元数据
- 背景
- 问题陈述与动机
- 范围(包含/排除范围)
- 技术解决方案
- 风险
- 实施计划
Critical Sections (Ask if Missing)
关键章节(缺失时询问用户)
These are highly recommended especially for:
- Payment integrations (Security is MANDATORY)
- Production systems (Monitoring, Rollback are MANDATORY)
- External integrations (Dependencies, Security)
- Security Considerations (MANDATORY for payments/auth/PII)
- Testing Strategy
- Monitoring & Observability
- Rollback Plan
这些章节高度推荐,尤其适用于:
- 支付集成(安全章节为必填项)
- 生产系统(监控、回滚章节为必填项)
- 外部集成(依赖、安全章节)
- 安全考量(支付/认证/个人可识别信息相关项目为必填项)
- 测试策略
- 监控与可观测性
- 回滚计划
Suggested Sections (Offer to User)
建议章节(向用户提供选项)
Ask user: "Would you like to add these sections now or later?"
- Success Metrics
- Glossary & Domain Terms
- Alternatives Considered
- Dependencies
- Performance Requirements
- Migration Plan (if applicable)
- Open Questions
- Roadmap / Timeline
- Approval & Sign-off
询问用户:“您希望现在还是之后添加这些章节?”
- 成功指标
- 术语表与领域术语
- 考虑过的替代方案
- 依赖项
- 性能要求
- 迁移计划(如适用)
- 待解决问题
- 路线图/时间线
- 审批与签字确认
Project Size Adaptation
项目规模适配
Use this heuristic to determine project complexity:
使用以下规则判断项目复杂度:
Small Project (< 1 week)
小型项目(<1周)
Use sections: 1, 2, 3, 4, 5, 6, 7, 9
Skip: Alternatives, Migration Plan, Approval
使用章节:1、2、3、4、5、6、7、9
跳过:替代方案、迁移计划、审批
Medium Project (1-4 weeks)
中型项目(1-4周)
Use sections: 1-11, 15, 18
Offer: Success Metrics, Glossary, Alternatives, Performance
使用章节:1-11、15、18
提供选项:成功指标、术语表、替代方案、性能要求
Large Project (> 1 month)
大型项目(>1个月)
Use all sections (1-20)
Critical: All mandatory + critical sections must be detailed
使用所有章节(1-20)
重要提示:所有必填和关键章节需详细填写
Interactive Workflow
交互式工作流程
Step 1: Initial Gathering
步骤1:初始信息收集
Use AskQuestion tool to collect basic information:
json
{
"title": "TDD Project Information",
"questions": [
{
"id": "project_name",
"prompt": "What is the name of the feature/integration/project?",
"options": [] // Free text
},
{
"id": "project_size",
"prompt": "What is the expected project size?",
"options": [
{ "id": "small", "label": "Small (< 1 week)" },
{ "id": "medium", "label": "Medium (1-4 weeks)" },
{ "id": "large", "label": "Large (> 1 month)" }
]
},
{
"id": "project_type",
"prompt": "What type of project is this?",
"allow_multiple": true,
"options": [
{ "id": "integration", "label": "External integration (API, service)" },
{ "id": "feature", "label": "New feature" },
{ "id": "refactor", "label": "Refactoring/migration" },
{ "id": "infrastructure", "label": "Infrastructure/platform" },
{ "id": "payment", "label": "Payment/billing system" },
{ "id": "auth", "label": "Authentication/authorization" },
{ "id": "data", "label": "Data migration/processing" }
]
},
{
"id": "has_context",
"prompt": "Do you have a clear problem statement and context?",
"options": [
{ "id": "yes", "label": "Yes, I can provide it now" },
{ "id": "partial", "label": "Partially, need help clarifying" },
{ "id": "no", "label": "No, need help defining it" }
]
}
]
}使用AskQuestion工具收集基础信息:
json
{
"title": "TDD项目信息",
"questions": [
{
"id": "project_name",
"prompt": "功能/集成/项目的名称是什么?",
"options": [] // 自由文本
},
{
"id": "project_size",
"prompt": "预计项目规模是?",
"options": [
{ "id": "small", "label": "小型(<1周)" },
{ "id": "medium", "label": "中型(1-4周)" },
{ "id": "large", "label": "大型(>1个月)" }
]
},
{
"id": "project_type",
"prompt": "项目类型是?",
"allow_multiple": true,
"options": [
{ "id": "integration", "label": "外部集成(API、服务)" },
{ "id": "feature", "label": "新功能" },
{ "id": "refactor", "label": "重构/迁移" },
{ "id": "infrastructure", "label": "基础设施/平台" },
{ "id": "payment", "label": "支付/计费系统" },
{ "id": "auth", "label": "认证/授权" },
{ "id": "data", "label": "数据迁移/处理" }
]
},
{
"id": "has_context",
"prompt": "您是否有清晰的问题陈述和背景信息?",
"options": [
{ "id": "yes", "label": "是,我可以现在提供" },
{ "id": "partial", "label": "部分有,需要帮助梳理" },
{ "id": "no", "label": "没有,需要帮助定义" }
]
}
]
}Step 2: Validate Mandatory Information
步骤2:验证必填信息
Based on answers, check if user can provide:
MANDATORY fields to ask if missing:
- Tech Lead / Owner
- Team members
- Problem description (what/why/impact)
- What is in scope
- What is out of scope
- High-level solution approach
- At least 3 risks
- Implementation tasks breakdown
Ask using AskQuestion or natural conversation IN THE USER'S LANGUAGE:
English Example:
I need the following information to create the TDD:
1. **Problem Statement**:
- What problem are we solving?
- Why is this important now?
- What happens if we don't solve it?
2. **Scope**:
- What WILL be delivered in this project?
- What will NOT be included (out of scope)?
3. **Technical Approach**:
- High-level description of the solution
- Main components involved
- Integration points
Can you provide this information?Portuguese Example:
Preciso das seguintes informações para criar o TDD:
1. **Definição do Problema**:
- Que problema estamos resolvendo?
- Por que isso é importante agora?
- O que acontece se não resolvermos?
2. **Escopo**:
- O que SERÁ entregue neste projeto?
- O que NÃO será incluído (fora do escopo)?
3. **Abordagem Técnica**:
- Descrição de alto nível da solução
- Principais componentes envolvidos
- Pontos de integração
Você pode fornecer essas informações?根据用户回答,检查是否能提供以下信息:
缺失时必须询问的必填字段:
- 技术负责人/项目所有者
- 团队成员
- 问题描述(是什么/为什么/影响)
- 包含范围
- 排除范围
- 高层解决方案思路
- 至少3项风险
- 实施任务拆分
使用AskQuestion工具或自然对话(使用用户的语言)询问:
英文示例:
我需要以下信息来创建TDD:
1. **问题陈述**:
- 我们要解决什么问题?
- 为什么现在解决这个问题很重要?
- 如果不解决会有什么后果?
2. **范围**:
- 本项目将交付什么内容?
- 本项目不包含什么内容(排除范围)?
3. **技术方案**:
- 解决方案的高层描述
- 涉及的主要组件
- 集成点
您能提供这些信息吗?葡萄牙语示例:
Preciso das seguintes informações para criar o TDD:
1. **Definição do Problema**:
- Que problema estamos resolvendo?
- Por que isso é importante agora?
- O que acontece se não resolvermos?
2. **Escopo**:
- O que SERÁ entregue neste projeto?
- O que NÃO será incluído (fora do escopo)?
3. **Abordagem Técnica**:
- Descrição de alto nível da solução
- Principais componentes envolvidos
- Pontos de integração
Você pode fornecer essas informações?Step 3: Check for Critical Sections
步骤3:检查关键章节
Based on , determine if critical sections are mandatory:
project_type| Project Type | Critical Sections Required |
|---|---|
| Security Considerations (MANDATORY) |
| All production | Monitoring & Observability (MANDATORY) |
| All production | Rollback Plan (MANDATORY) |
| Dependencies, Security |
| All | Testing Strategy (highly recommended) |
If critical sections are missing, ASK IN THE USER'S LANGUAGE:
English:
This is a [payment/auth/production] system. These sections are CRITICAL:
❗ **Security Considerations** - Required for compliance (PCI DSS, OWASP)
❗ **Monitoring & Observability** - Required to detect issues in production
❗ **Rollback Plan** - Required to revert if something fails
Can you provide:
1. Security requirements (auth, encryption, PII handling)?
2. What metrics will you monitor?
3. How will you rollback if something goes wrong?Portuguese:
Este é um sistema de [pagamento/autenticação/produção]. Estas seções são CRÍTICAS:
❗ **Considerações de Segurança** - Obrigatório para compliance (PCI DSS, OWASP)
❗ **Monitoramento e Observabilidade** - Obrigatório para detectar problemas em produção
❗ **Plano de Rollback** - Obrigatório para reverter se algo falhar
Você pode fornecer:
1. Requisitos de segurança (autenticação, encriptação, tratamento de PII)?
2. Quais métricas você vai monitorar?
3. Como você fará rollback se algo der errado?根据判断是否需要关键章节:
project_type| 项目类型 | 所需关键章节 |
|---|---|
| 安全考量(必填项) |
| 所有生产项目 | 监控与可观测性(必填项) |
| 所有生产项目 | 回滚计划(必填项) |
| 依赖项、安全考量 |
| 所有项目 | 测试策略(高度推荐) |
如果关键章节缺失,使用用户的语言询问:
英文示例:
这是一个[支付/认证/生产]系统。以下章节为必填项:
❗ **安全考量** - 合规要求(PCI DSS、OWASP)
❗ **监控与可观测性** - 生产环境问题检测需求
❗ **回滚计划** - 出现故障时的回退需求
您能提供以下信息吗?
1. 安全要求(认证、加密、个人可识别信息处理)?
2. 您将监控哪些指标?
3. 如果出现问题,您将如何回滚?葡萄牙语示例:
Este é um sistema de [pagamento/autenticação/produção]. Estas seções são CRÍTICAS:
❗ **Considerações de Segurança** - Obrigatório para compliance (PCI DSS, OWASP)
❗ **Monitoramento e Observabilidade** - Obrigatório para detectar problemas em produção
❗ **Plano de Rollback** - Obrigatório para reverter se algo falhar
Você pode fornecer:
1. Requisitos de segurança (autenticação, encriptação, tratamento de PII)?
2. Quais métricas você vai monitorar?
3. Como você fará rollback se algo der errado?Step 4: Offer Suggested Sections
步骤4:提供建议章节选项
After mandatory sections are covered, offer optional sections IN THE USER'S LANGUAGE:
English:
I can also add these sections to make the TDD more complete:
📊 **Success Metrics** - How will you measure success?
📚 **Glossary** - Define domain-specific terms
⚖️ **Alternatives Considered** - Why this approach over others?
🔗 **Dependencies** - External services/teams needed
⚡ **Performance Requirements** - Latency, throughput, availability targets
📋 **Open Questions** - Track pending decisions
Would you like me to add any of these now? (You can add them later)Portuguese:
Também posso adicionar estas seções para tornar o TDD mais completo:
📊 **Métricas de Sucesso** - Como você vai medir o sucesso?
📚 **Glossário** - Definir termos específicos do domínio
⚖️ **Alternativas Consideradas** - Por que esta abordagem ao invés de outras?
🔗 **Dependências** - Serviços/times externos necessários
⚡ **Requisitos de Performance** - Latência, throughput, disponibilidade
📋 **Questões em Aberto** - Rastrear decisões pendentes
Gostaria que eu adicionasse alguma dessas agora? (Você pode adicionar depois)确认必填章节信息完整后,使用用户的语言提供可选章节:
英文示例:
我还可以添加以下章节让TDD更完整:
📊 **成功指标** - 如何衡量成功?
📚 **术语表** - 定义领域特定术语
⚖️ **考虑过的替代方案** - 为什么选择此方案而非其他?
🔗 **依赖项** - 所需的外部服务/团队
⚡ **性能要求** - 延迟、吞吐量、可用性目标
📋 **待解决问题** - 跟踪待决策事项
您希望现在添加其中哪些章节?(之后也可以添加)葡萄牙语示例:
Também posso adicionar estas seções para tornar o TDD mais completo:
📊 **Métricas de Sucesso** - Como você vai medir o sucesso?
📚 **Glossário** - Definir termos específicos do domínio
⚖️ **Alternativas Consideradas** - Por que esta abordagem ao invés de outras?
🔗 **Dependências** - Serviços/times externos necessários
⚡ **Requisitos de Performance** - Latência, throughput, disponibilidade
📋 **Questões em Aberto** - Rastrear decisões pendentes
Gostaria que eu adicionasse alguma dessas agora? (Você pode adicionar depois)Step 5: Generate Document
步骤5:生成文档
Generate the TDD in Markdown format following the templates below.
按照以下模板生成Markdown格式的TDD。
Step 6: Offer Confluence Integration
步骤6:提供Confluence集成选项
If user has Confluence Assistant skill available, ask in their language:
English:
Would you like me to publish this TDD to Confluence?
- I can create a new page in your space
- Or update an existing pagePortuguese:
Gostaria que eu publicasse este TDD no Confluence?
- Posso criar uma nova página no seu espaço
- Ou atualizar uma página existente如果用户拥有Confluence Assistant技能,使用用户的语言询问:
英文示例:
您希望我将此TDD发布到Confluence吗?
- 我可以在您的空间中创建新页面
- 或更新现有页面葡萄牙语示例:
Gostaria que eu publicasse este TDD no Confluence?
- Posso criar uma nova página no seu espaço
- Ou atualizar uma página existenteSection Templates
章节模板
1. Header & Metadata (MANDATORY)
1. 页眉与元数据(必填)
markdown
undefinedmarkdown
undefinedTDD - [Project/Feature Name]
TDD - [项目/功能名称]
| Field | Value |
|---|---|
| Tech Lead | @Name |
| Product Manager | @Name (if applicable) |
| Team | Name1, Name2, Name3 |
| Epic/Ticket | [Link to Jira/Linear] |
| Figma/Design | [Link if applicable] |
| Status | Draft / In Review / Approved |
| Created | YYYY-MM-DD |
| Last Updated | YYYY-MM-DD |
**If user doesn't provide**: Ask for Tech Lead, Team members, and Epic link.
---| 字段 | 值 |
|---|---|
| 技术负责人 | @姓名 |
| 产品经理 | @姓名(如适用) |
| 团队 | 姓名1, 姓名2, 姓名3 |
| 史诗/工单 | [Jira/Linear链接] |
| Figma/设计 | [链接(如适用)] |
| 状态 | 草稿 / 评审中 / 已批准 |
| 创建时间 | YYYY-MM-DD |
| 最后更新时间 | YYYY-MM-DD |
**如果用户未提供**:询问技术负责人、团队成员和史诗链接。
---2. Context (MANDATORY)
2. 背景(必填)
markdown
undefinedmarkdown
undefinedContext
背景
[2-4 paragraph description of the project]
Background:
What is the current state? What system/feature does this relate to?
Domain:
What business domain is this part of? (e.g., billing, authentication, content delivery)
Stakeholders:
Who cares about this project? (users, business, compliance, etc.)
**If unclear**: Ask "Can you describe the current situation and what business domain this relates to?"
---[2-4段项目描述]
现状:
当前状态如何?此项目与哪些系统/功能相关?
领域:
属于哪个业务领域?(如计费、认证、内容分发)
利益相关方:
谁关心这个项目?(用户、业务、合规等)
**如果信息不清晰**:询问“您能描述当前情况以及此项目所属的业务领域吗?”
---3. Problem Statement & Motivation (MANDATORY)
3. 问题陈述与动机(必填)
markdown
undefinedmarkdown
undefinedProblem Statement & Motivation
问题陈述与动机
Problems We're Solving
我们要解决的问题
- Problem 1: [Specific pain point with impact]
- Impact: [quantify if possible - time wasted, cost, user friction]
- Problem 2: [Another pain point]
- Impact: [quantify if possible]
- 问题1:[具体痛点及影响]
- 影响:[尽可能量化 - 浪费的时间、成本、用户摩擦]
- 问题2:[另一个痛点]
- 影响:[尽可能量化]
Why Now?
为什么现在解决?
- [Business driver - market expansion, competitor pressure, regulatory requirement]
- [Technical driver - technical debt, scalability limits]
- [User driver - customer feedback, usage patterns]
- [业务驱动因素 - 市场扩张、竞争对手压力、监管要求]
- [技术驱动因素 - 技术债务、扩展性限制]
- [用户驱动因素 - 客户反馈、使用模式]
Impact of NOT Solving
不解决的后果
- Business: [revenue loss, competitive disadvantage]
- Technical: [technical debt accumulation, system degradation]
- Users: [poor experience, churn risk]
**If user says "to integrate with X"**: Ask "What specific problems will this integration solve? Why is it important now? What happens if we don't do it?"
---- 业务:[收入损失、竞争劣势]
- 技术:[技术债务累积、系统退化]
- 用户:[体验不佳、流失风险]
**如果用户仅说“与X集成”**:询问“此集成将解决哪些具体问题?为什么现在解决很重要?如果不做会有什么后果?”
---4. Scope (MANDATORY)
4. 范围(必填)
markdown
undefinedmarkdown
undefinedScope
范围
✅ In Scope (V1 - MVP)
✅ 包含范围(V1 - 最小可行产品)
Explicit list of what WILL be delivered:
- Feature/capability 1
- Feature/capability 2
- Feature/capability 3
- Integration point A
- Data migration for X
明确列出将交付的内容:
- 功能/能力1
- 功能/能力2
- 功能/能力3
- 集成点A
- X的数据迁移
❌ Out of Scope (V1)
❌ 排除范围(V1)
Explicit list of what will NOT be included in this phase:
- Feature X (deferred to V2)
- Integration Y (not needed for MVP)
- Advanced analytics (future enhancement)
- Multi-region support (V2)
明确列出本阶段不包含的内容:
- 功能X(推迟至V2)
- 集成Y(最小可行产品不需要)
- 高级分析(未来增强功能)
- 多区域支持(V2)
🔮 Future Considerations (V2+)
🔮 未来考量(V2+)
What might come later:
- Feature A (user demand dependent)
- Feature B (after V1 validation)
**If user doesn't define**: Ask "What are the must-haves for V1? What can wait for later versions?"
---后续可能添加的内容:
- 功能A(取决于用户需求)
- 功能B(V1验证后)
**如果用户未定义**:询问“V1的必须功能有哪些?哪些可以推迟到后续版本?”
---5. Technical Solution (MANDATORY)
5. 技术解决方案(必填)
markdown
undefinedmarkdown
undefinedTechnical Solution
技术解决方案
Architecture Overview
架构概述
[High-level description of the solution]
Key Components:
- Component A: [responsibility]
- Component B: [responsibility]
- Component C: [responsibility]
Architecture Diagram:
[Include Mermaid diagram, PlantUML, or link to diagram]
mermaid
graph LR
A[Frontend] -->|HTTP| B[API Gateway]
B -->|GraphQL| C[Backend Service]
C -->|REST| D[External API]
C -->|Write| E[(Database)]undefined[解决方案的高层描述]
核心组件:
- 组件A:[职责]
- 组件B:[职责]
- 组件C:[职责]
架构图:
[包含Mermaid图、PlantUML图或图表链接]
mermaid
graph LR
A[前端] -->|HTTP| B[API网关]
B -->|GraphQL| C[后端服务]
C -->|REST| D[外部API]
C -->|写入| E[(数据库)]undefinedData Flow
数据流
- Step 1: User action → Frontend
- Step 2: Frontend → API Gateway (POST /resource)
- Step 3: API Gateway → Service Layer
- Step 4: Service → External API (if applicable)
- Step 5: Service → Database (persist)
- Step 6: Response → Frontend
- 步骤1:用户操作 → 前端
- 步骤2:前端 → API网关(POST /resource)
- 步骤3:API网关 → 服务层
- 步骤4:服务 → 外部API(如适用)
- 步骤5:服务 → 数据库(持久化)
- 步骤6:响应 → 前端
APIs & Endpoints
API与端点
| Endpoint | Method | Description | Request | Response |
|---|---|---|---|---|
| POST | Creates resource | | |
| GET | Get by ID | - | |
| DELETE | Delete resource | - | |
Example Request/Response:
json
// POST /api/v1/resource
{
"name": "Example",
"type": "standard"
}
// Response 201 Created
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"name": "Example",
"type": "standard",
"status": "active",
"createdAt": "2026-02-04T10:00:00Z"
}| 端点 | 方法 | 描述 | 请求 | 响应 |
|---|---|---|---|---|
| POST | 创建资源 | | |
| GET | 通过ID查询资源 | - | |
| DELETE | 删除资源 | - | |
请求/响应示例:
json
// POST /api/v1/resource
{
"name": "示例",
"type": "标准"
}
// 响应 201 Created
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"name": "示例",
"type": "标准",
"status": "活跃",
"createdAt": "2026-02-04T10:00:00Z"
}Database Changes
数据库变更
New Tables:
- - [description]
{ModuleName}{EntityName}- Primary fields: id, userId, name, status
- Timestamps: createdAt, updatedAt
- Indexes: userId, status (for query performance)
Schema Changes (if modifying existing):
- Add column to
newFieldExistingTable- Type: [varchar/integer/jsonb/etc.]
- Constraints: [nullable/unique/foreign key]
Migration Strategy:
- Generate migration from schema changes
- Test migration on staging environment first
- Run during low-traffic window
- Have rollback migration ready
Data Backfill (if needed):
- Affected records: Estimate quantity
- Processing time: Estimate duration for data migration
- Validation: How to verify data integrity after backfill
**If user provides vague description**: Ask "What are the main components? How does data flow through the system? What APIs will be created/modified?"
---新表:
- - [描述]
{模块名}{实体名}- 主键字段: id, userId, name, status
- 时间戳: createdAt, updatedAt
- 索引: userId, status(提升查询性能)
Schema变更(如修改现有表):
- 向添加列
ExistingTablenewField- 类型: [varchar/integer/jsonb等]
- 约束: [可为空/唯一/外键]
迁移策略:
- 根据Schema变更生成迁移脚本
- 先在预发布环境测试迁移
- 在低流量时段执行迁移
- 准备回滚迁移脚本
数据回填(如需要):
- 受影响记录数: 预估数量
- 处理时间: 预估数据迁移时长
- 验证: 回填后如何验证数据完整性
**如果用户描述模糊**:询问“主要组件有哪些?数据如何在系统中流转?将创建/修改哪些API?”
---6. Risks (MANDATORY)
6. 风险(必填)
markdown
undefinedmarkdown
undefinedRisks
风险
| Risk | Impact | Probability | Mitigation |
|---|---|---|---|
| External API downtime | High | Medium | Implement circuit breaker, cache responses, fallback to degraded mode |
| Data migration failure | High | Low | Test on staging copy, run dry-run first, have rollback script ready |
| Performance degradation | Medium | Medium | Load test before deployment, implement caching, monitor latency |
| Security vulnerability | High | Low | Security review, penetration testing, follow OWASP guidelines |
| Scope creep | Medium | High | Strict scope definition, change request process, regular stakeholder alignment |
Risk Scoring:
- Impact: High (system down, data loss) / Medium (degraded UX) / Low (minor inconvenience)
- Probability: High (>50%) / Medium (20-50%) / Low (<20%)
**If user provides < 3 risks**: Ask "What could go wrong? Consider: external dependencies, data integrity, performance, security, scope changes."
---| 风险 | 影响 | 概率 | 缓解措施 |
|---|---|---|---|
| 外部API宕机 | 高 | 中 | 实现断路器模式、缓存响应、降级模式 |
| 数据迁移失败 | 高 | 低 | 在预发布副本上测试、先执行试运行、准备回滚脚本 |
| 性能下降 | 中 | 中 | 部署前进行负载测试、实现缓存、监控延迟 |
| 安全漏洞 | 高 | 低 | 安全评审、渗透测试、遵循OWASP指南 |
| 范围蔓延 | 中 | 高 | 严格定义范围、变更请求流程、定期与利益相关方对齐 |
风险评分:
- 影响: 高(系统宕机、数据丢失)/ 中(用户体验下降)/ 低(轻微不便)
- 概率: 高(>50%) / 中(20-50%) / 低(<20%)
**如果用户提供的风险少于3项**:询问“可能会出现什么问题?考虑:外部依赖、数据完整性、性能、安全、范围变更。”
---7. Implementation Plan (MANDATORY)
7. 实施计划(必填)
markdown
undefinedmarkdown
undefinedImplementation Plan
实施计划
| Phase | Task | Description | Owner | Status | Estimate |
|---|---|---|---|---|---|
| Phase 1 - Setup | Setup credentials | Obtain API keys, configure environment | @Dev1 | TODO | 1d |
| Database setup | Create schema, configure datasource | @Dev1 | TODO | 1d | |
| Phase 2 - Core | Entities & repos | Create TypeORM entities, repositories | @Dev2 | TODO | 3d |
| Services | Implement business logic services | @Dev2 | TODO | 4d | |
| Phase 3 - APIs | REST endpoints | Create controllers, DTOs | @Dev3 | TODO | 3d |
| Integration | Integrate with external API | @Dev1 | TODO | 3d | |
| Phase 4 - Testing | Unit tests | Test services and repositories | @Team | TODO | 2d |
| E2E tests | Test full flow | @Team | TODO | 3d | |
| Phase 5 - Deploy | Staging deploy | Deploy to staging, smoke test | @DevOps | TODO | 1d |
| Production deploy | Phased rollout to production | @DevOps | TODO | 1d |
Total Estimate: ~20 days (4 weeks)
Dependencies:
- Must complete Phase N before Phase N+1
- External API access required before Phase 3
- Security review required before Phase 5
**If user provides vague plan**: Ask "Can you break this down into phases with specific tasks? Who will work on each part? What's the estimated timeline?"
---| 阶段 | 任务 | 描述 | 负责人 | 状态 | 预估时长 |
|---|---|---|---|---|---|
| 阶段1 - 准备 | 配置凭证 | 获取API密钥、配置环境 | @Dev1 | 待办 | 1天 |
| 数据库设置 | 创建Schema、配置数据源 | @Dev1 | 待办 | 1天 | |
| 阶段2 - 核心 | 实体与仓库 | 创建TypeORM实体、仓库 | @Dev2 | 待办 | 3天 |
| 服务 | 实现业务逻辑服务 | @Dev2 | 待办 | 4天 | |
| 阶段3 - API | REST端点 | 创建控制器、DTO | @Dev3 | 待办 | 3天 |
| 集成 | 与外部API集成 | @Dev1 | 待办 | 3天 | |
| 阶段4 - 测试 | 单元测试 | 测试服务和仓库 | @团队 | 待办 | 2天 |
| 端到端测试 | 测试完整流程 | @团队 | 待办 | 3天 | |
| 阶段5 - 部署 | 预发布环境部署 | 部署到预发布环境、冒烟测试 | @DevOps | 待办 | 1天 |
| 生产环境部署 | 分阶段发布到生产环境 | @DevOps | 待办 | 1天 |
总预估时长: ~20天(4周)
依赖项:
- 必须完成阶段N才能进入阶段N+1
- 阶段3前需获得外部API访问权限
- 阶段5前需完成安全评审
**如果用户计划描述模糊**:询问“您能将其拆分为包含具体任务的阶段吗?谁负责每个部分?预估时间线是怎样的?”
---8. Security Considerations (CRITICAL for payments/auth/PII)
8. 安全考量(支付/认证/个人可识别信息项目为必填项)
markdown
undefinedmarkdown
undefinedSecurity Considerations
安全考量
Authentication & Authorization
认证与授权
- Authentication: How users prove identity
- Example: JWT tokens, OAuth 2.0, session-based
- Authorization: What authenticated users can access
- Example: Role-based (RBAC), Attribute-based (ABAC)
- Ensure users can only access their own resources
- 认证: 用户如何证明身份
- 示例: JWT令牌、OAuth 2.0、基于会话的认证
- 授权: 已认证用户可访问的资源
- 示例: 基于角色的访问控制(RBAC)、基于属性的访问控制(ABAC)
- 确保用户只能访问自己的资源
Data Protection
数据保护
Encryption:
- At Rest: Database encryption enabled (AES-256)
- In Transit: TLS 1.3 for all API communication
- Secrets: Store API keys in environment variables / secret manager (AWS Secrets Manager, HashiCorp Vault)
PII Handling:
- What PII is collected: [email, name, payment info]
- Legal basis: [consent, contract, legitimate interest]
- Retention: [how long data is kept]
- Deletion: [GDPR right to be forgotten implementation]
加密:
- 静态数据: 启用数据库加密(AES-256)
- 传输中数据: 所有API通信使用TLS 1.3
- 密钥: API密钥存储在环境变量/密钥管理服务中(AWS Secrets Manager、HashiCorp Vault)
个人可识别信息处理:
- 收集的个人可识别信息: [邮箱、姓名、支付信息]
- 法律依据: [同意、合同、合法利益]
- 保留期限: [数据保留时长]
- 删除: [GDPR被遗忘权的实现方式]
Compliance Requirements
合规要求
| Regulation | Requirement | Implementation |
|---|---|---|
| GDPR | Data protection, right to deletion | Implement data export/deletion endpoints |
| PCI DSS | No storage of card data | Use Stripe tokenization, never store CVV/full PAN |
| LGPD | Brazil data protection | Same as GDPR compliance |
| 法规 | 要求 | 实现方式 |
|---|---|---|
| GDPR | 数据保护、删除权 | 实现数据导出/删除端点 |
| PCI DSS | 不存储卡片数据 | 使用Stripe令牌化,绝不存储CVV/完整卡号 |
| LGPD | 巴西数据保护法规 | 与GDPR合规要求一致 |
Security Best Practices
安全最佳实践
- ✅ Input validation on all endpoints
- ✅ SQL injection prevention (parameterized queries)
- ✅ XSS prevention (sanitize user input, CSP headers)
- ✅ CSRF protection (tokens for state-changing operations)
- ✅ Rate limiting (e.g., 10 req/min per user, 100 req/min per IP)
- ✅ Audit logging (log all sensitive operations)
- ✅ 所有端点输入验证
- ✅ 防止SQL注入(参数化查询)
- ✅ 防止XSS(清理用户输入、CSP头)
- ✅ CSRF保护(状态变更操作使用令牌)
- ✅ 速率限制(如每个用户10次/分钟,每个IP 100次/分钟)
- ✅ 审计日志(记录所有敏感操作)
Secrets Management
密钥管理
API Keys:
- Storage: Environment variables or secret management service
- Rotation: Define rotation policy (e.g., every 90 days)
- Access: Backend services only, never exposed to frontend
- Examples: Stripe keys, database credentials, API tokens
Webhook Signatures:
- Validate webhook signatures from external services
- Reject requests without valid signature headers
- Log invalid signature attempts for security monitoring
**If missing and project involves payments/auth**: Ask "This is a [payment/auth] system. I need security details: How will you handle authentication? What encryption will be used? What PII is collected? Any compliance requirements (GDPR, PCI DSS)?"
---API密钥:
- 存储: 环境变量或密钥管理服务
- 轮换: 定义轮换策略(如每90天)
- 访问权限: 仅后端服务可访问,绝不暴露给前端
- 示例: Stripe密钥、数据库凭证、API令牌
Webhook签名:
- 验证外部服务的Webhook签名
- 拒绝无有效签名头的请求
- 记录无效签名尝试用于安全监控
**如果涉及支付/认证项目但信息缺失**:询问“这是一个[支付/认证]系统。我需要以下安全细节:如何处理认证?将使用什么加密方式?收集哪些个人可识别信息?有哪些合规要求(GDPR、PCI DSS)?”
---9. Testing Strategy (CRITICAL)
9. 测试策略(关键项)
markdown
undefinedmarkdown
undefinedTesting Strategy
测试策略
| Test Type | Scope | Coverage Target | Approach |
|---|---|---|---|
| Unit Tests | Services, repositories | > 80% | Jest with mocks |
| Integration Tests | API endpoints + database | Critical paths | Supertest + test DB |
| E2E Tests | Full user flows | Happy path + error cases | Playwright |
| Contract Tests | External API integration | API contract validation | Pact or manual mocks |
| Load Tests | Performance under load | Baseline performance | k6 or Artillery |
| 测试类型 | 范围 | 覆盖率目标 | 方法 |
|---|---|---|---|
| 单元测试 | 服务、仓库 | > 80% | Jest+模拟 |
| 集成测试 | API端点+数据库 | 关键路径 | Supertest+测试数据库 |
| 端到端测试 | 完整用户流程 | 正常流程+异常情况 | Playwright |
| 契约测试 | 外部API集成 | API契约验证 | Pact或手动模拟 |
| 负载测试 | 负载下的性能 | 基准性能 | k6或Artillery |
Test Scenarios
测试场景
Unit Tests:
- ✅ Service business logic (create, update, delete)
- ✅ Repository query methods
- ✅ Error handling (throw correct exceptions)
- ✅ Edge cases (null inputs, invalid data)
Integration Tests:
- ✅ POST → creates in DB
/api/v1/resource - ✅ GET → returns correct data
/api/v1/resource/:id - ✅ DELETE → removes from DB
/api/v1/resource/:id - ✅ Invalid input → returns 400 Bad Request
- ✅ Unauthorized access → returns 401/403
E2E Tests:
- ✅ User creates resource → success flow
- ✅ User tries to access another user's resource → denied
- ✅ External API fails → graceful degradation
- ✅ Database connection lost → proper error handling
Load Tests:
- Target: 100 req/s sustained, 500 req/s peak
- Monitor: Latency (p50, p95, p99), error rate, throughput
- Pass criteria: p95 < 500ms, error rate < 1%
单元测试:
- ✅ 服务业务逻辑(创建、更新、删除)
- ✅ 仓库查询方法
- ✅ 错误处理(抛出正确异常)
- ✅ 边缘情况(空输入、无效数据)
集成测试:
- ✅ POST → 在数据库中创建记录
/api/v1/resource - ✅ GET → 返回正确数据
/api/v1/resource/:id - ✅ DELETE → 从数据库中删除记录
/api/v1/resource/:id - ✅ 无效输入 → 返回400 Bad Request
- ✅ 未授权访问 → 返回401/403
端到端测试:
- ✅ 用户创建资源 → 成功流程
- ✅ 用户尝试访问其他用户的资源 → 被拒绝
- ✅ 外部API失败 → 优雅降级
- ✅ 数据库连接丢失 → 正确错误处理
负载测试:
- 目标: 持续100请求/秒,峰值500请求/秒
- 监控: 延迟(p50、p95、p99)、错误率、吞吐量
- 通过标准: p95 < 500ms,错误率 < 1%
Test Data Management
测试数据管理
- Use factories for test data (e.g., )
@faker-js/faker - Seed test database with realistic data
- Clean up test data after each test
- Use separate test database (never use production)
**If missing**: Ask "How will you test this? What test types are needed (unit, integration, e2e)? What are critical test scenarios?"
---- 使用工厂生成测试数据(如)
@faker-js/faker - 向测试数据库填充真实数据
- 每次测试后清理测试数据
- 使用独立的测试数据库(绝不使用生产数据库)
**如果信息缺失**:询问“您将如何测试?需要哪些测试类型(单元、集成、端到端)?关键测试场景有哪些?”
---10. Monitoring & Observability (CRITICAL for production)
10. 监控与可观测性(生产系统为必填项)
markdown
undefinedmarkdown
undefinedMonitoring & Observability
监控与可观测性
Metrics to Track
需跟踪的指标
| Metric | Type | Alert Threshold | Dashboard |
|---|---|---|---|
| Latency | p95 > 1s for 5min | DataDog / Grafana |
| Error rate | > 1% for 5min | DataDog / Grafana |
| Latency | p95 > 2s for 5min | DataDog |
| Counter | > 5 in 1min | PagerDuty |
| Duration | p95 > 100ms | DataDog |
| Duration | > 5s | Internal Dashboard |
| 指标 | 类型 | 告警阈值 | 仪表盘 |
|---|---|---|---|
| 延迟 | p95 > 1s持续5分钟 | DataDog / Grafana |
| 错误率 | > 1%持续5分钟 | DataDog / Grafana |
| 延迟 | p95 > 2s持续5分钟 | DataDog |
| 计数器 | 1分钟内超过5次 | PagerDuty |
| 持续时间 | p95 > 100ms | DataDog |
| 持续时间 | > 5s | 内部仪表盘 |
Structured Logging
结构化日志
Log Format (JSON):
json
{
"level": "info",
"timestamp": "2026-02-04T10:00:00Z",
"message": "Resource created",
"context": {
"userId": "user-123",
"resourceId": "res-456",
"action": "create",
"duration_ms": 45
}
}
**What to Log**:
- ✅ All API requests (method, path, status, duration)
- ✅ External API calls (endpoint, status, duration)
- ✅ Database queries (slow queries > 100ms)
- ✅ Errors and exceptions (stack trace, context)
- ✅ Business events (resource created, payment processed)
**What NOT to Log**:
- ❌ Passwords, API keys, secrets
- ❌ Full credit card numbers
- ❌ Sensitive PII (redact or hash)日志格式(JSON):
json
{
"level": "info",
"timestamp": "2026-02-04T10:00:00Z",
"message": "资源已创建",
"context": {
"userId": "user-123",
"resourceId": "res-456",
"action": "create",
"duration_ms": 45
}
}
**需记录的内容**:
- ✅ 所有API请求(方法、路径、状态、时长)
- ✅ 外部API调用(端点、状态、时长)
- ✅ 数据库查询(慢查询>100ms)
- ✅ 错误与异常(堆栈跟踪、上下文)
- ✅ 业务事件(资源创建、支付处理)
**无需记录的内容**:
- ❌ 密码、API密钥、密钥
- ❌ 完整信用卡号
- ❌ 敏感个人可识别信息(编辑或哈希处理)Alerts
告警
| Alert | Severity | Channel | On-Call Action |
|---|---|---|---|
| Error rate > 5% | P1 (Critical) | PagerDuty | Immediate investigation, rollback if needed |
| External API down | P1 (Critical) | PagerDuty | Enable fallback mode, notify stakeholders |
| Latency > 2s (p95) | P2 (High) | Slack #engineering | Investigate performance degradation |
| Webhook failures > 20 | P2 (High) | Slack #engineering | Check webhook endpoint, Stripe status |
| Database connection pool exhausted | P1 (Critical) | PagerDuty | Scale up connections or investigate leak |
| 告警 | 严重程度 | 渠道 | 值班操作 |
|---|---|---|---|
| 错误率>5% | P1(关键) | PagerDuty | 立即调查,必要时回滚 |
| 外部API宕机 | P1(关键) | PagerDuty | 启用降级模式,通知利益相关方 |
| 延迟>2s(p95) | P2(高) | Slack #engineering | 调查性能下降原因 |
| Webhook失败>20次 | P2(高) | Slack #engineering | 检查Webhook端点、Stripe状态 |
| 数据库连接池耗尽 | P1(关键) | PagerDuty | 增加连接数或调查泄漏情况 |
Dashboards
仪表盘
Operational Dashboard:
- Request rate (per endpoint)
- Error rate (overall and per endpoint)
- Latency (p50, p95, p99)
- External API health
- Database performance
Business Dashboard:
- Resources created (count per day)
- Active users
- Conversion metrics (if applicable)
**If missing for production system**: Ask "How will you monitor this in production? What metrics matter? What alerts do you need?"
---运维仪表盘:
- 请求速率(按端点)
- 错误率(整体及按端点)
- 延迟(p50、p95、p99)
- 外部API健康状态
- 数据库性能
业务仪表盘:
- 资源创建数(每日统计)
- 活跃用户数
- 转化指标(如适用)
**如果生产系统信息缺失**:询问“您将如何在生产环境监控此系统?哪些指标重要?需要哪些告警?”
---11. Rollback Plan (CRITICAL for production)
11. 回滚计划(生产系统为必填项)
markdown
undefinedmarkdown
undefinedRollback Plan
回滚计划
Deployment Strategy
部署策略
-
Feature Flag:(LaunchDarkly / custom)
FEATURE_X_ENABLED -
Phased Rollout:
- Phase 1: 5% of traffic (1 day)
- Phase 2: 25% of traffic (1 day)
- Phase 3: 50% of traffic (1 day)
- Phase 4: 100% of traffic
-
Canary Deployment: Deploy to 1 instance first, monitor for 1h before full rollout
-
Feature Flag:(LaunchDarkly / 自定义)
FEATURE_X_ENABLED -
分阶段发布:
- 阶段1: 5%流量(1天)
- 阶段2: 25%流量(1天)
- 阶段3: 50%流量(1天)
- 阶段4: 100%流量
-
金丝雀部署: 先部署到1台实例,监控1小时后再全面发布
Rollback Triggers
回滚触发条件
| Trigger | Action |
|---|---|
| Error rate > 5% for 5 minutes | Immediate rollback - disable feature flag |
| Latency > 3s (p95) for 10 minutes | Investigate - rollback if no quick fix |
| External API integration failing > 50% | Rollback - revert to previous version |
| Database migration fails | STOP - do not proceed, investigate |
| Customer reports of data loss | Immediate rollback + incident response |
| 触发条件 | 操作 |
|---|---|
| 错误率>5%持续5分钟 | 立即回滚 - 禁用feature flag |
| 延迟>3s(p95)持续10分钟 | 调查 - 若无快速修复则回滚 |
| 外部API集成失败率>50% | 回滚 - 恢复到之前版本 |
| 数据库迁移失败 | 停止 - 不继续执行,调查原因 |
| 客户报告数据丢失 | 立即回滚 + 事件响应 |
Rollback Steps
回滚步骤
1. Immediate Rollback (< 5 minutes):
- Feature Flag: Disable via feature flag dashboard (instant)
- Deployment: Revert to previous version via deployment tool (2-3 minutes)
2. Database Rollback (if schema changed):
- Run down migration using migration tool
- Verify schema integrity
- Confirm data consistency
3. Communication:
- Notify #engineering Slack channel
- Update status page (if customer-facing)
- Create incident ticket
- Schedule post-mortem within 24h
1. 立即回滚(<5分钟):
- Feature Flag: 通过feature flag控制台禁用(即时生效)
- 部署: 通过部署工具恢复到之前版本(2-3分钟)
2. 数据库回滚(如Schema变更):
- 使用迁移工具执行回滚迁移
- 验证Schema完整性
- 确认数据一致性
3. 沟通:
- 通知#engineering Slack频道
- 更新状态页面(如面向客户)
- 创建事件工单
- 24小时内安排事后复盘
Post-Rollback
回滚后
- Root Cause Analysis: Within 24 hours
- Fix: Implement fix in development environment
- Re-test: Full test suite + additional tests for root cause
- Re-deploy: Following same phased rollout strategy
- 根本原因分析: 24小时内完成
- 修复: 在开发环境实现修复
- 重新测试: 完整测试套件+针对根本原因的额外测试
- 重新发布: 遵循相同的分阶段发布策略
Database Rollback Considerations
数据库回滚注意事项
- Migrations: Always create reversible migrations (down migration)
- Data Backfill: If data was modified, have script to restore previous state
- Backup: Take database snapshot before running migrations
- Testing: Test rollback procedure on staging before production
**If missing for production**: Ask "What happens if the deploy goes wrong? How will you rollback? What are the triggers for rollback?"
---- 迁移: 始终创建可逆迁移(回滚迁移)
- 数据回填: 若数据被修改,准备恢复之前状态的脚本
- 备份: 执行迁移前拍摄数据库快照
- 测试: 在预发布环境测试回滚流程后再用于生产环境
**如果生产系统信息缺失**:询问“如果部署失败会怎样?您将如何回滚?回滚的触发条件是什么?”
---12. Success Metrics (SUGGESTED)
12. 成功指标(建议项)
markdown
undefinedmarkdown
undefinedSuccess Metrics
成功指标
| Metric | Baseline | Target | Measurement |
|---|---|---|---|
| API latency (p95) | N/A (new API) | < 200ms | DataDog APM |
| Error rate | N/A | < 0.1% | Sentry / logs |
| Conversion rate | N/A | > 70% | Analytics |
| User satisfaction | N/A | NPS > 8 | User survey |
| Time to complete action | N/A | < 30s | Frontend analytics |
Business Metrics:
- Increase in [metric] by [X%]
- Reduction in [cost/time] by [Y%]
- User adoption: [Z%] of users using new feature within 30 days
Technical Metrics:
- Zero production incidents in first 30 days
- Test coverage > 80%
- Documentation completeness: 100% of public APIs documented
---| 指标 | 基线 | 目标 | 测量方式 |
|---|---|---|---|
| API延迟(p95) | 无(新API) | < 200ms | DataDog APM |
| 错误率 | 无 | < 0.1% | Sentry / 日志 |
| 转化率 | 无 | > 70% | 分析工具 |
| 用户满意度 | 无 | NPS > 8 | 用户调查 |
| 操作完成时间 | 无 | < 30s | 前端分析工具 |
业务指标:
- [指标]提升[X%]
- [成本/时间]降低[Y%]
- 用户采用率: 30天内[Z%]的用户使用新功能
技术指标:
- 发布后30天内零生产事件
- 测试覆盖率>80%
- 文档完整性: 100%的公开API已文档化
---13. Glossary & Domain Terms (SUGGESTED)
13. 术语表与领域术语(建议项)
markdown
undefinedmarkdown
undefinedGlossary
术语表
| Term | Description |
|---|---|
| Customer | A user who has an active subscription or has made a purchase |
| Subscription | Recurring payment arrangement with defined interval (monthly, annual) |
| Trial | Free period for users to test service before payment required |
| Webhook | HTTP callback from external service to notify of events |
| Idempotency | Operation can be applied multiple times with same result |
| Circuit Breaker | Pattern to prevent cascading failures when external service is down |
Acronyms:
- API: Application Programming Interface
- SLA: Service Level Agreement
- PII: Personally Identifiable Information
- GDPR: General Data Protection Regulation
- PCI DSS: Payment Card Industry Data Security Standard
---| 术语 | 描述 |
|---|---|
| 客户 | 拥有有效订阅或已完成购买的用户 |
| 订阅 | 定期支付安排,有明确周期(月度、年度) |
| 试用 | 用户在付费前可免费试用服务的期限 |
| Webhook | 外部服务的HTTP回调,用于通知事件 |
| 幂等性 | 操作可多次执行且结果相同 |
| 断路器 | 外部服务宕机时防止级联失败的模式 |
缩写:
- API: 应用程序编程接口
- SLA: 服务水平协议
- PII: 个人可识别信息
- GDPR: 通用数据保护条例
- PCI DSS: 支付卡行业数据安全标准
---14. Alternatives Considered (SUGGESTED)
14. 考虑过的替代方案(建议项)
markdown
undefinedmarkdown
undefinedAlternatives Considered
考虑过的替代方案
| Option | Pros | Cons | Why Not Chosen |
|---|---|---|---|
| Option A (Chosen) | + Best documentation<br>+ Global support<br>+ Mature SDK | - Cost: 2.9% + $0.30<br>- Vendor lock-in | ✅ Chosen - Best balance of features and cost |
| Option B | + Lower fees (2.5%)<br>+ Brand recognition | - Poor developer experience<br>- Limited international support | Developer experience inferior, harder to maintain |
| Option C | + Full control<br>+ No transaction fees | - High maintenance cost<br>- Compliance burden (PCI DSS)<br>- Security risk | Too risky and expensive to maintain in-house |
| Option D | + Cheapest option | - No support<br>- Limited features<br>- Unknown reliability | Too risky for production payment processing |
Decision Criteria:
- Developer experience and documentation quality (weight: 40%)
- Total cost of ownership (weight: 30%)
- International support and compliance (weight: 20%)
- Reliability and uptime (weight: 10%)
Why Option A Won:
- Scored highest on developer experience (critical for fast iteration)
- Industry-standard for startups (easier to hire developers with experience)
- Built-in compliance (PCI DSS, SCA, 3D Secure) reduces risk
---| 选项 | 优点 | 缺点 | 未选择原因 |
|---|---|---|---|
| 选项A(已选) | + 最佳文档<br>+ 全球支持<br>+ 成熟SDK | - 成本: 2.9% + $0.30<br>+ 供应商锁定 | ✅ 已选 - 功能与成本的最佳平衡 |
| 选项B | + 更低费率(2.5%)<br>+ 品牌认知度 | - 开发者体验差<br>+ 国际支持有限 | 开发者体验不佳,维护难度高 |
| 选项C | + 完全控制<br>+ 无交易手续费 | - 维护成本高<br>+ 合规负担(PCI DSS)<br>+ 安全风险 | 内部维护风险过高、成本昂贵 |
| 选项D | + 最便宜的选项 | - 无支持<br>+ 功能有限<br>+ 可靠性未知 | 生产环境支付处理风险过高 |
决策标准:
- 开发者体验与文档质量(权重: 40%)
- 总拥有成本(权重: 30%)
- 国际支持与合规(权重: 20%)
- 可靠性与可用性(权重: 10%)
选择选项A的原因:
- 开发者体验得分最高(对快速迭代至关重要)
- 创业公司行业标准(更容易招聘有经验的开发者)
- 内置合规(PCI DSS、SCA、3D Secure)降低风险
---15. Dependencies (SUGGESTED)
15. 依赖项(建议项)
markdown
undefinedmarkdown
undefinedDependencies
依赖项
| Dependency | Type | Owner | Status | Risk |
|---|---|---|---|---|
| Stripe API | External | Stripe Inc. | Production-ready | Low (99.99% uptime) |
| Identity Module | Internal | Team Auth | Production-ready | Low |
| Database (PostgreSQL) | Infrastructure | DevOps | Ready | Low |
| Redis (caching) | Infrastructure | DevOps | Needs setup | Medium |
| Feature flag service | Internal | Platform | Ready | Low |
Approval Requirements:
- Security team review (for payment/auth projects)
- Compliance sign-off (for PII/payment data)
- Ops team ready for monitoring setup
- Product sign-off on scope
Blockers:
- Waiting for Stripe production keys (ETA: 2026-02-10)
- Need Redis setup in staging (ETA: 2026-02-08)
---| 依赖项 | 类型 | 所有者 | 状态 | 风险 |
|---|---|---|---|---|
| Stripe API | 外部 | Stripe Inc. | 生产就绪 | 低(99.99%可用性) |
| 身份模块 | 内部 | 认证团队 | 生产就绪 | 低 |
| 数据库(PostgreSQL) | 基础设施 | DevOps | 就绪 | 低 |
| Redis(缓存) | 基础设施 | DevOps | 需设置 | 中 |
| Feature Flag服务 | 内部 | 平台团队 | 就绪 | 低 |
审批要求:
- 安全团队评审(支付/认证项目)
- 合规签字(个人可识别信息/支付数据项目)
- 运维团队完成监控设置
- 产品团队确认范围
阻塞项:
- 等待Stripe生产密钥(预计: 2026-02-10)
- 预发布环境需设置Redis(预计: 2026-02-08)
---16. Performance Requirements (SUGGESTED)
16. 性能要求(建议项)
markdown
undefinedmarkdown
undefinedPerformance Requirements
性能要求
| Metric | Requirement | Measurement Method |
|---|---|---|
| API Latency (p50) | < 100ms | DataDog APM |
| API Latency (p95) | < 500ms | DataDog APM |
| API Latency (p99) | < 1s | DataDog APM |
| Throughput | 1000 req/s sustained | Load testing (k6) |
| Availability | 99.9% (< 8.76h downtime/year) | Uptime monitoring |
| Database query time | < 50ms (p95) | Slow query log |
Load Testing Plan:
- Baseline: 100 req/s for 10 minutes
- Peak: 500 req/s for 5 minutes
- Spike: 1000 req/s for 1 minute
Scalability:
- Horizontal scaling: Add more instances (Kubernetes autoscaling)
- Database: Read replicas if needed (after 10k req/s)
- Caching: Redis for frequently accessed data (> 100 req/s per resource)
---| 指标 | 要求 | 测量方法 |
|---|---|---|
| API延迟(p50) | < 100ms | DataDog APM |
| API延迟(p95) | < 500ms | DataDog APM |
| API延迟(p99) | < 1s | DataDog APM |
| 吞吐量 | 1000请求/秒持续 | 负载测试(k6) |
| 可用性 | 99.9%(每年停机<8.76小时) | 可用性监控 |
| 数据库查询时间 | < 50ms(p95) | 慢查询日志 |
负载测试计划:
- 基线: 100请求/秒持续10分钟
- 峰值: 500请求/秒持续5分钟
- 突增: 1000请求/秒持续1分钟
扩展性:
- 水平扩展: 添加更多实例(Kubernetes自动扩缩容)
- 数据库: 达到10k请求/秒后考虑读副本
- 缓存: 频繁访问的数据(每个资源>100请求/秒)使用Redis
---17. Migration Plan (SUGGESTED - if applicable)
17. 迁移计划(建议项 - 如适用)
markdown
undefinedmarkdown
undefinedMigration Plan
迁移计划
Migration Strategy
迁移策略
Type: [Blue-Green / Rolling / Big Bang / Phased]
Phases:
| Phase | Description | Users Affected | Duration | Rollback |
|---|---|---|---|---|
| 1. Preparation | Set up new system, run in parallel | 0% | 1 week | N/A |
| 2. Shadow Mode | New system processes but doesn't serve | 0% | 1 week | Instant |
| 3. Pilot | 5% of users on new system | 5% | 1 week | < 5min |
| 4. Ramp Up | 50% of users on new system | 50% | 1 week | < 5min |
| 5. Full Migration | 100% of users on new system | 100% | 1 day | < 5min |
| 6. Decommission | Turn off old system | 0% | 1 week | Restore from backup |
类型: [蓝绿部署 / 滚动部署 / 大爆炸迁移 / 分阶段迁移]
阶段:
| 阶段 | 描述 | 受影响用户 | 时长 | 回滚方式 |
|---|---|---|---|---|
| 1. 准备 | 设置新系统,并行运行 | 0% | 1周 | 无 |
| 2. 影子模式 | 新系统处理请求但不对外提供服务 | 0% | 1周 | 即时 |
| 3. 试点 | 5%用户使用新系统 | 5% | 1周 | <5min |
| 4. 扩容 | 50%用户使用新系统 | 50% | 1周 | <5min |
| 5. 完全迁移 | 100%用户使用新系统 | 100% | 1天 | <5min |
| 6. 退役 | 关闭旧系统 | 0% | 1周 | 从备份恢复 |
Data Migration
数据迁移
Source: Old system database
Destination: New system database
Volume: [X million records]
Method: [ETL script / database replication / API sync]
Steps:
- Export data from old system (script: )
scripts/export-old-data.ts - Transform data to new schema (script: )
scripts/transform-data.ts - Validate data integrity (checksums, row counts)
- Load into new system (script: )
scripts/load-new-data.ts - Verify: Run parallel reads, compare results
Timeline:
- Dry run on staging: 2026-02-10
- Production migration window: 2026-02-15 02:00-06:00 UTC (low traffic)
源: 旧系统数据库
目标: 新系统数据库
量级: [X百万条记录]
方法: [ETL脚本 / 数据库复制 / API同步]
步骤:
- 从旧系统导出数据(脚本: )
scripts/export-old-data.ts - 将数据转换为新Schema(脚本: )
scripts/transform-data.ts - 验证数据完整性(校验和、行数统计)
- 加载到新系统(脚本: )
scripts/load-new-data.ts - 验证: 并行读取,对比结果
时间线:
- 预发布环境试运行: 2026-02-10
- 生产迁移窗口: 2026-02-15 02:00-06:00 UTC(低流量时段)
Backward Compatibility
向后兼容性
- Old API endpoints will remain active for 90 days
- Deprecation warnings added to responses
- Client libraries updated with migration guide
---- 旧API端点将保留90天
- 响应中添加弃用警告
- 客户端库更新并提供迁移指南
---18. Open Questions (SUGGESTED)
18. 待解决问题(建议项)
markdown
undefinedmarkdown
undefinedOpen Questions
待解决问题
| # | Question | Context | Owner | Status | Decision Date |
|---|---|---|---|---|---|
| 1 | How to handle trial expiration without payment method? | User loses access immediately or grace period? | @Product | 🟡 In Discussion | TBD |
| 2 | Allow multiple trials for same email? | Prevent abuse vs. legitimate use cases | @TechLead | 🔴 Open | TBD |
| 3 | SLA for webhook processing? | Stripe retries for 72h, what's our target? | @Backend | 🔴 Open | TBD |
| 4 | Support for promo codes in V1? | Marketing requested, is it in scope? | @Product | ✅ Resolved: V2 | 2026-02-01 |
| 5 | Fallback if Identity Module fails? | Can we create subscription without user data? | @TechLead | 🔴 Open | TBD |
Status Legend:
- 🔴 Open - needs decision
- 🟡 In Discussion - actively being discussed
- ✅ Resolved - decision made
---| # | 问题 | 上下文 | 负责人 | 状态 | 决策日期 |
|---|---|---|---|---|---|
| 1 | 无支付方式时如何处理试用到期? | 用户立即失去访问权限还是有宽限期? | @产品 | 🟡 讨论中 | 待定 |
| 2 | 允许同一邮箱多次试用? | 防止滥用 vs 合理使用场景 | @技术负责人 | 🔴 未解决 | 待定 |
| 3 | Webhook处理的SLA? | Stripe重试72小时,我们的目标是? | @后端 | 🔴 未解决 | 待定 |
| 4 | V1是否支持优惠码? | 市场部要求,是否在范围内? | @产品 | ✅ 已解决: V2 | 2026-02-01 |
| 5 | 身份模块故障时的降级方案? | 无用户数据时能否创建订阅? | @技术负责人 | 🔴 未解决 | 待定 |
状态说明:
- 🔴 未解决 - 需决策
- 🟡 讨论中 - 正在讨论
- ✅ 已解决 - 已决策
---19. Roadmap / Timeline (SUGGESTED)
19. 路线图/时间线(建议项)
markdown
undefinedmarkdown
undefinedRoadmap / Timeline
路线图/时间线
| Phase | Deliverables | Duration | Target Date | Status |
|---|---|---|---|---|
| Phase 0: Setup | - Stripe credentials<br>- Staging environment<br>- SDK installed | 2 days | 2026-02-05 | ✅ Complete |
| Phase 1: Persistence | - Entities created<br>- Repositories implemented<br>- Migrations generated | 3 days | 2026-02-08 | 🟡 In Progress |
| Phase 2: Services | - CustomerService<br>- SubscriptionService<br>- Identity integration | 5 days | 2026-02-15 | ⏳ Pending |
| Phase 3: APIs | - POST /subscriptions<br>- DELETE /subscriptions/:id<br>- GET /subscriptions | 3 days | 2026-02-18 | ⏳ Pending |
| Phase 4: Webhooks | - Webhook endpoint<br>- Signature validation<br>- Event handlers | 4 days | 2026-02-22 | ⏳ Pending |
| Phase 5: Testing | - Unit tests (80% coverage)<br>- Integration tests<br>- E2E tests | 5 days | 2026-02-27 | ⏳ Pending |
| Phase 6: Deploy | - Documentation<br>- Monitoring setup<br>- Staging deploy<br>- Production rollout | 3 days | 2026-03-02 | ⏳ Pending |
Total Duration: ~25 days (5 weeks)
Milestones:
- 🎯 M1: MVP ready for staging (2026-02-22)
- 🎯 M2: Production deployment (2026-03-02)
- 🎯 M3: 100% rollout complete (2026-03-09)
Critical Path:
Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5 → Phase 6
---| 阶段 | 交付物 | 时长 | 目标日期 | 状态 |
|---|---|---|---|---|
| 阶段0: 准备 | - Stripe凭证<br>- 预发布环境<br>- SDK安装 | 2天 | 2026-02-05 | ✅ 已完成 |
| 阶段1: 持久化 | - 实体创建<br>- 仓库实现<br>- 迁移脚本生成 | 3天 | 2026-02-08 | 🟡 进行中 |
| 阶段2: 服务 | - CustomerService<br>- SubscriptionService<br>- 身份集成 | 5天 | 2026-02-15 | ⏳ 待开始 |
| 阶段3: API | - POST /subscriptions<br>- DELETE /subscriptions/:id<br>- GET /subscriptions | 3天 | 2026-02-18 | ⏳ 待开始 |
| 阶段4: Webhook | - Webhook端点<br>- 签名验证<br>- 事件处理 | 4天 | 2026-02-22 | ⏳ 待开始 |
| 阶段5: 测试 | - 单元测试(80%覆盖率)<br>- 集成测试<br>- 端到端测试 | 5天 | 2026-02-27 | ⏳ 待开始 |
| 阶段6: 部署 | - 文档<br>- 监控设置<br>- 预发布部署<br>- 生产环境发布 | 3天 | 2026-03-02 | ⏳ 待开始 |
总时长: ~25天(5周)
里程碑:
- 🎯 M1: 最小可行产品就绪(2026-02-22)
- 🎯 M2: 生产环境部署(2026-03-02)
- 🎯 M3: 100%发布完成(2026-03-09)
关键路径:
阶段0 → 阶段1 → 阶段2 → 阶段3 → 阶段4 → 阶段5 → 阶段6
---20. Approval & Sign-off (SUGGESTED)
20. 审批与签字确认(建议项)
markdown
undefinedmarkdown
undefinedApproval & Sign-off
审批与签字确认
| Role | Name | Status | Date | Comments |
|---|---|---|---|---|
| Tech Lead | @Name | ✅ Approved | 2026-02-04 | LGTM, proceed with implementation |
| Staff/Principal Engineer | @Name | ⏳ Pending | - | Requested security review first |
| Product Manager | @Name | ✅ Approved | 2026-02-03 | Scope aligned with roadmap |
| Engineering Manager | @Name | ⏳ Pending | - | - |
| Security Team | @Name | 🔴 Not Started | - | Required for payment integration |
| Compliance/Legal | @Name | N/A | - | Not required for this project |
Approval Criteria:
- ✅ All mandatory sections complete
- ✅ Security review passed (if applicable)
- ✅ Risks identified and mitigated
- ✅ Timeline realistic and agreed upon
- ⏳ Test strategy approved by QA
- ⏳ Monitoring plan reviewed by SRE
Next Steps After Approval:
- Create Epic in Jira (link in metadata)
- Break down into User Stories
- Begin Phase 1 implementation
- Schedule kickoff meeting with team
---| 角色 | 姓名 | 状态 | 日期 | 意见 |
|---|---|---|---|---|
| 技术负责人 | @姓名 | ✅ 已批准 | 2026-02-04 | 可以开始实施 |
| 高级/首席工程师 | @姓名 | ⏳ 待批准 | - | 先进行安全评审 |
| 产品经理 | @姓名 | ✅ 已批准 | 2026-02-03 | 范围与路线图一致 |
| 工程经理 | @姓名 | ⏳ 待批准 | - | - |
| 安全团队 | @姓名 | 🔴 未开始 | - | 支付集成必填 |
| 合规/法务 | @姓名 | 不适用 | - | 本项目无需 |
审批标准:
- ✅ 所有必填章节完整
- ✅ 安全评审通过(如适用)
- ✅ 风险已识别并制定缓解措施
- ✅ 时间线合理且已达成一致
- ⏳ 测试策略已获QA批准
- ⏳ 监控计划已获SRE评审
审批后下一步:
- 在Jira创建史诗(链接到元数据)
- 拆分为用户故事
- 开始阶段1实施
- 安排团队启动会议
---Validation Rules
验证规则
Mandatory Section Checklist
必填章节检查清单
Before finalizing TDD, ensure:
- Header: Tech Lead, Team, Epic link present
- Context: 2+ paragraphs describing background and domain
- Problem: At least 2 specific problems identified with impact
- Scope: Clear in-scope and out-of-scope items (min 3 each)
- Technical Solution: Architecture diagram or description
- Technical Solution: At least 1 API endpoint defined
- Risks: At least 3 risks with impact/probability/mitigation
- Implementation Plan: Broken into phases with estimates
最终确定TDD前,确保:
- 页眉: 包含技术负责人、团队、史诗链接
- 背景: 2段以上描述现状和领域
- 问题: 至少2个具体问题及影响
- 范围: 明确的包含/排除范围(各至少3项)
- 技术解决方案: 架构图或描述
- 技术解决方案: 至少定义1个API端点
- 风险: 至少3项风险及影响/概率/缓解措施
- 实施计划: 拆分为阶段并包含预估时长
Critical Section Checklist (by project type)
关键章节检查清单(按项目类型)
If Payment/Auth project:
- Security: Authentication method defined
- Security: Encryption (at rest, in transit) specified
- Security: PII handling approach documented
- Security: Compliance requirements identified
If Production system:
- Monitoring: At least 3 metrics defined with thresholds
- Monitoring: Alerts configured
- Rollback: Rollback triggers defined
- Rollback: Rollback steps documented
All projects:
- Testing: At least 2 test types defined (unit, integration, e2e)
- Testing: Critical test scenarios listed
如果是支付/认证项目:
- 安全: 定义认证方式
- 安全: 指定加密(静态、传输中)
- 安全: 记录个人可识别信息处理方式
- 安全: 识别合规要求
如果是生产系统:
- 监控: 至少定义3个带阈值的指标
- 监控: 配置告警
- 回滚: 定义回滚触发条件
- 回滚: 记录回滚步骤
所有项目:
- 测试: 至少定义2种测试类型(单元、集成、端到端)
- 测试: 列出关键测试场景
Output Format
输出格式
When Creating TDD
创建TDD时
- Generate Markdown document
- Validate against checklists above
- Highlight any missing critical sections
- Provide summary to user:
✅ TDD Created: "[Project Name]"
**Sections Included**:
✅ Mandatory (7/7): All present
✅ Critical (3/4): Security, Testing, Monitoring
⚠️ Missing: Rollback Plan (recommended for production)
**Suggested Next Steps**:
- Add Rollback Plan section (critical for production)
- Review Security section with InfoSec team
- Create Epic in Jira and link in metadata
- Schedule TDD review meeting with stakeholders
Would you like me to:
1. Add the missing Rollback Plan section?
2. Publish this TDD to Confluence?
3. Create a Jira Epic for this project?- 生成Markdown文档
- 对照上述检查清单验证
- 高亮缺失的关键章节
- 向用户提供摘要:
✅ TDD已创建: "[项目名称]"
**包含章节**:
✅ 必填章节(7/7): 全部完成
✅ 关键章节(3/4): 安全、测试、监控
⚠️ 缺失: 回滚计划(生产系统建议添加)
**建议下一步**:
- 添加回滚计划章节(生产系统关键项)
- 与信息安全团队评审安全章节
- 在Jira创建史诗并链接到元数据
- 安排利益相关方TDD评审会议
您希望我:
1. 添加缺失的回滚计划章节?
2. 将此TDD发布到Confluence?
3. 为此项目创建Jira史诗?Confluence Integration
Confluence集成
If user wants to publish to Confluence:
I'll publish this TDD to Confluence.
Which space should I use?
- Personal space (~557058...)
- Team space (provide space key)
Should I:
- Create a new page
- Update existing page (provide page ID or URL)Then use Confluence Assistant skill to publish.
如果用户希望发布到Confluence:
我将把此TDD发布到Confluence。
您希望使用哪个空间?
- 个人空间(~557058...)
- 团队空间(提供空间密钥)
您希望:
- 创建新页面
- 更新现有页面(提供页面ID或URL)然后使用Confluence Assistant技能发布。
Common Anti-Patterns to Avoid
需避免的常见反模式
❌ Vague Problem Statements
❌ 模糊的问题陈述
BAD:
We need to integrate with Stripe.
GOOD:
undefined不良示例:
我们需要与Stripe集成。良好示例:
undefinedProblems We're Solving
我们要解决的问题
- Manual payment processing takes 2 hours/day: Currently processing payments manually, costing $500/month in labor
- Cannot expand internationally: Current payment processor only supports USD
- High cart abandonment (45%): Poor checkout UX causing revenue loss of $10k/month
undefined- 手动支付处理每天耗时2小时: 当前手动处理支付,每月人工成本500美元
- 无法拓展国际业务: 当前支付处理器仅支持美元
- 高购物车放弃率(45%): 糟糕的结账体验导致每月损失1万美元收入
undefined❌ Undefined Scope
❌ 未定义的范围
BAD:
Build payment integration with all features.
GOOD:
undefined不良示例:
构建包含所有功能的支付集成。良好示例:
undefined✅ In Scope (V1)
✅ 包含范围(V1)
- Trial subscriptions (14 days)
- Single payment method per user
- USD only
- Cancel subscription
- 试用订阅(14天)
- 每个用户单一支付方式
- 仅支持美元
- 取消订阅
❌ Out of Scope (V1)
❌ 排除范围(V1)
- Multiple payment methods
- Multi-currency
- Promo codes
- Usage-based billing
undefined- 多种支付方式
- 多币种
- 优惠码
- 基于使用量的计费
undefined❌ Missing Security for Payment Systems
❌ 支付系统缺失安全章节
BAD:
No security section for payment integration.
GOOD:
undefined不良示例:
支付集成无安全章节。良好示例:
undefinedSecurity Considerations (MANDATORY)
安全考量(必填项)
PCI DSS Compliance:
- Never store full card numbers (use Stripe tokens)
- Never log CVV or full PAN
- Use Stripe Elements for card input (PCI SAQ A)
Secrets Management:
- Store in environment variables
STRIPE_SECRET_KEY - Rotate keys every 90 days
- Never commit keys to git
undefinedPCI DSS合规:
- 绝不存储完整卡号(使用Stripe令牌化)
- 绝不记录CVV或完整卡号
- 使用Stripe Elements收集卡片信息(PCI SAQ A合规)
密钥管理:
- 存储在环境变量中
STRIPE_SECRET_KEY - 每90天轮换密钥
- 绝不将密钥提交到git
undefined❌ No Rollback Plan
❌ 无回滚计划
BAD:
We'll deploy and hope it works.
GOOD:
undefined不良示例:
我们将直接部署,希望一切顺利。良好示例:
undefinedRollback Plan
回滚计划
Triggers:
- Error rate > 5% → immediate rollback
- Payment processing failures > 10% → immediate rollback
Steps:
- Disable feature flag
STRIPE_INTEGRATION_ENABLED - Verify old payment processor is active
- Notify #engineering and #product
- Schedule post-mortem within 24h
undefined触发条件:
- 错误率>5% → 立即回滚
- 支付处理失败率>10% → 立即回滚
步骤:
- 禁用feature flag
STRIPE_INTEGRATION_ENABLED - 验证旧支付处理器已激活
- 通知#engineering和#product频道
- 24小时内安排事后复盘
undefinedImportant Notes
重要提示
- Respect user's language - Automatically detect and generate TDD in the same language as user's request
- Focus on architecture, not implementation - Document decisions and contracts, not code
- High-level examples only - Show API contracts, data schemas, diagrams (not CLI commands or code snippets)
- Always validate mandatory sections - Don't let user skip them
- For payments/auth - Security section is MANDATORY
- For production - Monitoring and Rollback are MANDATORY
- Ask clarifying questions - Don't guess missing information (ask in user's language)
- Be thorough but pragmatic - Small projects don't need all 20 sections
- Update the document - TDDs should evolve as the project progresses
- Use industry standards - Reference Google, Amazon, RFC patterns
- Think about compliance - GDPR, PCI DSS, HIPAA where applicable
- Test for longevity - If implementation framework changes, TDD should still be valid
- 尊重用户语言 - 自动检测并使用用户请求的语言生成TDD
- 聚焦架构而非实现 - 记录决策与契约,而非代码
- 仅提供高层示例 - 展示API契约、数据Schema、图表(而非CLI命令或代码片段)
- 始终验证必填章节 - 不允许用户跳过
- 支付/认证项目 - 安全章节为必填项
- 生产系统 - 监控与回滚章节为必填项
- 询问澄清问题 - 不猜测缺失信息(使用用户的语言)
- 全面且务实 - 小型项目无需全部20个章节
- 更新文档 - TDD应随项目进展而演进
- 遵循行业标准 - 参考Google、Amazon、RFC模式
- 考虑合规 - 适用GDPR、PCI DSS、HIPAA等法规
- 测试长期有效性 - 即使实现框架变更,TDD仍应有效
Example Prompts that Trigger This Skill
触发此技能的示例请求
English
英文
- "Create a TDD for Stripe integration"
- "I need a technical design document for the new auth system"
- "Write a design doc for the API redesign"
- "Help me document the payment integration architecture"
- "Create a tech spec for migrating to microservices"
- "Create a TDD for Stripe integration"
- "I need a technical design document for the new auth system"
- "Write a design doc for the API redesign"
- "Help me document the payment integration architecture"
- "Create a tech spec for migrating to microservices"
Portuguese
葡萄牙语
- "Crie um TDD para integração com Stripe"
- "Preciso de um documento de design técnico para o novo sistema de autenticação"
- "Escreva um design doc para o redesign da API"
- "Me ajude a documentar a arquitetura de integração de pagamento"
- "Crie uma especificação técnica para migração para microserviços"
- "Crie um TDD para integração com Stripe"
- "Preciso de um documento de design técnico para o novo sistema de autenticação"
- "Escreva um design doc para o redesign da API"
- "Me ajude a documentar a arquitetura de integração de pagamento"
- "Crie uma especificação técnica para migração para microserviços"
Spanish
西班牙语
- "Crea un TDD para integración con Stripe"
- "Necesito un documento de diseño técnico para el nuevo sistema de autenticación"
- "Escribe un design doc para el rediseño de la API"
- "Ayúdame a documentar la arquitectura de integración de pagos"
- "Crea una especificación técnica para migración a microservicios"
- "Crea un TDD para integración con Stripe"
- "Necesito un documento de diseño técnico para el nuevo sistema de autenticación"
- "Escribe un design doc para el rediseño de la API"
- "Ayúdame a documentar la arquitectura de integración de pagos"
- "Crea una especificación técnica para migración a microservicios"