上个月我在重构团队的自动化测试平台时做了一件看起来跟“写代码”没什么关系的事给全组人统一了一套AI提示词规范。起因很简单——同样让AI生成pytest用例有人拿到的代码直接用不了有人拿到的从命名到断言都像老手写的。差别不在模型在提示词。这篇文章想说的就是这个AI自动化工程系统里的提示词不应该靠临场发挥而应该当成一套工程系统来设计。它不是一个“怎么跟AI聊天”的问题而是一个角色设定、任务描述、输出约束、结果校验同时设计的系统工程问题。我会用自动化测试和自动化运维两个场景做例子把我实际在用的提示词框架、失效案例和调试方法全部拆开讲。1. 为什么要为“AI自动化工程”单独设计提示词系统1.1 提示词工程和普通对话的本质区别普通对话式提示词目标是让模型“理解并回答”允许发散。你可以问AI“帮我想想这个接口可能有什么问题”它给你十个方向每个都有道理这就够了。但自动化工程的提示词目标完全不一样。它输出的不是“一段话”而是“一段可以被机器执行的产物”——测试代码、Playbook、配置文件、分析结论。这三类产物有一个共同特点必须被后续流程消费。你的CI脚本要跑它Ansible控制节点要解析它监控平台要读它。任何格式漂移、字段缺失、约束违背都会在下一环直接爆掉而不是像聊天那样“重说一遍就行”。所以自动化工程的提示词本质上是在跟模型签一份“交付契约”。契约里要写清楚交付物长什么样、边界在哪里、怎么自检。如果这些不写清楚模型会默认用最高效的方式满足你的字面意思而不会自动理解你的工程意图。举个例子你直接在聊天窗口说“帮我写个接口测试用例”模型会返回一个很漂亮但没法直接运行的demo——因为缺少具体接口地址、请求头、断言基准。这不是模型弱而是提示词少了“参数约束”和“验收标准”。同样的模型喂给一份结构完整的工程提示词产出质量会完全不一样。1.2 AI自动化提示词要解决的三个核心问题我在实际使用中把自动化场景提示词要解决的问题归纳成三个信息完整度、格式稳定性、可验证性。第一个是信息完整度。自动化执行需要的信息——环境、入参、预期、异常分支——必须全部注入提示词缺一个字段下游就断。模型不知道你的测试环境地址就会写一个localhost不知道鉴权方式就会略过Token。这不是模型不聪明是你没给它足够的上下文。第二个是格式稳定性。AI输出天然不稳定同一句话换个问法就换格式但工程系统要求绝对稳定。所以提示词必须强制输出为可解析的格式比如特定结构的代码文件、JSON或Markdown表格并且在模型输出偏离格式时用后续校验步骤“打回去”重写。第三个是可验证性。自动化工程讲究闭环产出之后必须有验证而不是看了一眼“觉得还行”就放行。提示词要内置自检指令——让模型先生成再自审或者用外部工具编译、静态检查、dry-run独立校验结果。这三个问题是我在让AI生成pytest用例、Ansible剧本时反复踩坑后总结出来的。下面这套六要素架构就是围绕它们设计的。2. 自动化工程提示词的六要素架构2.1 六要素角色、任务、上下文、约束、格式、验收我现在写自动化类提示词固定包含六个部分。思路乱了的时候就按这个表来回填基本不会漏东西要素解决的问题反面案例角色画像告诉模型用哪套行为偏好工作“你是开发”太模糊模型默认输出demo级代码任务定义说清楚到底要交付什么动作“分析一下”会得到发散性回答上下文注入提供执行产物需要的全部信息缺测试环境地址接口全是localhost行为约束划定AI不能碰的边界不限制依赖模型引入一堆第三方库输出格式保证产物可被后续工具消费不限定格式模型自由发挥验收标准让模型自检是否满足要求不要求自检AI对自己的输出毫无判断角色画像这里多说一句。不是简单写“你是资深测试开发”就完了要给行为偏好。我常用的写法是“你倾向于编写边界断言而不只是状态码断言”“你在生成用例时会主动考虑空数据和超长数据”。这种偏好描述比一个干巴巴的头衔好用得多。任务定义一定要动词具体化。“分析一下这个日志”是模糊任务“定位日志中Top5错误类别并给出每条根因假设”是工程任务。动词越具体输出越像个可执行的报告而不是读后感。上下文注入要克制只给当前产物需要的信息。比如生成pytest用例就给接口文档、已有目录结构、被测函数的边界约定不要把公司历史架构文档也丢进去模型会被无关信息带偏。行为约束是很多人忽视的。我最常用的约束是“不要修改被测函数实现”“不要引入额外依赖”“只使用标准库和pytest”。有一回没写“不要修改被测函数”AI“贴心”地把被测代码的重试逻辑也改了我差点把改坏的代码合进去。输出格式要精确到文件级别。我会写“输出一个完整Python文件文件顶部注明项目名和接口版本所有用例采用test_前缀。”宁可多啰嗦两句也不能让模型自己猜。验收标准是六要素里最值钱的一条。它的作用是让模型在结束生成前自己对照约束清单检查一遍输出。实际效果是加了这一条的提示词生成用例的边界覆盖率和格式合规率都明显更高。2.2 从“一次性生成”到“带反馈循环的提示词”单条提示词只是起点。做工程化时我会把整个流程设计成三步循环。第一步是生成GenerateAI根据需求产生初稿。第二步是校验Validate用编译、静态检查、dry-run等工具做机器校验同时用第二条提示词做逻辑校验。第三步是修订Revise把校验结果反馈给AI让它修改。举个例子生成pytest用例后我不会直接看代码本身而是先跑一遍pytest --collect-only确认用例能被正确收集。如果收集失败就把失败信息原样丢回给模型追加一句“这是pytest收集失败的错误信息请修正生成代码不要解释原因直接输出完整修正版代码”。这套闭环比“一次生成直接上线”的成功率高很多。而且每轮循环中反馈给模型的信息越原始越好——让它自己读报错比自己当传话筒更高效。3. 自动化测试场景用提示词产出可直接跑的pytest用例3.1 从需求文档到可执行的pytest用例我目前在项目里实际使用的测试用例生成提示词长这样你是一名测试开发工程师负责为一个RESTful API编写pytest接口自动化测试用例。 任务根据下面的接口文档生成test_get_orders.py文件。 上下文 - 接口GET /api/v1/orders - 参数page默认1正整数、size默认20范围1-100、status可选枚举值PENDING/PAID/CANCELLED - 鉴权方式Bearer Token放置于请求头Authorization中 - 基础URLhttps://test.example.com - 项目依赖requests、pytest 约束 - 只生成测试代码不生成被测函数实现 - 不引入额外依赖只用requests和pytest - 用例名以test_开头 - 覆盖正常分页、非法参数、Token缺失、状态筛选四种场景 - 断言必须有状态码和关键字段双重校验 - 测试数据通过pytest的fixture方式准备不写死订单ID。 输出格式输出一个完整Python文件文件顶部注明接口版本用例内部用注释标明场景名称。 验收标准在文件末尾追加三行自检注释分别列出 1. 覆盖了哪些场景 2. 每条用例的断言是否包含响应体字段级校验 3. 是否遵守了“不引入额外依赖”约束。这段提示词和我日常随手写的区别核心在于“验收标准”。模型生成完代码后会主动回看自己是否覆盖了约束。实测下来带自检提示词和裸提示词的用例有效性差距很大——自检版本至少能保证场景覆盖不缩水裸版本经常只写两条“happy path”用例就交差了。3.2 断言生成与测试数据构造的提示词技巧大部分失败用例问题不在用例设计而在断言太弱。典型表现是只校验response.status_code 200接口返回一个错误JSON也能通过。针对这个问题我会在提示词里明确要求“业务断言”“断言必须验证业务含义而不是HTTP状态码。例如订单支付成功时响应体status字段必须为PAID且必须存在transactionId字段创建订单失败时必须验证error.code在预设错误码枚举内。”这句话一加AI生成的断言就从“状态码断言”升级成了“字段级业务断言”。测试数据构造是另一个容易翻车的地方。AI默认喜欢写死数据比如order_id 2024001。这种用例跑一次没问题第二次跑就大概率失败。我的提示词里会专门写“测试数据通过fixture动态生成不允许出现写死的业务ID分页测试使用动态生成的数量保证每页大小可配置。”实际上fixture动态生成数据还有个额外好处并行执行时不撞数据。团队跑pytest-xdist时固定ID会导致严重的测试间干扰我在这里吃过一次大亏。3.3 失败用例自动分析提示词pytest跑完一片红的时候最浪费时间的就是人肉盯日志。我现在会把失败日志直接交给AI但不会只丢一句“帮我看看为什么挂了”。我会带上下文和约束这是一次接口自动化测试的失败输出包含pytest摘要和traceback。 请执行以下任务 1. 区分断言失败、环境失败、代码缺陷三类根因 2. 对每类根因给出判定依据 3. 对断言失败指出期望值和实际值的差异 4. 对环境失败指出缺失的依赖项或环境变量。 输出格式只输出一个Markdown表格列为“根因分类 / 失败用例 / 判定依据 / 建议动作”。不要解释分析过程。注意最后那句“不要解释分析过程”。这个约束很关键——AI默认会给你写一大段“从输出中可以看到……”的分析散文看着专业实际没法直接用。我要的是表格直接合并进测试报告讲清“根因分类、判定依据、建议动作”就够了。4. 自动化运维场景Ansible剧本与巡检提示词4.1 从运维需求到可执行的Ansible Playbook运维侧的提示词和测试侧差别很大。测试场景更看重场景覆盖运维场景更看重幂等性和环境差异。Ansible Playbook一旦写得不幂等重复执行就是灾难。我的运维场景提示词模板你是一名SRE运维工程师负责编写Ansible自动化脚本。 任务根据下面的运维需求生成deploy_nginx.yml剧本文件。 上下文 - 目标主机CentOS 7.9Python 3.6root用户执行 - 需求在10台Web节点部署nginx 1.20并开启gzip压缩 - nginx配置文件路径/etc/nginx/nginx.conf - 仓库内已有模板文件templates/nginx.conf.j2 约束 - 所有task必须幂等支持重复执行不报错 - 只使用ansible.builtin模块不使用command或shell模块执行安装类操作 - nginx配置使用template模块渲染不允许inline内联配置 - 包含handler用于配置文件变更后重启nginx - 每个task必须有name注明操作意图 - 不使用become目标环境已配置sudo免密。 输出格式一个合法YAML文件要求ansible-playbook --syntax-check能够通过。 验收标准在剧本末尾用注释列出每个task的幂等性依据、哪个handler会触发重启、哪些模块被刻意避免使用。这里“不使用command或shell模块执行安装类操作”是最重要的约束。模型特别喜欢用shell模块因为写起来顺手但shell模块天然不幂等重复执行时包管理器会报“already installed”或做无意义重装。用yum模块和template模块才是Ansible的规范玩法。上下文里写清楚“CentOS 7.9/Python 3.6”也很有必要——它约束了yum模块的可用性避免模型生成只适用于Ubuntu的apt操作。4.2 巡检报告与日志异常分析提示词运维日常最常做的日志分析用提示词可以做得非常细。我自己有个长期在用的日志告警分析提示词以下是一小时内Nginx错误日志的采样片段。请按下列要求分析 1. 按错误类别聚合输出出现频率Top5的错误模式 2. 每个模式给出可能根因和一条验证命令 3. 涉及上游超时的区分是网络延迟还是上游服务无响应 4. 输出必须包含“不确定项”标记当证据不足时明确写“证据不足无法判定”禁止强行给出结论。 输出格式Markdown表格列为“错误模式 / 出现次数 / 可能根因 / 验证命令 / 置信度”。置信度分为高、中、低三档。“不确定项”这个要求是我后来加的。AI本质上是个概率模型见到什么都能给你编一个解释哪怕证据完全不充分。让它在证据不足时明说“不确定”比强行给一个误导性结论安全得多。尤其在故障排查场景错误结论比没有结论更危险——它会让你在错误的方向上浪费时间。实际用下来加了“置信度”和“不确定项”两列之后这份报告的可信度直线上升。运维值班同事可以直接根据置信度排序处理问题不用怀疑AI是不是在瞎编。5. 提示词的失效模式与调试方法5.1 三种典型“假成功”及其对策提示词调试最大的难点是“看起来成功了实际是废的”。我总结了三种最常见的假成功每一种都有对应对策。第一种是输出格式合法但逻辑不对。比如pytest用例能被收集成功但断言根本没校验响应体或者校验了但只校验第一层字段。对策在验收标准里加硬性要求比如“所有断言必须对响应体做至少一次field级校验并在自检注释中说明校验了哪个字段”。第二种是上下文被忽略。模型在大量上下文里挑着用导致用错了接口版本或旧参数。我在一次生成用例时文档里有两个版本接口模型选了旧版参数生成完还自信满满。对策把关键上下文前置并在约束里写“只允许使用下方文档信息不要主动补充项目记忆”。第三种是模型编造不存在的配置项。这在Ansible场景特别常见——AI会“发明”某个模块参数看起来很像那么回事一执行就报错。对策在验收标准里要求“所有配置项必须来自上下文给出的官方路径不确定的参数必须标注来源”。5.2 上下文污染不是喂得越多越好很多人的直觉是给AI的信息越多输出越准。我在实践中发现这个直觉在工程场景经常是反的。有一回我想让AI根据整个仓库生成一个测试计划把目录树、关键模块代码、CI配置全塞进了提示词。结果模型记住了无关模块生成代码时引用了一个根本不存在于项目里的工具函数还一本正经地给它加了注释。我的解决思路是分阶段注入。生成阶段只给最小上下文——接口文档、目标目录、依赖列表。等到校验阶段再把报错信息、缺失模块信息补进去。两阶段各管各的上下文互相不污染准确率明显提升。5.3 用回归集和评分提示词迭代提示词提示词改来改去怎么知道哪个版本更好靠感觉不靠谱。我维护了一个小型回归集5到10组固定输入配套每组输入的期望特征描述。每次修改提示词都拿回归集跑一遍然后把AI的输出丢给另一个“评分提示词”让它按维度打分。评分维度包括格式合规性、功能覆盖度、约束遵守度。最后把分数记录在案用数据判断该不该合入这次修改。这套方法本质上就是把“测试”也应用到提示词上。提示词工程和数据模型一样需要一套评测体系才能持续迭代而不是拍脑袋决定“这次好像变聪明了”。6. 把提示词工程落进团队工作流6.1 提示词模板库与版本管理提示词应该和代码一样进Git不能躺在某人的聊天记录里。我在团队里建了一个目录每个场景单独建文件夹prompt_templates/ ├── README.md ├── pytest_generator/ │ ├── prompt.md │ ├── examples/ │ │ └── input_orders_api.md │ └── expected/ │ └── output_orders_api.md ├── ansible_playbook/ │ ├── prompt.md │ └── examples/ └── log_analysis/ ├── prompt.md └── expected/prompt.md里存模板examples里放固定输入样例expected里放期望输出特征。每次调整模板都同步更新expected内容。下一次回归测试时直接用脚本对比AI输出和expected的差异符合预期说明模板升级有效不符合就要重新评估。模板库的入口README里会写清楚每个模板的适用范围和已知局限。比如pytest生成模板就注明“适用于RESTful API项目暂不支持MQ消息类测试生成”。这样新人不会拿错模板硬套。6.2 从提示词到Agent化的演进当某条提示词经过多轮回归集测试稳定性和质量都达标后我会把它进一步封装成Agent能力。比如“pytest用例生成器”可以作为平台上的一个工具服务被自动化测试平台的菜单调用。内部执行的其实就是那套带参数校验、格式校验、回归校验的提示词逻辑。这里系统提示词相当于Agent的工作手册固定任务模板和校验逻辑是执行机制回归测试集是质量防线。三者一起构成一个可靠的自动化能力单元。说到底提示词工程就是自动化工程里的“需求分析”环节。把它做扎实了后面Agent化、平台化才有基础做不扎实AI生成的每一行代码都可能是埋雷。我自己的体会是别小看提示词它跟自动化代码一样会“腐化”。需求变更了接口升级了模型版本更新了同一套提示词的效果都会悄悄漂移。所以别写完就放着要像维护测试用例一样去维护提示词。我现在每个季度做一次全量回归把评分最低的几条提示词翻出来重写。这个习惯帮我省掉了大量肉眼盯AI输出的时间也让团队对AI产物的信任度保持在一个健康水平。