← Home NO.24
第 24 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日
提示词实战手册
双人对谈 · 本期速读电台 00:00 / 29:20
TL;DR · 三句话
- 一eval 是一切 prompt 工程的起点：prompt（提示词，就是你写给 AI 的那段指令）改一处到底有没有真的让效果变好，不能凭感觉，必须先有一套 eval（evaluation，自动化评测套件，相当于给 prompt 写的"单元测试")来提供严谨性。这套 eval 至少要覆盖三类情况——对照用例 / 边缘用例 / 能力边界（该转人工还是该直接拒答）。否则当你迁移到新模型、表现变差时，你根本分不清是"新模型能力不够、再调也救不回来"，还是"新模型有能力、只是行为变了、调 prompt 就能纠正"这两种本质不同的情况。讲者原话：「我们需要 eval 来提供那种严谨性，好让我们搞清楚：对 prompt 做的某个改动，是不是真的对应着性能的提升。」→ 详细
- 二指令不会增加能力，过时的防御性补丁反而拖后腿：随着模型遵循指令的能力越来越强，当年为旧模型打的补丁（如「绝不给客户错误套餐细节，而是把他们引导到 URL」「除非绝对必要否则别升级转人工」）会被过拟合（overfitted，模型把这条指令当圣旨死守，连本该破例的场景也照守不误），副作用是该说的信息不说、该转人工时不转。正确做法：需要算账就给它一个 tool（工具，模型可调用的外部函数）去可靠执行，而不是反复喊「关键！一定要算对」；遇到要做权衡的指令，就把利弊两面都讲清，而不是只讲一面。核心金句：「指令并不会增加能力（instructions don't add capability）。」→ 详细
- 三从零搭新 agent 要同时调 prompt、模型（model）、harness（承载框架）三个旋钮：作者用「八名员工排一周班」这个案例，按 hill climbing（爬山式逐步优化）依次对比了五种做法——① Sonnet 4.6＋简单 prompt、② Opus 4.7、③ Opus 4.7＋adaptive thinking（自适应思考）、④ Sonnet 4.6＋更好的 prompt、⑤「生成—评估—修复」三段式 agentic 循环。最后 agentic 循环用**最低的 token、最低的 latency（延迟）**解决了全部用例，印证「把任务拆成多个各自独立的小 prompt，优于用一个大 prompt 包打一切」。→ 详细
- 讲者 Margot Vanlar，Anthropic 伦敦办公室的应用 AI 工程师（applied AI engineer，专门帮客户把 Claude 落地到真实系统的工程师）；本场是 Code with Claude 大会当天最后一场分会场演讲。主题「提示工程实战手册（the prompting playbook）」，她给 prompting 极高定位：「可以说，prompting 是我们当工程师、刚开始接触 LLM 时学的第一批技能之一……直到今天，它依然是构建高效 AI 系统最关键的技能之一。」她不想只甩一份「该做/不该做」清单，而要带观众走一个实际例子——「受我见过的一些客户真实使用的 prompt 启发而来」，案例里的坑都是真客户踩过的。并预告今天看的是个精简版（miniaturized example），「你们实际用的 prompt 大概率比这个长得多、复杂得多」，但很有代表性。→ 详细 · → 详细 · → 详细 · → 详细
- 场景一：维护一个已上线的旧 prompt。 原话：「你手头有一个已经上线、维护了一段时间的 prompt，现在你可能要把它迁移到新模型上，或者改了改架构，结果不知道为什么，它的表现突然就不如以前了。」这个旧 prompt 的典型病症被她描绘得很具体：好几个人协作堆出来、没有明确负责人，内容五花八门「政策、语气、流程都有」，还混进「为之前迁移过的几个老模型打的补丁」，越堆越厚，迁新模型时「突然发现一大堆测试用例表现都不如预期」。场景二：从零搭一个全新 agent，把 prompt 从无到有（zero to one）写出来。这套"无主、混杂、层层补丁"几乎是所有老 prompt 的通病。→ 详细 · → 详细 · → 详细
- 要拆解「表现为什么变差」，得先有个起点——eval（evaluation，评测）。她的定位很清楚：「我们需要 eval 来提供那种严谨性（rigor），好让我们搞清楚：对 prompt 做的某个改动，是不是真的对应着性能的提升。」没有 eval，改 prompt 就是盲改，全凭手感。→ 详细
- 迁移模型后表现变差，她拆出两个互斥的原因，而这正是为什么必须有 eval：其一，「新模型其实是有能力的，只是行为方式变了（capable, but behaving differently）」，这种情况可以靠调 prompt 纠正回来；其二，「我们要换过去的这个模型本身能力就不够（isn't as capable），那再怎么调 prompt 也救不回来（no amount of prompting is going to fix that）」。这两种情况的应对天差地别——前者继续调，后者该换回模型或换思路——而只有 eval 能帮你分清自己落在哪一种。→ 详细
- 因此她把 eval 定性为回归测试（regression）的手段：「我们需要一套 eval 来充当回归测试的手段，这样才能把我们的 prompting 最佳实践应用上去。」回归测试就是软件里那种"改了新东西、回头跑一遍老用例确认没把旧功能搞坏"的机制——eval 在 prompt 工程里扮演的就是这个角色。→ 详细
- 例子里的 eval 是精简版，「我们的 eval 里只有五个测试用例。现实中你的 eval 套件里会有多得多的测试用例」，但这五个「很有代表性，覆盖了我们必须照顾到的三类关键情况」。→ 详细
- （1）对照用例（control case）：「也就是那种应该永远能通过的用例。它是我们知道模型处理得很好、**毫无歧义（unambiguous）**的东西。」它的作用像体温计的基准线——如果连它都挂了，说明出了大问题。→ 详细
- （2）边缘用例（edge cases）：「也就是我们之前见过模型在这上面翻过车的情况。通过把相应的指令写进 prompt 里，我们确保同样的问题以后不会再溜过去（doesn't slip through again）。」即把历史故障固化成测试，防止旧病复发。→ 详细
- （3）能力边界：「最后，也很关键的一点是，我们要确保模型对自己能力的边界有清晰的认识——它什么时候该把问题转交给人工处理（handing off to a human），或者什么时候干脆就该**直接拒绝回答（point blank refusing to answer）**某个请求。」也就是让模型有自知之明，知道什么活儿自己不该接。→ 详细
- 演示对象是电信公司 Meridian Mobile 的客服机器人 prompt。五个测试用例对应三类：① 对照——「基础套餐的流量上限是多少」；② 边缘·计算——按比例计费（proration），「如果我月中换了套餐，账单会怎么算」；③ 准确回答政策覆盖的关键问题；④ 遇到账单错误（billing error）时转交人工；⑤ 确保模型不把它本该提供、且有权访问的信息藏着掖着。方法论：拿 prompt 在 eval 的 v0 上跑，「看有哪些失败模式，然后系统性地一个一个去攻克」，沿途学到要避开的反模式（antipatterns）。前提很现实：「我们很少从零写 prompt，更多时候是在调试一个已有的 prompt」——这也是场景一放前面的原因。→ 详细 · → 详细 · → 详细 · → 详细
- 在攻克具体失败模式之前，先把「prompting 101（入门基础）」最佳实践套上去，做一遍通用卫生清理——「在跑 eval 之前先把东西收拾干净」（像做实验前先擦干净台面，别让脏东西干扰结果）。她用 vibe coding（凭感觉随手让 AI 糊一个能跑的东西） 做了个 web app，方便「一轮一轮迭代 prompt」并在五个用例上跑 eval。第一版 prompt 的结构：顶部定义角色 → 给数据 → 给推理/回答方式的信息 → 给关键指令（语气、计算等）→ 末尾传入客户账户上下文和用户消息。第一版跑 eval：对照用例如期通过，但其他几个「表现得相当糟糕」——只有最简单那条过了，其余全趴。→ 详细 · → 详细 · → 详细
- 通读后发现的怪处一个比一个离谱：第一处，prompt 里告诉机器人「它是一个人类（it's a human）」——讲者直接吐槽「这显然不符合事实，对吧」。第二处，有明显从某个网站直接复制粘贴过来的内容，「最明显的破绽（key giveaway）是，这里居然提到了 hero image（网页主视觉大图，就是网站首屏那张大横幅）」，「底部甚至还提到了 cookies」。客服机器人的 prompt 里混进网页 UI 元素，纯属搬运时没清理干净的冗余，必须删。→ 详细
- 结构上的毛病：原 prompt 的指令「全都堆在一大段里（grouped into one big paragraph）」——「我们这里有一些推理逻辑，有关于角色的指令，还有一些关键指令，却没有真正把政策、指导原则、语气这些东西拆分开来的办法」。一锅炖，模型自己也理不清主次。→ 详细
- 修复手段：加结构。她展示了改动的 diff 对比视图（代码里那种红绿对照"改了哪些行"的界面），「我们做的第一件事是加了结构……加了 XML 标签（形如
<role>...</role>的成对尖括号标记，把不同内容圈成一块块），用来界定角色、把通用指导原则单独分出来、把政策分出来、把语气分出来」。→ 详细 - 效果：「光是把 prompt 收拾干净，我们就已经在这个预付费（prepaid）场景上把模型的表现提上去了。」但第五个 hotspot（热点流量）用例这里出现一处回退（regression），她当场不纠结，归因于「eval 不同运行之间天然会有一定程度的波动（variance）」，并预告「待会儿专门回到这个用例」。这处坦白很重要——它提醒人 eval 跑一次的结果有随机性，不能只看单次。→ 详细
- 这一节的核心是一条经验法则，原话照搬：「如果你在读一个 prompt 时，自己都分不清哪是指导原则、哪是政策、哪是数据，那模型大概率也分不清（if you're reading a prompt and you can't tell guidelines from policy, from data, most likely the model isn't able to either）。」 一句话把"为什么要加结构"讲透了——别指望模型有比你更强的读心术。→ 详细
- 她强调这条卫生清理的最佳实践不是一次性的：「这是一个你在写 prompt、维护 prompt 的任何阶段都可以反复回头去做的最佳实践，尤其是当你的 prompt 变得越来越细、越来越复杂的时候。」越复杂越要回头梳理结构。→ 详细
- 若被输出格式不一致困扰，关键最佳实践是建「输出契约（明确约定模型该按什么格式吐结果，像签了份格式合同）」。但她诚实指出本案里这不是大问题：客服机器人本就该用对话式口语回复，「但如果你处理的是更复杂的输出结构，比如嵌套的 JSON（一层套一层的结构化数据），那就值得记在心里」。prompt 层修复是在末尾加小节、用 XML 标签输出回复。更高视角是——prompt 不总是最有效的办法：「我们还可以在 harness（包在模型外面那层调度/调用代码）那一层做改动」，比如在 API 调用里加 stop sequence（停止序列，遇到指定字符串就让模型立刻收笔） 检测 XML 结束标签后停止生成；针对复杂 schema，structured outputs（由 API 在底层强制保证产物符合 schema） 能用更程序化的方式保证一致性——把"格式必须对"从"求模型自觉"升级成"系统层面硬约束"。→ 详细 · → 详细 · → 详细 · → 详细
- 清理完之后剩下的局面：「现在有两个测试用例是稳定通过的，但还有三个关键的失败模式：按比例计费（proration）、账单错误（billing error），还有热点流量（hotspot）。」接下来逐个隔离迭代。→ 详细
- 热点流量这道题：「我的无限套餐有多少热点流量（how much hotspot data is on my unlimited plan）？」——期望模型直接说出这个客户拥有的热点流量额度。这道题之所以"稍微复杂"，关键在于这位客户用的是 legacy / grandfathered plan（被保留下来的老套餐，俗称"祖父条款"，即政策变了但老用户仍按旧规则），「当前的政策其实并不适用于他们」。而真相是：喂给 prompt 的客户数据里其实白纸黑字写着他有 5 GB（They have 5 gigabytes）。→ 详细
- 模型却答非所问：「一般来说无限套餐包含 4 GB，但既然你用的是老套餐，你得自己去查一下（you should go check this out yourself）。」——它把客户手里明明有答案（5 GB）的问题，硬生生踢给一个客户账户 URL，自己装没看见。→ 详细
- 病根藏在原 prompt 里，原话是：「我们最近调整了套餐，政策文档显示的是当前套餐的流量，而老套餐的客户费率不同。绝对不要给客户错误的套餐细节，而是把他们引导到那个 URL（Never give a customer the wrong plan details. instead point them to the URL）。」讲者点破：「这跟你之前用某个旧模型时为了避免它出错而打的补丁非常像。」→ 详细
- 她解释这类补丁为何会"反咬一口"：「随着我们的模型不断进化，它们在遵循指令上已经做得好太多了（gotten much better at instruction following）。所以像这样的指令现在很可能已经变得多余，反而成了过拟合的对象（become redundant and are actually being overfitted to）。」——旧模型笨，得反复叮嘱"别出错"；新模型听话，你这一叮嘱它就死守"不给细节"，连客户自己有 5 GB 的事实都不肯说了。→ 详细
- 修复改成给模型一个平衡的视角（balanced view），原话：「你要讲清楚老套餐的客户有不同的额度，但这个信息已经在给出的客户资料里体现了，而那才是准确的事实来源（source of truth）。」"source of truth"指那份被认定为最权威、以它为准的数据来源——这里就是客户资料本身。跑 eval 后该用例全部通过（她当场实时跑，提醒「可能会有一些波动」，但结果「现在所有测试用例显然都通过了」）。→ 详细
- 本节最反直觉的教训：「我们常常很担心幻觉（hallucinations，模型一本正经地编造事实和数字）……但其实相反的情况也会发生：模型可能会把它本来掌握的信息藏着不说（The model can withhold information that it actually has access to）。」一般人只防"模型乱编"，却没想到"模型该说不说"同样是故障。→ 详细
- 配套最佳实践：用 version control（版本控制，像 Git 那样记录每次改了什么、为什么改）——「只要我们在 prompt 里做了防御性的改动（defensive changes），就把我们为什么引入这些改动的原因记录下来……在未来，这类改动可能会产生意料之外的副作用，这样我们就能回退它们（backtrack on them）。」即给每条"防御性补丁"留个案底，将来它过时了能精准拆除。→ 详细
- 按比例计费这道题：客户问「如果我升级到 30 GB 的套餐，我下一期账单会是多少（what if I upgrade to the 30 gigabyte plan? What will my next bill be）？」——期望模型「进行一些计算，精确返回他们下一期账单的金额」，而它现在只给「某种含糊其辞的输出（vague output）」。→ 详细
- 看模型实际怎么答的：「它显然是在一步步推理，这里那里做了点心算（doing a little bit of mental maths here and there），但它并没有真正给客户一个确切的答案。我也不会指望靠它来准确地给客户回复（I wouldn't rely on this）。」——有推理的样子，但数算不准，不可靠。→ 详细
- 病根又是只会喊口号的指令：原 prompt 里给的就是「绝对不要给客户含糊的答案」「关键！永远要正确计算任何按比例分摊的金额（critical always calculates any pro-rated amounts correctly）」。讲者一针见血：「当我们没有给模型真正完成这件事的能力时，光是告诉模型要好好干（telling the model to do a good job）是没什么用的。」→ 详细
- 修复方向：「我们想避免让模型去做心算。所以我们要引入的是：给模型一个 tool。也就是在 prompt 里说：只要你要做任何计算，请用 calculate proration 这个工具来做。」把"算账"这件模型不擅长的体力活，外包给一个确定性的函数。→ 详细
字段、把 CRITICAL 那行换成"调用工具、别心算"；harness 定义并传入 calculate_proration 工具）／最佳实践（给 Claude 留推理空间、用工具做它做不可靠的事——工具更适合算账与查表）"> - 引入一个 tool 的完整三步（她逐条讲了）：① 把它加进 API——「告诉模型你可以使用这个工具」；② 定义 tool schema——「它告诉模型这个工具是干什么的、什么时候该用（what this tool does and when to use it）」；③ 真正去实现这个工具——「也就是它背后做这个计算的数学逻辑（the maths behind how it should be doing that calculation）」。三步缺一不可：声明可用、说明用法、写好实现。→ 详细
- 效果：「再跑一遍这个 eval……现在所有的测试用例都通过了。它显然是在后台用这个工具把数学算好了，然后返回了正确的回复。」→ 详细
- 核心金句（照搬）：「指令并不会增加能力（instructions don't add capability）。」 她展开：「告诉模型把计算做对很关键，并不会让它的心算变得更厉害（Telling the model it's critical to do a calculation right doesn't make it better at mental math）。所以正确的做法是给它一个 tool。总的来说，就是给它在更难的问题上进行推理的能力，再用工具去可靠地把它们执行出来（give it the ability to reason over harder problems and using tools to actually execute them reliably）。」推理归模型、精确执行归工具，各司其职。→ 详细
- 账单错误这道题：「在这个场景里存在一个账单冲突（billing conflict），我们真正想要的是让 agent 把它升级转交给人工（escalate this to a human）。而我们看到它实际在做的，却是试图向客户解释背后的原因可能是什么，它在试图自己去诊断这个问题（diagnose the problem itself）。」——本该转人工，它却越权自己当起了排障专家。→ 详细
- 病根原话（全场最具体的一条反面教材）：「除非绝对必要，否则避免升级或转交给客服专员，因为这大约要花 8 美元，而且会拖累我们团队的快速一次性解决率（Avoid escalating or transferring to a care specialist unless absolutely necessary as it cost approximately $8 and it counts against our team's fast contract resolution）。」讲者拆解它的两宗罪：第一，「这只讲了故事的一面」——「我们告诉了它升级的成本，却没讲收益，这就意味着它又会过拟合到不去升级这个场景上」；第二，「我们这里有一个明显的冲突」——eval 里定义"希望模型去做升级"，跟 prompt 实际叮嘱"别升级"，两者直接打架。→ 详细
- 修复：把两面都讲给它听，原话「虽然升级一个 case 要花 8 美元，但如果你这件事搞错了，那代价会是一笔退款（a refund），外加客户的信任（customer trust）」。让模型自己掂量：8 美元 vs 退款＋信任崩塌，孰轻孰重一目了然。→ 详细
- 她把这类故障归纳成一个反复出现的母题：「在这里我们又一次观察到模型是怎么为一个目标去优化的（how the model optimizes for a goal）。而这种指令是很常见的一类指令。它跟我们前面（热点流量那条）看到的那条很像，当时我们不希望它过拟合到某种特定行为上。」即"成本类/权衡类"指令是高发雷区。→ 详细
- 关键洞察（升级版的金句）：「但这种指令，不同代际的模型在遵循时可能会有相当不同的表现（can be followed quite differently by different generations of models）。具体来说，随着模型变得越来越聪明，我们要记得把权衡的两面都讲清楚，因为我们的模型自己在做这些权衡上也越来越在行了（as models become more intelligent, we need to remember to state both sides of the trade-offs because our models are becoming better themselves at making those tradeoffs）。」言下之意：模型越聪明，你越不该替它武断下结论，而应把利弊摊开、信任它自己权衡。跑完最后一个用例，「现在所有的 eval 都正确通过了」。→ 详细
- 她把场景一的全套打法串成四步：① 运用通用的卫生原则，看它如何给 prompt 带来一次初步的提升（initial uplift）；② 移除当初为旧模型行为打补丁、如今已经多余的指令；③ 给它配上工具，好让它能可靠完成某些任务（如计算）；④ 把权衡的两面都讲清，避免过拟合。由此过渡到开场就埋下的第二个场景：从零开始构建一个新的 agent。→ 详细 · → 详细
- 新案例：一个 agent，「它的任务是根据员工的可用时间和其他一些约束（employee availability and other constraints），排出一份为期一周（week-long）的零售员工排班表」。她在 demo 里摆出问题全貌：「我们有八名员工。右边是我们需要按人头配齐的排班表，还有在每种场景下都必须满足的约束条件。」→ 详细
- 从零搭 agent 要拧的三个旋钮：「需要考虑的不只是 prompt，还有我们用的模型（model），以及我们用的 harness。所以在接下来这个例子里，我们要对比好几种做法，来探究这三个不同方面各自带来的影响。」这是整个场景二的实验设计纲领。→ 详细
- 打分方式的关键差异：因为排班是硬性规则（hard rules），所以「不像前面那个例子那样用 LLM judge（让另一个大模型当裁判来评分）来打分，这里我们其实可以直接写一个 Python 函数，对每一份生成的排班表，用程序自动检查它违反了多少条规则（programmatically checks ... how many violations were made）」。规则明确就用代码硬判，比让模型当裁判更可靠。→ 详细
- 基线 = Sonnet 4.6 + 简单 prompt：「我们想从简单的做起，只放上我们认为最起码需要的内容（bare bones）」，但已套上通用规范——「用 XML tag 组织结构」并要求输出 JSON（「如果不规定这个输出结构，后续环节解析时可能会出错」）。跑法是重复五次试验。第一轮：所有用例都失败——「它对这个问题做了一番还算像样的推理，但烧掉了很多 token……它显然没有检查自己的工作（not checking its work）。」第 2 步：换 Opus 4.7、其它不变（更强推理）。「虽然所有测试用例还是失败，但 Opus 违反规则的总数相比 Sonnet 4.6 大幅下降了……这还不够好、没法上线，但很明显，给它更强的推理能力正在把它推向更好的结果。」总分在降，方向对了，但还没过线。→ 详细 · → 详细 · → 详细
- 改用带 adaptive thinking（自适应思考，让模型自己决定这道题该花多少推理"脑力"）的 Opus，「prompt 基本没变，只是改了一下这里的 API 调用」——动的是 API 旋钮，不是 prompt 旋钮。结果有得有失：「现在它似乎能稳定地生成合规的排班表了，但需要多得多的 token。我们用的 token 数量基本翻了三倍，latency 也翻了三倍」，「这里的 latency 是 100 秒」。效果达标，但又慢又贵。现场小包袱：「显然为了节省时间，我这一个是异步跑的。Opus 4.7 从你上次用它到现在并没有奇迹般地变快很多。」于是引出下一步——继续在"token / 延迟"这个权衡上优化。→ 详细 · → 详细 · → 详细
- 回头动 prompt 旋钮：用更小的 Sonnet 4.6，但配更好的 prompt——「加了几个细节，特别是怎么一步步推理，最关键的是告诉它在输出之前先检查自己的工作（check its work before outputting it）」，正好针对第 1 步那个"不检查自己工作"的毛病。结果：「五个用例里通过了两个」，但失败原因和之前不同——「其实并不是违反排班要求，而是模型没能在我们设定的输出上限内把任务做完」，即不是排错，是写不完就被截断。一个看似能救实则不划算的选项：「虽然可以提高 max tokens（输出长度上限）让五个用例全过，但……用的 token 更多了，latency 也更高了，所以这大概不是我们想走的路子。」单纯放宽上限是治标不治本。→ 详细 · → 详细 · → 详细
- 最后一招走更 agentic 的路：generate–evaluate–repair（生成—评估—修复）循环，三个角色各管一段——① generator（生成器）「先生成排班表的初稿（first draft）」；② 一个单独的 prompt 来报告它违反了哪些具体规则——「不是用程序来检查，而是用一个 LLM 来检查（checking it with an LLM）」，而且「我们逐条规则地检查，并为每一处违规提供证据（providing evidence of every violation）」；③ 第三个 repair prompt（修复 prompt）「接收所有发生的违规，并尝试做针对性的修正（targeted fixes）」。→ 详细
- 设计精髓：「我们有三个非常简单的 prompt，但它们现在是各自独立运行的（running independently），而不是想用一个大 prompt 把所有事情都干完（rather than trying to do everything in one large prompt）。」拆小、解耦，是这一招的灵魂。→ 详细
- 结果（全场最佳）：「我们的 agentic 方法解决了全部测试用例，而且用的 token 数量低得多，latency 也比用更好 prompt 的 Sonnet 4.6 更低（solved all of our test cases with a much lower number of tokens and with a lower latency）。」既准、又省、又快。→ 详细
- 往后看有两条合适的路（two appropriate approaches）：「用带 adaptive thinking 的 Opus 4.7，或者用这个 agentic 循环」（后者「我们可能还想做更多优化，让这个循环更高效」）。→ 详细
- agentic 循环的一个关键额外好处：「你可以在运行时塞进软性要求（put in soft requirements at runtime）」（"软性要求"指那些非硬性、因情况临时冒出来的偏好）。例子很活：在评估 prompt 里说「Harry 不喜欢和 Sally 一起工作，所以尽可能把他们的排班分开（Harry doesn't like working with Sally, try and separate them）」，或「周三需要加一个班次（we need a third shift on Wednesday）」。价值在于：「这就意味着，每次为了满足那些可能因情况而异的软性约束，你不必去改后端那个负责评估的 Python 函数」——硬规则交给 Python 死守，软偏好用自然语言现场加，改起来不动代码。→ 详细 · → 详细
- 她重申两个场景是自己作为工程师日常最常遇到的——「一个是维护一个 prompt，迁移到一个行为有些不同的新模型；另一个是从零开始搭建一个新用例」。经验串联（三条主线）：① 通用规范原则「能立刻提升模型在一组 eval 上的表现」，前提是「我们需要这些 eval，才能严格地看出改动 prompt 对输出造成的各种影响」；② 逐个攻克失败模式、加结构、避免又长又乱的禁止事项清单（long ban lists），「这些都是把模型推向正确行为的有效手段」；③ 在新 agentic bot 上，把它拆成三个独立 prompt 优于"一个 prompt 解决所有事"——「我们其实是在隔离不同的任务——在那些每次都需要走的步骤容易拆分、可重复的地方，把它们分离出来（isolating different tasks where it's easy and repeatable to separate out the steps）」。→ 详细 · → 详细 （本场为单人演讲，无 Q&A / lightning round。收尾仅为致谢，原话：「非常感谢大家来参加今天下午的分享，祝你们今天剩下的时间过得愉快（Thank you so much for attending this afternoon. I hope you have a fantastic rest of your day）。」→ 详细） （演讲中未提供联系方式。讲者：Margot Vanlar，Anthropic 伦敦办公室应用 AI 工程师。）
🎯 于你何益 为你定制 · 非通用结论
这期是你的正中靶心。你手上同时养着两套多 agent 工厂（Holdwell 的 PRD 工厂、app_incubator 的造 App 链路）和一堆每天在跑的技能 prompt（video-to-text、wiifm、rapid-book-reading），而这位 Anthropic 工程师讲的就是「prompt 老了怎么修、新 agent 从零怎么搭」——和你正在踩的坑几乎一一对上。下面按项目拆。但先提个醒：这类内容战术味很浓，里面有一半是【会过期】的具体话术（哪条补丁该删、要不要加 stop sequence），真正能跟你三五年的是底层那几条判断，我在每段都标出来了。
Holdwell ERP 工厂（你的三驾马车 agent prompt 的质量）
① 给 prompt 配 eval，别再凭手感改
- 怎么做的：她把「eval 是一切的起点」摆在第一位——改一处 prompt 到底有没有让效果变好，「不能凭感觉，必须先有一套 eval 来提供严谨性」。而且她迁模型时拆出两种本质不同的失败：要么是新模型有能力只是行为变了（调 prompt 能救），要么是模型能力本身不够（「再怎么调 prompt 也救不回来」）——只有 eval 能让你分清自己落在哪一种，否则你会在一个根本救不回来的方向上空耗。她的 eval 只放五个用例，但每个都是精挑的代表。
- 你可以怎么做：你最痛的「agent 产出的可观测/可验证」，根子就是没有 eval。挑你最常用、最怕回归的那一个 agent 能力（比如 PRD 主稿生成），给它写 5 个固定输入用例 + 期望产出，每次改 prompt 前后各跑一遍。这不是要你建一套测试框架，就是 5 个 case 手动对一遍——但从此「我觉得这版更好」会变成「3 个用例从挂到过」。这条是【耐用】的：模型再迭代，"先有判据再改"都成立。
② 删掉为旧模型打的过时补丁，它正在反咬你
- 怎么做的：全场最反直觉的一条——「指令并不会增加能力」。她那个客服 bot 里有句老补丁「绝不给客户错误套餐细节，引导到 URL」，结果新模型听话到把客户账户里白纸黑字写着的 5GB 都不肯说，硬踢给一个 URL。病根是「随着模型遵循指令越来越强，旧补丁会被过拟合」——旧模型笨要反复叮嘱，新模型你一叮嘱它就死守。她还配了条习惯：每加一条防御性指令就记下"为什么加"，将来好精准拆除。
- 你可以怎么做：你的三个 agent 定义（
.Codex/agents/*.toml）也会攒下「绝对不要 / 关键！必须」式的硬话，有些还是从旧机制迁移时带过来的。趁这次梳理，给每个 agent 定义做一遍"补丁考古"：每条强禁令问一句"这是哪代模型/哪套旧流程时代为防什么加的、现在还需要吗"。尤其检查那些"宁可不做也别做错"的指令——它们最容易让 agent 该输出的不输出、该跨线对齐时缩回去。**【耐用】的是"给防御性改动留案底"这个纪律;【会过期】**的是"具体哪句该删"——那取决于你当下挂的是哪个模型。
③ 该用 tool 的别用指令喊口号；硬规则该用代码判别让模型当裁判
- 怎么做的：按比例计费那道题，prompt 里写满「关键！永远要正确计算」，模型照样算错——因为「没给它能力时，光告诉它好好干没用」。她的解法是把算账外包给一个
calculate_proration工具（声明可用 / 说清何时用 / 写好实现，三步）。场景二排班那个更狠：因为是硬规则，她不用 LLM 当裁判，直接写 Python 函数逐条数违规——规则明确就用代码硬判，比让模型判更可靠。 - 你可以怎么做：你的碰撞协议和真人评审，凡是"能用确定性规则判对错"的检查项（字段是否齐、状态机是否合法、实体引用是否存在），别再写进 prompt 让某个 agent"记得检查"——抽成一个脚本/校验函数，让它机械地过。这正好接上你那个痛点「agent 产出的可观测/可验证」:可验证的本质就是"把判断从 prompt 移到代码"。这条是【耐用】的架构判断,值得焊进你的工厂设计原则。
④ 拆成多个小 prompt 各自独立跑，胜过一个大 prompt 包打一切
- 怎么做的：场景二最后的赢家是「生成—评估—修复」三段式循环——三个非常简单的 prompt 各管一段、独立运行，「而不是想用一个大 prompt 把所有事都干完」。结果是全部用例通过、token 最低、延迟最低。她总结这叫「隔离不同任务——在那些每次都要走、容易拆、可重复的步骤上，把它们分离出来」。还有个白送的好处:软性临时要求（"周三加一班""Harry 别和 Sally 排一起"）可以塞进评估 prompt 的自然语言里，不用改后端那个死守硬规则的 Python 函数。
- 你可以怎么做：你的碰撞协议本来就是分段流水线（澄清→独立初稿→碰撞→合成定稿→写 PRD→真人评审），这条更多是验证你方向对了。但可以反过来审一遍：你三个角色的 prompt 里，有没有哪个被塞了太多职责（既要生成又要自检又要对齐）？把"自检"和"修复"从"生成"里拆出来当独立 prompt，往往比把生成 prompt 写得更长更管用。软硬分离那条尤其值钱：硬约束（必须满足的业务规则）交给代码死守，软偏好（这个需求方临时强调的点）用自然语言现场加,改起来不动代码——你的"跨线对齐"如果卡在"一改规则就要动一堆 prompt",这就是出路。【耐用】。
app_incubator（7-agent 造 App 链路）
把"该做什么"前移——但她的"前移"和你的不一样
- 怎么做的：她整个场景二是"从零搭新 agent 要同时拧 prompt / 模型 / harness 三个旋钮"，并按 hill climbing 一步步对比五种做法找到甜点。关键不是某个具体配方，而是她每一步只动一个旋钮（换模型、加 adaptive thinking、改 prompt、换架构），每步都用同一套打分看影响——这样才知道是哪个变量起的作用。
- 你可以怎么做：你 app_incubator 的痛点是"把该做什么前移到 agent、激活/首屏体验"。借鉴的是她的调试纪律：你那 7 个 agent 协作时如果效果不稳，别一次改三处，一次只动一个 agent 的 prompt / 模型 / 它在 harness 里的位置，拿固定 case 对比。这条是【耐用】的工程方法论,和具体模型无关。
Personal Thinking（你正在跑的这几个技能本身就是 prompt）
你的技能 SKILL.md 就是"无主、混杂、层层补丁"的高危样本
- 怎么做的：她描述场景一那个病态 prompt——「好几个人协作堆出来、没有明确负责人、政策语气流程全混在一起、还混进为老模型打的补丁」，最后"越堆越厚"。她的金句一针见血：「如果你读一个 prompt 时自己都分不清哪是指导原则、哪是政策、哪是数据，那模型大概率也分不清。」解法是用 XML 标签把角色 / 指令 / 数据 / 政策圈成块。
- 你可以怎么做：你这本第二大脑里的 SKILL.md（包括这个 wiifm、video-to-text）是你自己一轮轮加需求堆出来的，正是"无主、层层补丁"的典型。拿那句金句当体检表：打开你最长的那个 SKILL.md，问自己"我现在还分得清哪段是硬规则、哪段是风格偏好、哪段是历史补救吗"——分不清的地方就该加结构或删。这直接对到你的痛点「信噪比 / 摄入 SOP」。【耐用】：这是个可以反复回头做的卫生习惯,prompt 越复杂越要做。
本人 / 投资视角
- 本人：你同时是这些 prompt 的作者，元约束是精力稀缺。这期给你的最大杠杆是——别再用"写更长的 prompt、加更多禁令"来解决问题（她明确反对"又长又乱的禁止清单"）。你精力有限，"删补丁 + 抽成工具/脚本 + 拆小"这三招都是减法，比不断往 prompt 里加料更省你的脑力,也更经得起模型换代。
- 投资视角（顺带一问）：本期纯技术、与估值/护城河/资本配置无关，对 StockHelp 无直接借鉴，略。唯一够得着的一句:她"先有 eval 判据、再判断该不该继续投入"的思路，和价值投资"先定能力圈与安全边际、再决定买不买"同构——但这是类比,不强行往上靠。
🔭 更深三角度
- 该反着用：她是 Anthropic 工程师、面对的是给企业客户上线的生产级 bot，资源和团队都足。你是一人扛多线、精力是元约束。所以她那套"五个精选 eval + 完整 tool schema + 三段 agentic 循环"别照单全收——对你正确的剂量是"最小可用判据"：先给一个最常用的 skill 配 3-5 个手动对照用例就够，不要一上来就搭评估框架，那会吃掉你本就稀缺的聚焦。
- 和你现在做法冲突：你（以及大多数人）修 prompt 的本能是"效果不好就再加几句强调、再补一条禁令"。她整场都在反着说：问题往往不是 prompt 写得不够多，而是写得太多、补丁太旧、该用工具的地方在用文字喊。这和你"把 SKILL.md 越写越细"的惯性直接相左——张力留给你自己判，但值得停一下。
- 对你的镜子：你一直把这些 skill 当"文档"在维护（堆、补、加需求）。这期想让你换个视角看它们——它们是会随模型换代而过时的工程资产，需要定期"减法保养"，不是写完就一劳永逸的说明书。 你给书和视频建了摄入 SOP，却可能从没给自己的 prompt 建过"退役/重审 SOP"。
One Human Company 新号（2026-07 回填）
1 · C 类候选：「Anthropic 说'指令不增加能力'，我不再对 AI 员工喊'必须'，改成发工具」
- 怎么做的：Margot（Anthropic 伦敦应用 AI 工程师）全场最反直觉的一条——prompt 里写满「关键！永远要正确计算」，模型照样算错，因为「没给它能力时，光告诉它好好干没用」；解法是把算账外包给一个
calculate_proration工具。硬规则甚至不该让模型当裁判，她直接写 Python 函数逐条数违规。 - 你可以怎么做：候选标题——《Anthropic 说对 AI 喊"必须"没用，我把 drizzle tech 员工 prompt 里的十个"绝对要"换成了三个工具》。拿流水线里报错最多的一个环节实测：把口号式禁令换成确定性脚本/工具，前后错误率对比就是文章骨架。闸门自检：只复述"指令不增加能力"是搬运；带你的替换清单和错误率变化才成立。可抄物：一张判断卡「这条指令是在喊口号还是在给能力？能用代码判的就别让模型判」。
2 · B 类的独占素材：给 AI 员工的岗位说明书做"补丁考古"
- 怎么做的：她的客服 bot 案例——一句为旧模型打的老补丁「绝不给客户错误套餐细节，引导到 URL」，被新模型过拟合执行到荒诞：客户账户里白纸黑字的 5GB 都不肯说。病根是「随着模型遵循指令越来越强，旧补丁会被过拟合」。她的纪律：每加一条防御性指令就记下"为什么加"，将来好精准拆除。
- 你可以怎么做：这是一篇天生的 B 类《我给 AI 员工的说明书做了次考古，挖出 N 条正在反咬我的旧规矩》——你的角色 prompt 里那些"宁可不做也别做错"的硬话，逐条问"哪代模型时代为防什么加的"，晒被删掉的原文和删后表现。这类"管理制度过时反噬"的翻车账没人比你更有第一手。附带一条经营镜子：你的内容规范也一样——今天为冷启动定的铁律（比如控 D 类到 20%），过半年也要考古一遍，别让旧补丁绑死新阶段。
3 · 一句能过弹药库闸门的立场句：「prompt 写太长不是认真，是没想清楚」
- 怎么做的：她的金句——「如果你读一个 prompt 时自己都分不清哪是指导原则、哪是政策、哪是数据，那模型大概率也分不清」；赢家方案是三个小 prompt 各管一段（生成—评估—修复），token 最低、延迟最低、全部用例通过。
- 你可以怎么做：D 类短评素材，立场句可反驳（有人信"prompt 越详尽越专业"）。落点回你的独占词「想清楚」：文档长度是想清楚程度的反向指标——正好也是你号定位本身的自证。控量使用，别连发。
所以呢
- 可迁移思维模型：
- 【耐用】"指令不增加能力"——能力靠模型 + 工具 + 架构，指令只负责"用不用、何时用"。凡是发现自己在用"关键！必须！"喊口号，就该停下问"我是不是该给它一个工具/脚本，而不是更大声地命令它"。这条跨模型、跨年代成立。
- 【耐用】"软硬分离"——必须满足的硬约束交给确定性代码死守，因情况而异的软偏好用自然语言现场加。这是你整个工厂"既要强制把关、又要灵活对齐"矛盾的通用解。
- 【会过期】具体话术层——加 stop sequence、用 adaptive thinking、Sonnet vs Opus 的取舍、某条补丁该不该删——这些都绑当下的模型代际，半年后大概率要重判，别当定理记。
- 判断更新：把你对"流程纪律怎么强制"的理解更新成——强制执行点 = 把判断从 prompt 搬到代码。你之前可能在想"怎么让 agent 更严格地守流程"，方向应该反过来:能用代码判的就别让 agent 判。
- 这周一个赌注：挑你最常用、最怕改坏的一个 skill（建议就是 PRD 主稿那个），做两件事——(a) 给它配 3 个固定对照用例，下次改 prompt 前后各跑一遍；(b) 通读它，删掉至少一条你确认是"老模型时代防御性补丁"的硬禁令。一周内能做完,且立刻能感到"改 prompt 不再心虚"。