AI 编程的真正瓶颈,不在提示词

先讲一个悖论。如果你用过 AI 写代码的“氛围编程”（vibecoding）模式，就是那种你描述功能、AI 直接生成代码的方式，你会发现它的质量曲线是倒过来的。前几轮交互，模型像读过你脑子的同事，产出让你想截图发朋友圈。但再迭代三五轮，同样的模型开始写 bug、忘需求、改好一个地方炸掉另一个地方。

不是模型变笨了。是它的上下文窗口被垃圾填满了。

▎TL;DR

上下文腐烂：AI 编程助手在长对话中质量断崖式下跌，根源是上下文窗口被无关信息填满，而非模型能力不足。

工程纪律系统化：开源工具 GSD 把讨论、规划、执行、验证的工程流水线塞进终端，让 AI 每次都在干净的上下文中工作，已被亚马逊、谷歌工程师采用。

波次并行交付：通过子代理编排和原子提交，每个任务在独立上下文中执行并自动归入 Git 历史，人类只做验收官而非调试苦力。

从聊天到产线：真正拉开生产力差距的，不是谁写的提示词更精妙，而是谁能把工程纪律塞进 AI 那不断膨胀的上下文窗口里。

▎01 描述得越细，它写得越烂

“氛围编码”这个名字本身就挺诚实的，它承认自己靠的是感觉，不是工程。你用自然语言描述想要什么，AI 吐出一堆代码，然后你一行行读，改几行，再让它试一次。头几次像魔法。但 当对话历史涨到几万字时，模型开始在一个越来越脏的画布上作画。

问题的正式名称叫“上下文腐烂”（context rot），随着大语言模型的上下文窗口被填充，输出质量持续退化。你有 200k token 的窗口容量，听起来巨大。但在一个来回一个来回的交互里，错误代码的残余、被放弃的方案、你已经忘记的早期指令，全堆积在里面。模型没办法主动遗忘，它只能带着全部垃圾继续往后写。

这不是谁的错。这是“描述即构建”模式天生的结构性缺陷。对话的本质是线性的，堆积而不是替换。你用聊天的方式造房子，每递一块砖都是在前面所有砖的基础上完成的，前面的砖如果歪了，后面的也跟着歪。而你不可能一直清空上下文重建，因为每次清空，你就丢掉了模型对你的项目建立的认知。

▎02 生长在 AI 系统外的工程骨架

GSD（get-shit-done）是一个不太像工具的工具。它的创造者 TÂCHES 是一位不写代码的独立开发者，他的所有代码都是 Claude Code 写的。他把自己受够了“氛围编码”之后建立的工程纪律，打包成了几个终端命令。亚马逊、谷歌、Shopify、Webflow 的工程师在用它。部分网友评价，“我用过 SpecKit、OpenSpec 和 Taskmaster，这个给我的结果最好”。另一些人说，“没有过度工程化，真的就只是把事情做完了”。

核心逻辑一句话：复杂性藏在系统里，露给用户的只有几个可靠的动作。你输入 /gsd-new-project，系统连续发问直到理解你的完整想法，目标、约束、技术偏好、边界条件，然后生成需求文档、路线图和项目状态文件。你批准路线图，然后进入“讨论、规划、执行、验证”的循环。每个阶段都像一个独立回合，主上下文从未被过往垃圾污染。

与其他规范驱动开发工具（spec-driven development tools）的差别在于，它拒绝扮演企业角色。没有冲刺仪式、没有故事点、没有干系人同步、没有 Jira 流程。TÂCHES 说得很直白：“我不是 50 人的软件公司，我不想玩企业剧场。我只是一个想做东西的创作者。”这种立场精准地击中了独立开发者和厌倦流程的工程师，他们想要的不是更复杂的流程，而是把工程纪律自动化，让我不用时刻盯着就能信任产出。

▎03 把流水线塞进终端，人就解放了

GSD 的讨论阶段（/gsd-discuss-phase 1）不是让你对着模型喋喋不休。系统分析当前阶段要构建什么，识别灰色地带，视觉功能就锁布局密度交互，API 就定响应格式错误码，然后逐个问你直到满意。产出是一份 CONTEXT.md，同时喂给后续的研究者代理（它知道该研究哪个库了）和规划者代理（它知道设计决策已被锁定了）。

规划阶段启动后，一个轻薄调度器派生出独立研究者，调查实现路径；然后规划者生成数个原子任务计划，每一个都小到可以在全新上下文窗口中执行；最后检查者验证计划是否覆盖阶段目标，不通过就循环重做。这里的关键设计是：规划本身也在干净上下文里完成，不继承你之前所有聊天的包袱。

执行阶段把计划按依赖关系分组为“波次”（waves）。波内并行、波间串行，User 模型和 Product 模型在同一波里跑，因为没有谁依赖谁；但依赖前两者的订单 API 必须在下一波。每个原子任务执行完毕立刻提交一次 Git commit，注释里带着阶段和计划编号。好处很直接：git bisect 能精确回溯到是哪个任务引入了 bug，而且每个 commit 都可独立回滚。验证阶段把你拉回来做验收官，系统会问“你现在能用邮箱登录吗？”，你答是或否，诊断代理自动找根因，失败的生成修复计划供你重新执行。

全程下来，你的主会话上下文窗口可能只用了 30-40%。重活在对临时子代理的独立上下文里完成。你感受不到累赘，因为它把累赘藏在了你看不到的地方。

▎04 可靠交付不是魔法，是搭管道

GSD 背后藏着一个更重要的范式转换。过去我们训练自己适应工具，学快捷键、记命令行参数、调整工作流来配合软件的脾气。AI 编程兴起后，大多数人还是在做同一件事：训练自己写更好的提示词，琢磨怎么说才能让模型不乱来。但 真正有效率的做法是这个方向的彻底反转：训练工具遵守工程纪律。

大部分 AI 编码方案现在还在“聊天”层次内卷，谁的对话更智能、谁的代码补全更懂上下文。GSD 直接跳到了“产线”层次：讨论是需求评审，规划是技术设计，执行是持续集成，验证是用户验收测试。它不是辅助你写代码的工具，而是一条把自然语言当原材料、输出到 Git 历史的生产线。

这意味着单人生产力还能再跃升一个量级，前提是你接受清晰的约束。内置的质量门（quality gates）会在模式漂移时警报，比如改了 ORM（对象关系映射）却没生成迁移，安全强制执行会把验证锚定在威胁模型上，范围缩减检测能阻止规划者悄悄丢弃你的需求。这些约束看起来是限制，实际上是让流水线不跑偏的护栏。你不必时刻盯防，因为系统会把“记着该做什么”这件事替你做掉。

▎05 真正让你跑起来的，从来不是它有多聪明

回到开头那个悖论。AI 编程的瓶颈被很多人描述成“模型还不够强”。但那些持续产出可靠交付的人，就是那些已经在用 GSD、SpecKit 或自己手工搭流水线的工程师，他们用的事实证明：瓶颈不在模型能写多复杂的代码，而在你让它写代码时，它记住的是建筑图纸还是废纸篓。

上下文腐烂是天然的。熵只会增加，对话只会膨胀，模型不会主动说“等等，之前那段已经不重要了，让我忘掉”。工具可以替你记着该做的事，替你清空不该留着的垃圾。而你唯一要做的就是信任那条管道，相信工程纪律可以从你的脑子里迁移到系统里，相信流水线跑出来的东西比靠感觉聊出来的东西更经得起迭代。

这件事不需要特别聪明的人才能做到。它需要的是一个愿意把纪律外包给工具的人。

▎参考链接

01 GSD 项目仓库

https://github.com/gsd-build/get-shit-done