5种方法，让AI编码智能体不再乱写架构

自动代码生成不是新概念，但AI编码智能体的编码速度远超以往任何工具。速度快了，好处明显，问题也独特——人们很容易失去对输出代码质量的控制。这种失控在架构层面尤其突出。如果你只向AI输入功能需求，它并不会自动确保架构的合理性。你必须向它提供具体的架构目标，比如可衡量的质量属性需求（QAR）和权衡取舍。AI生成的代码需要经过测试，以此来评估是否满足QAR。

用AI编码智能体开发具备弹性、可扩展、安全的系统，目前还处于起步阶段。你可以学课程、读书、找指导，但归根结底都是在实践中学习，不断尝试、犯错，再从经验里吸取教训。不过有一些方法能帮你快速上手，把实践经验用足，而不是把时间浪费在盲目尝试上。以下是在使用AI编码智能体构建架构合理系统的过程中，总结出的一些入门建议。

先摸清遗留服务的底细

现代架构通常依赖遗留服务来执行特定任务，比如从几十年前构建的保险单系统中检索当前和历史保单信息。麻烦在于，这些服务可能缺少精准的文档，如果没能充分理解其逻辑与数据，调用时就容易出问题。

有一个很少使用的遗留服务，用于从IMS数据库检索信息，它可能潜藏着未知问题，比如逻辑或安全缺陷，在非预期的场景中调用时会返回错误信息。这些问题可能在开发后期才暴露，比如系统测试或用户验收测试期间，甚至在新系统上线生产环境之后。

为了降低这种风险，可以用AI编码智能体梳理遗留服务的系统设计，包括记录数据流。它还可以扫描遗留服务的代码，识别潜在问题并提出修复建议。如果团队认为遗留服务确实状况糟糕、问题太多，可以用编码智能体对服务进行重构，提升代码可读性与可维护性。这种重构能消除新架构中的一项关键风险。

让智能体去查架构问题

除了发现和修复安全缺陷，你还可以用AI编码智能体发现和修复常见的架构问题。用法可能很简单，比如找出违背架构规范、编码规范执行不到位，或是需要重构以提升可维护性的代码位置。你甚至可以让编码智能体提出修改建议，解决它发现的问题。

用AI编码智能体发现常见的架构问题，例如API设计问题，包括难以使用、不安全或低效的接口，以及领域驱动设计（DDD）边界越界问题。明确指定需要检查的范围。比如，你可以要求AI编码智能体评估服务层，检查是否存在组件直接访问另一个领域的内部状态，或是复用其他领域代码的情况。这类评估存在收益递减效应，因为AI几乎总能发现改进之处。你需要自行判断哪些发现是关键问题，哪些不是。

采用这种方式，需要熟悉架构难题的团队成员引导AI编码智能体，他们知道如何编写提示词，通过约束和引导让编码智能体产出预期结果。团队通过提供具体、可衡量的架构目标，以及清晰阐述已知的取舍方案与备选方案，来完成对编码智能体的引导，聚焦智能体的工作范围，控制使用成本。这需要经验来阐明可能需要做出的权衡，让编码智能体在生成解决方案时将它们纳入考量。如果提示词只包含功能需求，就会缺乏这种聚焦，由此产生的系统架构很可能无法满足QAR。

这样使用编码智能体还有一个意外的好处：它会倒逼团队更清晰地梳理取舍方案，明确自己能够接受的代价。

用智能体挖漏洞，也用它补漏洞

近期关于恶意利用AI编码智能体挖掘现有系统安全漏洞的报告，让所有人都高度警惕。但这些风险也有另一面：AI编码智能体也可以识别漏洞并完成修复，特别是当架构中包含了开源包时。也就是说，我们是否使用了正确的、带有最新安全补丁的开源包？

你可以用AI编码智能体扫描源代码文件、绘制系统设计图和编写测试来发现软件缺陷，从而发现安全漏洞。除了指出糟糕的代码，AI编码智能体还能够分析整个系统，发现复杂的逻辑缺陷，并生成代码来修复这些问题。具体来说，你可以要求AI编码智能体：

• 追踪数据流、识别高风险文件，梳理系统设计（限制智能体访问权限，仅允许读取授权文件）。
• 扫描代码，跨文件查找复杂逻辑缺陷（在提示词中屏蔽或隐藏数据库密码等敏感密钥，降低风险）。
• 生成类似黑客脚本的压力测试脚本，对潜在漏洞进行测试（将智能体隔离在封闭网络环境，防止意外攻击线上服务器）。
• 生成代码补丁，修复安全漏洞（任何代码合并前，必须由人工完成代码评审）。

在漏洞测试工作中，客户报告说当前使用的若干npm包被标记存在安全风险。我们用AI编码智能体评估风险，并向客户反馈，输出详细的影响分析报告。最终我们更新了其中两个包，替换了一个包，还有一个包的告警属于误报，所以保留了下来。所有这些工作都是在AI编码智能体的协助下完成的。

随着大语言模型在网络安全领域能力变强、风险上升，我们更需要借助AI编码智能体，在漏洞被恶意利用之前提前发现架构中的潜在安全问题。

原型要快，但别只做一次性演示

AI编码智能体能够帮助团队快速做实验，几乎可以瞬间生成原型，方便用户确认需求。如果没有明确引导编码智能体去关注架构，生成的原型就不太可能实现系统的QAR，并且在很大程度上只能作为一次性演示原型。

要解决这个问题，需要引导和约束AI编码智能体，使其符合具体的、可衡量的架构目标和清晰阐述的权衡取舍。然后，可以使用编码智能体来创建预打包的shell应用程序，作为开发者制作原型的基础。架构目标与约束条件以Markdown格式提供，包含质量属性需求、编码规范、数据库设计、API、推荐平台与框架，同时将这些信息提供给AI编码智能体，进一步完善模型应用程序。

如果你正在开发一个小型的React应用程序，可以让AI编码智能体查看你的文件目录结构，并根据现代开发规范对其进行评估。如果你与推荐的或React社区所采用的做法不一致，编码智能体可以给出大小不等的修改建议并协助调整。与往常一样，需要检查它给出的建议是否匹配你要解决的业务场景。

团队一直在开发新的应用程序。如果你发现了通用的模式，就可以利用GitHub的模板功能。你可以借此勾勒出应用程序的常见结构，创建可供AI调用的技能，并内置编码规范，让团队从一开始就能搭建架构合理的应用。

描述你想要达成的目标，比直接告诉编码智能体要生成哪种实现方案效果更好。人们很自然会直接描述实现方案，但团队应当避免这种思路。描述目标、约束条件以及目标的验证方式会高效得多。

需求定义，反而成了最难的部分

从架构设计角度来看，这意味着很多原本默认资深开发人员能够理解的隐性架构需求与约束，现在必须显式定义，做到可落地、可测试。除此之外，团队还必须对这些QAR开展实测；仅有可测试需求远远不够。如果你使用AI编码智能体生成测试用例，至少要有人工的评审和验证，保证测试能够准确衡量指标。

实际上，使用AI编码智能体使编码变得更简单，但创建需求却变得更加困难。开发人员多年来磨练的技能，例如编写代码，现在变得不那么重要。开发人员因为觉得麻烦而想去回避的事情，即理解和阐明需求和约束，变成AI辅助开发模式下最需要磨练的重要技能。

只要需求定义准确，AI编码智能体就可以高效快速生成代码。乍一看，这种方式性价比很高，能够快速用现代技术替换老旧、难以维护的应用，例如COBOL程序。但问题在于，AI编码智能体生成的部分代码会存在错误。检查AI生成的代码很重要，但还不够，必须通过可量化的测试评估代码质量，这样才能构建高质量的软件架构。

因此，最小可行架构（MVA）需要包含全部必要代码，用以证明系统同时满足质量属性需求与功能需求。使用AI编码智能体并不会改变这一事实。使用AI编码智能体生成测试架构基础的代码，对于验证架构来说非常重要。如果团队在生成代码的提示词中提供了QAR和权衡信息，那么编码智能体就拥有生成测试代码所需的信息，包括测试框架、测试数据和测试环境（例如容器）配置。

团队还需要考虑一个风险：AI智能体可能无法生成完全满足其QAR的MVA，后续需要扩展生成。为了降低这种扩展成本超出其承受能力的风险，团队可以在评估AI生成的MVA的适用性时引入架构变更案例。

虽然AI编码智能体带来了显著的速度提升，但需要有效的护栏来确保它们的产出满足质量目标。软件架构是保证质量目标得以实现的一种方式。团队需要向AI编码智能体提供架构上下文来达成质量目标。

事实证明，AI编码智能体是实现架构需求的宝贵工具，但也带来了一系列我们才刚刚开始理解的全新挑战。由于AI编码智能体仍属于新兴事物，技术迭代迅速，这些建议可以帮助大家利用AI编码智能体改进甚至是搭建软件架构。它们并非该领域的终极定论，但可以作为坚实的起点，帮助团队开启相关实践之旅。