群里有人说，能不能在 AI 写完代码以后，继续监控人类审核代码的注意力轨迹，从而训练出“审美 AI”。我看到这句话，第一反应不是遥远，而是熟悉。因为我前两天在做校招辅助工作时，其实已经干过一件非常像的事。
AI 先生成了二十个人的面试评语。我看完很不满意。不是太严肃，就是太儿戏。后来我没有继续往 prompt 里补一堆形容词，也没有试图一次性把自己的风格解释清楚。我只做了一件更笨、但更有效的事：先手工改四份，然后让 AI 自己去总结我改了什么、为什么这么改，再让它照着这个总结去改剩下十几份。
效果一下就对了。
很多时候，我们以为自己在“给 AI 补要求”，其实已经在做一件更接近偏好学习的事：先用修改动作表达偏好，再让系统去学偏好。
为什么我觉得这件事不是小技巧，而是一条大方向
RLHF 这几个字这些年被讲得很重，像是只有大厂研究团队才能玩。但如果把形式感拿掉，它最核心的那层其实很朴素：不是让人类先写出一套完美规则，而是让人类先表达“哪个更好”。
InstructGPT 那篇论文里，最关键的动作不是模型多大，而是他们收集了人类对多个输出的排序，再把这些排序变成后续训练信号。后来 DPO 又把门槛往下砍了一截，告诉大家偏好优化不一定非得显式训练 reward model，再走完整 RL 流程。
这件事对真实工作非常重要。因为人类通常不擅长提前讲清楚“什么叫恰到好处”，但很擅长在两个版本里挑一个更喜欢的，或者顺手把一句话改到顺眼。
换句话说，真正高价值的反馈，很多时候不是 thumbs up，不是五分制打分，而是编辑动作本身。
编辑动作为什么这么值钱
我现在越来越确信，很多 AI 产品最容易忽略的一种数据，恰恰是最值钱的数据：用户改了什么。
因为它天然同时带着三层信息。第一层是结果偏好。用户把一句话改掉，本身就在说“原版不如这个版本”。第二层是局部归因。用户不是整篇推翻，而是改了某几个词、某几句结构，这等于顺手告诉了你问题发生在哪。第三层是上下文。这个修改不是实验室里的标注，而是发生在真实工作流里，天然带着角色、场景和业务约束。
所以我越来越不相信那种只盯着显式反馈的产品设计。很多用户懒得点赞点踩，就算点了，你也不知道他到底不满意什么。相比之下，修改痕迹的信息密度高得多。它不像一句“写得不好”那么含糊，它已经把“不好”翻译成了具体改动。
Rubric 才是把 taste 变成系统资产的桥
回头看那次招聘评语，我觉得最关键的一步其实不是“改四份”，而是“让 AI 总结我到底改了什么”。因为这一步做的，本质上是把隐性的审美标准外化成一套 rubric。
比如：要具体，不要空泛夸赞；要有人味，但不要油；要指出优点和风险，但不要上价值上得太满；语气要像真 manager 写的，而不是像系统模板。这些东西如果永远只留在人脑里，它就只能靠资深者亲自盯。它不能规模化，也不能稳定复用。
但一旦你把它写出来，很多事都变简单了。你可以让模型按 rubric 自评，让多个候选版本互相比，让 reranker 按 rubric 排序，甚至以后再把这套 rubric 转成训练数据。rubric 的价值，不是让文风更规范，而是让 taste 开始变成外部对象，开始可积累。
不做完整后训练，也完全可以先跑起来
很多团队一听“偏好学习”，第一反应是：我们没有训练能力，也没有那么多标注资源。那是不是只能继续补 prompt？我觉得不是。
Self-Refine 已经证明，不做额外训练，只靠 test-time 的“生成 -> 反馈 -> 改写”循环，也能明显提升输出质量。它给了一个特别现实的启发：反馈不一定非得先进参数层，先进入运行时循环也能产生很大价值。
所以一个非常现实的“人工简化 RLHF”流水线，其实可以很朴素：
- 先抓少量高质量人工修改样本，不求多，先求密度高。
- 让 AI 总结原版和修改版差异，抽出 rubric。
- 后续每次先生成多个候选，再按 rubric 做挑优，而不是一把梭直接终稿。
- 边界样本、风格强样本、低置信度样本，再回给人拍板。
- 失败案例单独沉淀成回归集，让这套 taste 不断被校准。
注意，这整套东西里最值钱的，根本不是某个模型名词，而是那条持续运转的反馈链。它让“这个更像我”的主观感觉，开始变成一个可以被复用、被放大、被自动化的系统输入。
代码评审领域已经给了很强的现实信号
如果你觉得招聘评语还只是文字工作，那代码评审会给一个更硬的现实版证据。
Google 关于 code review comments 的工作 已经说明，reviewer 的自然语言评论本身，就可以驱动模型给出建议修改。这等于默认承认了一件事：评审反馈不是噪声，它本身就是可学习信号。
更进一步，像 CRScore 这类工作开始强调 code review 没有唯一标准答案，更适合用 conciseness、comprehensiveness、relevance 这类维度来评价评论质量。最新的 SWE-PRBench 甚至直接拿 human-flagged issues 去量化 AI review 质量，结果显示今天的 frontier models 仍然离人类 expert 很远。
我对这些工作的解读不是“AI 还不行”，而是另一层：团队的评审 taste 正在从经验沉淀，变成数据沉淀。以前 reviewer 的好坏，更多靠口碑和资历在传。现在，评论文本、最终修改动作、接受率、回滚率，开始都能变成结构化信号。
那注意力轨迹呢
我对“监控审核代码时的注意力轨迹”这件事的判断是：有价值，但更适合作为高成本辅信号，而不是主干监督。
像 关于 PR 情绪理解的眼动研究 已经说明，开发者在 PR 页面上的 gaze 分布是有稳定模式的。评论正文、新增代码、用户名会被看得更多，甚至 emoji 也会获得异常高的注意力。这说明 reviewer 的认知资源并不是随机投放的。
但我不会把这条路吹得太满。眼动数据贵、噪声大、解释难，而且“看得久”并不天然等于“这个地方重要”。所以它更像研究工具和产品优化信号，适合帮助理解 reviewer workflow，或者验证界面设计，而不太像最先该规模化落地的监督主轴。
真正更现实、更低成本、也更容易规模化的主监督，还是这些：reviewer comment 文本、评论后的最终修改动作、多个候选改法里人类最后选了哪一个、哪类问题总被人类盯出来、哪类问题总被 AI 漏掉。
我现在更相信的判断
下一批真正拉开差距的 agent，不是会说得更多的 agent，而是会从这些细小却高密度的人类反馈里，慢慢学会“什么叫更对”的 agent。
所以如果今天让我给 AI 产品提一个最实际的建议，我不会先问“你用了哪个模型”，我会先问：用户编辑后的痕迹你们记了吗？用户挑优的动作你们记了吗？你们有没有把这些动作沉淀成下一轮系统能力？
如果没有，那产品再智能，本质上也还只是一次性生成器。如果有了，它才开始从工具走向会学习的系统。