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

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

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

先说说 Vibe Coding。那是一种习惯：把 AI 当作万Neng刷子，从零写起，直接把思路写进代码里。听起来hen酷，但实际上就是让模型跑到全局，却又没有给它足够清晰的边界。

哈哈，那些“随便试试”往往导致接口频繁变动。你想给个功Neng加点新特性，它就会把原本稳定好的类改名，然后再拆分成几个小模块，Zui后连日志dou跑了个自定义版本。结果是 PR kan起来像拼图，一边接一边修。

害，就是因为你没给它一个清晰起点，让它自己去探索全局；而全局又太大，它记不住重要细节，就只Neng凭直觉Zuo“重构”。这就是为什么hen多人说“AI 写代码就像玩俄罗斯方块”，随时可Neng掉砖。

Ai 模型Zui擅长Zuo什么？就是在Yi知框架内微调细节。想让它一次性写完一个模块，这相当于要求它同时规划和执行两件事，对吧？这两件事在一次对话里反复切换，会让整体产出质量塌方。

比如我让 GPT 写一个 HTTP 重试库，它第一轮给我一堆 urllib 封装，再加退避算法；第二轮又改成 requests + tenacity；第三轮却直接抛弃前面所有实现，用自己的异常分类。kan似创新，其实是模型在嘗試多種路徑，每次dou在吃掉上一版的信息。

那为什么要这么Zuo？因为模型无法精准判断哪个方案Zui合适，只Neng通过多次迭代尝试。Ru果你Neng提前给它一个“Yi有基础”，那么模型就Ke以直接填补缺口，而不是从零开始实验。

"八十分起点" 的概念其实就是：先把项目扫完，生成可检索索引，然后把自然语言需求映射到Yi有模块，再补齐缺失部分，把整个装配计划导出成 MD 文档。

步骤hen简单：①资产盘点；②匹配需求；③填充缺口；④生成装配清单；⑤交给 AI Zuo胶水代码。

我之前用这种方式跑过两个项目，一个是内部 CRM，一个是物流追踪系统。结果发现 AI 在Zui后一步只需要写不到三十行业务胶水，而不是几百行完整实现。所以时间压缩了约八成，还Neng保持质量。

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

"薄胶水层" 就是那种只关注接口调用、参数传递、不涉及业务逻辑细节的小脚本。有时候我们甚至Ke以把这一步交给脚手架工具，让它自动生成模板，然后再让 AI 根据模板填充具体调用方式。

"理由二：AI 在'规划'和'执行'两个任务上会互相干扰。" 对，我说得挺老套，但事实证明没错。当 AI 同时承担设计思路和实现细节时它hen容易走偏，导致Zui终代码既符合逻辑又存在漏洞，比如变量名重复、异常未捕获等问题频发。

"理由三：Vibe Coding 的上限是你自己的表达Neng力，不是 AI 的Neng力。" 换句话说你要先把思路梳理好，再交给机器去完成细节。Ru果你连需求dou描述模糊，它只Neng凭猜测走步，这根本不值得期待效果啊！

`GufaForge` 是啥玩意儿：

“古法锻造”——AI 出现之前，人手工写过且验证过的一堆成熟模块。 它帮你完成资产盘点、评估、装配，把所有脏活dou搬到前端，让 Ai Zui终拿着清晰蓝图去补齐剩余 % 的胶水。

不对不对，我刚刚说错了... 应该叫《古法》而不是《古法锻造》哦~

`从零开始`：

模型要同时规划+执行 => 注意力分散 => 输出质量大跌

`从八十分起点`：

模型只负责按约束填代码 => 输出稳定 => 容易审查

上周我请 GPT 给现有项目加文件批量处理子系统。一开始输出简洁，但到了第四轮，我突然发现原来的 `FileUploader` 被替换成 `BatchUploadManager` ——签名变了调用散落五六个文件。我kan到 diff 就骂：“这下好了全盘重构！”

那天晚上我整整花了半天来重新链接所有调用，还顺便改回旧类名，因为我知道Ru果继续走下去，只会导致geng多冲突。

No1 ：Ru果需求描述模糊，即使模型再聪明，也只Neng胡乱生成，“好像不错”但Zui终不可用。

No2 ：缺乏可复用资产时你必须花时间搜集和整理，否则每次dou是重头再来。

No3 ：当团队规模扩大后每个人dou需要快速定位Yi有模块，否则整个团队效率dou会被拖慢。

`资产盘点工具`：

把所有 module 边界扫描出来把接口暴露为 JSON 文件，再建立检索索引。一键查询，“找不到？”就说明还有漏扫。

`需求映射器`：

把自然语言拆解为任务列表，并根据Yi有资产进行匹配。Ru果匹配不到，就标记为 “新建” 并提交给外部生态搜索。

`装配计划生成器`：

把所有Yi匹配及待补齐项排布成顺序表，并输出 Markdown 文件供 QA 审阅。

`Ai 胶水编写器`：

用上述计划作为输入，只需几句提示即可得到业务级 glue code。例如：

from existingmodule import HttpClient from tenacity import retry, stopafter_attempt

@retry) def safe_request: ...

这样产生的代码行数远低于全量实现，而且可直接合并。

小技巧

1️⃣ 一句话提示 —— 不要打冗余词，例如“请帮我实现…”，直接说“请按照以下 API 调用…” 2️⃣ 强调Yi验证模块 —— 一定要提及 “Yi存在 tenacity 装饰器” 等信息 3️⃣ 保留注释 —— 把关键逻辑放进注释里让 QA 一眼kan到核心。

咱们一直围着“AI Ke以替代程序员”转圈圈，其实真正的问题是怎么让 AI 有效地参与我们的工作流，而不是盲目投其所好。从八十分起点入手，让你的团队专注于核心业务，而将琐碎包装交给机器完成。这才是真正高效协作，也是避免沦为 “灾难型合作者”的唯一途径。

所以下次当有人问 “怎样才Neng跟上 Stripe 那样高产率？” 我们回答：“先抬高起点，把全部知识提前消化掉。” 再交给 Ai Zuo剩余工作，你就Neng轻松拥有十个人级别工程量，却不必陷入无休止删改循环。

记住一句话：不要让 AI 从零开始——只要你的框架足够完整，它就Neng像专业助手一样完成剩下的小事。

祝编码愉快，也祝 Ai 为你的项目增值而非添乱！

---