最近不少投资人、开发者、产品经理、爱好者配置了 OpenClaw,但使用体验并不好。原因可能是SOUL.md这种 System Prompt 的编写过于依赖直觉,缺乏结构。
工业级的 Prompt 优化是一套严谨的工程方法。
生产环境下的调优可概括为三步走:
1. 制定基准测试(Benchmark)
2. 构建初始 Prompt
3. 基于 A/B 测试循环迭代
核心总结【优秀的 Prompt 是测出来的,不是一次性写出来的】
1. 核心机制:LLM-as-a-Judge
面对海量测试样本,人工评估极不现实。解法是让 AI 充当“阅卷人”。
产品经理作为“出卷人”定义量化标准:维度 + 权重 + 评分细则。
例如「AI 减脂建议」的评测标准:
- 有用性 70% + 易操作性 20% + 情绪价值 10%
- 细则量化:3分(学术验证有效),2分(多数人有效),1分(无效)。
2. 评测提示词(Judge Prompt)的最佳实践
构建“阅卷人”的标准操作:
- 解耦维度:每个维度独立编写 Prompt 并分开调用 API,避免模型注意力分散。
- 结构化:使用 XML 标签(如 <task>, <examples>)隔离指令。
- 对齐人工:提供覆盖高低分的 Few-shot 示例,先人工打标 10-20 条,对比 AI 打分直至标准对齐。
- 稳定性:Temperature 务必设为 0。
3. 生产提示词(System Prompt)的结构化写法
推荐采用标签化的 xml 模块写法:
<role> 设定系统角色
<task> 明确核心任务
<guideline> 分步拆解执行逻辑
<examples> 提供多场景的 Few-shot
<format_requirement> 约束输出格式
优势:结构清晰,便于后续控制变量进行单模块的优化与实验。
4. 科学迭代:控制变量法
A/B 测试的核心在于控制变量。切忌同时修改多个模块,否则无法归因提升来源。
正确的迭代路径:
分析低分 Case -> 判断是通用逻辑缺陷(General Case)还是边缘场景(Edge Case) -> 抓主要矛盾 -> 单独修改影响最大的段落(如只改 Guideline) -> 重跑 Benchmark 验证。
5. 工程实践与产品反思
大批量跑测时的避坑指南:
- 务必使用多线程并设定 Checkpoint 定期存档,采用 append 模式写入,避免异常中断导致数据丢失。
- 如果调优毫无起色,需反思任务本身是否具备可行性(Practical)。
- 如果一两次就拿满分,需检查评估标准是否过于宽松。
最后的最后,AI 只是工具,即使机评分数达标,仍需进行人工抽样走查,对最终结果负责,判断表现是否在Use Case上是否符合预期。Overall it's taste that matters.