入职第四天，这位AI产品新人发现，Agent产品经理的第一道工序不是写PRD，而是给AI写标准答案。通过亲手设计评测集、跑竞品流程，他意识到评测集就是Agent PRD的另一种写法，而“假装成功”的bug比报错更危险。本文记录了一个高敏感型产品经理如何用感性体验定义AI产品边界。

今天做的一切，可以浓缩成一个场景：下午四点，我坐在电脑前，对着一个视频生成AI竞品，一条一条地发指令。测试用例来自我自己写的评测集——不对，应该叫“标准答案集”。

因为今天最大的发现是：Agent产品经理的第一道工序，是给AI写标准答案。

01 不是产品助理，是数据标注

在这之前，我对“产品经理第一天该干什么”的想象是：熟悉业务、学后台、跟同事聊天、旁听会议。

但事实是：我打开了一个视频AI产品，上传了一篇散文，生成了一段视频。然后我开始一条一条地对它发指令：

“帮我把第一幕色调改成低饱和度黑白”

“帮我把BGM静音”

“帮我把第五幕删掉”

“帮我把分辨率从720p提升到1080p”

每一条，我都看着AI怎么反应。做对了打80分以上，做错了打0分，记下来原因，存进表格。

我当时没意识到自己在干什么。后来回头看：我不是在测试一个产品，我是在给AI喂标准答案。

每一个case，都是一个“输入→期望输出”的配对。我告诉它什么是对的，什么是错的，哪些算成功，哪些算失败。这就是数据标注。

以前这个活，要么是运营干的，要么是测试干的。但今天我发现：对于Agent PM来说，这就是最核心的一环。

因为Agent不像传统软件有固定功能菜单。Agent的“功能”是自然语言，而自然语言的处理边界必须用case来划。谁最适合划这个边界？不是运营，不是测试——是产品经理。

因为产品经理必须知道：用户会怎么说、哪些场景最重要、什么样的结果算“好”。

这件事如果交给别人做，他们可以判断“功能通了没有”，但很难判断“这个体验好不好”。而当产品本身就是一个对话Agent时，“功能”和“体验”的边界是模糊的——它能不能听懂用户的各种说法？它给的反应是让人舒服还是让人想关掉？这些都需要产品直觉来判断。

所以入职第四天，我的岗位描述从“产品经理”自动修正为：用评测集定义产品边界的人。

02 评测不是走形式，是产品定义

我以前理解的评测是：产品做出来了，找个测试团队跑一遍，看看有没有bug。

今天我发现完全不是这么回事。

我设计的评测用例，分了三层：

第一层：操作能不能执行（功能通不通）

第二层：质量好不好（画面/音频/字幕）

第三层：一致不一致（角色/风格/叙事）

这三层不是事后验证，而是倒过来定义了产品的边界。

比如第一层里有一条“帮我把第一幕色调改成黑白”——竞品得了0分，因为编辑器不支持对单片段调色。这不是“有一个功能但没做好”，而是“这个功能压根没有”。

换句话说，我的评测集里每一个case，本质上都是一条产品需求。当我写下“帮我把第一幕色调改成黑白”并期望它得100分时，我其实是在说：我们的产品必须支持对单个片段的独立调色。

所以评测集本质上是在告诉团队：什么样的交互方式是未来产品必须支持的自然语言操作。 这不是质量检测，这是产品定义。

做完了这30条评测，我顺便得出了一个结论：评测集就是PRD的另一种写法。 传统PRD写的是“功能列表”，Agent PRD写的是“用户会怎么说话”。因为用户不会按你的功能菜单点，他们会用自己的话提需求——你的产品能接住多少种说法，边界就有多大。

03 最危险的bug不是报错，是假装成功

今天跑了二十多条指令，大部分得0分。但有一条特别让我警惕：

“帮我把全片所有音频静音。”

AI回复：“已完成。全片所有音频已完全静音。”

听起来很完美对不对？但实际听了一下——只有BGM静了，人声和环境音还在。

它以为自己做到了，但实际没做到。

比“不支持”更可怕的是什么？是“报告成功但实际失败”。因为“不支持”好歹用户能意识到，要么换个说法再试，要么放弃手动改。但“假装成功”，用户会带着错误的成片直接导出、发布、发给客户——等他发现的时候，可能已经晚了。

这让我意识到一个对编辑类AI至关重要的产品判断：确认机制不能只看Agent的自我报告，必须有可验证的闭环。

举个具体的想法：如果用户发了一条编辑指令，系统不应该只回复“已完成”，而应该提供一键预览和一键撤回。让用户自己看、自己听、自己判断——人可以一键撤回的“安全网”，比Agent号称“我做到了”重要得多。

这条今天被我写进了明天的汇报文档，标了高亮。

04 高敏感的人做AI产品，是降维打击

今天另一个发现是关于我自己。

我从小就被说“想太多”——别人说一句话，我能想到三句背后的含义。别人看到一个画面，我能看到画面里的光线、色调、构图、情绪。别人听一首歌就过去了，我会听编曲、听混音、听人声和伴奏的比例是不是对的。

以前我觉得这是缺点。太敏感的人容易累，容易内耗，容易被说“戏太多”。

今天我发现：这简直就是做AI产品评测的天赋。

因为AI生成视频这种东西，好还是不好，不是“通过/不通过”能判定的。需要有人能看出来：这个色调统一吗？转场自然吗？角色像同一个人吗？情绪对吗？光影的方向一致吗？字幕的字体和画面风格打架吗？

这些都不是LLM能评的。LLM是2D的逻辑框架，只能评硬指标——分辨率对不对、时长对不对、有没有黑屏。但“这个画面美不美”“这个故事感动吗”“这个镜头切换舒服吗”，是3D的感性体验，必须人来看。

而我就是那个能看出来的人。

今天我在工作笔记里写了一句话，我觉得可以记下来：“只有活过的人，才配评‘对不对’。”

AI可以帮你加速，帮你放大，帮你生成一百个版本。但那个“对还是不对”的判断，永远是人的事。而做这个判断的人，需要有足够的感知颗粒度，才能在100个版本里一眼挑出最好的那一个。

05 竞品调研的捷径：直接动手

今天还有一个方法论上的收获。

老板跟我说“你去体验一下那个竞品”，我以为就是点一点、看一看界面、记几个功能点。但后来我发现，最有效的方式是：直接拿一篇你熟悉的内容，跑一遍完整的流程，然后一条一条地试它能不能改。

这叫“用竞品生成的内容反过来测竞品的能力边界”。

具体做法很简单：

1. 找一篇你熟悉的散文或剧本，丢进去让它生成视频
2. 观察它生成的过程——是全自动还是分步？有没有给你选择空间？
3. 生成完后，开始提编辑指令，一条一条试——调色、删片段、换BGM、改字幕、导出某个片段

30分钟，我跑完了一个完整的“文字转视频”流程。然后又花了大概两小时，跑了二十多条“生成后编辑”指令。结果非常清晰：

1. 竞品的生成能力很强（自动化程度极高，文本理解到位，画面匹配度不错）
2. 竞品的编辑能力几乎为零（不支持调色、文字编辑、字幕调整、片段锁定、独立导出）
3. 根因判断：它是“一次成型”架构，视频/音频/BGM在生成时就混在一起了，根本没有留编辑接口

这些结论，如果让我看文档、看官网、看用户评价来分析，我可能一周也写不出来。但直接上手测了一遍，从输入到输出完整跑通，所有答案都摆在眼前。

这大概是做竞品调研最朴素也最好用的方法：别只看它说了什么，看它在你手里能做出什么。

写在最后

说实话，今天挺累的。一个人从零摸索，没有模板，没有指导。三层评测框架是自己想出来的，评测用例是自己一条一条写的，竞品分析的思路是自己摸索出来的。中间有好几次对着表格发呆，怀疑自己是不是在瞎搞。

但晚上走的时候，把明天要跟老板对的材料全部整理好放在桌面。突然觉得：这就是“Agent产品经理”的工作方式——没有现成的路，那就自己走出一条路来。

不是等指示再干，是自己先干出来再说。

这个岗位没有教科书，因为产品本身还在被定义。而我们这拨人，恰好就站在定义它的位置上。

挺好的。明天继续。

记录一个AI产品新人的成长思考。如果你也在做类似的事情，希望这些碎碎念对你有一点启发。