1. 从写提示词到搭系统AI自动化工程到底在解决什么问题大多数人接触AI的第一反应是写个好提示词然后打开对话框把需求敲进去等结果。这个模式在单次任务里够用但一旦任务变成每天要跑几十次要串联多个步骤要保证输出格式稳定纯靠手写提示词就会迅速崩溃。我最早做内容批量生成的时候一天要复制粘贴上百次提示词改一个变量就得重新检查整段话错一个标点输出就跑偏那种感觉就像用一把没有刻度的尺子量东西每次都得重新对一遍。AI自动化工程系统提示词核心不是写一句聪明的话而是把提示词当成一套工程系统里的一个模块来设计。它要解决的是三个层面的问题第一可复用——同一套提示词在不同输入下都能稳定产出符合预期的结果第二可组合——多个提示词模块能像流水线一样串起来前一个的输出是后一个的输入第三可维护——当业务需求变化时改一个地方不会引发连锁崩溃。这套思路和传统软件工程里的函数封装非常像。你写一个函数不是为了跑一次而是为了被调用一千次。系统提示词就是AI的函数签名它定义了角色、边界、输入格式、输出格式和异常处理方式。区别在于传统函数的逻辑是确定的而AI的输出带有概率性所以系统提示词还要额外承担收敛输出空间的职责。适合读这篇内容的人我大致分三类一是已经在用AI干活、但每次都要重新调提示词的人二是想把AI接入自己工作流、但不知道从哪下手的人三是做自动化测试、运维、内容生产等重复性工作想用AI替代手工环节的人。如果你属于其中任何一类接下来的内容应该能帮你省下不少试错时间。2. 系统提示词和普通提示词的分界线在哪里2.1 普通提示词是一次性指令系统提示词是长期契约普通提示词更像你在餐厅点菜来一份宫保鸡丁少放辣。厨师做完这一单就结束了。系统提示词更像你给一个新员工写的岗位说明书你负责什么、按什么标准做、遇到什么情况找谁、输出物长什么样。它不是为了单次交互而是为了在大量重复调用中保持一致。我做过一个对比实验同一个从产品描述生成卖点文案的任务用普通提示词跑20次输出风格漂移严重有的偏正式、有的偏口语、有的甚至开始编造参数换成系统提示词之后20次输出的结构一致率从不到60%提升到95%以上。差距不在提示词写得好不好而在于有没有把约束条件显式化。2.2 三个硬指标稳定性、可组合性、可观测性判断一套提示词是不是系统级的我一般看三个指标。稳定性指的是同样的输入多次运行输出的核心结构是否一致。这里不要求字字相同但格式、字段、语气基调必须可控。做法是把必须遵守的规则放在提示词最前面和最后面中间放具体任务描述利用大模型对首尾位置更敏感的特性来强化约束。可组合性指的是这套提示词的输出能不能直接被下一个环节消费。比如第一个模块输出JSON第二个模块就要能解析这个JSON。如果第一个模块有时候输出JSON、有时候输出Markdown表格那组合就断了。所以系统提示词里必须明确指定输出格式并且给出格式示例。可观测性指的是当输出不符合预期时你能定位到是哪一段提示词出了问题。普通提示词是一大坨出了问题只能整体重写系统提示词应该分块每块负责一个明确的约束方便单独调试。2.3 一个常见的误解系统提示词不等于更长更复杂很多人以为系统提示词就是把话写得越多越好其实恰恰相反。我见过一份两千多字的提示词里面塞了角色设定、任务描述、格式要求、示例、注意事项、兜底策略结果模型反而抓不住重点输出质量还不如三百字的精简版。系统提示词的关键是结构清晰、约束明确、冗余最少。每一句话都要有存在的理由能删的就删。我自己的习惯是先写一版最简的跑十次看哪里出问题再针对性地加约束而不是一开始就把所有可能的情况都写进去。3. 一套可落地的系统提示词骨架长什么样3.1 角色层定义谁在说话和对谁说话角色层不是写一句你是一个专业助手就完事了。有效的角色定义要包含三个要素专业身份、服务对象、表达风格。比如做自动化测试报告生成角色层可以这样写你是一名有五年经验的自动化测试工程师负责向开发团队和产品经理汇报测试结果。 你的读者包括技术人员和非技术人员所以结论要直白技术细节放在附录部分。 表达风格客观、简洁不堆砌形容词不用感叹号。这三句话分别解决了用什么知识回答问题输出给谁看用什么语气写的问题。缺了任何一个输出都会偏。我试过只写你是测试工程师结果模型经常用一堆技术黑话产品经理根本看不懂。3.2 任务层把做什么拆成可执行的步骤任务层最容易犯的错是写得太笼统。帮我分析数据这种指令模型只能靠猜。系统提示词里的任务描述应该像操作手册一样具体。一个可参考的写法是你的任务是按以下步骤处理输入数据 1. 检查输入是否包含必填字段id、name、timestamp缺失则记录到 errors 数组 2. 对每条有效记录提取 name 字段并去除首尾空格 3. 按 timestamp 升序排列 4. 输出结果格式见下方输出规范。这种写法的好处是每一步都有明确的判断依据和动作模型不需要发挥创造力。在自动化场景里创造力往往是负面的因为你要的是可预测。3.3 约束层把不能做什么写清楚约束层是系统提示词里最容易被忽略、但最关键的部分。大模型有很强的补全冲动你不说不能做什么它就会自己加戏。常见的约束包括不得编造输入中不存在的信息不得改变指定的输出格式遇到无法处理的情况输出指定的错误标识而不是自行猜测不得在输出中添加解释性文字除非明确要求。我踩过的一个坑是让模型从一段文本里提取邮箱地址结果它把exampledomain这种不完整的字符串也补全成了exampledomain.com。后来在约束层加了一句只提取输入中完整出现的邮箱不得补全或推测问题就解决了。3.4 输出层用示例锁定格式输出层最有效的做法不是描述格式而是直接给一个示例。人对格式的理解有歧义模型也一样。你说输出JSON它可能输出带注释的JSON、带Markdown代码块的JSON、或者字段顺序随机的JSON。给一个完整的示例歧义就消失了。输出必须严格遵循以下JSON结构不得添加或删除字段 { status: success, data: [ {id: 001, name: 示例名称, timestamp: 1700000000} ], errors: [] }注意示例里的值要用占位符不要让模型误以为这些是真实数据。我一般会在示例后面补一句以上仅为格式示例实际输出请使用真实处理结果。4. 把提示词接入自动化流水线的实操路径4.1 先跑通单点再考虑串联我见过太多人一上来就想搭一个全自动内容工厂结果每个环节都没调稳串起来之后到处漏。正确的顺序是先把一个环节的提示词调到稳定输出再接入下一个环节。具体做法是选定一个最小任务比如把一段中文翻译成英文用系统提示词跑50次统计输出格式的合规率。如果合规率低于90%先别急着往下走继续调提示词。合规率达标之后再把这个环节的输出作为下一个环节的输入重复同样的过程。4.2 用脚本做批量调用和结果校验手工复制粘贴永远做不成自动化。哪怕你只是用最简单的Python脚本也比手工强。下面是一个最小可用的调用框架import json import time def call_model(system_prompt, user_input, max_retries3): for attempt in range(max_retries): try: response client.chat(systemsystem_prompt, useruser_input) result json.loads(response) if validate(result): return result except (json.JSONDecodeError, ValidationError): time.sleep(1) return {status: error, reason: max_retries_exceeded} def validate(result): required [status, data, errors] return all(k in result for k in required)这个框架里有三个关键点重试机制、格式校验、错误兜底。大模型的输出有概率性单次失败不代表提示词有问题但连续失败就说明需要调整。校验函数负责判断输出是否符合预期不符合就重试重试多次仍失败就返回错误标识交给上游处理。4.3 日志记录让每次调用都可追溯自动化系统里日志不是可选项。我一般会记录四个字段输入、系统提示词版本、原始输出、校验结果。这样当某次输出出问题时可以快速定位是输入的问题、提示词的问题还是模型本身波动。日志的存储格式建议用JSON Lines每行一条记录方便后续用脚本分析。我自己的习惯是每天跑完之后统计一次合规率如果某天合规率突然下降就去翻当天的日志通常能发现是某类输入触发了提示词的盲区。4.4 版本管理提示词也要有提交记录提示词改了之后输出质量可能变好也可能变差。如果没有版本记录你根本不知道是哪次改动导致的。我的做法是把系统提示词存成独立文件用Git管理每次改动写清楚改了什么、为什么改、改完之后合规率变化多少。prompts/ extract_v1.txt extract_v2.txt extract_v3.txt CHANGELOG.mdCHANGELOG里记录的内容大概是这样v3 (2024-06-15) - 在约束层增加不得补全不完整邮箱 - 合规率从82%提升到96% - 副作用对含特殊字符的邮箱识别率略降待观察这种记录看起来麻烦但当你三个月后回头看会感谢自己当初记了这些。5. 那些只有踩过才知道的坑5.1 提示词里的否定句经常被忽略大模型对否定句的处理能力比人弱。你写不要输出解释性文字它可能还是会加一句以下是处理结果。更稳的写法是正面描述你要什么输出仅包含JSON对象第一个字符是左花括号最后一个字符是右花括号。我做过对比用否定句约束格式合规率大概70%换成正面描述合规率能到90%以上。原因不难理解模型在生成时是逐token预测的否定句需要它先理解什么不能做再反推该做什么多了一层转换出错概率自然高。5.2 长输入下的中间遗忘现象当输入文本很长时模型对中间部分的关注度会下降。这是注意力机制的固有特性不是提示词能完全解决的。应对方法有两个一是把关键约束放在提示词的开头和结尾二是如果输入本身很长先在提示词里要求模型先复述任务要求再开始处理用复述动作把注意力拉回来。我在处理长文档摘要时用过第二个方法效果明显。让模型先输出一句我将按照以下要求处理……然后再输出摘要格式合规率和内容完整度都有提升。5.3 温度参数和提示词要配合调温度参数控制输出的随机性。做自动化任务时温度一般设低0到0.3保证输出稳定。但有些任务需要一定的多样性比如生成多个候选方案这时候温度可以设高一些。关键是温度变了提示词可能也要跟着调。低温下模型倾向于保守输出如果提示词里要求创造性它可能做不到高温下模型容易发散如果提示词约束不够强格式就容易崩。我一般会先固定温度调提示词调稳之后再微调温度看效果。5.4 不要指望一套提示词打天下不同模型对同一套提示词的反应不一样。同一个任务在A模型上跑得好换到B模型可能就出问题。这不是提示词写得不好而是模型的训练数据和对齐方式不同。我的做法是针对主力模型调一套精细提示词同时准备一套通用版作为备选。通用版约束更宽松牺牲一些格式严格性换取跨模型的兼容性。当主力模型不可用时切到通用版加备用模型至少能保证流程不断。6. 从提示词工程到Agent边界在哪里6.1 系统提示词能做的和不能做的系统提示词擅长的是定义角色、约束格式、规范流程、处理确定性任务。它不擅长的是需要多轮交互才能完成的任务、需要调用外部工具的任务、需要根据中间结果动态调整策略的任务。举个例子让模型从一段文本里提取信息这是系统提示词能搞定的。但让模型先搜索最新数据再根据搜索结果决定下一步查什么这就超出单次提示词的能力范围了需要Agent架构来支撑。6.2 Agent补的是决策和工具调用这两块Agent的核心是在提示词之外增加了两个能力工具调用和循环决策。工具调用让模型能查数据库、调API、读写文件循环决策让模型能根据上一步的结果决定下一步做什么。但Agent不是银弹。Agent的每一步决策都依赖提示词如果提示词没写好Agent会陷入死循环或者做出莫名其妙的决策。我见过一个Agent因为提示词里没写清楚什么时候停止结果反复调用同一个工具十几次。所以我的建议是先把系统提示词调稳再考虑上Agent。提示词是地基Agent是上层建筑。地基不稳楼越高越危险。6.3 一个实用的判断标准什么时候该用系统提示词什么时候该上Agent我的判断标准是如果任务的步骤数是固定的用系统提示词如果步骤数取决于中间结果用Agent。比如翻译一篇文章步骤固定读取、翻译、输出。用系统提示词就够了。根据用户问题查资料并回答步骤不固定可能查一次就够可能查三次可能查完发现方向不对要换关键词。这种就该用Agent。7. 我在实际项目里沉淀下来的几条经验第一条提示词里的每个字都要有理由。我现在的习惯是写完一版提示词之后逐句问自己删掉这句会怎样。如果删掉之后输出没变化这句就是冗余的删。提示词越短模型越容易抓住重点。第二条测试用例要覆盖边界情况。不要只用正常输入测提示词要专门准备一批脏数据空输入、超长输入、含特殊字符的输入、格式不规范的输入。这些才是真正考验提示词健壮性的场景。我一般会准备20到30条边界用例每次改完提示词都跑一遍。第三条合规率比单次效果更重要。单次输出很漂亮但十次里崩三次的提示词不如单次输出普通但十次都稳的提示词。自动化场景里稳定性就是生命线。第四条留好人工兜底的口子。再好的自动化系统也会有处理不了的情况。我的做法是在流程里设置一个待人工处理队列凡是校验失败超过重试次数的任务自动进队列由人来判断是改提示词还是手工处理。完全无人值守听起来很美但实际项目里一个合理的人工兜底环节能省掉大量救火时间。第五条定期回顾提示词的历史包袱。业务在变提示词也要跟着变。我每季度会翻一遍在用的提示词把那些为了应对已经不存在的问题而加的约束删掉。提示词和代码一样不清理就会越来越臃肿。最后分享一个我常用的小技巧当你觉得提示词已经调无可调、但输出还是不满意时试着把任务拆成两步。第一步让模型理解并复述任务第二步让模型基于复述执行。这个拆分动作看起来多了一步但往往能解决很多单步搞不定的问题因为复述过程本身就是在帮模型对齐你的意图。