学习
为什么 AI 编码智能体不足以支撑生产应用
这不是一篇反对编码智能体的文章——它们在自己的领域非常出色。这是一份盘点:生产软件需要的、位于差异之外的一切,以及必须由谁来负责。
AI 编码智能体加速的是软件交付的一个阶段:编写和修改代码。生产应用还需要测试证据、安全验证、变更治理、部署、监控与事故响应——这些职责位于代码编辑本身之外。采用编码智能体却不覆盖生命周期其余部分的团队,发布更快,却在盲飞。缺口不在智能体的质量;而在那圈仍然要有人负责的交付闭环。
发布日期 2026-07-03 · 最近更新 2026-07-03 · Ciao 编辑团队
简短的答案,展开来说
先对这个品类公道一点。现代编码智能体——Cursor、Claude Code、OpenAI Codex 及其同侪——是货真价实的强工具。它们阅读大型代码库、规划多文件变更、编写测试、修复失败,并迭代到通过为止。用得好的工程团队明显更快,本文没有任何一处与此相左。要点在于范围,不在质量。
编码智能体的产出,再好也只是一次代码变更。生产软件是一个大得多的、由长期义务组成的系统:证明变更对真实用户有效、验证它没有引入漏洞、判定它究竟是否被允许、安全地发布它、在它行为不端时察觉,并在出事后重建发生了什么。这些义务无论有没有人被指派,都客观存在——而一个在代码编辑阶段工作的编码智能体,一项都不能替你卸下。它反而加大了所有这些义务的压力,因为它加速的恰恰是喂饱其他所有阶段的那一个。
所以对一个要上生产的团队,实际的问题不是“我们的智能体够好吗?”,而是“既然差异到来的速度快了五倍,差异下游的一切归谁负责?”。有强平台组织的团队可以用他们已经在运行的基础设施作答。没有的团队需要自建或采纳那个闭环——而且应当是有意为之的决定,不是在一次事故中才发现缺口。
值得注意这个缺口为什么如此容易被忽视。智能体的产出是鲜活的——一个能用的功能、一次通过的测试、一张关闭的工单——而缺失的闭环在被压力测试之前是隐形的:没人看得见那条不存在的浏览器测试,或那份从未写下的审计轨迹。采购决策天然偏向鲜活而轻视隐形,组织就是这样落得生成一流、交付即兴。把下面六项义务写进评估是纠偏之道;诚实评估它们只需一个下午,而它们对生产之痛的预测力,远胜任何生成能力基准。
速度的不对称,以及它悄悄压垮的东西
这是工程负责人反复报告的模式。智能体到位;几周内 PR 数量跳涨;而每一个下游阶段——审核、QA、安全、发布——突然成了约束。组织随后滑进两种失败模式之一。要么下游阶段守住底线,队伍在它们面前重新排起,生产力收益蒸发成排队时间;要么这些阶段让步,批准变轻、测试“就这一次”被跳过,组织实际上在规模化地发布未经审核的代码,却从未做过这个决定。
第二种模式才危险,因为它看起来像成功。前置时间下降,仪表盘发光,而累积的风险在某个特定的星期二之前都是隐形的:一次由智能体编写的迁移,被一个开着四十个标签页的审核者在九秒内批准,放倒了结账流程——复盘发现结账没有浏览器级测试,没有任何政策把 schema 变更标给真正的审核,而且没有干净的办法知道该回滚这一周两百次合并中的哪一次。
这些都不是智能体的错。每一道缺失的护栏在智能体到来之前就缺;只是那座桥上的车流少而已。不对称正是要点:让代码产量倍增的工具,会让你交付闭环里缺什么的后果也随之倍增。
如果你想要预警而不是复盘,随着智能体采用加深,盯住四个数字:每次合并的中位审核时长(向零塌缩是症状,不是胜利)、承载营收的流程的测试覆盖率、把生产问题归因到肇事变更的平均时间,以及带已验证回滚路径的部署占比。合并量攀升时其中任何一个走错方向,都是不对称如期而至——而这四项在第二个月修,都比第十二个月便宜。
差异之外,生产责任还包括什么
六项长期义务。对每一项都问:今天由谁或什么替我们负责?它能随智能体速度的变更一起扩展吗?没人认领的行不会一直没人认领——它们会变成署着你名字的事故。
- 测试证据,而不是测试存在. 对养家糊口的用户流程做浏览器级验证,在每次变更上运行,结果日后可以调取。智能体能写测试;必须有东西负责把它们作为关卡来运行,并在应用演进时让它们保持诚实。
- 针对运行中应用的安全验证. 静态扫描和依赖项检查是基本盘;承重的一步是把发现针对线上应用确认,让真实漏洞从噪音中浮出——而且要持续做,因为变更现在是持续到来的。
- 变更治理. 对“这次变更是否被允许?”的明确回答:按业务领域和风险给变更分类的政策、身份验证与支付的受保护区域、要紧之处记录在案的人工批准,以及一份熬得过人事变动的审计轨迹。
- 部署作为受控阶段. 发布前的冒烟测试关卡、发布后的验证、彼此一致的环境,以及一步到位的回滚操作。发布路径是代码变成后果的地方;它配得上比一条终端命令更多的仪式,而不是更少。
- 监控与诊断. 要有东西盯着线上应用、它的 DNS、CDN 和依赖项——并且能诊断根本原因,而不只是在凌晨两点拿着一张红色曲线图呼叫某个人。
- Fleet 可见性. 一旦 AI 让应用变得便宜,你就会有很多个。得有人有一个屏幕,显示存在什么、每个应用归谁、处于什么状态、哪些变更在等审核——否则项目组合本身就会变成影子 IT。
交付闭环:已覆盖 vs 仍属于你
编码智能体在每个阶段帮到哪里,生产环境又仍然向你要什么。这描述的是品类的范围,不是任何具体产品的上限。把它当作一次职责分配练习:在扩大智能体采用之前,给右栏的每一行都填上一个名字。
| 生命周期阶段 | 编码智能体的贡献 | 生产环境仍然要求你提供的 |
|---|---|---|
| 实现 | 出色:多文件变更、重构、修复 | 方向、架构、品位 |
| 测试 | 可以按要求编写测试 | 在每次变更上运行、拦住糟糕发布的关卡 |
| 安全 | 可以修复被标记的问题 | 持续扫描、线上验证、分诊责任 |
| 审核与治理 | 可以总结和解释差异 | 政策、受保护区域、记录在案的负责批准 |
| 部署 | 可以编写流水线配置 | 流水线本身:关卡、环境、回滚 |
| 监控 | 被问到时可以帮忙排查 | 常态化的观测、诊断、事故响应 |
| 审计与合规 | 提交信息 | 一条你的审计员认可的、从提示词到生产的轨迹 |
补上缺口的两条诚实路径
路径一:自己拼装闭环。带真实关卡的 CI、浏览器测试基础设施、接上验证机制的安全扫描、团队真正执行的审核政策、带回滚的部署自动化、可观测性,以及让智能体生成的变更流经这一切的胶水。这是一条正当的路——强平台团队正是这么做的——代价是它是一笔长期的工程投入,不是一次采购。如果你有能构建并维护它的平台组织,闭环之内的编码智能体是绝佳组合。
路径二:采纳一个闭环即产品的平台,让生成发生在闭环之内。这是大多数没有平台组织的团队应当诚实评估的交换:比自建少一些定制控制,换来第一天就存在、且按设计随变更量扩展的测试、治理、安全、部署与监控。两条路也不是敌人——很多组织让工程师带着编码智能体守核心系统,同时用一个受治理的平台承接那条平台团队永远顾不上的业务应用长尾。
在两条路径之间选择,有个公道的经验法则:数一数你的平台工程师和你的应用。一个支撑少数核心系统的强平台团队完全可以自建闭环,而且多半应该。同一个团队若被要求把闭环延伸到几十个部门应用、代理机构建的门户和并购继承物上,会被淹没——那条长尾正是购买决策通常回本的地方。两条路径还可以组合:为项目组合采纳一个平台,丝毫不要求放弃你核心产品已经信任的流水线。
Ciao 的角色
Ciao 就是刻意建成的路径二。每一个工作区都配有一套 AI 软件组织——CTO、Doctor、QA 分析师、安全工程师、Coder 与 SysOps 运维——所以从第一条提示词起,负责闭环的角色就已存在。QA 运行确定性浏览器回放、自愈式测试、发布前的冒烟测试关卡与发布后的生产环境检查。Security 运行静态扫描、依赖项检查与访问控制探测,并在标记漏洞前先针对线上应用进行确认。Guardrails 应用简明英文政策、记录人工审核,并在每次合并背后留下审计轨迹。Doctor——一个只读的 AI SRE——探测线上应用、DNS 与 CDN,诊断根本原因并草拟修复方案,Conductor 则用一个屏幕覆盖整个 Fleet。
而且代码编辑阶段不该是一座围墙花园:应用是真实的 React、TypeScript 与 Supabase,100% 所有权,随时可导出到你自己的代码仓库,自定义沙箱镜像把同一套生命周期包裹在 Rails、Java、Go、Python、Node 与多进程后端之上。可部署到 Ciao 云、你自己的 AWS、Azure 或 GCP 账户、私有 VPC,或在另行约定条款下的本地环境。严肃的开发项目起价为每年 10,000 美元——如果这篇文章说中了你的处境,最有用的演示,是看一次变更从提示词到被监控的生产环境走完整个闭环。
常见问题
你们是在说 AI 编码智能体是糟糕的工具吗?
不是——它们在自己针对的阶段非常出色,本文的前提就是你继续用它们。论点关乎差异下游的一切:测试、治理、部署、监控与审计,这些义务智能体只会让你更急需,而不会替你免除。
我们的智能体也会写测试。这不就补上测试缺口了吗?
它补上的是编写的那一半。生产的那一半是系统性的:测试必须在每次变更上运行、默认为发布把关、在浏览器层面覆盖真实用户流程,并产出审计或事故期间可以调取的证据。那是基础设施和政策,不是代码生成。
在编码智能体周围加上 CI/CD 就算完事了吗?
CI/CD 是答案里真实的一块,无论如何都值得做。常见缺失的是治理——按政策分诊哪些变更需要记录在案的人工批准——线上验证的安全测试、带诊断的生产监控,以及一条从提示词到生产的审计轨迹。要拿全部六项义务给你的闭环打分,而不只是流水线。
Ciao 会取代我们的编码智能体吗?
不必。许多组织让工程师和智能体守着核心系统,同时在 Ciao 上运行受治理的应用交付——尤其是平台团队永远够不到的业务应用长尾。Ciao 自己的 Coder 在同一个闭环内工作,自定义沙箱把既有的 Rails、Java、Go、Python 和 Node 系统也带进来。
我们怎么知道自己是不是已经有了这个问题?
回顾上个月发布的三个问题:合并的变更中有多大比例经过了有意义的人工或政策审核?一条坏掉的结账流程会在用户发现之前被捕获吗?你能在一小时内拿出某次生产变更的批准轨迹吗?两个以上让你不自在的答案,就是这个问题的签名。
在 Ciao 上,完整的闭环要花多少钱?
个人构建者可以用积分自助起步,严肃的生产项目起价为每年 10,000 美元。真正该比的很少是许可证那一行;而是自己拼装并维护一个等价闭环所需的平台工程投入,销售团队可以帮你诚实地算这笔账。