AI 工具如何彻底改变产品经理的工作流？本文深度拆解从需求文档撰写到上线公告、工作量评估及产品方案设计的四大核心场景，揭示如何通过 Skills 将经验固化为可复用的能力模块。不同于简单的提示词技巧，关键在于如何定义标准、反复调试并嵌入真实工作流程，实现从10%到翻倍的效率跃升。

在之前那篇文章里，曾提到过用 AI 提效的“三步曲”。

第一步，是把 AI 当搜索引擎，效率大约提升 10%。这一步很多人已经很熟了，用豆包、DeepSeek 之类的工具查资料、找答案，确实比传统搜索更快，但提升往往有限。

第三步，是把 OpenClaw 当作“实习生”来用，效率可能直接翻倍，但对应的时间成本、学习成本和经济成本也不低。它更像是一种更彻底的工作方式改造，不太适合大多数人一上来就直接进入。

真正值得大多数产品经理认真做的，其实是第二步：用合适的 AI 工具，把自己的工作流拆解成原子化的 Skills。

上次主要分享的是，怎么用 Skills 高效完成 50 个客户案例 PPT。今天继续沿着这个主题往下走，不过这次不讲客户案例，而是回到产品经理最日常、也最真实的工作场景里，聊聊一件更重要的事：

如何用 Skills，高效完成产品经理的工作？

如果你是做 B 端产品的，对下面这条工作流应该不会陌生：需求管理、需求优先级判断、产品规划、竞品调研、客户需求调研、设计产品方案、评估工作量、绘制原型、写 PRD、评审、项目管理、上线、上线培训、写上线公告、收集反馈……

看上去每个环节都重要，但真正要下手改造时，千万别想着一口气全做完。改变工作流从来不是一件容易的事，更不是装一个工具、写几句提示词就能立刻见效。

更现实的做法是：先僵化，再固化，然后再优化。

说白了，就是先挑那些高频、重复、相对标准化的环节，固定下来反复用，等跑顺了，再慢慢扩大范围。别一上来就想“重构整个产品经理工作方式”，那样大概率只会把自己折腾累。

以自己的实践为例，真正把“写需求文档”和“写上线公告”这两个环节改造出来，前后差不多花了一年多。到现在，这两个环节基本已经稳定下来了。日常需求文档，通常先由 AI 生成，再做人工调整。如果是 1 到 2 周的小需求，调整量大概在 5% 到 10%；如果是 2 到 4 周的中等需求，改动量一般在 10% 到 20%；大型项目的变动会更高，通常在 30% 到 50%。

这里有一个非常真实的规律：你给 AI 的上下文越完整，最后需要改的内容就越少。

后来又花了近半年时间，把“评估工作量”和“设计产品方案”这两个环节调到可用状态。前者帮忙处理每周 2 到 5 个客户需求的工作量评估，后者更像一个随时能讨论思路的“军师”，在方案设计上提供结构化支持。

最近还在持续调试的是“需求价值判断”和“竞品调研”两个环节。一个用来避免陷入自嗨，更客观地看待需求价值和优先级；另一个用来更高效地收集竞品信息，尤其是相关需求的解决思路。

下面，就结合这几个真实案例，讲讲 Skills 到底怎么嵌进产品经理的工作流里。

Case 1：怎么用 AI 写一份专属的需求文档？

最开始用的工具，其实不是 Skills，而是智谱清言的自定义智能体。后来逐渐转向 Trae 的智能体，再到扣子的 Skills，现在基本稳定在 Trae + Skills这套组合上。

如果你现在才开始，不想绕太多弯路，我反而更建议你直接用 Skills，而不是从自定义智能体起步。原因很简单：Skills 更稳定、更可控，也更灵活。

智能体早期最大的问题，是每次都得先切换入口。写需求文档要进“B 端需求文档助理”，写上线公告又要换“B 端上线公告助理”。

更麻烦的是，效果并不总稳定。尤其当提示词变长、格式要求变复杂时，经常会出现偏差。比如明明要求“一个需求对应一条需求清单”，最后却常常被拆成 3 到 5 条。

现在换成Trae + Skills之后，体验就顺了很多。入口其实还是同一个，只是通过前缀告诉它这是“需求文档”还是“上线公告”，输出的结构和质量基本就比较稳定了。

很多人会问，能不能直接把现成的 Skills 拿去用。坦白说，这种想法很正常，但意义不大。

因为每家公司、每个团队，甚至每个产品经理，对需求文档模板的定义都不一样。你真正需要的，不是一份别人现成的 Skills，而是知道怎么做出自己的专属 Skills。

这件事的核心，无非三步。

第一，你要有一个能帮你写 Skills 的工具。第一次上手的话，扣子编程里的“技能”或者 Trae 都可以，门槛不高，直接用自然语言告诉它：“帮我创建一个写需求文档的 Skills”，再补充背景、文档格式和注意事项，它就能先搭一个雏形出来。

第二，你得先定义清楚，什么叫一份“好的需求文档”。这个标准非常重要，因为 Skills 最终输出的稳定性，不是来自模型本身，而是来自你对格式和标准的定义。你给得越清楚，它越容易稳定。

第三，反复调试，直到结果符合预期。写 Skills 很像做一个小项目，不可能一次就对。你得像调产品一样，一轮轮试、一轮轮改，不断把它往你的标准上拉。

最终形成的，通常不只是一个简单的提示词，而是一套更完整的文档结构。核心一般包括SKILL.md和format-template.md。前者负责说明这个技能的目标、触发时机、格式要求和注意事项，后者负责严格定义格式和示例。

如果你能把第一个需求文档 Skills 跑通，后面的很多事其实就开始通了。因为你会突然意识到，原来工作里很多原本靠经验和手感完成的环节，都是可以被拆出来、定义出来、再固化下来的。

Case 2：怎么用 AI 写上线公告？

上线公告其实是很适合 Skills 化的一个环节。

它的特点很典型：高频、重复、格式相对固定，而且只要结构清楚，AI 的完成度通常就会很高。你把第一个 Skills 做出来之后，后面做上线公告，整个过程会明显轻松很多，本质上就是不断“复制、粘贴、优化”。

上线公告最关键的，不是语言有多华丽，而是信息结构要稳定。发布对象是谁、更新了什么、影响哪些用户、操作路径是什么、注意事项有哪些，这些都要提前定义清楚。只要结构定住，后面就好办了。

真正要做的，依然是反复调试。让它输出出来的内容，越来越贴近你所在公司的真实公告风格，而不是一个“看起来正确”的通用模板。

当这个环节稳定之后，你会明显感觉到，写上线公告不再是一件要重新组织思路的事，而更像是“填充上下文，再快速确认”的过程。生成后贴进用户中心，稍微调整下语气和细节，通常就能直接发布。

这类工作以前很容易被低估，觉得只是写一篇公告而已。但真正做久了你会发现，正是这种高频、事务性、又不太复杂的环节，最适合优先用 Skills 改造。因为一旦跑顺，几乎每周都能立刻回收效率。

Case 3：怎么用 AI 评估工作量？

如果说前两个案例更像是“怎么做”，那工作量评估更值得聊的是“为什么做”，以及“做的时候最容易踩什么坑”。

做 SaaS 产品的人对这个场景应该都不陌生。很多客户需求排不上标准版本时，就会问能不能付费定制。这时候，产品经理通常要先给一个工作量评估，作为客户是否继续推进的依据。

问题在于，这件事很尴尬。

你如果随口说个 10 人天，客户大概率会追问依据；你如果认真拉人评估，又会发现很耗时间，因为超过 90% 的需求最后可能都不会真的落地。也就是说，这是一件必须做，但很容易“投入产出不成正比”的事。

所以，给工作量评估单独做一个 Skills，价值就出来了。

这类 Skills 的核心不是“拍脑袋估时”，而是先把需求结构化，再按角色分工去估算。比如它先把一个需求拆成若干功能点，再分别评估产品、设计、前端、后端、测试各自的工作量，最后输出成一份清晰的 Markdown 文档，可以直接发给客户。

这里特别关键的第一点，是：需求没诊断清楚之前，不要评估。

这和真实工作完全一样。一个模糊需求，谈不上有效评估。真正靠谱的 Skills，应该先帮你补齐信息、识别歧义、确认边界，然后再进入评估阶段。

第二点，是把拆解规则讲清楚。比如一个用户故事对应一个需求，一个需求再拆成若干功能。简单需求可能只有 1 到 2 个功能，复杂需求拆成 3 到 6 个功能。如果超过 6 个，就应该提示“这已经不是一个需求，而是多个需求”。

第三点，是输出格式一定要明确。工作量评估最怕看起来很多，实际不可用。所以最好直接定义成 Markdown 表格，明确列出功能清单、角色分工和对应人天。

你会发现，这个环节的核心价值，不只是帮你省时间，而是帮你把“评估”这件事从经验型动作，慢慢变成一个更可解释、更可复用的过程。

Case 4：怎么用 AI 设计产品方案？

如果你做过复杂需求，应该对这种感觉很熟：思路卡住了，但又找不到一个真正能把背景接住、愿意耐心陪你推演的人。

跟同事聊，大家都有自己的工作，能给的时间有限；跟外部同行聊，又常常因为上下文太多、背景太重，很难在短时间内给出真正有效的建议。

这时候，产品方案 Skills 的价值就会非常明显。

它最像的，不是一个“自动生成方案的工具”，而是一个随时在线的资深产品经理。你可以不断跟它聊思路、聊困惑、聊约束条件，让它帮你做结构化思考，也帮你看到自己没注意到的视角。

不过这里也有两个特别容易走偏的点。

第一，不要让它一上来就直接给方案。真正有效的方式，是先让它诊断需求，确认背景、目标、角色、边界，再逐步进入方案讨论。你可以把它理解成一次高质量的同行交流，而不是一次机械的内容生成。

第二，要把你的方法论告诉它。比如“需求是 1，方案是 0”，“以终为始，全面规划；以始为终，最小闭环”这类原则，就很适合写进 Skills。这样它每次给方案时，不是只会拼凑功能点，而是会沿着你的思考框架去展开。

在输出结构上，也最好提前定义清楚。通常一个需求对应一个解决方案，而一个方案可以包括需求背景、用户故事、设计理念、解决方案、原型示意图、流程图，复杂场景下甚至还可以补实体关系图。

最后，要告诉它不能谄媚（尤其是在用Gemini模型），保持质疑、警惕之心。

这样一来，它就不只是“帮你写方案”，而是真的在参与方案设计。

顺便说一句，我准备再写一个子SKills，快速输出3个完全不同思路的方案，用于早期设计方案时，完全打开自己的思路。

写在最后

聊到这里，你应该已经能感受到，Skills 真正厉害的地方，不是“让 AI 多会一点”，而是把你自己的经验和方法论，慢慢固化成一个能反复调用的能力模块。

为什么会觉得它很重要？因为它同时具备几个非常关键的特性。

首先是稳定。复杂任务下，普通提示词经常会漂，今天写得像回事，明天又偏了。但 Skills 一旦定义清楚，输出会稳定得多。

其次是灵活。你不需要每次都精确记住要调哪个工具、进哪个入口。只要描述清楚需求，它就能根据上下文调用合适的 Skills，甚至多个 Skills 配合完成一个任务。

还有一个很容易被忽略的点，是可复用。不同工具之间，Skills 的底层格式其实越来越像一个统一接口。你在一个工具里沉淀下来的能力，不至于每换个平台就得从零再来一次。

更重要的是，它的能力并不止于“写文档”。在更深入的场景里，Skills 还能写脚本、调接口、执行具体动作。之前那篇文章里，就用它直接请求企业内部系统，拿客户信息，再自动生成客户案例 PPT。到了这一步，你会发现 Skills 已经不只是内容助手，而是在真正进入工作流。

说到底，AI 改造工作流这件事，最难的从来不是工具本身，而是你愿不愿意把自己的经验拆出来、定义清楚、反复调试，直到它变成一个真正能用的“技能”。

如果你现在正准备开始，真没必要一上来就追求“大而全”。不如先问自己一个更简单的问题：

在你的工作流里，哪个环节最重复、最耗时、也最容易先被改造？

从那个点开始，往往比什么都重要。