系统提示词工作区¶
路由：/#/basic/system
这个工作区适合处理“角色设定、行为边界、输出规范”这类长期约束。
如果你优化的重点是“一次具体任务怎么说”，通常更适合去 用户提示词工作区。
第一次使用，先这样判断¶
如果满足下面两条，通常就该用这个页面：
- 你在写的是长期角色、规则、边界
- 右侧需要配一段测试文本才能运行
什么时候用它¶
适合：
- 给模型一个稳定角色
- 规定统一输出结构
- 约束不能做什么
- 测试模型在不同问题下能不能始终守规则
如果你只想快速开始，看这 4 步¶
- 左侧填一条 system prompt
- 左侧先做一次优化
- 右侧填测试文本
- 右侧跑测试，再做结果评估
左侧到底在改什么¶
左侧改的是 system prompt 本身。
当前页面可以这样理解：
- 左侧上方：原始系统提示词
- 左侧下方：当前工作区和版本链
左侧的 分析 / 优化 / 迭代，目标都是把这条 system prompt 写得更清楚、更稳定、更容易执行。
右侧到底在测什么¶
右侧测的是：
- 某个 system prompt 版本
- 加上一段固定测试文本
- 最后看真实输出
所以在这个工作区里，右侧测试文本是必须的，因为 system prompt 通常不会单独执行。
这个页面里“分析”和“评估”的边界¶
- 左侧
分析：只分析 system prompt 本身，不读取右侧测试文本 - 右侧
结果评估：评估某一列真实输出是否达到目标 - 右侧
对比评估：比较多列真实输出之间的差异
如果你主要在分辨这几种动作，建议配合 测试与评估 一起看。
推荐工作流¶
- 左侧输入原始 system prompt
- 左侧先做一次优化，得到工作区版本
- 如需先看提示词本身是否清楚，再点左侧
分析 - 右侧填写一段固定测试文本
- 在右侧比较
原始 / 工作区 / vN - 先做单列
结果评估 - 如果已经跑了两列或更多，再做
对比评估 - 把真正有价值的建议应用回左侧工作区
最容易混淆的地方¶
因为左侧分析的目标是“这条 system prompt 写得怎么样”，不是“某一次执行结果怎么样”。
因为 system prompt 需要和一段用户输入一起执行，才能看出角色、规则和边界到底有没有生效。
一个最小例子¶
system prompt：
你是一个客服助手。
右侧测试文本：
我的订单三天了还没发货，现在可以退款吗？
这样你就能比较：
- 原始版本是否太泛
- 工作区版本是否更守规则
- 不同模型是否更容易误解这条 system prompt