引言一个让人抓狂的循环我维护着一个 Agent Skill——一份告诉大模型你是谁、该怎么做、什么不能做的 system prompt。它驱动一个数据质量异常检测 Agent每天自动分析数据、生成报告、定位问题客户。Skill 上线后很快暴露出一个问题模型会反复违反写得清清楚楚的指令。 工具选错、被禁字段照样输出、四个维度不能遗漏的规则下某个维度因为经常正常就被悄悄跳过。我的应对方式是接入一个自动修复工具每次发现 badcase把问题喂给它它自动分析原因、生成修复规则、更新文档、提交发布。我只看修复结果不审核文档本身——效率很高问题似乎在逐个被解决。但几十轮迭代后情况反而恶化了。Skill 从 400 多行膨胀到 1500 行同一条规则被写了 5 遍、8 遍散布在不同位置“严禁”、铁律层层加码——反复强调过的问题还是会出现。直到我终于打开文档从头读了一遍才发现它已经面目全非同一个意思换了四五种说法散落各处整份文档臃肿到模型根本读不动了。越强调文档越长文档越长注意力越分散注意力越分散违反越多违反越多再追加一遍。 一个完美的恶性循环。这促使我停下来想一个根本问题为什么模型不听话是它故意忽略还是有更深层的结构性原因再强调一遍真的有用吗如果没用正确的做法是什么01为什么模型不遵循指令1.1****原因一“迷失在中间”——注意力的 U 形曲线Stanford 的经典论文 Lost in the Middle 揭示了一个关键事实LLM 对输入序列的注意力分布不是均匀的而是呈 U 形曲线——开头和末尾的内容获得最多关注中间区域容易被遗忘。实际数据开头指令约 73% 遵循率末尾略低但仍可靠中间区域遵循率下降 30%–50%。根因在于 Transformer 的位置编码机制——两个 token 距离越远注意力越弱。我的 Skill 正是如此300 行时关键规则在前 50 行模型几乎不犯错。膨胀到 1500 行后前 50 行没动但后面多了 1400 行中间内容注意力被严重稀释——犯错频率明显上升。1.2 原因二隐性冲突——模型的静默择一当 Skill 中多条指令之间有微妙的张力模型不会报错而是静默选择一条遵循、丢弃另一条。研究显示即使是顶级模型在指令冲突场景下的解决失败率也在 23%–47% 之间。我的 Skill 中就有这样的冲突规则 A“分析必须覆盖四个质量维度”规则 B“只对有异常的维度展开正常维度不展开”当某个维度长期稳定在 99.9% 时模型认为规则 B 说不展开→直接跳过。它不是忘了规则 A而是规则 B 给了它一个合理的跳过理由。1.3 原因三训练偏差——模型有自己的本能LLM 在训练阶段形成了一些内隐的行为倾向会和你的指令对着干倾向于输出建议训练语料中大量 QA 以建议结尾模型会本能地在分析后追加建议即使你说了禁止给建议倾向于关联相关概念分析归因失败时模型自动联想到ID 映射即使你明确禁止——因为训练数据里这两个概念总是一起出现倾向于有用模型的优化目标鼓励它多给信息被要求过滤不展示时有天然的抵触这类问题特别棘手因为你越说禁止模型反而越需要先激活那个被禁概念——心理学中叫粉红大象效应。LLM 有类似的机制否定指令反而提高被禁内容出现的概率。1.4 原因四上下文窗口的淘汰赛多轮对话中当上下文窗口接近满载时早期的 system prompt 内容会被截断或压缩。你精心撰写的 1500 行指令到对话第 5 轮时可能只剩一部分还在有效上下文中。这解释了为什么第一次提问表现完美多问几轮后又开始犯错——不是它忘了是那些规则已经被挤出了注意力窗口。02为什么修复工具总是选择再写一遍回到我的经历。每次发现 badcase自动修复工具的处理方式几乎一模一样生成一段新规则追加到文档中。理论上它应该先通读全文找到已有规则分析根因——是措辞不清位置不对还是和其他规则冲突然后选择最小化修改方案。实际上它做的只是读到 badcase 描述生成一段新规则插入到一个它觉得相关的位置。它选择了最安全的路径追加。不碰已有规则万一改坏了呢不分析位置问题那需要理解注意力机制不做全局审视上下文预算不够扫描 1000 行文档。这不是个别工具的问题而是当前 LLM 在修改长文档上的结构性短板局部视角 vs 全局视角修复工具聚焦于这个 badcase 怎么解决很难对长文档做全局语义扫描安全追加偏好训练数据中追加内容远比修改中间段落更常见、更安全没有文档健康度概念它不知道最优长度是多少不知道重复本身是一种坏味道自动化移除了天然刹车手动修 Skill 时人的懒惰反而是膨胀刹车。自动修复把它拆掉了——每次 badcase 都被勤勤恳恳地转化为新规则回溯 git 提交历史膨胀过程很清晰阶段行数发生了什么初版~400核心规则清晰10 次修复~650关键禁令各被追加了 2-3 次25 次修复~1000部分规则出现 3 个版本分布在正文、报告模板、下钻详情40 次修复~1500同一条规则最多出现在 8 个不同位置40 次修复追加了约 1100 行平均每次 27 行——每次都是一小段但累积就是原文的 2.75 倍。其中真正的新知识可能只有 300 行剩下 800 行都是重复表述。任何基于提取经验→自动追加规则的反馈系统如果不做额外约束都会重蹈覆辙。03工程化解法既然再强调一遍不是答案那什么才是3.1 解法 1分层架构——位置即优先级将 Skill 视为有层次结构的文档位置决定优先级[第 1 层] 全局不可违反规则最前面20-50 行以内 ├── 工具选择规则 ├── 数据过滤规则 └── 全局禁令清单 [第 2 层] 核心方法论紧随其后 ├── 分析框架 └── 判定规则 [第 3 层] 执行流程中间区域允许适度遗漏 ├── 分析步骤 └── 维度下钻规则 [第 4 层] 输出模板末尾利用近因效应 └── 报告格式关键点全局禁令只在第 1 层写一次后续章节不再重复只做引用。禁令始终在最前面遵循率最高消除重复后文档大幅缩短中间内容也能获得更多注意力。实际效果从 1500 行精简到 300 行减少 80%核心就是这个分层策略——把散布在 8 个位置的同一条规则合并到开头。3.2 解法 2消除隐性冲突——规则要无歧义回到某个维度总被遗漏的问题根因是两条规则隐性冲突。修复方式是让优先级显式化❌ 模糊版本 - 分析必须覆盖四个维度 - 只对有异常的维度展开 ✅ 无歧义版本 - 总览表格必须包含四个维度的全部指标行无论是否异常 - 维度下钻只对异常维度展开但总览表不受此规则影响技巧当两条规则存在张力时明确标注各自的适用范围消除模型合理推理出错误行为的空间。3.3 解法 3正向指令替代否定指令多项研究表明模型对不要做 X的遵循率显著低于只做 Y。原因很直觉token 生成本质上是正向选择——选择下一个最可能的 token。负向指令只是微弱降低了不想要的 token 概率而正向指令会主动提升期望输出的概率。发现这个规律后我把整份 Skill 的全局禁令从一列严禁改造成了场景→正向行为→对应禁止项的三列表格场景✅ 正向行为执行这个对应禁止项报告结尾以数据表格结束最后一个元素必须是表格或数值不追加建议、推测IDMapping输出时跳过所有 idmapping 开头的字段不展示相关指标工具选择每条 SQL 执行前按表名前缀匹配工具不混用工具维度覆盖总览表格固定包含四性全部行无论是否异常不因正常而省略正向行为放在禁止项前面占更多篇幅。模型读到这张表时注意力首先落在该做什么上。禁止项变成简短的补充说明而不是主角。核心思路不要告诉模型别想粉红大象而是告诉它想一只蓝色的猫。3.4 解法 4结构化格式——降低理解成本表格、编号列表、明确的标题层级比大段自然语言描述更容易被模型扫描到❌ 难以遵循 查询这类表时用工具 A查询那类表时用工具 B 大部分场景都用 A只有需要查全量明细时才用 B... ✅ 容易遵循 | 表类型 | 使用的工具 | |--------|-----------| | 聚合表、明细表、维表 | 工具 A | | 全量明细表 | 工具 B |同样的信息量表格格式的遵循率显著更高。3.5 解法 5指令三明治——首尾呼应对绝对不能违反的核心约束采用三明治模式开头写一遍首因效应中间是正常的执行流程和上下文末尾再简要重申一遍近因效应注意只对最关键的 2-3 条规则使用此模式——否则又回到了到处重复的老路。三明治和无序重复的区别在于三明治是有意识地利用首因近因效应只在首尾两个注意力高峰区放置而无序重复是在中间区域堆砌。3.6 解法 6外置知识——给 Skill 减负Skill 膨胀到 1500 行很大原因是把所有东西都塞进去了——表结构、SQL 模板、报告格式、下钻规则……这些参考性内容不需要常驻 Skill。原则很简单规则类内容行为约束→ 留在 Skill参考类内容需要时查阅的知识→ 外置为引用文件这样 Skill 保持在 300-500 行的甜区把注意力预算留给真正重要的行为约束。但外置不是扔出去就完事了——我在精简 Skill 后做了一次参考文件审计发现了一个惊人的问题。3.7 解法 7参考文件一致性——教材不能和规则打架外置参考文件后一个容易被忽略的问题浮出水面参考文件本身可能在教模型犯错。Skill 说输出时跳过某类字段但 SQL 模板里几十处都在 SELECT 这些字段Skill 要求四个维度都不能遗漏但模板示例只覆盖了其中两个。模型一边读规则一边照着模板写——两个信号矛盾结果就是时灵时不灵。修复原则模板中彻底删除被规则禁止的内容注释掉也不行——注释也是 token模板示例必须完整覆盖规则要求的所有维度不给部分覆盖的坏示范关键格式差异如不同表的日期格式放到显眼的对照表中不让细节隐藏在角落一句话参考文件就是模型的课本。课本里的示例违反了规则模型就会在听老师的话和照课本做之间反复横跳。3.8 解法 8给自动修复加刹车如果你也用工具自动迭代 Skill一定要加防膨胀机制行数预算超过阈值时强制进入重构模式而非追加模式语义去重插入新规则前扫描是否已有语义相近的表述单次追加上限每次变更不超过 20 行超了就要考虑外置定期压缩每 N 次修复后强制做一次全局审视和规则合并这和代码工程中的技术债管理是一回事每次 hotfix 都在堆债不定期重构就会腐化。04写在最后这段经历让我得出一个反直觉的结论在 Prompt Engineering 中少即是多不是鸡汤是物理定律。注意力机制有固定的带宽。你往 Skill 里塞的内容越多每条指令分到的注意力就越少。重复一条规则 5 遍看似强调了实际上是在抢占其他规则的注意力配额。精简后的 300 行版本遵循率明显优于 1500 行版本——因为每条规则终于有足够的注意力去读懂了。如果你也在维护复杂的 Agent Skill不妨对照这个检查清单Skill 超过 500 行了吗 该分拆和外置了最关键的禁令在前 10% 吗 不在就赶紧移上去有隐性冲突的规则吗 逐对检查合理推理出错误行为的空间同一规则重复超过 2 次 说明架构有问题不是强调不够参考内容和规则分开了吗 表结构、模板不该和行为约束混在一起参考文件和规则一致吗 模板里有没有被禁止的字段示例覆盖完整吗自动修复有刹车吗 只会追加不会重构那就是一台膨胀机器Prompt Engineering 正在从写好一句话进化为设计一个系统。指令位置、注意力分配、规则层级——这些工程化思维比反复加严禁有效得多。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】