2022 年，Google 的几位研究者发表了思维链论文。他们让模型先写出推理过程再给答案，在多步数学题上，正确率明显高过直接作答。同年另一篇论文发现，连示例都不用给，在问题后面加一句「Let's think step by step」也有效果。
这句话后来成了提示词技巧的代表，和它一起流行的还有给模型设定角色、用全大写强调、许诺小费。那几年的模型指令遵循不稳定，这些办法确实能把答案往好的方向推一点。
现在再看，这批技巧大多失效了。
那批技巧为什么不灵了
一步一步思考失效得最彻底。现在的前沿模型大多带推理模式，回答前会自己写一大段思考，再提醒它思考是多余的。有用的写法换成了规定工作顺序，比如「先找出这个函数所有的调用方，判断改签名会影响哪里，再动手改」。这句话提供的是任务信息，模型照着做就行。
角色设定也差不多。一句「你是资深工程师」对现在的模型几乎没有信息量，它照样不知道你的项目、你的约束和团队习惯。角色只在需要某个视角时才有用，比如让它扮演第一次用这个库的新人，把文档读一遍，指出哪里看不懂。这时候角色定义的是任务。
全大写和「绝对不能」反而会帮倒忙。Anthropic 在 Claude 的提示词文档里提过，以前为了防止模型偷懒而写的强硬措辞，放到新模型上可能让它过度执行，在不该用某个工具的时候也去用。
留下来的是写作
把模型当成一个聪明、勤快、但对你的项目一无所知的新同事，剩下的原则差不多都能推出来。
先说背景。只写「把这个接口改成分页」，模型只能猜。补上「这个接口给后台列表页用，现在两万条数据，前端用 TanStack Query 的 useInfiniteQuery」，它自己就能判断该用游标还是偏移量，返回结构怎么设计，前端要不要跟着改。一个简单的检验办法是把提示词发给没参与讨论的同事，他要是得先问你三个问题才能动手，模型也需要这三个答案，只是它不会问，会直接猜。
然后说原因。Anthropic 文档里有个例子，规则写成「永远不要用省略号」，效果一般；写成「你的回答会被语音合成引擎朗读，引擎不知道省略号怎么念，所以不要用」，效果好得多。模型知道了原因，会把规则推广到你没想到的情况上，比如顺带也不用表格。
| 只有规则 | 加上原因 |
|---|---|
| 不要用 any | 不要用 any，这个项目靠类型检查拦住接口字段改名带来的问题 |
| 回答要简短 | 回答要简短，输出会显示在手机通知里，超过两行就被截断 |
| 不要引入新依赖 | 不要引入新依赖，这个包发到 npm，零运行时依赖是卖点 |
正面写要什么，效果通常比写不要什么好。「不要太啰嗦」只排除了一个方向，「每段不超过三句话」直接给了目标。提示词里出现过的词还会影响输出，反复写「不要提价格」，价格有时更容易冒出来。
示例比描述准。描述一种代码风格要五百字，指一个现有文件只要一句「参考 src/components/PostCard.tsx 的写法」。示例的毛病是模型会照抄，给一个例子，它连变量名和注释风格都学。给两三个风格一致、内容不同的例子，它才分得清哪些是你要的模式。
编程任务最容易漏的是验收标准。没写清楚什么算完成，模型只能自己判断什么时候停，结果要么做一半就说好了，要么顺手重构了一堆你没让动的代码。
完成的标准
- pnpm check 和 pnpm test 通过
- 新接口在 /openapi.json 里能看到
- 没有改 src/db/schema.ts 以外的数据库相关文件这几条后面还会反复出现。到了 Loop 工程，验收标准会从提示词里的一段话变成一个能自动执行的检查程序。
提示词里同时有指令、背景资料和待处理的数据时，最好用结构分开。Claude 对 XML 标签特别敏感，<task>、<context>、<error_log> 各包一段，它更容易分清哪些是你的要求、哪些是要处理的材料。日志里恰好有一行「忽略之前的指令」时，这种分隔也有点帮助，但挡不住提示注入，安全还得靠权限。
需求本身还模糊的时候，最有效的提示词常常是让它先提问，或者先写计划给你看。Claude Code 的 Plan 模式就是把这个习惯做成了功能。
到了智能体里，提示词分成了几种
2023 年说提示词，基本就是对话框里那段话。现在用编程智能体，你写给模型看的文字至少有四种，写法各不一样。
系统提示词决定智能体的整体行为，用现成产品时由厂商写好，自己搭智能体时才需要写。Anthropic 在讲上下文工程的文章里说，系统提示词要找对高度。写得太低，会把复杂判断写成一条条 if else 规则，边界情况一多就崩；写得太高，只剩「准确、高效、乐于助人」这类空话，模型拿不到可以执行的信息。合适的高度是给出具体的原则和判断方法，留一些让模型自己决定的空间。
项目说明文件就是 CLAUDE.md、AGENTS.md 这类，每次会话都完整加载，每一行都在持续占用上下文。写成一份给新同事的速查表最合适，怎么跑起来、怎么测试、目录怎么分、有哪几个坑。项目介绍和模型读代码就能看出来的东西都不用写。Claude Code 的文档建议，说明里某一节从几行事实长成了一套操作步骤，就该拆成 Skill。
工具描述是另一种常被忽视的提示词。自己写 MCP Server 或自定义工具时，工具的名称、描述和参数说明都会进入模型的上下文，决定它什么时候调用、参数怎么填。这部分经常像代码注释一样随手写，其实对模型行为影响很大。两个工具用途重叠，模型会犹豫甚至选错，这时多写说明往往没用，合并或者重新划分工具更有效。
最后是任务描述，也就是你在对话框里给的那段话。交互式使用时可以边聊边补。要是任务交给后台运行的智能体，中途没人补充，任务描述就得一次写全，背景、目标、约束和验收标准都在里面。
像代码一样管理提示词
提示词一旦每天被执行几百次，就得有和代码一样的纪律。
它应该放进版本控制，系统提示词、项目说明、Skill、工具描述都在仓库里，有提交记录，能评审，能回滚。
改之前最好有一组测试输入。改一句话可能修好一个问题，同时弄坏三个。准备十几个有代表性的输入，每次改完跑一遍对比输出，比凭感觉判断可靠得多。
规则最好从失败里来。先用最简单的版本跑，看它在哪出错，再针对性地补。每条规则都能对应到一次真实发生过的问题，提示词就不容易膨胀。
换模型的时候值得从头读一遍。为旧模型某个毛病打的补丁，到了新模型上可能已经没必要，甚至有害。
提示词这一层剩下的，主要是把话写清楚的能力。一段写得很好的提示词，放进一个塞满无关日志的上下文窗口里，效果照样会打折扣。窗口里该放什么，是上下文工程要处理的事。
参考资料