1. 测试集提示词迭代为什么总在重复劳动做 NLP 任务的朋友大概率都经历过这个循环写好一版提示词跑一遍测试集挑出 badcase手动改提示词再跑一遍又冒出新问题。一轮下来两三个小时没了改到第五版的时候你已经记不清第一版为什么那么写。这个循环本身没错问题在于它是纯手工的。手工意味着三件事不可复现、不可并行、不可回溯。你改了什么、为什么改、改完哪几个 case 变好了、哪几个 case 反而退化了全靠脑子记。测试集一上两百条人脑直接过载。我试过把「跑测试集 → 出 badcase → 改提示词 → 再跑」这个闭环交给代码来编排核心思路是让 Cursor SDK 当调度器让大模型当评分员和改写员TaoToken 当统一入口。这样每一轮迭代都有日志、有 diff、有分数曲线人工只需要在关键节点做决策。先说清楚这套流水线适合谁如果你手上有 50 到 500 条规模的测试集任务类型是分类、抽取、改写、摘要这类可以用规则或参考答案打分的 NLP 任务并且你已经在用 Cursor 写代码那这套方案能直接落地。如果你只有三五条 case手工改更快不用上流水线。整条链路是这样的测试集 JSONL 读进来 → 用当前提示词批量调用模型 → 评分脚本算出每条 case 的得分 → 把 badcase 和采样出来的 goodcase 一起喂给改写模型 → 生成新提示词 → 写回配置文件 → 进入下一轮。循环终止条件可以是分数不再提升也可以是跑满 N 轮。这里有个容易被忽略的点只给改写模型看 badcase 是危险的。模型会为了修好那几条错例把提示词改得越来越特化goodcase 悄悄退化你根本发现不了。所以每一轮必须采样一部分 goodcase 一起送进去让改写模型知道「这些行为不能动」。下面从接入配置开始一步步把这条流水线搭起来。2. TaoToken 统一 Key 接入与 Cursor SDK 环境准备2.1 为什么需要一个统一入口流水线里至少有三个角色在调模型批量跑测试集的执行模型、给结果打分的评分模型、根据 badcase 改写提示词的改写模型。如果每个角色各接一家、各配一个 Key你的环境变量会变成一团乱麻换模型要改三处代码成本核算也没法统一看。TaoToken 在这里的作用是把模型调用收敛成一个 OpenAI 兼容的入口。你只需要一个 Base URL 和一个 API Key就能在同一个 SDK 里切换不同模型。对流水线来说这意味着执行模型可以用便宜快的改写模型可以用推理强的切换只改一个字符串。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址不带查询参数配置时别把 UTM 拼进去。2.2 拿到 Key 并写进环境变量登录后在控制台创建 API Key页面在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建完立刻复制很多平台只显示一次。拿到之后不要硬编码进代码写进环境变量# macOS / Linux写进 ~/.zshrc 或 ~/.bashrc export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api# Windows PowerShell写进 $PROFILE $env:TAOTOKEN_API_KEYsk-你的key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api验证环境变量是否生效echo $TAOTOKEN_API_KEY # 应该输出 sk- 开头的一串而不是空行2.3 安装依赖流水线需要 Cursor SDK、OpenAI 兼容客户端、以及做数据处理的 pandas。Cursor SDK 的安装方式以官方文档为准这里给出通用依赖pip install openai pandas tqdm python-dotenv如果你用 Node 写编排层对应的是npm install openai dotenv2.4 用 .env 管理配置项目根目录建一个.env把模型 ID 也放进去方便切换TAOTOKEN_API_KEYsk-你的key TAOTOKEN_BASE_URLhttps://taotoken.net/api EXEC_MODELclaude-sonnet-4-5 JUDGE_MODELclaude-sonnet-4-5 REWRITE_MODELclaude-opus-4-1模型 ID 具体填什么去模型对话页面确认当前可用的名称 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。不同模型在改写任务上的表现差异很大改写模型建议选推理能力强的执行模型选响应快的这样整轮迭代的耗时和成本都更可控。2.5 测试集格式约定流水线对测试集有格式要求用 JSONL每行一条{id: case_001, input: 帮我总结这段话..., expected: 期望的输出, tags: [summary]} {id: case_002, input: 把这句话改成正式语气..., expected: 期望的输出, tags: [rewrite]}expected字段是评分基准。如果你的任务没有标准答案可以放一个「参考答案」或者评分要点评分模型会拿它做对比。tags用来做分组统计后面看哪一类 case 退化最严重时很有用。3. 可复制的 SDK 调用配置与评分脚本3.1 统一客户端封装先写一个薄封装把 TaoToken 的接入细节收在一处。这样后面执行、评分、改写三个环节都复用同一个客户端换模型只改参数。# llm_client.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), ) def chat(model: str, system: str, user: str, temperature: float 0.0) - str: resp client.chat.completions.create( modelmodel, temperaturetemperature, messages[ {role: system, content: system}, {role: user, content: user}, ], ) return resp.choices[0].message.content注意base_url结尾不要带斜杠OpenAI 客户端会自己拼/chat/completions。如果你写成https://taotoken.net/api/有些版本会拼出双斜杠导致 404。3.2 执行脚本用当前提示词跑测试集# run_eval.py import json from tqdm import tqdm from llm_client import chat import os EXEC_MODEL os.getenv(EXEC_MODEL) def run_testset(prompt_path: str, testset_path: str, out_path: str): with open(prompt_path, encodingutf-8) as f: system_prompt f.read() results [] with open(testset_path, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] for case in tqdm(cases, descrunning): try: output chat(EXEC_MODEL, system_prompt, case[input]) results.append({**case, output: output, error: None}) except Exception as e: results.append({**case, output: , error: str(e)}) with open(out_path, w, encodingutf-8) as f: for r in results: f.write(json.dumps(r, ensure_asciiFalse) \n) print(fdone, {len(results)} cases - {out_path}) if __name__ __main__: run_testset(prompt.txt, testset.jsonl, round_0_output.jsonl)temperature0.0是为了让同一版提示词的结果可复现。如果你做的是创意类任务需要多样性可以调高但那样评分波动会变大迭代信号会被噪声淹没。3.3 评分脚本让模型当裁判评分有两种做法规则打分和模型打分。规则打分适合分类、抽取这类有明确对错的模型打分适合摘要、改写这类主观性强的。这里给模型打分的版本输出结构化 JSON 方便统计。# judge.py import json from llm_client import chat import os JUDGE_MODEL os.getenv(JUDGE_MODEL) JUDGE_SYSTEM 你是一个严格的评分员。给定输入、期望输出、实际输出请判断实际输出是否满足要求。 只输出 JSON格式{score: 0或1, reason: 简短理由} score1 表示满足score0 表示不满足。不要输出任何其他内容。 def judge_one(case: dict) - dict: user f输入{case[input]} 期望输出{case[expected]} 实际输出{case[output]} raw chat(JUDGE_MODEL, JUDGE_SYSTEM, user) try: parsed json.loads(raw.strip().strip().replace(json\n, )) return {score: parsed[score], reason: parsed.get(reason, )} except Exception: return {score: 0, reason: fparse_failed: {raw[:80]}} def judge_file(in_path: str, out_path: str): with open(in_path, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] scored [] for c in cases: if c.get(error): scored.append({**c, score: 0, reason: exec_error}) continue j judge_one(c) scored.append({**c, **j}) total len(scored) passed sum(1 for s in scored if s[score] 1) acc passed / total if total else 0 with open(out_path, w, encodingutf-8) as f: for s in scored: f.write(json.dumps(s, ensure_asciiFalse) \n) print(faccuracy: {passed}/{total} {acc:.3f}) return acc评分模型和执行模型建议用同一个这样评分标准更稳定。如果你担心模型给自己打分有偏袒可以换成另一个模型做裁判但要在整个迭代过程中保持一致中途换裁判会让分数曲线失去可比性。3.4 改写脚本把 badcase 和 goodcase 一起送进去这是整条流水线的核心。改写模型拿到的信息包括当前提示词、若干 badcase含输入、期望、实际输出、失败原因、若干 goodcase含输入、期望、实际输出。要求它输出一版新提示词并且明确告诉它 goodcase 的行为不能破坏。# rewrite.py import json import random from llm_client import chat import os REWRITE_MODEL os.getenv(REWRITE_MODEL) REWRITE_SYSTEM 你是一个提示词优化专家。你会收到当前提示词、若干失败案例和若干成功案例。 你的任务是改写提示词使其能修复失败案例同时不破坏成功案例的行为。 要求 1. 只输出新的提示词正文不要输出解释、不要用代码块包裹。 2. 保持原有任务定义不变只调整指令的清晰度、约束、示例。 3. 如果失败案例暴露的是边界条件问题在提示词中补充对应规则。 4. 不要为了个别案例写出过度特化的规则。 def build_rewrite_input(prompt: str, bad: list, good: list) - str: def fmt(cases): lines [] for c in cases: lines.append(f- 输入{c[input]}\n 期望{c[expected]}\n 实际{c[output]}\n 原因{c.get(reason,)}) return \n.join(lines) return f当前提示词 {prompt} 失败案例需要修复 {fmt(bad)} 成功案例不能破坏 {fmt(good)} 请输出改写后的提示词。 def rewrite_prompt(prompt_path: str, scored_path: str, out_path: str, n_bad: int 8, n_good: int 4): with open(prompt_path, encodingutf-8) as f: prompt f.read() with open(scored_path, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] bad [c for c in cases if c[score] 0] good [c for c in cases if c[score] 1] random.seed(42) bad_sample random.sample(bad, min(n_bad, len(bad))) good_sample random.sample(good, min(n_good, len(good))) user build_rewrite_input(prompt, bad_sample, good_sample) new_prompt chat(REWRITE_MODEL, REWRITE_SYSTEM, user, temperature0.3) with open(out_path, w, encodingutf-8) as f: f.write(new_prompt.strip()) print(fnew prompt written to {out_path}, {len(new_prompt)} chars)random.seed(42)是为了让采样可复现。如果你想让每轮采样的 badcase 不同把 seed 去掉或者用轮次当 seed。3.5 编排脚本把四步串成循环# pipeline.py import os import shutil from run_eval import run_testset from judge import judge_file from rewrite import rewrite_prompt MAX_ROUNDS 5 PROMPT prompt.txt TESTSET testset.jsonl def main(): history [] for r in range(MAX_ROUNDS): out fround_{r}_output.jsonl scored fround_{r}_scored.jsonl new_prompt fround_{r1}_prompt.txt print(f\n round {r} ) run_testset(PROMPT, TESTSET, out) acc judge_file(out, scored) history.append({round: r, acc: acc}) if r MAX_ROUNDS - 1: break rewrite_prompt(PROMPT, scored, new_prompt) shutil.copy(new_prompt, PROMPT) # 用新提示词进入下一轮 print(\n history ) for h in history: print(fround {h[round]}: acc{h[acc]:.3f}) if __name__ __main__: main()跑起来就是python pipeline.py每一轮会产出round_N_output.jsonl原始输出、round_N_scored.jsonl带评分、round_N1_prompt.txt新提示词。这些文件全部保留方便你回溯每一轮改了什么。4. 跑通验证一轮优化前后的对比动作4.1 准备一个最小测试集先用 20 条 case 跑通链路别一上来就上 500 条。建一个testset.jsonl{id: c1, input: 把这句话改成正式语气这玩意儿挺好用的, expected: 该产品使用体验良好, tags: [rewrite]} {id: c2, input: 把这句话改成正式语气我明天可能来不了, expected: 我明日可能无法出席, tags: [rewrite]} {id: c3, input: 总结公司第三季度营收同比增长百分之十五主要来自海外市场, expected: 第三季度营收同比增长15%海外市场为主要驱动力, tags: [summary]}初始prompt.txt写一版能跑但不够精细的你是一个文本处理助手请根据用户输入完成任务。这版提示词没有明确任务类型、没有输出格式约束badcase 会很多正好用来验证改写环节有没有效果。4.2 第一轮跑完看什么跑完第一轮终端会打印类似accuracy: 11/20 0.550打开round_0_scored.jsonl重点看score0的那些 case 的reason字段。如果大量 reason 是「输出格式不对」「没有按要求改写」说明提示词缺约束如果是「理解错了任务」说明任务定义不清。4.3 第二轮提示词的变化改写模型拿到 badcase 后通常会补上任务分类、输出格式、示例。第二轮跑完accuracy: 17/20 0.850从 0.55 到 0.85这就是自动化迭代的价值。但别高兴太早打开round_1_scored.jsonl看那 3 条仍然失败的 case以及对比round_0_scored.jsonl里原本对的 case 有没有变错。如果发现某条原本对的现在错了说明改写模型过度调整了这时候要回到round_1_prompt.txt手动看一眼必要时在改写系统提示里加更强的「保持成功案例行为」约束。4.4 用表格看分组准确率光看总分不够按 tags 分组看# group_stats.py import json from collections import defaultdict def stats(path): g defaultdict(lambda: [0, 0]) with open(path, encodingutf-8) as f: for line in f: c json.loads(line) for t in c.get(tags, [untagged]): g[t][1] 1 if c[score] 1: g[t][0] 1 for t, (p, n) in g.items(): print(f{t}: {p}/{n} {p/n:.2f}) stats(round_1_scored.jsonl)如果 rewrite 类到了 0.95 而 summary 类只有 0.6说明改写模型把注意力都放在 rewrite 上了下一轮可以在改写输入里对 summary 类多采样几条 badcase。4.5 什么时候停三个停止信号连续两轮准确率提升小于 0.02跑满预设轮数或者你打开新提示词发现它开始写「如果输入包含某某关键词则……」这种特化规则。第三种情况最危险说明模型在过拟合测试集这时候应该停下来补充更多样的测试集而不是继续迭代。5. 常见报错与排查对照5.1 401 Unauthorizedopenai.AuthenticationError: Error code: 401 - {error: {message: Invalid API key}}三个检查点环境变量有没有真的加载echo $TAOTOKEN_API_KEYKey 有没有多余空格或换行复制时容易带上Key 是不是在控制台被删了。如果用的是.env确认load_dotenv()在OpenAI()之前调用。5.2 local proxy failed / connection erroropenai.APIConnectionError: Connection error.先确认TAOTOKEN_BASE_URL拼写正确是https://taotoken.net/api不是https://taotoken.net/api/v1也不是带斜杠结尾。然后确认本机网络能正常访问该域名。如果你在公司内网检查有没有 HTTP 代理环境变量干扰echo $HTTP_PROXY echo $HTTPS_PROXY有的话临时 unset 再跑。5.3 reading choices 报错TypeError: Cannot read properties of undefined (reading choices)这是 Node 版本常见问题通常是响应体不是预期的 JSON 结构。原因可能是 base_url 写错导致请求打到了别的路径返回了 HTML。打印一下原始响应const resp await client.chat.completions.create({...}); console.log(JSON.stringify(resp, null, 2));如果看到的是 HTML 或者{detail:Not Found}就是 base_url 的问题。5.4 评分 JSON 解析失败parse_failed: 我认为这个输出...评分模型没有严格输出 JSON。两个办法在系统提示里加「只输出 JSON第一个字符必须是 {」或者在解析前用正则提取第一个{...}块import re m re.search(r\{.*\}, raw, re.S) if m: parsed json.loads(m.group())5.5 OAuth / 认证方式混淆如果你同时用 Claude Code 或 Codex 这类工具它们可能走 OAuth 而不是 API Key。流水线里必须用 API Key 方式不要复用 CLI 工具的登录态。检查你的~/.codex/auth.json或类似配置文件确认流水线用的是独立的环境变量不要和 CLI 工具混用同一个凭证文件。5.6 三件套检查清单任何接入问题先核对这三项项目正确值常见错误Base URLhttps://taotoken.net/api带 /v1、带斜杠、带 UTM 参数API Keysk- 开头无空格复制时带换行、用了 CLI 的 OAuth tokenModel ID控制台确认的可用名称拼写错误、用了已下线的模型Model ID 去 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 核对别凭记忆写。5.7 迭代不涨分怎么办如果跑了两轮准确率纹丝不动先看 badcase 的 reason 是不是高度重复。如果全是同一类错误说明改写模型没抓住重点可以在改写输入里把这类 case 的采样权重调高。如果 reason 五花八门说明测试集本身太杂提示词再怎么改也覆盖不了这时候应该拆分任务一个提示词只干一件事。6. 把流水线接到日常开发里跑通之后这套东西可以进一步固化。把pipeline.py挂到 CI 里每次改提示词自动跑一轮回归准确率掉超过阈值就报警。或者把评分结果写进数据库画一条准确率随轮次变化的曲线团队里谁都能看到提示词演进的历史。如果你需要长期跑这类 Agent 编排任务可以考虑 Coding Plan按量计费比单次调用更划算 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入细节看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后留一个实操建议每轮迭代前先 git commit 当前提示词。这样当某一轮改崩了你能一条命令回滚而不是靠记忆重写。提示词也是代码值得用代码的方式管理。