Svelte 5憋了34个新特性，开发者用AI扫描代码库才发现

一个维护Svelte迁移指南的开发者发现，他的网站每月有3000人查阅"React的useState对应Svelte的哪个语法"，但真正的问题没人问出口：你的代码库里到底还有多少过时写法？

他算了一笔账。手动检查一个中等规模的SvelteKit项目，需要翻遍12个可能的目录，对比官方文档的更新日志，再判断每个语法是否值得迁移。平均耗时4小时。而AI代理（AI Agent）做这件事，理论上只需要一个结构化的数据源。

问题是他没有数据源。网站上的300条迁移条目都是给人看的，机器读不懂。

从"人找答案"到"答案找人"

迁移指南的经典模式是"拉取式"交互：开发者带着具体问题来，查完就走。这种模式有个盲区——开发者不知道自己不知道什么。

Svelte 5从2024年10月发布到2025年3月，累计新增了34个实质性特性。包括$state class替代writable()、$effect.pre取代beforeUpdate、Snippet组件取代等等。大多数开发者只迁移了最明显的那几个，剩下的散落在代码库里慢慢变旧。

作者想要的是"推送式"交互：一份机器可读的清单，告诉AI"这些是Svelte 5.0之后的新东西，去代码库里搜这些签名，找到后按这个替换"。

他的第一次尝试是造了一个/llms-whatsnew.txt端点，里面写满SEARCH FOR / REPLACE WITH区块。能用，但是个伪标准。llms.txt社区规范只定义了两个文件——llms.txt和llms-full.txt。他发明的llms-whatsnew.txt需要每次手动告诉AI"去这个非标地址取数据"，违背了"零配置发现"的原则。

转折点来自一个自我拷问：如果某人没看文档就发现了这个端点，他能直接用吗？

用自定义txt格式，答案是否定的。用JSON Feed 1.1，答案是肯定的——任何RSS阅读器都能解析，AI代理也能无缝消费。

34个模式的数据结构

最终的数据结构长这样。每个模式包含9个字段，核心是两个动作指令：搜什么、换成什么。

search_signatures字段是自动化关键。它不是自然语言描述，而是grep能直接用的代码片段。比如检测旧版store用法，签名是writable(、readable(、derived(三个字符串。AI拿到后可以直接执行文件扫描。

replacement字段则是完整的现代写法。以$state class替代writable为例，旧代码是：

import { writable } from 'svelte/store';
const count = writable(0);

新代码是：

class Counter {
count = $state(0);
}

since字段精确到版本号，比如svelte@5.29.0或sveltekit@2.55.0。这让AI可以按项目依赖版本做过滤——如果你的package.json锁在5.20.0，5.29.0的特性就不该出现在建议列表里。

category分为syntax、architecture、ecosystem、tooling四类。frameworks字段标记该模式对哪些迁移者有意义——从React来的需要知道"你的useEffect是$effect"，从Svelte 4来的则需要知道"你的onMount可以删了"。

实际跑起来什么样

作者用Claude Code测试了这个工作流。场景是：一个2023年创建的SvelteKit项目，想升级到最新实践但不知道从何下手。

AI代理的消费路径是这样的：首先请求JSON Feed获取全部34个模式，读取本地package.json确定当前Svelte版本，过滤出since版本≤当前版本的条目，用search_signatures在src目录执行grep，对匹配结果按replacement生成迁移建议。

输出示例：在12个文件中发现writable()用法，其中3个可以用$state class简化，9个需要保留（因跨组件共享状态）。

这个判断逻辑来自另一个字段——docs。每个模式附带官方文档链接，AI可以递归抓取来理解边界条件。比如$state class不能用于需要外部订阅的场景，这个限制写在文档里，AI会据此排除不适用文件。

对比人工审计：开发者需要记住34个新特性的存在、各自对应的旧写法、以及升级限制。这超出了工作记忆容量，结果就是选择性迁移——只改最明显的，留下技术债务。

为什么JSON Feed赢了

技术选型上有个反直觉的点。JSON Feed 1.1是2017年发布的规范，比LLM热潮早六年。但它的设计恰好命中AI时代的需求：自描述、无认证、结构化、支持扩展字段。

作者考虑过GraphQL，但过度设计——客户端不需要灵活查询，只需要全量拉取。考虑过专门的LLM工具描述格式（如MCP），但生态太新，解析器不普及。

JSON Feed的另一个优势是"意外可用性"。人类用户用Feedly订阅这个端点，能收到"本周新增3个Svelte模式"的推送。机器用户用标准HTTP客户端就能解析，无需SDK。

这种双重接口让数据源有了生命力。作者提到，网站上线两个月后，已有开发者用Zapier把Feed接进Slack频道，每次Svelte发新版就自动通知团队。

迁移指南的商业模式也在变。传统模式是卖课程或咨询，按人头收费。结构化数据模式是按API调用收费，或者按代码库规模收费。作者的网站目前免费，但他测试了付费墙：企业版解锁私有模式库，可以把公司内部的组件规范也写成search_signatures/replacement对，让AI统一审计多仓库代码。

其他框架会跟吗

Vue和React的官方团队尚未提供类似接口，但社区已经出现模仿者。一个Nuxt开发者 fork 了这个项目，做了Vue 3到Nuxt 3的迁移模式库。Angular社区有人在讨论把官方升级指南转成机器可读格式。

阻力来自框架团队的惯性。迁移文档的维护者通常是人文学科背景的技术写作者，习惯写给人看的叙述文本。要把"考虑使用新的响应式原语"翻译成search_signatures: ["$derived(", "$effect("]，需要懂代码的人介入。

作者的折中方案是双轨制：网站保持人类友好的叙述文本，JSON Feed由代码自动生成。他写了个脚本，把Markdown里的代码块提取出来，用正则匹配旧/新写法，自动填充search_signatures和replacement。

准确率约85%，剩下15%需要人工校对。但比起从零手写34个模式，效率提升了一个数量级。

这个项目的GitHub仓库现在有1.2k star，最活跃的issue是请求添加更多框架——Solid、Qwik、甚至jQuery迁移到现代框架的模式。作者的态度是谨慎开放：每个新增框架需要至少50个验证过的模式，否则数据质量会稀释整个Feed的可信度。

你的代码库上一次全面语法审计是什么时候？如果有个AI能24小时监控依赖更新、自动扫描你的src目录、只推送真正适用的迁移建议，你会给它多少权限——只读报告，还是直接提交PR？