在AI时代编写高质量代码

# 在AI时代编写高质量代码 来源：https://serverpod.dev/blog/quality-code-with-ai AI 已迅速成为编写代码的绝佳助手，但它也带来了一系列全新的挑战。六个月前，我写了一篇关于如何最佳设置环境以进行AI辅助代码生成的文章(https://serverpod.dev/blog/vibe-coding-flutter)。感觉那已经是上辈子的事了。工具已经进化，模型也变得更聪明。以下是截至2026年使用AI编写*高质量*代码的更新版、更深入的指南。 我职业生涯的一部分是在Google担任软件工程师，那里的每个人都痴迷于代码质量。每一行代码在进入主代码库之前，都要经过仔细审查、重做、测试和批准。我还花了很多年管理大型开源项目，过去是Cocos2d for iPhone，现在是Serverpod。 我最近在LinkedIn和X上对超过600名Flutter开发者进行了一项投票，结果显示超过90%的人现在使用AI生成代码。公平地说，并非每个代码库都需要达到Google仓库那样严格的标准。但如果你在构建可维护性、安全性和可扩展性至关重要的大型应用程序，那么代码质量是没有商量余地的。 质量问题与代码习惯 问题在于：AI极大地提高了代码生成的速度和数量，但速度并不等于质量。 作为开源维护者，收到低质量的AI生成代码贡献正成为日常头疼的问题。乍看之下，代码往往看起来合理，促使你开始正式审查。但深入挖掘，裂缝便开始显现：糟糕的架构结构、完全无视项目既定的代码风格，以及对边缘情况的巨大盲区。 在Serverpod，我们致力于保持极高的标准，这意味着我们会手动审查进入代码库的*所有*内容。对于复杂项目，这不仅仅是偏好，而是防止代码库失控的严格要求。 如果你认为这只是使用基础工具的初级开发者的问题，那就大错特错了。AI辅助开发失败的一个明显例子是Anthropic的Claude Desktop应用程序。如果你想深入了解那里出了什么问题，我强烈推荐观看Theo最近的评论视频(https://www.youtube.com/watch?v=WkHdkwDQJ5o)。这是一个发人深省的提醒：你会认为Anthropic的工程师能够接触到目前绝对最好的模型，但输出仍然存在许多根本性缺陷。 ## 范式转变 我们正在从编写每一行语法，转向通过提示词引导AI并积极审查其输出。你必须不再把自己看作打字员，而是开始像导演一样行事。 这种新工作流程的最大陷阱是**能力错觉**。AI生成的代码极具说服力。它使用正确的变量名，格式完美，在快速浏览时看起来正确。但在那光鲜的表面之下，往往隐藏着只有经验丰富的工程师才能发现的微妙错误。 ## AI生成代码的隐藏风险 如果你盲目相信AI助手输出的内容，你将以前所未有的规模引入技术债务。以下是一些需要注意的问题： ### 偏向平均值 AI模型基于训练数据预测统计上最可能的代码。这意味着它们常常提出最通用的、广泛使用的解决方案。统计上常见的东西很少是你高度特定用例的最现代或最合适的方法。请自行研究最适合你项目的框架、工具和算法。 ### 重复造轮子 AI喜欢为标准问题编写自定义的、冗长的实现，而不是利用现有的、经过实战检验的库、框架甚至内置语言特性。审查生成的代码时，确保它恰当地复用了既定的模式和方法。检查是否已经有值得信赖的库可用。 ### 安全漏洞 模型在大量公共代码上训练，其中许多代码是过时的或从根本上不安全的。如果不加检查，AI会自信地引入SQL注入、糟糕的密码学实现和弃用的身份验证模式。始终对可能引入漏洞的任何代码进行深入审查。浏览客户端或应用代码可能可以接受，但后端必须稳固。 ### 意大利面条式代码 AI擅长编写独立的函数，但常常难以处理广泛的系统架构。过度依赖AI生成会导致代码碎片化、高度耦合和高度重复。有时，值得手动编写或强力引导项目的初始架构，以建立其基础模式。这样，AI更容易填补空白并遵循代码库的规则。 ### AI偷懒 模型常常遭受输出token疲劳。如果你要求AI跨五个文件应用更改，它可能完美更新前两个，部分更新第三个，然后剩下的留给你。始终仔细检查实现是否真正完成。 ### 黑盒问题 集成你不理解的AI生成代码就是一颗定时炸弹。当它在生产中不可避免地崩溃时，调试将是一场噩梦。当你使用AI生成大部分代码时，你仍然需要理解它是如何工作的。 ### 幻觉 AI模型以幻觉而臭名昭著，这个问题远不止是编造不存在的API或导入已弃用的包。它们可以构建复杂的语义幻觉：代码编译并运行而不崩溃，但悄无声息地执行了错误的逻辑。因为LLM是设计用于生成合理序列而非严格事实的概率引擎，它们会以如此确信的方式编写这些虚构内容，以至于你可能会质疑自己的知识。始终根据官方文档验证不熟悉的方法，并考虑采用自动验证步骤，例如使用一个独立的次要AI代理，专门提示其审查和事实核查主要代理的输出，然后再将其送入你的审查队列。 ## 确保质量的最佳实践 那么，我们如何在利用AI速度的同时不牺牲代码库的质量呢？这通常归结为严格的实践和更好的上下文工程。 ### 掌握提示语 你的提示语需要强制执行项目的特定风格指南、架构模式和约束。以下是一个示例。 > ❌ **糟糕的提示：** *“重构这个认证文件。”* 这完全依赖于AI的通用训练偏差，并会引入巨大的架构漂移。 > ✅ **优秀的提示：** *“将 `auth_endpoint.dart` 中的登录方法重构，将会话处理逻辑提取到一个单独的辅助类中。确保使用我们现有的 `Result` 类型进行错误处理，而不是抛出异常。不要修改加密函数。使用标准的 Dart test 包为新的辅助类编写测试。”* 这高度受约束，明确提到了内部类型/库，并设定了清晰的边界。 ### 上下文工程 停止在每个提示中手动复制粘贴规则。组织你的项目，使AI始终知道规则。以下是改善智能体上下文的最重要方法。 #### 使用 AGENTS.md 编码规则 在你的仓库根目录下放置一个 `AGENTS.md` (https://agents.md/) 文件。这本质上是智能体的README，并且总是包含在上下文中。用它来编码项目级别的规则，例如你偏好的测试框架、包管理器和严格的架构约束。然而，由于它总是被包含在内，保持其简洁并只包含智能体必须知道的内容很重要。用太多无关信息膨胀上下文会降低智能体的性能并使其困惑。 #### 将知识打包为技能 除了 `AGENTS.md` 文件，你还应该利用新兴的智能体技能标准(https://agentskills.io/) 将领域特定知识、参考文档和工作流程打包成模块化实体。这种方法允许AI仅在特定任务需要时才延迟加载专门的指令。在实践中，这节省了宝贵的token上下文，同时能在需要时提供专家级别的指导。 #### 通过MCP增加能力 虽然技能对于基础静态上下文很有用，但模型上下文协议 (Model Context Protocol, MCP) (https://modelcontextprotocol.io/) 对于为AI配备额外工具很有用。它弥合了服务交互的差距，例如安全地查询实时数据库或更新Jira工单，这些是AI本身无法访问的。 ### 指导AI 一旦建立了正确的上下文，下一步关键是如何在编码阶段与AI交互。成为有效的导演意味着为任务选择合适的模型，知道何时指导架构，一次生成多少代码，以及何时介入并完全接手。 #### 为工作选择合适的模型 并非所有AI模型都一样，成为有效导演的一部分就是为场景挑选合适的人才。快速、轻量级的模型非常适合快速自动补全、生成样板代码或执行简单的、定义良好的重构。然而，如果让它们理清复杂逻辑或设计复杂的数据库模式，它们就会出错。对于需要深度推理、导航大量文件或解决困难架构谜题的任务，你需要切换到更重、能力更强的推理模型。这些模型生成答案需要更长时间，但它们思考复杂代码的能力要优越得多。试图强迫快速模型进行繁重工作会导致微妙错误和挫败感，而使用重型推理模型进行琐碎更改则会不必要地瓶颈你的工作流。 #### 架构指导 vs. 头脑风暴 协作使用AI进行头脑风暴和探索架构选项非常有帮助。但一旦到了实际编写代码的时候，你需要坚定地握住缰绳。始终提供清晰、严格的架构指令，而不是让AI决定各部分如何组合在一起。 #### 小批量生成 保持你的提示严格限定范围。生成较小的输出可以避免审查过程中的认知过载，使你更容易验证逻辑并在细微错误滚雪球之前捕捉到它们。 #### 知道何时手动编写代码 你必须认识到AI成为障碍而非帮助的临界点。对于高度复杂的逻辑、新颖的架构或训练数据有限的狭窄领域，与AI无休止地修改提示通常比你自己编写代码花费的时间长得多。 #### 黄金示例 引导AI智能体最有效的方法之一是从你自己的代码库中给它一个高质量的示例。花时间创建一个实现，展示你希望未来代码遵循的结构、命名、错误处理、测试和风格。然后让这个示例易于引用，要么将其转化为智能体技能，要么在提示时直接指向它。 #### 积极的代码审查 审查AI代码需要*更多*的审查，而不是更少。在阅读生成的拉取请求时，重点关注边缘情况、状态管理和业务逻辑，因为这些是AI最常出错的地方。 #### 测试驱动开发 测试驱动开发 (TDD) 是你在AI时代的终极安全网。确保为所有AI生成的逻辑编写严格的单元测试和集成测试，并在要求智能体实现之前使用它们来定义期望的行为。重要的是，测试仍然是一个独立的真理来源：仔细审查对测试的任何更改，并确保它们在CI管道中运行，以便永远不会被遗忘。 #### 保持代码模块化 在将问题交给AI之前，将复杂问题分解成更小、可测试的函数。确保生成的代码整齐地融入你的更大系统至关重要。老实说，无论代码是如何编写的，这都只是好建议，但在委托给AI时变得至关重要。 ### 自动化验证 最大的效率提升来自于你的AI助手能够看到与你相同的反馈。配置你的linter、编译器和测试运行器，使错误直接流入智能体的上下文。这就创建了一个快速循环，智能体可以诊断失败、提出修复建议并重新运行检查，而无需手动在工具之间复制输出。 你可以将同样的想法扩展到CI中。当管道失败时，向智能体提供差异、失败的日志和相关的测试输出，然后让其建议修复甚至创建拉取请求。重要的是，智能体不应是最终权威。你的CI管道仍然是回归、集成问题和安全敏感代码的守门人。 AI还可以帮助处理容易推迟的清理和审查任务：查找重复逻辑、移除死代码、检查过时注释，以及在你查看之前审查其自身生成的更改。通过这种方式使用，AI成为你质量流程的一部分，而不仅仅是更快生成更多代码的方法。 ## 结论 AI是一个极其强大的放大器。但请记住：它放大不良实践和放大良好实践一样容易。 规模化构建软件仍然需要优秀的开发者来确保所有不同的部分能够安全可靠地组合在一起。如果我们这个行业的目标是构建更好、更可靠的软件，那么结论很简单：开发者仍然是质量的最终守门人。 代码很廉价，你的大脑不是。所以，放慢速度，为你产生的代码负责。