1. 当编译器报错变成历史程序员还剩下什么前几天在技术社区刷到一个帖子标题是Ask HN: Will software still matter when AI write all our programs?。底下吵成一片有人说程序员要失业了有人说AI写的代码根本没法维护还有人翻出当年COBOL程序员被Java取代的旧账。我盯着屏幕看了很久脑子里冒出来的第一个画面不是未来而是去年帮朋友处理的一个烂摊子——他公司用某个AI编程助手生成了整套后端接口上线两周后数据库连接池被打满排查了整整三天才发现是AI在循环里反复创建连接对象而那个循环嵌套了四层每一层都看起来没问题。这件事让我意识到讨论AI会不会写程序其实是个伪命题。真正值得聊的是当代码的生产成本趋近于零软件这件事的价值锚点会漂移到哪里。我自己从2015年开始带团队做企业级系统经历过从手写SQL到ORM、从单体到微服务、从人工部署到CI/CD的每一次范式转移。每一次工具升级都会淘汰一批只会翻译需求为语法的人但也会把真正理解系统行为的人推到更关键的位置。AI写代码这件事本质上和当年IDE的自动补全、框架的代码生成器没有区别只是量级大了几个数量级。这篇文章不打算给你灌AI是工具人才是核心这种正确的废话。我想拆的是更具体的东西当LLM能在一分钟内吐出几百行可运行的代码时软件工程中哪些环节的价值被稀释了哪些环节的价值反而被放大了以及一个普通开发者现在应该把精力押注在什么地方。关键词里的software、AI、programs、operating system、LLM这些词每一个背后都对应着一层正在被重构的实践逻辑。我会结合自己踩过的坑、带团队的经验以及最近半年密集使用各种AI编程工具的实际感受把这件事聊透。如果你是在一线写代码的工程师、带技术团队的管理者或者正在犹豫要不要转行做开发的学生这篇内容应该能帮你建立一个更务实的判断框架。不吹不黑只讲我验证过的东西。2. 代码生成成本崩塌后软件的价值锚点漂移到了哪里2.1 从能跑就行到跑得对且改得动的鸿沟先讲一个我自己的实测数据。上个月我用某个主流LLM写了一个简单的用户权限校验模块输入是用Python实现基于角色的访问控制支持角色继承和资源级权限输出大概120行代码包含三个类和一个装饰器。我把代码贴进项目里单元测试跑通了接口调用也正常。整个过程不到五分钟。但如果把时间轴拉长到三个月后当产品经理要求增加一个临时权限提升的功能有效期两小时时问题就来了。AI生成的代码里权限判断逻辑散落在三个地方装饰器里有一份、基类的check_permission方法里有一份、还有一个工具函数里有一份。三份逻辑的边界条件处理不一致有的检查了角色继承链有的只检查直接角色。我当时改的时候先花了二十分钟理解AI为什么这么写——它其实是在不同抽象层级上做了防御性编程但因为没有全局视角导致逻辑重复。然后我花了四十分钟重构把权限判断收敛到一个策略类里再花二十分钟补测试。也就是说AI用五分钟生成的代码我花了八十分钟才让它变得可维护。这个比例很说明问题。代码生成的成本从小时级降到分钟级但代码理解和重构的成本几乎没有变化甚至因为AI生成的代码往往缺乏一致的架构意图理解成本还上升了。软件的价值从来不只是能运行而是在需求变化时能以可控成本修改。AI把第一部分的成本打下来了第二部分反而变得更贵。2.2 软件的本质是决策的固化而不是语法的堆砌我经常跟团队里的新人说一句话你写的每一行代码本质上都是一个决策。为什么用哈希表不用数组因为查询频率远高于插入。为什么这个接口要幂等因为客户端可能重试。为什么这个字段要加索引因为后台报表要按它排序。这些决策背后是对业务场景、数据特征、失败模式的理解。AI能帮你写出哈希表的语法但它不知道你的查询频率是多少也不知道客户端在什么情况下会重试。LLM的训练数据里包含了海量的代码模式所以它非常擅长做模式匹配——给定一个常见的需求描述它能找到最常见的实现方式。但软件工程中真正困难的部分恰恰是那些不常见的决策你的系统里有一个遗留的SOAP接口响应时间在特定条件下会飙升到十秒你的用户群体里有一批人用的是五年前的浏览器不支持某个现代API你的数据库在每月最后一天会有一波批量任务那时候写入性能会下降一半。这些约束条件不在AI的训练数据里只存在于你的监控面板、事故报告和老员工的记忆里。所以当有人说AI能写所有程序时我理解的是AI能写出所有符合常见模式的程序。但软件的价值往往体现在那些不符合常见模式的地方——那些为了适配特定约束而做出的、看起来不优雅但必要的设计。这些设计才是软件真正的护城河。2.3 一个反直觉的结论AI越强架构能力越值钱按照上面的逻辑推下去会得到一个反直觉的结论AI编程能力越强架构设计和系统思维的价值反而越高。原因很简单——当实现成本趋近于零时瓶颈会转移到决定实现什么和如何组织实现上。我拿操作系统举个例子。关键词里有operating system这其实是个很好的参照系。操作系统内核的代码量在千万行级别但真正核心的决策可能只有几百个进程调度用什么算法、内存如何分页、文件系统如何保证一致性、中断如何处理优先级。这些决策一旦定下来剩下的就是大量的实现工作。如果AI能承担大部分实现工作那么操作系统的竞争就会变成谁的架构决策更优的竞争。事实上现在已经有研究团队在用LLM辅助生成内核模块的代码但调度策略、内存模型这些核心设计仍然需要人来拍板。这个逻辑放到任何软件系统都成立。一个电商系统的核心决策是库存如何扣减、订单状态如何流转、支付失败如何补偿。这些决策的质量决定了系统能扛住多少并发、能支持多少种促销玩法、出故障时能不能快速恢复。AI可以帮你写出扣减库存的代码但它不知道你的业务是下单减库存还是支付减库存也不知道超卖一单的代价是赔十块钱还是赔一万块钱。3. LLM写代码的真实能力边界我半年实测的五个发现3.1 单文件、单函数、有明确输入输出的场景接近可用先说好消息。对于给定输入产出输出的纯逻辑函数LLM的表现已经相当可靠。我实测过几十个场景日期格式化、字符串解析、简单的数学计算、数据结构的增删改查、正则表达式生成。这些场景的共同特征是需求可以完整描述边界条件可以枚举不需要与外部系统交互。在这类任务上AI生成的代码首次通过率大概在70%到80%之间剩下的20%到30%通过补充边界条件描述或简单调试也能解决。我现在的习惯是写这类代码时先让AI生成一版然后自己过一遍边界条件。比如让AI写一个解析用户输入的金额字符串的函数它会处理123.45、1,234.56这些常见格式但可能不会处理123.、.45、1,2,3.45这些边缘情况。我通常会补一句考虑所有可能的非法输入返回None而不是抛异常这样生成的代码质量会明显提升。3.2 跨文件、跨模块、需要理解上下文的场景错误率陡增一旦任务涉及多个文件或模块AI的表现就明显下降。我试过让AI在一个已有的Django项目里增加一个导出订单CSV的接口。它生成的代码本身没问题但它不知道项目里已经有一个csv_utils.py封装了编码处理和流式写入也不知道项目的权限装饰器叫require_permission而不是permission_required。结果就是生成了一个能跑但风格不一致、重复造轮子的实现。这个问题的根源在于LLM的上下文窗口虽然越来越大但它对项目约定的理解仍然很弱。它能看到你贴给它的代码但看不到那些没有写在代码里的约定命名规范、分层规则、异常处理策略、日志格式。这些约定往往存在于团队的文化里、代码审查的评论里、以及老员工的口头传授里。AI没有这些信息所以它只能按照通用最佳实践来写而通用最佳实践往往和你的项目约定冲突。我的应对策略是在让AI写跨模块代码之前先花几分钟把相关的接口定义、工具函数、约定文档整理成一个上下文包贴给它。这个准备工作看起来麻烦但比事后重构省时间。实测下来有上下文包的情况下AI生成代码的可用率能从30%提升到60%左右。3.3 涉及并发、状态机、分布式协调的场景基本不可用这是目前LLM最明显的短板。我试过让AI写一个带超时和重试的分布式锁它生成的代码在单线程测试下没问题但仔细看会发现获取锁和设置超时不是原子操作重试时的退避策略没有考虑时钟漂移锁释放没有校验持有者。这些问题在低并发下不会暴露一旦上生产环境就是灾难。类似的还有状态机。AI能写出状态转移的代码但它很难保证所有状态都有出口、没有不可达状态、并发转移时状态一致这些性质。我见过一个AI生成的订单状态机在已支付状态下可以转移到已取消但已取消状态下没有回到已支付的路径导致退款流程走不通。这种错误在代码审查时很容易被忽略因为每个单独的状态转移看起来都合理。对于这类场景我的建议是AI可以帮你写测试用例、生成状态转移表、甚至画出状态图但核心的并发控制和状态管理逻辑必须自己写。这不是因为AI能力不够而是因为这类逻辑的正确性依赖于对全局不变量的把握而全局不变量很难用自然语言完整描述。3.4 代码审查和Bug定位AI是很好的副驾驶虽然AI写复杂代码不行但它在读代码这件事上表现不错。我经常把一段报错信息和相关代码贴给AI让它分析可能的原因。它给出的答案不一定对但往往能提供几个我没想到的排查方向。比如有一次线上出现software rendering doesnt support drawrendernode这个异常我一开始以为是GPU驱动问题AI提示我检查Chromium的启动参数里是否禁用了硬件加速结果还真是。在代码审查场景AI也能帮上忙。我让AI审查过一段同事写的数据库迁移脚本它指出了三个问题没有处理外键约束、没有考虑大表锁表风险、回滚逻辑不完整。这三个问题我其实也看出来了但AI能在几秒内给出结构化的反馈省去了我组织语言的时间。对于初级工程师的代码AI审查的覆盖率甚至比我人工审查还高因为它不会因为疲劳而漏看。3.5 一个被低估的能力把模糊需求翻译成技术方案这是我觉得AI目前最有价值、但讨论最少的能力。产品经理说用户希望能快速找到之前看过的商品这句话很模糊。AI可以帮你把它翻译成几个技术方案基于浏览历史的推荐、基于协同过滤的推荐、基于搜索关键词的缓存。每个方案的技术栈、数据需求、开发成本它都能列出来。虽然这些方案不一定都可行但它能帮你快速建立一个决策空间避免在需求讨论时陷入这个做不了的僵局。我现在的做法是在需求评审前先把模糊需求丢给AI让它生成三到五个技术方案然后我基于对系统的理解筛选和调整。这个过程能把需求评审的效率提升一倍以上因为大家讨论的不再是能不能做而是做哪个方案。4. 如果AI包揽了实现软件工程的瓶颈会卡在哪些环节4.1 需求验证从写出来到写对的鸿沟假设AI真的能写出所有代码那么软件交付的瓶颈会前移到需求验证。我经历过太多这样的项目需求文档写了五十页开发做了三个月上线后发现用户根本不用那个功能。原因不是代码写得不好而是需求本身是错的。AI能加速开发但加速不了一个错误的需求。需求验证的核心是快速试错。与其花三个月做一个完整功能不如花两周做一个最小可用版本让真实用户用起来然后根据反馈调整。AI编程工具在这个环节的价值是让两周做一个版本变得更容易。以前两周可能只够搭个架子现在两周能做出一个能跑的原型。这意味着团队可以把更多时间花在用户访谈、数据分析、A/B测试上而不是写代码上。但这里有个陷阱AI让做原型变得太容易容易导致团队跳过验证直接做完整版。我见过一个团队用AI在一天内生成了一个完整的后台管理系统然后直接部署给内部用户用结果因为权限模型没设计好导致数据泄露。原型和产品的区别不在于代码量而在于对边界条件的处理。AI能帮你快速达到能用但可靠仍然需要人来保证。4.2 系统集成软件从来不是孤岛关键词里有operating system这提醒我一个常被忽略的事实软件从来不是孤立运行的。一个Web应用要跑在操作系统上要连数据库要调第三方API要处理网络延迟和分区。这些集成点才是软件故障的高发区。我统计过自己团队过去两年的线上事故大概70%的问题出在集成点数据库连接池配置不当、第三方API超时没处理、消息队列积压、文件描述符耗尽。这些问题和业务逻辑无关和代码质量也无关纯粹是系统交互的复杂性导致的。AI能写出调用第三方API的代码但它不知道那个API在高峰期会返回503也不知道你们的网络出口在特定时段会抖动。系统集成的能力本质上是对失败模式的理解。你需要知道每个依赖在什么情况下会失败、失败后如何降级、降级后对用户体验有什么影响。这些知识来自监控数据、事故复盘和压测结果不来自代码。AI可以帮你写重试逻辑但重试几次、间隔多久、什么错误该重试什么不该这些决策需要人来定。4.3 运维与可观测性代码写完只是开始我经常跟团队说代码写完的那一刻软件的寿命才刚开始。接下来的几年里它会被部署、监控、扩容、迁移、打补丁。这些运维工作占据了软件总成本的很大一部分但在讨论AI写代码时往往被忽略。可观测性是运维的基础。你需要日志、指标、链路追踪来理解系统在做什么。AI生成的代码往往缺乏可观测性设计没有结构化日志、没有关键路径的埋点、没有业务指标的暴露。这不是AI的错而是因为可观测性需求很难在代码生成时描述清楚。你需要知道这个接口的P99延迟超过500毫秒时要告警、这个队列的积压超过一万条时要扩容这些阈值来自对业务的理解不来自代码逻辑。我现在的做法是在AI生成代码后强制要求补充三类信息关键路径的日志、核心指标的暴露、异常情况的告警规则。这个补充工作大概占代码总量的20%但它决定了系统上线后能不能快速定位问题。4.4 技术债务管理AI会加速债务积累吗这是一个我还在观察的问题。直觉上AI生成代码的速度越快技术债务积累得也越快。因为快速生成的代码往往缺乏一致性而一致性是控制技术债务的关键。但另一方面AI也能帮助识别和重构债务比如自动发现重复代码、建议抽象、生成重构方案。我目前的观察是AI对技术债务的影响取决于团队的使用方式。如果团队把AI当作代码生成器生成完就直接提交债务会快速积累。如果团队把AI当作代码助手生成后经过审查、重构、补充测试债务增长速度反而可能比纯人工开发慢因为AI能帮你发现一些人工容易忽略的问题。关键是要建立AI生成代码的审查流程。我的团队现在的做法是AI生成的代码必须经过至少一轮人工审查审查重点是架构一致性、边界条件处理、可观测性设计。审查通过后才能合并。这个流程增加了短期成本但控制了长期债务。5. 开发者该把精力押注在什么地方一份务实的技能清单5.1 系统思维理解组件如何交互比理解组件本身更重要如果你现在还在花大量时间学习某个框架的API用法我建议你调整一下重心。框架API是最容易被AI替代的知识因为它们是公开的、结构化的、有大量示例的。相反系统思维——理解缓存和数据库如何配合、消息队列如何解耦服务、负载均衡如何影响会话状态——这些知识更难被替代因为它们依赖于对具体场景的判断。我自己的学习方法是每接触一个新系统先画三张图数据流图、部署图、故障传播图。数据流图帮你理解数据从哪里来到哪里去部署图帮你理解组件之间的网络关系故障传播图帮你理解一个组件挂了会影响哪些功能。这三张图画完你对系统的理解就超过了大多数人。AI可以帮你生成代码但画不出这三张图因为它不知道你的系统长什么样。5.2 调试能力从猜到验证的思维训练调试是AI目前最不擅长的领域之一因为它需要提出假设-设计实验-验证假设的循环而AI倾向于直接给出答案。但调试恰恰是软件工程中最核心的能力之一。一个优秀的调试者能在半小时内定位的问题一个糟糕的调试者可能花三天。我训练调试能力的方法是二分法日志法。二分法是不断缩小问题范围先确认是前端还是后端再确认是哪个接口再确认是接口的哪个环节。日志法是在关键路径上打日志观察实际执行流程和预期是否一致。这两个方法看起来简单但需要大量的实践才能熟练。我建议你每次遇到Bug时先不要急着问AI自己走一遍二分法和日志法然后再对比AI的分析看看自己漏了什么。5.3 领域知识软件是手段业务才是目的我见过太多技术很强但业务理解很弱的工程师他们的职业天花板往往在高级工程师就卡住了。原因很简单软件的价值最终体现在业务结果上而不是代码质量上。一个能帮公司多赚一百万的技术方案比一个优雅但没人用的架构更有价值。领域知识的积累没有捷径就是多和业务方聊天、多看数据、多参与决策。我自己的习惯是每做一个新项目先花一周时间泡在业务团队里看他们怎么工作、用什么工具、遇到什么困难。这一周的时间投入往往能帮我省下后面几个月的返工。AI可以帮你写代码但它不理解你的业务所以领域知识是你相对于AI的独特优势。5.4 沟通与协作技术方案的落地依赖共识最后但同样重要的是沟通能力。一个技术方案再优秀如果推不动就没有价值。推动方案落地需要说服产品经理、协调后端和前端、争取运维资源、向管理层汇报进展。这些工作AI都做不了因为它没有组织中的信任关系。我见过很多技术方案失败的原因不是技术不行而是沟通不到位。比如一个团队想引入新的消息队列技术选型做了三个月但因为没有提前和运维团队沟通上线时发现运维不支持这个中间件又花了两个月重新选型。如果一开始就拉运维进来讨论这两个月完全可以省下来。6. 回到那个问题软件还会重要吗回到开头那个帖子的问题。我的答案是软件会变得更重要但写软件这件事的定义会改变。当AI能写出大部分代码时软件的价值会从实现转移到决策——决定做什么、决定怎么做、决定做到什么程度。这些决策需要系统思维、领域知识、调试能力和沟通能力而这些能力恰恰是AI目前最不擅长的。我自己的实践是把AI当作一个能力很强但缺乏上下文的初级工程师。它能快速产出代码但需要我来提供上下文、审查质量、补充设计。这个定位让我既能享受AI带来的效率提升又不会因为过度依赖而失去对系统的掌控。最后分享一个我最近在用的方法每次让AI生成代码后我会问自己三个问题——这段代码在什么情况下会失败失败后系统会怎样我如何知道它失败了这三个问题回答不上来代码就不能合并。这个方法看起来简单但帮我避免了好几次潜在的生产事故。软件会不会重要取决于你写的是不是能跑就行的代码。如果你追求的是跑得对、改得动、坏了好修那么软件永远重要而AI只是让你有更多时间去做那些真正重要的事。 AI编程时代软件工程价值锚点与开发者技能清单
1. 当编译器报错变成历史程序员还剩下什么前几天在技术社区刷到一个帖子标题是Ask HN: Will software still matter when AI write all our programs?。底下吵成一片有人说程序员要失业了有人说AI写的代码根本没法维护还有人翻出当年COBOL程序员被Java取代的旧账。我盯着屏幕看了很久脑子里冒出来的第一个画面不是未来而是去年帮朋友处理的一个烂摊子——他公司用某个AI编程助手生成了整套后端接口上线两周后数据库连接池被打满排查了整整三天才发现是AI在循环里反复创建连接对象而那个循环嵌套了四层每一层都看起来没问题。这件事让我意识到讨论AI会不会写程序其实是个伪命题。真正值得聊的是当代码的生产成本趋近于零软件这件事的价值锚点会漂移到哪里。我自己从2015年开始带团队做企业级系统经历过从手写SQL到ORM、从单体到微服务、从人工部署到CI/CD的每一次范式转移。每一次工具升级都会淘汰一批只会翻译需求为语法的人但也会把真正理解系统行为的人推到更关键的位置。AI写代码这件事本质上和当年IDE的自动补全、框架的代码生成器没有区别只是量级大了几个数量级。这篇文章不打算给你灌AI是工具人才是核心这种正确的废话。我想拆的是更具体的东西当LLM能在一分钟内吐出几百行可运行的代码时软件工程中哪些环节的价值被稀释了哪些环节的价值反而被放大了以及一个普通开发者现在应该把精力押注在什么地方。关键词里的software、AI、programs、operating system、LLM这些词每一个背后都对应着一层正在被重构的实践逻辑。我会结合自己踩过的坑、带团队的经验以及最近半年密集使用各种AI编程工具的实际感受把这件事聊透。如果你是在一线写代码的工程师、带技术团队的管理者或者正在犹豫要不要转行做开发的学生这篇内容应该能帮你建立一个更务实的判断框架。不吹不黑只讲我验证过的东西。2. 代码生成成本崩塌后软件的价值锚点漂移到了哪里2.1 从能跑就行到跑得对且改得动的鸿沟先讲一个我自己的实测数据。上个月我用某个主流LLM写了一个简单的用户权限校验模块输入是用Python实现基于角色的访问控制支持角色继承和资源级权限输出大概120行代码包含三个类和一个装饰器。我把代码贴进项目里单元测试跑通了接口调用也正常。整个过程不到五分钟。但如果把时间轴拉长到三个月后当产品经理要求增加一个临时权限提升的功能有效期两小时时问题就来了。AI生成的代码里权限判断逻辑散落在三个地方装饰器里有一份、基类的check_permission方法里有一份、还有一个工具函数里有一份。三份逻辑的边界条件处理不一致有的检查了角色继承链有的只检查直接角色。我当时改的时候先花了二十分钟理解AI为什么这么写——它其实是在不同抽象层级上做了防御性编程但因为没有全局视角导致逻辑重复。然后我花了四十分钟重构把权限判断收敛到一个策略类里再花二十分钟补测试。也就是说AI用五分钟生成的代码我花了八十分钟才让它变得可维护。这个比例很说明问题。代码生成的成本从小时级降到分钟级但代码理解和重构的成本几乎没有变化甚至因为AI生成的代码往往缺乏一致的架构意图理解成本还上升了。软件的价值从来不只是能运行而是在需求变化时能以可控成本修改。AI把第一部分的成本打下来了第二部分反而变得更贵。2.2 软件的本质是决策的固化而不是语法的堆砌我经常跟团队里的新人说一句话你写的每一行代码本质上都是一个决策。为什么用哈希表不用数组因为查询频率远高于插入。为什么这个接口要幂等因为客户端可能重试。为什么这个字段要加索引因为后台报表要按它排序。这些决策背后是对业务场景、数据特征、失败模式的理解。AI能帮你写出哈希表的语法但它不知道你的查询频率是多少也不知道客户端在什么情况下会重试。LLM的训练数据里包含了海量的代码模式所以它非常擅长做模式匹配——给定一个常见的需求描述它能找到最常见的实现方式。但软件工程中真正困难的部分恰恰是那些不常见的决策你的系统里有一个遗留的SOAP接口响应时间在特定条件下会飙升到十秒你的用户群体里有一批人用的是五年前的浏览器不支持某个现代API你的数据库在每月最后一天会有一波批量任务那时候写入性能会下降一半。这些约束条件不在AI的训练数据里只存在于你的监控面板、事故报告和老员工的记忆里。所以当有人说AI能写所有程序时我理解的是AI能写出所有符合常见模式的程序。但软件的价值往往体现在那些不符合常见模式的地方——那些为了适配特定约束而做出的、看起来不优雅但必要的设计。这些设计才是软件真正的护城河。2.3 一个反直觉的结论AI越强架构能力越值钱按照上面的逻辑推下去会得到一个反直觉的结论AI编程能力越强架构设计和系统思维的价值反而越高。原因很简单——当实现成本趋近于零时瓶颈会转移到决定实现什么和如何组织实现上。我拿操作系统举个例子。关键词里有operating system这其实是个很好的参照系。操作系统内核的代码量在千万行级别但真正核心的决策可能只有几百个进程调度用什么算法、内存如何分页、文件系统如何保证一致性、中断如何处理优先级。这些决策一旦定下来剩下的就是大量的实现工作。如果AI能承担大部分实现工作那么操作系统的竞争就会变成谁的架构决策更优的竞争。事实上现在已经有研究团队在用LLM辅助生成内核模块的代码但调度策略、内存模型这些核心设计仍然需要人来拍板。这个逻辑放到任何软件系统都成立。一个电商系统的核心决策是库存如何扣减、订单状态如何流转、支付失败如何补偿。这些决策的质量决定了系统能扛住多少并发、能支持多少种促销玩法、出故障时能不能快速恢复。AI可以帮你写出扣减库存的代码但它不知道你的业务是下单减库存还是支付减库存也不知道超卖一单的代价是赔十块钱还是赔一万块钱。3. LLM写代码的真实能力边界我半年实测的五个发现3.1 单文件、单函数、有明确输入输出的场景接近可用先说好消息。对于给定输入产出输出的纯逻辑函数LLM的表现已经相当可靠。我实测过几十个场景日期格式化、字符串解析、简单的数学计算、数据结构的增删改查、正则表达式生成。这些场景的共同特征是需求可以完整描述边界条件可以枚举不需要与外部系统交互。在这类任务上AI生成的代码首次通过率大概在70%到80%之间剩下的20%到30%通过补充边界条件描述或简单调试也能解决。我现在的习惯是写这类代码时先让AI生成一版然后自己过一遍边界条件。比如让AI写一个解析用户输入的金额字符串的函数它会处理123.45、1,234.56这些常见格式但可能不会处理123.、.45、1,2,3.45这些边缘情况。我通常会补一句考虑所有可能的非法输入返回None而不是抛异常这样生成的代码质量会明显提升。3.2 跨文件、跨模块、需要理解上下文的场景错误率陡增一旦任务涉及多个文件或模块AI的表现就明显下降。我试过让AI在一个已有的Django项目里增加一个导出订单CSV的接口。它生成的代码本身没问题但它不知道项目里已经有一个csv_utils.py封装了编码处理和流式写入也不知道项目的权限装饰器叫require_permission而不是permission_required。结果就是生成了一个能跑但风格不一致、重复造轮子的实现。这个问题的根源在于LLM的上下文窗口虽然越来越大但它对项目约定的理解仍然很弱。它能看到你贴给它的代码但看不到那些没有写在代码里的约定命名规范、分层规则、异常处理策略、日志格式。这些约定往往存在于团队的文化里、代码审查的评论里、以及老员工的口头传授里。AI没有这些信息所以它只能按照通用最佳实践来写而通用最佳实践往往和你的项目约定冲突。我的应对策略是在让AI写跨模块代码之前先花几分钟把相关的接口定义、工具函数、约定文档整理成一个上下文包贴给它。这个准备工作看起来麻烦但比事后重构省时间。实测下来有上下文包的情况下AI生成代码的可用率能从30%提升到60%左右。3.3 涉及并发、状态机、分布式协调的场景基本不可用这是目前LLM最明显的短板。我试过让AI写一个带超时和重试的分布式锁它生成的代码在单线程测试下没问题但仔细看会发现获取锁和设置超时不是原子操作重试时的退避策略没有考虑时钟漂移锁释放没有校验持有者。这些问题在低并发下不会暴露一旦上生产环境就是灾难。类似的还有状态机。AI能写出状态转移的代码但它很难保证所有状态都有出口、没有不可达状态、并发转移时状态一致这些性质。我见过一个AI生成的订单状态机在已支付状态下可以转移到已取消但已取消状态下没有回到已支付的路径导致退款流程走不通。这种错误在代码审查时很容易被忽略因为每个单独的状态转移看起来都合理。对于这类场景我的建议是AI可以帮你写测试用例、生成状态转移表、甚至画出状态图但核心的并发控制和状态管理逻辑必须自己写。这不是因为AI能力不够而是因为这类逻辑的正确性依赖于对全局不变量的把握而全局不变量很难用自然语言完整描述。3.4 代码审查和Bug定位AI是很好的副驾驶虽然AI写复杂代码不行但它在读代码这件事上表现不错。我经常把一段报错信息和相关代码贴给AI让它分析可能的原因。它给出的答案不一定对但往往能提供几个我没想到的排查方向。比如有一次线上出现software rendering doesnt support drawrendernode这个异常我一开始以为是GPU驱动问题AI提示我检查Chromium的启动参数里是否禁用了硬件加速结果还真是。在代码审查场景AI也能帮上忙。我让AI审查过一段同事写的数据库迁移脚本它指出了三个问题没有处理外键约束、没有考虑大表锁表风险、回滚逻辑不完整。这三个问题我其实也看出来了但AI能在几秒内给出结构化的反馈省去了我组织语言的时间。对于初级工程师的代码AI审查的覆盖率甚至比我人工审查还高因为它不会因为疲劳而漏看。3.5 一个被低估的能力把模糊需求翻译成技术方案这是我觉得AI目前最有价值、但讨论最少的能力。产品经理说用户希望能快速找到之前看过的商品这句话很模糊。AI可以帮你把它翻译成几个技术方案基于浏览历史的推荐、基于协同过滤的推荐、基于搜索关键词的缓存。每个方案的技术栈、数据需求、开发成本它都能列出来。虽然这些方案不一定都可行但它能帮你快速建立一个决策空间避免在需求讨论时陷入这个做不了的僵局。我现在的做法是在需求评审前先把模糊需求丢给AI让它生成三到五个技术方案然后我基于对系统的理解筛选和调整。这个过程能把需求评审的效率提升一倍以上因为大家讨论的不再是能不能做而是做哪个方案。4. 如果AI包揽了实现软件工程的瓶颈会卡在哪些环节4.1 需求验证从写出来到写对的鸿沟假设AI真的能写出所有代码那么软件交付的瓶颈会前移到需求验证。我经历过太多这样的项目需求文档写了五十页开发做了三个月上线后发现用户根本不用那个功能。原因不是代码写得不好而是需求本身是错的。AI能加速开发但加速不了一个错误的需求。需求验证的核心是快速试错。与其花三个月做一个完整功能不如花两周做一个最小可用版本让真实用户用起来然后根据反馈调整。AI编程工具在这个环节的价值是让两周做一个版本变得更容易。以前两周可能只够搭个架子现在两周能做出一个能跑的原型。这意味着团队可以把更多时间花在用户访谈、数据分析、A/B测试上而不是写代码上。但这里有个陷阱AI让做原型变得太容易容易导致团队跳过验证直接做完整版。我见过一个团队用AI在一天内生成了一个完整的后台管理系统然后直接部署给内部用户用结果因为权限模型没设计好导致数据泄露。原型和产品的区别不在于代码量而在于对边界条件的处理。AI能帮你快速达到能用但可靠仍然需要人来保证。4.2 系统集成软件从来不是孤岛关键词里有operating system这提醒我一个常被忽略的事实软件从来不是孤立运行的。一个Web应用要跑在操作系统上要连数据库要调第三方API要处理网络延迟和分区。这些集成点才是软件故障的高发区。我统计过自己团队过去两年的线上事故大概70%的问题出在集成点数据库连接池配置不当、第三方API超时没处理、消息队列积压、文件描述符耗尽。这些问题和业务逻辑无关和代码质量也无关纯粹是系统交互的复杂性导致的。AI能写出调用第三方API的代码但它不知道那个API在高峰期会返回503也不知道你们的网络出口在特定时段会抖动。系统集成的能力本质上是对失败模式的理解。你需要知道每个依赖在什么情况下会失败、失败后如何降级、降级后对用户体验有什么影响。这些知识来自监控数据、事故复盘和压测结果不来自代码。AI可以帮你写重试逻辑但重试几次、间隔多久、什么错误该重试什么不该这些决策需要人来定。4.3 运维与可观测性代码写完只是开始我经常跟团队说代码写完的那一刻软件的寿命才刚开始。接下来的几年里它会被部署、监控、扩容、迁移、打补丁。这些运维工作占据了软件总成本的很大一部分但在讨论AI写代码时往往被忽略。可观测性是运维的基础。你需要日志、指标、链路追踪来理解系统在做什么。AI生成的代码往往缺乏可观测性设计没有结构化日志、没有关键路径的埋点、没有业务指标的暴露。这不是AI的错而是因为可观测性需求很难在代码生成时描述清楚。你需要知道这个接口的P99延迟超过500毫秒时要告警、这个队列的积压超过一万条时要扩容这些阈值来自对业务的理解不来自代码逻辑。我现在的做法是在AI生成代码后强制要求补充三类信息关键路径的日志、核心指标的暴露、异常情况的告警规则。这个补充工作大概占代码总量的20%但它决定了系统上线后能不能快速定位问题。4.4 技术债务管理AI会加速债务积累吗这是一个我还在观察的问题。直觉上AI生成代码的速度越快技术债务积累得也越快。因为快速生成的代码往往缺乏一致性而一致性是控制技术债务的关键。但另一方面AI也能帮助识别和重构债务比如自动发现重复代码、建议抽象、生成重构方案。我目前的观察是AI对技术债务的影响取决于团队的使用方式。如果团队把AI当作代码生成器生成完就直接提交债务会快速积累。如果团队把AI当作代码助手生成后经过审查、重构、补充测试债务增长速度反而可能比纯人工开发慢因为AI能帮你发现一些人工容易忽略的问题。关键是要建立AI生成代码的审查流程。我的团队现在的做法是AI生成的代码必须经过至少一轮人工审查审查重点是架构一致性、边界条件处理、可观测性设计。审查通过后才能合并。这个流程增加了短期成本但控制了长期债务。5. 开发者该把精力押注在什么地方一份务实的技能清单5.1 系统思维理解组件如何交互比理解组件本身更重要如果你现在还在花大量时间学习某个框架的API用法我建议你调整一下重心。框架API是最容易被AI替代的知识因为它们是公开的、结构化的、有大量示例的。相反系统思维——理解缓存和数据库如何配合、消息队列如何解耦服务、负载均衡如何影响会话状态——这些知识更难被替代因为它们依赖于对具体场景的判断。我自己的学习方法是每接触一个新系统先画三张图数据流图、部署图、故障传播图。数据流图帮你理解数据从哪里来到哪里去部署图帮你理解组件之间的网络关系故障传播图帮你理解一个组件挂了会影响哪些功能。这三张图画完你对系统的理解就超过了大多数人。AI可以帮你生成代码但画不出这三张图因为它不知道你的系统长什么样。5.2 调试能力从猜到验证的思维训练调试是AI目前最不擅长的领域之一因为它需要提出假设-设计实验-验证假设的循环而AI倾向于直接给出答案。但调试恰恰是软件工程中最核心的能力之一。一个优秀的调试者能在半小时内定位的问题一个糟糕的调试者可能花三天。我训练调试能力的方法是二分法日志法。二分法是不断缩小问题范围先确认是前端还是后端再确认是哪个接口再确认是接口的哪个环节。日志法是在关键路径上打日志观察实际执行流程和预期是否一致。这两个方法看起来简单但需要大量的实践才能熟练。我建议你每次遇到Bug时先不要急着问AI自己走一遍二分法和日志法然后再对比AI的分析看看自己漏了什么。5.3 领域知识软件是手段业务才是目的我见过太多技术很强但业务理解很弱的工程师他们的职业天花板往往在高级工程师就卡住了。原因很简单软件的价值最终体现在业务结果上而不是代码质量上。一个能帮公司多赚一百万的技术方案比一个优雅但没人用的架构更有价值。领域知识的积累没有捷径就是多和业务方聊天、多看数据、多参与决策。我自己的习惯是每做一个新项目先花一周时间泡在业务团队里看他们怎么工作、用什么工具、遇到什么困难。这一周的时间投入往往能帮我省下后面几个月的返工。AI可以帮你写代码但它不理解你的业务所以领域知识是你相对于AI的独特优势。5.4 沟通与协作技术方案的落地依赖共识最后但同样重要的是沟通能力。一个技术方案再优秀如果推不动就没有价值。推动方案落地需要说服产品经理、协调后端和前端、争取运维资源、向管理层汇报进展。这些工作AI都做不了因为它没有组织中的信任关系。我见过很多技术方案失败的原因不是技术不行而是沟通不到位。比如一个团队想引入新的消息队列技术选型做了三个月但因为没有提前和运维团队沟通上线时发现运维不支持这个中间件又花了两个月重新选型。如果一开始就拉运维进来讨论这两个月完全可以省下来。6. 回到那个问题软件还会重要吗回到开头那个帖子的问题。我的答案是软件会变得更重要但写软件这件事的定义会改变。当AI能写出大部分代码时软件的价值会从实现转移到决策——决定做什么、决定怎么做、决定做到什么程度。这些决策需要系统思维、领域知识、调试能力和沟通能力而这些能力恰恰是AI目前最不擅长的。我自己的实践是把AI当作一个能力很强但缺乏上下文的初级工程师。它能快速产出代码但需要我来提供上下文、审查质量、补充设计。这个定位让我既能享受AI带来的效率提升又不会因为过度依赖而失去对系统的掌控。最后分享一个我最近在用的方法每次让AI生成代码后我会问自己三个问题——这段代码在什么情况下会失败失败后系统会怎样我如何知道它失败了这三个问题回答不上来代码就不能合并。这个方法看起来简单但帮我避免了好几次潜在的生产事故。软件会不会重要取决于你写的是不是能跑就行的代码。如果你追求的是跑得对、改得动、坏了好修那么软件永远重要而AI只是让你有更多时间去做那些真正重要的事。