如果你曾观察过别人“写代码”，可能会发现他们盯着空白处的时间远多于敲键盘的时间。不，他们（很可能）并非在偷懒。软件开发本质上是一种解决问题的实践，因此，如同破解一道棘手的填字游戏，大部分工作都是在脑海中完成的。
在软件开发生命周期中，编码如同填入填字游戏的字母，与所有绞尽脑汁和涂鸦笔记相比，只占很小一部分精力。真正的工作通常伴随编码进行——开发者需要理解业务领域、细化需求、规划相关抽象、考虑副作用、逐步测试功能，最终消灭历经严格流程仍存活的缺陷。整个过程大致如下：
但在 AI 驱动的编程模式下，情况却截然不同。
“先写代码，后提问题”
诸如 Claude Code 之类的人工智能编程助手正在以惊人的速度独立编写代码。但大多数软件都存在于复杂系统中，由于 LLMs 尚无法一次性在内存中保存应用程序的完整上下文，人工审查、测试和集成需求仍将存在。当代码未经人类思考就被编写出来时，这些工作会变得困难得多。因此对于复杂软件而言，大部分时间将花在事后理解人工智能所编写代码的含义上。
这正是营销宣传中鼓吹使用 AI 编写代码具有范式转换级速度（常被包装成“10 倍提速 ”），与实际环境中交付可用软件所获得的边际生产力提升（通常 接近 10%）之间存在差距的根本原因。
更令人沮丧的是，作为开发者，我们花费越来越多 的时间仅仅是为了修复这些神奇 胡言乱语的机器的输出。当 LLMs 以闪电般的速度完成所有有趣简单的工作时，我们却被留下来处理所有吃力不讨好的任务：测试以确保现有功能不被破坏，清理重复代码，编写文档，处理部署和基础设施等等。实际上，很少有时间真正投入到开发者真正热爱的事情上：编程。
幸运的是，解决方案就在眼前。虽然 LLMs 正在颠覆软件开发的方式，但这个问题本身其实并不新鲜。事实上，这只是一个古老问题的鲜明例证，我称之为：
技术负责人的困境
随着工程师在职业生涯中的发展，他们最终会步入技术负责人的角色。他们可能在管理团队，也可能是首席工程师 ，在不涉及人员管理的情况下推动技术交付。无论哪种情况，他们都对团队的技术交付负责。通常他们也是团队中经验最丰富的开发者：无论是在职业生涯中，在团队的专业领域内，还是两者兼而有之。
软件交付是团队协作的过程，但经验可能对个人贡献产生极不平衡的 影响 速度 。因此，当技术负责人的主要任务是最大化交付时，他们常常会在两种软件交付方式之间面临内心的冲突：
-
在团队中实现公平的任务分配，既为初级成员最大化学习与担当机会，又因效率最低成员的进度而使交付受到瓶颈制约。
-
过度呵护团队，即仅将简单或非关键性工作委派给初级成员，而将最困难的任务留给自己，因为自己是团队中最有能力快速交付的人。
遗憾的是，尽管我们将看到过度呵护对团队的长期健康发展极为有害，但它也常常是加速交付的有效方式。技术负责人的更高带宽往往通过包揽所有最艰巨的任务来实现最高效的运用：
因此，在我的职业生涯中，我屡次目睹这一模式重演。当然，这必然伴随着代价。技术负责人的经验壁垒使团队变得脆弱，增加了支持难度，并使其作为单一故障点承受着日益增长的压力。接下来的发展可想而知：当团队失去唯一真正通晓全局的核心成员后，便会陷入人员倦怠、离职频发，以及随之而来的生存危机。
通常情况下，解决方案在于找到第三条道路，避免这两种极端，在交付与团队成长之间取得平衡。我们可以将其表述为：
建立团队实践机制，使工程师能够在最小化返工、最大化高效协作、促进个人成长与学习的框架内交付可运行代码。
在担任 Datasine 首席技术官期间，我们将这一理念凝练成技术团队的简洁座右铭：
学习。交付。享受乐趣。
优秀的技术负责人会让工程师在能力极限边缘工作，通过流程与实践最大限度降低交付风险，同时帮助每位团队成员提升技能水平、知识储备和领域专长。这实际上正是卓越技术领导力的精髓所在。
实现这一目标的方式多种多样，从严格成文的框架体系 极限编程规则 ，到我们可统称为“最佳实践”的宽松原则体系：
-
代码审查
-
增量交付
-
测试驱动开发
-
结对编程
-
高质量文档
-
持续集成
因此，对于当今经验丰富的工程师而言，一个紧迫的问题是：我们如何将这些实践应用到人工智能驱动的编程世界中？
LLMs 是闪电般高效的初级工程师
到 2025 年，许多工程师将首次面临每个技术主管都熟悉的处境：监督一位才华横溢但难以预测的初级工程师。如何驾驭和控制这样的人才，使其有利于有效的团队协作，正是工程领导力的核心挑战之一。但 AI 编程助手需要不同于初级工程师的管理方式，因为它们的生产力本质和成长轨迹截然不同。
随着软件工程师经验积累，我们往往会在多个维度同步提升生产力：编写更健壮的代码、运用更优的抽象方案、减少编写和修复缺陷的时间、理解更复杂的架构、更有效地覆盖边缘情况、更早识别重复模式等。工程学是一门丰富而复杂的学科，存在诸多专业化路径，但为简化起见，我们或许可将这些维度归纳为两大主题：
-
代码质量 ：交付更复杂、更高性能、更易维护代码的能力
-
速度 ：在更短时间内开发出可运行、无缺陷代码的能力
随着时间的推移，优秀工程师将在这两个维度上持续提升。
早期的 LLMs 编写代码速度很快，但修复错误和消除幻觉所花费的时间意味着它们完成无错误代码的速度很慢。随着时间的推移，更智能的 LLMs 以及更好的上下文工程和工具使用，使得现代 AI 编程代理在”一次性”代码编写方面表现更佳。当前一代商用代理在解决某些中级工程师都会感到棘手的问题时，能够极其快速地生成可运行代码，尽管它们还无法与高级工程师的专业能力相匹敌：
因此我们可以将当前这一代 AI 编程代理视为初级工程师，尽管存在两个根本性差异：
-
LLMs 交付代码的速度比初级工程师快得多，既不受思考时间限制也不受编写时间约束；
-
LLMs 不具备真正的学习能力，只能通过更有效的 上下文工程或新基础模型的到来。
与初级工程人才的使用类似，根据你关注的是长期还是短期目标，大致有两种部署方式：
-
AI 驱动工程 ：采用最佳实践，突出人类对代码的理解，缓慢推进以确保开发的可持续性。
-
氛围编程 ：不顾风险快速实现，为交付速度牺牲理解力，最终陷入无法挽救的混乱代码困境。
正如预期的那样，在这两种方法之间做选择的长期轨迹，与在平行委派和过度呵护初级团队之间做选择遵循着极为相似的模式：
这正是氛围编程方式特别适合小型项目或一次性原型的原因：对于足够简单的应用场景，完全无需人类思考即可交付成果。通过限制项目复杂度并善用工具能力，我们能在极短时间内交付端到端可运行的软件。
但你_确实会_遇到 AI 无法单独应对的复杂性壁垒。
如今构建原型比以往任何时候都更加容易。但如果我们希望有效运用 LLMs 来加速交付真实、复杂、安全且可运行的软件，并实现远超边际效率的收益，就需要编写一套全新的工程实践手册，专门用于最大化人类工程师与 LLMs 协同工作的效能。
如何避免 AI 编程陷阱
AI 编程代理的生产力令人眩目，但缺乏对业务、代码库或发展路线的深入理解。若不加以约束，它们会乐此不疲地生成数千行代码，却完全无视设计、一致性与可维护性。此时工程师的职责，就是担任这些高效能手的技术领航员：通过建立结构、标准与流程，将原始速度转化为可持续的交付能力。
我们需要一套新的行动指南来高效交付可运行软件，不妨从历史经验中汲取智慧。将 LLMs 视为反应神速的初级工程师 ，就能借助软件开发生命周期中的最佳实践来构建可扩展的系统。
正如技术主管不仅编写代码，还为团队制定规范一样，工程师现在需要为 AI 代理制定规范。这意味着将 AI 融入生命周期的每个阶段：
规范制定 ：探索、分析并完善功能规范，以覆盖边界情况并聚焦核心需求。
文档编写 ：预先生成和审阅文档，以提供可复用的指导框架和持久依据。
模块化设计 ：搭建模块化架构以控制上下文范围，最大化代码可理解性。
测试驱动开发 ：在实施前生成全面测试用例，用以指导实现过程并预防功能回退。
编码标准 ：通过上下文工程应用内部风格与最佳实践来生成代码。
监控与内省 ：以超越人类极限的速度分析日志并提取洞察。
当我们认识到交付软件远不止编写代码，就能避开 AI 编程陷阱，转而极大提升交付可运行、可扩展软件的能力。
原文链接：
