教模型记笔记:为什么有一类 skill 模型再聪明也替代不了 📅 2026/8/5 7:59:01 能力增长会消灭很多 skill那些教模型怎么想的模型自己会想了就该拆。但它消灭不了教模型你这里是什么样的那一类——私有格式、内部约定、只有你知道的输入长相。模型可以无限聪明但它猜不到你没告诉它的事。只要你有一套自己的约定就总得有一份东西把它写下来递到模型这一轮的上下文里。这类 skill 的寿命和你的私有约定一样长。这套约定长什么样私有库有几条死规矩都不复杂但都不是模型能推出来的根目录扁平不建子文件夹——分类靠链接不靠目录树。文件名一律 Title CaseRalph Wiggum Index.md这样带空格、首字母大写。每篇笔记底部挂[[wikilinks]]指向相关笔记笔记之间连成网。同类笔记由一个* Index.md聚合是这一类的入口页。这套组合不是随便定的扁平 标准命名让find和grep一抓一个准wikilink 让知识互相可达Index 给每一类一个稳定入口。三者合起来才让一个纯文件夹变成能被检索、能被关联的知识网——而不是一堆躺在硬盘上、彼此不认识的 markdown。约定开源内容不开源这个 skill 目录里放了个.gitignore只忽略一样东西——memory/也就是笔记真正存放的地方。于是同一个 skill 目录被切成两半SKILL.md 里的约定怎么命名、怎么链接、怎么建索引随仓库开源谁都能拿去用memory/里的笔记内容留在本地永不进 git。可公开的是怎么记私有的是记了什么。这和整件事的道理是同一个喂给模型的应该是约定不是内容。约定是可复用、可分享、值得写死的那层内容是你私人的、每个库各不相同的那层。一个 skill 携带前者.gitignore挡住后者——它自带了哪些该共享、哪些该留下的判断。为什么模型再强也猜不到LLM 能写出漂亮的代码能推理复杂的逻辑但它没法知道这个库用 Title Case 而不是 snake_case靠链接而不是文件夹分类。这不是智力问题是信息问题——私有约定不在它的训练数据里也不在这一轮的上下文里。不在上下文里的东西对这一轮的模型就等于不存在。于是没有这个 skill模型会落入两种都不理想的处境。多数时候它直接按默认习惯行动顺手建个子文件夹分类用它习惯的camelCase命名写完笔记就走、不挂任何链接——一个崭新的孤岛既搜不到也关联不上。即便模型足够聪明、选择先花时间探索再顺应项目代价是额外的工具调用和 token。两条路一条错、一条贵而一份写死的 skill 能把两条都省掉。skill 在这里的作用本质上是喂证据告诉模型输入从哪来、长什么样、该往哪写。自定义格式就是这样一种证据。注本 skill 的设计遵循 write-skill。开源链接maintain-ai-research-vaultmaintain-ai-research-vaultdescription: 维护或搜索 AI Research Obsidian 库中的笔记。当用户要求创建、查找或组织该特定库中的笔记时使用。维护 AI Research 库范围与边界目标路径根据上下文假设更倾向使用本SKILL相对路径./memory/。结构根目录扁平化。不使用子文件夹进行组织。命名标题大写Title Case例如Ralph Wiggum Index.md。动作1. 搜索笔记输入关键词或文件名。行为按文件名搜索find Target Path -name *.md | grep -i keyword按内容搜索grep -rl keyword Target Path --include*.md完成标准返回确切的文件路径或确认未找到匹配项。2. 创建新笔记输入主题标题内容。行为预检查执行“搜索笔记”以防止重复。如果已存在则改为建立链接。命名将输入转换为Title Case。如有需要验证文件名中不含空格Obsidian 通常处理空格但需遵循标准。位置直接在Target Path的根目录下创建文件。内容编写学习单元内容。链接在底部追加“相关笔记”部分包含[[wikilinks]]。索引识别相关的* Index.md文件并追加新笔记链接。完成标准文件以 Title Case 名称创建于根路径包含[[wikilinks]]且至少更新了一个 Index 笔记。3. 查找相关笔记 (反向链接)输入笔记标题。行为在整个库中搜索[[Note Title]]。命令grep -rl \\[\\[Note Title\\]\\] Target Path完成标准返回链接到目标笔记的文件列表。约束 (硬性护栏)禁止在Target Path下创建子文件夹进行分类。禁止对文件名使用 CamelCase 或 snake_case使用带空格的 Title Case。禁止在未追加[[wikilinks]]的情况下完成笔记创建。