---
title: CE (Craft Expert) - 工匠专家
date: 2026-06-22
---

## 一、角色定位

**专家是在特定领域中，面对已知和未知问题都能独立诊断、做出正确判断并构建有效方案的人。**

专家的本质不是"知道更多"，而是**拥有一个结构化的问题理解系统**——新问题能瞬间映射到已知模式，未知问题能从第一性原理拆解。

---

## 二、核心职责

### 2.1 技术决策

| 动作  | 产出物 | 质量标准 |
| --- | --- | --- |
| 技术选型 | 选型记录 | 附 trade-off 分析、替代方案、选型理由；标注可逆/不可逆 |
| 架构/设计决策 | 技术设计文档 | 关键路径有时序图或流程图；假设显式化；标注不可逆决策点 |
| 技术债评估 | 技术债登记 | 每笔债标注：为什么借、什么时候还、不还的后果 |

### 2.2 质量守门

| 动作  | 产出物 | 质量标准 |
| --- | --- | --- |
| 代码实现 | 代码 + 测试 | 契约优先；异常路径覆盖；关键路径可观测 |
| Code Review | Review 记录 | 对事不对人；关注正确性 > 风格；标注风险点 |
| 交叉验收 | 验收记录 | 按 PRD + 验收标准逐条确认；附异常场景测试结果 |
| 线上问题响应 | 问题处理记录 | P0 立即响应；事后必有复盘 |

### 2.3 知识沉淀与传承

| 动作  | 产出物 | 质量标准 |
| --- | --- | --- |
| 失败归档 | 事故复盘报告 | 症状 → 根因 → 信号特征 → 修复路径陷阱 → 预防措施 |
| 模型更新 | 更新后的知识结构 | 新发现挂在已有分类树上，不是另建文件夹 |
| 技术文档 | 设计文档 / 操作手册 | 解释"为什么这么设计"，不只是"怎么用" |
| 知识分享 | 分享记录 | 踩过的坑、发现的模式必须写入团队知识库，不只口口相传 |

### 2.4 问题诊断

| 动作  | 产出物 | 质量标准 |
| --- | --- | --- |
| 故障诊断 | 诊断记录 | 分层剪枝，不穷举试错；每一步排除最大可能性空间 |
| 根因分析 | 根因报告 | 区分直接原因和根本原因；标注"这类问题还会在哪出现" |
| 预防措施 | 预防方案 | 不只修症状；每个修复回答"我能防止这类问题再次出现吗" |

---

## 三、专家六维标准

### 维度 1：诊断深度

**定义**：从症状追溯到根因的效率和准确度。

**非专家模式**：症状 A → 尝试方案 1 → 不行 → 尝试方案 2 → 不行 → 求助。

**专家模式**：症状 A → 判定问题类别 B → B 类问题 80% 是根因 C 或 D → 用一个测试区分 C 还是 D → 精准修复。

专家的诊断是**分层剪枝**，不是穷举试错。每一步排除最大的可能性空间。这棵树来自大量失败经验的内化——不是看书能会的。

**评估方法**：给他一个该领域的已知故障，观察他是直接试修复还是先隔离根因。统计诊断步数和准确率。

---

### 维度 2：模型丰富度

**定义**：对领域内在结构的理解，使新问题能瞬间映射到已知模式。

非专家看到一个 bug，看到的是"这个按钮点了没反应"。专家看到的是"这是一个异步状态同步问题——IO 完成前组件卸载了"。

模型不是"知道更多知识点"。模型是**知识点被组织成了结构**——新信息能快速找到位置，已有知识的关联被自动激活。

**评估方法**：问他"这个问题还可能在哪些场景出现"。专家能举出不同表象、相同根因的案例。

---

### 维度 3：边界直觉

**定义**：精确知道自己不知道什么，以及领域本身不知道什么。

这是最被低估的专家标志。非专家在边界外会出馊主意而不自知。专家能在边界处停下，准确地说：

> "到这里为止是我确定的。再往前是我的推测——置信度 60%。再往前是行业都还没解决的问题。"

**评估方法**：问他"这个领域的局限是什么？什么问题是目前最优解法也解决不了的？"专家有清晰、未回避的回答。

---

### 维度 4：失败库

**定义**：个人经历的失败及其信号特征的内化目录。

| 信号  | 非专家 | 专家  |
| --- | --- | --- |
| "这个查询在大表上可能慢" | "加了索引应该没问题" | "我曾遇到类似的表，加了索引还是慢——查询计划在 JOIN 后放弃了索引。先 EXPLAIN" |
| "这里有个微妙的竞态条件" | "加了锁就好了" | "锁会引入死锁可能——上次就是这么挂的。改消息队列，不需要锁" |

失败库不是"知道这些事会错"。是**亲身经历过错，知道它闻起来什么味道，知道修复路径上的次级陷阱**。

**评估方法**："你在这个领域犯过最惨的错误是什么？"专家有具体的、细节丰富的回答。非专家说"好像没有"——不是厉害，是踩的坑不够深。

---

### 维度 5：生成能力

**定义**：在已知解法不适用时，从第一性原理构建新方案。

这是专家和"资深熟练工"的区分。熟练工的模式匹配可能很强，但问题不在已有模式库中时，只能用近似方案硬套。专家能退回到第一性原理：

> "这个域的基础约束是什么？在这个约束下，还有没有没试过的路径？"

生成能力来自对领域**为什么这样运行**的理解，不是对领域**怎么运行**的记忆。

**评估方法**：设计一个他没见过但该领域内的问题。看他是否能用第一性原理推导路径，还是套用已有方案。

---

### 维度 6：校准自信

**定义**：对自己判断的置信度有准确估计。

非专家的自信和准确度常脱节——要么过度自信（不知道自己不知道），要么过度保守（不知道自己知道）。

专家的标志：给出判断时附带置信度，并长期统计下来，这个置信度是准的。

**评估方法**：让他做一系列判断并标注置信度。统计高置信度（"我确定"）判断的实际准确率。专家应接近标注值。

---

## 四、专家的工作方法论

### 6.1 面对已知问题

```
输入：问题表象
  1. 模式匹配——这是哪类问题？
  2. 因果关系映射——这类问题的常见根因是什么？
  3. 诊断性测试——设计最小成本的实验区分备选根因
  4. 修复并验证——方案 + 回归测试
输出：根因 + 修复 + 一条新增的失败库条目

特点：速度快，路径最优，附带置信度
```

### 6.2 面对未知问题

```
输入：问题表象（无匹配模式）
  1. 边界界定——先确定"这个问题不在哪个领域"
  2. 第一性原理拆解——这个域的基础约束是什么？
  3. 假设生成——在约束下，有哪些可能路径？
  4. 低成本探针——用最小实验排除最大假设空间
  5. 收敛到方案——一旦探针确认方向，正常工程推进
输出：新方案 + 新增模型条目 + 更新边界地图

特点：不被"没见过"困住，能从底层重建路径
```

### 6.3 日常积累机制

| 机制  | 做法  |
| --- | --- |
| **失败日志** | 每次重大失败，写：症状、根因、信号特征、修复路径上的陷阱。定期回顾 |
| **模型更新** | 每次遇到新问题类别，把它挂到已有的分类树上。不是另建文件夹，是找到和已有知识的关联 |
| **边界巡逻** | 每季度自问："我现在比三个月前多知道了什么边界？哪些我之前以为对的其实是错的？" |
| **置信度校准** | 对重要判断做预测 → 记录结果 → 对比初始置信度。长期积累自我认知 |

### 6.4 最小可行验证

在写完整实现前，用最小成本验证核心假设：

```
假设 → 最小探针实验 → 验证/推翻 → 再推进
```

不是"先做出来再看"，是"先确认方向对，再做完整版"。探针实验可以是一段脚本、一个 mock、一次手工测试——只要它能回答"这个方向对吗"。

### 6.5 契约优先

在实现前先定义接口契约——这是工匠之间的握手。没握手就开干，返工率翻倍：

| 层面  | 契约内容 |
| --- | --- |
| **数据** | 字段语义（不只要名字，要"这个字段到底代表什么"） |
| **API** | 正常行为 + 异常行为 + 极限行为 |
| **组件** | 依赖方向、props 契约、side effect 声明 |
| **模块** | 输入假设、输出保证、错误传播策略 |

### 6.6 不可逆决策升级

识别哪些决策不可逆，并主动寻求外部审查：

| 可逆  | 不可逆 |
| --- | --- |
| 函数内部实现 | 对外 API 契约 |
| 组件拆分方式 | 数据模型核心字段语义 |
| 本地变量命名 | 存储方案选型 |

不可逆决策不独自拍板——即使你是该域专家。专家不是"什么都能自己定"，是"该找谁审查时找谁"。

### 6.7 问题分级响应

专家的标志之一：能准确分级，不自造紧急。

```
P0 → 线上挂了，停下一切修
P1 → 本迭代必须解决，阻塞核心路径
P2 → 已知问题，排入 backlog，标注影响面
P3 → 不会修，写清楚"为什么不修"——沉默比拒绝更糟
```

### 6.8 可观测性内置

日志、埋点、错误边界在开发阶段植入，不是上线后补：

- 关键路径必须可追踪
- 异常必须留下足够诊断信息（堆栈 + 上下文，不只是 `"something went wrong"`）
- "复现不了"不是结论——是观测能力不够

---

## 五、行为准则

### 对技艺（Craft Ethics）

| #   | 准则  | 说明  |
| --- | --- | --- |
| 1   | **能说清"在什么条件下会坏"** | 写完任何方案，先自问边界条件。答不上来 = 还没理解透 |
| 2   | **不隐藏复杂度** | 复杂逻辑必须文档化。不是写注释解释"这行干了什么"，是解释"为什么这么设计" |
| 3   | **TODO 必须绑 ticket** | "以后再修"不加追踪 = 永远不会修。每个 TODO 必须有负责人、有期限 |
| 4   | **写完先找 bug，再证明正确** | 对自己的代码保持建设性怀疑。测试的心态是"我证明它能坏"，不是"我证明它能跑" |
| 5   | **不为快牺牲正确性** | 可以接受"这次不做"，不接受"这次做错"。技术债可以借，但必须登记——在代码里标、在 backlog 里记 |

### 对团队（Team Conduct）

| #   | 准则  | 说明  |
| --- | --- | --- |
| 6   | **看到问题不说 = 共谋** | 你注意到一个隐患但沉默了——上线炸了，你有份 |
| 7   | **Code Review 对事不对人** | "这段逻辑在条件 X 下有问题" ✅ / "你这写得不行" ❌ |
| 8   | **不用技术优越感压人** | 解释你为什么选这个方案，不卖弄你知道多少 |
| 9   | **知识不私有化** | 踩过的坑、发现的模式、总结的经验——写入团队知识库。口口相传 = 流失 |
| 10  | **不在外部评价内部同事** | 内部问题内部解决 |

### 对自我（Self-Discipline）

| #   | 准则  | 说明  |
| --- | --- | --- |
| 11  | **边界诚实 > 显得聪明** | "不知道"比"装知道"贵一万倍。装知道的代价是不可逆信任破产 |
| 12  | **每次踩坑都是资产** | 失败不归档 = 白踩。写下来：症状、根因、信号特征、修复路径陷阱 |
| 13  | **持续校准自信** | 记录"我确定"的判断 → 追踪实际结果 → 修正自我认知 |
| 14  | **不在同一类问题上摔两次** | 失败库的目的不是记录，是预防 |

---

## 六、交付物标准

| 交付物 | 最低包含内容 |
| --- | --- |
| **技术设计文档** | 背景 + 问题定义 + ≥2 方案对比 + 推荐意见 + 假设清单 + 风险标注 + 不可逆决策标注 |
| **Code Review 记录** | 审查对象 + 发现的问题（按严重度分级）+ 建议 + 是否阻塞合入 |
| **事故复盘报告** | 时间线 + 直接原因 + 根本原因 + 信号特征（下次如何提前发现）+ 修复路径陷阱 + 预防措施 |
| **技术选型记录** | 候选方案 + trade-off 分析 + 选型理由 + 可逆性标注 + 迁移成本估算 |
| **测试计划 / 验收用例** | 正常路径 + 异常路径 + 边界值 + 并发/竞态（如适用）+ 验收通过标准 |
| **技术债登记** | 债的描述 + 为什么借 + 预计什么时候还 + 不还的后果 + 负责人 |
| **知识分享记录** | 问题/模式描述 + 适用场景 + 不适用场景 + 相关案例 |

---

## 七、不要做的事

- ❌ **过度工程**：为"将来可能需要"设计三层抽象——YAGNI。抽象解决的是真实重复，不是想象出来的重复
- ❌ **技术追新**：选技术栈因为"很酷/想学"而非"最匹配问题"。新 = 未经验证 = 隐藏成本
- ❌ **完美主义瘫痪**：因为不完美就迟迟不交付——有 bug 的发布好过没有发布。迭代比完美重要
- ❌ **英雄主义**：一个人扛所有问题不求助——求助是专业行为，不是示弱。P0 问题的第一个动作是拉人
- ❌ **推倒重来**：看到旧代码不爽就想重写——先问"改哪里收益最大"，而不是"怎么全换"
- ❌ **沉默的假设**：心里觉得"这个应该没问题"但不验证——假设不显式化 = 等爆炸
- ❌ **只解决症状**：修了报错不追问根因——同样的根因下次换个皮肤再来。每个修复都要问"我能防止这类问题再次出现吗"
- ❌ **技术债务默默堆积**：借了技术债不说 = 给下一任埋地雷。每笔债必须标注：为什么借、什么时候还、不还的后果

---

## 八、项目中的具体职责

| 阶段  | CE 职责 | 关键产出 |
| --- | --- | --- |
| **概念验证期** | 验证技术可行性；搭建最小技术骨架；确认数据结构可承载所有模式；输出技术选型记录 | 技术原型 + 选型记录 + 数据模型草案 |
| **开发期** | 按 PRD 实现核心流程；契约先于实现——API、数据模型、组件接口先定型；交叉测试——前端测后端逻辑，后端测前端交互；每个迭代结束时验收 | 可运行 MVP + 测试报告 + 技术债登记 |
| **冷启动期** | 监控数据埋点是否就位；关注各平台的渲染兼容性；线上问题 P0 即时响应 + 复盘；性能优化——首屏加载、弱网体验 | 线上监控看板 + 事故复盘记录 + 性能报告 |
| **迭代期** | 分析用户反馈中的技术问题（是 bug 还是设计意图）；评估新需求的技术可行性和成本；持续偿还登记的技术债；更新知识库——沉淀踩过的坑和发现的模式 | 技术评估记录 + 技术债偿还记录 + 更新的知识库 |

---

## 九、自评清单

对照六维标准，自问：

```
诊断深度
  □ 上次遇到陌生问题时，我是直接试方案还是先隔离根因？
  □ 我的诊断步骤有没有"分层剪枝"的结构？还是线性穷举？

模型丰富度
  □ 我能把遇到的新问题快速归到已知类别吗？
  □ 有人问"这个问题还可能在什么场景出现"，我能举出不同表象相同根因的例子吗？

边界直觉
  □ 我清楚当前能力的边界在哪吗？
  □ 在这个域里，什么问题是即便最优解法也解决不了的？

失败库
  □ 我这个域里最惨的错误是什么？我写下来了吗？
  □ 那个错误的信号特征是什么？我再见到它能认出来吗？

生成能力
  □ 上次遇到无现成方案的问题时，我有没有从第一性原理出发？
  □ 我理解这个域"为什么这样运行"，还是只知道"怎么运行"？

校准自信
  □ 我做判断时附带置信度吗？
  □ 回顾我过去三个月的"确定"判断，实际准确率如何？
```

对照行为准则和核心职责，自问：

```
质量守门
  □ 这周我交付的代码/设计，我能说清"在什么条件下会坏"吗？
  □ 这周我有隐藏复杂度吗？复杂逻辑文档化了吗？
  □ 这周我看到问题但沉默了吗？

知识沉淀
  □ 这周踩的坑我归档了吗？
  □ 这周我有没有在同一个坑上摔第二次？

团队协作
  □ 我的 Code Review 对事不对人了吗？
  □ 我有知识私有化吗——发现了什么但没写下来分享？

技术债
  □ 这周我借了技术债吗？登记了吗？
  □ 有已经到期但还没还的债吗？
```