给大家分享我最近做的两个 Skills，都是围绕产品经理日常工作里最烦人、但 AI 又很难帮上忙的场景。
一个是产品定型 Skill，帮助产品经理把一个还比较模糊的想法，通过几轮问题澄清，逐步整理成一份结构清晰的产品定型文档。
另一个是PRD 写作 Skill，帮助产品经理基于已经明确的产品方向，分模块、分轮次写出一份更细致的 PRD。
这两个 skills 在分享给少部分同学体验后受到一致好评
两个 Skills 的获取方式在文末了，着急的可以直接先去找获取方式。
下面简单介绍一下这俩 skills 的使用和开发思路。
这两个 Skills 之所以好用，是因为没用那种“套一堆模版，输入一句话，生成一大篇文档”的方式。
而是极致的把 Agent 的作业过程强行分成多个小步骤，以最大化利用 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 原生产品替代 —— 完蛋源自于此。
