> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/08-metrics/role-capability-efficiency.md).

# 人效评估：角色、能力与效率的推导框架

大多数团队在评估人效时犯同一个错误：用单一标准衡量所有人。结果是数字看起来整齐，但测的不是真正重要的东西。

***

## 问题出在哪里

人效、能力、角色是三个不同层次的概念，但常被混为一谈：

* **用执行量衡量决策者** — 决策者为了"看起来忙"而忙，真正需要判断的地方反而没时间想
* **用同一标准衡量不同能力水平的人** — 高能力的人被低估，低能力的人被压垮
* **人效目标脱离角色定义** — 数字达标，但产出的东西没有价值

根本原因是：这三个维度之间有层级关系，必须按顺序推导，不能倒过来。

***

## 三个维度的层级关系

**角色**定义"应该产出什么"。不同角色的输出类型根本不同：

| 角色类型 | 核心输出          |
| ---- | ------------- |
| 执行者  | 完成任务的数量与质量    |
| 协作者  | 对团队产出的推进和解除阻塞 |
| 决策者  | 判断的质量和方向的正确性  |
| 管理者  | 团队整体效能的变化趋势   |

**能力**定义"能做到什么程度"。同一个角色，初级和高级的天花板不同，期望效率自然不同。能力不只是技能熟练度，还包括：

* 对问题的判断速度（遇到新情况需要多少时间定位）
* 对边界的感知（知道什么时候该快、什么时候该慢）
* 对 AI 的放大能力（能否用 AI 扩展自己的实际输出）

**人效**是结果，不是输入。它是角色和能力共同决定的函数，不能脱离前两者单独设定目标。

***

## 推导框架

按以下顺序推导，而不是直接设定人效数字：

**第一步：定义角色的核心输出**

这个角色存在的价值是什么？产出是质量型（判断对不对）、数量型（做了多少）还是杠杆型（放大了多少其他人的效能）？

**第二步：根据能力水平设定基准和天花板**

* 基准：这个能力水平下，稳定能达到的最低预期
* 天花板：这个能力水平下，发挥充分时能达到的上限

两者之间的区间才是合理的效率目标范围。

**第三步：在区间内设定当前目标**

考虑上下文因素：当前项目复杂度、团队状态、工具成熟度。目标应该在基准之上、天花板之内，而不是拍脑袋定一个数字。

***

## AI 改变了什么

引入 AI 之后，能力的定义需要调整。

传统意义上，能力主要指个人技能的熟练程度。AI 时代，"会不会用 AI 放大自己"本身成了能力的一部分。一个基础能力普通但善用 AI 的人，实际输出可能超过能力强但不用 AI 的人。

这带来两个变化：

**能力评估需要包含 AI 使用的有效性** — 不只是"会不会用"，而是"用了之后实际输出有没有提升"。频繁使用 AI 但返工率高，说明 AI 使用没有真正转化为能力放大。

**角色边界需要重新定义** — AI 承担了大量执行工作，人的核心价值逐渐集中在判断、定义问题、审查输出。这意味着决策类和判断类的输出权重在上升，执行类的输出权重在下降。用执行量衡量一个应该做判断的人，在 AI 时代会造成更严重的误判。

***

## 一个值得想的问题

速度和思考的平衡，取决于决策的可逆性：可逆的快，不可逆的慢。高能力的人本来应该把 AI 节省出来的时间用于更深的判断，而不是用来生产更多输出。

如果评估体系只看产出数量，最终会把所有人都推向同一个错误方向：跑得更快，但不一定跑得更对。

***

## AI 场景下的评估体系设计

传统评估的核心问题是衡量**产出量**。AI 把执行成本压低之后，产出量变得廉价——人人都能快速生成大量输出。这时候继续用量来评估，等于在测一个已经不稀缺的东西。

评估重心必须做两个转移。

### 能力评估：从技能熟练度到判断质量

AI 场景下，真正拉开差距的能力是那些**决定 AI 能不能被用好**的能力：

* **问题拆解** — 能不能把复杂问题分解成 AI 可以执行的单元，边界清晰，互不依赖
* **约束设定** — 能不能给 AI 足够明确的条件，让输出第一次就在正确方向上
* **输出校准** — 能不能判断 AI 的输出什么时候足够好、什么时候需要推翻重来
* **错误识别** — 能不能在 AI 的错误传播之前发现并截住

这些能力看不见、不好量化，但决定了 AI 是放大器还是噪音来源。它们无法通过使用频率衡量，只能通过结果反推：返工率低、方向稳定、少走弯路，是它们存在的信号。

### 角色设计：从"做什么"到"决定什么"

AI 承担执行之后，角色的设计逻辑要变：不再只定义"这个角色负责哪些任务"，而是要定义"这个角色必须亲自做哪些判断"。

| 角色类型 | 传统核心职责 | AI 场景下的核心职责           |
| ---- | ------ | --------------------- |
| 执行者  | 完成任务   | 方向确认、输出审查、异常上报        |
| 协作者  | 推进和对齐  | 定义清楚问题边界，让 AI 和团队都能执行 |
| 决策者  | 做决定    | 判断 AI 给出的选项，设定不可逾越的约束 |
| 管理者  | 管理人    | 管理判断容量——团队能做多少高质量决策   |

新的瓶颈不再是执行容量，而是**判断容量**。一个团队一天能做多少高质量的判断，决定了他们能驾驭多大规模的 AI 输出。盲目扩大 AI 使用量，但判断容量没有跟上，只会产生更多需要返工的噪音。

### 衡量 AI 杠杆的有效性

AI 使用频率是中性指标，不应作为评估依据。真正需要衡量的是：**用了 AI 之后，判断质量有没有提升，方向有没有跑偏。**

| 衡量维度    | 正向信号           | 负向信号          |
| ------- | -------------- | ------------- |
| AI 使用效果 | 返工率下降，方向稳定     | 频繁使用但返工率高     |
| 判断质量    | 决策少被推翻，少走回头路   | 方向反复调整，输出大量废弃 |
| 问题定义能力  | AI 输出第一次就可用    | 需要多轮修正才能用     |
| 错误拦截    | 问题在 AI 输出阶段被发现 | 问题流入下游才被发现    |

### 重新设定效率目标

在 AI 场景下，用前面的三步推导框架时，第一步"定义角色的核心输出"需要重新审视：

原来的执行类产出，大部分可以由 AI 承担。人的核心产出向**判断类**和**杠杆类**集中。如果角色定义没有随之更新，效率目标就还是在衡量错误的东西。

一个简单的检验方法：把这个角色的主要工作列出来，逐项问"这件事 AI 能不能做？"能做的部分，不应再作为人效的主要衡量项；不能做的部分，才是这个角色真正的价值所在，也是效率目标应该聚焦的地方。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/08-metrics/role-capability-efficiency.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.