AI写PRD越来越不靠谱，我决定重新构建产品经理AI工作台

用AI 写 PRD，真正让人头疼的不是它不会写。

让人头疼的是，每次开始一个新对话，我都要先临时搭建一次现场。

我要把这次需求要解决什么问题、当前功能是什么情况、这次希望它帮我做什么、验收标准是什么、有哪些边界不能乱动，一大段一大段发进去。

发少了，它就只能靠通用经验补。

发多了，我自己又要先花很多时间整理上下文。

最后看起来是我在让 AI 写 PRD，实际上我是在反复给 AI 搭一个临时工作台。

它当然能写。

如果产品上下文已经准备好，需求也梳理清楚了，我会直接让它写，而且它会写得很快。

但在没有稳定工作现场的情况下，它写得越快，问题也会越隐蔽。

它可以很快写出一份看起来完整的文档。

但字段规则可能是编的，权限边界可能是泛化的，状态流转可能和真实产品不一致，异常情况也可能只是套了一层通用经验。

最后看起来是 AI 帮我省了时间，实际上只是把判断、删改和纠偏的压力转移给了我自己。

所以我要改的不是"让不让 AI 写 PRD"。

而是不再每次临时拼一大段上下文。

我要先给 AI 一个稳定的产品工作现场，再让它写。

我真正想要的状态，是以后我再说"帮我写一份 PRD"时，AI 已经知道该读哪些上下文、当前需求在哪个任务里、哪些边界不能乱补。

所以我最近决定重新搭一遍自己的产品经理 AI 工作台。

这次我不想再把 AI 当成一个临时聊天窗口，也不想继续研究更长的 Prompt。

我想解决的是另一个问题：

怎么让 AI 进入一个稳定的产品工作现场。

它要知道这个产品是什么，有哪些模块，术语是什么意思，当前需求属于哪个任务，哪些内容可以当成事实，哪些只是讨论，什么时候必须停下来问我。

这篇文章就是这个工作台 v0.1 的开头。

先不做大而全。

只先跑通一条最小链路：需求梳理 -> PRD 写稿 -> PRD 审稿 -> 按需原型 -> 功能沉淀。

我对 AI 的使用大概经历过三个阶段。

第一阶段是兴奋。

那时候只要 AI 能帮我写点东西，我就觉得很神奇。周报、需求背景、会议纪要、产品文案、竞品分析，只要丢进去，它都能很快给我一个初稿。

第二阶段是依赖。

很多以前需要自己慢慢组织语言的工作，我开始习惯先让 AI 起草。产品经理很容易进入这个状态，因为我们每天都要把脑子里的判断写成文档。

第三阶段是疲惫。

因为我发现，AI 很能写，但它不一定真的懂我的产品。

它可以帮我分析需求，但不知道我们产品现在支持什么、不支持什么。

它可以帮我补异常情况，但不知道现有权限体系、流程状态和交付成本。

它可以写一份 PRD，但里面很多内容需要我一条一条判断，因为他写的很多东西都与我目前的功能现状不符合。

问题就出在这里。

AI 写得越快，我反而越需要检查它哪里写错了。

这已经不是在用AI提效了，这是把审核压力全都到我这边了。

我之前的工作台也有类似问题。

文件夹里资料越放越多，规则越写越散，历史讨论、草稿、产品事实和临时判断混在一起。AI 一会儿读这个，一会儿漏那个，有时候还会把一个未确认的想法当成后续任务的事实。

最典型的几个症状是：

这时候我才意识到，问题可能不在某一个模型，也不在某一句 Prompt。

真正要处理的，是本地项目文件夹这一层的约束管理。

换句话说，AI 需要一个产品经理工作场景里的工作现场。

很多人用 AI 写 PRD，第一反应是去找更好的 Prompt。

这个很正常，我以前也这样。

"帮我写一个专业 PRD 的 Prompt。"

"帮我生成一个完整需求文档的 Prompt。"

"帮我写一个资深产品经理分析需求的 Prompt。"

这些东西有用，但作用有限。

因为 PRD 不是单纯的文本生成任务。

PRD 背后是产品当前事实、业务规则、用户场景、权限边界、字段逻辑、状态流转、系统约束和交付成本等等。

这些东西不在 Prompt 里。

它们在产品上下文里。

Prompt 更像一次临时说明。

Context 才是产品现场。

一个审批流需求来了，AI 不能只知道"帮我写审批流 PRD"。

它得知道当前审批流模块已经支持什么，这次是新增能力还是改已有能力，谁能配置，谁能发起，谁能审批，谁能查看，审批中、已通过、已拒绝、已撤回这些状态在产品里到底怎么流转。

如果这些都不知道，它只能靠通用经验补。

而产品经理最怕的，恰恰就是 AI 补得很像真的，自己一看，全是漏洞。

所以，产品经理用 AI 的关键不只是你会不会提问，而是有没有给 AI 一个稳定的 Context 层。

这个 Context 层至少要告诉 AI：

当这些东西被组织起来，AI 才不会每次都像失忆一样重新开始。

我现在理解的产品经理 AI 工作台，就是一个本地项目文件夹。

这个文件夹可以被 Codex App、Claude Code、Cursor、VSCode 这类本地 AI Agent 工具读取和操作。

用哪款工具、用什么模型，当然重要。

但更底层的是：这个文件夹到底怎么组织。

它不应该只是一个资料堆。

它应该有产品上下文，有工作规则，有可复用流程，有每个具体任务自己的工作区。

如果用产品经理更熟悉的话来说，它有点像一个给 AI 用的"产品后台"。

AI 在前台对话里帮我干活，但它背后依赖的是这个本地工作台。

我希望它至少能做到几件事：

这不是一个"万能 AI 产品经理"。

我也不相信一套模板能替代产品经理判断。

它更像一个让产品经理和 AI 协作的工作现场。

我负责判断和取舍。

AI 负责读取上下文、整理材料、生成初稿、发现漏项、辅助沉淀。

第一版我不想做复杂。

先拆成四层就够了：

AGENTS.md：工作台总规则

context：产品事实层

skills：可复用工作流程

workspace：具体任务工作区

AGENTS.md就像这个工作台的总说明。

它告诉 AI：

这个文件不能太长。

它不应该变成教程，也不应该变成产品百科。

它只放最稳定、最重要、每次都要遵守的规则。

这是整个工作台最核心的一层。

产品经理想让 AI 写出靠谱 PRD，最少要给它四类上下文：

1. 产品定位

2. 模块地图

3. 术语表

4. 功能模块现状

对应到文件结构，大概是这样：

context/

├── 01-产品定位.md

├── 02-产品架构.md

├── 03-术语表.md

└── 04-功能模块/

01-产品定位.md负责告诉 AI：这个产品是什么，为谁服务，边界在哪里。

02-产品架构.md负责告诉 AI：一个需求来了以后，应该判断它涉及哪些模块。

03-术语表.md负责告诉 AI：这些术语在我们产品里是什么意思，避免 PRD 里概念混乱。

04-功能模块/负责记录每个功能模块当前已经有什么能力、规则、权限、状态、字段和异常。

这里最关键的是：

context 只放稳定、已确认、可复用的产品事实。

草稿不放。

猜测不放。

临时客户定制不放。

评审中还没确认的内容不放。

因为一旦 context 被污染，AI 后面就会把错误信息当成确定上下文继续使用。

这也是我之前踩过的大坑：一开始什么都往项目文件夹里塞，好像上下文很丰富。

后来发现，AI 并不会天然知道哪些是事实，哪些只是讨论。

所以 v0.1 我想反过来做。

先把 context 层做薄，做准，再让 AI 按规则读取。

现在大家都在聊 Skill，这个工作台也不例外。

但对产品经理来说，Skill 不应该只是一个很炫的工具名

它更像标准作业流程。

每一个 Skill 只负责一类稳定任务：什么时候启动、需要读哪些上下文、产出什么内容、完成后进入哪一步。

v0.1 里，我先保留 5 个业务 Skill：

1. prd-thinking：需求梳理

2. prd-writing：PRD 写稿

3. prd-review：PRD 审稿

4. prototype-drafting：原型说明 / 低保真原型

5. context-update：功能沉淀

还有一个元技能：

workbench-setup-maintenance：工作台初始化和维护

这里我最看重的是prd-thinking和prd-review。

因为很多 PRD 写得不好，不是因为 AI 写得慢，而是前面没想清楚，后面没人认真审。

我的流程不会是：

一句话 -> AI 直接写 PRD

而是：

先梳理需求

再写 PRD

再独立审稿

再决定怎么改

尤其是审稿，我倾向于尽量独立。

最好是新开一个线程，或者用单独的审稿 Skill，让它不要带着"刚刚自己写完 PRD"的作者视角去自我合理化。

AI把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

一个需求进来后，不直接让 AI 写 PRD。

第一步，先新建一个需求工作区。

第二步，用prd-thinking梳理需求。

它会先读产品定位、模块地图、相关模块现状，再帮我整理用户是谁、场景是什么、当前问题是什么、目标结果是什么、边界是什么、关键规则是什么、还有哪些待确认问题。

第三步，当需求已经足够清楚，再用prd-writing写 PRD。

第四步，PRD 写完后，不急着发评审。

我会用prd-review做一轮冷启动审稿。

我看完之后决定哪些采纳，哪些不采纳，再让 AI 修改 PRD。

第五步，如果需要原型，再用prototype-drafting生成页面结构或低保真 HTML 原型。

第六步，等 PRD 评审通过或功能上线后，再用context-update把新的产品事实沉淀回 context。

这才是完整链路。

它不复杂。

但它能把一件事讲清楚：AI 不应该直接越过产品经理判断，替你生成一个看起来很完整的 PRD。

它应该先进入产品现场，再帮你完成执行环节。

我觉得它适合这类产品经理：

不太适合这类人：

AI 时代，AI 确实能让产品经理提效。

但前提是，产品经理自己要知道这件工作到底长什么样。

你不能把所有判断都丢给 AI。

你要先给 AI 一个清楚的工作现场，然后让它在这个现场里帮你干活。

如果你也想做一个产品经理 AI 工作台，我建议先别急着收集一堆资料。

先做 4 件事就够了。

第一，写一份很短的AGENTS.md。

只写 AI 每次都必须遵守的规则：基于事实输出、上下文不足要提问、未经确认不能修改产品事实。

第二，建一个最小context/。

先放产品定位、模块地图、术语表和一个核心模块现状。

不要一开始就把历史文档全塞进去。

第三，固定 PRD 工作流程。

至少拆成需求梳理、PRD 写稿、PRD 审稿三步，不要一句话直接生成 PRD。

第四，给每个真实需求建一个workspace/。

任务现场和长期事实分开。

讨论、草稿、临时判断都留在 workspace。

只有评审通过、上线确认、后续可复用的内容，才进入 context。

这篇文章只是开头。

后面我会继续记录这个工作台从 v0.1 一点点搭起来的过程，包括：

最后再把这件事说简单一点：

AI 写 PRD 不稳定，不一定是因为 AI 不够聪明

是因为它没有进入真实的产品现场

AI 负责执行，人负责判断。

这样 AI 才不是在聊天，而是在真正参与产品经理的工作流。