旧稿：
阅读用户反馈日志，分析推荐系统中存在的问题。
问题出在【分析】这两个字上。它不是一个动作，是个筐。筐不指定看哪儿、看多细、跟什么比，模型接住它，只能回你分析腔的句子：整体相关性有待提升、部分场景下体验不佳。你盯着这两行字，跟没看日志一样，区别只是多等了几秒。
几天前挂上 arXiv 的 AURA（2609.16625）干的是同一件事的另一头。我改一句话，它改一条产线的诊断流程。它的立论不新鲜但很硬：聚合指标看不出推荐在哪儿、以什么方式、对哪个用户失灵了。所以系统里几个专用 agent 直接去读会话日志，从几千个会话一路到几百万个，从里面捞出失效的模式和具体案例，而不是算个平均值交差。14 页、1 张图、6 张表，过几天要在明尼阿波利斯那个 RecSys 的电商 workshop 上讲。
我真正在意的不是它读了多大的日志，是"具体案例"这四个字。抽象结论没法验证——你说"相关性有待提升"，我打开日志也核对不出你对不对。具体到某一条会话、某一个轮次，我能打开那一行去看，错了就是错了。诊断类 prompt 唯一的实用判据就是这个：输出能不能被核验。
岔一句。"诊断"这词从词根上说是"穿过性地知道"。医生给你看病，不会说"你的健康度六十三分"，他说哪根血管、堵了几成。扯回来——prompt 里的诊断一个道理：模型不是不肯给你东西，是它不知道你要它切到多细。
上一稿里还有【请】和【仔细】。先删了。仔细不解决歧义，它只是表态，占着位置不干活。
V1 我加了个词：
阅读用户反馈日志，找出问题，并举例说明。
加"举例"两个字，以为能逼出具体。例子确实有了，十个里八个是编的——"一位家长想找儿童内容，却被推荐了恐怖片"。这类例子太好写，因为它躺在训练分布的中间，不在你的日志里。
V2 换成引用原文：
阅读用户反馈日志，找出问题，并引用日志原文作为例子。
编造堵住了。新毛病冒出来：模型开始逐条复述，几十条流水账，没有一条落到"哪一步断了"上。它把"具体"理解成了"逐字"。这版唯一的收获，是让我看清光喊"要具体"没用，得说清具体在哪个维度上。
V3 拆成两步：
第一步：定位到具体会话与轮次，指出推荐在哪一步偏离了用户意图。
第二步：每个偏离点，说明用户当时的意图、推荐给出的结果、两者的差距。
"哪一步"逼它切分，"意图 vs 给出"逼它对照。两个词一放，输出粒度立刻变了。
同一个位置的字重差别，在这儿看得最清楚：放【分析】，出来三百字综述；换成【定位】，出来三条带会话 ID 的指认。模型没变聪明，它只是终于知道该往哪个方向使劲。
再往外一层。刚才那两步的骨架跟领域无关，但"什么算偏离用户意图"，在流媒体和电商里完全是两回事。AURA 的做法是把领域特定的东西从主体里挪到配置层去注入，而且那套配置已经在两个平台之间迁过一遍。我自己读出来的东西是：prompt 里该留的是形状，不是内容。类目、分级、库存这些领域词写死在主体里，等于每换个场景就把骨架重写一遍；骨架固定住，领域词从外面喂进来就够了。这条我拿不准是不是作者的本来意思，但对我这种每天改一句话的人，它是这篇论文里最有用的一页。
定稿先放这：
读这段会话日志，只做两件事：
1) 指出推荐在哪一轮、以什么方式偏离了用户意图
2) 每处偏离附上日志原句作为依据
从最初那三十来字缩到两条，中间废了三版。我不敢说这是终版——"偏离"这个词我到现在也没拿准，有些情况是用户自己改的主意，不是推荐跑偏，模型分不出这条边界，会误判。先这么用着，哪天这种误判攒够数了，再回来换一版。