NPO单线提示优化：以更少预算实现稳定AIGC输出

AIGC 项目落地时，最耗时间的往往不是模型选型，而是提示词调整。团队里经常出现“同一个 Prompt 上一轮效果很好，换了一个模型版本就崩了”“为了让模型稳定输出 JSON，试了十几种写法”“每轮对话都要人工修补输出格式”这类问题。这些场景既消耗 token，也消耗开发精力。

最近在梳理团队内部的 AIGC 内容生成链路时，我对比了两种提示词优化思路：一种叫“单线提示优化”，圈内常称 NPO（Narrow Prompt Optimization），另一种是面向全链路参数对齐的 GEPA（Global Enumeration & Parameter Alignment）。在这套方案里，我们最终用更少的预算，达到了接近复杂优化流程的效果。本文将围绕这个对比展开，梳理概念、拆解方法、给出可直接复用的提示词模板和评测脚本，也回答几个容易被忽略的细节问题。

本文适合三类读者：

• 正在做 AIGC 应用、需要提升模型输出稳定性的人；
• 想减少 prompt 调优成本、降低 API 调用费用的工程师；
• 对“AI 提示词优化、AIGC 提示词设计”这类新型岗位内容感兴趣，想了解具体工作方法的人。

在看具体模板之前，我们先把 NPO 和 GEPA 这两个概念讲清楚。需要提前说明的是，这两个叫法并非严格意义上的行业标准术语，更多是团队内部对两种优化思路的总结性代号。不同公司的命名可能不同，但背后解决的问题是相通的。

1. 背景：AIGC 内容生成中的提示词优化问题

1.1 提示词不是“写一段话”那么简单

很多人刚开始接触大模型时，觉得提示词就是“把需求说清楚”。但在真实业务中，提示词承担的责任远比想象中复杂。

以内容生成类项目为例，一个合格的提示词需要同时实现以下目标：

• 明确任务边界，让模型知道“要做什么、不做什么”；
• 约束输出格式，便于下游程序解析；
• 控制内容风格，让结果符合品牌调性；
• 控制风险，避免模型生成不符合安全底线的内容；
• 减少多轮返工，降低 token 消耗。

由此看来，提示词优化本质上是在做一种“面向大模型的接口设计”。如果接口设计得不好，模型返回的结果就会不稳定，进而导致下游解析报错、人工修复成本上升。近两年出现在招聘市场上的“AI 提示词优化师”“AIGC 提示词设计”等岗位，处理的核心问题也正是这一类。

1.2 为什么提示词优化会消耗大量预算

先看一个开发中的常见现象：

一个内容生成需求，最初提示词只有一两句话，测试时发现输出格式不稳定。于是开始补充“请以 JSON 格式输出”“不要输出多余内容”“每个字段的含义如下”。模型偶尔还是会犯错，然后继续加示例、加 negative prompt（反向约束）、加 few-shot 示例。最终提示词可能膨胀到几千字，但每次调用都会把这些内容全部送入模型。

这样做的结果是：

• 单次调用 token 增加，费用上升；
• 响应速度变慢，影响用户体验；
• 模型注意力被长提示词分散，核心指令反而被忽略；
• 后续维护困难，改一个词可能影响全链路输出。

因此，提示词优化不能只追求“模型偶尔输出正确”，而应该追求“用最少的信息达到稳定的、可复现的输出”。这正是 NPO 单线提示优化要解决的核心问题。

2. NPO 与 GEPA：两种提示优化思路拆解

2.1 NPO：单线提示优化

NPO，即 Narrow Prompt Optimization，我把它理解为“窄口径提示优化”。它的核心主张是：在一条独立的提示词链路中，把任务背景、角色设定、输入数据、输出要求、反向约束等要素一次性设计完整，尽量让模型一次调用即可产出符合预期的结果。

NPO 有以下几个特点：

• 单线：每次任务只围绕一条核心提示词，不依赖多轮对话或外部二次清洗；
• 独立：每个场景拥有独立的提示词模板，模板之间不互相牵连；
• 聚焦：明确“当前这一步只需要解决什么问题”，不做过度包装；
• 可控：输出结构在设计时就已经确定，后续只需校验字段和边界。

举一个最简单的场景：

如果我们要让模型从一段客户反馈中提取“姓名、联系方式、问题类型、紧急程度”，NPO 的做法是将这四项明确写入提示词，并给出格式示例，而不是简单地说“提取客户信息”。

2.2 GEPA：全局枚举与参数对齐优化

GEPA，即 Global Enumeration & Parameter Alignment。它代表一种更重、更全面的优化思路：把所有可能影响输出的参数全部纳入优化范围，包括模型版本、temperature、top_p、max_tokens、system prompt、few-shot 示例、输出格式指令、后处理逻辑等。通过枚举不同配置组合，找到一组“最优参数矩阵”。

GEPA 的优点是效果好、覆盖全面，能发现一些单条提示词无法暴露的问题。但缺点也很明显：

• 实验组合爆炸，测试成本高；
• 调参结果容易过拟合到特定测试集；
• 当模型版本更新时，参数矩阵往往需要重新验证；
• 团队协作成本高，新人难以快速上手。

在预算有限的情况下，GEPA 容易把项目拖入“调参无底洞”。相比之下，NPO 更偏向工程化落地：先保证单条提示词稳定，再考虑全局参数组合。

2.3 两者的关系：不是替代，而是分层

严格来说，NPO 和 GEPA 并不是对立关系，而是不同颗粒度的优化手段。

在实际项目中，比较合理的做法是：

• 第一阶段：用 NPO 思路设计单条提示词，追求单点稳定；
• 第二阶段：如果单条提示词已经稳定，再评估是否需要引入 GEPA 做全局参数组合；
• 第三阶段：当模型版本升级或业务需求变化时，优先回归验证单条提示词，再决定是否调整全局参数。

本文后续内容会重点展开 NPO 的实施细节，因为它是成本最低、见效最快的切入点，也是后续做全局参数对齐的基础。

3. 环境准备与版本说明

进行提示词优化，并不需要特别复杂的开发环境，但有几点准备工作值得提前完成。

3.1 推荐的运行环境

以下是团队内部使用的参考环境，你可以根据项目实际情况调整：

• 操作系统：Windows 10/11、macOS 或 Linux 均可；
• 编程语言：Python 3.9+；
• 大模型 API：以兼容 OpenAI 接口的服务或国内大模型 API 为例；
• 开发工具：VS Code 或 PyCharm，配合 Jupyter Notebook 做快速实验；
• 版本管理：Git，用于对提示词模板和测试用例做版本管理。

需要说明的是，不同大模型对提示词的敏感度不同，同一个提示词在模型 A 和模型 B 上的表现可能差异很大。本文的示例代码以通用接口调用为例，实际使用时请根据所选模型的官方文档调整请求参数。

3.2 项目目录结构建议

为了方便管理提示词模板和测试脚本，建议采用下面的目录结构：

prompt-optimization/ ├── prompts/ # 提示词模板文件（按场景拆分） │ ├── customer_feedback.md │ ├── product_copy.md │ └── data_extract.yaml ├── scripts/ # 测试与评测脚本 │ ├── call_model.py │ ├── evaluate.py │ └── run_regression.py ├── test_cases/ # 测试用例集 │ ├── case_001.json │ └── case_002.json └── README.md

3.3 统一模型调用封装

为了避免每个脚本重复写 API 调用逻辑，建议先封装一个统一的模型调用函数。这里以兼容 OpenAI 接口的服务为例，使用环境变量保存 API Key，避免明文写在代码中。

# 文件路径：scripts/call_model.py import os import json from openai import OpenAI def call_model(prompt, system_prompt="", temperature=0.2, max_tokens=1024): client = OpenAI( api_key=os.environ.get("LLM_API_KEY"), base_url=os.environ.get("LLM_BASE_URL"), ) messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) messages.append({"role": "user", "content": prompt}) response = client.chat.completions.create( model=os.environ.get("LLM_MODEL", "gpt-4o-mini"), messages=messages, temperature=temperature, max_tokens=max_tokens, ) return response.choices[0].message.content if __name__ == "__main__": result = call_model("请用一句话介绍你自己。") print(result)

这里需要注意：

• api_key 和 base_url 通过环境变量注入，不要硬编码在代码中；
• temperature 默认设成 0.2，是为了在内容生成类任务中保持一定的稳定性；
• max_tokens 需要根据业务场景调整，过长会造成浪费，过短会导致输出被截断；
• 使用时请确认你已经获得对应模型服务的合法访问权限，并遵守服务方的使用条款。

4. NPO 单线提示优化的核心方法

这一部分是全文重点。我们按照“指令结构设计、约束表达技巧、参数选择、输出解析”四个维度，拆解单线提示优化中的关键方法。

4.1 单线提示词的基本结构

一条优秀的单线提示词，通常包含六个组成部分。下面用一个思维导图式的列表来呈现：

1. 角色设定：定义模型以什么身份完成任务；
2. 任务描述：一句话说清楚要做什么；
3. 输入数据：把待处理的数据放入固定标记中；
4. 输出格式：指定返回结果的结构；
5. 边界约束：说明不该做什么；
6. 补充示例：在必要时给出一个输入输出对作为参考。

以“客户反馈信息提取”为例，一个符合 NPO 思路的提示词模板如下：

你是一名客户服务数据分析助手。 请从用户反馈中提取以下四个字段： 1. user_name：客户姓名 2. contact_way：联系方式（手机号或邮箱） 3. problem_type：问题类型（取值范围：账号问题、支付问题、物流问题、产品质量、其他） 4. urgency_level：紧急程度（取值范围：高、中、低） 要求： - 只输出 JSON，不要输出其他解释内容； - 如果某个字段无法提取，使用 null 填充； - 问题类型只从给定范围中选择； - 联系方式需要脱敏处理，手机号中间四位用 * 代替。 用户反馈如下： """ {user_feedback} """ 请按照以下格式输出： { "user_name": "", "contact_way": "", "problem_type": "", "urgency_level": "" }

这个模板具备六个基本要素，同时通过“要求”和“输出格式示例”对模型做了双重约束。与“请提取客户反馈中的关键信息”相比，输出的稳定性和可解析性都有明显提升。

4.2 约束表达技巧：正向约束与反向约束

只告诉模型“要做什么”往往不够，还需要明确“不要做什么”。在提示词工程中，这两者分别称为正向约束和反向约束。

正向约束示例：

• “只输出 JSON 对象，不要输出 markdown 代码块标签”；
• “每个字段的取值只能从枚举范围内选择”；
• “如果信息不明确，使用 null 代替猜测”；
• “不要编造用户反馈中不存在的信息”。

反向约束示例：

• “禁止输出与 JSON 无关的内容”；
• “不要解释你的思考过程”；
• “不要使用列表格式”；
• “不要重复用户反馈中的敏感信息”。

需要提醒的是，约束并不是越多越好。过量的约束会让模型进入“过度防御”状态，表现为输出变短、不敢回答、频繁返回默认值。通常每个场景保留 3 到 6 条关键约束即可。

4.3 系统提示词与用户提示词的拆分

有些大模型接口支持 system、user、assistant 三种消息角色。利用角色区分，可以进一步压缩单条用户提示词的长度，把固定规则放到系统提示词中，把动态数据放到用户消息中。

以同样的信息提取场景为例，我们可以这样拆分：

# system prompt 你是一名客户服务数据分析助手。 提取规则： - 只输出 JSON，不要包含其他内容； - 字段缺失时使用 null； - 联系方式需要脱敏； - 问题类型只能从给定范围中选择。 # user prompt 用户反馈： """ {user_feedback} """ 请提取以下字段： user_name, contact_way, problem_type, urgency_level

这样做的好处是：

• 系统提示词中存放固定规则，每次请求重复发送，但结构稳定；
• 用户提示词中只放动态数据，减少格式化拼接出错的可能；
• 后续需要调整规则时，只需改动系统提示词，便于统一管理。

4.4 利用 JSON Mode 或结构化输出

如果所选模型支持 JSON Mode 或结构化输出，建议优先使用，因为这些机制会从模型层面约束输出。下面是一个参考示例，展示了如何通过 response_format 指定 JSON 输出。

# 文件路径：scripts/call_model_json.py import os import json from openai import OpenAI def call_model_json(prompt, system_prompt=""): client = OpenAI( api_key=os.environ.get("LLM_API_KEY"), base_url=os.environ.get("LLM_BASE_URL"), ) messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) messages.append({"role": "user", "content": prompt}) response = client.chat.completions.create( model=os.environ.get("LLM_MODEL", "gpt-4o-mini"), messages=messages, temperature=0.2, response_format={"type": "json_object"}, ) content = response.choices[0].message.content return json.loads(content)

这段代码的核心点是：

• 通过 response_format 参数请求模型返回 JSON 对象；
• 使用 json.loads 将文本转为 Python 字典；
• 在解析前可以先做一次 try-except，防止模型返回非法 JSON。

并不是所有模型服务商都支持这个参数，使用前请查阅对应接口文档。如果不支持，可以在提示词中强制要求“不输出 markdown 代码块”，并在后处理中过滤多余字符。

4.5 温度与生成参数的选择

temperature 控制着模型输出的随机性。数值越低，输出越稳定，但可能显得机械；数值越高，输出越丰富，但容易出现格式漂移。

经验参考如下：

在 NPO 思路中，如果发现模型输出频繁出现格式问题，第一步不是改提示词，而是将 temperature 降低。如果降低后问题依旧，再考虑调整提示词结构。

5. 实战案例：用 NPO 优化广告文案生成提示词

下面用一个完整的实战案例，展示单线提示优化从“原始提示词”到“优化后提示词”的完整过程，并对比预算消耗的变化。

5.1 需求描述

业务方希望模型根据产品信息和目标人群，产出三条不同风格的商品推广文案。要求：

• 每条文案不超过 50 字；
• 必须包含产品核心卖点；
• 输出格式方便下游系统写入数据库；
• 文案风格不能低俗或夸大。

5.2 原始提示词（优化前）

最初版本的提示词是这样的：

请根据下面这个产品写3条商品推广文案。产品：无线蓝牙耳机，卖点是降噪、续航长、佩戴舒适。

这个提示词存在几个明显问题：

• 没有说明文案字数限制；
• 没有给出目标人群；
• 没有定义输出结构；
• 没有排除夸大宣传等风险内容。

在实际测试中，类似提示词会出现文案过长、卖点遗漏、输出格式混乱等情况，通常需要多轮补充说明才能得到可用结果。

5.3 NPO 优化后的提示词（优化后）

按照 NPO 思路重新设计后，提示词变成了这样：

你是一名电商文案策划专家。 任务：根据提供的产品信息，生成 3 条商品推广文案。 产品信息： """ 产品名称：轻音无线蓝牙耳机 核心卖点：主动降噪、30小时长续航、佩戴舒适 目标人群：通勤族、办公室白领 """ 写作要求： - 每条文案不超过 50 个字； - 每条文案必须包含至少一个核心卖点； - 风格可以分别侧重：通勤场景、办公场景、运动场景； - 禁止使用夸张表述，如“史上最强”“绝对最好”； - 每条文案末尾用 | 分隔。 输出格式： 文案1：... | 文案2：... | 文案3：...

优化后的提示词做了什么？

• 角色设定让模型进入文案专家模式；
• 产品信息结构化，避免模型漏读关键卖点；
• 写作要求明确了字数、卖点、风格和禁用词；
• 输出格式指定了分隔符，方便后处理拆分。

5.4 批量评测脚本

为了验证优化效果，我们需要一个简单的评测脚本。它会对同一批输入数据分别使用旧提示词和新提示词，并统计模式化的指标，比如是否包含规定字段、是否超出字数限制、一次调用是否成功等。

# 文件路径：scripts/evaluate.py import re from call_model import call_model OLD_PROMPT = "请根据下面这个产品写3条商品推广文案。产品：无线蓝牙耳机，卖点是降噪、续航长、佩戴舒适。" NEW_PROMPT = """你是一名电商文案策划专家。 任务：根据提供的产品信息，生成 3 条商品推广文案。 产品信息： """ 产品名称：轻音无线蓝牙耳机 核心卖点：主动降噪、30小时长续航、佩戴舒适 目标人群：通勤族、办公室白领 """ 写作要求： - 每条文案不超过 50 个字； - 每条文案必须包含至少一个核心卖点； - 风格可以分别侧重：通勤场景、办公场景、运动场景； - 禁止使用夸张表述，如“史上最强”“绝对最好”； - 每条文案末尾用 | 分隔。 输出格式： 文案1：... | 文案2：... | 文案3：... """ def evaluate(prompt: str, case_id: str): output = call_model(prompt, temperature=0.3, max_tokens=512) items = [item.strip() for item in output.split("|") if item.strip()] result = { "case_id": case_id, "item_count": len(items), "output": output, } # 简单检查每条文案是否包含“降噪”或“续航” keyword_hit = any(("降噪" in item or "续航" in item) for item in items) result["keyword_hit"] = keyword_hit return result if __name__ == "__main__": for name, prompt in [("OLD", OLD_PROMPT), ("NEW", NEW_PROMPT)]: r = evaluate(prompt, case_id=name) print(name, r)

这个脚本的作用并不是做全面的自然语言质量评估，而是快速发现格式漂移和关键词缺失问题。如果旧提示词在 10 次测试中有 5 次格式错误，而新提示词在 10 次测试中只有 1 次格式错误，那么优化思路就是有效的。

5.5 预算变化对比

预算消耗可以用“单次调用 token 数 × 调用次数”来估算。假设一次调用的固定消耗如下：

从这个对比可以看出，优化后的提示词虽然单次调用更“重”，但因为一次通过率更高，整体预算反而更低。这也是 NPO 的核心价值：不追求单次调用最便宜，而是追求项目整体成本最优。

5.6 运行说明

运行上面的脚本前，请先设置环境变量：

export LLM_API_KEY="你的API Key" export LLM_BASE_URL="你的API地址" export LLM_MODEL="你的模型名称"

然后再运行：

python scripts/evaluate.py

请根据实际服务商提供的模型名称和接口信息调整环境变量，不要照抄示例中的占位内容。

6. 如何用更少预算追平 GEPA

看到这里，你可能会问：NPO 相对简单，GEPA 听起来更全面，那 NPO 凭什么追平 GEPA？关键在于“预算分配”和“优化节奏”。

6.1 把预算花在“高杠杆”环节

GEPA 的做法是把预算分散到大量实验组合中，去枚举各种参数和提示词变体。NPO 的做法则是先用较少的实验确定单条提示词结构，再集中预算做回归测试和线上验证。

在预算有限的情况下，NPO 更符合“二八定律”：

• 80% 的输出稳定性问题，往往来自提示词结构不合理；
• 只有少数情况需要调整 temperature 或 top_p；
• 盲目枚举参数组合，容易陷入局部调优。

6.2 建立回归测试集

不管你采用哪种优化思路，回归测试集都是必不可少的。它的作用是防止优化 A 场景时破坏了 B 场景。

一个简单的回归测试集可以包含以下内容：

• 10 到 20 条代表性输入数据；
• 每条数据标注期望输出结构；
• 每次修改提示词后，运行回归测试；
• 记录通过率、格式错误率、关键词命中率。

下面是一个回归测试用例的 JSON 示例：

{ "case_id": "case_001", "input": "你们这个耳机戴着很舒服，但是降噪效果一般，坐地铁还是能听到声音。", "expected_fields": ["problem_type", "urgency_level"], "expected_problem_type": "产品质量", "expected_urgency_level": "中" }

把测试用例保存在 test_cases 目录下，配合脚本自动执行，可以帮助团队在多人维护提示词时避免“互相覆盖”的问题。

6.3 评估指标不要只看“最终结果”

很多团队在评估提示词优化效果时，只关注“最终输出是否能解析”，却忽略了过程中的不稳定因素。建议至少记录以下指标：

• 格式错误率：模型返回内容无法被程序解析的比例；
• 字段缺失率：能解析但关键字段为 null 或缺失的比例；
• 一次通过率：无需人工修正即可直接使用的比例；
• 平均调用次数：达到一次可用结果所需尝试次数；
• 平均 token 消耗：每次任务最终消耗的 token 总量。

这些指标共同反映了“更少预算”是否真正落地。

6.4 与“AI 提示词优化”岗位新趋势的结合

近期的招聘趋势中，与“AIGC 提示词设计”“AI 生成内容优化”相关的岗位需求增长很快。这与各行业加速落地 AIGC 应用有关，也说明团队开始把提示词优化当作一项需要专门投入的工作。

从团队协作的角度来看，建议项目组明确一位提示词 Owner，负责管理提示词模板、测试集和优化记录。这样即使团队人员变动，提示词资产也不会丢失。

7. 常见问题与排查思路

在实施提示词优化时，下面几个问题出现的频率最高。

下面展开几个高频问题的排查思路。

7.1 模型输出格式不稳定

这个问题通常有三个原因：

1. 提示词中格式要求与示例不一致；
2. temperature 过高；
3. 模型本身不支持强约束输出。

排查顺序建议：

• 先把 temperature 降到 0；
• 如果还是不稳定，检查提示词中是否存在相互矛盾的指令；
• 如果仍然不行，考虑使用模型的 JSON Mode 或 Function Calling 能力；
• 最后再检查后处理逻辑是否可以兜底。

在要求模型输出 JSON 时，一个容易被忽略的细节是：提示词里的“字段名”要和代码解析时使用“字段名”保持完全一致。例如提示词中写的是 user_name，代码解析时就不要写成 username。

7.2 输出结果过于简略

为了让模型“少废话”，有些人在提示词里写了过多反向约束，导致模型输出变得过于机械，甚至缺少必要信息。

解决方案是：

• 删除重复的“不要解释”“不要多余内容”等指令；
• 明确告知模型“如果信息不足，可以根据已知信息做推断”；
• 增加示例，让模型理解信息密度要求。

7.3 响应速度变慢

如果同一个 API 请求需要传入很长的提示词，响应速度必然会变慢。优化思路包括：

• 将不随请求变化的规则放入 system prompt；
• 压缩历史对话内容，只保留必要上下文；
• 减少 few-shot 示例的数量；
• 用更精确的枚举值代替长句子描述。

8. 最佳实践与工程建议

8.1 为提示词建立版本管理

提示词是 AIGC 项目的重要资产，应当像代码一样进行版本管理。建议每个提示词文件都写上版本号和变更说明。

# 客户反馈信息提取提示词 - 版本：v1.3 - 更新人：张三 - 更新时间：2025-01-20 - 变更说明： - 增加联系方式脱敏要求； - 将 problem_type 枚举值从 5 个调整为 4 个； - 明确缺失字段使用 null 填充。

这样做的价值在于：当线上效果回退时，可以快速定位是哪一次修改导致的。

8.2 区分“提示词错误”和“模型能力边界”

不是所有问题都能靠提示词解决。如果模型不具备某个能力，比如无法理解某些专业术语，或者无法从极少量信息中准确推断意图，调整提示词的收益可能很低。此时应该考虑更换模型、补充训练数据或引入外部工具。

判断标准很简单：

• 如果模型在人工编写的理想示例上表现良好，说明是提示词问题；
• 如果模型在理想示例上仍然无法完成，说明是模型能力边界问题。

8.3 安全与合规边界

在提示词优化过程中，必须注意安全与合规要求：

• 不要通过提示词诱导模型输出违法、违规内容；
• 涉及个人信息提取时，要遵守数据最小化原则，并进行脱敏处理；
• 提示词本身不要包含敏感的内部系统信息；
• API Key 必须保存在服务端环境变量中，禁止提交到代码仓库。

8.4 建立监控与告警

线上 AIGC 应用上线后，建议对以下内容进行监控：

• API 调用失败率；
• 平均响应时间；
• 输出格式解析失败率；
• token 消耗趋势；
• 用户反馈中与内容质量相关的投诉量。

这些指标可以在问题扩大之前提前发现异常。

9. 总结与下一步学习方向

回到开头的问题：NPO 单线提示优化为什么能以更少预算追平 GEPA？

关键在于：NPO 首先保证了单条提示词的质量，用结构化的方式降低模型的输出不确定性，再通过回归测试集和预算指标追踪，确保每次优化都花在值得投入的地方。而预算充足时，GEPA 可以作为后续进阶手段，用来做全局参数组合验证。

读完本文，你应该已经掌握了以下内容：

• NPO 和 GEPA 的含义、区别与适用场景；
• 单线提示词的六段式结构设计方法；
• 正向约束与反向约束的使用技巧；
• 使用 Python 封装模型调用和评测脚本的具体方法；
• 通过测试集和预算指标验证优化效果的方式；
• 提示词优化过程中的常见问题与排查方案。

下一步，你可以从这几个方向继续深入：

• 尝试用不同类型的大模型接口测试同一个提示词，观察输出差异；
• 设计一套适合自己业务的回归测试集，把提示词优化流程固化下来；
• 学习 Function Calling / Tool Use 相关知识，在需要调用外部工具的场景中进一步提升稳定性；
• 如果团队预算允许，可以结合 GEPA 思路，在 NPO 基础上尝试参数枚举实验，寻找更优的模型配置组合。

如果你正在负责一个 AIGC 内容生成项目，建议从今天开始整理自己的提示词模板和测试集。只要愿意花少量时间把基础结构搭好，后续的每一次优化都会变得更快、更省、更可控。如果本文对你有帮助，可以收藏备用，后续迭代新版本时再来对照检查。