你有没有遇到过这种情况——
你在提示词里写了六条叮嘱：别用术语、别写太长、要举例子、语气口语化、别说套话、结论放前面。
结果模型前两段乖得很，第三段开始，全忘了。
你又加了两条。它开始忘四条。
先说结论：叮嘱是事后擦，角色是事前选。
你每加一条"不要 XX"，都是在让模型先想到 XX，再绕开它。这活儿它干得不稳。而一个足够具体的身份，能让那些词从一开始就不太可能冒出来。
模型干的事，本质上是猜下一个词该是什么。它猜的依据，是它见过的所有文字里，这种上下文后面通常跟什么。
"你是资深前端工程师"这句话，等于给它划了一个范围。
在这个范围里，那些烂大街的套话出现的频率本来就低。资深工程师写东西，很少那么开头。你不用禁止，它们的概率已经被压下去了。
而"不要说某某套话"是另一回事。这句话把那几个字塞进了上下文，还得指望模型全程记得这是个禁令。生成到第八百个字的时候，这条禁令的存在感已经很稀薄了。
打个比方。
你招了个实习生写文档。你得盯着他：别写太长、加个例子、别堆术语。每一篇都得盯。
你招了个干了十年的人。你什么都不用说，他自己知道。
叮嘱是写 SOP，角色是招人。SOP 要执行者时刻记得，招人是一次性的事。
这是大多数人卡住的地方。
职位是个壳。壳里没东西，模型只好按平均值填。而平均值就是那种谁都能写出来的、正确但没劲的文字。
你真正想要的不是职位，是判断标准。
对比一下：
你是一位资深前端工程师。
你维护过一个跑了七年的后台系统。你见过太多"当时很火"的库最后没人管。所以你评估任何技术方案，第一个问题都是：三年后它还在不在，出事了谁修。
第二段里没有"资深"两个字，但它比第一段更能改变输出。
因为它给的不是标签，是取舍逻辑。模型接下来写的每一句，都会被这个逻辑筛一遍。
所以写角色的时候，你要问自己一件事：这个身份带来了什么判断标准？
如果答不上来，这个角色就是空的，删掉不影响。
想锁语气的时候，人的本能是堆形容词："专业、亲切、有趣、接地气"。
这四个词，一百个人有一百种理解。模型也一样。
更狠的办法是给一句这个人会说的话。
语气：专业、亲切、有点幽默。
你说话像在工位上转过椅子跟同事讲："这个坑我踩过，你听我说。"
第二种是个样本，不是标签。样本的解读空间小得多。
现在说示例。
很多人以为给示例是在给模型看"好东西长什么样"。不完全对。
示例真正的作用，是让模型自己推出一个规则：从这样的输入，到这样的输出，中间发生了什么。
它在学一个函数，不是在学一篇范文。
这就带出一个很实用的判断：能用一句话说清的，写规则；说不清的，才给示例。
"输出 JSON""不超过 200 字""结尾加一句提问"——这些一句话就说明白了，写成规则更省 token，也更好改。
"这种切入角度""这种颗粒度""这种自嘲但不油腻的分寸"——你形容半天也说不准，那就别形容了，给两个示例。
数量不是重点。
给了五个还是不对的很常见，两个就锁死的也很常见。差别在挑。
关键在这儿：模型会同时看示例里不变的部分和变化的部分。
不变的，它当成硬约束。变化的，它当成允许你发挥的维度。
所以挑示例的顺序是这样的：
先想清楚哪些东西必须固定——比如结构必须是"场景 → 问题 → 方案"，标题必须带数字。
再想清楚哪些东西必须变——比如涉及的技术栈要能是 React 也能是 Vue，长度要能伸缩。
然后让你的示例，在固定项上完全一致，在变化项上尽量拉开。
两个示例，一个讲 React 的状态管理坑，一个讲 CSS 布局坑，但结构一模一样——这比五个都在讲 React 的示例有用得多。
反过来，如果你的三个示例长得几乎一样，那等于只给了一个。模型会把那些"碰巧一样"的东西也当成硬约束，然后你会发现它输出的东西全长一个样。
不要在示例区放反例。
不要写"错误示范：xxx"然后期待模型避开。
反例一旦写成示例的格式，那段错误的文字就进了上下文，模型很可能把它当成可以模仿的花样之一。
反例要写在规则里，用文字描述："避免用疑问句开头"——而不是给一个疑问句开头的样例让它别学。
下面这个骨架可以直接抄，改中括号里的东西就行。
markdown## 你是谁
[一句话身份 + 两句话经历，经历要能推出判断标准]
你评估任何东西的第一反应是：[一句话取舍逻辑]
## 你怎么说话
你说话像[一个具体场景]，会说这样的话："[一句原话]"
## 规则
- [能一句话说清的约束，全放这里]
- [格式、字数、结构]
- 避免：[用陈述句描述要避开的东西，不要给反面样例]
## 示例
输入：[示例 1 输入]
输出：
[示例 1 输出]
输入：[示例 2 输入，技术栈/话题跟示例 1 拉开]
输出：
[示例 2 输出，结构跟示例 1 完全一致]
## 现在处理
输入：[你的真实输入]
输出：配一个填好的版本，方便对照：
markdown## 你是谁
你是一个写了六年前端教程的人，教程发在 qianduandaren.com。
你带过三十多个转行的学员，最清楚他们在哪一步会卡住。
你讲任何知识点的第一反应是：新人会在这儿误解成什么样。
## 你怎么说话
你说话像在工位上转过椅子跟同事讲："这个坑我踩过，你听我说。"
## 规则
- 结论放第一句，限定条件放后面
- 单句不超过 70 字
- 每个抽象概念后面必须跟一个具体例子
- 代码里标识符用英文，注释用中文
- 避免：用反问句开头，用"我们"称呼读者
## 示例
输入：解释一下什么是防抖
输出：
防抖就是——你别急着动，等我停手三秒你再动。
搜索框最典型。你打"前端达人"四个字，不做防抖会发四次请求。
做了防抖，只在你停下来之后发一次。
// 停止输入 300ms 后才真正执行
const debouncedSearch = debounce(handleSearch, 300)
输入：解释一下什么是事件委托
输出：
事件委托就是——别给每个孩子配保姆，让家长一个人看着。
一个列表有一百个 li，你绑一百个点击事件，浏览器要存一百份。
绑在父级 ul 上只要一份，靠 e.target 判断是谁被点了。
// 只绑一次，新增的 li 也自动生效
ul.addEventListener('click', (e) => {
if (e.target.tagName === 'LI') handleClick(e.target)
})
## 现在处理
输入：解释一下什么是虚拟列表
输出：注意看两个示例的关系。
结构完全一样：一句大白话类比 → 一个具体场景 → 一段带中文注释的代码。这是固定项。
话题完全不同：一个讲性能优化，一个讲事件机制。这是变化项。
模型学到的是那个结构，不是那两个知识点。
角色不管事实准确性。
"你是三甲医院主任医师"不会让模型少编药名。身份影响的是它怎么说，不是它知道什么。
想让它别瞎编，唯一有效的办法是把资料喂给它，然后说"只用我给的资料"。这跟角色是两条线。
精确任务里角色是噪音。
让它算个数、查个 API 参数、转换个数据格式——加角色只会稀释真正的指令。这类任务直接说要什么。
示例太多会把多样性锁死。
让它一次出二十个标题，你给了三个示例，很可能二十个标题都是那三个的近亲。
要多样性的时候，要么示例只给一个，要么就把示例之间的差异拉到极限，明确告诉它"这三个只是风格下限，不要模仿具体句式"。
还有一件事，别再做了。
"你是世界上最好的前端专家""这件事对我职业生涯非常重要""请深呼吸，一步一步思考"——这类咒语现在基本没用了。
早期模型需要被推一把才展开推理，现在的模型默认就会。堆最高级形容词，只会让开头多两句废话。
有用的是具体的经历和取舍逻辑。"最好的"是形容词，"维护过七年老系统"是信息。
翻出你最近用得最顺手的那条提示词，把里面所有"不要 XX"的叮嘱删掉，改成一段带判断标准的身份描述，跑同一个输入，对比两版输出。
扫码关注公众号，每周更新实用前端干货