AI 把「做」变便宜了
「判断」还是原价

过去一年，产品圈几乎所有关于 AI 的争论，都围绕着一个错误的问题展开：用哪个模型。

而真正决定你的 AI 能不能干成活的那个东西，绝大多数人连它的名字都没听说过。

先看一组数据。

2026 年 7 月，Databricks 公开了一份内部基准测试。他们没有用 SWE-Bench 这类公开榜单，而是从自己那个数百万行、横跨十几种语言的真实代码库里，挑出工程师最近实际合并过的 PR，改造成测试任务，然后让市面上主流的模型和工具跑一遍。

其中有两个结果，值得每一个正在做 AI 产品的人停下来读三遍。

第一个：单价便宜的模型，总账反而更贵。

Sonnet 5 的 token 单价大约是 Opus 4.8 的六折，直觉上应该更省钱。但实测下来，Sonnet 5 每个任务花掉 2.09 美元，Opus 4.8 只要 1.94 美元。原因是 Sonnet 干活时读得更多、绕得更远，总共多烧了 1.9 倍的 token。任务完成率还低了六个百分点，81% 对 87%。

第二个，也是更重要的那个：同一个模型、同一档思考强度，换一套执行工具，单任务成本能差出两倍以上，而质量几乎不变。

Databricks 拿 Claude Code、Codex 和一个叫 Pi 的工具做对比，模型完全相同，参数完全相同。差异出在一个很朴素的地方——每一轮对话，各自往模型里塞了多少上下文。Pi 每轮送进去的上下文大约只有别人的三分之一。它把工作区间管得更紧，用更少的轮次把活干完了。

Databricks 在文章里写了一句结论：模型选择只是拼图的一块。

如果你只记住这篇文章的一句话，那就记这句：你以为你在选模型，其实你在选执行系统。

那个执行系统，有个专门的名字，叫 harness。

一、先给一个能带走的定义

关于 Agent 是什么，市面上的定义已经多到没法看了。有人说是「能自主决策的智能体」，有人说是「具备规划、记忆、工具调用能力的 AI 系统」，还有人干脆把公司里所有沾了 AI 的产品都改名叫 Agent。

这些定义的共同毛病是：说完之后，你还是不知道该怎么判断眼前这个东西算不算。

所以这篇文章只给一个定义，一个你能带走、能用来做判断的定义：

Agent = LLM + Harness
会自己动手干活的 AI。LLM 负责判断，harness 负责让判断变成真实世界里的动作。

LLM 是大脑。它读输入，做判断，输出下一步该干什么。但它本身什么也做不了——它不能打开文件，不能发邮件，不能执行一条命令。它只能说话。

Harness 是身体、工具、记忆和规矩的总和。它决定这个大脑能看见什么、能碰什么、能记住多少、哪些操作需要先问过你。

英文里 harness 原本指马具——套在马身上的那套皮带、缰绳和挽具。这个词选得很准。马再快，没有挽具就只能自己跑，套上挽具才能拉车。而且挽具的做工，直接决定这匹马能拉多重、走多稳、会不会脱缰。

把这个定义摆出来之后，Databricks 的那组数据就不再反直觉了。同一匹马，套两副挽具，一副做工精细，一副松松垮垮，跑出来的结果当然不同。

这个定义为什么重要？因为它把选型从一维变成了二维。

过去我们的选型是一条线：GPT、Claude、Gemini、DeepSeek、Qwen……往右走就是更强。现在它是一个平面：横轴是模型，纵轴是 harness。同一个模型配不同 harness，可以落在这个平面上完全不同的位置。

再说得直白一点：当有人跟你说「我们的 Agent 用的是最强的模型」时，他其实什么都没说。

二、「Agent」这个词是怎么被讲糊的

在拆 harness 之前，得先处理一个更基础的问题：为什么这么关键的一层，被集体忽略了这么久？

1. 模型厂商的叙事把注意力全吸走了

发布会、跑分、榜单、参数量、上下文窗口——所有的营销资源都压在模型这一层。这不奇怪，模型厂商卖的就是模型。但结果是，整个行业的注意力被训练成了单一维度：谁更强。

harness 没有发布会。没有人会为「我们的上下文压缩机制迭代到了第四代」开一场直播。

2. 换模型是最低成本的动作

效果不好怎么办？换个模型试试。这个动作只需要改一行配置，五分钟出结果。而改 harness 要动架构、要重新设计上下文策略、要重新划权限边界，是以周为单位的工程量。

人总会先做便宜的那个动作，然后在便宜的动作里反复循环，直到撞墙。

3. Harness 不可见，模型名可见

用户能看到「由 GPT-5 强力驱动」，看不到「每轮上下文控制在 X token 以内」。产品经理写 PRD 时能写「接入某某模型」，写不出「设计一套四层递进的压缩管线」——因为他根本不知道有这个东西。

可见的部分被反复优化，不可见的部分被长期忽略。这是产品行业的老规律，在 AI 时代重演了一遍。

4. 套壳产品也自称 Agent

一个在模型前面加了段提示词的问答框，叫 Agent。一个把三次 API 调用串起来的流程，也叫 Agent。当一个词可以指代任何东西的时候，它就不再指代任何东西。

5. 演示视频只展示成功路径

所有 Agent 的 demo 都长得差不多：输入一句话，等待，输出一个漂亮结果。你看不到它失败的那 40 次，看不到它中途忘了前面说过什么，看不到它差点把不该删的文件删了。

而 harness 存在的全部意义，恰恰是处理这些不出现在 demo 里的情况。

那么，怎么判断一个东西算不算 Agent？

给一条可以当场验证的分界线，两个条件，缺一不可：

第一，它能不能自己决定下一步。如果每一步都是你预先编排好的，A 完了走 B，B 完了走 C，那是 workflow（工作流），不是 Agent。Workflow 没有不好，很多场景下它更可靠、更便宜、更好排查。但它不是 Agent。

第二，它能不能观察结果再调整。执行完一个动作之后，它会不会去看这个动作的真实结果，然后基于结果决定下一步？如果它只是按顺序把预设动作做完，不管中间发生了什么，那还是 workflow。

这两条合起来，就是 agent loop——Agent 的最小闭环。

三、Harness 的四个零件

拆开任何一个能干活的 Agent，你会发现里面装的东西高度一致，就四样：system prompt、tools、context、安全机制。差别不在有没有，而在做得糙还是细。

零件一：System Prompt——它的岗位说明书

很多人把 system prompt 理解成「提示词工程」，理解成怎么把话说得更漂亮让模型听话。这个理解太浅了。

在 harness 里，system prompt 承担的是岗位定义的功能，它至少要交代清楚四件事：

• 身份：你是谁。不是「你是一个乐于助人的助手」这种废话，而是「你是一个在多语言代码库里做增量修改的工程师，你不熟悉这个项目的历史，遇到不确定的地方要先读代码而不是猜」。
• 可用工具：你手里有什么。以及每样工具什么时候该用、什么时候不该用。
• 行动方式：你该怎么干活。先看后动还是边看边动？改完要不要跑测试？拿不准的时候是问人还是自己决定？
• 边界：什么事你不能做。

缺了它会怎样？模型会用它训练时的默认习惯来干活。这个默认习惯是几亿人平均出来的，不是为你的场景优化的。你会发现它总在做一些「技术上没错，但在我们这儿不该这么干」的事。

这里有个反直觉的点，值得单独说。

前面提到的 Pi，是 Earendil 公司做的一个极简 coding agent。它默认只给模型四个工具：read、bash、edit、write。读文件、跑命令、改文件、写文件，没了。subagent、plan mode、权限弹窗这些，全部丢给扩展去做。它的 system prompt 加上工具定义，官方说控制在 1000 token 以内。

按常理，工具越少能力越弱。但 Databricks 的实测里，Pi 在多个场景下表现最好。Composio 也做过一组对比测试：让 8 套不同的 agent 工具调用同一个模型，完成 30 项任务。Pi 做对 20 项，排第一。

原因不难理解：system prompt 和工具定义里塞的每一句话，都在跟你的真实任务抢模型的注意力。当一个 harness 内置了大量默认指令、大量工具说明、大量「以防万一」的规则时，模型在真正开始干活之前，已经被喂了几千 token 的噪音。

写过 PRD 的人对这个应该很有共鸣：一份把所有边界情况都写进去的一百页文档，开发看完之后，往往比看一份讲清楚核心目标的五页文档做得更差。

零件二：Tools——它的工具箱

Tools 是模型通过 function call 能调用的东西。这是 Agent 和聊天机器人最直观的分界：聊天机器人只能告诉你「你可以打开终端输入这条命令」，Agent 直接把命令跑了。

工具设计有三个常被忽略的点：

第一，工具的粒度比数量重要。四个通用工具（读、写、改、执行）能组合出的动作，往往比四十个专用工具更多。专用工具的问题是模型得先在四十个里挑对那一个，挑错的概率随数量上升。

第二，工具的返回值要为「下一步判断」服务。一个工具返回三千行日志，和返回「失败了，原因是端口被占用」，对模型来说是天壤之别。前者会瞬间吃掉上下文预算，后者直接给出下一步动作的依据。这一点在设计上很容易被工程同学忽略，因为对人来说日志越全越好，对模型不是。

第三，MCP 让工具从「内置」变成了「可插拔」。现在主流的 harness 基本都支持 MCP 协议，意味着工具层不再需要 harness 厂商亲自开发。这是一个结构性变化：工具的丰富度不再是 harness 的核心竞争力，怎么管好这些工具才是。

零件三：Context——它的记忆和笔记本

这是四个零件里最难做、差异最大、也最能拉开产品档次的一块。

问题的根源是：模型的上下文窗口是有限的，而且，这个窗口越满，模型表现越差。

第二句是关键。很多人以为上下文窗口就像硬盘，没满就没事。实际不是。上下文填得越满，模型的注意力被分散到越多 token 上，旧的、不相关的内容开始干扰当前任务。典型症状是：它开始前后矛盾，忘了二十轮之前已经达成的决定，引用一个根本不存在的变量名。

一个长任务跑上几个小时，上下文一定会撑爆。所以每个 harness 都必须回答一个问题：满了怎么办？

最粗暴的答案是滑动窗口——把最老的对话直接丢掉。这个方案的问题是，最老的那部分往往包含了最重要的东西：用户最初的需求是什么、我们为什么选了方案 A 而不是方案 B。丢掉这些，Agent 就变成了一个只记得最近五分钟的失忆患者。

成熟的做法是压缩，而不是丢弃。以 Claude Code 为例，社区对它的源码做过比较细的拆解，它的压缩不是单一动作，而是一套从轻到重的分层机制：

• 最轻的一层，不调用模型，纯规则操作：把旧的、大块的工具输出结果清掉。比如二十轮之前读过的那个三千行文件，内容清掉，「我读过这个文件」这个事实保留。这一层每轮都跑，几乎不耗时。
• 往上一层，当上下文用量接近阈值时（社区反推的数值大约在有效窗口的 83% 左右，或者说有效窗口减去一万三千 token 的缓冲），触发真正的压缩：把整段对话历史交给一个独立的模型实例，让它生成摘要，然后用摘要替换原文。
• 再往上，还有兜底层：如果压缩之后依然超限，API 返回错误，系统会再走一轮更激进的紧急压缩。

这套设计的核心原则，社区总结得很精准：尽可能用廉价的规则操作，延迟昂贵的模型调用，只在不得已时才丢弃信息。

还有两个细节值得产品经理注意：

其一，摘要不是随便摘的。Claude Code 的压缩提示词会去读项目根目录的 CLAUDE.md，如果你在里面写了「总结时重点关注 TypeScript 的改动，以及踩过的坑和解决方法」，压缩时就会按这个偏好来。这意味着「该记住什么」是可配置的，是产品设计决策，不是技术黑盒。

其二，压缩后必须能回溯。摘要里会附上完整会话记录的文件路径。摘要是给模型看的精简版，原始记录还在硬盘上，需要时能翻回去。摘要是索引，不是替代品。

Hermes 走的是另一条路，更值得借鉴。它不把所有技能说明都塞进 system prompt，而是默认只放一份极轻量的目录——每个技能只留名字和一句话描述。Agent 判断某个技能跟当前任务相关时，才通过一个专门的加载动作把完整内容读进来。

社区把这两种模式的差别形容为「重型背包」和「动态图书馆」：一个是出门前把所有可能用到的东西都背上，一个是需要什么去架子上取什么。

零件四：安全机制——什么事必须先问过人

前三个零件决定 Agent 能干多少活，第四个决定它出事的时候你损失多大。哪些操作可以自己做、哪些必须弹窗确认、哪些永远不许碰——这份清单在哪里定义、由什么机制保证，是 harness 里最不该省的部分。

四、Agent Loop：把四个零件串起来

四个零件装好之后，需要一个东西让它们转起来。这个东西就是 agent loop。它的结构简单到有点朴素：

执行一个动作 → 观察当前状态 → 判断下一步 → 再执行
循环，直到任务完成或者被叫停。

就这样。所有花哨的 Agent 架构，剥到最里面都是这个循环。

但这个循环就是 Agent 和 workflow 的分水岭，理由前面说过：workflow 的下一步是预先写死的，Agent 的下一步是当场判断的。

「观察当前状态」这一步尤其容易被低估。它意味着 Agent 执行完动作后，会去看真实世界的反馈——命令的返回码、文件的新内容、接口的响应——然后基于这个反馈重新判断。这是它能自我纠错的唯一来源。

一个不观察结果的 Agent，跟一个闭着眼睛按流程走的机器人没有区别。

循环还有一个变体，值得单独提：主动触发。

大部分 Agent 是被动的——你说一句，它动一下。但 OpenClaw 这类「长期在线」的 Agent 走的是另一条路：它有心跳机制，每隔一段时间自己醒一次，问一句「现在有什么要做的吗」，然后根据日程、邮件、消息里的新情况决定要不要行动。

从「你叫它才动」到「它自己会醒」，这是产品形态上的一次跃迁。前者是工具，后者更接近「雇了个人」。当然，代价是它需要一直跑着，需要更严格的权限管理，也需要更好的成本控制。

五、用这个框架去看六个真实产品

有了四个零件加一个循环，现在我们可以拿它当尺子，去量市面上的产品了。

Pi：极简主义的胜利

Earendil 出品的 coding agent harness。四个工具，read / bash / edit / write，system prompt 和工具定义控制在千 token 以内。subagent、plan mode、MCP 全部交给扩展。

它在四个零件上的选择：system prompt 极短，tools 极少，context 管得极紧（Databricks 实测每轮上下文只有别人的三分之一），安全和权限交给外部环境。

验证它的不只是自己人。Databricks 在自家代码库上的基准测试里，Pi 配 Claude Opus 4.8 拿到了最高通过率之一，成本还显著低于更复杂的方案。Shopify 则基于 Pi 的扩展机制做了一套自动优化循环，实测把单元测试跑得快了 300 倍，React 组件挂载快了 20%。

需要说明的是，Pi 官方的案例材料是厂商自己发的，有推广性质；但 Databricks 和 Shopify 是独立验证，这让结论可信度高了不少。

它证明了什么：少即是多，在 harness 这一层同样成立。

Claude Code：把工程规范写进文件

Anthropic 的编码 Agent，harness 的设计非常「工程化」，核心是几个约定好的 markdown 文件：

• CLAUDE.md：项目规范。用什么语言、什么框架、代码风格是什么、这个项目有哪些坑、哪些目录不要碰。相当于新人入职手册。
• 记忆机制：之前做了什么，接下来要做什么。跨会话保持状态的关键。
• hooks：在工具调用的关键节点强制插入检查。写完代码必须测试、危险操作必须确认，这类「必须发生」的事情由它保证。

配合前面讲过的四层压缩管线，它在 context 这块做得相当细。

它证明了什么：harness 可以是可读、可改、可版本管理的文本。这一点对团队协作的意义被严重低估了——CLAUDE.md 可以提交到仓库里，全组共享，像代码一样评审和迭代。

OpenClaw：把 Agent 变成常驻角色

2026 年最出圈的开源 Agent 项目，由 PSPDFKit 创始人 Peter Steinberger 开发，最早叫 Clawdbot，后来改名 Moltbot，最终定名 OpenClaw，社区叫它「小龙虾」。GitHub star 数以十万计。

它的差异化在两个地方：一是长期在线，它不是你打开才用的工具，而是一直跑着的助理，通过心跳机制主动询问有没有事要做，还能接进飞书、Discord 这些日常聊天工具。二是文件驱动的身份系统，SOUL.md、AGENTS.md 这类文件定义 Agent 是谁、怎么行动，人写规则，Agent 执行规则。控制权明确留在人手里，所有操作需要显式授权。

它的短板也很明确：社区形容它是「重型背包」模式——每次会话把各种设定文件一股脑塞进上下文，设定越多背包越沉，token 浪费严重，模型注意力也被稀释。这正好是前面讲的 context 那一块没做好的典型表现。

它证明了什么：Agent 可以从「工具」变成「角色」。但角色化的代价是上下文管理难度陡增。

Hermes：让 Agent 自己长本事

Nous Research 出品。它和 OpenClaw 兼容（有专门的迁移命令，能直接读 ~/.openclaw 目录），但设计哲学完全不同。

OpenClaw 的技能是人手写的 markdown：你写多少它会多少，你不写它就不会。这是一个需要持续人工喂养的体系。

Hermes 加了一个学习循环：Agent 干完一个复杂任务后（社区反馈的触发条件之一是工具调用超过五次），会自动把整个解决过程提炼成一份 markdown 格式的技能文档。下次遇到同类问题直接调用。后续如果发现更好的路径，还会回头更新这份文档。

配合前面说的「动态图书馆」式技能加载——默认只在上下文里放技能目录，用到时才加载全文——它把「技能越多越沉」这个问题也一并解了。

它证明了什么：harness 里可以内置「经验沉淀」的机制。这可能是 Agent 产品下一个阶段最重要的竞争维度——不是谁的能力强，是谁的能力会自己长。

不过要清醒：自我进化的另一面是透明度和可控性下降。它学到的东西对不对，得靠你去检查。OpenClaw 那种「人在决策链中心」的路线，在需要严格审计的场景下反而更合适。

WorkBuddy：办公场景的本土化封装

腾讯云 CodeBuddy 团队出品的 AI 办公工作台，覆盖日常办公、代码开发和设计创意。你用自然语言下任务，它自己拆解、规划、执行，最后交付一个可以直接验收的结果——周报、纪要、调研报告、PPT。

它的选择很清楚：把 harness 的复杂度全部藏起来，只暴露结果。免部署，装完就能用，预集成了混元、DeepSeek、GLM、Kimi、MiniMax 等多个模型，用户不需要关心模型配置。兼容 OpenClaw 的技能格式和 MCP。

需要澄清一点：它不是完全免费。基础功能免费，采用 Credits 计费模式，高频使用需要购买额度，企业版另有方案。

它证明了什么：对非技术用户，harness 应该是不可见的。但「不可见」不等于「不存在」——它的安全机制主要依赖客户端的高危指令拦截，企业如果要大规模用，策略层的管控还是省不掉。

OpenCode：不绑定任何一家的开源选项

由 Anomaly 团队（原 SST）开发的开源 coding agent，MIT 许可，主要用 TypeScript 和 Bun 写成。

很多人把它理解成「低配版 Claude Code」，这个理解不准确。它的核心主张是 provider-agnostic——不绑定任何一家模型厂商，通过 Models.dev 注册表能接七十多家提供商，也能通过 Ollama 接本地模型。它有终端 TUI、桌面应用和 IDE 扩展三种形态，对话存在本地 SQLite 里，整套系统可以自己部署。

它内置两个可以随时切换的 agent 模式：build（完整权限，用于开发）和 plan（只读，用于分析和探索代码）。这个设计本身就是权限分级的一个漂亮实现——不是弹窗问你，而是让你显式地选择当前处于哪个模式。

它证明了什么：harness 的价值之一是避免锁定。模型会一直换代，能平滑换模型的执行系统，比绑死在某一家上更抗风险。

横向对比

选型建议，一句话版本：写代码、团队有规范要求 → Claude Code；写代码、看重成功率和成本 → Pi；写代码、不想被绑定或要自己部署 → OpenCode；办公场景、非技术团队 → WorkBuddy；想要一个常驻的私人助理 → OpenClaw；长期用、希望它越用越懂你 → Hermes。

六、方法论：这个框架，明天上班怎么用

前面讲的所有内容，如果不能变成你手上的动作，就白讲了。这一节给具体的。

第一件事：把选型问题从一维改成二维

以后再遇到「我们该用哪个模型」这个问题，把它拆成两个：

1. 这个任务需要多强的判断力？决定模型档次。
2. 这个任务需要什么样的执行系统？决定 harness。

Databricks 的做法值得抄：他们发现工程师日常任务里，四分之一是低复杂度的（改个配置、翻个开关），六成是中等复杂度的，但默认用的却一直是最贵的模型。看清楚这个分布之后，他们把大量工作下放到了更便宜的模型档位。

你的团队大概率也有同样的浪费。先去看真实的任务分布，再决定配什么。

第二件事：需求评审时，问这六个问题

这是我认为对产品经理最实用的部分。下次技术同学跟你说「我们做个 Agent」，把这六个问题问出来。答不上来的，就是还没设计到的地方：

1. 上下文超了怎么办？是直接丢老的，还是压缩？压缩用什么策略？压完还能不能找回原文？
2. 哪些操作必须人工确认？这个清单在哪儿定义的？是写在提示词里，还是有强制机制？
3. 它失败的时候，我们怎么知道？有没有日志、有没有轨迹、能不能复现？
4. 同一个任务跑十次，成功几次？如果答不上来，说明还没建评测。
5. 经验怎么沉淀？这次踩的坑，下次会不会再踩一遍？
6. 换个模型要改多少东西？如果答案是「要重写一半」，那这个架构有锁定风险。

这六个问题，全都在 harness 层，一个都不在模型层。

第三件事：自己动手跑一次

看十篇文章不如自己跑一次。最低成本的路径：

• 非技术岗：装 WorkBuddy 或者 OpenClaw，给它一个你每周都要做一遍的重复任务——整理周报、汇总数据、批量改文件名。观察它在哪一步卡住。卡住的那一步，就是 harness 没设计好的地方。
• 有技术基础：装 OpenCode 或 Claude Code，找一个真实的小需求让它做。重点不是看它做没做成，而是打开它的配置文件，看看四个零件分别长什么样。这比读一百篇解析都直观。

跑完之后你会得到一个别人没有的东西：对失败模式的直觉。知道 Agent 会在哪儿掉链子，比知道它能干什么重要得多。

第四件事：建立自己的评测集

Databricks 那篇文章里，我认为最有价值的一句话是这个意思：任何一个有历史代码合并记录的团队，手上其实已经躺着一套基准测试了——任务是真的，评分标准是你自己写的测试，而且没有任何模型在上面训练过。

这个思路可以直接迁移到非代码场景：客服团队有历史工单和真实回复，运营团队有过往的活动方案和实际效果，财务团队有做过的报表和核对记录。

把过去三个月的真实任务挑二十个出来，把标准答案存好，让候选方案各跑一遍。这比看任何公开榜单都有用，因为公开榜单的题目早就泄漏进训练数据了，而你的历史任务没有。

不用一开始就搞得很复杂。二十个任务、一张表格、人工打分，一周之内能做完。做完之后，你在选型会上说的每一句话都有据可依。

第五件事：先做减法，再做加法

前面 Pi 的例子已经说明了：工具越多、指令越长、默认规则越密，未必效果越好。所以设计第一版的时候，反过来：

• 从最少的工具开始，能用四个通用工具解决的，不要造二十个专用的。
• 从最短的 system prompt 开始，只写你确定必要的那几句。
• 每加一样东西，都要能说清楚它解决了哪个具体的失败案例。说不清楚的，说明是「以防万一」，砍掉。

这个原则我称之为：给 Agent 的每一句话，都在跟你的任务抢注意力。

结语

回到开头那组数据。同一个模型，换一套执行系统，成本差两倍，质量不变。这件事在提醒我们一个更朴素的道理：能力和把能力用出来，是两回事。

过去两年，行业把几乎所有的资源和注意力都投在了「提升能力」上，模型一代比一代强。但决定这个能力最终值多少钱的，是外面那一层不起眼的东西——它看得见什么、记得住什么、被允许碰什么、出错时能不能自己爬起来。

模型是买来的，harness 是自己搭的。
买来的东西，所有竞争对手都能买到。自己搭的那部分，才是你的。

对产品经理来说，这可能是这一轮技术变革里，为数不多还留给我们的位置。定义身份和边界、设计信息该怎么取舍、判断哪些操作不能出错——这些从来都不是纯粹的技术问题，它们是产品问题。

只是这一次，我们服务的对象不是人，是一个会自己动手的系统。

本文中涉及的产品数据与技术细节，来自 Databricks 官方工程博客（2026 年 7 月）、各产品官方文档，以及开源社区对相关项目的源码分析。技术细节随版本迭代变化较快，落地前建议以官方最新文档为准。

现在让 AI 写一份 PRD，十分钟就能拿到一版能看的初稿。当「把东西做出来」这件事的成本被压到接近于零，产品经理凭什么拿这份工资？答案藏在一个几乎所有人都想快点跳过的环节里——启动。这篇文章把 AI 产品的启动阶段整个拆开：找竞品、做调研、写场景、筛需求、立项，每一步干什么、交什么、AI 能帮到哪一层、哪一层必须你自己扛。

引子：最贵的错误，都发生在写第一行代码之前

我见过太多这样的项目。

立项会开得很兴奋，老板拍板，团队三周做出原型，两个月上线，然后数据出来——日活三位数，留存跌破个位数百分比。复盘会上所有人都在找执行的毛病：交互不够顺、模型效果不稳、推广没跟上。没人提那个真正的问题：这个东西从一开始就不该做。

过去这套错误是有成本刹车的。想验证一个方向，你得先说服老板给人给钱，前端后端算法测试排期，两三个月过去了，中间任何一个环节觉得不对劲，项目就自然死掉了。流程慢，本身就是一道过滤网。

现在这道网没了。

一个人用 AI 能在一周内搭出可用的原型。PRD 可以让 AI 写初稿，产品结构图可以让 AI 用 PlantUML 的语法直接生成，用户故事板可以让 AI 照着模板产出五版让你挑。你想做什么，几乎当天就能做出来。

听起来是好事。但它带来一个很少被说破的后果：

AI 没有降低犯错的概率，它只是让你更快地把错误做出来。

以前一个错误方向要烧三个月才暴露，现在三天就能做出个能点的东西，然后你会拿着这个东西去说服自己「方向没问题，只是没打磨好」，接着投入真正的资源。错误被做得更快、更精致、更难承认。

把一个 AI 产品从想法推到上线，中间大概是五个阶段、十七个工作环节、十六份关键产出物。我把这张表逐格看过之后发现一件事：AI 能接管的那部分，绝大多数集中在中后段；它接管不了的那部分，几乎全部堆在最前面的「启动」。

所以问题变了。不再是「AI 产品怎么做」，而是——AI 产品怎么启动。

01 先把话说清楚：AI 能替你干什么，不能替你干什么

在讲怎么启动之前，得先把这条流水线摊开看一眼。不然「启动很重要」这句话，跟「要重视用户」一样，是句正确的废话。

现在，拿一支笔，把 AI 今天已经能干得不错的环节圈出来：

AI 基本能接管的

• 竞品的资料收集。官网、研报、社交媒体上的公开信息，让 AI 去搜、去整理、去列表格，比你自己一个个开网页快得多。
• 用户访谈的转录和归类。录音转文字、把三十个人说的话按主题聚成几堆，这活儿 AI 做得又快又便宜。
• 用户故事板的初稿。给它角色、目标、场景三个要素，它能给你一版结构完整的推演。
• PRD 初稿、产品结构图、流程图。尤其结构图，直接让它输出 PlantUML 的代码，粘进去就是一张图。
• 上线后的数据分析。异常波动的定位、分渠道分版本的对比，AI 比大部分人手工拉表快。

AI 替不了你的

• 判断一个需求是真是假。
• 在访谈现场，听出对方那句话背后没说出口的东西，然后追一句「为什么」。
• 让研发、测试、运营三方在一场评审会上达成一致。
• 项目卡住的时候，去找那个能解开卡点的人。
• 决定这件事到底做不做。

AI 擅长的是「把已知的东西整理出来」，它不擅长的是「判断哪些东西值得被知道」。

02 第一步：不要先想创意，先去找竞品

当你想做任何一款产品或功能时，先去找竞品。这句话我想放大加粗贴在每个产品团队的墙上。

我知道很多人不服：先看竞品不就成抄袭了吗？我的想法明明是原创的。

这个逻辑有个前提错误——你去看竞品，不是为了知道该做什么，是为了知道什么已经被证明过了。

竞品分析到底在回答什么

说白了就三件事：

第一，证明这件事能活下去、能赚钱。如果一个方向做了五年没有一家活下来，大概率不是所有人都比你笨，是这条路本身有问题。反过来，如果已经有产品把规模做起来了，至少说明需求是真的、用户是愿意付钱的。

第二，持续盯住对手，新功能好及时跟进。竞品分析不是一次性的作业，是长期动作。对手上了什么新功能、改了什么定价、换了什么主推场景，这些都是免费的市场测试结果。

第三，找机会点：他们没做什么，我们能做什么。这才是真正出差异化的地方。

对应到日常工作里，竞品分析有四个具体用处：辅助决策、寻找差异化、规避风险、快速迭代。

三类竞品，别搞混

• 直接竞品：产品形态、核心功能、目标用户跟你一致。日常做小版本迭代，分析直接竞品就够了。
• 间接竞品：产品形态不同，但两个产品可以同时存在，抢的是同一批人的同一段时间或同一笔预算。
• 潜在竞品：没有直接竞争，存在替代关系。这类不用花太多精力。

怎么找？C 端产品直接下载注册用，把付费墙也走一遍。B 端产品联系对方销售，走一遍完整的售前流程——如果需要，跟老板申请买一个账号试用，这笔钱是所有市场调研里性价比最高的。

AI 产品的竞品分析，多了一个维度

传统产品看四件事：市场定位、产品功能、用户体验，再加上竞争格局。AI 产品要多看一层：模型技术。

一、市场定位（最难，但价值最高）。要弄清楚：这个产品的定位是高是低，目标人群是谁，市场规模有多大。这里有个新手最容易犯的错：去算领域的总体规模。说「中国 AI 应用市场有几千亿」没有任何意义。有意义的问题是：头部几家吃掉之后，剩给我们的还有多少。

然后认真算一遍，看看投入能不能回本。不是走形式的财务模型，是真的把服务器成本、模型调用成本、获客成本、人力成本加起来，除以你预计的付费用户数。AI 产品尤其要算这笔账——每一次调用都在烧钱，用户越多亏得越多的产品是真实存在的。

二、模型技术（AI 产品独有）。看两件事：模型技术选型（开源还是闭源，这决定了对方的成本结构、迭代速度、被上游卡脖子的风险）；模型性能，重点看 TTFT（首次响应时间）和 TPS（响应后的连贯程度）。

为什么盯这两个？因为对普通用户来说，AI 产品的体感差异，一大半来自这两个数字，而不是模型有多聪明。一个答案质量稍差但秒回的产品，用户留存往往好过一个答案更好但要转八秒圈的产品。这是可以实测的：拿同一个问题，在两个产品上各问十次，掐表记时间。这份数据交给研发团队，比你说一百句「我们要提升体验」都管用。

三、产品功能。先找核心功能——判断标准很简单：产品没有这个功能就不存在了。抖音没有信息流推荐就不是抖音，微信没有聊天就不是微信。找到核心功能，才知道对方真正的护城河在哪儿，其余都是装饰。然后拉功能矩阵，围绕核心功能把辐射出去的功能一层层列出来。你会很直观地看到对方的产品逻辑，也会看到他们刻意没做的地方。

四、用户体验。交付流程：从用户产生念头到拿到结果，中间隔了几步。界面设计：主要操作流程尽可能短，最好不超过五步。内容质量：这是 AI 产品特有的一项——对产品生成的内容本身做测评。准备一组固定的测试用例，同一批输入喂给不同产品，把输出摆在一起对比。这是最实在的功课，也是最多人偷懒跳过的。

怎么做，以及交出什么

流程是五步：明确分析目的 → 筛选竞品（一到两个旗鼓相当的，加一个行业标杆，别贪多）→ 确定分析维度 → 资料收集 → 对比分析拉表格。

关于第一步「给谁看」，这里有个很多人没意识到的关键：同一份竞品分析，不同的人要从里面拿走完全不同的东西。老板要看的是怎么提升市场占有率；产品团队要看的是竞品哪个功能可以直接借鉴；研发团队要看的是竞品的各项性能数据，我们差在哪；运营团队要看的是竞品最近推了什么活动。

你如果不提前问清楚「这份报告是给谁用的」，写出来的东西就是四不像——每个人都翻了两页，然后放下了。

最终报告的结构四段就够：报告概况 → 竞品概况 → 详细对比 → 自身问题分析。最后一段最重要，也最容易被删掉。前面三段都在讲别人，只有第四段在讲你自己。一份没有结论指向自己的竞品分析，等于没做。

03 第二步：用户调研不是去证明你对，是去找自己哪里错了

竞品分析看的是供给侧，用户调研看的是需求侧。两个都做完，你才有资格谈方向。

先纠正一个观念

大部分人做调研，心里是想找支持自己的证据的。问题设计得诱导性十足，遇到反对意见就归类为「这个用户不是我们的目标人群」，最后写出一份「用户非常期待这个功能」的报告。

调研是为了发现哪里错了。

把这句话记住，你的调研质量立刻提升一半。

调研真正能给你的东西有四样：降低决策风险、发现真实痛点（方法只有一个：不断问「为什么」）、修正产品方向、建立用户画像。

还有一个必须提前知道的坑：用户会说谎，或者根本无法准确表达。这不是贬低用户。人对自己行为的解释能力天然有限——你问一个人为什么每天刷两小时短视频，他会给你一个听起来很合理的理由，但那个理由多半是他事后编出来的。所以调研里，用户说了什么只是原料，用户在什么情境下做了什么才是事实。

五个阶段，每一步都有具体动作

准备阶段。想清楚调研目的是什么：是为了优化某个功能，还是为了搞明白用户到底遇到了什么问题？这两件事的问法完全不同。定调研方法，设计调研问题（根据目的来设计，不是随便列二十个）。找主战场：各大应用商店的用户评价、应用内的用户反馈——这两个地方是免费的、量大的、真实的原始素材，AI 在这一步能帮你把几千条评价聚类，效率极高。

招募阶段。确定要邀请的目标用户名单，提前邀约。

执行阶段（这一步的细节决定了调研的成败）。

• 全程录音，有条件的话录像。后面分析要反复回看。
• 两个人一组：一个主持人，一个记录人。
• 主持人先破冰，拉近关系。开场先聊几句无关的，别一上来就掏问题清单。
• 说明免责声明：明确告诉对方，本次内容只在公司内部调研使用。这句话必须说，既是尊重，也能显著提高对方说真话的意愿。
• 主持人不要输出观点。你一旦表态，对方就会开始迎合你。你的任务是让他说，不是让他同意你。
• 记录人要记：时间、表情、反应（比如反应很大的地方），以及当时对方所说内容的总结。

为什么要记表情和反应？因为这是判断真伪的最重要线索。一个人说「这个功能挺好的」，语气平淡；说到另一个地方突然坐直了、语速变快了——后面那个才是痛点。这类信息，录音转文字之后是丢失的，AI 也读不出来。这就是为什么现场必须有人。

分析阶段。整理用户分析信息；客观陈述用户反馈，逐条列出，不可以加入任何的主观判断。

这条我要单独强调。分析和陈述必须分开，先把用户原话完整摆出来，再另起一段写你的判断。混在一起写的报告，读的人无法分辨哪句是用户说的、哪句是你想的，整份报告的可信度就没了。

总结阶段。用户表示对什么东西强烈不满的地方，在原文的位置标出来，或者直接把原话贴在后面。

调研报告的五个要素

1. 背景与目的
2. 样本描述（多少人、什么画像、怎么招募的）
3. 关键发现
4. 问题归类与优先级
5. 行动方案——下一步行动建议

以及一个通用原则：文档一般都要给出下一步行动建议。一份看完之后不知道该干什么的报告，就是一份浪费所有人时间的报告。

04 第三步：场景分析，把需求演一遍

竞品和调研做完，你手上会有一堆碎片：用户说了什么、竞品做了什么、市场有多大。但这些还不足以支撑一个产品判断，因为它们都是静态的。场景分析要做的，是把这些碎片拼成一段连续的、能演出来的过程。

核心动作只有一个：代入用户

具体到什么程度？模拟用户从早上睁开眼开始，到与你这款产品产生直接联系为止的全部行为。

不是从「用户打开 App」开始——那已经太晚了。你要往前推：他在什么状态下想起这件事的？在做什么？手边有什么？为什么在这个时刻他觉得需要解决？

举个不加 AI 的例子：一个记录类工具，如果你的场景推演是从「用户打开 App 点新建」开始，你会做出一个功能齐全的编辑器。但如果你真的把用户的一天走一遍，你会发现关键时刻是「他在地铁上，一只手抓扶手，脑子里冒出一个念头，三秒钟之内如果没记下来就忘了」。这两种推演，会导出完全不同的产品——后者的核心功能是「一步到达输入框」，前者的核心功能是「排版」。

AI 产品尤其要做这一步。因为 AI 产品的本质，大多数时候是替代用户原本的一个旧动作。你必须知道那个旧动作长什么样、发生在什么时刻、有多难受，才知道你要替代的到底是什么。

标准流程五步

1. 确定目标角色
2. 设定核心目标（必须与产品有直接联系）
3. 还原时空环境（与产品有直接联系）
4. 梳理行为路径（与产品有直接联系）
5. 还原时空

三个「与产品有直接联系」不是重复。它是在反复提醒你：场景推演很容易写成小说。写着写着就开始描写用户的心理活动、家庭背景、职业理想，热闹但没用。每写一句都要回头问一遍：这句话跟我要做的功能有关系吗？没关系就删。

AI 在这一步能帮什么

可以帮很多，前提是你给的提示词足够具体。一个能直接用的模板：

帮我列出一些与「XX 产品」相关的内容：
1. 这个产品在什么场景下，帮谁解决了什么问题？
2. 用户使用的操作流程是怎样的？尽可能详细地描述每一个步骤。
3. 挖掘用户心理状态，每一个动作背后，他的情绪变化是怎样的？
4. 寻找共情点，哪里不爽？哪里可以优化？
5. 如果为了实现这样的产品功能，需要哪些数据字段？

拿到 AI 的输出之后，你的工作不是照抄，是逐条划掉那些不成立的。AI 给你的是一个「常见用户」的平均推演，它写得很顺，但里面一定混着现实中不会发生的步骤。你用调研里那些真实的表情和反应去校准它——这才是人和 AI 在这一步的正确分工。

05 第四步：需求宽进严出，甄别只认三把尺

前面三步做完，需求会自己涌上来。这时候最考验人的不是找需求，是拒绝需求。

一条铁律：宽进严出

所有的需求都要接，宽进严出。如果你在需求提出的当场就拒绝，会发生两件坏事：一是对方以后不再给你提需求了，你的信息源断了；二是你在信息不完整的情况下做了判断，很可能拒错。

正确的做法是：当场全接、当场记录、事后严格筛。筛掉的需求要有记录、有理由，下次对方再问的时候你拿得出来。这不是拖延，是把判断从「情绪现场」挪到「冷静桌面」。

拿到需求之后，先还原三件事

• 用户：使用者是谁？谁对产品产生了这个问题？
• 问题：在什么情境下，使用产品时产生了这个问题？
• 现状：目前产品使用中存在的问题是什么？

这三个问题问不清楚，这条需求就还不能进池子。因为你后面所有的判断，都要建立在这三个事实上。

三把尺：普遍、痛点、高频

这是整篇文章里最该被记住的部分。一条需求要三项全中，才算真需求。

• 普遍：这个需求是普遍存在的，还是只是这个用户的特例？
• 痛点：现有的产品方案是否已经解决了这个问题？如果已经能凑合解决，那它就不是痛点。
• 高频：这个需求会不会反复出现？只出现一次的问题，不值得为它做一个常驻功能。

三项里缺任何一项，都不该进开发排期。缺「普遍」，你是在为一个人做定制；缺「痛点」，你做出来用户懒得切换；缺「高频」，你做出来用户用一次就忘了它在哪儿。

我建议把这三个字直接做成需求评审会上的一张表，每条需求当场打三个勾。有人拍脑袋提需求的时候，你不用跟他吵，把表推过去让他填。

分优先级：P0 / P1 / P2

判定标准就一条——与产品定位的距离。P0 核心需求：与产品定位直接相关。P1 分支需求：与产品定位相关。P2 辅助需求：使产品更加完善。

注意这个标准里没有「老板要」「竞品有」「研发觉得好做」这几项。这三样是干扰项，不是标准。

需求收集
   ↓
需求澄清（理解这个需求 / 搞清楚为什么 / 用户场景目的）
   ↓
判断需求真伪（普遍、痛点、高频）
   ↓
划分优先级
   ↓
记录到需求池
   ↓
需求分析 —— 判断「做」还是「不做」
   ├─ 不做 → 记录结束（但必须记下不做的理由）
   └─ 做  → 写出需求方案 → 多方案评估 → 需求分析表 → 功能清单

06 第五步：立项，把前面所有事压成一个能被否掉的判断

立项报告不是把前面四份文档订在一起交上去。它的作用是：把一堆分析压缩成一个明确的、可以被否决的判断。

一份立项报告要能回答清楚四个问题：

1. 我们要为谁，解决什么问题？（来自用户调研 + 场景分析）
2. 这件事凭什么是我们做？（来自竞品分析里的「自身问题分析」那一段）
3. 做到什么程度算成功？（明确的、可测量的指标，不是「提升用户体验」）
4. 投入多少，多久回本？（来自市场规模那一步真刀真枪算的账）

第四个问题在 AI 产品上必须格外认真。传统软件的边际成本接近零，用户越多越划算；AI 产品每一次调用都在花钱，用户量上去了但转化没上去，是会把公司拖垮的。所以在立项阶段就要把单位经济账算清楚：一个活跃用户一个月消耗多少模型成本，付费转化率要到多少才不亏。这笔账算不出来的产品，不该立项。

还有一个判断标准，我称之为「能不能被否掉」。

一份好的立项报告，看完之后老板是有可能说「不做」的。如果一份报告写得让人只能说「好，那就干吧」，那它多半只是一份说服材料，不是判断材料。产品经理的职业价值，一半在于推动该做的事，另一半在于拦住不该做的事。后一半没人给你发奖，但它省下来的钱是真的。

07 方法论：一份可以照着做的「启动七日清单」

前面讲了这么多，最后给一套能直接上手的东西。周期可以按项目大小放大缩小，但顺序不要动。

Day 1｜把目的写死在一张纸上

动作：写下三句话——我们准备为谁、解决什么问题、做到什么程度算成功。成功标准必须是能测量的数字。
产出：一页纸的启动目标。
AI 用在哪：不用。这一步只能是人拍板。
自检：把这张纸给一个不在项目里的同事看，他能不能一句话复述出来。做不到就重写。

Day 2–3｜竞品

动作：筛一到两个直接竞品加一个行业标杆。C 端全部注册使用，走到付费墙；B 端联系销售走完售前。四个维度逐项填表：市场定位、模型技术（实测 TTFT 和 TPS 各十次）、产品功能（先定核心功能）、用户体验（数操作步数、跑一组固定测试用例对比生成质量）。
产出：竞品分析报告。
AI 用在哪：公开资料收集、信息整理、表格生成。实测和亲身体验不能交给 AI。
自检：第四段「自身问题分析」是否给出了明确的差异化方向。写不出来，说明前面白做了。

Day 4–5｜用户调研

动作：先扫商店评价和应用内反馈（这一步 AI 帮你聚类），从中提炼假设；再约五到八个真实用户做深访，双人一组、全程录音、主持人不表态、记录人记表情和反应。
产出：用户调研报告。
AI 用在哪：评价聚类、录音转写、访谈内容按主题归类。追问和判断不能交给 AI。
自检：报告里有没有一条结论，是跟你 Day 1 的假设相反的。如果一条都没有，那你多半只是在自证。

Day 6｜场景与需求

动作：上午做场景推演——挑一个核心用户角色，从他早上睁眼演到接触产品，用五步标准流程走完；下午过需求——把所有收集到的需求过一遍「普遍、痛点、高频」三把尺，然后按与产品定位的距离排 P0/P1/P2。
产出：用户功能旅程图 + 需求池 + 产品功能清单。
AI 用在哪：用提示词生成故事板初稿，然后你用调研里的真实素材逐条划掉不成立的部分。
自检：P0 清单里有几条？超过五条就是没做取舍，回去重排。

Day 7｜立项

动作：把前面全部压成一份立项报告，回答那四个问题，把单位经济账算出来。
产出：立项报告。
AI 用在哪：文档成稿、数据表整理。判断不能交给 AI。
自检：这份报告，老板有没有可能看完说「不做」。

三个不该启动的信号

写完了先别急着交，对照这三条看一眼。中任何一条，我建议你把项目往后压：

1. 竞品分析的「自身问题分析」那一段写不出来。说明你没找到自己的位置，只是想做个差不多的东西。
2. 调研里没有出现任何一条推翻你原有假设的信息。说明调研做成了走过场。
3. 单位经济账算不出来，或者算出来要靠「以后规模上去就好了」来圆。AI 产品上这句话通常是反的——规模上去，亏得更多。

最后，把这套东西用起来的关键

不在于文档写得多漂亮，在于你能不能在会议室里，用这套东西支撑一次「不做」的判断。

你可以从下周开始，只做一件事：下一次有人给你提需求的时候，不要当场答应，也不要当场拒绝。你说「我记一下」，然后回去用三把尺打三个勾，用 P0/P1/P2 排一下位置，第二天给对方一个带理由的答复。

坚持两个月，你在团队里的位置会发生变化。因为大家会发现，你是那个能说清楚为什么的人。

结语：AI 把「做」变便宜了，「判断」还是原价

回到开头那个问题：AI 已经能写 PRD、能画用户故事板、能生成产品结构图，那产品经理还剩下什么？我的答案是三句话。

第一，创业和做产品的最小单元，确实在被压缩。一个人加上一套 AI 工具，今天真的能把一款产品从想法推到应用商店上架。这不是段子，是正在发生的事。这意味着团队规模不再是壁垒，判断力才是。

第二，加了 AI 功能的不一定是好产品，能让用户忘记 AI 存在的产品才更有价值。用户不关心你背后用了什么模型、写了多长的提示词。他感知到的只是：一个东西帮他把事情办了。AI 最好的状态是被藏在有用和有趣的背后，而不是顶在产品名字前面。

第三，也是对我们自己最重要的一条：AI 把「把东西做出来」的成本压到了很低，但「判断这个东西该不该做」的成本，一分钱没降。

写文档、画原型、拉表格，这些能力正在快速贬值——不是因为它们不重要，是因为它们不再稀缺。而在访谈现场听出一句话背后的犹豫、在评审会上顶住老板的一个拍脑袋需求、在数据还没出来之前判断一个方向是不是死路，这些能力反而变得更值钱了。

所以，AI 产品之间真正的差距，在需求进入需求池之前就已经拉开了。

后面那些跑得快的团队，不是执行力更强，是他们在启动阶段少犯了几个错。

本文基于一线产品工作方法整理。文中提到的 Incredibox 相关数据引自《人人都是产品经理》平台「扬帆出海」专栏公开报道。