幾個月沒手寫一行代碼，我怎麼衡量自己的產出
我已經幾個月沒有手寫過一行代碼了。
不是誇張。所有代碼都由 AI 生成——幾個不同的編碼 agent 輪流上，用的是同一個 git 身份提交。我做的事情是拆任務、寫任務説明、看結果、判斷對錯、決定合不合。
這帶來一個很實際的問題：我怎麼知道自己這一天、這一週幹得好不好？
一、舊尺子全部失真
先説哪些尺子不能用了：
- 提交數。 我的提交裏大約四分之三是機器自動產生的：自動修復、生成文件、翻譯、定時任務。報提交數，對內對外都顯得注水。
- 代碼行數。 AI 可以一次生成兩千行，也可以一次刪掉兩千行。行數和價值沒有穩定關係。
- git 作者。 所有 agent 都用我的身份提交，作者字段區分不出「誰寫的」。
- 忙不忙。 我可以一整天都在和 agent 對話，最後什麼都沒合進去。
這些尺子以前大致能用，是因為「寫」本身是昂貴的，寫了多少和做了多少大體相關。現在「寫」接近零成本，這層相關性就斷了。
二、新尺子：只看交付物
我現在只看交付物：
- 上線了哪些頁面、功能；
- 修掉了哪些線上問題，有沒有數據證明它真的修好了；
- 合併了哪些 PR，它們解決了什麼；
- 寫下了哪些規則、skill、工具，讓以後的工作更快或更穩。
彙報的口徑也跟着改：寫「編排 AI 產出了 X」，不寫「我寫了 X」。 這不是謙虛，是準確。
日報也因此變短了：全文不超過 200 字，只列 3 到 5 件事，用業務語言説「解決了什麼」，不列提交、不寫明日計劃。如果 200 字裝不下，説明我在羅列過程，而不是在説結果。
三、只問流向，不問辛苦
我給自己定了一條規矩：判斷一天好壞，只問產出流向了哪裏，不問有多累。
一整天都在處理雜事、回答問題、救火，累得很，但沒有一件推動最重要的事往前走——這一天就是沒打分。反過來，只做了一件事，但那件事是今天最重要也最難的，它就是好的一天。
所以每天早上我只挑一件「最重要也最難的事」先做，其餘排在後面。累不是證據，流向才是。
四、真正的瓶頸在「驗、收、推、合」
幾個月下來，最讓我意外的一個發現：瓶頸不在寫，在後面。
有一段時間，本地沒推送的提交從一百多漲到三百多，又漲到四百多。不是因為我懶，而是 AI 把「寫」壓到了接近零成本，但「驗證、收活、推送、合併、上線」一點沒有變便宜，全部堵在我這一環。
這改變了我對產出的理解：寫出來不算，合進去、上線、被驗證有效才算。 所以我現在：
- 給並行設收斂線，做完一批先合、先刪，再開下一批；
- 本地 CI 通過就開 PR，不讓完成的工作停在本地；
- 用定時任務和自動化把能交出去的驗證交出去，把人的注意力留給判斷。
五、我的能力到底是什麼
如果不寫代碼，我的能力體現在哪？我現在的回答是三件事：
編排。 把一個模糊的需求拆成 agent 能獨立完成的任務，劃清它們之間的邊界，知道什麼時候並行、什麼時候不該並行。
評審。 判斷 agent 交回來的東西是不是真的對。這比寫難：它的報告永遠是「全部通過」，而我要知道「全綠」什麼時候不構成證據。
方法論。 把每次糾正、每次事故寫成規則、skill 或自動化，讓同樣的錯誤不犯第二次。這一部分會複利。
這三件事，都不體現在提交數里。
六、它逼我承認的幾件事
這套尺子也有不舒服的地方：
- 不寫代碼，不代表可以不懂代碼。 評審需要讀得懂；出了事，需要知道該問什麼。我的短板（比如 git）沒有消失，只是換了一種方式去補。
- 產出少的日子會更明顯。 以前「寫了一天代碼」本身就像一種產出，現在沒有這層遮擋了。
- 衡量要誠實。 機器產生的東西不能算成自己的工作量，但組織機器把它做出來，是我的工作。
收束
當「寫」不再是瓶頸，衡量產出的尺子就要從「寫了多少」換成「交付了什麼」。
只看交付物，只問流向，把驗、收、推、合當成真正的瓶頸，把能力放在編排、評審和方法論上。 這套尺子不會讓我看起來更忙，但會讓我更清楚自己到底做成了什麼。