fde-skills：让 FDE 交付物会记住经验的开源技能包
干了第三个客户，交付的还是同一批文档：风险登记表、集成规格、干系人地图。每份都从空白页开始——尽管前两单已经教会了你其中大部分该写什么。
mk668a/fde-skills（MIT 许可）就是针对这个痛点：让交付物 schema 跨客户累积证据，第三次出现自动"铺路"成模板。
一、FDE 的隐性重复劳动
Forward Deployed Engineer（FDE）的日常工作，一半是写代码，一半是写交付物：业务诊断、风险登记、集成规格、干系人地图、上线计划……
问题在于：这些文档每次都是从零开始。客户的行业不同、系统不同，但文档的"骨架"高度相似——你要判断的维度、要避开的坑、要问的问题，前一单早就教过你一遍。
这个仓库的切入点是：重复不是要避免的坏事，而是要利用的资产。 只要把"经验如何沉淀"做成机制，第 N 个客户就会比第 N-1 个客户更轻松。
二、它是什么
项目分两半：
- 精选工具箱：按 engagement 生命周期（发现→共建→交付→交接）排列的第三方仓库清单，例如
github/spec-kit（模糊需求转可执行规格）、anthropics/skills（官方文档技能）、microsoft/presidio（客户数据 PII 脱敏）、makeplane/plane（自托管项目管理）等。 - 四个自有技能：解决清单里没有任何仓库解决的问题——"交付物会记住"。安装只需一条命令，无市场、无 API Key、无托管后端。
四个技能的分工：
| 技能 | 触发场景 | 做什么 |
|---|---|---|
/fde-init | "新接一个 Acme 客户" | 一次性搭好 .fde/ 骨架 + 每个客户一个目录 |
/fde-draft | "起草 Acme 的风险登记表" | 用当前客户笔记填表，并自动预填前几单沉淀的经验，报告覆盖率 |
/fde-promote | "把这些经验变成可复用的" | 去标识化、统计出现次数，第 3 次出现时把 schema 本身升级 |
/fde-recall | "过去类似 pilot 我们学到什么？" | 按出现频次加权，调出匿名化的历史先验 |
三、核心机制：Rule of Three 被机械化
Fowler 在《Refactoring》里说"不要从单个例子做泛化，第三次再提取"。在这里，这条建议变成了 shell 脚本里的一个计数器：
| 出现次数 | 层级 | /fde-draft 的行为 |
|---|---|---|
| ×1 | candidate | 以 [候选 ×1：请确认] 形式提供（只代表一个客户的看法） |
| ×2 | recurring | 以 [候选 ×2：请确认] 形式提供 |
| ×3 | paved（铺路） | 默认预填；如果是新维度，schema 本身新增该槽位并升级版本号 |
铺路时刻是真实的、git diff 可见的 schema 变更——不是玄学，是版本化的经验：
PAVED: risk-register v1 -> v2: + rollback_plan (3 sightings)
-version: 1
+version: 2
-evolved_slots: []
+evolved_slots:
+ - id: rollback_plan
+ label: Rollback plan
+ prompt: "How do we return to the pre-pilot state if go-live fails?"
+ paved_from: "3 sightings, 2026-07-04"
三个客户跑下来，第三个客户的风险登记表第一天就有 5/6 的槽位是继承来的，不用重敲。
四、两层架构：判断归 LLM，统计归脚本
这个设计值得所有做"经验复用"的人抄：
- LLM 层（
skills/*）：负责读杂乱笔记、填槽、把客户特有信息改写掉、判断什么值得沉淀。 - 确定性 spine（
.fde/bin/*.sh）：负责计数、去标识、闸门、铺路、渲染 dashboard。纯 shell，无 LLM 调用，可复现、可审计。
覆盖率的数字、sighting 计数器、去标识闸门、dashboard 全是普通 shell；判断的活儿留给 Claude Code。运行时没有任何 LLM 调用，也没有托管后端。
五、去标识化：闸门，不是承诺
客户数据不上 GitHub——这是硬纪律：
- 强制层（确定性）：
fde-validate.sh检查任何客户 slug、客户名 token 是否泄漏到共享层；fde-promote.sh在临时文件里构建合并语料，结果若泄漏标识符则拒绝写入。金额和百分比一律剥离。 - 判断层（LLM + 你）：人名、内部系统名、一读就知道是谁的措辞，由
/fde-promote改写掉。
/fde-init 还会把 engagements/ 和 dashboard 加进 .gitignore。仓库的立场很明确：push 到远程等于不可逆（clone、fork、缓存、代码搜索索引都会留痕），私有仓库也不是安全港——只有匿名化的语料和 schema 可以提交。
六、对我们的启示
- 交付物 = 版本化的 schema，不是一次性文档：这一条直接适用于 FDE 客户的诊断-交付流程。每次客户访谈、诊断、交付都应该喂给一个可进化的模板体系。
- 经验沉淀要有计数器："三次才固化"是防止过度泛化的好规则，也给了团队一个可讨论的机制，而不是靠某个人记得。
- 判断与统计分层：AI 负责"判断什么值得留"，脚本负责"保证不留错"——审计与效率不冲突。
- 隐私是机制不是承诺：把"客户名字不能出现在远程"做成脚本检查，比写进团队规范可靠得多。这与我们案例库"来源方披露不代表独立审计"的严谨是一路的。
项目地址：github.com/mk668a/fde-skills（MIT，含 15 秒可跑的 demo：examples/demo.sh，无需 LLM，所有数字由 spine 脚本打印）。