這項由加拿大皇后大學（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%是由人類完成的，且這些修改大多出現在後續的代碼提交里，而不是通過正式的審查意見提出來的。研究團隊把這種現象稱為"隱形清潔工"效應——人類在悄悄補漏，而不是在審查環節公開指出問題。
