需求碰撞与对齐

要解决什么问题

需求文档写完后直接开工，常见结果是实现路径与产品预期不一致：边界没写清、状态流转漏了一步、和现有代码假设冲突。返工往往不是因为写得少，而是理解偏差在开发中期才暴露。

本技能面向「正式开发之前」的一次对齐：把文字需求、功能点梳理（若有）和仓库里的真实实现放在一起读，先推演能不能闭环，再决定是开工还是回到文档澄清。

技能如何工作

输入会自动区分两种场景：

• 双文档模式：同时有「功能点梳理文档」和「需求文档」时，按梳理文档里的代码位置去读实现。
• 单文档模式：只有需求文档时，用需求里的关键词在工程里搜相关代码、配置和类型定义。

核心步骤是四段式流程：

1. 全量阅读：不跳过章节和附录里的细节。
2. 代码关联：把需求条目落到具体文件/模块，避免「文档说法」和「代码现状」各说各话。
3. 逻辑推演：沿着实现路径检查数据流、状态变化、边界与异常路径是否自洽。
4. 结论输出：逻辑完整则给出可开工的确认；有断层则逐条列出疑点，并尽量标明文档章节或代码位置。

输出上只讨论当前需求范围，不主动塞优化建议；最终结论必须是「可以开始」或「需要澄清」之一。

适用边界

• 依赖你能提供可读的需求材料；单文档模式下需要 Agent 能访问当前工程代码。
• 它做的是分析与对齐，不替代评审会、不代写 PRD，也不保证业务优先级判断。
• 疑点列表需要人来回澄清；澄清后应重新跑一轮对齐，而不是把首轮结论当终稿。