夜雨聆风Part1：四大困惑
这套“文档驱动代码，代码反哺文档”的闭环，在单个功能上跑得非常顺。但产品迭代了几个版本后，问题开始暴露：
困惑一：文档数量爆炸，管理成本飙升故事地图、需求文档、需求卡……随着产品不断迭代，这些文档的数量线性增长。每次打开项目文件夹，面对越来越长的文件列表，我开始陷入“找文档”和“担心漏文档”的焦虑中。
困惑二：缺少一张“产品地图”，AI看不懂关联每次启动一个新模块的开发，我都得手动把之前分散在各个需求文档里的上下文、已经实现的代码路径、模块间的依赖关系喂给AI。AI很聪明，但如果没有一张完整的产品需求架构图，它无法快速判定“当前这个新需求”和“已实现的代码”是什么关系——是扩展、修改，还是冲突？
这种感觉有点像， 之前的Rules，需要将所有的Rules给到AI，消耗token（费用是一方面）， 速度是另一方面， 最后是，对产品们自己查阅也是一个点
困惑三：发版实践文档，我不想再手写每个版本发版，都要手动梳理变动、编写《发版实践文档》。这几乎成了每个迭代（大的版本上线）最枯燥的体力活。我多希望AI能基于产品需求架构，自动生成这些文档啊！
困惑四：多人协作时，需求文档的“合并”比代码还难一般来说， 一个团队/项目不止一个规划人员。代码有Git可以自动合并，但需求文档呢？很多时候不是简单的行级冲突，而是语义层面的分歧——你说订单详情页要有发票入口，我说要放在个人中心。这怎么合并？
这四个困惑，让我开始怀疑：是不是我走错了路？传统开发模式里，需求文档不是“用完即弃”吗？在AI时代背景下，有没有要做全量需求管理呢？
Part2：定心丸
带着这些问题，我向一位长期研究AI+产品工程的外部专家请教。他的分析让我豁然开朗，也坚定了继续探索的信心。
一：全量管理方向正确，但要“分层+压缩”专家明确告知：在AI驱动的开发时代，全量管理产品需求是正确的方向。因为AI需要了解一个功能的“进化背景”——为什么从A改成B？为什么某个校验规则被删除了？这些决策若不保存，AI可能重新引入已被否决的方案。
但“全量”不等于“全部细节”。他给出的分层策略非常实用：
战略层（产品愿景、用户目标）：变化慢，永久留存。
战术层（功能模块、主要流程）：AI主要交互对象，状态化管理。
细节层（字段、校验规则）：变化快，以代码为源，需求图谱只记录“存在该细节”而不保留全文。
同时，引入状态化（规划中→已上线→已弃用→已删除）和定期压缩（将上线超1年的功能压缩成摘要）——这能有效避免文档沼泽。
二：用“产品需求架构图谱”代替“文档集合”我的核心问题是缺乏一个机器可读、可推理的产品模型。专家建议从“管理文档”转向“管理一个YAML/JSON格式的需求图谱”。
在这个图谱里，实体是：用户角色、业务能力、功能模块、UI页面、API端点……关系是：包含、依赖、冲突、实现为……然后通过脚本或AI Agent，在新需求进来时，先查询图谱中相关模块的依赖关系，再作为上下文喂给AI（Cursor）。这让AI瞬间从“盲人摸象”变成了“导游带路”。
三：被动废弃的需求，标记后移出主图谱关于“历史需求被移除后如何处理”的追问，专家给出了清晰的原则：不物理删除，而是“标记状态 + 记录移除影响 + 移出AI活跃上下文”。
也就是说，当某个功能下线时，在产品架构图谱中将其状态改为 removed，并附上移除原因、影响范围。然后AI在默认任务中会自动过滤掉这些实体，只有当开发者显式查询“历史上是否有类似做法”时，才会被检索。这样既保留了决策知识，又不会让AI带上历史包袱。
Part3：怎么调整？
专家的分析让我看到了从“能跑”到“好跑”的进化路径。我计划分四步走：
第一步（轻量级改良） ---部分已具备在当前Cursor项目中，为每个需求文档/卡增加YAML frontmatter元数据区，包含关联代码路径、依赖需求ID。这立即让AI可以通过读取文件元数据建立初步关联。
第二步（构建核心图谱）手动或半自动构建一个核心功能模块的“产品需求架构图谱”示例（YAML），覆盖一个完整的小功能。用脚本实践“图谱查询+AI生成代码”的流程，验证效果。
第三步（纳入版本控制）将图谱文件纳入Git管理，编写简单的PR冲突检测脚本（例如检测是否有两个PR同时修改了同一个实体）。然后推广给团队第二位规划人员使用，观察协作模式。
第四步（发版自动化）基于图谱和Git历史，开发发版文档生成脚本。目标：输入版本号，一键输出包含新功能、优化、问题修复、已知问题的可发布文档。
Part4：从“用完即弃”到“知识资产”
这次深入的复盘，让我重新认识了“需求文档”这四个字。在AI时代，它们不再是项目结束就丢进废纸篓的产物，而是团队和AI共同进化的“知识资产”。
传统模式下需求文档“用完即弃”，根本原因有两个：
维护成本>收益：文档与代码割裂，同步成本极高。
缺乏高效检索/演化机制：没有AI，历史需求很难被再次利用。
但在 AI驱动的开发环境 中，情况完全改变：
AI需要“进化背景”：一个按钮为什么从左边移到右边？某个校验规则为什么被删除？这些决策若不留存，AI可能重新引入已否决的方案。
需求是测试与回归的依据：全量管理意味着每一个已实现的功能都能追溯到验收标准，这对自动化测试生成至关重要。
团队知识永不流失：多人协作时，新成员或新AI可通过历史需求快速理解系统演化逻辑。
当产品需求被结构化、版本化、图谱化管理后，AI不只是一个代码生成器，更可以成为产品的“协作者”——它能帮你梳理演化脉络、预测变更影响、自动沉淀发版说明。
这条路才刚刚开始，但每一步调整都让我离“更聪明的AI工作流”近了一点。如果你也在探索产品规划的AI新范式，欢迎评论区聊聊～
