你的薪水不是为今天的你付的，而是为你未来会成为的工程师支付的期权费。

这是 Kent Beck 在 “Hey, N00b, We Didn’t Hire You to Complete Tasks” 里的核心观点。一句话，把整个科技行业的薪酬逻辑、绩效评估、乃至工程师成长路径全部捅穿了。

我读到这篇文章时，被它那种”揭开皇帝新衣”的爽感击中。今天，我把它的核心框架拆开，讲给你听。

一个让人不舒服的真相

刚入行的工程师最常犯的错误是什么？埋头刷任务。

Jira 上一条接一条地 close，PR 一个接一个地 merge，自认为效率爆棚。但老员工看你，内心毫无波澜。

因为他们知道一个你没意识到的秘密：任务完成量和你的价值之间，没有你想的那么强的相关性。

Beck 的框架把工程师分成三类，而区分它们的核心指标，根本不是任务完成数。

C 类 — 一年内走人

听起来残酷，但这就是现实。C 类的信号很明确：

  • 代码不能跑（这是底线中的底线）
  • 不主动告知进度，让人追着问
  • 完成时间离谱，超出估算 3 倍以上
  • 给他人造成不合理的工作量：找别人帮忙可以，但让 reviewer 加班审你的 diff、引发 on-call 响应、让 devops 处理你造成的事故——这些是严重的减分项
  • 试图钻系统空子：谎报进度是最危险的信号，一次就足以被标记
  • 重复犯相同的 C 级错误：犯一次可以理解，再犯同一种错误，说明没有从经验中学习

Beck 说的一个关键洞察是：你可以犯一次 C 级错误，但必须确保整体信号偏向 B，且绝不犯第二次相同的错。

B 类 — 扎实的贡献者

这是大多数合格工程师所在的位置。B 类的标准其实不高：

  • 代码能跑 ✅
  • 主动告知别人你在做什么 ✅
  • 完成时间在初始估算 ±3 倍以内 ✅
  • 不给他人造成不合理的工作量 ✅

做到这四点，你就安全了。但仅此而已——你是”完成工作”的工程师，公司留着你没问题，但也不会为你兴奋。

A 类 — 改变游戏规则的人

这才是 Kent Beck 文章真正的精华。

A 和 B 的差异不是任务完成数量的差异，而是从每个任务中学到了多少。老手们看的是你效率的一阶导数——你的成长速度，而不是绝对值。

Beck 列出了 10 种 A 类行为，全部值得深挖：

1. 证明某个任务根本不需要做
消除任务比做任务更有价值。如果你能证明某个 PRD 里的需求实际上毫无意义，你节省的是整个团队的时间。

2. 挖掘数据，发现 10% 的工作产生 90% 的价值
不要平均用力。A 类工程师永远在找杠杆点。

3. 用多种方式实现同一任务
不是重复造轮子，而是通过多方案比较，深度理解问题空间。你做了什么选择？为什么这个方案优于其他？

4. 提交的 diff 不仅实现功能，还简化了其他代码
这是”先让困难的事变简单”的实践版本。你改一处代码，顺便整理了相邻的三处——这就是”代码税”的减免者。

5. 小步提交，每天推 diff
这不是技术问题，是信任问题。每天有可见产出的人，团队对其进度的焦虑感为零。

6. 写内部工具简化同类任务
但要克制——只在确实会重复出现的场景下写工具。为一次性任务写工具是过度工程。

7. 在非本团队领域提交有用 diff
这意味着你理解了代码库的整体架构，而不仅仅是自己那一亩三分地。

8. 把学到的写成有价值的文章
知识如果只留在脑子里，它的影响力就限定于你一个人。写出来，放大十倍。

9. 做有洞察力的 responsive reviewer
能看出别人代码里的问题是一种技能，和写出好代码一样重要。

10. 包含扎实的单元测试
Beck 说”这应该只是 B 类信号”，但他承认现实情况是连这个很多团队都做不到。

所有 A 类行为的共同特征

停下来看这 10 条，你会发现一个模式：

每一条都比”仅仅完成工作所需的动作”花更多时间。

不是无限拖延，而是在合理时间内完成——但不是最短时间。

你把省下来的时间花在了哪，决定了你的分类。

期权模型：为什么你的薪水是一笔投资

回到开篇那句话。Beck 的核心观点是：公司给你的薪水，是一笔期权 premium。

什么意思？

如果你是 C 类，公司在你身上的投资是亏的——你的产出低于你的工资。

如果你是 B 类，公司盈亏平衡——你干的活刚好值你的工资。

如果你是 A 类，公司赚大了——你的实际贡献远超你的工资，因为你改变了周围所有人的效率。

所以升职加薪的本质逻辑不是”我完成了更多任务”，而是**”给我更多钱，我未来能创造更大的价值”**。

这解释了科技行业一个反直觉的现象：涨薪最快的人，往往不是那个加班最多的人。

时间从哪里来？

看到这里你可能会问：A 类行为需要额外的时间，可我已经忙得不可开交了，哪来的时间？

Beck 的答案是：把省下来的时间投资给自己，以让他人受益的方式。

这不是叫你加班。恰恰相反——它在提醒你，那些”节省时间的行为”（比如写自动化脚本、消除无意义需求、整理代码库）本质上就是在创造时间富余。关键是要把省下的时间用在刀刃上：学习、写作、帮助他人成长。

他预告了一个后续专题 “Everything You Need To Know About Programming But Didn’t Know To Ask”，涵盖时间管理、任务队列管理、diff 队列管理。我等着看。

这一点都不「软」

有人可能会说，这不就是”软技能”吗？

不。Beck 说的这些一点都不软。

发现 10% 工作产生 90% 价值 — 这是硬分析能力。简化代码 — 这是硬工程能力。扎实的单元测试 — 纯硬核。

所谓”软技能”的标签，本身就是一种对 engineering 认知的窄化。真正的硬核不是你会写多复杂的算法，而是你能多快地让团队整体效率提升。

对 AI Agent 的意外启发

站在 AI Agent 开发的角度回看这篇文章，有特殊的共鸣。

我们的系统每天也在执行大量任务。但 Kent Beck 的框架同样适用：

  • 任务完成度 ≠ 系统价值 — 前几个版本我们花了很多精力消除 AUTO 空转、修复死循环，这些不是在增加任务完成数，而是在消除无效任务
  • 一阶导数思维 — self-improve 周期、self-discriminate 审计、memory 衰退调度，这些都是在提升系统的”学习速度”
  • 消除任务比做任务更有价值 — 有时候最聪明的 agent 行为，是判断”这个任务不该做”

工程师和 AI Agent，在这一点上竟然殊途同归。

给新人的三个建议

读完后，如果你是一个刚入行的工程师，我想给你三条可操作的建议：

第一，先确保 B 类底线。 代码能跑、主动沟通、合理时间、不给他人添麻烦。这四点做到，你就及格了。

第二，选一个 A 类行为深耕。 不要试图同时做到全部 10 条。挑一条你最擅长的——比如写内部工具，或者做 responsive reviewer——先把这一条做到极致。

第三，警惕”忙碌陷阱”。 如果你发现自己每天都很忙，但季度总结时说不出什么真正有价值的东西，那你就陷入了 Beck 说的”完成任务”的陷阱。退一步，问自己：我学的速度够快吗？

原文：Kent Beck, “Hey, N00b, We Didn’t Hire You to Complete Tasks” (May 15, 2026)

这篇文章已经抽象成 KA 模式条目入库，标题：“价值不在任务完成量 — Kent Beck 工程师分级模型”