这项由加拿大皇后大学Queens 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%差异在统计上不显著。这意味着在当前的开发实践中日志这件事陷入了一个双重困境人类很少开口说说明gapAI说了也常常不听执行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查阅完整原文原论文附有详细的数据集、分析代码及完整方法描述为进一步研究提供了充分的基础。QAQ1AI编程助手生成的代码里日志数量是比人类少还是多A总体来说AI在日志频率上比人类低——58.4%的项目里AI改动日志的代码提交比例低于人类。但当AI确实去写日志时每千行代码里写的日志条数反而比人类多约30%。这个密度更高主要是因为AI通常负责较小规模的代码修改任务小改动天然导致日志密度偏高并不代表AI真的更重视日志。当控制了代码改动规模这个因素后两者的日志行为其实相当接近。Q2在指令里明确要求AI写日志有效果吗A效果相当有限。研究发现即便人类在任务说明里明确、具体地要求AI添加日志比如指定了框架、级别和文件AI的遵守率也只有27.3%。综合所有场景计算AI对日志指令的整体不遵守率高达67%。更关键的是从统计上看有没有日志相关指令对AI最终是否改动日志这件事几乎没有影响。Q3AI写的日志在提交后谁会去修改它A主要还是人类工程师在默默修改。研究发现在AI提交代码后发生的所有日志修改中有72.5%是由人类完成的且这些修改大多出现在后续的代码提交里而不是通过正式的审查意见提出来的。研究团队把这种现象称为隐形清洁工效应——人类在悄悄补漏而不是在审查环节公开指出问题。