以前 PM 写文档,现在 PM 交付产品本身

最近这段时间的工作和实践让我想沉淀这篇文章，在 AI 时代，PM 应该如何协作以及对应的交付物是什么。

我发现，随着 AI 更多引入到工作、生产环境中，PM 的产出物慢慢在成为可执行的交付物，而不是需要被"翻译"的中间产物，比如 PRD 不再是文档，是产品的一部分；而SKILL 不再是需求 SOP 描述，变成了生产链路中的重要一环。

而这件事情，可能又会重塑 PM 的工作范式与协作分工。

需求长在产品里

我们在尝试一种 PRD 的新形态——产品逻辑直接挂在 UI 元素上。每个按钮、每张卡片、每个进度圆，鼠标悬停时浮出一段说明：业务含义是什么、当前 mock 规则是什么、未来后端要怎么对接、颜色分别代表什么状态。

平时不显示，避免影响视觉；开发打开页面就能看到对应逻辑，不用回去翻另一份文档。

这种做法不是孤例。在不同的工种里，类似的事情正在发生——

Storybook Autodocs（组件域）：以前组件文档单独维护、容易过期；现在组件代码改一行，文档自动同步刷新——组件代码本身就是它的文档。Airbnb、Shopify、BBC 等公司已把这套机制作为组件库的工程化标准。

BDD / Cucumber（测试域）：以前 PRD → 测试用例 → 代码层层翻译；现在用 Given-When-Then 这种结构化语言写一遍，系统直接拿去跑自动化测试——需求描述本身就是可执行的测试。Capital One 等金融类公司在合规驱动下广泛采用，因为需求和测试必须严丝合缝。

OpenAPI（接口域）：以前后端写一份接口文档，前端靠人对齐字段；现在用机器可读的格式写一次，前端自动生成调用代码——接口契约本身就是协作的可执行物。Stripe、GitHub、Twilio 这些 API 优先型公司都把它作为对外提供能力的事实标准。

组件、测试、接口，三个工种都在做同一件事——信息要长在产品里，不单独躺在一份文档里。

而 PM 的 PRD，也自然可以沿着同样的路径走。

需求也可挂在 SKILL 上

同样我搭建的 SKILL 体系，也是在替代 PRD（产品方案文档）的一种形式。

每个 SKILL.md 写清楚四件事——触发条件（什么时候启动）、执行流程（分几步做）、输出格式（要什么样的结果）、质量门禁（出错怎么办）。这里承接的就是业务需求。

接着写完后不用给开发"翻译成代码"，LLM 直接读、直接执行。这里承接的是直接实现。

SKILL.md 作为一层交付物，它的能力点在于不仅包含了业务需求，而且后续业务需求发生变化，直接改 SKILL 就行，工程测都可以不用发版。

这其实是一个红利。业务变化的吸收层，从代码层下移到了 SKILL 层——从工程师的活，变成了 PM 的活。

新分工的三件事

那 PM 在新分工里具体怎么干？三件事——

第一件事：拆需求。拿到需求先按三层切——

· 背景层（为什么做、目标、版本、合规）→ 留在传统文档

· UI 行为层（界面交互、字段口径、颜色规则、状态规则）→ 挂在前端代码上

· AI 行为层（触发条件、执行流程、输出格式、质量门禁）→ 写进 SKILL.md

第二件事：用 AI 编程工具做出可运行的产物 + 把产品逻辑挂上去。

PM 不需要会写代码，但要把 AI 编程工具当成"翻译器"——

· 已有项目 → 让技术把代码复制一份给你，用 AI 编程工具打开，告诉它要改什么。比如"把进度圆改成显示剩余小时数 + 百分比双指标"，AI 自己找到位置改好，你刷新页面看效果，不对再让它改

· 新项目 → 用自然语言生成原型工具，描述需求就能出可运行原型

· AI 行为层 → 直接写一份纯文本说明文件，不写代码

视觉改完之后还有关键一步——让 AI 给每个 UI 元素加上 hover 提示，把产品逻辑写进去。业务含义、字段口径、颜色规则、后端接口依赖、当前 mock 规则，这些平时不显示，鼠标悬停才出现。

这才是 PRD 真正"挂在 UI 上"的动作——你给开发的，就是产品本身带着的注释。

第三件事：跟工程师按毛坯房 vs 精装修分工。旧分工是"PM 给文档，工程师盖楼"；新分工是"PM 给毛坯房，工程师做精装修+水电"。

· 毛坯房 = 业务逻辑已经跑通的原型 + 挂着的产品逻辑 + SKILL.md

· 精装修 = 接真实 API、加权限、做监控、抗并发、灰度发布

PRD 的内容会变

未来还会有 PRD（产品方案文档）么，我觉得还是存在的，只是内容会变。

过去写 PRD，主要是把"产品现在长什么样、改完后长什么样"一项一项铺出来给开发看。AI 时代不需要这种描述了，AI 编程工具拿到原型自己能看自己能读，这部分翻译工作被 AI 吃掉了。

而 PRD 真正要写的，变成了三件事——

· 为什么改：这次需求背后的底层判断，而非表层那句"业务需要"

· 怎么决策：方案选择的过程。为什么选方案 A 不选方案 B，背后有什么权衡

· 怎么验证：用户反馈闭环要怎么收。关键是提前定好分层应对规则——如果反馈 A 维持原方案、或者反馈 B 调整为 A+、或者反馈 C 推翻换成方案 C

PRD 本身也会按受众拆——给人看的部分讲原因和决策、给系统看的部分是 SKILL 文件里那种结构化指令。两份写法不同，但来自同一份业务理解。

PM 写的东西，会越来越成为"判断的轨迹"。

为什么值得做

这种分工的价值有三层递进。

对个人——主动权回到 PM 自己手上。

以前写完文档要等开发理解、要反复对齐，主动权可能在工程师手上。现在给的是可直接跑的产物，改完即生效。

当然要做到这个程度，对 PM 的要求一定是有的，假如方向是对的，那么如何让自己快速长出如此的能力也就是时间的问题了。

换一句话说，作为 PM，我是不是在自我迷惑我自己，让自己干更多的活，现在这个阶段也未可知。

工程师会相对省心些，不用再做"需求翻译员"，把脑力花在性能、稳定性、扩展性这些工程真本事上。

对企业——线性接力变两层并行。

旧流程是需求→文档→评审理解→代码→联调，每一个节点都可能有翻译损耗。新流程是 PM 跑智能层、工程师同步做基础设施层，两层并行。

一个需求从想法到上线，时间能压缩。更重要的是，业务逻辑由最懂业务的人直接定义和验证，避免"传话游戏"导致的失真。

对行业——PM 这个角色正在被重新定义。

以前 PM 是"会写文档的中间人"，现在是"直接交付可执行物的设计者"。AI 应用层和平台层的分工，第一次有了清晰接口——应用层做业务智能，平台层做基础设施。

AI 不只是新工具，它在重塑生产关系，开发方式走向"两层并行"的范式变化。

你那边的 PRD（产品方案文档）现在是什么状态，欢迎评论区沟通。

END

我是老贺，医疗健康+供应链双行业产品人。
正在用 AI 搭建数字分身，把干过的活沉淀成方法论。