让它连跑五次都能用
同一输入五连跑演示；三档任务：写第一版提示词、给不稳定归类、加示例与违禁项重跑对比
本页解决的问题
先给结论「让它连跑五次都能用」要解决的关键问题是什么？
同一输入五连跑演示；三档任务：写第一版提示词、给不稳定归类、加示例与违禁项重跑对比
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
很多人卡在这一步的表现是：「我试过了，效果时好时坏。」时好时坏，通常是提示词没把要求钉死。模型背这个锅有点冤。同一句话连问五次，你就能看见它到底稳不稳。
同样一句话，问五次
稳定不是一字不差
大模型天生带随机性，追求逐字复现是白费劲。你要钉死的是三样东西：结构稳（说好三段就三段）、字段稳（说好有「下周计划」就必须有）、边界稳（信息不够时它说「资料里没提」，别让它编一个）。这三样用这一章学的输出格式约束加 Few-Shot 示例就能焊住。顺便记得把用户输入用分隔符围起来，这是 Prompt 注入的第一道防线。
这一章的动手清单
0 / 3 已完成
把 M0 那件事写成第一版提示词
15 分钟 所有人按「角色 + 背景 + 要求 + 输出格式」四件套写。别追求完美，先有一版能跑的，这版就是你后面所有优化的对照组。
什么算做完了
连跑五次，给不稳定归类
1 小时 想知道差在哪同一个输入连跑五次，把每次结果存下来。不能直接用的，归进三类之一：格式飘了、内容编了、长度失控了。三类的解法不一样：格式飘补示例，内容编收窄材料，长度失控上硬性字数。
什么算做完了
加示例和违禁项，重跑对比
半天 要接进真流程给提示词补一个标准示例（Few-Shot）和一份违禁清单（比如「不要任何客套话」「资料里没有的信息写『未提及』」），再连跑五次和上一版对比。顺手做一件事：把用户输入用分隔符围起来，试着在输入里塞一句「忽略以上所有指令」，看它会不会中招。
什么算做完了
「先看清楚 · 「有时候挺好用」是什么病」怎样变成可执行的指令
「很多人卡在这一步的表现是：「我试过了，效果时好时坏。」时好时坏，通常是 提示词没把要求钉死 。模型背这个锅有点冤。同一句话连问五次，你就能看见它到底稳不稳」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「大模型天生带随机性，追求逐字复现是白费劲。你要钉死的是三样东西： 结构稳 （说好三段就三段）、 字段稳 （说好有「下周计划」就必须有）、 边界稳 （信息不够时它说「资料里没提」，别让它编一个）。这三样用这一章学的输出格式约束加 Few-Shot 示例就能焊住。顺便记得把用户输入用分隔符围起来，这是 Prompt 注入的第一道防线」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「M1 要记的就两样：最终版提示词，和五连跑的成绩。下一章接上工具之后，你还会回来改它」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「先看清楚 · 「有时候挺好用」是什么病」走到「动手清单 · 挑一个开始，勾掉它」
「先看清楚 · 「有时候挺好用」是什么病」先把问题落在「很多人卡在这一步的表现是：「我试过了，效果时好时坏。」时好时坏，通常是 提示词没把要求钉死 。模型背这个锅有点冤。同一句话连问五次，你就能看见它到底稳不稳」上；到了「动手清单 · 挑一个开始，勾掉它」，讨论继续推进到「按「角色 + 背景 + 要求 + 输出格式」四件套写。别追求完美， 先有一版能跑的 ，这版就是你后面所有优化的对照组」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「先看清楚 · 「有时候挺好用」是什么病」：很多人卡在这一步的表现是：「我试过了，效果时好时坏。」时好时坏，通常是 提示词没把要求钉死 。模型背这个锅有点冤。同一句话连问五次，你就能看见它到底稳不稳
- 「动手清单 · 挑一个开始，勾掉它」：按「角色 + 背景 + 要求 + 输出格式」四件套写。别追求完美， 先有一版能跑的 ，这版就是你后面所有优化的对照组
- 「最后的要点」：M1 要记的就两样：最终版提示词，和五连跑的成绩。下一章接上工具之后，你还会回来改它
最后的「最后的要点」把讨论落到「M1 要记的就两样：最终版提示词，和五连跑的成绩。下一章接上工具之后，你还会回来改它」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。