1. 項(xiàng)目緣起從一次失敗的代碼審查說起去年年底我們團(tuán)隊(duì)在合并一個(gè)大型功能分支時(shí)遇到了一個(gè)典型的“歷史災(zāi)難”。這個(gè)分支由三位同事并行開發(fā)了兩個(gè)月最終為了保持主分支的整潔采用了Squash Merge壓縮合并的方式將上百個(gè)提交記錄壓扁成了一個(gè)完美的、邏輯連貫的大提交。合并后不久一個(gè)線上服務(wù)出現(xiàn)了偶發(fā)性崩潰。當(dāng)我們試圖通過git bisect二分查找來定位引入問題的具體提交時(shí)卻傻眼了——那個(gè)唯一的、巨大的 Squash 提交包含了海量的改動(dòng)git bisect毫無用武之地。我們不得不花費(fèi)數(shù)天時(shí)間像考古學(xué)家一樣手動(dòng)翻閱合并前的原始分支提交記錄、代碼審查評論和 Slack 聊天記錄才勉強(qiáng)拼湊出問題的引入路徑。這個(gè)過程極其低效且痛苦。這次經(jīng)歷讓我開始思考在崇尚“整潔提交歷史”的現(xiàn)代協(xié)作流程如 GitHub Flow下Squash Merge 確實(shí)讓主線歷史清晰了但也徹底抹去了開發(fā)過程中的決策脈絡(luò)和上下文。當(dāng)我們需要回溯、理解或調(diào)試時(shí)這些被“壓縮”掉的歷史信息又變得至關(guān)重要。那么有沒有可能通過技術(shù)手段從那個(gè)最終“完美”的 Squash 提交中反向重構(gòu)出接近原始的、有意義的提交歷史呢這聽起來像是一個(gè)“反編譯”版本歷史的過程。AtomicCommitBench正是為了解決這個(gè)問題而生的一個(gè)基準(zhǔn)測試框架。它的核心命題非常有趣且具有挑戰(zhàn)性評測編碼智能體Coding Agents能否從一個(gè)被壓縮Squashed的代碼補(bǔ)丁中重建出合理的、細(xì)粒度的提交歷史。這不僅僅是測試 AI 的代碼生成能力更是對其理解代碼變更意圖、拆分邏輯單元、推斷開發(fā)步驟等高階認(rèn)知能力的綜合考驗(yàn)。對于從事代碼倉庫分析、開發(fā)工具增強(qiáng)甚至是 AI 輔助編程本身的研究者和開發(fā)者來說這個(gè)基準(zhǔn)提供了一個(gè)全新的、貼近真實(shí)工程痛點(diǎn)的評估視角。2. 深入拆解AtomicCommitBench 究竟在評測什么要理解這個(gè)基準(zhǔn)的價(jià)值我們得先拋開“AI”、“智能體”這些光環(huán)看看它試圖解決的核心問題是什么。本質(zhì)上這是一個(gè)代碼變更理解與結(jié)構(gòu)化重建的任務(wù)。2.1 任務(wù)定義從“是什么”到“為什么”和“怎么做”假設(shè)我們有一個(gè)最終的、合并后的代碼庫狀態(tài)以及一個(gè)代表了所有改動(dòng)的、單一的.patch文件即 Squashed Patch。這個(gè) Patch 里可能包含了新增的多個(gè)功能模塊。對現(xiàn)有模塊的修改和重構(gòu)。修復(fù)的若干個(gè) Bug。更新的測試用例和文檔。人類開發(fā)者在回顧這個(gè) Patch 時(shí)憑借經(jīng)驗(yàn)可以大致推斷出“哦這里應(yīng)該先搭建框架然后實(shí)現(xiàn)核心邏輯接著補(bǔ)充測試最后修復(fù)了邊界情況?！?我們是在嘗試還原開發(fā)者的意圖和步驟。AtomicCommitBench的任務(wù)就是要求 Coding Agent 扮演這個(gè)“歷史重構(gòu)者”的角色。給定一個(gè) Squashed Patch 和代碼庫的上下文Agent 需要輸出一系列原子提交Atomic Commits。每個(gè)原子提交應(yīng)該邏輯自洽包含一個(gè)完整、獨(dú)立的變更意圖例如“添加用戶登錄驗(yàn)證函數(shù)”或“修復(fù)數(shù)據(jù)序列化中的空指針異常”。可獨(dú)立編譯/通過測試在提交序列中每一步的代碼庫狀態(tài)理論上都應(yīng)該是可工作的雖然基準(zhǔn)可能不強(qiáng)制要求運(yùn)行。順序合理提交的順序應(yīng)符合開發(fā)依賴關(guān)系例如定義數(shù)據(jù)結(jié)構(gòu)的提交應(yīng)該在使用了該結(jié)構(gòu)的提交之前。2.2 評估指標(biāo)如何衡量“重建”的好壞光有輸出不行必須要有科學(xué)的衡量標(biāo)準(zhǔn)。AtomicCommitBench 的評估體系可能包含以下幾個(gè)維度這也是我們在設(shè)計(jì)類似任務(wù)時(shí)需要借鑒的與真實(shí)歷史的匹配度這是最直接的指標(biāo)。如果基準(zhǔn)數(shù)據(jù)集中包含了原始的、細(xì)粒度的真實(shí)提交歷史作為 Ground Truth那么就可以計(jì)算重建的提交序列與真實(shí)歷史在內(nèi)容、順序上的相似度。例如使用代碼差異Diff的編輯距離、提交信息的關(guān)鍵詞匹配度、以及提交順序的 Kendall Tau 相關(guān)系數(shù)等進(jìn)行綜合評估。注意完全匹配幾乎不可能也不應(yīng)是目標(biāo)。因?yàn)閷τ谕粋€(gè) Patch不同的開發(fā)者可能拆分成不同的合理序列。因此評估需要容忍合理的多樣性。原子性與合理性通過人工或啟發(fā)式規(guī)則評估每個(gè)重建的提交是否滿足“原子性”。例如一個(gè)提交是否同時(shí)包含了不相關(guān)的功能改動(dòng)和 Bug 修復(fù)提交信息是否準(zhǔn)確描述了其包含的變更這部分的評估往往需要引入人工評審或基于大語言模型的自動(dòng)評審。依賴關(guān)系還原度分析重建的提交序列中的依賴圖例如提交 A 定義的函數(shù)在提交 B 中被調(diào)用并與從最終代碼狀態(tài)反向推斷出的理想依賴關(guān)系進(jìn)行對比。還原的依賴關(guān)系越清晰、越合理得分越高。信息增益這是我認(rèn)為最關(guān)鍵的一點(diǎn)。重建的歷史相比單一的 Squash 提交是否提供了更多的、有用的開發(fā)上下文例如是否清晰地分離了“功能新增”和“后續(xù)重構(gòu)”是否將“Bug 引入”和“Bug 修復(fù)”隔離成了不同的提交這種結(jié)構(gòu)化的信息對于后續(xù)的代碼審查、問題定位和知識傳承具有巨大價(jià)值。2.3 為什么選擇 Coding Agents 作為評測對象你可能會(huì)問為什么不用傳統(tǒng)的程序分析工具來做這件事事實(shí)上有一些研究嘗試通過靜態(tài)分析代碼差異、識別變更簇Change Clusters來拆分提交。但這類方法往往局限于語法層面難以理解深層的開發(fā)意圖。Coding Agents特別是基于大語言模型LLM的智能體帶來了新的可能性。它們能夠理解自然語言上下文結(jié)合代碼變更和可能的上下文信息如 Issue 描述、代碼注釋推斷開發(fā)任務(wù)。進(jìn)行邏輯推理判斷哪些修改屬于同一個(gè)邏輯單元哪些修改之間存在先決條件關(guān)系。生成結(jié)構(gòu)化輸出不僅能生成代碼 Diff還能生成符合規(guī)范的提交信息Commit Message這是重構(gòu)歷史不可或缺的一部分。因此AtomicCommitBench 將 Coding Agents 置于這個(gè)復(fù)雜任務(wù)中正是為了檢驗(yàn)當(dāng)前 AI 在理解軟件開發(fā)過程這一深層能力上的進(jìn)展而不僅僅是代碼補(bǔ)全的熟練度。3. 實(shí)戰(zhàn)模擬如何構(gòu)建一個(gè)簡易的 Commit 重建任務(wù)理解了基準(zhǔn)的原理后我們可以嘗試設(shè)計(jì)一個(gè)簡化版的實(shí)戰(zhàn)任務(wù)來親身體驗(yàn)其中的挑戰(zhàn)。這里我們以 Python 項(xiàng)目為例。3.1 準(zhǔn)備階段創(chuàng)建“真實(shí)歷史”與“Squash 補(bǔ)丁”首先我們模擬一個(gè)微型的開發(fā)過程。步驟一初始化倉庫并創(chuàng)建一系列原子提交# 1. 初始化倉庫和初始文件 mkdir atomic_commit_demo cd atomic_commit_demo git init echo # 用戶管理模塊 README.md git add README.md git commit -m docs: 添加項(xiàng)目README # 2. 提交1添加用戶模型類 cat user.py EOF class User: def __init__(self, username, email): self.username username self.email email self.is_active True def get_profile(self): return fUser: {self.username}, Email: {self.email} EOF git add user.py git commit -m feat: 添加User數(shù)據(jù)模型類 # 3. 提交2添加用戶驗(yàn)證函數(shù) cat auth.py EOF from user import User def validate_user(user): 驗(yàn)證用戶信息是否有效 if not user.username or not user.email: return False if not in user.email: return False return user.is_active EOF git add auth.py git commit -m feat: 添加用戶基礎(chǔ)驗(yàn)證函數(shù) # 4. 提交3修復(fù)驗(yàn)證邏輯的邊界情況 cat auth.py EOF from user import User def validate_user(user): 驗(yàn)證用戶信息是否有效 if not user.username or not user.email: return False if not in user.email: return False # 修復(fù)檢查郵箱格式是否包含域名部分 if . not in user.email.split()[-1]: return False return user.is_active EOF git add auth.py git commit -m fix: 完善郵箱格式驗(yàn)證邏輯 # 5. 提交4為驗(yàn)證函數(shù)添加單元測試 cat test_auth.py EOF import pytest from user import User from auth import validate_user def test_valid_user(): user User(alice, aliceexample.com) assert validate_user(user) True def test_user_with_invalid_email(): user User(bob, bob-example) # 缺少符號 assert validate_user(user) False def test_user_with_malformed_email(): user User(charlie, charlieexample) # 缺少域名后綴 assert validate_user(user) False EOF git add test_auth.py git commit -m test: 為validate_user函數(shù)添加單元測試現(xiàn)在我們有了一個(gè)包含4個(gè)邏輯清晰原子提交的歷史。步驟二模擬 Squash Merge生成“目標(biāo)補(bǔ)丁”我們創(chuàng)建一個(gè)新的分支模擬將這些提交壓縮合并。# 切換到新分支并重置到初始狀態(tài) git checkout -b squashed_branch git reset --hard HEAD~4 # 回到README提交之后 # 使用 git merge --squash 來獲取合并后的所有變更但不實(shí)際提交 git merge --squash main # 此時(shí)所有從main分支的修改都已暫存staged # 生成這個(gè)“壓縮后”的補(bǔ)丁即Squashed Patch git diff --cached squashed_patch.patch現(xiàn)在squashed_patch.patch文件包含了所有4個(gè)提交的總和變更它就是我們要提供給 Coding Agent 的“謎面”。而main分支上的4個(gè)獨(dú)立提交就是“謎底”Ground Truth。3.2 任務(wù)挑戰(zhàn)人工分析 Squash 補(bǔ)丁讓我們先不借助 AI人工查看一下squashed_patch.patch文件。你會(huì)發(fā)現(xiàn)它同時(shí)包含了新增user.py文件定義了User類。新增auth.py文件包含validate_user函數(shù)及其后續(xù)修復(fù)。新增test_auth.py文件包含三個(gè)測試用例。挑戰(zhàn)立刻浮現(xiàn)邏輯分組你會(huì)如何拆分是把user.py和auth.py放一起作為一個(gè)“用戶認(rèn)證模塊”提交還是分開auth.py中的函數(shù)定義和后續(xù)的修復(fù)邏輯是放在一個(gè)提交里還是拆成兩個(gè)順序推斷直覺上User類應(yīng)該在validate_user函數(shù)之前因?yàn)楹瘮?shù)依賴這個(gè)類。測試文件顯然應(yīng)該在功能代碼之后。但那個(gè)“修復(fù)郵箱驗(yàn)證邏輯”的補(bǔ)丁是在寫測試之前還是之后發(fā)現(xiàn)的從最終的 Patch 里很難判斷。提交信息生成為每個(gè)拆分出來的提交撰寫清晰、準(zhǔn)確的提交信息。例如對于修復(fù)郵箱驗(yàn)證的那幾行代碼信息是寫“修復(fù)郵箱驗(yàn)證邏輯”還是更具體的“修復(fù)郵箱域名缺失導(dǎo)致的驗(yàn)證通過問題”這個(gè)簡單的例子已經(jīng)包含了功能新增、邏輯修復(fù)、測試添加三種常見變更類型并且存在清晰的依賴關(guān)系。對于一個(gè) Coding Agent 來說它需要理解 Python 語法導(dǎo)入關(guān)系、代碼語義函數(shù)功能并做出合理的推斷。3.3 設(shè)計(jì)一個(gè)簡單的評估腳本假設(shè)我們有一個(gè) Coding Agent 的輸出一組重建的提交我們可以編寫一個(gè)簡單的 Python 腳本從幾個(gè)維度進(jìn)行自動(dòng)化評估這里僅為示例真實(shí)評估更復(fù)雜。import subprocess import os from difflib import SequenceMatcher class SimpleCommitEvaluator: def __init__(self, ground_truth_dir, reconstructed_dir): ground_truth_dir: 存放真實(shí)原子提交補(bǔ)丁的目錄 reconstructed_dir: 存放智能體重建提交補(bǔ)丁的目錄 self.gt_dir ground_truth_dir self.rc_dir reconstructed_dir def get_patch_content(self, filepath): 讀取補(bǔ)丁文件內(nèi)容 with open(filepath, r, encodingutf-8) as f: return f.read() def evaluate_content_similarity(self): 計(jì)算內(nèi)容相似度非常簡單的基于文本的相似度 gt_patches sorted([f for f in os.listdir(self.gt_dir) if f.endswith(.patch)]) rc_patches sorted([f for f in os.listdir(self.rc_dir) if f.endswith(.patch)]) # 這里假設(shè)順序一一對應(yīng)實(shí)際情況需要做對齊如最長公共子序列匹配 total_similarity 0 for gt_file, rc_file in zip(gt_patches, rc_patches): gt_content self.get_patch_content(os.path.join(self.gt_dir, gt_file)) rc_content self.get_patch_content(os.path.join(self.rc_dir, rc_file)) ratio SequenceMatcher(None, gt_content, rc_content).ratio() total_similarity ratio print(f對比 {gt_file} 與 {rc_file}: 相似度 {ratio:.2f}) avg_similarity total_similarity / len(gt_patches) if gt_patches else 0 print(f\n平均內(nèi)容相似度: {avg_similarity:.2f}) return avg_similarity def check_commit_message_format(self, rc_msg_dir): 檢查重建提交的信息格式示例是否包含類型前綴 # 例如檢查是否遵循類似 Conventional Commits 的格式 # feat:, fix:, test:, docs:, chore: 等 valid_prefixes [feat:, fix:, test:, docs:, chore:, refactor:] rc_msgs [f for f in os.listdir(rc_msg_dir) if f.endswith(.msg)] format_ok_count 0 for msg_file in rc_msgs: with open(os.path.join(rc_msg_dir, msg_file), r) as f: first_line f.readline().strip() if any(first_line.startswith(prefix) for prefix in valid_prefixes): format_ok_count 1 else: print(f可能格式不符: {msg_file} - {first_line}) format_score format_ok_count / len(rc_msgs) if rc_msgs else 0 print(f\n提交信息格式合規(guī)率: {format_score:.2f}) return format_score # 假設(shè)使用方式 if __name__ __main__: evaluator SimpleCommitEvaluator(path/to/ground_truth_patches, path/to/reconstructed_patches) content_score evaluator.evaluate_content_similarity() message_score evaluator.check_commit_message_format(path/to/reconstructed_messages) # 可以設(shè)計(jì)更復(fù)雜的加權(quán)總分這個(gè)評估器非常基礎(chǔ)真實(shí)場景中AtomicCommitBench 會(huì)使用更嚴(yán)謹(jǐn)?shù)闹笜?biāo)例如基于抽象語法樹AST的差異比較、考慮提交順序的圖匹配算法等。4. 對 Coding Agents 的能力要求與當(dāng)前局限通過上面的模擬我們可以總結(jié)出要完成 AtomicCommitBench 的任務(wù)一個(gè) Coding Agent 需要具備以下多維度的能力4.1 核心能力維度代碼變更聚類分析能識別出哪些文件的修改是高度相關(guān)的屬于同一個(gè)邏輯任務(wù)。例如auth.py中函數(shù)定義的修改和test_auth.py中對應(yīng)測試的修改應(yīng)該被聚類。開發(fā)意圖推斷能根據(jù)代碼變更的內(nèi)容推斷出開發(fā)者的意圖是“新增功能”、“修復(fù)缺陷”、“重構(gòu)代碼”還是“添加測試”。這需要理解代碼語義而不僅僅是語法。依賴關(guān)系解析能分析出代碼元素類、函數(shù)、變量之間的創(chuàng)建、使用關(guān)系從而推斷出合理的提交順序。例如User類必須先于使用它的validate_user函數(shù)被提交。原子性邊界判斷知道“一個(gè)合理的提交”應(yīng)該有多大。過細(xì)每一行一個(gè)提交和過粗把所有東西塞一起都不對。這需要平衡“功能完整性”和“變更隔離性”。高質(zhì)量文本生成能為每個(gè)重建的提交生成準(zhǔn)確、簡潔的提交信息。好的提交信息是歷史可讀性的關(guān)鍵。4.2 當(dāng)前主流 Coding Agents 的潛在局限盡管像 GitHub Copilot、Claude、ChatGPT 等基于 LLM 的智能體在代碼生成上表現(xiàn)出色但在 AtomicCommitBench 這類任務(wù)上可能面臨挑戰(zhàn)上下文長度限制一個(gè)大型的 Squash Patch 可能非常龐大超出模型的上下文窗口。雖然可以通過分塊處理但會(huì)丟失全局視圖。對“過程”的理解缺失LLM 通常在“快照”數(shù)據(jù)上訓(xùn)練對軟件開發(fā)這種動(dòng)態(tài)的、有狀態(tài)的過程缺乏內(nèi)在理解。它可能擅長生成最終的代碼但不一定理解達(dá)到最終狀態(tài)所經(jīng)歷的合理步驟序列。項(xiàng)目特定知識的依賴優(yōu)秀的提交拆分需要了解項(xiàng)目的架構(gòu)、編碼規(guī)范和團(tuán)隊(duì)習(xí)慣。一個(gè)通用的 Coding Agent 在沒有微調(diào)或提供充足上下文的情況下很難做到這一點(diǎn)。評估的模糊性正如前文所述對于“什么是最好的拆分”沒有唯一答案。這導(dǎo)致評估本身具有主觀性使得訓(xùn)練和優(yōu)化 Agent 的目標(biāo)函數(shù)難以明確界定。4.3 可能的改進(jìn)方向與工具思路面對這些挑戰(zhàn)未來的 Coding Agents 或?qū)ｉT工具可能會(huì)朝以下方向發(fā)展分層處理架構(gòu)先使用輕量級程序分析工具如基于 AST 的差異分析、代碼克隆檢測對大型 Patch 進(jìn)行初步的粗粒度聚類再將每個(gè)聚類交給 LLM 進(jìn)行細(xì)粒度的意圖理解和提交信息生成。這樣可以有效解決上下文長度問題。融入開發(fā)過程信號如果條件允許讓 Agent 能夠訪問開發(fā)過程中的輔助信息如 Issue/PR 描述、代碼審查評論、甚至開發(fā)者活動(dòng)時(shí)間線。這些信息能為意圖推斷提供強(qiáng)有力的線索?；诮换サ牡亟ㄔ试S Agent 與用戶或評估系統(tǒng)進(jìn)行交互。例如Agent 提出一個(gè)初步的重建方案用戶反饋“這個(gè)提交包含了兩個(gè)不相關(guān)的功能”Agent 據(jù)此進(jìn)行調(diào)整。這模擬了人類重構(gòu)歷史時(shí)的思考過程。領(lǐng)域自適應(yīng)微調(diào)在特定公司或項(xiàng)目的代碼歷史數(shù)據(jù)上對 Agent 進(jìn)行微調(diào)使其學(xué)習(xí)該環(huán)境下的提交模式和規(guī)范從而生成更符合期望的歷史。5. 超越評測AtomicCommitBench 的工程實(shí)踐啟示AtomicCommitBench 雖然是一個(gè)研究性的評測基準(zhǔn)但它所指向的問題和思路對我們?nèi)粘５墓こ虒?shí)踐有著直接的啟示。5.1 對開發(fā)流程的反思Squash Merge 的利與弊這個(gè)基準(zhǔn)讓我們不得不重新審視Squash Merge的廣泛使用。它的優(yōu)點(diǎn)顯而易見主線歷史清晰線性、整潔每個(gè)提交都對應(yīng)一個(gè)完整的功能或修復(fù)。避免中間態(tài)污染不會(huì)將“WIP”工作進(jìn)行中或“調(diào)試用打印語句”這類提交混入主線。但其代價(jià)是巨大的信息損失決策過程丟失一個(gè)功能是如何一步步構(gòu)建起來的遇到了哪些問題嘗試了哪些方案這些寶貴的工程決策上下文消失了。責(zé)任追溯模糊如果一個(gè)大提交引入了問題很難快速定位是其中哪一部分修改導(dǎo)致的削弱了git bisect等工具的功效。代碼審查負(fù)擔(dān)后移審查一個(gè)巨大的、最終的 Squash 提交非常困難。理想的審查應(yīng)該針對一系列小的、原子提交以便于理解增量變化。實(shí)踐建議不必完全放棄 Squash Merge但可以更智慧地使用它。例如在功能分支內(nèi)部依然保持原子提交。合并時(shí)如果分支歷史整潔且有價(jià)值考慮使用Merge Commit保留歷史。如果使用 Squash Merge確保 Squash 后的提交信息極其詳盡最好能手動(dòng)概括分支內(nèi)的關(guān)鍵步驟和決策點(diǎn)。利用工具也許未來就是由 AtomicCommitBench 錘煉出的 Coding Agent在合并后自動(dòng)或半自動(dòng)地生成一份“開發(fā)歷程摘要”文檔附在 PR 或 Issue 后面作為知識留存。5.2 對代碼倉庫管理與知識留存的價(jià)值A(chǔ)tomicCommitBench 的終極目標(biāo)可以看作是提升代碼倉庫作為知識載體的質(zhì)量。一個(gè)結(jié)構(gòu)良好的提交歷史就是一個(gè)生動(dòng)的項(xiàng)目編年史和設(shè)計(jì)文檔。對于團(tuán)隊(duì)的新成員閱讀一系列原子提交是理解代碼庫演變和設(shè)計(jì)思路的最佳途徑之一遠(yuǎn)比直接閱讀最終代碼或冗長的設(shè)計(jì)文檔更有效。對于排查復(fù)雜問題細(xì)粒度的歷史允許進(jìn)行更精確的“考古”。對于衡量開發(fā)效率和質(zhì)量原子提交提供了更細(xì)粒度的分析數(shù)據(jù)。因此無論是否有 AI 的參與作為開發(fā)者我們都應(yīng)該有意識地去撰寫原子提交。這不僅僅是一個(gè)好習(xí)慣更是為未來的自己、隊(duì)友和任何需要理解這段代碼的人留存下一份寶貴的、結(jié)構(gòu)化的上下文信息。AtomicCommitBench 的出現(xiàn)或許會(huì)推動(dòng)工具生態(tài)的發(fā)展未來我們的 IDE 或 Git 客戶端可能會(huì)內(nèi)置“提交建議”功能實(shí)時(shí)分析我們的暫存區(qū)提示“當(dāng)前修改似乎包含了兩個(gè)獨(dú)立的功能建議拆分成兩個(gè)提交”并自動(dòng)生成草稿信息。這將是 AI 對開發(fā)者工作流一次真正意義上的賦能。從一次痛苦的排查經(jīng)歷到一個(gè)前沿的研究基準(zhǔn)再到對我們?nèi)粘ｉ_發(fā)習(xí)慣的反思AtomicCommitBench 這個(gè)命題串聯(lián)起了軟件工程中一個(gè)深刻而實(shí)際的問題我們?nèi)绾卧谧非笳麧嵭缘耐瑫r(shí)不丟失過程中的智慧與上下文。目前這主要依靠開發(fā)者的自覺和技藝。但未來我們或許可以期待經(jīng)過類似 AtomicCommitBench 這樣高標(biāo)準(zhǔn)任務(wù)錘煉的 Coding Agents能夠成為我們得力的“開發(fā)歷史助理”幫助我們在信息的“壓縮”與“解壓”之間找到更好的平衡點(diǎn)。