---
source_url: "https://mp.weixin.qq.com/s/N26pnOoBwnWsglqaobPcRA"
title: "给产品经理的loop engineering"
author: "AI技术立文 (译自 Shubham Saboo, Google PM)"
date: 2026-06-24
ingested: 2026-06-24
sha256: ""
language: zh
tags: [loop-engineering, product-management, pm, ai-agent, iterative-improvement]
---

ps. 本文来自 Google 的产品经理 - Shubham Saboo

产品经理下一项需要掌握的能力，会从 prompt engineering 转向 loop engineering，也就是循环工程。

过去两年，大多数产品经理都在练习怎么把提示词写得更好。更清楚的指令，更充分的上下文，更合适的例子，更准确地告诉 Claude、Codex、Cursor，或者任何你正在使用的智能体该做什么。

更重要的能力，是设计一套能在反复运行中持续改进的系统，而非每次都重新写一个完美提示词。

循环，就是 AI 系统反复执行的一组流程。你修改某个会影响智能体行为的配置或规则。运行智能体。评估输出。如果质量变好，就保留这次修改；如果质量变差，就回退。然后把这次经验记录下来，让下一次运行直接沿用这次改进。

对工程师来说，这个周期通常从代码开始。

对产品经理来说，起点在别处。它从那些影响产品工作的长期资产开始：PRD 评审技能、客户访谈总结器、评估标准、发布检查清单、研究工作流、CLAUDE.md 指令、提示词模板，或者优先级框架。

这些东西会长期存在，也会被反复使用。它们写进了你的判断，会影响智能体此后几十次运行，而不只是影响某一次输出。

也因为它们会被反复使用，效果会不断累积。一个好的工作资产，会让你的判断和产出每周都更稳定。一个坏的工作资产，也会让你的工作每周都变慢，而且变化很隐蔽。直到某天你发现输出不太对，却说不清原因。

所以它们需要循环。一个一次性的提示词，写错了还能承受。一个十个人都依赖的评审标准，就不能这样。

## 1. 写提示词解决不了的问题

第一层变化很明显。智能体让构建东西变得更容易。

你描述一个仪表盘，就能拿到一个原型。你写下一个粗略想法，就能得到可运行的代码。你交给它十份客户访谈记录，几分钟后就能拿到结构化总结。

这改变了产品经理的工作流。你不再只是写规格说明，交给工程师，等待，评审，再重复。你现在可以直接参与第一个版本的形成。

但这样工作一段时间之后，你会遇到另一个问题。

你的 AI 工作区会开始走样。

你的 CLAUDE.md 变得越来越长。你的 PRD 评审技能变得越来越严格。你的研究工作流带进了旧项目里的指令。你的发布检查清单越扩越长，直到智能体忽略其中一半。你的评估标准变了，但你忘了什么时候改的，也忘了为什么改。

一个月后，智能体的表现变差了。它写出的 PRD 质量下降。研究总结变得空泛。以前能捕捉到的产品细节，现在开始漏掉。

模型本身大概率没有变差。是这些工作资产已经走样，而且没有任何机制在监控它们。

这才是循环工程真正要为产品经理解决的问题。重点不在某一个提示词写得多好，而在那些影响产品工作的长期资产能否持续改进，避免慢慢失效。

## 2. 一个循环到底由什么组成

一个有用的循环包含五个部分：触发器、动作、证据、记忆和停止条件。

触发器说明循环什么时候开始。动作说明智能体应该做什么。证据说明你如何判断输出是否变好。记忆说明经验保存在哪里。停止条件说明循环什么时候结束。

最后一个部分，在递归循环里尤其重要。

很多 AI 系统失败，问题往往不在模型，而在循环没有干净的退出方式。智能体会持续生成，持续扩大范围，持续发明新工作。或者在证据不足时，给你一份自信的总结。

一个好的产品循环，应该允许自己说：没有发生有意义的变化，输入信息不足，这件事被阻塞了，质量没有达标，或者这里需要人来决策。

一个能说"停止"的循环，你才敢让它运行。一个不能停止的循环，你只能一直看着它。

如果你想看真实环境里的循环，Matthew Berman 的 Loop Library 收集了工程、研究和运营中的真实案例。它们主要面向工程师，但这五个部分同样适用于产品工作。

## 3. 落到实际工作里是什么样

拿客户研究来说。

简单做法是让智能体"总结这些访谈"。这对一次性任务有用，但不会改善下一次访谈总结的质量。

更好的做法，是做一个客户访谈总结器，让它知道你的团队真正关心什么：痛点、当前替代方案、紧迫性、反对意见、产品缺口、原话引用，以及后续动作。

循环版本每周运行一次。它使用这个总结器，把新的访谈和之前的主题对比，标出哪些信号反复出现，哪些是新变化，哪些地方证据不足。你评审输出。如果总结漏掉了细节，就改进这套总结规则。下一次运行时，它会用上这次修正。

PRD 评审也是一样。

简单做法是问："能帮我评审一下这份 PRD 吗？"更好的做法，是有一套 PRD 评审规则，知道你的团队对质量的要求。循环版本会测试这套规则是否真的给出了更好的反馈。

它能不能抓到模糊的问题？会不会推动补充真实证据？能不能指出缺失的指标？会不会避开无意义的吹毛求疵？能不能保留产品意图？

当答案开始变差时，你要修评审规则，而不是临时改一个提示词。

写提示词能帮你完成一次任务。循环工程改进的是决定任务怎么做的长期规则，让之后每次执行都受益。

## 4. 你的第一个循环：每周产品信号

我不会从一个试图决定产品战略的循环开始。

这个范围太大，主观性太强，也太容易出错。我会从产品运营开始。那里有重复工作，有证据，也更需要一致性。

一个好的起点，是每周产品信号循环。

每个周五，这个循环读取客户访谈、支持工单、销售记录、实验更新、数据分析摘要、已发布变更和未关闭的升级问题。它产出一份产品信号备忘录。

这份备忘录不应该只是泛泛总结。它要把反复出现的信号和孤立噪声分开。

它应该包含客户原话，说明和上周相比发生了什么变化，指出哪些地方证据不足，并识别哪些产品路线图假设得到了加强，哪些被削弱，哪些没有变化。

你来评审它。如果备忘录漏掉了重要内容，就更新规则。如果智能体过度重视了弱证据，就收紧评估标准。如果出现了新的产品问题，就把它加入下周的观察视角。

几周后，它会开始变得有用。

几个月后，它会成为每次产品路线图会议前你都会先查看的东西。

## 5. 品味仍然重要，只是现在需要证据

产品经理一直依赖品味。

一个好的产品经理读 PRD 时，能感觉到问题定义是否模糊。他能判断一条客户引用是不是被过度解读了。他能看出发布计划里是不是假装某个依赖不存在。

这种判断仍然重要。循环工程不会移除它，反而会把判断放到中心位置。现在这份工作的核心，是定义什么叫正确，并判断它何时已经达成。问题是，你怎么在不靠猜的情况下做到这一点。

当你把自己的判断写进可复用规则里，品味就需要证据。

如果你修改了一套 PRD 评审规则，怎么知道它真的变好了？如果你更新了一个研究总结器，怎么知道它捕捉到的是更多信号，而不是更多噪声？如果你收紧了发布检查清单，怎么知道它提升了发布准备度，而不是增加了流程负担？

这就是评测进入产品工作的地方。

产品经理的评测不需要一开始就是大型基准测试。它可以从已知案例开始。

拿三份质量高的 PRD 和三份质量差的 PRD。用你的 PRD 评审规则评一遍。它抓到了真正的缺口吗？它避开了无意义的挑刺吗？它保留了产品意图吗？

拿五次你已经理解过的客户访谈。运行你的研究总结器。它捕捉到了真实痛点吗？引用准确吗？它能区分强信号和一次性噪声吗？

拿两次过去的发布：一次顺利，一次混乱。运行你的发布准备度循环。它本来能抓到那个真正出问题的点吗？

这就是循环工程。问题不在于"这个智能体听起来聪不聪明"，而在于"这套规则面对已知案例时，是否更接近你的产品判断"。

## 6. 循环需要记忆层

一旦你开始评估这些规则，就需要一个地方保存经验。否则改动会散在聊天记录、文件片段和个人记忆里，很快就丢了。

你在聊天里改了一个提示词。你把一条新指令粘进文件。你调整了一个标准。你加了一个例子。你删掉一个约束。输出变了，但历史没了。

几周后，没人知道智能体为什么会变成现在这样。

这就是 GitHub 变得有用的地方。产品经理不需要都变成工程师，但需要版本历史来管理那些越来越影响自己工作的规则、模板和检查清单。

规则放在那里。变更放在那里。评测结果放在那里。决策记录放在那里。回滚路径也放在那里。

如果一套规则变好了，你需要留下那次 commit。如果它变差了，你需要看到 diff。如果标准变了，你需要知道原因。如果发布检查清单抓住了一个真实阻塞点，你希望这次经验能保存到下一次发布。

仓库会变成产品工作的记忆层。

## 7. 任何循环都可以从这个骨架开始

这件事不用做得很复杂。

选一个重复发生的产品任务。写清楚它什么时候开始，使用哪些输入，由哪套规则来引导，智能体应该做什么，什么样的输出算好，经验保存在哪里，以及循环什么时候停止。

这样就足够开始。

关键是把循环保持在足够小的范围内，让你真的能判断它有没有变好。每一个严肃的产品循环，也都应该写清楚人仍然负责什么。

循环可以总结客户证据，但不应该独自决定战略。循环可以评审 PRD，但不应该变成产品负责人。循环可以标记有风险的发布，但不应该在缺少上下文时替你做权衡。

可以建立循环，但产品经理不能离开决策位置。

## 8. 循环通常会在哪里失效

循环通常会以很简单的方式失败。

触发器模糊。输入混乱。规则太长。证据太主观。经验没有地方保存。停止条件太弱。

或者，你太早给了循环过大的权力。

最后一点是陷阱。不要从一个可以改变战略、给客户发消息、更新产品路线图，或者在未经评审的情况下做出产品承诺的循环开始。

先从能帮助你决策的循环开始，最终决策仍然由你来做。让它们先赢得信任，再慢慢提高自主度。

这可能是产品工作里使用智能体最健康的方式。

## 9. 产品经理的工作会变成什么

产品经理过去的工作是翻译。把客户痛点翻译成需求。把业务目标翻译成产品路线图。把工程约束翻译成取舍。

这份工作仍然存在。但现在它上面多了一层。

你现在要设计那些让产品判断可重复的系统。你沉淀规则，给它们做版本管理，评估它们，并发现它们什么时候走样。智能体执行任务。你负责判断支撑任务执行的规则是否在持续改进。

最好的产品经理，不会是拥有最长提示词库的人。他们会知道产品工作中的哪些部分应该变成可长期运行的循环，哪些规则应该引导这些循环，哪些决策必须留给人。

这就是产品工作的未来。

未来的重点会转向另一件事：把可复用、可版本化、可评估的规则放进循环里，让系统在一次次运行中变得更可靠。

参考链接：
[1] https://signals.forwardfuture.ai/loop-library/