Linguista

AI原生软件工程师

AI原生软件工程师 是指那些将AI深度融入日常工作流程，视其为伙伴以放大自身能力的人。

这需要一个根本性的思维转变。AI原生工程师不会想“AI可能会取代我”，而是对每项任务都问自己：“AI能帮助我更快、更好或以不同方式完成这项任务吗？”。

这种思维模式是乐观和积极主动的——你将AI视为提高生产力和创造力的倍增器，而非威胁。采用正确的方法，AI可以将你作为工程师的产出提高2倍、5倍，甚至可能10倍。经验丰富的开发者尤其会发现，他们的专业知识使他们能够以产生高水平结果的方式来提示AI；高级工程师可以通过适当的上下文工程，向AI提出正确的问题，从而获得与同行交付结果相当的答案。

成为AI原生意味着拥抱持续学习和适应——工程师从一开始就将基于AI的辅助和自动化融入软件构建中。这种思维模式会带来对可能性的兴奋而非恐惧。

是的，可能会有不确定性和学习曲线——我们许多人都经历过兴奋、恐惧然后又回到兴奋的情绪过山车——但最终目标是落脚于兴奋和机遇。AI原生工程师将AI视为一种委派开发中重复或耗时部分（如样板代码、文档起草或测试生成）的方式，从而解放自己，专注于更高层次的问题解决和创新。

核心原则——AI是协作者，而非替代品： AI原生工程师将AI视为一个知识渊博但经验尚浅的结对编程伙伴，并且全天候可用。

你仍然主导开发过程，但会不断利用AI获取想法、解决方案，甚至是警告。例如，你可能会使用AI助手来集思广益架构方案，然后凭借自己的专业知识来完善这些想法。这种协作可以显著加快开发速度，同时提高质量——如果你能保持监督。

重要的是，你不能将责任完全推给AI。把它想象成与一个阅读过所有StackOverflow帖子和API文档的初级开发者合作：他们拥有大量信息，可以快速生成代码，但你负责指导他们并验证其输出。这种“信任但验证”的思维模式至关重要，我们稍后会再次讨论。

坦率地说：AI 生成的劣质内容是真实存在的，这不能成为低质量工作的借口。使用这些工具的一个持续风险是草率批准的建议、微妙的幻觉和简单的懒惰相结合，这远远低于专业工程标准。这就是为什么“验证”是这个口号中不可协商的部分。作为工程师，你不仅仅是工具的使用者；你是最终的担保人。你仍然对你提交的每一行代码的质量、可读性、安全性和正确性负有全部直接责任。

核心原则——现在每个工程师都是管理者： 工程师的角色正在发生根本性变化。有了AI智能体，你更多地是协调工作，而不是亲力亲为地执行所有工作。

你仍然对提交到主分支的每一项改动负责，但你更多地关注定义和“分配”要完成的工作。在不远的将来，我们可能会越来越多地说“现在每个工程师都是管理者”。合法的工作可以指派给Jules或Codex等后台智能体，或者你可以让Claude Code/Gemini CLI/OpenCode处理分析或代码迁移项目。工程师需要有意识地塑造代码库，使其更容易与AI协作，这可以通过使用规则文件（例如GEMINI.md）、良好的READMEs和结构良好的代码来实现。这使得工程师扮演了监督者、导师和验证者的角色。AI优先的团队规模更小，能完成更多工作，并且能够缩短SDLC的步骤，从而更快地交付更高质量的产品。

高级优势： 通过将AI完全融入你的工作流程，你可以实现显著的生产力飞跃，可能更快地发布更多功能，而不会牺牲质量（当然，这需要考虑任务复杂性等细微差别）。

日常任务（从代码格式化到编写单元测试）可以在几秒钟内完成。也许更重要的是，AI可以增强你的理解：就像有一个随叫随到的专家，可以解释代码或在你专业领域之外的领域提出解决方案。结果是，AI原生工程师可以承担更雄心勃勃的项目，或者以更小的团队处理相同的工作量。从本质上讲，AI扩展了你的能力，让你在更高的抽象层次上工作。但前提是需要有效使用它——这就是正确的思维模式和实践发挥作用的地方。

示例——思维模式的实践： 想象你正在调试一个棘手的问题或评估一个新的技术栈。传统方法可能涉及大量的Google搜索或阅读文档。而AI原生方法是与支持搜索基础或深度研究的AI助手互动：描述错误或询问技术栈的优缺点，让AI提供见解甚至代码示例。

你仍然负责解释和实施，但AI会加速信息收集和可能的解决方案。一旦你习惯了，这种协作式问题解决就会成为第二天性。养成习惯，问自己：“AI如何能帮助我完成这项任务？”直到这成为一种反射。随着时间的推移，你将培养出AI擅长什么以及如何有效提示它的直觉。

总而言之，成为AI原生意味着将AI内化为你思考问题和构建软件的核心方式。这是一种与机器协作的思维模式：利用它们的优势（速度、知识、模式识别）来补充你自己的优势（创造力、判断力、上下文）。有了这个基础，我们就可以进入将AI融入日常工作的实用步骤。

如果你对AI原生工作流程完全陌生，一开始可能会感到望而生畏。关键是从小处着手，逐步建立你的AI熟练度。在本节中，我们将提供具体指导，帮助你在日常工程任务中从零开始，高效地使用AI。

以上是对我们最终可能在软件生命周期中实现AI的推测性展望。我仍然坚信需要人工参与（工程、设计、产品、用户体验等），以确保质量不会下降。

步骤1：第一个改变是什么？你通常从AI开始。

AI原生工作流程并非偶尔寻找AI可以提供帮助的任务；它通常是首先将任务交给AI模型，看看它的表现如何。一个团队指出：

典型的工作流程是首先将任务交给AI模型（通过Cursor或CLI程序）……并理解很多任务仍然是“碰运气”。

你是在研究一个领域还是一个竞争对手？从Gemini深度研究开始。发现自己陷入关于某个设计方面的无休止争论？当你的团队争论不休时，你可能已经用AI构建了三个原型来验证这个想法。Google员工已经用它来制作幻灯片、调试生产事故等等。

当你听到“但LLM会产生幻觉，聊天机器人给出糟糕的答案”时，是时候更新你的工具链了。今天任何认真使用AI编码的人都在使用智能体。幻觉可以通过适当的上下文工程和智能体反馈循环得到显著缓解和管理。思维转变是基础性的：我们所有人都应该立即成为AI优先的用户。

步骤2：准备好正确的AI工具。

要顺利集成AI，你需要在你的环境中至少设置一个编码助手。许多工程师从VS Code中的GitHub Copilot开始，它具有代码自动完成和代码生成功能。如果你使用VS Code等IDE，可以考虑安装一个AI扩展（例如，Cursor是一个专门的AI增强代码编辑器，而Cline是一个用于AI智能体的VS Code插件——稍后会详细介绍这些）。这些工具非常适合初学者，因为它们在后台运行，为你正在编辑的任何文件实时提供代码建议。在编辑器之外，你还可以在单独的窗口中探索ChatGPT、Gemini或Claude，以获取问答式的帮助。从工具开始很重要，因为它降低了使用AI的摩擦。一旦安装，每当你想到“也许AI可以帮助我完成这项任务”时，AI就近在咫尺。

步骤3：学习提示基础——具体并提供上下文。

有效使用AI是一项技能，这项技能的核心是提示工程。新用户常犯的一个错误是给AI一个过于模糊的指令，然后对结果感到失望。记住，AI不是读心术；它对你给出的提示做出反应。多一点上下文或清晰度会大有帮助。例如，如果你有一段代码，想要它的解释或单元测试，不要只说_“为这个写测试。”_ 相反，在你的提示中描述代码的预期行为和要求。比较以下两个为React登录表单组件编写测试的提示：

第二个提示更长，但它给了AI我们所需的一切。结果将更准确和有用得多，因为AI不会猜测我们的意图——我们已经明确说明了。实际上，多花一分钟澄清你的提示可以为你节省数小时的后期AI生成代码修正时间。

有效的提示是一项如此重要的技能，以至于Google发布了完整的指南（参见Google的提示指南101以获取一个很好的起点）。随着你的练习，你将对如何措辞请求有感觉。一些快速提示：明确你想要的格式（例如，“将输出返回为JSON”），在你的提示中将复杂任务分解为有序的步骤或项目符号，并尽可能提供示例。这些技术有助于AI更好地理解你的请求。

步骤4：使用AI进行代码生成和补全。

在设置好工具并掌握了如何提示后，开始将AI应用于实际的编码任务。一个好的首次用例是生成样板代码或重复性代码。例如，如果你需要一个函数来解析多种格式的日期字符串，请让AI来草拟。你可以说：“编写一个Python函数，该函数接受可能为X、Y或Z格式的日期字符串，并返回一个datetime对象。包括对无效格式的错误处理。”

AI将生成一个初步实现。不要盲目接受——阅读它并运行测试。这种实践会让你对AI何时可靠建立信任。许多开发人员惊喜地发现AI在几秒钟内生成了一个不错的解决方案，然后他们可以对其进行调整。随着时间的推移，你可以转向更重要的代码生成任务，例如搭建整个类或模块的脚手架。例如，Cursor甚至提供根据描述生成整个文件或重构代码的功能。早期，依赖AI生成_辅助代码_——你理解但需要时间编写的东西——而不是核心的、关键的算法逻辑。这样，你可以在低风险任务上建立对AI能力的信心。

步骤5：将AI集成到非编码任务中。

AI原生不仅仅是更快地编写代码；它关乎改进你工作的方方面面。一个很好的起点是使用AI进行围绕编码的写作或分析任务。例如，尝试使用AI在你进行代码更改后编写提交信息或拉取请求描述。你可以粘贴一个git diff并询问：“用专业的PR描述总结这些更改。”AI会起草一些你可以润色的内容。

这是休闲用户和真正的AI原生工程师之间的关键区别。最优秀的工程师一直都知道，他们的主要价值不仅仅在于敲代码，还在于围绕代码的思考、规划、研究和沟通。 将AI应用于这些领域——加速研究、澄清文档或构建项目计划——是一个巨大的倍增器。将AI视为整个工程流程的助手，而不仅仅是编码部分，对于充分发挥其在速度和创新方面的潜力至关重要。

沿着这些思路，使用AI来记录代码：让它根据你的代码库生成文档字符串，甚至整个技术文档部分。另一个想法是使用AI进行规划——如果你不确定如何实现某个功能，描述需求并让AI概述一个可能的方案。这可以为你提供一个起始蓝图，然后你可以进行调整。不要忘记日常沟通：许多工程师使用AI来起草电子邮件或Slack消息，特别是在传达复杂想法时。

例如，如果你需要向产品经理解释某个bug为何棘手，你可以让AI帮助清晰地阐述解释。这听起来微不足道，但它确实能提高生产力，并有助于确保你有效沟通。记住，“并非所有事情都与代码有关”——AI也可以协助会议、头脑风暴和表达想法。AI原生工程师会利用这些机会。

步骤6：通过反馈迭代和改进。

当你开始日常使用AI时，将其视为你自己的学习过程。注意AI输出需要修正的地方，并尝试推断原因。是提示不完整？AI是否假设了错误的上下文？利用这些反馈在下次创建更好的提示。大多数AI编码助手都允许迭代过程：你可以说“哎呀，那个函数没有正确处理空输入，请修复一下”，AI会完善它的答案。利用这种交互性——通过告诉AI需要更改什么来纠正AI的草稿通常比从头开始编写更快。

随着时间的推移，你将开发出一个运行良好的提示模式库。例如，你可能会发现_“像我是一个新团队成员一样解释X”_对于文档目的可以产生非常好的高层代码解释。或者，在你的提示中提供一个简短的输入和输出示例可以极大地改进AI对数据转换任务的答案。将这些发现融入你的工作流程。

步骤7：始终验证和测试AI输出。

这一点再怎么强调也不为过：永远不要假设AI是100%正确的。即使代码编译通过或者答案看起来合理，也要尽职尽责地进行检查。运行代码，编写额外的测试，或者对推理进行健全性检查。许多AI生成的解决方案表面上可以工作，但在边缘情况或有细微的bug时就会失败。

你是工程师；AI是助手。对AI编写的代码，使用你所有正常的最佳实践（代码审查、测试、静态分析），就像对待人类编写的代码一样。实际上，这意味着要预算一些时间来检查AI生成的内容。好消息是，阅读和理解代码通常比从头编写更快，所以即使经过验证，你在生产力方面仍然会领先。

随着经验的积累，你还会了解到AI弱势的任务类型——例如，许多LLM在精确算术或高度领域特定的逻辑方面表现不佳——你就会知道要格外仔细地双重检查这些部分，或者避免将AI用于这些方面。建立这种直觉可以确保，当你信任AI生成的更改足以提交或部署时，你已经降低了风险。一个有用的思维模型是将AI视为一个高效但不万能的队友：你重视它的贡献，但始终亲自进行最终审查。

步骤8：逐步扩展到更复杂的用例。

一旦你习惯了AI处理小任务，你就可以探索更高级的集成。例如，从被动使用AI（在你想到时寻求帮助）转变为主动使用：让AI在你编码时进行监控。像Cursor或Windsurf这样的工具可以在智能体模式下运行，它们会监视错误或TODO注释并自动提出修复建议。或者你也可以尝试像Cline提供的自主智能体模式，其中AI可以规划多步骤任务（创建文件、在其中编写代码、运行测试等），并在每一步获得你的批准。

这些高级用法可以释放更大的生产力，但它们也需要更高的警惕性（想象一下给一个初级开发者更大的自主权——你仍然需要定期检查）。

一个强大的中间步骤是使用AI进行端到端原型设计。例如，挑战自己在周末主要借助AI辅助来构建一个简单的应用程序：描述你想要的应用程序，看看Replit的AI或Bolt能帮你做到多远，然后用你的技能来填补空白。这种练习对于理解AI当前的局限性以及学习如何更好地指导它非常有帮助。而且这很有趣——当你几个小时内就拥有一个可能需要几天甚至几周手动编码才能完成的工作原型时，你会感觉自己拥有了超能力。

通过遵循这些步骤并逐步提升，你将从AI新手转变为一个能够本能地将AI融入其开发工作流程的人。下一节将更深入地探讨可用的工具和平台——了解针对不同任务使用何种工具是利用AI提高生产力的重要组成部分。

现在成为工程师令人兴奋的原因之一是，AI驱动的工具种类繁多。作为一名AI原生软件工程师，你的技能之一就是知道针对不同任务如何利用哪些工具。在本节中，我们将考察AI编码工具和平台的现状，并提供关于如何有效选择和使用它们的指导。我们将它们大致分为两类——AI编码助手（它们集成到你的开发环境中，帮助你编写代码）和AI驱动的原型设计工具（它们可以根据提示生成整个项目脚手架或应用程序）。两者都很有价值，但它们服务于不同的需求。

在深入探讨具体工具之前，任何专业人士都必须将“数据隐私防火墙”作为其核心思维模式的一部分。始终问自己：“我是否愿意将此提示及其上下文记录在第三方服务器上？”这种自律是负责任地使用这些工具的基础。AI原生工程师学会区分适合公共云AI的任务和需要企业级、注重隐私甚至自托管的本地模型的任务。

这些工具就像与你的编辑器或IDE集成的“AI结对编程伙伴”。当你处理现有代码库或以传统方式（逐文件编写代码）构建项目时，它们非常宝贵。以下是一些值得注意的例子及其细微差别：

当你迭代构建或维护代码库时，使用AI编码助手——这些工具自然地融入你的编辑-编译-测试循环。它们是编写新函数（只需输入函数签名，它们通常会自动补全函数体）、重构（“重构此函数以提高可读性”）或理解不熟悉的代码（“解释这段代码”——你会得到一个简洁的总结）等任务的理想选择。它们并非旨在一次性构建整个应用程序；相反，它们增强了你的日常工作流程。对于经验丰富的工程师来说，调用AI助手会成为第二天性——就像一个按需搜索引擎——每天使用数十次，以获得快速帮助或见解。

在幕后，像OpenAI Codex和Google的Jules这样的现代异步编码智能体更进一步。Codex作为一个自主云智能体运行——在隔离的沙盒中处理并行任务：编写功能、修复bug、运行测试、生成完整的PR——然后呈现日志和diff以供审查。

Google的Jules由Gemini 2.5 Pro提供支持，为你的GitHub工作流程带来了异步自治：你分配一个问题（例如升级Next.js），它在VM中克隆你的仓库，规划其多文件编辑，执行它们，总结更改（包括音频摘要），并发出拉取请求——所有这些都在你继续工作时进行。这些智能体与行内自动完成不同：它们是自主协作者，在后台处理已定义的任务，并返回已完成的工作供你审查，让你专注于更高层次的挑战。

除了集成开发环境中的助手外，还有一类新的工具可以从高层提示生成整个工作应用程序或其中大部分内容。当你希望快速引导新项目或功能时，这些工具非常有用——基本上是从零开始，以最少的手动编码获得第一个版本（“v0”）。它们通常不会在没有进一步迭代的情况下生成最终的生产质量代码，但它们能创建一个出色的起点。

何时使用原型工具： 当你启动新项目或功能并希望消除初始设置的繁琐工作时，这些工具会大放异彩。例如，如果你是一名技术主管，需要一个快速的概念验证来向利益相关者展示，使用Bolt或v0来搭建基础并部署它，可以节省数天的工作量。它们对于探索想法也很有用——你可以生成应用程序的多个变体以查看不同的方法。然而，请预期需要迭代。将这些工具生成的内容视为初稿。

生成后，你可能会将代码导入你自己的IDE（也许在那里有AI助手帮助你）并进行完善。在许多情况下，最佳工作流程是混合式的：使用生成工具进行原型设计，然后使用IDE中的助手进行完善。例如，你可以使用Bolt创建应用程序的MVP，然后在Cursor中打开该项目，继续使用AI结对编程处理更精细的细节。这些方法并非相互排斥——它们相互补充。在每个阶段使用正确的工具：原型设计工具用于初始脚手架和高层布局，助手工具用于深度代码工作和集成。

另一个考虑因素是局限性和学习：通过检查这些原型工具生成的内容，你可以学习常见的模式。这几乎就像一次性阅读了十几个框架教程的输出。但也要注意它们_没有_做到的事情——通常它们不会完成应用程序的最后20-30%（比如打磨、性能调优、处理边缘业务逻辑），这些将由你来完成。

这类似于AI辅助编码中观察到的“70%问题”：AI帮你完成了大部分工作，但最后一步需要人类的洞察力。了解这一点，你可以相应地预算时间。好消息是，最初的70%（启动UI组件、设置路由、连接基本CRUD）通常是无聊的部分——如果AI完成了这些，你就可以将精力集中在有趣的部分（自定义逻辑、用户体验优化等）。但不要因此而产生虚假的安全感；始终检查生成的代码，例如安全性（它是否硬编码了API密钥？）或正确性。

工具与用例总结： 回顾和简化这些工具的差异很有帮助。简而言之：当你正在演进或维护代码库时，使用IDE助手；当你需要快速生成新的代码库或模块时，使用生成式原型工具。 如果你已经有一个大型项目，像Cursor或Cline这样插入VS Code的工具将成为你日常的盟友，帮助你智能地编写和修改代码。

如果你从零开始一个项目，Bolt或v0这样的工具可以完成大部分设置工作，这样你就无需花一天时间配置构建工具或创建样板文件。如果你的工作涉及两者（这很常见：启动新服务和维护旧服务），你很可能定期使用这两种类型。许多团队报告结合使用它们取得了成功：例如，生成一个原型来启动开发，然后使用AI增强的IDE来管理和发展代码。

最后，请注意有些人可能对AI生成的代码抱有的“非我发明”偏见。在团队内部沟通使用这些工具的情况很重要。一些传统主义者可能对非自己编写的代码持怀疑态度。克服这一点的最佳方法是展示其优势（速度，以及在你审查后，代码质量可以得到保证）并使AI使用具有协作性。例如，在PR描述中分享提示和输出（“这个控制器是使用v0.dev根据以下描述生成的……”）。这会揭开AI贡献的神秘面纱，并像对待人类生成的代码一样，邀请建设性的审查。

现在我们已经了解了工具，在下一节中，我们将放大视角，探讨如何将AI应用于整个软件开发生命周期，从设计到部署。AI的作用不仅限于编码；它还可以协助需求、测试等更多方面。

AI原生软件工程师不仅使用AI编写代码——他们将其应用于软件开发生命周期（SDLC）的每个阶段。本节将探讨AI如何在工程工作的每个阶段实际应用，使整个过程更高效和创新。我们将保持领域无关性，示例略偏向于常见的Web开发场景，但这些想法适用于软件的许多领域（从云服务到移动应用）。

任何项目的第一步是确定要构建_什么_。AI可以充当头脑风暴伙伴和需求分析师。

例如，如果你有一个高层产品想法（“我们需要一个用于X的应用程序”），你可以请AI帮助头脑风暴功能或用户故事。一个提示，比如：_“我需要设计一个个人财务追踪器的移动应用程序。它应该具备哪些功能才能提供出色的用户体验？”_可以生成一份功能列表（例如，预算、费用分类、图表、提醒），你可能最初没有考虑到。

AI可以汇总它已吸收的无数应用程序和文章中的想法。同样，你可以让AI编写初步的用户故事或用例：“列出乘车共享服务MVP的五个用户故事。”_这可以通过结构良好的故事启动你的规划，你可以对其进行完善。AI还可以帮助澄清需求：如果某个需求模糊不清，你可以问“我应该就这个需求提出哪些问题来澄清它？”_——AI会提出需要定义的关键点（例如，对于“为登录添加安全性”，AI可能会建议询问2FA、密码复杂性等）。这确保你不会在早期阶段遗漏任何东西。

另一个构思用途：竞品分析。你可以提示：_“任务管理Web应用程序的常见功能和陷阱是什么？提供一份摘要。”_AI会列出此类应用程序通常会做什么以及常见的抱怨或挑战（例如，数据同步、离线支持）。这些信息可以塑造你的需求，以包含最佳功能或避免已知问题。本质上，AI可以充当研究助手，扫描集体知识库，这样你就无需手动阅读10篇博客文章。

当然，所有AI输出都需要批判性评估——运用你的判断力过滤掉在特定上下文中合理的建议。但在早期阶段，想法的数量可能比质量更有用，因为它为你提供了与团队或利益相关者讨论的选项。具有AI原生思维的工程师通常会在参加规划会议时带上一份AI生成的想法列表，然后用自己的见解来补充。这加速了讨论并显示了主动性。

AI还可以帮助非技术利益相关者在此阶段。如果你是一名技术负责人，与（比如）一名业务分析师合作，你可能会在AI的帮助下生成一份产品需求文档（PRD）草稿，然后分享供审查。编辑草稿比从头编写更快。Google的提示指南甚至为这种情况提供了特定角色的提示——例如，_“作为一名业务分析师，概述薪资系统升级的需求。”_结果会给每个人一些具体的东西来做出反应。总之，在需求和构思阶段，AI的目标是广泛撒网，组织思想，从而提供一个强大的起始基础。

一旦需求到位，下一步就是系统设计。在这里，AI可以充当架构的参考对象。例如，你可以描述你正在考虑的高层架构——“我们计划使用一个微服务作为用户服务、一个API网关和一个React前端”——然后询问AI的意见：“这种方法有什么优缺点？是否存在潜在的可伸缩性问题？” 一个精通技术的AI会列出一些点，可能类似于经验丰富的同事会说的话（例如，微服务允许独立部署但增加了开发运维的复杂性等）。这对于验证你的想法或发现你遗漏的角度很有用。

AI还可以帮助解决具体的、设计问题：“我们应该为这个特性存储选择SQL还是NoSQL？”或“聊天应用中实时通知的健壮架构是什么样的？”它将为不同的选择提供理由。虽然你不应该将它的答案奉为圭臬，但它可以揭示一些考虑因素（延迟、一致性、成本），从而指导你的决策。有时，听到推理被阐述出来有助于你向他人论证或巩固自己的理解。把它想象成向AI阐述你的架构——只是这只“橡皮鸭”会用相当合理的观点回应！

另一个用途是通过文本生成图表或映射。有些工具，如果你描述一个架构，AI可以输出一个伪图（例如，使用Mermaid markdown），你可以将其可视化。例如：“绘制一个组件图：客户端 -> 负载均衡器 -> 3个后端服务 -> 数据库。” AI可以生成一个Mermaid代码块，渲染成一个图表。这是从概念到文档的快速方式。或者你可以要求API设计建议：“为图书馆系统设计一个REST API，包含书籍、作者和借阅的端点。” AI可能会列出端点（GET /books、POST /loans等）以及示例负载，这可以是一个有用的起点，然后你再进行调整。

在此阶段，AI的一个特别强大的用途是通过询问失败情况来验证假设。例如：“我们计划在某个数据中心使用内存缓存来存储会话数据。可能出现什么问题？” AI可能会提醒你缓存崩溃、数据中心中断或伸缩性问题等场景。它有点像一个风险清单生成器。这并不能取代进行适当的设计审查，但它是早期发现明显陷阱的一个很好的补充。

另一方面，如果你在设计上遇到阻力，需要阐明你的理由，AI可以帮助你清晰地表达论点。你可以将上下文提供给AI，让它帮助阐明担忧并探索替代方案。AI会列举问题，你可以用这些来形成一个尊重、结构良好的回应。本质上，AI可以增强你围绕设计的沟通能力，这在团队环境中与设计本身同样重要。

一个更深层次的转变是，我们正在转向规范驱动的开发。这不再是代码优先；事实上，我们几乎在隐藏代码！现代软件工程师正在创建（或请求AI创建）实施计划。有些人通过要求工具首先创建一个技术设计（保存到markdown文件）和一个实施计划（同样本地保存并在稍后输入）来启动项目。

一些人指出，他们发现自己“更少思考如何编写代码，更多思考如何编写规范——将脑海中的想法转化为清晰、可重复的指令给AI。”这些设计规范具有巨大的后续价值；它们可以用于生成PRD、第一轮产品文档、部署清单、营销信息，甚至销售团队的培训材料。今天的优秀工程师善于记录意图，而这些意图反过来又催生了技术解决方案。

AI的这种战略性应用对当今高级工程师的定义产生了深远的影响。它标志着从优秀的“问题解决者”转变为具有前瞻性的“解决方案塑造者”。一位高级AI原生工程师不仅仅是更快地编写代码；他们利用AI来洞察先机——建模未来状态、分析行业趋势，并制定能够预见下一波创新的技术路线图。利用AI进行这种架构上的预见不再仅仅是锦上添花；它正迅速成为技术领导力的核心竞争力。

这是大多数人立即想到AI辅助的阶段，确实，这也是最具变革性的阶段之一。我们之前已经讨论过如何在IDE中使用编码助手，因此在这里，我们围绕典型的编码子任务进行组织：

在所有这些编码场景中，核心思想是AI加速编码的机械部分并提供即时知识，而你仍然是决策者和质量控制者。需要插入一条关于版本控制和代码审查的说明：对待AI的贡献就像对待初级开发者的拉取请求一样。勤奋使用git，比较AI所做的更改，在主要编辑后运行你的测试套件，并进行代码审查（即使你正在审查AI为你编写的代码！）。这确保了你在实现阶段的健壮性。

测试是AI可以大放异彩的领域，因为它能减少繁重的工作。我们已经提到了单元测试生成，但让我们深入探讨：

最终目标是以更少的手动工作实现更高的质量。测试通常是工程师_知道_他们应该做得更多，但时间压力常常限制了它。AI通过自动化测试的创建或至少其脚手架，帮助消除了一些摩擦。这使得你更有可能拥有一个更健壮的测试套件，从而减少回归并简化维护，带来回报。

Bug和维护任务占据了工程师大量的时间。AI也可以减少这些负担：

本质上，AI可以被视为维护过程中无处不在的助手。它可以比你更快地搜索代码（如果集成得好），回忆某个功能应该如何工作，甚至关注潜在问题。例如，如果你让AI智能体扫描你的仓库，它可能会标记出可疑模式（例如，许多地方都存在没有错误处理的API调用）。

Anthropic通过 CLAUDE.md 为AI提供你的仓库上下文的方法是实现更多此类功能的一种技术。随着时间的推移，我们可能会看到AI工具主动为某些类别的问题（安全性或风格）创建工单或拉取请求。作为AI原生工程师，你将欢迎这些帮助——它们处理繁重的工作，你处理最终的判断和创造性问题解决。

即使代码已经编写并测试完成，部署和运营软件仍然是生命周期中的重要组成部分。AI也可以在这里提供帮助：

通过将AI贯穿部署和运维，你基本上拥有了一个不仅在编码方面，还在DevOps方面的副驾驶。它减少了查找时间（我们多久会搜索特定的YAML片段或AWS CLI命令？），直接提供可用的答案。然而，请始终记住，当涉及到基础设施时，要仔细检查AI建议的任何内容——Terraform脚本中的一个小错误可能会代价高昂。如果可能，请在安全环境中进行验证。随着时间的推移，当你微调提示或使用某些经过验证的AI“配方”时，你将对哪些建议是可靠的获得信心。

正如我们所看到的，从构思到维护的整个生命周期中，都有机会注入AI辅助。

模式是：AI承担繁重的工作并提供知识，而你提供方向、监督和最终判断。

这提升了你的角色——你将更多时间花在创造性设计、批判性思维和决策上，更少时间花在样板代码和查找信息上。结果通常是更快的开发周期，如果管理得当，还会提高质量和开发人员的幸福感。在下一节中，我们将讨论一些最佳实践，以确保你有效且负责任地使用AI，以及如何持续改进你由AI增强的工作流程。

在软件开发中使用AI可以带来变革，但要真正获得好处，必须遵循最佳实践并避免常见陷阱。在本节中，我们将提炼出在工程工作流程中高效使用AI的关键原则和指南。这些实践确保AI仍然是一个强大的盟友，而不是错误或虚假自信的来源。

我们已经多次强调：有效的提示至关重要。将编写提示视为你工具箱中的一项新的核心技能——就像编写好的代码或好的提交信息一样。一个精心设计的提示，可能意味着AI答案是切中要害还是无用或误导性的分水岭。作为一项最佳实践，始终为AI提供足够的上下文。如果你在询问代码，请包含相关的代码片段或函数的目的描述。不要说：“我如何优化这个？”而要说“给定这段代码[包含代码片段]，我如何优化它以提高速度，特别是排序部分？”这有助于AI专注于你关心的问题。

还要具体说明所需的输出格式。如果你想要JSON，就说出来；如果你期望逐步解释，也要提及。例如，“逐步解释为什么这个测试失败”_或“将结果作为JSON对象返回，包含键X、Y”_。这样的指令会产生更可预测、更有用的结果。提示工程中的一个很棒的技巧是将任务分解为步骤或提供示例。你可以提示：“首先，分析输入。然后提出解决方案。最后，给出解决方案代码。”这种结构可以引导AI完成复杂的任务。Google的高级提示工程指南涵盖了诸如思维链提示和提供示例以减少猜测的方法。如果你得到一个完全偏离的答案，不要只是叹气——优化提示并再试一次。有时迭代提示（“实际上忽略之前关于X的指令，只关注Y……”）会纠正方向。

维护一个成功的提示库也很有价值。如果你发现一种提问方式始终能产生好的结果（例如，编写测试用例或解释代码的特定格式），就保存下来。随着时间的推移，你会建立一个个人“剧本”。有些工程师甚至有一个用于提示的文本片段管理器。鉴于像Google这样的公司已经发布了广泛的提示指南，你可以看到这项技能的价值正在日益增长。简而言之：投入学习如何有效地与AI对话，因为这将在输出质量方面带来丰厚回报。

无论AI的答案多么令人印象深刻，永远不要盲目信任它。这句话怎么强调都不为过。对待AI的输出，就像对待人类初级开发者的工作一样：可能有用，但需要审查和测试。无数的案例表明，由于有人在不理解AI代码的情况下接受了它，导致bug悄然潜入。养成检查AI建议更改的习惯。如果它编写了一段代码，请在脑海中或使用调试器逐步检查它。添加测试来验证它（AI可以帮助编写，正如我们讨论过的）。如果它给出了解释或分析，请交叉检查关键点。例如，如果AI说“这个API是O(N^2)，导致速度变慢”，请从官方文档或通过自己推理来验证复杂性。

尤其要警惕看起来精确的事实陈述。AI有幻觉细节的倾向——比如看起来合理但实际上不存在的函数名或语法。如果AI的答案引用了API或配置键，请在官方文档中确认。在企业环境中，永远不要信任AI提供的公司特定事实（比如“根据我们内部政策……”），除非你已经将这些事实提供给它，并且它只是在复述。

对于代码，一个好的做法是运行你所拥有的任何快速检查：代码检查工具（linters）、类型检查器、测试套件。AI代码可能不符合你的风格指南，或者可能使用了已弃用的方法。运行linter/formatter不仅能修复样式，还能捕获某些错误（例如，未使用的变量等）。一些AI工具集成了这一点——例如，AI可能会在沙盒中运行代码，如果发现异常则进行调整，但这并非万无一失。因此，作为工程师，你必须是安全网。

在安全敏感或关键系统中，要格外小心。不要使用AI生成秘密或凭据。如果AI提供了一段处理认证或加密的代码片段，请对照已知的安全实践仔细检查。曾有案例表明，AI会提出不安全的算法，因为它优化了通过测试而不是实际安全性。责任在于你，确保所有输出都是安全和正确的。

一个有用的提示：使用AI验证AI。例如，从AI获得一段代码后，你可以询问同一（或另一个）AI：“这段代码是否有任何bug或安全问题？”它可能会指出你遗漏的地方（比如，“它没有在这里清理输入”或“如果X发生，这可能会溢出”）。虽然AI的这种第二意见也不能保证，但它是一个快速的健全性检查。OpenAI和Anthropic的编码指南甚至建议这种迭代提示和审查的方法——本质上是借助AI进行调试。

最后，保持健康的怀疑态度。如果输出中的某些内容让你觉得奇怪或好得不像真的，请进一步调查。AI很擅长听起来自信。成为AI原生的一部分是学习AI擅长和容易出错的地方。随着时间的推移，你将获得一种直觉（例如，“我知道LLM倾向于弄乱日期计算，我会仔细检查那一部分”）。这种直觉，结合彻底的审查，让你始终掌握主动权。

虽然点击一个按钮就能让AI构建整个系统的想法很有吸引力，但在实践中，它很少如此简单或理想。最佳实践是利用AI放大你的生产力，而不是完全自动化你无法监督的工作。换句话说，对于任何非微不足道的结果，都要保持人工参与。如果你使用自主智能体生成应用程序（正如我们在原型工具中看到的），将输出视为原型或草稿，而不是成品。计划由你或你的团队进行迭代。

将大任务分解成小的AI辅助块。例如，与其说“给我构建一个完整的电子商务网站”，不如将其分解：首先使用AI生成前端页面（你进行审查），然后使用AI创建基本的后端（审查它），最后进行集成和完善。这种模块化方法确保你保持理解和控制。它还利用了AI在集中任务上的优势，而不是期望它处理非常复杂的相互依赖任务（这往往是它可能遗漏重要内容的地方）。记住，AI并不能真正“理解”你项目的更高目标；那是你作为工程师或技术负责人的工作。你决定架构和约束，然后将AI作为一个强大的助手来实现部分愿景。

抵制过度依赖的诱惑。 出于方便，你可能会忍不住让AI处理所有小事，甚至是你自己知道的事情。虽然将其用于繁琐任务没有问题，但请确保你仍在学习和理解。AI原生工程师不会关闭他们的大脑——恰恰相反，他们利用AI来解放大脑，进行更重要的思考。例如，如果AI为你编写了一个复杂的算法，花时间理解该算法（或者至少验证其正确性），然后才能部署。否则，你可能会积累“AI技术债”——代码能工作但没有人真正理解，这可能会在以后让你吃苦头。

管理范围的一种方法是为AI智能体设置清晰的边界。如果你使用像Cline或Devin（自主编码智能体）这样的工具，用你的规则配置它们（例如，未经询问不得安装新依赖项，不得进行网络调用等）。并使用试运行或计划模式等功能。例如，让智能体向你展示其计划（就像Cline那样），并逐步批准。这确保了AI不会偏离主题或采取你不会采取的行动。本质上，你充当AI工作者的项目经理——你不会让一个初级开发人员在没有代码审查的情况下直接提交到主分支；同样，也不要让AI这样做。

通过对AI的角色进行范围界定和监督，你可以避免在不知不觉中出现问题。你还能保持自己对项目的参与度，这对于质量和你自身的成长至关重要。反之亦然：确实要将AI用于所有那些耗时但不需要大量创造性工作的_小事_。让它编写第十个CRUD端点的变体或样板表单验证代码，而你则专注于需要人类洞察力的棘手集成逻辑或性能调优。这种分工——AI负责繁重工作，人类负责监督和创造性问题解决——是当前AI集成的最佳平衡点。

AI领域和可用的工具发展速度惊人。“AI原生”今天的定义与一年后将会不同。因此，一个关键原则是：永不停止学习。关注新工具、新模型功能和新的最佳实践。订阅新闻通讯或社区（有一些专门针对编码AI工具的开发者新闻通讯）。与同行分享经验：他们使用了哪些提示策略，他们尝试了哪些新的智能体框架等等。社区正在共同探索这个问题，积极参与将让你保持领先。

一个实际的学习方法是将AI融入副项目或黑客松。风险较低，你可以自由探索其能力。尝试纯粹在AI协助下构建一些东西作为实验——你将发现它的超能力和痛点，然后可以将其小心地应用到你的日常工作中。也许在这样做的过程中，你会发现一个巧妙的工作流程（比如将GPT的提示链接到编辑器中的Copilot），你可以教给你的团队。事实上，指导团队中的其他人使用AI也将巩固你自己的知识。举办一次关于提示工程的午餐会，或者分享一个AI如何帮助解决棘手问题的成功案例。这不仅帮助了同事，他们也经常会分享自己的技巧，从而提升每个人的水平。

最后，也要投资于你的基本技能。AI可以自动化很多东西，但你对计算机科学、系统设计和问题解决的基础越扎实，你向AI提出的问题就越好，评估其答案的能力也就越强。人类的创造力和对系统的深度理解并没有被取代——事实上，它们变得更加重要，因为你现在正在指导一个强大的工具。正如我的一篇文章所建议的，关注“最大化‘人类30%’”——工作中人类洞察力不可替代的部分。这包括定义问题、做出判断和关键调试。通过持续学习来增强这些能力，让AI处理枯燥的70%。

如果你在团队环境中工作（我们大多数人都是如此），那么协作AI使用实践非常重要。与队友分享你所学到的，也要倾听他们的经验。也许你发现使用某个AI工具提高了你的提交速度；向团队提出，看看大家是否愿意采纳。反之，也要接受指导方针——例如，有些团队决定“我们不会在未经至少一名人工审查和测试的情况下提交AI生成的代码”（这是一个明智的规则）。一致性很重要；如果每个人都遵循类似的方法，代码库就会保持一致，人们会信任彼此的AI增强贡献。

你甚至可以将此正式化为团队惯例。例如，如果使用AI进行代码生成，一些团队会在PR或代码注释中注明，如 // Generated with Gemini, needs review。这种透明度有助于代码审查者集中注意力。这类似于我们处理来自自动化工具的代码（例如“此文件由Rails生成器搭建”）。知道某个内容是AI生成的可能会改变你的审查方式——也许在某些方面会更彻底。

鼓励与AI进行结对编程。一个巧妙的做法是_AI驱动的代码审查_：当有人打开拉取请求时，他们可能会在diff上运行AI以获取初始审查意见列表，然后利用这些意见在人类看到PR之前进行完善。作为一个团队，你可以将此作为一步（但要小心AI可能无法捕捉所有问题，也无法理解业务上下文）。另一个协作角度是文档：也许维护一个内部FAQ，例如“我如何要求AI为我们的代码库做X？”——例如，如何用你的特定技术栈进行提示。这可以是新团队成员入门AI在你的项目中使用的部分。

另一方面，尊重那些对AI持谨慎或怀疑态度的人。并非所有人都能立即感到舒适或被说服。以非威胁的方式展示结果比抽象地宣扬更好。展示它如何发现了一个bug或通过起草测试节省了一天的工作。也要诚实地面对失败（例如，“我们尝试用AI生成那个模块，但它引入了一个我们后来发现的细微bug。这是我们学到的。”）。这有助于建立集体智慧。一个共同学习的团队将比各自为政的个人更有效地集成AI。

从领导角度（对于技术主管和经理而言），思考如何整合AI培训和指南。可以拨出时间让团队成员进行实验和分享发现（如黑客日或关于AI工具的闪电演讲）。此外，作为团队决定如何处理AI生成代码的许可或知识产权问题——例如，代码生成工具具有不同的许可或使用条款。确保遵守这些规定以及任何公司政策（有些公司禁止使用公共AI服务处理专有代码——在这种情况下，你或许可以投资内部AI解决方案或使用可本地运行的开源模型，以避免数据泄露）。

简而言之，将AI采纳视为一项团队运动。每个人都应该朝着同一个方向努力，并使用大致兼容的工具和方法，以使代码库保持可维护性，并将收益在整个团队中倍增。组织层面的AI原生能力可以成为强大的竞争优势，但这需要一致性和集体学习。

最后但同样重要的是，始终负责任地使用AI。这包括以下几点：

总之，成为一名AI原生工程师也意味着成为一名负责任的工程师。我们构建可靠、安全、尊重用户的系统的核心职责没有改变；我们只是现在有了更强大的工具。以一种让你引以为豪的方式使用它们，就好像它们完全由你编写一样（因为实际上，你对此负有责任）。许多公司和组织（OpenAI、Google、Anthropic）已经发布了关于负责任AI使用的指南和手册——这些可以是深化你这方面理解的绝佳延伸阅读（参见“延伸阅读”部分）。

如果你领导一个工程团队，你的职责不仅仅是允许AI的使用，而是要战略性地倡导它。这意味着从被动接受转向积极培养，重点关注以下几个关键领域：

遵循这些最佳实践将有助于确保你将AI集成到工程中能够产生积极的结果——更高的生产力、更好的代码、更快的学习——而不会带来草率使用带来的负面影响。它关乎将AI的最佳能力与你作为熟练人类的最佳能力相结合。下一节也是最后一节将总结我们的讨论，反思AI原生之旅和未来的道路，以及继续探索的额外资源。

我们已经探讨了成为AI原生软件工程师的意义——从思维模式到实际工作流程，从工具领域到生命周期集成，再到最佳实践。很明显，软件工程师的角色正在随着AI能力的不断增长而演变。AI非但没有使工程师过时，反而证明了它是人类技能的强大增强。通过采纳AI原生方法，你将自己定位为能够更快地构建、学到更多、应对比以往任何时候都更大的挑战。

总结几个关键要点：成为AI原生首先要将AI视为你技能的倍增器，而不是一个神奇的黑盒或威胁。它关乎不断追问：“AI能在这方面帮助我吗？”然后审慎地利用它来加速日常任务，探索创造性解决方案，甚至发现错误。它涉及提示工程和智能体编排等新技能，但也提升了永恒技能的重要性——架构设计、批判性思维和道德判断——因为这些指导着AI的应用。AI原生工程师始终在学习：学习如何更好地使用AI，并利用AI更快地学习其他领域（一个良性循环！）。

实际上，我们看到有一个丰富的工具生态系统。没有放之四海而皆准的AI工具——你可能会根据自己的工作组建一个个人工具包（IDE助手、原型生成器等）。最优秀的工程师会知道何时选择何种工具，就像一个工具箱齐全的工匠一样。而且他们会随着新工具的出现而不断更新工具箱。重要的是，AI成为工作各个阶段的协作伙伴——不仅是编码，还包括编写测试、调试、生成文档，甚至在设计阶段进行头脑风暴。你让AI参与的领域越多，你就能将你独特的人类才能集中在最重要的地方。

我们还强调了谨慎和责任。AI能力的兴奋应与健康的怀疑和严格的验证相平衡。通过遵循最佳实践——清晰的提示、代码审查、小步迭代、注意局限性——你可以避免陷阱，并在使用AI时建立信任。作为一名经验丰富的专业人士（特别是如果你是IC或技术负责人，就像你们中的许多人一样），你拥有有效指导AI和减轻其错误的背景。从某种意义上说，你的经验比以往任何时候都更有价值：初级工程师可以从AI获得提升来生成中级代码，但需要高级思维才能提示AI以健壮的方式解决复杂问题，并将其优雅地集成到更大的系统中。

展望未来，我们只能预期AI将变得更加强大，并更深入地集成到我们使用的工具中。未来的IDE可能会有AI持续运行，检查我们的工作甚至在后台优化代码。我们可能会看到针对不同领域的专业AI（例如，擅长前端用户体验的AI与擅长数据库调优的AI）。成为AI原生意味着你将顺利适应这些进步——你将将其视为工作流程的自然演变。也许最终“AI原生”将简单地等同于“软件工程师”，因为使用AI将像今天使用Stack Overflow或Google一样普遍。在那之前，那些率先采用这种方法的人（就像你，阅读并应用这些概念的人）将拥有优势。

还有一个更广泛的影响：通过加速开发，AI可以解放我们，让我们专注于更宏大的项目和工程中更具创造性的方面。它可能预示着一个快速原型设计和实验的时代。正如我在其中一篇文章中所思考的，我们甚至可能会看到软件构建者发生转变——随着AI降低门槛，更多人（甚至是非传统编码者）可以将想法变为现实。作为一名AI原生工程师，你可能会在其中发挥作用，通过构建工具或指导他人使用它们。这是一个令人兴奋的前景：工程变得更多地关乎想象力和设计，而重复的劳动则由我们的AI助手处理。

总之，将AI融入你的日常工程实践并非一次性转变，而是一个旅程。从你所在的位置开始：尝试一个新工具，或将AI应用于下一个任务的一部分。逐步扩大你的舒适区。庆祝成功（比如第一次AI生成的测试捕获了你遗漏的bug），并从挫折中学习（也许AI重构破坏了什么——这是改进提示的教训）。

鼓励你的团队也这样做，建立一个对AI友好的工程文化。通过务实的使用和持续的学习，你会发现AI不仅能提高你的生产力，还能重燃开发的热情——让你专注于创造性问题解决，并更快地将想法变为现实。

AI辅助开发时代已经到来，那些巧妙驾驭这股浪潮的人将定义软件工程的下一个篇章。通过阅读本文并自行实践，你已然走上这条道路。继续前进，保持好奇心，继续编码——与你的新AI伙伴并肩作战。

为了加深您的理解并持续改进您的AI辅助工作流程，这里有一些来自领先组织的优秀免费指南和资源。它们涵盖了从提示工程到构建智能体以及负责任地部署AI的方方面面：

每个资源都可以帮助您进一步发展您的AI原生工程技能，提供理论框架和实用技术。它们都是免费提供的（没有付费墙），阅读它们将巩固本节中讨论的许多概念，同时从行业专家那里引入新的见解。

祝您学习愉快，构建愉快！

很高兴告诉大家，我正在与O'Reilly合作撰写一本新的AI辅助工程书籍。如果您喜欢我在这里的文章，您可能会对它感兴趣。