pipeline
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePipeline
Pipeline
<purpose>
Some tasks are inherently sequential - you can't test what isn't built, can't
build what isn't designed, can't review what isn't complete. This elixir
enforces pipeline discipline: define stages, ensure clean handoffs, and never
skip ahead.
</purpose>
<purpose>
有些任务本质上具有顺序依赖性——你无法测试未开发的内容，无法开发未设计的内容，也无法评审未完成的内容。该方法旨在强化流水线规范：明确阶段划分、确保清晰的流程交接，且绝不跳过任何阶段。
</purpose>
When To Activate
适用场景
Trigger when:
- Task has natural phases that must happen in order
- Output of one stage is input to the next
- Skipping stages would cause problems
- User describes multi-phase work ("first X, then Y, then Z")
- Work involves: plan → implement → verify pattern
Do NOT trigger for:
- Independent tasks (use fan-out instead)
- Single-stage work
- Exploratory work with no clear sequence
满足以下条件时启用：
- 任务存在必须按顺序执行的自然阶段
- 前一阶段的输出是下一阶段的输入
- 跳过阶段会引发问题
- 用户描述了多阶段工作（如“先做X，再做Y，最后做Z”）
- 工作遵循“规划→开发→验证”模式
以下情况请勿启用：
- 独立任务（请使用扇出模式替代）
- 单阶段工作
- 无明确顺序的探索性工作
The Pattern
模式框架
[Input] → [Stage 1] → [Handoff] → [Stage 2] → [Handoff] → [Stage 3] → [Output]
│ │ │
└── Checkpoint ──────────┴── Checkpoint ──────────┘[输入] → [阶段1] → [交接] → [阶段2] → [交接] → [阶段3] → [输出]
│ │ │
└── Checkpoint ──────────┴── Checkpoint ──────────┘Instructions
操作步骤
Step 1: Define the Pipeline
步骤1：定义流水线
Map out all stages:
Pipeline: [Task Name]
Stages:
1. [Stage Name] - [What happens] - [Output artifact]
2. [Stage Name] - [What happens] - [Output artifact]
3. [Stage Name] - [What happens] - [Output artifact]
Dependencies:
- Stage 2 requires: [Stage 1 output]
- Stage 3 requires: [Stage 2 output]梳理所有阶段：
Pipeline: [任务名称]
Stages:
1. [阶段名称] - [工作内容] - [输出产物]
2. [阶段名称] - [工作内容] - [输出产物]
3. [阶段名称] - [工作内容] - [输出产物]
Dependencies:
- 阶段2依赖：[阶段1输出]
- 阶段3依赖：[阶段2输出]Step 2: Define Checkpoints
步骤2：定义Checkpoint
Each stage needs exit criteria:
Stage 1 checkpoint:
- [ ] [Exit criterion 1]
- [ ] [Exit criterion 2]
- [ ] Artifact produced: [what]
Stage 2 checkpoint:
- [ ] [Exit criterion 1]
- [ ] Receives: [Stage 1 artifact]
- [ ] Artifact produced: [what]每个阶段需要明确退出标准：
阶段1 Checkpoint:
- [ ] [退出标准1]
- [ ] [退出标准2]
- [ ] 产出物：[具体内容]
阶段2 Checkpoint:
- [ ] [退出标准1]
- [ ] 接收：[阶段1产物]
- [ ] 产出物：[具体内容]Step 3: Execute Stage by Stage
步骤3：按阶段执行
For each stage:
═══════════════════════════════════════
STAGE [N]: [Name]
═══════════════════════════════════════
Input: [What this stage receives]
[Execute stage work]
Checkpoint:
- [✓/✗] Criterion 1
- [✓/✗] Criterion 2
Output: [What this stage produces]
[If all criteria pass] → Proceed to Stage N+1
[If any criterion fails] → Stop and resolve针对每个阶段：
═══════════════════════════════════════
STAGE [N]: [名称]
═══════════════════════════════════════
输入：[本阶段接收的内容]
[执行阶段工作]
Checkpoint:
- [✓/✗] 标准1
- [✓/✗] 标准2
输出：[本阶段产出的内容]
[若所有标准通过] → 进入第N+1阶段
[若任意标准未通过] → 停止并解决问题Step 4: Handoff Protocol
步骤4：交接流程规范
Between stages, explicit handoff:
──────────────────────────────────────
HANDOFF: Stage [N] → Stage [N+1]
──────────────────────────────────────
Passing:
- [Artifact 1]: [description]
- [Artifact 2]: [description]
Context for next stage:
- [Key decision made]
- [Constraint to maintain]
- [Risk to watch for]
──────────────────────────────────────阶段之间需执行明确的交接：
──────────────────────────────────────
HANDOFF: 阶段[N] → 阶段[N+1]
──────────────────────────────────────
移交内容：
- [产物1]：[描述]
- [产物2]：[描述]
给下一阶段的上下文：
- [已做出的关键决策]
- [需遵循的约束条件]
- [需要关注的风险]
──────────────────────────────────────Step 5: Pipeline Completion
步骤5：流水线完成
When all stages complete:
═══════════════════════════════════════
PIPELINE COMPLETE: [Task Name]
═══════════════════════════════════════
Stages completed: [N/N]
Final output:
[Description of what was produced]
Artifacts:
- [Final deliverable 1]
- [Final deliverable 2]
Summary:
- Stage 1: [Brief outcome]
- Stage 2: [Brief outcome]
- Stage 3: [Brief outcome]所有阶段完成后：
═══════════════════════════════════════
PIPELINE COMPLETE: [任务名称]
═══════════════════════════════════════
已完成阶段：[N/N]
最终输出：
[产出物描述]
产物清单：
- [最终交付物1]
- [最终交付物2]
执行总结：
- 阶段1：[简要成果]
- 阶段2：[简要成果]
- 阶段3：[简要成果]Common Pipeline Templates
通用流水线模板
<templates>
**Feature Development**
```
1. Design → Spec document
2. Implement → Working code
3. Test → Passing tests
4. Review → Approved PR
```
</templates>
Bug Fix
1. Reproduce → Consistent repro steps
2. Diagnose → Root cause identified
3. Fix → Code change
4. Verify → Bug no longer occursRefactoring
1. Assess → Impact analysis
2. Prepare → Tests in place
3. Refactor → Code changed
4. Validate → Tests still passDocumentation
1. Outline → Structure defined
2. Draft → Content written
3. Review → Feedback incorporated
4. Publish → Live documentation<templates>
**功能开发**
```
1. Design → 需求规格文档
2. Implement → 可运行代码
3. Test → 通过测试用例
4. Review → 已批准的PR
```
</templates>
Bug修复
1. Reproduce → 可复现的步骤
2. Diagnose → 已定位根因
3. Fix → 代码变更
4. Verify → Bug已解决代码重构
1. Assess → 影响范围分析
2. Prepare → 测试用例就绪
3. Refactor → 代码已修改
4. Validate → 测试用例仍通过文档编写
1. Outline → 结构已定义
2. Draft → 内容已撰写
3. Review → 已整合反馈
4. Publish → 已上线文档Handling Stage Failures
阶段失败处理
<failure-handling>
When a stage fails:
</failure-handling>
- Stop the pipeline - Don't proceed with bad input
- Diagnose the failure - What went wrong?
- Options:
- Fix and retry current stage
- Roll back to previous stage
- Abort pipeline with partial results
STAGE FAILURE: [Stage Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Failed criterion: [What didn't pass]
Reason: [Why it failed]
Options:
A) Retry after fixing [specific issue]
B) Roll back to [previous stage]
C) Abort - partial output available
Recommendation: [A/B/C] because [reason]<failure-handling>
当某个阶段失败时：
</failure-handling>
- 停止流水线 - 不要基于错误输入继续推进
- 诊断失败原因 - 问题出在哪里？
- 可选方案：
- 修复问题后重试当前阶段
- 回滚到上一阶段
- 终止流水线，保留部分成果
STAGE FAILURE: [阶段名称]
━━━━━━━━━━━━━━━━━━━━━━━━━━━
未通过的标准：[具体内容]
原因：[失败原因]
可选方案：
A) 修复[具体问题]后重试
B) 回滚到[上一阶段]
C) 终止流水线 - 可获取部分输出
推荐方案：[A/B/C]，原因：[理由]NEVER
禁止操作
- Skip stages, even when "obvious" they'll pass
- Proceed without explicit checkpoint verification
- Let failures cascade to later stages
- Lose context between stages (use handoff protocol)
- Run stages in parallel (use fan-out for that)
- 跳过任何阶段，即使你认为“显然会通过”
- 未经过明确的Checkpoint验证就推进
- 让失败问题扩散到后续阶段
- 阶段间丢失上下文信息（请使用交接规范）
- 并行执行依赖阶段（此类场景请使用扇出模式）
ALWAYS
必须执行
- Define all stages before starting
- Verify checkpoint criteria explicitly
- Document handoffs with context
- Stop on stage failure
- Report pipeline status at completion
- 启动前明确所有阶段
- 显式验证Checkpoint标准
- 记录包含上下文的交接内容
- 阶段失败时立即停止
- 完成后报告流水线状态
Examples
示例
Example 1: Feature Implementation
示例1：功能开发
User: "Add password reset functionality"
Pipeline: Password Reset Feature
Stages:
1. Design → Security spec, API contract
2. Implement → Endpoint, email service, token handling
3. Test → Unit tests, integration tests
4. Review → Security review, code review
═══════════════════════════════════════
STAGE 1: Design
═══════════════════════════════════════
[Produces security spec covering token expiry,
rate limiting, email verification]
Checkpoint:
- [✓] Security requirements defined
- [✓] API contract specified
- [✓] Edge cases documented
Output: Design spec
──────────────────────────────────────
HANDOFF: Design → Implement
──────────────────────────────────────
Passing: Design spec
Context: Tokens expire in 1 hour, max 3 attempts/hour
═══════════════════════════════════════
STAGE 2: Implement
═══════════════════════════════════════
[Implements based on spec]
...continues through all stages...用户需求：“添加密码重置功能”
Pipeline: 密码重置功能
Stages:
1. Design → 安全规格、API契约
2. Implement → 接口、邮件服务、Token处理
3. Test → 单元测试、集成测试
4. Review → 安全评审、代码评审
═══════════════════════════════════════
STAGE 1: Design
═══════════════════════════════════════
[产出包含Token过期时间、频率限制、邮箱验证的安全规格文档]
Checkpoint:
- [✓] 已定义安全需求
- [✓] 已明确API契约
- [✓] 已记录边缘场景
输出：设计规格文档
──────────────────────────────────────
HANDOFF: Design → Implement
──────────────────────────────────────
移交：设计规格文档
上下文：Token有效期1小时，每小时最多3次尝试
═══════════════════════════════════════
STAGE 2: Implement
═══════════════════════════════════════
[基于规格文档进行开发]
...后续阶段持续推进...Example 2: Debugging Pipeline
示例2：调试流水线
User: "Users are seeing 500 errors on checkout"
Pipeline: Checkout 500 Error Fix
Stages:
1. Reproduce → Consistent repro steps
2. Diagnose → Root cause found
3. Fix → Code change
4. Verify → Error resolved
═══════════════════════════════════════
STAGE 1: Reproduce
═══════════════════════════════════════
Attempting to reproduce...
Checkpoint:
- [✓] Error reproduced locally
- [✓] Consistent reproduction steps documented
Output: Repro steps - 500 occurs when cart has
item with null price field
──────────────────────────────────────
HANDOFF: Reproduce → Diagnose
──────────────────────────────────────
Passing: Repro steps
Context: Only occurs with specific data condition
...continues...用户问题：“用户在结账时遇到500 errors”
Pipeline: 结账500错误修复
Stages:
1. Reproduce → 可稳定复现的步骤
2. Diagnose → 已找到根因
3. Fix → 代码变更
4. Verify → 错误已解决
═══════════════════════════════════════
STAGE 1: Reproduce
═══════════════════════════════════════
尝试复现问题...
Checkpoint:
- [✓] 已在本地复现错误
- [✓] 已记录稳定的复现步骤
输出：复现步骤 - 当购物车中存在价格字段为null的商品时会触发500错误
──────────────────────────────────────
HANDOFF: Reproduce → Diagnose
──────────────────────────────────────
移交：复现步骤
上下文：仅在特定数据条件下触发
...后续阶段持续推进...Why This Elixir Exists
设计初衷
Sequential work needs sequential discipline. The temptation is to skip ahead -
"I'll just start coding and figure out the design as I go." This leads to
rework, bugs, and frustration.
Pipelines force the discipline: complete each stage before moving on. It feels
slower but is faster in total time because you don't backtrack.
The checkpoint isn't bureaucracy - it's the moment where you catch problems
before they become expensive.
顺序型工作需要严格的流程规范。人们往往会有跳过阶段的冲动——“我先写代码，边写边想设计”。这会导致返工、Bug和不必要的挫折。
流水线模式强制要求规范：完成一个阶段后再进入下一个阶段。虽然初期看似耗时，但整体来看反而更快，因为你无需回头返工。
Checkpoint并非形式主义——它是在问题变得昂贵之前发现并解决问题的关键节点。