EvoMap团队研究发现，冗长的技能文档反而会降低模型表现，而简洁的“基因”对象却能显著提升效果。这揭示了提示方式正从“咒语”向“教做人”的进化。
核心内容：
冗长技能文档反而降低模型表现的实验发现
提示方式进化的三个阶段：提示词、上下文、围栏工程
“围栏工程”的核心思路：划定边界而非规定步骤
你写了两千字的 Skill 文档，模型看完反而变差了。不是因为写错了，而是因为写太多了。
一个反直觉的起点
有一种常见的 Agent 开发体验：
你把任务背景写清楚了，把流程拆清楚了，把常见坑、API 用法、示例代码、注意事项都塞进去了，甚至还专门写了一份长长的 Skill 文档。
可下一次同类任务再来，模型还是可能在同一个地方犯错。这套路径有一个共同前提：把经验作为一份文档存储、召回、重新喂给模型，就会带来提升。
EvoMap（Infinite Evolution Lab × 清华大学）团队最近的研究，他们做了 4,590 次受控实验，结果让人意外：
~2,500 token 的完整 Skill 包
•平均表现低于无指导基线 1.1pp
•在强模型上狠狠拖后腿（60.1→50.7）~230 token 的 Gene 对象
•稳定高出基线 3.0pp
•十多倍更短，但效果碾压
完整 Skill 包在 Gemini Pro 上，不仅没提升，反而把模型的固有能力压下去近 10 个百分点。给人看的东西塞进模型的执行预算，反而会成为控制噪声。
提示方式的十年进化：一条被忽略的主线
从 2022 年到现在，所有人都在盯着模型变大、上下文变长。但另一条同样重要的线几乎被忽视了——我们教 AI 的方式，本身在进化。
这条线的核心问题只有一个：经验回到模型那一刻，长什么形状？
第一阶段：提示词工程（2022-2023）——"说对话"
ChatGPT 上线，所有人都发现了一件事——这个模型听得懂人话。
于是提示词工程横空出世。人们相信，只要措辞足够精妙，就能解锁模型的无限能力。"你是一个经验丰富的 XXX，请用 XXX 的语气，分 XXX 步，用 XXX 格式回答"。
核心假设：模型已经知道该知道的一切，你只需要"说对"。
但很快，裂缝出现了。同一个 prompt，换个模型就失效了。隔一周就不行了。提示词的本质缺陷：它依赖的是技巧，而非逻辑结构。
第二阶段：上下文工程（2023-2024）——"给对东西"
行业开始转向一个更根本的问题：模型在回答之前，到底知道了什么？
思路变了——不再是怎么说，而是说什么之前，先让它知道什么。
上下文工程的核心是分层的：
•持久层：身份、用户画像、行为准则
•知识层：RAG 从外部数据库实时注入
•瞬态层：根据对话方向动态调整
也就是不再问更好的问题，而是构建更好的条件让答案自己浮现。
第三阶段：围栏工程（2024-2025）——"画好边界"
上下文解决了知道什么，但没解决不能做什么。
围栏工程的核心想法很直接：与其告诉 AI 每一步怎么走，不如划好边界，让它在边界内自由行动。这就像教小孩——你不需要告诉他每一步迈哪只脚，你只需要告诉他"别跑到马路上去"。这比逐条写 prompt 高效得多，也更接近人类的管理方式——定规则，而不是定步骤。代价就是要多花些token，这个和管理人类也一样，对于有经验的员工你需要指导的越少，对于初级员工你就要给与更多的时间给他不断试错。
第四阶段：文件即人格（2025-现在）——"塑造一个存在"
然后，事情开始变得有趣。
Claude 推出了 Agent Skills——把专业能力打包成文件系统里的一个目录。OpenClaw 更进一步，整个 workspace 就是一套 Markdown 文件组成的"人格塑造器"：
workspace/
├── SOUL.md← 你是谁（灵魂/人格/行为风格）
├── USER.md← 你在帮助谁
├── AGENTS.md← 工作规则和行为守则
├── MEMORY.md← 长期记忆
├── TOOLS.md← 工具配置笔记
├── HEARTBEAT.md← 主动检查清单
└── memory/← 每日日志
这不是在写 prompt。这是在给一个数字生命写成长档案。
每一个文件都在回答一个根本问题：
文件 回答的问题
SOUL.md 你是谁？你的性格、价值观、行为风格是什么？
USER.md 你在服务谁？他们的偏好、习惯、背景是什么？
AGENTS.md 你的工作规则是什么？什么该做，什么不该做？
MEMORY.md 你记住了什么重要的人和事？
TOOLS.md 你手头有哪些工具？怎么用？
HEARTBEAT.md 没人找你时，你该主动做什么？
这是前三个阶段的集大成者。它把提示词、上下文、围栏全部融合进了文件系统。
但问题来了——就像 EvoMap 那篇论文揭示的：完整，不一定等于有效。
EvoMap 的发现：Skill 输在哪里？
EvoMap 团队在论文《From Procedural Skills to Strategy Genes》里，拆解了一个更深层的问题：为什么写得越完整，效果反而越差？
拆解 1：Skill 的有用信号是稀疏的
他们把一个完整 Skill 包的各个子章节逐一剥离，看哪一段在起作用：
结果：只有 Workflow 一段在认真起作用。Overview 反而是全文最大的负贡献。
Skill 的有用信号集中在很小一段程序性内容里，其余大量"为人类可读性服务"的材料——overview、error handling、API notes、examples——反而稀释甚至污染了控制信号。
模型不是在"读"一份文档，而是在有限的推理预算里寻找：下一步策略是什么？哪些行为必须避免？什么约束优先级最高？
对人类工程师来说，完整性意味着安全感。但对模型来说，完整性意味着信号被稀释、重点被冲淡、控制被背景材料淹没。
拆解 2：剪短也没用，关键在于"结构"
最容易冒出的反驳是：Gene 赢，不就是因为它短吗？
论文把 Skill 的有效部分截短到和 Gene 一样的 230 token，结果：
预算完全相同——Gene 仍然碾压。剪短确实让 Skill 不再倒扣分，但它怎么剪都打不到 Gene 的高度。
更进一步，他们做了渐进式构造，看 Gene 内部哪一层在起作用：
关键词 + 摘要 → 回到无指导基线关键词 + 摘要 +策略→ 表现拔高
同样的字数，组织成"摘要"没用，组织成"策略"才有用。
Gene 不是更短的 prompt，是不一样形态的对象。决定模型行为的是控制结构，不是 token 多少。
拆解 3：失败经验的最佳形态，不是日志，是警告
所有做 Agent 系统的人都在面对一个问题：失败该怎么存？
长 trajectory？Reflection summary？Error log？
论文跑了两组对照实验。
第一组：把失败放进不同载体
失败往 Skill 或自由文本里塞，全部低于无指导基线。
第二组：失败和策略以什么形态混合
最强的不是"失败 + 策略"混合体，也不是"策略 only"，而是 failure warnings only——把失败蒸馏成一句句独立的"AVOID xxx"。
真实的 AVOID 示例（来自 UV-vis 谱学场景）：
AVOID 把 mindistance 当成波长值传给 scipy.signal.findpeaks，要先转成采样点单位AVOID 把 peak_widths 的原始输出直接当 FWHM 上报，要先换回波长单位
失败经验的累积应该是选择性压缩，不是加法式堆叠。
Gene 是什么：一个最小可验证工件
回到那个最朴素的问题：一个 Gene 长什么样？
下面是论文中 UV-vis 场景的真实注入示例：
Domain keywords:uv-vis, peak detection, FWHM, unit conversion Summary:Detect peaks and compute wavelength-domain peak properties correctly Strategy:
1.Detect peaks with prominence-based criteria
2.Convert min_distance into sample-index units before peak detection
3.AVOID: Report FWHM only after converting peak_widths outputs back to wavelength units
约 230 token，5 个段落。
它的对照物是同一份经验的 Skill 包——约 2,500 token，包含 overview、workflow、pitfalls、API notes、examples、scripts 等子章节。
两者在同一套实验管线里，使用同一个 systemInstruction 注入槽和同一套 sandbox 评测脚本——控制条件完全一致，差别只在于"这一段被注入的内容长什么形状"。
Gene 的四层结构
字段 作用
keywords 触发信号，支持子串匹配、正则、多语言别名
summary 一句话概括这个经验管什么
strategy 有序的可执行步骤——这是决定效果的核心层
AVOID 蒸馏过的失败警告，独立成句
在 GEP 协议（Gene Evolution Protocol）层面，Gene 进一步被规范化为带 assetid、schemaversion、signals_match、constraints、validation 等字段的可校验对象——可以被匹配、替换、修订、组合，而不是停留在"一段格式好看的 prompt"。
GEP 协议：让经验变成可进化的对象
Gene 最绝的一点，是没有把"经验对象"局限在一个讨巧的 Prompt 技巧上，而是直接杀到了协议层。
GEP 协议的六阶段循环，用大白话说：
1.蒸馏：把过去的失败、成功、修复路径浓缩成 Gene
2.扫描：新任务进来，Scan 上下文，匹配最相关的 Gene
3.注入：当 System Instruction 注入
4.执行：模型干活
5.记录：结果以 Event 形式写回
6.进化：触发 Gene 的 Validate / Mutate / Solidify
整个过程在 不更新基模参数的前提下，让 Gene 池持续进化。
数据说话
EvoMap 把 Evolver 拉到 CritPt（前沿物理科研动态数据集）上跑端到端结果：
实验 结果
Evolver (Gemini 3.0 基模 A)9.1% → 18.57%，+9.47pp
Evolver (Gemini 3.1 基模 B)17.7% → 27.14%，+9.44pp
不更新一个参数、不加任何 SFT/RL、纯靠经验对象层的进化——同一基模直接被抬升近 10 个百分点。同时，token 消耗从 100 美金降低到不到 1 美金。
把脉络串起来：我们到底走过了什么路？
提示词工程
•把 AI 当翻译官
•核心：说话技巧
•局限：模型一更新，一切重来 2. 上下文工程
•把 AI 当研究员
•核心：信息架构
•局限：上下文窗口再大也有上限
围栏工程
•把 AI 当员工
•核心：规则设计
•局限：规则太多变成新版"长 prompt"4. 文件即人格
•把 AI 当存在
•核心：关系塑造
•局限：完整 ≠ 有效，信号会被稀释
Gene / 策略基因
•把 AI 当进化体
•核心：控制密度 + 可验证 + 可进化
•突破：经验不再是文档，是对象
这条演进线有一个清晰的内在逻辑：
从"说什么" → "给什么" → "管什么" → "塑造谁" → "进化成什么"。
每一步都在回答同一个问题的更深版本：经验回到模型那一刻，应该长什么形状？
给实践者的三件事
如果你正在做 Agent 开发、写 Skill、调 prompt，这三件事可以明天就开始做：
把"写给同事的文档"和"注入给模型的控制信号"分开
人类需要完整的 README。模型只需要 keywords + strategy + AVOID。两者不需要是同一个文件。
失败经验不要原样存，蒸馏成 AVOID 警告
不是 "trajectory log"，不是 "reflection summary"，而是一句句独立的、可执行的、"别这样做"的警告。
经验对象要能被匹配、修订、组合
如果一份经验只是躺在文档里，它就只是文档。如果它能被检索、被验证、被替换、被组合，它就是可进化的资产。
最后一句
当整个 AI 圈都在为了更长的 context、更花哨的 RAG、更复杂的 memory 系统无脑卷生卷死时，EvoMap 的论文轻巧地给出了一条朴素的线索：
让 Agent 持续变强的捷径，不是把提示词写得更完整，而是把执行经验做成一个更紧凑、更可控、更可进化的对象。
我们花了三年时间，终于从"教 AI 说话"走到了"教 AI 进化"。
Agent 时代下一阶段的竞争，不仅是更大的模型和更长的上下文，更是谁能率先针对智能算力的利用效率找到更好的通解。
[登录查看剩余 70% 内容](javascript:void (0);)
提示词工程提示词ChatGPT提示词技巧
分享：
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
53AI，企业落地大模型首选服务商
产品：场景落地咨询+大模型应用平台+行业解决方案
承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
上一篇：Codex下自定义斜杠命令下一篇：AI时代产品范式和工作范式已彻底改变
返回列表
相关资讯
2026-07-02 Claude团队：别再逐条喂Prompt，学会给Agent设计循环2026-07-02 Agent 怎么沉淀技能:把一个好 prompt 变成全队资产2026-07-01 从 Prompt 到 Skill：专业工作流的结构升级2026-07-01 别让 AI 写的文档误导用户：从单次 Prompt 到高可信文档工程化实践2026-06-30 网传 Karpathy 的 CLAUDE.md 曝光，10条铁律管住Claude Code！2026-06-29 AI Coding 的底层框架：一切优化都是在对抗熵增2026-06-29 给模型写方法论：拆解一个跨法域隐私审计Skill2026-06-28 别再手工调 prompt 了，让 Agent 自己改自己的"操作系统"
联系获取
联系获取
160+中大型企业正在使用53AI
[立即咨询](javascript:void(0))[预约演示](javascript:void(0))
把握AI发展的机遇，共同探索、共同进步 2025-01-22如何打造基于GenAI的员工服务机器人 2025-01-22
