8 月 11 号挂到 arXiv 上的一篇论文，提了个叫 Principal Trait Analysis 的东西，缩写 PTA，讲的是怎么从人和 AI 的对话记录里自动提取“有效交互特质”。我知道这不是第一篇干这事的，但它把我想骂很久的一个念头顶到了嗓子眼：我们是不是已经急到，要把“人和 AI 怎么聊天”这件事本身，变成一套可以打分、排名、发 KPI 的新指标？
我把论文读了。方法部分不算差，但问题从来不在方法，在方向。
作者先把现存的那些“人类-AI 协作指南”归了类：要么自上而下拍脑袋拍出来，要么从具体场景里观察出来。因为 LLM 能力涨太快，这两种都可能过时。于是他们仿照 PCA，把对话记录当高维数据，让大模型去提炼共同特质，再给每个协作者按特质打分。发现过程里还能注入领域知识，最后选那些协作者之间方差最高的特质作为最有区分度的东西。实验做在两个数据集上，一个教育场景一个专业开发场景，结论是这些特质统计显著、能帮忙预测任务结果，但作者又补了一句：这些特质算不算“技能”，不知道；会不会随时间变，不知道。
让我不舒服的从来不是论文本身，是它出现的土壤。2026 年了，AI 编程工具早就从“会不会用”走到“怎么用得专业”这一步。这一步最大的焦虑不是工具不够聪明，是管理者手里没一个数字。代码质量、测试覆盖率、故障率，这些能衡量直接产出；“这个人跟 AI 协作的方式对不对”，没有数字。没有数字，管理就发慌。于是这类研究就有了市场：你给一个特质列表，我能量化、能比较、能排名——哪怕作者自己在论文里承认，这些特质是不是技能、是不是稳定，统统没搞清楚。
先拆一层方法。PTA 对 PCA 的类比听着像回事：PCA 是找一组正交方向，让投影方差最大化；PTA 是对话经过“大模型处理”以后，找一组“特质”，让不同协作者得分方差最大化。但 PCA 是在实数向量空间里做，方差有明确的几何意义，第一主成分就是数据散得最开的方向，方差大通常意味着里面藏着结构性差异，值得往下看。换成对话记录，再过一层 LLM 抽象，方差大还意味着“结构性差异”吗？不一定。它可能意味着样本里混了不同水平的协作者，可能意味着对话主题本身差异大，也可能只是噪声大。标注的人对“什么是好交互”有不同标准，也会贡献一大块方差。方差从来不是重要性的充分条件，它只是一个粗筛条件。在行为数据里，方差最大的维度经常是最无聊的维度：学生和职业开发者用的词汇不一样，那个维度方差大不大？大。有意义吗？有，但你根本不需要一套 PTA 来发现它。
最别扭的是“注入领域专业知识”这一步。这一步听着很克制、很工程，实际上它承认了一件事：你在“发现”之前，已经知道你想看见什么了。你不是让数据把底层结构吐出来，你是把手伸进工具箱里挑了把形状合适的尺子，然后宣布“看，数据里有这个刻度”。注入的领域知识是对的，就是拿算法验证一套你早就信的东西；注入的领域知识是错的，你就得到一套错误但漂亮的“特质”。哪种情况，这都更像投影，不像发现。
让我坐不住的是论文结尾那段话。作者很诚实，说这些特质能不能算技能，尚不确定，泛化性不明，随时间怎么变也没结论。这种科学态度没什么可挑的。但请你想一个场景：一个工程团队的负责人，或者一个教育产品经理，看到这篇论文以后最可能做什么？他不会等“这些特质是不是技能”有结论再动手。他会说：这方法统计显著、能预测任务结果，先跑一套，给每个人打个分再说。等“技能”的定义清楚了，工具都换了好几茬了。
这个流程一旦跑起来，最大的受益人是那些没能力判断代码质量、又必须向上交一张表的角色。他们会拿到一份“交互特质报告”，上面写着某个初级工程师“主动澄清需求”得分低、“适应性调整策略”得分低——天知道这些标签对应什么实际行为。然后这个工程师就被送去补“交互”，而不是去补代码阅读、补测试、补网络。这不就是我最恶心的那套东西吗：烂地基上刷漆。
还有个更阴险的地方。这类分析模型天然偏向那些“会说话”的人。对话记录里的礼貌程度、结构化程度、追问频率，很容易被 LLM 捕捉并放大成高方差特质。一个没学过网络的人，只要 prompt 写得有条理、知道在模型给错方向时“礼貌地重新表达需求”，很可能拿到不错的交互评分；一个技术很硬但不爱多打字的人，反而被标成“协作特质低”。用这套东西去预测“任务结果”，它预测出来的到底是什么？是真本事，还是表演真本事的能力？
我不是说 prompt 能力不重要。它重要，但它是基本功之上的东西。我反复在说一件事：先搞清楚 HTTP 请求怎么从浏览器走到服务器再走回来，再谈指令设计。现在这类 PTA 工具最可能的落地方式，是把第二步提前，把第一步无限期往后推。
我可能是错的。但每次看到“从人类-AI 协作记录中自动得出有效交互特质”这种题目，我心里只有一句话：先给我看看这些交互生成的代码有没有测试、有没有审查、有没有人愿意为生产事故负责。把这几件事做完了，再回来谈特质方差。一个工程师和 AI 聊得再“有效”，生成的代码没有 review 就能过，测试用例是 AI 自己写的，掉进生产没人敢回滚——那协作特质再高，也是给垃圾流水线刷了一层传感器。
说到这我想起一个画面。不是论文里的，是我在一个群里看到过的：有人贴了一个“AI 协作效率评分工具”的截图，给每个人的 prompt 质量、追问次数、修正策略打分，满屏雷达图，视觉上特别高级。下面一水儿评论是“这个好，终于能度量 vibe 了”。我当时想回一句——vibe 本来就是写代码的姿态，不是产出物的质量。你给姿态装雷达图，不叫度量，叫测谎。最后我什么也没回，因为我知道回也没用，人家要的是这张图好看。
放下那篇论文本身，它方法上不是没有巧劲，把 PCA 的思路拿来改改用于对话分析，在 NLP 里也有些年头了。但它把“发现的到底是什么”这个根本问题留白，外面的人会拿“统计显著”四个字去市场上兑现。用方差解释行为、把标签误认为能力、先给结论再找合法性——这是我们这一行最老也最危险的反模式，只不过这次套了层“大模型推导”的新外套。工具三年一换，这个反模式三十年没变过。
我的态度很明确：别急着给“人和 AI 聊天”发明指标。真想度量一个工程师，有更稳定的东西可看：他交上来的 diff 里有没有测试，边界条件想过没有，依赖引入的代价有没有算清，出了生产事故敢不敢站出来把问题扛到底。你要非做交互分析，先把“这个特质为什么算技能、它随时间和任务类型怎么变”这两条想清楚再说。想清楚之前，任何一张交互特质雷达图，都只是另一种气味机——闻起来像工程，其实什么都没量。
先把代码看明白，再谈协作姿态。顺序搞反了，就是掩耳盗铃。