约 4756 字 · 阅读约 12 分钟

我本来只是想教 AI 做事，折腾到最后，却差点连自己写的规矩都看不懂了。

#一、事情是怎么变成这样的

我一直觉得，教 AI 干活，和带一个刚入行的新人差不多。

你不需要把世界上所有可能出错的情况都写进说明书。你只要告诉他，遇到问题先看清楚发生了什么，别急着动手；改完东西自己检查一下，别把没做完的事说成做完了。

简单，明白，还挺管用。

所以，我给自己的 AI 助手写了一套技能。每份技能都是一个小文件，用自然语言告诉它该怎么做。我原本追求的就是一件事：让一个不懂复杂技术的人，也能通过几句清楚的话，把 AI 带上正轨。

后来，AI 开始帮我优化这些技能。

这听起来不是挺好吗？

AI 会总结经验，会整理流程，还会发现原来没想到的边界情况。每次出问题，它都能给出一套看起来很有道理的改进方案。

问题也就出在这里。

原本一句话能讲清楚的事，慢慢变成了好几页说明书。原本一个文件就能说完的经验，变成了一个文件负责指路，另外十几个文件负责解释怎么走。

我看着它们，越来越陌生。

最难受的不是文件变多了，而是有一天，我突然发现：我已经很难判断，这些新增的复杂东西究竟是在帮我，还是只是在让我觉得它们很专业。

#二、我决定翻翻自己的历史记录，看看它到底是怎么长成这样的。

最早的版本文字其实很少，8 份技能说明，加起来 491 行。

后来 AI 开始帮我“优化”，这次补一条规则，下次加一个脚本，再下次把内容拆成好几个文件。

每次单看都有道理，放在一起却越滚越大，最后长成了 154 个文件、两万六千多行。

中间我也整理过一轮，目录看起来清爽了不少，技能被拆成更规整的几份。但这并没有真正解决问题。

到后来，8 份技能说明背后，藏着 72 份参考文件、12 个脚本，还有几份公共规则。

真正每次都会直接交给 AI 阅读的，主要还是那 8 份技能说明，加起来不到 500 行。

剩下两万多行，大多躺在旁边等它按需去翻。

听起来是不是挺像那么回事？我原本以为，这样可以让 AI 按需阅读，节省精力。

可后来我越来越担心：它到底知不知道该找哪份文件？会不会漏掉某份说明？

结果让我生气了，因为这些文件不停相互引用，AI 为了弄清楚一件小事，把一大堆文件重新读一遍。

就像一个小文书，为了搞懂上头的一句话，日期格式你看着办，读了表格内容，发现文件里有附件。

附件正文里又嵌着一份关于什么什么的通知，关于什么什么的说明。于是不得不读了十几万字，终于明白了，日期的格式是 20XX.XX.XX。

我甚至给这些文件配上了检查工具，专门检查文件有没有写错、脚本能不能运行、引用有没有指向不存在的地方。

结果，检查工具自己也出了问题，我又得修检查工具。

那一刻，我有点哭笑不得。

我本来是想让 AI 少犯错，最后却花了不少力气，去维护一套防止维护工具出错的工具。

这不是说检查工具不好。真正让我警觉的是，我已经开始为了维护这套复杂系统而工作，却越来越少问自己：它最初究竟是为了帮我做什么？

#三、越专业，就一定越好吗？

翻旧文件的时候，我发现有几种变化特别有意思。

第一种，是每次出错，就多加一条规矩。

比如，AI 调试程序时容易急着修改，还没搞清楚问题就开始试着修。于是技能里增加提醒：不要先快速修一下，不要觉得问题简单就跳过步骤，不要想着这次例外……

一口气列了十条。

这些话单独看，没什么错。但它们其实都在提醒同一件事：先弄清楚哪里出了问题，再动手。

如果十条规则最终只是为了让 AI 记住同一个道理，那为什么不直接把这个道理讲清楚？

第二种，是把今天的情况当成永远不变的事实。

我以前的技能里，甚至记录了这台电脑上的一些具体路径、端口和工具是否可用。

当时确实都测过，写进去也很有道理。

但电脑环境会变，软件会更新，别人使用的机器也和我不同。今天准确的答案，明天可能就不准确了。

与其告诉 AI「这个工具就在这里」，不如告诉它「需要时先检查工具在哪里」。

前者给出答案，后者教它怎么判断。

第三种，也是我最在意的一种：原本教 AI 做事的说明，最后变成了一张告诉 AI 去哪里找说明的地图。

文件拆得越细，层次看起来越清晰，可我想教它的那些经验，却被分散到了越来越多的地方。

我不想每次改一条简单的规则，都得先研究这条规则属于哪个文件、会影响哪些文件、有没有其他文件也在引用它。然后为了读懂它在讲啥，再自学一下编程从入门到入土。

我只是想让 AI 好好干活啊！

#四、于是，我开始删

这次我没有再给技能库增加一套新规矩，也没有再设计一个更聪明的管理工具。

我决定试试相反的方向：能直接用大白话讲清楚的，就不要再绕一圈。

8 份技能，我重新整理了一遍。

72 份参考文件，删掉。

12 个脚本，删掉。

另外几份专门管理这些文件的公共规则，也一起删掉。

当然，不是所有细节都不重要。有些内容确实值得保留，只是没必要为了它们单独建立一层层文件。我把原本分散在各处的经验，重新放回对应的技能说明里。

最后，8 份技能说明加起来，480 行。

而最早那版，是 491 行。中间被 AI 一轮轮扩建，搞到了两万六千多行。

忙活了两天，从两万六千多行删回 480 行。可要是和最初的 491 行比，居然只少了 11 行。

第一次看到这个数字，我自己都觉得好笑。

不过，真正重要的从来不是少了多少字。

中间那两万六千多行，更多是在告诉 AI「详细说明放在哪里」。

现在这 480 行，才是我真正想交给它的全部经验。

不能说图书馆被压缩成了一张纸，相反，这些技能本来就不应该是图书馆。

#五、我具体改了什么？

说几个不需要懂编程也能明白的例子。

第一，把标准答案换成寻找答案的方法。

以前，我会告诉 AI，这台电脑上的某个工具在哪里、某项设置是什么。

现在，我更愿意告诉它：需要用这个工具时，先看看它是否存在；涉及电脑环境的信息，先检查再判断。

因为我真正需要的，不是一个只会背我家电脑配置的助手，而是一个换到别人的电脑上，也不会理所当然地把事情做错的助手。

第二，把十条禁止事项，改成一句提醒。

以前，我担心 AI 调试时偷懒，于是列了一长串「不要这样」「不要那样」。

现在，我把它们合并成一句：

如果你开始想着「先快速修一下，回头再查」，就停一停。你可能还没真正弄清楚问题出在哪里。

我更喜欢这种写法。

它不是在用十道栏杆拦住 AI，而是在提醒它留意自己什么时候开始走捷径。

第三，不再为了让 AI 说人话，专门造一套复杂的规则系统。

以前，我甚至为「怎么写得不像 AI」准备过一份四百多行的规则文件，还配了一个专门安装它的脚本。

现在呢？

我更愿意直接告诉它：

说人话。别为了显得专业，把简单的事情讲得云里雾里。

比如，明明可以说「这件事还没做完」，就没必要非得说「相关工作尚未形成完整闭环」。

我知道，这样写并不能解决所有写作问题。但对我来说，它至少回到了我最初想要的方向：把意思说清楚，而不是把规则写得越来越复杂。

#六、删掉的东西，真的没有用吗？

也不是。

有些细节确实被我删掉了。

以前，技能里会详细解释某些 Git 设置为什么这样配置；现在只留下更简单的原则，让 AI 根据实际情况判断。

以前，会具体写某种浏览器应该怎样启动；现在只保留了关键要求。

以前，会详细讲程序出错时如何沿着调用过程一步步追查；现在只留下「沿着数据往回找，看看问题从哪里开始出现」。

这些细节并非毫无价值。遇到复杂问题时，它们可能真的能帮上忙。

但我开始换一个角度思考：

一份技能，是不是非得把每个问题的答案都提前写好，才算有用？

我越来越觉得，不一定。

有些东西，确实应该明确写下来，比如不能随便破坏用户的数据，修改之后要检查结果。

但有些东西，AI 本来就会做。对于这些操作，如果我又把它拆成一套特别细的流程，要求它每一步都严格照着走，反而可能让它只顾着执行流程，忘了眼前究竟是什么问题。

而且，写得越具体，越容易不小心把自己的电脑、自己的项目、自己当时的情况，当成所有人的标准答案。

我宁愿给 AI 一句留有判断空间的提醒，也不想给它一份看起来滴水不漏、换台电脑却可能处处不适用的说明书。

当然，这不代表模糊永远比具体好。涉及安全、不可逆操作或容易造成损失的地方，该明确的还是得明确。

我只是想把那些不必要的复杂性还回去。

#七、我重新找回了什么？

这次整理还有一个变化。

以前，技能库里有很多文件互相引用。想弄懂一件事，可能得先找到入口，再沿着它给出的路径继续阅读。

现在，我尽量让每份技能都能独立读懂。

我不需要先理解整个技能库，才敢修改其中的一句话。

我也不需要担心，删掉一份自己已经看不懂的参考文件，会不会让另一个角落突然出问题。

至少从阅读和维护的角度来说，这让我轻松了不少。

还有一件事，我觉得特别值得记下来。

AI 越来越擅长写出专业、完整、结构漂亮的东西，不代表我们就应该把每个想法都交给它扩建。

当它提出一套复杂的方案时，我也可以反问：

这件事真的需要这么复杂吗？

如果只是提醒它别急着修改，为什么非要设计十条禁令？

如果只是教它检查电脑环境，为什么非要记住我这台电脑的全部配置？

如果它本来就知道怎么做，为什么还要用一套细密的规则把它框起来？

这些问题没有统一答案，但它们让我重新成为了技能库的主人，而不是一个只能看着 AI 不断施工的旁观者。

#八、这次整理，也有一个不太好意思说的地方

我得承认，这次删改并不是一次严格的实验。

我没有先让 AI 在旧技能的帮助下做一遍任务，再把技能拿走做一遍对照；也没有在修改后，系统地测试它是否真的变得更好。

换句话说，我现在能确定的是：文件少了，层次简单了，我自己读起来也舒服多了。

但 AI 实际干活是不是一定更好，还需要后面的使用来检验。

这一点，我不打算替自己美化。

不过，这次至少让我重新想清楚了一个问题：我究竟想让 AI 变得多么复杂，还是只想让它把事情做好？

接下来，我更愿意观察真实使用中的表现。它还会不会在没弄清问题时就急着修改？会不会遇到环境变化时，仍然照搬旧答案？会不会为了一个简单任务，折腾出一大堆不必要的步骤？

如果这些问题没有改善，我也可以继续修改。

但这次，我想先用一用，而不是马上再建一套系统来管理它。

#九、最后，我还是想写大白话

回头看这段经历，我最大的感受不是「我终于掌握了某种更高级的提示词技巧」。

恰恰相反。

我以前总觉得，自己是不是还应该把事情想得更周全一点？是不是应该再补上几条规则，再增加一点检查，再把每个可能出错的地方都安排妥当？

后来才发现，规则多了，不一定更可靠；文件拆细了，也不一定更好维护。

尤其是对我这样的普通用户来说，我希望 AI 能帮我省心，而不是让我为了维护 AI 的工作方式，再去学一整套新的工程体系。

这次，我把技能库从一大堆文件，删回了八份能一口气读完的说明。

我没有证明「越简单就一定越好」，也不打算把它变成什么普遍适用的方法论。

我只是重新找回了一种自己更愿意相信的写法。

遇到问题，先看清楚再动手。

容易变化的东西，不要假装永远不变。

AI 本来就会做的事情，不必为了显得严谨，再给它套上一层层规则。

最重要的是，写下的每一句话，都应该是我自己看得懂、知道为什么要写，也愿意继续维护的。

说到底，我想要的从来不是一个背熟了所有规矩的 AI。

我想要的是一个能听懂人话、知道什么时候该自己判断，也能在不确定的时候停下来想一想的助手。

最后，我在技能库里留了一句提醒。它不是给 AI 的复杂指令，而是留给每一个想教 AI 做事的自己：

如果你想让一个刚入行的人，半夜别把项目搞坏，你会怎么用最简单的话提醒他？

这次，我决定先从这个问题开始。