软件工程这几年变得有点陌生。前不久我把一位在浏览器性能领域深耕多年的工程师的分享重新翻出来听他在里面反复强调一个判断未来十年的软件工程赢得比赛的不再是“谁的代码写得最漂亮”而是“谁能用最小的成本把正确的事做出来”。这句话我回味了很久结合自己这两年带项目、写代码、搭工具链的经历我觉得可以从他的洞察里提炼出五个关键转型写出来和大家聊聊。这篇文章不是分享会的听后感而是把其中的观点落到我自己踩过的坑、调过的系统、改过的流程上希望能给同样在一线写代码、也在为团队技术方向发愁的工程师一些参考。1. 第一个转型AI 不只是补全代码它正在重写交付流程1.1 从“帮你写”到“替你干”交互方式已经变了两年前我们聊 AI 编程讨论最多的是自动补全——写一个函数名它帮你补后面三行。那时候大家的心态是“这玩意儿就是个高级输入法”好用但谈不上改变工作方式。但现在你再去看主流 AI 编程助手的能力边界已经远远不止补全给它一个 issue 描述它能直接生成整整一个 PR给它一份接口文档它能帮你把客户端调用代码、类型定义、单元测试全部铺出来。我真正意识到“变天了”是在模拟项目 X 里。当时我们要做一批数据迁移脚本一个同事用 AI 生成了整个迁移逻辑自己只负责 review。第一眼看上去代码结构很规范注释也漂亮跑测试全绿。结果一上灰度就出问题——脚本在处理时区转换时漏掉了夏令时的情况凌晨那一个小时的数据全部错位。这件事给我的冲击很大。问题不在 AI 写得不好而在于“把问题描述清楚”这件事本身变得极其重要。以前我们花时间写代码现在花时间想清楚“这个需求的确切边界是什么异常情况怎么定义哪些数据是可信的”你把这些问题描述得越清楚AI 生成的上限就越高反过来你自己都模模糊糊AI 给你交回来的就是一份做工精致的错误答案。所以我现在对我们团队的要求变了。新来的同学第一课不是学框架而是学“如何把需求翻译成一条可执行的机器指令”。你问任何一个问题至少要能说清楚输入是什么、输出是什么、边界条件有哪些、失败了怎么处理。这套能力以前叫“需求分析”现在它变成了每一个写代码的人的基本功。1.2 新的代码评审你还在查语法它在查意图代码评审这件事也在被 AI 重塑。过去我们 review 一个 PR看的是命名规不规范、有没有明显的性能问题、逻辑有没有写反。这些低级错误现在的 AI 工具基本都能在提交前就扫出来。如果人还在 review 阶段一行行查这类东西你的价值就趋近于零。真正需要人来判断的是意图层面的问题。我给自己整理了一个评审四问分享出来供参考这段代码真的是在为用户解决问题还是在为某个“看起来正确的指标”服务这个改动的影响面是什么它会不会破坏我们没意识到的东西有没有更简单的路径可以达到同样目的还是说写复杂了三个月后的自己看到这段代码能不能快速理解当时为什么这么写举个例子。有一次我们做一个按钮点击事件的上报一个同事用 AI 生成了非常完整的埋点代码覆盖了十几个参数、五个上报时机。代码本身无可挑剔但评审时我们问了一句这些数据采集上来给谁看分析之后发现这个数据的下游消费者根本不存在整套上报体系是“为了上报而上报”。最后我们把十几个参数砍成了三个。这就是人和 AI 的差别。AI 擅长的是在给定的约束下找到最优解而人要做的是质疑这个约束本身是否正确。以后的评审重点不是挑毛病而是确认“我们做的是不是该做的事”。这个转变短期内很难适应但越早适应你作为工程师的不可替代性就越强。1.3 组织层面的冲击技能模型和团队结构要重构AI 对软件工程最深远的影响不在 IDE 里而在组织层面。传统的软件团队里角色边界很清晰产品经理定义需求架构师设计系统工程师实现功能测试保证质量。但 AI 把“实现功能”这件事的成本拉到了极低这种角色分工的假设就开始松动。我观察到的现象是能用 AI 写好代码的人往往是那些既懂业务、又懂系统的人。他们能区分“这个需求背后的真实动机”和“需求文档里写出来的表面描述”能把模糊的商业问题转化为清晰的技术约束。这种能力同时横跨了产品、架构和工程三个领域。未来团队里的核心角色我称之为“问题拥有者”——他未必是写代码最快的人但一定是最理解“为什么要做这件事”的人。团队里这样的人越强AI 的杠杆效应就越大。反过来如果团队里全是只会按指令执行的人AI 反而会放大混乱每个人拿到的上下文不同生成出来的代码拼在一起就是一场灾难。这也是为什么我不太担心“AI 会取代程序员”这种说法。AI 能取代的是“代码翻译”——把明确规格翻译成代码的过程。它短期取代不了的是“在模糊和冲突中找到正确路径”的能力。而这个能力恰恰是从前很多工程师最不愿意培养的部分。2. 第二个转型开发者体验从“锦上添花”变成“留人利器”2.1 为什么过去我们忍了那么烂的开发环境在聊开发者体验之前先讲个真实的场景。模拟项目 X 当时有个新的后端服务要接入文档写了两页纸写了要用什么版本、要配哪些环境变量、还要手动建一张表。一个刚入职的同学照着文档跑第一天环境就崩了三次。第一次是依赖版本和本机不一致第二次是配置项少了一个冒号第三次是数据库初始化脚本里有个隐藏的 SQL 错误。折腾到第三天环境终于跑起来了。但他第一周的产出基本为零。这还算是顺利的。我见过更离谱的有人在本地环境配置上花了一整个迭代最后发现只要用 Docker 重新构建就可以解决但团队里根本没人写过这个 Dockerfile。为什么会出现这种局面因为长期以来我们把“搭开发环境”这件事当成工程师的个人修为。环境起不来你自己想办法。文档不更新你自己看代码。这种态度的潜台词是开发者体验不重要重要的是你够不够“硬核”。可事实是开发环境的摩擦成本是团队产能的隐形杀手。每有一个新成员在环境搭建上多花一天团队就多承担一天的工资成本、时间成本和士气损失。更隐蔽的是工具链的摩擦会让人产生“这个团队不专业”的潜意识优秀的人才流失往往不是因为薪资而是因为“在这干活太累了”。2.2 黄金路径与内部开发者平台把正确的事变成容易的事开发者体验的核心不是做个漂亮的门户网站也不是写一堆“最佳实践”文档。它真正的逻辑只有一句把正确的事变成容易的事把错误的事变成麻烦的事。这句话听起来简单做起来需要一套系统来支撑这就是最近很火的“平台工程”概念。通俗点说平台工程不是再造一套工具而是把团队里所有公认的“标准做法”沉淀成一条修好的路。走在这条路上资源自动配好、权限自动给好、监控自动接上、部署自动执行想抄近路乱来平台会拦着你。对比一下传统方式和平台化方式在同一个场景下的差异动作传统流程平台化流程新成员启动项目阅读文档、手动装依赖、手动改配置、靠运气跑一个标准命令环境自动拉起申请测试环境找运维提工单排队等半天自助申请秒级创建用完自动释放部署上线人工检查、手工点按钮、靠检查清单流水线自动执行卡在每个质量门禁上配置密钥通过聊天工具传来传去平台提供密钥托管应用运行时自动注入监控告警出了事再翻日志平台自动接入日志、指标、告警开箱即用我在实际落地时最大的体会是平台工程最难的从来不是技术而是“共识”。你得先和团队坐下来把“什么是正确的事”定义清楚把每个环节的最低标准定下来。否则平台只是把当前的一团乱自动化了跑得越快死得越快。2.3 用四个数字判断你的开发者体验是否健康谈体验不能只谈感受得有能测量的指标。我这些年观察下来有四个数字最能反映一个团队开发者体验的真实状态第一个是“入职到首次部署”的时长。理想情况应该在三天以内超过一周说明环境搭建和文档体系有大问题。第二个是“本地环境搭建”的耗时。一个成熟的工程体系新成员应该能在半个小时内通过标准命令把环境拉起来。超过两小时就意味着有人正在用生命填补工具链的窟窿。第三个是“构建失败平均恢复时间”。构建失败不可怕可怕的是失败了没人知道为什么、找谁修。恢复时间越长说明团队对自家构建体系的理解越差也说明构建过程里的不确定性越高。第四个是“每周工具链摩擦耗时”。这个数字很主观但你可以在周会上让大家匿名估平均每周有多少时间花在处理环境问题、依赖冲突、配置不对这些事上如果人均超过半天就说明自动化程度远远不够。这四个数字不需要做一个复杂的度量系统一个简单的周报就能统计。重点不是数字多精确而是让团队意识到开发体验是可以用数据来驱动改进的不是靠“大家忍一忍”来维持的。我自己的经验是只要你开始盯这几个数字三个月内工具链的摩擦就会明显下降——因为问题一旦被看见就藏不住了。3. 第三个转型性能是一笔预算不是一个阶段3.1 性能前置的真正原因用户不会告诉你他不耐烦过去很长一段时间性能优化在团队里的地位很尴尬。项目初期没人提上线前集中“优化”一波上线后有人反馈卡顿再修一修。这种“事后消防”的模式本质上是在赌用户不会因为卡顿而离开。但真实世界的用户行为非常残酷。页面加载超过三秒用户就会开始怀疑自己是不是点错了操作没有及时反馈用户就会疯狂地重复点击然后抱怨应用“坏了”。用户不会告诉你他为什么走他只会默默关掉页面然后在评论区留下一句“真难用”。我印象很深的一次是模拟项目 X 的一个查询页。开发时大家都觉得功能好用上线后业务方反馈“会用的老用户才觉得好用新用户打开就跑了”。后来一看数据首屏加载在部分低端安卓机上要接近六秒。一个新用户连页面都没看到哪来的机会感受到产品好这就是典型的功能价值被性能拖死。所以那位工程师的分享里有一句话我特别认同性能不是功能性能是功能的载体。你的页面再好看、功能再强大如果它不能在用户耐心耗尽之前呈现出来就等于不存在。3.2 性能预算怎么定才不吵架从北极星指标倒推性能预算的最大问题是一旦你说“首屏要三秒以内”就会有人问“凭什么是三秒为什么不是两秒或者五秒”如果答不上来预算就被架空了最后变成墙上的一张纸。我的建议是预算必须从业务指标倒推出来而不是拍脑袋定一个数值。具体可以分五步走第一步定义一个关键用户旅程。不要贪多先选一个最核心的比如“从打开应用到完成一次搜索查询”。第二步采集真实的性能数据。用真实用户监控拿到这个旅程在 p50、p75、p90 下的耗时分布。实验室数据可以看趋势但定预算一定要看真实数据。第三步按设备分段。把用户分成旗舰机和低端机两群因为同一套代码在两类设备上的表现能差出三倍。只有旗舰机达标等于放弃了一大批真实用户。第四步和业务方一起设一个“转换率损失”阈值。比如 p75 耗时每多一秒转化率下降多少这个数可以通过 A/B 实验估出来。有了这个数你就不是和技术吵架而是和业务方一起对目标负责。第五步把预算写进团队的工作协议里。预算不是“希望达到”而是“不允许超过”。超过预算的改动要么优化后再上要么明确申请豁免并设置回落日期。以上任意一步看起来都有工作量但相信我比起上线一个月后再做大型性能重构这种前置约定的成本低得多。3.3 把预算变成门禁在 CI 里拦住每一次性能回退光有预算还不够预算要变成一条无人可以绕过的高压线才算生效。最隐蔽的性能问题几乎都是“慢慢变差”的今天加一个依赖多 10KB明天加一张图片多 50KB看起来都不起眼但一个季度下来首屏体积就翻倍了。这种事靠人工审查很难发现必须在流水线里自动拦截。我们的做法是在持续集成的一个环节里加了个性能门禁每次构建跑完后自动测量几个关键产物的体积和加载耗时跟预设预算做对比。超出预算就构建失败直接把问题暴露在提交阶段。这里有一个非常关键的细节不要用平均值做判断要用分位数。平均值会被“运气好的一小撮用户”拉低掩盖大量真实卡顿。我曾经见过一个接口平均耗时 300 毫秒看起来很美但 p95 要两秒多——因为有个第三方依赖在高峰期会抖动。如果一个团队的性能目标是建立在这种“平均”幻觉上的那迟早要出事。用分位数定门禁还有一个好处它天然容忍极少数异常样本避免误杀。比如 p75 超一点就报警但 p50 正常那说明问题只是影响了一部分用户你可以选择先观察而不是手忙脚乱回滚代码。这个平衡很重要门禁太松形同虚设太紧团队天天挨枪子儿最后大家就会想办法绕过它。4. 第四个转型可持续软件工程从“能跑”到“少耗”4.1 一行低效代码的碳足迹从数据中心到手机屏幕说到软件开发很少有人会把它和“碳排放”联系起来。但每一次请求背后都有一台服务器在消耗电力都会经过重重网络最终在一个用户设备上渲染出界面。软件虽然看不见摸不着它的运行却始终在消耗真实的能源。我看到过一个令人震惊的数字全球数据中心的耗电量已经占到全社会用电的几个百分点而且还在快速增长。每一张没有压缩的图片、每一段重复执行的计算、每一个不必要的网络请求都在为这个数字添一块砖。代码的低效不只是技术债问题它正在变成一个实实在在的环境议题。对于商业公司来说能耗也直接意味着成本。我记得模拟项目 X 当时有一个批量任务处理同样的数据量优化前要跑四十分钟优化后只要八分钟。不只是用户等得不那么急了服务器的占用时间也降了一大截。如果这个任务每天都跑一年下来节省的电费和机器成本相当可观。当然我不主张为“绿色”而无脑牺牲开发效率。可持续软件工程的核心是在实现同样功能的前提下消耗更少的计算资源。它和性能优化的方向高度一致只是多了一层“对环境负责”的目光。你可以把它理解为——把省电当成一个隐性需求写在每次技术评审里。4.2 绿色软件的具体姿势不是装个插件那么浪漫我在实际项目里摸索过一些具体可行的“减碳”动作整理成一张体检表每个团队都可以对着自己的系统过一遍检查项优化动作落地难度图片体积转为现代格式、去掉元数据、用响应式尺寸低接口返回裁剪冗余字段、启用压缩、增加缓存策略低定时任务检查执行频率能降频的降频低前端包体积移除无效依赖、启用按需加载中旧功能下线清理不再使用的服务和页面中数据存储冷热分层不常用的数据转到低成本存储中渲染方式高耗能视图用服务端渲染或静态化替代高这些动作没有一个需要发明新技术全是工程基本功。但真正执行下去的不多因为“省电”带来的好处不直接大家总是优先做那些能看到即时收益的事。一个常见的误区是有些人把可持续软件工程等同于“用某个绿色插件监测碳排放”。那东西作为一个宣传工具可以真拿它当工程实践的抓手很难持久。真正的践行方式是把加进系统的每一份成本计算、存储、网络都当成需要持续审视的负债。另外想多说一句可持续并不意味着牺牲体验。把图片压缩到肉眼无损的体积用户打开更快服务器压力更小碳排放也更低。这个方向的成功标准是“多赢”而不是“为了环保忍受更差的体验”。4.3 AI 与能耗的悖论效率工具本身正在吃掉效率AI 工具和可持续软件工程之间有一个不那么容易被注意到的矛盾。AI 的训练和推理都非常耗电一次大规模模型的训练其能耗可能相当于数百个家庭一年的用电量。我们享受着 AI 带来的编码提速但同时也在为算力买单——这个单不仅有金钱还有能源。更隐蔽的问题是AI 生成代码往往比人类手写代码更“啰嗦”。因为它倾向于采用通用、稳妥的实现而不是针对特定场景的最优解。如果团队不加审查地全盘接受 AI 生成的代码应用的体积可能在几个版本内悄悄膨胀。我的态度不是“拒绝 AI”而是“用 AI 的时候带着成本意识”。比如收到一段 AI 生成的实现多问一句这段逻辑有没有更轻量的写法能不能复用已有的公共能力有没有引入一个本不需要的依赖这些问题的答案决定了一个 AI 提效显著的团队最终是变得更高效了还是变成了一台吞电的机器。5. 第五个转型从“实现需求”到“拥有问题”5.1 “完成 80%”不是完成任务所有权文化到底在说什么我在评审里碰到频率最高的一句话是“这个功能我写完了但是数据有没有对、用户用不用不关我的事。”这种“任务完成度”思维是软件工程里一种隐蔽的浪费。你以为功能上线就结束了实际上用户跑不通、没人用、用不好前面的开发等于白做。所有权文化说的恰好相反一个工程师对一件事的责任从“把代码写完”延伸到“让问题被解决”。它不是让你背锅而是让你在做事的时候有完整的判断链。比如你接到一个需求“增加一个导出报表的功能”任务式思维会说“做完了接口通了按钮亮了”。所有权思维会追问更多这个报表真的有用户需要吗导出格式要 CSV 还是 Excel导出数据量如果超过一百万行怎么办导出的数据安全吗这些追问看起来是产品经理的活但只有最了解代码的实现者才能给出最靠谱的答案。我在模拟项目 X 里见过一个最典型的正面案例有个功能模块的负责人接到“在新用户注册流程里加一个推荐码”的需求。他没有直接开工而是先和运营沟通“推荐码是为了拉新还是为了奖励老用户”确认主次之后又检查了现有的用户表结构最后提交的版本几乎没怎么返工而且上线两周后他还主动跟进数据确认推荐码确实带来了预期的新增。这种做事方式看起来只是“多想了一步”但它构筑的信任感完全不同。团队里这样的人多了组织就不需要那么多层层汇报和反复确认反过来说如果大家都只管自己那一亩三分地系统一定会出现很多无人认领的灰色地带——接口没人维护、文档没人更新、告警没人理会。5.2 工程师参与决策不越位但也不能缺席所有权文化最容易走向一个极端工程师变成“指点江山的架构师”什么都想参与什么都觉得别人不行。这不是所有权这是越位。我的经验是工程师参与产品决策应该聚焦在三个问题上第一这个问题的本质是什么第二在这个问题上技术的约束点和机会点分别是什么第三有没有一种更简单的办法达到同样的目标而不是去讨论按钮放左边还是右边这种纯交互判断。有一次我们讨论一个会员体系的重构产品方提了一版非常完整的功能列表排期要三个迭代。技术评审时我们发现列表里有两项功能依赖的核心数据我们根本没有要采集到可靠的样本至少半年。如果不发声团队就会花半年去建一个注定失败的体系。后来我们把这两项明确标成“不可行除非补齐数据采集”并顺带给出了一个过渡方案产品方欣然接受。这就是工程师参与决策的价值帮团队早一点看到“此路不通”比事后返工有价值得多。要做到这一点不需要你兼任产品经理只需要你在评审时保持一种“我来对最终结果负责”的姿态。一个提问“这个需求解决了谁的什么问题”往往就能拦住一个无效功能。5.3 未来团队的最小模型懂问题的人比写代码的人更稀缺顺着所有权文化往下推未来的团队结构会越来越向“小而精”的方向演变。一个人如果能同时理解商业问题、系统设计、代码实现和数据分析AI 在TA手里的产出效率会十倍于一个只会写代码的人。我说的“最小团队”不是指永远三到五个人包打天下而是一个基本配置产品思维的人负责判断方向技术能力强的人负责把方向变成现实再加上一个懂数据的人验证结果。如果这三样能力集中在两三个人身上那就更理想了。但这不等于说专业纵深不重要了。恰恰相反未来最稀缺的是“既深且广”的人才——在某个领域钻得很深同时又愿意抬头看整个系统的运作逻辑。这种人才在 AI 普及的背景下尤其珍贵因为 AI 让他如虎添翼而不是让他可有可无。6. 把这五点放在一起我看到的那条暗线6.1 复杂性正在从代码层转移到系统层回头看这五个转型——AI 重写交付流程、开发者体验崛起、性能预算前置、可持续变成约束、所有权文化回归——它们表面上彼此独立背后其实藏着同一条暗线软件工程的复杂性正在从“代码怎么写”转移向“系统怎么运转”。过去十年我们焦虑的是语言、框架、算法够不够新未来十年真正难的是如何在充满变数的业务环境里用一套既高效又可持续的工程体系持续交付真正有价值的东西。代码本身的技术含量还在但它已经不再是最大的瓶颈。这也解释了一个现象为什么有些团队用了最好的技术栈却依然深陷泥潭因为他们把所有精力都花在了“代码层”的完美上忽视了系统层的摩擦。工具链让人抓狂、性能靠运气、需求来什么做什么、做完了没人对结果负责——这些才是拖垮团队的真凶。理解了这条暗线再看那位工程师分享里的话就不觉得是唱高调了。他说“我们不需要更多会写代码的人我们需要更多对系统负责的人。”以前我把这句话当成一种修辞现在我真的信了。6.2 对我们这些一线工程师来说具体该做什么最后这几点是我在听完分享、想完这五个转型之后给自己列的行动清单。如果你也是在软件行业工作的人可以照着试试。第一件所有人每周抽半天关掉 IDE去读自己负责模块的业务数据和用户反馈。只看代码永远发现不了“用户为什么不用”。第二件把“搭环境要多久”当成一个正经的开发任务排进迭代。不要因为它不产生用户可见的功能就无限拖延。第三件做需求之前先问三遍“为什么”。第一遍是对方口头说的第二遍是背后动机第三遍是“如果我不做这个可不可以”。第四件认真对待性能预算和能耗审视。哪怕是每周只测一次页面体积、只检查一个接口的响应分布也比上线前抱佛脚强。第五件愿意从“这个功能做完了”走向“这个问题解决了”。前者让你成为工具后者让你成为问题的拥有者。这五件事没有一件需要引入新框架或新技术但它们合在一起的复利效应会远超你重写一次架构或换一套技术栈。我个人的体会是软件工程的未来不会以某种炫酷工具的形式到来它会藏在这些更本质的工作习惯里一点一点地改变团队交付的效率和质感。 
长河君 · 2026/10/20 15:53:06 · 阅读 1.2k 软件工程未来转型：AI重写交付、开发者体验与可持续的五大关键
软件工程这几年变得有点陌生。前不久我把一位在浏览器性能领域深耕多年的工程师的分享重新翻出来听他在里面反复强调一个判断未来十年的软件工程赢得比赛的不再是“谁的代码写得最漂亮”而是“谁能用最小的成本把正确的事做出来”。这句话我回味了很久结合自己这两年带项目、写代码、搭工具链的经历我觉得可以从他的洞察里提炼出五个关键转型写出来和大家聊聊。这篇文章不是分享会的听后感而是把其中的观点落到我自己踩过的坑、调过的系统、改过的流程上希望能给同样在一线写代码、也在为团队技术方向发愁的工程师一些参考。1. 第一个转型AI 不只是补全代码它正在重写交付流程1.1 从“帮你写”到“替你干”交互方式已经变了两年前我们聊 AI 编程讨论最多的是自动补全——写一个函数名它帮你补后面三行。那时候大家的心态是“这玩意儿就是个高级输入法”好用但谈不上改变工作方式。但现在你再去看主流 AI 编程助手的能力边界已经远远不止补全给它一个 issue 描述它能直接生成整整一个 PR给它一份接口文档它能帮你把客户端调用代码、类型定义、单元测试全部铺出来。我真正意识到“变天了”是在模拟项目 X 里。当时我们要做一批数据迁移脚本一个同事用 AI 生成了整个迁移逻辑自己只负责 review。第一眼看上去代码结构很规范注释也漂亮跑测试全绿。结果一上灰度就出问题——脚本在处理时区转换时漏掉了夏令时的情况凌晨那一个小时的数据全部错位。这件事给我的冲击很大。问题不在 AI 写得不好而在于“把问题描述清楚”这件事本身变得极其重要。以前我们花时间写代码现在花时间想清楚“这个需求的确切边界是什么异常情况怎么定义哪些数据是可信的”你把这些问题描述得越清楚AI 生成的上限就越高反过来你自己都模模糊糊AI 给你交回来的就是一份做工精致的错误答案。所以我现在对我们团队的要求变了。新来的同学第一课不是学框架而是学“如何把需求翻译成一条可执行的机器指令”。你问任何一个问题至少要能说清楚输入是什么、输出是什么、边界条件有哪些、失败了怎么处理。这套能力以前叫“需求分析”现在它变成了每一个写代码的人的基本功。1.2 新的代码评审你还在查语法它在查意图代码评审这件事也在被 AI 重塑。过去我们 review 一个 PR看的是命名规不规范、有没有明显的性能问题、逻辑有没有写反。这些低级错误现在的 AI 工具基本都能在提交前就扫出来。如果人还在 review 阶段一行行查这类东西你的价值就趋近于零。真正需要人来判断的是意图层面的问题。我给自己整理了一个评审四问分享出来供参考这段代码真的是在为用户解决问题还是在为某个“看起来正确的指标”服务这个改动的影响面是什么它会不会破坏我们没意识到的东西有没有更简单的路径可以达到同样目的还是说写复杂了三个月后的自己看到这段代码能不能快速理解当时为什么这么写举个例子。有一次我们做一个按钮点击事件的上报一个同事用 AI 生成了非常完整的埋点代码覆盖了十几个参数、五个上报时机。代码本身无可挑剔但评审时我们问了一句这些数据采集上来给谁看分析之后发现这个数据的下游消费者根本不存在整套上报体系是“为了上报而上报”。最后我们把十几个参数砍成了三个。这就是人和 AI 的差别。AI 擅长的是在给定的约束下找到最优解而人要做的是质疑这个约束本身是否正确。以后的评审重点不是挑毛病而是确认“我们做的是不是该做的事”。这个转变短期内很难适应但越早适应你作为工程师的不可替代性就越强。1.3 组织层面的冲击技能模型和团队结构要重构AI 对软件工程最深远的影响不在 IDE 里而在组织层面。传统的软件团队里角色边界很清晰产品经理定义需求架构师设计系统工程师实现功能测试保证质量。但 AI 把“实现功能”这件事的成本拉到了极低这种角色分工的假设就开始松动。我观察到的现象是能用 AI 写好代码的人往往是那些既懂业务、又懂系统的人。他们能区分“这个需求背后的真实动机”和“需求文档里写出来的表面描述”能把模糊的商业问题转化为清晰的技术约束。这种能力同时横跨了产品、架构和工程三个领域。未来团队里的核心角色我称之为“问题拥有者”——他未必是写代码最快的人但一定是最理解“为什么要做这件事”的人。团队里这样的人越强AI 的杠杆效应就越大。反过来如果团队里全是只会按指令执行的人AI 反而会放大混乱每个人拿到的上下文不同生成出来的代码拼在一起就是一场灾难。这也是为什么我不太担心“AI 会取代程序员”这种说法。AI 能取代的是“代码翻译”——把明确规格翻译成代码的过程。它短期取代不了的是“在模糊和冲突中找到正确路径”的能力。而这个能力恰恰是从前很多工程师最不愿意培养的部分。2. 第二个转型开发者体验从“锦上添花”变成“留人利器”2.1 为什么过去我们忍了那么烂的开发环境在聊开发者体验之前先讲个真实的场景。模拟项目 X 当时有个新的后端服务要接入文档写了两页纸写了要用什么版本、要配哪些环境变量、还要手动建一张表。一个刚入职的同学照着文档跑第一天环境就崩了三次。第一次是依赖版本和本机不一致第二次是配置项少了一个冒号第三次是数据库初始化脚本里有个隐藏的 SQL 错误。折腾到第三天环境终于跑起来了。但他第一周的产出基本为零。这还算是顺利的。我见过更离谱的有人在本地环境配置上花了一整个迭代最后发现只要用 Docker 重新构建就可以解决但团队里根本没人写过这个 Dockerfile。为什么会出现这种局面因为长期以来我们把“搭开发环境”这件事当成工程师的个人修为。环境起不来你自己想办法。文档不更新你自己看代码。这种态度的潜台词是开发者体验不重要重要的是你够不够“硬核”。可事实是开发环境的摩擦成本是团队产能的隐形杀手。每有一个新成员在环境搭建上多花一天团队就多承担一天的工资成本、时间成本和士气损失。更隐蔽的是工具链的摩擦会让人产生“这个团队不专业”的潜意识优秀的人才流失往往不是因为薪资而是因为“在这干活太累了”。2.2 黄金路径与内部开发者平台把正确的事变成容易的事开发者体验的核心不是做个漂亮的门户网站也不是写一堆“最佳实践”文档。它真正的逻辑只有一句把正确的事变成容易的事把错误的事变成麻烦的事。这句话听起来简单做起来需要一套系统来支撑这就是最近很火的“平台工程”概念。通俗点说平台工程不是再造一套工具而是把团队里所有公认的“标准做法”沉淀成一条修好的路。走在这条路上资源自动配好、权限自动给好、监控自动接上、部署自动执行想抄近路乱来平台会拦着你。对比一下传统方式和平台化方式在同一个场景下的差异动作传统流程平台化流程新成员启动项目阅读文档、手动装依赖、手动改配置、靠运气跑一个标准命令环境自动拉起申请测试环境找运维提工单排队等半天自助申请秒级创建用完自动释放部署上线人工检查、手工点按钮、靠检查清单流水线自动执行卡在每个质量门禁上配置密钥通过聊天工具传来传去平台提供密钥托管应用运行时自动注入监控告警出了事再翻日志平台自动接入日志、指标、告警开箱即用我在实际落地时最大的体会是平台工程最难的从来不是技术而是“共识”。你得先和团队坐下来把“什么是正确的事”定义清楚把每个环节的最低标准定下来。否则平台只是把当前的一团乱自动化了跑得越快死得越快。2.3 用四个数字判断你的开发者体验是否健康谈体验不能只谈感受得有能测量的指标。我这些年观察下来有四个数字最能反映一个团队开发者体验的真实状态第一个是“入职到首次部署”的时长。理想情况应该在三天以内超过一周说明环境搭建和文档体系有大问题。第二个是“本地环境搭建”的耗时。一个成熟的工程体系新成员应该能在半个小时内通过标准命令把环境拉起来。超过两小时就意味着有人正在用生命填补工具链的窟窿。第三个是“构建失败平均恢复时间”。构建失败不可怕可怕的是失败了没人知道为什么、找谁修。恢复时间越长说明团队对自家构建体系的理解越差也说明构建过程里的不确定性越高。第四个是“每周工具链摩擦耗时”。这个数字很主观但你可以在周会上让大家匿名估平均每周有多少时间花在处理环境问题、依赖冲突、配置不对这些事上如果人均超过半天就说明自动化程度远远不够。这四个数字不需要做一个复杂的度量系统一个简单的周报就能统计。重点不是数字多精确而是让团队意识到开发体验是可以用数据来驱动改进的不是靠“大家忍一忍”来维持的。我自己的经验是只要你开始盯这几个数字三个月内工具链的摩擦就会明显下降——因为问题一旦被看见就藏不住了。3. 第三个转型性能是一笔预算不是一个阶段3.1 性能前置的真正原因用户不会告诉你他不耐烦过去很长一段时间性能优化在团队里的地位很尴尬。项目初期没人提上线前集中“优化”一波上线后有人反馈卡顿再修一修。这种“事后消防”的模式本质上是在赌用户不会因为卡顿而离开。但真实世界的用户行为非常残酷。页面加载超过三秒用户就会开始怀疑自己是不是点错了操作没有及时反馈用户就会疯狂地重复点击然后抱怨应用“坏了”。用户不会告诉你他为什么走他只会默默关掉页面然后在评论区留下一句“真难用”。我印象很深的一次是模拟项目 X 的一个查询页。开发时大家都觉得功能好用上线后业务方反馈“会用的老用户才觉得好用新用户打开就跑了”。后来一看数据首屏加载在部分低端安卓机上要接近六秒。一个新用户连页面都没看到哪来的机会感受到产品好这就是典型的功能价值被性能拖死。所以那位工程师的分享里有一句话我特别认同性能不是功能性能是功能的载体。你的页面再好看、功能再强大如果它不能在用户耐心耗尽之前呈现出来就等于不存在。3.2 性能预算怎么定才不吵架从北极星指标倒推性能预算的最大问题是一旦你说“首屏要三秒以内”就会有人问“凭什么是三秒为什么不是两秒或者五秒”如果答不上来预算就被架空了最后变成墙上的一张纸。我的建议是预算必须从业务指标倒推出来而不是拍脑袋定一个数值。具体可以分五步走第一步定义一个关键用户旅程。不要贪多先选一个最核心的比如“从打开应用到完成一次搜索查询”。第二步采集真实的性能数据。用真实用户监控拿到这个旅程在 p50、p75、p90 下的耗时分布。实验室数据可以看趋势但定预算一定要看真实数据。第三步按设备分段。把用户分成旗舰机和低端机两群因为同一套代码在两类设备上的表现能差出三倍。只有旗舰机达标等于放弃了一大批真实用户。第四步和业务方一起设一个“转换率损失”阈值。比如 p75 耗时每多一秒转化率下降多少这个数可以通过 A/B 实验估出来。有了这个数你就不是和技术吵架而是和业务方一起对目标负责。第五步把预算写进团队的工作协议里。预算不是“希望达到”而是“不允许超过”。超过预算的改动要么优化后再上要么明确申请豁免并设置回落日期。以上任意一步看起来都有工作量但相信我比起上线一个月后再做大型性能重构这种前置约定的成本低得多。3.3 把预算变成门禁在 CI 里拦住每一次性能回退光有预算还不够预算要变成一条无人可以绕过的高压线才算生效。最隐蔽的性能问题几乎都是“慢慢变差”的今天加一个依赖多 10KB明天加一张图片多 50KB看起来都不起眼但一个季度下来首屏体积就翻倍了。这种事靠人工审查很难发现必须在流水线里自动拦截。我们的做法是在持续集成的一个环节里加了个性能门禁每次构建跑完后自动测量几个关键产物的体积和加载耗时跟预设预算做对比。超出预算就构建失败直接把问题暴露在提交阶段。这里有一个非常关键的细节不要用平均值做判断要用分位数。平均值会被“运气好的一小撮用户”拉低掩盖大量真实卡顿。我曾经见过一个接口平均耗时 300 毫秒看起来很美但 p95 要两秒多——因为有个第三方依赖在高峰期会抖动。如果一个团队的性能目标是建立在这种“平均”幻觉上的那迟早要出事。用分位数定门禁还有一个好处它天然容忍极少数异常样本避免误杀。比如 p75 超一点就报警但 p50 正常那说明问题只是影响了一部分用户你可以选择先观察而不是手忙脚乱回滚代码。这个平衡很重要门禁太松形同虚设太紧团队天天挨枪子儿最后大家就会想办法绕过它。4. 第四个转型可持续软件工程从“能跑”到“少耗”4.1 一行低效代码的碳足迹从数据中心到手机屏幕说到软件开发很少有人会把它和“碳排放”联系起来。但每一次请求背后都有一台服务器在消耗电力都会经过重重网络最终在一个用户设备上渲染出界面。软件虽然看不见摸不着它的运行却始终在消耗真实的能源。我看到过一个令人震惊的数字全球数据中心的耗电量已经占到全社会用电的几个百分点而且还在快速增长。每一张没有压缩的图片、每一段重复执行的计算、每一个不必要的网络请求都在为这个数字添一块砖。代码的低效不只是技术债问题它正在变成一个实实在在的环境议题。对于商业公司来说能耗也直接意味着成本。我记得模拟项目 X 当时有一个批量任务处理同样的数据量优化前要跑四十分钟优化后只要八分钟。不只是用户等得不那么急了服务器的占用时间也降了一大截。如果这个任务每天都跑一年下来节省的电费和机器成本相当可观。当然我不主张为“绿色”而无脑牺牲开发效率。可持续软件工程的核心是在实现同样功能的前提下消耗更少的计算资源。它和性能优化的方向高度一致只是多了一层“对环境负责”的目光。你可以把它理解为——把省电当成一个隐性需求写在每次技术评审里。4.2 绿色软件的具体姿势不是装个插件那么浪漫我在实际项目里摸索过一些具体可行的“减碳”动作整理成一张体检表每个团队都可以对着自己的系统过一遍检查项优化动作落地难度图片体积转为现代格式、去掉元数据、用响应式尺寸低接口返回裁剪冗余字段、启用压缩、增加缓存策略低定时任务检查执行频率能降频的降频低前端包体积移除无效依赖、启用按需加载中旧功能下线清理不再使用的服务和页面中数据存储冷热分层不常用的数据转到低成本存储中渲染方式高耗能视图用服务端渲染或静态化替代高这些动作没有一个需要发明新技术全是工程基本功。但真正执行下去的不多因为“省电”带来的好处不直接大家总是优先做那些能看到即时收益的事。一个常见的误区是有些人把可持续软件工程等同于“用某个绿色插件监测碳排放”。那东西作为一个宣传工具可以真拿它当工程实践的抓手很难持久。真正的践行方式是把加进系统的每一份成本计算、存储、网络都当成需要持续审视的负债。另外想多说一句可持续并不意味着牺牲体验。把图片压缩到肉眼无损的体积用户打开更快服务器压力更小碳排放也更低。这个方向的成功标准是“多赢”而不是“为了环保忍受更差的体验”。4.3 AI 与能耗的悖论效率工具本身正在吃掉效率AI 工具和可持续软件工程之间有一个不那么容易被注意到的矛盾。AI 的训练和推理都非常耗电一次大规模模型的训练其能耗可能相当于数百个家庭一年的用电量。我们享受着 AI 带来的编码提速但同时也在为算力买单——这个单不仅有金钱还有能源。更隐蔽的问题是AI 生成代码往往比人类手写代码更“啰嗦”。因为它倾向于采用通用、稳妥的实现而不是针对特定场景的最优解。如果团队不加审查地全盘接受 AI 生成的代码应用的体积可能在几个版本内悄悄膨胀。我的态度不是“拒绝 AI”而是“用 AI 的时候带着成本意识”。比如收到一段 AI 生成的实现多问一句这段逻辑有没有更轻量的写法能不能复用已有的公共能力有没有引入一个本不需要的依赖这些问题的答案决定了一个 AI 提效显著的团队最终是变得更高效了还是变成了一台吞电的机器。5. 第五个转型从“实现需求”到“拥有问题”5.1 “完成 80%”不是完成任务所有权文化到底在说什么我在评审里碰到频率最高的一句话是“这个功能我写完了但是数据有没有对、用户用不用不关我的事。”这种“任务完成度”思维是软件工程里一种隐蔽的浪费。你以为功能上线就结束了实际上用户跑不通、没人用、用不好前面的开发等于白做。所有权文化说的恰好相反一个工程师对一件事的责任从“把代码写完”延伸到“让问题被解决”。它不是让你背锅而是让你在做事的时候有完整的判断链。比如你接到一个需求“增加一个导出报表的功能”任务式思维会说“做完了接口通了按钮亮了”。所有权思维会追问更多这个报表真的有用户需要吗导出格式要 CSV 还是 Excel导出数据量如果超过一百万行怎么办导出的数据安全吗这些追问看起来是产品经理的活但只有最了解代码的实现者才能给出最靠谱的答案。我在模拟项目 X 里见过一个最典型的正面案例有个功能模块的负责人接到“在新用户注册流程里加一个推荐码”的需求。他没有直接开工而是先和运营沟通“推荐码是为了拉新还是为了奖励老用户”确认主次之后又检查了现有的用户表结构最后提交的版本几乎没怎么返工而且上线两周后他还主动跟进数据确认推荐码确实带来了预期的新增。这种做事方式看起来只是“多想了一步”但它构筑的信任感完全不同。团队里这样的人多了组织就不需要那么多层层汇报和反复确认反过来说如果大家都只管自己那一亩三分地系统一定会出现很多无人认领的灰色地带——接口没人维护、文档没人更新、告警没人理会。5.2 工程师参与决策不越位但也不能缺席所有权文化最容易走向一个极端工程师变成“指点江山的架构师”什么都想参与什么都觉得别人不行。这不是所有权这是越位。我的经验是工程师参与产品决策应该聚焦在三个问题上第一这个问题的本质是什么第二在这个问题上技术的约束点和机会点分别是什么第三有没有一种更简单的办法达到同样的目标而不是去讨论按钮放左边还是右边这种纯交互判断。有一次我们讨论一个会员体系的重构产品方提了一版非常完整的功能列表排期要三个迭代。技术评审时我们发现列表里有两项功能依赖的核心数据我们根本没有要采集到可靠的样本至少半年。如果不发声团队就会花半年去建一个注定失败的体系。后来我们把这两项明确标成“不可行除非补齐数据采集”并顺带给出了一个过渡方案产品方欣然接受。这就是工程师参与决策的价值帮团队早一点看到“此路不通”比事后返工有价值得多。要做到这一点不需要你兼任产品经理只需要你在评审时保持一种“我来对最终结果负责”的姿态。一个提问“这个需求解决了谁的什么问题”往往就能拦住一个无效功能。5.3 未来团队的最小模型懂问题的人比写代码的人更稀缺顺着所有权文化往下推未来的团队结构会越来越向“小而精”的方向演变。一个人如果能同时理解商业问题、系统设计、代码实现和数据分析AI 在TA手里的产出效率会十倍于一个只会写代码的人。我说的“最小团队”不是指永远三到五个人包打天下而是一个基本配置产品思维的人负责判断方向技术能力强的人负责把方向变成现实再加上一个懂数据的人验证结果。如果这三样能力集中在两三个人身上那就更理想了。但这不等于说专业纵深不重要了。恰恰相反未来最稀缺的是“既深且广”的人才——在某个领域钻得很深同时又愿意抬头看整个系统的运作逻辑。这种人才在 AI 普及的背景下尤其珍贵因为 AI 让他如虎添翼而不是让他可有可无。6. 把这五点放在一起我看到的那条暗线6.1 复杂性正在从代码层转移到系统层回头看这五个转型——AI 重写交付流程、开发者体验崛起、性能预算前置、可持续变成约束、所有权文化回归——它们表面上彼此独立背后其实藏着同一条暗线软件工程的复杂性正在从“代码怎么写”转移向“系统怎么运转”。过去十年我们焦虑的是语言、框架、算法够不够新未来十年真正难的是如何在充满变数的业务环境里用一套既高效又可持续的工程体系持续交付真正有价值的东西。代码本身的技术含量还在但它已经不再是最大的瓶颈。这也解释了一个现象为什么有些团队用了最好的技术栈却依然深陷泥潭因为他们把所有精力都花在了“代码层”的完美上忽视了系统层的摩擦。工具链让人抓狂、性能靠运气、需求来什么做什么、做完了没人对结果负责——这些才是拖垮团队的真凶。理解了这条暗线再看那位工程师分享里的话就不觉得是唱高调了。他说“我们不需要更多会写代码的人我们需要更多对系统负责的人。”以前我把这句话当成一种修辞现在我真的信了。6.2 对我们这些一线工程师来说具体该做什么最后这几点是我在听完分享、想完这五个转型之后给自己列的行动清单。如果你也是在软件行业工作的人可以照着试试。第一件所有人每周抽半天关掉 IDE去读自己负责模块的业务数据和用户反馈。只看代码永远发现不了“用户为什么不用”。第二件把“搭环境要多久”当成一个正经的开发任务排进迭代。不要因为它不产生用户可见的功能就无限拖延。第三件做需求之前先问三遍“为什么”。第一遍是对方口头说的第二遍是背后动机第三遍是“如果我不做这个可不可以”。第四件认真对待性能预算和能耗审视。哪怕是每周只测一次页面体积、只检查一个接口的响应分布也比上线前抱佛脚强。第五件愿意从“这个功能做完了”走向“这个问题解决了”。前者让你成为工具后者让你成为问题的拥有者。这五件事没有一件需要引入新框架或新技术但它们合在一起的复利效应会远超你重写一次架构或换一套技术栈。我个人的体会是软件工程的未来不会以某种炫酷工具的形式到来它会藏在这些更本质的工作习惯里一点一点地改变团队交付的效率和质感。