修改并扩充从一份原稿生成、供多个 AI 工具使用的指令集

## 修改前，先找出负责这项功能的部分 将仓库视为一组职责归属明确的层，而不是松散的文件集合。编辑前，先确定哪一层负责所请求的行为： - 源指令定义可复用的面向用户的操作； - 共享参考文档定义跨领域的契约和模式； - 辅助脚本实现可重复执行的处理； - 适配器将规范指令转换为平台专用软件包； - 生成的发行内容包含可重新构建的输出； - 钩子负责强制执行仓库规则和输出规则； - 架构文档和操作手册说明各层如何协作； - 依赖项文件和安装文件定义受支持的运行环境。 以规范源文件层为权威依据。生成的发行内容是构建能够正常工作的证据，而不是独立的事实来源。不要直接编辑这些内容，应通过文档规定的构建流程重新生成。 追溯控制所请求行为的最小权威文件，然后识别依赖它并且需要同步的每一份文档、模式、测试和生成产物。 ## 原稿只保留一份，各 AI 工具的版本由转换程序生成 使用一种与平台无关的源格式管理可复用指令。让适配器完成每个受支持环境所需的打包和语法转换。 适配器可以： - 在不改变语义的情况下复制兼容源文件； - 为每项操作生成一个原生技能包； - 组装具有多个入口的共享引擎； - 构建包含提示词和辅助技能的平台软件包； - 根据源文件元数据生成调度器和路由表。 适配器必须保留原始行为和约束。当目标环境使用不同工具时，将平台专用工具名称转换为中性的操作描述。应根据规范说明生成路由元数据，而不是维护第二份手写目录。 添加操作时，只编辑一次其规范源文件。只有在该操作无法于某个平台运行时，才使用明确的平台排除设置。重新构建所有受影响的适配器，并检查其输出是否发生语义偏移。 ## 每条保存的笔记都标明出处和可信程度 所有写入知识产物的操作都必须遵守仓库的规范写入契约。设计产物时，应确保未来能够可靠检索和推理，而不能只考虑眼前的人类可读性。 要求每项产物包含： - 一段向未来的 AI 读者说明其用途的简短前言； - 产物类型、日期、标签和明确的 `AI-first` 标记等结构化元数据； - 指向所引用人物、项目、想法和决策的稳定内部链接； - 为可能过时的主张标注时效信息； - 在外部主张旁原样保留来源 URL； - 用于区分明确陈述的事实、强证据、中等证据和推测的置信度标签。 不得为了让产物看起来更简洁而移除元数据、链接、出处或置信度信号。如果一项操作引入新的产物类型，应先扩展共享模式，再生成该类型。 ## 使用自动检查能确认的书写规则 使用格式化工具和钩子能够一致验证的规范： - Markdown 标题采用句首式大小写； - 指令源文件中不使用装饰性表情符号； - 除非非 ASCII 符号具有独立含义，否则使用 ASCII 标点而不使用排版替代符号； - 标签值使用小写，并为含义可能不明确的元数据字符串加引号； - 遵循已配置的语言版本、格式化工具、行长限制和依赖项管理器； - commit 标题使用祈使语气，并遵循仓库的署名归属政策。 对于机械化样式，以规范格式化工具和验证钩子为最终依据。不得绕过它们，也不得手动保留它们所拒绝的格式。 规范的范围应足够明确，以便自动强制执行。如果某项规则无法机械验证，应记录确认该规则所需的审查证据。 ## 新增功能时，同时更新说明书和清单 添加新操作时使用以下顺序： 1. 创建包含路由元数据和完整操作说明的规范指令源文件。 2. 只有在需要可执行逻辑时，才在指定的脚本区域添加辅助程序。 3. 从每一条能够创建或修改产物的路径引用共享写入契约。 4. 引入新的产物类型前，先扩展共享元数据模式。 5. 更新操作手册、能力清单、架构说明和公开命令目录。 6. 在变更日志的未发布部分记录该变更。 7. 运行适配器构建，并检查每个受影响平台的输出。 不要在生成的平台目录树中复制操作。同步变更应同时更新源文件、适用的参考规范、测试和文档，确保后续重新构建不会抹去或违背这些内容。 ## 把指令本身的行为和生成版本的流程分开测试 分别测试源行为和生成管道。使用隔离的测试工作区或链接的本地检出，而不是正在使用的知识库。 验证行为时： - 使用具有代表性的测试数据调用已更改的操作； - 检查生成的产物； - 验证必需的元数据、链接、出处、置信度标签和其他写入契约字段； - 确认未知事实仍被明确标记为未知。 验证管道时： - 通过已配置的软件包运行器执行仓库的冒烟测试套件； - 验证适配器输出位置和生成的路由； - 测试辅助脚本接口和机器可读输出； - 如果有意更改输出布局，在同一项变更中更新对应的断言。 先运行范围最小的相关测试，再运行受影响的冒烟测试套件。手动行为检查用于补充自动测试，不能取代自动测试。 ## 检查通过后，只由有权限的人发布新版本 只有在持续集成全部通过，并且面向机器的写入契约仍然得到满足时，才进行发布。 使用受控的发布顺序： 1. 将未发布的变更日志条目移到带日期的版本标题下。 2. 更新主要软件包文件以及每个镜像清单或引用信息文件中的版本。 3. 运行偏移检查，比较所有版本声明。 4. 重新构建生成的发行内容，并运行受影响的测试。 5. 在创建标签或 push 前，确认发布角色和分支政策。 6. 根据已批准的变更日志条目发布版本说明。 保护共享默认分支。贡献者应使用规定的审查路径。只有当仓库政策明确授予维护者相应权限，并且相同的验证门槛均已通过时，维护者才可以直接发布。 ## 不编造缺失的事实，也不手动修改自动生成的文件 绝不能为了外观而削弱系统的检索契约。不得移除必需的前言或元数据，不得仅为了让表述更像人类而改写面向机器的产物，也不得添加源文件规范禁止的装饰元素。 不得编造比率、日期、所有权、关系或其他缺失的事实。使用 `TBD` 或仓库规定的等效显式未知标记来标注未知值。 当生成器拥有产物的管理权时，绝不能编辑生成产物。不得绕过钩子、通过未经授权的分支发布，也不得仅凭检查源文件就宣称成功。 报告完成前： - 审查完整的预期差异，确认没有无关更改； - 确认规范源文件与生成产物一致； - 运行相关格式化工具、钩子、测试和适配器构建； - 验证需要同步的模式、手册、目录和变更日志条目； - 记录所有手动验证，以及任何无法运行的检查； - 确认最终发布操作符合获授权的角色。 报告已更改的行为、验证证据、剩余限制以及仍需决定的事项。