1. 从补全一行代码到接管一个模块大模型在开发链路里的真实位置过去两年我身边做开发的朋友分成了两派。一派觉得大模型就是个高级点的自动补全写写样板代码、生成个正则表达式还行真到复杂业务逻辑就歇菜另一派则已经开始焦虑觉得自己每天干的活正在被一点点吃掉。这两派其实都没说错只是他们观察的是同一个光谱的两端。我自己是从2022年底开始把大模型往日常工作流里塞的从最开始只敢让它写单元测试到后来让它参与接口设计评审再到现在有些模块我基本只做review和边界把控。这个过程里我最大的感受是大模型改变的不是写代码这个动作本身而是一个程序员的时间该花在哪里这个分配问题。它没有替代开发但它确实在重新定义开发这个岗位的含金量分布。这篇文章我想聊的不是AI会不会取代程序员这种标题党式的问题而是从一线实操的角度拆解大模型到底在开发链路的哪些环节真正产生了价值哪些环节它目前还靠不住以及作为一个普通开发者你应该怎么调整自己的技能栈和协作方式才能在这个变化里站到有利位置。不管你是刚入行的初级程序员还是带了几年团队的技术负责人下面这些内容应该都能给你一些可以直接用的参考。2. 大模型真正吃掉的四类编码任务以及它为什么能吃下2.1 样板代码与重复性结构从手酸到审一遍就行先说最没有争议的一块。CRUD接口、DTO转换、配置文件模板、单元测试骨架这类工作大模型现在的完成度已经相当高。我实测过一个典型的Spring Boot项目让大模型根据一张表结构生成对应的Entity、Mapper、Service、Controller四层代码包括基本的增删改查方法和分页逻辑生成出来的代码大概有八成可以直接用剩下两成改改字段名和注解就能跑。为什么这类任务容易被吃下因为它们的模式高度固定、上下文依赖极低、正确性容易验证。你让模型生成一个分页查询它见过成千上万个类似实现本质上是在做模式匹配和组合而不是在理解你的业务。这也解释了为什么它在写算法题时表现也不错——因为算法题的约束条件清晰、边界明确、有标准答案。但这里有个坑我得提醒你样板代码生成得越快你越容易跳过review。我踩过这个坑有一次让模型生成了一个批量更新的Service方法逻辑看着没问题但它默认用了全量更新而不是增量更新上线后把几个字段的默认值覆盖了。后来我养成了一个习惯凡是模型生成的涉及数据写入的代码我必须逐行看一遍尤其是默认值处理、空值判断、事务边界这三块模型翻车的概率明显高于其他部分。2.2 代码翻译与迁移跨语言、跨框架的体力活被大幅压缩第二类被明显改变的是代码迁移和翻译。比如把一个Python脚本转成Java把jQuery的DOM操作改成Vue的响应式写法把老版本的API调用升级到新版本。这类工作以前是纯体力活现在大模型可以做到给一段旧代码输出一段新代码附带改动说明。我去年做过一个项目需要把一个用了五六年的AngularJS页面迁移到React。如果纯手工做两个页面大概要一天。我尝试让大模型先做第一遍转换它把大部分指令和绑定逻辑都翻译对了我只需要处理几个自定义指令和路由跳转的边界情况。整体效率大概提升了三到四倍。但这类任务有个隐藏风险模型对旧代码里的业务意图理解是缺失的。它只能看到语法结构看不到这段代码为什么这么写。比如有一段代码里有个看似多余的if判断模型在迁移时直接把它优化掉了但实际上那个判断是为了兼容某个特定客户的历史数据格式。所以我的做法是迁移类任务模型做第一遍我做第二遍重点检查所有被优化掉的逻辑。2.3 调试与报错定位从大海捞针到缩小包围圈调试这件事大模型的表现比很多人想象的要好但也没有好到可以完全放手。它的强项在于根据报错信息快速缩小可能的原因范围。比如你贴一段堆栈信息给它它通常能指出是哪一类问题——空指针、类型不匹配、依赖冲突、配置缺失——并且给出几个排查方向。我印象比较深的一次是排查一个ClassNotFoundException表面上看是依赖没引入但模型提示我检查一下依赖的作用域和打包插件配置最后发现是provided作用域在打包时没被包含进去。这种问题如果纯靠搜索引擎可能要翻好几页才能找到相关讨论。但调试类任务的天花板也很明显模型看不到你的运行时环境。它不知道你的JDK版本、不知道你的操作系统、不知道你本地装了什么奇怪的全局配置。所以它给出的方案经常是理论上可行但实际跑不通。我的经验是把模型当成一个知识渊博但没见过你项目的远程同事它能给你思路但验证必须你自己来。2.4 文档与注释生成被低估的效率提升点这一类经常被忽略但我觉得价值很大。给现有代码补注释、生成接口文档、写README、整理变更日志这些工作技术含量不高但极其耗时而且很多人不愿意做。大模型在这块的表现相当稳定尤其是当你给它足够的上下文时。我现在的习惯是每完成一个模块把核心代码贴给模型让它生成一份面向调用方的接口说明包括参数含义、返回值结构、异常情况。然后我再人工过一遍补充一些业务背景。这样产出的文档质量比我以前手写的高而且我花的时间大概只有三分之一。这里有个技巧给模型喂代码时把相关的类型定义和常量一起给它。只给一个方法体它经常猜错参数的含义把DTO和枚举一起给它生成的文档准确率会高很多。3. 大模型目前啃不动的硬骨头为什么复杂业务逻辑仍然依赖人3.1 跨模块的隐式契约模型看不到的空气墙在一个稍微有点规模的项目里模块之间往往存在大量没有写在代码里的约定。比如订单模块和库存模块之间可能有一个口头约定订单创建时库存必须先锁定但锁定失败时订单不能直接失败而是要进入一个待处理队列。这种约定可能只存在于某个老员工的脑子里或者散落在几年前的邮件里。大模型看不到这些。它只能看到代码里显式表达的逻辑。所以当你让它修改订单模块的某个方法时它可能会引入一个看似合理但破坏了隐式契约的改动。这不是模型不够聪明而是信息本身就不在它的输入里。我处理这个问题的方式是在让模型参与核心模块修改之前先把我知道的隐式契约写成注释或者文档作为上下文一起给它。虽然麻烦但比事后擦屁股划算得多。3.2 性能敏感路径的取舍模型倾向于正确而非高效大模型生成的代码有一个普遍特点可读性好、结构清晰、但性能往往不是最优的。它倾向于选择最通用、最不容易出错的写法而不是针对特定场景优化过的写法。举个例子让模型写一个列表去重的逻辑它大概率会给你一个基于Set的实现清晰易懂。但在一个百万级数据、对内存敏感的场景里你可能需要用位图或者布隆过滤器。模型不是不知道这些方案而是它默认选择最安全的答案因为它在训练时见到的绝大多数场景都是普通场景。所以我的做法是性能敏感的核心路径模型可以参与讨论方案但最终实现我自己来写。我会让模型帮我对比几种方案的优劣但不会直接采用它生成的第一版代码。3.3 需求模糊时的决策模型不会帮你猜老板想要什么开发工作中很大一部分时间不是在写代码而是在搞清楚到底要做什么。需求文档写得含糊、产品经理自己也没想清楚、老板临时加了个小需求——这些情况模型完全无能为力。它可以根据你给的明确需求生成实现但它无法替你判断这个需求合不合理有没有更好的替代方案做了之后会不会影响其他功能。这些判断依赖对业务、对用户、对团队资源的综合理解目前来看还是人的领域。我甚至觉得随着大模型把编码效率提上去需求理解和方案设计能力的重要性反而会进一步放大。因为写代码变快了瓶颈就转移到了想清楚要写什么这一步。4. 初级、中级、高级开发者的处境差异谁在被挤压谁在受益4.1 初级开发者最容易被替代的环节也是最容易借力的环节网上有一种说法是AI会先取代初级程序员这个说法对了一半。初级开发者工作中那些纯执行、纯重复的部分确实在被快速替代比如照着设计稿写页面、按照接口文档写调用、修一些简单的bug。如果一个初级开发者的日常工作百分之八十都是这类内容那他的处境确实比较危险。但反过来看大模型也是初级开发者最好的老师。以前一个新人遇到问题要么问同事可能被嫌弃要么自己搜可能搜不到点上。现在他可以把代码和报错贴给模型得到一个即时的、有针对性的解释。我团队里有个刚毕业的同学他进步速度明显比以前的新人快因为他遇到不懂的API、不熟悉的框架用法直接问模型然后自己验证学习闭环短了很多。所以初级开发者的策略应该是主动把重复性工作交给模型把省下来的时间花在理解业务、学习底层原理、参与方案讨论上。如果你只是用模型来更快地完成同样的重复工作那你的可替代性并没有降低。4.2 中级开发者受益最明显的群体我觉得中级开发者是这波变化里受益最明显的群体。为什么因为中级开发者通常已经具备了独立完成模块的能力但时间被大量琐碎工作占据——写测试、改bug、做代码迁移、写文档。大模型把这些琐碎工作压缩之后中级开发者有更多时间去做架构设计、技术选型、跨团队协作这些更有价值的事情。我自己的体感是以前一个中等复杂度的功能从设计到上线大概要一周现在可能三天就能完成编码和自测剩下两天用来做更充分的测试和优化。这不是说工作变轻松了而是工作的重心从实现往设计和验证偏移了。4.3 高级开发者与架构师决策权重在上升对于高级开发者和架构师来说大模型带来的变化更多是工具层面的增强而不是角色层面的冲击。他们本来就不怎么写重复代码主要精力在架构设计、技术决策、团队协调上。大模型可以帮他们更快地验证想法、生成原型、对比方案但最终的决策责任还是在他们身上。不过有一个变化值得注意大模型让快速验证变得极其廉价。以前你想验证一个架构方案是否可行可能要花几天搭个demo现在可能半天就能让模型生成一个可运行的原型。这意味着架构师的试错成本大幅降低可以更激进地探索新方案。5. 把大模型用出高价值的五个实操习惯5.1 上下文给足别让模型盲猜这是最基础但也最容易被忽略的一点。很多人用大模型的方式是贴一段代码问这段代码有什么问题。模型只能根据这段代码本身来回答看不到它调用的其他方法、看不到它的数据结构、看不到它的运行环境。我的习惯是在提问之前先把相关的类型定义、接口声明、关键常量、甚至数据库表结构一起整理好作为上下文给模型。这样它给出的回答准确率会高很多。虽然整理上下文要花几分钟但比来回追问要高效得多。5.2 分步拆解不要指望一次对话解决复杂问题大模型在处理复杂任务时一次性给出完整方案的质量往往不如分步引导。比如你要实现一个复杂的业务逻辑不要直接说帮我实现这个功能而是拆成几步先让它理解需求、再让它给出设计方案、然后让它实现核心逻辑、最后让它补充边界处理。这种分步方式的好处是每一步你都可以检查、纠正避免它在错误的方向上越走越远。而且分步之后每一轮的上下文更聚焦模型的表现也更稳定。5.3 让它解释给自己听用自检降低翻车率一个很实用的技巧是让模型在给出代码之后自己解释一遍这段代码的逻辑并列出可能的边界情况。很多时候它在解释的过程中就会发现自己漏掉了某个条件或者某个假设不成立。我经常用的一个提示是请检查你刚才生成的代码列出三个可能出错的场景并说明你的代码在这些场景下的表现。这个动作能筛掉相当一部分低级错误。5.4 建立自己的提示词模板库如果你每天都在用大模型把那些反复用到的提示词整理成模板会省很多时间。比如代码review模板单元测试生成模板接口文档生成模板bug排查模板。每个模板里把固定的上下文格式、输出要求、检查项都写清楚用的时候直接填内容就行。我自己的模板库里大概有十几个常用模板覆盖了日常工作中百分之七八十的场景。这个东西一开始花点时间建后面就是纯赚。5.5 永远保留人工验证这一环这条是底线。不管模型生成的代码看起来多合理涉及数据写入、权限判断、金额计算、并发控制的代码必须人工逐行验证。我见过太多因为盲目信任模型输出而导致的事故有些甚至是低级错误——比如模型把写成了在边界条件下就会出问题。验证的方式可以多样写单元测试、做代码review、在测试环境跑一遍。但这一步不能省。6. 工具链正在怎么变从编辑器插件到全流程嵌入6.1 代码补全类工具已经变成默认配置最早普及的一批工具是编辑器内的代码补全比如根据上下文预测下一行、根据注释生成代码块。这类工具现在已经相当成熟很多团队已经把它当成默认配置就像当年从记事本换到IDE一样自然。这类工具的价值在于减少打断。以前你写一个循环要停下来想一下语法现在你写个注释它就把循环框架补出来了。这种微小的效率提升累积起来很可观。6.2 对话式编程助手从问答到协作第二类是对话式的编程助手你可以跟它讨论方案、让它解释代码、让它帮你排查问题。这类工具的使用方式更接近结对编程——你有一个随时可以问的伙伴虽然它有时候会给出错误答案但大多数时候能给你提供思路。我现在的习惯是遇到不确定的技术选型先跟模型聊一轮让它列出几种方案的优劣然后我再结合自己的经验做判断。这个过程比纯靠自己想要快很多。6.3 自动化Agent还在早期但方向明确第三类是自动化Agent你可以给它一个任务它自己去读代码、改代码、跑测试、提交。这类工具目前还在比较早期的阶段在简单任务上表现不错但复杂任务还经常跑偏。不过方向是明确的未来的开发工具会越来越像一个能自己干活的助手而不是一个等你来问的问答机。作为开发者你需要学会的是如何给Agent下清楚的任务描述、如何设置检查点、如何验收它的产出。这些技能现在开始练以后会用得上。7. 我踩过的几个坑关于大模型写代码的负面经验7.1 过度信任导致的低级错误前面提过一次这里再展开说。我有一次让模型生成一个日期格式化的工具方法它用了SimpleDateFormat但没考虑线程安全问题。这个方法后来被用在了并发场景里导致偶发的日期解析错误。排查了半天才定位到。这个坑的教训是模型生成的代码你要按一个刚入职的新人写的代码来对待。它可能语法正确、逻辑通顺但对线程安全、资源释放、异常处理这些老手才会注意的点经常考虑不周。7.2 上下文污染导致的越改越乱当你跟模型进行多轮对话时前面的错误信息会污染后面的回答。比如你第一轮给了一个错误的示例模型在后续回答里可能会一直受这个错误示例的影响。或者你纠正了它一次它在后续回答里又矫枉过正。我的应对方式是当发现对话开始跑偏时果断开新对话把整理好的、干净的上下文重新给它。不要试图在已经混乱的对话里把它拉回来那样效率很低。7.3 对新框架、新版本的知识滞后大模型的训练数据是有截止时间的对于最近半年到一年内发布的新框架、新版本、新API它的了解可能是不准确的甚至会编造不存在的用法。我就遇到过模型给我推荐一个新特性结果一查文档根本没有。所以对于新技术栈我的做法是模型只用来帮我理解概念和对比方案具体API用法一定以官方文档为准。8. 往后看开发者的能力模型会怎么变8.1 会写代码的权重在下降会定义问题的权重在上升以前评价一个开发者很重要的一条是代码写得好不好。未来这条依然重要但**能不能把模糊的需求转化成清晰的、可执行的任务描述**会变得越来越关键。因为当实现环节被大幅加速之后瓶颈就转移到了定义问题这一步。这个能力包括把业务需求拆解成技术任务、把技术任务拆解成模型能理解的提示、判断模型的输出是否满足要求、在多个方案之间做取舍。这些能力本质上都是判断力和表达力而不是编码熟练度。8.2 代码review能力变得比代码编写能力更稀缺当大量代码由模型生成时能快速、准确地review代码的人会变得非常稀缺。因为review需要的不只是语法知识还有对业务的理解、对边界条件的敏感、对潜在风险的预判。这些恰恰是模型目前不擅长的。我甚至觉得未来团队里最值钱的人可能是那种自己写代码不一定最快但一眼就能看出别人代码里问题的人。8.3 对系统全局的理解成为分水岭模型擅长局部人擅长全局。当模型把局部实现变得极其廉价时对系统全局的理解——模块怎么划分、数据怎么流转、瓶颈可能在哪里、故障怎么隔离——就成了区分开发者水平的关键。这也是为什么我一直建议身边的年轻开发者不要只盯着怎么写这个函数要多问这个函数在整个系统里处于什么位置它的上游和下游是谁如果它挂了会怎样。这些问题模型回答不了但你的职业发展需要它们。9. 一个具体的协作流程我现在怎么跟大模型配合完成一个功能9.1 需求理解阶段让模型帮我翻译需求拿到一个需求文档后我会先把它贴给模型让它用技术语言重新描述一遍并列出它认为需要澄清的点。这一步经常能帮我发现需求里模糊的地方比我自己读一遍要仔细。比如有一次需求里写用户可以导出数据模型追问了导出格式是什么数据量大概多大是否需要异步导出这几个问题我才意识到产品经理根本没想清楚这些细节。9.2 方案设计阶段让模型列出多种方案并对比理解需求之后我会让模型列出两到三种实现方案并对比它们的优劣——开发成本、维护成本、性能影响、扩展性。然后我结合自己对项目的了解选择其中一种或者做融合。这一步的价值不在于模型选的方案一定对而在于它帮我快速穷举了可能性避免我陷入思维定式。9.3 编码阶段模型写第一版我做review和修正方案确定后我会把核心逻辑拆成几个部分让模型分别实现。每个部分生成后我立即review确认没问题再进入下一部分。这样比一次性生成全部代码再review要高效因为问题能更早发现。9.4 测试阶段让模型生成测试用例我来补充边界模型生成的单元测试通常覆盖的是正常路径边界条件和异常路径往往不够。所以我的做法是让模型先生成一批测试然后我自己补充那些我觉得可能会出问题的场景。9.5 文档阶段模型生成初稿我补充业务背景最后让模型根据代码生成接口文档和变更说明我再补充一些业务背景和注意事项。这样产出的文档既完整又有实际指导意义。10. 关于替代这件事我的真实看法回到标题里的问题大模型是辅助写代码还是会替代开发我的答案是它在替代开发工作中的某些环节而不是替代开发者这个角色。就像计算器替代了手算但没有替代会计Excel替代了算盘但没有替代财务分析师。被替代的是那些重复、模式化、上下文依赖低的环节。被放大的是那些需要判断、需要全局理解、需要跨领域协调的环节。对于开发者来说这既是一个威胁也是一个机会。威胁在于如果你一直停留在重复性工作的舒适区你的价值确实在缩水。机会在于如果你能借助模型把自己从重复性工作中解放出来把精力投入到更高价值的事情上你的成长速度会比以前快得多。我自己这两年最大的变化不是写代码变快了而是思考的时间变多了。以前一天下来可能写了八百行代码但没想清楚为什么要这么写现在可能只写了两百行但每一行都知道它在整个系统里的位置和作用。这种变化我觉得是好的。