夜雨聆风结论先说：AI 做单个工具很爽，同时推进多个项目就是另一回事了。
之前我写过两篇文章，讲自己一个技术小白怎么用 AI 做出桌面工具和 Chrome 扩展。评论区问得最多的问题是：能不能用这套方法做更大的东西？
过去一个月我真的试了。手上同时推进三个项目：一个 Python 桌面工具（文件索引，迭代到 v2.6.0）、一个 ERP 辅助 Chrome 扩展（迭代到 v4.3.0）、一个商品批量处理扩展（从单文件脚本重构到模块化架构）。
结果是：踩的坑比前两次加起来还多，而且全是新品种的坑。
这篇就是复盘。不讲"AI 能不能做大事"这种空话，只讲我实际撞上的四堵墙，以及撞完之后立下来的几条规矩。
一、背景：从"做一个工具"到"养一堆工具"
先说清楚什么叫"规模化"。不是代码量变大，而是三个维度同时变了：
项目变多：三个项目并行，技术栈还不一样（PySide6 / Chrome MV3 / 混合） 模块变多：单个项目从 1 个文件涨到 20+ 个文件 时间变长：不再是"2 小时做完收工"，而是跨周、跨版本的长期迭代
单点工具时代，AI 是神。规模化之后，神的记性不太好。
二、四堵墙：规模化之后的典型翻车现场
墙 1：上下文丢失——AI 不记得上周写的逻辑
这是最先撞上、也最疼的一堵墙。
做桌面工具 v2.6.0 的时候，我要加"暗色模式"。AI 很痛快地写了一个主题管理模块，代码本身没毛病。
问题是：它不知道我 v2.5 里已经有一套样式处理逻辑了。新的主题管理器和旧的样式代码各管各的，切换主题后一半控件变了色、另一半纹丝不动。
AI 的上下文窗口装不下整个项目的演进史。它看到的是当前这堆文件，看不到"当初为什么这么写"。
单点时代这不叫事——项目总共几百行，贴给它就完了。几千行、十几个文件之后，贴不全了。
墙 2：版本混乱——版本号在 5 个地方，5 个说法
Chrome 扩展要显示版本号的位置多到离谱：manifest.json、popup 页面、options 页面、content.js 生成的悬浮面板标题、还有打包文件名。
有一次发版，我改了 manifest 里的版本号，以为完事了。结果用户截图过来，悬浮面板上显示的还是旧版本。
AI 改代码的时候不会主动帮你"全位置同步"——它只改你让它改的地方。而我自己也记不住到底有几处。
墙 3：回归 bug——加新功能把老功能改坏了
ERP 扩展 v4.3.0 要加一个新的单据对比模块。AI 的做法是：把新模块写好，然后"顺手"调整了面板加载逻辑——把原来"页面加载自动弹出面板"改成了"右下角悬浮按钮点击展开"。
新功能是好的。但原来 popup 里"批量验收"按钮的跳转逻辑，是建立在"面板自动弹出"这个前提上的。前提没了，老功能的行为就变了。
这就是典型的回归 bug：你没让 AI 碰老功能，但新改动改变了老功能的运行环境。
项目小的时候，全量回归测试肉眼就能做完。20 个文件之后，肉眼不够用了。
墙 4：逻辑漂移——同一个功能，两个项目两份写法
商品处理扩展和 ERP 扩展都需要"监听 SPA 页面跳转"。
隔了两周，AI 给两个项目写了两套实现：一个用 URL 轮询，一个用 MutationObserver。都能用，但行为细节不一样，bug 也要分别修两遍。
没有强制约束的情况下，AI 每次生成都带点随机性。时间一长，重复逻辑就漂移成了近亲而不是孪生。
三、撞完墙立下的四条规矩
下面是实战总结。不高级，但每一条都是拿真实 bug 换的。
规矩 1：先书面梳理逻辑，再动代码
现在每个版本动手前，我先让 AI 干一件事：把要改的功能逻辑写成一份书面方案——不改什么、改什么、影响哪些现有功能，一条条列清楚。我确认之后，才让它动代码。
这一步直接治好了"上下文丢失"的大部分症状。书面方案就是 AI 的"外置记忆"，它不用猜当初为什么，方案里写着。
做商品扩展 v4.3.0 模块化重构时，先出的重构方案里明确写了一条："原有四大功能逻辑 100% 兼容，行为完全一致。"这句话后来成了验收标准，一条条对着查。
规矩 2：版本号唯一来源，其他位置动态读取
版本号只在一个地方维护：manifest.json。
其他所有位置——popup、options、悬浮面板标题——全部改成代码动态读取：
// 所有需要显示版本号的地方，统一这样取
const version = chrome.runtime.getManifest().version;
document.getElementById('version-label').textContent = `v${version}`;
桌面工具同理：版本号只在配置文件里写一次，UI 全部读取。
从此发版只改一处，版本不一致这个 bug 类别被整个消灭了。
规矩 3：变更说明制度——每次迭代必须留下"改了什么"
每发一个版本，强制产出一份变更说明，固定三段：
改了什么（文件级清单） 没改什么（明确声明哪些老功能未动） 已知风险（强依赖什么，什么情况下会坏）
别小看第 2 条。"没改什么"写下来的过程，本身就是一次回归检查——你得真的去核对老功能，而不是拍脑袋说没动。
第 3 条救过我一次：某云 ERP 页面结构强依赖一组 DOM 选择器，变更说明里写了"ERP 升级页面结构需同步更新选择器"。后来 ERP 真改版了，我翻到这句话，十分钟就定位了问题，而不是从头排查。
规矩 4：能复用的逻辑，固化成"只准抄、不准重新发明"
两个扩展都要监听 SPA 跳转之后，我把 MutationObserver 那套实现定成了标准件。后来做第三个多功能工具箱扩展时，直接写进架构约束：同类需求一律复用标准件，禁止 AI 现场重新发明。
顺带说一句，这也是"先书面梳理"的副产品——方案里写清楚"复用 XX 模块"，AI 就不会自由发挥。
四、所以，AI 编程的边界到底在哪
一个月多线作战下来，我的判断是：
AI 的编码能力没有边界，有边界的是 AI 的"项目记忆"和"全局责任感"。
看出来规律了吗？缺的不是 AI 的能力，是工程纪律。而这些纪律——写方案、版本管理、变更说明、强制复用——恰恰是不需要会写代码就能执行的。
这大概是技术小白做 AI 编程最反直觉的一点：到了规模化阶段，你真正的竞争力不是"会提需求"，而是"会立规矩"。
一句话总结
AI 不会替你记住整个项目，但你可以用文档和制度替它记住。
单点工具时代，AI 编程是"对话的艺术"；规模化时代，是"管理的艺术"。