每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
在假期期间，我一直在思考：2025年AI编程工具的进展，将会在2026年如何影响软件的设计、构建与运行方式。
到目前为止，大语言模型（LLM）工具带来的最主要影响，是高质量代码的边际生产成本——无论是时间成本还是金钱成本——都显著下降了。当然，写代码只是软件工程整体工作的一部分，因此工程时间的瓶颈会自然转移到其他环节。
那么，作为软件工程师，我们到底在做什么？给出一个模糊但或许有点用的定义：构建、演进并运营分布式软件系统，从而提供明确的商业价值。在这三点中，“构建”随着LLM的出现明显变得更便宜，“演进”系统也变得更容易；而从我目前的观察来看，“运营”系统受到LLM影响最小。
至于“商业价值”，它会因公司不同、工程组织不同而变化。一个最明显的区分是基础设施团队与产品团队。我预计产品团队会从LLM编程中获得更大的提升——LLM似乎对前端理解得尤其好，而且产品团队往往有更多从零开始（greenfield）的工作，而基础设施则较少。
市场将会期待软件工程师能够真正从LLM中榨取生产力红利。整体来看，这个行业正走向更高度的机械化，但也因此变得更高效。再技能化（reskilling）与思维方式的转变已经加速了几个月，但其大多数影响仍尚未完全显现。
以下是我预计在2026年会进一步加速的一些变化：
基础设施抽象
良好的基础设施抽象，其回报会以更快的速度复利增长。你是否能快速发布二进制文件，并同样快速地回滚？你是否拥有开箱即用的方式，能够迅速为所服务的功能启动新的计算资源或后端？
所有核心基础设施组件仍然至关重要：指标、日志、事故管理、功能开关、发布系统、自动扩缩容、编排、工作流引擎、配置、缓存、网络等等。企业若能让这些核心基础设施既易于人类使用，也易于LLM使用，将会获得巨大收益。基础设施应尽可能做到自助化，提供友好的CLI或支持MCP的API，并尽量减少必须由基础设施工程师亲自介入才能解锁进展的情况，无论面对的是人类还是AI。
CI基础设施
随着AI代理编写的代码越来越多，CI基础设施的质量、保真度与速度将变得更加重要。我们或许需要重新思考“单元测试”本身，在技术栈的底层更多投入诸如性质测试（property testing）和形式化验证等方法。
人类通常不喜欢写测试——它们不好玩、机械，而且常常让人觉得是在为本可以用来写炫酷实现代码的精力缴税。但LLM对此毫无心理负担。我们已经没有任何借口不去实现几乎穷尽的测试场景覆盖。
人类引导的抽象
清晰、由人类引导的抽象将变得愈发重要。如果没有强有力的指导原则，LLM往往会用贪婪、填空式的方式生成代码，只要能通过CI检查就好，长期来看会不断制造“意大利面式”的代码结构。前期仍然需要良好的直觉与成熟的“系统品味”。模块边界、库接口、基础设施层与产品层之间的契约，这些都会成为维持长期代码质量的高杠杆因素。缺乏清晰边界的系统，将会更快地积累技术债。
LLM生成的代码并不天然等同于高质量代码。尽管过去一年中质量提升显著，但只需几个构造不佳的PR，就依然可能让团队迅速淹没在技术债之中。
人工代码评审
人工代码评审将越来越成为一个重要瓶颈，并且需要形成一种新的“评审品味”。在可能的情况下，样式层面的争议应尽量下沉到自动化lint中，在合并前运行，理想情况下甚至由LLM代理在提交前完成。人工评审应当重点关注那些之后无法轻易通过代码生成来弥补的决策：例如接口变更、涉及数据持久化的敏感代码、以及性能关键路径代码，这些仍然需要高度审慎的审查。
这也给初级工程师带来一个悖论：他们需要更早培养“评审品味”，但却在“写代码”这一传统上用于形成直觉的环节中参与得更少。
我们需要集体回答一些问题：
哪些代码即便不完美，但在风格上是可以接受的？
哪些代码是绝对不允许提交的？
哪些是新的“滑坡式”坏味道？
代码评审本身，又有多少是可以自动化的？
项目时间预期的方差上升
我预计项目时间预估的方差会显著增大。一项任务在多大程度上可以被LLM化，将越来越直接地影响其实际耗时。这会对高价值项目产生压力，推动它们被设计成更适合LLM参与的形式，但这种调整往往并不可行。
最有价值、也最需要降低风险的项目，往往恰恰是最不适合LLM辅助的：它们需要深厚的上下文理解，涉及底层系统，或者具有极高的爆炸半径。
一些过去需要长期投入的任务现在变得容易得多（例如以代码为中心的迁移，或跨语言、跨系统的转换）；而另一些任务的难度则相对稳定（例如网络相关工作）。
AI对“自建 vs 购买”决策的影响
代码成本的下降，会在多大程度上影响SaaS领域的“自建还是购买”决策？我的猜测是：在边际上会有影响，但在结构性上影响有限。对于主要是CRUD加一层薄UI的商品化SaaS，中大型技术公司在具备成熟IT能力的情况下，决策会更多倾向于自建。
但对于基础设施即服务（IaaS）或合规即服务（compliance-as-a-service），决策逻辑不会发生太大变化，因为这些系统的运营成本并未像开发成本那样大幅下降。
一些尚待回答的问题：
我们是否仍然需要对每一行代码进行人工审查？这件事到底有多关键？
哪些系统需要“放大镜级”的审查，哪些真的可以完全靠“vibe coding”？
软件工程师最好的“用更多信息对抗低质量输出（Add bits to beat slop）”方式是什么？
当模型变得快100倍、便宜1000倍时，又会发生什么变化？
一个让我豁然开朗的想法是：在每一条服务日志上运行一个LLM将变得足够便宜。现在这听起来仍然有些荒谬或多余，但可以想象它在某些场景下会非常有用，比如辅助调试事故。我已经开始看到一些很有前景的演示：针对事故排查而设计的、自动化的LLM副驾驶工具。
