engineering-workflow

name	engineering-workflow
description	可靠工程工作流的执行细则——探索→计划→TDD→系统化调试→代码审查→完成前验证。供方法论教练在开发任务中逐步引导。
metadata	{"octop":{"emoji":"🛠️","label":{"zh":"工程工作流","en":"Engineering Workflow"},"summary":{"zh":"按探索、计划、TDD、调试、审查与验证逐步推进开发。","en":"Guide development through explore, plan, TDD, debug, review, and verify."}}}

可靠工程工作流（执行细则）

当进入一个开发任务时，按下述顺序推进。每个阶段都要有"可验证的出口"，不要跳步。

阶段 1 — 探索（Brainstorming）

• 先回答：要解决什么问题？成功长什么样？边界与约束是什么？
• 不确定就向用户提问，不要假设。产出清晰的问题定义。

阶段 2 — 计划（Writing Plans）

多步骤任务先写书面计划：

目标：<一句话>
步骤：
  1. <步骤> — 验收点：<如何确认完成>
  2. ...
风险：<已知坑>

计划被确认后再写代码。小改动可省显式计划，但验证不能省。

阶段 3 — 测试驱动（TDD）

1. 写一个会失败的测试，定义"完成"的边界。
2. 写最小实现让测试变绿。
3. 重构，保持测试绿。 禁止"先写一大堆实现再补测试"——那等于没有验收。

阶段 4 — 系统化调试（Systematic Debugging）

遇到失败：

1. 复现：找到稳定复现的最小输入。
2. 观察：用日志/断点/打印建立信号，定位出错层。
3. 假设：提出 1–3 个可能根因。
4. 实验：用最小改动逐一验证假设，排除。
5. 修复：定位根因后再改，不靠猜。 禁止：盲目改代码碰运气、同一 prompt 无限重试。

阶段 5 — 代码审查（Requesting / Receiving）

• 合并前主动请求审查；自查清单：正确性、边界、错误处理、可维护性、测试覆盖。
• 收到审查意见：逐条理解并回应，不因"小"而忽略；要反驳也得给依据。

阶段 6 — 完成前验证（Verification Before Completion）

声称完成前必须有证据：

• 测试通过（贴输出或明确说明）
• 命令/脚本实际跑过
• 关键行为被确认 没有证据就闭嘴，不要说"应该没问题"。

收尾（Finishing a Development Branch）

功能完成 → 引导合并 / 提 PR / 清理分支。用约定式提交，中文 commit 清晰说明意图。