Vibe Coding 这个词从 2024 年尾开始刷屏几乎每隔几天就能看到新工具宣称“用一句话生成一个应用”。我当时觉得这就是又一个被放大的炫技概念直到自己带着它做了几个能要走完一整套验收流程的真实项目才意识到大多数讨论都在争一个伪问题——AI 写代码到底靠不靠谱。真正值得拆解的其实是另一件事当写代码的方式从“人手敲键盘”变成“人和模型来回对齐”整个工程链条要怎么重新设计才能让产出的东西在验收、部署、维护环节里依然被人信任。这篇文章适合两类人看。第一类是已经开始用 Cursor、Copilot、Codex 这类 AI IDE 或编程 Agent 的开发者总感觉“代码能跑起来”和“我能放心交付”之间差了点什么却说不出差在哪。第二类是团队负责人正考虑在项目里引入 AI Agent 写代码又怕代码库失控。下文不评测工具只讲“Vibe Coding 怎么从个人手感升级成代理式工程”的底层逻辑以及我自己踩出来后总结的实操方法。先给一个我个人的总判断Vibe Coding 不是错误它只是开发流程的一个入口。入口之后所有工程问题都会被放大而不是被模型自动消化。想让它真正可交付你必须把“凭感觉”翻译成“规格”把“灵感”翻译成“验收门”把聊天记录翻译成可审计的变更记录。这就是从 Vibe 到代理式工程的完整路径。1. Vibe Coding 的底层逻辑它凭什么成立又凭什么危险1.1 语言成为编程接口之后发生了什么Vibe Coding 描述的状态很直接你用自然语言描述意图让大模型把意图变成代码你再运行、观察、继续提要求整个过程像在“带节奏”所以叫 vibe。在这样一个循环里编程的主入口从“精确语法”变成了“语义表达”这是它最颠覆性的地方。大量开发者发现很多以前要花一小时查文档才能写的模块现在只要把需求说清楚几十秒内就能得到一版能跑的代码。这不是模型在“理解业务”而是它在训练数据中见过大量相似模式的实现能够基于上下文做出概率最高的补全。换句话说Vibe Coding 成立的前提是模型具备了极强的“模式接续”能力而不是因为它真的理解你的系统。这个机制决定了它天然擅长一件事在有明确“标准答案形态”的领域里快速生成符合惯例的代码。接口封装、CRUD 页面、脚本工具、临时数据处理这些任务重复度高、范式清晰模型几乎没有发挥空间但恰恰是这种任务里它最可靠。反过来越是需要准确业务判断、跨模块影响分析、历史包袱权衡的工作它越容易“一本正经地胡说八道”。我刚开始用的时候一个很深的体感是模型每次给我的代码都特别像回事结构清爽、注释齐全甚至还会顺手预留扩展点。这反而是一种危险——因为它的“信心”和“代码质量”并不代表它对全局有认知它只是在做一个非常优秀的局部续写。1.2 Vibe Coding 真正擅长的边界在哪里如果给 Vibe Coding 画一个能力雷达图它的强项集中在三个方向。第一是快速原型。从零到一做一个 demo或者验证某个交互是否可行根本不需要规范流程。你脑海里的想法还不完整一边和模型聊一边把它补全这比坐在白板前画架构再写代码高效得多。第二是填补重复模式代码。比如按固定格式生成一堆 DTO、路由配置、测试桩只要给它一两个样例它能连续产出高质量副本。第三是解释和理解陌生代码。把一段老代码丢给模型让它注释或改写比人肉逐行追踪快很多。但它的边界也很清楚当项目规模超过上下文窗口的覆盖范围当一次改动会牵扯多个模块的隐藏约定当团队的长期维护价值大于短期上线速度Vibe Coding 的“随性”就开始变成负债。最典型的表现是你让它“加一个小功能”它只盯着你提到的那一两个文件改完全不会意识到某个基类里还有两处分支需要同步调整。你在 vibe 状态下很难察觉这种遗漏因为运行结果可能正常直到某个边界输入出现才会暴露。所以我不建议把 Vibe Coding 理解成“一种低质量编程方式”更准确的说法是它是一台没有仪表盘的挖掘机。干活很快但你在驾驶室里看不到引擎温度、油量和周围障碍物。小面积施工没问题要在复杂的管线旁边作业就得先加装监测设备。1.3 “凭感觉”为什么容易被误认为生产力Vibe Coding 给人最大的错觉是“我产出很快”这种快感来自超短反馈循环。你在聊天框里提一个新要求几秒钟后改动出现运行一下看到效果再提下一个要求。这是典型的“操作—反馈”回路天然让人上瘾和我们刷短视频时停不下来的机制没有本质区别。但工程交付是慢反馈系统。代码合并之后要等测试覆盖、代码审查、灰度发布、线上监控真正的问题往往在几周甚至几个月后才暴露。两种反馈速度的巨大落差导致很多人长期停留在“我很高产”的假象里每天能生成上千行代码可到了要发版的时候却因为没人说得清系统到底依赖了什么、哪段逻辑和需求有偏差而迟迟不敢合并。我一度也陷入过这种状态。连续三个晚上用 vibe 模式冲出一个功能页面确实都跑通了结果第四天产品说“这个按钮的状态要和另一个模块联动”我花了整整两天才理清模型生成的代码里分散在五个文件中的隐藏状态。那一刻我意识到真正的生产力不是“生成代码的速度”而是“从当前状态抵达可交付状态的速度”。后者包含理解、验证和修正成本而 Vibe Coding 恰恰会把这些成本延期并且延期到最难处理的时候。2. 从“能跑”到“可交付”Vibe Coding 缺的那几道闸门2.1 纯 Vibe 产出的典型症状和纯 vibe 模式打过一段时间交道后我从自己和他人的项目里总结出几个高频症状。第一是“能跑但不可改”。代码看起来都合理可一旦需求变更你会发现自己根本不敢重构。因为模型生成时没有考虑模块间的耦合约定每一处都被“足够好”地实现但没有任何设计主线。第二是“测试由 Agent 写Agent 自己验证”。让它补测试它通常会基于自己对实现的期待生成测试结果测试全绿实际上什么都没验证到。第三是“缺少变更记录”。对话上下文会不断刷新改了哪几个文件、为什么这么改如果没做梳理可能等代码 review 时你还需要重新问它一遍。第四是“边界条件大面积缺失”。模型非常擅长生成 main path但异常分支、超时、权限不足、重复提交、数据格式错误这些分支它不会主动想到。短期的运行演示看不出问题生产环境的异常流量一来到处是洞。第五是“依赖随意引入”。你让它展示 CSV 解析它很可能直接顺手引一个库而不考虑这个库的许可、维护状态和安全漏洞。这些症状其实指向同一件事Vibe Coding 缺的不是代码生成能力而是“交付闸门”。一个能稳定交付的工程流程必须有人检查改动范围、有人验证行为、有人记录变更原因、有工具拦住意外依赖。如果你不在流程上设置这些闸门它们就会被跳过去而不是被模型自动补上。2.2 什么是真正意义上的“可交付”“可交付”听起来像一句废话做工程的人都以为自己懂。但在 AI 生成代码的语境下它需要被重新定义。对我来说一段代码只有同时满足下面五个条件才算真正可交付。能验证有可以自动运行的测试或检查能证明这次改动实现了预期行为而不是“我看运行结果没问题”。能理解过一个月或者换一个同事来读能够从代码和注释里推导出设计意图而不是需要重新问一遍原对话。能回滚改动被限制在明确的范围内出了问题可以快速定位并撤销不会因为代码分散导致无处下手。能演进在此之上继续加功能不需要推翻重来模块边界足够清晰可以局部替换。能审计每行关键逻辑都能追溯到某条需求或某个决策而不是“模型说这么写”。用比喻来解释的话AI 生成代码很像请了一个实习生在周末加班干活。实习生的产出能跑、能演示你表扬他效率高。但等到你要把这份工作交接给正式同事时才发现他干活过程中做的判断没人知道原因涉及的隐藏依赖他不知道测试也都是照着源码写的。这时候项目还能算交付吗显然不算。所以在代理式工程里我刻意把“可交付”放在“功能完成”前面。宁可让 Agent 少写两成新功能也必须有测试、有文档、有清晰的提交记录。这不是保守而是因为 AI 生成代码的不确定性已经足够高交付闸门如果再放松代码库会以指数级速度腐化。2.3 Spec-driven 是对 Vibe 的第一次纠偏要治“凭感觉”这个病最有效的第一步就是引入 Spec-driven Development也就是规格驱动开发。它的核心主张是动手写代码之前先用可验证的方式把“做什么、怎么算完成”写清楚。Vibe Coding 从 prompt 出发问的是“帮我把这个页面做出来”Spec-driven 从契约出发问的是“这段逻辑的输入输出边界是什么、验收条件是什么”。这两者真正的区别不在“要不要用 AI”而在“验证依据从哪来”。Vibe Coding 的验证依据是人的观感——页面看起来对不对结果感觉好不好Spec-driven 的验证依据是事先定义的行为约束——数据状态是否符合预期边界条件是否被处理。前者依赖主观后者指向客观。我见过很多团队以为自己在做 Spec-driven实际上只是把需求文档写长了一点里面全是“支持用户登录”“展示数据列表”这种无法验收的描述。真正的规格应该长这样用户可以输入合法的 JSON提交后系统返回 201 和持久化 ID当 JSON 超过 1MB 时系统返回 413 并给出明确错误信息不写入任何脏数据。这样的句子才有资格称为验收条件。实际实施的时候并不需要一开始就上复杂工具。一个普通 Spec 文档就够了记录功能目标、用户故事、验收标准、非目标明确不做什么、涉及的接口和数据结构。关键是让 Agent 在生成的代码里显式对照这些验收条件并在提交描述里说明每一项是怎么做到的。这一步会立刻过滤掉一大部分“貌似能跑但根本没写到点子上”的输出。3. 代理式工程把 Agent 关进“轨道”里干活3.1 从交互式编码到代理式开发如果说 Spec-driven 是在“做什么”的层面做约束那代理式工程Agentic Engineering就是在“谁来做、怎么做”的层面做升级。Vibe Coding 的交互模式本质上是人机结对每次改动都由人发起提示模型给出回应。而代理式开发的变化在于Agent 不再只是“回答你问题的聊天框”它被赋予一系列工具和环境可以在限定的范围内自主执行多步任务读文件、跑测试、修 bug、提交代码。这里有一个理解上的鸿沟。很多人在 Vibe 模式下用 Agent 只干一件事生成一个文件或者改一段函数。一旦让它做“把某个接口从旧方案迁移到新方案并保证测试通过”这种多步任务它就开始失控。根因不是模型变笨了而是你没有为它设计足够清晰的“运行轨道”——一套从任务目标到验收标准的完整闭环。我习惯把代理式工程比作工地管理。Agent 是一个技术出色但不太了解工地规矩的施工队。你不给它施工图、不划定作业范围、不提供验收标准它也能砌墙但很可能把承重墙砌错位置你给它一份图纸、一块围起来的作业面、一套质量检查流程它就能在规定区域内高效施工。代理式工程的核心工作不是在工地门口喊“你要好好干”而是把图纸、围栏、检查流程全部准备好。3.2 Harness不是散装 prompt而是开发环境上的“运行轨”围绕 Agent 搭的这套围栏现在行业里通常叫 Harness。很多朋友对它有个误解觉得 Harness 就是一段写得很长的 system prompt里面塞满“你要遵循最佳实践、不要乱改代码、注意安全性”。这种思路只能说方向对了一半因为 prompt 只是静态文本Agent 执行任务时有没有真正遵守它自己说了不算跑完也没办法被机械地检查出来。真正可用的 Harness 应该是一套能够和开发环境联动的规则系统我觉得它至少包含六个模块。任务与约束明确要做的功能目标、明确的非目标以及必须遵守的技术栈约束例如“后端是 Python 3.12不要引入非标准库作为新依赖”。上下文入口告诉 Agent 代码库的结构、相关文档、要修改的核心模块路径避免它在没有全局视角时到处乱猜。工具集合给 Agent 提供执行 shell、编辑器、测试运行器、Git 操作等能力让它不只停留在生成文本而是能真正操作环境。自动校验器把 lint、格式检查、类型检查、单元测试和静态分析都接进流程一旦 Agent 执行完就自动跑一遍而不依赖它口头汇报“我测试过了”。反馈机制校验器输出的失败日志要能被送回 Agent 的上下文让它据此进行修复形成“执行—失败—修复—再验证”的闭环。权限边界用文件白名单、禁用命令列表、环境变量保护等手段防止 Agent 的自主操作造成不可控破坏。这六个模块组合起来Agent 才真正像是在一个受控的开发机里干活。它知道自己该做什么做完马上有自动检查接住结果出错了还能根据反馈修正。没有这个 Harness代理式工程和“高配版 chat 打补丁”没有区别。3.3 底层逻辑升级由直觉反馈转向流程验证Vibe Coding 站在一个很讨巧的位置上它把“主观的 vibe”当作标准。你感觉不错代码就通过了。但代理式工程做的事情恰恰相反它把所有关键判断点都从“感觉”挪到了“流程验证”上。Agent 做完了任务然后呢不是你说一句“看起来没问题”而是 CI 跑完一整套检查测试用例给出绿或红代码扫描结果符合预期版本变更记录完整。这听起来像是一种限制其实是对 Agent 能力的解放。没有明确验证标准的时候Agent 和人都不知道任务什么时候真正结束两边都会陷入“再改一轮试试”的漩涡。有了验证流之后Agent 可以在失败日志的引导下自主修到绿人只需要在关键节点做判断。模式从“每一行都要人盯”变成“人在轨道出口做质量把关”效率差的不是一点半点。用我自己的体会来说Vibe Coding 像是开车在一条没有路灯的乡道上近光灯只能照亮眼前十米代理式工程则是把道路护栏、指示牌和限速标志都装好然后在车上装了一套自动驾驶系统。你不需要时刻握紧方向盘但要清楚每个入口出口在哪以及哪些路段必须人工接管。底层逻辑变了手里的工具才真正敢交给 Agent。3.4 为什么单靠“会写提示词”走不到这一步那个时期流行“prompt 工程”的时候很多人花大量精力研究话术、技巧和“角色设定”试图靠一段神奇的咒语让模型变得更聪明。这套东西在 Vibe Coding 阶段是有效的因为模型的输出质量确实会随着指令的清晰度改变。但如果你要构建的是代理式工程讨论的重心就必须从提示词转移到环境与流程上因为提示词无法带来可靠性和记忆。一段写得很好的提示词只能短时间约束模型行为换个任务、过个上下文窗口、遇到没见过的错误日志它照样自由发挥。但流程不一样它被固化在文件系统里、在 CI 脚本里、在测试用例里、在分支保护规则里任何一次任务都必须通过同一套验证不会有“这次忘了”的余地。我曾见过一个团队把 Agent 的 system prompt 改了几十版就为了让它在每次改动时都跑一遍测试。后来我把“跑测试”直接接进 Harness 的校验器里执行完成后自动执行 npm test不允许 Agent 跳过。从那以后没有一个人再关心 prompt 怎么写因为机制保证了行为。这就是这个行业正在经历的转变从“提示词工程”走向“流程工程”。4. 实操一个内部数据看板如何用“Spec Harness”流程落地4.1 第一步把想法翻译成可验收的 Spec讲完理论我拿最近一个内部项目的流程做实例拆解。背景很简单团队需要一个内部错误数据看板接数仓库日志按时间维度展示不同服务的错误数趋势异常时候要能提醒维护人员。这个项目不算大但涉及前端展示、后端聚合、数据源接入三块恰好适合观察 Agent 在受控流程中的表现。第一件事不是打开聊天工具写代码而是写一份足够“可验收”的 Spec。我用的模板大致包含四个部分功能目标说明这个看板给谁用、解决什么问题用户故事与验收标准用 Given/When/Then 格式描述关键路径非目标明确这一期不做权限对接、不做告警下发、不做移动端适配接口与数据约定约定数据源格式、聚合维度、前端渲染字段。举一个具体验收标准例子作为运维负责人给定过去七天的错误日志数据当我打开看板首页时系统应在三秒内展示按服务分组的错误趋势折线图当数据源无响应超过五秒时页面应显示明确错误状态并保留上一次成功加载的数据。这句描述是 Agent 能够对照自测的因为“三秒”和“无响应超过五秒”都是可判定条件。我更建议不要写“系统要提供良好的用户体验”这种话它们无法被自动或人工判定只会把 Agent 带回 vibe 模式。写 Spec 的时间不要省。这个项目我花了大约两个小时梳理需求但之后整个开发阶段几乎没有出现过“做出的东西根本不是我要的”这种推倒重来。Spec 越清晰Agent 的自由度越小最终产物的可控性越高。4.2 第二步给 Agent 搭一块能安全干活的场地Spec 写好之后我给这次任务搭了一个最小 Harness。因为是内部工具我优先保证四点依赖约束、命令规范、目录边界和测试入口。依赖约束很简单在仓库 README 和 AGENTS.md 里写明技术栈固定为某一套组合并注明所有新增依赖必须列出理由由人工确认后单独提交。这么做的原因是 Agent 太喜欢引入新库了它每遇到一个小问题就倾向于找一个库来解决完全不考虑维护成本。只允许用现有依赖完成后它的实现会朴实一些但可控性明显更高。命令规范是把开发流程中会用到的测试、类型检查和 lint 脚本固定下来并同时写进 Harness 的校验逻辑里。我告诉 Agent“每次修改完成后请运行 npm run test 和 npm run lint并把输出结果作为提交说明的一部分”。校验器本身也会跑同样的命令防止它跳过。目录边界是用来限制改动范围的。对于内部看板我直接限定 Agent 只能改 srv/api、src/view 等指定目录其他如部署脚本、公共配置文件的修改一律需要人工另行审批。这个限制非常有效它避免了 Agent 在一次“加个图表”的任务里顺手改了 CI 配置或者公共请求封装造成影响面扩散。最后是测试入口。我会事先手写两三个“种子测试”把最核心的业务逻辑用测试钉死。比如“数据聚合接口在输入合法时返回 200按服务分组后数量正确”“数据源无响应时返回降级状态而不是空数组”。这些测试由人先写Agent 只需要让实现满足测试这让它的自主探索被牢牢锁在正确范围内。4.3 第三步用粒度任务和 Pull Request 建立交付节拍Harness 准备好之后agent 开发流程要进入“小步快跑”的节拍。我做过对照组让 Agent 一口气完成“整个看板从零到一”出过一次非常绝望的情况它一次就生成了两千多行代码基础设施、服务端、前端一次到位初看很完整但数据源一断、时区一换整套东西就乱了改起来比从零写还麻烦。后来我换成按 Spec 中的用户故事拆分任务一次只做一件事并建议不要贪多。拆完的任务可能是“搭一个响应 /api/trends 的聚合服务读取本地缓存的样例日志返回按服务分组的最近七天趋势数据附带测试”。这种任务粒度大概只涉及 200 到 500 行变更Agent 全部处理完不会超过上下文窗口人工 review 也扛得住。每次任务执行完毕后Agent 需要把改动提交为一个独立的 branch 和 Pull Request并在描述里写清三个东西这次改动对应 Spec 里的哪一项改动时做过的关键假设比如数据源字段格式与预期一致运行测试和 lint 的结果截图或日志摘要。这套要求看起来很琐碎但它让 Agent 的工作过程变得可审计、可回滚。每个 PR 就是一次可验证的交付单元而不是一条长长的对话记录。等到所有独立 PR 都合入主干再把联调环境部署起来做一次整体验证。我把这个阶段叫“交付节拍”开发过程中几乎每一小时都有一个小交付物可以被检查和合并它让 AI 的高频输出和工程的低频验收之间找到了平衡。4.4 第四步代码评审要看 diff更要看“证据链”即使有 Spec、Harness 和验收门代码评审仍然是不可省略的一环。Vibe Coding 时代最容易被人忽视的审查问题是你和 Agent 的对话上下文会消失但代码会留下来。如果 review 时不把证据链记录清楚后续维护者就只知道代码长这样不知道它为什么长这样。我给自己定了一个评审清单。第一diff 是否在 Spe c约定的目录和任务范围内第二是否有未声明的依赖变更第三测试用例是否覆盖了 Spec 里每条验收标准尤其是失败路径第四是否存在硬编码的密钥、IP、数据库连接串第五错误处理方式是否符合项目现有惯例例如统一走错误中间件还是各自 catch第六是否修改了与本次任务无关的代码。为了让这个环节更高效我在 Harness 里加了一段自动摘要提示要求 Agent 在提交前自己生成“改动摘要”。它要把改动归纳为几句话并说明每处关键改动对应的需求点。这么做有两个好处Agent 为了生成准确的摘要被迫在提交前重新审视一遍自己的改动一些明显的冗余或无关改动会被它自己清理掉人工 review 时也不用在两千行 diff 里大海捞针而是先看摘要再抽查对应位置。这里我说一句容易被忽略的体感review Agent 的代码不完全是在审代码质量更是在审“它有没有走偏”。Agent 的常规输出质量并不低真正让人头疼的是它在需求理解上的细微偏移。每一处偏移在代码上都显得合理但合在一起产物就变成了“看起来是你的功能用起来到处是别扭”。只有对照 Spec 一条条过验收条件才能把这层偏移揪出来。5. 场景判断与工具选型什么时候适合 Vibe什么时候必须 Spec5.1 三种典型场景与推荐策略不是所有项目都需要完整 Spec 和 Harness也不是所有项目都可以靠纯 Vibe 一把梭。做了一段时间后我倾向于把任务场景分成三类每类的策略差别很大。第一类是“探索型原型”。你只是想验证一个想法是否成立例如“能不能把某个 Excel 导入流程改成移动端扫描”这类工作建议直接 Vibe Coding不要用任何流程拖慢速度。但心里要清楚原型经过验证后如果确定要做成正式产品很大概率要重写不能直接在上面叠代。第二类是“内部工具与中小型全栈应用”。这类场景最适合从 Vibe 走向轻量 Spec。我的做法是只写核心用户流程和验收标准Harness 要求也降级不需要依赖锁定那么严格但必须包含自动测试入口。如果项目是用 Vercel AI、Replit 这类云端平台起步的也要尽早把数据模型和核心业务逻辑固定成一两个测试文件防止功能越堆越乱。第三类是“核心系统与高并发服务”。这类代码涉及状态一致性、权限边界、资金或数据安全任何一行都不能没有归属。这里没有商量余地必须先定义接口契约和异常语义再由 Agent 在指定目录内实现测试要覆盖异常分支CI 里要有安全检查工具。纯 Vibe 在这里不是“不好”而是“会出事故”。现在有不少平台试着把“AI 生成应用”和“部署后端”一体化声称用户做几个选择就能得到一个可发布的应用。这确实是 Vibe Coding 的进步但它本质上是把某些工程规则置入 Harness 里了不代表工程流程可以省略。平台替你处理了鉴权、数据库、部署好让你专注业务逻辑可一旦你的业务超出平台的抽象范围那些被隐藏的工程复杂度会原封不动地还给开发者。5.2 生态适配阶段的“分层使用”我也看过很多文章讨论“鸿蒙 Vibe Coding”之类的话题其实这类话题背后的共性是当 AI 要接入一个拥有独立应用框架、签名和发布流程的生态时Vibe 只能在特定分层起作用。用自然语言生成符合国产系统规范的自绘 UI 卡片可能很快但那只是视图层如果涉及系统权限、应用签名、隐私弹窗、后台行为约束这些默认不对开发者开放的机制Agent 不可能从“感觉”里想出来。我的处理方法是做“分层使用”视图、静态数据、简单交互这类低风险层可以放心让 Agent 充分 vibe系统和权限相关层则以官方文档作为 Harness 的上下文入口并要求 Agent 每次引用文档章节解释自己的改动依据。比如“关闭页面后要继续定位需要在 manifest 中声明 xxx 权限并写清启动场景”这句话放到 Spec 里就变成了可验证门槛。这种方法的好处是既没有放弃 Agent 的效率优势也没有让它在高风险区域盲抽。很多新手容易误入的路径是因为整套系统跑在 Vibe 模式下就让 Agent“顺手把权限申请给它补上”结果产物在真机上无法安装或发布会直接被打回。这其实不是 Agent 能力问题而是你没有在合适的层做合适约束。5.3 Agent 选型时的现实考量工具选型方面我不想给一个“最强”结论因为迭代太快。从实践经验上看更值得关注的是 Agent 与工作流的契合度它是否能执行自动测试是否能操作 Git 并生成规范 commit是否有明确的权限控制方式限制它访问特定文件以及是否支持把外部文档灌入上下文。这些能力决定了 Harness 能不能搭起来比单次代码生成质量更重要。如果你是在 IDE 里用 Copilot 写代码它更像是“结对程序员”适合在人工主导的过程中补全代码。如果你用的是 Codex 或 Cloude Code 这类偏命令行交互的工具它更适合在 Harness 里作为执行主体完成多文件改动并调用测试。选择的关键是先想清楚“谁是主导者”。人工主导的工具强在实时和轻量代理执行式的工具强在批量与自主没有一种工具能同时做到两者极致的平衡。项目若小直接选和 IDE 融合最好的项目大了宁可选那些能接 CI、能跑测试、能限制权限的工具不要因为单次生成效果惊艳就忽略工程可控性。工具迭代快但判断框架不过时。6. 常见问题与排查技巧实录6.1 六个高频翻车现场现场根因解决思路Agent 反复重写同一段代码提交前又推翻没有明确验收标准只凭“感觉不对”迭代先写 Spec 验收条件每次改动后只对照条件不关心风格好坏告诉它“不要动 X 文件”它还是改了上下文太长初始约束被稀释或被相关引用带回它在 Harness 的文件白名单里直接禁止路径比用自然语言强调可靠得多测试全绿功能实际是错的测试是 Agent 自己写的测试对实现的“自我确认”太强关键断言由人先写或引入独立样例数据阻断测试与实现的同谋加了新功能却破坏了旧行为Agent 只看到局部上下文没意识到全局依赖提升测试覆盖率强制让它跑全量测试而不是“只测相关功能”代码里出现无法解释的依赖Agent 为省事引入外部库在 Harness 中定义“新增依赖必须单独出一份 PR 并说明理由”Agent 陷入死循环反复修但不同修 bug 时缺少根因定位能力只是随机试错要求 Agent 先写“根因假设”再改代码并且每次失败后更新假设避免盲目跑这张表里的问题大部分不是模型聪明度的问题而是工作流设计的问题。把流程卡到位一半以上会自动消失。剩下一部分仍然存在的通常需要人工介入做高难度判断。6.2 几条直接能用的排查经验我做 Agent 任务调试时最常犯的错误是“陪它一起迷路”。Agent 连续三次提交都不对我会下意识地继续在提示里补充更多细节结果对话越来越长模型越来越抓不住重点。后来我强制自己换一种策略一旦同一个任务连续失败两次我就把任务重新拆小退回上一级结论而不是在原有问题上继续叠背景。第二个经验是给 Agent 尽可能小的“最小复现样本”。比如触发 bug 的数据是一份 20MB 的日志Agent 会被淹没在里面我用脚本截取出 10 行能触发问题的样例再配上预期输出的描述它通常几分钟内就能定位根因。用户提供的局部上下文越干净Agent 的分析质量越有把握。第三是多训练自己看“失败日志”而不是看“报告”。Agent 在提交说明里写“测试全部通过”我不会直接相信。我会在 CI 页面或本地终端重新看一眼真实输出。这个习惯跟信任没关系纯粹是因为 Agent 的自我汇报与真实状态之间存在系统性的偏差靠感觉弥补不了只能靠工具确认。6.3 从“代码生成器”到“工程协作者”的转变回头看随着我对工具的掌控更强我对 Agent 的定位也从“代码生成器”转变成了“工程协作者”。前者的用法是把它当打字机我告诉它要什么它打出来我来复制粘贴。后者的用法是把它当作一个在固定轨道内工作的执行者我不仅告诉它要什么还告诉它规则是什么、边界在哪、完成后怎么证明自己做到了。这个转变并不发生在一次操作里而是发生在你对“交付”这个词的理解变深之后。我完全理解为什么很多人会在 Vibe Coding 阶段感到兴奋那种“我说什么模型都能写出来”的体验确实有魔力。但我也越来越确信把工程建立在“感觉”上是不可持续的。模型的不确定性要求我们用更确定的事情去对冲才能在享受高效率的同时不失去控制权。所以每次新建项目我都建议你先问自己三个问题如果这个代码被 AI 破坏我能发现吗如果这个代码要交接给别人他们能独立接手吗如果这个 Agent 明天就换了一个模型这套流程还能继续跑吗前两个问题决定你要不要写 Spec第三个问题决定你需不需要搭建 Harness。想清楚了再决定自己是放开手脚 Vibe还是多花两小时把轨道铺好再让 Agent 上工。根据我自己的项目体会愿意先做这道判断题的人通常都不会被 AI 编程时代甩下车。