领域 Skill 工厂

把一批资料变成一个真正懂这个领域、能够带人解决问题的 Skill 工具箱。

好的产物不只是摘要。它应该让人看见这个领域的全貌，理解其中最重要的判断，并在遇到具体问题时知道该调用哪套方法。

核心原则

原文是真源

保留原始资料、来源位置和处理范围。AI 拆解稿可以提供线索，但不能替代原文。没有处理完的范围如实说明，不用原子数量制造“已经蒸馏完成”的错觉。

先找这个领域如何运转

不要急着按章节做摘要。先理解：这个领域最终要解决什么问题，事情通常怎样推进，哪些判断最关键，哪些地方最容易卡住。

提炼方法，不制造术语

优先保留作者真正反复使用的底层观点、判断框架、操作方法、案例与边界。可以给方法命名，但名称只是入口，Reference 里必须保留足够解释和例子。

地图负责看全局，Skill 负责解决眼前问题

知识地图展示领域结构和学习路线。实际使用时，根据用户当前材料和问题，选择最相关的方法，不要求所有人机械走完同一条课程。

实践决定知识是否有用

能用真实案例、真实产物或真实反馈检验的内容，优先进入执行 Skill。纯背景知识可以保留在知识库，不必全部改造成训练任务。

开始工作

先读：

• 知识地图方法：怎样从资料中恢复领域全貌与学习路线。
• Skill 套件设计：怎样把方法论组织成类似 DBS/TDS 的路由与执行 Skills。
• 完整工作流：怎样分阶段处理大体量资料。

处理原文时读 原子抽取协议；需要写 JSONL 或运行脚本时读 数据契约；发布前读 质量门。

工作流程

1. 确认这套 Skill 要帮助谁做什么

弄清主要使用者、典型任务和资料边界即可。目标可以是学习一个领域、完成一类工作、辅助行业研究，也可以是为求职准备作品。不要默认把所有项目都写成跨行求职系统。

2. 建立资料底座

python3 scripts/pipeline.py prepare --input <资料路径> --project <工程路径> --name <领域名>

脚本负责登记来源、切块、哈希和状态。检查是否缺章节、混入二次整理稿、存在扫描页或图表遗漏。原始资料不修改，付费全文不进入公开发布包。

3. 先画一张地图草案

根据目标任务、目录、样本章节和真实案例，写出这个领域的大体结构。地图通常会包含：主要阶段或模块、核心方法、能力之间的关系、常见卡点、实践路径和仍待验证的地方。

这些不是固定栏目。销售可以按成交过程组织，开发可以按交付过程和技术能力组织，写作也可以按选题、结构、表达和反馈组织。选择最能解释该领域的形状。

4. 分批提炼知识

读取文本块和必要上下文，提炼定义、原则、判断信号、动作、话术、案例、反例、指标和边界。每条原子保留证据位置；粒度以“以后能够被检索和重新组合”为准，不为追求最小而割裂语义。

python3 scripts/pipeline.py validate-atoms --project <工程路径>
python3 scripts/pipeline.py coverage --project <工程路径>

批量处理使用 next-batch 和 mark-chunks。只有独立复核过的文本块才算完整覆盖。

5. 从方法与卡点中划分 Skills

观察哪些内容共享一套底层判断和工作方式。它们适合成为一个执行 Skill；具体问题、案例和变体放进 References。不要一条知识建一个 Skill，也不要把整本书塞进一个巨型 Skill。

多 Skill 套件通常需要一个路由入口。路由负责理解用户的问题和上一次结果，执行 Skill 负责真正诊断、生成、审查或指导行动。

6. 生成骨架并补充领域内容

python3 scripts/pipeline.py scaffold --project <工程路径>

脚手架只是起点。最终 Skill 应像一位有明确方法论的领域专家：知道自己主要解决什么，有一套稳定判断框架，能结合用户材料工作，并有足够案例说明方法怎样落地。

7. 用真实任务验证

测试它能否识别典型问题、区分相邻情况、使用用户提供的材料、完成有用产物，并在不知道时保持克制。对于强调训练的领域，再测试它能否根据实践反馈调整下一步。

python3 scripts/pipeline.py validate-project --project <工程路径>

结构校验通过后，再运行 Skill 校验和独立前向测试。不要因为目录和字段齐全，就认为内容已经有用。

怎样判断已经完成

至少能够回答：

• 原始资料处理到了哪里，还有什么没处理？
• 这个领域最重要的几套方法是什么，它们之间是什么关系？
• 用户遇到常见问题时，路由能否找到合适的执行 Skill？
• 执行 Skill 是否真的能使用材料做出判断或产物？
• 案例、反例和边界是否足以防止生搬硬套？
• 新资料加入后，能否继续补充，而不推倒重来？

脚本保证工程不乱，Agent 负责把知识理解透。两者不要互相替代。