面向产品经理的循环工程（Loop Engineering）
面向产品经理的循环工程（Loop Engineering）
面向产品经理的循环工程（Loop Engineering） 面向产品经理的循环工程（Loop Engineering） Modified June 22 循环的五个组成部分 实践中是什么样 以客户研究为例。 简单版本是问智能体：“整理这些访谈。”这一次很有用，但它不会让你下次整理访谈时变得更好。 更好的版本，是一个客户访谈整理器。它知道你的团队关心什么：痛点、当前替代方案、紧迫性、反对意见、产品缺口、原话引用，以及后续跟进。 循环版本每周运行一次。它使用这个整理器，把新访谈和过去主题进行对比，标出哪些是重复出现的、哪些是新的，以及哪些地方证据还很薄。你评审输出。如果这份整理漏掉了细微差别，你就改进这个产物。下一次运行会更好。 PRD 评审也是一样。 简单版本是问：“你能评审一下这份 PRD 吗？”更好的版本，是一个知道你团队质量标准的 PRD 评审产物。循环版本会测试这个产物是不是真的给出了更好的反馈。 它有没有抓到模糊问题？有没有推动补充真实证据？有没有指出缺失的指标？有没有避免没用的挑刺？有没有保留产品意图？ 当答案出现偏差时，你应该修正产物，而不是提示词。 提示词能帮你完成一次任务，而循环工程则能改进塑造每次任务完成方式的产物。 你的第一个循环：每周产品信号 每周产品信号循环 我不会建议你一开始就做一个试图决定产品战略的循环。 那太宽泛、太主观，也太容易出错。我会从产品运营开始。重复性工作在那里，证据也在那里，一致性也最重要。 一个良好的初始循环是每周产品信号循环。 每周五，这个循环读取客户访谈、支持工单、销售记录、实验更新、数据分析摘要、已发布的变更和未解决的升级问题。它会产出一份产品信号备忘录。 这份备忘录不应该是泛泛的整理。它应该把重复出现的信号和孤立噪音分开。 它应该包含客户原话。它应该展示和上周相比发生了什么变化。它应指出证据不足的地方。它应确定哪些路线图假设得到了加强、削弱或保持不变。 你来评审它。如果备忘录遗漏了重要内容，你就更新该文档。如果分析人员对薄弱证据的权重过高，你就收紧评估标准。如果出现了新的产品问题，你就将其添加到下周的审查范围中。 几周后，这个循环就会变得有用。 几个月后，它就会成为你在进行任何路线图会议之前都会查看的内容。 品味仍然重要，只是现在需要证据 产品经理一直依赖品味。 好的产品经理读一份 PRD，就能感觉到问题描述什么时候太模糊。他们能判断出客户的引用是否被过度延伸。他们能感觉到一个发布计划是否在假装某个并不真实的依赖关系。 这种判断仍然重要。循环工程不会移除它。恰恰相反，它把判断力放在中心位置。 但当你将自身判断固化为可复用工具时，主观评判标准就需要客观依据支撑。 如果你修改了产品需求文档评审工具，要如何确认优化确实有效？如果你迭代了调研摘要生成工具，要怎样判断它提取到了更多有效信息而非冗余干扰内容？如果你完善了上线核对清单，又该如何证明它提升了上线就绪度，而非徒增繁琐流程？ 评估体系正是产品经理需要着手搭建的核心工作。 产品经理搭建的评估体系无需是庞大的基准测试集，完全可以从已知典型案例起步。 选取三份优质产品需求文档与三份劣质产品需求文档，用你的产品需求文档评审工具对其进行核验。该工具能否找出真实的设计漏洞？是否只会纠结无关紧要的细枝末节？能否完整保留产品核心设计意图？ 选取五段你已吃透的客户通话录音，使用你的调研内容总结工具进行处理。该工具能否提炼出客户真实痛点？引用内容是否准确无误？能否区分高价值有效信息与偶然出现的无效杂音？ 选取两次过往产品上线案例：一次流程顺畅，一次漏洞百出。套用你的上线就绪校验流程进行复盘。这套流程当初能否排查出最终引发故障的核心问题？ 这就是循环工程。你关注的重点不该是“这个智能工具的输出听起来是否专业”，而是“这套标准化工具相比过往成熟的产品判断标准，是否真正实现了优化提升”。 循环需要记忆层 一旦你开始评估产出物，就需要一个地方来留存这些学习成果。否则，这些工作就会消失。 你在聊天中修改提示词，在文件中粘贴新指令，调整评分标准，添加示例，移除限制条件。输出结果改变了，但历史记录却没了。 几周后，没人知道Agent为什么会有那样的行为。 这就是 GitHub 发挥作用的地方。不是因为产品经理需要成为工程师，而是因为产品经理需要那些日益影响其工作的工件的版本历史记录。 产出物存放在那里，变更存放在那里，评估结果存放在那里，决策日志存放在那里，回滚路径也存放在那里。 如果产出物有所改进，你需要提交记录；如果它变差了，你需要差异对比；如果评分标准改变了，你需要知道原因；如果启动检查清单发现了真正的阻碍因素，你需要将这些经验保存下来，供下次启动时参考。 仓库就成了产品的记忆库。 产品记忆层 任意循环的骨架 你不需要把事情做复杂。 选一个重复出现的产品任务。写下它什么时候开始、使用哪些输入、由哪个产物指导、智能体应该做什么、好的输出长什么样、学习结果保存到哪里，以及循环应该什么时候停止。 这就足够开始了。 关键是让循环足够小，小到你真的能判断它是否在变好。每一个优秀的产品经理循环都应该明确人类仍然掌控的部分。 循环可以整理客户证据，但不应该单独决定战略。循环可以评审 PRD，但不应该变成产品负责人。循环可以标记高风险发布，但不应该在缺乏上下文的情况下做取舍。 构建循环，但继续做产品经理。 它会在哪里失效 循环通常以很简单的方式失败。 触发器太模糊。输入太乱。产物太长。证据太主观。学习结果没有地方保存。停止条件太弱。 或者，你太早给了循环过多权限。 最后这一点是陷阱。不要一开始就做一个无需评审就能改变战略、给客户发消息、更新路线图，或做出产品承诺的循环。 从那些为你仍然会亲自做的决定提供信息的循环开始。让它们先赢得信任。然后慢慢提高自主度。 这可能是产品工作中和智能体协作最健康的方式。 工作会变成什么 过去，产品经理的工作是翻译。把客户痛点翻译成需求。把业务目标翻译成路线图。把工程约束翻译成取舍。 这份工作仍然存在。但它上面多了一层新东西。 你现在设计的系统要让产品判断具有可重复性。你创建产物，对其进行版本管理、评估，并留意它们何时出现偏差。智能体执行任务。而你要确保执行任务的事物持续改进。 最优秀的产品经理不会是那些拥有最长提示库的人。他们会是那些知道产品工作的哪些部分应形成持久循环、哪些产出物应指导这些循环，以及哪些决策应保留人为因素的人。 这就是产品经理工作的未来。 不是更好的提示词。而是可复用、可版本管理、可评估的产物，运行在每次执行都会变得更锐利的循环里。 实践中是什么样 以客户研究为例。 简单版本是问智能体：“整理这些访谈。”这一次很有用，但它不会让你下次整理访谈时变得更好。 更好的版本，是一个客户访谈整理器。它知道你的团队关心什么：痛点、当前替代方案、紧迫性、反对意见、产品缺口、原话引用，以及后续跟进。 循环版本每周运行一次。它使用这个整理器，把新访谈和过去主题进行对比，标出哪些是重复出现的、哪些是新的，以及哪些地方证据还很薄。你评审输出。如果这份整理漏掉了细微差别，你就改进这个产物。下一次运行会更好。 PRD 评审也是一样。 简单版本是问：“你能评审一下这份 PRD 吗？”更好的版本，是一个知道你团队质量标准的 PRD 评审产物。循环版本会测试这个产物是不是真的给出了更好的反馈。 它有没有抓到模糊问题？有没有推动补充真实证据？有没有指出缺失的指标？有没有避免没用的挑刺？有没有保留产品意图？ 当答案出现偏差时，你应该修正产物，而不是提示词。 提示词能帮你完成一次任务，而循环工程则能改进塑造每次任务完成方式的产物。 你的第一个循环：每周产品信号 我不会建议你一开始就做一个试图决定产品战略的循环。 那太宽泛、太主观，也太容易出错。我会从产品运营开始。重复性工作在那里，证据也在那里，一致性也最重要。 一个良好的初始循环是每周产品信号循环。 每周五，这个循环读取客户访谈、支持工单、销售记录、实验更新、数据分析摘要、已发布的变更和未解决的升级问题。它会产出一份产品信号备忘录。 这份备忘录不应该是泛泛的整理。它应该把重复出现的信号和孤立噪音分开。 它应该包含客户原话。它应该展示和上周相比发生了什么变化。它应指出证据不足的地方。它应确定哪些路线图假设得到了加强、削弱或保持不变。 你来评审它。如果备忘录遗漏了重要内容，你就更新该文档。如果分析人员对薄弱证据的权重过高，你就收紧评估标准。如果出现了新的产品问题，你就将其添加到下周的审查范围中。 几周后，这个循环就会变得有用。 几个月后，它就会成为你在进行任何路线图会议之前都会查看的内容。 品味仍然重要，只是现在需要证据 产品经理一直依赖品味。 好的产品经理读一份 PRD，就能感觉到问题描述什么时候太模糊。他们能判断出客户的引用是否被过度延伸。他们能感觉到一个发布计划是否在假装某个并不真实的依赖关系。 这种判断仍然重要。循环工程不会移除它。恰恰相反，它把判断力放在中心位置。 但当你将自身判断固化为可复用工具时，主观评判标准就需要客观依据支撑。 如果你修改了产品需求文档评审工具，要如何确认优化确实有效？如果你迭代了调研摘要生成工具，要怎样判断它提取到了更多有效信息而非冗余干扰内容？如果你完善了上线核对清单，又该如何证明它提升了上线就绪度，而非徒增繁琐流程？ 评估体系正是产品经理需要着手搭建的核心工作。 产品经理搭建的评估体系无需是庞大的基准测试集，完全可以从已知典型案例起步。 选取三份优质产品需求文档与三份劣质产品需求文档，用你的产品需求文档评审工具对其进行核验。该工具能否找出真实的设计漏洞？是否只会纠结无关紧要的细枝末节？能否完整保留产品核心设计意图？ 选取五段你已吃透的客户通话录音，使用你的调研内容总结工具进行处理。该工具能否提炼出客户真实痛点？引用内容是否准确无误？能否区分高价值有效信息与偶然出现的无效杂音？ 选取两次过往产品上线案例：一次流程顺畅，一次漏洞百出。套用你的上线就绪校验流程进行复盘。这套流程当初能否排查出最终引发故障的核心问题？ 这就是循环工程。你关注的重点不该是“这个智能工具的输出听起来是否专业”，而是“这套标准化工具相比过往成熟的产品判断标准，是否真正实现了优化提升”。 循环需要记忆层 一旦你开始评估产出物，就需要一个地方来留存这些学习成果。否则，这些工作就会消失。 你在聊天中修改提示词，在文件中粘贴新指令，调整评分标准，添加示例，移除限制条件。输出结果改变了，但历史记录却没了。 几周后，没人知道Agent为什么会有那样的行为。 这就是 GitHub 发挥作用的地方。不是因为产品经理需要成为工程师，而是因为产品经理需要那些日益影响其工作的工件的版本历史记录。 产出物存放在那里，变更存放在那里，评估结果存放在那里，决策日志存放在那里，回滚路径也存放在那里。 如果产出物有所改进，你需要提交记录；如果它变差了，你需要差异对比；如果评分标准改变了，你需要知道原因；如果启动检查清单发现了真正的阻碍因素，你需要将这些经验保存下来，供下次启动时参考。 仓库就成了产品的记忆库。 任意循环的骨架 你不需要把事情做复杂。 选一个重复出现的产品任务。写下它什么时候开始、使用哪些输入、由哪个产物指导、智能体应该做什么、好的输出长什么样、学习结果保存到哪里，以及循环应该什么时候停止。 这就足够开始了。 关键是让循环足够小，小到你真的能判断它是否在变好。每一个优秀的产品经理循环都应该明确人类仍然掌控的部分。 循环可以整理客户证据，但不应该单独决定战略。循环可以评审 PRD，但不应该变成产品负责人。循环可以标记高风险发布，但不应该在缺乏上下文的情况下做取舍。 构建循环，但继续做产品经理。 它会在哪里失效 循环通常以很简单的方式失败。 触发器太模糊。输入太乱。产物太长。证据太主观。学习结果没有地方保存。停止条件太弱。 或者，你太早给了循环过多权限。 最后这一点是陷阱。不要一开始就做一个无需评审就能改变战略、给客户发消息、更新路线图，或做出产品承诺的循环。 从那些为你仍然会亲自做的决定提供信息的循环开始。让它们先赢得信任。然后慢慢提高自主度。 这可能是产品工作中和智能体协作最健康的方式。 工作会变成什么 过去，产品经理的工作是翻译。把客户痛点翻译成需求。把业务目标翻译成路线图。把工程约束翻译成取舍。 这份工作仍然存在。但它上面多了一层新东西。 你现在设计的系统要让产品判断具有可重复性。你创建产物，对其进行版本管理、评估，并留意它们何时出现偏差。智能体执行任务。而你要确保执行任务的事物持续改进。 最优秀的产品经理不会是那些拥有最长提示库的人。他们会是那些知道产品工作的哪些部分应形成持久循环、哪些产出物应指导这些循环，以及哪些决策应保留人为因素的人。 这就是产品经理工作的未来。 不是更好的提示词。而是可复用、可版本管理、可评估的产物，运行在每次执行都会变得更锐利的循环里。 原帖链接：https://x.com/Saboo Shubham /status/2068730090457006588 原帖链接：https://x.com/Saboo Shubham /status/2068730090457006588 产品经理接下来要掌握的能力，不是提示词工程，而是循环工程（Loop Engineering）。 过去两年，大多数产品经理都在努力把提示词写得更好。更好的指令、更好的上下文、更好的例子，以及更好的方式去告诉 Claude、Codex、Cursor，或他们使用的任何智能体要做什么。 但最终状态，不是产品经理每次需要什么都写出完美提示词。最终状态，是产品经理设计出一个每次运行都会变好的系统。 循环是你的 AI 系统反复运行的一套流程。你改动某个会影响智能体行为的东西，运行智能体，评估输出。如果质量提升，就保留这个改动；如果质量下降，就回滚。然后把这次学习提交下来，让下一版从比上一版更高的位置开始。 对工程师来说，这个循环从代码开始。 对产品经理来说，它从那些塑造产品工作的产物开始：PRD 评审技能、客户访谈整理器、评测标准、发布检查清单、研究工作流、CLAUDE.md 指令、提示词模板，或者优先级框架。 这些东西是持久的。它们会被反复使用。它们体现了你的判断力。它们影响智能体在几十次运行中的行为，而不只是某一次。 正因能够重复使用，其影响会双向累积。一套优质标准每周都能让你的工作更高效精准；而一套存在缺陷的标准会潜移默化地拖慢工作效率，直到你察觉到产出结果不对劲，却又说不清问题根源。 这也是必须配套迭代循环机制的原因。单次提示词即便出错，影响也有限；但一套十个人都依赖的评判标准，绝不能出现疏漏。 提示词解决不了的问题 第一波变化很明显。智能体让构建变得更容易。 你描述一个仪表盘，就能得到一个原型。你写下一个粗略想法，就能得到可运行的代码。你交给它十份客户访谈记录，几分钟后就能得到结构化整理。 这改变了产品经理的工作流。你不再只是写规格说明、交给工程团队、等待、评审，然后重复。现在你可以直接塑造第一个版本。 但一旦你以这种方式工作一段时间，就会遇到另一个问题。 你的 AI 工作空间开始偏离正轨。 你的 CLAUDE.md 越写越长。你的 PRD 评审技能越来越严格。你的研究工作流从过去的项目里吸收了一些指令。你的发布检查清单不断膨胀，直到智能体开始忽略其中一半的内容。你的评测标准变了，但你忘了是什么时候变的，也忘了为什么。 一个月后，智能体的表现变差了。它写出的 PRD 质量下降。它给出的研究总结千篇一律。它错过了过去能捕捉到的产品细节。 模型本身可能并没有变差。是你的产物偏离了正轨，而且没有人关注它们。 这就是循环工程为产品经理解决的真正问题。不是让某一个提示词更好，而是确保那些塑造产品工作的产物在不断改进，而不是慢慢衰退。 一个循环到底由什么组成 一个有用的循环有五个部分：触发器、动作、证据、记忆和停止条件。 触发器说明循环什么时候开始。动作说明智能体应该做什么。证据说明你怎么知道输出变好了。记忆说明学习结果保存到哪里。停止条件说明循环什么时候结束。 最后一部分在递归循环里最重要。 很多 AI 系统失败，并不是因为模型差，而是因为循环没有清晰出口。智能体会一直生成，不断扩大范围，不断发明新工作。或者在证据不足的情况下，给你一个很自信的整理结果。 一个良好的PM循环应该能够表达：没有有意义的变化、输入信息太少、此任务受阻、未达到质量标准，或者这需要人工决策。 一个能说“停止”的循环，才是你可以放心让它运行的循环。不能说停止的循环，就需要你一直盯着。 如果你想看看现实中的这类循环，Matthew Berman 的 Loop Library 收集了工程、研究和运营里的真实案例。它们是为工程师构建的，但这五个组成部分对产品工作同样适用。 Loop Library