一、Stripe 每周千个 PR，我却连一个模块都不敢让 AI 独立写

前阵子技术圈被 Stripe 的一则消息刷屏：他们的 Minions 系统让 AI 每周产出上千个 PR，工程师只需要做代码审查。消息一出，一批人高呼“AI 替代程序员进入倒计时”，另一批人开始焦虑——一个人或小团队，怎么才能跟上这个节奏？

说实话，看完之后的第一个反应不是焦虑，而是疑惑：大厂是怎么做到让 AI 产出的 PR 质量过关的？

因为不少人都试过太多次 Vibe Coding——打开 AI 工具，凭感觉让它从头写一个功能，结果多半是：

打开 Claude Code 或 Cursor，甩一句“帮我实现 XX 功能”；AI 兴致勃勃地开始生成，前两轮效果不错；第三轮开始出现接口名不一致、重复的工具函数、偶尔蹦出的幻觉 API；第五轮之后，整个模块开始“漂移”——连自己都快认不出这是让它写的项目了。

举一个最近刚踩的坑：上周让 AI 给一个现成项目加“批量上传”子系统，前两轮输出干脆利落，到第四轮突然发现它悄悄把项目里已有的 FileUploader 类替换成了一个新造的 BatchUploadManager——接口签名都改了，调用点还散落在五六个文件里。看到 diff 的时候直接让人骂出声——这下好了，一下午全得搭进去把这些“善意的重构”一个一个挑出来清理。

然后就得花半天去清理。清理到最后发现一个残酷的事实：删掉的 AI 代码，比留下的还多。

二、Vibe Coding 的失控，不是 AI 不够聪明，是起点错了

先抛出一个核心观点：

Vibe Coding 之所以失控，不是因为 AI 不够聪明，而是从一开始，它的起点就错了。

这里面的门道是什么？从实战踩过的坑归纳下来，三条硬道理：

理由一：超长上下文里，AI 的“注意力”一定会掉档。

Stanford 2023年有篇论文（Lost in the Middle）把这个现象钉死了：大模型在长上下文里，两头的信息记得最牢，中间段位的信息被严重稀释。放到编码场景就更戏剧——不管你用的是 Claude、GPT 还是别的旗舰模型，一旦让它在几万行代码的上下文里做增量开发，到第三四轮就会出现“遗忘已有约定”的现象。前面定义过的接口签名会被它悄悄改成新名字，已经存在的 util 函数会被它重新造一个轮子。这不是 bug，是注意力机制的物理极限——上下文越长，关键信息被稀释得越厉害。

所以别再指望“把整个项目扔进上下文，AI 就能看懂全局”——塞得越多，它漏得越狠。大上下文不等于好结果，这是写 AI 编程文章的人不愿意告诉你的真相。

理由二：AI 在“规划”和“执行”两个任务上会互相干扰。

让 AI 从零写一个模块，它同时要做两件事：想清楚应该怎么设计（规划），和把设计翻译成代码（执行）。这两件事在一次对话里反复切换，会让它的整体产出质量塌方。仔细看失控后的代码，常常是“每一段单看都对，合在一起逻辑自相矛盾”。

理由三：Vibe Coding 的上限是你自己的表达能力，不是 AI 的能力。

不少人抱怨“AI 写的代码不能用”，仔细一追，需求本身就描述得模糊。AI 不是没给你最好的答案，是没人告诉它什么叫好——而你自己也没想清楚。

三、成熟模块的真正价值，是给 AI 减负

上面的三条理由听起来像是“AI 编程的死路”，但其实它们都指向同一条出路——不要让 AI 从零开始。

一个可能更反直觉的观点是：

成熟模块的真正价值，不是“避免重复造轮子”，而是“给 AI 的注意力减负”。

过去用开源模块，想的是“别重复造轮子”。现在 AI 参与进来之后，价值发生了升级——预验证过的成熟模块，等于给 AI 一块“不用再理解”的既定地基。AI 不需要搞清楚这个模块内部怎么实现的、有没有坑、边界条件怎么处理，它只需要知道接口长什么样、怎么调。这些信息量只有原始代码的零头。

一句话：把 AI 要处理的 10 万行代码减负到只需要理解 20% 的胶水。注意力焦点一旦收窄，幻觉和漂移立刻降一个数量级。

这不是什么新思路，它就是传统软件工程里“复用优先”的老道理。但放到 AI 编程时代，它突然变得极其关键——因为 AI 最怕的就是“从零到一”，它最擅长的恰恰是“在既定约束下做微调”。换句话说：AI 擅长修修补补，不擅长白手起家。那你就别让它白手起家。

举一个前阵子的实测小例子：同样是“给一个项目加 HTTP 请求重试能力”，让 AI 从零写，它会把 urllib 封装、退避算法、异常分类一套全重新实现一遍，动辄两三百行还未必对；但如果先在提示里告诉它“项目里已经有 tenacity 装饰器、一个统一日志工具、一个自定义异常基类”——这些都是预验证过的成熟模块——AI 最后只写了不到三十行的业务胶水就解决了。十倍的代码量差距背后，是 AI 注意力焦点的断崖式收窄：它不用再去“发明”什么，只需要“连接”什么。

道理讲完了，但操作上还有三个老大难挡在路上：你知道有一堆开源模块可以用，但在哪儿找？每次开新功能就要开五个标签页翻 GitHub、npm/PyPI、社区推荐，一小时过去了正事还没开始。就算找到了，把多个模块“胶水”到一起，工作量不小——每个模块的 API 风格、初始化方式、异常处理都不同，跨三四个模块的胶水就是两天。更要命的是，已有的大项目里其实已经沉淀了一堆可复用模块，但你自己都记不全有哪些。换个新需求过来，想复用自己的资产，却发现连翻找的成本都高到让人放弃。

所以后来就在想：能不能有个工具，把“找模块 + 评估 + 装配 + 胶水”这些脏活全自动化？只负责告诉它我要做什么，它直接产出一个可以丢给 AI 去执行的八十分起点？

四、GufaForge 的思路：把“给 AI 减负”做成一条流水线

承接上一篇提到的 GufaForge（古法锻造——“古法”就是 AI 出现之前人手工写的那些经过验证的代码），这篇正好可以聊清楚它到底在解决什么问题。

先把定位讲清楚：它不是又一个代码生成工具，也不是套壳 Claude Code 的 IDE 插件。它解决的是一个更底层的问题——在 AI 动手之前，先替它把注意力减负做完。可以把它理解成 AI 的“前置工作台”：扫描、评估、装配、产出清单——所有让 AI 头疼的“理解已有代码”的脏活都在这里做完，AI 最终拿到的只是一份边界清晰的装配计划。

整条流水线串起来就是一条“从需求到八十分起点”的自动化路径：先对你本地代码库做一次资产盘点（扫描模块边界、输入输出、依赖关系，打成可检索的索引），再拿你的自然语言需求去匹配——能复用的自家模块先填上，缺什么再去外部生态（GitHub / npm / PyPI）检索候选，最后把完整的装配计划导出成一份结构化的 MD 文档。

关键是到这一步为止，还没有生成任何一行真正的代码——GufaForge 只在做“规划”这件事，它产出的不是代码，是一张可执行的蓝图。

这份 MD 就是你递给 AI Agent 的“从八十分开始的起点”。Agent 拿到它，看到的不是“你从零实现一个 XX”，而是“这里有 80% 的骨架，请按清单把剩下 20% 的胶水代码补完”。从白纸到代码 vs 从清单到代码，AI 的失控率差了一个量级——前者要它同时做规划和执行两件事，这俩在一次对话里会互相干扰；后者只让它做最擅长的“按约束填代码”，规划的脏活 GufaForge 已经替它做完了。

五、同一个功能，两种起点，差距有多大

说这么多不如看实际对比。拿同一个功能需求——“给现有项目加一个文件批量处理的子系统，支持并发、错误重试、进度回调”——分别用两种方式交给 AI 实现。

一个下午的 A/B 对比做下来，差距大到让人意外：

• Vibe Coding 方案：AI 吐出一个两千多行的实现，其中一半是重复造轮子（项目里其实已经有并发池工具），三个地方用了根本不存在的 API，接口风格和项目其他部分完全不一致。花了一个下午做审查和清理。
• 从八十分起步方案：AI 拿到装配清单后只补了约四百行业务胶水代码，复用了项目里已有的并发池 + 重试装饰器 + 日志模块，接口风格天然一致。花了半小时过一遍就合并了。

具体到几个可量化的维度，差距大到不像同一个 AI 写的：

• 代码行数：两千多行 vs 四百行，差 5 倍以上。不是 AI 变懒了，是它不用再实现那些项目里已经有的工具函数。
• 幻觉 API 数量：Vibe Coding 方案里至少有三处 AI 自己编出来的 API（比如调用了根本不存在的 ConcurrentPool.batch_submit_async()），八十分方案里一个都没有——因为能用的 API 都在清单里给它定死了。
• 接口风格一致性：Vibe Coding 方案里新老代码风格撕裂感明显（有的用 snake_case 有的用 camelCase），八十分方案因为复用了项目既有工具，风格天然对齐。
• 手动修正次数：前者改了不下二十处，后者两三处就收尾了。
• 心理成本：前者每次合并前都要反复自问“这段 AI 代码真的能跑吗”，后者因为边界清晰，合并前的心跳明显低一档——这个感受看起来软，但它才是真正能把人和 AI 长期绑在一起的东西。

不是说 AI 变聪明了，是它的任务被压缩到了它最擅长的粒度——“在既定约束下做微调”。

六、这个方法什么时候不好使

新项目第一天你手里没有任何可复用的模块，这招就用不上；你得愿意写“薄胶水层”而不是追求完美抽象；Agent 执行阶段你还是得自己过一遍，人工审查这一关谁也省不掉。

但它能帮你做到的事非常具体：让 AI 从“灾难型合作者”变成“靠谱的初级工程师”，让你写过但遗忘的历史代码资产重新激活，让“一个人的工程量”追上“小团队的节奏”——最后这条是很多人最在乎的点。

GufaForge 目前还在内部打磨，工程化在持续完善。开源时间暂时不想承诺——这个工具对作者自己太重要，想等它稳到敢每天自用再放出来。

不过，如果对“从八十分开始”这个思路感兴趣，有几件事可以立刻做：

• 花半小时写一份“本项目模块清单”——核心工具类、通用组件、已有的装饰器，每条一行注明“做什么 + 从哪调用”——把这份清单塞到 Claude Code 或 Cursor 的项目级 instructions 里，下次让 AI 写功能时它自然会先去复用而不是瞎造。
• 下次写新功能时，别直接甩给 AI，先自己搭个骨架再让 AI 填肉——哪怕骨架只是个空函数签名列表，你会发现失控率立刻降一半。
• 下一篇打算写“从八十分开始”在真实项目上跑一圈后踩到的新坑（有的坑只有规模化用了才会出现）。

从去年开始，一个核心问题就一直挂在心头：一个人怎么才能做出十个人的工程量，而不是被 AI 拖进“写一堆又要删一堆”的循环里。“从八十分开始”是目前能想到的最靠谱的答案。

如果看着 Stripe 的千 PR 公告，一边兴奋一边焦虑，那欢迎一起走这条路。先把起点抬到八十分，剩下的交给 AI——这个分工方式已经自己跑了几个月，到今天为止，它是一条唯一不让人抓狂的 AI 编程路径。