把格式钉死
开场
你有没有遇到过这种事——同一条提示词，今天给你一份 Markdown 列表，明天给你三段散文。你一个字没改。你怀疑是模型变笨了，其实是你那条提示词从来就没说清楚要什么形状。
讲透
先说结论：输出里任何一个你会挑剔的维度，提示词里必须有一句话对应它。没说的地方，模型会替你猜，而猜的结果每次都不一样。
为什么会这样？模型干的事本质上是续写。你给一段文字，它算下一个词最可能是什么，然后一个一个吐出来。"最可能"不是"唯一"。当你的提示词没规定输出形状时，"用列表回答"和"用段落回答"这两条路的概率可能是 51% 对 49%。掷一次骰子的事。你看到的不稳定，就是这个骰子。
所以稳定性不是靠祈祷得来的，是靠把自由度一个个关掉。
那关哪些？你需要判断的其实只有一件事：这次不满意，是哪一层没说。
四层，从外到内：
它用的词不对劲——比如你要中文技术文，它蹦出一堆英文缩写；或者你要口语，它写得像论文。这是语言层没锁。补一句话就行："中文输出，术语第一次出现给一句人话解释，单句不超过 40 字。"
它做的事不对——你让它"分析"这段代码，它给你重写了一遍。这是任务层没锁。问题通常出在动词太虚。"分析""优化""处理"这类词，每个人心里的意思都不同，模型也一样。换成可验证的动词："列出这段代码里会导致重渲染的 3 个地方，每处说明触发条件。"
它做对了，但不合场景——内容没错，可就是不能用。写给 1 年经验前端的东西，它按资深架构师的口径写了。这是上下文层没锁。上下文管的是"按谁的标准做"：读者是谁、在什么场合看、他们已经知道什么、最在意什么。
内容都对，但形状不对——该出五条它给三条，该出 JSON 它给了 Markdown。这是输出层没锁。
诊断顺序按这个来，从外往里查，一次只补一层。四层一起改，你永远不知道是哪句起了作用。
接下来讲一个特别省事的技巧：给一个示例，胜过写三句格式说明。
原理不神秘。你写"请用表格输出"，模型得先做一次翻译——"表格"在这个场景里到底几列、表头叫什么、要不要合计行？这次翻译有很多种解，它挑哪种你控制不了。而你直接甩一段样例过去，模型的续写本能会让它照着这个骨架往下填。翻译那一步被跳过了。
打个比方。你跟外包设计师说"给我做个简洁的按钮"，你会收到十种简洁。你甩一张现有按钮的截图说"照这个来"，你会收到一种。
但这里有个坑，很多人踩。**示例锁的是形状，不是内容。**如果你的示例内容和真实任务太像，模型会连内容一起抄。所以示例要挑一条真实但不相干的——比如你要它拆解 React 文章，示例就用一条 CSS 的。另外别用 {标题} [此处填写] 这种占位符，模型有相当概率把占位符原样吐给你。
最后说 JSON，因为这是最容易翻车的场景。
JSON 跑偏的方式就那么几种：前面加一句"好的，这是你要的 JSON"；给你包在代码块围栏里；字段名从 codeLang 自己变成 code_lang；该留空的字段它编一个值出来；数组只有一项时退化成对象。
提示词层能按住大部分：字段清单写死，每个字段标类型和长度；每个可能为空的字段都要明确写"不知道时填什么"（这条最关键，不给缺省值模型就会编）；给一个包含空值情况的完整示例；最后明确一句"只输出 JSON，第一个字符是 {，最后一个字符是 }，不要代码块围栏，不要任何解释"。
但你要清楚一件事：**提示词层只能"劝"，劝就有失手的时候。**如果这段 JSON 要直接进你的代码、要 JSON.parse，别靠劝。用结构化输出、JSON Schema 或者工具调用（function calling）。这几种做法是在模型吐字的那一步就把不合规的选项掐掉，它物理上吐不出错的字段名。一个是劝说，一个是上锁。要跑生产就上锁。
怎么做
这是一个四层都补齐的模板，直接改字段就能用：
text# 任务 把 <article> 里的文章拆成公众号卡片文案。 # 上下文 读者是 1-3 年经验的前端开发，通勤时用手机看。 他们最关心「这东西我明天能不能用上」。 # 语言 中文。技术术语第一次出现给一句人话解释。 单句不超过 40 字。用「你」称呼读者，不用「我们」。 # 输出 只输出 JSON。第一个字符是 {，最后一个字符是 }。 不要代码块围栏，不要任何解释文字。 字段： - title: string，不超过 20 字 - hook: string，开场第一句，必须描述一个具体场景 - points: string[]，3 到 5 条，每条不超过 60 字 - code_lang: string，示例代码的语言；文章里没有代码时填 "" - source_url: string，原文链接；找不到时填 "" 示例（只示范形状，内容不要照抄）： {"title":"容器查询上手","hook":"你有没有改过一个组件，换个位置就塌了","points":["容器查询按父容器宽度响应，不看视口","..."],"code_lang":"css","source_url":"https://qianduandaren.com/css-container-query"} # 输入 <article> {{ARTICLE}} </article>
注意 code_lang 和 source_url 那两行的写法。给了缺省值，模型就不会编。
什么时候不灵
要多样性的时候，示例会反噬。 你给一个示例让它写 10 条标题，会得到 10 条同一句式的标题。示例锁形状锁得太好了。这时候要么给 3 到 5 个刻意写得不一样的示例，要么干脆不给示例、只给约束。
约束太多会挤压内容质量。 模型的注意力是有预算的。你同时要求六个字段、严格字数、特定语气、还要有金句，一定有一项会松掉。所以约束要排优先级，把真正不能错的那两三条写在最前面和最后面——中间的东西最容易被忽略。
长输出的格式会漂。 让它一口气生成 20 条，写到第 8 条时开始丢字段。这不是提示词的问题，是长度的问题。解法是分段生成，一次 3 到 5 条。
别用 XML 标签去控制输出格式。 这套写法今天仍然好用，但用途是划分输入区块——像上面模板里的 <article>，帮模型看清哪段是待处理的原料。至于输出格式，直接用 JSON Schema 或结构化输出，比让模型自己配对开闭标签可靠得多。
今晚练什么
挑一条你现在用得最多、但结果时好时坏的提示词，只做一件事：把输出层补上一个真实示例，跑五遍，看五次结果是不是长得一模一样。
如果这篇对你有帮助，欢迎关注公众号「前端达人」，每周更新实用前端干货。
