2026 年 11 月 11 日，知名开发者 Simon Willison 为自己攒下的 244 个氛围编程（Vibe-coding）小工具集上线了按标签分类浏览的新功能。他赶在每周额度重置前，用剩下的 Fable 5.2 额度驱动 py-tree-sitter 扫描了全部源码，提取出每个工具调用的 JavaScript 库、浏览器原生 API 和外部 Web API 主机。这原本只是一次个人网站的体验升级，但生成的标签云却意外交出了一份极具说服力的行业切片，当一个人靠 AI 写出两百多个自己都不曾逐行细读的工具后，他最终必须请回最讲确定性的传统编译器语法树工具，才能搞清楚自己的代码库里到底装了些什么。
用确定性的语法树，盘点 244 个不读代码的生成物
氛围编程的核心特征是开发者只管提要求、看运行结果，基本不逐行审阅 AI 生成的代码。这种模式在攒下三五个脚本时轻松愉快，一旦膨胀到 244 个独立工具，管理难题就立刻显现。没人记得哪几个工具调了摄像头，也没人说得清哪些页面偷偷引了外部脚本。
为了给这批资产建档，Simon Willison 没有把代码直接塞给大模型去“读”出标签，而是让 Fable 5.2 编写了核心脚本 build_tags.py。这个脚本通过 uv run build_tags.py 运行，读取前置脚本 gather_links.py 生成的 gathered_links.json，最终输出结构化的 tags.json。
为什么放着现成的大模型不用，非要绕道用 Tree-sitter？因为未经人工精读的 AI 代码里充满注释、提示词残留和普通字符串。如果用正则匹配或大模型泛读，很容易把注释里提到的一句 API 名称误判为实际调用。build_tags.py 直接解析 HTML 内联脚本与事件处理器的抽象语法树，严格匹配浏览器 API 的语法规则，精准剔除了注释和字符串里的伪提及；同时设定门槛，只有被至少 2 个工具通过 CDN 加载的第三方库才会生成标签。
这种“用 AI 写语法树分析器，去清点 AI 写出的代码库”的做法，点破了当前辅助编程落地的一条硬规律。生成代码可以靠概率模型放飞自我，但代码资产盘点与依赖审计，一步都离不开传统编译器的确定性标尺。
92 次 ES Modules 对 3 次 React：数据戳破万能幻象
把这 244 个工具的底层依赖摊开来看，技术栈的冷热反差极为鲜明。在浏览器原生 API 中，ES modules 被调用了 92 次，Clipboard API 达到 69 次，Canvas 2D 有 44 次，Blob URLs 38 次，Drag and drop 30 次，Dynamic import() 12 次，连直接调用摄像头或麦克风的都有 9 次。
再看通过 CDN 加载达 2 次及以上的第三方 JavaScript 库，解析 Markdown 的 Marked 用了 12 次（外加 markdown-it 4 次），在浏览器里跑 Python 的 Pyodide 高达 11 次，负责安全过滤的 DOMPurify 7 次，处理图像的 @jsquash/webp 和地图库 Leaflet 各 4 次。而在现代前端工程中几乎统治半壁江山的 React，在这 244 个工具里仅仅出现了 3 次。
这组客观数字直接戳破了社交媒体上鼓吹的“氛围编程无所不能”幻象。Simon Willison 的工具库之所以能顺畅运转到两百多个，是因为他死死守住了一套极简配方，即采用单文件 HTML 架构，刻意规避 React 和繁琐的前端构建流水线，直接作为静态文件托管，并在 Git 提交历史里完整保留原始 Prompt 或 Agent 对话记录。
69 次剪贴板调用和 30 次拖拽 API 揭示了这类工具最真实的交互模型——用户拖进一个文件或粘贴一段文本，靠浏览器本地的 Canvas 或 Pyodide 算完结果，再一键复制走。没有复杂的组件状态树，没有构建步骤的版本冲突，AI 只需要在一个 HTML 文件里把输入和输出接通。这是大模型写代码最舒服的温床，也是成功率最高的边界。
靠沙盒架构兜底，跨出边界就是漏洞与认知债
很多人看到个人开发者用 AI 攒出 244 个工具且安然无恙，便以为 AI 生成的代码质量已经可以直接搬进企业生产环境。实际上，这批工具没闯祸的头号功臣是零后端沙盒架构，而不是 AI 写出的代码滴水不漏。
当一个工具只在浏览器本地解析 PDF 或转换图片格式、不设后端数据库时，它的爆炸半径几乎为零；就算代码写得糙，大不了刷新网页重来。可一旦跨出这个纯静态沙盒，缺乏人工逐行审查的短板就会立刻暴露。
首先是密钥与供应链风险。为了让纯前端工具能调用外部大模型，Simon 曾图省事把用户填入的 API 密钥直接存在浏览器的 localStorage 里。在同一个域名下托管两百多个工具、且大量通过 CDN 动态加载第三方库的前提下，只要同源下的任一脚本存在缺陷或某个 CDN 依赖被攻破，攻击者就能顺手读走 localStorage 里的密钥。
更直接的教训来自认证逻辑。在一次 AI 辅助编写的 GitHub OAuth 项目中，AI 给出的初始代码不仅缺少基本的错误处理，还漏掉了对 OAuth state 参数的校验，直接留下了登录 CSRF 漏洞，最后全靠人工审查才把这个坑填上。
架构兜住了不看代码的侥幸，但兜不住越界后的认证漏洞与认知透支。
除了看得见的漏洞，还有看不见的认知债（cognitive debt）。Simon Willison 曾专门提出这个概念，指出在中大型项目里，AI 生成代码的速度远远甩开了人类大脑建立系统心智模型的速度。不仅如此，因为现在的 AI 可以眨眼间生成格式工整的文档、密集的提交记录和看似高覆盖率的测试套件，传统的“有测试、有文档”已经不再是代码经过深思熟虑的可靠证明；只有软件被长期实际使用，才算得上硬核验证。
- 提醒.企业技术负责人切忌把个人开发者的 244 个微工具战绩直接外推到公司业务线；一旦涉及用户鉴权、外部密钥存储或跨模块状态同步，免审阅的氛围编程就会把研发团队拖进认知债与安全事故的泥潭。
对于独立开发者而言，“单文件 HTML + 原生 Web API + Tree-sitter 静态盘点”已经构成了一套极具性价比的个人微工具生产力范式。接下来最值得盯紧的变量，是这套原本用来生成前台标签云的 build_tags.py 语法树扫描机制，会不会被进一步改造成针对 AI 代码库的自动化安全巡检器——比如在构建阶段自动揪出所有读写 localStorage 或连接陌生外部主机的脚本，用编译器的冷酷规则去管束大模型的野蛮生长。