AI 编程工具这一年的变化,不在「能不能写代码」,「能参与到项目的哪个深度」才是分水岭。从补全单行,到改多个文件,再到理解整个项目,边界在持续外推。这篇讲三处变化各自意味着什么、怎么判断跟没跟上、哪些环节仍然必须人来做。提到的功能形态,以各产品官方最新版本为准。
从补全单行到改多个文件
早期的代码助手主要做行级补全:你写前半行,它补后半行,或根据注释生成一个函数。上限很直白——它看到的上下文有限,经常补出一个项目里已有的函数,或引入你不希望的依赖。
现在越来越多工具能参与跨文件改动:先理解项目结构,定位相关代码,再批量修改。给一个函数改签名,它能把所有调用点一起改掉;加一个字段,能把模型、接口、前端表单串起来改。判断这类能力靠不靠谱,看一件事:它改完之后,你敢不敢不逐行读就合入——不敢,说明它还停在「给建议」阶段,够不上「能干活」。
这背后依赖两个条件成熟:更大的上下文窗口,让模型一次能读进更多文件;以及代码检索,让它在读不完整个项目时知道去哪里找相关代码。这两个条件不成熟之前,跨文件改动只能停留在演示阶段。
从对话到智能体:给个任务自己完成
第二处变化是从「你问我答」到「给个任务自己完成」。形态是一个循环:读代码、提出改动、写文件、跑测试、看报错、再改。人从「每一步都确认」变成「只确认目标和最终结果」,中间步骤由它自己迭代。
代价是可控性。循环跑起来之后,它可能在错误的方向上越跑越远——测试没覆盖到的地方,它改了你看不见;为了「让测试通过」,它可能去改测试本身。所以智能体编程真正要建的不是提示词,是护栏:允许改哪些目录、能跑哪些命令、什么时候必须停下来问人。
一个可带走的判断:自主程度每提高一档,审阅时间就涨一截。省下的打字时间,会以审阅时间还回来——区别在于审阅比打字值钱,它逼你看懂项目结构。
编辑器本身在 AI 化
第三处变化发生在编辑器里。AI 不再是一个侧边栏插件,交互围绕它重新设计:改动以 diff 形式预览,接受与否由你决定;上下文由工具自动收集,而不是手动贴文件;指令可以直接作用于选区或整个仓库。
这件事对使用习惯的影响比前两处大。插件时代的逻辑是「你写,它补」;编辑器 AI 化之后是「你说要什么,它动手,你审」。只接受补全、拒绝一切跨文件改动,等于换了把新刀继续切旧的菜。
怎么跟上:用真实项目做试用评估
不用追每一个新工具。工具会变,判断力不会过时。做法是每隔一段时间,拿一个真实的小任务试新工具:修一个熟悉的 bug、加一个小功能,看三件事——它定位代码准不准、改完能不能跑、你审阅花的时间比不比手写少。三件事里两件不过关,这个工具对你就还不成熟。
国内大厂几乎都有自己的编程助手——通义灵码、MarsCode、文心快码,功能形态大同小异,不必挨个试,按上面三件事挑顺手的用下去即可。
看新工具的新闻也要有分辨方法。芯片和算力是底层约束,制程、算力与生态怎么读能判断一次发布是真进步还是营销话术;价格变化的背后是补贴和留存的博弈,一次价格战该怎么看讲的是同一套逻辑;榜单迭代里的排名信号同样值得翻一翻。
它做不到什么
它不做需求判断。「做什么」永远是你的活。它能列出三个实现方案,但选哪个取决于业务约束、团队习惯、后续维护成本——这些信息不在代码里,只在你脑子里。
它也不兜底质量。测试通过只说明没被你写到的测试抓到。在没有测试的老项目里,「看起来能跑」和「真的能跑」之间隔着一整片没人踩过的地。涉及资金、权限、数据迁移的代码,审阅要逐行读,不是抽样看。
还有成本问题。智能体循环的调用量和单次问答不是一个量级,跑一轮复杂任务烧掉的额度可能是几次对话的几十倍。值不值,要看它省下的小时数和烧掉的费用哪个贵——这笔账每个团队要自己算。
AI 编程变化速查
- 判断跨文件能力:改完你敢不敢不逐行读就合入
- 智能体编程的核心不是提示词,是护栏:目录、命令、停机条件
- 自主度每涨一档,审阅时间就涨一截
- 老项目无测试,「能跑」和「真能跑」之间没有安全网
- 试用评估看三件事:定位准、能跑通、审阅省时间
| 变化维度 | 过去的形态 | 现在的形态 | 判断跟没跟上的标准 |
|---|---|---|---|
| 改动范围 | 行级补全,单文件内生成函数 | 跨文件定位与批量修改 | 改完敢不敢不逐行读就合入 |
| 交互方式 | 你问我答,每步人工确认 | 给任务自主循环:读、改、跑、修 | 护栏是否明确:能改什么、能跑什么、何时停 |
| 编辑器 | AI 是侧边插件 | 交互围绕 AI 重设计:diff 预览、自动收集上下文 | 还在用新工具只干补全的活,就是没跟上 |
| 成本结构 | 按次调用,开销可忽略 | 智能体循环调用量成倍上升 | 省下的工时与烧掉的额度,哪个贵 |
顺手答三个追问
问:代码助手现在能替代初级程序员吗?答:能替的是「照着明确需求写样板代码」那部分活。需求说不清、要跟人确认、要在几个都不完美的方案里挑一个的场景,它插不上手。团队里先被替代的往往是重复劳动,先被需要的反而是能把需求问清楚的人。
问:该不该把整个项目丢给它重构?答:别。重构的判据在代码之外——哪里是热点路径、哪些坑是历史遗留不能碰,它不知道这些,大规模重写等于把没人说得清的债务重新埋一遍。正确做法是划一个小模块让它改,你审,确认质量再扩大。
问:多个 AI 编程工具要不要同时用?答:前期可以,稳定后收窄到一两个。快捷键、上下文收集方式、改动预览形式都不同,切换成本比想象高。留一个主力,再拿一个做备选就够了。


