模型越来越强，为什么 AI 编程的工程问题反而更多？

前两天看到 Codex 新功能列表的时候，我第一反应不是“牛逼”。

是有点慌。

browser、memory、automations、90+ plugins、GitHub review comments、多终端、SSH devbox。看起来像是 OpenAI 把半个开发工作台塞进了 Codex。Claude Opus 4.7 也在往 long-running agentic coding 上走，GitHub Copilot 接了 GPT-5.5，重点说复杂多步骤 coding task。

听起来都是好消息。

但如果你真的把这些东西放进项目里跑过，就会知道另一个问题也被放大了：

以前 AI 写错代码，最多坏一个函数。
现在 Agent 写错代码，可能顺手把半个工程流程跑完。

这才麻烦。

我现在不太关心“谁更会写代码”

不是不重要。模型能力当然重要。

但过去一年我自己的感受是：AI 编程最卡人的地方，已经慢慢从“它会不会写”变成了“它会不会乱写”。

这两个差别很大。

不会写，你一眼就能看出来。
乱写，反而更危险。

它会把 plan 写得很像样，diff 也挺完整，最后还补一句“已验证”。你打开一看，它确实改了文件，也确实跑了某个命令。问题是，它可能改多了，测少了，或者绕开了真正的业务约束。

这种东西最像真实工程事故。

不是红色大爆炸。
是一串看起来都合理的小决定，连起来就坏了。

我之前让 Agent 做任务时，最怕的不是它报错。报错还好，至少停住了。最怕的是它一路绿灯，最后给我一个“完成”。那时候才要开始翻 diff、查日志、看它到底动了哪些地方。

很累。

Agent 的问题不是太笨，是太能动

一个补全模型，没有太多行动空间。

它最多补一段代码。你不接受，它就没有进入仓库。

但现在的 Agent 不一样。它能读文件、改文件、跑测试、开终端、处理 review comment。Codex 还在往 browser、plugins、automation、SSH devbox 上扩。GitHub 也在把 Claude、Codex、Copilot 放进 issue、PR、安全告警这些工作流里。

这意味着什么？

意味着 Agent 的手越来越长。

手长是好事。也不是好事。

HN 上前段时间有个讨论，说 Claude Code 通过 Terraform 命令把生产数据库删了，快照也没保住。这个事情我看完之后一点都不觉得离谱。因为真实工程里，这种事故不是靠“模型更聪明”就能完全避免的。

如果一个 Agent：

看得到 infra 配置；
能执行命令；
没有 production 保护；
没有人类确认点；
还被要求“自己解决问题”；

那它做出危险动作只是时间问题。

人类工程师至少会在 terraform destroy 前心里咯噔一下。

Agent 不会咯噔。

它没有那种“我今晚可能要睡公司”的生理反应。

强模型会让烂流程更危险

很多人会有一个直觉：模型更强了，流程就可以少一点。

我现在觉得正好反过来。

模型越强，越需要流程。

弱模型跑不远。它写两步就卡住，反而没机会造成大面积破坏。强模型不一样，它会自己找路。上下文不够，它猜；测试失败，它修；权限不够，它换个办法；目标不清楚，它补一个自己理解的目标。

听起来很主动。

问题是，工程里“主动”不总是优点。

一个真实项目里，有些地方就是不能碰。有些命令就是不能跑。有些改动必须先问人。有些测试没跑完就不能说完成。有些业务逻辑看起来可以简化，但其实背后有一堆历史债。

这些东西 Prompt 很难一次说清楚。

你可以在提示词里写“不要做危险操作”。
没用。太虚。

危险操作到底是什么？删文件算不算？改 migration 算不算？自动升级依赖算不算？把 feature flag 删了算不算？在测试环境跑可以，在生产跑不行，这个边界谁来判断？

靠模型自己猜，迟早出事。

我越来越相信 Harness，而不是神 Prompt

我现在写 AI 编程工具相关内容，经常会提 Harness。这个词听起来有点装，但它解决的是很土的问题：

怎么把一个会写代码、会跑命令、会自作主张的 Agent，关进一个不会乱炸的笼子里。

这个笼子不一定复杂。甚至可以很简单：

只允许它改某几个目录；
先写计划，再动手；
破坏性命令必须停下来问人；
每次改完必须跑指定测试；
没有测试输出就不能说完成；
只能开 draft PR；
production 默认只读；
所有工具调用留日志。

这些听起来不像未来科技。

像项目管理。

但真正把 Agent 放进工程里，靠的就是这些东西。

我最近做一个 Social Ops MVP，也故意把边界拆得很死：LLM 负责选题、内容、复盘判断；CLI 只做确定性动作，比如抓数据、存状态、打开网页、半自动填表。发布这一步必须停在人工确认前，不让它自动点最终提交。

这不是因为我不想自动化。

是因为我知道“自动化发布”这四个字，迟早会给自己挖坑。

尤其是内容平台。发错一篇，不是 CI 红了重跑一下那么简单。

先让 Agent 做窄任务

GitHub 现在允许把 Dependabot alert 分配给 AI Agent，我反而觉得这个方向靠谱。

因为它窄。

安全告警有明确输入：哪个包有问题。
有明确动作：升级、替换、补 patch。
有明确出口：开 PR、跑 CI、等人 review。

这种任务很适合 Agent。

不是因为它简单，而是因为边界清楚。Agent 搞错了，你大概率能在 diff 和 CI 里看出来。它不会突然决定“顺手重构一下支付模块”。

我现在比较愿意交给 Agent 的任务，大概是这些：

小范围 bugfix；
依赖升级；
lint 和类型错误；
测试补齐；
文档同步；
review comment 处理；
重复性迁移，但必须分批。

我不愿意直接交给它的任务也很明确：

生产数据库；
大型架构重写；
权限配置；
发布上线；
核心业务规则；
没有测试的老代码。

不是永远不能做。

是不能一上来就放权。

先让它在笼子里跑几圈。别第一次见面就把生产钥匙给它。

以后工程师更像 Agent 领班

这句话有点难听，但我觉得挺准确。

AI 编程不会让工程师立刻消失。至少现在不会。它会先改变工程师每天干活的比例。

以前你一天可能 70% 时间写代码，30% 时间看需求、跑测试、review。

以后可能变成：

设计任务边界；
准备上下文；
看 Agent 的计划；
卡住危险操作；
review 它的 diff；
查它为什么跑偏；
把成功流程沉淀成 Skill；
把失败案例写进 guardrail。

写代码还是要会。

不会写代码的人，很难判断 Agent 写得对不对。更麻烦的是，Agent 经常不是语法错，而是工程判断错。它可能写出一段能跑的代码，但这个改法会让三个月后的维护者想骂人。

这种判断，模型可以辅助，但锅最后还是人背。

没人会对事故复盘说：“都是模型的责任，我们也没办法。”

老板只会问：谁给它权限的？

我看 AI 编程工具，开始看这些东西

现在看到一个新的 coding agent，我不会先看 demo 里它 30 秒写了多少代码。

Demo 都会剪。

我会先看几个更扫兴的问题：

它能不能只改指定文件？
能不能先停下来给计划？
能不能限制 shell 命令？
能不能接 CI？
能不能在人类 review 前停住？
能不能把 token 花在哪里说清楚？
能不能失败后留下现场？
能不能把一套流程保存成下次还能用的 Skill？

这些问题不好营销。

但决定你敢不敢把它放进真实项目。

如果一个工具只告诉我“模型更强、速度更快、上下文更长”，我现在会自动打个折。因为真实项目里，上下文长了以后，它能误解的东西也更多；速度快了以后，它改坏东西也更快。

快不是问题。

刹车才是问题。

这波 AI 编程的分水岭

2026 年 AI 编程大概率会继续卷模型。

Claude 会更强，Codex 会接更多工具，GitHub 会把 Agent 放进更多工程流程。Product Hunt 上也会继续出现各种 Agent Fleet、Agent Builder、Agent Workflow 平台。

这些都会发生。

但我觉得真正的分水岭不在这里。

分水岭在于：谁能把 Agent 管起来。

不是写一个神 Prompt。
不是收藏一堆模板。
不是让它开十个终端同时跑。

而是让它知道什么时候该做，什么时候该停，什么时候必须等人看一眼。

这件事听起来不酷。

但工程本来很多时候就不酷。写测试不酷，权限隔离不酷，备份不酷，灰度发布不酷。只有出事的时候，你才会突然觉得它们很美。

AI 编程也一样。

模型越来越强是好事。
但如果没有 Harness，它只是一个更有行动力的风险源。

我现在的判断很简单：

下一阶段拼的不是“谁的 Agent 更像天才”。

拼的是谁能让这个天才别乱碰生产。

参考资料：