夜雨聆风你有没有遇到过这种情况：
接到一个老功能的改版需求，打开历史文档夹，发现里面躺着七八个文件——"收款码需求v1.2"、"收款码改版v2.0"、"收款码安全加固（紧急）"、"2024Q1迭代补充"……
你不知道哪个是最新的，不知道v1.2里的某个字段后来改没改，更不知道当初为什么要这么设计。
翻了半小时，心里大概有了个轮廓，但还是不太确定。
这是每个产品经理都经历过的痛苦。历史需求文档，是一笔被封印的资产。
问题出在哪？
传统的需求文档有三个典型问题：
一、分散。 每次迭代新建一个文档，几年下来同一个功能可能有五六个版本散落在不同文件夹里。
二、版本混乱。 "最新版"不一定真的最新，有些改动只在群里说了一句，根本没更新到文档。
三、信息过时。 文档里写的字段名、数值限制、交互逻辑，可能早就在某次迭代里悄悄变了，但没人回头改文档。
结果就是：文档越积越多，却越来越难用。
我的解法：用AI给历史文档做一次"大扫除"
去年我开始用 Trae 辅助写需求，但最开始效果不好——AI写出来的东西总感觉"飘"，跟我们产品的实际情况对不上。
后来我意识到问题所在：我给AI的上下文太脏了。
把七八个版本混乱的历史文档直接扔给AI，它也搞不清楚哪个是准的。垃圾进，垃圾出。
所以我换了一个思路：先整理，再写作。
具体怎么做？
第一步：把历史文档统一导出为 md 格式
Markdown 是纯文本，没有格式噪音，AI 读起来效率最高。我会把同一个功能模块的所有历史需求文档，按时间顺序整理成若干个 .md 文件。
比如"收款码"功能，可能对应这样几份原始文档：
收款码需求 v1.2（2022年8月）收款码改版 v2.0（2023年3月）收款码安全加固（2023年9月）收款码功能补充（2023年12月）2024Q1收款码迭代（2024年2月）内容是这样的——零散、口语化、有大量已作废的信息混在一起：
"收款码最多5个（最多5个 → v2.0放开至20个，2024Q1业务方申请改50个）""90天有效期，因商户反馈太短，后调整为180天""备注：Logo样式待UI确认"（这条早已过时）
第二步：用自定义 Skill 清理整合
这是整个工作流最关键的一步。
我在 Trae 里写了一个自定义 Skill，专门用来处理这类历史需求文档。它的核心逻辑是：
• 去重合并：同一个字段在多个版本里出现时，只保留最新的规则 • 标记废弃：识别已被后续版本推翻的内容，统一归入"已废弃/已变更"区域 • 结构化输出：按功能维度重新组织，而不是按时间线堆叠 • 保留决策记录：变更原因和背景不删，放在备注里，方便日后溯源
运行之后，七八个版本的散乱文档，会被整合成一份按功能模块组织的"最新快照"。
整理后的效果大概是这样：
收款码模块 · 功能快照整理自：v1.2 / v2.0 / 安全加固版 / 2023Q4补充 / 2024Q1迭代
核心功能
• 商户最多可创建 20 个收款码（v1.2初始为5个 → v2.0放开至20个，2024Q1业务方申请改50个，暂未调整） • 收款码名称：支持中英文，最多20字符（v1.2称"备注名称"，v2.0统一改为"收款码名称"） • 支持下载为PNG图片
安全机制
• 动态水印：商户ID + 时间戳 • 有效期：180天（初版90天，因商户反馈后调整） • 支持手动刷新、到期前提醒
已废弃/已变更
看出差别了吗？
整理前：信息分散在五个文件里，需要自己交叉比对，搞清楚"哪条是现行规则"。
整理后：每个字段只有一条最新结论，历史变更有迹可查，废弃内容单独列出不干扰主体。
第三步：以这份"快照"为基础，写新需求
有了这份干净的上下文之后，我再去跟 Trae 对话写新需求，效果完全不一样。
AI 知道当前字段叫什么、限制是多少、哪些逻辑已经废弃——它不会再写出已经不存在的"备注名称"，也不会把有效期错写成90天。
这就像你给一个新同事做入职培训，给他一份整理好的功能手册，和给他一堆未经整理的历史版本文档，效率差距是显而易见的。
这套工作流帮我节省了什么？
时间上：以前接手一个老功能，光是"理清现状"就要花半小时到一小时。现在跑一遍 Skill，五分钟出结果。
质量上：写出来的需求文档更准确，少了很多"这个字段到底叫什么""这个限制还在不在"的低级错误。
心理负担上：不再害怕接历史包袱重的老功能了。历史文档越多，这套工作流越有价值。
小结
在用AI写需求之前，先用AI整理需求。
上下文的质量，决定了AI输出的质量。给AI一份乱七八糟的历史文档，它帮不了你多少。但给它一份经过整理的功能快照，它就能真正成为你的助手。
