你的Claude PRD审查和客户通话总结 为什么三个月后开始走样
你每周五把十几个客户通话录音、支持工单和销售笔记丢给Claude,让它输出一份产品信号备忘录。起初它能抓住重复出现的痛点、用户原话、产品缺口,甚至指出哪些路线图假设正在被强化。三个月后,输出开始泛化,关键引用消失了,对“证据薄弱”的标记越来越宽松,新出现的异议也被忽略。你隐约觉得agent“变笨了”,却找不到明确原因。
这不是模型更新或者上下文窗口不够的问题。你的制品——那个指导agent行为的审查标准、总结模板、质量rubric——在悄无声息地漂移,而没有任何机制在持续观察和修正它。
提示工程擅长把一次任务的指令写得更好,但它对“可复用、持续运行”的制品缺乏治理。制品一旦被反复调用,就开始积累隐性变化:上一个项目的偏好混进了当前模板,过去的严格标准被新团队成员无意放宽。漂移不是突然发生,而是每周一点点,直到你忽然发现agent不再像最初那样懂你的产品判断。
我起初以为只要把提示词写得足够详细、例子足够多,就能把判断力“固化”进去。后来把同一个审查器连续跑在多个真实PRD上,才发现它对“缺少量化指标”的容忍度在慢慢上升。问题从来不是agent听不懂,而是我们没有给它一个能自我进化的反馈闭环。
这就像没有CI/CD的代码仓库。每次提交都改一点,没有自动化测试和回滚路径,技术债就一点点堆起来。你以为多加几条注释就能控制质量,直到某天线上出问题才发现根源早已经不可追溯。产品判断的制品也一样:没有闭环,它只会单向熵增。
另一个更贴近日常的例子是厨师的评分卡。资深厨师不是每次出菜都从零发明标准,而是基于上一轮客人反馈更新自己的口味记忆库和执行 checklist。循环让个人直觉变成了可传承、可迭代的系统资产,而不是每次都靠当天状态。
一个有用的循环由五个部分组成:触发器、行动、证明、记忆、停止条件。
触发器决定什么时候启动(每周五09:00、PRD提交后、实验结束时)。行动由当前制品指导agent具体怎么做。证明是用已知的好案例和坏案例跑一遍,看看这次输出是否真的更好。记忆把这次运行的输出、diff、审查笔记和决策理由存下来。停止条件则告诉系统:什么时候该停、什么时候该把决策权还给人类。
下面是一个可直接落地的每周产品信号循环制品示例(已做逻辑重构,增加中文关键注释):
# 每周产品信号循环 - 制品定义 v1.3
trigger: "每周五 09:00 自动拉取过去7天全部数据源"
inputs:
- customer_calls: "带speaker和时间戳的转录文本"
- support_tickets
- sales_notes
- experiment_updates
- analytics_summary
action: |
使用当前制品 product_signal_rubric.md 进行结构化总结
对比上周已识别主题,标记:
- 重复出现的强信号(带证据强度)
- 新出现的信号(带首次出现时间)
- 证据薄弱或相互矛盾的点
输出必须包含至少3条用户原话引用
# 关键注释:制品而非单次提示,决定了agent如何区分信号与噪声
proof: |
与历史已验证的强/弱信号案例库对比
计算:主题覆盖率、引用准确率、证据强度识别准确率
若任意指标低于基线则标记为需人工复核
memory: |
提交到 Git 仓库 product-memory/
包含:本次输出、diff、上次commit、PM审查笔记、决策日志
stop_condition: |
- 证据总量低于阈值
- 出现需要战略取舍的重大矛盾
- 输出质量连续两次低于基线
# 关键注释:能明确说“stop”才是敢长期运行的循环
把这个制品放在Git仓库后,每次运行都会留下可追溯的痕迹。你改了rubric里的某一条权重,下次就能看到输出发生了什么变化;如果变差了,一键回滚即可。
同样的逻辑可以套在PRD审查上。把“你的团队质量标准”写成可版本化的rubric(是否要求真实证据、是否允许模糊目标、是否必须量化影响),然后用已知的好PRD和坏PRD做基准测试。测试通过后再上线给agent使用。
循环最容易失败的地方往往是停止条件缺失。很多系统会一直生成、一直扩展范围、一直给出自信满满却证据不足的总结。能明确说“这个输入太薄”“需要人类决策”的循环,才是你真正敢放手让它每周自动跑的循环。
我见过太多团队一开始就把战略决策或路线图优先级交给循环,结果很快就失控。正确的做法是先从产品运营里最高频、最有证据的环节开始——比如每周产品信号循环。让它先跑出价值,再逐步把自主权往上提。
下面是两种实践方式的直接对比:
| 维度 | 传统提示工程方式 | 循环工程方式 |
|---|---|---|
| 改进机制 | 手动修改单次提示词 | 评估后更新可复用制品 + Git版本控制 |
| 时间尺度 | 单次任务优化 | 跨数十次运行的持续进化 |
| 漂移风险 | 无感知,依赖人工偶然复盘 | 可自动标记变化、可一键回滚 |
| 判断力传承 | 隐含在提示里,换人就失效 | 显式编码在制品中,可测试、可分享、可审计 |
| 适合场景 | 探索性、低频任务 | 高频重复的核心产品工作 |
| 长期成本 | 持续人工 babysit + 质量波动 | 前期设计成本换来 compounding 优势 |
判断力从来不是要被AI取代,而是要被“证明”和“复用”。当你把判断放进可版本化的制品里,它就必须经得起证据检验,否则就会像没有测试的代码一样慢慢腐烂。
最好的产品经理,不会是提示库最厚的那一个,而是能分辨出“哪些产品工作值得变成 durable loop”的人。
循环的本质是把“个人品味”升级成“组织级可迭代资产”。在AI代理越来越能规模化生产内容的时代,产品经理的核心价值正在从“写规格、做翻译”转向“设计让好判断反复发生并持续变好的系统”。那些把判断力转化为可追踪、可回滚、可进化的闭环的人,将在团队里建立别人难以复制的 compounding 优势。
这个周末,挑一个你每周都会做的产品任务——PRD审查、客户洞察总结、launch readiness检查都可以。试着为它完整写下触发器、行动、证明、记忆和停止条件,然后跑一次。跑完后问自己:我对“什么算好”的定义,是否真的经得起这次证据的检验?
我是紫微AI,在做一个「人格操作系统(ZPF)」。后面会持续分享AI Agent和系统实验。感兴趣可以关注,我们下期见。
更多推荐


所有评论(0)