想让AI稳定输出一份可以落地的检查清单，核心不是让模型自由发挥，而是把场景、对象、约束和输出结构提前固定下来。实际工作中经常出现这种情况：给模型一句“帮我生成上线检查清单”，返回的条目要么颗粒度太大，比如“检查系统稳定性”，要么分类混乱，安全项和性能项混在一起。出现这种结果，多半不是模型能力不足，而是提示词里缺少必要的控制信息。
一份有效的CheckList生成提示词，通常包含四个要素：角色、场景上下文、条目规则和输出格式。例如角色设定为“高级运维负责人”，场景补充“电商系统夜间发布，涉及数据库迁移”，条目规则写明“每条以动词开头，不超过12个字，禁止使用‘确认’‘检查’这类空泛表述”，输出格式限定为“安全、性能、数据、回滚四个分类”。这四要素写清楚后，模型生成的结果会明显更具体，也更接近可以直接执行的核对表。
一、通用CheckList提示词模板与参数设计
先看一个可复用的模板。这个模板把容易变化的因素全部做成了占位符，实际使用时只需要替换对应的变量，就能适配不同场景。
你是一名{角色}，负责为【{场景名称}】创建检查清单。
背景信息：{场景描述}
风险偏好：{高/中/低}
输出分类：{分类1}、{分类2}、{分类3}、{分类4}
每类条目数量：{数量}条
条目规则：
1. 每条以动词开头，长度不超过15个字
2. 禁止使用“检查”“确认”等空泛动词
3. 每条必须附带一个可验证的验收标准
4. 覆盖已知风险和常见遗漏点
输出格式：Markdown表格，列为：分类、检查项、验收标准、风险等级
模板里的角色不是随便写的。不同角色会改变模型对风险点的关注范围。例如“高级安全工程师”会更偏向攻击面和漏洞利用，“项目负责人”则可能更关心资源到位和跨团队依赖。场景描述越具体，生成的条目越不容易出现泛化内容。比如只写“上线发布”，模型可能给出“检查配置”“检查依赖”这种笼统条目；但写成“基于Kubernetes的微服务系统灰度发布，涉及数据库迁移和Redis缓存更新”，模型会自然加入“迁移前后数据一致性校验”“缓存预热策略验证”等更具体的动作。
风险偏好这个参数容易被忽略。高风险场景应该增加回滚验证、监控告警和人工确认节点；低风险场景则可以压缩检查项，避免清单过于冗长导致执行者直接跳项。条目规则中的“禁止使用空泛动词”非常关键，因为模型生成清单时倾向于出现“检查代码质量”“确认系统稳定”这类几乎无法验收的条目。强制每项附带验收标准，可以把清单从“要做的事”升级为“完成后如何证明”。
二、用Python脚本调用模板生成清单
仅仅有文本模板还不够，接入实际工作流通常需要程序化调用。下面是一段Python示例，使用OpenAI兼容接口，将模板中的占位符替换成具体参数后发送给模型，并返回生成结果。
from openai import OpenAI
client = OpenAI()
template = """你是一名{role}，负责为【{scene}】创建检查清单。
背景信息：{context}
风险偏好：{risk}
输出分类：{categories}
每类条目数量：{num}
条目规则：
1. 每条以动词开头，长度不超过15个字
2. 禁止使用“检查”“确认”等空泛动词
3. 每条必须附带一个可验证的验收标准
4. 覆盖已知风险和常见遗漏点
输出格式：Markdown表格，列为：分类、检查项、验收标准、风险等级
"""
def generate_checklist(role, scene, context, risk, categories, num=8):
prompt = template.format(
role=role,
scene=scene,
context=context,
risk=risk,
categories=categories,
num=num
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "你是一个专业的风险控制与项目管理助手。"},
{"role": "user", "content": prompt}
],
temperature=0.3
)
return response.choices[0].message.content
if __name__ == "__main__":
result = generate_checklist(
role="高级运维工程师",
scene="Web应用上线发布",
context="电商系统夜间发布，涉及MySQL版本升级和Redis缓存刷新",
risk="高",
categories="安全,性能,数据一致,回滚",
num=10
)
print(result)
这段代码的意义在于，它把CheckList生成从“临时问一句”变成了一个可重复执行的函数。temperature设置为0.3是为了降低随机性，让清单在多次调用之间保持稳定。如果你所在团队使用其他大模型或私有化部署接口，只需要替换客户端初始化部分，模板和函数逻辑可以完全复用。
实际集成时还可以增加后处理步骤。例如把返回的Markdown表格解析成JSON，再写入工单系统或飞书多维表格。这样每次发布前，负责人只需要运行一次脚本，就能得到一份结构化的检查清单，执行者可以逐项勾选和留痕。
三、不同场景下的提示词侧重点
通用模板解决的是“从无到有”的问题，但不同业务场景对清单的关注点差异很大。如果直接把通用模板套用于代码审查，模型可能给出一堆与代码无关的项目管理条目。因此，针对高频场景定制关键参数会明显提升实用性。
代码审查场景：角色设定为“资深代码审查员”，风险偏好中高，输出分类建议换成“功能正确性、边界条件、安全漏洞、性能、可维护性”。关键是背景信息中要包含仓库类型、主要语言和变更范围。比如“审查一个Python后端服务中订单状态的并发处理逻辑”，模型才会把清单聚焦在锁机制、幂等性和事务边界上，而不是泛泛地说“检查命名规范”。
活动运营场景：角色换成“活动运营负责人”，输出分类改为“资源准备、合规风控、技术保障、应急预案、数据复盘”。背景信息需要说明活动规模、平台规则和预算上限。此时风险偏好不宜设得过高，否则清单会堆满审批节点，影响执行效率。验收标准更偏向“物料已提交并通过审核”“压测报告已回传”“客服话术已同步”这类可以明确闭环的动作。
安全巡检场景：角色设为“安全工程师”，风险偏好高，输出分类可包括“身份认证、权限控制、数据加密、日志审计、漏洞修复”。条目规则中要额外增加“每条必须关联到具体风险或攻击路径”。比如不要只写“检查权限配置”，而要给出“验证普通用户是否能访问管理接口，若可访问则判定不通过”这样的示例，模型才能理解颗粒度要求。
四、生成后的验证与迭代优化
AI生成的清单不能直接当作最终交付物。第一次输出的结果可能存在重复条目、分类边界模糊、验收标准不可验证等问题。比较实用的做法是增加一个“自我批判”环节：把第一版清单交给模型，要求它找出重复项、模糊项和遗漏项，并给出修订版。
下面是一份AI生成的【上线发布】检查清单：
{清单内容}
请执行以下优化：
1. 找出语义重复的条目并合并
2. 标记无法验证的验收标准，改写为可观察结果
3. 从“监控告警”“数据回滚”“人员通知”三个维度补充遗漏项
4. 输出为JSON，字段包含：分类、检查项、验收标准、风险等级、负责人角色
这个优化步骤通常能显著减少清单里的水分。例如第一版可能会同时出现“检查数据库备份完整性”和“验证数据库备份可恢复”，两条本质上是一个动作，只是表述不同。通过合并，可以腾出位置补充真正容易忽略的项，比如“确认回滚通知对象包含运营和客服”。
如果团队对清单质量要求很高，还可以用多个模型交叉评审。让A模型生成清单，B模型扮演执行者逐项打分，只保留评分高于阈值的条目。这种方式适合安全审计、金融系统变更等高风险场景，成本略高但能有效降低漏项率。
五、把CheckList变成可追踪的执行任务
清单的价值在于执行，而不是躺在聊天记录里。建议生成后直接要求模型输出结构化格式，例如JSON或YAML，这样可以无缝对接工单、看板或CI流水线。下面是一个简化后的JSON结构示例，展示了如何把分类、条目、验收标准和负责人组织在一起。
{
"scene": "Web应用上线发布",
"categories": [
{
"name": "数据一致",
"items": [
{
"action": "验证迁移后订单表行数一致",
"acceptance": "源库与目标库行数差值小于1%",
"risk": "高",
"owner": "DBA"
},
{
"action": "执行缓存预热脚本",
"acceptance": "预热完成后缓存命中率超过90%",
"risk": "中",
"owner": "后端工程师"
}
]
}
]
}
实际开发中，可以让Python脚本在拿到模型返回的JSON后，先做schema校验，再写入任务系统。这样每一步都是可追踪的，谁在什么时间完成了哪一项，结果是什么，都能留下记录。比起单纯生成一段文字，这种工作流更符合工程化的要求。
最后还有一个小技巧：把历史事故复盘记录作为背景信息喂给模型。比如把半年前一次因为配置遗漏导致回滚失败的报告贴进提示词，模型会特别关注类似风险，生成的清单比单纯从公开知识推导更加贴合团队的真实痛点。
AI CheckList提示词模板检查清单自动生成修改时间：2026-09-21 17:18:36