给大家分享我最近做的两个 Skills，都是围绕产品经理日常工作里最烦人、但 AI 又很难帮上忙的场景。
一个是**产品定型 Skill**，帮助产品经理把一个还比较模糊的想法，通过几轮问题澄清，逐步整理成一份结构清晰的产品定型文档。
另一个是**PRD 写作 Skill**，帮助产品经理基于已经明确的产品方向，分模块、分轮次写出一份更细致的 PRD。
这两个 skills 在分享给少部分同学体验后受到一致好评
两个 Skills 的获取方式在文末了，着急的可以直接先去找获取方式。
下面简单介绍一下这俩 skills 的使用和开发思路。
这两个 Skills 之所以好用，是因为没用那种“套一堆模版，输入一句话，生成一大篇文档”的方式。
而是极致的把 https://www.53ai.com/news/LargeLanguageModel/2024052823549.html 的作业过程强行分成多个小步骤，以最大化利用 LLM 的注意力。
* * *
## PM-Make：把模糊需求变成产品定型文档
适用于以下产品设计过程中最常见的情况：
* • 有一个大概的产品想法
* • 业务方说了一堆背景，但边界不清楚
* • 老板说“先出个方案看看”
* • 用户需求听起来很真实，但落到页面、流程、规则时又很模糊
* • 如果直接写 PRD，很容易越写越散
PM-Make 不负责写 PRD，只帮你做需求澄清：**把模糊需求定型。**
我在 skill 的最开始增加了一个强制初始化作业空间的步骤，它会在接到需求后，先创建 6 个文档：
* •`shaping/00-intake.md`
* •`shaping/01-product-shaping.md`
* •`shaping/02-jtbd.md`
* •`shaping/03-scope.md`
* •`shaping/04-pages-and-flows.md`
* •`shaping/05-open-questions.md`
然后它会读取其中的`shaping/00-intake.md`和`shaping/01-product-shaping.md`，按照模板文档的要求，把你已经收集到的信息先填进去。
有信息的地方就补上，没有信息的地方不会乱编，而是保留`[待确认]`。
这个小设计很重要的。
LLM 最大的臭毛病就是太会写了。
它会把不确定的信息写得很像真的，导致我们看着很顺，但其实里面已经混进了很多未经确认的假设。
这些假设会在之后更长的 PRD 写作里无限积累，最后变成一大堆不可用的废话。
然后 Agent 会跟你做第一轮澄清，抛出 3-5 个需要确认、澄清的问题。
一次不能抛太多，多了反倒影响思考。
尤其是在需求早期，我们其实自己也没想清楚。如果一上来丢给他一大堆问题，反倒是在制造压力。
每轮问题都围绕当前最缺的关键信息来问，而不是机械地把所有维度都问一遍。
问完之后，回答一段自然语言就可以，不需要严格按照表格格式。
然后 Skill 会根据回答更新 01-05 那五个文档。
根据需求的复杂度，问个 2-3 轮觉得信息收集齐了，才会去完成最后`06-shaped-brief.md`文档描述。
信息不只在最后一个文档里，00-05 的六个文档是细化的内容，也会在你澄清的过程中同步更新。
详细的澄清边界和问题约束，在`PM-Make/references/shaping-playbook.md`里面，可以按需自定义。
最后输出的定型摘要大概会包括：
* • 产品定位
* • 目标用户
* • 核心场景
* • 用户当前替代方案
* • 核心价值
* • MVP 范围
* • 核心流程
* • 页面结构
* • 关键业务规则
* • 仍待确认的问题
这一步更像是产品开发前的“对齐仪式”。
它的价值在于，大家可以先确认：
* • 我们是不是在做同一个产品？
* • 这个产品的边界是不是清楚？
* • 现在的信息够不够进入 PRD？
* • 哪些问题还不能假设，需要继续确认？
确认之后，这份产品定型文档有两个用途。
第一，它可以作为后续写 PRD 的基础。
第二，它其实也是一个非常好的 Coding Agent 提示词。
关于第二点，很多产品经理直接把 PRD 丢给 Codex 或者 WorkBuddy 写产品，写出来的东西稀烂。会有大量不可交互、奇奇怪怪的约束，甚至很多地方都是 mock 的。
核心原因在于 PRD 里的功能模块又多又细，每个功能之间又相互关联影响，导致 Agent 的注意力完全被搞崩溃。
这个定型文档做Vibe-Coding 的提示词已经验证完全没问题，我自从使用它作为产品开发需求开始，**所有产品都是一稿过**，全程什么都不需要修正、补充
* * *
## PRD-Make：写 PRD，但不让 AI 一次写完
第二个 Skill 看名字就知道是用来写 PRD 的。
它的思路其实很简单：
**不要让 LLM 一次性写完整篇 PRD。**
大家大概率这么用过：
> 请你根据下面的信息，帮我写一份完整 PRD。
然后模型会输出一篇很长的文档，看起来结构完整，但很多地方其实很粗。
这不是因为 LLM 不行，而是因为一次性生成太多内容时，它的注意力会被摊薄。
所以这个 PRD Skill 的核心策略是：
**先制定写作模块计划，再按顺序一个一个写完。**
每写完一个模块后，先让你确认、修改或补充，再继续下一个模块。
为了让 Agent 能严格遵循每轮作业只写一个模块，我给它加了两层约束：
* • 每写完一个模块，更新`_module-plan.md`的状态
* • 我确认没问题后，更新`_append-log.md`的确认状态
这个过程会慢一点，但可以确保 LLM 的每轮注意力聚焦在一个板块上，且可以享受吃满每次请求的`max_tokens`，整体交付的质量也就会高很多。
## 一些碎片想法
产品经理使用 AI，不应该再只聚焦在“生成”这两个字上，更多应该是在理解了原理后的“约束添加”。
榨干 AI 的 max_tokens ，还是为它提供详尽的上下文，以“服务者”的姿态释放 AI 的价值？
当 LLM 被塞进 Agent 循环，很多事情会变得有意思：你既要看它整体的效能提升，又要钻到它每一个“断点”里找风险和机会。
一次能完成超长程任务是“整体效能提升”，但每一个“断点”处都可能累加一个错误，同时也是你去发挥“产品 sence”的机会
skills 是毋容置疑的下一代产品，就像过去的 PC 应用要有一个移动端 App 一样。
不只是让 UI 自适应，应该围绕手机的特点提供点什么 —— 但不要像 iPhone 开屏广告一样作恶。
Agent 的底层虽然是非常简单的“Loop + Tools”，但它是“带脑子的循环”。
“带脑子的循环”是一个非常有破坏性的产品形态：“带脑子”改变了“规则”这件事，“循环”把“一生二、二生三、三生万物”给卷进来了 —— “日拱一卒，万事可成”。
AI 改变的是用户完成任务的方式，它不是大数据、区块链那样的单点技术，只要行业不涉及完全不影响职业生涯。
但如果你不是真的懂 AI，就无法判断哪些任务可以被 AI 改写、哪些体验应该被重构、哪些产品会被 AI 原生产品替代 —— 完蛋源自于此。
我最近每周末在`深圳-北京-上海`三个城市循环开线下课，会用 2 天的时间完成**产品经理对 AI 理解的全面塑造**
目前深圳第一场已结营、北京第一场已满员，**上海第一场还有少量名额**。
| 城市 | 时间 | 状态 |
| — | — | — |
| 深圳-1期 | 6月27-28日 | ✅已结营 |
| 北京-1期 | 7月4-5日 | 🔴已满员 |
| 上海-1期 | 7月11-12日 | 🟡少量名额 |
| 北京-2期 | 8月1-2日 | 🟢招募中 |
| 深圳-2期 | 8月15-16日 | 🟢招募中 |
| 上海-2期 | 8月22-23日 | 🟢招募中 |
两天课程会涵盖从会用 AI、到设计 AI 产品的全部关键技能，全程**不会干巴巴的讲概念**，而是从一系列实操任务入手，完成“干中学”。
详细课程教学内容和安排，可以扫码查看课程详情页了解。
需要提醒的是：
课程~~原价 3999~~，**早鸟价 2999**
**早鸟优惠会在第一期招生结束后结束。**
* * *
最后，这两个 Skill 现在也还不太完美。
比如有时候它问的问题还是会有点偏泛；有时候如果你回答得太散，它也可能跟你一起糊弄事洋洋洒洒的胡编。
但整体用下来，已经能明显减少从“一个想法”到“一份可协作产品文档”之间的摩擦。
尤其是当产品经理不是在写给自己看，而是要写给设计、研发、业务方，甚至 Coding Agent 看时，结构化和边界感会变得特别重要。
两个 skills 的压缩包我已经放在 AI 学习行动圈知识星球了，扫码领券、加入后分别搜索`PM-Make`和`Make-PRD`即可下载使用。
