当AI能轻松生成软件界面时，B端产品经理们面临的新挑战是如何让AI持续产出贴合业务的严谨设计。Skill作为一套可复用的协作规则，正成为驯服AI随机性的关键武器。本文将揭示一个成熟Skill如何从混乱踩坑到系统化落地的完整培育路径，并剖析它对B端产品经理在效率、思维和组织层面的三重价值升级。
当 Cursor、Windsurf、Bolt 这类工具把“用自然语言生成软件界面”变成了日常，一种新的焦虑和兴奋开始在 B 端产品经理圈子里蔓延。大家很快发现，随手写一段 prompt 让 AI 吐出一个后台 demo 并不难，难的是让它持续、稳定地产出贴合业务、逻辑严密、风格一致的东西。难的是把那种“这次还行，下次又不行”的随机感，变成一种可预期、可迭代的协作能力。
这就是skill要解决的问题。
在 vibe coding 的语境里，skill 不是指传统意义上的个人能力，而是指一套被编码进 prompt 或工具配置里的、可复用的协作规则。它的载体可以是一个 Cursor Rules 文件、一段 Windsurf Memories、一个固定的 prompt 模板，或者一份skill.md。它的本质，是把产品经理个人的判断力、审美和业务认知，外化成一套 AI 的“操作系统”——每一次你和 AI 协作的起点，都因为它而大幅提高。
这篇文章想和你聊的，不是某一个现成的 skill 怎么写，而是一个成熟的 skill 是怎么在实战中，一步一步“长”出来的。以及这个过程，对 B 端产品经理到底意味着什么。
几乎所有 B 端 PM 上手 vibe coding，都会经历一条相似的成长曲线。这条曲线，就是 skill 从无到有、从简陋到成熟的培育之路。
刚开始的时候，你甚至意识不到自己在“培育 skill”。你只是频繁地被 AI 的产出弄得哭笑不得：
这个阶段的你，像一个在黑暗中摸索的猎人。你所有的不满和挫败，其实都是宝贵的信号，只是还没被系统地收集起来。
这个阶段唯一需要刻意做的事，是“记录”。
建一个私人笔记，就叫做《我和 AI 的协作日志》。不用追求格式，每次有感就记一两句：
这样碎片化地记录一个月，你会积累几十条零散但真实的洞察。它们就是培育 skill 的种子。混乱期不可怕，可怕的是经历完混乱之后，什么都没留下来。
当协作日志积攒到一定厚度，你自然会开始发现规律。那些反复出现的问题，背后其实可以被归纳成有限的几类：
这个阶段的核心动作是“归纳”。你把日志里那些具体的坑，抽象成几条可写入规则文件的“铁律”。
比如，关于 UI 风格的问题，你可能会归纳出第一条 rule：
生成 B 端界面时，风格严格参考 Ant Design Pro，信息密度优先。禁止：大圆角、装饰性阴影、渐变色、过度留白。
这条规则加进去之后，界面跑偏的问题解决了大半。但你很快会发现新问题：AI 开始把所有页面都做成密密麻麻的表格，连概览页都不例外。于是你补充第二条：
概览类页面优先使用卡片布局，但仍需保持高信息密度，卡片内只展示关键指标。
Skill 就是这样一点一点“修”出来的。每加一条规则，都是为了解决一类反复出现的真实问题。这个阶段的产物，是一个只有三五条规则的 v0.1 版 skill 文件。它很简陋，但它标志着你从“被动踩坑”正式进入了“主动驯化”。
v0.1 版本的 skill 开始被投入到各种真实场景里。这时候，新的问题才会真正暴露出来：你的规则之间，是会互相打架的。
比如，你有一条规则要求“高信息密度”，另一条要求“概览页用卡片”。当 AI 同时执行这两条时，可能产出一个每张卡片里塞了十几个指标、让人完全没法看的页面。这时你才意识到，“高信息密度”这个规则太模糊了。你被迫把它精细化：
概览页卡片内仅展示 4-6 个最核心指标，详细数据通过“查看详情”跳转。任何单个卡片内的文字数量不应让用户停留超过 3 秒。
这就是压力测试的价值所在：你之前一拍脑袋写下的规则，在真实场景里暴露出模糊和矛盾，你不得不把它们变得更精确、更可执行。
这个阶段还会发生一件很重要的事：你开始把这份 skill 分享给团队的同事使用。同事用完反馈说：“你那个关于表格的规则，在数据分析类的场景里很好用，但在流程配置类的场景里太僵化了。” 于是你再加上场景分支的判断逻辑：
如果是数据分析类界面，优先表格+图表混合布局；如果是流程管理类界面，优先分步式引导；如果是基础配置类界面，优先表单一屏完整展示。
经过这个阶段，你的 skill 从“只适合我”的个人武器，开始升级为“可以迁移”的团队资产。它的规则不再是一条条孤立的指令，而是一个有逻辑、有场景、有边界的系统。
经过多次项目上的反复打磨，你的 skill 会进入一个相对稳定的状态。它不再需要你每周改一次，但也不是从此束之高阁、变成教条。
一个成熟态 skill 的结构，通常会自然演化成这个样子：
最后这一点尤其重要。知道一条规则是“为什么而来”，你才能知道它什么时候该被改掉，甚至被拿掉。否则 skill 就会不断变臃肿，最后变成一个僵化的教条，反而压制了 AI 可能的创造力。
培育一个成熟的 skill，至少需要几周甚至几个月的持续投入。很多人会问：这值得吗？我随手写 prompt 不也能用吗？
答案是：如果你只把 vibe coding 当成一个偶尔玩玩的 demo 工具，那确实不值得。但如果你想把它真正嵌入工作流，成为你日常思考的外延，那培育 skill 带来的回报，会体现在三个递进的层次上。
第一层：效率价值。这是最显而易见的。每一次协作的起点都被抬高了，你不用再一遍遍纠正那些低级错误，AI 产出的“初稿质量”越来越接近可用状态。原本需要一整个下午的 demo，现在可能半小时就能出一个能让业务方认真讨论的版本。
第二层：思维价值。这一点更深刻，也更被低估。培育 skill 的过程，是在反向逼迫你把那些飘在脑子里、只能意会的“产品感觉”显性化、结构化。你觉得某个界面“不好”，以前你最多说一句“不够专业”。但现在，为了把它写进 skill 里，你必须把它拆解成：“信息密度不够”、“操作路径太长”、“和系统整体风格不一致”。这个拆解的过程，本质上是在训练你的产品判断力。你写得越清楚，你对自己想要什么就越清楚。
第三层：组织价值。如果你是一个产品团队的负责人，这一点将是关键。一个新人入职，拿到你的 skill，他第一次用 AI 生成的后台界面，起点就非常接近你的水准。这不是取代他思考，而是帮他跳过了那些没必要的、反复出现的低级试错，让他能把精力花在真正需要人脑判断的地方。Skill 是你把个人的隐性知识，变成团队共享资产的一种方式。
如果看完上面这些，你决定开始培育自己的第一个 skill，最后再分享几个帮你少走弯路的心法。
心法一：从最疼的那个点开始。不要一上来就试图写一个“大而全”的完美 skill。找到目前让你最头疼的那个具体问题——比如“AI 总把审批流设计成单线，完全不考虑会签和转办”——然后只写一两条规则去解决它。Skill 是长出来的，不是设计出来的。
心法二：用“参考系”和“禁止清单”代替形容词。“要好看”、“要专业”在规则里是无效的。有效的是“参考 Ant Design Pro 表格页风格”和“禁止渐变背景、禁止装饰性投影”。让你的规则可以被 AI“无歧义地遵守”。
避雷提醒一：规则不要“我觉得”，要“我验证过”。一条没经过真实场景压力测试的规则，加进 skill 是有风险的。它可能看起来很对，但在某些场景下反而把 AI 带偏。
避雷提醒二：警惕 skill 的膨胀。每次想加新规则时，先问自己：它解决的是一个真实存在的新问题吗？还是旧问题的另一个说法？如果不是，就别加。定期做减法，和添加规则同样重要。
避雷提醒三：Skill 不能替代你对业务的理解。它解决的是“如何让 AI 更好地执行你的意图”，但“你究竟要做什么、为什么要做”——这些问题的答案，仍然需要你走向业务现场，在一线把那些混乱、矛盾和潜规则摸清楚。这是 skill 永远无法替你完成的部分。
Vibe coding 不是要让产品经理都变成半吊子前端，而是在你和代码之间，架起了一座可以随时互译的桥梁。而 skill，就是你教会这座桥只承载你认可的设计、只传递你验证过的逻辑的过程。
这就像养一株植物。一开始，你只是每天浇浇水、跟它说说话，不知道它会变成什么样。然后某一天你发现，它已经长出了自己的形状，和你想象的不完全一样，但每一片叶子，都带着你修剪的痕迹。
本文由 @Serencry 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。