当AI输出的竞品分析报告满是排比句和功能罗列时，问题可能不在AI本身——而是你缺少一份精准的spec任务说明书。本文以竞品功能对比为实战案例，手把手教你构建包含上下文、任务、要求、结果呈现四段式骨架的AI指令书，将模糊指令转化为可落地的标准输出，并进一步将其固化为可复用的工作技能。掌握这套方法，你的AI协作效率将从'勉强能看'跃升到'开箱即用'。
AI火了一年了，你大概率已经用过它。比如让AI帮你分析竞品：
“帮我分析一下竞品1和竞品2的供应商管理功能。”
回车。出来的东西呢——排比句扎堆、功能罗列、没有一个能直接贴进报告里的结论。
你心想：AI也没多好用。
不是AI不好用。是你没给它写spec。
最直接的做法是直接告诉AI”帮我做竞品分析”。不行——AI不知道你的产品是谁、客户是谁、当前阶段在哪、报告要给谁看、结论要长什么样。它会按自己的偏好生成一份东西，你用你的问法问出一版，同事用他的问法问出另一版，格式完全不同。
正确的做法是写一份spec——任务说明书，把”做什么 + 做成什么样”清清楚楚交给AI。
这篇文章，我们一起来写这份spec。就拿”竞品功能对比”这个场景——你在前面那篇竞品分析文章里已经学会怎么自己做，今天教你怎么让AI帮你做。不读理论，一段段跟着写，写完你就知道下次怎么套。
我们的目标：写完这份spec之后，你把同样的骨架套到任何一个你反复做的工作上，AI给出的东西从”勉强能看”变成”基本能用”。
一份能让AI稳定执行、输出能直接用的spec，就四段：
四段回答四个问题：前提是什么 / 做什么 / 怎么做 / 算不算做对了。一段都不能少。
下面我们一段段写。场景就用前阵子我真实做过的一件事：写一份竞品功能对比的spec。
我们当前的情况很简单：正在做招采平台产品规划，老板让出一份竞品分析报告。手头有竞品1、竞品2、竞品3三个竞品的官网截图和客户案例。供应商管理模块是这次分析的重点。
写出来：
上下文： 我在做B端招采平台，公司主打中型企业采购部门，客户人均管理200+供应商。当前版本只有基础的供应商录入功能，正在规划2.0。手头有三个竞品（竞品1、竞品2、竞品3）的官网功能列表和客户案例。本次聚焦供应商管理模块。
要点1：上下文要让AI知道三件事——你是谁、手头有什么、卡在哪。
AI不是你同事，不知道你公司做什么、不知道你客户画像、不知道你看了哪些资料。你不写，它就猜。猜出来的东西，基本跟你的实际情况对不上。
“我们公司是做招采的”——不够。”我们做招采平台，客户是中型企业采购部门，人均管理200+供应商”——够了。多这一句话，AI就不会给你写出一堆大企业才用得上的供应商战略管理功能。
任务要具体到一句话能说清。”做一下竞品分析”不够——分析什么维度？跟谁比？输出给谁看的？
任务： 对比竞品1、竞品2、竞品3三家竞品在供应商准入流程和绩效评估两个维度的功能设计。输出差距分析和可借鉴建议。不涉及审批流配置和合同管理，那两个维度后续单独做。
要点2：任务要说清楚干什么，也说清楚不干什么。
很多PM的prompt只有一个动作：”帮我分析”。太宽了，AI不知道怎么下手。
给任务划边界，跟写PRD时标注”本期不做”一样重要。AI才不会跑偏去分析一堆你暂时不需要的东西。
“对比供应商管理功能”→”只对比供应商准入流程和绩效评估两个维度，不涉及审批流和合同管理”——差异就在这后半句。
要求段是spec的主体，把”怎么做、什么格式、什么算好”写清楚。
要求：
-表格格式。行是3家竞品，列是”供应商准入流程（步骤数、关键节点、自动化程度）”和”供应商绩效评估（维度、打分方式、数据来源）”
-每个格子不超过50字，不做功能罗列，要提炼设计逻辑
-不写”体验好””功能强””行业领先”这种空话。每个结论必须有具体功能点举例——比如”竞品1支持三级审批流自定义，我们只支持固定一级审批”，而不是”竞品1审批流更灵活”
-表末附一段不超过200字的差距分析，回答：我们跟最好的差在哪、差多少、优先级
-最后列三条可借鉴建议，按投入产出比排序
要点3：要求的核心不是“做精致”，是“让AI没有自由发挥的空间”。
你给AI的自由度越大，输出的随机性越大。今天跑出来能用，明天换个说法就跑偏。”要写得好””要有深度”——这些词AI听不懂，你同事也听不懂。
把”好”翻译成可验证的约束：”每个格子不超过50字””每个结论必须有具体功能点举例””不写行业领先这种空话”。AI看到这些，输出就稳了。
最后一段最容易被省略，也是最要命的。
“输出分析结论”——这不是结果呈现。”一张表+一段差距分析+三条建议，可以直接贴进产品规划文档”——这才是。
结果呈现：
1.一张对比表（3家竞品×2个维度），格式：Markdown表格
2. 一段200字差距分析，写在表格下方
3. 三条可借鉴建议，按投入产出比标①②③
4. 这三部分拼在一起，可以直接复制粘贴到竞品分析报告里，不需要再调格式
要点4：成功的标志要能机械验证。
“跑通了””看起来对””应该没问题”——这些都是不合格的成功标志。
一份好spec的结果呈现，要让你扫一眼就能判断对了还是错了。表有了吗？200字以内吗？三条建议标注序号了吗？能直接贴进报告吗？——每一项都是”是/否”可以回答的。不需要你凭感觉。
把上面四段拼在一起，就是一份完整的spec：
这份spec第一次调花了15分钟。之后每次做竞品分析，把上下文和任务里的竞品名字换掉，30秒就能出第一版。
这就是spec——不是一次性的prompt，是把你的工作流固化成可复用的东西。
同一个框架，换一个场景。需求评审前我想知道方案有没有坑，写一份让AI扮演研发和测试来审PRD的spec。
上下文： 下周评审供应商准入模块的PRD。参会人有后端研发组长、前端和测试。上一次评审被问到数据结构和异常流程，这次想提前排查。
任务： 你扮演三类角色审阅PRD，分别从各自视角找出我没有考虑到的点。
要求：
-后端：关注数据模型、接口设计、性能
-前端：关注交互异常、边界状态、加载态
-测试：关注极端case、回归影响、兼容性
-每人至少3个问题，格式”场景→为什么有问题→建议怎么改”
-问题必须具体到某个功能点，不写”用户体验不好”
-不加客气话，直接说问题
结果呈现： 一份评审问题清单，共约10条，每条50-80字。末尾加一栏”我自己没想到但应该考虑的”。可以直接打印带到评审会。
四段填进去，一份评审预演的spec就出来了。实际跑下来，测试角色提的问题杀伤力最大——会在你没写的异常流程里翻出三个”用户这么操作会不会崩”。
两份spec写完了。你有没有发现一件事——它们的骨架一模一样：上下文/任务/要求/结果呈现。填的内容不同，结构一个标点都没变。
这就是spec和skill的关系。
一份spec，是一个一次性任务说明书。写完，AI跑一次，任务结束。
一个skill，是把这个骨架抽出来，变数留下来，其他全焊死。以后每次只要填变数，AI按同一套规矩跑。
用产品经理的话说：spec是一份PRD，skill是一个产品能力。PRD写一份实现一次，产品能力做一次能用无数次。
回到竞品分析那份spec。里面哪些是每次都会变的？哪些是永远不变的？
每次会变的：
永远不变的：
把不变的焊死，变的标成参数——这就是skill：
竞品功能对比 Skill
固定骨架（不用改）：
– 四段结构：上下文/任务/要求/结果呈现
– 表格格式 + 每格≤50字 + 禁止空话 + 必须有举例
– 输出：对比表 + 差距分析(≤200字) + 三条建议
– 可直接贴进报告
可替换参数（每次填）：
– 产品名 / 客户画像 / 当前阶段
– 竞品名称列表
– 分析维度
对比一下，同样的竞品分析任务：
要点：spec和skill不是一个东西。spec跑一次，skill能跑到你退休。
评审预演那套也一样——角色定义、每人至少3个问题、”场景→问题→建议”格式、不加客气话……这些全焊死。每次只换PRD内容和参会角色。你下周评审一个新模块，30秒填完，丢给AI，一份排雷清单就出来了。
写完一份spec，用下面这7条过一遍：
三件事：
① 一份spec的四段骨架在你眼前展开了一遍——上下文/任务/要求/结果呈现，每条要点跟着一段真实写法。
② 你看到了同一个框架套两个完全不同场景——竞品分析和需求评审，骨架一样，填的内容不同。
③ 你知道了怎么把一份跑通的spec，提炼成可复用的skill——焊死不变的，留下变的当参数。
第三件事最重要。因为spec跑一次，skill能用到你退休。你工作里不止这两个场景——需求文档、用户故事、数据分析、周报总结……任何一个你做熟了的工作流，先用四段骨架写成spec，跑通之后提炼成skill。以后每次只要改几个参数。
产品经理的核心能力是什么？把需求说清楚。这份能力在AI时代第一次变成了”写好就直接出东西”——你写得清，AI就产得准。你写不清，AI就乱产。spec是写清楚一次，skill是永远不用再写第二次。
打开你最近反复做的一项任务——什么都行。竞品分析、需求文档、评审准备、用户故事。
用上面的四段骨架写出它的spec。第一次写大概要15-20分钟，写完之后丢给AI跑一次。对比你之前”随便问一句”的结果。
大概率你会跟当初的我一样，拍一下大腿——”靠，原来是我没写清楚。”
跑通之后，花5分钟把它提炼成skill：哪些永远不变（焊死），哪些每次会变（留参数）。下次同类任务，30秒改参数，丢给AI，第一版就基本能用。
作者：光点神奇，微信公众号：产品研究所
本文由 @光点神奇 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图由作者提供
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。