先说个真实感受。过去这一两年身边不少程序员朋友的状态从“学不完新技术”变成了“学不动了”。框架更新换代还能追但当你看到大模型能自己写代码、改bug、甚至能根据一句需求把整个模块搭出来的时候那种冲击感是真的不一样。朋友圈里刷到“AI替代程序员”的文章后台留言里焦虑的同行也越来越多。但我的看法其实偏向标题里后半句大模型对程序员而言是冲击没错但更是一次很少见的逆袭窗口。为什么这么说因为这一轮技术变革的本质不是“工具取代人”而是“工具重新分配了能力的门槛”。以前很多程序员卡在“不会写底层”“不懂算法”“搞不定架构设计”这些壁垒需要多年积累才能突破。现在大模型把这些高门槛的东西压低了真正拉开差距的反而是你愿不愿意换一套工作方式、能不能把业务问题拆解成模型能执行的指令。这篇文章我就想围绕这个判断聊聊我观察到的冲击来源、正在被重新定价的能力以及几条我自己试过、也确实走通的路。1. 冲击感的真实来源不是模型多强而是工作方式变了先说一个大家可能没注意到的事实大部分程序员的日常其实并不是在创造复杂算法而是在做“翻译”和“搬运”。把业务需求翻译成代码把接口文档翻译成调用逻辑把旧系统的逻辑搬运到新架构里。这些工作以前靠经验积累写得多、见得多了自然熟练。但大模型最擅长的恰恰就是这类“模式识别生成”的活儿它的效率高到让人产生一种错觉——好像自己的岗位随时可以被替代。我最早有这种冲击感是有一次在重构一个老模块。那个模块少说也有几千行逻辑耦合很重以前我至少得花两三个晚上才能捋清楚。那次我试着把模块的入口函数和几个关键调用关系粘给模型让它先帮我梳理数据流再生成一版重构建议。结果十几分钟它给出的结构图感和分层思路已经接近我平时做方案的水平。那一刻我意识到真正被冲击的不是“我会写代码”这个能力而是“我过去引以为傲的熟练度”贬值了。但这恰恰也是转机的起点。熟练度贬值之后剩下来的核心价值是什么是做判断、定方向、控质量。模型能生成代码但它不知道该不该用这个方案能重构但它不清楚业务上哪条分支是核心路径能写测试但它不知道哪些边界条件是用户真正会踩到的。这些东西需要人基于对业务的理解和对系统的整体认知来拍板。换句话说大模型把“怎么做”的成本打到接近零但“做什么、为什么做、做到什么程度”的决策责任全压到了我们身上。我还注意到一个现象很多焦虑的同行焦虑的不是模型本身而是周围人用模型的方式。某次团队里一个同事用提示词半小时搭了一个内部工具的雏形而另一个同事还在逐行手写接口。这种对比带来的心理落差比模型本身的威胁要直接得多。所以我觉得与其花时间焦虑“AI会不会取代我”不如立刻开始研究“我该怎么用AI把效率拉满”后者才是真正能缓解焦虑的动作。2. 正在被重新定价的能力哪些角色最危险哪些人反而吃香如果非要对“冲击面”做一个拆解我倾向于把程序员岗位分成三类来看初级执行型、中间业务型、高级架构型。被冲击最大的是第一类因为他们的工作内容高度标准化比如按照原型写页面、按照接口文档调接口、写常规CRUD。这类代码的“信息量”很低模式固定正是大模型生成质量最高的部分。一个三年经验的人手写一天的模块模型可能十分钟就能给个七八成成品。中间业务型的人则处于“危与机并存”的位置。他们既要写代码又要对接需求、梳理流程、排查线上问题。模型能帮他们省掉大部分“查资料、翻文档、写样板代码”的时间但前提是他们能准确描述问题、能在模型给出答案后快速判断是否靠谱。这种人如果转型及时会变成“超级个体”的雏形一个人干过去两三个人的活。高级架构型的人反而迎来了黄金期。过去架构设计是个“高门槛信任活”因为容错率低、试错成本高团队通常只敢让最资深的人拍板。但现在不一样了你可以让大模型做架构方案的横向对比、风险评估、甚至生成演进路线草案架构师的工作从“从零思考”变成了“审核、收敛、决策”。我认识的一位某一线团队的技术负责人现在做技术选型时会让模型先把候选方案的利弊拉个矩阵他只需要把业务约束加进去做筛选即可。这不叫被替代这叫如虎添翼。所以我在很多场合跟年轻同事说不要看“岗位名称”判断安全度要看“工作内容的标准化程度”。越标准化、越依赖已知模式、越不需要上下文理解的工作越危险反过来越依赖上下文判断、越需要承担责任、越涉及人与人协作的工作越安全。大模型本质上是把“技能”的溢价打没了把“判断”和“责任”的溢价抬高了。想不被替代不是去学更多技能而是去承担更多需要判断的职责。3. 逆袭的三条主路线从“被替代”到“被放大”焦虑的尽头应该是行动。我梳理了一下身边真正从这波浪潮里获益的人发现他们的路径其实高度一致基本可以归纳成三条主路线每条都有对应的具体做法和适合人群。3.1 路线一成为“提示词工程师业务翻译官”这条路最适合那些业务理解能力不错、但代码深度一般的人。核心思路是你不跟模型比写代码而是比谁更懂业务、谁更能把模糊的需求转化成模型能执行的精确指令。举个例子同样是“帮我做个报表页面”初级用法是直接甩这句话给模型得到的可能是通用但不可用的模板进阶用法是把数据来源、权限范围、展示维度、交互要求、性能约束全部结构化描述出来让模型一次生成接近正式交付水平的代码。这套能力拆开看就两件事一是“需求结构化”把业务语言翻译成技术约束二是“指令迭代”根据模型输出反馈快速修正方向。这两件事都不需要深厚底层知识但对逻辑性和表达精确度要求很高——恰好是长期写代码的人被训练出来的强项。我见过好几个以前写业务页面的同事转岗做内部AI工具链的效率专家后价值反而比之前翻倍了。实操上可以这么练选一个你熟悉的业务模块先不写任何代码。用自然语言把它的功能、输入、输出、异常处理、性能预期全部写清楚然后扔给模型生成实现再对比你以前手写的版本看差距在哪。持续做十来个模块之后你对“模型到底能理解到什么程度”就会有非常具体的体感这比看一百篇教程都有用。3.2 路线二用大模型重构个人开发流程做“超级个体”第二条路适合所有写代码的人门槛最低见效最快。思路是不改变你原有的职责范围但把你工作流里所有“高重复、低创意”的环节全部交给模型。以前我写一个接口从Controller到Service再到Mapper一半时间是机械敲代码现在我直接把表结构、业务规则、返回格式丢给模型让它生成初版我再根据实际业务语义去调整命名、补充校验和异常处理。这条路的操作细节很值得说道说道。第一步把“代码生成”场景拆细。我用过的场景有根据数据库表生成实体类、根据接口文档生成前后端类型定义、根据一段日志堆栈生成问题排查脚本、根据需求描述生成技术方案初稿。每个场景都对应一套固定的提示词模板用熟了以后效率提升非常明显。第二步建立“人审模型”的流程意识。模型生成的东西一律默认有bug、有漏洞、有风格问题输出的代码必须过一遍“命名是否语义化、边界是否完整、异常是否兜底、性能是否达标”四项检查再合入。我现在的个人开发节奏大概是模型负责写七八成的内容骨架我负责把握方向、修细节、跑测试、处理边界情况。以前三天做完的功能现在一天半差不多就能完成多出来的时间我去看业务数据、完善测试用例、甚至整理技术文档。长期看这种“人机分工”如果被团队所有人采用整个研发效率的曲线会明显上移个人在团队里的价值反而不降反升因为你成了那个“能把模型用好的人”。3.3 路线三锚定“模型搞不定的硬骨头”做深做透第三条路更接近传统的技术护城河路线但方向需要调整。以前我们会说“把底层原理吃透”现在更明智的选择是“锚定那些模型输出质量差、犯错率高、需要深度推理和领域经验的场景”。我观察了一下当前大模型在几类任务上的表现还是明显偏弱的高并发场景下的性能调优、分布式系统的故障根因分析、安全相关的攻击面评估、大规模存量系统的渐进式重构还有那些涉及复杂业务规则和隐藏逻辑的模块。这些领域有一个共同特点公开的语料少、上下文依赖重、错误的代价高。模型生成的答案看起来“像那么回事”但距离可落地还有不小的距离而这段距离就是资深工程师的价值所在。一个做了五年性能优化的同事现在专攻“用模型辅助生成压测方案人工定位瓶颈”的半自动流程从技术深度和业务价值两个维度看都比单纯会写几段Prompt的人扎实得多也更难被替代。我的建议是做一个“反向筛选”把你自己手头的工作任务列个清单凡是模型轻松能做好的你就逐步放手让它做凡是模型做得不好、总需要你返工的就是你接下来要重点积累的方向。把精力集中在后者上既跟上了AI时代对效率的要求又巩固了你自己不可替代的那部分能力。这比单纯恐慌“底层会不会没用”要实在得多。4. 实测中的新工作流两个可落地的实操场景上面讲了不少理念这一节我就分享两个我自己在项目里实测过的具体场景把操作路径写细一些方便你直接上手试。场景不一定都适合你但流程逻辑是通用的核心是“如何把大模型嵌入到常规研发环节而不是停留在聊天框里”。4.1 场景一从混乱需求到第一版可运行代码我接手过一个中台模块的改造需求描述有一大段但里面包含了隐藏约束比如旧接口不能动、部分数据源访问频率受限、下游调用方兼容多种返回格式。以前的做法是拉个会反复确认然后花一天搭骨架。这次我换了个流程先把需求原文拆成“功能清单”“约束清单”“疑问清单”三块把疑问清单发群里让业务确认同时把两块确认后的清单直接作为提示词上下文发给模型让它给出模块设计草案。模型返回的初版方案里接口划分和数据模型设计基本合理但它没有考虑到数据源频控的问题。我在指令里追加了一条约束说明让它重新调整缓存策略和降级方案。第二次生成的代码把限频、熔断、兜底数据都考虑进去了虽然还需要改命名和补单测但整体框架比我以前从零画要快得多。当天下午我就把可运行的骨架代码合入分支了放在以前至少要两天。这个场景里我觉得最关键的一步不是“如何写提示词”而是“如何把需求拆成模型能理解的结构化输入”。很多人用不好模型是因为输入就是一句话模型只能给出一个泛泛而谈的答案。当你把需求拆成功能、约束、疑问三个维度再喂给它生成的方案质量会跳到另一个台阶。这也是为什么我说“业务翻译能力”会越来越值钱的原因。4.2 场景二老系统重构中的代码解释与模块拆分另一个高频场景是接手老系统。大家都知道老系统最难的不是代码本身而是“没有人说得清楚这段代码为什么这么写”。以前我只能靠读代码加脑补效率很低。现在我有一个固定套路把某个方法的完整代码贴给模型让它用三句话概括功能再列出所有外部依赖和隐藏副作用。它做得好的地方在于不会遗漏细节比如某个静态变量的修改、某个异常被吞掉的逻辑它都能在解释里标出来。拿到解释之后我会进行模块拆分规划。具体做法是把系统按“稳定核心”“外部适配”“历史包袱”三类划分稳定核心逻辑交给模型做单测生成和注释补齐外部适配部分用“接口定义适配层代码生成”的方式迭代历史包袱暂时不动只写清说明文档。这套方法让一个小团队在一个迭代周期内就把一个两万行的老模块梳理干净了而且接手的同事反馈现在的代码可读性比之前好太多。这类“解释→规划→执行”的流程其实也是人机协作的正循环模型负责把“过去的状态”快速摸清人负责判断“未来的方向”。消耗在阅读理解上的时间少了就能把精力投入真正需要脑子的架构决策和高风险改造。我建议每个准备重构老系统的团队都先拿一两个模块做这个实验体感会非常直观。5. 从认识到行动给不同阶段程序员的具体建议讲了不少大方向最后我想落脚到“接下来怎么办”这个问题上。我身边有刚入行的新人也有工作了十几年的资深开发大家的焦虑点和机会点完全不一样所以我按人群分开说你可以对号入座。5.1 刚入行一两年的新人别慌先把“工具化生存”练成本能我这个建议可能会被误解成“不重视基础”但实际上恰恰相反。正是在基础还没完全成型的时候借助模型效率工具把大量重复劳动外包出去你才有时间补齐底层的短板如数据结构、网络协议、操作系统原理。现在的错误做法是一边恐慌“AI会取代我”一边还在用最低效的方式重复写样板代码两头都耽误。具体做法建议分三步走。第一步把模型当成你的“结对编程伙伴”每一段代码都先让它给个版本再问它几个关键问题这里为什么用这个数据结构这个边界情况要不要处理这个方法的时间复杂度是多少它的回答就是你的免费导师。第二步每周拿出一定时间补底层知识看模型生成的代码时多问“为什么”并追到语言特性或框架源码层面。第三步坚持手写一些核心算法的实现和关键业务链路的整体流程确保哪天模型不可用了你依然能独立干活。5.2 有五到十年经验的中坚力量把“模型效率”变成团队资产五年以上经验的同学编码能力已经不是瓶颈瓶颈在于时间不够用。大家既要写代码、带新人、还要各种接口协作会议。如果你的需求场景还停留在“偶尔问模型一段代码”那确实浪费了这一波工具红利。我建议你做的不是“更高效地写代码”而是“把提效流程固化下来沉淀给团队”。具体来说可以做三件事。一是梳理团队里高频、重复、有标准答案的研发环节比如接口联调前的类型生成、环境初始化脚本、通用组件案例收集做成一整套提示词模板库。二是定期组织内部交流分享人机协作的踩坑经验。三是从你手头最耗时的模块开始做至少一次“人机协作流程重构”把效果数据记录下来。别小看这件事在一个百人研发团队里如果你带领的小组效率提升了30%这就是非常亮眼的业绩。5.3 资深专家或架构师你的战场在决策层放手把执行交给工具如果你是团队里最资深的那几个人我猜你的时间更多花在评审、规划、跨团队协调上。这个位置其实受冲击最小但责任也最大——因为你需要决定“哪些环节该用模型、模型用到什么程度、边界和质量红线划在哪里”。这不是甩手掌柜而是更高阶的管理能力。我的个人体会是架构师这个角色现在最好当也最难当。好当是因为信息获取成本低了新的框架、新的方案、新的性能数据可以让模型先帮你做对比分析省去大量调研时间难当是因为决策越来越卷以前大家拼的是谁能设计出更优雅的方案现在拼的是谁能在更高的不确定性和更短的时间内做出可行且风险可控的决策。模型负责提供信息增量你负责为决策后果负责这个分工短期内不会变。写在最后的一点个人体会说了这么多其实最想表达的只有一句话大模型这波浪潮里真正让人拉开差距的不是谁的工具更新、谁的提示词更花哨而是谁先完成了“自我工作方式的重新设计”。我自己也是踩了不少坑才慢慢摸到门道早期用过很蠢的方式比如让模型直接生成整个项目结果生成了一堆看似完整实则难以维护的代码后来才明白模型适合出现在“流程中效率最低的环节”而不是“整个流程的替代品”。如果你现在还在焦虑我建议你做一件最简单的事挑一个你下周要做的任务把一个环节交给模型完整记录它和你的分工过程。一周之后回来看看你的体感会比读任何文章都真实。这大概是这个时代少数几个“越想越焦虑、越做越踏实”的事情与其等着被冲击不如先动手把自己变成那个用好工具的人。 
长河君 · 2026/10/20 6:51:33 · 阅读 1.2k 大模型时代程序员逆袭：人机协作重塑工作流
先说个真实感受。过去这一两年身边不少程序员朋友的状态从“学不完新技术”变成了“学不动了”。框架更新换代还能追但当你看到大模型能自己写代码、改bug、甚至能根据一句需求把整个模块搭出来的时候那种冲击感是真的不一样。朋友圈里刷到“AI替代程序员”的文章后台留言里焦虑的同行也越来越多。但我的看法其实偏向标题里后半句大模型对程序员而言是冲击没错但更是一次很少见的逆袭窗口。为什么这么说因为这一轮技术变革的本质不是“工具取代人”而是“工具重新分配了能力的门槛”。以前很多程序员卡在“不会写底层”“不懂算法”“搞不定架构设计”这些壁垒需要多年积累才能突破。现在大模型把这些高门槛的东西压低了真正拉开差距的反而是你愿不愿意换一套工作方式、能不能把业务问题拆解成模型能执行的指令。这篇文章我就想围绕这个判断聊聊我观察到的冲击来源、正在被重新定价的能力以及几条我自己试过、也确实走通的路。1. 冲击感的真实来源不是模型多强而是工作方式变了先说一个大家可能没注意到的事实大部分程序员的日常其实并不是在创造复杂算法而是在做“翻译”和“搬运”。把业务需求翻译成代码把接口文档翻译成调用逻辑把旧系统的逻辑搬运到新架构里。这些工作以前靠经验积累写得多、见得多了自然熟练。但大模型最擅长的恰恰就是这类“模式识别生成”的活儿它的效率高到让人产生一种错觉——好像自己的岗位随时可以被替代。我最早有这种冲击感是有一次在重构一个老模块。那个模块少说也有几千行逻辑耦合很重以前我至少得花两三个晚上才能捋清楚。那次我试着把模块的入口函数和几个关键调用关系粘给模型让它先帮我梳理数据流再生成一版重构建议。结果十几分钟它给出的结构图感和分层思路已经接近我平时做方案的水平。那一刻我意识到真正被冲击的不是“我会写代码”这个能力而是“我过去引以为傲的熟练度”贬值了。但这恰恰也是转机的起点。熟练度贬值之后剩下来的核心价值是什么是做判断、定方向、控质量。模型能生成代码但它不知道该不该用这个方案能重构但它不清楚业务上哪条分支是核心路径能写测试但它不知道哪些边界条件是用户真正会踩到的。这些东西需要人基于对业务的理解和对系统的整体认知来拍板。换句话说大模型把“怎么做”的成本打到接近零但“做什么、为什么做、做到什么程度”的决策责任全压到了我们身上。我还注意到一个现象很多焦虑的同行焦虑的不是模型本身而是周围人用模型的方式。某次团队里一个同事用提示词半小时搭了一个内部工具的雏形而另一个同事还在逐行手写接口。这种对比带来的心理落差比模型本身的威胁要直接得多。所以我觉得与其花时间焦虑“AI会不会取代我”不如立刻开始研究“我该怎么用AI把效率拉满”后者才是真正能缓解焦虑的动作。2. 正在被重新定价的能力哪些角色最危险哪些人反而吃香如果非要对“冲击面”做一个拆解我倾向于把程序员岗位分成三类来看初级执行型、中间业务型、高级架构型。被冲击最大的是第一类因为他们的工作内容高度标准化比如按照原型写页面、按照接口文档调接口、写常规CRUD。这类代码的“信息量”很低模式固定正是大模型生成质量最高的部分。一个三年经验的人手写一天的模块模型可能十分钟就能给个七八成成品。中间业务型的人则处于“危与机并存”的位置。他们既要写代码又要对接需求、梳理流程、排查线上问题。模型能帮他们省掉大部分“查资料、翻文档、写样板代码”的时间但前提是他们能准确描述问题、能在模型给出答案后快速判断是否靠谱。这种人如果转型及时会变成“超级个体”的雏形一个人干过去两三个人的活。高级架构型的人反而迎来了黄金期。过去架构设计是个“高门槛信任活”因为容错率低、试错成本高团队通常只敢让最资深的人拍板。但现在不一样了你可以让大模型做架构方案的横向对比、风险评估、甚至生成演进路线草案架构师的工作从“从零思考”变成了“审核、收敛、决策”。我认识的一位某一线团队的技术负责人现在做技术选型时会让模型先把候选方案的利弊拉个矩阵他只需要把业务约束加进去做筛选即可。这不叫被替代这叫如虎添翼。所以我在很多场合跟年轻同事说不要看“岗位名称”判断安全度要看“工作内容的标准化程度”。越标准化、越依赖已知模式、越不需要上下文理解的工作越危险反过来越依赖上下文判断、越需要承担责任、越涉及人与人协作的工作越安全。大模型本质上是把“技能”的溢价打没了把“判断”和“责任”的溢价抬高了。想不被替代不是去学更多技能而是去承担更多需要判断的职责。3. 逆袭的三条主路线从“被替代”到“被放大”焦虑的尽头应该是行动。我梳理了一下身边真正从这波浪潮里获益的人发现他们的路径其实高度一致基本可以归纳成三条主路线每条都有对应的具体做法和适合人群。3.1 路线一成为“提示词工程师业务翻译官”这条路最适合那些业务理解能力不错、但代码深度一般的人。核心思路是你不跟模型比写代码而是比谁更懂业务、谁更能把模糊的需求转化成模型能执行的精确指令。举个例子同样是“帮我做个报表页面”初级用法是直接甩这句话给模型得到的可能是通用但不可用的模板进阶用法是把数据来源、权限范围、展示维度、交互要求、性能约束全部结构化描述出来让模型一次生成接近正式交付水平的代码。这套能力拆开看就两件事一是“需求结构化”把业务语言翻译成技术约束二是“指令迭代”根据模型输出反馈快速修正方向。这两件事都不需要深厚底层知识但对逻辑性和表达精确度要求很高——恰好是长期写代码的人被训练出来的强项。我见过好几个以前写业务页面的同事转岗做内部AI工具链的效率专家后价值反而比之前翻倍了。实操上可以这么练选一个你熟悉的业务模块先不写任何代码。用自然语言把它的功能、输入、输出、异常处理、性能预期全部写清楚然后扔给模型生成实现再对比你以前手写的版本看差距在哪。持续做十来个模块之后你对“模型到底能理解到什么程度”就会有非常具体的体感这比看一百篇教程都有用。3.2 路线二用大模型重构个人开发流程做“超级个体”第二条路适合所有写代码的人门槛最低见效最快。思路是不改变你原有的职责范围但把你工作流里所有“高重复、低创意”的环节全部交给模型。以前我写一个接口从Controller到Service再到Mapper一半时间是机械敲代码现在我直接把表结构、业务规则、返回格式丢给模型让它生成初版我再根据实际业务语义去调整命名、补充校验和异常处理。这条路的操作细节很值得说道说道。第一步把“代码生成”场景拆细。我用过的场景有根据数据库表生成实体类、根据接口文档生成前后端类型定义、根据一段日志堆栈生成问题排查脚本、根据需求描述生成技术方案初稿。每个场景都对应一套固定的提示词模板用熟了以后效率提升非常明显。第二步建立“人审模型”的流程意识。模型生成的东西一律默认有bug、有漏洞、有风格问题输出的代码必须过一遍“命名是否语义化、边界是否完整、异常是否兜底、性能是否达标”四项检查再合入。我现在的个人开发节奏大概是模型负责写七八成的内容骨架我负责把握方向、修细节、跑测试、处理边界情况。以前三天做完的功能现在一天半差不多就能完成多出来的时间我去看业务数据、完善测试用例、甚至整理技术文档。长期看这种“人机分工”如果被团队所有人采用整个研发效率的曲线会明显上移个人在团队里的价值反而不降反升因为你成了那个“能把模型用好的人”。3.3 路线三锚定“模型搞不定的硬骨头”做深做透第三条路更接近传统的技术护城河路线但方向需要调整。以前我们会说“把底层原理吃透”现在更明智的选择是“锚定那些模型输出质量差、犯错率高、需要深度推理和领域经验的场景”。我观察了一下当前大模型在几类任务上的表现还是明显偏弱的高并发场景下的性能调优、分布式系统的故障根因分析、安全相关的攻击面评估、大规模存量系统的渐进式重构还有那些涉及复杂业务规则和隐藏逻辑的模块。这些领域有一个共同特点公开的语料少、上下文依赖重、错误的代价高。模型生成的答案看起来“像那么回事”但距离可落地还有不小的距离而这段距离就是资深工程师的价值所在。一个做了五年性能优化的同事现在专攻“用模型辅助生成压测方案人工定位瓶颈”的半自动流程从技术深度和业务价值两个维度看都比单纯会写几段Prompt的人扎实得多也更难被替代。我的建议是做一个“反向筛选”把你自己手头的工作任务列个清单凡是模型轻松能做好的你就逐步放手让它做凡是模型做得不好、总需要你返工的就是你接下来要重点积累的方向。把精力集中在后者上既跟上了AI时代对效率的要求又巩固了你自己不可替代的那部分能力。这比单纯恐慌“底层会不会没用”要实在得多。4. 实测中的新工作流两个可落地的实操场景上面讲了不少理念这一节我就分享两个我自己在项目里实测过的具体场景把操作路径写细一些方便你直接上手试。场景不一定都适合你但流程逻辑是通用的核心是“如何把大模型嵌入到常规研发环节而不是停留在聊天框里”。4.1 场景一从混乱需求到第一版可运行代码我接手过一个中台模块的改造需求描述有一大段但里面包含了隐藏约束比如旧接口不能动、部分数据源访问频率受限、下游调用方兼容多种返回格式。以前的做法是拉个会反复确认然后花一天搭骨架。这次我换了个流程先把需求原文拆成“功能清单”“约束清单”“疑问清单”三块把疑问清单发群里让业务确认同时把两块确认后的清单直接作为提示词上下文发给模型让它给出模块设计草案。模型返回的初版方案里接口划分和数据模型设计基本合理但它没有考虑到数据源频控的问题。我在指令里追加了一条约束说明让它重新调整缓存策略和降级方案。第二次生成的代码把限频、熔断、兜底数据都考虑进去了虽然还需要改命名和补单测但整体框架比我以前从零画要快得多。当天下午我就把可运行的骨架代码合入分支了放在以前至少要两天。这个场景里我觉得最关键的一步不是“如何写提示词”而是“如何把需求拆成模型能理解的结构化输入”。很多人用不好模型是因为输入就是一句话模型只能给出一个泛泛而谈的答案。当你把需求拆成功能、约束、疑问三个维度再喂给它生成的方案质量会跳到另一个台阶。这也是为什么我说“业务翻译能力”会越来越值钱的原因。4.2 场景二老系统重构中的代码解释与模块拆分另一个高频场景是接手老系统。大家都知道老系统最难的不是代码本身而是“没有人说得清楚这段代码为什么这么写”。以前我只能靠读代码加脑补效率很低。现在我有一个固定套路把某个方法的完整代码贴给模型让它用三句话概括功能再列出所有外部依赖和隐藏副作用。它做得好的地方在于不会遗漏细节比如某个静态变量的修改、某个异常被吞掉的逻辑它都能在解释里标出来。拿到解释之后我会进行模块拆分规划。具体做法是把系统按“稳定核心”“外部适配”“历史包袱”三类划分稳定核心逻辑交给模型做单测生成和注释补齐外部适配部分用“接口定义适配层代码生成”的方式迭代历史包袱暂时不动只写清说明文档。这套方法让一个小团队在一个迭代周期内就把一个两万行的老模块梳理干净了而且接手的同事反馈现在的代码可读性比之前好太多。这类“解释→规划→执行”的流程其实也是人机协作的正循环模型负责把“过去的状态”快速摸清人负责判断“未来的方向”。消耗在阅读理解上的时间少了就能把精力投入真正需要脑子的架构决策和高风险改造。我建议每个准备重构老系统的团队都先拿一两个模块做这个实验体感会非常直观。5. 从认识到行动给不同阶段程序员的具体建议讲了不少大方向最后我想落脚到“接下来怎么办”这个问题上。我身边有刚入行的新人也有工作了十几年的资深开发大家的焦虑点和机会点完全不一样所以我按人群分开说你可以对号入座。5.1 刚入行一两年的新人别慌先把“工具化生存”练成本能我这个建议可能会被误解成“不重视基础”但实际上恰恰相反。正是在基础还没完全成型的时候借助模型效率工具把大量重复劳动外包出去你才有时间补齐底层的短板如数据结构、网络协议、操作系统原理。现在的错误做法是一边恐慌“AI会取代我”一边还在用最低效的方式重复写样板代码两头都耽误。具体做法建议分三步走。第一步把模型当成你的“结对编程伙伴”每一段代码都先让它给个版本再问它几个关键问题这里为什么用这个数据结构这个边界情况要不要处理这个方法的时间复杂度是多少它的回答就是你的免费导师。第二步每周拿出一定时间补底层知识看模型生成的代码时多问“为什么”并追到语言特性或框架源码层面。第三步坚持手写一些核心算法的实现和关键业务链路的整体流程确保哪天模型不可用了你依然能独立干活。5.2 有五到十年经验的中坚力量把“模型效率”变成团队资产五年以上经验的同学编码能力已经不是瓶颈瓶颈在于时间不够用。大家既要写代码、带新人、还要各种接口协作会议。如果你的需求场景还停留在“偶尔问模型一段代码”那确实浪费了这一波工具红利。我建议你做的不是“更高效地写代码”而是“把提效流程固化下来沉淀给团队”。具体来说可以做三件事。一是梳理团队里高频、重复、有标准答案的研发环节比如接口联调前的类型生成、环境初始化脚本、通用组件案例收集做成一整套提示词模板库。二是定期组织内部交流分享人机协作的踩坑经验。三是从你手头最耗时的模块开始做至少一次“人机协作流程重构”把效果数据记录下来。别小看这件事在一个百人研发团队里如果你带领的小组效率提升了30%这就是非常亮眼的业绩。5.3 资深专家或架构师你的战场在决策层放手把执行交给工具如果你是团队里最资深的那几个人我猜你的时间更多花在评审、规划、跨团队协调上。这个位置其实受冲击最小但责任也最大——因为你需要决定“哪些环节该用模型、模型用到什么程度、边界和质量红线划在哪里”。这不是甩手掌柜而是更高阶的管理能力。我的个人体会是架构师这个角色现在最好当也最难当。好当是因为信息获取成本低了新的框架、新的方案、新的性能数据可以让模型先帮你做对比分析省去大量调研时间难当是因为决策越来越卷以前大家拼的是谁能设计出更优雅的方案现在拼的是谁能在更高的不确定性和更短的时间内做出可行且风险可控的决策。模型负责提供信息增量你负责为决策后果负责这个分工短期内不会变。写在最后的一点个人体会说了这么多其实最想表达的只有一句话大模型这波浪潮里真正让人拉开差距的不是谁的工具更新、谁的提示词更花哨而是谁先完成了“自我工作方式的重新设计”。我自己也是踩了不少坑才慢慢摸到门道早期用过很蠢的方式比如让模型直接生成整个项目结果生成了一堆看似完整实则难以维护的代码后来才明白模型适合出现在“流程中效率最低的环节”而不是“整个流程的替代品”。如果你现在还在焦虑我建议你做一件最简单的事挑一个你下周要做的任务把一个环节交给模型完整记录它和你的分工过程。一周之后回来看看你的体感会比读任何文章都真实。这大概是这个时代少数几个“越想越焦虑、越做越踏实”的事情与其等着被冲击不如先动手把自己变成那个用好工具的人。