## 01、痛点

我是老李。最近在给一个核心业务做架构方案评审时，遇到一件让人哭笑不得的事。团队一位同事用大模型直接生成了一份架构设计文档，拿过来一看，章节齐全、术语专业、图表也画得像模像样。但细读下去，问题就来了：没有限流策略，没有备份方案，多可用区只写了一句“建议部署在多个区域”，成本预估则拍脑袋写了一个数字。最要命的是，模型自己在文档末尾还加了一句“本方案已经过全面评估，具备生产级可靠性”。

这件事让我开始认真思考一个被越来越多团队讨论的做法：让模型对已有的结果进行批评和修正。官方示例里也专门提供了类似的反射实现，用模型对输出做二次评审。但问题来了：模型自己评价自己，到底靠不靠谱？为什么现在要讲这个？因为很多团队已经把它当成了默认动作，每个回答都多跑一次模型，成本翻倍，效果却未必更好。今天就把原理、实战和边界一次说清楚。

## 02、是什么

先给这个做法下一个定义。所谓反射机制，英文叫 Reflection，本质上是一个“生成 → 评价 → 修改”的反馈回路。具体来说，模型先根据需求产出一份结果，然后由另一个评估角色对这份结果从指定维度进行批评和打分，如果分数不达标，就把批评意见反馈给生成环节，重新生成，直到满足条件或者达到最大轮次。

这个思路和经典的“评估-优化”模式非常接近。在软件工程里，我们早就熟悉这种结构：开发人员写代码，测试人员挑毛病，开发人员再修改。只不过在反射机制里，生成者和评估者往往由同一个底层大模型担任，只是通过不同的角色设定和输入要求来区分职责。生成者负责创造，评估者负责找茬，生成者再根据反馈修改。

需要注意的是，反射不是简单地让模型“多看一遍自己的答案”。它必须引入明确的外部评价维度，例如安全、成本、可靠性、可维护性，并且要求评估器给出具体批评和量化评分。如果只让模型“你再检查一下”，通常效果很有限，因为缺乏明确的评价标准，模型很容易说“看起来没问题”。

## 03、为什么

为什么需要反射？核心原因是大模型单次生成存在明显的局限性。对于简单问答，一次生成通常足够；但对于架构方案、复杂代码、合同条款、安全策略这类高价值复杂输出，单次生成就像第一版草稿，表面合理但细节往往经不起推敲。模型容易遗漏边界条件、忽略真实的成本约束、或者把常见模板套用在不合适的场景上。

反射的价值在于把隐性的质量要求显性化。我们心里可能知道一份架构方案“应该具备高可用”，但模型不知道。通过评估器把这个要求拆成具体维度，例如“是否包含限流和熔断”“是否有多可用区部署”“是否有数据备份策略”，再逐项打分，模型就有机会发现自己遗漏了什么，并在下一轮补齐。

另外，反射的成本相对人工评审要低得多。一个资深架构师审一份方案可能需要半天，而模型评估只需要几秒钟。对于高价值输出，这种成本是值得的。但不能因此把反射当成万能药，这正是后面要展开讨论的关键。

## 04、架构

一个典型的反射机制可以抽象成四个部分。

第一是生成器。它接收原始需求和上一轮的反馈意见，生成一份新的结果。生成器可以是同一个模型，只是输入中包含了反馈。

第二是评估器。它接收生成器产出的结果，配合预先定义好的评价维度和打分标准，输出一个评分和具体的批评意见。评估器的输入设计非常关键，如果评价标准模糊，例如只写“评估方案质量”，评估器就很难给出有用的反馈。实际使用中，通常会把每个维度拆成若干子项，并要求逐项打分。

第三是循环控制。它负责判断评分是否达到阈值、是否超过最大轮次。如果达标，就结束并输出结果；如果未达标，就把批评意见作为反馈传给生成器，进入下一轮；如果轮次耗尽仍未达标，则转入人工评审或直接丢弃。

第四是最终输出。可以是达标结果，也可以是附带评估记录和未解决问题的半成品，供人工介入。

用一段伪代码表示这个流程：

```python
for i in range(max_rounds):
    draft = generate(requirement, feedback)
    score, comments = evaluate(
        draft,
        dimensions=['security', 'cost', 'reliability']
    )
    if score >= threshold:
        return draft
    feedback = comments

raise NeedHumanReview(draft, score, comments)
```

这段逻辑并不复杂，但实际效果取决于评估器的维度和标准是否合理。很多团队在这一步偷懒，只写一句“请评估这份方案”，结果反射流于形式。

## 05、实战

拿一个真实场景来演示。假设我们要设计一个电商订单系统的架构方案，要求是高可用、安全、成本可控。先让模型生成第一版方案。

第一版方案大概是这样的：前端通过负载均衡访问后端服务，后端使用无状态服务集群，数据库采用 MySQL 主从复制，缓存使用 Redis，文件存储使用对象存储。听起来很标准，但很多关键细节缺失。

我们把这份方案交给评估器，从三个维度打分：安全、成本、可靠性。每个维度 0 到 5 分，总分低于 12 分就判定不通过。评估器给出的批评可能包括：

- 安全：未提及 API 鉴权、传输加密、敏感数据落盘加密、SQL 注入防护，得 2 分。
- 成本：未考虑数据库连接数、缓存规格、跨可用区流量费用，也没有冷热数据分层，得 2 分。
- 可靠性：缺少限流、熔断、降级、备份策略、多可用区部署说明，得 2 分。

总分 6 分，不通过。反馈写回生成器。第二轮，生成器根据批评补上：增加 API 网关层的鉴权和限流，启用 TLS 传输加密，对用户敏感字段做应用层加密，增加 WAF，数据库改为多可用区部署，Redis 使用哨兵模式，增加每日全量备份和实时 binlog 备份。再次评估，安全 4 分，成本 3 分，可靠性 4 分，总分 11 分，仍差一点。反馈指出成本估算仍然没有具体依据。第三轮，生成器补充了按量付费、预留实例、冷热数据分层和缓存容量评估。最终安全 4 分，成本 4 分，可靠性 4 分，总分 12 分，通过。

这个例子说明反射确实能补上常见遗漏。但注意，评估器对“成本 4 分”的判断本身可能并不可靠——它并不真正知道云资源单价，也不清楚业务实际流量。这正是反射的边界。

## 06、洞见

这里必须回答一个尖锐的问题：模型自己评价自己，真的可靠吗？

答案是：部分可靠，但远非完全可靠。反射能提升的是“维度覆盖”和“结构完整性”，它更擅长发现“该写没写”的问题，而不是“写了但写错”的问题。例如，补充了备份策略，但备份策略是否真的能恢复数据？评估器很可能判断不了。补充了多可用区，但跨可用区网络延迟对业务的影响有多大？评估器也无法精确评估。

根本原因在于，评估器和生成器共享同一个能力边界。如果底层模型对某个领域的知识存在盲区，那么生成器会犯错，评估器同样会忽略。就像一个实习生写的方案，另一个实习生来审，可能两人都不清楚某个行业合规要求。模型还可能对不确定的事情表现出过度自信，给出看似有理但事实错误的评分。比如成本估算，模型可能编出一个听上去合理的数字，但和云平台实际价格相差很大。

此外，反射还有一个隐性风险：如果评估标准设计不当，模型可能学会迎合标准，而不是真正提升质量。例如只考核“是否提到限流”，模型就会在所有方案里机械地加上“限流”二字，却没有具体阈值或实现方式。这会导致一种表面合规、实际空洞的输出。

因此，反射可以提升部分复杂任务质量，但不能替代确定性的验证、测试和人工审核。确定性的验证包括单元测试、静态扫描、成本计算器、故障注入、安全基线检查等，这些工具不依赖模型的主观判断。人工审核则负责把握那些需要经验和责任兜底的环节。

一句话总结：反射是内审，不是外审。内审有用，但不能取代外部审计。

## 07、行动

既然反射有边界，我们应该怎么用？

第一，只把反射放到高价值复杂输出上。架构方案、安全策略、合同条款、复杂算法实现，这些值得多跑几轮。普通问答、摘要、文案润色，没必要增加第二次模型调用，因为成本和延迟增加，质量提升却很有限。

第二，评估维度要具体、可打分。不要写“评估方案质量”，而是写“从安全、成本、可靠性三个维度打分，每项 0 到 5 分，列出扣分原因”。维度越具体，反馈越可执行。

第三，设置最大轮次和达标阈值。一般 2 到 3 轮即可，超过这个次数往往收益递减。如果仍未达标，应该转入人工评审，而不是无限循环。

第四，在反射之后加一道确定性校验。例如用云成本计算器核算方案成本，用静态扫描工具检查安全配置，用故障注入测试验证高可用。反射负责查漏，确定性校验负责纠错。

第五，记录评估历史。每次评估的意见和修改过程最好留存，这样能分析模型反复犯的错，也能优化评估标准。

## 08、小结

反射机制本质上是“生成 → 评价 → 修改”的反馈回路，与评估-优化模式一脉相承。它能帮我们把隐性的质量要求显性化，在架构方案、复杂代码等高价值场景中提升完整性和常见维度覆盖。但模型自己评价自己并不完全可靠，它受限于自身能力边界，不能替代确定性验证、测试和人工审核。

真正成熟的做法，是把它当成一道内置评审工序，而不是质量背书。懂得什么时候用、怎么用、什么时候停下，比盲目叠加模型调用重要得多。

## 09、链接与概念说明

- Reflection：反射/反思，指让模型对已有输出进行批评和修正的机制，属于“生成→评价→修改”的反馈回路。
- Evaluator-Optimizer：评估-优化模式，将生成和评价分离，由评估器驱动生成器反复优化，与反射机制思路相近。
- 确定性验证：不依赖模型主观判断的检查手段，例如单元测试、静态扫描、成本计算器、故障注入、合规基线检查等。
- 官方示例：主流大模型平台的示例中提供了反射机制的参考实现，可查阅相关文档了解具体用法。
- 推荐实践：将反射作为复杂输出流程中的中间环节，而不是最终质量关卡，最终输出前应尽量经过确定性校验或人工审核。

我是老李。最近在给一个核心业务做架构方案评审时，遇到一件让人哭笑不得的事。团队一位同事用大模型直接生成了一份架构设计文档，拿过来一看，章节齐全、术语专业、图表也画得像模像样。但细读下去，问题就来了：没有限流策略，没有备份方案，多可用区只写了一句“建议部署在多个区域”，成本预估则拍脑袋写了一个数字。最要命的是，模型自己在文档末尾还加了一句“本方案已经过全面评估，具备生产级可靠性”。

《Spring AI 2.0实战》第17招 Reflection怎么做

模型自我反思机制通过“生成-评价-修改”回路提升复杂输出质量，但自我评价并不可靠，应只用于高价值场景并配合确定性校验。

架构师

人工智能

架构设计

后端

架构方案评审中模型自评的反射机制，能通过生成-评价-修改循环补齐高价值输出的细节遗漏，但评估器与生成器共享能力边界，无法识别事实错误。实际应用需限定高价值场景、明确打分维度、设置轮次上限，并配合确定性校验与人工审核作为最终质量关卡。

网络延迟

负载均衡

敏感数据

代码解释

单元测试

文件存储

对象存储

数据备份

软件工程

数据库

Redis

MySQL

2026上云采购 | AI焕新·智启新局

cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第17招 Reflection怎么做-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第17招 Reflection怎么做

《Spring AI 2.0实战》第17招 Reflection怎么做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐