会技术，但不知道做什么 Agent 产品？我从这 3 个案例里找到了一套办法

5077 字约 17 分钟

agent product pm 需求分析

2026-07-04

我之前一直有个挺现实的困惑。

会一点技术，能调模型，能写 Prompt，也知道 RAG、Agent、工作流这些概念。但真要做一个产品，或者做一个开源项目，反而卡住了。

不是不会写代码，是不知道该写什么。

这个状态很常见。很多技术人做 Agent 项目，第一反应都是从自己会什么开始：

我会接大模型 API，那就做个聊天机器人。
我会 RAG，那就做个知识库问答。
我会 Agent，那就做个自动执行任务的助手。
我会工作流，那就做个节点编排工具。

这些方向都没错，但很容易做成"技术展示"。看起来完整，实际没人持续用。

我后来读《Agent产品案例深度拆解.pdf》时，里面有个点让我挺受触动：

做 Agent 产品，不应该从技术反推产品，而应该从用户场景反推技术。

这句话听起来像常识，但真做项目时很容易忘。

用户并不关心你用了什么框架。他更关心的是：你到底帮我在什么场景里，省了什么时间，少了什么麻烦，或者完成了原来很难完成的任务。

01 先别问"我能做什么"，先问"用户卡在哪里"

技术人的惯性是从能力出发。

我会什么，所以我能做什么。

但产品不是这么长出来的。产品更像是从一个具体麻烦里长出来的。

比如：

用户现在每周都要重复整理一堆资料；
开发者总是在文档和代码之间来回查；
产品经理要从评论、工单、访谈里找需求；
运营要看一堆竞品和用户反馈；
开源维护者每天面对一堆重复 Issue；
团队里的知识散在飞书、Notion、GitHub、Slack 里，谁都找不全。

这些地方才适合问：Agent 能不能介入？

不是"我有 Agent 技术，所以找个地方用上"，而是"这个任务本来就很烦，Agent 有没有可能让它变简单"。

我觉得这是区分 AI Demo 和 AI 产品的第一道线。

AI Demo 展示的是能力。

AI 产品解决的是任务。

02 PDF 里的二维框架：先判断场景值不值得做

文档里有一个判断 Agent 产品机会的二维框架，我觉得非常适合用来做选题。

它把场景分成两条轴：

工作 / 生活
慢积累 / 快感

组合起来就是四类机会：

场景	典型方向	我的判断
工作 + 快感	自动化、提效、代码、数据分析、知识库问答	最适合个人开发者先切入，价值容易被感知
工作 + 慢积累	学习、培训、知识管理、经验沉淀	有长期价值，但留存比较难做
生活 + 快感	娱乐、陪伴、创作、角色互动	容易传播，但付费不一定稳定
生活 + 慢积累	健康、习惯、成长、长期陪伴	信任门槛高，产品体验要求也高

如果你和我一样，是技术背景，想做开源项目，我会建议先看"工作 + 快感"这一象限。

原因很直接。

工作场景里的痛点更容易观察。用户现在怎么做、哪里慢、哪里错、哪里需要复制粘贴，通常都能问出来。结果好不好也更容易判断。

比如一个 Agent 帮开发者分析 API 文档，它有没有找对接口，用户马上知道。

一个 Agent 帮产品经理整理用户反馈，它有没有归纳出真正的高频问题，也能比较快验证。

这种场景不一定性感，但更适合做出第一个有用的东西。

03 Rizz：ToC 需求很多时候不是"大问题"，而是"小情境"

PDF 里的第一个案例是 Rizz。

这个产品很有意思。它不是那种"帮你完成复杂工作流"的工具，而是切进了社交表达这种很细的场景。

用户的问题也不宏大：

不知道怎么回复；
不知道怎么开场；
怕说得尴尬；
想要一点即时反馈；
想在社交场景里更自然一点。

这类需求看起来小，但不代表不重要。

很多 ToC 产品就是从这种"小情境"里出来的。用户不是来买一个复杂系统的，他只是希望在某个具体时刻，有东西帮他一下。

这对做 Agent 产品有个提醒：

ToC 需求不一定能靠传统访谈直接问出来。你问用户"你需要一个社交回复 Agent 吗"，他可能说不需要。但你去看小红书、Reddit、Product Hunt、应用商店评论，就会发现很多人确实在表达类似的焦虑。

所以 ToC 需求更像探险。

你要多看：

用户在社交平台上抱怨什么；
年轻用户在哪些场景里求助；
哪些旧产品可以被 AI 重新做一遍；
哪些上一代工具解决得很别扭；
哪些需求以前做不了，现在模型能力刚好够了。

文档里总结了几种方式：

十倍速改进旧产品；
用新技术重构老场景；
寻找上一代技术没解决好的问题；
创造新需求。

我自己的理解是：ToC Agent 不要一开始就做"大而全助手"。太大了，用户不知道为什么要用。

反而可以从一个很窄的瞬间切入。

帮用户写第一句话。帮用户改一段尴尬表达。帮用户模拟面试。帮用户练口语。帮用户处理某一类高频社交场景。

这里的重点不是 AI 有多聪明，而是它在那个具体时刻有没有帮用户省心。

04 Chat2API：Agent 最适合处理"有目标、有资料、有步骤"的任务

第二个案例是 Chat2API。

这个场景更偏开发者，也更容易拆。

它解决的问题是：开发者面对大量 API 文档时，很难快速找到符合需求的 API，也很难判断应该怎么组合调用。

这个问题为什么适合 Agent？

因为它不是单纯问答。

它里面有一个完整任务链：

用户提出开发诉求；
系统理解用户到底想实现什么；
在大量 API 文档里检索；
找出可能相关的接口；
判断这些接口怎么配合；
给出调用顺序和编排建议；
用户再根据建议开发和验证。

你看，这和普通 Chatbot 很不一样。

Chatbot 更像是"你问我答"。

Agent 更像是"我知道你的目标，然后帮你查资料、选工具、排步骤、给方案"。

所以做 Agent 产品时，我现在会先看一个任务有没有这几个特征：

有明确目标；
需要查资料；
需要跨多个信息源；
需要判断和取舍；
需要生成一个可执行结果；
结果还需要用户验证。

如果这些条件都满足，就比较适合做 Agent。

Chat2API 还有一个很重要的点：它不是接上模型就结束了。

文档里把产品落地拆成了三层：

层次	要解决的问题
Agent 能力 / 提示词工程	让系统会规划、会调用工具、会保留上下文
模型能力	决定理解和生成质量的上限
Evaluation	判断结果到底有没有满足用户需求

这里我最想强调 Evaluation。

很多 AI 产品早期都会有一个错觉：演示时看起来不错，就以为产品可用了。

但 Agent 产品不能这么判断。

你要问得更具体：

它有没有找对 API？
有没有漏掉必要参数？
调用顺序对不对？
用户拿到结果后还要改多少？
它到底节省了多少开发时间？
错的时候，错在哪里？

这些问题都要进入评估集。

否则你根本不知道产品是在变好，还是在换一种方式胡说。

05 Cursor：不要把 Agent 做成孤岛，要贴着用户工作流

第三个案例是 Cursor。

Cursor 不只是"AI 写代码"。真正值得拆的是它为什么能长起来。

它没有让开发者离开自己的工作流。

开发者本来就在 IDE 里写代码、查上下文、改文件、Debug、重构。Cursor 做的事情，是把 Agent 能力放进这些动作旁边。

这一点非常重要。

很多 Agent 产品会犯一个问题：做了一个很完整的独立入口，但用户根本不想多打开一个地方。

用户正在写代码，你让他去另一个网页里复制粘贴。

用户正在看评论，你让他先导出 CSV 再上传。

用户正在写 PRD，你让他换一个工具重新组织材料。

这些都会增加摩擦。

Cursor 给我的启发是：Agent 离用户任务越近，越容易被用起来。

所以你做产品时，可以先问：

开发者现在在哪工作？IDE、GitHub、终端。
产品经理现在在哪工作？文档、表格、飞书。
运营现在在哪工作？评论区、后台、数据面板。
研究者现在在哪工作？论文、笔记、资料库。
开源维护者现在在哪工作？GitHub Issues、PR、Release。

把 Agent 放到这些地方，比新造一个"大平台"更实际。

还有一个点也很现实：Agent 产品早期不一定要等到 100 分。

PDF 里有句话，大意是"60 分就让产品在浅水区游泳"。我挺认同。

前提是你选的场景足够小，风险可控，用户愿意试。

先让真实用户用起来，再根据反馈改。比闭门打磨三个月更靠谱。

06 真要获取 Agent 产品需求，可以按这条线走

看完这三个案例，我会把 Agent 产品需求获取拆成六步。

不是标准答案，但够实用。

第一步，先选一个很窄的人群

别上来就说"所有人都能用"。

先选一个具体人群：

独立开发者；
开源项目维护者；
AI 应用开发者；
产品经理；
运营人员；
数据分析师；
教培老师；
法务；
销售。

然后问一句：

这个人每周反复处理什么任务？

如果说不出来，项目基本还没到可以做的时候。

第二步，找真实任务，不找抽象需求

Agent 适合处理这类任务：

步骤多；
信息多；
重复高；
需要判断；
需要跨工具；
需要上下文；
输出后还要修改和确认。

比如：

分析用户评论；
整理竞品差评；
总结会议纪要；
检索公司知识库；
生成 API 调用方案；
分析开源项目 Issues；
根据文档生成测试用例；
把一堆资料整理成报告。

不要问"用户想不想用 AI"。

这问题没什么意义。

要问："你上一次完成这个任务时，具体卡在哪？"

第三步，收集证据

每条需求都要有证据。

证据可以来自：

用户原话；
GitHub Issues；
社区讨论；
G2 差评；
Product Hunt 评论；
Reddit / Hacker News；
搜索趋势；
竞品功能缺口；
用户现有工作流；
付费行为。

做 ToC，可以多看这些：

做 ToB 或开发者工具，可以多看这些：

这些工具只能帮你找到信号，不能替你理解用户。

最后还是要回到那几个朴素问题：谁在用？他要完成什么？现在怎么做？哪里痛？Agent 介入后是不是明显更好？

第四步，访谈时别问"你会不会用"

我以前也会犯这个错。

拿着一个想法去问别人："如果我做一个 AI 工具，你会不会用？"

大多数人都会说"可以啊""听起来不错"。

然后你就误以为需求成立了。

更好的问法是还原最近一次真实经历：

最近一次处理这个问题是什么时候？
当时你要完成什么目标？
从开始到结束做了哪些步骤？
哪一步最慢、最烦、最容易出错？
你现在用了哪些工具？
哪些地方在复制粘贴？
哪些地方必须人工判断？
如果这个任务做错了，会有什么后果？
如果有 Agent 帮你，你最希望它先接管哪一步？
哪些动作必须由你确认？

用户的态度不可靠，行为更可靠。

需求通常藏在行为里。

第五步，先拆 Agent 能力，再写功能列表

拿到需求后，不要马上写功能清单。

先拆任务。

这个 Agent 到底要承担什么？

Agent 能力	对应问题
规划	是否需要理解目标并拆步骤？
工具使用	是否需要调用搜索、API、数据库、代码、文档？
行动	是否需要生成、修改、提交、发送、创建？
记忆	是否需要记住偏好、历史上下文、业务规则？

比如你想做"竞品评论分析 Agent"。

它可能不是一个简单总结工具，而是要做这些事：

从 G2、Product Hunt、App Store 收集评论；
识别差评主题；
聚类用户痛点；
提取用户原话；
生成产品机会报告；
记住你持续关注的竞品和行业。

这样拆完之后，功能自然会长出来。

否则很容易变成"再加一个总结、再加一个导出、再加一个聊天框"。

第六步，尽早做 Evaluation

Agent 产品很麻烦的一点是：输出不稳定。

普通软件只要逻辑固定，测试相对明确。Agent 不一样，它今天答得好，明天换个输入可能就跑偏。

所以从早期就要做 Evaluation。

一个简单评估集就够：

用户输入；
上下文资料；
期望输出；
判断标准；
用户反馈；
失败原因。

指标也不用一开始搞得很复杂，可以先看：

任务完成率；
用户修改次数；
工具调用成功率；
首次可用输出比例；
平均节省时间；
用户确认通过率。

别只看"回答得像不像"。

要看"用户能不能拿去用"。

07 如果目标是开源项目，该怎么选题？

如果你不是要做商业产品，而是想做开源项目，我会把标准再收窄一点。

开源项目更适合这些方向：

用户是开发者或技术团队；
有自托管需求；
有插件化和扩展需求；
商业产品太重或太贵；
用户愿意自己部署；
社区可以贡献模板、数据源、插件或评估集。

你可以按这个流程走：

第一，选一个你熟悉的人群。

比如开发者、开源维护者、AI 应用团队、产品经理、运营人员。

第二，找他们的高频任务。

开发者查文档、改代码、调 Bug。

维护者处理 Issues、写 Release Note。

产品经理分析用户反馈、整理 PRD。

运营人员分析评论、生成选题。

AI 应用团队做评估、调 Prompt、排查 Agent 失败。

第三，看现有方案哪里不舒服。

太贵、太重、不开源、难部署、难集成、文档差、不支持本地化、不支持私有数据，或者需要大量人工整理。

第四，做最小 MVP。

别一上来做完整平台。

CLI、浏览器插件、单场景工作流、飞书 / Slack / Discord 机器人、README + Demo、Prompt Demo，都可以。

你要验证的不是功能多不多，而是用户会不会拿真实任务来试。

08 GitHub Issue 分析 Agent，只是一个例子

这里放一个例子，但它不是主角。

假设目标用户是开源项目维护者，或者正在找开源项目方向的独立开发者。

他们有个真实任务：从大量 GitHub Issues 里找出用户高频痛点和产品机会。

现在怎么做？

人工看。

问题也很明显：

太慢；
信息太散；
很难聚类；
很难判断哪些需求高频；
很难从 Bug、Feature、Docs、Deployment 里提炼出新项目机会。

那就可以做一个很小的 Agent：

输入一个 GitHub 仓库地址，自动分析 Issues，输出用户痛点、需求分类、证据摘录和潜在项目机会。

第一版甚至不用做 Web。

一个 CLI 就够：

issue-radar analyze https://github.com/open-webui/open-webui

输出一份 Markdown 报告：

# Issue 需求分析报告

## 高频问题

1. 部署和环境配置
2. 本地模型连接
3. 用户权限管理
4. 插件扩展
5. 文档和教程不足

## 用户原话摘录

> "I followed the docker setup but still cannot connect to Ollama."

## 潜在项目机会

### Ollama 连接诊断工具

目标用户：本地 LLM 用户

痛点：模型连接失败但不知道原因

MVP：检测 Ollama 服务、端口、模型列表、API 可用性

这个例子的重点不是"做 GitHub 工具"。

重点是方法：

从一个真实任务出发，找到用户现在怎么做，再判断 Agent 可以接管哪几步。

这里对应的 Agent 能力很清楚：

规划：决定分析步骤；
工具使用：调用 GitHub API；
行动：分类、聚类、生成报告；
记忆：后续记住用户关注领域和分析偏好。

09 我现在会怎么找下一个 Agent 项目

如果让我重新找一个 Agent 开源项目方向，我大概率会这么做。

先选一个我熟悉的人群，比如开发者或产品经理。

然后连续看一周他们的真实反馈：GitHub Issues、G2 差评、Product Hunt 评论、Reddit 讨论、群聊里的抱怨。

不急着写代码，先记录 50 条痛点。

每条都写清楚：

用户是谁；
他在什么场景里；
现在怎么做；
哪里麻烦；
出现频率高不高；
有没有现成替代方案；
Agent 能不能明显变好；
能不能做一个很小的 MVP。

如果某类痛点反复出现 5 次以上，我才会考虑动手。

动手也不做完整产品，先做一个最小版本。可能是 CLI，可能是浏览器插件，也可能只是一个半自动脚本。

然后找 5 个真实用户试。

他们愿意拿真实任务来用，才算有戏。

10 最后

会技术但不知道做什么产品，这不丢人。

很多时候不是你技术不够，而是你还没把技术放进真实任务里。

Agent 产品尤其不能只停在"模型 + 聊天框"。

更好的理解是：Agent 是围绕用户目标，进行规划、工具使用、行动和记忆的任务系统。

所以找方向时，别先问：

我会什么技术，所以能做什么？

先问：

哪类用户正在反复处理一个麻烦任务？我能不能用 Agent 做出一个更简单、更开放、更可扩展的方案？

Rizz 提醒我们，ToC 需求可能藏在很小的情境里。

Chat2API 提醒我们，Agent 适合处理有目标、有资料、有步骤的任务。

Cursor 提醒我们，产品要贴近用户已经在用的工作流。

把这三点连起来，选题会清楚很多。

不是靠灵感，也不是靠堆技术。

是从真实任务里，把需求挖出来。

参考资料

版权所有

版权归属：Alan Zero

许可证：署名 4.0 国际 (CC-BY-4.0)