从 Demo 到产品证据：AI 项目的作品集应该怎么展示？

为什么想写这篇

最近 AI Agent 赛道特别热闹。谷歌发布了"同事智能体" Gemini Agent，OpenAI 上线了常驻型 Agent Dots，Manus 拿到 5 亿美元融资推出个人 Agent Cue。一夜之间好像所有人都在说"我做过 Agent"。

这让我想起最近改自己作品集的经历。

我有一个项目叫 OpenClaw，是一个以企业微信为入口的内部研发运营 Agent，运营同学可以用自然语言查数据库、查 K8s 状态、查 Git 提交。项目做完之后，我把它放进作品集，前后改了三遍：

• 第一版：15 节点 Case Study，从业务背景一路讲到复盘——结构完整，但读完像一份"项目文档"
• 第二版：加了核心价值、关键数据、场景截图——开始有亮点，但更像一个产品 Demo
• 第三版：每个场景补上"用户原来怎么解决→Agent 怎么解决→为什么适合 AI→最终结果"，并单独加了"我的贡献"——这一版才真正回答了一个关键问题

这个问题是：你怎么证明这个东西真的做出来了，而且产品决策是你做的？

这篇文章不讲怎么做 Agent，讲一件很多人忽略的事：AI 产品经理应该怎么展示自己的项目，才能让面试官相信你真的具备产品思维。

先说说大多数 AI 项目作品集的问题

我看过不少 AI PM 候选人的作品集，也研究过网上的案例，发现一个普遍现象：技术细节很多，产品证据很少。

典型的 AI 项目页长这样：

• 一张系统架构图（LLM、RAG、向量数据库、工具调用，框框箭头一大堆）
• 一个 Workflow 流程图（意图识别→知识检索→生成回答）
• 几段技术栈介绍（用了什么模型、什么框架）
• 最后放一个产品截图

看完之后，我通常会产生三个疑问：

第一，这个东西真的跑起来了吗？ 架构图谁都会画，但它有没有真实用户、真实查询、真实输出？

第二，为什么要这么设计？ 为什么用 Agent 不用传统方案？为什么这个能力交给 LLM、那个能力交给工具？看不到产品判断。

第三，哪些是你做的？ 一个 Agent 项目通常有算法、研发、产品多人协作，候选人本人到底承担了什么职责？边界在哪里？

这三个疑问不解决，作品集再漂亮也只是"我参与过一个 AI 项目"，而不是"我是这个产品的产品经理"。

方法一：把场景展示做成"证据链"，而不是一张截图

我第二版作品集在场景部分就是放截图：一张企业微信对话截图，配一句"用户可以自然语言查询数据库"。

这能证明"东西能跑"，但证明不了"你为什么这么设计"。后来我把每个场景改成了五层结构：

① 用户问题 → ② 用户原来的解决方式 → ③ Agent 如何解决（分步）→ ④ 为什么这个场景适合 AI → ⑤ 最终结果

拿 OpenClaw 的数据库查询场景举例：

① 用户问题

"帮我查一下 dev_jingsocial 库里面 admin 表用户为 leo 的记录"

② 用户原来的解决方式

运营在企业微信找研发 → 研发登录数据库 → 手动写 SQL → 查询 → 整理结果 → 回复运营，平均耗时 30 分钟以上。

③ Agent 如何解决

我把完整链路拆成 7 步：意图识别 → Schema 检索 → SQL 生成 → 安全校验（只读+权限）→ SQL 执行 → 结果结构化 → 自然语言总结。

④ 为什么这个场景适合 AI

这一层是我认为最能体现产品思维的地方。用户表达的是"帮我看看 Leo 的账号状态"，而不是"请执行 SELECT * FROM admin WHERE..."。传统后台需要为每种查询开发表单页面，而 LLM 能理解自然语言意图、自动生成 SQL，一个入口覆盖几乎所有查询场景。

⑤ 最终结果

返回 2 条记录，约 10 秒完成（含意图识别 + SQL 生成 + 执行 + 总结）。

这五层放出来，效果完全不一样。因为它讲的不再是"我有一个 Agent"，而是：

我发现了一类具体的用户问题，理解了旧方案的成本，设计了一套 Agent 流程去解决它，并且清楚地知道为什么这类问题适合用 AI。

这就是产品经理视角。工程师关注"系统怎么实现"，产品经理关注"用户问题怎么被解决"。

一个进阶技巧：把复杂任务单独标出来

我有两个场景，其中一个是"一句话同时查 K8s 状态和数据库表数量"。这个场景比单工具查询更有价值，因为它体现了 Agent 的多工具编排能力。

我给它单独打了一个"复杂任务"标签，并在 Agent 流程里明确画出：意图解析 → 工具路由（并行调度 K8s Tool + Database Tool）→ 多源数据聚合 → LLM 总结。

普通的 Workflow 图是"设计图"，而真实场景 + 处理流程 + 实际结果 = 产品证据。面试官一眼就能看出你做的是一个真正多步任务的 Agent，而不是一个套壳聊天机器人。

方法二：明确写出"我的贡献"，别让面试官猜

这是我认为最容易被忽略、但最重要的一点。

Agent 项目天然是多人协作的：底层 Tool/API 是研发写的，模型是算法团队调的，基础设施是运维搭的。如果作品集只写"我们做了什么"，面试官很自然会问一句：

"这些都是你自己做的吗？"

这个问题一旦是面试官主动问出来的，你就被动了——你需要在面试现场费力地切分职责，而且容易显得在"抢功"。

更好的做法是在作品集里主动、清晰、诚实地划清边界。 我在项目页里单独加了"My Contribution（我的贡献）"板块，分成两部分：

我主要负责（6 项）：

• 业务需求调研与场景识别：深入运营团队，梳理高频查询需求并排序优先级
• Agent 产品方案设计：定义 6+ 工具的调用场景、输入输出协议和验收标准
• Workflow 设计：设计意图解析 → 工具路由 → 结果聚合的完整流程
• Prompt / Schema 知识库设计：定义数据库表结构、字段含义等元数据
• 测试与效果验证：设计四层评估体系，跟踪各层指标
• 根据用户反馈推动迭代：建立点赞/点踩反馈闭环

研发协作（单独一栏）：

研发团队负责底层 Tool/API 实现（Git、K8s、SQL 执行引擎）；我的职责是定义工具能力边界、输入输出协议、调用场景和验收标准。

这样写有三个好处：

第一，诚实。不把研发的工作说成自己的，面试官追问技术实现细节时你不会露馅。

第二，反而更能突出产品价值。"定义工具能力边界、输入输出协议、验收标准"——这恰恰是 AI PM 最核心的工作，比"我也会写代码"有说服力得多。

第三，掌握叙事主动权。你自己定义了"产品做什么、研发做什么"，面试官就会在你的框架里提问，而不是自己瞎猜。

我的经验： 区分"我做的"和"团队做的"不是示弱，恰恰是专业的表现。一个能清楚说出"这部分不是我负责的，但我负责定义它应该做成什么样"的候选人，比一个把所有功劳都揽在自己身上的候选人可信得多。

方法三：用一张映射表，把"业务价值"和"产品能力"串起来

很多作品集的逻辑是"功能罗列"：我做了 A 功能、B 功能、C 功能。但面试官真正想看的是：你是不是先发现了业务问题，再决定哪些地方值得做？

我用一张"价值-场景映射表"解决这个问题：

这张表的阅读顺序是从左到右：先有业务价值，再落到具体场景，然后才是产品能力，最后是可感知的结果。

它和"功能列表"的本质区别在于：功能列表是"我能做什么"（供给视角），价值映射是"用户因为我得到了什么"（价值视角）。

产品经理最忌讳的就是从技术能力出发倒推场景——"我们接了 6 个工具，所以有 6 个功能"。正确的方向永远是："运营有 4 类高频痛点，所以我设计了对应的工具能力来解决。"

这张表放在"真实场景"之前，相当于先给面试官一张地图：先看价值全貌，再看每个场景的具体证据。信息结构清晰，说服力会成倍提升。

方法四：数据要真实透明，试点阶段就老实标试点阶段

第二版我放了几个看起来很漂亮的指标，比如"90% 的查询在 30 秒内返回""覆盖 5+ 核心场景"。

后来我改掉了。原因很简单：作品集到了一定深度，面试官是会深挖数据的。

他可能直接问："你说 90% 的查询 30 秒内返回，这个 90% 是怎么统计的？样本量多少？日志在哪里？"

如果这个数字是估算的、或者测试环境跑出来的，你当场答不上来，前面建立的所有可信度都会崩掉。一个假数据的伤害，远大于十个真实但朴素的数据。

所以我现在的数据板块只放经得起追问的真实数据，并在最下面加了一行注释：

4+ 典型场景示例 / 6+ 接入工具 / 日均 10-50 次查询 / 2-3 个使用团队

以上为试点阶段真实数据，非正式上线生产环境指标。

"日均 10-50 次""2-3 个团队"听起来不性感，但它是真的，而且我能讲清楚每个数字怎么来的。试点阶段的数据不丢人，丢人的是把试点数据包装成规模化成果。

我的经验： 数据展示有三个原则——能说清统计口径、能说清数据来源、能说清所处阶段。如果面试官问起，你应该能立刻回答"这个数字是 X 月 X 日到 X 月 X 日、在 XX 团队、通过 XX 方式统计的"。

最后：AI PM 的作品集到底在展示什么

改完三遍之后我想明白一件事：AI 产品经理的作品集，核心不是展示"我会什么技术"，而是展示"我怎么做产品决策"。

架构图、技术栈、Workflow 这些东西当然要有，它们证明你懂技术边界。但真正拉开差距的是另外四样东西：

1. 场景证据链——证明你能从用户问题出发，设计出完整的 AI 解决方案，并且知道为什么 AI 是对的选择
2. 贡献边界——证明你清楚产品经理的职责是什么，能在团队协作中真正承担产品责任
3. 价值映射——证明你是从业务价值倒推产品设计，而不是拿着技术锤子找钉子
4. 真实数据——证明你对结果诚实，经得起追问，也真正用数据验证过自己的决策

这四样东西，本质上都在回答同一个问题：

"给你一个模糊的业务问题和一堆不确定的 AI 能力，你能不能做出合理的产品判断，并为这个判断负责？"

这正是 AI 产品经理这个岗位存在的意义。技术会一直变，模型会一直更新，今天的热点明年可能就过时了。但"发现真问题、设计好方案、诚实验证结果"这套产品思维，是可以穿越周期的。

与其追着每一个新模型、新框架跑，不如先把自己做过的项目讲清楚——讲清楚用户是谁、问题是什么、你为什么这么决策、最后结果如何。

能把一个真实项目讲到让面试官信服"这个人真的懂产品"，比简历上罗列十个 AI 项目都有用。