深度思考：基于第一性原理重构本地 Skills
把“技能库”变成可执行的输入/输出合约与反馈回路（以 Obsidian 为载体）
用第一性原理重构本地 Skills：从目标函数到可复用 SOP
第一性原理Obsidian个人知识管理SOP技能库复盘
TL;DR
- 本文将“本地 skills”定义为：你在 Obsidian/本地知识库里沉淀的可复用“问题→行动→产出”SOP/模板卡（不是职业技能树）。
- 第一性原理落地的起点不是写模板，而是写清：目标函数（优化什么）、硬约束（不能违反什么）、成功指标（如何验收）。
- 把每个 Skill 设计成“函数/API 合约”：明确触发器与输入，定义输出物与验收指标，并预先列出失败模式与回滚方案。
- 改造路径：先做1个高频场景的最小 Skill → 用 Templater/QuickAdd 自动创建 → 用 Dataview 聚合索引 → 每次使用后2分钟复盘迭代。
Key Insights
- 你要解决的本质往往不是“缺少方法”，而是“重复问题每次都重新检索与重新决策”，导致时间成本与心理摩擦持续累积。
- 第一性原理的价值在于把复杂问题还原为：目标、约束、事实、可控变量；然后用最小可验证方案（MVP）快速闭环，而非一次性做“完美体系”。
- Skill 内容建议分三层管理：原则（Why）/启发式（What）/SOP（How）；把变动频率不同的内容隔离，降低维护成本与认知噪音。
- “可复用”依赖标准化：统一命名、统一元数据字段、可搜索的依赖关系（前置 Skill/工具/参考），否则技能库会退化为“收藏夹”。
Playbook
- 选题：从过去14天日志/任务记录中抽取反复出现的场景，筛选满足“高频（≥3次）×高耗时（≥30min）×可评估”的1个问题做试点。
- 第一性原理拆解：写出目标函数（例：把周报从90分钟降到30分钟）、硬约束（受众/格式/必须包含项/合规要求）、不可再分的事实清单；用 Five Whys 追到最底层阻塞点。
- 设计 Skill 合约：触发器（何时用）、输入（你已有的素材/数据）、步骤（控制在≤9步）、输出物（文档/决策/文件）、验收指标（是否达标）、风险与回滚（失败如何止损）。
- Obsidian 实装：用 Templater/QuickAdd 一键生成 Skill 卡；用 Dataview 做 Skills Index 与状态看板；（可选）用 Git 对 Skills 目录做版本管理以便回滚与对比。
示例：Skill 卡模板（可直接做成 Templater 模板）
---
type: skill
status: draft
trigger:
inputs:
outputs:
metric:
time_cost_min:
risk:
deps:
---
建议正文结构：目的/第一性原理 → SOP步骤 → 常见失败模式 → 复盘记录（时间、结果、改动点）
示例：Dataview 索引（聚合全库技能）
TABLE status, metric, time_cost_min, trigger
FROM "Skills"
WHERE type = "skill"
SORT status ASC
Diagrams
Options
- 方案A（本文采用）：Skills=Obsidian 内可复用 SOP 卡；交付物是模板+索引+复盘字段，目标是减少重复决策与执行时间。
- 方案B（另一种定义）：Skills=本地 AI/Agent 的工具能力（函数调用/脚本/工作流）；重点是接口化（参数/返回值/错误码）、可观测性（日志/指标）、回滚与权限控制。
- 方案C（另一种定义）：Skills=职业能力模型/技能树；重点是分级标准、训练计划、作品集证据与评估，而不是 SOP 自动化。
- 方案D（混合）：同一 Skill 同时包含人执行 SOP + 机执行脚本入口 + 训练任务；用统一元数据把三者关联，既能落地又能长期成长。
Expert Views
- 产品经理视角（paraphrase）：把每个 Skill 当成“解决一个具体 Job 的产品”，先定义用户价值与验收指标（速度/质量/一致性），反对为模板美观与复杂字段过早优化。
- 开源自动化工程师视角（paraphrase）：强调“可组合、可测试、可版本化”，建议关键步骤脚本化（Shell/Python/Node CLI），并在 Skill 中固定输入输出样例与日志位置，便于复现与回滚。
- 学习科学/训练教练视角（paraphrase）：关注“使用次数驱动的刻意练习”，建议每个 Skill 增加“常见错误/纠偏动作/练习任务”，并用间隔复习提醒避免只收藏不执行。
- 隐私与安全工程师视角（paraphrase）：本地库包含个人敏感信息时优先本地处理与最小权限；插件/脚本要评估数据外发风险，敏感字段不要进入公开仓库历史记录。
Evidence & Confidence
- “输入/输出/验收指标”的 Skill 合约能提升复用性：medium（符合工程化最佳实践，但个人收益依赖执行纪律与使用频率）。
- Dataview/Templater/QuickAdd 能实现自动生成与索引：high（存在公开文档/仓库可查；此处无法在线核验当前可用性与版本差异）。
- 将内容分层（原则/启发式/SOP）能降低维护成本：medium（常见知识管理做法合理，但需要你持续归档与重构）。
- 每次使用后2分钟复盘能加速技能迭代：medium（与反馈回路/刻意练习理念一致，但提升幅度需用你的耗时与达标数据验证）。
Next Steps
- 建一个“问题池”页：列出近两周10个重复问题，并给每条打分：频率、耗时、情绪成本（1-5分）。
- 选Top1问题写清：目标函数、硬约束、成功指标与输出物格式；明确哪些信息是“必须输入”。
- 按模板创建第一个 Skill；配置 QuickAdd 快捷入口；固定目录（如 /Skills）与命名规范（如“Skill-动词-对象”）。
- 建 Skills Index（Dataview 表格+状态字段）；两周内至少使用5次并记录耗时/是否达标，基于数据改到 v2。
Details (Optional)
Details
TL;DR
- 本文将“本地 skills”定义为：你在 Obsidian/本地知识库里沉淀的可复用“问题→行动→产出”SOP/模板卡（不是职业技能树）。
- 第一性原理落地的起点不是写模板，而是写清：目标函数（优化什么）、硬约束（不能违反什么）、成功指标（如何验收）。
- 把每个 Skill 设计成“函数/API 合约”：明确触发器与输入，定义输出物与验收指标，并预先列出失败模式与回滚方案。
- 改造路径：先做1个高频场景的最小 Skill → 用 Templater/QuickAdd 自动创建 → 用 Dataview 聚合索引 → 每次使用后2分钟复盘迭代。
Key Insights
- 你要解决的本质往往不是“缺少方法”，而是“重复问题每次都重新检索与重新决策”，导致时间成本与心理摩擦持续累积。
- 第一性原理的价值在于把复杂问题还原为：目标、约束、事实、可控变量；然后用最小可验证方案（MVP）快速闭环，而非一次性做“完美体系”。
- Skill 内容建议分三层管理：原则（Why）/启发式（What）/SOP（How）；把变动频率不同的内容隔离，降低维护成本与认知噪音。
- “可复用”依赖标准化：统一命名、统一元数据字段、可搜索的依赖关系（前置 Skill/工具/参考），否则技能库会退化为“收藏夹”。
Playbook
- 选题：从过去14天日志/任务记录中抽取反复出现的场景，筛选满足“高频（≥3次）×高耗时（≥30min）×可评估”的1个问题做试点。
- 第一性原理拆解：写出目标函数（例：把周报从90分钟降到30分钟）、硬约束（受众/格式/必须包含项/合规要求）、不可再分的事实清单；用 Five Whys 追到最底层阻塞点。
- 设计 Skill 合约：触发器（何时用）、输入（你已有的素材/数据）、步骤（控制在≤9步）、输出物（文档/决策/文件）、验收指标（是否达标）、风险与回滚（失败如何止损）。
- Obsidian 实装：用 Templater/QuickAdd 一键生成 Skill 卡；用 Dataview 做 Skills Index 与状态看板；（可选）用 Git 对 Skills 目录做版本管理以便回滚与对比。
示例：Skill 卡模板（可直接做成 Templater 模板）
---
type: skill
status: draft
trigger:
inputs:
outputs:
metric:
time_cost_min:
risk:
deps:
---
建议正文结构：目的/第一性原理 → SOP步骤 → 常见失败模式 → 复盘记录（时间、结果、改动点）
示例：Dataview 索引（聚合全库技能）
TABLE status, metric, time_cost_min, trigger
FROM "Skills"
WHERE type = "skill"
SORT status ASC
Expert Views
- 产品经理视角（paraphrase）：把每个 Skill 当成“解决一个具体 Job 的产品”，先定义用户价值与验收指标（速度/质量/一致性），反对为模板美观与复杂字段过早优化。
- 开源自动化工程师视角（paraphrase）：强调“可组合、可测试、可版本化”，建议关键步骤脚本化（Shell/Python/Node CLI），并在 Skill 中固定输入输出样例与日志位置，便于复现与回滚。
- 学习科学/训练教练视角（paraphrase）：关注“使用次数驱动的刻意练习”，建议每个 Skill 增加“常见错误/纠偏动作/练习任务”，并用间隔复习提醒避免只收藏不执行。
- 隐私与安全工程师视角（paraphrase）：本地库包含个人敏感信息时优先本地处理与最小权限；插件/脚本要评估数据外发风险，敏感字段不要进入公开仓库历史记录。
Options
- 方案A（本文采用）：Skills=Obsidian 内可复用 SOP 卡；交付物是模板+索引+复盘字段，目标是减少重复决策与执行时间。
- 方案B（另一种定义）：Skills=本地 AI/Agent 的工具能力（函数调用/脚本/工作流）；重点是接口化（参数/返回值/错误码）、可观测性（日志/指标）、回滚与权限控制。
- 方案C（另一种定义）：Skills=职业能力模型/技能树；重点是分级标准、训练计划、作品集证据与评估，而不是 SOP 自动化。
- 方案D（混合）：同一 Skill 同时包含人执行 SOP + 机执行脚本入口 + 训练任务；用统一元数据把三者关联，既能落地又能长期成长。
Evidence & Confidence
- “输入/输出/验收指标”的 Skill 合约能提升复用性：medium（符合工程化最佳实践，但个人收益依赖执行纪律与使用频率）。
- Dataview/Templater/QuickAdd 能实现自动生成与索引：high（存在公开文档/仓库可查；此处无法在线核验当前可用性与版本差异）。
- 将内容分层（原则/启发式/SOP）能降低维护成本：medium（常见知识管理做法合理，但需要你持续归档与重构）。
- 每次使用后2分钟复盘能加速技能迭代：medium（与反馈回路/刻意练习理念一致，但提升幅度需用你的耗时与达标数据验证）。
Next Steps
- 建一个“问题池”页：列出近两周10个重复问题，并给每条打分：频率、耗时、情绪成本（1-5分）。
- 选Top1问题写清：目标函数、硬约束、成功指标与输出物格式；明确哪些信息是“必须输入”。
- 按模板创建第一个 Skill；配置 QuickAdd 快捷入口；固定目录（如 /Skills）与命名规范（如“Skill-动词-对象”）。
- 建 Skills Index（Dataview 表格+状态字段）；两周内至少使用5次并记录耗时/是否达标，基于数据改到 v2。
Sources
- First principle（概念）：https://en.wikipedia.org/wiki/First_principle（无法在线核验）
- Five whys（根因分析）：https://en.wikipedia.org/wiki/Five_whys（无法在线核验）
- Obsidian 官方帮助文档：https://help.obsidian.md/（无法在线核验）
- Obsidian 社区插件：Dataview https://github.com/blacksmithgu/obsidian-dataview ，Templater https://github.com/SilentVoid13/Templater ，QuickAdd https://github.com/chhoumann/quickadd（均无法在线核验）
Sources
- First principle（概念）：https://en.wikipedia.org/wiki/First_principle（无法在线核验）
- Five whys（根因分析）：https://en.wikipedia.org/wiki/Five_whys（无法在线核验）
- Obsidian 官方帮助文档：https://help.obsidian.md/（无法在线核验）
- Obsidian 社区插件：Dataview https://github.com/blacksmithgu/obsidian-dataview ，Templater https://github.com/SilentVoid13/Templater ，QuickAdd https://github.com/chhoumann/quickadd（均无法在线核验）
Closing Summary
- 结论：用第一性原理重构本地 Skills：从目标函数到可复用 SOP
- 下一步：先选1个高频痛点，用“Skill合约模板”在Obsidian落地，并用Dataview做索引与复盘闭环。
One next action
先选1个高频痛点，用“Skill合约模板”在Obsidian落地，并用Dataview做索引与复盘闭环。