皇后大学与魁北克大学揭示:AI代码生成存在运行日志记录行为差异
这项由加拿大皇后大学（Queen's University）与魁北克大学高等技术学院（ETS - Québec University）联合开展的研究，于2026年4月发表于ACM旗下的学术期刊，论文编号为arXiv:2604.09409，感兴趣的读者可通过该编号查阅完整原文。研究团队分析了81个开源代码仓库中的4550条AI生成的"代码合并请求"（可以把它理解为AI工程师提交的一批工作成果）以及3276条人类工程师提交的同类成果，专门考察了一个此前从未被系统研究过的问题：当AI替我们写代码时，它们是否也会像有经验的工程师一样，在代码里留下"运行日志"？
要理解这个问题的重要性，先聊聊"运行日志"究竟是什么。以你家的热水器为例，如果它内置了一个小本子，每隔一段时间就自动记录"当前水温38度"、"加热元件正常工作"、"某处管道压力异常"，那么当热水器某天突然不出热水时，维修师傅翻开这个小本子，就能快速判断是哪里出了问题。软件系统里的"日志"（Log）扮演的正是这个小本子的角色。它记录程序在运行过程中发生的各种事件，帮助工程师在系统出问题时快速定位原因，或者在日常运营中监控系统健康状况。没有日志，系统出了故障就像在黑屋子里找一只黑猫——不是不可能，但极其痛苦。日志太多，又像是把整栋楼的噪声都录下来找某一句话，同样令人头疼。如何在"记录足够多"和"不记录废话"之间找到平衡，是软件工程师凭经验磨练出来的手艺。
现在，AI代码助手大量涌现，它们能接受人类用自然语言描述的任务，自主规划、编写代码，并提交工作成果。问题来了：这种手艺，AI学会了吗？
研究团队给这个问题设计了三条调查线索，分别对应三个研究问题：AI的日志习惯与人类有什么不同？人类会不会专门在指令里告诉AI怎么写日志？AI写完日志之后，人类又做了什么修改？带着这三条线索，研究团队展开了一场颇具意思的侦查。
一、AI工程师的"记录习惯"：写得少，但写起来密度不低
先来说第一条线索。研究团队发现，在81个被研究的代码仓库中，有58.4%的仓库里，人类工程师比AI更频繁地在提交代码时顺手改动日志——也就是说，在同一个项目里，人类更习惯把日志调整当作写代码的"连带动作"，而AI则更倾向于专注于功能代码本身，把日志这件事放到一边。
具体数字是这样的：在同一批项目里，人类提交的代码中有23.5%会涉及日志改动，而AI只有18.5%。这个差距在统计上是显著的（p值为0.019，意思是这个差距不太可能是偶然导致的），大约意味着AI改动日志的频率比人类低了16%左右。
然而，事情有个反转。当AI确实去写日志的时候，它写得相当密集。在那些AI和人类都会改动日志的67个仓库里，AI平均每修改1000行代码就会留下比人类多30%的日志记录。表面上看，这似乎说明AI"很重视"日志，但研究团队进一步挖掘后发现，这个"密度更高"其实有一个很朴素的解释：AI通常负责的是规模较小的代码改动任务，而日志密度天然随着代码量的增加而降低（毕竟你修改10行代码加了1条日志，和修改1000行代码加了5条日志相比，前者的密度就高得多）。AI提交的代码改动中位数约为1279行，而人类是2770行，差了一倍多。把这个规模差异考虑进去之后，两者的日志密度其实相当接近——在那些AI负责的代码量反而更大的仓库里，AI甚至比人类还要保守，少写了21%的日志。
研究团队把这个现象解读为一种"选择性委托"模式：人类工程师倾向于把规模较小、边界清晰的任务交给AI，把大型架构性改动留给自己。这让AI看起来"密度更高"，其实只是任务规模使然。
在日志内容的风格上，AI和人类的相似程度颇为一致：两者写的日志消息长度几乎一样（中位数分别为33个字符和30个字符），在同类项目里，63.6%的仓库里两者的消息长度相当。然而，有两个地方出现了明显分歧。
第一个分歧是日志级别。软件日志有不同的"严重程度"分级，就像医院里的病情分级一样：DEBUG是"日常体检记录"（最详细的调试信息），INFO是"今日状况汇报"（正常运行的流程说明），WARN是"有点异常但还没出事"，ERROR和CRITICAL则是"出大问题了"。研究发现，AI在ERROR级别的日志上表现不错，与人类的使用习惯高度一致（53.2%的仓库里两者相近）。但在INFO级别，人类比AI更爱写——在24.7%的仓库里，人类的INFO日志明显多于AI。WARN级别则是AI的"冒进区"，在29.9%的仓库里，AI写的WARN比人类多。
这个规律背后有一个有趣的含义：AI倾向于把日志当成"出事了才记录"的工具，而人类工程师还习惯用INFO日志来记录程序的正常流转状态，比如"某个操作已经成功完成"。这种"顺手记录正常状态"的习惯，AI学得不够好。
第二个分歧是日志放在代码的什么位置。代码里的"控制流结构"就像是一条河流里的分叉和关卡：条件判断（if/else）是一个岔路口，循环（for/while）是一段会反复走的回路，异常捕获（try/catch）是一张安全网。研究发现，AI在异常捕获块和顶层函数体里放日志的习惯与人类相近（分别在58.4%和59.7%的仓库里相似），但在条件判断块里，只有46.7%的仓库里两者相近，人类更爱在这里写日志的情况占28.6%。在循环结构里，差距更大——32.5%的仓库里人类写的循环日志明显多于AI。循环里的日志通常用于追踪一批数据处理的进度或状态，这类"过程性记录"恰好也是INFO级别日志的典型用途。两个发现前后呼应，共同指向一个结论：AI的日志视角偏向"发生错误时留痕"，而非"记录整个运行过程"。
二、"告诉AI要写日志"有用吗？98.7%的时候根本没人说
顺着第一条线索的发现，研究团队开始追问：既然AI在日志上的习惯和人类有差距，那人类会不会通过给AI的指令来弥补这个差距呢？
研究团队系统性地检查了三种人类向AI发出指令的渠道。第一种是"任务说明书"，即人类在给AI分配任务时写的问题描述（类似于给员工的工单）。第二种是"仓库级别的行为守则"，即存放在代码仓库里、用来告诉AI这个项目应该遵守哪些规矩的说明文件，例如CLAUDE.md或AGENTS.md这类文件。第三种是"代码审查评论"，即人类在审查AI提交的代码时写下的修改意见。
结果非常直接：在研究团队能够观察到指令内容的1308条AI代码提交中，只有4.7%（61条）附带了任何关于日志的明确指示。换句话说，超过95%的时候，人类把任务交给AI，压根没提日志的事。这就好像你雇了一个新员工来装修房子，结果忘了告诉他"墙上记得留水管走线"，事后却抱怨他没留。
更有意思的发现在于，即便那5%的人确实说了关于日志的要求，AI的执行情况也令人失望。研究团队把这61条含有日志指令的情况分成两大类来分析：来自任务说明书的15条，和来自仓库说明文件的46条。
在任务说明书这一侧，15条日志指令中有73.3%（11条）是措辞明确、要求具体的"强指令"，比如指定了要用哪个日志框架、用什么日志级别、在哪些文件里加日志。然而，这些强指令的遵守率只有27.3%——换言之，哪怕人类写得清清楚楚，AI也有将近四分之三的概率忽视这个要求。相比之下，那4条措辞模糊的"弱指令"（比如只说"加点日志"或"确保可观测性"）反而有50%的遵守率，虽然也不算高，但比强指令还好。这个反直觉的结果提示我们，指令越具体不一定越有效，模型可能在某些情况下对模糊指令反而有更高的响应意愿，但两者的整体合规率都偏低。
在仓库说明文件这一侧，46条日志指令全部是强指令，但整体遵守率只有6.5%。其中有一个特殊情况值得一提：某个项目的说明文件里写着"调试时可以用日志，但提交前必须删掉"，结果对应的10条日志提交里，AI的遵守率是100%——但研究团队怀疑这可能是"空遵守"，因为AI很可能从头到尾就没有添加过调试日志，所以最终代码里当然也不会有，并非真正意义上的"主动删除"。
将所有情况综合起来，研究团队计算得出：含有日志指令的AI提交中，遵守率约为33%，也就是说有67%的时候AI没有按照人类的日志要求行事。更进一步，从统计上来看，有没有日志相关指令，对AI最终是否改动日志这件事几乎毫无影响（有指令的14.8%改动率对比无指令的20.8%，差异在统计上不显著）。这意味着，在当前的开发实践中，日志这件事陷入了一个双重困境：人类很少开口说（说明gap），AI说了也常常不听（执行gap）。
三、AI写完日志后，人类悄悄当起了"隐形清洁工"
追到这里，研究团队开始看第三条线索：AI提交的代码被合并之前和之后，日志有没有被修改过？谁在改？
研究发现，不论是AI还是人类写的代码，在最终合并之前被修改的比例都很高。AI提交的含日志代码中，77.2%在后续提交中经历了修改；人类的比例稍高，为81.6%。光看这个数字，两者似乎差不多。
但修改的执行者大相径庭。在AI提交的代码被修改的案例里，有54.5%的修改是由人类单独完成的，有35.1%是由自动化机器人完成的，剩余10.3%是人类和机器人共同参与。而在人类提交的代码被修改的案例里，97.8%的修改者也是人类，机器人参与的不到2%。
更清晰的数字来自日志语句层面的统计：在AI代码里所有的后续日志改动中，72.5%是由人类完成的，只有27.5%来自自动化工具。这意味着，人类工程师在审查、合并AI提交的代码之后，还在默默地补充、修正、或删除日志——这项工作发生在后续的代码提交里，而不是通过正式的审查意见提出来的。
研究团队用了一个贴切的比喻来描述这种现象：人类工程师成了"隐形清洁工"（silent janitors）。他们不是在正式的审查流程里高调地指出"这里日志不对"，而是悄悄地在后续提交里把问题修掉，就像餐厅里有个人一直在收拾别人漏下的碎屑，但从来不大声说出来。
研究团队还用一种叫做"生存分析"的统计方法，追踪了AI新写的日志在多久后会被第一次修改。结果发现，两者的日志都倾向于在代码提交后早期就被修改（这很正常，刚提交时问题最容易被发现），但人类写的日志被修改的速度更快、频率更高。换句话说，AI写的日志更"粘"，一旦进入代码就很少再被改动——但这并不意味着AI的日志质量更高，更可能的原因是审查者对AI代码里的日志关注不够。
在代码审查评论层面，明确提及日志问题的意见在AI提交（2.18%）和人类提交（2.17%）中几乎一样罕见。即便限定在那些本来就含有日志改动的提交里，比例也只有5.8%和6%。这说明日志问题很少以正式审查意见的形式被提出，大多数情况下，它是被默默修复的，而不是被明确指出的。
另一个有趣的发现是，日志被修改的行为主要集中在大体量的代码提交里。AI提交中，被修改过日志的代码量中位数是2702行，而未被修改的只有231行。人类提交里的规律更明显：被修改的是4390行，未修改的是250行。简而言之，改动越大，日志越容易被重新打磨，小打小闹的改动里的日志往往就这么过去了。
四、这些发现告诉我们什么：三个关键启示
这项研究的发现指向了三个非常实际的方向。
对于开发AI编程工具的团队而言，研究给出了一个明确信号：光靠自然语言指令来约束AI的日志行为，可能是条死路。指令稀少、执行率低、效果不可预期，这三重叠加让"在说明文件里告诉AI写好日志"变成了一种不可靠的保障机制。研究团队建议，未来的工具设计应该引入"确定性护栏"（deterministic guardrails），也就是在AI提交代码之前，通过自动化的规则检查工具（类似于代码风格检查器或持续集成流水线里的测试）来强制验证日志是否符合标准。把"有没有写日志"从一个可选项变成一个硬性门槛，才能确保AI产出的代码在可观测性上是可靠的。
对于研究AI能力边界的学者而言，这项研究揭示了一个有趣的训练偏差。当前的大语言模型在错误处理场景里表现出来的日志意识是不错的，但在追踪程序正常状态方面的意识明显偏弱。研究者建议，未来可以用专门的训练数据或奖励模型来强化AI对"状态转移日志"（即记录程序从一个状态过渡到另一个状态的日志）的重视程度，甚至可以利用强化学习的方法，用静态代码分析工具作为"评分标准"，让AI在未打日志的代码路径上自动受到惩罚，从而学会更全面的日志习惯。
对于实际使用AI辅助开发的工程师和项目负责人而言，这项研究揭示了一个被忽视的隐性成本。AI写代码的速度是快了，但人类在后续默默补日志、改日志、删日志所花的时间，并没有因为AI的介入而减少，反而形成了一种"隐形维护税"。研究团队建议，代码审查流程应该把"日志和可观测性"列为明确的检查项，就像功能正确性一样受到重视。如果审查者发现AI的代码缺乏必要的日志，应该明确要求AI修改，而不是自己悄悄补上。只有把这个责任清晰地交回给AI，才能让AI辅助开发真正减轻人类的工作负担，而不是把负担转移到一个不那么显眼的地方。
归根结底，这项研究描绘出一幅相当真实的图景：AI编程助手已经能写出功能上基本过关的代码，也能模仿人类在错误处理时留日志的直觉，但在"时刻记录程序健康状态"这个更深层的工程习惯上，它们还差得远。更令人警觉的是，人类在与AI协作的过程中，似乎已经悄悄接受了这个缺口，并默默地承担起了填补它的责任，而没有人大声说出来。这就像雇了一个不擅长收尾工作的承包商，然后业主自己每天早上偷偷补漏，表面上工程进度很快，实际上背后的维护成本从来没有真正消失。
如果你在工作中使用或计划使用AI辅助编程，这项研究的结论或许值得认真思考：你的团队是否在不知不觉中也扮演着这种"隐形清洁工"的角色？你们的代码审查流程，是否真的把AI提交的可观测性质量当成一个需要显式检验的问题？对这些问题感兴趣的读者，可以通过arXiv编号2604.09409查阅完整原文，原论文附有详细的数据集、分析代码及完整方法描述，为进一步研究提供了充分的基础。
Q&A
Q1：AI编程助手生成的代码里，日志数量是比人类少还是多？
A：总体来说，AI在日志频率上比人类低——58.4%的项目里，AI改动日志的代码提交比例低于人类。但当AI确实去写日志时，每千行代码里写的日志条数反而比人类多约30%。这个"密度更高"主要是因为AI通常负责较小规模的代码修改任务，小改动天然导致日志密度偏高，并不代表AI真的更重视日志。当控制了代码改动规模这个因素后，两者的日志行为其实相当接近。
Q2：在指令里明确要求AI写日志，有效果吗？
A：效果相当有限。研究发现，即便人类在任务说明里明确、具体地要求AI添加日志（比如指定了框架、级别和文件），AI的遵守率也只有27.3%。综合所有场景计算，AI对日志指令的整体不遵守率高达67%。更关键的是，从统计上看，有没有日志相关指令，对AI最终是否改动日志这件事几乎没有影响。
Q3：AI写的日志在提交后，谁会去修改它？
A：主要还是人类工程师在默默修改。研究发现，在AI提交代码后发生的所有日志修改中，有72.5%是由人类完成的，且这些修改大多出现在后续的代码提交里，而不是通过正式的审查意见提出来的。研究团队把这种现象称为"隐形清洁工"效应——人类在悄悄补漏，而不是在审查环节公开指出问题。