为AI编程助手构建“工具大脑”：告别重复教学，固化肌肉记忆-编程实验室

1. 项目概述：为AI编程助手构建“肌肉记忆”

上周二，我让Claude Code帮我压缩一批PDF文件以便邮件发送。它花了两分钟研究ghostscript的参数，尝试了三种错误的组合，最后生成的文件居然比原始文件还大。讽刺的是，两周前我刚刚用同一个助手、同一个工具、同一套参数完美解决了这个问题。但Claude Code不记得什么方法是有效的。每一次会话，它都从零开始。它会重新研究同一份ghostscript文档，在同样的错误默认值上磕磕绊绊，如果运气好，最终会找到它之前已经找到过的答案。有时候，它会找到一个更糟的方案。

这不仅仅是Claude Code的问题。这是当前所有AI编程助手工作方式的一个结构性缺陷。它们拥有巨大的智能，却完全没有“肌肉记忆”。这个没人谈论的鸿沟在于：AI助手在解决复杂问题上确实很出色，比如架构决策、复杂的重构、调试竞态条件、编写解析器——这些需要推理的事情。但如果你让它将一个PNG图片以85%的质量转换为WebP格式且不覆盖原文件，它会花三十秒去阅读ImageMagick的文档，仿佛从未见过一样。它其实见过，只是它记不住。

同样的事情也发生在视频压缩的ffmpeg参数、PDF处理的qpdf命令、图像优化的pngquant工具上。每一次会话，助手都把这些当作需要研究的新问题来对待。它们并非新问题。它们是那几十个被重复了上百次的操作，而每个操作的正确方法早在多年前就被日常使用这些工具的人们确立了。

我一直在观察这种现象。不是发生在难题上，而是发生在那些琐碎的任务上。助手可以出色地完成一个复杂的数据库迁移，却会在“让这个JPEG图片变小点”这种任务上卡壳。这就像与一位才华横溢但永远记不住咖啡机在哪的同事共事。

于是，我花了一周时间，构建了一个我称之为“工具大脑”的东西。它由六个用纯Markdown编写的技能文件组成，为AI编程助手提供了那些它总是要从头开始研究的操作的可靠默认方案。这六个技能分别是：PDF处理、图像处理、视频处理、音频处理、文件操作和自动化。整个技能包大约54KB，比大多数README文件还要小。关键在于，它改变了我们与AI助手协作的底层逻辑——从不断重复教学，转变为赋予其可靠的、可复用的经验。

2. 核心设计思路：从“零记忆智能体”到“经验赋能伙伴”

构建这个工具大脑的过程，让我重新审视了AI编程助手的本质。我们通常把它们当作需要更好提示语的初级开发者。但我觉得这个类比不准确。它们更像是一位才华横溢的承包商，每天早晨都来到一个新的工地，对昨天的工作毫无记忆。问题不在于智力，而在于它们对于日常工作没有“默认设置”，没有“肌肉记忆”。

2.1 技能即肌肉记忆：压缩经验，释放智能

“技能”就是AI的肌肉记忆。助手不需要在ghostscript参数上展现聪明才智；它只需要记住，对于邮件附件，-dPDFSETTINGS=/ebook是正确的选择，并且明白这种质量权衡是可以接受的。这不是推理，这是被压缩成315行Markdown的经验。

我的核心思路是：将开发者高频、重复、琐碎的操作，固化成一套AI可读、可理解、可执行的“协议”或“技能手册”。这并非编写脚本让AI盲目执行，而是将意图、逻辑、最佳实践和安全规范清晰地表述出来，让AI能够“理解”任务背后的领域知识，从而做出与经验丰富的开发者一致的选择。

2.2 四层架构的涌现：从失败中提炼的模式

我最初并没有一个宏伟的设计图。这个四层架构是在我反复解决同一类失败的过程中自然涌现出来的。每一层都对应着AI助手在实际操作中暴露出的一个特定弱点。

路由层：AI首先需要理解你的真实意图。你说“把这个弄小点好发邮件”，它需要能路由到“有损压缩，并针对邮件附件设定特定质量目标”。而“把这些归档”则应该路由到完全不同的处理流程。早期版本中，AI经常错误理解请求，导致执行了风马牛不相及的操作。清晰的意图检测逻辑解决了这个问题。
领域逻辑层：这里是真正知识沉淀的地方。质量预设、格式特定的规则——那些每天使用ghostscript的开发者了然于胸的东西。默认值不是泛泛而谈的，而是为特定用例产出良好结果的具体数值。例如，电子书PDF压缩、印刷级PDF压缩和“我需要邮件发送这个PDF”所使用的设置是完全不同的。这一层封装了“为什么用这个参数”的上下文。
执行层：这一层处理现实的混乱。AI需要检测你机器上安装了哪些工具，选择最优可用项，并在首选工具缺失时提供备用方案。如果系统没有安装ghostscript，它会告诉你怎么安装，而不是静默失败或尝试一个更差的方法。这解决了工具链不一致导致的脆弱性问题。
输出契约层：这是安全的最后防线。它包含一系列强制规则：永远不覆盖原始文件；在执行有损操作前明确告知用户；进行破坏性操作（如批量删除）前先进行“模拟运行”并展示将要发生的变化。我是在早期测试中，因为助手“热心”地删除了我的源文件（两次！）之后，才痛定思痛加入这一层的。

这个架构的价值在于，它不仅仅是一组命令，而是一个让AI能够稳健、可靠、安全地处理现实世界任务的认知框架。

3. 技能文件深度解析：以PDF和图像处理为例

让我们深入看看两个核心技能文件的具体实现，理解Markdown如何承载复杂的操作逻辑。

3.1 PDF技能：不只是Ghostscript命令

PDF技能文件大约315行，它解决的核心问题是：PDF处理有无数种参数组合，但90%的日常需求其实只有几种固定模式。

领域逻辑的核心——预设场景：技能文件里不会简单地说“用Ghostscript压缩PDF”。它会定义几个清晰的场景预设：

email：目标是大幅减小体积以便附件发送。默认使用-dPDFSETTINGS=/ebook，这会进行较强的有损压缩（降低图像DPI，简化字体等），将文本转换为曲线，通常能将文件缩小至原来的30%-50%，在屏幕上阅读依然清晰。
web：用于网页发布。可能采用-dPDFSETTINGS=/screen，与ebook类似但可能保留更多可搜索文本的特性。
archive：无损或近乎无损的归档压缩。使用-dPDFSETTINGS=/printer并结合-dCompressFonts=true -dSubsetFonts=true等参数，主要优化字体和结构，体积减少有限（可能10%-20%），但完美保留打印质量。
prepress：印刷准备。通常进行最少的压缩或仅进行无损压缩，确保所有字体嵌入、色彩空间正确。

注意：-dPDFSETTINGS是一组预设的集合，它本身包含了数十个底层参数。直接使用这个预设，比让AI每次去组合几十个独立参数要可靠得多。这就是“肌肉记忆”的体现——记住那个经过验证的、代表最佳实践的“快捷方式”。

执行层的智能回退链：技能文件会这样描述执行逻辑：

首选工具：Ghostscript (gs) 检查命令：`which gs` 或 `gs --version` 成功：执行预设的gs命令。 失败：检查备选工具1：qpdf (用于无损重组、解密、合并)。 检查命令：`which qpdf` 成功：使用qpdf进行无损优化（如 `qpdf --linearize input.pdf output.pdf`）。 失败：检查备选工具2：pdftk (功能较旧，但可能安装)。 检查命令：`which pdftk` 成功：提供基础操作指南。 全部失败：给出清晰的安装指引：`# 错误：未找到PDF处理工具。建议安装Ghostscript: brew install ghostscript (Mac) 或 apt-get install ghostscript (Linux)。`

这种链式回退逻辑，使得技能具备了环境适应性，而不是一个脆弱的单点脚本。

3.2 图像技能：质量、格式与元数据的权衡

图像技能文件（约273行）处理的是另一个重灾区：格式转换和压缩。AI助手常常混淆JPEG、PNG、WebP、AVIF的特性，或者使用导致质量严重下降的默认参数。

关键领域知识封装：

格式转换决策树：
- 目标：有损压缩，用于网页/邮件-> 优先转换为WebP（在同等质量下比JPEG体积小25-35%）。如果系统不支持WebP，则回退到JPEG。
- 目标：需要透明通道-> 转换为PNG（无损）或WebP（有损/无损均支持透明）。如果原图颜色简单（如图标），优先PNG；如果颜色丰富（如带阴影的UI截图），优先有损WebP。
- 目标：最高压缩比，现代浏览器-> 可考虑AVIF，但需检测环境支持性并准备回退方案。
- 技能文件会将这些决策逻辑以“如果-那么”的伪代码形式写在Markdown中，AI可以阅读理解并执行。
质量参数的经验值：
- WebP有损压缩：-q 85是一个甜点。低于75可能产生明显伪影，高于95体积增益大但质量提升感知弱。
- JPEG压缩：-quality 85同样是通用推荐。对于缩略图可降至75，对于高质量展示可提至92。
- PNG优化：不是用一个“质量”参数，而是使用pngquant进行有损压缩（--quality=65-80）或oxipng进行无损压缩（-o max）。
- 技能文件会明确写出这些数字及其适用场景，防止AI每次去搜索“好的JPEG质量是多少”。
元数据处理与安全：
- 安全规则：任何操作默认添加-strip（ImageMagick）或-metadata all（exiftool）来删除EXIF等隐私元数据（如GPS位置、相机型号）。
- 输出契约：强制规定输出文件名模式。例如，原始文件为photo.jpg，转换为WebP后输出为photo.webp，绝不直接覆盖。如果指定了有损压缩，在命令执行前，AI会模拟输出并提示：“即将对photo.jpg进行有损压缩（WebP, 质量85%），预计体积减少约40%。原文件将保留。是否继续？”

通过将这类琐碎但至关重要的知识固化下来，AI助手就不再需要为“如何把图片变小”这种问题重新发明轮子，而是可以直接调用经过验证的最佳实践。

4. 自动化技能：预设工作流的力量

如果说单个技能文件是“肌肉记忆”，那么自动化技能就是“条件反射”。这是我构建过程中最惊喜的部分，也是我认为最能体现“工具大脑”价值的地方。自动化技能文件（约299行）定义了八个针对常见批处理工作流的命名预设。

4.1 预设工作流详解

每个预设都是一个完整的、多步骤的处理流水线。用户只需要说出预设的名字，AI就知道该做什么，无需任何额外指令。

prepare-for-email（邮件准备包）：
- 路由：识别用户意图为“发送邮件附件”。
- 执行链：
  - 扫描目标文件夹下所有文件。
  - PDF：使用email预设压缩所有PDF，目标大小 < 10MB。
  - 图像：将PNG/JPEG转换为WebP格式，质量85%，剥离元数据。
  - 视频：（如有）尝试转换为GIF（短片段）或强烈建议使用链接而非超大附件。
  - 输出：将所有处理后的文件放入一个名为[原文件夹名]_for_email的新文件夹，并生成一个简短的摘要报告（文件数、总大小减少百分比）。
blog-asset-pack（博客素材包）：
- 目标：为博客文章准备图片。
- 执行链：
  - 将所有图片调整为最大宽度1200像素（保持长宽比）。
  - 转换为WebP格式，质量80%（针对网页浏览优化）。
  - 运行无损压缩（如oxipng对PNG，jpegoptim对JPEG）。
  - 输出到webp_assets文件夹，并按image_01.webp顺序命名。
social-video-bundle（社交媒体视频包）：
- 目标：为Twitter、Instagram等平台准备视频。
- 执行链：
  - 识别视频比例，必要时进行智能裁剪或加黑边以适应目标平台比例（如9:16, 1:1, 16:9）。
  - 压缩至平台推荐码率（如Instagram Feed H.264, 3500kbps）。
  - 添加平台要求的静音音频轨道（如果需要）。
  - 输出多个版本到以平台命名的子文件夹。
photo-delivery-pack（照片交付包）：
- 这是我个人最常用的预设，用于处理Patreon上分发的视觉素材。
- 执行链：
  - 阶段一：整理。将RAW文件（.cr2, .nef）和成品文件分开。
  - 阶段二：处理成品。将成品JPEG/PNG转换为WebP（质量92%，保留较高画质），同时生成一份中等尺寸（最长边1920px）的预览图集。
  - 阶段三：文档打包。将相关的PDF说明文档用archive预设进行无损压缩打包。
  - 阶段四：生成清单。创建一个delivery_manifest.txt，列出所有文件、格式和大小。
  - 输出：一个结构清晰的文件夹，包含raw/,webp_hi-res/,previews/,documents/和清单文件。

4.2 预设工作流带来的范式转变

这个设计的精妙之处在于，它将交互模式从“微观管理”转变为“目标管理”。我不再需要说：

“把这张图转成WebP，质量85%，去掉元数据，别覆盖原图；再把那个PDF用ebook设置压缩一下，检查大小；哦对了，把所有处理好的东西放到一个新文件夹里……”

我只需要说：

“用photo-delivery-pack预设处理这个文件夹。”

AI助手读取自动化技能文件，理解photo-delivery-pack这个“协议”所代表的一系列复杂、有序的操作，然后自动执行。这极大地减少了认知负荷和提示工程的工作量，并且保证了结果的一致性。无论是我自己操作，还是将来团队其他成员操作，只要调用同一个预设，得到的结果就是可预期的。

5. 为何选择Markdown而非脚本：透明性与适应性

我最初尝试将这些技能写成Shell脚本。但这被证明是一个错误，原因有三：

1. 脚本是脆弱的：Shell脚本严重依赖特定环境：操作系统（Linux/macOS命令与Windows PowerShell/CMD天差地别）、工具的具体版本、甚至目录结构。一个在Mac上运行完美的脚本，在Windows上可能一半命令都无法识别。而Markdown技能文件描述的是意图和逻辑，AI可以在当前环境中寻找最佳实现路径。如果技能文件说“使用Ghostscript压缩PDF”，AI在Mac上会调用gs，在Linux上也会调用gs，如果没安装，它会按照技能文件里的指引告诉你如何安装。脚本则只会报“command not found”。

2. 脚本是不透明的：AI执行一个Shell脚本时，它只是在运行一个黑盒。如果脚本中途失败，AI很难理解为什么，因为它看不到脚本内部的逻辑分支。它无法进行适应性调整。而Markdown技能文件是透明的。AI阅读它，理解其中的路由逻辑、领域知识和安全规则。当遇到意外情况时（比如首选工具缺失），AI可以根据技能文件里描述的“回退链”逻辑，尝试备选方案，或者给出更精准的错误诊断。

3. Markdown是通用且可审计的：一份纯文本的Markdown文件，无需任何依赖，无需编译，用任何文本编辑器都能查看和修改。整个“工具大脑”不到2000行，人类可以轻松阅读、理解和定制。这使得知识的沉淀和共享变得极其简单。你可以基于我的PDF技能文件，轻松添加你们公司内部特定的PDF水印流程。而修改一个复杂的、充满bash技巧的Shell脚本则要困难得多。

一个具体对比：

脚本方式：convert input.jpg -quality 85 -strip output.jpg

技能文件方式：

## 操作：有损压缩图片用于网页 **意图**：用户希望减小图片体积以加快网页加载。 **逻辑**： - 首选输出格式：WebP（压缩率更高）。 - 质量预设：85（视觉无损与文件大小的良好平衡）。 - 安全操作：必须剥离EXIF等元数据以保护隐私。 - 输出契约：永不覆盖原文件。输出文件名应添加格式后缀（如 `.webp`）。 **执行**： 1. 检查工具：优先使用 `cwebp`，其次 `magick convert` (ImageMagick 7)，再次 `convert` (ImageMagick 6)。 2. 执行命令（示例）：`cwebp -q 85 input.jpg -o input.webp` 3. 回退命令（示例）：`magick convert input.jpg -quality 85 -strip output.webp` **检查**：执行前，确认输出文件路径不与原文件冲突。

当AI读取技能文件时，它获得的是“为什么这么做”和“可以怎么做”的知识，而不是一个呆板的命令。这赋予了它真正的适应能力。

6. 实际应用场景与效率提升

我运营着一个Patreon页面，主要分享用于视觉内容创作的ComfyUI工作流。这意味着我每周都要处理大量的图像转换、PDF打包、视频压缩和文件整理工作。

在没有“工具大脑”之前：每一次处理，我都要对AI助手说：“帮我把这些截图转换成WebP，质量不要太低，也不要太大，适合网页用。”然后看着它开始搜索“ImageMagick convert to WebP quality setting”，偶尔还会尝试一些已经过时的语法。或者处理PDF时，它可能会错误地使用/prepress预设，生成一个对于邮件来说仍然过大的文件。我不得不反复检查它的输出，扮演一个“人肉校验器”的角色。最令人沮丧的不是单次任务耗时，而是每次都要重复同样的教学和纠错过程，毫无积累。

在拥有“工具大脑”之后：我的工作流变成了这样：

将一周积累的素材（教程截图、工作流PDF、示例视频）扔进一个文件夹。
对AI助手说：“用photo-delivery-pack预设处理这个文件夹。”
助手读取自动化技能，开始执行。
- 它识别出截图，调用图像技能，以92%的质量转换为WebP。
- 它发现PDF文档，调用PDF技能，用archive预设进行无损压缩。
- 它将RAW源文件单独归类。
- 它生成预览图和文件清单。
我收到一个处理完成的、结构清晰的文件夹，直接打包上传即可。

节省的时间可能并不惊天动地，每天大概15-30分钟。但带来的改变是根本性的：

一致性：每次的输出质量、文件结构都是完全一致的，符合交付标准。
可信度：因为“输出契约”层强制保护了原始文件，并在执行有损操作前明确提示，我可以放心地将这些重复性任务交给AI，而无需事后逐一核对。信任一旦建立，协作效率便呈指数级增长。
焦点转移：我将认知资源从“管理AI做琐事”中彻底解放出来，可以100%投入到那些真正需要创造力和复杂推理的工作上，比如设计新的ComfyUI工作流逻辑、撰写教程内容、与社区互动。AI助手回归了它最擅长的角色：一个处理复杂问题的智能伙伴，而不是一个需要手把手教的生活不能自理的“天才”。

这就是“工具技能”的核心价值：它抬高了地板。AI仍然可以思考难题，但它不再需要假装“把PNG转换成WebP”是一个需要它动用通用人工智能去解决的难题。这些琐事被固化为可靠的、可重复的肌肉记忆，让智能用在刀刃上。

7. 构建你自己的“工具大脑”：实践指南

如果你也被AI助手“金鱼般的记忆”所困扰，想要构建自己的技能库，以下是我从实践中总结的步骤和建议：

7.1 第一步：从你最常重复的“无聊”操作开始

不要一开始就想着构建一个覆盖所有场景的庞大系统。回想一下，在过去一周里，你向AI重复解释过多少次同样的操作？

“怎么给这个视频加个静音音轨？”
“怎么把这些散乱的日志文件按日期合并？”
“怎么把这个CSV文件从GBK编码转换成UTF-8？” 把这些记下来。你的技能库应该始于你的真实痛点，而不是想象中的需求。

7.2 第二步：用Markdown书写“意图”，而非用脚本书写“命令”

这是最关键的心态转变。你不是在写一个自动执行的脚本，而是在为AI编写一份它能理解的“工作说明书”。

错误的开始（脚本思维）：

#!/bin/bash # 压缩PDF gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf

正确的开始（技能思维）：

# PDF压缩技能 ## 场景：用于电子邮件附件 **用户意图**：用户需要将PDF文件缩小以便通过电子邮件发送，允许一定的质量损失，屏幕阅读清晰即可。 **核心逻辑**： - 使用有损压缩，大幅减少文件体积。 - 目标：在可接受的质量损失下，达到最小的文件大小。 - 安全：必须保留原始文件。 **实现**： - **首选工具**：Ghostscript。 - **关键参数**：`-dPDFSETTINGS=/ebook`。此预设将图像分辨率降至150 dpi，将彩色图像转换为sRGB，并进行其他优化，通常可减少50-70%的体积。 - **完整命令示例**：`gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile="{input_filename}_compressed.pdf" "{input_filename}.pdf"` - **备选方案**：如果未安装Ghostscript，建议使用在线工具或指导用户安装。 **输出契约**： - 输出文件必须使用新文件名（建议添加 `_compressed` 后缀）。 - 执行前，需估算并告知用户原文件大小和预期输出大小。 - 操作完成后，提示用户检查输出文件是否满足需求。

当你用Markdown写下这些，AI学习到的是“为什么用/ebook预设”以及“整个操作的上下文是什么”。下次遇到“发邮件用”这个意图，它就能直接调用这份知识。

7.3 第三步：为工具链设计回退路径

你的开发环境和你同事的、你服务器的环境可能都不同。技能必须具备适应性。

列出首选工具：每个操作都有一个最推荐的工具（如图像处理用ImageMagick）。
列出备用工具：如果首选工具不存在，用什么替代？（例如，没有ImageMagick，也许可以用ffmpeg处理视频帧，或用系统预览进行简单转换）。
提供安装指引：如果所有工具都没有，给出最简洁的安装命令（如brew install imagemagick或apt-get install imagemagick）。
在技能文件中明确写出这个“工具检测与回退”逻辑，AI会照此执行。

7.4 第四步：尽早、尽可能严格地加入安全规则

这是用教训换来的经验。在AI助手“热心”地帮你“清理”掉源文件之前，就把安全规则刻在技能文件里。

规则一：永不覆盖。任何输出文件必须使用不同的名称或路径。
规则二：有损须确认。在进行有损压缩、格式转换等不可逆操作前，必须暂停并告知用户即将进行的操作和预期结果，等待确认（或通过一个明确的--force参数来跳过）。
规则三：破坏性操作先模拟。对于删除、移动、批量重命名等操作，必须先运行“模拟”或“试运行”模式，列出所有将要发生的更改，让用户审查。
规则四：创建备份。对于关键文件的操作，可考虑自动在临时目录或备份目录创建副本。

将这些规则作为“输出契约”层写在每个技能的末尾。这不仅能防止灾难，更能建立你对AI处理自动化任务的信任。

7.5 第五步：迭代与抽象，形成预设工作流

当你有了一批基础技能（如PDF压缩、图像转换、文本清洗）后，观察你的工作模式。你是否经常按固定顺序执行一系列技能？比如“先压缩图片，再打包PDF，最后整理到文件夹”。这就是创建预设工作流的时机。像我的prepare-for-email一样，将这些固定组合抽象成一个更高阶的“技能”。这会将你的效率提升到另一个维度。

8. 常见问题与故障排查

在实际使用和分享这个“工具大脑”概念的过程中，我遇到并解决了一些典型问题。

8.1 AI不读取或不理解技能文件

问题：你写好了PDF_SKILL.md，但AI助手在对话中似乎完全忽略它，还是去网上搜索。排查：

确保文件可访问：最简单的方式是在对话开始时，让AI“阅读”或“总结”一下这个文件。例如：“请先阅读./skills/PDF_SKILL.md文件的内容。” 这能确认AI能否看到并解析你的文件。
检查格式：确保是纯Markdown，语法正确。特别是YAML Frontmatter（如果有）的格式要正确（以---包裹）。
明确引用：在提出请求时，明确指向技能。例如：“根据PDF_SKILL.md中定义的email场景，请帮我压缩这个文件。” 这比单纯说“压缩PDF”提供了更明确的上下文。

8.2 技能文件中的命令在特定环境失败

问题：技能文件里写的gs命令在用户的Windows PowerShell里报错。解决：这正是使用Markdown而非脚本的优势。不要只在技能文件里写死命令。

描述意图，而非具体命令：写“使用Ghostscript进行压缩”，而不是具体的gs命令行。

提供多平台示例：在技能文件的“执行”部分，可以分平台给出示例。

**执行示例**： - macOS/Linux: `gs -sDEVICE=pdfwrite ... -sOutputFile=output.pdf input.pdf` - Windows (如果gs在PATH中): `gs -sDEVICE=pdfwrite ... -sOutputFile=output.pdf input.pdf` - Windows (通用建议): 建议安装Ghostscript后使用完整路径，或使用图形工具如QPDF。

强化回退链：在工具检测环节，增加对Windows可执行文件（如gswin64c.exe）的检查。

8.3 处理复杂或模糊的用户请求

问题：用户说“优化这个文件”，这可能指压缩、转换格式、修复错误等多种意图。解决：加强“路由层”的逻辑描述。

在技能文件开头，清晰定义每个“操作”所处理的用户意图关键词。例如：

## 路由指南 - 用户提到“变小”、“压缩”、“用于邮件/网页” -> 触发 **有损压缩** 流程。 - 用户提到“修复”、“打不开”、“损坏” -> 触发 **修复** 流程。 - 用户提到“合并”、“拆分”、“提取页面” -> 触发 **页面操作** 流程。

教导AI，如果意图模糊，应主动询问澄清。例如：“您说的‘优化’是指减小文件大小，还是修复文件错误？”

8.4 技能文件变得冗长难以维护

问题：随着技能增多，一个Markdown文件可能变得非常长。解决：

模块化：保持一个技能一个文件。PDF技能只关心PDF，图像技能只关心图像。
索引文件：创建一个MASTER_SKILL_INDEX.md文件，作为目录。里面只包含各个技能的简介和链接（或引用方式）。让AI先读索引，再根据需要深入阅读特定技能。
版本化：使用Git管理你的技能库。你可以为不同的项目或环境创建不同的分支或标签。

8.5 与不同AI助手的兼容性

问题：你为Claude Code写的技能，在Cursor或Gemini CLI里表现不一样。现状：目前，不同AI助手对长上下文、文件读取、指令遵循的能力确实有差异。Claude和Cursor可能表现更好。策略：

追求最大公约数：使用最清晰、最结构化的Markdown语法。避免过于复杂的嵌套或冷门格式。
测试与适配：在你的主要工作环境中测试。如果某个助手对特定格式（如表格）解析不好，就改用列表描述。
核心是思想：即使某个助手不能完美执行技能文件里的每一步，你将操作逻辑清晰文档化的过程本身，也极大地提升了你提示工程的质量。你可以手动复制粘贴相关段落给AI看。

构建“工具大脑”不是一个一蹴而就的项目，而是一个持续积累和优化的过程。每当你教会AI助手一件事，并且将它固化下来，你就在为你未来的自己节省时间，并构建一个更强大、更可靠的数字工作伙伴。它的价值不在于那54KB的文本，而在于你将那些散落在无数次搜索和试错中的经验，系统地、可传递地封装了起来。这，或许是应对AI时代“智能健忘症”的一剂良方。