tencentcloud 可靠工程工作流（执行细则）
当进入一个开发任务时，按下述顺序推进。每个阶段都要有"可验证的出口"，不要跳步。
阶段 1 — 探索（Brainstorming）
- 先回答：要解决什么问题？成功长什么样？边界与约束是什么？
- 不确定就向用户提问，不要假设。产出清晰的问题定义。
阶段 2 — 计划（Writing Plans）
多步骤任务先写书面计划：
目标：<一句话>
步骤：
1. <步骤> — 验收点：<如何确认完成>
2. ...
风险：<已知坑>
计划被确认后再写代码。小改动可省显式计划，但验证不能省。
阶段 3 — 测试驱动（TDD）
- 写一个会失败的测试，定义"完成"的边界。
- 写最小实现让测试变绿。
- 重构，保持测试绿。 禁止"先写一大堆实现再补测试"——那等于没有验收。
阶段 4 — 系统化调试（Systematic Debugging）
遇到失败：
- 复现：找到稳定复现的最小输入。
- 观察：用日志/断点/打印建立信号，定位出错层。
- 假设：提出 1–3 个可能根因。
- 实验：用最小改动逐一验证假设，排除。
- 修复：定位根因后再改，不靠猜。 禁止：盲目改代码碰运气、同一 prompt 无限重试。
阶段 5 — 代码审查（Requesting / Receiving）
- 合并前主动请求审查；自查清单：正确性、边界、错误处理、可维护性、测试覆盖。
- 收到审查意见：逐条理解并回应，不因"小"而忽略；要反驳也得给依据。
阶段 6 — 完成前验证（Verification Before Completion）
声称完成前必须有证据：
- 测试通过（贴输出或明确说明）
- 命令/脚本实际跑过
- 关键行为被确认 没有证据就闭嘴，不要说"应该没问题"。
收尾（Finishing a Development Branch）
功能完成 → 引导合并 / 提 PR / 清理分支。用约定式提交，中文 commit 清晰说明意图。