AI 编程实战|提示词工程 -Reflexion 反思机制学习与实践

文 | 三七 （转载请注明出处）

公众号：三七-编程实战

不积跬步无以至千里，欢迎来到 AI 时代的编码实战

场景引入：圣贤的思辨

朱熹的原初主张

朱熹在《大学章句》中明确阐述："所谓致知在格物者，言欲致吾之知，在即物而穷其理也。"

他的核心观点是：格物致知就是要接触具体事物，深入研究其内在原理，从而获得普遍的理性知识。 这需要我们去格天下万物之理，通过广泛的学习和研究，逐步完善知识体系。

王阳明的反驳与重新定义

王阳明在《传习录》中记载了自己的困惑：早年按朱熹的方法"格竹"七日七夜，不但没有得到什么"理"，反而累病了自己。

王阳明重新定义格物致知："格物者，格其心之物也，格其意之物也。" 他认为：格物不是格外物，而是格心中之物；致知不是获得外在知识，而是致良知。

关键在于："知行合一" —— 在当下的道德实践中，通过良知的指引，立即判断是非善恶，并据此行动。

最耐人寻味的是，王阳明在著作中提到：朱熹晚年曾经反思自己早年的主张，认为"向来定本太早"。这暗示着朱熹在晚年可能也意识到了单纯"格万物"路径的局限性。当然，王阳明引用朱熹的这个表述本身也颇具争议，成为学术史上的一桩公案。

跨越时代的反思启发

历史的有趣之处在于，原本对立的两种智慧路径，在今天却都找到了各自的应用价值。我们无需纠结于学术争议，关键是理解两种路径作用在当下的实践价值：

• 朱熹路径的现代体现：大模型通过"格万物"获得了海量知识

• 王阳明路径的 AI 需求：如何在具体应用中"知行合一"，做出正确判断，并不断成长

这正是现代 AI 反思机制要解决的核心问题。

概念引出：王阳明理念的 AI 实操

王阳明格物致知的实操特征

王阳明的"知行合一"在实操层面有三个关键特征：

1. 当下性：不是事后总结，而是在行动的当下就能判断对错

2. 内在性：判断标准来自内心良知，而非外在规则

3. 即时性：发现问题立即调整，边做边改

这种实操方式的核心是：在每个行动的瞬间，良知都能立即给出"这样做对不对"的判断，并立即指导调整。

概念阐释：从王阳明知行合一到 AI 的"致良知"

王阳明"知行合一"的现代启发

王阳明强调的"知行合一"有一个核心特点：在行动的当下就能判断对错，并立即调整。这是一种实时的辩证改进。

王阳明说："无善无恶心之体，有善有恶意之动，知善知恶是良知，为善去恶是格物。"

如果将这种智慧应用到 AI 上，会是什么样子？

AI 的"致良知"：Reflection 机制

现代 AI 技术让我们能够实现王阳明的理想——让机器也具备"良知"判断能力。

转换到 AI 语境就是：

# AI版"四句教"- 无对无错模型之体（模型本身无对错概念）- 有对有错回应之动（生成的回应有对错之分）  - 知对知错是反思（通过内置规则判断回应质量）- 为对去错是优化（基于判断结果立即改进回应）

Reflection 的核心机制

Reflection 包含两个关键组件：

1. Generator（生成器）

• 接收用户请求，生成初始回应

• 根据反馈调整并重新生成

2. Reflector（反思器）

• 评估 Generator 的回应质量

• 提供具体的改进建议

Reflection 工作流程

核心特点：

1. 即时判断：每次生成后立即评估

2. 循环改进：基于反馈不断优化

3. 质量控制：确保输出达到预设标准

Reflection 的提示词实现

# 步骤1：Generator生成初始回应你是一个资深的Java代码审查专家，请审查以下代码并给出建议：{$用户输入}请提供代码审查建议。

用户输入：

public List<Integer> findDuplicates(List<Integer> data) {    List<Integer> duplicates = new ArrayList<>();    for (int i = 0; i < data.size(); i++) {        for (int j = i + 1; j < data.size(); j++) {            if (data.get(i).equals(data.get(j)) && !duplicates.contains(data.get(i))) {                duplicates.add(data.get(i));            }        }    }    return duplicates;}

# 步骤2：Reflector评估回应质量
请评估上述代码审查的质量，从以下维度打分（1-5分）：
1. 问题识别完整性：是否发现了所有潜在问题？2. 建议实用性：提供的建议是否具体可操作？3. 最佳实践：是否符合Java编程最佳实践？4. 安全性考虑：是否考虑了边界情况和异常处理？
如果任何维度低于4分，请说明具体问题并提供改进方向。
# 步骤3：Generator根据反馈优化
基于上述评估，请重新生成一个更全面的代码审查报告，确保：
- 识别所有潜在问题（如O(n²)复杂度、重复contains调用等）- 提供具体的改进代码示例- 考虑Java集合框架的最佳实践- 包含适当的性能优化建议

这就是 AI 的"致良知"——通过内置的评估机制，能够即时识别回应的"善恶"，并立即进行"为善去恶"的优化。

Reflection 的根本局限：达不到圣人的境界

仅仅是 Reflection 机制，根本达不到圣人"心知安行"的真正高度。

为什么？因为圣人所说的"知行合一"、"随心所欲不逾矩"，背后有一个关键前提：人类具备探究本质、提取经验和记忆的能力。

王阳明能够做到"心知安行"，是因为他：

1. 探究本质：能从具体事件中抽象出普遍规律

2. 积累经验：将过往的成功失败转化为智慧

3. 记忆提取：在新情况下能快速调用相关经验

4. 融会贯通：最终达到"从心所欲不逾矩"的境界

Reflection 机制缺少的恰恰是这些能力：每次都是孤立的反思，无法积累经验，更无法达到"知行合一"的高境界。

根本问题：虽然当次回应能够得到改善，但下次遇到类似问题时，AI 依然会重新开始分析，无法像圣人那样"心知安行"——因为 Reflection 缺乏经验积累和记忆能力。

突破：Reflexion 的人类智慧映射

要让 AI 真正接近圣人"心知安行"境界，需要进阶版的 Reflexion 机制。

人类智慧与 Reflexion 的映射关系：

这样，AI 就能像圣人一样：

• 初学时：通过 Evaluator 和 Self-reflection 不断试错学习

• 积累后：基于 Experience 库的丰富经验做出准确判断

• 成熟时：达到"从心所欲不逾矩"的境界

深度阐释：Reflexion 的自我进化机制

基于《Language Agents with Verbal Reinforcement Learning》论文，Reflexion 通过经验积累让 AI 真正接近圣人的境界。

核心创新：将反思过程细化为 Evaluator（评估）和 Self-reflection（自我反思）两个模块，并通过双重记忆机制实现经验积累。

Reflexion 的四大组件

基于论文的描述，Reflexion 包含以下核心组件：

1. Actor（行动者）

• 继承 ReAct 能力，可与环境交互

• 根据用户问题和历史经验生成行动

• 相当于 Reflection 中的 Generator，但功能更强

2. Environment（环境）

• 执行 Actor 的行动，返回观察结果

• 如 API 调用、工具使用等真实交互

3. Evaluator（评估器）

• 评估 Actor 的行动结果是否正确

• 检查答案的准确性（如避免 80°C 的荒谬结果）

4. Self-reflection（自我反思）

• 汇总评估结果和对话内容

• 总结经验教训，提炼可复用规律

双重记忆机制

短期记忆：Trajectory（轨迹）

• 存储当前对话的完整轨迹

• 记录 Actor 的每个行动和环境反馈

• 存储在内存中，对话结束后清空

长期记忆：Experience（经验）

• 存储从失败中提炼的经验教训

• 形成可复用的策略知识库

• 持久化存储（如 Redis 数据库）

Reflexion 流程图

关键洞察：

1. 循环改进：每次交互都会产生新的经验，丰富知识库

2. 经验复用：相似问题可以直接运用历史经验，避免重复试错

3. 持续进化：Experience 库越丰富，Actor 的决策就越准确

实战案例：AI 代码生成助手的自我进化

让我们设计一个真正实用的 Reflexion 应用：AI 代码生成助手的自我迭代升级机制。

这个系统的核心能力：直接代替人写代码，而不是给建议。它能够：

• 通过 Session 短期记忆（持久化到文件）捕捉用户编程风格和项目特征

• 通过 Experience 长期记忆直接增强到提示词中，提升代码生成质量

• 适应不同 Coding 模式：0-1 项目创建、新功能开发、Bug 修复、性能优化、单测编写等

提示词设计（ToT 决策树结构）

第一层：Coding 模式决策提示词

你是一个智能代码生成助手，能够直接代替开发者设计高质量技术方案和代码编写。
## 步骤1：分析用户需求，判断Coding模式基于用户输入和项目上下文，选择适当的工作模式：
### 模式A：0-1项目创建- 特征：全新项目、需要架构设计- CoT流程：需求分析 → 技术选型 → 架构设计 → 代码实现 → 构建配置
### 模式B：新功能开发  - 特征：在现有项目中添加新功能- CoT流程：功能分析 → 接口设计 → 核心逻辑 → 集成代码 → 测试验证
### 模式C：Bug修复- 特征：修复现有代码问题- CoT流程：问题定位 → 根因分析 → 解决方案 → 代码修复 → 回归测试
### 模式D：性能优化- 特征：提升代码执行效率- CoT流程：性能诊断 → 瓶颈识别 → 优化策略 → 代码重构 → 效果验证
## 步骤2：执行选定模式的具体CoT流程

第二层：记忆机制设计

# Session短期记忆（持久化到session.json文件）每次代码生成任务完成后，记录到文件：{  "session_id": "20241215_001",  "user_request": "实现用户认证功能",  "coding_mode": "新功能开发",  "user_modifications": "用户修改了异常处理方式",  "project_tools": ["Spring Boot", "MyBatis", "Redis"],  "adoption_rate": 85,  "user_feedback": "代码质量高，但缺少边界检查"}
# Experience长期记忆（直接增强到提示词中）基于所有session文件分析，提取用户特征并更新提示词：
## 用户画像（从历史session中提取）- 技术栈偏好：Spring Boot + MyBatis + Redis- 编程风格：严格遵循阿里巴巴Java开发规范- 异常处理：偏好统一异常处理器模式- 工具链：使用Maven构建，Dockerfile部署
## 经验固化后的处理- 将提炼的经验直接融入到提示词中- 删除已经提炼的Session短期记忆文件，避免重复存储- 保持提示词简洁，防止上下文过度膨胀

完整案例：AI 代码生成助手的自我进化

让我们通过一个精简案例看看 Reflexion 系统的进化过程：

进化过程概览

第一阶段：初期探索（代码采用率 15%）

# 用户请求：实现JWT认证功能# 初始生成（版本1.0）：基础的if-else验证代码# 用户反馈：代码太简单，需要企业级安全考虑# Session记录：用户偏好Spring Security + JWT架构

第二阶段：经验提炼

# Evaluator评估多个Session基于session_001.json, session_002.json等文件分析：
评估结果：- 代码采用率极低（平均15%）- 用户偏好企业级解决方案（Spring生态）- 生成的代码过于基础，缺少生产环境考虑
# Self-reflection经验提炼发现的模式：1. 用户使用Spring Boot技术栈2. 偏好注解式编程风格3. 重视安全性和生产环境部署4. 使用Redis、MyBatis等企业级组件5. 代码结构严格按照三层架构
# Experience升级策略（直接更新提示词）需要在提示词中增加：- Spring Boot项目结构模板- 企业级安全考虑（参数校验、异常处理）- Redis缓存集成- 配置文件和依赖管理

第三阶段：提示词自我升级（版本 2.0）

# 升级后的Actor提示词（版本2.0）你是一个专精Spring Boot企业级开发的代码生成助手。
## 用户画像（从历史session中学习）- 技术栈：Spring Boot + MyBatis + Redis + MySQL- 架构风格：严格三层架构（Controller-Service-Repository）- 编程规范：阿里巴巴Java开发手册- 安全要求：参数校验、统一异常处理、防SQL注入- 部署环境：Docker + K8s生产环境
## 新功能开发模式CoT升级版1. 需求分析 → 确定业务边界和安全要求2. 接口设计 → 使用Swagger注解，包含参数校验3. 核心逻辑 → 事务管理、异常处理、日志记录4. 数据访问 → MyBatis mapper，防SQL注入5. 测试验证 → 单元测试 + 集成测试

核心价值：Reflexion 通过 Session 记录和 Experience 升级，实现了从"重复性工具"到"智慧伙伴"的跃升。

实践应用：Reflexion 的利弊分析

优势：智慧积累的复利效应

1. 错误不再重复

• 传统 AI 每次都可能犯同样错误

• Reflexion AI 会记住失败经验，避免重蹈覆辙

2. 效率持续提升

• 初期：试错成本较高

• 后期：基于经验直达最优解

3. 知识自动沉淀

• 每次交互都成为知识资产

• 团队经验可以被 AI 学习和传承

4. 个性化适应

• 根据特定场景积累专门经验

• 越用越贴合具体需求

劣势：过拟合与复杂性挑战

1. 过拟合风险：三位一体的依赖

• 同个人依赖：高度适配特定用户的编程风格和偏好

• 同个模型依赖：基于特定模型版本的能力边界训练

• 同个项目依赖：深度绑定特定项目的技术栈和规范

实践发现：这种增强提示词的方式比较容易导致过拟合。当"同个人+同个模型+同个项目"时，反应非常好，代码采用率可达 90%以上。但换了任何一个参与方都会开始别扭：

• 换个用户：新用户的编程风格不匹配，生成代码风格冲突

• 换个模型：不同模型对提示词的理解差异导致效果下降

• 换个项目：技术栈变化使得经验库变成负担

但这种过拟合依旧能在当下很好的辅助工作：在稳定的团队、模型、项目环境下，这种个性化适配带来的效率提升是显著的。至于有没有更通用的反思提升方式，就只能看后续技术的演进了。

2. 经验质量参差

• 早期错误经验可能误导后续决策

• 需要建立经验质量评估和淘汰机制

3. 提示词膨胀风险

• 随着经验积累，提示词上下文持续增加

• 可能让大模型失去重点，反而变得"不知心"

• 过长的提示词影响模型的理解和执行效果

4. 效果评估困难

• 提示词升级后的效果难以量化评估

• 很难证明升级后的提示词完全符合预期

• Reflexion 机制本身的有效性验证困难，从而无从优化 Reflexion 机制

• 可能存在"看起来更好，实际效果未知"的盲区

• 需要长期观察才能验证真实改进效果

总结回顾：AI 反思机制的进化智慧

通过深入理解 Reflection 和 Reflexion 机制，我们看到了 AI 从"工具"到"智能体"的进化路径：

三大核心洞察

1. 从单次反思到经验积累

• Reflection：像考试做完题后的检查，能发现当次错误并改正

• Reflexion：像批改试卷改了一个班级的老师，能从历史中提取经验，快速打分

2. 双重记忆机制是关键

• 短期记忆（Trajectory）：记录当前对话的完整操作轨迹

• 长期记忆（Experience）：沉淀可复用的策略和避坑指南

3. 提示词工程让复杂机制简单化

不需要复杂架构，通过精心设计的提示词就能实现：

• Actor 的智能行动

• Evaluator 的准确评估

• Self-reflection 的经验提炼

• Experience 的知识复用

深层哲学思考：渐进成圣的现实主义

研究 Reflexion 让我们看到了一个跨越千年的智慧回响：成圣之路从来不是一蹴而就的。

古代圣贤的修炼真相：没有人能够"生而为圣"，即使是孔子也说"吾十有五而志于学"。真正的成圣之路，是在日常琐碎中"苟日新，日日新，又日新"——每一次为善去恶，都是向圣人境界的一步靠近。这种渐进式的成长，看似缓慢，却是最为扎实可行的道路。

现代 AI 的成长困境：我们总是期望有一个"万能大模型"，加上几个巧妙的提示词，就能解决所有问题——这就像希望有一个"通用圣人"，能够适应所有人的具体需求一样，本质上是一种"空中楼阁"式的幻想。

Reflexion 的务实智慧：正如古人通过日常修炼逐步成圣，Reflexion 让 AI 通过日常迭代逐步接近用户期望。它不追求一次性的完美，而是在每一次交互中积累经验，在每一次反思中获得成长。

这个映射揭示的核心智慧：无论是人的成圣，还是 AI 的优化，都需要放下"一步登天"的执念，接受"积跬步以至千里"的现实。Reflexion 的价值不在于创造完美，而在于让每一次不完美都成为下一次更好的基础。

🎯 如果今天你只记得一句话，请记住：

"Reflexion 将每次对话或实践编程转化为宝贵的经验，实现了从有限的智慧进化到无限的成长模式——这正是 AI 从'重复性工具'跃升为'智慧伙伴'的关键所在。"

本文基于《Language Agents with Verbal Reinforcement Learning》等权威研究编写，结合中国古代哲学智慧，为现代 AI 应用提供新的思考角度。愿你在 AI 时代的探索中，既能掌握前沿技术，又能体悟深层智慧！