今年 7 月，我读了 Lilian Weng 关于 Harness Engineering 的文章。她讨论了围绕模型运行环境做迭代改进[1]。提示词是这个环境（Harness）的一部分，我开始尝试一个更具体的问题：能不能让高级模型帮助我们改进低级模型使用的复杂提示词？
这里的“高级”和“低级”是相对称谓：高级模型负责分析和提出修改建议，低级模型是实际运行提示词的目标模型。
我碰到的场景是品牌发现：从网页或搜索材料里找出被提及的品牌，再判断哪些品牌在目标品牌的相关业务上构成竞争或替代，最后输出候选品牌。客户、渠道、合作方、工具等即使出现在材料里，也不一定符合条件。提示词由系统提示词、用户提示词和 few-shot 示例组成。
优化时，难点在于判断问题出在规则、任务说明、示例，还是模型选型；还要决定探索方向，以及该优先减少漏报还是误报。最初几轮，我只让高级模型看着提示词自由提方案，效果并不稳定：新方案有时比旧方案更差，我又换方向继续试。这样的探索消耗调用成本和时间，却未必能解释问题出在哪里。
我们需要一个比较完整的方法和流程，来帮助高级模型寻找优化方向，并且根据评测结果决定是否采纳。包括这几个方面：
固定目标模型与执行环境
相同提示词在不同模型、不同推理模式下，表现可能完全不同。在 GPT 上运行得好，不代表换到豆包 Mini 后也有效。优化必须围绕实际使用的目标模型和模式进行。
我先尝试了豆包、DeepSeek Flash、DeepSeek Pro 和 GPT，几种模型的表现都没有达到任务需求。这一步让我把后续优化重点转向提示词；它本身还不能证明模型能力没有影响。确定目标模型后，后续评测需要固定模型和推理模式，不能把不同执行环境的结果直接比较。
本次任务是单轮提示词判定，执行端只需一次 LLM call，固定超参数和批量脚本即可自动运行。我用 Codex 的 sol 提出修改建议，执行脚本则放在隔离环境中。每轮保留提示词版本、调用参数、输入、输出和评分，避免把模型或运行模式的变化误算成提示词带来的改善。
把提示词拆成可区分的部分
复杂提示词如果不分层，前后结构容易混乱，也难判断该从哪里改。我把它拆成系统提示词、用户提示词和 few-shot 示例。为了保持泛化性，我会优先优化用户提示词；系统提示词主要约定身份和任务核心目标，不需要频繁改动；few-shot 则用于呈现难以用规则说明的歧义边界，加入有区分力的正反案例。
分清各部分的职责后，才容易检查它们之间是否有重复、歧义或冲突。目标模型对不同位置的指令遵循程度也不同，可能在一条规则上判断符合条件，又在另一条规则上得出相反判断，最终在不同案例里来回摇摆。
固定评测数据和指标
评测数据要包含真实失败案例，也要覆盖关键边界，并标注 P0、P1、P2 等优先级。指标按任务风险选择：漏报影响更大，就优先看召回率；误报代价更高，就优先看精确率（Precision）；两者同等重要时，再看 F1 score。每个候选版本都用同一批数据和同一套口径比较，再决定是否保留。
让目标模型的执行轨迹参与诊断
我把目标模型每次调用返回的推理内容（尤其是思考过程），也就是 trajectories，和对应的提示词版本、输入、输出及评测标签一起完整记录。高级模型可以对照这些具体轨迹，检查模型在哪条规则、哪个示例或哪种关系判断上出了偏差。修改方向因此能从实际失败中得出，不必只靠高级模型根据提示词文本猜测。
模型返回的推理内容是诊断线索，不能单独证明模型内部的决策过程。分析时还要把轨迹和原始输入、最终输出及评测标签相互核对。
品牌发现任务中的结果
这套做法用在品牌发现提示词的迭代上。不到十轮优化后，最终提示词的精确率（Precision）为 92.31%、召回率（Recall）为 88.89%、F1 为 90.57%。
这套方法适用于什么问题
适用条件：
- 方案生成模型与实际执行模型不同，需要针对执行模型优化。
- 任务使用复杂提示词，执行过程是单轮 LLM call。
- 评测可以使用明确标签和固定指标。
- 时间或 token 有限，需要控制试错成本。
- 设计空间可以限定在少数可验证的方向，不需要大规模搜索。
本次实验局限：
- 最终提示词版本只重复调用了 5 次，稳定性证据有限。
- 没有评估 judge 过程的准确性。
- 没有验证对未见数据的泛化能力，也没有验证跨模型兼容性。
参考
[1] Lilian Weng, “Harness Engineering for Self-Improvement”, Lil’Log, July 4, 2026. 原文