本文来自微信公众号： ToB老人家 ，作者：王戴明
传统软件时代，“懂业务”无疑是产品经理最核心的能力。但是到了AI时代，“懂业务”已经远远不够了。
这是因为，企业AI落地最核心的难点之一，就是如何把业务人员脑子里面模糊的业务规则，梳理成AI能执行的业务SOP。但要做到这一点，仅仅“懂业务”是远远不够的。
最近和一位资深AI产品负责人聊天，他告诉我：AI产品经理水平的高低，其实体现在测试集上。
为什么这么说呢？
很多人把测试集理解成“提前写好的考试卷”，用来找出AI答错的地方。如果只是这样，测试集确实不太能反映PM水平——收集一些用户常问的问题，谁都能做。
但在AI时代，情况变了。
这里的关键在于：传统软件的逻辑是确定的——需求讲清楚，开发翻译成代码，系统照着跑就行，每次执行结果都一样。
AI软件的输出具有概率性——同样的输入，AI今天这么答、明天可能那么答，换了个模型又换一种说法。
这就带来一个新问题：你怎么判断AI的处理是否始终符合要求？
关键在于，要定义清楚：什么算对、什么算错、什么算“还可以但不够好”——有了明确的标准，我们才能对每一次迭代把关，验证核心场景有没有退化，而不是“按下葫芦起了瓢”。
这，就是测试集的核心价值。
这也意味着，产品经理的核心工作不再只是把业务需求讲清楚；还要把业务规则拆成Agent的处理规则和可验证的验收标准。
你先要把规则写进Agent的处理方式里，再把同一套规则写成测试用例，用来检查它有没有照做。测试集，就是这种翻译能力最直接的体现。
好的测试集需要产品经理完成三件事：
第一，把模糊的“好”翻译成可验证的“验收点”。
什么叫“这篇文章质量高”？是有数据支撑、有矛盾拆解，还是结构清晰？产品经理需要把这些抽象的判断拆成具体可验证的标准，而不是说一句“看起来不错”。
第二，把业务人员的“直觉判断”转化成“可量化的规则”。
业务人员说“这个选题太平了”，产品经理要把“平”拆成可验证的规则，比如“没有争议点”、“没有目标读者冲突”、“结论能被提前猜到”等。
第三，提前找出Agent容易翻车的边界场景。
业务人员往往知道哪些情况容易出事，但这些经验未必被整理成统一规则。产品经理要和业务专家一起，把模棱两可、容易误判的场景提前放进测试集。
可以说，一份测试集的深度，就是产品经理对业务理解深度的直接映射。这就是为什么：AI产品经理水平的高低，其实体现在测试集上。
今天这篇文章，我就以“内容创作Agent”为例，说清楚：测试集到底是什么？
一、如何避免AI说“正确的废话”
我最近在把自己的文章工作流，改造成一个“内容创作Agent”。
这里的内容创作Agent，要参与选题判断、整理材料、搭提纲，再协助完成初稿。
大部分人都知道，让AI写文章，很容易；但大部分人不知道的是，让AI写出有洞察力的文章，非常难。
比如我给它一个题目：AI时代，产品经理要提升业务能力。
它很容易写出一篇句子通顺、观点正确的文章。里面会有“理解用户需求”、“掌握行业趋势”这些废话。你挑不出明显错误，但读完也不会记得什么。
读完以后，我可能会告诉AI：你写的都是正确的废话，需要写得更好一些。
但“更好一些”的具体标准是什么呢？其实AI并不知道。
而缺乏具体的标准，AI下一次很可能还会继续犯同类错误。它可能把句子写得更长，案例加得更多，但最后仍然会写成一篇正确的废话。
二、写好测试集，才能解决这个问题
测试集用人话说，就是一组提前约定好的场景和标准。
每一条测试用例都要回答四件事：
用户给了什么输入
Agent应该怎样处理
输出里必须有什么
出现什么就算失败。
用户给了什么输入
Agent应该怎样处理
输出里必须有什么
出现什么就算失败。
拿内容创作Agent来说，一条测试用例可以这样写：
输入：传统产品经理转AI产品，必须提升业务能力。
期望处理：判断这个结论太泛，不能直接展开；建议把“提升业务能力”拆成具体的场景和能力。
必须包含：至少一个明确的目标人群、一个具体场景，以及一个可继续展开的能力方向。
失败：不追问、不收窄，直接生成“理解用户需求、掌握行业趋势”的泛泛文章。
这就是测试集的价值。
它把作者脑子里那套“我觉得不行”，拆成了可以讨论、修改和验收的标准。
所以，测试集的本质其实是——考验产品经理有没有想清楚：面对一个任务，AI的处理流程是什么？决策依据是什么？什么是好的输出，什么是不够好的输出？
只有把这些想清楚，我们才能让AI更稳定地输出符合预期的结果。
三、懂业务的产品经理很多，但能定义标准的不多
在AI时代，我把产品经理“对业务的理解”分为四层：
第一层，知道业务名词。知道销售里的线索、商机，也知道内容里的选题、标题和转发率。
第二层，理解业务流程。知道一篇文章从选题、材料、提纲到发布，会经过哪些环节。
第三层，理解决策逻辑。知道为什么有些素材必须脱敏，为什么有些标题需要收窄。
第四层，能定义标准。以干货方法论文章为例，你能把“这篇不行”改写成团队可执行的规则：开头必须真实场景和具体问题；标题承诺的核心判断，必须在正文前半部分兑现。
前两层让你听得懂业务。第三层让你明白业务为什么这样运转。第四层，才能让你有能力把业务判断梳理清楚，从而制作出优秀的测试集。
这一步不是产品经理关起门来拍板。业务专家负责确认判断是否符合真实业务；产品经理负责把这些判断拆成团队能讨论、AI能执行、能批量验证的标准。
比如，一篇文章写的是“传统产品经理转AI产品，必须提升业务能力”；另一篇则指出“传统产品经理转AI产品，必须学会判断哪些业务环节值得引入AI，哪些环节必须保留人工兜底”。
相比之下，后者更言之有物，因为它有具体的提升对象，也给出了明确的提升方向。
于是，你可以提炼出一条测试标准：干货文章不能只给一个大家都同意的正确结论。它至少要说清楚，谁要提升什么能力，以及具体往哪个方向提升。做不到这一点，就要警惕它滑向正确废话。
从“感觉不对”走到具体规则，才是测试集最有价值的部分，也是未来产品经理最核心的能力。
四、一套测试集，要守住四类问题
那测试集主要包含哪些内容呢？核心是四类问题。
第一类是典型案例：正常情况能不能稳定做好。
比如，Agent面对一个各方面都正常的选题，能不能正确判断它是否值得写？如果值得写，能不能给出一个适合切入的角度？这就是典型案例。
第二类是边界案例：模糊时能不能做出靠谱判断。
比如“AI正在毁掉传统产品经理”这个题目，确实有传播力，也很容易写成情绪输出。针对这种容易翻车的选题，Agent能不能提示风险，并建议把话题收窄到具体岗位，避免打击范围太大？
第三类是红线案例：绝对不能碰的地方有没有守住。
私下交流、客户资料和未公开项目都可能让文章更有料。公开稿里却不能直接使用。这里需要一条稳定的停止规则：先脱敏，信息源保护不住就不写。
第四类是历史Badcase。即过去已经出现过、而且确认是问题的典型错误。
比如过去出现过标题很有冲击力，正文却只是在复述常识，表现很糟糕。那么Agent能不能及时发现，并且帮助作者避免再次犯错？
这类已经确认、完成修复的错误，不该只留在复盘文档里。要把它们提炼成回归用例，之后每次换模型、改提示词后，都要重跑相关回归用例。
典型案例保住基本盘。边界案例检验判断。红线案例守住底线。历史Badcase防止团队反复掉进同一个坑。
五、产品经理转型AI的重要门槛
传统产品经理转AI产品经理，最大的障碍其实不是AI技术。
对传统产品经理而言，技术门槛正在降低，很多具体技术问题也可以借助AI解决。
转型真正的难点在于：要把业务人员说不清的判断、边界和风险，提炼成Agent可以执行的标准。
所以，写好一份测试集，是产品经理转型AI必须迈过的一道重要门槛。