几个月没手写一行代码，我怎么衡量自己的产出
我已经几个月没有手写过一行代码了。
不是夸张。所有代码都由 AI 生成——几个不同的编码 agent 轮流上，用的是同一个 git 身份提交。我做的事情是拆任务、写任务说明、看结果、判断对错、决定合不合。
这带来一个很实际的问题：我怎么知道自己这一天、这一周干得好不好？
一、旧尺子全部失真
先说哪些尺子不能用了：
- 提交数。 我的提交里大约四分之三是机器自动产生的：自动修复、生成文件、翻译、定时任务。报提交数，对内对外都显得注水。
- 代码行数。 AI 可以一次生成两千行，也可以一次删掉两千行。行数和价值没有稳定关系。
- git 作者。 所有 agent 都用我的身份提交，作者字段区分不出「谁写的」。
- 忙不忙。 我可以一整天都在和 agent 对话，最后什么都没合进去。
这些尺子以前大致能用，是因为「写」本身是昂贵的，写了多少和做了多少大体相关。现在「写」接近零成本，这层相关性就断了。
二、新尺子：只看交付物
我现在只看交付物：
- 上线了哪些页面、功能；
- 修掉了哪些线上问题，有没有数据证明它真的修好了；
- 合并了哪些 PR，它们解决了什么；
- 写下了哪些规则、skill、工具，让以后的工作更快或更稳。
汇报的口径也跟着改：写「编排 AI 产出了 X」，不写「我写了 X」。 这不是谦虚，是准确。
日报也因此变短了：全文不超过 200 字，只列 3 到 5 件事，用业务语言说「解决了什么」，不列提交、不写明日计划。如果 200 字装不下，说明我在罗列过程，而不是在说结果。
三、只问流向，不问辛苦
我给自己定了一条规矩：判断一天好坏，只问产出流向了哪里，不问有多累。
一整天都在处理杂事、回答问题、救火，累得很，但没有一件推动最重要的事往前走——这一天就是没打分。反过来，只做了一件事，但那件事是今天最重要也最难的，它就是好的一天。
所以每天早上我只挑一件「最重要也最难的事」先做，其余排在后面。累不是证据，流向才是。
四、真正的瓶颈在「验、收、推、合」
几个月下来，最让我意外的一个发现：瓶颈不在写，在后面。
有一段时间，本地没推送的提交从一百多涨到三百多，又涨到四百多。不是因为我懒，而是 AI 把「写」压到了接近零成本，但「验证、收活、推送、合并、上线」一点没有变便宜，全部堵在我这一环。
这改变了我对产出的理解：写出来不算，合进去、上线、被验证有效才算。 所以我现在：
- 给并行设收敛线，做完一批先合、先删，再开下一批；
- 本地 CI 通过就开 PR，不让完成的工作停在本地；
- 用定时任务和自动化把能交出去的验证交出去，把人的注意力留给判断。
五、我的能力到底是什么
如果不写代码，我的能力体现在哪？我现在的回答是三件事：
编排。 把一个模糊的需求拆成 agent 能独立完成的任务，划清它们之间的边界，知道什么时候并行、什么时候不该并行。
评审。 判断 agent 交回来的东西是不是真的对。这比写难：它的报告永远是「全部通过」，而我要知道「全绿」什么时候不构成证据。
方法论。 把每次纠正、每次事故写成规则、skill 或自动化，让同样的错误不犯第二次。这一部分会复利。
这三件事，都不体现在提交数里。
六、它逼我承认的几件事
这套尺子也有不舒服的地方：
- 不写代码，不代表可以不懂代码。 评审需要读得懂；出了事，需要知道该问什么。我的短板（比如 git）没有消失，只是换了一种方式去补。
- 产出少的日子会更明显。 以前「写了一天代码」本身就像一种产出，现在没有这层遮挡了。
- 衡量要诚实。 机器产生的东西不能算成自己的工作量，但组织机器把它做出来，是我的工作。
收束
当「写」不再是瓶颈，衡量产出的尺子就要从「写了多少」换成「交付了什么」。
只看交付物，只问流向，把验、收、推、合当成真正的瓶颈，把能力放在编排、评审和方法论上。 这套尺子不会让我看起来更忙，但会让我更清楚自己到底做成了什么。