面向产品经理的循环工程（Loop Engineering）
输入“/”快速插入内容
面向产品经理的循环工程（Loop Engineering）
面向产品经理的循环工程（Loop Engineering）
用户4242用户42426月22日修改
面向产品经理的循环工程（Loop Engineering）
产品经理接下来要掌握的能力，不是提示词工程，而是循环工程（Loop Engineering）。
过去两年，大多数产品经理都在努力把提示词写得更好。更好的指令、更好的上下文、更好的例子，以及更好的方式去告诉 Claude、Codex、Cursor，或他们使用的任何智能体要做什么。
但最终状态，不是产品经理每次需要什么都写出完美提示词。最终状态，是产品经理设计出一个每次运行都会变好的系统。
循环是你的 AI 系统反复运行的一套流程。你改动某个会影响智能体行为的东西，运行智能体，评估输出。如果质量提升，就保留这个改动；如果质量下降，就回滚。然后把这次学习提交下来，让下一版从比上一版更高的位置开始。
对工程师来说，这个循环从代码开始。
对产品经理来说，它从那些塑造产品工作的产物开始：PRD 评审技能、客户访谈整理器、评测标准、发布检查清单、研究工作流、CLAUDE.md 指令、提示词模板，或者优先级框架。
这些东西是持久的。它们会被反复使用。它们体现了你的判断力。它们影响智能体在几十次运行中的行为，而不只是某一次。
正因能够重复使用，其影响会双向累积。一套优质标准每周都能让你的工作更高效精准；而一套存在缺陷的标准会潜移默化地拖慢工作效率，直到你察觉到产出结果不对劲，却又说不清问题根源。
这也是必须配套迭代循环机制的原因。单次提示词即便出错，影响也有限；但一套十个人都依赖的评判标准，绝不能出现疏漏。
Loop Engineering
提示词解决不了的问题
第一波变化很明显。智能体让构建变得更容易。
你描述一个仪表盘，就能得到一个原型。你写下一个粗略想法，就能得到可运行的代码。你交给它十份客户访谈记录，几分钟后就能得到结构化整理。
这改变了产品经理的工作流。你不再只是写规格说明、交给工程团队、等待、评审，然后重复。现在你可以直接塑造第一个版本。
但一旦你以这种方式工作一段时间，就会遇到另一个问题。
你的 AI 工作空间开始偏离正轨。
你的 CLAUDE.md 越写越长。你的 PRD 评审技能越来越严格。你的研究工作流从过去的项目里吸收了一些指令。你的发布检查清单不断膨胀，直到智能体开始忽略其中一半的内容。你的评测标准变了，但你忘了是什么时候变的，也忘了为什么。
一个月后，智能体的表现变差了。它写出的 PRD 质量下降。它给出的研究总结千篇一律。它错过了过去能捕捉到的产品细节。
模型本身可能并没有变差。是你的产物偏离了正轨，而且没有人关注它们。
这就是循环工程为产品经理解决的真正问题。不是让某一个提示词更好，而是确保那些塑造产品工作的产物在不断改进，而不是慢慢衰退。
一个循环到底由什么组成
一个有用的循环有五个部分：触发器、动作、证据、记忆和停止条件。
触发器说明循环什么时候开始。动作说明智能体应该做什么。证据说明你怎么知道输出变好了。记忆说明学习结果保存到哪里。停止条件说明循环什么时候结束。