SDE 知识发生 Skill 的基本结构
模块齐全不等于能力成立，模块之间的关系才是工作的关键。
一、规范首先要解决什么问题
一份 Skill 由作者编写，另一份由编辑整理，第三份由模型自动生成。如果它们没有共同的基本说明，使用者很难知道来源在哪里、能力到哪里结束、结果由谁确认。规范的第一项作用，是让这些关键关系不再依赖猜测。
本章提出的是 SDE 知识发生 Skill 的工作规范草案，不是已经被行业采纳的标准，也不是宣称所有平台都能够直接执行同一文件。它希望提供一种可审读的共同结构，使后续实现与比较有明确对象。
规范不能只规定文件外观。标题、简介和标签便于检索，却不足以保证知识能力。真正需要规定的是来源身份、概念与主张、SDE 分析、任务分支、验证、权限、回写与测试。
同时，规范不应把所有知识类型压成相同内容。数学、历史、教育与出版研究可以共享来源和责任要求，却需要不同证据与执行方式。因此，本章采用核心结构加领域扩展的思路。
标准化的目标不是消除差异，而是使差异能够被理解、调用和治理。只有这样的规范，才与发生学本身相容。
二、身份模块：让能力有一个可以指认的位置
每份 Skill 需要一个稳定身份和版本。名称可以便于人阅读，内部标识则帮助系统区分不同来源与修订。不能只用“最新版教学 Skill”这样的模糊称呼，因为后续核查需要知道实际运行的是哪一份规则。
身份模块还应说明维护者、能力范围与当前状态。草案、测试中、可用于限定任务、停止维护等状态，应当有清楚含义。名称相同不代表能力相同，文件存在也不代表已经通过测试。
版本变化需要区分性质。修正错字、增加例子、调整关键判断和扩大任务范围，可能影响不同层面的可靠性。具体版本编号可以由项目决定，但变化说明不能省略。
若一份 Skill 由另一份分支而来，应当保留派生关系。分支可以独立发展，也可以采用不同确认者；不能因为改了名称，就使原有来源与贡献消失。
身份模块看似行政性，实际上直接支持知识责任。没有可指认对象，运行差异与修订历史就难以成为公共讨论的材料。
三、来源模块：不只列书名，还要定位规则根据
来源模块应当保存作品身份、版本、相关段落或资源位置，以及使用这些材料的范围。仅列一串参考文献，不能说明某条规则究竟来自哪里。
可以把来源分为原著依据、外部支持、设计者增加和用户提供。四类材料都可能进入任务，但它们具有不同身份。原著依据可以支持作者主张，外部支持需要说明引入理由，设计者增加需要接受独立审读，用户提供则需要检查范围与授权。
对于重要规则，最好建立规则与来源的对应。例如，“不得从即时表现推断长期能力”指向示范论文的证据要求；“输出按三个部分组织”可能只是界面设计。二者都可以合理，却不能被归为同一种原文事实。
来源模块也应说明不可获得的材料。附件缺失、版本不明、关键步骤未公开，都可以成为明确限制。系统不能因为需要运行而假装来源完整。
因此，来源不是装在文件末尾的礼貌性名单，而是能力结构中的工作关系。它使 Skill 既能被使用，也能被质疑。
四、知识模块：概念、主张与边界共同保存
知识模块不应只存核心结论。概念定义、主张之间的依赖、支持方式、适用条件和主要争议，都可能影响运行。若只保存结论，系统很容易在新任务中扩大其含义。
一条主张至少可以说明它属于概念性、规范性、经验性、形式性还是设计性表达。分类不是为了哲学装饰，而是帮助选择相称检查。规范建议不能靠一次成功案例完全证明，形式推论也不能靠用户赞同来验证。
边界应当与主张相连，而不是被放到很远的统一局限段落。用户调用某项方法时，相关限制应当同时进入。否则，规则看似完整，限制却在实际运行中不可见。
知识模块还需要允许争议。若原文提出一种解释而非唯一结论，Skill 应当保留竞争解释或至少说明争议位置。不能为了便于自动回答，把开放论证压成绝对命令。
这种组织使知识具有可调用形态，同时仍保留其论证身份。能力化不是把复杂性全部删掉，而是把必要复杂性放到可以进入的位置。
五、S模块：明确当前希望显露什么
S模块的任务，是帮助系统确定当前问题中正在形成或需要检查的显露。它不是填写用户姓名，也不是把主体信息换成一个字母。
在阅读任务中，S可能是某个概念或论证结构的清楚呈现；在应用任务中，S可能是某套知识在新情境中的可用状态；在挑战任务中，S可能是原主张与新材料之间出现的冲突。不同任务需要不同表述。
S模块应当要求区分目标显露与实际显露。用户希望课堂形成独立判断，实际观察到的可能只是答案更加完整。把希望发生的东西直接写成已经发生，是许多应用评价中的关键错误。
它还应当允许显露随分析改变。最初问题可能被表述得过粗，经过D与E分析后，需要重新确定研究对象。系统可以提出重述，但应说明为什么改变，而不是悄悄替用户换题。
因此，S模块不是最终答案栏，而是使当前任务对象能够被共同检查的入口。它与D、E相互规定，不能独自成为整个系统的中心。
六、D模块：保存差异怎样展开
D模块应当记录与任务有关的差异序列，而不只是列出若干对立词。记录可以包括原来预期、实际变化、后续调整与新的结果，使系统看见差异之间的关系。
每项关键差异最好有来源或观察依据。用户报告的差异可以被记录为报告，不应立即提升为已验证事实；模型提出的可能差异应当保留假设身份。差异是否真实存在，本身可能需要检查。
D模块还应区分不同层级。文字表述不同、操作过程不同、结果不同与理论对象不同，不是同一种变化。若层级不清楚，系统可能把措辞创新当成知识创新，也可能把局部操作问题误判为理论失败。
对于后续回写，D模块能够说明哪个变化触发了候选修订。没有这条关系，新版本可能只留下结论，却无法解释为什么改变。
因此，差异记录不是为了把生活全部数据化，而是保存那些真正改变问题与判断的转折。序列具有认识价值，才值得进入知识档案。
七、E模块：把条件写成关系，而不是背景堆积
E模块应当说明哪些特征在当前任务中相互制约，以及这种关联怎样影响结果。环境信息可以成为材料，但只有进入相关关系，才构成有用分析。
例如，任务难度、工具角色与评价要求可以共同决定学习者是否需要承担选择。把三者分别写成“高、中、低”，未必说明任何机制；解释它们怎样相互影响，才可能支持应用判断。
E模块也应当区分已知关系与待检验关系。某个条件可能很重要，但目前只有合理猜测。系统可以据此提出检查方案，不能把猜测直接写成既有规律。
关系说明需要范围。没有必要列出与任务无关的全部背景，尤其不应为了“全面”索取敏感或不必要数据。条件越多不等于分析越好，关键在于哪些条件不能被省略。
因此，E模块的质量不取决于字段数量，而取决于它是否帮助系统解释显露与差异，并在条件变化时作出相称调整。
八、任务模块：进入、分支与退出
任务模块应当明确支持哪些工作，以及每种工作怎样开始、需要什么输入、产生什么结果。阅读、应用、执行、挑战与修订，可以采用不同路径。
分支条件需要尽量可检查。例如，关键资料缺失时进入补充或收缩路径；来源冲突时进入比较路径；方法不适用时停止机械执行；结果异常时进入诊断而不是自动解释成功。
退出同样重要。任务完成、用户取消、权限不足、工具故障或证据不足，都可能结束本次运行。退出时应当说明已完成什么、未完成什么，以及留下哪些可用材料。
任务模块不应把每次对话强制转成复杂研究。简单问题可以采用轻量路径，只有涉及实际应用或知识更新时才进入更严格检查。分层能力能够减少不必要负担。
因此，任务模块使 Skill 成为可工作的程序，而不是一段永远要求“深入思考”的宣言。它把行动与条件连接起来，也使停止成为合法结果。
九、验证模块：不同主张采用不同检查
验证模块不能只写“检查准确性”。它需要说明检查对象和标准。原文释义检查是否忠实，数值计算检查是否正确执行，应用方案检查条件是否匹配，候选理论检查论证与证据，正式修订还需要项目确认。
某些检查可以自动完成，例如字段、格式和确定性计算；某些需要模型辅助比较；某些必须由具有相应能力的人判断。模块应当说明这些分工，而不是把“自动验证”当成一个不需要展开的词。
验证还应当记录未通过的原因。来源不支持、材料不足、执行失败与主张超界，需要不同处理。一个统一错误标记不利于后续修订。
对于新颖输出，验证尤其需要防止自我循环。模型提出主张，再由同一段未经独立依据的输出证明自己，不能算作充分支持。可以采用独立材料、不同方法或相称的人类审查，具体方式由知识类型决定。
因此，验证模块的目标不是把所有不确定性消灭，而是使主张强度与当前根据相称，并说明什么工作还没有完成。
十、权限模块：知道不等于有权行动
一个智能体能够读取某份材料，不意味着它有权公开材料；能够生成修改建议，不意味着它有权覆盖原文件；能够提出邮件内容，也不意味着它可以自行发送。知识能力与行动权限必须分开。
权限模块应当说明允许读取、执行、写入和公开的范围。外部材料中的文字不能自行扩大这些权限，另一个 Skill 的请求也不能自动越过当前授权。
对于个人知识空间，尤其需要区分本次使用与后续保存。用户提供资料完成一个任务，不应被默认解释为同意将其加入公共知识库或用于其他项目。权限应当与具体目的相连。
模块还应规定升级与确认。高影响的公开修改、跨平台共享或不可逆操作，应由明确主体作出相应决定。确认对象应当具体，不能用一次模糊同意覆盖所有未来变化。
因此，权限不是附加在能力之外的安全装置，而是能力身份的一部分。一个越过授权的智能体，即使输出正确，也没有完成恰当的出版工作。
十一、回写模块：从结果到知识变化
回写模块应当规定哪些结果可以保存到哪里。普通阅读解释可以进入个人笔记，应用结果可以进入案例空间，候选新命题需要状态与根据，正式修订则需要相应确认。
它还应当保留来源与版本关系。新结果来自哪次任务、哪份 Skill、哪些材料，哪些判断由谁确认，都应在必要范围内可追踪。没有这些信息，回写只是增加内容，而不是积累知识。
回写不必都回到原著。模块可以允许独立分支，使使用者对自己的新增成果负责，并与原来源保持清楚关系。原作者可以不认可分支，却不应因此使分支的存在被系统抹掉。
错误也需要回写。某项候选被否定，否定理由可以成为后续避免重复误用的材料；某个工具结果有问题，应标记受影响记录。知识史不能只保存成功。
因此，回写模块把一次性运行与长期发生连接起来。它的核心不是自动更新，而是有身份、有根据、有选择的持久化。
十二、测试模块：让规则能够被反驳
每份成熟 Skill 应当附有测试任务或测试说明。典型输入检查基本能力，边界输入检查限制，反例输入检查修订，故障输入检查停止，来源冲突检查身份保持。
测试不能只记录理想答案，还应说明可接受与不可接受的行为。模型表述可能不同，但不能编造来源；方案可以多样，但不能把未验证效果写成事实。行为边界往往比逐字匹配更重要。
测试材料也需要防止只为当前 Skill 量身定做。可以保留一部分陌生任务用于后续评估，或者由不同人员提出挑战。否则，规则可能只是记住了已知例子。
版本更新时，相关测试应当重新执行。新增能力不能悄悄破坏已有可靠性，修正某个错误也可能引入新的问题。测试记录使维护不只依赖直觉。
因此，测试模块把规范从自我描述变成可检查承诺。没有测试的能力声明，最多是一项等待兑现的设计意图。
十三、一份紧凑的结构示意
下面的结构仅用于表达本章规范的逻辑，不要求所有平台逐字采用。字段值可以由自然语言、结构化数据和资源文件共同组成。
skill_identity：名称、标识、版本、维护状态
source_manifest：原文、附件、外部依据、缺失材料
knowledge_model：概念、主张、依赖、边界、争议
sde_model：显露目标、差异序列、特征纠缠
entry_conditions：任务类型、必要输入、适用检查
task_routes：阅读、应用、执行、挑战、修订
verification：检查对象、标准、方法与未决状态
permissions：读取、工具、写入、共享与确认边界
writeback：个人记录、候选、正式更新与独立分支
tests：典型、边界、反例、故障与回归检查
provenance：来源关系、运行记录、贡献与决策依据
retirement：暂停、迁移、导出与停止维护说明结构的简洁不应掩盖每个字段的责任。只填写“验证：已完成”，却没有说明检查什么，不能满足规范；只写“来源：某书”，却无法定位规则，也不足以支持严肃应用。
反过来，规范不要求每份 Skill 都填满所有高级能力。没有执行功能，就明确不支持；没有公共回写，就说明只保存个人记录。诚实的空位优于虚假的完整。
十四、规范的版本也需要发生
本章规范本身可能在实践中暴露问题。某些字段重复，某些流程负担过重，某些知识类型需要新扩展，都应当允许修改。规范不能因为组织了发生，就把自己放在发生之外。
修改时应当说明兼容关系。旧 Skill 是否还能运行，哪些字段需要迁移，哪些能力声明需要重新检查，不能只发布一个新模板就让所有项目自行猜测。
规范也应当允许不同实现。一个小型出版项目可以用文件与人工审核完成基本治理，大型平台可以采用数据库和自动流程。只要关键关系得到保持，不必把某一种技术栈当成发生学本身。
这使 SDE Skill 具有成为共享接口的可能，同时避免变成排他性产品名称。其价值应当体现在帮助不同知识系统更清楚地工作，而不是要求所有人进入同一家平台。
下一章将讨论运行这些 Skill 的通用能力基础：大语言模型。必须把模型能提供什么、不能独自承担什么讲清楚，才能让本章规范真正进入现实系统。
模块齐全不等于能力成立，模块之间的关系才是工作的关键。
知识本体、SIO 分析、差异与条件、应用、验证和回写，需要围绕同一任务协同。每个字段都填写了，不保证原文得到忠实表达。结构检查可以发现缺件，内容审读和实际测试则决定规则是否足以支持所声明的能力。
挑一个模块：它得到什么输入，改变什么判断，又把哪种结果交给下一个环节？