最近在做一个内部 AI 工具链的迭代项目时碰到一个很有意思的命题我们整天在教 AI 怎么做事情写提示词、微调模型、搭建 Agent 流程但很少停下来想一想——能不能让 AI 来帮我们完成这些“让 AI 更聪明”的工作换句话说Making AI Smarter with AI用 AI 来增强 AI 的智商。这篇文章不是讲某个单一框架的教程而是探讨一条正在快速落地的工程路线如何用大模型优化提示词、生成训练数据、自动化评估、甚至构建一个能自我迭代的 Agent 工作流。我会从概念讲起拆解技术路线再给出可以直接改改就用的 Python 示例代码。适合对大模型应用开发有兴趣、已经跑通过基本 API 调用的开发者阅读。1. 背景与核心概念1.1 什么是“用 AI 让 AI 更聪明”传统的大模型开发流程通常是这样的开发者写提示词 - 调用模型 - 看结果 - 觉得不满意 - 手动改提示词 - 再调用。这个过程完全靠人的直觉和经验费时费力而且不同模型、不同任务之间的迁移能力很差。“用 AI 让 AI 更聪明”这个方向本质上就是把上面这个循环中的“人”逐步替换成“AI”用大模型来分析和优化提示词用大模型自动生成训练或评测数据用大模型扮演裁判评估另一个模型的输出质量用大模型感知任务结果自动调整下一步行动。听起来有点递归的味道但在工程上完全可行。大模型的优势在于语言理解和生成而“优化提示词”“打标数据”“评估结果”这些工作恰好都是语言密集型任务。让 AI 来处理这些任务反而比传统的规则脚本更灵活。1.2 为什么现在这个方向值得关注过去一年AI 应用开发的关注点正在从“怎么调用模型”转向“怎么把模型用得更聪明、更稳定、更可控”。在真实项目中模型 API 的底层能力已经相对固定开发者之间的差距渐渐体现到了三个地方提示词质量同样的模型好的提示词和差的提示词效果差距可能非常大数据质量微调或评测时训练数据的好坏直接决定模型表现反馈闭环能不能自动评估模型输出并且根据评估结果持续优化流程。这三个环节恰好都是 AI 可以介入的。所以“Making AI Smarter with AI”不是实验室里的炫技而是 AI 工程实践里非常实际的方向。1.3 适用范围与典型场景举几个真实场景你应该能感受到这个方向的价值场景传统做法用 AI 增强后的做法提示词调优靠人反复试错让 AI 分析失败样例自动改写提示词微调数据准备人工写标注规则逐条标注用大模型生成初稿人工抽检修正模型评测人工看几百条结果打分用大模型作为裁判批量打分并输出理由Agent 决策写死 if-else 逻辑让模型根据任务反馈决定下一步动作从个人开发者的辅助工具到企业内部的自动化评测平台这个思路都可以落地。接下来我会以自己的项目为例完整拆解一个“AI 增强 AI”的最小工程闭环。2. 技术路线总览在动手写代码之前先梳理清楚技术路线。我把它拆成四个层次由浅入深。2.1 第一层提示词工程增强这是最直接、最轻量的一层。核心思路是写一个“元提示词”meta-prompt让大模型帮你分析现有提示词的问题并给出优化版本。典型实现原始提示词对用户问题给出简洁回答。 任务分析这个提示词在“明确性、约束条件、输出格式”三个维度上的不足并给出优化后的版本。这一层适合那些经常需要写提示词、但不想每次手动调优的开发者。2.2 第二层数据增强与合成数据当模型需要微调或做 few-shot 时训练数据的数量和质量是瓶颈。大模型可以用于根据少量人工种子样本生成更多相似样本对已有样本做改写、扩写、纠错生成“难例”来提升模型的鲁棒性。这一层适合做垂直领域模型微调、RAG 知识库构建、评测集扩充的团队。2.3 第三层自动化评估LLM-as-a-Judge评测是 AI 工程里最容易被忽视的环节。人工评测几十条还可以几百条几千条就完全不现实了。用大模型当裁判LLM-as-a-Judge可以按多个维度打分相关性、完整性、安全性输出结构化的评估理由对比两个模型的输出质量A/B 评估。这一层适合做模型选型、版本回归、Prompt 效果对比的团队。2.4 第四层Agent 自我迭代Agent 是“AI 让 AI 更聪明”的进阶形态。它不只是优化单个环节而是把“计划 - 执行 - 反馈 - 修正”闭环串起来。模型在执行任务后根据结果自动调整下一步提示词或动作。这一层适合做自动化研究、代码生成、复杂任务拆解的开发者。四个层次不是互斥的实际项目可以组合使用。下面我会给出每一层的代码示例并在最后组合成一个完整的流程。3. 环境准备与项目结构3.1 环境与依赖本文示例使用 Python 3.9通过 OpenAI 兼容接口调用大模型。如果你的环境使用国内大模型服务或者公司内部部署的模型网关只要接口是 OpenAI 兼容格式代码思路都是一样的。需要安装的依赖pip install openai python-dotenv注意openai库请根据你的实际环境选择合适的版本。新版 SDK 的调用方式是OpenAI()老版本的openai.ChatCompletion.create()在新版本中已经不再建议使用。本文示例以新版 SDK 写法为主。环境变量配置# .env OPENAI_API_KEY你的API密钥 OPENAI_BASE_URLhttps://你的模型服务地址 MODEL_NAMEgpt-4o-mini如果你使用的是本地模型服务OPENAI_BASE_URL指向本地服务地址即可。3.2 项目结构ai-smart-ai/ ├── .env ├── config.py ├── prompt_optimizer.py ├── data_generator.py ├── auto_evaluator.py ├── agent_loop.py └── main.py这个结构是一个最小可运行工程后面每一节都会对应一个文件。3.3 公共配置模块先写一个统一的配置模块方便其他文件复用。# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini)在编写后续代码之前需要先确认你的 API 密钥和模型服务地址可以正常访问。建议先用一个最简单的调用测试一下。4. 实战用 AI 优化提示词4.1 场景描述假设你现在有这样一个提示词你是一个助手。请回答用户的问题。这个提示词太笼统了不同模型的输出质量会很不稳定。传统做法是开发者手动补充角色、约束、输出格式、示例等信息。现在我们让 AI 来做这件事。4.2 核心实现创建一个提示词优化器输入原始提示词和任务描述输出优化后的提示词。# 文件路径prompt_optimizer.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) META_PROMPT 你是一位经验丰富的提示词工程专家。你的任务是分析用户提供的原始提示词并给出优化版本。 分析维度 1. 角色设定是否清晰定义了 AI 承担的角色 2. 任务描述是否明确了 AI 要完成的具体任务 3. 约束条件是否有明确的正面/负面约束 4. 输出格式是否规定了输出的结构和格式 5. 示例引导是否提供了 few-shot 示例 请先输出分析再输出优化后的提示词格式如下 【分析】 逐条列出每个维度的不足 【优化后提示词】 给出完整可用的新版提示词 def optimize_prompt(original_prompt: str, task_description: str ) - str: user_content f原始提示词\n{original_prompt}\n if task_description: user_content f\n任务描述\n{task_description}\n resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: META_PROMPT}, {role: user, content: user_content} ], temperature0.3 ) return resp.choices[0].message.content4.3 运行与验证# 运行示例python prompt_optimizer.py if __name__ __main__: original 你是一个助手。请回答用户的问题。 improved optimize_prompt( original, task_description这是一个电商客服助手需要回答用户关于订单、退换货、物流的问题。 ) print(improved)预期输出会包含两部分一部分是对原提示词不足之处的分析另一部分是优化后的提示词。以下是可能的输出形态【分析】 1. 角色设定未明确 AI 是电商客服助手导致回答风格不统一。 2. 任务描述未限定问题范围模型可能回答与电商无关的内容。 3. 约束条件未说明禁止提供虚假物流信息。 4. 输出格式未规定回答结构。 【优化后提示词】 你是一位专业的电商客服助手...这里要注意不同的模型服务对输出格式的遵循程度不同。如果你希望优化结果更加稳定可以在 META_PROMPT 中加入“必须严格按 JSON 格式输出”的约束并在代码中解析 JSON。4.4 如何把优化结果接入现有流程优化后的提示词可以直接写入一个配置文件例如prompts.py然后在业务代码中引用。核心思路是提示词不再是一段写死的字符串而是由 AI 持续优化、由人工审核后固化的资产。5. 实战用 AI 生成合成数据5.1 场景描述假设你在做一个法律问答机器人手头只有 20 条人工标注的高质量问答对但微调模型时想要 200 条。这时候可以写一个合成数据生成器基于种子样本生成更多样化的数据。5.2 核心实现# 文件路径data_generator.py import json from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) GENERATION_PROMPT 你是一个数据增强专家。根据给定的种子问答对生成新的问答对。要求 1. 问题必须与种子问题属于同一主题但表述不能完全重复 2. 答案必须正确、完整信息不能与种子答案冲突 3. 输出必须是 JSON 数组格式每个元素包含 question 和 answer 两个字段。 种子样本 {seed_examples} 请生成 {num_samples} 条新样本。 def generate_synthetic_samples(seed_examples: list, num_samples: int 10) - list: seed_text json.dumps(seed_examples, ensure_asciiFalse, indent2) prompt GENERATION_PROMPT.format( seed_examplesseed_text, num_samplesnum_samples ) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你只输出合法 JSON不要输出多余文字。}, {role: user, content: prompt} ], temperature0.7 ) content resp.choices[0].message.content # 有些模型会输出 json 包裹这里做一次清洗 content content.strip().removeprefix(json).removesuffix().strip() return json.loads(content)5.3 运行与验证# 运行示例python data_generator.py if __name__ __main__: seeds [ {question: 合同纠纷的诉讼时效是多久, answer: 根据民法典规定普通诉讼时效为三年。}, {question: 劳动仲裁需要准备哪些材料, answer: 需要准备身份证、劳动合同、工资流水等材料。} ] samples generate_synthetic_samples(seeds, num_samples5) for item in samples: print(item)5.4 人工抽检与风险控制合成数据最大的风险是“看起来对实际上错”。因此不能把大模型生成的合成数据直接用于微调需要加入人工抽检环节。我建议的流程是先用大模型批量生成候选数据按比例抽检例如抽 20%抽检通过后再全量进入微调流程对高风险领域医疗、法律、金融人工审核比例要提高到 50% 以上。另外合成数据通常会放大模型的潜在偏见。生成时可以在提示词中加上“禁止包含歧视性内容”等约束但这不是绝对保障人工审核仍然不可或缺。6. 实战用 AI 自动化评估模型输出6.1 场景描述当你有两个候选提示词版本或者两个不同的模型版本时需要评估哪个输出更好。人工看几十条还行看几百条会崩溃。用 LLM-as-a-Judge 可以批量完成这个任务。6.2 实现一个评估器# 文件路径auto_evaluator.py import json from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) EVALUATION_PROMPT 你是一个严格的 AI 输出质量评估专家。请根据以下维度对模型回答进行评分每个维度 1-5 分 - relevance是否与问题相关 - completeness是否完整回答了问题 - clarity是否清晰易懂 输出 JSON 格式评分结果包含字段relevance, completeness, clarity, overall_score, reason。 问题{question} 回答{answer} def evaluate_response(question: str, answer: str) - dict: prompt EVALUATION_PROMPT.format(questionquestion, answeranswer) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你只输出合法 JSON不要输出多余文字。}, {role: user, content: prompt} ], temperature0.2 ) content resp.choices[0].message.content content content.strip().removeprefix(json).removesuffix().strip() return json.loads(content)6.3 批量对比两个模型下面这段代码演示了如何批量对比两个模型输出并计算平均分。# 文件路径auto_evaluator.py追加 def batch_evaluate(questions: list, model_a_func, model_b_func, sample_size: int 10): 对同一批问题分别用两个模型输出并用 AI 评分对比。 model_a_func / model_b_func 是接受 question 返回 answer 的函数。 results [] for q in questions[:sample_size]: answer_a model_a_func(q) answer_b model_b_func(q) score_a evaluate_response(q, answer_a) score_b evaluate_response(q, answer_b) results.append({ question: q, answer_a: answer_a, answer_b: answer_b, score_a: score_a, score_b: score_b }) return results6.4 评估器的设计要点LLM-as-a-Judge 看起来很简单但有几个细节需要注意评估维度要具体不要只让模型打一个总分要拆成多个维度每个维度有明确的评分标准这样结果更稳定。模型偏见大模型评估时会有“位置偏见”即更倾向于排在后面的答案。所以 A/B 对比时可以把顺序反过来再测一遍。评估模型与被评估模型的差异如果评估模型和被评估模型是同一个模型可能出现“自吹自擂”的情况。条件允许时评估模型应该比被评估模型能力更强或者使用不同的模型。7. 实战构建 Agent 自我迭代闭环7.1 场景描述最后这个示例更进阶构建一个可以“自我修正”的 Agent。它执行任务后会检查结果质量如果不达标会自动调整提示词重新执行。以自动生成商品文案为例Agent 先生成文案用评估器检查文案质量分如果分数低于阈值让优化器分析原因并改写提示词重新生成最多循环 N 次。7.2 核心实现# 文件路径agent_loop.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) BASE_WRITE_PROMPT 你是一个电商文案专家。请为以下商品写一段文案。 商品名称{product_name} 商品卖点{features} 文案风格{style} REFINE_PROMPT 之前的文案存在以下问题 {feedback} 请参考以下建议重新生成文案 {advice} def check_quality(product_name: str, features: str, style: str, draft: str) - tuple: 返回 (是否通过, 评分结果) 这里简化处理让模型判断是否达标。 check_prompt f 你是文案质量审核员。请评价以下电商文案是否达到合格标准。 要求文案需要包含至少 3 个商品卖点语言通顺有购买吸引力。 商品{product_name} 卖点{features} 文案{draft} 请先输出通过或不通过再输出改进建议。格式 结果通过/不通过 建议xxx resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: check_prompt}], temperature0.2 ) result resp.choices[0].message.content passed 通过 in result and 不通过 not in result advice result.replace(结果, ).replace(建议, ) return passed, advice def write_and_refine(product_name: str, features: str, style: str, max_rounds: int 3) - str: prompt BASE_WRITE_PROMPT.format( product_nameproduct_name, featuresfeatures, stylestyle ) draft for i in range(max_rounds): resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.7 ) draft resp.choices[0].message.content passed, advice check_quality(product_name, features, style, draft) print(f第 {i1} 轮生成审核结果{通过 if passed else 不通过}) if passed: return draft # 未通过时让模型基于建议重新生成 prompt REFINE_PROMPT.format(feedbackadvice, adviceadvice) return draft if __name__ __main__: final_copy write_and_refine( product_name智能保温杯, features316不锈钢内胆、24小时保温、智能温度显示、防漏杯盖, style年轻时尚 ) print(最终文案) print(final_copy)7.3 这个闭环的价值这个示例的价值不在于它是一个完美的生产级 Agent而在于它展示了一个核心思想AI 应用不应该是一次性调用的“死流程”而是可以感知结果、自我修正的“活系统”。在这个闭环里AI 担任了三重角色写作者生成内容评估者判断质量优化者提供建议三者互相配合形成一个自动反馈循环。如果把这个思路扩展到代码生成、数据分析、报告撰写等任务就是一个通用的 Agent 框架雏形。8. 常见问题与排查思路8.1 常见报错对照表问题现象常见原因解决思路调用 API 超时网络不稳定或模型服务负载过高增加超时时间设置重试机制检查模型服务状态输出不是合法 JSON模型没有严格遵循格式指令在 prompt 中强制指定输出格式增加输出清洗逻辑提示词优化结果不稳定temperature 设置过高调低 temperature 到 0.2-0.3固定随机种子评估结果与人工判断差距大评估维度定义不够具体细化评估维度增加评分标准描述增加 few-shot 示例Agent 循环陷入死循环没有设置最大循环次数增加 max_rounds 限制设置分数阈值提前退出合成数据质量差种子样本太单一扩充种子样本的多样性增加生成轮次后人工筛选8.2 高频排查清单如果遇到问题建议按以下顺序排查先确认 API 连通性用最简单的 prompt 测试模型服务是否正常再确认输出格式打印模型原始输出检查是否有额外字符导致 JSON 解析失败检查环境变量确认.env中的 API Key 和 Base URL 是否生效调整模型参数temperature 过高会导致输出不稳定建议评估类任务设为 0.2 以下增加日志在关键环节打印输入输出定位是哪一步出了问题。8.3 关于成本控制每轮 Agent 迭代都会产生多次模型调用成本会成倍增加。建议做到两点设置调用次数上限使用评估器和生成器分离的模型等级评估任务使用更便宜的模型。如果对成本敏感可以先在小样本集上验证效果再扩大规模。9. 最佳实践与工程建议9.1 明确“人机协作”边界“用 AI 让 AI 更聪明”不等于完全脱离人工。在工程实践中最合理的方式是AI 负责规模化生成、初筛、批量评估人负责制定标准、审核关键样本、处理边界情况。特别是在内容安全、法律、医疗等高风险场景必须保留人工审核环节。自动化流程可以显著提高效率但不能完全替代责任判断。9.2 日志与可观测性AI 应用的调试比传统应用更困难因为同样的输入可能产生不同的输出。因此日志记录非常重要。建议在代码中记录以下信息每次调用的 prompt 全文模型返回的原始输出评估分数和判定理由运行耗时和 token 消耗。这样当线上效果出现波动时才能回溯到具体的失败样本。9.3 提示词与代码的版本管理提示词是会持续演化的资产建议像管理代码一样管理提示词将提示词存放在独立文件中不要散落在业务代码里使用 Git 管理提示词的每次变更每次修改后用自动化评估器做回归测试重要变更需要人工审核后再上线。9.4 保护 API 密钥与最小权限项目中一定不要把 API Key 硬编码在代码里。使用环境变量或专用的密钥管理服务。同时遵循最小权限原则每个应用只申请它需要的最小权限避免一个密钥到处复用。如果密钥不慎泄露立即在服务商后台吊销并重新生成。9.5 设计上预留“人工降级”开关任何 AI 自动化流程都应该设计人工降级方案。比如 Agent 连续多次达不到质量阈值时可以把任务转交人工线上业务流程应该支持随时切换回旧的稳定版本。这样即使 AI 出 bug也不会影响核心业务。10. 总结与下一步学习路线这篇文章围绕“Making AI Smarter with AI”这个主题从四个层次展开提示词优化让 AI 分析并优化提示词合成数据生成让 AI 生成训练和评测数据自动化评估用 LLM-as-a-Judge 批量评估输出质量Agent 自我迭代构建感知结果、自动修正的执行闭环。这四个层次可以独立使用也可以组合成完整的 AI 工程流水线。代码我已经尽量简化你可以直接复制到自己的项目中修改使用。如果你在自己环境下运行遇到问题优先检查模型服务地址、API Key 和依赖版本大部分报错都出在环境差异上。更进一步可以往这几个方向深入学习RAG 与向量检索让 AI 能读取外部知识库再回答问题是当前企业应用的主流方向微调与对齐如果基础模型效果不够可以考虑在垂直领域做微调多 Agent 协作把“写作者 评估者 优化者”扩展成多个 Agent 协作的复杂系统模型评估体系学习更严谨的评测集设计、评估指标和人工评估方法。如果这篇内容对你有帮助可以收藏备用。也建议你手头准备一个项目把思路落地成代码一定会有不少收获。运行中遇到任何卡点欢迎在评论区交流讨论。 用AI让AI更聪明：提示词优化、合成数据与自动化评估实践
最近在做一个内部 AI 工具链的迭代项目时碰到一个很有意思的命题我们整天在教 AI 怎么做事情写提示词、微调模型、搭建 Agent 流程但很少停下来想一想——能不能让 AI 来帮我们完成这些“让 AI 更聪明”的工作换句话说Making AI Smarter with AI用 AI 来增强 AI 的智商。这篇文章不是讲某个单一框架的教程而是探讨一条正在快速落地的工程路线如何用大模型优化提示词、生成训练数据、自动化评估、甚至构建一个能自我迭代的 Agent 工作流。我会从概念讲起拆解技术路线再给出可以直接改改就用的 Python 示例代码。适合对大模型应用开发有兴趣、已经跑通过基本 API 调用的开发者阅读。1. 背景与核心概念1.1 什么是“用 AI 让 AI 更聪明”传统的大模型开发流程通常是这样的开发者写提示词 - 调用模型 - 看结果 - 觉得不满意 - 手动改提示词 - 再调用。这个过程完全靠人的直觉和经验费时费力而且不同模型、不同任务之间的迁移能力很差。“用 AI 让 AI 更聪明”这个方向本质上就是把上面这个循环中的“人”逐步替换成“AI”用大模型来分析和优化提示词用大模型自动生成训练或评测数据用大模型扮演裁判评估另一个模型的输出质量用大模型感知任务结果自动调整下一步行动。听起来有点递归的味道但在工程上完全可行。大模型的优势在于语言理解和生成而“优化提示词”“打标数据”“评估结果”这些工作恰好都是语言密集型任务。让 AI 来处理这些任务反而比传统的规则脚本更灵活。1.2 为什么现在这个方向值得关注过去一年AI 应用开发的关注点正在从“怎么调用模型”转向“怎么把模型用得更聪明、更稳定、更可控”。在真实项目中模型 API 的底层能力已经相对固定开发者之间的差距渐渐体现到了三个地方提示词质量同样的模型好的提示词和差的提示词效果差距可能非常大数据质量微调或评测时训练数据的好坏直接决定模型表现反馈闭环能不能自动评估模型输出并且根据评估结果持续优化流程。这三个环节恰好都是 AI 可以介入的。所以“Making AI Smarter with AI”不是实验室里的炫技而是 AI 工程实践里非常实际的方向。1.3 适用范围与典型场景举几个真实场景你应该能感受到这个方向的价值场景传统做法用 AI 增强后的做法提示词调优靠人反复试错让 AI 分析失败样例自动改写提示词微调数据准备人工写标注规则逐条标注用大模型生成初稿人工抽检修正模型评测人工看几百条结果打分用大模型作为裁判批量打分并输出理由Agent 决策写死 if-else 逻辑让模型根据任务反馈决定下一步动作从个人开发者的辅助工具到企业内部的自动化评测平台这个思路都可以落地。接下来我会以自己的项目为例完整拆解一个“AI 增强 AI”的最小工程闭环。2. 技术路线总览在动手写代码之前先梳理清楚技术路线。我把它拆成四个层次由浅入深。2.1 第一层提示词工程增强这是最直接、最轻量的一层。核心思路是写一个“元提示词”meta-prompt让大模型帮你分析现有提示词的问题并给出优化版本。典型实现原始提示词对用户问题给出简洁回答。 任务分析这个提示词在“明确性、约束条件、输出格式”三个维度上的不足并给出优化后的版本。这一层适合那些经常需要写提示词、但不想每次手动调优的开发者。2.2 第二层数据增强与合成数据当模型需要微调或做 few-shot 时训练数据的数量和质量是瓶颈。大模型可以用于根据少量人工种子样本生成更多相似样本对已有样本做改写、扩写、纠错生成“难例”来提升模型的鲁棒性。这一层适合做垂直领域模型微调、RAG 知识库构建、评测集扩充的团队。2.3 第三层自动化评估LLM-as-a-Judge评测是 AI 工程里最容易被忽视的环节。人工评测几十条还可以几百条几千条就完全不现实了。用大模型当裁判LLM-as-a-Judge可以按多个维度打分相关性、完整性、安全性输出结构化的评估理由对比两个模型的输出质量A/B 评估。这一层适合做模型选型、版本回归、Prompt 效果对比的团队。2.4 第四层Agent 自我迭代Agent 是“AI 让 AI 更聪明”的进阶形态。它不只是优化单个环节而是把“计划 - 执行 - 反馈 - 修正”闭环串起来。模型在执行任务后根据结果自动调整下一步提示词或动作。这一层适合做自动化研究、代码生成、复杂任务拆解的开发者。四个层次不是互斥的实际项目可以组合使用。下面我会给出每一层的代码示例并在最后组合成一个完整的流程。3. 环境准备与项目结构3.1 环境与依赖本文示例使用 Python 3.9通过 OpenAI 兼容接口调用大模型。如果你的环境使用国内大模型服务或者公司内部部署的模型网关只要接口是 OpenAI 兼容格式代码思路都是一样的。需要安装的依赖pip install openai python-dotenv注意openai库请根据你的实际环境选择合适的版本。新版 SDK 的调用方式是OpenAI()老版本的openai.ChatCompletion.create()在新版本中已经不再建议使用。本文示例以新版 SDK 写法为主。环境变量配置# .env OPENAI_API_KEY你的API密钥 OPENAI_BASE_URLhttps://你的模型服务地址 MODEL_NAMEgpt-4o-mini如果你使用的是本地模型服务OPENAI_BASE_URL指向本地服务地址即可。3.2 项目结构ai-smart-ai/ ├── .env ├── config.py ├── prompt_optimizer.py ├── data_generator.py ├── auto_evaluator.py ├── agent_loop.py └── main.py这个结构是一个最小可运行工程后面每一节都会对应一个文件。3.3 公共配置模块先写一个统一的配置模块方便其他文件复用。# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini)在编写后续代码之前需要先确认你的 API 密钥和模型服务地址可以正常访问。建议先用一个最简单的调用测试一下。4. 实战用 AI 优化提示词4.1 场景描述假设你现在有这样一个提示词你是一个助手。请回答用户的问题。这个提示词太笼统了不同模型的输出质量会很不稳定。传统做法是开发者手动补充角色、约束、输出格式、示例等信息。现在我们让 AI 来做这件事。4.2 核心实现创建一个提示词优化器输入原始提示词和任务描述输出优化后的提示词。# 文件路径prompt_optimizer.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) META_PROMPT 你是一位经验丰富的提示词工程专家。你的任务是分析用户提供的原始提示词并给出优化版本。 分析维度 1. 角色设定是否清晰定义了 AI 承担的角色 2. 任务描述是否明确了 AI 要完成的具体任务 3. 约束条件是否有明确的正面/负面约束 4. 输出格式是否规定了输出的结构和格式 5. 示例引导是否提供了 few-shot 示例 请先输出分析再输出优化后的提示词格式如下 【分析】 逐条列出每个维度的不足 【优化后提示词】 给出完整可用的新版提示词 def optimize_prompt(original_prompt: str, task_description: str ) - str: user_content f原始提示词\n{original_prompt}\n if task_description: user_content f\n任务描述\n{task_description}\n resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: META_PROMPT}, {role: user, content: user_content} ], temperature0.3 ) return resp.choices[0].message.content4.3 运行与验证# 运行示例python prompt_optimizer.py if __name__ __main__: original 你是一个助手。请回答用户的问题。 improved optimize_prompt( original, task_description这是一个电商客服助手需要回答用户关于订单、退换货、物流的问题。 ) print(improved)预期输出会包含两部分一部分是对原提示词不足之处的分析另一部分是优化后的提示词。以下是可能的输出形态【分析】 1. 角色设定未明确 AI 是电商客服助手导致回答风格不统一。 2. 任务描述未限定问题范围模型可能回答与电商无关的内容。 3. 约束条件未说明禁止提供虚假物流信息。 4. 输出格式未规定回答结构。 【优化后提示词】 你是一位专业的电商客服助手...这里要注意不同的模型服务对输出格式的遵循程度不同。如果你希望优化结果更加稳定可以在 META_PROMPT 中加入“必须严格按 JSON 格式输出”的约束并在代码中解析 JSON。4.4 如何把优化结果接入现有流程优化后的提示词可以直接写入一个配置文件例如prompts.py然后在业务代码中引用。核心思路是提示词不再是一段写死的字符串而是由 AI 持续优化、由人工审核后固化的资产。5. 实战用 AI 生成合成数据5.1 场景描述假设你在做一个法律问答机器人手头只有 20 条人工标注的高质量问答对但微调模型时想要 200 条。这时候可以写一个合成数据生成器基于种子样本生成更多样化的数据。5.2 核心实现# 文件路径data_generator.py import json from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) GENERATION_PROMPT 你是一个数据增强专家。根据给定的种子问答对生成新的问答对。要求 1. 问题必须与种子问题属于同一主题但表述不能完全重复 2. 答案必须正确、完整信息不能与种子答案冲突 3. 输出必须是 JSON 数组格式每个元素包含 question 和 answer 两个字段。 种子样本 {seed_examples} 请生成 {num_samples} 条新样本。 def generate_synthetic_samples(seed_examples: list, num_samples: int 10) - list: seed_text json.dumps(seed_examples, ensure_asciiFalse, indent2) prompt GENERATION_PROMPT.format( seed_examplesseed_text, num_samplesnum_samples ) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你只输出合法 JSON不要输出多余文字。}, {role: user, content: prompt} ], temperature0.7 ) content resp.choices[0].message.content # 有些模型会输出 json 包裹这里做一次清洗 content content.strip().removeprefix(json).removesuffix().strip() return json.loads(content)5.3 运行与验证# 运行示例python data_generator.py if __name__ __main__: seeds [ {question: 合同纠纷的诉讼时效是多久, answer: 根据民法典规定普通诉讼时效为三年。}, {question: 劳动仲裁需要准备哪些材料, answer: 需要准备身份证、劳动合同、工资流水等材料。} ] samples generate_synthetic_samples(seeds, num_samples5) for item in samples: print(item)5.4 人工抽检与风险控制合成数据最大的风险是“看起来对实际上错”。因此不能把大模型生成的合成数据直接用于微调需要加入人工抽检环节。我建议的流程是先用大模型批量生成候选数据按比例抽检例如抽 20%抽检通过后再全量进入微调流程对高风险领域医疗、法律、金融人工审核比例要提高到 50% 以上。另外合成数据通常会放大模型的潜在偏见。生成时可以在提示词中加上“禁止包含歧视性内容”等约束但这不是绝对保障人工审核仍然不可或缺。6. 实战用 AI 自动化评估模型输出6.1 场景描述当你有两个候选提示词版本或者两个不同的模型版本时需要评估哪个输出更好。人工看几十条还行看几百条会崩溃。用 LLM-as-a-Judge 可以批量完成这个任务。6.2 实现一个评估器# 文件路径auto_evaluator.py import json from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) EVALUATION_PROMPT 你是一个严格的 AI 输出质量评估专家。请根据以下维度对模型回答进行评分每个维度 1-5 分 - relevance是否与问题相关 - completeness是否完整回答了问题 - clarity是否清晰易懂 输出 JSON 格式评分结果包含字段relevance, completeness, clarity, overall_score, reason。 问题{question} 回答{answer} def evaluate_response(question: str, answer: str) - dict: prompt EVALUATION_PROMPT.format(questionquestion, answeranswer) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你只输出合法 JSON不要输出多余文字。}, {role: user, content: prompt} ], temperature0.2 ) content resp.choices[0].message.content content content.strip().removeprefix(json).removesuffix().strip() return json.loads(content)6.3 批量对比两个模型下面这段代码演示了如何批量对比两个模型输出并计算平均分。# 文件路径auto_evaluator.py追加 def batch_evaluate(questions: list, model_a_func, model_b_func, sample_size: int 10): 对同一批问题分别用两个模型输出并用 AI 评分对比。 model_a_func / model_b_func 是接受 question 返回 answer 的函数。 results [] for q in questions[:sample_size]: answer_a model_a_func(q) answer_b model_b_func(q) score_a evaluate_response(q, answer_a) score_b evaluate_response(q, answer_b) results.append({ question: q, answer_a: answer_a, answer_b: answer_b, score_a: score_a, score_b: score_b }) return results6.4 评估器的设计要点LLM-as-a-Judge 看起来很简单但有几个细节需要注意评估维度要具体不要只让模型打一个总分要拆成多个维度每个维度有明确的评分标准这样结果更稳定。模型偏见大模型评估时会有“位置偏见”即更倾向于排在后面的答案。所以 A/B 对比时可以把顺序反过来再测一遍。评估模型与被评估模型的差异如果评估模型和被评估模型是同一个模型可能出现“自吹自擂”的情况。条件允许时评估模型应该比被评估模型能力更强或者使用不同的模型。7. 实战构建 Agent 自我迭代闭环7.1 场景描述最后这个示例更进阶构建一个可以“自我修正”的 Agent。它执行任务后会检查结果质量如果不达标会自动调整提示词重新执行。以自动生成商品文案为例Agent 先生成文案用评估器检查文案质量分如果分数低于阈值让优化器分析原因并改写提示词重新生成最多循环 N 次。7.2 核心实现# 文件路径agent_loop.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) BASE_WRITE_PROMPT 你是一个电商文案专家。请为以下商品写一段文案。 商品名称{product_name} 商品卖点{features} 文案风格{style} REFINE_PROMPT 之前的文案存在以下问题 {feedback} 请参考以下建议重新生成文案 {advice} def check_quality(product_name: str, features: str, style: str, draft: str) - tuple: 返回 (是否通过, 评分结果) 这里简化处理让模型判断是否达标。 check_prompt f 你是文案质量审核员。请评价以下电商文案是否达到合格标准。 要求文案需要包含至少 3 个商品卖点语言通顺有购买吸引力。 商品{product_name} 卖点{features} 文案{draft} 请先输出通过或不通过再输出改进建议。格式 结果通过/不通过 建议xxx resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: check_prompt}], temperature0.2 ) result resp.choices[0].message.content passed 通过 in result and 不通过 not in result advice result.replace(结果, ).replace(建议, ) return passed, advice def write_and_refine(product_name: str, features: str, style: str, max_rounds: int 3) - str: prompt BASE_WRITE_PROMPT.format( product_nameproduct_name, featuresfeatures, stylestyle ) draft for i in range(max_rounds): resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.7 ) draft resp.choices[0].message.content passed, advice check_quality(product_name, features, style, draft) print(f第 {i1} 轮生成审核结果{通过 if passed else 不通过}) if passed: return draft # 未通过时让模型基于建议重新生成 prompt REFINE_PROMPT.format(feedbackadvice, adviceadvice) return draft if __name__ __main__: final_copy write_and_refine( product_name智能保温杯, features316不锈钢内胆、24小时保温、智能温度显示、防漏杯盖, style年轻时尚 ) print(最终文案) print(final_copy)7.3 这个闭环的价值这个示例的价值不在于它是一个完美的生产级 Agent而在于它展示了一个核心思想AI 应用不应该是一次性调用的“死流程”而是可以感知结果、自我修正的“活系统”。在这个闭环里AI 担任了三重角色写作者生成内容评估者判断质量优化者提供建议三者互相配合形成一个自动反馈循环。如果把这个思路扩展到代码生成、数据分析、报告撰写等任务就是一个通用的 Agent 框架雏形。8. 常见问题与排查思路8.1 常见报错对照表问题现象常见原因解决思路调用 API 超时网络不稳定或模型服务负载过高增加超时时间设置重试机制检查模型服务状态输出不是合法 JSON模型没有严格遵循格式指令在 prompt 中强制指定输出格式增加输出清洗逻辑提示词优化结果不稳定temperature 设置过高调低 temperature 到 0.2-0.3固定随机种子评估结果与人工判断差距大评估维度定义不够具体细化评估维度增加评分标准描述增加 few-shot 示例Agent 循环陷入死循环没有设置最大循环次数增加 max_rounds 限制设置分数阈值提前退出合成数据质量差种子样本太单一扩充种子样本的多样性增加生成轮次后人工筛选8.2 高频排查清单如果遇到问题建议按以下顺序排查先确认 API 连通性用最简单的 prompt 测试模型服务是否正常再确认输出格式打印模型原始输出检查是否有额外字符导致 JSON 解析失败检查环境变量确认.env中的 API Key 和 Base URL 是否生效调整模型参数temperature 过高会导致输出不稳定建议评估类任务设为 0.2 以下增加日志在关键环节打印输入输出定位是哪一步出了问题。8.3 关于成本控制每轮 Agent 迭代都会产生多次模型调用成本会成倍增加。建议做到两点设置调用次数上限使用评估器和生成器分离的模型等级评估任务使用更便宜的模型。如果对成本敏感可以先在小样本集上验证效果再扩大规模。9. 最佳实践与工程建议9.1 明确“人机协作”边界“用 AI 让 AI 更聪明”不等于完全脱离人工。在工程实践中最合理的方式是AI 负责规模化生成、初筛、批量评估人负责制定标准、审核关键样本、处理边界情况。特别是在内容安全、法律、医疗等高风险场景必须保留人工审核环节。自动化流程可以显著提高效率但不能完全替代责任判断。9.2 日志与可观测性AI 应用的调试比传统应用更困难因为同样的输入可能产生不同的输出。因此日志记录非常重要。建议在代码中记录以下信息每次调用的 prompt 全文模型返回的原始输出评估分数和判定理由运行耗时和 token 消耗。这样当线上效果出现波动时才能回溯到具体的失败样本。9.3 提示词与代码的版本管理提示词是会持续演化的资产建议像管理代码一样管理提示词将提示词存放在独立文件中不要散落在业务代码里使用 Git 管理提示词的每次变更每次修改后用自动化评估器做回归测试重要变更需要人工审核后再上线。9.4 保护 API 密钥与最小权限项目中一定不要把 API Key 硬编码在代码里。使用环境变量或专用的密钥管理服务。同时遵循最小权限原则每个应用只申请它需要的最小权限避免一个密钥到处复用。如果密钥不慎泄露立即在服务商后台吊销并重新生成。9.5 设计上预留“人工降级”开关任何 AI 自动化流程都应该设计人工降级方案。比如 Agent 连续多次达不到质量阈值时可以把任务转交人工线上业务流程应该支持随时切换回旧的稳定版本。这样即使 AI 出 bug也不会影响核心业务。10. 总结与下一步学习路线这篇文章围绕“Making AI Smarter with AI”这个主题从四个层次展开提示词优化让 AI 分析并优化提示词合成数据生成让 AI 生成训练和评测数据自动化评估用 LLM-as-a-Judge 批量评估输出质量Agent 自我迭代构建感知结果、自动修正的执行闭环。这四个层次可以独立使用也可以组合成完整的 AI 工程流水线。代码我已经尽量简化你可以直接复制到自己的项目中修改使用。如果你在自己环境下运行遇到问题优先检查模型服务地址、API Key 和依赖版本大部分报错都出在环境差异上。更进一步可以往这几个方向深入学习RAG 与向量检索让 AI 能读取外部知识库再回答问题是当前企业应用的主流方向微调与对齐如果基础模型效果不够可以考虑在垂直领域做微调多 Agent 协作把“写作者 评估者 优化者”扩展成多个 Agent 协作的复杂系统模型评估体系学习更严谨的评测集设计、评估指标和人工评估方法。如果这篇内容对你有帮助可以收藏备用。也建议你手头准备一个项目把思路落地成代码一定会有不少收获。运行中遇到任何卡点欢迎在评论区交流讨论。