从 Vibe Coding 到 Coding Agent：最后由谁验收

2026/6/20大约 8 分钟

Vibe Coding 这个词近期很热。

它说的是一种很直观的开发方式：开发者不再从空文件开始一行行写，而是用自然语言描述想法，让 AI 先生成代码、页面、脚本或者一个能跑起来的原型。

这个词有传播力，也确实抓住了一部分现实。但如果把所有 AI 编程都叫成 vibe coding，又会显得不够准确。

做一个本地小工具、快速搭一个 demo、让 AI 补一个函数，这些可以叫 vibe coding。可当工具开始读仓库、改文件、跑命令、接 issue、开 PR、进入 CI/CD，它已经不只是“凭感觉写代码”了，而是在进入软件交付流程。

这时更合适的词可能是 AI coding agent。

区别不在叫法上，而在责任边界上。生成一段代码，只需要审代码。一个 agent 改了项目、触发测试、提交 PR，就必须审整条变更链路。

工具已经进入交付流程

几个主流工具的形态正在靠近。

OpenAI 的 Codex web 文档里写得很直接：Codex 可以读代码、编辑代码、运行代码；在 cloud 模式下，它能在自己的云环境里后台处理任务，也能并行执行。这个定位已经不是“帮忙补全”，而是“把一件事先放到隔离环境里跑一轮”。

Copilot 也是类似逻辑。GitHub 官方介绍里说，把 issue 分配给 Copilot 后，它会启动虚拟机、clone 仓库、配置环境、分析代码，然后把修改持续推到 draft PR。过程中还能看到 session logs，用来追踪它做了什么。

Google Jules 的入口更像 GitHub 工作流：给 issue 加 jules label，它会把仓库拉到 Cloud VM，先生成计划，再给 diff，最后创建 PR。Claude Code Action 则把 agent 放进 GitHub Actions，用评论、issue 或 workflow 输入触发它做代码审查、triage 或生成代码。

这些工具背后的方向很清楚：AI 不再只待在聊天框或编辑器里。它开始接触仓库、CI、PR 和发布前的检查环节。

所以问题不再是“AI 会不会写代码”。它当然会写。

更实际的问题是：它写完以后，这个变更会走到哪一步？能不能进 PR？能不能触发 CI？能不能拿到仓库权限？谁看 diff？谁判断它没有破坏权限、数据结构、流程状态和发布链路？

模糊任务会被工具自动补全

Vibe coding 最容易出问题的地方，不是模型不会写代码，而是任务描述太松。

比如一句“帮我优化这个页面”，里面几乎没有可执行信息。优化的是加载速度、布局层级、交互路径、可访问性，还是视觉风格？能不能影响其他页面？能不能改主题配置？要不要保留现有路由？如果这些边界没有写清楚，agent 会自己补。

补出来的东西未必错，但很可能不符合项目真实约束。

更稳定的任务写法应该像工程变更说明：

目标：把文章详情页左侧栏改成大纲。
范围：只影响文章详情页和 About 页面，不影响首页、分类、标签、时间线。
约束：不要改 .temp 生成文件，不要改 node_modules。
验证：npm.cmd run docs:build 和 npm.cmd run docs:verify 必须通过。
交付：说明改了哪些文件，为什么这样改，哪些地方没有验证。

这不是 prompt 技巧，而是变更边界。

AI agent 很擅长把一句模糊愿望补成一个完整方案。网页能打开、命令能跑、PR 能提交，看起来都很顺。问题是，真正的风险往往藏在它“顺手”补出来的部分里：多改了一个配置、绕过了原来的路由约定、引入了一个没必要的依赖，或者把生成目录当成源码改了。

到了 agent 阶段，好的输入不是一句愿望，而是目标、范围、禁区和验收方式。

社区争论的重点是边界

这次用 last30days 查最近 30 天的 AI coding agent 讨论。能看到几个反复出现的主题：企业环境里的权限和治理，vibe coding 这个词过于粗糙，agent 的风险很多时候不是“模型失控”，而是“权限给得太大”。

有一个讨论提到，coding agent 的价值不只来自模型本身，还来自周围的 plumbing：它怎么读仓库、怎么调用工具、怎么展示 diff、怎么保留日志、怎么让人接管。这个判断很实际。agent 能不能进入日常工作，很大程度取决于它能不能被约束、被追踪、被中断。

另一个讨论里，有人说自己不得不在提示里写明：“这只是问题，不要编辑代码，不要运行命令。”这句话听起来有点夸张，但它指向同一个问题：工具能力越强，行为边界越要清楚。

以前工具能力弱，最多是答错。现在工具能力强，它可能会多改文件、多跑命令、多引入依赖。错误从“回答不准确”变成“项目状态被改变”。风险级别不一样。

更合理的协作方式，是在任务一开始就声明状态：

只分析，不改文件。
先计划，不执行。
可以修改，但不要安装依赖。
可以运行测试，但不要部署。
可以给建议，但不要替人合并。

这些约束看起来琐碎，但它们决定了 agent 是工程工具，还是一个容易跑偏的自动化脚本。

安全问题不是题外话

Vibe coding 的速度感很强。想法描述出来，应用很快就能跑。

这也是风险来源。

The Hacker News 写过一篇关于 vibe-coded apps 暴露数据的文章，里面提到一个调查：大约 5,000 个看起来像企业用途的 AI 构建应用里，有超过 2,000 个暴露了敏感的企业、运营或个人数据，很多缺少基本访问控制。这个数字不一定代表整个行业，但足够说明一个现象：AI 让搭应用变快了，也让“没想清楚就上线”变快了。

The Verge 最近也写到类似风险。个人在本地做一个小工具，和把处理客户日志、医疗数据、财务记录、内部文档的应用放到公网，不是一回事。前者可以粗糙一点，后者必须考虑认证、授权、日志、数据边界和故障处理。

更麻烦的是，coding agent 本身也可能成为攻击面。

GMO Flatt Security Research 在 2026 年 6 月发布过一篇关于 Claude Code GitHub Actions 的研究。文章里说，他们发现了一个漏洞，可以让攻击者绕过权限控制，把不可信输入送进原本只处理可信输入的 workflow。默认配置下，这个 workflow 可能拥有对代码、issue、PR、discussion 和 workflow 文件的读写权限。Anthropic 后来在 v1.0.94 修复了相关问题。

这个案例说明，agent 进入 CI/CD 后，风险不只是“生成的代码有没有 bug”，还包括：

谁能触发它。
它能读什么。
它能写什么。
它能不能改 workflow。
它处理的输入是否可信。
日志是否足够复盘。
最终变更是否需要人工批准。

这和传统自动化脚本很像。脚本本身不一定危险，危险的是权限过大、输入混乱、输出没人审、失败没人看。

验收权不能交给工具

OpenAI 在 2026 年 6 月关于 agent 工作方式的文章里提到，Codex 用户里的不少请求已经不是几分钟的小问答。到 2026 年 5 月，在采样的个人用户中，80.6% 至少提交过一次相当于经验工程师 30 分钟以上工作量的 Codex 请求，70.2% 至少提交过一次超过 1 小时的请求，25.6% 提交过超过 8 小时的请求。

这个数据不适合简单理解成“AI 替代了多少工作”。更合理的信号是：开发者正在把更长、更完整的任务交给 AI 处理。

这会改变工作方式。

让 AI 解释一段代码，错了也只是浪费几分钟。让它改一个项目，如果边界没说清楚，它可能会生成一组看起来合理、实际埋了风险的变更。工具越强，验收责任越重。

比较清醒的态度应该是：

可以让它读代码。
可以让它写计划。
可以让它改文件。
可以让它跑测试。
可以让它开 PR。

但不能把验收权交出去。

这不是保守。

如果一个 agent 能把整理、迁移、重构、文档和测试补齐工作先做一轮，它当然有价值。关键是留下证据：改了什么，为什么改，跑过什么，失败过什么，哪里没有验证。

从 vibe coding 到 coding agent，真正的变化不是“代码由谁写”，而是“变更由谁负责”。