我不记得那天晚上具体在调哪一段逻辑了但我清楚记得那种荒诞感——我在一个字段命名问题上纠结了半小时旁边的对话框里AI三秒钟就生成了一段能跑的代码。我盯着屏幕坐了很久脑子里只有一个问题如果“写代码”这件事可以被替代那我这十几年到底在积累什么然后我突然意识到这个问题本身就是答案的起点——当AI开始写代码我们才第一次真正去想除了“写代码”之外我们到底是谁。这篇文章不是来教你某个具体框架或工具的我想认真聊聊这段时间我在AI编程浪潮里的一些真实经历和想法。包括我怎样从“看不上”到“离不开”包括我在人机协作中踩过的坑也包括我认为AI永远替代不了的那部分东西。如果你想了解AI编程到底把人逼到了什么位置或者你自己也在焦虑“程序员还有没有未来”这篇内容应该能给你一些不一样的视角。1. 从“看不上”到“离不了”再到“有点慌”我使用AI编程的真实轨迹1.1 第一阶段把AI当“高级补全”嘴上嫌弃身体诚实大概两年前我第一次用AI写代码当时的感觉就四个字不过如此。让它写个冒泡排序、斐波那契数列还行一旦涉及稍微复杂一点的业务逻辑它就开始一本正经地胡扯生成一堆看似合理但根本无法编译的代码。那时候我的结论很简单这玩意儿就是个高级点的代码补全工具替代不了程序员顶多是个玩具。但转折来得很突然。大概过了一年我接了一个需求要把一份旧的CSV数据处理脚本改造成一个支持实时调用的服务接口。按理说这活儿不难但我那段时间项目排得特别满实在没时间一行一行去写。于是我试着把需求描述了一下丢给AI它真的给我生成了一版结构完整的Spring Boot接口包括异常处理、日志记录和分页逻辑。我把它拿下来改改就直接上线了。那一刻我就知道自己的心态已经回不去了。很多同行现在还在争论“AI写不出好代码”“AI只会拼凑网上内容”我的态度很明确别急着下结论先去用几个周再说话。用完之后你会发现真正让你慌的不是AI写得好不好而是它生成代码的速度已经远超你的预期你原本最自豪的“手速”变成了最廉价的能力。1.2 第二阶段Agent出现后我开始重新定义自己的工作2024年下半年开始越来越多的AI编程工具从“单轮问答”升级成了“Agent式自主执行”。你给它一个目标它能自己拆解步骤、写代码、跑测试、报错、再修改整个循环可以持续好几轮。我在本地跑过一次真实的体验要求AI把一个低速的批量图像处理脚本改造成支持并发和断点续传的工具十几分钟后它交出了一个能用的版本不仅加了线程池还顺手把日志格式统一了。实测下来的感受是Agent式编程跟单轮问答完全不是一个量级。单轮问答里的AI像是一个“你问一句它答一句”的新人Agent已经变成“你交代任务它自己推进”的实习生。这个转变让我心里咯噔了一下因为过去我判断“AI替代不了程序员”的最重要依据就是“它无法自主完成一个完整任务”。现在这个依据已经被瓦解了一角。1.3 第三阶段真正让我警醒的是“写得又快又像”的平庸代码说实话写了这么多年程序我对“代码质量”是有点自负的。但AI编程出现之后我慢慢发现一个扎心的事实AI生成的代码在绝大多数普通业务场景里质量已经超过了相当一部分工作年限不长的程序员。它的命名规范、注释风格、容错处理虽然不是完美的但绝对是“及格线以上”的。坏就坏在这个“及格线以上”。因为过去企业里大量所谓“开发工作”实际上需要的恰恰就是这种及格线以上的代码——增删改查、接口封装、页面渲染、简单的数据处理。这些活儿在任何一个开发团队里都占了可能六成以上的工作量。当AI把这些活儿做得又快又有模有样时整个行业的价值结构就必然要重新洗牌。那些只会“照着重写写、照着需求码”的程序员很快会发现自己的不可替代性约等于零。2. AI写的代码越来越像“标准答案”但编程从来不是做标准答案2.1 AI本质上是“已知答案的检索重组器”我花了很长一段时间去琢磨AI写代码的原理到底是什么然后在一次很偶然的机会里想通了一个类比。你可以把AI想象成一条巨大的、看过无数网络答案的狗它不是每条都懂但它见过的“标准答案”太多了。你给它一个需求它就是从海量的、已经存在的代码片段里找出最相似的那几块再用概率判断的方式拼接出一个组合。这就决定了它擅长的事情有一个明确的天花板凡是网上已经有答案的问题AI能做得又快又好凡是网上没有答案、或者答案散落且互相矛盾的问题AI就会开始“自信地胡说”。换句话说它不是在解决问题它是在检索重组“看起来像解决方案”的东西。这两者之间有一条巨大的鸿沟。2.2 编程真正的难度在于“约束理解和权衡决策”我们可能很久没想过一个问题了写代码这件事里到底哪部分是难的如果只是“把某个功能用代码实现出来”那其实真的不难语法是死的框架是固定的API查一查就知道。真正的难度在于在理解业务诉求的基础上识别出所有隐含的约束条件然后在多个可能方案里做出最合适的权衡。我举个实际例子。之前做一个系统客户说“导出报表就行”听起来很简单对吧但业务背后的隐含约束是数据量可能超过百万行、服务器内存只有2G、财务部门要求导出必须保留原始字段不做任何转换、IT部门要求不能新增数据库只读账号。这一堆约束没有任何一个写在需求文档里。如果你不了解业务的真实压力、不了解服务器的真实水位、不了解部门之间的政治关系你写出来的代码就算性能再好也是废的。AI不懂这些。它只知道“导出报表”四个字然后生成一个最简单的全量查询方案。如果照着这个方案做项目上线第一天就会把内存打爆。所以问题的重点始终不在“怎么把代码写出来”而在“怎么把约束找出来并做出正确取舍”。这件事AI做不了因为约束往往不在代码里而在人的脑子里和组织的缝隙里。2.3 AI能做什么 vs 不能做什么一张说清楚边界的对照表AI能做到且效果不错的AI目前很难做到的生成样板代码和常见算法实现理解业务痛点的优先级何为“紧急”何为“重要”快速搭建原型和Demo在多条约束条件互相冲突时做真正的取舍决策将代码从一种语言翻译成另一种为自己的判断和产出承担最终责任根据已有测试生成补充用例理解组织里的人怎么协作、谁是真正拍板的人识别明显的语法错误和风格问题创造性地定义一个新问题而不是在旧问题里打转在给定上下文里重构部分逻辑在连续多天、多人协作的复杂系统中保持全局一致性写这张表的时候我很认真地想了想自己平时到底在做什么。有一说一我每天真正花在“写代码”上面的时间可能只占四成不到其他时间都在沟通需求、确认边界、评审方案、排查线上问题、跟其他团队扯清楚接口约定。这些工作从来就不好被量化但它们才是一个软件能真正落地、能长期稳定运行的关键。3. 当“会写码”不再稀缺程序员的价值锚点开始迁移3.1 从“编码者”到“问题定义者”身份的第一次跃迁我在上一篇博客里提过一句话今天还想再拿出来说一遍编码者是最容易被替代的角色问题定义者是最难被替代的角色。这句话听起来有点像是心灵鸡汤但时间越长我越觉得它是一个很务实的行业判断。AI接管“写码”之后程序员如果还把自己的身份锚定在“我会写Java/Python”那确实无处可逃。但如果你把自己的身份锚定在“我能搞清楚项目里真正要解决什么问题”那AI反而成了你最好的放大器。原因也很简单。以前我们做一个功能要先花一两天把代码写出来才能让业务方看到雏形才能根据反馈修正方向。现在AI可以在几分钟内生成一个可运行的版本你甚至可以让它一次生成三五个不同风格的方案。这时候整个团队的约束瓶颈就转移了——不再是“写得慢、写得累”而是“你想清楚自己要什么了没有”。谁能更快地想清楚需求边界谁能更准地定义成功标准谁就成了那个不可替代的人。3.2 一个让我记忆深刻的案例AI在几分钟内给了我10版方案但没有一版是对的这个案例我每次跟同行聊都觉得特别典型。有一次一个非技术背景的同事找我帮忙说想做一个数据迁移工具把旧系统里的客户资料搬到一个新表结构里。我试着把这个需求交给了AI工具并让它生成10个不同的迁移脚本方案。AI非常配合哗啦啦全写出来了有的用存储过程有的用Python脚本有的用ETL工具配置甚至还有一版用了消息队列做异步迁移。乍一看都很完美但所有方案都漏掉了同一个关键点旧系统里近三成的客户记录是有创建时间和更新时间缺失的财务那边要求这些记录必须人工逐条确认后才能迁移。这个约束我没告诉AI吗我告诉了但它没办法理解这件事在业务现场到底意味着什么、它会给整个项目带来什么样的节奏影响。它觉得“缺失时间”就是“填一个默认值”的问题。但在真实业务里这是要开三次会、拉两个部门、得罪一个老员工才能敲定的大事件。那一刻我忽然明白AI替我们完成了所有“方案层面的想象力”却完全帮不上“现实层面的判断力”。它能在两分钟内生成十种可能路径但它无法告诉你哪条路在你们公司、你们的业务环境里真的走得通。这是只有人才能给出的答案。后来那个项目的最终方案其实没有任何技术含量——就是“先导出待确认清单做完了人工确认再跑AI生成的迁移脚本”。3.3 审查、负责、兜底AI时代程序员的三个新动作既然价值锚点已经从“写”转移到了“定义判断”和“承担后果”那具体到每天的工作我觉得程序员的日常动作也该跟随调整。过去我们的核心动作是“生产代码”——把它写出来就行。现在你手里的AI已经承担了一部分“生产”工作那你应该把精力放到这三件事上审查AI生成的代码你要像给一个新同事做代码评审一样严格看。不是看它语法对不对而是看它的边界处理、日志埋点、并发安全、异常路径是否考虑了。负责AI写出来的代码出了问题追责链条上永远指向人不会是模型。所以你是在用一个工具给自己加杠杆杠杆的方向要自己把控。上线之前哪些东西你愿意签字背书这是很重要的修炼。兜底当AI在迭代过程中反复陷入同一种错误时你要有能力跳出来看全局是需求描述有问题还是上下文给得不够还是这个方案路线本身就错了这个跳出循环的能力是现在的Agent还不太具备的。这三个动作本质上都是在围着“判断”服务。因为“写”已经被工具代劳了“判断”就成了我们生存的护城河。4. 与AI协作的正确姿势提示词、规则和Agent工作流避坑版4.1 提示词工程的本质把需求说清楚而不是把答案问出来我知道“提示词工程”这个词已经被讲烂了但很多朋友其实误解了它。他们以为提示词工程是“想方设法问AI要一个准确的答案”所以拼命地给AI下命令——“给我生成一个最优解”。但真正高效的提示词它的关键是让你的需求边界足够清晰、足够可验证而不是让你像个甲方一样提要求。我自己的经验是一段高质量的编程提示词至少应该包含五个维度背景、目标、约束、非目标、交付格式。你把它当作你在给一个认真但缺乏常识的实习生布置任务你写得越清楚AI的产出就越靠谱。反过来如果你只写“帮我写个导出接口”那AI只能给你一个连异常处理都懒得加的平庸答案那时候骂AI不行就不公平了。下面是我一个实战中常用的模板可以直接抄走【背景】 我在做一个内部管理系统的导出模块技术栈是Java Spring Boot PostgreSQL。 现有导出逻辑是单线程一次性查询已经在生产环境暴露出慢和内存占用高的问题。 【目标】 实现一个支持按时间区间、按状态筛选的CSV导出接口。 成功标准10万行数据导出内存占用不超过256MB耗时不超过5秒。 【约束】 - 不能引入新的第三方依赖库 - 导出必须使用流式写入不允许一次性装载全量数据到内存 - 必须兼容现有权限校验逻辑方法签名不能被破坏 【非目标】 - 不需要做前端页面 - 不需要支持多语言国际化 - 不需要考虑分库分表那不在本次范围内 【交付格式】 先给出设计思路和代码结构说明我确认后再写具体实现。 代码需要包含完整的异常处理、日志埋点和单元测试。写清楚这五块之后AI的产出质量会有肉眼可见的提升。特别值得留意的是“非目标”这一项很多人会忽略它但它的价值非常大。因为AI最擅长“自作主张”如果你不明确告诉它“哪些事不归你管”它就会沿着自己的想象力给你增加一堆你没有要求的复杂度最后你还要花时间删掉那些多余的“好意”。4.2 规则设定让AI先问、先计划、再动手很多AI工具现在都支持自定义规则或者“项目级Agent设定”我强烈建议你利用好这个能力而不是每次对话都重复一遍你的要求。我自己的做法是在规则文件里写死几条铁律长这样接到需求后先输出你对需求的理解并列出所有不确定的业务点等待确认后再开始写代码。任何关键API的使用必须备注你参考的文档来源不允许编造不存在的函数签名。代码风格以项目内已有的历史代码为准先阅读几个现有文件再动笔。涉及数据库的操作必须考虑索引和分批处理禁止全表扫描式实现。这几条规则每一条都是我踩过坑以后总结出来的。你可能会说“这也太细了”但实战里正是这些细节决定了AI产出的下限。特别是“先输出理解再动手”这一条能够拦截掉绝大多数的需求偏差。很多AI生成的代码之所以带着一股“披着用户需求外衣的通用答案”味就是因为它在没搞清楚场景的情况下就急着输出了。4.3 我在实战里踩过的几个坑坑一AI会一本正经地编造API。有一次我让它用某个开源库的新版本写一段逻辑它给我生成了一个看起来特别合理的API调用但一查文档那个函数根本不存在。后来我养成了习惯凡是AI用到的陌生API我都会先复制函数名到官方文档里核对一下。这不是对AI不信任而是对自己的代码负责。坑二上下文窗户在长任务里会“漏风”。Agent在连续执行多轮任务后经常忘记最开始设定的约束条件。我遇到过它会中途把“不能用第三方库”这条约束给忘了然后在代码里引入一个新的JSON处理库。解决方法是把最重要的约束反复放在每个新的提示词开头不要指望它每次都记得住。说白了AI的记忆力没有你想象中那么好它更像一个做完一段就擦黑板的临时工。坑三表面能跑的代码边界处理几乎为零。AI特别喜欢把“正常路径”写得清清楚楚却对“异常路径”一片空白。你让它写一个文件上传接口它会写得漂漂亮亮但根本没有考虑磁盘满了怎么办、上传了一半连接断了怎么办、文件名带中文非法字符怎么办。现在我的习惯是拿到AI生成的代码后先审查所有“else”和“catch”分支这两个地方才是代码能不能上生产的真正分水岭。坑四代码风格割裂维护成本高。AI生成的代码如果跟项目原有风格差异太大后面接手的人会疯掉。你写它它写它的混在一起堪称灾难。这个问题的解法也很简单在项目规则里贴一段你自己写的风格示例代码让AI输出时“参考这段代码的风格保持一致”效果好很多。4.4 一套可以落地的AI编程工作流我自己现在日常跑的标准工作流是这样分享给各位参考描述需求和约束按前文那个五段式模板写清楚背景、目标、约束、非目标、交付格式。让AI先输出“你理解的需求是什么 你觉得哪些业务点需要我再确认”反复对齐后再进入代码生成。生成代码之后不直接复制粘贴。先把关键路径看一遍再把异常分支和边界处理补齐。让AI帮自己写测试用例特别是边界测试和异常场景测试这一步省力且效果好。人工审查通过后再提交到仓库。提交信息也顺手让AI写质量还挺稳定。这套流程下来我可以把一部分时间从“写代码”挪到“设计和评审”上而不是完全把产出托付给AI。它是个好工具但不是甩手掌柜。5. 代码只是思想的载体我们终于想起了自己是谁5.1 AI写得出“怎么做”但写不出“为什么”做程序员这么多年我越来越觉得代码本身只是思想和决策的一种凝固形态。让你能够日复一日坚持下去的其实是“为什么这件事值得做”的驱动力。AI并不具备这个能力。它可以解释一个功能是怎么实现的但当你问它“这个功能到底要不要做”“做出来对谁有用”“它和我们长期的产品方向有什么关系”时它就沉默了。因为这些都是关于价值和意义的问题它们依赖的是价值判断和长期思考。行业里有一种悲观的论调说程序员迟早被AI替代。我的看法目前恰恰相反被替代的是那些把“写码”当成全部、从不追问“为什么”的人。AI逼着我们去回答那个一直存在但我们总用忙碌回避的问题——我们在这份职业里到底在创造什么一旦开始回答这个问题反而会发现自己比机器更像一个创造者。5.2 回到现场品味、责任感和对系统的敬畏还有一个AI很难替代的东西是“品味”。对一段代码有些人觉得“能跑就行”有些人会坚持“可读性、可维护性、命名准确、注释克制”。这种对质量的敏感不完全来自技能更多来自长期工作里建立起来的手感和自尊。AI生成的东西平均水准是“还不错”但离“有品味”还有一段距离。有品味的人拿到AI的产出能做的是润色、优化、把它从“能用”打磨成“好用”。同样重要的还有责任感。我见过AI写的一版部署脚本看起来无懈可击但它把生产环境的连接串信息直接写进了日志。这属于技术问题吗不是这是安全意识、责任意识的问题。AI不知道一段代码在真实生产环境里意味着什么它没有经历过凌晨三点被紧急电话叫醒的感觉。它也无法理解“一行看似无害的改动可能会导致用户数据丢失”的那种战战兢兢。这份敬畏心只有经历过故障的人才有。它不写在简历上但它是行业里最值钱的东西。5.3 最后的体会不是AI让我们变成废物而是AI逼着我们变成真正的人写到这里我想把标题里那句“我们终于想起了自己是谁”再翻出来聊聊。这句话不是反讽也不是悲观我更多把它当成一个正向的提醒。过去很多年我们习惯性地以为“程序员写代码的人”把自己包装成一个能熟练把需求翻译成代码的技术体力劳动者。这种自我定义在代码不值钱的时代是可以的但在一个AI能把大部分通用代码免费生成的时代继续这样定义自己才真正危险。我想起一位老前辈说过的话工具的进步从来没有让手艺人失业它会淘汰那些只会用手艺的人然后奖励那些愿意重新思考自己价值的人。AI去写代码刚好把我们从繁琐的、重复的“搬运工作”里解放出来让我们有机会往更上游走一步——去做那个提出问题、定义边界、守护质量、承担决策责任的人。套用一句话程序里的很多难事其实都不难真正的难事都在程序之外。那些难事才是我们作为人、作为工程师、作为产品创造者存在的意义。AI可以帮助我们更快地到达那个起点但那个起点之后的旅程还是我们自己来走。