番外｜編程 Agent 寫一篇技術文章，為何反而能改進項目？

简介： 本文探讨技术写作如何破解AI与人类的“认知惰性”：通过让AI撰写结构化文章，倒逼其暴露隐含假设、引入外部方案、生成可验证问题，从而发现连续开发中被忽略的设计缺口。该方法已成功应用于AI导师项目，并为科研问题提炼、实验设计提供新路径。（239字）

目录

摘要

1. 事情从五篇技术文章开始

2. 为什么人和 AI 都会出现这种“惰性”？

2.1 人的惰性：认知吝啬鬼（Cognitive Miser）与最小阻力路径

2. 2 AI的“惰性”：概率分布下的高频模式滑落

3. AI 写文章和做项目，具体差别在哪？

4. 为什么文章能发现连续开发没发现的问题？

4.1 它把隐含的假设变成了必须解释的句子

4.2 它把外部方案带进了原来的搜索范围

4.3 它为下一轮 Agent 提供了更具体的任务

5. 这对科研有什么帮助？

5.1 把“项目有个功能”推进到“有个问题可以研究”

5.2 帮助选择基线、指标和失败案例

5.3 在多智能体方案没有超过基线时，重新检查问题定义

6. 2025—2026 年，类似问题有哪些新解法？

6.1 从执行轨迹提炼策略，让经验进入下一次行动

6.2 修改 Agent 的工具和流程，探索不同候选

6.3 开发之前，先把领域知识和约束写出来

6.4 自我改进以后，检查是否破坏了原来能工作的场景

6.5 回到项目，先根据停滞的表现选择动作

7. 如何把它放进实际开发流程？

8. 回到这次实践

参考资料

摘要

在 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 就能据此继续工作。

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 回到项目，先根据停滞的表现选择动作

进一步研究写作本身的作用，可以设计三组任务——常规评审、文章写作，以及同样要求查资料和找反例的问题清单。固定仓库版本、模型、工具和总预算，隐藏组别后比较问题复现率、有效修复、误报、回归与成本，再用未参与修改的样本检查迁移效果。

7. 如何把它放进实际开发流程？

一次完整的往返可以控制在六步。

1. 固定当前状态。 记录代码版本、项目目标、已完成检查和暂缓事项。
2. 要求解释实现。 回到代码说明用户操作、数据流和状态变化，并核对相关工作。
3. 列出待查问题。 为每条建议附上涉及位置、依据、适用条件和最小验证方式。
4. 按项目目标筛选。 优先处理明确缺陷，区分缺验证、设计选项和不适用建议。
5. 实施最小修改。 对照当前版本验证问题，再修改相关路径，检查收益及回归。
6. 让结果回写文章。 记录实现变化、失败案例和仍未验证的判断，供后续开发使用。

图 3　同一篇文章可以提出多种建议，只有一部分需要立即改代码

下面是一段可用于写作阶段的任务说明。

基于当前版本整理一篇技术复盘。

先阅读代码，再说明功能如何服务用户，以及关键数据如何传递。
比较相关论文或开源方案，标明来源和适用条件。
区分已经实现、已有验证、合理推测和未来设想。

对每条改进建议，给出代码或行为依据、受影响场景、
最小验证方法，以及成本和可能的副作用。
没有依据的问题可以留空，不要求凑足固定数量。

如果已有尝试持续失败，先检查执行轨迹中重复的策略和缺少的信息。
将验证过的经验整理成带来源、版本和适用条件的条目。
修改后复测触发问题及原来正常的相关场景，再决定是否保留。

本轮先交付分析与候选建议。下一轮按项目目标筛选后，
再验证并实施修改。实验结果应当能够支持或推翻建议。

每项建议都经过同一条检查路径——找到依据，复现问题，判断是否符合项目目标，再修改和复测。验证没有发现缺陷时，就更新文章中的判断。

8. 回到这次实践

我最初把这种体验理解成“让 AI 写文章，它的思路就跳出来了”。回看具体过程，文章让 Agent 把现有实现讲清楚，相关工作带来了新的比较对象，代码核查暴露了信息传递缺口，实际需求又筛掉了不适合教学场景的方案。随后，候选建议成为了可以执行和验证的开发任务。

第 5 篇中的反馈传递问题，最后能够落到请求组装、有效意见选择和任务状态更新上。科研讨论也可以从这里继续推进，比较不同反馈方式对后续指导的影响。

对我来说，值得持续使用的是这样的往返。每当准备在文章里写下一句“系统能够……”，就回到 Agent 和代码面前追问——这句话对应哪个具体场景，我们现在有什么结果可以拿出来？

项目案例：AI Tutor Engine（信科院智能助手）资源仓库链接github于此

W1413580489/Computer-Suience-From-Enrollment-to-Expulsion: 信科院智能助手（jnuxky.xyz）——暨南大学信科院学生王叔发起的校园 RAG 问答与 AI 项目制教学项目

参考资料

1. Bilalić, M., McLeod, P., & Gobet, F. Why good thoughts block better ones: The mechanism of the pernicious Einstellung (set) effect. Cognition, 2008. 论文摘要
2. Madaan, A., et al. Self-Refine: Iterative Refinement with Self-Feedback. 2023. 原论文
3. Shinn, N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. 2023. 原论文
4. Gou, Z., et al. CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing. ICLR 2024. 原论文
5. Huang, J., et al. Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. 原论文
6. Agrawal, L. A., et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. 首次公开于 2025，ICLR 2026；核对 v2，2026-02-14. 原论文
7. Zhang, Q., et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. 首次公开于 2025，ICLR 2026；核对 v3，2026-03-29. 原论文
8. Zhang, J., et al. Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents. 首次公开于 2025；核对 v3，2026-03-12. 原论文
9. Zigler, A. Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology. VibeX 2026；核对 v1，2026-05-06. 原论文
10. Tayebati, S., et al. Self-Healing Harness for Runtime Oversight of Agent Self-Modification. 预印本；核对 v1，2026-09-21. 原论文