这篇文章讨论的是基于量化指标来考核的管理方式。观点来自我与 AI 的多轮辩论，最终由 AI 整理成文。

一、量化对被考核者做了什么

考核经常面对一堆说不清道不明的事。谁在拼命，谁在划水，哪个架构重构是真的非做不可——在没有一套硬性标准之前。最终全看谁跟主管关系好、谁嘴皮子利索，或者看主管今天心情怎么样。

有一种管理方案是：纯拿数字和指标说话。规则摆在桌面上，尽可能把所有工作都量化成一个带有分数的任务单。难的活、时间长的活分数高，出了 Bug 就扣分。怎么说呢，

最浅显的好处和坏处

痛点：管理层难以通过客观数据快速识别真正高价值贡献。只能依赖主观印象，

你能清清楚楚地数出来一个人这个月提了几个需求、改了几个 Bug、每个单子多少分。不过，这些 Jira 上的数字跟代码提交记录对得上，谁也赖不掉。但把这些数字加起来真的就是这个人的全部贡献吗？

并不是。它们只是评分程序刚好能数得清的那一小块。剩下的——

• 顺手帮旁边写前端的兄弟排查了一个卡了两天的死锁问题
• 在设计评审时提了一个质疑，帮团队挡掉了未来的线上事故
• 硬气地拒绝把一个本该整体交付的重构任务拆成三个小单子来凑分

这些在程序里全部归零。不是分低，是根本没有分，

痛点：工程师为了解决关键技术难题而被迫放弃，因为这些工作无法获得可见分值。

量化一无是处吗？并不是，那些数不清的东西里也混着很多浑水摸鱼。怎么说呢，

• 天天扯宏大架构、实际连行代码都写不明白的人；其实，打着“技术探索”旗号混了半年什么也交不出来的方向——量化程序虽然误伤了那些默默排雷的人。但它也一刀切地把混子给清洗掉了。

量化不是不公正。它是用一种程序性的、透明的、规则明确的偏见，替代了你用私人直觉碰运气时那种随机且不可追溯的偏见。前者的受害者至少知道自己被什么伤害了可以讨论和改进； 后者的受害者连被什么伤害都无法指认。

当指标绑定奖惩。调整行为就开始了

经济学里有个古德哈特定律：

痛点：团队成员会刻意“刷分”，导致真正业务价值下降。

在研发团队里尤其快，因为程序员是全公司最擅长分析程序规则和寻找最优方法的人。整个过程分三步：

分数自带万有引力

大家总觉得刷指标是故意的，但很多时候根本不需要有人使坏。考核表自己就带了偏向，说起来，

• A：去改老程序里乱成一团的底层兼容方案 → 掉一层皮，花三天拿 X 分
• B：顺手写一个简单业务 CRUD 接口 → 半小时搞定。也拿 X 分

痛点：P5级别工程师为追求高分而回避长期技术债务修复任务。

这不是道德问题，而是规则把大家往低风险、快出分的活儿上赶。那些真正难啃、对架构有长远好处的硬骨头，就这么被程序性地晾在那里。而主管在报表上根本看不出问题——你看到的是大家热火朝天地领单子、拿分，每个单子都拿到了该拿的分。

二、量化程序的维护成本

程序会膨胀

SOP 痛点：#1 维护人员增加工时以堵住新的博弈漏洞；#2 指标库膨胀到几百条，使得治理成本超过节省的人力资源。

AI 了可量化的边界。但尺子自己在老化

• SOP 痛点：A.I. 评估模型本身是一块黑盒，其偏差比显式规则更难审计；模型漂移导致评分失准却难以发现。老实说，
• A.I. 将可量化对象从“结果”推进到“过程”。但永远无法覆盖全部隐性贡献。
• A.I. 评分与绩效绑定后引发“写出 AI 会给高分代码”的倾向，使代码风格趋同且创新受限。
• A.I. 与传统指标叠加后出现“双输”：代码库健康度提高但可维护性平庸。

A.I 扩张可量化疆域。却未改变量化底层交易：任何量化程序都是设计者瞬时快照，而世界继续移动。其实，#精度≠真相；老实说，更精确的不完整仍是不完整。

让分值追着业务跑，是永远做不完的大事

• 给每类任务定 分，本质 上 是 管理 者 对 “这 类 工作 在 现 阶段 值 多 少 钱 ” 的 判 断 .但 这 个 判 断
• 随 着 商业 场景 、 技术 堆 栈 、 团队 能 力 的 演 化。必 须 持 续 调 整 –
• 否则，打 分 程序 成 为 僵 局，只 能 捕 获 历史 行 为，忽 略 新 兴 战 略