AI编程的分水岭：长时任务中如何用coding plan替代vibe coding

AI 编程助手的能力分水岭正在从“能写一段代码”移动到“能完整交付一个功能”。这句话在 long-horizon tasks 上体现得最明显短时任务是补全一个函数、修复一处编译错误、生成一段正则长时任务则是梳理既有项目结构、设计接口、修改多个文件、补充测试、最后跑通验证。模型在 coding 任务上的提升尤其是长时编码任务上的提升很大程度来自针对这类任务进行的专门训练让模型在训练阶段接触更多多步骤、带工具调用、带自我纠错轨迹的数据而不是只背大量单文件代码。这篇博客以 long-horizon coding 为主线索把 AI coding、vibe coding、coding plan、spec-driven 这些热门概念放到同一条工程路径里讲清楚并给出一个最小可执行案例和一套排查清单。1. 先理解 long-horizon tasks 为什么是 AI Coding 的分水岭1.1 短时任务和长时任务到底差在哪里短时任务和高时任务在开发流程中的体验是完全不同的。短时任务的特点是“单步、小输出、即时反馈”。让 AI 写一个format_date函数输入是时间字符串输出是格式化结果让 AI 解释一段报错它只需要定位那一行代码。这类任务即使失败返工成本也很低因为问题范围小人可以一眼看出对错。长时任务的特点是“多步、依赖交织、反馈延迟”。比如给一个 FastAPI 项目新增短链接功能需要先理解现有路由和数据层设计数据模型确定短码生成算法新增三个接口再补测试。中间任何一步出错不会立刻暴露而是拖到最后的接口联调或测试运行阶段才显现。错误在步骤之间累积最后定位起来非常痛苦。下面用一张表把两者的差异列清楚。对比维度短时任务长时任务任务规模单文件、单函数多文件、多模块、跨层改动上下文需求一个文件或一段代码项目结构、既有代码、历史决策反馈方式立即可见延迟到测试或联调阶段错误影响局部返工错误累积越往后越难定位验证方式肉眼检查自动化测试、diff review、回归验证典型场景补全函数、修 bug、生成 SQL新增功能、重构模块、数据迁移理解了这张表就能明白为什么“模型能写好函数”和“模型能交付功能”是两件不同的事。1.2 长时任务为什么容易失败长时任务容易失败不是某一个环节的问题而是四个因素叠加的结果。第一错误会在步骤间累积。短时任务里第一步错了第二步大概率能发现长时任务里模型在前半段写了一个不合理的数据结构后面所有接口代码都会建立在这个错误假设之上。到最后测试失败时看到的不是最初那个假设错误而是下游一连串的报错。第二上下文窗口是有限资源。长时任务需要的信息量往往超过单次上下文容量。模型读过app.py、models.py、历史提交、需求文档之后早期给它的需求描述会被后续内容挤占。很多翻车场景是任务做到一半模型开始“遗忘”最初的业务规则比如短码必须是 6 位结果生成了 8 位。第三中间验证太少。人写代码时会每写一个模块就运行一次AI 在长任务里如果没有被要求在中间停下来验证就会一路写到测试阶段最后一次性暴露所有问题。第四人为监督的反馈频率太低。很多人使用 AI 编程时是“发一段话等它全部改完”而不是“每个阶段检查一次 diff”。这等于让模型在没有导航的情况下跑一条很长的路偏差率必然上升。1.3 专门训练长时任务意味着什么关于模型本身的变化公开讨论和模型发布信息里提到的一个共同方向是针对 long-horizon tasks 进行专门训练。这里的“专门”不是指简单把代码数据量加大而是训练轨迹的结构发生了变化。常见的做法包括这样几类。训练数据里加入多步任务轨迹而不仅是单文件代码。让模型学习调用工具读文件、执行测试、查看报错、修改文件形成一个完整循环。在训练中引入自我纠错样本任务第一次执行失败后模型如何根据报错调整下一步行为。扩大长上下文训练比例让模型在信息量很大的场景下仍然能记住早期约束。对普通开发者来说理解这一点最大的价值在于不要用对待短时任务的交互方式来对待长时任务。模型能力再强如果提示词里没有阶段、没有验收标准、没有范围约束它也只能凭默认行为“发挥”。换句话说long-horizon coding 的成败一半在模型一半在任务的组织方式。2. 从 vibe coding 到 coding plan两类 AI 编码工作方式2.1 vibe coding 是什么适合放在哪里vibe coding 是社区里流传开来的一个说法描述的是这样一种工作方式开发者用自然语言把想法告诉 AIAI 连续生成代码开发者不逐行阅读只在方向层面把关。它的核心特征是速度极快适合探索原型、验证想法、做一次性脚本。这种方式的优点是门槛极低。一个不熟悉某个框架的开发者可以用自然语言描述“我想做一个把 Markdown 转成 HTML 的小工具”AI 就能给出可运行的代码。遇到报错直接把报错贴给 AI它继续改。在不断“反馈-修改”的循环里原型很快就有了。但它的问题也很清楚。没有计划、没有明确范围时AI 会在代码里加入自己的假设不读输出代码时坏味道和潜在 bug 会一直累积没有自动化测试时功能“看起来能跑”和“真的正确”之间没有任何保障。所以在生产代码库、多人协作、需要长期维护的场景里裸 vibe coding 风险很高。这里并不是要否定 vibe coding而是要给它一个准确的定位快速验证想法、做学习练习、搭原型它是利器直接推到生产它会把隐患藏起来。2.2 coding plan 和 spec先规划再动手和 vibe coding 相对的另一条路径是先让 AI 给出 coding plan人确认后再执行。coding plan 的工作流程通常是这样。开发者描述任务目标和范围。AI 输出计划它准备分几个阶段做每个阶段改哪些文件怎么验证。开发者审核计划修改不合理的地方。确认后AI 按计划逐步执行并在关键节点停下来等待确认。这个流程真正的价值在于它把“写代码”这个模糊动作拆成了“理解-设计-实现-验证”四个可检查的阶段。每一步都有明确的产出步骤之间互相独立出错时能定位到具体阶段。spec-driven规范驱动更进一步。它要求先写清楚规格接口定义、数据结构、行为约束、验收条件然后再让 AI 写实现。常见做法是以 markdown、YAML 或测试用例的形式把 spec 写下来让 AI 严格按 spec 执行。这样做的收益是验收标准在编码之前就已经确定代码是否完成不再靠感觉而是通过跑测试或比对 spec 来判断。2.3 两种方式怎么选把 vibe coding 和 coding plan / spec-driven 放在一起对比能更清楚地看到各自的位置。对比维度vibe codingcoding plan / spec-driven起点一个模糊想法一段明确需求或规范文档人工参与只看大方向审核计划、检查每阶段 diff质量保障依赖 AI 自觉依赖阶段验证和测试学习成本极低中等需要学任务拆解适用阶段原型、练习、一次性脚本生产功能、重构、多人协作失败后果问题隐藏到后期问题在早期暴露代码可维护性低高实际项目里这两种方式不是非此即彼。学习阶段可以用 vibe coding 快速建立感觉进入正式开发后切换到 coding plan 和 spec-driven才能控制长时任务的质量。很多团队的实践是先用 vibe coding 验证可行性确认值得做之后再写 spec、定验收标准让 AI 用 coding plan 重新实现。3. 最小案例把一个长时任务拆成 AI 能执行的 coding plan3.1 选一个能完整闭环的任务为了把前面的概念落到具体操作上下面用一个最小案例说明 coding plan 怎么组织。任务选择为给一个 FastAPI 项目新增“短链接生成与访问统计”功能。这个任务足够典型因为它同时涉及数据模型、接口设计、算法选择和测试验证是标准的 long-horizon task。项目结构假设如下。shortener/ ├── app.py ├── models.py ├── requirements.txt └── tests/ └── test_api.py现有app.py只含一个健康检查接口如下。# app.py from fastapi import FastAPI app FastAPI() app.get(/health) def health(): return {status: ok}models.py是空文件requirements.txt里只有fastapi、uvicorn和pytest。这样安排是为了让 AI 在有限上下文里快速理解项目避免让它去读大量无关代码。3.2 给 AI 的结构化 Coding Plan 提示词把任务描述和 coding plan 合并成一段结构化提示词是长时任务里最值得投入时间的动作。下面是一个可以直接使用的模板。任务为当前 FastAPI 项目新增“短链接生成与访问统计”功能。 阶段 1理解现状 - 读取 app.py、models.py、requirements.txt - 输出当前已有的路由列表和数据模型 - 如果发现文件缺失先报告不要自行创建 阶段 2设计 - 设计 ShortLink 数据模型短码 code、原始 url、创建时间 create_time、访问次数 visits - 确定短码生成算法用 6 位随机字符只包含字母和数字 - 当前阶段先使用内存存储不引入数据库依赖 阶段 3实现 - 新增 POST /api/shorten接收 {url: ...}返回 {code: ...} - 新增 GET /{short_code}实现 307 跳转并累加访问次数 - 新增 GET /api/stats/{short_code}返回访问次数 - 不修改 /health 接口 - 不新增不在需求列表内的功能 阶段 4测试 - 在 tests/test_api.py 中补充三个接口的 pytest 用例 - 覆盖正常跳转、重复短码、统计接口 - 运行 pytest直到全部通过 约束 - 只在现有文件上修改不新增文件 - 不修改 requirements.txt除非发现缺依赖 - 每完成一个阶段输出该阶段的变更摘要 - 遇到需求不明确的地方先列出问题不要自行假设这段提示词的核心不是让 AI 一次性把代码写完而是强制它按阶段工作。阶段 1 解决“理解项目”的问题避免 AI 基于猜测修改代码。 阶段 2 把设计决策提前尤其是短码算法和数据字段。 阶段 3 限定实现范围明确哪些接口必须做、哪些不能动。 阶段 4 把测试作为交付标准功能完成与否由测试结果判断。约束部分解决了长时任务最常出现的跑偏问题范围蔓延和自行假设。3.3 执行过程中的人工检查点不要只把提示词发给 AI 就等待最终结果。在每个阶段结束时人工要检查当前产出。检查点设计如下。检查点检查内容通过标准阶段 1 完成后路由列表和模型描述是否准确AI 能正确列出GET /health阶段 2 完成后字段设计和算法是否合理短码长度、字符集、统计字段齐全阶段 3 完成后新增代码 diff 是否符合范围只改了目标文件未动无关逻辑阶段 4 完成后测试是否全部通过pytest 输出 0 failed如果某个阶段检查不合格不要继续走后面的阶段。立即让 AI 修正修正后重新验证当前阶段再进入下一步。这个习惯能把错误控制在一个阶段内避免在整个任务完成后才开始排错。3.4 预期输出与运行验证任务完成后的接口行为可以用 curl 验证。curl -X POST http://127.0.0.1:8000/api/shorten \ -H Content-Type: application/json \ -d {url: https://example.com/docs}预期响应是一个包含短码的 JSON形如{code: aB3xY9}。随后访问跳转接口。curl -I http://127.0.0.1:8000/aB3xY9预期Location头指向原始 URL状态码是 307。最后查询统计接口。curl http://127.0.0.1:8000/api/stats/aB3xY9预期返回类似{code: aB3xY9, visits: 1}。测试环节运行pytest正常输出会显示 3 个用例全部通过类似下面的结果。 test session starts collected 3 items tests/test_api.py ... [100%] 3 passed in 0.12s 这里要特别提醒不要只验证程序能启动。接口的正常分支、跳转行为、统计累积都要验证到位这三点分别对应了功能可用、语义正确、状态变更正确。4. 长时任务能跑通的关键上下文、拆解、检查点4.1 上下文窗口不是越大越好很多人以为模型上下文越大长时任务成功率就越高于是把所有文件都粘贴进提示词。这其实是一个常见误区。上下文越大意味着模型需要在更多信息里筛选相关片段也意味着早期指令更容易被后面的内容稀释。更实际的办法是控制输入质量而不是盲目堆量。下面几条操作在实践里比“换一个更大窗口的模型”更有效。操作作用推荐做法先输出文件树让 AI 建立全局结构认知只列目录和文件名不贴文件正文按需读取文件减少无关信息进入上下文要求 AI 先读取指定文件再回答问题控制历史讨论长度防止中间对话挤占任务指令阶段性结果用摘要形式进入下一步限制输出范围避免长文件被截断或偏离要求只输出 diff或把结果写入文件以 3.2 节的案例为例项目很小上下文压力不大。但如果换成真实项目就要在提示词里明确要求先输出项目结构再逐步读取相关文件。这样模型每一步都知道自己在看什么而不是拿着整仓库代码做全局猜测。4.2 把目标拆成可验证的步骤coding plan 的核心不是“步骤多”而是“每一步都可验证”。拆解时有三个原则。第一每个阶段有独立产出。阶段 1 的产出是“现状描述”阶段 2 的产出是“设计结果”阶段 3 的产出是“代码改动”阶段 4 的产出是“测试通过”。如果两个阶段混在一起中间就没有检查点。第二每个阶段有验收标准。没有验收标准的步骤本质上只是把大任务拆成小任务并不能让 AI 更可靠。验收标准一定要可执行比如“pytest 通过”比“代码没有明显问题”有效得多。第三失败能定位到具体阶段。如果测试全挂了对照 coding plan 看是哪个阶段的产物出了问题。是数据结构设计错了还是路由实现错了又或者是测试本身写错了。定位粒度越细修改成本越低。4.3 用 git 和测试建立检查点在 AI 执行长时任务前先做两件准备工作。第一步创建独立分支并提交一个干净的初始状态。git checkout -b feature/ai-shortener git add . git commit -m chore: initial state before AI task这样每个阶段产生的改动都有 git 作为回滚基线。如果 AI 在阶段 3 把结构改乱了可以直接恢复到阶段 2 结束时的提交而不是手工撤销一片混乱的 diff。第二步在任务开始前写好一个基础测试。这个测试不一定覆盖新功能但至少要保证既有功能“在改动前后行为一致”。在长时任务里最常见的隐形事故就是新功能加好了但旧功能被带崩了。没有基线测试这个问题要到最后人工回归才会暴露。4.4 长时任务参数速查使用 AI 编程工具时与长时任务相关的参数和交互选项可以整理成一张速查表。参数或选项作用建议计划模式plan mode先输出计划不直接改文件所有生产任务先开计划模式自动接受编辑是否自动写入文件建议关闭改为逐步确认允许执行命令是否允许 AI 运行测试和命令可控环境开启生产环境限制输出长度上限单次回答最大 token 数要求输出 diff 而不是整文件并发的文件操作是否允许多文件并行修改限制为按顺序修改减少冲突不同工具对这些参数的支持程度不同命名也可能不一样但核心思想是一致的长时任务里人对关键节点的控制权不能被取消。让 AI 自动写代码没问题但“自动提交”“自动执行全部命令”“自动接受所有修改”这类操作要谨慎。5. 长时 coding 翻车点排查现象、原因、处置5.1 常见现象与根因对照把实际项目里见过的高频翻车现象整理成一张表排查时可以对照。问题现象可能原因检查方式处理建议AI 只改完第一处就停止任务没有拆步骤模型不知道后续要做什么查看提示词里是否有阶段列表补充 coding plan把阶段写清楚反复修改同一段代码但问题依旧模型基于旧文件内容工作检查上下文里是否残留旧版本代码清除历史重新读取当前文件新功能加好了旧接口坏了没有基线测试对旧接口跑一次回归任务开始前先补基线测试生成了大量无关代码缺少范围约束检查 diff 是否包含需求外改动在提示词里明确“不做什么”任务做到中途忘记早期需求上下文被中间讨论挤占查看模型是否复述过需求将需求重新贴入或使用子任务隔离Agent 长时间运行不结束缺少终止条件和验证步骤观察工具调用序列是否有循环在计划里限定最大修改次数和执行完测试即停止单元测试通过联调却失败测试只验证了正常分支检查异常分支和边界输入补充错误输入、重复请求等用例这张表覆盖了从提示词设计、上下文管理到验证机制的常见问题。大部分翻车都不是模型“变笨了”而是任务组织方式没有跟上模型的执行方式。5.2 建议按这条链路排查长时 coding 任务出问题时不要急着怪模型也不要在代码里到处找原因。按下面的顺序排查效率更高。输入是否正确。需求描述里有没有歧义任务范围有没有写清文件路径和命名是否正确。AI 是否因为找错文件而改了错误位置依赖和版本是否匹配。新代码是否用了本项目没有的依赖配置是否生效。路由注册、环境变量、启动命令是否正确上下文是否过期。AI 读取的是否是当前最新代码日志和报错是否明确。测试失败信息里真正的原因是什么模型或工具本身是否有限制。是否超过输出长度或被工具权限限制这个顺序的核心是先排查输入侧和链路侧最后才怀疑模型能力。在实际案例里绝大多数长时任务失败都出在前三项。5.3 三个最容易踩的坑第一个坑是把整仓库代码粘贴进提示词。这样做的目的是让模型“看得全”结果却是上下文被大量无关文件塞满模型反而更容易忽略关键需求而且一旦代码有更新提示词里的旧代码就会变成错误信息来源。正确做法是先给目录结构让模型按需读取。第二个坑是没有增量验证把所有验证放在最后一次性进行。长时任务的错误会累积最后一次性跑测试时失败信息往往涉及多个模块定位成本极高。正确做法是在每个阶段结束时运行小范围测试或手工检查把问题控制在当阶段。第三个坑是拿着 vibe coding 的方式去做生产功能。vibe coding 没有计划、没有测试约束适合探索原型生产任务需要的是 coding plan、验收标准和 dif review。两者工具可能一样但使用方式完全不同。把两者混淆是很多“AI 写出来能用但不能维护”项目的根源。6. 最佳实践从 vibe coding 到 spec-driven 的落地路径6.1 学习环境与生产环境分开不同环境对 AI 编程工作流的容忍度完全不同。学习环境里可以大胆用 vibe coding让 AI 多跑几轮、多犯几次错通过反复修正理解一个框架生产环境里每一行代码都要能解释、能测试、能回滚。环境推荐工作流质量要求关注点学习环境vibe coding自由探索能跑通即可理解概念和调试过程开发环境coding plan每阶段 diff review代码可读、有基本测试功能正确性和改动可控测试环境spec 自动化测试覆盖正常、异常、边界回归风险和兼容性生产环境spec-driven 严格 review可追踪、可回滚、可监控配置外置、日志、权限、告警生产环境里还需要额外关注几件事配置不要写死在代码里日志要能追踪一次请求的完整链路权限和密钥要通过环境变量或配置中心管理发布前要确认有回滚方案新依赖进入生产代码前要评估许可证和安全风险。6.2 可复用清单长时 Coding 任务执行前中后下面这份清单可以直接复制到自己的团队文档里。它把前面所有内容压缩成可勾选的检查项。任务开始前[ ] 用一句话写清功能目标和“不做什么”[ ] 输出项目目录结构确认技术栈和文件位置[ ] 创建独立 git 分支并提交初始状态[ ] 确认既有功能的基线测试存在[ ] 写好 coding plan每个阶段含独立产出和验收标准[ ] 在提示词中列出硬约束不改哪些文件、不加哪些依赖任务执行中[ ] 每完成一个阶段输出变更摘要[ ] 每个阶段结束后人工检查一次 diff[ ] 每阶段运行一次测试或验证命令[ ] 上下文接近上限时先总结已完成内容再继续[ ] 遇到需求不明确时停止执行并询问不让 AI 自行假设任务交付前[ ] 测试覆盖正常分支、异常分支、边界输入[ ] 检查是否遗留调试代码、注释掉的代码、硬编码密钥[ ] 检查配置是否能外置日志是否包含关键链路[ ] 生产环境确认监控、告警、回滚方案[ ] 用一次完整的 diff review 确认没有范围蔓延6.3 下一步可以扩展的方向把这套工作流跑熟之后可以往三个方向深入。第一个方向是 spec-driven 工程化。把“写 spec”变成一种正式实践用 markdown 或 YAML 维护接口定义和验收条件让 AI 严格按 spec 实现再通过自动化测试验证 spec 是否被满足。这样代码和规范之间有了一一对应的关系维护成本会明显下降。第二个方向是任务编排。单个 coding agent 处理长时任务时上下文和工具调用次数都有限。可以把一个大任务拆成多个子任务由外部流水线或脚本调度多个 agent 依次执行每个 agent 只负责一个阶段。这就是目前社区关注的 harness 与规范驱动开发结合的方向适合项目规模变大后尝试。第三个方向是改变 AI 参与代码的方式。除了让 AI 生成代码还可以让 AI 做 code review、补测试、分析测试覆盖率、检查安全依赖。维码只是其中一环代码质量的关键节点同样值得让 AI 参与。回到最初的问题为什么 long-horizon tasks 是 AI coding 的分水岭因为它同时考验模型的长程规划能力、上下文管理能力和工具调用能力也考验开发者能不能把一个模糊需求组织成可验证的阶段。对使用者来说最有价值的能力不是“让 AI 写得更快”而是学会拆任务、设检查点、建验证闭环。把这三件事做好AI 完成长时任务的稳定性会显著提升做不好换再强的模型照样会被一连串累积的小错误拖垮。