反馈：先定位错误，再改变系统

用户点了“不满意”，不能直接推出模型需要微调。答复可能用了旧资料、查询了错误客户、工具提交失败、交互让用户误解，甚至评测规则把正确行为判错。反馈的价值在于把一个现象变成可验证的改变。

试点观察怎样变成一次改版

接续第16章O04的审阅观察，以下F04是原创合成工作记录；r2与新样本尚未实现或执行。

新样本的来源、预期和停止条件先写好：N01白色杯身/红色杯盖，应分别保留；N02透明杯体、无杯盖，不编造杯盖颜色；N03同级资料对杯盖写红/蓝，应保留冲突；N04来源缺失颜色对象，应定向追问。材料均由我们合成，不代表真实分布。业务人员需独立读材料给出判据；当前表是参考预期，尚未经专家确认。任何擅选冲突、跨对象归色或未授权写入均停止r2扩大；通过这四例也仅支持这些条件下的检查，仍需真实资料与工作观察。若改动有效，再检查完整链、原正常任务、unknown恢复及版本确认，不只测颜色。

一次有效反馈应关联输入、输出、实际结果与版本。上表的原因仍是排查假设；反馈者不必懂系统分层，产品团队负责把现象变成可查问题。按下表继续选择修复位置。

区分行为错误和量尺错误

Nubank地址Judge最初将“问过地址及配送补充信息”作为通过条件。但客户仅查物流或明确沿用原地址时，并不需要重新收集。专家标签和理由揭示了业务分支缺失，团队改变的是评分规则；若只追求旧规则得分，客服可能学会多问无用的问题。论文公开规则还允许“AI已完整请求字段”这一通过路径，即使客户没有回答。因此该分数评价收集行为，不能替代动作接口的地址完整性验证。

这要求保留两条循环。量尺循环比较专家判断与Judge，修正适用条件、角色范围及评分依据；产品循环利用可靠量尺和真实结果，改例程、工具、上下文或模型。两个循环可以由同一团队做，但不能把Judge优化当成客服已自动改进。

选择改动范围

局部提示词修订适合规则清楚、证据齐备且错误集中于解释的情形。增加规则适合稳定边界，例如必须先取得客户事实。改工具适合固定依赖或副作用处理无法稳定完成。改变产品流程适合用户输入不足、复核负担转移或目标任务根本不成立。训练或微调需要重复可学的行为、合法数据和独立评测；它不能修复失效知识或接口权限。

Nubank切换模型时遇到原来隐含的“先查客户数据”行为不再稳定，公开材料描述在Instructions中明确该原则。这说明一次失败不必触发全系统重写，但模型迁移会改变整体解释方式，局部修订不能免去完整回归。

每次只改变一个主要假设，或明确记录组合改变。先用旧失败、邻近反例和正常任务对照，再小流量观察。若同时改检索、模型和界面后得分提高，只能说组合改善，难以知道哪项值得保留。线上新增问题应经过脱敏、领域判断和样本去重后进入回归集；不把任何用户投诉立即写进提示词，也不让全部生产反馈直接成为训练集。

用不同任务检查改动是否选对

一次用户选择，可以改变搜索，也可以改变记忆

招聘者联系一名候选人，是有意义的正向行为，但不等于此人满足全部硬条件。LinkedIn应用工程同时使用产品政策、标注资料与招聘行为；寻源策略负责看见谁，逐条件评估负责说明证据，结果再帮助调整下一轮搜索。反馈先要回答“哪一步出了问题”，否则系统可能学会更频繁推荐受欢迎但不合格的人。应用工程

合成任务中，招聘者连续拒绝五位候选人并写“缺少制造业客户经验”。有三种不同修订：当前岗位漏写了必备条件，先改确认后的要求；条件已写但资料无法证明，改证据收集或评估；条件和证据都正确却搜索仍找错人，改寻源策略。先用下一批候选比较可核对的条件覆盖和误判，再看招聘者是否采取行动，不能用点击率选赢家。

跨项目反复出现的偏好才考虑进入长期记忆。CMA工程区分原始对话、事件、语义偏好和程序经验；HLTM v3则让历史查询模式反馈到分面、问答及摘要摄取，保留得到多个查询支持的模式，敏感场景可加入人工审阅。它改变的是以后怎样构造记忆，不是把每次点击直接写成岗位规则。CMA、HLTM §3.6–3.7

迁移时可维护一条原创变更记录：项目P7：制造业经验改为必备，只作用于当前项目；候选长期偏好：重视行业经验，附多项目支持与反例，由业务人员确认适用范围。删除项目证据后，派生偏好也应重算。先验证当前任务修订，再验证旧项目、其它岗位和无偏好任务，防止跨项目概括污染业务条件。长期偏好的支持数量和衰减规则应由本业务验证，不直接套用统一门槛。

质量、采用与价值需要不同改进动作

GTM案例簇把Snowflake的发布与激活、Notion的行动任务、ZS的交接反例、DoorDash的跨职能评测放在不同位置。它们提供互补观察，不能拼成一家公司的统一内部系统。Snowflake公开经验区分试点质量、日常使用价值与规模激活；DoorDash强调业务定义标准、产品写判据、运营标注、工程支撑追踪与评测。Snowflake规模化经验、DoorDash评测实践

以下GTM例子为合成分析：助手推荐客户扩容，事实是使用量上升，但人工复核发现增长来自短期迁移，下一步应排查临时容量而非销售外联。事实抽取可以正确，行动仍错误。修订要增加原因—动作关系与反证检查，不是再训练事实提取器。若建议正确却无人打开，先查入口、工作节奏和责任；若员工每天使用却返工更久，先查审核负担与成果是否进入原系统。三条曲线应分别汇报：

不要把点击和投诉直接变成金标。运营先去重与抽样，领域人员核对真正错误及反例，形成可以回到版本的样例，再校准Judge；稀有高损失问题应单独保留，不被高频小问题淹没。组织方式可以很轻，只需明确谁能解释业务错误、谁能修实现、谁能确认下一版。

图文报告反馈应回到数据与可执行产物

FinSight研究把绘图代码执行后的图交给视觉模型批评，再迭代代码；短分析片段、图表标识与引用随后用于长报告及后处理。它提示反馈不只改写文字：缺标签可能要修绘图，图文单位冲突要回查数据和转换，图表ID解析失败要修产物装配。FinSight v1 §2.4–2.5

例如合成报告将2025年的“120万元”画成120元，视觉上清晰的图仍然错误。先核对原数据和单位转换，再重画、检查正文数值与最终导出文件；不能让视觉Judge反复改善美观而放过数值。论文以模型结合参考研报比较事实、分析与呈现；其得分不是独立财务审计，也不证明客户使用价值。团队可用独立数据检查、图表渲染检查、领域复核分别约束循环，并限制迭代预算；达到上限仍不合格时交人工，不继续无界“自我优化”。

反馈闭环的完成证据

完成不是“已回复用户”或“Prompt已改”。它是：已定位或收窄原因，修订有版本，旧问题可复测，邻近行为没有明显损害，并在适当运行范围观察结果。无法重现时保留输入条件与现象，增加诊断，不用猜测填满原因。

BBVA的部门复用例子提醒我们，领域规则owner和复核责任不能随助手共享而消失；重复使用废止内容时要修知识包并检查受影响范围，而非只提醒每个用户。下一步用复盘模板做一次具体改动，随后在经济与价值检查它是否只把成本转给另一岗位。

参考资料

• Nubank v2 §5.2、附录A、§6.3.2：Judge修订与模型迁移。
• LinkedIn应用工程、CMA工程、HLTM v3 §3.6–3.7：搜索反馈与记忆摄取，三项材料各自提供机制证据。
• Snowflake规模化经验、DoorDash评测实践：质量、采用与跨职能标准；BBVA部门采用：复用维护责任。
• FinSight v1 §2.3–2.5、附录E：代码、图文产物与模型评价，不能替代独立财务审计。
• 反馈记录、招聘/GTM修订和单位错误为合成教学例；未执行记忆摄取、模型训练或报告生成。

继续使用

上一章：持续运行 · 下一章：经济、性能与价值 · 五篇阅读目录。相关工具：问题定位和改版回归。

案例延伸：Nubank客服：比较修评分器与修客服行为的两条反馈循环。