THE JOURNAL / FIELD NOTES
每个人都成了十倍工程师，然后呢？
Zheng Li
几年前，如果有人告诉我，一名工程师很快就能拥有一支随叫随到的虚拟开发团队，我大概会把它当成遥远的未来。现在，这件事已经稀松平常。公司为工程师购买 Copilot、Claude Code 和各种内部 Agent，Token 额度越给越高。代码、Commit、PR、原型都在增加，过去要几周完成的工作，现在几天甚至几个小时就能看到结果。
照这个速度，我们似乎应该迎来一个遍地都是十倍工程师的时代。可我在管理现场感受到的，却不是十倍增长带来的从容，而是越来越强的焦虑。
管理层在问：工具已经给了，为什么业务没有十倍增长？中层在问：大家都用了 AI，为什么人效还是不够高？工程师也很困惑：我明明做得更快，为什么工作没有减少，岗位反而更不安全了？
问题可能不在于 AI 没有提高生产力。它确实提高了。问题在于，我们把“生产得更快”和“创造出更多可以卖掉的价值”当成了同一件事。
软件工程师生产的从来不只是代码
借用马克思剩余价值理论的语言，工程师出售的是一段时间内的劳动力。公司提供电脑、服务器、云资源、开发工具、已有代码库、客户、品牌和销售渠道，工程师用自己的知识、判断和时间，把这些生产资料转化为产品。
在这个框架里，工资是劳动力的价格。劳动创造出来、又没有以工资和其他成本返还给劳动者的部分，构成企业利润的重要来源。当然，现代软件公司的利润远比一座十九世纪工厂复杂。网络效应、知识产权、数据、品牌和市场地位都会放大收益，产品、设计、销售、运维和客服也共同参与了价值创造。不能把一家软件公司的全部利润简单除以工程师人数，再说差额都是某个人被拿走的劳动。
但这个框架仍然帮我们看清一件事：工程师的产出从来不是代码本身。代码只是中间品。真正完成价值实现的，是被用户采用的产品、愿意续费的服务、可以降低事故和维护成本的系统。
写完一个功能和卖掉一个功能，中间隔着很长的路。
Token 是新的生产资料，不是利润
公司购买的模型调用、推理算力和 Token，可以近似看成一种新的生产资料。它们的作用和更好的机器相似：提高人的生产率，让同样的工时完成更多工作，或者让同样的工作由更少的人完成。
资本期待的链条很直接：增加 Token 投入，工程师写得更快，同样的人交付更多功能，单位成本下降，利润随之增长。
这套推理在一家公司率先使用 AI 时可能成立。它用新的工具降低了生产成本，还能按照旧的市场价格出售产品，于是获得一段时间的额外利润。问题在于，AI 没有只卖给这一家公司。
同行在用，创业公司在用，独立开发者在用，原本进不了这个行业的人也在用。再往后，客户甚至可以自己用 Agent 拼出一个够用的替代品。过去“重写太贵”“开发门槛太高”构成的护城河，正在一点点变浅。
每一家企业单独看，都必须采用 AI；所有企业一起采用以后，却不可能都得到十倍利润。
当所有人都变快，快本身就不再值钱
剩余价值理论里有一个很适合解释当下的概念：社会必要劳动时间。一件商品的价值，不由某家公司在它身上花了多少工时决定，而受整个社会在正常生产条件下制造同类商品所需时间的影响。
一家企业率先变快，可以短暂占到便宜。等同行也变快，生产同类软件所需的社会必要劳动时间就降了下来。供给增加，客户选择更多，价格和溢价开始承压。原本属于少数公司的效率优势，很快变成整个行业的基本门槛。
这时，AI 带来的生产力没有消失，只是换了一种归宿。它让市场上出现更多软件、更多功能和更多原型，也让许多功能更便宜。使用价值快速膨胀，单个企业能够占有的交换价值却没有同步增长。
这种落差已经能在研究中看到。METR 在 2025 年对熟悉自己代码库的资深开源开发者做过随机对照实验。使用当时的 AI 工具后，参与者完成任务反而慢了 19%，但他们主观上仍认为自己快了 20%。这项研究只覆盖特定人群和特定时期，不能用来断言 AI 编程普遍无效，却揭示了一个重要问题：我们对“变快”的感觉，未必等于端到端的真实效率。
更大的错位发生在组织里。AI 最先放大的是最容易计数的东西：代码行数、Commit、PR、Ticket、Demo。真正限制价值实现的环节却没有同比例提速：判断该做什么、理解客户、通过采购和合规、完成上线、获得信任、让用户留下来并持续付费。
AI 可以在一分钟内生成十种实现，客户却不会因此多出十倍预算，用户也不会多出十倍注意力。
明明是价值的问题，却向劳动日要答案
当 Token 账单、代码和功能一起增长，收入却没有跟上，组织需要一个解释。承认编码本身正在贬值很困难，因为这意味着“全面拥抱 AI”与“利润自然增长”原来是两回事。
更容易接受的解释是：员工没有真正用好 AI，节省下来的时间被拿走了，中层没有把效率压出来。
于是，AI Adoption 被放进绩效，Token 使用量被做成仪表盘，PR 和 Ticket 被当成人效。原本用来节省劳动的工具，逐渐变成要求更多劳动的理由。今天快一倍，明天目标就加一倍；这次提前完成，下次排期便直接减半。效率红利被立刻填满，团队没有更从容，反而越来越不敢承认自己做得快。
这也是基层管理者最难受的位置。上面看到新增的工具投入，希望得到成倍产出；团队看到裁员风险，希望把一部分效率用于休息、学习和准备未来；市场并没有凭空产生十倍需求。基层管理者无法决定市场价格，也无法决定公司向投资人讲了什么故事，却要负责解释为什么 PR 多了，收入没多；为什么功能交付快了，客户采用没有更快。
如果管理者只会把上面的焦虑翻译成下面的工时，他最终管理的不是生产力，而是失望。
员工也在争夺 AI 的效率红利
AI 节省出来的时间可以流向三个地方：公司拿到更多产出，劳动者拿到更多闲暇，或者劳动者用它学习新工具、提高技能，为下一份工作做准备。
站在公司的角度，它购买了生产资料，自然希望全部效率红利回到公司。站在员工的角度，当公司一边宣传 AI 能替代人，一边要求每个人教会 AI 做自己的工作，把一部分时间用于保护自己的职业未来，同样是理性选择。
公司越强调岗位随时可能消失，员工越不会把命运完全交给公司。有人做完工作后早一点下班，有人学习新的技能，也有人制作作品集。知识劳动和机器生产不同：工人很难把车床带回家，但借助 AI 形成的能力会跟着人走。
这不意味着所有行为都可以用“自保”来辩护。拿客户代码、公司机密或者企业付费额度做私活，有明确的合同和职业风险。结构分析可以解释动机，不能免除责任。
同样需要警惕的是另一种幻觉：把任务做完后隐身，并不等于劳动者已经赢得了新的分配。整个行业的进入门槛下降时，闲暇不会自动变成更高工资。真正影响下一份工作议价的，仍然是那些不容易一键生成的能力：读懂遗产系统、处理生产事故、做安全和合规判断、把模糊需求收敛成可以上线的范围，以及对结果负责。
三方都在做理性的事，然后一起走向内耗
公司想要更高的回报，管理者想让投入可以解释，工程师想证明自己没有被新工具甩下。单独看，每个选择都说得通。问题是，当编码速度突然变快，我们最先拿到的仍然是提交数、PR 数、交付周期这些活动数据。它们清楚、及时、容易比较，于是自然进入汇报，接着进入目标，最后悄悄变成了价值本身。
这时内耗就开始了。上面看到产出曲线往上走，会追问为什么业务结果没有同步增长；下面发现做得越快，队列里只会塞进更多需求，于是努力证明自己的工作量；夹在中间的人明知 PR 不能回答商业问题，却又拿不到更好的证据，只好继续打磨那张最容易获得的图。
我就在这个位置上。最难受的不是压力大，而是你清楚大家都没在撒谎，拼起来却是一幅失真的图。
这不是哪一方缺少常识，而是价值链上的控制权、信息权和责任没有对齐。
没有人真正拥有整条价值链
代码变成业务价值，中间隔着很长一段路。功能要被发布，用户要看见、愿意尝试、持续使用，产品还要有合适的定价、销售和服务方式。可靠性、合规、市场窗口，甚至别的团队是否配合，都会改变最后的结果。AI 能明显压缩“把想法写成代码”的一段，却不会自动打通后面的环节。
可我们常把链条一头的提速，当成整条链条的增值。工程师可以把功能按时交付，却未必有权决定该做哪个问题、何时推向市场，也看不到完整的采用和收入数据。让他直接为收入负责，听起来比统计 PR 更先进，实际上可能同样粗暴。
反过来，高层要求“关注商业结果”，也不等于已经完成了管理。商业目标与一线工作之间没有天然通路。有人必须讲清楚：我们相信哪一种用户行为会改变，什么产品能力可能带来这种改变，工程上要交付什么，质量至少达到什么程度，又准备根据什么证据判断原来的设想是否成立。若这段路没有人走，“结果导向”就只剩下一句态度正确的话。到了执行层，大家还是只能抓住手边最清楚的数字。
基层管理者被卡在这条断裂的链条中间。手边最完整的是研发过程数据，需要解释的却是跨越多个职能的结果。如果一个人无权选择问题，无法调动后续环节，也拿不到结果信息，却要为最终结果负责，这不是担当，而是责任越过了控制边界。掌握取舍权的人如果只要求下面提高活动量，却不承担方向选择的后果，组织也会得到同样荒唐的激励：每个人都在优化自己能被看见的那一小段，没有人真正拥有整条链。
指标不是答案，而是对因果关系的猜测
所以，仅仅把评价从 PR 换成采用、留存、付费和可靠性，并不能解决问题。换一组更接近价值的名词，不会凭空补上权限、数据和责任。
指标应该呈现的是一条可以讨论、可以验证，也允许被推翻的假设链：我们投入了什么，希望改变什么行为；这些行为会产生什么输出；输出需要达到什么质量；在什么条件下，它才可能影响用户和业务。每一段都可能断，也需要不同的人提供证据。
多消耗 Token，只能说明生产资料被使用了。PR 增加，说明代码流动得更快。交付周期缩短，说明某些等待被压缩。再往后，还要看变更是否真正上线、是否被采用、是否增加维护负担、是否改善可靠性，最后才可能谈到收入、留存或成本。
这里没有一条必然成立的直线。更多代码可能带来更多功能，也可能只带来更多库存；更快上线可能抢到窗口，也可能更快制造事故。过程指标不是没有用。它们可以告诉我们评审是否堵塞、返工是否增加、工具是否真正被采用。它们适合诊断工作系统，却不能冒充价值。一旦过程数字进入绩效和排名，团队很快就会学会优化数字本身：代码拆得更碎，Ticket 开得更多，Token 尽量用满。报表越来越漂亮，组织却未必更接近客户。
真正的共同负责，也不是最后一起领功或挨骂。它应该发生在写第一行代码以前：我们赌的是什么，谁能改变哪一环，出现什么信号时继续，什么信号出现时停下。工程师应当对技术判断、交付质量和风险暴露负责，但不能独自背负整条商业链；做产品和商业决策的人不能只交付一个收入目标，还要为问题选择、采用路径和优先级负责；组织则要提供跨越职能的数据和协作条件。最终结果属于共同完成它的人，却不能假装可以被精确切开，再平均压到每一个人身上。
允许证据不完整，但不允许责任含糊
现实里很难做到干净归因。一次留存改善，可能来自新功能，也可能来自价格变化、市场季节或销售策略；一个季度的收入，更不可能准确拆给某几个 PR。承认这一点，不等于放弃衡量。它只是要求我们少一点假装精确，多一点对判断边界的诚实。
我们可以看上线前后的变化，可以做小范围试验，可以听客户如何描述，也可以追踪一组方向一致但各有噪声的信号。证据永远会有缺口，决策仍然要做。需要说清楚的是：这次判断基于什么，我们还不知道什么，谁有权在不确定中下注，又由谁承担取舍带来的后果。
对基层管理者来说，这比交一张报表困难得多。我既不能只递上一条漂亮的产出曲线，也不能把遥远的收入目标原封不动地压给工程师。更有用的工作，是把价值链摊开，指出已经验证到哪一步、断点在哪里。要继续验证，缺的究竟是工程能力、跨职能配合、可信的数据，还是一个有权说“不做”的决定。
这种回答不整齐，有时甚至显得不够振奋。但至少它不会用确定的过程数字，掩盖并不确定的业务判断；也不会把组织尚未回答的问题，改写成员工尚未完成的任务。
十倍之后，我们究竟想放大什么
所谓“十倍工程师”，如果只是让一个人制造十倍的代码和变更，很可能也只是让组织更快撞上原本就存在的瓶颈。需求选错了，十倍速度会让错误扩散得更快；价值链断了，更多产出只会堆在断点前面；责任与权力错位，效率越高，互相证明和互相追责也会越猛烈。
AI 的确在放大人的执行能力。但人的价值从来不只在于敲出多少代码，还在于发现哪个问题值得解决，看见局部优化会伤害什么，并在证据不完整时和别人一起作出取舍。机器越擅长执行，这些能力就越不该被藏在“工程效率”四个字后面。
我真正关心的，不是哪一位工程师已经变成了十倍，而是当一个人的执行能力被放大十倍之后，我们有没有同时给他理解价值链的信息、影响取舍的权力，以及与别人共同承担结果的关系。
如果没有，我们放大的究竟是人的价值，还是一套系统性内耗的速度？
参考：