侦察驱动开发工作流

解决代码探索与方案设计的脱节

很多开发者在面对陌生代码库或长期维护的项目时，容易跳过前期的“摸底”，直接切入需求分析和方案设计。这种直接拍脑袋的做法极易踩中隐藏的依赖雷区（比如某张表或某个工具函数在多个模块中被复用）。当在实施阶段才发现这些连锁反应时，往往需要付出高昂的返工成本。侦察驱动开发工作流（Recon-Driven Development）正是为了填补这一空白，强制要求在动需求、写方案之前，先对本次改动波及的现有代码进行一次有锚点、有事实支撑的定向侦察。

自包含的五阶段线性流水线

该工作流的核心是一个严格线性、不设回流的五阶段流水线。每个阶段产出的产物都会落入本次改动目录下的 docs/recon-driven-dev/ 中，且阶段末尾强制暂停，等待用户确认后才能推进。

• ① 定向分析：动工前的“摸底”阶段。只摆现状事实，不作方案建议。产出 directed-report.md 作为后续阶段的参考起点。此阶段设有一道主会话实测门，要求主会话亲自利用只读工具对报告中的“未核验”推断进行真实值比对。
• ② 需求与设计：基于定向报告，内联对话产出 requirements.md 和 design.md。遇到实质性不确定或分叉时，绝不静默拍板，而是向用户提问或记录 ADR。此阶段设有硬闸：在用户批准设计前，绝不写任何实现代码或脚手架。
• ③ 可选评审：据 ①② 的信号决定是否派发一个上下文隔离的评审子代理。它只看被评审的主张，做定点源码核验，产出 review.md。
• ④ 写计划：将设计拆解为小而独立、可验证的任务，并排好依赖序。需在此阶段决定执行方式是内联还是每任务一个新子代理。
• ⑤ 实施与归档：在隔离工作区（如 Git Worktree）中按计划落地，强制先写失败测试（TDD），最后收尾归档。

适用边界与运行约束

这个技能的护栏同样严格。流程线性不回流，唯一的例外是“事实订正”——当后续阶段用证据推翻了 directed-report.md 中的某条事实时，只能在原文条目正下方追加订正块并标记 [已订正]，绝不重做整个侦察过程。此外，派发子代理时必须确保其冷启动，不继承主会话的上下文历史，以保证隔离评审的新视角。对于需要严格控制变更爆炸半径、强调文档留痕和多重质量门禁的复杂工程任务，它是一套极具工程纪律性的工作框架。