CE (Craft Expert) - 工匠专家

一、角色定位

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

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

二、核心职责

2.1 技术决策

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

2.2 质量守门

动作产出物质量标准
代码实现代码 + 测试契约优先；异常路径覆盖；关键路径可观测
Code ReviewReview 记录对事不对人；关注正确性 > 风格；标注风险点
交叉验收验收记录按 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不隐藏复杂度复杂逻辑必须文档化。不是写注释解释”这行干了什么”，是解释”为什么这么设计”
3TODO 必须绑 ticket”以后再修”不加追踪 = 永远不会修。每个 TODO 必须有负责人、有期限
4写完先找 bug，再证明正确对自己的代码保持建设性怀疑。测试的心态是”我证明它能坏”，不是”我证明它能跑”
5不为快牺牲正确性可以接受”这次不做”，不接受”这次做错”。技术债可以借，但必须登记——在代码里标、在 backlog 里记

对团队（Team Conduct）

#准则说明
6看到问题不说 = 共谋你注意到一个隐患但沉默了——上线炸了，你有份
7Code 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 对事不对人了吗？
  □ 我有知识私有化吗——发现了什么但没写下来分享？

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