给老插件插上 AI 的翅膀-夜雨聆风

给老插件插上 AI 的翅膀

背景

这次给 FaWave^[1] 做 AI 改造，我感触很深，不是因为它用了 AI，而是因为它太“老”了。老到什么程度？打开仓库你就能感受到那种扑面而来的年代感：

它不是今天那种 React + TypeScript + Vite 的新项目，它更像一台服役多年的老机器，结构不新，零件也不潮，但它真的干过很多活，也真的陪用户走了很多年。更现实一点说，我最初动手用 AI 改这个项目，并不是因为我一上来就想做“AI 插件”。恰恰相反，最直接的原因其实很朴素：

项目太大了，大到已经很难靠人工完整阅读一遍后，再有把握地下手修改。

这是很多老项目都会走到的一个阶段，不是没人愿意读代码。而是代码的历史太长、入口太多、逻辑太散、上下文切换成本太高。你刚看明白一段，另一段又把你拉走；你以为理清了一个流程，结果发现后面还牵着一串历史兼容逻辑。对这种系统来说，“先全部读懂再开始改”往往已经不是一个现实策略。

所以一开始我就在想：

如果 FaWave 这样的老插件也能被 AI 改造成功，那它证明的就不是“AI 很热”，而是“老产品依然能进化”。

当然，说得更直接一点，“给老插件插上 AI 的翅膀”这件事，本身也有一层很现实的考虑：

要和当下的潮流吻合。

毕竟今天用户重新认识一个老产品，很多时候就是从它有没有接住这一轮 AI 变化开始的。所以这个标题既不是纯概念包装，也不是完全抽离现实的技术理想。

它一半是在借 AI 的势，让老插件重新被看见；另一半，则是在这个过程中，顺手把真正有用的 AI 能力放进去。

这件事本身，就很有意思。

如果一定要让我用一句话总结这次改造里对 AI 编程的感受，那就是：

单元能力强悍，组织能力薄弱。

这不是一句批评。更像是一种越来越清楚的认识。

它在很多局部任务上，真的很猛。如果非要打一个比方，我会觉得它很像一个不知疲倦的老厂修理工。你给它一个明确指令，它就会钻进一台落满灰尘的老爷机里，一点点帮你找到要修改的零部件，拆开、辨认、翻新，而且不会嫌烦，也不会喊累。

当任务足够清晰、边界足够明确时，AI 的输出效率非常惊人。它像一个执行力极强的协作者。尤其适合：

这一点放在老项目里尤其珍贵。因为很多时候，人不是不会改，而是没法一直保持那种高强度、长时间、反复切换上下文的耐心。AI 在这里最有价值的地方，就是它真的可以不知疲倦地顺着你的指令往下翻。

但一旦问题来到“组织层”，它就开始不稳定了。像 FaWave 这种重型项目，代码之间的依赖关系错综复杂，AI 很难像局部任务那样，给出清晰、稳定的输出。

比如：

这些问题不是“写一段代码”能解决的。

它们依赖的是：

而这恰恰是 AI 目前最薄弱的地方。它可以把一个局部做得很好，但它不一定知道，这个局部为什么应该出现在这里；也不一定知道，这个局部会如何影响整套系统。

所以它很适合“翻新零部件”，但你不能只发一句指令，就指望它把整台老爷机直接焕然一新。

如果你真这么做，很多时候它会自动把任务简化：

这不是它偷懒，更像是它在当前能力边界里的自我保护。因为一旦任务太大、链路太长、依赖太多，它就很难持续稳定地把整件事在一个上下文里完整托住。

所以我现在越来越倾向于把 AI 定义成：

一个极强的实现放大器，但不是天然可靠的架构师。

这背后其实还有一个很现实的问题：

大模型的上下文，终究还是有限的。

它已经比过去强很多了，但面对一个体量很大、历史很深、关系很乱的老项目时，“有限上下文”依然会成为组织级改造的天然天花板。

至于大家常说的那些“solo 模式”或者更强的自治工作流，能不能真正解决这个问题？字节的 TRAE 号称有 solo 模式，不过它太小众了；OpenAI Codex 号称有更强的自治工作流，不过它的口碑不如 cursor，性价比不高。

所有现在，我还是对 solo 编程保留判断。

说到底，AI 很强。但真正重要的从来不是“它能写多少代码”，而是“你有没有能力把问题组织成适合它发挥的样子”。

在重构 FaWave 过程中，我新增了网页 AI 总结能力，可基于当前网页内容生成适合直接分享的短摘要，算是紧跟 AI 时代的潮流了吧。也不枉我这么多天的改造，也算给给为老用户提供点新鲜的东西，算是给这次改造暂时画个句号吧。

[1] FaWave: https://chrome.google.com/webstore/detail/fawave/elbkcajfelcihnbipppmnodnfahbhbad