本文是 ES 存储引擎系列的进阶篇，深入剖析相关度评分：从 BM25 算法的 k1/b 参数，到分布式 IDF 问题，再到 Function Score 的各类函数（weight、field_value_factor、decay、random_score、script_score）实战。

第一部分：控制相关度（BM25）

评分框架演进

现代 ES 默认使用 BM25 概率模型替代了早期的 TF-IDF 向量空间模型：

查询上下文 vs 过滤上下文

• 查询上下文：回答”这个文档和查询语句有多匹配？”，计算 _score。使用 match、term（在 should 中）等。
• 过滤上下文：回答”是否匹配？”，答案是 是/否。不计算 _score，但结果会被缓存，性能极高。

实际搜索通常是混合模型：用布尔逻辑（filter）快速精确过滤，用评分查询（must、should）对结果集相关度排序。

BM25 饱和度参数 k1

k1 控制词频对相关度贡献的边际效益递减速度。传统 TF-IDF 中词频线性增长（出现 100 次得分就是 100），存在明显问题——“的”字出现 100 次并不代表相关 100 倍。

BM25 TF 公式（文档长度等于平均长度时的简化）：

$$\text{TF}_{\text{BM25}} = \frac{f \cdot (k_1 + 1)}{f + k_1}$$

BM25 词频饱和效果（k1=1.2）：

完整公式（含长度归一化）：

$$\text{TF}_{\text{BM25}} = \frac{f \cdot (k_1 + 1)}{f + k_1 \cdot \left(1 - b + b \cdot \dfrac{|D|}{\text{avgdl}}\right)}$$

k1 取值场景参考：

BM25 长度归一化参数 b

b 决定文档长度与平均长度的差异如何影响词频贡献。

• b = 0：禁用长度归一化
• b = 0.75（默认）：中度惩罚长文档，奖励短文档
• b = 1：强烈惩罚长文档

自定义 BM25 配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

PUT /my_index
{
  "settings": {
    "index": {
      "similarity": {
        "my_custom_bm25": { "type": "BM25", "b": 0.3, "k1": 1.6 }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "similarity": "my_custom_bm25" }
    }
  }
}

逆向文档频率（IDF）

词在集合所有文档里出现的频率越高，权重越低。

$$\text{IDF}(q_i) = \log\left(1 + \frac{N - n(q_i) + 0.5}{n(q_i) + 0.5}\right)$$

与经典 IDF 的关键区别： +1/+0.5 平滑防止极端值；永远为正；对高频词的惩罚更温和。

分布式 IDF 问题

在分布式集群中，数据被水平分割到多个分片，每个分片是独立的 Lucene 索引，分片之间不共享 IDF 统计信息。

**默认 QUERY_THEN_FETCH**：各分片独立计算 IDF（各自为政），导致同一个词在不同分片中 IDF 不同：

1
2
3

分片1：idf₁ = log(1 + (3000-150+0.5)/(150+0.5)) ≈ 3.04
分片2：idf₂ = log(1 + (3500-200+0.5)/(200+0.5)) ≈ 2.88
分片3：idf₃ = log(1 + (2500-100+0.5)/(100+0.5)) ≈ 3.24

**精确方式 DFS_QUERY_THEN_FETCH**：先预查询收集全局统计，广播给所有分片统一计算 IDF。

1

GET /my_index/_search?search_type=dfs_query_then_fetch

⚠️ dfs_query_then_fetch 需要额外预查询阶段，代价较高，生产中谨慎使用。数据量大、分片多时，默认模式的近似误差通常可接受。

第二部分：Function Score

Function Score 是 ES 的”评分增强器”，允许在基础查询评分上通过一系列函数二次评分。

1
2
3
4
5
6
7
8
9
10

{
  "function_score": {
    "query": { "match": { "title": "咖啡" } },
    "functions": [ ... ],
    "score_mode": "sum",       // 函数得分之间如何组合
    "boost_mode": "multiply",  // 函数分与基础分如何组合
    "max_boost": 10,
    "min_score": 2.0
  }
}

函数组合方式：score_mode

示例：func1=1.5, func2=2.0, func3=0.5

与基础分组合：boost_mode

示例：_score=2.0，functions_score=4.0

Weight：最简单的加权

1

{ "weight": 2.0, "filter": { "term": { "featured": true } } }

⚠️ weight 不是乘数，是固定值！匹配时函数得分为 2，不是乘以 2 倍；不匹配时为 1.0。

Field Value Factor：字段值参与评分

1
2
3
4
5
6
7
8

{
  "field_value_factor": {
    "field": "popularity",
    "factor": 1.2,
    "modifier": "log1p",   // 推荐：平滑且正值
    "missing": 1
  }
}

modifier 函数对比：

Decay 衰减函数：时间、距离、数值的平滑衰减

高斯衰减示例（以上海为原点的地理距离）：

1
2
3
4
5
6
7
8
9
10

{
  "gauss": {
    "location": {
      "origin": { "lat": 31.2304, "lon": 121.4737 },
      "scale": "10km",
      "offset": "1km",
      "decay": 0.3
    }
  }
}

衰减三阶段：offset 内（≤1km）几乎不衰减 → offset ~ offset+scale（1~11km）平滑下降至 decay（0.3）→ 超过后继续趋近 0 但越来越平缓。

Random Score：引入随机性

1

{ "random_score": { "seed": "用户ID", "field": "_seq_no" } }

相同种子 + 相同字段 → 相同随机分数（可复现，保证分页连贯）。

适用场景：商品推荐（避免每次展示同样商品）、内容发现、打散同分文档、探索与利用。

Script Score：完全自定义评分

当内置函数无法满足需求时的终极方案，可访问 doc['field'].value、_score、params.*：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "script_score": {
    "script": {
      "source": """
        double price = doc['price'].value;
        double rating = doc['rating'].value;
        double priceFactor = 1.0 / (1.0 + price * 0.001);
        double ratingFactor = rating / 5.0;
        return _score * (priceFactor * params.price_weight
                       + ratingFactor * params.rating_weight);
      """,
      "params": { "price_weight": 0.6, "rating_weight": 0.4 },
      "lang": "painless"
    }
  }
}

总结

相关度调优的核心：先用 BM25 保证基础相关性，再用 Function Score 叠加业务规则，boost_mode: multiply 是最常用的组合方式。

个人使用备忘 · 感受来自日常开发，不一定完全准确
配合《我的AI编程工作流》· 索引见《AI编程-个人文档索引》
最后更新：2026-07-03

一、一句话选型

二、总览（我的主观打分）

三、各模型使用感受

Opus 4.8

我怎么用：大需求开 /grill-with-docs、出 PRD、拆 Issues，重要改动的 AI 审查也用它。

我的感受：

• 思考明显慢，转圈时间长，但想的东西确实全——会反问我「验收标准是什么」「这个 Out-of-Scope 要不要排除」，有时候还会帮我把边界想得更清楚
• 贵，是目前账单里最能感觉到花钱的模型，一个 Grill 会话下来用量肉眼可见
• 写具体代码也能写，但拿它 implement 小 Issue 有点浪费，我基本不用它写 CRUD

和 4.7 比：日常短对话体感差别不大（待验证：超长会话 4.8 可能更稳，我还没专门 A/B 测过）

印象：像资深架构师，慢，但适合「先把方向定死」

Opus 4.7

我的感受：

• 和 4.8 用起来感觉差不多，没感到明显「代差」
• 同样慢、同样贵、同样会追问
• 4.8 排队或限额时直接换 4.7，规划质量没觉得掉档

印象：4.8 的平替，够用了

Sonnet 5

我的感受：

• 官方说 speed + intelligence 平衡，但我用起来体感偏慢，没有 4.6 那种「说干就干」的爽感
• 虽然 token 单价在促销，但用量下得很快，怀疑是 thinking 在背后烧（待验证：没试过调低 effort）
• 能力应该比 4.6 强，但对我来说定位尴尬——定方案不如 Opus 深，写代码不如 4.6 听话省心

印象：试了几回就回到 4.6 了，暂时不是主力

Sonnet 4.6

我怎么用：每个 Issue 新开会话 /implement，工作流里 Phase 1 固定用它。

我的感受：

• 非常听话——Issue 和 Acceptance Criteria 写清楚，基本按条做，很少自作主张大改架构
• 速度、费用都在能接受的范围，比 Opus 省很多
• 让它单独做 Grill 或写大 PRD 深度不够，会漏一些边界考量
• 不适合审自己刚写的代码，和 implement 同模型容易「互相放过」

印象：靠谱的执行者，给清楚任务就稳定交付

GPT-5.3 Codex（我用的 Codex）

我怎么用：主要是 换 OpenAI 审 Claude 写的代码，做 AI 审查那道门。

我的感受：

• 看 diff、找规范问题、对照 Issue 检查 够用
• 不太习惯它的输出风格——文字偏短、偏「任务清单」，写技术方案或 PRD 时缺少 Opus 那种「为什么选 A 不选 B」的讨论
• 不是不能用，是 和 Claude 习惯不一样，prompt 要重新适应
• implement 试过几次，能写，但我更信任 4.6 的「听话」

和其他 Codex 型号：具体用的 5.3，5.1/5.2 没仔细对比过（待验证）

印象：适合当「第二双眼」审代码，不适合当「主笔」写方案

GPT-5.5

我的感受：

• 用得不多，偶尔通用任务
• 比 Codex 写文档像样一点，但 定大方案还是 Opus 更顺
• 费用感知比 Codex 高，和 Opus 档接近，所以不常选

印象：有能力的通用模型，但在我工作流里没占到固定位置

Composer 2.5

我怎么用：查 SCM 工单、快速总结、FAQ 类问答；极小改动有时也用它。

我的感受：

• 快，响应几乎不用等
• 便宜，用量几乎无感，适合高频低价值任务
• 写技术方案 深度不够，Grill 级讨论 hold 不住
• 复杂 Issue implement 不如 4.6 稳，有过改着改着偏题的情况（样本不多，待验证）

印象：日常杂活神器，别拿它干重活

DeepSeek Pro（V4-Pro）

我怎么用：审查阶段 省钱初筛——先看一遍 diff，再人工过，重要改动 Opus/Codex 复审。

我的感受：

• 极便宜，审查几轮也不心疼
• 速度 OK，中文业务场景理解还行
• 考虑不够全面——并发、边界 case、顺手改别的文件这类问题，漏过几次（所以必须人工补）
• 不能当最终审查，只能当第一道筛子

印象：便宜的预审员，后面还得我自己签字

四、按工作流怎么用

1
2
3
4
5
6

Phase 0 规划        Opus 4.8（4.7 也行）
Phase 1 实现        Sonnet 4.6
Phase 2 AI 审查     Opus 4.8 / Codex（换厂商）
                    或 DeepSeek 初筛 + 人工
Phase 2 人工审查    我自己（必做）
日常查工单          Composer 2.5

五、我常用的组合

六、费用 vs 质量（我的体感）

1
2
3
4
5
6
7
8
9

          质量
           ↑
Opus ●     │      GPT-5.5 ●
Sonnet 5 ● │
           │           Sonnet 4.6 ●
Codex ●    │
           │      Composer ●
           │           DeepSeek ●
           └────────────────→ 费用（越低越右）

七、快速决策

• 要想清楚再动手 → Opus 4.8
• Issue 明确了开写 → Sonnet 4.6
• 审别人/AI 写的代码 → 换 Opus 或 Codex，最后人工过
• 查工单、小问答 → Composer 2.5
• 审查想省钱 → DeepSeek 初筛，人工不能省

八、备注

• 上面都是 我个人习惯，换项目、换 prompt 可能不一样
• 带「待验证」的是样本少或没系统对比过，大方向应该对
• 模型更新快，这篇不对了随时改

感受会随模型更新变，当个人备忘用。

学习日期：2026-07-03
主题：AI 编程助手的「调教」架构 — 从 Anthropic 官方设计到可迁移的工程思维

一、为什么这件事值得学

Claude Code 的配置体系，表面上是「怎么让 AI 更听话」，底层其实是在回答一个更通用的问题：

如何把「概率性的 LLM」包装成「可预期的工程工具」？

大多数人对 AI 编程助手的用法还停留在：写一段 prompt，希望它每次都照做。但长对话、上下文压缩、任务切换、安全边界——这些真实场景会迅速击穿这种 naive 方案。

Anthropic 官方把 7 种配置方式拆开讲，本质上是在做关注点分离：什么必须常驻、什么按需加载、什么必须确定性执行、什么可以隔离出去。这套思路不只适用于 Claude Code，任何要落地生产的 Agent 系统都值得借鉴。

二、核心认知：上下文是稀缺资源

在深入每种配置之前，先建立一个底层模型：

1

上下文窗口 = 有限的工作台面积

所有配置方式的差异，都可以归结为三个问题：

1. 什么时候占用了工作台？（加载时机）
2. 对话变长、要「收拾桌子」时，它还在不在？（压缩行为）
3. 它占多大面积？（token 成本）

很多人配置 AI 助手时的典型错误：把所有想让它知道的东西都塞进 CLAUDE.md。结果不是 AI 变聪明了，而是：

• 简单任务也背着几百行无关规范
• 真正重要的指令被稀释，遵循度下降
• token 账单无声上涨

我的判断：配置 AI 助手和写软件架构一样 — 不是「能塞多少塞多少」，而是「什么信息在什么生命周期里可见」。

三、七种方式，一张心智地图

我不按官方文档顺序记，而是按信息的生命周期来理解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

会话启动
  │
  ├─ 始终在场 ────────── CLAUDE.md（根目录）
  │                      Output Styles（替换系统提示）
  │
  ├─ 条件加载 ────────── Rules（读特定路径时）
  │                      子目录 CLAUDE.md（读该目录时）
  │
  ├─ 按需触发 ────────── Skills（用户 / AI 主动调用）
  │                      Append System Prompt（单次 CLI）
  │
  ├─ 隔离执行 ────────── Subagents（独立窗口，只回结论）
  │
  └─ 确定性执行 ──────── Hooks（不经过 AI 决策）

这张地图比记住 7 个名词更重要。遇到新需求时，先问「这条信息属于哪个生命周期」，再选配置方式，而不是反过来。

四、逐层理解 + 个人思考

4.1 CLAUDE.md — 不是百科全书，是索引卡

官方定位：项目手册，放「事实」不放「流程」。

我的理解：

CLAUDE.md 最接近真实团队里的 onboarding 文档 — 新同事第一天需要知道的：用什么技术栈、怎么构建、目录怎么组织、命名有什么规矩。你不会在 onboarding 里塞一份 50 页的部署 runbook，那是运维手册，需要时再去翻。

几个我自己会遵守的原则：

一个反直觉的点：CLAUDE.md 越精简，AI 表现往往越好。不是因为 AI 变聪明了，而是因为信号噪声比提高了 — 每条指令的「权重」更大。

4.2 Rules — 精准的「地方法规」

Rules 解决的是 CLAUDE.md 覆盖不了的问题：同一条规范，只在特定文件类型 / 路径下生效。

比如「所有 API handler 必须用 Zod 验证」 — 这条规则对前端改 CSS 毫无意义，加载它纯属浪费。Rules 的 paths 作用域就是为此设计的。

和子目录 CLAUDE.md 怎么选？

• 规范绑定一个模块目录 → 子目录 CLAUDE.md 足够
• 规范跨目录生效（如所有 *.test.ts） → 必须用 Rules

我的思考：Rules 本质上是 AI 时代的 .editorconfig / eslint overrides — 按路径施加不同约束。如果你已经在项目里用 lint 规则做分层约束，Rules 的配置思路应该很直觉。

4.3 Skills — 目前最被低估的能力

Skills 的渐进式加载设计，我认为是整个配置体系里最优雅的部分：

1
2

会话开始 → 只加载 Skill 名称 + 一行描述（几乎零成本）
触发时   → 加载完整 SKILL.md（按需付费）

这意味着你可以定义几十个 Skill — 部署、审查、创建组件、写测试、发版 checklist — 而平时它们不占上下文。

为什么我说它被低估？

大多数人把 Skills 当成「高级 prompt 模板」，但它真正的价值是工作流封装：

• 把重复性、多步骤、需要判断分支的流程固化下来
• 新人（或未来的自己）不需要重新摸索「审查代码要检查哪些点」
• 团队可以共享同一套 Skill，减少「每个人 prompt 写法不同导致结果不一致」

一个需要注意的坑：压缩对话时，已触发的 Skills 会按预算重新注入，最早触发的可能被丢弃。所以一次会话里不要贪多 — 聚焦当前任务，完成后再开新会话触发下一个 Skill。

我的实践方向：任何我做过两次以上的多步骤流程，都值得封装成 Skill。判断标准不是「流程复不复杂」，而是「下次还需不需要重新解释一遍」。

4.4 Subagents — 上下文隔离的利器

Subagent 和 Skill 最容易混淆，我的区分标准很简单：

典型 Subagent 场景：

• 在代码库里深度搜索 Bug 根因（中间可能翻几十个文件）
• 分析日志定位性能瓶颈
• 调研某个库有没有替代方案
• 批量迁移（Claude Code 的 /batch 本质就是 Subagent 编排）

我的思考：Subagent 解决的是 LLM 上下文窗口的「污染问题」。调研类任务的中间过程可能产生几万 token 的噪音，如果全堆在主对话里，很快就会把真正重要的上下文挤出去。Subagent 相当于把「脏活」外包出去，主对话保持干净。

这跟微服务里的「异步任务队列」思维类似 — 长耗时、高噪音的任务不应该阻塞主流程。

4.5 Hooks — 唯一确定性的一环

前面所有配置方式 — CLAUDE.md、Rules、Skills — 本质上都是给 AI 的建议。AI 大概率会遵循，但在以下情况下可能失效：

• 长对话后上下文被压缩
• 任务复杂，AI 注意力被分散
• 遇到 prompt 注入（文件里藏了恶意指令）

Hooks 不同：它是自动化代码，绑定到 Claude Code 的生命周期事件，触发即执行，不经过 AI 决策。

1
2
3

PreToolUse   → 工具调用前（拦截危险操作）
PostToolUse  → 工具调用后（自动格式化、跑 lint）
PreCompact   → 压缩对话前（保存关键状态）

我认为最值得记住的观点：

「永远不要做 X」不能靠指令保证，必须靠 Hook + 权限双保险。

这跟软件安全里的 fail-closed 设计一脉相承 — 默认拒绝，显式允许。你不会靠注释防止函数被误调用，你会用类型系统和权限检查兜底。AI 助手的安全边界也应该一样。

典型 Hook 用法：

• 编辑文件后自动 Prettier（不依赖 AI 记得格式化）
• 提交前自动 lint
• 拦截删除数据库迁移文件的操作
• 完成任务后发通知

判断标准：「每次 X 后必须做 Y」→ 用 Hook，不要写进 CLAUDE.md。

4.6 Output Styles & Append System Prompt — 轻量调参

这两个我用得少，但理解它们的边界很重要：

Output Styles：

• 注入系统提示词，永不被压缩
• ⚠️ 会替换默认系统提示词 — 内置的安全行为、修改范围判断等会丢失
• 内置 Proactive / Explanatory / Learning 三种，够用就别自定义

Append System Prompt：

• CLI 参数，单次生效，追加而非替换
• 适合临时调整语气或输出格式
• 指令越多遵循度越低，别滥用

我的建议：90% 的场景不需要碰这两个。需要改 AI 行为时，优先想能不能用 Skill 或 Rule 解决。

五、决策框架（我自己的版本）

遇到新需求，我按这个顺序想：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

1. 这是「项目事实」还是「操作流程」？
   ├─ 事实 → CLAUDE.md
   └─ 流程 → Skill

2. 这条规范是否只在特定路径下有意义？
   └─ 是 → Rule（带 paths）

3. 中间过程是否很长、且我不需要看到？
   └─ 是 → Subagent

4. 这件事是否「必须发生」，不能依赖 AI 自觉？
   └─ 是 → Hook

5. 这是「绝对不能做」的安全红线？
   └─ 是 → Hook + 权限，不要只写指令

6. 只是临时调整一次会话的行为？
   └─ 是 → Append System Prompt

六、可迁移到 Agent 系统的设计原则

Claude Code 的配置体系，提炼成 4 条可以迁移到其他 Agent 项目的设计原则：

6.1 事实与流程分离

常驻上下文只放「不变的事实」，可变的多步骤流程按需加载。这直接对应软件工程里的「数据与逻辑分离」。

6.2 渐进式披露（Progressive Disclosure）

不要一次性把所有信息塞给 AI。先给索引，需要时再展开。这和 UI 设计里的 progressive disclosure 是同一个思想 — 减少认知负荷，提高信号质量。

6.3 确定性优于概率性

凡是「必须发生」或「绝对不能发生」的事，不要指望 LLM 的概率性遵循。用 Hook、权限、类型系统、中间件等确定性机制兜底。

6.4 隔离执行，避免污染

长耗时、高噪音的任务（搜索、分析、调研）应该在隔离环境中执行，只把结论带回主流程。这跟分布式系统里的 bulkhead pattern（舱壁模式）同构。

七、对我当前工作的启发

结合 Cursor / Claude Code 的日常使用，我打算做的几件事：

1. 审计 CLAUDE.md：把超过 5 行的流程性内容移到 Skills
2. 封装重复流程：代码审查、部署检查、新模块脚手架 — 每个做成 Skill
3. Rules 按路径分层：API 层、DB 层、前端组件层各一套，避免全局加载
4. 关键安全操作用 Hook：不依赖 AI「记得不要删 migration」
5. 调研类任务主动用 Subagent：保持主对话上下文干净

八、遗留问题 & 待验证

• Skills 在团队间共享的最佳实践是什么？Git 管理 vs 个人本地？
• Subagent 嵌套 5 层的实际使用场景有哪些？是否过度设计？
• Hook 的性能开销在长会话中是否可感知？
• Output Style 替换默认提示词后，哪些内置行为会丢失？需要实测清单
• 这套配置体系迁移到 Cursor Rules / Skills 时的对应关系

九、一句话总结

配置 AI 编程助手，不是在写更好的 prompt，而是在设计一套信息生命周期管理系统 — 什么常驻、什么按需、什么隔离、什么确定性执行。CLAUDE.md 是索引卡，Skills 是工作流，Subagents 是外包，Hooks 是安全网。搞清楚了这四层，7 种配置方式自然各归其位。

本笔记为个人学习总结，参考了 Anthropic 官方博文《Steering Claude Code》及社区解读，加入了个人理解和工程化思考。

看了几篇解读 + 对照官方文档后的自己的理解 · 2026-07-03

先讲清楚：为什么分七种

以前我配置 Claude Code，基本就是往 CLAUDE.md 里堆东西。后来发现两件事：

1. 上下文窗口是硬资源——塞越多，遵循度越差，长对话里尤其明显
2. 「建议」和「必做」是两回事——写在 md 里的是概率性遵守，Hook 才是确定性执行

官方把配置拆成七种，本质上是在回答三个问题：什么时候进上下文、压缩后还在不在、占多少 token。选错位置，等于白写。

我自己的三条判断：

一张表看清七种方式

注：Output Styles 和 Append Prompt 算第七种里的两个变体，官方表格是分开列的。

1. CLAUDE.md — 项目常驻记忆

放什么：构建命令、目录结构、monorepo 布局、命名规范、团队约定——AI 需要始终知道的事实。

不放什么：部署 runbook、审查清单、30 行以上的步骤——这些该进 Skills。

两种加载行为（之前我搞混了）：

子目录 CLAUDE.md 和 path-scoped Rules 的压缩行为一样——这点容易记错。

200 行：官方明确建议上限。不是玄学，是实测：行数多了，无关任务也带着跑，遵循度反而下降。我有过类似体验，把流程全塞 CLAUDE.md 后，长对话里 AI 开始「选择性失忆」。

索引思维：CLAUDE.md 当目录，不当百科全书。

1
2
3

前端规范 → docs/FRONTEND.md
部署 → /deploy 技能
安全策略 → .claude/rules/security.md（path-scoped）

Monorepo：各团队子目录放自己的 CLAUDE.md；用 claudeMdExcludes 跳过不碰的团队目录。组织级安全策略可以 MDM 下发，个人 settings 无法 exclude。

个人 vs 项目：个人偏好（semantic commit、语气）放 ~/.claude/ 用户级；团队约定放项目级。别把个人习惯写进团队 CLAUDE.md。

维护方式：当代码对待——有 owner、PR review、出问题时回溯是不是某条规则太长或被淹没了。

2. Rules — 路径级约束

.claude/rules/ 下的 Markdown，YAML frontmatter 里加 paths 做作用域：

1
2
3
4
5
6

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
所有 API handler 必须用 Zod 校验输入

无 paths 的 Rule = 另一个 CLAUDE.md：会话开始就加载，改文档也带着，浪费 token。写 Rule 如果不加 paths，和直接往 CLAUDE.md 堆没区别。

** vs 子目录 CLAUDE.md**：

• 规范只跟某个模块目录走 → 子目录 CLAUDE.md
• 规范跨目录（所有 *.test.ts、所有 migration 文件）→ path-scoped Rule

3. Skills — 按需加载的流程

.claude/skills/<name>/SKILL.md，渐进式加载：

• 会话开始：只有 name + description（几乎不占 token）
• 触发时：加载完整 body（/code-review 手动调，或 AI 根据 description 自动匹配）

Commands 已合并进 Skills：.claude/commands/ 还能用但是 legacy；新东西一律放 .claude/skills/。Skills 多了 auto-invocation——AI 看 description 自己决定要不要调，Commands 时代没有这能力。

两种触发模式：

auto-invocation 写 description 要精准——太宽会误触发，太窄永远调不到。

压缩预算：一次会话触发太多 Skill，压缩后按总预算重注入，最早触发的先被踢。所以大需求别在一个会话里 /grill + /deploy + /review 全跑一遍，分会话更稳。

我的用法：工作流里的 /grill-with-docs、/to-prd、/implement、/review 本质上都是 Skills。Phase 0 规划、Phase 1 实现、Phase 2 审查各开新会话，也是为了避免 Skill 预算和上下文互相污染。

4. Subagents — 隔离干活的

.claude/agents/ 下每个文件一个独立助手，YAML frontmatter 配 name、description、model、tools 等。

和 Skills 的核心区别：

调研 50 个文件找 Bug 根因、扫日志、依赖审计——中间几万 token 的中间结果，主对话不需要看，Subagent 合适。

支持嵌套最多 5 层；/batch 批量迁移本质就是 Subagent 编排。很多工具现在能自动创建 Subagent，但理解「隔离上下文」这个设计点，才知道什么时候该手动 spawn。

我的倾向：implement 阶段仍是一 Issue 一会话 + Skill，不用 Subagent——我要看 diff 过程。调研型、只关心结论的任务才考虑 Subagent。

5. Hooks — 唯一靠谱的「必做」

前面六种本质上都是给 AI 的建议。Hooks 是 harness 在生命周期事件上跑的确定性逻辑，跟模型想不想无关。

注册位置：.claude/settings.json（项目级）或 ~/.claude/settings.json（用户级），也可 managed policy（组织级，用户改不了）。

常见事件：PreToolUse、PostToolUse、PreCompact、SessionStart、Stop 等。

Hook 类型要分清（之前容易误以为全是 shell 脚本）：

经典用法：

• PostToolUse：编辑后自动 Prettier / lint
• PreToolUse：检测危险操作，exit code 2 拦截工具调用（拦截原因会进上下文让 AI 知道为啥被拒）
• PreCompact：压缩前备份对话
• Stop：跑测试脚本，不通过不让结束本轮（best practices 里提到的 unattended 验证闭环）

「永远不要做 X」：CLAUDE.md 写「别删 migration 文件」——长会话、压缩、文件里的 prompt injection 都可能破功。真防线是 PreToolUse Hook + Managed Settings 权限，组织级强制的 managed settings 用户本地改不掉。

这跟 fail-closed 设计一脉相承：别指望 AI 自觉，靠类型系统和权限兜底。

6. Output Styles — 慎用的高权重开关

.claude/output-styles/ 注入系统提示，不压缩，且官方说它是七种里指令遵循权重最高的。

自定义 Output Style 默认会替换 Claude Code 内置系统提示——改范围、注释习惯、安全处理、跑测试再收工这些默认行为会全没，变成「通用助手」而非「编程助手」。

frontmatter 里设 keep-coding-instructions: true 可以保留默认编程指令，自定义前先查内置三种：

• Proactive — 更主动执行
• Explanatory — 详细解释
• Learning — 协作学习模式

我基本不用自定义 Output Style——改系统提示的副作用太大，不如 Skills 精准。

7. Append System Prompt — 临时微调

CLI --append-system-prompt，追加不替换，仅当次 invocation 生效，不持久化到文件。

适合：临时调语气、输出格式、加一段领域知识。

限制：追加越多，每条遵循度越低，冲突时更明显。首请求后 prompt caching 会降 input cost，但 verbose 风格会增加 output token。

和 Output Style 对比：Append 是加法、单次；Output Style 是文件级、可能替换默认行为、权重更高。

决策树（我自己用的）

1
2
3
4
5
6
7
8
9
10
11
12

要写一条配置
    │
    ├─ 全局事实，≤200 行          → 根 CLAUDE.md
    ├─ 某模块事实                 → 子目录 CLAUDE.md
    ├─ 跨目录规范                 → Rules + paths
    ├─ 无 paths 的 Rule           → 别写，等于第二个 CLAUDE.md
    ├─ 多步流程 / SOP             → Skills
    ├─ 调研只要结论               → Subagent
    ├─ 每次 X 后必做 Y            → Hook（command 型）
    ├─ 绝对不能 X                 → PreToolUse Hook + 权限
    ├─ 改整体行为模式             → Output Style（先看内置）
    └─ 临时调一次                 → --append-system-prompt

不在「七法」里但经常一起出现的

Cursor 侧有 .cursor/rules、.cursor/skills 等平行概念，思路类似：常驻规则 vs 按需技能 vs 确定性 hook。跨工具迁移配置时，先对齐「加载时机」而不是文件名。

设计思想（对我自己的启发）

1. 事实 / 流程分离 — CLAUDE.md 是内存常驻变量，Skills 是按需 import 的函数
2. 作用域收窄 — path-scoped Rules、子目录 CLAUDE.md、Skill 渐进加载，都是在对抗 context bloat
3. 概率 vs 确定 — 「建议 AI 跑 lint」和「编辑完必跑 lint」不是一回事；安全边界必须确定性
4. 隔离 vs 透明 — Skill 透明可干预，Subagent 隔离保主对话干净；选型看你要控过程还是只要结果
5. 配置也是代码 — CLAUDE.md 会膨胀、会过时、会互相打架；需要 owner 和定期 prune

搭自己的 Agent 系统（不限 Claude Code）也适用：把「常驻记忆」「按需 SOP」「硬 guardrail」「后台 worker」分开设计，比一个大 system prompt 靠谱得多。

和我现有工作流的对照

一个具体计划：

• 各 repo CLAUDE.md 审计：流程性内容迁 Skills，超 200 行拆索引
• 加 PostToolUse format hook，别写在 CLAUDE.md 里赌 AI 记得
• 加 PreToolUse 拦截 rm -rf、删 migration、动生产配置等
• /review Skill 的 description 写清楚触发条件，避免 implement 会话误调
• 调研型任务试 Subagent，implement 仍保持主对话可见

最后想说的

七种方式看起来多，记一个核心就够：上下文窗口是最 scarce 的资源，确定性和概率性不要混用。

我之前的误区是把所有东西往 CLAUDE.md 塞——省事，但长对话里 AI 反而更不听话。拆成 Facts / Flows / Guards 三层之后，token 省下来，遵循度反而上去。

Output Styles 和 Append Prompt 我日常几乎不用；Hooks 和 path-scoped Rules 是被低估的两块——前者管「必须发生」，后者管「别什么都加载」。Skills 是目前 ROI 最高的投入点，把工作流里重复说的话封装成 /xxx，比每次 copy prompt 强一个数量级。

看了几篇讲 AI 上下文配置的文章 + 对照 Claude Code 官方 best practices 后的自己的理解 · 2026-07-03

我踩过的坑

AI 不听话，我第一反应总是「换更强的模型」。后来发现很多时候是上下文给错了——该常驻的没写进文件，该按需加载的全塞根目录，该用 Hook 硬拦的却写成一句「请不要…」。

新会话 AI 是白纸。技术栈、构建命令、团队约定、历史 ADR，你不写它就猜，猜错返工，返工比多写几行配置贵多了。

CLAUDE.md 到底是什么

项目根目录（或子目录）的 Markdown，Claude Code 会话开始就读，相当于给 AI 的入职手册。

但它本质是建议，不是强制执行。写得越具体、越短，遵循越好；模糊要求（「写干净代码」）等于没写。

Cursor 侧是 .cursor/rules + AGENTS.md；Claude Code 是 CLAUDE.md。AGENTS.md 已是跨工具开放标准（Agentic AI Foundation 维护），多 Agent 团队可以 AGENTS.md 放通用约定、CLAUDE.md 放 Claude 特有配置，或在 CLAUDE.md 里 @AGENTS.md 导入，避免维护两份 diverge 的内容。

篇幅：200 行不是形式主义

官方建议 200 行以内。每一行会话全程占 token——改个 CSS 也带着后端部署规范，纯属浪费。

有社区数据说 50 行遵循率 ~94%、400 行掉到 ~71%（待验证：样本和方法我不清楚，但方向对——越长越稀释）。

还有说法 AI 合理遵循约 150–200 条指令，超过后质量均匀下降。我不数条数，用一句自检：删掉这行 AI 会犯错吗？ 不会就删。

只放事实，不放流程——构建命令、目录结构、命名规范是事实；部署 runbook、审查清单是流程，应进 Skills（见《Claude-Code七种配置方式-个人总结》）。

写什么、不写什么

该写

• AI 猜不到的：npm run test、uv sync 这类构建命令
• 跟默认不同的：必须用 Zod 校验、统一 BaseResponse 包装
• 团队 Git 规范、必需 env var、非显而易见的坑
• 正面、可验证的指令

不该写

• 读代码就能知道的结构
• 「写干净代码」「注意性能」
• 大段 API 文档——放 docs/，CLAUDE.md 里写指针

否定句慎用

有文章说 87.5% 规则违反来自否定句（待验证）。白熊效应确实存在——「不要用 class 组件」反而激活 class 组件概念。我习惯改成正面表述：

大项目：别全堆根目录

path-scoped Rules

.claude/rules/ + frontmatter paths，只在 Claude 读匹配文件时加载：

1
2
3
4
5

---
paths:
  - "src/api/**"
---
API handler 必须 Zod 校验输入

改前端时不加载 API 规则。无 paths 的 Rule = 第二个 CLAUDE.md，会话开始就全量加载。

子目录 CLAUDE.md

app/api/CLAUDE.md 只在读该目录文件时加载。压缩后会丢，直到再碰那个目录——和根 CLAUDE.md 行为不同，别搞混。

@ 指针做渐进披露

1
2
3

## 参考
- API 架构 → @docs/api-architecture.md（改 API 时读）
- 部署 → /deploy 技能

核心思想：CLAUDE.md 当目录，不当百科全书。官方叫 just-in-time context，和 Skills 按需加载是一脉的。

Hooks 管「必须发生」

格式化、提交前 lint、危险命令拦截——写 CLAUDE.md 里 AI 可能忘。Hook 触发必执行，跟模型无关。

PreToolUse + exit code 2 可以硬拦删 migration 等操作。CLAUDE.md 负责建议，Hooks 负责强制——这条和我另一篇「七种配置方式」总结是同一逻辑。

多层级配置

优先级大致：本地 > 项目 > 用户；组织级是底线。

口头说的不算：对话里「后面都用 async/await」，压缩后就没了。持久化信息必须落文件。

怎么起步

1. /init 自动生成初稿——一定要人工精简，一条烂指令的破坏力超过一行烂代码
2. 从实战沉淀：先协作 1–2 个任务，再让 AI 回顾对话总结规范写成 CLAUDE.md
3. 从 20 行开始：技术栈 + 构建/测试命令 + AI 反复犯的 3–5 条，用着再加

Claude Code 创始人习惯：AI 犯错时不只改代码，让它把纠正写进 CLAUDE.md。Auto Memory（~/.claude/projects/.../memory/）也会自动记模式，用 /memory 查看——和 CLAUDE.md 互补，但不能替代团队级约定。

规则不生效时我查什么

1. /memory 看 CLAUDE.md 有没有被加载
2. 指令是否够具体——「格式化好」→「2 空格、单行 80 字符」
3. 有没有矛盾——CLAUDE.md 说 MyBatis Plus，rules 说 Flex
4. 该用 Hook 的是不是错写在 md 里

官方还建议：CLAUDE.md 当代码维护——AI 反复犯同一错，说明规则太长被淹没了，或表述歧义。

和我工作流的关系

以前 README 给人看，现在 CLAUDE.md 给 AI 看——本质都是「把重要信息组织清楚」，但给 AI 的版本要更短、具体、可执行。

待办

• 各 repo 审计 CLAUDE.md：流程迁 Skills、超 200 行拆索引
• 统一 AGENTS.md + CLAUDE.md 分工，避免双份维护 diverge
• 配 PostToolUse format Hook
• AI 犯错后追加规则，定期 prune 过时条目

华为的管理逻辑其实很简单，就是”价值创造—价值评价—价值分配”的闭环循环。本文梳理华为绩效管理的核心精髓、关键落地机制及激励体系设计思路。

一、核心底层逻辑：价值链循环

华为管理的本质是”价值创造—价值评价—价值分配”的闭环，三个环节环环相扣、缺一不可：

感悟：学华为不可盲目照搬制度，需吃透价值链循环逻辑，结合企业实际调整。企业驱动员工奋斗，核心是做好利益牵引，让努力有回报。

二、绩效管理核心精髓

五不看，只看责任与贡献

不看资历、学历、能力、潜力、态度，仅以当期责任履行情况和实际贡献为评价标准，杜绝”光说不做””靠资历混日子”。

补充：不是说华为没人情味。对于员工的历史贡献，会通过升职、加薪、配股等方式回馈；只是当期绩效评价只看当下表现，这样才公平。

分层分级，比例控制

同一岗位、同一级别的员工放在一起评比，不跨层级对比。同时严格控制绩效比例：

三个实用知识点

1. 绩效管理不是要让所有人满意，主管只要做到”公平公正、激励希望“八个字就够了；
2. 主管的核心能力是绩效诊断，不是简单打分——找出员工绩效不好的根本原因，帮其明确改进方向；
3. 绩效管理的核心是”做大蛋糕“，不是”内部内卷”，不是比谁加班更多。

三、关键落地机制

华为靠三大机制确保价值评价公平公正，杜绝黑箱操作：

华为绩效申诉率仅千分之 1.6，离职率约 8%（主动淘汰 5%、主动离职 3%），处于高科技行业低位，印证了机制的有效性。

四、激励体系：物质 + 非物质双轮驱动

物质激励：低固定、高弹性，拉开差距

固定工资只占 40%，剩余 60% 是与绩效直接挂钩的奖金。同一岗位同一级别，A 类员工年收入约是 B 类的 2.8 倍（目标 3–5 倍）。

核心逻辑：固定工资不用太高，避免员工躺平；浮动奖金要足够有吸引力，让奋斗者拿到超额回报。

非物质激励：愿景 + 机会 + 荣誉

• 愿景使命激励：将员工工作与中国科技崛起绑定，激发使命感；
• 机会激励：奋斗者优先获得发展机会（干部选拔四优先、任职资格体系、蒙哥马利计划）；
• 荣誉激励：金牌奖、明日之星奖等，注重仪式感，让付出被看见。

五、核心认知与避坑点

三个核心价值观不能丢： “以客户为中心”（价值创造原则）、”以奋斗为本”（价值分配原则）、”责任结果导向”（价值评价原则）。

两个常见误区要避开：

1. 盲目照搬华为制度，忽略自身实际（中小企业照搬复杂机制只会增加成本）；
2. 把绩效搞成内部内卷，比谁加班多、比谁更惨。

文化落地不是靠背诵心得： 真正的文化落地，是通过机制让员工知道、理解、认同，最后自觉去做。

六、延伸思考：OKR 与 PBC 的差异

华为针对高不确定性岗位（研发、创新业务）采用 OKR，针对确定性岗位（行政、运维、成熟销售）采用 PBC：

企业选择工具的考虑因素： 岗位不确定性（最核心）、企业发展阶段、管理成熟度、激励导向。

七、中小企业能否照搬”低固定、高弹性”

不适合直接照搬，核心原因：

1. 成本承受能力不足：中小企业盈利不稳定、现金流紧张，业务淡季奖金大幅减少会导致员工批量离职；
2. 绩效体系不完善：高弹性薪酬需公平精准的评价体系支撑，评价不公只会引发不满；
3. 人才吸引力不足：品牌与发展空间不及华为，低固定工资难以吸引和留住核心人才。

建议：中小企业可借鉴其核心逻辑，调整固浮比例（固定 60%–70%、浮动 30%–40%），兼顾员工安全感与激励效果。

八、总结

华为绩效管理与激励体系的核心，是通过”价值创造—价值评价—价值分配”闭环，实现”利益牵引 + 使命驱动”：以责任结果导向保障公平，以低固定高弹性薪酬拉开激励差距，以愿景、机会、荣誉唤醒使命感，最终推动全员聚焦客户价值，形成”奋斗者有回报、躺平者被淘汰”的良性循环。

看了 spec-kit 介绍 + 规约驱动相关讨论，对照自己工作流后的理解 · 2026-07-03

为什么跟 AI 越聊越乱

典型场景：「帮我加登录」→「密码要加密」→「失败要有提示」→ 改到第三轮注册接口被动了。

直觉怪模型不够聪明。真相是输入就是碎的——AI 每次只看到这一句话 + 眼前上下文，做第五步时可能忘了第一步为什么那么设计。你和 AI 之间缺一份双方都认可的对齐物。

Vibe Coding 爽在不用写文档，适合小玩具、一次性脚本、周末 demo。正经项目、要长期维护的，口头一句句喂，就像跟外包说需求——双方都没有完整图。

Spec Coding 是什么

先把要做成什么样讲清楚，再让 AI 动手。

不是写一份死合同，而是分台阶、每阶停一下对一次。任何一步发现前面想岔了，随时回去改——规约是活的共识，不是瀑布式签字定死。

1
2
3
4
5
6
7

需求（做什么、为什么，不谈技术）
    ↓
方案（用什么技术、怎么架构）
    ↓
任务（拆成可独立执行的活）
    ↓
实现（照着任务清单写代码）

spec-kit：把流程做成斜杠命令

GitHub 官方的 spec-kit 把上面四步封装成 Skill，装在 .claude/skills/ 下：

兜底：

关键细节：Skill 是 Claude Code 启动时扫描的，必须 cd 进项目目录再开 claude，斜杠命令才会出现。

安装：uv tool install specify-cli --from git+https://github.com/github/spec-kit.git，然后 specify init <项目名> --integration claude。

和标准瀑布的区别

表面都是分阶段，内核完全不同——规约是橡皮泥，不是石头。

选型标准：这东西打不打算长期维护、持续加功能？是 → Spec；几十行跑一次就扔 → Vibe 一把梭。

和我自己的工作流：本质一样，工具不同

我没直接用 spec-kit，但大需求走的是同一套逻辑：

1
2
3
4
5

/grill-with-docs  ≈  constitution + specify + clarify（压力测试 + 对齐边界）
/to-prd           ≈  plan（技术方案 + 验收标准）
/to-issues        ≈  tasks（垂直切片 Issue）
/implement        ≈  implement
/review           ≈  人工 + AI 验收

区别是我用自定义 Skills 而不是 spec-kit 默认模板，Grill 阶段会读代码库、写 ADR，比纯 spec-kit 更重「领域建模」。

spec-kit 的 /speckit-specify 强调需求阶段零技术词——这点我认同，也是性价比最高的一次检查：花 2 分钟读 spec，省 2 小时返工。

实操教训

1. specify 只谈需求——「React + SQLite」留到 plan
2. 每步产物亲自过——不对当场改，别攒到 implement
3. 大项目分阶段 implement——别一条命令从头撸到尾；上下文太长会顾此失彼
4. implement 前一行代码都没有是正常的——到 tasks 步还在规划，说明做对了

有人用 spec-kit 做看板 demo，10 分钟跑通——我信小 demo 可以，但生产级项目别指望一次 /speckit-implement 搞定。

和 MewCode Agent 项目的关联

MewCode Agent 虽没用 spec-kit，但文档结构也是：

1

spec.md → plan.md → task.md → checklist.md → 代码

让 AI 写代码前先把规划做满——这和 spec-kit 哲学一致，只是文件命名不同。

我的判断

AI 时代瓶颈从「会不会写代码」转向能不能把事情讲清楚。Spec Coding 的价值不是文档本身，是把「先想清楚再写」从废话变成绕不过去的工序。

规约驱动真正值钱的是对齐成本前置——第一步发现理解偏差，比 implement 完返工便宜一个数量级。

待办

• 挑一个 repo 用 spec-kit 完整跑一遍，和我的 Skills 流程对比差异
• constitution 级铁律（测试、安全）是否该单独文件化
• 大需求 implement 继续一 Issue 一会话，别合并成 mega-session

读了 Anthropic 2026.6 关于 Claude Code 的大规模研究 + 几篇解读后的自己的理解 · 2026-07-03

研究在说什么

Anthropic 分析了约 40 万次 Claude Code 会话、23.5 万用户（2025.10–2026.4），报告名 Agentic coding and persistent returns to expertise。

核心结论：决定 Agent 编程成败的， increasingly 是领域专业度，不是编码背景。

这不是某博主体感，是隐私 preserving 分类器 + 遥测交叉验证的统计结果（分类器读 transcript，不只看 job title）。

人机分工已经变了

典型会话里：

• 人 ~70% 规划决策（做什么、什么算完成）
• Claude ~80% 执行决策（改哪些文件、写什么代码、跑什么命令）

用户发一条 prompt，Claude 平均链式执行 ~10 个 action、产出 ~2400 词——人决定方向，Agent 填细节。

「怎么写代码」这块硬功夫 Agent 接走了大头；剩下「做什么」靠的是对这件事本身的理解。

会写代码的护城河还守得住吗？

各职业成功率（产出代码的会话，verified success）

• 十大职业群全部落在软件工程师 7 个点以内
• 管理岗 verified success 甚至略高于软件工程（可能 partly 因为更愿意在 transcript 里确认完成）
• 七个月观察期内，这个 gap 没有缩小也没有扩大——模型变强了，职业差距没抹平

整体（含不产代码的会话）：软件相关 ~30%，其他 ~26%。

结论：编码背景正在变得 less decisive，但不是 zero——5pp 差距真实存在，只是远小于直觉预期。

真正拉开差距的是什么

同一条 prompt，不同专业度

差在会不会派活——跟 Java 语法无关，跟懂不懂这个领域的门道直接相关。

秒杀例子：

• 新手：「写个扣库存接口」→ 直接 update set stock = stock - 1，单线程测试 OK
• 老手：「Redis 预扣 + Lua 原子扣减 + 热点限流 + 异步落库最终一致」→ 一整套

差别不在语法，在于懂超卖、击穿、一致性。

翻车时的差距

专家也会遇到 AI 瞎写——区别在于一眼看出哪不对、知道往哪救。本地全绿不信，上压测；新手本地 OK 就上线，真秒杀超卖。

得先修炼成专家吗？不用

verified success 按 expertise 分级：

最大跳跃：新手 → 中级；中级 → 专家曲线平了。

官方原话：a working grasp of the domain captures most of the benefit, while deep specialization adds only a bit more.

翻译：及格线很低。不需要二十年老炮，知道一件正常的活该长什么样、关键约束是什么、做出来对不对，就已经跨过收益最大的坎。

七个月趋势：Agent 在扛更值钱的活

Agent 从「帮你打补丁的小工」→ 能扛端到端部署、数据分析、文档的主力。人顺势从抠 bug → 更靠近「想清楚要什么」。

截至 2026.4，新手和专家的 success gap 没有因模型进步而收敛——领域判断力暂时还没被 Agent 替代。

用好 AI 编程的三件事（全不考编码）

这三件和我工作流完全对齐：Grill 说清 → Issues 拆活 → AI 审查 + 人工审查验收。

「AI 不能担责」——我的理解

研究数据支持一个直觉：AI 能执行，不能为你的业务决策担责。

• 34% verified success 意味着 66% 的会话 strict 意义下不算完全成功——即使专家也一样
• 你必须懂行，才能指方向、拆任务、验结果、在 AI 瞎写时救回来
• 护城河不是语法和 API（Agent 比你熟），是你在某个领域里比 AI 更懂这件事本身

Non-engineer 29% vs engineer 34% 说明红利不 exclusive 给程序员——懂业务的人照样能指挥 Agent。反过来说，只会写 CRUD、不懂业务的程序员，优势在缩小。

对我工作流的启示

Spec Coding + 双道审查，本质上就是在系统化地做「说清、拆活、验收」——研究给的是统计背书，不是新方法论。

待验证 / 研究局限

• 分类器读 transcript，不能测「代码上线后是否真的在用」
• expertise 是 task-specific 的——Rust 新手和 reconciliation 专家可以同一个人
• 非交互式 usage（CI 里的 Agent）未纳入
• 我的体感：partial success 91% 看着高，但「部分成功」离「可 merge 上线」可能还差很远——verified 15–33% 更接近真实交付门槛

一句话

同样一个 Claude Code，有人开挂有人骂笨——差在懂不懂行，不是会不会写代码。我的优势不是和 AI 比语法，是比它更懂我要解决的那个问题，并且敢为 merge 担责。

任正非对华为人才体系的核心关注点是干部。本文承接上篇战略部分，梳理华为管理的底层逻辑”三道”，以及干部选拔、培养、文化建设与激励体系。

一、底层逻辑：管理的”三道”

企业竞争的本质是管理竞争，管理竞争的核心是认知竞争。华为管理的底层逻辑可概括为”三道”：

二、核心认知误区打破

三、干部选拔：实战赛马，四维立标

核心原则

“将军是打出来的”，坚持选拔制与淘汰制，通过实战赛马筛选。三大优先原则：

• 优先从成功团队选干部（沉淀优秀基因）；
• 优先从主攻战场、一线及艰苦地区选干部（艰苦环境是试金石）；
• 优先从长远发展关键事件中选干部。

同时明确”以岗选人，而非以人定岗”，核心看人与岗位的适配度。

四维选拔标准

后备干部储备

为每位现任干部配备继任者（继任 1 为即时可接任者，继任 2 为差一项经验的储备者，Two-job away 为高潜人才），通过”有人随时可替代”构建危机感，倒逼现任干部持续奋斗。

四、干部培养：训战结合，分层锻造

华为大学以”对内赋能、训战结合”为核心宗旨，对标黄埔军校。四大教学方针：坚持选拔制、训战结合、循环赋能、优秀者培养优秀者（无专业教师，高级干部每年需完成 32 小时授课）。

从秀才到将军的三阶锻造：

1
2
3

① 秀才变战士：半个月魔鬼训练筛骨干，强化服从、纪律与团队意识
② 战士变班长：训战结合练带队能力，参与铁三角作战
③ 班长变将军：聚焦认知升级，锤炼格局，"神经粗糙、个性坚强"

坚持”之字形”跨部门轮岗，核心覆盖研发、市场客户经理、财经三大岗位，萃取技术、客户洞察、经营三大核心能力。

干部三砍：明确分层定位

• 高级干部砍手脚：摒弃事务性干预，聚焦战略布局；
• 中层干部砍屁股：打破部门本位，实现端到端协同；
• 基层干部砍脑袋：强化执行力，聚焦战术落地。

干部六大责任

思想导航、捕捉机会、达成目标、抓住主要矛盾、提升效率、赋能团队。领导者最核心的能力是影响文化的能力，需以身作则，行胜于言。

五、文化建设：以故事为载体

核心文化内核——狼文化： 敏锐的嗅觉（捕捉机会）、不屈不挠的进攻意识（结果导向）、团队作战（群体奋斗）。配套”狼狈文化”实现平衡——狼负责前端进攻，狈负责后端防守与管理。

文化落地路径： 文化深入人心不靠空洞说教，而靠鲜活故事。新员工入职会收到 100 个一线故事。同时强调持续自我批判（设立战略蓝军挑战自我）、以熵减变革对抗衰退。

六、激励体系：物质与非物质协同

激励理论支撑

• 马斯洛需求层次：生理→安全→社交→尊重→自我实现，低层次满足后转向高层次；
• 赫兹伯格双因素：保健因素（如基本工资，不给则不满）vs 激励因素（如认可、荣誉，能点燃斗志）。奖金需拉开差距才能保持激励属性。

差异化激励设计

不同群体需求差异显著：新生代重物质、认可与成长，中生代重授权与机会，老员工重尊重与信任，空降兵重成就感与工作家庭平衡。

激励组合拳

• 物质激励：多重、多次、多维度，涵盖工资、奖金分红、专项补贴，针对艰苦地区增设家属补助；
• 非物质激励：场景化、多元化，包括公开认可、领袖合影、父母颁奖、评选”明日之星”。

激励的终极目标是”三个人干五个人的活，给四个人的钱”，通过科学价值分配撬动更大价值创造。

七、组织与流程能力建设

人才管理六环节闭环： 选、用、流、育、激、管，以选拔为核心，坚持”选后再育、以战验才”。建立”无尖双塔”人才金字塔——管理通道与专家通道级别对等、薪酬无差，打破”唯有当官才有出路”的困境。

分层 KPI： 绩效结果遵循”战略-组织-个体”解码路径，各部门 KPI 围绕”独特价值创造”设计，权重向主要矛盾倾斜（超过 50%）。

管理者双重角色： 管理是”完成目标的执行与平衡”，领导是”点燃团队的追随力”。做到”用兵狠、爱兵切”，刚柔并济。领导者的核心职责是培养接班人——“不培养接班人是对公司最大的不负责任”。

八、核心逻辑总结

华为管理的底层逻辑可归结为”价值共生“——以客户为中心创造价值，以奋斗者为本分配价值，以自我批判和熵减变革保障价值持续创造，以文化凝聚共识。

其核心是对”人性、实战、价值”的深刻把握：正视人性自私，用利益驱动奋斗；坚守实战导向，让干部在战场成长；聚焦客户价值，拒绝形式主义。虽行业不同、场景有别，但其对”实战、人性、价值”的把握，值得所有企业借鉴——但不可盲目照搬制度，需吃透逻辑，结合企业实际调整。