猎鬼：如何看清开发者的真实贡献

“幽灵工程师”——每十名开发者中，就有一人几乎不做任何有价值的工作，只是把“很忙”演得像模像样。无论真实原因是同时打多份工、职业倦怠，还是单纯摸鱼，都可能长期瞒过管理层。(2024 年斯坦福研究：原始帖文)

开发者不喜欢别人谈论自己的绩效。这个职业经历了漫长的“黄金时代”后，行业里渐渐形成了一种忌讳：开发产出是否配得上投入的时间和金钱？这个简单的问题反而很难问出口。不过，开发者自己同样厌烦幽灵工程师，而且通常最早发现问题的不是管理层，而是团队。

在俄罗斯，人们历来很反感“打小报告”。所以，即使很多人都知道有问题，也没人愿意开口：何必卷进别人的麻烦？事情往往要等到所有人的耐心都耗尽，才会彻底暴露。

要不就随这些幽灵去吧。反正公司也不差这点钱，不是吗？

可问题恰恰就在这里……

我所说的低绩效，并不是 Alex 埋头苦干，却比 Ben 少完成 10% 的工作。我要说的是另一种情况：每次站会，全队都要听一遍最新的苦情故事——别的团队拖了后腿、工单写得不清楚、运气也不站在他这边。不过明天一定能做完，保证。

只是这个“明天”，昨天说过，前天也说过，如今已经成了固定节目。

团队很快就能察觉这种事。真正扛着工作的人自然会想：既然编几个故事也不用承担后果，我为什么还要把自己累垮？

但发现问题还不够。手里没有数字和事实，对话很快就会变成争吵：团队说“他没有产出”，开发者回应“他们根本不让我好好工作”。通常要等到大家彻底失去耐心、团队要求主管换人，才有人开始认真调查。

接下来便是一场漫长的拉锯：收集事实、听双方陈述、给出反馈，再留出时间观察是否改善。按我的经验，最常见的结局是，幽灵转投下一位——非常“幸运”的——雇主。

问题不只是某个人干得少。公司要付两次钱：先为没有完成的工作买单，再为同事和主管反复检查、填补缺口、追查原因所花的时间买单。到最后，低绩效的已经不只是一个开发者，而是整个团队。

主管能不能更早发现问题——先看到异常，再了解背景，在团队忍无可忍、公司损失时间和金钱之前就着手调查？

经验足够丰富时，往往可以从几种典型的行为模式提前识别这种情况：

• 所有成功都是我的功劳，所有失败都是你的责任。
• 任务还没开始，就已经准备好了失败的借口。
• 能力不足，却试图用滔滔不绝来补偿。
• 时间越久，主管越容易被塑造成那个“罪魁祸首”。
• 与真正遇到困难的人不同，即使收到直接反馈，这种行为也不会改善。

但怀疑还需要数字足迹来佐证。

下面看看衡量研发绩效最常用的工具，以及它们能否帮我们找出幽灵。

比较之前，我必须先说明一个显而易见的利益冲突：你正在阅读 DevGhost 官方博客，而我是这个产品的创始人。这是作者的观点，不是独立研究。

如果要评估的是软件研发本身，而不是整个业务或产品，我会采用一个简单的三角框架：速度、质量和工作量。DORA 指标告诉我们速度，测试和缺陷告诉我们质量。最难的是工作量。这片领域探索得最少，也正是我们要找的幽灵最容易藏身的地方。

DORA：速度与发布可靠性

DORA 展示一个团队能以多快的速度、多高的可靠性把变更送进生产环境。当前模型包含五项指标：从提交到生产的时间、部署频率、引发故障的部署比例、恢复时间，以及计划外返工所占的比例。

它很适合衡量交付流程，却无法衡量个人贡献。如果一个人干了三个人的活，另一个人躲在团队总体成绩背后，DORA 不会告诉你。

这些指标拿来做 KPI 也格外方便。我曾工作过的一家公司从 2018 年就开始充分“利用”它们，成功把每块仪表盘都刷成绿色，所有人也都皆大欢喜。当前的 DORA 模型。

测试与缺陷：工作做得有多好

这些方法早已成熟，也确实能在实践中发挥作用。代码评审、测试和静态分析负责控制质量，缺陷和事故则用来追踪后果。

但这些信号无法说明工作量。一处很小却无可挑剔的修复，就能让所有指标变绿，而幽灵依旧藏在暗处。

Jira 与故事点：关闭了多少工单

Jira 能显示已关闭的工单和故事点，但估算本身来自团队。同一项工作可以估成 3 点，也可以估成 13 点；可以拆成 5 个工单，也可以全塞进 1 个。

故事点对规划很有用，用来衡量个人贡献却不可靠。一旦点数成了目标，人们就会开始优化点数，而不是优化工作。

它同样很适合做 KPI。为了通过质量门禁而录入数据、来回移动工单，最后制造出大量毫无意义的手工劳动。

提交与代码行数：没有上下文的事实

Git 不依赖团队估算，所以人们很自然地想数提交、数代码行。但 5 次提交可能只是一个小修复，一次 squash 提交也可能包含整整一周的工作。

格式化、生成代码、复制和移动代码都会把行数吹大，而一次困难的修复也许只有 10 行。

Swarmia、LinearB 与 Waydev：把整个研发系统放在一处

Swarmia、LinearB 和 Waydev 把 Git、任务跟踪系统与 CI/CD 汇总起来。管理者可以看到 DORA 指标、评审队列、变更前置时间和调查结果。

它们能勾勒出一幅有价值的研发系统全景，也常常揭示问题出在流程，而不是某个人身上。但如何用同一把尺子比较单个开发者的工作量，并不是这些平台试图回答的核心问题。Swarmia、LinearB、Waydev。

GitClear：去掉代码噪声后还剩什么

GitClear 会区分新增、移动和复制的代码，排除生成文件，还会考虑新代码后来是否被重写或删除。

由此得到 Diff Delta——GitClear 自己定义的一种单位，用来表示最终留在代码库里的实质性变更。复制来的代码或很快被丢弃的代码，权重低于一处紧凑且持续在生产环境中运行的改动。Diff Delta 的原理。

Diff Delta 回答的不是“完成这些工作需要多少投入”，而是“经过噪声和返工后，还留下多少有意义的改变”。GitClear 的强项是衡量代码的持久性与质量，并分析 AI 带来的影响。

这已经更接近了。服务会公布基准，但 Diff Delta 仍是一套自有单位：如果没有合适的对照和对方法的了解，10,000 这个数字本身说明不了多少。它没有“100% 就是正常水平”这样清晰的锚点。Diff Delta 基准。

BlueOptima：在企业规模上回答同一个问题

我对 BlueOptima 并不陌生。2019 年我就开始使用这个平台，也正是这段经历启发我做了自己的产品。

Coding Effort 算法会用一组静态指标分析每一处源代码变更，考虑变更的规模、复杂度，以及它与其余代码的关联，最后把结果表示为小时数。

这样一来，就能跨团队、跨技术栈比较开发者，也能与全球基准比较。对我来说，这是第一次有一种方法真正试图回答的不是“这个开发者写了多少行代码”，而是“这些变更背后有多少实质性工作”。BlueOptima 方法论、全球基准。

以我的经历来看，要获得这些企业级能力，实施过程相当沉重：必须在封闭网络环境中部署代理，价格很高，结果也需要专家解读。

对于拥有数千名开发者的公司，这也许值得。对于创业公司或小团队，恐怕很难。后来，正是这个落差成为 DevGhost 诞生的原因之一。

同一把尺子，不必走招标流程

做 DevGhost 时，我并不是想再造一个塞满所有研发指标的“大而全”平台。

我想提供与 BlueOptima 相同的答案——变更背后到底有多少实质性工作——但让创业公司老板或小团队不用招标、不用经历漫长实施，也不用请一队顾问就能获得它。

思路很直接：DevGhost 分析变更本身——增加了什么、删除了什么、重构了什么，以及创建并验证结果有多困难。格式化、代码移动、批量自动替换和生成代码会与实质性工作分开计算。

结果是一项用“等效工时”表示的工作量估算：一名熟悉代码库、且不使用 AI 的中级开发者，写出同样的代码需要多长时间。它不是实际敲键盘的时长，也不是对代码质量或业务价值的评价，而是一把用来比较不同变更的共同标尺。进一步了解 DevGhost 方法论。

Ghost% 会把这项估算与中级开发者的预期产出比较，同时考虑本人实际用于开发的时间比例。100% 表示符合正常水平；低于它，值得调查原因；高于它，则值得研究，并可能沉淀为最佳实践。

这项基准有意假设开发者不使用 AI。DevGhost 不试图区分某段代码究竟出自人、Copilot 还是自主智能体。它评估的是最终变更：如果没有 AI，一名中级开发者创建并验证这些变更需要多少投入。

因此，AI 的效果不会被埋在指标里，反而会显现出来。如果某个时期，一名开发者创建并验证的成果按过去的方式需要两三倍的投入，Ghost% 会反映这种差异。格式化、批量生成和其他代码噪声不应产生同样的效果。

谁来评判评判者？

最直接的问题是：凭什么相信机器生成的估算？简短的答案是：不应该盲信。

评估工作难度本来就是主观的。我们做过测试：让多位经验丰富的开发者估算同一批变更，得到的数字差异明显。每个人的速度、经验和对难度的理解都不同。

DevGhost 也会出错。它的优势不在于掌握某种绝对真理，而在于用同一把尺子评估所有变更——没有偏爱，没有疲劳，也不会预先对作者形成看法。

所以 Ghost% 是信号，不是判决。低结果可能意味着贡献不足，也可能是因为承担团队负责人职责、架构工作、指导新人、处理事故，或受到阻碍。

数字告诉你该在哪里提出问题。答案仍要由管理者寻找，但现在除了直觉，他们还有一个独立的第二意见。

“我本来就知道团队里每个人干得怎么样”

DevGhost 的一位客户是一家高速成长的 AI 公司的技术负责人。起初，他对衡量研发绩效这个想法本身很怀疑。他的观点很简单：好的技术负责人不看仪表盘，也知道每个人干得怎么样。

我们分析了一个他非常熟悉的代码库。此前，他们已经对三名开发者有所怀疑：工单推进得很慢，但三人负责一个独立服务，所以很难与团队其他人比较。DevGhost 显示，三人在大约半年里都持续处于低位。

后来，随着这些开发者陆续离职，大家才发现他们在那段时间里一直同时开发自己的产品。DevGhost 不可能知道原因。它只是揭示了提交数、拉取请求和 Slack 日常交流都没有呈现出来的事实：他们的工作量明显低于预期。

但分析并没有变成一份解雇名单。对于另外两名开发者，低结果帮助主管给出了具体反馈、查明原因并改善绩效。两人都留在了团队里。

他认为优秀的开发者，也恰好出现在他预期的位置。而且现在不仅能看出谁在超额产出，还能看出这种表现有多稳定。

当然，一个案例不能证明方法准确。真正让客户惊讶的是，整体图景与过去只能凭感觉知道的情况高度吻合——有些事情甚至要事后回看才会变得明显。

如果一名开发者能交付三个人的成果呢？

猎鬼是这个故事里最吸引眼球的部分，但图表的上半区也许更有价值。

如果一名开发者持续交付平均水平数倍的成果，就值得弄清楚他究竟是怎么做到的。

今天的问题已经不是开发者是否使用 AI——对很多人来说，AI 已经是日常工作的一部分。真正的问题是，他能多有效地把智能体转化为额外的交付能力。

有人只用自动补全；也有人懂得给智能体提供上下文、制定清晰规则、并行推进多个任务，并仔细审查结果。因此，即使拥有相同的 AI 工具，生产力提升也会相差悬殊。

高 Ghost% 能帮我们找到那些已经把“人 + 智能体”配合得很好的开发者，并了解哪些做法可以推广给团队其他人。

如果高结果也得到工作质量和主管评价的支持，就应该重视并留住这位开发者，把他纳入晋升考虑；同时研究他的做法，并在团队中推广。

别把尺子变成棍子

所有指标都有同样的命运：迟早会有人想把它变成 KPI。Ghost% 不适合这样用。

把 Ghost% 设成团队 KPI，人们就会围绕指标优化工作；公开排行榜，信任就会消失；把分数变成解雇按钮，错误就不可避免。

我会定下四条规则：

• 不要根据一次测量或很短的周期下结论。
• 考虑一个人的角色、真正用于开发的时间比例，以及代码之外的工作。
• 把结果给开发者看，并让他有机会解释背景。
• 不要把 Ghost% 作为人事决定的唯一依据。

如果低结果持续存在，主管应该先查明原因。也许这个人确实难以胜任；也许他在做架构工作、替别人处理事故，或者被团队流程卡住了。

如果问题得到确认，就应该制定具体的改进计划，并在约定的期限后再次评估。

拒绝指标，并不会让对人的评价消失。它只会把判断留给直觉、站会上讲的故事，以及主管个人的偏好。

速度、质量和工作量需要不同的工具。DORA 展示变更如何进入生产环境，测试与缺陷展示质量，DevGhost 则补上对代码变更背后工作量的估算。

这些指标都不应该替管理者做决定。

数字的价值不在于宣判，而在于让困难的对话更早开始，并且建立在事实之上。

你会如何评估开发者的工作量？在你看来，有益的透明度与监控之间，界线应该画在哪里？