AI 編碼時代，良好的編程習慣仍然重要

最近做一個 Agent 基準測試，發現不能簡單地用開發者視角來評估一個編程任務對 AI 的複雜度。
比如一個重構任務：把一個幾千行的大文件，按功能拆成十多個小模組。
這個任務對開發者來說其實不算難，主要工作就是移動代碼、整理 imports、編譯驗證，新手也能搞定。
所以想到用一個簡單的任務來做一下基準，結果卻出乎意料。
Claude Code 判斷這個任務比較大，嘗試拆了一部分，提了個 PR 寫了 Future work 打算分步來。
我自己的 Agent 是“硬上”，往完整拆分的方向推進了更多，但代價也很明顯：Token 消耗是 Claude 的幾十倍，後面大量時間都花在反覆讀文件、修編譯錯誤、再讀文件、再修錯誤上。
這讓我意識到，人覺得簡單的任務，對 Agent 不一定簡單。
對人來說，這類重構很多時候就是“把這一段挪過去”。但對 Agent 來說，它要先分批讀大文件，記住哪些函數和哪些測試有關，再生成一堆跨文件修改，最後通過編譯錯誤一點點補洞。看起來像機械活，實際變成了一個高 Token、高狀態管理成本的任務。
前一段時間看到有人說，AI Coding 時代，拆分模組這些編程原則沒那麼重要了，反正人也不看代碼。現在看，我不太同意。模組邊界清楚、文件粒度合適、依賴關係簡單，不只是方便人讀，也是在幫 Agent 降低任務複雜度。
從另一個角度看，現在 Agent 的讀文件和改文件工具，對這種重構也不太順手。
Coding Agent 改文件，主要還是文本替換。比如 Claude Code 常見的是 old_string / new_string 模式：先給出一段舊文本，再替換成新文本。Codex 常用的是 apply_patch：生成一個類似 git diff 的 patch，表達把舊的內容替換成新的。它們都適合小範圍修改，但如果要刪除一大段舊代碼，或者把一批函數挪到別的文件，模型往往還是要先把原始內容讀進上下文，再生成一大段替換或 diff。
所以我後來給 Agent 一個提示，讓它先用腳本、sed、perl 這類工具把大文件粗拆開，直接把舊內容刪掉，寫到新文件中，然後再逐個慢慢修，它的完成度確實高了許多。Agent 默認不會這樣做，主要是因為系統提示詞裡會強烈要求 Agent 用內置工具修改文件，而不是命令行工具。
再往前想一步，Coding Agent 可能還需要更高級的編輯工具。不是只給它一個“替換文本”的接口，而是先通過 parser、LSP 或 compiler 建立代碼結構，讓 Agent 可以像 IDE 一樣做重構：移動函數，刪除 impl block，整理 imports。不知道是否有朋友做這方面的嘗試。
總的來說，即便是 AI Coding 時代，好的編程習慣還是有價值的。盡量在早期通過 harness engineering，把好的編程習慣變成 Agent 的預設工作方式，比後來再重構的成本要小很多。