架构修复时要不要给模型低级别提示

给模型补上「最好也改一下」的提示，它会把设计补完整，还是顺手改掉不该动的地方？CloudArchitect Lite 的作者围绕这个问题做了一次配对实验：同一份初稿，分别接受两种修复指令，再比较结果。

结论有用，但范围很窄：GPT-6 Luna 值得开启这类提示，另外两个模型还没有足够理由跟进。比结论更值得程序员借鉴的，是作者如何区分提示的收益、模型随机波动，以及修复带来的额外改动。

为什么低优先级提示也可能影响最终质量

CloudArchitect Lite 把自然语言需求转成 AWS 架构图，再用 25 条确定性规则检查。对于较便宜的模型，系统提供一轮修复：把检查结果发回模型，让它提交修正版。

原来的修复消息只包含 error 和 warning，不包含 info。后者覆盖静态加密缺失、缺少监控、Lambda 直连 RDS 而未使用 RDS Proxy、组件没有关联需求，以及需求之外的成本项。

这里的 info 是检查器的严重程度分类，不能直接理解成「没有实际影响」。模型看不到这些发现，就很可能保留原样。作者此前的基准测试里，GPT-6 Luna 的 44 份设计有 32 份遗漏静态加密。

但全部发送也有风险。模型可能为了满足建议，增加不需要的服务，或者改掉已经正确的连接。因此，实验组额外收到一句约束：符合需求就处理，否则保留，并解释原因。

还有一条 info 被刻意排除：「组件不在已验证目录中」。组件尚未确认，有时就是当前信息下最诚实的答案；强迫模型修复，反而可能诱导它编造服务。

提示是否应该进入修复流程，要看它能不能引导出有依据的改动。

同一份初稿修两次，才能少受运气干扰

分别生成两份设计，再比较两种提示，容易把初稿差异误认为提示效果。作者让每个任务先生成一份初稿，再从它分出两条修复路径：

• Arm W 只发送 error 和 warning，维持现有行为。
• Arm I 额外发送五条 info 规则，并附上按需求取舍的约束。

实验覆盖 Claude Haiku 5.5、GPT-6 Luna、Gemini 3.5 Flash-Lite，包含 22 个场景，每个重复 2 次，共 132 个任务、264 次修复，每个模型对应 44 份设计。

「改了不该改的东西」也被拆成可统计的操作。系统按元素 id 比较初稿和修正版，记录节点增删、服务替换、连接增删或重连、节点跨容器移动，以及需求关联丢失。涉及检查结果点名对象，或者补上明确要求的组件，例如为缺少监控添加 CloudWatch，算目标改动；其余算附带改动。另外统计修复后新出现的问题。

模型收到相同请求，也可能输出不同答案。因此，当初稿没有 info 时，两组会收到完全相同的修复消息，用两份结果的差异估计随机波动的基线。

作者还提前写好上线门槛：info 至少减少三分之一，error、warning 和通过率不明显恶化，附带改动不超出随机波动，新问题不明显增加，盲评分数不能降低，并公开额外成本。其中「明显」使用 90% 配对 bootstrap 区间是否排除零来判断。大白话讲，就是反复重采样这些配对结果，估计差异有多稳定。

为什么只有 Luna 开启了新设置

清理效果很直接。本轮实验里，Luna 在原有修复方式下，44 份最终设计有 31 份遗漏静态加密；加入对应提示后，降到 0 份。这里的 31 与前述基准中的 32 来自不同测试，不能混作同一组结果。Haiku 的 info 数量也从每份设计 0.40 条降到零。

三个模型都没有显示出附带改动或新增问题的明确上升，每份设计增加的成本低于 $0.001。不过，Luna 的「负载均衡器位于单个 Availability Zone」警告从 6/44 增至 10/44。它仍在统计噪声范围内，作者把它列为下一轮重点观察项。

真正卡住 Haiku 的是盲评。评审沿用 0.3 基准的配置：一个 Claude、一个 GPT、一个 Gemini，设计匿名，按 7 个维度评分，每个模型抽取 10 对设计。

Haiku 加入 info 后，中位盲评分从 2.43 降到 2.36；可逐对选优时，评审又有 8/10 次偏好加入 info 的版本。两项结果方向相反，样本又小，作者没有事后修改「盲评分不能下降」的门槛，因此保留 Haiku 的原有行为。

Luna 满足全部条件，成为唯一开启新设置的模型。Flash-Lite 的 44 份初稿只有 2 份触发 info，能观察的改善空间太少。没有修复轮次的高质量模型也保持原样。配置已进入 main，原文说会随下一版本发布，没有提供发布日期。

我的判断

我更认同这套验证方式，而不是把结果理解成「多给提示总会更好」。同一初稿分叉、设置随机基线、提前约定门槛，都能减少事后挑选有利结果的空间。相比直接把所有检查结果塞回模型，这种按模型配置的做法有更具体的证据支撑。

但「没有测出副作用」距离「没有副作用」还有差距。每个模型只有 44 份设计，盲评只有 10 对；配置修改，例如开启加密，没有计入改动，而元素改名却会被算成删除再新增。它测到的是特定定义下的结构变化，不能覆盖所有设计风险。模型评审也不能代替人类架构师。

评审本身还暴露了一个工程问题：Claude 曾输出合法 JSON，却用「Duplicate placeholder; see the first A entry」跳过部分场景。作者靠内容校验发现，一次重试修复了这些情况。四个较长的 Haiku 任务和三次评审调用还曾以「terminated」中断；配对设计让初稿失败同时影响两组，减轻了比较偏差。

整轮冒烟测试、132 个任务和包含一次重试的评审共花费 $6.88。这是一次有边界的小实验，尚不足以证明同样策略能推广到其他任务。

能拿来做什么

• 给 AI 编程助手回传检查结果时，可以区分必须修复与按需求处理的建议，并要求后者说明跳过原因，避免把所有建议都变成硬性任务。
• 比较两种修复提示时，保留同一份初始代码或设计作为起点，同时统计新问题和额外改动，别只看原问题消失了多少。
• 在 Node 等评测流水线里，除了校验 JSON schema，还要检查场景是否遗漏、结果是否重复、评审是否逐项完成。结构合法只是第一关。
• 想复现架构生成流程，可以准备 Docker，以及 Anthropic、OpenAI 或 Google 的 API key，运行原文提供的命令：

curl -fsSLO https://raw.githubusercontent.com/aliaksandr-liapin/cloudarchitect-lite/v0.3.1/compose.yaml && docker compose up

其中 v0.3.1 固定了配置文件版本；启动应用不等于复现整套实验，原文没有给出完整评测命令。