企业官网建设流程全解析

1. 为什么ProTeGi值得单独写一篇笔记

第一次翻到ProTeGi这篇论文的时候，我的反应是"终于有人把提示词优化这件事讲成一个可复现的工程流程了"。在此之前，提示词优化在圈子里更像一门玄学：有人靠反复试错，有人靠直觉堆叠指令，有人干脆把希望寄托在模型换代上。ProTeGi（全称是Prompt Optimization with Textual Gradients，基于文本梯度的提示词优化）做的事情，是把"改提示词"这个动作拆解成一套有反馈、有方向、有迭代的闭环，让提示词优化从手工艺变成可批量执行的流程。

这篇笔记适合三类人看：一是手上有一批任务、需要稳定提升模型输出质量的人；二是想理解"文本梯度"这个概念到底怎么落地的人；三是准备自己复现或改造ProTeGi流程的人。我会把论文里的核心机制、我自己的理解、复现时踩过的坑、以及可以直接抄的参数配置都写清楚。核心关键词就三个：ProTeGi、提示词优化、论文笔记，全文围绕它们展开，不跑题。

先说结论性的判断：ProTeGi的价值不在于它提出了某个神奇的提示词模板，而在于它给出了一套**"生成-评估-反思-改写"的通用循环**。这套循环的骨架其实和很多优化算法是相通的，只不过把数值梯度换成了自然语言描述的"文本梯度"。理解了这个映射关系，后面所有的细节都会变得顺理成章。

2. ProTeGi的核心设计思路拆解

2.1 从数值梯度到文本梯度：一个关键的类比

要理解ProTeGi，先得理解它借用的那个类比。传统机器学习里，我们优化参数靠的是梯度：损失函数对参数求导，得到"往哪个方向调、调多少"的信息，然后沿着梯度反方向走一小步。ProTeGi把这个思路搬到了提示词上——提示词就是"参数"，模型的输出质量就是"损失"，而文本梯度就是一段自然语言写的"改进建议"，告诉你当前提示词哪里不好、应该往哪个方向改。

这个类比妙在哪？妙在它绕开了"提示词是离散文本、没法求导"这个死结。既然没法算数值梯度，那就让模型自己用语言描述"梯度"。论文里的做法是：给定当前提示词、一批输入样本、以及每个样本的输出和对应的评价（比如打分或错误标记），让模型生成一段批评意见，这段批评意见就是文本梯度。它可能长这样："当前提示词没有明确要求输出格式，导致模型有时输出解释有时只输出答案；另外没有给出边界情况的处理方式。"——你看，这就是一段有方向性的改进信号。

我个人的理解是，文本梯度的本质是把"哪里错了"和"怎么改"这两件事解耦。传统试错法里，人看到错误输出，脑子里同时要完成"诊断"和"开方"两步，很容易顾此失彼。ProTeGi把诊断交给模型（生成文本梯度），把开方也交给模型（根据梯度改写提示词），人只需要把控循环和评估标准。这个分工是它工程价值的基础。

2.2 为什么是"文本"而不是"数值打分"

有人会问：既然要评估，为什么不直接给提示词打个分，然后做搜索？这就涉及到提示词优化的一个根本困难——搜索空间太大且不连续。一句提示词改一个词，语义可能天翻地覆，也可能毫无变化，数值打分只能告诉你"这个提示词好还是不好"，但没法告诉你"往哪个方向改会更好"。这就是典型的稀疏反馈问题。

文本梯度的优势在于它提供了密集的、有语义的方向信息。它不只是说"这个提示词得了0.6分"，而是说"得了0.6分是因为缺少格式约束和边界处理"。后者可以直接指导下一步改写，前者只能让你盲目再试。我在实际项目里对比过这两种方式：纯打分搜索在提示词较短、任务较简单时还能凑合，一旦任务复杂、约束多，纯搜索的收敛速度会慢到让人绝望，而带文本梯度的迭代通常三五轮就能看到明显改善。

2.3 整体流程的四个阶段

把ProTeGi的流程拆开，其实是四个阶段循环：

1. 初始化：给一个初始提示词，可以很粗糙，甚至就是一句"请完成以下任务"。
2. 评估：用当前提示词在一批训练样本上跑一遍，收集输出和评价。
3. 生成文本梯度：把提示词、样本、输出、评价一起喂给模型，让它写出改进建议。
4. 改写提示词：根据文本梯度，让模型生成新的提示词，然后回到第2步。

这个循环会跑若干轮，每轮都保留表现最好的提示词（论文里叫"beam"或者候选池），最后选评估分数最高的那个作为最终提示词。注意这里有个细节：不是每轮都无条件接受新提示词，而是要和历史最优比较，只有更好才替换。这个"保留最优"的机制很关键，它防止了优化过程来回震荡甚至越改越差。

3. 核心细节解析与实操要点

3.1 文本梯度到底怎么生成

这是整个方法里最需要拿捏的部分。文本梯度的生成质量直接决定了优化效果，而它的生成又高度依赖你给模型的上下文。论文里的做法是把以下几样东西拼成一个提示，让模型输出批评意见：

• 当前的提示词全文
• 一批（通常几个到十几个）输入样本
• 每个样本对应的模型输出
• 每个输出的评价（正确/错误，或者分数，或者具体的错误类型）

我实测下来，评价信息的粒度对梯度质量影响极大。如果只给"对/错"，模型生成的梯度往往很泛，比如"需要更清晰"这种废话。如果给出具体的错误类型，比如"这个样本错在把日期格式理解成了月/日而不是日/月"，模型生成的梯度就会非常具体，改写出来的提示词也更有针对性。所以我的建议是：在评估阶段尽量记录结构化的错误信息，哪怕多花点功夫做错误分类，回报是值得的。

还有一个容易忽略的点：样本的选择。如果一批样本全是简单题，梯度会告诉你"当前提示词已经够好"；如果全是难题，梯度又会过度聚焦在边缘情况上。论文里用的是随机采样，但我在实践中会做分层采样——简单、中等、困难各取一些，这样生成的梯度更均衡，改出来的提示词泛化性更好。

3.2 改写阶段的约束设计

生成文本梯度之后，下一步是让模型根据梯度改写提示词。这一步看似简单，其实坑很多。最常见的坑是模型改着改着把提示词改跑偏了——本来只是要修格式问题，结果它把整个任务描述都重写了，引入了新的问题。

论文里对这个问题的处理是加约束：要求改写后的提示词保持原意、只做增量修改、长度不要暴涨。我在复现时进一步细化了几条规则，实测有效：

• 明确要求"保留原提示词中所有仍然正确的要求"
• 限制新提示词的长度不超过原来的1.5倍
• 要求改写时逐条对应文本梯度里的建议，不要自由发挥
• 如果某条建议和现有提示词冲突，优先保留现有提示词

这些约束看起来琐碎，但它们把改写这个动作从"自由创作"拉回到了"受控编辑"，稳定性提升非常明显。我做过对比：不加约束的版本，五轮迭代里有大概两轮会出现性能回退；加了约束之后，回退基本消失。

3.3 评估环节的样本量与成本权衡

评估是ProTeGi里最耗资源的一环，因为每轮都要在训练集上跑一遍。样本量怎么定？论文里用的规模不算大，但也没给出一个放之四海皆准的数字。我的经验是：评估样本量至少要能区分出两个提示词的优劣。如果你只有5个样本，两个提示词可能都是4/5正确，根本分不出高下，优化就失去了方向。

一个实用的做法是先用小样本快速迭代，等提示词稳定了再用大样本做最终验证。比如前几轮每轮用20个样本，最后两轮用100个样本。这样既控制了成本，又保证了最终选择的可靠性。另外，评估样本和最终测试样本一定要严格分开，否则你优化出来的提示词只是在训练样本上过拟合，换个数据集就原形毕露。这个坑我踩过，当时优化出来的提示词在训练集上准确率95%，换到新数据直接掉到70%，教训很深。

3.4 候选池与beam search的取舍

ProTeGi在改写阶段会生成多个候选提示词（论文里叫beam），然后评估选最好的。这个设计借鉴了beam search的思路。候选数量多了，找到好提示词的概率高，但成本也线性上升。我的建议是候选数控制在3到5个，再多边际收益就很小了。而且候选之间最好有多样性约束——如果5个候选长得都差不多，那和只生成1个没区别。可以在改写提示里要求"生成N个风格不同的版本"，或者对候选做去重。

4. 实操过程与核心环节实现

4.1 环境与依赖准备

复现ProTeGi不需要什么特殊环境，核心就是能调用大模型API。我用的是Python，主要依赖就几个：

pip install openai tqdm pandas numpy

如果你用的是其他模型服务，把对应的SDK换掉就行。关键是要有一个稳定的评估函数，它接收"提示词+输入"，返回"输出+评价"。这个函数是整个流程的地基，一定要先把它写扎实。

4.2 评估函数的实现要点

评估函数看起来简单，其实决定了整个优化的上限。我把它拆成三步：

def evaluate(prompt, dataset): results = [] for item in dataset: output = call_model(prompt, item["input"]) score, error_type = judge(output, item["expected"]) results.append({ "input": item["input"], "output": output, "expected": item["expected"], "score": score, "error_type": error_type }) avg_score = sum(r["score"] for r in results) / len(results) return avg_score, results

这里judge函数是重点。如果任务有标准答案，可以直接比对；如果是开放式任务，就得用模型来打分，这时候要小心打分模型本身的偏差。我的做法是让打分模型输出结构化的结果（分数+错误类型+简短理由），而不是一个笼统的分数，这样后续生成文本梯度时信息更丰富。

4.3 文本梯度生成的提示词模板

这是整个流程里我改动最多的地方。论文里的模板比较简洁，我根据自己的任务做了扩充。核心结构是这样的：

你是一个提示词优化专家。当前提示词如下： 【当前提示词】 以下是一批样本的执行结果： 【样本1】输入：... 输出：... 期望：... 评价：... 【样本2】... 请分析当前提示词存在的问题，输出一段改进建议。要求： 1. 指出具体是哪类样本出了问题 2. 说明问题的根本原因（是提示词缺少约束，还是表述有歧义） 3. 给出明确的修改方向，但不要直接写出新提示词

注意最后一条"不要直接写出新提示词"——这是为了让生成梯度和改写两个阶段分开，避免模型在生成梯度时就把改写做了，导致后面改写阶段没有发挥空间。分开之后，梯度更聚焦于诊断，改写更聚焦于执行，各司其职。

4.4 改写阶段的提示词模板

改写阶段的模板要强调"受控编辑"：

根据以下改进建议，修改当前提示词： 【当前提示词】 【改进建议】 要求： 1. 保留原提示词中所有仍然有效的内容 2. 只针对改进建议做修改，不要重写整个提示词 3. 新提示词长度不超过原来的1.5倍 4. 输出修改后的完整提示词，不要输出解释

我实测下来，第4条"不要输出解释"很重要。如果不加这条，模型经常会在提示词后面附一段"我做了如下修改……"，这段解释如果被当成提示词的一部分，会污染后续的评估。所以要么明确要求只输出提示词，要么在代码里做后处理把解释部分切掉。

4.5 完整循环的代码骨架

把上面几块拼起来，主循环大概长这样：

best_prompt = initial_prompt best_score, _ = evaluate(best_prompt, train_set) for round in range(max_rounds): _, results = evaluate(best_prompt, train_set) gradient = generate_textual_gradient(best_prompt, results) candidates = rewrite_prompt(best_prompt, gradient, n=3) for cand in candidates: score, _ = evaluate(cand, train_set) if score > best_score: best_score = score best_prompt = cand print(f"Round {round}: best score = {best_score}") final_score, _ = evaluate(best_prompt, test_set)

这个骨架很朴素，但包含了ProTeGi的全部核心逻辑。你可以在此基础上加日志、加早停、加候选池管理，但骨架不要动。

4.6 参数选择的计算过程

几个关键参数我给出自己的取值和理由：

这些数字不是拍脑袋来的。比如候选数3，是因为我做过2、3、5的对比，3和5的最终效果差异在1%以内，但5的成本高了近一倍。再比如早停条件，连续2轮无提升基本可以判定已经到局部最优，继续跑大概率是浪费。

5. 常见问题与排查技巧实录

5.1 优化过程中性能震荡怎么办

这是最常见的问题：第3轮比第2轮好，第4轮又掉回去了。原因通常是改写引入了新问题。排查思路是：把每轮的提示词和文本梯度都存下来，对比看是哪次改写引入了回退。我遇到过一次，模型在改写时把"输出JSON格式"改成了"输出结构化格式"，结果模型开始输出各种奇怪的结构。解决办法就是在改写约束里加一条"不要修改输出格式相关的硬性要求"。

5.2 文本梯度总是很空泛

如果生成的梯度总是"需要更清晰""需要更多示例"这种废话，八成是评估信息给得太少。检查你的评估函数是不是只返回了分数，没有返回具体的错误类型和错误样本。把错误样本和错误类型喂给梯度生成模型，梯度质量会立刻提升一个档次。

5.3 优化后的提示词过拟合训练集

这个前面提过，核心原因是训练集和测试集没有严格分开，或者训练集样本太少、太单一。解决办法有两个：一是扩大训练集并做分层采样；二是在评估时加入"留出验证集"，每轮除了看训练集分数，也看验证集分数，选两者都好的提示词。我现在的做法是训练集、验证集、测试集按6:2:2分，优化过程只看训练集和验证集，测试集只在最后用一次。

5.4 成本失控

ProTeGi的token消耗主要在三块：评估、梯度生成、改写。评估是大头，因为每轮都要跑全量样本。控制成本的关键是前期用小样本、少候选。我一般前3轮用20个样本、2个候选，确认方向对了再加大投入。另外，评估结果可以缓存——如果两个候选提示词在某个样本上输出相同，就不用重复调用模型。

5.5 常见问题速查表

5.6 几个我踩过的坑

第一个坑是评估函数里的模型和优化用的模型是同一个。这会导致评估有偏——模型倾向于给自己生成的输出打高分。后来我换了一个不同的模型做评估，客观性好了很多。第二个坑是没有保存中间结果。有一次跑到第6轮发现效果最好的是第3轮的提示词，但没存，只能重跑。从那以后我每轮都把提示词、梯度、分数存成JSON。第三个坑是初始提示词太复杂。我一开始给了一个写得很详细的初始提示词，结果优化空间很小，几轮下来几乎没变化。后来换成一句简单的"请完成以下任务"，优化效果反而更明显。这说明ProTeGi更适合从简到繁的优化路径。

6. 我对ProTeGi的延伸思考

ProTeGi这套流程跑通之后，我发现它的骨架其实可以迁移到很多场景。比如你可以把"文本梯度"换成"用户反馈"，把"改写"换成"人工调整"，整个循环依然成立——本质上它是一个带反馈的迭代优化框架，只是ProTeGi把反馈和调整都自动化了。

另一个值得琢磨的点是多任务联合优化。如果你的多个任务共享一部分提示词结构，能不能用ProTeGi同时优化？我试过一个简化版：把多个任务的样本混在一起生成梯度，然后改写一个通用提示词。效果不算惊艳，但在任务相似度较高时确实能省不少事。这个方向我觉得还有挖掘空间。

最后一个体会是关于人的角色。ProTeGi把优化过程自动化了，但人并没有被完全替代——你需要定义评估标准、设计约束、判断何时停止。这些决策的质量，直接决定了自动化流程能走多远。所以与其说ProTeGi是"替代人写提示词"，不如说它是"把人从重复劳动里解放出来，去做更关键的判断"。这个定位想清楚了，用起来就顺手了。