Back to Details

swe-method

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

SWE Method

SWE方法

Use this workflow to work through a Jira story with enough context and validation to avoid speculative implementation.
使用此工作流来处理 Jira story，通过足够的上下文和验证来避免推测性实现。

Step 1: Define Context

步骤 1：定义上下文

Bring together the resources you already know about up front.
提前汇集你已经了解的资源。

Specification

规格说明

  • Jira ticket ID
  • Jira ticket ID

Additional Context Index

附加上下文索引

  • Slack thread URLs
  • Session IDs from AI-tool interactions
  • Meeting transcripts
  • Personal notes
  • Parent, related, and child tasks
  • Existing branches and PRs
  • Slack 线程链接
  • AI 工具交互的会话 ID
  • 会议记录
  • 个人笔记
  • 父任务、相关任务和子任务
  • 现有的分支和 PR

Step 2: Fetch Data Into An Immutable Layer

步骤 2：提取数据到不可变层

Gather the source material you will reason from and keep it separate from interpretation so later steps are grounded in facts rather than memory.
收集你将用于推理的源材料，并将其与解释分开，以便后续步骤基于事实而不是记忆。

Step 3: Explore Codebase And Systems

步骤 3：探索代码库和系统

Based on the specification and additional context, inspect the real repositories, branches, PRs, APIs, schemas, CLIs, and surrounding systems that the work depends on.
根据规格说明和附加上下文，检查工作所依赖的真实仓库、分支、PR、API、模式、CLI 和周边系统。

Step 4: Human-In-The-Loop Specification Refinement

步骤 4：人在回路（Human-In-The-Loop）规格细化

Rules:
  • The bigger the task, the harder it is to disambiguate everything up front.
  • The longer the autonomous run, the larger the divergence risk from the engineer's intended outcome.
Sizing guidance:
  • Tiny and repetitive tasks: the HIL step can often be skipped and decisions encoded in a skill.
  • Small tasks: do a lightweight HIL planning step, then automate implementation.
  • Larger tasks: break the work into smaller subtasks and refine each before execution.
Use the agent's question flow to extract one decision at a time and store the clarified specification in a spec file or spec folder.
Question types can include:
  • Requirements that depend on stakeholders or teammates
  • Design decisions the engineer can make or escalate
规则：
  • 任务越大，预先消除所有歧义的难度就越大。
  • 自主运行的时间越长，与工程师预期结果背离的风险就越大。
规模指导：
  • 微小且重复的任务：通常可以跳过 HIL 步骤，并将决策编码到 skill 中。
  • 小任务：执行一个轻量级的 HIL 规划步骤，然后自动化实现。
  • 较大任务：将工作拆分为较小的子任务，并在执行前对每个子任务进行细化。
使用 agent 的提问流程一次提取一个决策，并将澄清后的规格存储到 spec 文件或 spec 文件夹中。
问题类型可以包括：
  • 依赖利益相关者或团队成员的需求
  • 工程师可以做出或升级的设计决策

Step 5: Execution Plan

步骤 5：执行计划

The specification is about what to build. The execution plan is about how to build it without hallucinating missing facts.
In brownfield systems, especially when databases, APIs, CLIs, or SDKs are involved, do not let the agent assume schemas or response shapes. Validate them first.
Execution plans may include HIL steps that expose the agent to:
  • Real API responses
  • Real DB schemas
  • Real CLI or SDK behavior
Only after assumptions are validated should tests be written against those facts.
Example execution plan for a class change:
  1. Query the API or DB the class depends on.
  2. Use the observed shape to define a test case.
  3. Implement until the test passes.
  4. Refactor and simplify.
  5. Update docs.
规格说明是关于要构建什么。执行计划是关于如何在不凭空捏造缺失事实的情况下构建它。
在存量系统中，尤其是涉及数据库、API、CLI 或 SDK 时，不要让 agent 假设模式或响应形状。请先验证它们。
执行计划可包括向 agent 展示以下内容的 HIL 步骤：
  • 真实的 API 响应
  • 真实的数据库模式
  • 真实的 CLI 或 SDK 行为
只有在假设得到验证后，才应该根据这些事实编写测试。
一个类变更的执行计划示例：
  1. 查询该类所依赖的 API 或数据库。
  2. 使用观察到的形状定义测试用例。
  3. 实现直到测试通过。
  4. 重构并简化。
  5. 更新文档。

Step 6: Implementation

步骤 6：实施

Two workable paradigms:
  • Implement a slice, run it end to end against the real system, troubleshoot until it behaves correctly, then add tests to lock it down.
  • Validate real external behavior first, then do TDD using tests grounded in factual responses rather than imagined ones.
Alternate implementation with cleanup so code quality and conventions are applied continuously rather than deferred to the end.
两种可行范式：
  • 实现一个切片，在真实系统上端到端运行，排除故障直至行为正确，然后添加测试将其锁定。
  • 首先验证真实的外部行为，然后使用基于事实响应的测试进行 TDD，而不是凭空想象的测试。
将实现与清理交替进行，以便持续应用代码质量和约定，而不是推迟到结尾。