使用 AI 进行小幅更改时降低架构漂移
Source: Dev.to
请提供您希望翻译的正文内容（包括任何 Markdown 格式的文本），我将为您翻译成简体中文并保留原有的格式、代码块和链接。谢谢！
背景
在之前的文章中，我讨论了架构漂移以及 AI 在加速交付的同时，如何悄然将系统推离其最初的设计意图。本文并不声称能够解决漂移问题；它探讨一个更务实的问题：如果漂移是不可避免的，在使用 AI 处理小型、日常的变更请求时，我们该如何降低漂移的发生？
下面的观察来源于我注意到的模式——哪些情况容易出错，哪些措施能稍有帮助，以及哪些方法至少能让损害更早显现。
什么是“架构”
架构并不是关于图表或繁重的文档，而是关于使变更安全的决策：
- 边界所在之处
- 谁拥有何种责任
- 数据如何流动
- 系统悄然依赖的、使其能够可预测运行的假设
当这些决策未被保留时，AI 并不会立刻破坏系统——它只是进行局部优化，直至整体结构不再合理。
Shift in Mindset
与其把 AI 当作更快生成代码的方式，我把它视为在能够发挥作用之前必须 受约束 的工具。真实系统中大多数 AI 辅助的改动都很小，但在缺乏架构意识的情况下反复进行这些小改动会累积成漂移。因此目标从“获得正确的输出”转变为“在进行更改的同时保持结构”。
非协商约束
这些不是建议；它们是必须在任何请求的更改下都保持真实的硬性约束：
- 不要引入新的服务边界。
- 不要重复业务逻辑。
- 不要更改数据契约。
- 不要跨越架构层。
当这些约束被隐含时，AI 会用在单独情况下看似合理的假设填补空白，但整体上会产生有害影响。
约束所在位置
约束必须是 原始提示 的一部分，而不是事后补充。每个更改请求应以相同的基础开始，首先说明影响，然后才进入实现阶段。在意图不明确的情况下进行更改，几乎总是会在以后花费更多成本进行修复。
Code Duplication: A Subtle Failure Mode
AI 在稍微更清晰的方式重新实现逻辑方面非常擅长。如果没有明确指示，它会创建看似正常但逐渐导致行为碎片化的平行路径。如果重用很重要——通常是——必须明确说明：
- “复用已有逻辑。”
- “不要创建平行实现。”
- “扩展，而不是复制。”
这些指令模型本身并不能可靠推断。
Managing Context Windows
AI只能对当前看到的内容进行推理。向它喂入大型文件或整个代码库往往适得其反，因为早期的约束可能会悄然超出范围。更现实的做法是假设模型只能看到一小部分文件，并明确列出这些文件名。于是，架构就变成一个紧凑的工作上下文，而不是文档堆砌。
有助的提示结构
一个简单且有效的提示结构：
- 首先说明不可协商的要点。
- 定义假设的范围（哪些文件在上下文中）。
- 在编写代码之前，要求模型解释架构影响。
这并不会让 AI 更聪明；它迫使在执行前停下来。仅此停顿就能降低意外偏离的风险。
限制
这并不是治愈之策。架构漂移是不断演化系统的自然属性。目标不是阻止变化，而是确保变化是有意为之，而非凭推断发生。这些做法并不能消除风险；它们让风险更早显现，从而仍有可能进行纠正。
AI 在推动系统前进方面异常擅长。架构的存在是为了确保我们不会盲目前进。如果架构意图没有明确体现在我们的提示中，系统仍会演化——只是不在我们有意识选择的方向上。
示例架构约束变更请求提示
You are implementing a small, incremental change to an existing system.
The following architectural constraints are non‑negotiable and must be preserved:
- The system follows a layered architecture.
- Business logic resides exclusively in the domain layer.
- Adapters are responsible only for data translation, not decision‑making.
- Existing service boundaries and data contracts must remain unchanged.
- No new abstractions, services, or parallel implementations may be introduced.
Assume your effective context is limited to the following files:
OrderService.py, OrderValidator.py, OrderRepository.py.
Do not infer, recreate, or duplicate logic that may exist outside this scope.
Change request:
Add validation for a new optional field in the order payload.
Reuse existing validation mechanisms wherever applicable.
Avoid duplication and ensure behavior remains centralized.
Before implementing the change, explicitly state:
- the architectural layer where the change belongs
- whether the change risks violating any constraint listed above
If a violation is identified, stop and explain the risk.
If no violation exists, implement the minimal code change required, ensuring the system’s architectural shape remains intact.