AI生成PRD速度飙升，我的审阅负担却越来越重
最近在审阅AI生成的PRD文档时，我常常感到一种说不出的别扭。
它写得并不差。
恰恰相反，它写得过于面面俱到了。
需求背景、业务目标、操作流程、权限设置、边界场景、界面文案，看起来应有尽有。
但我越读越疲惫。
因为我不仅要判断它"写得好不好"，还得逐句甄别：这是产品现实，还是AI基于通用经验推测出来的内容？
所以，AI写得很全面，但未必是真实情况。
这时我才意识到，AI撰写PRD最棘手的问题，并非速度太慢。
而是它写得太像那么回事了。
---
刚开始尝试用AI撰写PRD时，确实体验很棒。
需求背景、功能定位、逻辑描述、边界处理、界面文案，丢给AI后，它很快就能输出一大段看起来还挺像样的内容。
产品经理的日常工作中，本来就有很多"先把思路理清，再落笔成文"的环节。
AI刚出现时，真的像凭空多了一个不知疲倦的实习生。
后来Claude Code、Codex App、Cursor这类本地AI Agent工具问世后，我又开始进一步探索。
我不再只是打开聊天窗口，临时问AI几个问题。
我开始把一个本地项目文件夹，作为AI工作的主战场。
里面存放产品上下文、需求资料、PRD、规则、模板、工作说明。然后让AI在这个文件夹里帮我撰写需求、修改文档、做评审、完善原型。
这一步骤确实比单纯聊天更好用。
因为我不用每次都重新给AI喂大量背景信息。
但用久了以后，问题也更明显了。
AI不是不会写，它太会写了。
它会把通用经验套进真实业务场景，会补充一些看起来合情合理、但产品中根本不存在的规则，也会把我随口提到的一句话，当作既定事实写入PRD。
它输出的内容通常不是明显的错误。
而是"看起来很真"。
这才是最棘手的地方。
一个审批流程需求，如果AI不了解当前审批模块已支持哪些功能，它就无法判断这次是新增能力还是修改现有能力。
如果它不熟悉权限体系，就可能遗漏谁能配置、谁能发起、谁能审批、谁能查看。
如果它不了解当前流程状态，就可能自行杜撰一套"审批中、已通过、已驳回、已撤回"。
这些内容看起来都很在理。
但产品经理一看就明白：不具备可执行性。
这就是我后来越来越心力交瘁的原因。
AI可以给我一个快速的初稿。
但那个初稿里混杂着事实、推测、通用经验和它自行补全的逻辑。
我经常不是在修改文字，而是在判断：它这里到底了不了解我们当前产品的实际状态。
有些内容写得很流畅，但我一看就会停下来。
这些东西如果不拎出来，后面开发和测试一定会追着问。
这时我才意识到，如果AI没有稳定的工作环境，它越能写，我就越危险。
---
很多人用AI写PRD，第一反应是找更好的Prompt。
我以前也是这样。
"帮我写一个专业PRD的Prompt。"
"帮我生成一个完整需求文档的Prompt。"
"帮我用资深产品经理视角分析这个需求。"
这些Prompt都有用。
但它们只能解决部分问题。
Prompt更像一次任务说明。
它可以告诉AI：你这次要怎么写，按照什么结构写，关注哪些维度。
但产品经理真正需要的很多信息，不在Prompt里。
它们在产品上下文里。
比如当前产品的模块现状、权限边界、字段规则、状态流转、历史兼容、客户定制。
这些东西如果每次都靠Prompt临时补，就会很累。
更麻烦的是，AI也很难判断你刚刚输入的内容到底是什么性质。
一句客户反馈，是已经确认的产品事实，还是一次临时讨论？
一个方案草稿，是评审通过了，还是只是随手记下来的想法？
一个旧PRD，是现在仍然有效，还是早就被后来版本覆盖了？
如果这些边界没有分清，AI就会把所有材料都当作可用上下文。
这也是我之前踩过的坑。
一开始我以为，只要把资料都放进项目文件夹，AI就会更懂我。
后来发现，资料越多，风险也越高。
因为AI并不会天然知道哪些内容能引用，哪些内容只能参考，哪些内容已经过期，哪些内容不能写进正式文档。
所以现在我越来越觉得，产品经理用AI的关键，不只是会不会提问。
更关键的是，有没有给AI建一层稳定的Context。
这里的Context，不是随便堆资料。
它应该是一层干净、稳定、可复用的产品事实层。
它告诉AI：这个产品是什么，当前有哪些模块，核心术语怎么理解，哪些内容可以作为事实引用，哪些内容必须标记为待确认。
有了这层，AI才不会每次都像失忆一样重新开始。
也不会每次都靠通用经验瞎编。
---
我现在想搭的产品经理AI工作台，本质上就是一个本地项目文件夹。
这个文件夹可以被Codex App、Claude Code、Cursor、VSCode这类本地AI Agent工具读取和操作。
工具和模型当然重要。
但更底层的东西，是这个文件夹里的组织方式。
它不只是放资料。
它应该有产品上下文，有工作规则，有可复用Skill，也有每个具体任务自己的工作区。
如果用产品经理更熟悉的话来说，它有点像一个给AI用的"产品后台"。
AI在前台对话里帮我干活。
但它背后依赖的是这个本地工作台。
我希望它能做到几件事：
写PRD前，先知道产品定位和模块现状。
每个需求都有自己的任务文件夹，不和其他需求混在一起。
需求梳理、PRD写稿、PRD审稿、原型说明、功能沉淀，都有相对固定的流程。
PRD评审通过或者功能上线后，新的产品事实可以沉淀回context，而不是散落在某个历史文档里。
整个系统要保持精壮，不要最后变成文件坟场。
这里面最关键的词，其实是约束。
AI需要被约束住。
这里说的约束，不是限制AI不能干活。
而是告诉它：该读什么，不该乱写什么，什么时候必须问人，哪些东西只能放在workspace，哪些东西经过确认后才能沉淀进context。
人负责判断和取舍。
AI负责读取上下文、整理材料、生成初稿、发现漏项、辅助沉淀。
这才是我想要的工作台。
它不是一个万能AI产品经理。
我也不相信一套模板能替代产品经理判断。
它更像一个稳定的产品工作现场。
---
这次重构，我先把工作台拆成四层：
AGENTS.md：工作台总规则
context：产品事实层
skills：可复用工作技能
workspace：具体任务工作区
它告诉AI：你现在不是在写代码，而是在协助一个产品经理工作。你要基于产品事实输出，不能在上下文不足时瞎编，也不能未经确认就修改产品事实。
这个文件不能太长。
它不应该变成教程，也不应该变成产品百科。
它只放最稳定、最重要、每次都要遵守的规则。
我现在认为，产品经理想让AI写出靠谱PRD，最少要有产品定位、产品架构、术语表、功能模块现状这几类上下文。
但这里最关键的不是文件名，而是边界。
context最怕被过程污染。
尤其是和AI聊出来的过程。
我在讨论里临时试过的方案、当时没想清楚的判断、为了让AI理解问题补充的一堆背景，都不应该直接变成产品事实。
这些东西可以留在workspace。
但只有确认过、后面还会复用的内容，才应该进context。
因为一旦context被污染，AI后面就会把错误信息当作确定事实继续使用。
你以为只是多放了一点资料，
实际上是在污染AI后续所有任务的判断依据。
放到这个工作台里，我更愿意把Skill理解成"标准作业流程"。
每一个Skill负责一类稳定任务：什么时候启动，需要读哪些上下文，应该怎么处理信息，产出什么内容，完成后进入哪一步。
这样AI不需要每次从零理解我要干什么。
在v0.1里，我先保留几个最基础的业务Skill：
prd-thinking：需求梳理
prd-writing：PRD写稿
prd-review：PRD审稿
prototype-drafting：原型说明/低保真原型
context-update：功能沉淀
这里我最看重的是prd-thinking和prd-review。
很多PRD写得不好，前面是需求没想清楚，后面是没人认真审。
所以我的流程不会是：
一句话→AI直接写PRD
我更想把它改成：
先梳理需求
再写PRD
再独立审稿
再决定怎么改
尤其是审稿这一步，我会尽量让它独立。
最好是新开一个线程，或者用单独的审稿Skill，让AI不要带着"刚刚自己写完PRD"的作者视角去自我合理化。
PRD一次写好这件事，概率并不高。
真正有价值的是，AI能帮我发现哪里漏了，哪里边界不清，哪里开发会追问，哪里测试会卡住，哪里需要我这个产品经理重新判断。
workspace是每个具体任务发生的地方。
这里有个核心的原则：一个任务一个文件夹。
比如一个需求：
workspace/2026-Q2/REQ-001-审批流配置优化/
├── todo.md
├── 需求梳理.md
└── PRD.md
如果需要原型，再加prototype/。
如果PRD评审通过或功能上线，需要沉淀产品事实，再生成context-update.md。
这层的作用是把每个任务隔离开。
一个需求就是一个需求。
一次竞品分析就是一次竞品分析。
一次售前调研就是一次售前调研。
任务现场归workspace。
长期事实归context。
这就是我现在想要的本地项目文件夹约束管理。
---
这套工作台现在只是v0.1。
我不想一开始就把它做成一个大而全的知识库。
v0.1只先解决一条线：PRD。
因为PRD是产品经理最典型、最高频，也最容易被AI改造的一类工作。
但它也最容易被AI写废。
所以我想先拿PRD作为切入口。
最小闭环是：
最小产品上下文
→需求梳理
→PRD写稿
→PRD审稿
→按需原型
→评审通过后沉淀context
一个需求进来后，先新建一个需求工作区。
然后用prd-thinking梳理需求。
它会先读产品定位、产品架构、术语表、相关模块现状，然后帮我整理用户是谁、场景是什么、当前问题是什么、产品边界是什么、涉及哪些模块、有哪些关键规则、有哪些待确认问题。
当需求已经足够清楚，再用prd-writing写PRD。
PRD写完后，不急着发评审。
继续用prd-review做一轮冷启动审稿。
这一步，我最想让它帮我守住的是文档规范。
不是再帮我多补几个点，而是检查这份PRD有没有按模板写。
哪些内容应该进正式PRD，哪些只应该留在决策记录或沟通过程里，要分清楚。
我不希望AI把我和它讨论方案时留下的过程、取舍、猜测，全都塞进正式文档。
PRD最后是给开发、测试、交付看的，不是给人看我和AI怎么聊天的。
我看完之后，决定哪些采纳，哪些不采纳，再让AI修改PRD。
如果需要原型，再用prototype-drafting生成页面结构或低保真HTML原型。
等PRD评审通过或功能上线后，再用context-update把新的产品事实沉淀回context。
它不复杂。
甚至可以说很朴素。
但我现在越来越相信，AI工作台一开始就应该朴素。
先让一个简单系统跑起来。
然后随着真实需求一点点演化。
复杂系统不应该一开始就设计出来。
复杂系统应该从一个有效的简单系统里长出来。
---
这套工作台，我觉得更适合这类产品经理：
尤其是ToB产品经理，会更容易感受到这件事的价值。
因为ToB产品里的很多需求，真正麻烦的地方都藏在系统边界里。
组织结构、角色权限、数据范围、流程状态、字段规则、历史兼容、客户定制、交付成本···这些东西随便漏一个，PRD都可能看起来完整，但交付时却给你留下一堆坑。
当然，它也不太适合这类人：
因为AI可以帮助你写得更快。
但前提是，你得先把这些东西组织成它能读取的上下文。
另外，如果只是偶尔用AI改改文字，没必要搞这一套。
打开ChatGPT问一句就够了。
但如果你真的想让AI长期进入自己的产品工作流，光靠临时对话肯定不够。
你需要一个稳定的工作现场。
---
这篇不是一个完整教程。
它只是我重构产品经理AI工作台的第一篇记录。
我会先把PRD这条线跑通，再继续记录AGENTS.md、context、skills、workspace这些东西到底怎么写，哪些地方会踩坑。
如果你也是产品经理，也正在用AI写PRD、拆需求、做评审材料，可以先从一个很小的本地文件夹开始试。
不用一上来做一个很大的系统。
先让AI读得懂一个产品，处理好一个需求，少编一点，少返工一点。
后面我会继续把这个过程写出来。
我现在不想把它包装成一个万能模板，这不现实。
这套东西也一样，先别急着做大。
先让一个小MVP在真实需求里跑起来。
这可能就是个人AI工作台最早的样子。