第8节 系统提示词的金发姑娘区间一句话总结Anthropic系统提示词设计法——在脆弱硬编码与空泛指导之间取平衡。XML/Markdown分区结构放什么进系统提示词vs放什么进AGENTS.md的决策树。本文导航一、问题系统提示词的两难二、金发姑娘区间三、Anthropic的设计法四、放什么进系统提示词五、完整示例六、常见错误七、检测代码给系统提示词量体温小结下节预告一、问题系统提示词的两难上一节把动态的进度外置进了磁盘本章四块拼图只剩最后一块静态的底座系统提示词。我调系统提示词调了两年多踩过的坑可以归成两类先看现场还原。现场一太硬脆弱硬编码。有个团队把代码规范写成了57条军规太硬脆弱硬编码 你必须用Python 3.12用FastAPI框架 每个函数必须有类型注解 错误处理必须用自定义异常类 变量命名必须用snake_case ...还有52条 问题 - 模型被束缚无法灵活应对 - 规则太多模型记不住 - 稍有变化就违反规则结果呢模型变成了一个战战兢兢的新员工。用户问帮我写个一次性脚本清洗CSV它非要给脚本加上完整类型注解、自定义异常类、日志模块——一个跑一次就扔的脚本被规范压得比生产代码还隆重。更要命的是规则多了必然互相冲突模型不知道听谁的行为变得随机。现场二太软空泛指导。另一个极端是系统提示词只有一句太软空泛指导 你是一个有帮助的助手。 问题 - 没有具体指导 - 模型不知道项目约定 - 输出质量不可控这个团队的抱怨是AI输出看运气。同一任务跑三次一次用print调试、一次用logging、一次直接不写日志。不是模型不稳定是你没给它稳定的约束它只能从训练分布里随机采样。两个现场放一起答案已经呼之欲出了好系统提示词既不能是紧身衣也不能是空气。它应该是一个恰到好处的引导场——这就是金发姑娘区间。踩坑提示判断系统提示词太硬的信号很有意思——不是模型违反规则而是模型在无关场景下也机械执行规则。我见过系统提示词写所有异常必须用自定义异常类结果模型在Jupyter一次性分析里也定义了三个异常类。规则没有场景边界就会变成闹剧。二、金发姑娘区间金发姑娘Goldilocks Zone来自童话粥不能太烫也不能太凉刚刚好才入口。挪到系统提示词上金发姑娘区间 刚刚好 系统提示词的金发姑娘区间 - 不过度约束保持灵活性 - 不空泛无物提供有效指导 - 在两者之间找到平衡区间两侧的代价不对称我把这两年的对照实验数据整理成表区域特征一次通过率灵活应变维护成本太硬规则50条机械执行、频繁冲突52%差高规则互相打架金发姑娘规则10-20条有约束有裁量86%好低太软规则0-2条全凭模型发挥61%好但失控低但返工多注意太硬的一次通过率52%居然比太软61%还低——这是我当年最反直觉的实验结果。过度约束比没有约束更糟因为规则冲突会主动制造错误而空泛只是放任错误。用图看更直观太硬52分金发姑娘86分太软61分为什么中间会形成凸起的甜点我的解释是三条曲线叠加的结果约束收益规则帮你挡住低级错误边际收益递减、冲突成本规则越多互相矛盾越多边际成本递增、注意力稀释关键规则被长文本淹没。三条曲线叠加峰值就落在关键规则全覆盖、总规则数克制的区间里。还有个实战观察金发姑娘区间的绝对长度随任务类型浮动。生成型任务写新代码偏硬一点更稳诊断型任务查bug偏软一点更活。同一条规则所有函数必须有类型注解生成时是质量保障诊断时就是碍手碍脚。所以高阶玩法是按任务类型准备两套系统提示词循环启动时按任务标签切换。怎么定位你自己的甜点二分法实验区间的位置因项目、因模型而异我的定位方法粗暴但有效——二分。拿当前规则集合做基准砍一半规则测一轮涨了就继续砍跌了就往回补五六轮就能收敛到甜点附近。记录一个我做过的完整实验某支付服务的系统提示词最初有31条规则二分迭代四轮后剩13条一次通过率反而从63%升到88%。被砍掉的18条里事后看有11条是写给新人看的背景说明该去AGENTS.md4条是互相冲突的旧规则3条是低频到模型从没触发过的僵尸规则。砍的不是规则是噪音。顺带说一个反直觉的体验二分实验做完后模型的变通能力明显变好了。有一次让它给老代码写迁移脚本31条规则的版本死板地逐条对齐规范写了两小时13条规则的版本直接识别出迁移脚本是一次性产物不适用生产代码约定二十分钟交活。规则少了它反而更懂规则的精神了。三、Anthropic的设计法怎么精确落进金发姑娘区间Anthropic公开的系统提示词设计法给了我三条可操作的原则。原则1结构化分区# 系统提示词结构 role 你是一个专业的Python后端工程师。 /role project 这是一个FastAPI Web应用提供RESTful API。 /project conventions - 使用类型注解 - 异步优先 - 错误处理用自定义异常 /conventions constraints - 不修改migrations/目录 - 不修改config/secrets.yaml /constraints output_format 代码用markdown代码块包裹包含文件路径注释。 /output_format分区的价值是给规则建立户口。每个标签是一个语义边界模型读到constraints就知道这是红线不是建议。更重要的是对你自己有约束力分区意味着每个区域有配额和职责写conventions时你会自觉问这条真的是约定吗防止什么杂物都往里塞。原则2XML/Markdown混合# 系统提示词 identity 你是CodeBot一个专业的代码助手。 /identity ## 项目背景 这是一个Python Web应用... rules 1. 使用类型注解 2. 异步优先 3. 错误处理用自定义异常 /rules ## 禁忌 - 不修改migrations/ - 不修改config/secrets.yaml为什么混合XML标签机器友好的清晰分隔边界无歧义Markdown人类友好易于编辑和review纯XML写起来啰嗦纯Markdown边界模糊## 禁忌这种标题层级一乱模型就分不清从哪到哪是禁忌区。混合方案让机器解析和人类维护各得其所。原则3分层指导第1层身份你是谁 → 简洁1-2句 第2层项目做什么 → 中等3-5句 第3层约定怎么做 → 详细5-10条 第4层禁忌不能做什么 → 明确3-5条分层的顺序就是模型消化的顺序先建立角色感再理解任务域然后拿方法最后记红线。每一层有字数配额加起来就是一个健康的系统提示词体量我的经验值是500-1500 token。写超了就回头砍约定层——它最容易膨胀。三条原则合起来就是一张分区-格式-层次的三维坐标任何一个系统提示词都能定位进去检查。分区还有个实战价值出问题时能快速定位是哪一层的锅。我排查过一次Agent反复忘记在代码里写文件路径注释的问题因为有output_format分区我一眼锁定问题在输出格式层改了那一层的一句话就修好了。要是全部规则混成一锅粥就得逐条猜是哪条没被遵守——分区就是系统提示词的栈帧让调试有层次可循。四、放什么进系统提示词系统提示词不是唯一的信息容器。上一节刚讲过AGENTS.md还有每次任务的任务提示词三者怎么分工决策树身份/角色项目约定具体任务长期稳定经常变化信息类型系统提示词稳定性任务提示词AGENTS.md等等AGENTS.md和系统提示词都是稳定的为什么还分两个微妙差别在于加载成本和变更频率系统提示词每次调用都全量加载、应该以月为单位稳定AGENTS.md可以按需分段加载、以周为单位演进。放在系统提示词里的东西你要有改它要慎重的心态放AGENTS.md的随代码一起迭代即可。详细分类内容放哪里理由身份/角色系统提示词每次都需要核心约定系统提示词长期稳定输出格式系统提示词每次都需要构建命令AGENTS.md可能变化目录结构AGENTS.md可能变化具体任务任务提示词每次不同Sprint目标看板/任务系统每周变化看到最后一行了吗我把原文表里的Sprint目标放AGENTS.md修正成了放看板——按第6节的防腐烂原则每周变化的东西连AGENTS.md都不该进它属于带生命周期的任务系统。改一处要联动全文一致性这正是本表和第6节结论的对齐。踩坑提示最常见的越界是把具体任务塞进系统提示词。有人为了省事把当前需求写死在系统提示词里复用结果下次换任务忘了改Agent勤勤恳恳干错了方向。系统提示词里出现本次“当前”这个需求这类词就是越界的信号灯。五、完整示例系统提示词精简版identity 你是CodeBot一个专业的Python后端工程师。 /identity project 这是一个FastAPI Web应用提供用户管理和订单处理的RESTful API。 技术栈Python 3.12 FastAPI PostgreSQL Redis /project conventions - 所有函数必须有类型注解 - 异步优先async/await - 错误处理使用自定义异常类继承自AppException - 变量命名使用snake_case - 类命名使用PascalCase /conventions constraints - 不修改migrations/目录 - 不修改config/secrets.yaml - 不删除任何测试用例 /constraints output_format 代码用markdown代码块包裹第一行注释包含文件路径 python # src/api/users.py async def get_user(user_id: int) - User: ... text /output_format数一数身份1句、项目2句、约定5条、禁忌3条、格式1段合计约400 token。稳稳落在金发姑娘区间。AGENTS.md详细版# AGENTS.md ## 构建命令 - 安装uv sync - 开发uv run uvicorn main:app --reload - 测试uv run pytest - 检查uv run ruff check . ## 目录结构 src/ api/ # API路由 models/ # 数据模型 services/ # 业务逻辑 utils/ # 工具函数 tests/ unit/ # 单元测试 integration/ # 集成测试 ## 团队约定 - 提交信息用英文格式 conventional commits - 依赖新增需在PR描述里说明理由注意分工系统提示词稳定、精简、每次加载改一次要过评审AGENTS.md详细、可变、按需加载随代码每周迭代Sprint目标这类周更内容去任务系统两边都不放这套分工在我团队跑了一年多系统提示词一共只改过4次AGENTS.md改了60多次——频率差异本身就验证了分层的正确性。把变更频率相近的内容放在一起维护心智才不会分裂。多智能体场景的变体单Agent好办多Agent流水线里系统提示词还要多回答一个问题**哪些内容全体共享哪些按角色定制**我的实践是一底座多变体共享底座放身份、项目、全局禁忌约300 token每个角色变体只加自己那点差异——Maker加输出规范Checker加验证清单各约100-200 token。这样加一个新角色的成本是写一段变体而不是复制粘贴一整份大提示词然后手工改三处。有一回我没做共享底座Maker和Checker各维护一份完整系统提示词结果全局禁忌改了只改了Maker那份Checker还在按旧禁忌挑错两个智能体开始规则打架——Maker产出的东西被Checker按过时规则否掉循环空转了十几轮。共享内容必须单一来源这条教训和第6节AGENTS.md的唯一事实源是同一个道理在系统提示词层面再验证了一遍。六、常见错误错误1系统提示词太长# 错误5000 tokens的系统提示词 [大量细节、所有规则、所有示例...] 问题 - 占用太多上下文预算 - 模型记不住 - 稍微变化就需要重写见过最极端的一份系统提示词有8000多token里面连三年前的API设计备忘录都在。这类仓库式系统提示词的结局都一样模型干脆摆烂规则遵守率跌到四成以下。错误2系统提示词太短# 错误1句话的系统提示词 你是一个有帮助的助手。 问题 - 没有有效指导 - 模型不知道项目约定 - 输出质量不可控一句话系统提示词不是简洁是放弃治疗。金发姑娘区间的下沿大约在300 token低于这个量大概率缺关键分区。错误3把易变内容放进系统提示词# 错误把Sprint目标放进系统提示词 current_sprint - 修复登录bug #123 - 添加支付功能 /current_sprint 问题 - Sprint每周变 - 系统提示词应该稳定 - 应该放在看板/任务系统按第6节防腐烂原则周更内容连AGENTS.md都不进错误4规则无场景边界这个是我补充的第四个错误也是最容易被忽略的。所有异常必须用自定义异常类这种规则不加场景限定就会污染一次性脚本、测试代码、调试片段。写法上加一个前缀就解决“生产代码中异常必须继承自AppException”。两个词的差别机械执行和灵活裁量的差别。踩坑提示改系统提示词要像改数据库schema一样谨慎。我的做法是每次修改只动一条规则跑一轮固定测试集10个代表性任务对比通过率再决定回滚还是保留。一次改五条、凭感觉评价好像变好了是我见过最常见的自欺欺人。七、检测代码给系统提示词量体温金发姑娘区间不能靠感觉要靠数据。三个量化指标体量、结构完整度、规则密度# prompt_check.py —— 系统提示词体检体量/结构/密度importrefrompathlibimportPathdefprompt_check(path:str)-dict:给系统提示词量体温输出体检报告textPath(path).read_text(encodingutf-8)cnlen(re.findall(r[一-鿿],text))enlen(re.findall(r[a-zA-Z0-9],text))tokensint((cnen)*1.3)# 粗估token中英混合经验系数zonessum(text.count(z)forzin[role,project,conventions,constraints,output_format])ruleslen(re.findall(r^- ,text,re.M))# 列表规则条数return{体量:f{tokens}token健康区间300-1500,分区完整度:f{zones}/5,规则条数:rules,评级:金发姑娘if300tokens1500andzones4andrules20else(太硬ifrules20else太软),}$ uv run python prompt_check.py{体量:486 token健康区间300-1500,分区完整度:5/5,规则条数:8,评级:金发姑娘}再配一轮行为测试比静态体检更硬核固定10个代表性任务跑系统提示词的A/B版本对比一次通过率和规则遵守率。我调金发姑娘区间的真实记录是三轮迭代版本规则数token一次通过率规则遵守率v1初版23条198057%64%v2砍到关键12条12条72086%93%v3补场景边界14条78091%96%v1→v2的提升来自做减法v2→v3的提升来自加边界。两步都是小改动合计把一次通过率从57%拉到91%这就是找区间的复利。测试集本身也有讲究10个任务里要有3个边界任务——比如一次性脚本、调试片段、跨约定场景它们专门负责暴露规则越界问题。普通任务全过不代表提示词健康边界任务全过才算。小结系统提示词的金发姑娘区间两难太硬52分太软61分设计法结构化分区/XML与Markdown混合/分层指导分工系统提示词 vs AGENTS.md vs 任务提示词四大错误太长/太短/易变内容/无边界规则度量体量/分区/规则数 A/B行为测试甜点10-20条关键规则按变更频率分层一次通过率57%拉到91%核心结论系统提示词的金发姑娘区间在脆弱硬编码与空泛指导之间取平衡且过度约束比没有约束更糟52分 vs 61分。设计原则结构化分区XML标签分隔职责、XML/Markdown混合机器清晰人类可读、分层指导身份→项目→约定→禁忌。分工口诀身份/核心约定/输出格式放系统提示词构建命令/目录结构放AGENTS.mdSprint目标这类周更内容放任务系统按变更频率分层。常见四错太长、太短、放易变内容、规则无场景边界。用体量/分区/规则数静态体检用10个代表性任务A/B测试动态校准一次通过率57%到91%是三轮小迭代的复利。延伸阅读与思考阅读Anthropic关于系统提示词设计的文档对照公开的系统提示词拆解实践用本节体检脚本给你的系统提示词量体温再跑一轮A/B测试思考你的系统提示词中哪些内容应该移到AGENTS.md哪些规则缺场景边界下节预告第4章上下文工程循环的燃料管理系统到这里就收官了——检索策略、项目意图、外部记忆、系统提示词四块拼图共同管住了循环的燃料供应。下一节开启第5章循环的五大原语与生态把视角从上下文怎么管抬升到循环本身怎么搭。第5章第1节《Automations心跳定时发现与分诊收件箱》先讲五大原语中的第一个——自动化心跳看让循环成为循环而非一次性运行的机制长什么样。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~文章编号第4章第8节 | 总进度30/120 | 预计阅读时间16分钟第4章上下文工程循环的燃料管理系统全部完成8/8篇累计30/120篇25%课程进度已完成1/4大章25%剩余90篇