AI 编程助手的竞争点从“会写代码”变成“会长期协作”
AI 编程助手的下一阶段：不是补全代码，而是跑完整个工程任务
这两年大家聊 AI 编程，最常见的说法是：
它会不会写代码？ 它能不能一次生成一个接口？ 它能不能根据报错修一个 bug？这些问题当然重要，但已经不够用了。
现在真正有意思的变化，不是模型又会多写几个排序算法，也不是补全速度又快了多少。更大的变化是：AI 编程助手正在从“代码补全工具”，变成“工程任务执行器”。
补全工具的工作边界很窄。你写一半函数，它猜下一段。你问一个问题，它给一段示例。它像一个坐在旁边的同事，你问一句，它答一句。
但 coding agent 的边界不一样。它要读 issue，理解代码库，搜索文件，打开测试，修改代码，跑命令，看失败日志，再改，再跑，最后给你一个可以 review 的 diff。你交给它的不是一句“帮我写个函数”，而是一个小型工程任务。
这也是最近 Claude Opus 4.8 这类模型发布时，大家容易忽略的地方。官方强调的关键词不只是“coding benchmark 更高”，还有“dynamic workflows”“long-running tasks”“effort control”“tool calling efficiency”。翻译成人话就是：模型越来越像一个能在项目里干活的执行体，而不是只会聊天的代码问答机。
这篇文章不想复述发布新闻。我们直接聊工程上真正会遇到的问题：一个 coding agent 要跑完整任务，到底难在哪里？团队应该怎么用？又该怎么评估它是不是靠谱？
1. 补全代码和完成任务，是两件事
很多人第一次用 AI 编程工具，感受最强的是“写得很快”。
比如你写：
functionvalidateToken(token:string){它马上补出一堆 JWT 校验逻辑。这个体验很爽，但它解决的是局部问题。
真正的工程问题通常长这样：
线上反馈：过期 token 调用接口仍然返回 200，预期应该返回 401。 请修复，并保证现有测试通过。这句话看起来很短，但背后至少有这些动作：
找到认证入口； 找到 token 解析逻辑； 找到过期时间判断； 确认项目里 401 的返回方式； 看现有测试怎么写； 补一个失败用例； 修改实现； 跑测试； 如果失败，读日志再定位； 最后整理 diff 和风险点。这里面真正“写代码”的部分，可能只有 10 行。
难点不在写，而在找。
找对文件，找对上下文，找对行为约定，找对测试边界。人类工程师熟悉项目以后，这些东西在脑子里。Agent 不熟悉项目，它必须靠工具一步一步恢复上下文。
所以，判断一个 AI 编程助手好不好，不能只看它能不能写出一段漂亮代码。更应该看：
它能不能少读无关文件？ 它能不能先写测试而不是直接改？ 它能不能看懂失败日志？ 它能不能发现自己没证据？ 它能不能把改动限制在最小范围？ 它能不能在跑完验证后再说完成？这就是从“代码生成”到“工程执行”的分水岭。
2. 一个完整 coding agent 任务，大概长什么样
我们把一次比较正常的 bug 修复拆开看。
用户给出需求：
修复登录态过期后仍然返回 200 的问题。一个比较成熟的 agent，不应该马上改代码。它应该先做几件事。
第一步，明确任务边界。
这是认证问题，不是前端展示问题； 目标状态码是 401； 要确认是 access token 过期，还是 refresh token 过期； 需要看项目现有错误处理风格。第二步，搜索相关代码。
rg"validateToken|jwt|expired|401|Unauthorized"src tests第三步，优先看测试。
如果项目里已经有认证测试，测试比实现更值得先读。因为测试告诉 agent：这个项目认为什么是正确行为。
第四步，再读实现。
这时候 agent 才应该打开auth.ts、middleware.ts、jwt.ts这类文件，而且最好按片段读，不要一上来把整个项目塞进上下文。
第五步，先补测试。
it("returns 401 when access token is expired",async()=>{consttoken=createExpiredToken();constres=awaitrequest(app).get("/api/profile").set("Authorization",`Bearer${token}`);expect(res.status).toBe(401);});第六步，跑测试，看红灯。
npmtest-- auth.test.ts第七步，最小修改。
不要顺手重构整个认证模块。不要顺手换库。不要把错误格式也改了。只修这个边界。
第八步，再跑测试。
第九步，给出结果。
改了哪里； 为什么这样改； 跑了哪些测试； 还有哪些风险没覆盖。这套流程听起来普通，但对 agent 来说并不普通。因为每一步都可能跑偏。
| 步骤 | 容易出的问题 |
|---|---|
| 搜索 | 关键词太宽，读了大量无关文件 |
| 读文件 | 一次读太多，上下文被噪音挤满 |
| 制定计划 | 看起来很完整，但没有基于代码证据 |
| 修改代码 | 改动范围过大，引入新行为 |
| 跑测试 | 只跑了无关测试，或者没看失败细节 |
| 总结 | 没跑验证却说“已修复” |
所以 coding agent 的核心能力，其实是“在不熟悉代码库的情况下，逐步缩小不确定性”。
这比写一个函数难多了。
3. 为什么 benchmark 开始不够用了
过去评价代码模型，大家喜欢看 benchmark。
比如给它一道算法题，看能不能通过。给它一个 GitHub issue，看能不能生成 patch。SWE-Bench 这一类评测很有价值，因为它让模型不再只做玩具题，而是进入真实代码仓库。
但如果你真的在团队里用 agent，会发现 benchmark 只能说明一部分问题。
真实工程里还有很多 benchmark 不容易覆盖的东西：
项目依赖能不能装起来； 本地测试是否稳定； 日志是否太长； 权限边界怎么给； 失败后能不能恢复； 有没有误删文件； 会不会把无关格式化混进 diff； 能不能处理用户中途补充的新要求； 能不能在预算快用完时收敛。这些问题不太像“答题”，更像“跑任务”。
Claude Opus 4.8 发布时提到 dynamic workflows，可以让 Claude Code 规划工作并运行大量并行子 agent，然后用测试套件作为验收标准。这个方向很重要。它说明模型厂商也意识到，单轮问答已经不是 coding agent 的主要战场。
未来更重要的指标，可能会变成这些：
| 指标 | 看什么 |
|---|---|
| 任务完成率 | 从 issue 到可验证 diff 的成功率 |
| 无关改动率 | 是否改了不该改的文件 |
| 工具调用效率 | 为完成同一任务用了多少次搜索、读取、测试 |
| 失败恢复能力 | 第一次测试失败后能不能正确定位 |
| 证据意识 | 没确认的地方会不会硬说 |
| 成本稳定性 | 同类任务 token 和时间是否可控 |
| 人工 review 成本 | 生成的 diff 是否容易审 |
这里面最值得注意的是“人工 review 成本”。
一个 agent 可能确实把测试跑绿了，但 diff 很乱，改了 20 个文件，顺手重命名变量，顺手调整格式，顺手改了错误消息。测试通过不代表这个改动适合合并。人类 reviewer 还得一行行看，最后比自己改还累。
好的 coding agent，不只是能改对，还要让人类容易相信它改对。
4. Agent 的能力不只来自模型，也来自 harness
很多人讨论 AI 编程助手时，习惯只问一个问题：
哪个模型更强？这个问题有意义，但不完整。
同一个模型，放在不同的工具环境里，效果会差很多。这里的工具环境，可以叫 harness，也可以简单理解成“agent 的工作台”。
一个 coding agent 的工作台至少包括：
文件读取策略； 搜索工具； 命令执行权限； 测试运行方式； 上下文压缩； diff 生成； 失败日志摘要； 安全规则； 任务预算； 人工确认点。模型像大脑，harness 像手、眼睛、记事本和工位规则。
如果搜索工具每次返回几千行，模型会被噪音淹没。
如果测试日志不做摘要，模型会把 warning 当成主线。
如果文件读取没有范围控制，小任务也会变成全仓库扫描。
如果命令执行权限太大，agent 可能为了“解决问题”做出危险动作。
如果没有 diff 约束，它很容易把无关格式化带进去。
所以团队真正要建设的，不只是“接一个更强模型”，而是一套可控的 agent 运行环境。
一个实用的最小配置可以是这样：
1. 搜索默认只返回路径和命中行附近少量内容； 2. 读文件默认按片段读，大文件必须说明目的； 3. 修改前必须说明计划； 4. 修改后必须展示 diff 摘要； 5. 测试失败时只保留关键失败段； 6. 禁止自动执行破坏性命令； 7. 任务结束必须列出已验证和未验证项。这些规则不花哨，但很管用。
因为 agent 最怕的不是不会做，而是越做越散。一个好 harness 的作用，就是让它在长任务里一直贴着目标走。
5. “努力程度”会变成一个产品按钮
Claude Opus 4.8 同时提到 effort control，也就是让用户选择模型在任务上投入多少“努力”。
这个设计很合理。
因为不是所有编程任务都值得高强度思考。
比如这些任务，低努力就够了：
解释一个函数； 补一段简单类型定义； 改一个文案； 生成一个 mock 数据； 把一段代码改成项目风格。但这些任务，低努力通常不够：
跨模块 bug 修复； 数据库迁移； 认证权限改造； 大型依赖升级； 性能问题定位； 多服务接口契约调整。这背后其实是成本问题。
高努力不只是“模型多想一会儿”，它往往意味着：
更多工具调用； 更多上下文读取； 更多中间计划； 更多测试尝试； 更多自我检查； 更多 token。所以团队用 coding agent 时，最好不要一刀切。
可以给任务分级：
| 任务级别 | 示例 | Agent 策略 |
|---|---|---|
| S | 注释、解释、简单改名 | 快速模式，不跑全量测试 |
| M | 单文件 bug、小功能 | 读相关文件，跑局部测试 |
| L | 跨模块改动、接口调整 | 先写计划，分阶段执行 |
| XL | 大迁移、架构清理 | 拆子任务，并行探索，人工 gate |
这个分级比“全部交给最强模型”更现实。
强模型很贵，长任务更贵。真正成熟的团队，会把模型能力、工具权限、测试范围和人工审核放在一起设计。
6. 哪些任务适合交给 coding agent
不是所有编程任务都适合交给 agent。
比较适合的任务有一个共同点：目标清楚，验证方式明确。
比如：
修一个已有测试覆盖的 bug； 补一个明确输入输出的接口； 把旧 API 调用迁移到新 API； 给已有模块补测试； 根据 lint/typecheck 修错误； 把重复逻辑抽成已有项目风格的 helper。这些任务适合 agent，因为它能通过测试、类型检查、lint、diff 来收敛。
不太适合直接交给 agent 的任务是：
产品目标还没想清楚； 架构方向存在争议； 业务规则只在某个人脑子里； 安全边界没有定义； 验收标准很模糊； 改错了会产生严重线上事故。这种任务不是不能用 agent，而是不能让 agent 直接开干。更好的方式是先让它做阅读、梳理、列风险、写方案，再由人决定。
一句话：
Agent 适合执行可验证的工程任务，不适合替你决定模糊的产品方向。
这句话很朴素，但能避免很多误用。
7. 团队接入 coding agent，最先该做什么
如果一个团队准备正式把 coding agent 放进开发流程，我建议先别急着追最强模型。
先做三件事。
第一，整理任务模板。
不要只给 agent 一句话：
帮我修一下这个 bug。更好的任务描述是：
问题：过期 token 调接口返回 200，预期 401。 范围：只修改认证相关逻辑，不调整其他接口错误格式。 验证：新增或更新认证测试，至少运行 auth 相关测试。 输出：说明改动文件、测试结果、未覆盖风险。第二，建立验证命令清单。
每个项目都应该告诉 agent：
怎么跑单测； 怎么跑类型检查； 怎么跑 lint； 哪些测试很慢； 哪些失败是已知问题； 发布前必须跑什么。这些东西如果不写清楚，agent 会猜。它一猜，就容易浪费时间。
第三，控制 diff。
可以规定：
一次任务尽量不超过 5 个文件； 禁止顺手格式化无关文件； 禁止无说明改依赖版本； 禁止删除测试； 大改动必须先给计划。这不是不信任 agent，而是正常的软件工程纪律。
人类工程师也应该遵守。
8. 真正的变化：工程师从写每一行，变成设计执行环境
有人会问：如果 agent 能跑完整工程任务，工程师是不是就没事干了？
现实没这么简单。
越强的 agent，越需要人类把任务边界、验证标准和风险控制讲清楚。
过去工程师的时间花在：
找文件； 读实现； 写代码； 跑测试； 修报错。以后其中一部分会交给 agent。工程师的工作会更多转向：
定义任务； 设计测试； 设置权限； 控制上下文； 审查 diff； 判断风险； 沉淀项目规则。这不是工作变少，而是工作重心变了。
以前你自己开车。现在你像是在带一个新同事做任务。这个同事打字很快，查资料很快，不怕重复跑测试，但它不天然理解你的业务，也不天然知道哪里不能动。
你要给它路线、边界和验收标准。
给得越清楚，它越有用。
9. 结尾：别再只问“会不会写代码”
AI 编程助手的下一阶段，真正的问题不是：
它会不会写代码？而是：
它能不能在一个真实代码库里，把一个工程任务跑到可验证状态？这中间差了很多东西。
搜索、阅读、计划、测试、失败恢复、权限控制、成本控制、diff 纪律、人工审核，这些都不是炫技功能，但它们决定 coding agent 能不能进生产流程。
所以以后看一个 AI 编程工具，不要只看 demo 里它一口气生成了多少代码。
更应该看它怎么处理失败，怎么限制改动，怎么证明自己做完了，怎么让人类 reviewer 少花时间。
能写代码，只是入门。
能跑完整工程任务，才是下一阶段。