swe-method

SWE 方法

使用此工作流处理 Jira 故事，确保掌握足够的上下文并完成验证，避免凭空实现。

第 1 步：明确上下文

提前汇总你已了解的资源。

规格说明

• Jira 工单 ID

补充上下文索引

• Slack 讨论串 URL
• AI 工具交互的会话 ID
• 会议记录
• 个人笔记
• 父任务、相关任务和子任务
• 现有分支和 PR

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

收集将用于推理的源材料，并将其与解读分开，以便后续步骤以事实而非记忆为依据。

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

根据规格说明和补充上下文，检查工作所依赖的实际代码仓库、分支、PR、API、架构、CLI 和相关系统。

第 4 步：人在回路中的规格说明细化

规则：

• 任务越大，就越难在一开始明确所有模糊之处。
• 自主运行时间越长，偏离工程师预期结果的风险就越大。

规模指导：

• 微小且重复的任务：通常可以跳过 HIL 步骤，并将决策编码到技能中。
• 小型任务：进行轻量级 HIL 规划，然后自动执行实现。
• 较大型任务：将工作拆分成更小的子任务，并在执行前逐一细化。

使用 Agent 的提问流程，一次提取一项决策，并将明确后的规格说明保存到规格文件或规格文件夹中。

问题类型可以包括：

• 取决于利益相关者或队友的需求
• 工程师可以自行决定或上报的设计决策

第 5 步：执行计划

规格说明关注要构建什么。执行计划关注如何构建，同时避免臆测缺失的信息。

在棕地系统中，尤其涉及数据库、API、CLI 或 SDK 时，不要让 Agent 猜测架构或响应格式。应先进行验证。

执行计划可以包含让 Agent 接触以下内容的 HIL 步骤：

• 真实 API 响应
• 真实数据库架构
• 真实 CLI 或 SDK 行为

只有在验证假设后，才应根据这些事实编写测试。

类变更的执行计划示例：

1. 查询该类依赖的 API 或数据库。
2. 根据观察到的数据结构定义测试用例。
3. 进行实现，直到测试通过。
4. 重构并简化。
5. 更新文档。

第 6 步：实现

两种可行的方法：

• 实现一个切片，针对真实系统端到端运行，排查问题直到行为正确，然后添加测试以确保其稳定。
• 先验证真实的外部行为，然后使用基于真实响应而非臆想内容的测试进行 TDD。

交替进行实现和清理，持续应用代码质量标准与惯例，而不是推迟到最后。