猫咪唱歌 25 期小结：从 1M 提示词到 200K
好久没有来记录博客了，「猫咪唱歌」已经更新到 25 期。
总体来说，基本达到预期效果。我的整个流程跑通了，初步的音乐效果和可爱程度也是有的。虽然没有做到爆款，但属于同类型作品中较为优秀的。
也是时候停下来整理一下了。正好下周女儿要去做手术，预期停更一周，中间大概只发一次，不太掉活跃就行。
关于创作智能体构建的思考¶
还是整体说一下我们创作这个智能体的构建。
随着工程逐步制作，接进来的技能、工具、流程越来越多，否决项目也变多。整个工程的提示词已经有将近 1M。虽然这 1M 提示词是分在多个流程里的，不会一次性全部注入上下文，但还是显得过于臃肿。
正好前两天 Gemini 4 上线到 OpenCode 的 Go 订阅里，我这个月的 Go 订阅还有三四天就到期了，额度还很富裕，就斗胆拿 Gemini 4 对整个流程做了一次复盘。从将近 1M 的提示词，优化到了 200 多 K，23 分钟，消耗了 8.3 美元额度。整体来说还是比较值的——后期把工程再交回给 Deepseek v4.1，它也还是能工作得很流畅，但 Deepseek 没有能力把整个工作流程优化到 200K。
我发现无论是 Deepseek 还是 GPT 的一些模型，都很喜欢写废话，那种防御性的工程很多。而大语言模型本身有一个记录的习惯：它会把所有负面条件默认记到提示词里去。这样你越用，东西就越臃肿。特别是作为一个大型的连续性的工程开发，提示词总会有爆炸的一天。现在很多大模型，基本上超过三四百 K 就不太转得动了，推理速度大幅下降。其实大模型对于提示词规模的最优解，肯定还是在 200K 以内，速度才比较快；100K 以内那是飞快。
但大语言模型又有重复大量记录负面条件的习惯。我让 Deepseek 也好，让其他 Claude 模型也好，想过的办法都是给它加门槛——什么情况下才能进入提示词——然后加评估。其实这都是治标不治本。
我想了个法子：每一期工程给它建一个叫「工程记录」的 Markdown 文件。这样每期工程都有一个默认的记录出口，它就不会记到整个流程提示上去。在这一期工程完工的时候，我们做一次复盘，看工程里哪些可以记录到流程里去。其实大多数工程的东西不会进入流程，只有一些很关键的话进流程，这是可以接受的。我觉得这个解法应该是能治本的。
然后再隔两周或者一个月，用最顶尖最前沿的大模型对整个工程再做一次梳理，应该就能持续地进行开发，而没有太多的劣化体验。
轻量智能体的尝试¶
另外前几天我想过办法：把智能体的方案从 Claude Code 变更为「Pi」。我认为换个轻量级的智能体，可能执行速度会更快一些。结果其实是执行的质量下降了，而且很多功能缺失。
所以轻量级的智能体不是解决执行速度问题的办法——工程要相对简单，你才能用轻量智能体。所以我把「Pi」这个智能体给归档了，还是用回原来以 Claude Code 为基准的智能体。
这里的 Claude Code 和「Pi」的智能体，均为在 Cherry Studio 下魔改过的版本。