不写一行代码，把提示词测个遍：零代码 Playground 实战手册

Token炼金师

83人浏览 · 2026-09-30 22:20:32

Token炼金师 · 2026-09-30 22:20:32 发布

在这里插入图片描述

摘要

第 65 篇把提示词做成了模板，这一篇给它配一个不写代码的测试台。Playground 提供迭代与测试提示词和模型配置的界面，六件可变项是它的核心。从 Playground 还能跑评测打分，并用 Chat 辅助优化提示词。

1. 零代码测试台

1.1 Playground 定位

官方文档给 Playground 的定位原话是：提供迭代与测试提示词和模型配置的界面。同一页还给了用法描述：在一系列输入上测试提示词或模型配置，看它在不同场景下的得分，无需写任何代码。

把这句定位拆成三个词看。

迭代：改一版配置，跑一轮，看结果，再改。这个循环发生在同一个界面里，不用反复运行脚本。

测试：不是只跑一条输入，而是一系列输入。一条输入看着好，换三条就可能翻车。

无需写任何代码：改动本身不经过代码。写代码的人仍然可以从代码里带走结论，但验证动作发生在界面上。

定位里的词	白话含义	对应的动作
迭代	改一版再看一版	在界面上改配置并重跑
测试	一系列输入而不是一条	换不同输入逐条观察
界面	不经过脚本与终端	鼠标与键盘完成改动
打分	看它在场景下的得分	从 Playground 跑评测

这张表是理解后面七章的入口。第 2 章讲改动什么，第 5 章讲怎么打分。

作为对照，先看不用 Playground 时做同一件事要写什么。下面这段脚本只覆盖了六件可变项里的两件。

# 来源：自实现 / 演示脚本
# 对照用：不用 Playground 时，测一次提示词要写的最小脚本
from langchain_core.prompts import ChatPromptTemplate
from langchain.chat_models import init_chat_model

# 第 65 篇做好的模板，这里是测试对象
template = ChatPromptTemplate.from_messages([
    ("system", "你是客服助手，回答不超过两句话。"),
    ("human", "{question}"),
])

# 换模型等于改这一行字符串，然后重新运行整个脚本
model = init_chat_model("provider:model")

# 测一系列输入等于自己写循环，自己打印，自己肉眼对比
chain = template | model
for question in ["退货政策是什么", "发票怎么开", "怎么改收货地址"]:
    print(chain.invoke({"question": question}).content)

这段代码做了三件事：定义模板、组装链、循环三条输入。每一处改动都要回到编辑器改代码再重跑。Playground 把这三件事都搬进了界面，这正是"无需写任何代码"的落点。

还有一个隐藏收益：界面上跑的每一次尝试都留在平台里，回看时不用翻终端历史。这对团队协作比对个人更有价值，第 7 章会展开。

1.2 与 Studio 的分工

第 46 篇讲过 Studio。它也是界面化工具，但它调的是 agent 图。具体指节点的编排、边的走向与图的执行路径。

两者面向的对象不同。Studio 的对象是 agent 整体结构，Playground 的对象是提示词与模型配置。一个管骨架，一个管措辞。

图里两条链各自独立：左边管结构，右边管配置。它们不共享对象，但共享同一个平台的追踪记录。

分工带来的实际判断标准很简单。问题出在流程走向，去 Studio。问题出在措辞或模型选择，去 Playground。

维度	Studio（第 46 篇）	Playground（本篇）
调试对象	agent 整体图	提示词与模型配置
主要动作	调节点与边	换六件可变项
观察重点	执行路径与状态流转	输出内容与得分
典型问题	流程走错了分支	回答跑偏或字段缺失

两者也有交叠：agent 图里的提示词最终也是提示词。先把单点提示词在 Playground 里调稳，再放回 agent 图里跑。这比直接在图里改更快。

这也解释了学习顺序。第 65 篇做模板，本篇在 Playground 里试模板。第 63 篇用评测给模板定型，第 46 篇在 Studio 里看它上线后的表现。

# 来源：自实现 / 演示清单
# 判断该开哪个界面的三问自查
问题一  卡住的是流程还是措辞
  流程卡住走 Studio，措辞卡住走 Playground
问题二  观察对象是路径还是输出
  看执行路径走 Studio，看输出内容走 Playground
问题三  改动会落在哪个文件
  改编排落回图定义，改提示词落回模板库

# 三问答案一致时直接走对应界面，不一致时先拆问题

三问里第三问最有约束力：改动最终要落回某个文件。先想清楚落点，就不会在错误的界面上白调一轮。

下一章先把这个测试台上的六件可变项数清楚。

2. 六件可变项

2.1 官方清单逐件讲

官方页给 Playground 列了六件可变项。下面是清单原文与中文对照，这张表是全篇的核心。

序号	官方清单原文	中文含义	换它回答什么问题
1	Change the model being used	换所用模型	同一模板换个模型，输出变好还是变差
2	Change the prompt template being used	换所用提示词模板	同一模型换套措辞，是否更稳
3	Change the output schema	换输出 schema	要求结构化输出后，字段是否齐全
4	Change the tools available	换可用工具	工具集增减后，行为是否跑偏
5	Enter the input variables to run through the prompt template	输入变量喂给模板	模板在新输入上是否仍然成立
6	Run the prompt through the model and observe the outputs	跑提示词过模型并观察输出	前面换完之后，结果到底如何

六件可以分成两类。前五件是配置：模型、模板、schema、工具、输入变量。第六件是动作：跑起来并观察。

逐件看一遍。

换模型：同一套措辞在不同模型上的表现差异可能很大。语气、格式服从度、拒答倾向都随模型变。

换模板：第 65 篇做好的模板在这里当资产用。同一个模型配不同版本的模板，比较哪一版更稳。

换输出 schema：schema 一变，模型的注意力就变了。字段名本身就是指令。

换可用工具：工具集决定了模型能做什么。多给一个工具，模型可能就开始用它，哪怕不该用。

输入变量：模板是壳，变量是内容。壳做得再好，遇到没预料到的输入也会露馅。

第六件最容易被忽视。跑提示词过模型并观察输出，重点词是观察。跑完不看等于没跑。

# 来源：自实现 / 演示清单
# 六件可变项的使用顺序建议（前五件配置，第六件验证）
1 换模型       先定模型，措辞问题才可比
2 换模板       模型固定后，比较模板版本
3 换 schema    需要结构化输出时再引入
4 换工具       涉及动作能力时引入
5 输入变量     每轮固定一组输入作为考题
6 运行观察     每轮跑完立刻记录结论

这份顺序不是官方规定，是减少返工的做法。先换模型再调措辞，能避免为弱模型过度补偿措辞。

六件之间还存在耦合关系。schema 一变，模板里可能要补字段说明。工具一变，模板里的角色设定可能要跟着改。遇到这类联动，仍然一次只动一件，动完再观察另一件是否需要跟进。

可变项	动它的高频理由	动它的错误理由
模型	成本与能力权衡	换新模型尝鲜
模板	输出稳定跑偏	单条输入不满意
输出 schema	下游要消费结构化字段	觉得结构更专业
工具	能力边界要扩张	工具库里有现成的
输入变量	覆盖新场景	随手换一条试试

第二列与第三列的分界线只有一条：改动是否由明确问题驱动。没有问题的改动，等于在给归因添乱。

六件里任何一件都可能成为当前实验的自变量。怎么控制变量，是下一节的方法论。

2.2 单变量实验法

六件可变项同时存在，最大的风险是一次改好几件。改完变好了，但不知道是哪件起了作用。

单变量实验法的白话版本：一次只换一件，其余五件全部锁死。这样输出差异只能归因于被换的那一件。

时序图里的关键在第一格：动手之前先确认其余五件没动。末尾一格的记录动作决定经验能否积累。

落到执行层面，每轮实验要留下一条记录。下面是记录格式。

# 来源：自实现 / 演示脚本
# 单变量实验的记录格式：相邻两条之间只允许一个字段不同
runs = [
    {"run": 1, "model": "provider:model-a", "template": "v1", "schema": "无", "tools": "无", "note": "基线"},
    {"run": 2, "model": "provider:model-b", "template": "v1", "schema": "无", "tools": "无", "note": "只换模型"},
    {"run": 3, "model": "provider:model-a", "template": "v2", "schema": "无", "tools": "无", "note": "只换模板"},
]

# 校验规则：相邻两条之间恰好只有一个字段变更
for prev, curr in zip(runs, runs[1:]):
    changed = [k for k in prev if k not in ("run", "note") and prev[k] != curr[k]]
    print(curr["run"], "变更字段:", changed)

这个脚本本身不跑模型，只做记录校验。它的价值是强迫实验者把每轮改动写下来，写不出来的改动就是没想清楚。

实验轮次	变更项	观察指标	记录要求
第 1 轮	无，建基线	三条固定输入的输出	存下完整输出
第 2 轮	只换模型	格式服从与语气	与基线逐条对比
第 3 轮	只换模板	答案准确性	标注改善与退化各几条
第 4 轮	只换 schema	字段完整率	记录缺失字段名

轮次数量没有硬性规定。经验做法是同一改动至少看三条输入，只看一条容易把偶然当规律。

单变量法也有代价：六件全试一遍的轮次会多。这时该优先动哪两件，下一章先讲最常用的两件，模型与模板。

3. 换模型与换模板

3.1 换模型

六件可变项的第一件是换所用模型。这一件的典型场景：模板已经写好，不确定哪个模型跑它最合适。

第 4 篇讲过 provider:model 的写法：一个字符串同时指定服务商与模型名。Playground 里换模型不需要改这个字符串，直接在界面上选。背后的语义是同一个。

换模型这一维的实验设计：其余四件全部锁死，只换模型列。锁死的四件是模板、schema、工具、输入变量。

# 来源：自实现 / 演示数据
# 换模型实验的矩阵：模板固定为 v1，输入固定为三条考题
模型 A    模板 v1    考题 1 2 3    输出记录为 A1 A2 A3
模型 B    模板 v1    考题 1 2 3    输出记录为 B1 B2 B3
模型 C    模板 v1    考题 1 2 3    输出记录为 C1 C2 C3

# 对比方向：格式服从度、语气一致性、答错条数
# 结论格式：模型 B 在格式服从上最好，但在考题 3 上答错，原因记录在旁

矩阵里的每一行是一次完整运行。横向比是同一模型跨考题，纵向比是同一考题跨模型。

换模型时常见的三个观察点。

观察点	白话说法	翻车表现
格式服从	让它两句话它是不是就两句话	写成五段长文
指令遵从	system 里的约束是否被记住	忽略禁止事项
稳定性	同一输入多跑几次是否一致	时好时坏无法依赖

第三点要特别说明：同一输入跑多次输出可能不同。 Playground 上重复运行同一组配置，本身就是一次廉价的一致性检查。

图里的判定顺序有讲究：先看格式再看内容。格式问题常靠改模板就能修，没必要为它换更贵的模型。

一个容易被忽略的关联成本：不同模型的计价不同。若要做成本对比，数字需要标注"示例数据，以厂商定价页为准"。不要引用未经核实的单价。

模型这一维定了之后，第二个要动的是模板。

3.2 换模板

第二件可变项是换所用提示词模板。第 65 篇把提示词做成了带变量的模板，这一篇是那批资产的实验场。

换模板的典型场景：模型已经选定，两三版措辞之间拿不定主意。这时候把模板这一维当作自变量，其余五件锁死。

两维合起来看，模型与模板构成一张对比矩阵。

	模板 v1	模板 v2	模板 v3
模型 A	A 跑 v1	A 跑 v2	A 跑 v3
模型 B	B 跑 v1	B 跑 v2	B 跑 v3
模型 C	C 跑 v1	C 跑 v2	C 跑 v3

九格不必全跑。实际做法是先沿一个维度定标，再沿另一个维度细化。

矩阵解读有一条纪律：不要拿交叉格下结论。如果同时换了模型与模板，那一格的差异无法归因，回到单变量法。

模板版本之间要有版本标记。下面是第 65 篇模板资产在本篇的用法约定。

# 来源：自实现 / 演示清单
# 模板版本约定：相邻版本之间只做一类改动
v1 基线版本    只有角色设定与任务描述
v2 加约束      增加输出长度与格式限制
v3 加示例      增加一个回答示例
v4 调变量      只改变量命名与占位写法

# 每一版在 Playground 里跑同一组输入变量
# 每一版的结论写进模板备注，下一代人不重踩

版本约定的核心是相邻版本只做一类改动。同时加约束又加示例，观察到的提升就不知道该记在谁头上。

图里两条出口都通向记录：改好要记原因，改坏也要记原因。只记成功会让模板库变成幸运集合。

这一章的两件是六件里最常用的组合。下一章看另外两件配置：输出 schema 与工具。它们改的不是措辞，而是输出的形状与模型的能力边界。

4. 输出 schema 与工具

4.1 换输出 schema

第三件可变项是换输出 schema。schema 在这里指结构定义：规定输出必须是哪些字段、每个字段什么类型。

第 18 篇讲过结构化输出：让模型按给定 schema 返回结构化数据。这里的 schema 指结构定义，规定输出必须包含哪些字段、各是什么类型。Playground 提供了这件事的界面化试错场。

换 schema 这一维的观察点与换模板完全不同。换模板看内容质量，换 schema 看字段完整率。

schema 变化	观察点	常见结果
从无到有	输出是否仍可读	长度变短，内容收敛
加一个字段	新字段是否总被填上	偶发留空
删一个字段	剩余字段是否变详细	内容回流到其他字段
改字段名	语义是否被理解	名称贴近业务则更准

第三行值得展开：删字段不会让输出变短，内容会挤到剩下的字段里。这在做摘要类任务时经常反直觉。

下面这个 schema 变体实验的记录格式，延续第 2 章的单变量法。

# 来源：自实现 / 演示脚本
# schema 变体记录：相邻版本只动一处字段定义
schemas = {
    "v1": {"topic": "str", "summary": "str"},
    "v2": {"topic": "str", "summary": "str", "risk": "str"},
    "v3": {"topic": "str", "summary": "str", "risk": "str", "risk_level": "str"},
}

# 检查项：每轮统计留空字段出现的次数
# 留空多说明模型对字段含义不确定，优先改字段名而不是加解释
# 相邻版本差异：v2 只加 risk，v3 只加 risk_level

字段名本身就是指令。留空率高的字段，第一反应是改名字，第二反应才是加说明文字。

六件里的第 6 件在这里的作用最明显：换了 schema 之后必须实际跑一遍并观察。字段齐全与否，只有跑了才知道。

schema 变体之间的对比也有记录格式。沿用第 2 章的规则：相邻版本只动一处。

# 来源：自实现 / 演示清单
# schema 变体的观察记录模板
版本 v1    无 schema    记录  输出长度与可读性
版本 v2    加 topic 与 summary    记录  两个字段的留空次数
版本 v3    再加 risk    记录  risk 的留空次数与内容质量

# 每一版跑同一组三条输入，留空次数直接对比
# 结论写法示例：v3 的 risk 在考题 2 留空，改名后留空消失

记录里的"改名字后留空消失"这类结论，正是 Playground 上最便宜的收获。它不需要评测跑全量数据集，三条考题就能暴露。

4.2 换可用工具

第四件可变项是换可用工具。工具集决定了模型能做什么动作，增减一件工具都会改变行为。

第 2 篇讲过工具选择：工具不是越多越好，而是越贴合越好。这一节把那个结论放进 Playground 里验证。

工具集变化的三个典型实验。

实验设计	工具集变化	预期观察
减法实验	从五件减到两件	不该调工具的问题不再乱调
加法实验	加一件易混淆工具	调用错工具的频率上升
替换实验	换成同名不同实现	行为差异体现在参数上

第一行对应最常见的坑：工具太多导致误调用。减掉几件后误调用是否消失，是 Playground 上一眼能看出来的。

图里每一轮只移除一件工具，这是单变量法在工具维上的应用。一次移三件，消失的原因又说不清了。

六件可变项里的第 6 件在工具实验里有个细节：观察对象不只是文字输出。还包括工具是否被调用、以什么参数调用。只看最终回答会漏掉中间的动作。

工具与 schema 还会互相影响。加了搜索工具之后，模型可能把不确定的字段留空，因为它想先查再填。遇到这类联动，回到单变量法，一次只动其中一件。

工具实验同样要留记录。记录的对象比 schema 实验多一栏：调用参数。

# 来源：自实现 / 演示清单
# 工具集减法实验的记录模板
轮次 1    工具五件    记录  误调用出现在哪条考题
轮次 2    移除工具甲  记录  该误调用是否消失
轮次 3    移除工具乙  记录  新出现的误调用

# 每轮同时记下被调用工具名与传入参数
# 结论写法示例：移除工具甲后考题 2 不再误调用，参数里曾出现空字符串

第三栏的新误调用容易被忽略。减掉一件工具，模型可能改调另一件更不合适的工具，这不是改善而是转移。

到这里，六件里的前四件讲完了。界面上的单点尝试有局限：样本只有几条，结论靠肉眼。下一章把它升级成在数据集上打分的评测。

5. 从 Playground 跑评测

5.1 数据集上测试并打分

官方页对这一步的定位是：要在数据集上测试提示词或模型配置并给结果打分，从 Playground 跑评测。细节见 run-evaluation-from-playground 页，以该页为准。

这句话把第 2 章的肉眼观察升级成打分。肉眼观察的三个局限，评测逐一补上。

局限	肉眼观察	在数据集上评测
样本量	三五条输入	全数据集逐条
判断方式	主观印象	按评估器打分
结论可比性	靠记忆	结果沉淀可对比

第三行是关键差异。肉眼比较两轮输出靠记忆，评测比较两轮结果靠记录。记录不会记错，也不会换人之后就失效。

第 63 篇已经核实过一个关联事实：离线评测可以服务端经 Playground 跑。这条来自官方 evaluation-types 页的原话。它意味着 Playground 不只是手工试验台，也能承接正式评测。

图里的分叉在 F 之后：一轮评测的价值一半在自身分数，一半在与历史的对比。只看单轮分数容易误判波动为进步。

与第 30 篇讲过的三层测试对上位置：Playground 里的评测属于 evals 层。它不需要本地环境，适合没有代码环境的角色。

打分的具体机制，包括评估器怎么配、有哪些类型，本篇不展开。这些属于 run-evaluation-from-playground 页的内容，以官方页为准。

从肉眼到打分的分界线也可以用一张表说清。什么时候留在界面里试，什么时候发起评测。

判断需求	用肉眼观察够吗	建议动作
方向性判断，改了是否更差	够	界面里跑三五条
要给团队交付结论	不够	发起数据集评测
要与上一版正式对比	不够	发起评测并对比实验
要看字段留空率	不够，样本太少	发起评测统计

界面上试是免费的，评测要跑全量数据集，成本与时间都更高。分界线的意义就在控制这笔开销。

5.2 创建实验

官方 See also 区给了另一个入口：run-evaluation-from-playground 页的 Create an experiment in the Playground，即从 Playground 创建实验。

实验这个词在上一章出现过。第 30 篇与第 63 篇都讲过：一次评测跑完即成为一个实验。实验之间可以横向比较。

从 Playground 创建实验的流程要点有三个。界面里的配置就是被测对象，选好数据集后发起，跑完得到一份可命名的实验记录。

# 来源：自实现 / 演示清单
# 从 Playground 创建实验前后的自检清单
发起前
  1 配置是否已冻结：六件可变项都记下当前值
  2 数据集是否选对：覆盖目标场景而不是顺手那个
  3 实验名是否可读：包含模板版本与关键改动
发起后
  4 结果是否与上一实验可比：数据集是否同一个
  5 进退结论是否写进实验备注
  6 赢的配置是否已同步回模板库

第 1 条来自第 2 章的教训：实验发起前不记录配置，事后无法归因。第 6 条来自第 7 章要讲的工作流闭环：赢的配置不回写，实验就白做了。

阶段	动作	常见遗漏
发起前	冻结六件可变项的取值	没记工具集
发起时	选数据集并命名实验	沿用默认名事后认不出
发起后	对比历史实验	只看本轮绝对分
收尾	赢的配置回写模板库	停在看到分数

创建实验的界面步骤与可配项细节，以 run-evaluation-from-playground 页为准，链接在外部引用。

实验命名的价值值得单说。三个月后翻实验列表，能认出哪个是"v2 加长度约束"的只有命名。

# 来源：自实现 / 演示清单
# 实验命名的三段式写法
第一段  模板版本号    例如 v2
第二段  关键改动      例如 加长度约束
第三段  数据集标识    例如 客服问答集

# 组合示例：v2-加长度约束-客服问答集
# 反例：test-01  事后完全认不出改了什么

命名的成本只有十秒，收益在整个实验历史里。反例那种默认名，等于把对比工作全部推给未来的自己。

评测解决的是配置定稿问题。定稿之前的草稿工作，还有一件帮手：Playground 里的 Chat。下一章讲它。

6. Chat 辅助

6.1 AI 帮你优化提示词

官方页的原话：用 Playground 里的 Chat 借 AI 辅助优化提示词、生成工具、创建输出 schema。细节见 chat 页。

这句话给 Chat 划了三条能力边界。本节先讲第一条：优化提示词。

白话版本：写提示词卡住时，让 AI 看着当前的模板与输出给建议。相当于结对编程里的另一双眼睛。

Chat 辅助能力	官方原话含义	适合的时机
优化提示词	改进现有模板的措辞	输出稳定跑偏
生成工具	帮忙产出工具定义	需要新能力
创建输出 schema	帮忙产出结构定义	字段设计没把握

这个边界也划出了 Chat 不做的事。Chat 给建议与草稿，验证仍然要靠六件可变项里的第 6 件：跑起来观察。跳过验证直接采纳，等于把判断外包。

图里从 E 到 F 的验证环节不能省。Chat 的建议是假设， Playground 的运行才是证据。

向 Chat 描述问题的方式影响建议质量。给出现象比给出方向更有效。

# 来源：自实现 / 演示清单
# 向 Chat 描述问题的两种写法对比
低质量提问
  帮我把提示词写好一点
  问题：没给现象，Chat 只能泛泛给套路

较好提问
  模板要求两句话内回答，考题 3 的回答一直是五段长文
  system 里已有长度限制，请针对这条考题改进模板
  问题：给了现象、给了已尝试的约束、给了改进目标

# 规则：现象、已尝试、期望，三样至少给两样

6.2 生成工具与创建输出 schema

Chat 的另外两条能力：生成工具与创建输出 schema。官方原话同样来自定位句。

生成工具的场景：第 4 章做减法实验时发现缺一件能力。工具定义的初稿可以交给 Chat。它给出的字段与描述是否合理，仍要在 Playground 里验证。

创建输出 schema 的场景：第 4 章的 schema 变体设计。字段名、类型、是否可空的初稿可以交给 Chat，留空率要靠实际运行统计。

两条能力的共同点：Chat 负责初稿，实验负责裁决。工具与 schema 都会改变模型行为，改了就必须重跑。

产出物	Chat 的贡献	必须人工验证的点
工具定义	字段与描述的初稿	是否被误调用
输出 schema	字段名与类型的初稿	留空率与语义偏差
模板改写	措辞候选	三条考题上的实际差异

三条产出物里，模板改写的验证成本最低，工具定义的验证成本最高。工具一旦误调用，影响的是后续动作链，不只是输出文本。

# 来源：自实现 / 演示清单
# Chat 三条辅助能力的使用次序建议
第一步  用 Chat 优化提示词    成本低见效快
第二步  用 Chat 创建输出 schema    字段初稿很快
第三步  用 Chat 生成工具    影响动作链，谨慎引入

# 每一步产出都必须回到第 2 章的单变量法里跑一轮
# 禁止把 Chat 的产出直接标记为已验证

次序建议的依据是影响范围。措辞只影响输出文本，schema 影响下游解析，工具影响真实动作。影响范围越大的产出，验证轮次要越多。

Chat 产出的初稿还有一道人工必查项：字段名与工具名是否与现有系统一致。Chat 不知道团队里已有的命名约定，它起的名字可能撞上现有关键字。

# 来源：自实现 / 演示清单
# Chat 产出的三道人工必查项
必查一  命名冲突    新字段名是否与现有 schema 撞名
必查二  语义偏差    工具描述是否暗示了不存在的行为
必查三  冗余字段    是否生成了没人消费的字段

# 三道必查项都在 Playground 里跑一轮才能确认
# 其中冗余字段最隐蔽，下游没人读的字段会拖累输出质量

三道必查项的共同点是机器看不出来，只有熟悉系统的人能判断。这也是 Chat 辅助不能替代人工的边界所在。

Chat 界面的具体操作、入口位置与可用选项，以 chat 页为准。链接在外部引用一章。

把三条能力放到一起看，Chat 的价值是缩短草稿时间，而不是缩短验证时间。验证环节的不可压缩性，正是第 2 章方法论的立足点。

到这里，单个界面的能力讲完了：六件可变项、评测、Chat。下一章把它们串进提示词的完整工作流。

7. 工作流闭环

7.1 提示词工作流全链

前面几篇各管一段。把它们的先后关系摆出来，Playground 的位置才清楚。

第 65 篇做模板：把提示词整理成带变量的资产。第 63 篇做评测定型：在数据集上打分决定哪一版留下。第 46 篇 Studio 做上线观测：看它在真实 agent 图里的表现。

本篇的 Playground 在做与评之间，充当试验台。

图是环形的。线上观测发现的新问题，回到 Playground 里重新开始一轮试验。不要直接改生产配置。

每一段的职责与不越界是这套流程能转起来的前提。

环节	承担的事	不承担的事
做模板	定义变量与措辞	不做最终选型
Playground 试	六件可变项的单点对比	不下批量结论
评测定型	数据集打分与实验对比	不再改措辞细节
上线观测	看真实流量下的表现	不做配置改动

第二行的"不下批量结论"值得强调。Playground 上的输入是手挑的几条。这类结论只配指导下一步实验，不配直接定稿。定稿要走评测。

# 来源：自实现 / 演示清单
# 一处改动走完全链的完整路径示例
1 第 65 篇侧：模板升到 v2，只加一条长度约束
2 本篇侧：v2 在 Playground 里跑固定考题，确认约束生效
3 评测侧：v2 与 v1 在同一数据集上对比，看分数进退
4 观测侧：v2 上线，观察真实输入下的表现
5 回流侧：发现新问题，回到第 2 步开始下一轮

# 纪律：任何一步跳过，改动就没有留痕

路径里的第 3 步是必经关卡。只走第 2 步就上线，等于用手挑的输入代表全部流量。

7.2 跨职能场景

第 65 篇讲过一个协作观点：懂业务的人应该能直接改提示词。这一节是那个观点的落地。

Playground 的价值不只是省代码，而是换人。PM 或领域专家可以在界面上直接迭代提示词，不必把意图翻译给工程师再等回包。

角色	在 Playground 里做什么	原来要经过谁
领域专家	判断回答的准确与得体	要口述给开发复现
PM	试不同措辞下的表现	提需求排队
工程师	定 schema 与工具集	自己写脚本试
测试	挑边界输入喂给模板	自己写脚本试

第一行收益最大：判断"这个回答对不对"的人，原来恰好是离运行环境最远的人。

协作分工的边界也要清楚。非工程角色负责判断与措辞，工程角色负责 schema 与工具的实现正确性。两边在同一个界面里看到同一份输出，争议就少一半。

时序图里专家全程不碰代码，判断动作发生在看到真实输出之后。alt 块收在 end，两条出路都通向下一轮迭代。

这套流程能跑的前提是模板资产化：措辞存在模板库里而不是散在代码里。这正是第 65 篇做的那件事，也是本篇能"不写一行代码"的原因。

闭环讲完了。接下来这一章把本篇里最容易踩的坑列成对照表与决策流程。

8. 边界与坑

8.1 失败模式对照表

把本篇各章埋过的坑集中列一次。

失败模式	白话描述	后果	对应章节
一次换多件变量	同时换模型又改模板	差异归因不了	第 2 章
只试不存	好配置没进数据集与模板库	下次从头再试	第 5 章
当生产环境用	在 Playground 跑大量真实流量	界面与流程都不合适	本章
忽略关联页	不看 See also 的入口	重复走弯路	本章

第二行展开一下：只试不存的代价最隐蔽。当时觉得结论显然，三个月后换人接手，又要把同样的实验重跑一遍。

第三行来自 Playground 的定位。它是迭代与测试的界面，不是面向真实用户的服务。真实流量该走第 46 篇那条链路，观测用观测工具。

第四行也值得说：官方 See also 区给了五条关联入口，都与本篇直接相关。跳过它们容易在细节上自己猜。

图里三个菱形对应三道闸门：变量数、结论类型、请求量。任何一道闸门判断错，后面就会踩表里的坑。

# 来源：自实现 / 演示清单
# 收尾前一遍核对
1 本轮实验的六件可变项取值是否已记录
2 结论是否写明数据来源：几条考题还是整个数据集
3 赢的配置是否已回写模板库或数据集
4 未决问题是否标注为待验证而不是已验证
5 涉及评测与 Chat 的细节是否标注以官方页为准

# 核对方式：
# 第 1 条翻本轮实验记录逐项对
# 第 3 条以模板库或数据集里能检索到为准
# 第 5 条检查文中是否留了官方页链接

第 4 条最常被违反：界面上看了一眼觉得会更好，记录里就写成了"已验证"。把猜测与验证分开记，是这一篇反复出现的纪律。

8.2 评测与 Chat 细节以官方页为准

本篇有两个话题刻意停在入口处。

评测细节：评估器的配置方式、可用类型、从 Playground 发起评测的具体步骤，本篇没有展开。这些内容在 run-evaluation-from-playground 页，以该页为准。

Chat 细节：入口位置、对话可用的具体操作、三条辅助能力的完整边界，本篇同样没有展开。这些内容在 chat 页，以该页为准。

不展开的原因与写作纪律有关。这两页的界面细节更新较频繁，转述容易过期。入口与定位已经足够支撑工作流决策，细节以官方页为唯一来源。

话题	本篇给出的	需要查官方页的
从 Playground 跑评测	定位与用途	评估器配置与操作步骤
创建实验	入口与自检清单	界面步骤与可配项
Chat 辅助	三条能力清单	对话操作与完整边界

官方 See also 区还给了另外几条关联入口。分别是 prompt-engineering-concepts 的 Playground 小节、manage-datasets 的 From the Playground、observability-studio 的 Playground 小节。它们对应提示词方法、数据集沉淀与观测视图三个方向，链接都在外部引用一章。

三条 See also 入口各自指向一件本篇提到的收尾动作。逐条看一遍就知道去哪补齐。

See also 入口	对应本篇的哪件事
prompt-engineering-concepts 的 Playground 小节	第 65 篇的提示词方法延续
manage-datasets 的 From the Playground	第 5 章把好输入沉淀成数据集
run-evaluation-from-playground 的创建实验	第 5 章发起评测的入口
observability-studio 的 Playground 小节	第 7 章上线后的观测视图
chat 的 Playground 小节	第 6 章 Chat 辅助的操作细节

第二条值得单独强调。Playground 里试出来的一组好输入，只有进了数据集才能长期复用。不存进去，就是第 8.1 节说的只试不存。

# 来源：自实现 / 演示清单
# 查官方页之前的定位三问
问题一  我要的是定位还是操作步骤
  定位本篇已给，操作步骤去官方页
问题二  这个细节会不会随版本变
  会变的界面细节一律以官方页为准
问题三  不查这个细节能否推进工作流
  能推进就先推进，细节留到要用时再查

# 目的：避免在细节上空转，把时间留给实验本身

三问的意图是控制查文档的时机。入口知识够用就先跑实验，等真要配评估器时再精读官方页。

一句话收束：本篇能用界面说清的事已经说完，剩下的事以官方页为准。