随着人工智能承担繁重的工作，开发人员必须掌握提示模型、评估模型输出的能力，以及最重要的一点：保持自身的编码技能。
编写代码一直是软件开发中最耗时、最资源密集型的任务。人工智能正在改变这一点，而且其速度远超大多数工程组织的预期。Claude Code和Cursor等工具已经在处理代码构建的重要部分，使开发人员能够将更多时间投入到需求分析、架构设计和系统设计上。
但这种转变带来了一项新挑战，很少有人充分讨论：随着AI承担了繁重工作，最重要的技能正在向“上游”迁移——如何为提示提供正确的上下文，如何评估模型生成的内容，以及如何深入理解一个问题，以至于不会被一个自信却错误的答案所迷惑。
本文探讨这三项技能，并解释为什么掌握它们的开发者将比那些没有掌握的开发者拥有显著优势。
超越编码：掌握提示的艺术
编译器和汇编器等软件翻译工具将代码的高级描述映射为适合执行的低级表示。对此类工具进行分层，带来了编码生产力的首次大幅提升。AI提示工程代表了下一代分层翻译软件，它位于编译器和汇编器之上。随着AI生成代码的普及，重点将从编写好代码转向编写好的提示。
什么是好的提示？答案是：良好的上下文。但什么能提供好的上下文？最重要的是，开发者必须充分理解软件必须执行的任务。想一想编写一个作为更大系统组成部分的典型软件模块需要什么。提示应涵盖：
预期的输入与输出，即软件的核心功能
错误和异常情况及其处理方式
性能预期
软件所依赖的现有框架及使用的编程语言
用户期望的界面
所需的存储、计算和网络资源
系统设计如何为上下文提供信息
对于新项目，该模块的上下文应从详细的系统设计中获取。系统设计本质上是软件的蓝图，通过将整体设计分解为称为模块的更小、独立的部分而创建。每个模块都负责执行软件需要交付的特定功能。在微服务实现中，领域驱动设计将业务需求分解为不同的子域，这些子域可以映射到微服务。
良好的系统设计拥有连贯的架构，提供一个操作概念，例如模块如何协同工作以满足功能需求。当被充分理解的需求与正确的架构相结合时，好的系统设计便应运而生。
通过逆向工作并将上下文构建到提示中，我们发现了开发生命周期中最重要的阶段：需求分析（软件必须做什么）以及架构与系统设计（它是如何做到的）。
图1：线性软件生命周期示例
虽然一次设计迭代可能奏效，但开发者通常需要通过迭代来获得好的结果。多年来，许多软件专家都强调过这一点，其中最著名的计算机科学家弗雷德·布鲁克斯曾说：“计划扔掉一个，无论如何你都会的。”
图2：迭代软件生命周期示例
螺旋模型和演化原型等迭代生命周期将“先扔掉一个”的理念融入流程中。扔掉东西听起来很浪费，但每次迭代都会加深对问题的理解：用户需求、架构约束、风险与机会。从每次迭代中学习，可以大幅降低最终产品的成本与复杂性。
AI工具如何影响开发者的生产力
AI翻译工具有可能提高我们的工作效率，但也带来了我们变得懒惰并依赖它们的风险。最近一项研究发现，与没有LLM辅助写作的参与者相比，LLM辅助写作降低了用户与工作相关的认知能量。这种效应被称为“认知债务”。
我和力量训练师一起训练，因为现代生活过于安逸——它不需要举重或剧烈活动。因此，我们必须主动模拟挑战来提升力量和健康。AI编码工具就像是替我们完成繁重代码生成工作的机器人。如果没有需要克服的不同挑战，我们会变得虚弱。
现代编码与AI工具
我们需要找到在使用AI工具时保持大脑努力工作的方式，这样我们才能思考软件设计及其开发工作中的难题。
编写优化的汇编代码不再被认为是任何人时间的有效利用，因为编译器在这方面非常出色。但直到最近，用Java、Go或Python为编译器或运行时编写高效代码一直是一项重要技能。事实上，即使有了LLM辅助代码生成，这些技能仍然很重要，因为开发者仍然需要审查生成的代码，并验证LLM输出是否符合某些标准。多年来编写代码的经验丰富的开发者已经具备了这些技能。新手和现有开发者都可以通过与LLM工具的互动来学习和扩展知识，这些工具让他们接触到新的技术和思想。
我们需要找到相当于编码的力量训练——直接替代部分编码工作，但保留对LLM生成代码的理解和判断力。我们该在哪些地方让大脑工作以避免认知债务？
避免认知债务的危险
首先，学习并理解从提示中生成的代码。然后重写提示来改进生成的代码，或者如果生成的代码已经足够接近你的需求，就手动重写生成的代码。LLM在统计上表现良好，因此生成的代码可能无法完全达到设计目标。LLM的“气灯效应”（gaslighting）是真实存在的：它生成的东西往往无法运行或不正确，但LLM会自信地坚称一切正常。不要轻信。始终验证。
LLM可以从相同或略有不同的提示中生成替代设计。许多开发者已经在利用这种能力来探索设计空间。确保你努力理解和修改生成的代码，这样你就能保持你的编码技能。
其次，提示工程的重点是为LLM提供上下文。因此，关键是创建优质的上下文，并理解和判断生成的代码。除了保留他们现有的语言和编码技能外，软件专业人士还应专注于其他生命周期要素，特别是需求、架构和设计，以便他们拥有高质量的提示上下文。
第三，学习新的语言和数据模型，并了解每种语言和数据模型最适合的场景。
第四，学习独立于语言的代码构建与设计实践，以便能够使用适用于多种不同语言的实践来判断生成的代码。
为了保持竞争力，你应该明白标准正在提高。从历史上看，研究表明最高效的个人开发者与最低效的开发者之间的生产力差距约为10倍，优秀团队与最弱团队之间的差距约为5倍。AI工具可能将这些差距扩大两到三倍，进一步拉大生产力鸿沟。许多这些高生产力的团队将为你的竞争对手工作。
AI将允许能够具体化需求、架构和设计的开发者和团队快速将不同的语言和数据模型应用于他们的项目。AI将通过允许在每次迭代中并行发展路径，使螺旋模型和演化原型等迭代生命周期更加高效。成功的关键在于利用AI让你专注于更高层次的设计问题，同时不失去对代码复杂性的控制。如果你不学习这些更高层次的技能，那些学习了这些技能的开发者和团队将比你更有生产力。
图3：具有并行路径和反馈回路的迭代生命周期
有些人认为，AI将大大提高软件生产力。他们设想了一个未来：软件开发人员只需编写几个提示，LLM就能生成可以取代现有SaaS产品的软件。但正如弗雷德·布鲁克斯在1986年的著名论文《没有银弹》中所说，这仍然不可能，因为仍然存在两种类型的复杂性——偶然复杂性和本质复杂性。
偶然复杂性（或称“意外”复杂性）
偶然复杂性并非问题本身所固有，而是生产过程所固有的，包括我们用于构建软件的工具、语言、硬件限制和实现细节。从历史上看，大多数生产力的提升都来自于减少偶然复杂性。AI生产力工具可以降低偶然复杂性，但开发者必须应对自己的挑战，包括幻觉和必须检测的低质量生成代码。
本质复杂性（或称“基本”复杂性）
本质复杂性是指问题本身固有的、不可避免的复杂性。它是“塑造复杂概念结构”的挑战，例如抽象的、互锁的想法、数据关系、算法和行为，这些必须准确模拟软件所要解决的真实世界问题。
由于软件固有的复杂性，AI不可能成为银弹。即使你可以将所有偶然任务的时间减少到零，本质任务仍然是你最大的挑战，并将占据你大部分精力。然而，AI是一个强大的工具。当正确用于管理复杂性和探索设计空间时，它可以显著提高团队的生产力和软件开发的质量。
