自动代码生成并不是一个新概念，但 AI 编码智能体的编码速度远超以往的任何工具。这种速度带来了巨大的好处，但也产生了独特的问题，人们很容易失去对输出代码质量的控制。
这种失控在架构层面显得尤为突出。如果你只向 AI 输入功能需求，AI 并不会自动确保架构的合理性。
你必须向它提供具体的架构目标，例如可衡量的质量属性需求（QAR）和权衡取舍（参见“ 怀疑论者眼中的软件架构决策指南 ”）。 AI 生成的代码需要经过测试，以此来评估是否满足 QAR。
使用 AI 编码智能体来开发具备弹性、可扩展、安全的系统尚处于起步阶段。你可以学习编码智能体相关课程、阅读书籍，甚至寻找指导，但我们都是在实践中学习，不断尝试、犯错，并从经验中吸取教训。
不过，有一些很好的方法可以帮助你快速上手，充分利用实践经验，而不是浪费太多时间盲目尝试。以下是我们在使用 AI 编码智能体构建架构合理的系统的过程中总结的一些有用的入门建议。
这些建议不是菜谱式操作手册，也不是固定的流程，而是一些有用的方法，可以帮助你们获得经验、有目的地学习，至少足以让你能够进行自主的探索学习。使用 AI 编码智能体记录架构所依赖的遗留服务 现代架构通常依赖遗留服务来执行特定任务，例如从几十年前构建的保险单系统中检索当前和历史保单信息。
不幸的是，这些服务可能缺少精准的文档，如果没能充分理解其逻辑与数据，调用时就容易产生问题。示例 有一个很少使用的遗留服务，用于从 IMS 数据库检索信息，它可能潜藏着未知的问题，例如逻辑或安全缺陷，在非预期的场景中调用时会返回错误的信息。
这些问题可能在开发的后期才暴露出来，例如在系统测试或用户验收测试期间，甚至在新系统上线生产环境之后。为了降低这种风险，可以用 AI 编码智能体梳理遗留服务的系统设计，包括记录数据流。
此外，它还可以扫描遗留服务的代码，识别潜在问题并提出修复建议。如果团队认为遗留服务确实状况糟糕且问题太多，可以用编码智能体对服务进行重构，提升代码可读性与可维护性。
这种重构能够消除新架构中的一项关键风险。使用 AI 编码智能体发现和修复架构缺陷 除了发现和修复安全缺陷外，你还可以使用 AI 编码智能体来发现和修复常见的架构问题。
这种用法可能很简单，比如找出违背架构规范、编码规范执行不到位或是需要重构以提升可维护性的代码位置。你甚至可以使用编码智能体提出修改建议，解决它发现的问题。
示例 使用 AI 编码智能体来发现常见的架构问题，例如 API 设计问题，包括难以使用、不安全或低效的接口，以及领域驱动设计（DDD）边界越界问题。明确指定需要检查的范围。
例如，你可以要求 AI 编码智能体评估服务层，检查是否存在组件直接访问另一个领域的内部状态或是复用其他领域代码的情况。这类评估存在收益递减效应，因为 AI 几乎总能发现改进之处。
你需要自行判断哪些发现是关键问题，哪些不是。采用这种方式，需要熟悉架构难题的团队成员引导 AI 编码智能体，他们知道如何编写提示词，通过约束和引导让编码智能体产出预期结果。
团队通过提供具体、可衡量的架构目标以及清晰阐述已知的取舍方案与备选方案完成对编码智能体的引导，聚焦智能体的工作范围，控制使用成本。这需要经验来阐明可能需要做出的权衡，让编码智能体在生成解决方案时将它们纳入考量。
如果提示词只包含功能需求，就会缺乏这种聚焦，由此产生的系统架构很可能无法满足 QAR。这样使用编码智能体还有一个意外的好处：它会倒逼团队更清晰地梳理取舍方案，明确自己能够接受的代价。
使用 AI 编码智能体对系统进行安全审计 近期关于恶意利用 AI 编码智能体挖掘现有系统安全漏洞的报告让所有人都高度警惕，但这些风险也有另一面：AI 编码智能体也可以识别漏洞并完成修复，特别是当架构中包含了开源包时。也就是说，我们是否使用了正确的、带有最新安全补丁的开源包？
你可以使用 AI 编码智能体扫描源代码文件、绘制系统设计图和编写测试来发现软件缺陷，从而发现安全漏洞。除了指出糟糕的代码外，AI 编码智能体还能够分析整个系统，发现复杂的逻辑缺陷，并生成代码来修复这些问题。
具体来说，你可以要求 AI 编码智能体： 追踪数据流、识别高风险文件，梳理系统设计（限制智能体访问权限，仅允许读取授权文件）。扫描代码，跨文件查找复杂逻辑缺陷（在提示词中屏蔽或隐藏数据库密码等敏感密钥，降低风险）。
生成类似黑客脚本的压力测试脚本，对潜在漏洞进行测试（将智能体隔离在封闭网络环境，防止意外攻击线上服务器）。生成代码补丁，修复安全漏洞（任何代码合并前，必须由人工完成代码评审）。
示例 在漏洞测试工作中，客户报告说当前使用的若干 npm 包被标记存在安全风险。我们用 AI 编码智能体评估风险，并向客户反馈，输出详细的影响分析报告。
最终我们更新了其中两个包，替换了一个包，还有一个包的告警属于误报，所以保留了下来。所有这些工作都是在 AI 编码智能体的协助下完成的。
随着大语言模型在网络安全领域能力变强、风险上升，我们更需要借助 AI 编码智能体在漏洞被恶意利用之前提前发现架构中的潜在安全问题。使用 AI 编码智能体为开发人员提供架构基础 AI 编码智能体能够帮助团队快速做实验，几乎可以瞬间生成原型，方便用户确认需求。
如果没有明确引导编码智能体去关注架构，生成的原型就不太可能实现系统的 QAR，并且在很大程度上只能作为一次性演示原型。要解决这个问题，需要引导和约束 AI 编码智能体，使其符合具体的、可衡量的架构目标和清晰阐述的权衡取舍。
然后，可以使用编码智能体来创建预打包的 shell 应用程序，作为开发者制作原型的基础。架构目标与约束条件以 Markdown 格式提供，包含质量属性需求、编码规范、数据库设计、API、推荐平台与框架，同时将这些信息提供给 AI 编码智能体，进一步完善模型应用程序。
示例 如果你正在开发一个小型的 React 应用程序，可以让 AI 编码智能体查看你的文件目录结构，并根据现代开发规范对其进行评估。如果你与推荐的或 React 社区所采用的做法不一致，编码智能体可以给出大小不等的修改建议并协助调整。
与往常一样，需要检查它给出的建议是否匹配你要解决的业务场景。补充示例 团队一直在开发新的应用程序。
如果你发现了通用的模式，就可以利用 GitHub 的模板功能。你可以借此勾勒出应用程序的常见结构，创建可供 AI 调用的技能，并内置编码规范，让团队从一开始就能搭建架构合理的应用。
描述你想要达成的目标比直接告诉编码智能体要生成哪种实现方案效果更好。人们很自然会直接描述实现方案，但团队应当避免这种思路。
描述目标、约束条件以及目标的验证方式会高效得多。从架构设计角度来看，这意味着很多原本默认资深开发人员能够理解的隐性架构需求与约束，现在必须显式定义，做到可落地、可测试。
除此之外，团队还必须对这些 QAR 开展实测；仅有可测试需求远远不够。如果你使用 AI 编码智能体生成测试用例，至少要人工的评审和验证，保证测试能够准确衡量指标。
实际上，使用 AI 编码智能体使编码变得更简单，但创建需求却变得更加困难。开发人员多年来磨练的技能（例如编写代码）现在变得不那么重要。
开发人员因为觉得麻烦而想去回避的事情（即理解和阐明需求和约束）变成 AI 辅助开发模式下最需要磨练的重要技能。使用 AI 编码智能体生成可测试的 MVA 只要需求定义准确，AI 编码智能体就可以高效快速生成代码。
乍一看，这种方式性价比很高，能够快速用现代技术替换老旧、难以维护的应用（例如 COBOL 程序）。但问题在于，AI 编码智能体生成的部分代码会存在错误。
检查 AI 生成的代码很重要，但还不够，必须通过可量化的测试评估代码质量，这样才能构建高质量的软件架构。因此， 最小可行架构（MVA） 需要包含全部必要代码，用以证明系统同时满足质量属性需求与功能需求。
使用 AI 编码智能体并不会改变这一事实。使用 AI 编码智能体生成测试架构基础的代码对于验证架构来说非常重要。
如果团队在生成代码的提示词中提供了 QAR 和权衡信息，那么编码智能体就拥有生成测试代码所需的信息，包括测试框架、测试数据和测试环境（例如容器）配置。团队还需要考虑一个风险：AI 智能体可能无法生成完全满足其 QAR 的 MVA，后续需要扩展生成。
为了降低这种扩展成本超出其承受能力的风险，团队可以在评估 AI 生成的 MVA 的适用性时引入 架构变更案例 。总结 虽然 AI 编码智能体带来了显著的速度提升，但需要有效的护栏来确保它们的产出满足质量目标。
软件架构是保证质量目标得以实现的一种方式。团队需要向 AI 编码智能体提供架构上下文来达成质量目标。
事实证明，AI 编码智能体是实现架构需求的宝贵工具，但也带来了一系列我们才刚刚开始理解的全新挑战。由于 AI 编码智能体仍属于新兴事物，技术迭代迅速，本文给出了一些建议，帮助大家利用 AI 编码智能体改进甚至是搭建软件架构。
这些内容并非该领域的终极定论，但可以作为坚实的起点，帮助团队开启相关实践之旅。查看英文原文： /ai-market-guide/