---
description: 确认方案并开始实施开发
---

# 开发实施阶段

**第〇步：更新 draft 状态（如有）**

若任务源自 draft（`./drafts/<史诗>/N-<标题>.md`），在同目录 `summary.md` 中将子任务状态 `未开始` → `开发中`。

**第一步：实施开发**

按子任务逐个实施：

1. 先读 `AGENTS.md` 确认禁止修改的目录/文件
2. 按方案子任务顺序逐一实现，遵循 `AGENTS.md` 规范
3. 使用 `todowrite` 追踪进度（每个子任务 `in_progress` → `completed`）
4. 每个子任务完成后立即：运行方案指定的检查工具（`tsc --noEmit`、`eslint` 等）+ `lsp_diagnostics` + 对照验收标准确认。不通过则修复重检，通过后进入下一个
5. 代码须包含详细注释（各个函数/重要的代码块/重要的逻辑分支/重要的哨兵变量），所有代码可审计

**第二步：代码检查（分层执行，通过一层进下一层）**

*2.1 静态检查*：类型检查 → Linter → Formatter → `lsp_diagnostics` → 回顾 `AGENTS.md` 约束。优先使用项目 `fix` 类命令（如 `yarn fix`）一次性完成。

*2.2 整体验证*：运行 `AGENTS.md` 定义的项目级验证命令（`yarn test`、`pytest` 等）→ 端到端功能验证。全部通过才算完成。

> 发现问题立即修复，修复后从当前层重新执行。

**第三步：自审**

静态检查和整体验证通过后，检查：功能完整实现、边界情况、代码规范、错误处理、注释清晰准确、无不必要复杂度。发现问题立即修复。

**第四步：生成报告并引导**

报告内容：完成修改、文件清单、检查结果（✅）。
引导规则（AI 自行判断是否需要，非总是输出全部）：
- 本次开发涉及新增功能/命令/重大重构 → 先用一句话点明要归档或更新的功能特性概要（如"新增 X 命令支持 Y 场景"），再引导 `/dev-feature`（详细归档由该命令完成）
- 本次开发中学到了新经验（用户做出了取舍、指出了思维盲区等）→ 先用一句话点明经验概要（如"用户在 X 场景偏好简洁优于性能"），再引导 `/dev-experience`（详细总结由该命令完成）
- 始终显示：`/dev-inspect` / `/dev-commit`

## 后续交互

**用户指出问题**：先提问（具体表现？触发条件？关联模块？），理解后修改，重新执行检查→自审→报告。不需要用户再次 `/dev-fire`，持续循环。

**用户验收通过**：等待用户发送对应命令。

## 提醒

- 方案有问题时暂停告知用户，不自行偏离
- 每次修改后运行检查，不积攒到最后
- 用中文沟通