目录
2.1 人的惰性：认知吝啬鬼（Cognitive Miser）与最小阻力路径
摘要
在 AI 导师项目的开发中，我遇到过一种现象。功能做完以后，让 AI 继续优化，它经常沿着已有方案修补。但让同一个 AI 回到代码、查阅相关工作、写清楚系统的设计与不足，文章里却会出现此前没有认真讨论过的问题。再把这些问题交回开发流程，一部分就变成了实际修改。本文结合本系列第 5 篇及后续修订，讨论这种方法如何改变编程 Agent 的任务目标、检查范围与反馈来源，并说明它对科研问题提炼、实验设计和失败分析的帮助。
关键词 AI 编程、Agent、技术写作、上下文工程、反馈、实验设计
1. 事情从五篇技术文章开始
先进行一下前情提要，同时声明本文结合 AI Tutor Engine （信科院智能助手 · INFO SYSTEM) 项目进行说明，这个系列原本在拆解 AI 导师的交付物验收流程。写到后来，我发现文章除了介绍系统，也提出了一些值得回到代码里检查的改进意见。
于是，2026 年 10 月 20 日，我把一个问题交给了编程 Agent。问题大意如下。
这五篇文章里，对系统本身提出了一些修改意见，是否应该采纳？测试员也反馈了文字溢出、按钮容易误点、缺少代码时提示不清楚、简历生成质量差等问题。先读完代码，再讨论方案。
后续工作把文章建议、测试员反馈和代码核查放到一起，逐项讨论，再决定修改范围。其中一个具体案例，来自第 5 篇的 “验收后继续指导”。
原来的页面能够展示评审卡，数据库也保存了评审结果。但是，在 “已有指导会话—提交验收—继续指导” 的默认路径中，详细评审意见没有自动装入下一轮指导请求。这个问题容易被功能清单掩盖。系统已经有“评审”和“指导”两个模块，单独看都能运行。只有沿着学生的一次连续操作追问，才会发现两者之间缺了一次信息传递。
后续修订接通了当前评审反馈，同时处理新提交替换旧意见、任务切换和过期反馈等情况。“页面显示过”与“下一轮模型实际收到”，是两个需要分别检查的事实。
图 1 文章提出的问题，需要经过代码核查、范围筛选和修改验证
这里还有一个重要决定。讨论中曾出现加强证据要求的建议，我重新强调了“教学优先”——已有材料足以合理确认学生完成任务，就应允许通过。最终保留反馈传递、缓存隔离和明确误判修复，收缩了可能增加学生举证负担的方案。这轮修订完成了场景、离线回归和页面检查，外部模型及 GitHub 使用替代响应。
2. 为什么人和 AI 都会出现这种“惰性”？
2.1 人的惰性：认知吝啬鬼（Cognitive Miser）与最小阻力路径
人在做项目时，大脑倾向于走最熟悉的神经回路。因为全局规划（如架构设计）需要消耗极大的前额叶皮层能量。如果没有外力逼迫（比如老板发火、考试Deadline），人本能地会去写“不用动脑子的CRUD代码”，一个已经可用的方案会影响接下来的注意方向。
同时，Bilalić 等人的国际象棋实验发现，高手找到熟悉的好走法后，虽然认为自己仍在寻找更好的解，眼动记录却显示，他们继续关注与原走法有关的位置。这种思维定势解释了一个常见体验——我们可以投入很多时间，却一直在熟悉的几个位置上用力。1
2. 2 AI的“惰性”：概率分布下的高频模式滑落
大模型倒是没有这么多内心戏，这种表现出规划上的短视，根源来自于生成范式的问题，在，你没有提供提示词或者相关的规范/约束下，大语言模型更擅长接续已有的模式，而不是具备独立的长程全局规划能力，直接生成代码时，模型会顺着局部上下文产出语法通顺、局部合理的代码，这种逐段拟合统计分布的行为，会慢慢累积冗余逻辑，最终形成「每一段看起来合理流畅，但整体架构矛盾、复杂度失控」的现象，这看起来有点像是一种局部最优算法，但准确来说，是“滑向了统计学上的高频平庸解” ，毕竟大模型所追求的是通用的，防御式的，带安全检验的普通代码，同时在此，也表达一句通用，防御式的结论：就是这个结论，他没有经过充足实验认证，而是基于大模型原生问题，也正如上面所说，它可以通过提示词，规范等方法来解决
对编程 Agent，更适合从任务和反馈来分析。假如需求是“学生提交后返回评审结果”，测试只检查接口成功、字段完整、页面显示，那么这些检查通过以后，Agent 已经获得了足够的完成信号。
但是，“学生接着求助时，导师是否知道刚才为什么没通过”，可能从来没有成为必须回答的问题。
连续开发还要维护项目状态。旧需求、已否决的方案、当前代码和历史讨论需要保持一致。如果交接材料漏掉设计理由，新一轮 Agent 就可能重新采用已经否决的方案。这种停滞可以从两个地方检查。任务是否持续要求它改进同一个局部，反馈是否遗漏了真正影响用户的行为。技术写作把用户目标、模块关系和判断依据重新放到一起，为后续开发提供了新的检查入口。
3. AI 写文章和做项目，具体差别在哪？
持续开发通常从需求、文件和报错出发，决定下一步修改，编程 Agent 可能反复沿用同一种解决思路。即使局部修改不断完成，模块之间的信息传递、设计前提和用户的完整操作流程，仍可能缺少检查。需求不明确、状态记录不完整，以及验收标准覆盖不足，都可能让这种情况持续存在。
要求 Agent 基于代码、参考外部资料撰写技术文章，会改变它需要回答的问题。为了解释系统为什么这样设计、与其他方案有什么区别、结论有什么依据，它需要重新整理模块关系、核对隐含假设，并寻找尚未验证的场景。文章中的解释缺口，由此可能转化为下一轮开发中的具体检查和修改任务。
解释整个方案——它解决什么问题，模块如何配合，为什么采用这种设计，以及用什么结果支持判断。
这种任务变化，会让原来隐含的设计前提成为需要查证的问题。
例如，“评审接口成功返回” 满足了一项开发要求；要解释 “导师能够根据评审继续指导”，就必须沿着请求检查评审意见是否实际传递。可以理解为结构化写作提供了思考与检查的脚手架
| 维度 | 围绕当前功能持续开发 | 基于代码与外部资料撰写技术文章 |
|---|---|---|
| 任务目标 | 实现需求、修复报错，让当前功能达到验收要求 | 解释设计理由、比较替代方案，说明依据与适用边界 |
| 上下文组织 | 通常围绕相关文件、接口、运行结果和历史修改展开 | 按用户目标、模块关系、相关工作和验证问题重新组织材料 |
| 规划与检查范围 | 如果任务划分和验收要求较窄，容易持续关注局部实现 | 结构化问题有助于检查跨模块关系、设计前提和完整操作流程 |
| 发现问题的入口 | 报错、测试失败、用户反馈，以及主动开展的工程评审 | 解释不完整、代码与描述不一致、缺少对照或证据，以及外部方案带来的新问题 |
| 外部知识的作用 | 根据开发需要，查找接口用法、实现方案和故障原因 | 在明确要求并实际查阅资料时，引入不同设计、反例与测试条件 |
| 反馈如何进入下一轮 | 依赖任务记录、测试、提交说明和交接材料保留经验 | 将发现整理为有依据、可验证的候选建议，再交给 Agent 筛选和实施 |
| 效果如何判断 | 检查功能行为、用户需求、维护成本和回归情况 | 检查文章提出的问题是否真实、修改是否有效，以及原有行为是否受到影响 |
文章结构在这里充当思考与检查的脚手架。设计部分要求整理模块关系，相关工作要求比较其他选择，验证部分要求给出可观察的结果。这些要求使 Agent 能够重新组织项目，再把发现的问题交回开发流程。写下来的设计理由和经验也成为交接材料。随着代码更新，同步记录版本、已解决问题和仍待验证的判断，下一轮 Agent 就能据此继续工作。
4. 为什么文章能发现连续开发没发现的问题？
4.1 它把隐含的假设变成了必须解释的句子
“评审后可以继续指导” 在功能列表里很简短。展开成文章以后，就要说清楚谁读取意见、读取哪次提交、什么情况下旧意见失效。这些问题一旦写出来，就能沿着请求和状态查证。此前看起来完整的模块组合，也就出现了可以定位的连接缺口。
4.2 它把外部方案带进了原来的搜索范围
查阅相关论文和开源项目，可以带来新的状态处理方式、测试条件或更简单的实现。原来反复调提示词的问题，可能需要改请求组装；原来想增加一个模型的问题，也可能先修缓存就能缓解。
比较时，可以要求 Agent 找到一个外部方案，说明它与当前实现的具体差别，再给出一个能检验这项差别的场景。
4.3 它为下一轮 Agent 提供了更具体的任务
“继续优化导师” 范围很大。“检查本次评审失败项是否进入下一次指导请求” 则能够指定输入、观察点与预期结果。对能够读文件、调用接口和运行测试的 Agent，这种问题可以直接转成工具操作。它由此获得新证据，再决定修改什么。
图 2 解释和比较产生待查问题，工具结果决定后续行动
5. 这对科研有什么帮助？
写这篇文章的初衷，也是跟人讨论到这个方法的有趣之处，我们无需进行多agent的评估，也不用通过新开窗口，切换模型等方法，来让AI跳出思维的惰性，我的朋友在科研工作中提出了一个想法，自己在进行多智能体协作的优化时，往往通用指标或特色指标都比不过基线，他初步判断这是因为过多的提示和约束反而让AI陷入进去，也许找一个相关的任务让基跳出来是一个可行的道路，只是还有待实验进行商榷。
5.1 把“项目有个功能”推进到“有个问题可以研究”
“把评审意见传给导师” 是工程改动。进一步追问，就能得到一个研究问题。
在其他条件相同时，提供当前有效的评审意见，是否能减少后续指导重复索取材料的情况？旧意见未及时移除，又会造成什么影响？
这里已经有可变化的因素、可观察的行为和可能失败的条件。写作帮助我们把宽泛的“导师更智能”，拆成可研究的具体问题。
5.2 帮助选择基线、指标和失败案例
围绕这个问题，可以考虑比较
“不提供详细意见”
“直接追加全部意见”
“只提供当前有效意见”
三种方式，再观察指导是否针对当前失败项、是否引用旧问题、是否重复询问已有材料，以及请求成本。实验可以分两层记录。先检查请求是否装入了正确意见，再使用固定样本和标注规则，评估真实模型有没有据此给出合适指导。
5.3 在多智能体方案没有超过基线时，重新检查问题定义
如果一个多 Agent 系统长期不如单 Agent 基线，写作可以要求它逐项说明每个角色带来了什么新信息、交接丢失了什么、协调增加了多少成本。由此提出的改进可能是新增角色，也可能是删掉重复角色、修正接口或保留更简单的基线。将每个角色的作用写清楚，有助于定位协调成本来自哪里，以及哪些角色值得保留。
实验前固定指标和比较方式，同时保留成功与失败样本。这样既能判断改动有没有收益，也能分析它在哪些条件下失效。
6. 2025—2026 年，类似问题有哪些新解法？
早期的 Self-Refine、Reflexion 和 CRITIC，分别探索了分轮自我反馈、文字经验复用与工具核查。2 3 4 关于内在自我纠错的研究也说明，缺少外部反馈时，重复审视推理答案可能造成退步。5 这些构成历史背景，近期研究则把优化对象扩展到提示词、记忆、工具和整个工作流程。
6.1 从执行轨迹提炼策略，让经验进入下一次行动
GEPA 于 2025 年首次公开，2026 年修订并被 ICLR 2026 接收。它读取运行轨迹中的推理、工具调用和工具返回，分析失败原因，提出并测试提示词更新，同时保留不同任务上有优势的候选。它与技术复盘的相似处，在于把具体执行经历整理成可测试的策略。6
ACE（Agentic Context Engineering） 同样在 2025 年公开，2026 年修订并发表于 ICLR 2026。它把上下文组织成持续更新的经验手册，通过生成、反思和整理，增量修改条目，减少整篇重写造成的经验丢失。对本文流程的启发是，长文章可以保留完整论证，实际交接时再提取有来源、适用条件和版本的经验条目。7
6.2 修改 Agent 的工具和流程，探索不同候选
Darwin Gödel Machine（DGM） 于 2025 年公开，本文核对了 2026 年 3 月修订版。它让编程 Agent 修改自身代码，维护多个候选版本，并借助编程基准评估改动。保留不同分支，使搜索不必每次只沿当前最优版本前进。工具和工作流程因此也成为可搜索的改进对象。考虑到计算与 API 成本，实际项目可以先用小预算比较少量候选。8
6.3 开发之前，先把领域知识和约束写出来
2026 年 5 月公开、被 VibeX 2026 工作坊接收的 Mise en Place for Agentic Coding（MEP），提出领域知识外显、协同形成设计规格、拆解任务三个准备阶段。它与本文的一个共同点，是将隐含判断整理成 Agent 可以使用的材料；时间点则放在实现之前。该论文报告的是单次黑客松案例，缺少对照组。9
6.4 自我改进以后，检查是否破坏了原来能工作的场景
2026 年 9 月的预印本 Self-Healing Harness，研究由外部运行层检查 Agent 提出的行为规则更新，验证后再允许长期保留。它报告了一些建议改善触发失败、却损害既有成功案例的情况。这提醒我们，反馈采纳以后仍需检查回归。10
图 4 近期研究中的方法及其在项目中的用法
6.5 回到项目，先根据停滞的表现选择动作
| 观察到的情况 | 可以尝试的动作 | 对应研究提供的思路 |
|---|---|---|
| 同一错误反复出现，但每次都从头分析 | 回看工具轨迹，提取具体规则，再比较更新前后表现 | GEPA 的轨迹反思与候选评估 |
| 换窗口后丢掉设计理由，摘要越写越空 | 按条目保存已验证经验、适用条件和失效条件 | ACE 的增量上下文管理 |
| 总在同一结构上微调，改进长期停滞 | 用小预算比较少量工具或流程候选，保留不同方向 | DGM 的候选归档与探索 |
| 实现很快，但需求理解偏差反复返工 | 先写领域约束、数据流、接口和任务依赖，再执行 | MEP 的前置准备 |
| 修好一个案例，另一类操作变差 | 复测触发案例与既有成功案例，再决定是否保留 | Self-Healing Harness 的外部验证思路 |
进一步研究写作本身的作用，可以设计三组任务——常规评审、文章写作，以及同样要求查资料和找反例的问题清单。固定仓库版本、模型、工具和总预算，隐藏组别后比较问题复现率、有效修复、误报、回归与成本，再用未参与修改的样本检查迁移效果。
7. 如何把它放进实际开发流程？
一次完整的往返可以控制在六步。
- 固定当前状态。 记录代码版本、项目目标、已完成检查和暂缓事项。
- 要求解释实现。 回到代码说明用户操作、数据流和状态变化，并核对相关工作。
- 列出待查问题。 为每条建议附上涉及位置、依据、适用条件和最小验证方式。
- 按项目目标筛选。 优先处理明确缺陷，区分缺验证、设计选项和不适用建议。
- 实施最小修改。 对照当前版本验证问题，再修改相关路径，检查收益及回归。
- 让结果回写文章。 记录实现变化、失败案例和仍未验证的判断，供后续开发使用。
图 3 同一篇文章可以提出多种建议，只有一部分需要立即改代码
下面是一段可用于写作阶段的任务说明。
基于当前版本整理一篇技术复盘。
先阅读代码，再说明功能如何服务用户，以及关键数据如何传递。
比较相关论文或开源方案，标明来源和适用条件。
区分已经实现、已有验证、合理推测和未来设想。
对每条改进建议，给出代码或行为依据、受影响场景、
最小验证方法，以及成本和可能的副作用。
没有依据的问题可以留空，不要求凑足固定数量。
如果已有尝试持续失败，先检查执行轨迹中重复的策略和缺少的信息。
将验证过的经验整理成带来源、版本和适用条件的条目。
修改后复测触发问题及原来正常的相关场景，再决定是否保留。
本轮先交付分析与候选建议。下一轮按项目目标筛选后，
再验证并实施修改。实验结果应当能够支持或推翻建议。
每项建议都经过同一条检查路径——找到依据，复现问题，判断是否符合项目目标，再修改和复测。验证没有发现缺陷时，就更新文章中的判断。
8. 回到这次实践
我最初把这种体验理解成“让 AI 写文章，它的思路就跳出来了”。回看具体过程，文章让 Agent 把现有实现讲清楚，相关工作带来了新的比较对象，代码核查暴露了信息传递缺口，实际需求又筛掉了不适合教学场景的方案。随后，候选建议成为了可以执行和验证的开发任务。
第 5 篇中的反馈传递问题，最后能够落到请求组装、有效意见选择和任务状态更新上。科研讨论也可以从这里继续推进，比较不同反馈方式对后续指导的影响。
对我来说，值得持续使用的是这样的往返。每当准备在文章里写下一句“系统能够……”，就回到 Agent 和代码面前追问——这句话对应哪个具体场景，我们现在有什么结果可以拿出来？
项目案例：AI Tutor Engine（信科院智能助手）资源仓库链接github于此
参考资料
- Bilalić, M., McLeod, P., & Gobet, F. Why good thoughts block better ones: The mechanism of the pernicious Einstellung (set) effect. Cognition, 2008. 论文摘要
- Madaan, A., et al. Self-Refine: Iterative Refinement with Self-Feedback. 2023. 原论文
- Shinn, N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. 2023. 原论文
- Gou, Z., et al. CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing. ICLR 2024. 原论文
- Huang, J., et al. Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. 原论文
- Agrawal, L. A., et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. 首次公开于 2025，ICLR 2026；核对 v2，2026-02-14. 原论文
- Zhang, Q., et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. 首次公开于 2025，ICLR 2026；核对 v3，2026-03-29. 原论文
- Zhang, J., et al. Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents. 首次公开于 2025；核对 v3，2026-03-12. 原论文
- Zigler, A. Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology. VibeX 2026；核对 v1，2026-05-06. 原论文
- Tayebati, S., et al. Self-Healing Harness for Runtime Oversight of Agent Self-Modification. 预印本；核对 v1，2026-09-21. 原论文
