← Playbook 索引
Playbook阶段 17可泛化原则
用户反馈与需求闭环（Feedback & Requirement Loop）
学习
把现场反馈从聊天和工单，变成可以去重、分流、排序、验证和关闭的队列。每条反馈最终只能有一个主去向：修复、产品决定、Eval、代码护栏、文档更新或明确不做。
什么时候拿出来用
- 试点或生产持续收到缺陷、需求、口径疑问和体验反馈
- 同类问题反复出现，但团队无法判断是逐条修还是升级为产品或架构决定
开始前先拿到
- 统一的反馈入口和最小记录字段
- 可查询的缺陷与需求队列
- 产品、工程和业务口径的升级责任人
操作主线
怎么推进
公开的是判断与动作骨架。客户数据、私有模板和内部示例不在其中。
- 01
接入、去重、分类
先关联已有问题，再区分 bug、需求、问题、数据缺口、抱怨或正向信号。
- 02
按影响排优先级
结合影响面、严重度和频次决定顺序，高危误导、泄露或核心阻断优先。
- 03
选择唯一主去向
缺陷进根因修复；范围和口径进入产品决策；硬规则优先进入代码与测试。
- 04
验证后再关闭
修复必须生成回归资产，产品决定要有记录，重复或不做也要留下理由。
会留下什么
- 结构化反馈队列
- 优先级与唯一归宿
- 由反馈生成的 Case、护栏或决策记录
过关前再看一遍
- 每条反馈都有类型、优先级和负责人
- 被修问题已经进入回归资产
- 关闭项能从队列追到验证或决策证据
Exit Gate · 放行条件
反馈被结构化分类入队
容易做错的地方
- 工单修完即结，不补回归
- 没有 Probe 就把我方缺陷说成数据缺口
- 可以代码强制的规则只写进文档
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。