惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
博客园 - 司徒正美
C
Check Point Blog
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
IT之家
IT之家
B
Blog
博客园_首页
量子位
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
J
Java Code Geeks
H
Help Net Security
A
About on SuperTechFans
Apple Machine Learning Research
Apple Machine Learning Research
Jina AI
Jina AI
D
DataBreaches.Net
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
云风的 BLOG
云风的 BLOG
Google DeepMind News
Google DeepMind News

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
从 Harness 到 Loop:AI 产品的下一个设计层
John · 2026-06-11 · via 人人都是产品经理

AI产品经理的工作范式正在经历深刻变革——从编写静态prompt到设计动态loop机制。当Claude Code的作者宣称"我的工作是写loop"时,这标志着一个新时代的开始:产品经理需要构建包含验收标准、独立评审机制和止损条件的完整循环系统。本文将深入解析loop设计如何成为AI产品的核心竞争力,以及产品经理该如何交付包含判定机制与记忆回路的下一代方案。

前几天 Anthropic 的 Lance Martin 发了篇文章,讲他怎么用 loop 来跑新模型。文章本身是写给工程师的,但我读完的第一反应是:这事跟产品经理的关系,可能比跟工程师的关系还大。

Claude Code 的作者 Boris Cherny 说过一句最近被反复引用的话:他已经不直接 prompt 模型了,”我的工作是写 loop”。几百个 agent 读他的 GitHub 和 Slack,自己决定接下来做什么。

loop 突然火起来,但中文社区的讨论大多停在工程层面:怎么写 bash 循环、怎么配 hook。

我想换个角度聊聊:如果你是一个做 AI 产品的 PM,loop 意味着什么。

先把概念捋清楚:harness 是环境,loop 是机制

去年大家都在谈 harness。模型之外的一切都算 harness:

给它什么工具、什么沙箱、能读哪些文件、有哪些权限。一句话,harness 是模型干活的环境。

但环境是静态的。你给模型配了一间设备齐全的车间,不等于它知道今天该干什么、干到什么程度算完、干砸了怎么办。

loop 补的就是这一层。它是架在 harness 之上的运行机制:模型跑一轮,从环境里收到反馈,对照标准检查,没达标就带着反馈再跑一轮,直到验收通过。Lance 文章里提到的 Claude Code 的 /goal 命令、Claude 托管 Agent 里的 Outcomes,都是把这套机制做成了产品原语。

所以现在的 AI 产品其实有三层:

模型是引擎,harness 是车间,loop 是排班和验收制度。引擎大家都从几家厂商买,车间的搭法也越来越标准化,能拉开差距的开始变成第三层。而机制设计这件事,工程师未必比 PM 更擅长。

Lance 的实验里,藏着两个产品启示

Lance 做了个实验:让模型在 8 张 H100 上自主做机器学习调优,连续跑 8 个小时,自己改代码、跑训练、读日志、决定下一个实验。细节不展开,我只说两个对产品人有用的发现。

第一个:他给模型的不是操作步骤,而是一份验收清单。九条可检查的标准,比如”必须先跑基线”、”至少做 20 组实验”。模型怎么达成,随它。

这其实就是 PRD 思路的迁移。过去我们写需求文档是给人看的,要描述流程和交互;给 loop 写的”需求文档”是一份 rubric,核心只有一个问题:什么状态算完成,怎么客观地检查。比起规定怎么做,说清什么算做完要紧得多。一条模糊的标准(”代码质量要高”)会让整个 loop 空转,换成可检查的写法(”测试全过且无新增 lint 报错”)它才收敛得了。

第二个发现更有意思:不能让模型自己给自己打分。

Lance 提到,模型自我批判的效果不好,它会倾向于认可自己刚做完的东西。有效的做法是再开一个独立的”验收 agent”,在干净的上下文里打分,跟执行者完全隔离。运动员不能兼任裁判,对模型也一样。

这对产品设计的含义很直接:在你的 AI 产品里,”判定任务完成”应该是一个独立的机制,而不是执行流程的最后一步。谁来验收、不通过怎么打回?验收者能看到哪些信息,会不会被执行过程的叙述带偏?这些都得画进产品方案。

记忆:跨会话的外循环

文章后半段讲记忆,我觉得是更被低估的部分。

如果说自我纠错是会话内的小循环,记忆就是跨会话的外循环:

这次踩的坑,下次别再踩。Lance 用一个基准测试对比了三代模型怎么用记忆,三代都在记,差距体现在记忆的深度上。他描述了一个五步的递进:出错并记下来,弄清楚为什么错,验证自己的诊断,把诊断提炼成通用规则,最后在新任务里直接查规则而不是重新踩坑。

弱一点的模型停在第一步,记忆库就是一堆错题集和猜测,下次也想不起来翻。强的模型能走完全程,把教训变成规则。

做过记忆功能的 PM 应该都有体感:

大部分产品的”记忆”就是存聊天历史,本质是个回收站。Lance 这个递进给了一个更好的设计框架。记忆功能的价值不在存储,而在回路是否闭合:写进去的东西经过了验证吗?提炼成可复用的形式了吗?下次任务开始时,它会被读到吗?三个环节断掉任何一个,记忆就只是占地方的日志。

反过来,回路一旦闭合,这部分积累很难被抄走。模型能力人人都买得到,但你的产品在这个用户身上验证过的那些规则,竞品拿不到。

那 PM 到底要交付什么

说点实操的。如果你在做 agent 类产品,我觉得有四个问题值得在方案评审之前先想清楚。

任务的”完成”由谁判定、依据什么标准?反馈信号从哪里来,是测试结果、用户行为,还是独立的评审 agent?loop 什么时候必须停,迭代次数上限和预算上限是多少?记忆写入什么、何时被消费?

第三个问题单独说一句。loop 不会自己停,停止条件是设计出来的。Uber 今年给工程师设了每人每工具每月 1500 美元的 AI 开支上限,因为年度预算四个月就烧完了。一个没有止损机制的 loop,要么烧钱,要么”规模化地生产自信的错误”。止损听起来是成本问题,等账单或者错误交到用户手上,就变成信任问题了。

这两年这个岗位的工作对象一直在上移:

先是写 prompt,后来管上下文,现在到了设计 loop。交付物也跟着变了,以前是界面和流程图,现在还要加上一份验收标准、一个判定机制和一组止损条件。

模型还会继续变强。我的判断是,这反而让机制设计更值钱:引擎越猛,方向和刹车越不能省。

本文由 @John 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议