简介《AI引擎Prompt指令设计绿皮书》面向希望系统掌握ChatGPT、Claude、Bard等对话式AI工具的创作者、运营人员与职场学习者重点解决指令表述含糊、输出质量波动、不同场景难以复用等问题。内容从Prompt写作方法切入讲解如何明确定义需求、补充对话上下文、限定输出格式与篇幅、提供示例、设置内容边界并通过多轮迭代逐步优化指令同时给出小红书笔记、短视频开头、简历写作、求职面试与个人发展等场景模板方便读者对照修改并积累自己的指令库。资源包共1个PDF文件大小约3.64MB结构集中、便于随时查阅。已有6756人学习下载可作为从入门到进阶的Prompt设计参考帮助读者提升与AI引擎的沟通效率和内容产出质量。1. 一个反直觉的现象模型没变指令一改输出就崩某同学拿着一份写好的简历让 AI 润色同一款人工智能工具早上给出的版本条理清楚下午再问一次就变成一堆形容词堆砌某团队的内容编辑天天写 Prompt 指令产出的笔记时好时坏谁也说不清哪一版能过审。这类 Prompt 指令设计问题九成不在模型参数而在指令本身需求含糊、上下文断裂、约束没量化、没有可回滚的模板。《AI 引擎Prompt 指令设计绿皮书》这套方案要解决的正是这件事——把「随手一问」变成有公式、有骨架、有场景库、有验收标准的指令资产让 AI 引擎的输出从碰运气变成可复现。它适合两类人做 AI 应用方向课设、毕设需要一份完整可交付设计文档的学生要给团队沉淀内容生产规范、需要能直接抄模板的从业者。下面按需求、设计、落地、避坑、验收五段把整套方案摊开讲。2. 指令质量的分层模型把「写得好」拆成七个可检查的要素2.1 七要素的职责与先后顺序绿皮书给出的七条原则很多人当成并列的清单写指令时随手挑几条用结果自然是时灵时不灵。我一般把它们分成三层来看前三条决定模型「听懂没」中间三条决定模型「做得对不对」最后一条决定这套指令「能不能稳定复现」。分层之后你会发现输出质量差往往不是模型不行而是某一层整个缺位。第一层是语义对齐明确定义需求、提供足够上下文、使用简单直白的语言。需求定义要直白到没有歧义比如「用简单的语言解释什么是区块链」而不是「聊聊区块链」。上下文这一条最容易被忽略——多轮对话里模型并不会自动记住你三小时前说过的背景你要在新指令里复述关键前提比如「我们之前讨论过人工智能的发展接下来请解释机器学习及其应用」。语言层面则要避免长定语和嵌套从句模型不需要你文采好只需要你指代清楚。第二层是交付控制详细说明要求、举例说明、添加限制条件。这一层直接决定输出的可用率。要求要落到格式、长度、语言风格三件事上「请以不超过 500 字的短文形式介绍孩子如何学习编程」就是一条合格的控制句。举例是性价比最高的手段给一到两个同类示例模型能迅速抓住你想要的风格和颗粒度。限制条件则是安全阀敏感主题、商业文案、对外发布的材料都要显式写明禁区。第三层是迭代优化。这条放在最后不是因为不重要恰恰是因为它是唯一需要在真实输出上做判断的环节。第一版结果不理想常见做法是按「补背景、加示例、拆步骤、改约束」四个方向依次试而不是简单粗暴地重发一遍。同一句话发十次拿到十种答案那不叫迭代叫抽奖。要素缺失时的典型症状自检问句明确定义需求回答正确但偏离目标换成新人他能看懂要交付什么吗提供上下文多轮后答非所问、前后矛盾这条指令单独拎出来还成立吗语言直白输出结构混乱、指代不清有没有超过 30 字的长句详细说明要求长度、格式每次都不一样字数、段落、风格写死了吗举例说明风格漂移越写越像通用模板有没有给一正一反两个样本限制条件出现不该出现的表述禁区列了几条多次迭代靠重发碰运气这一版改的是哪个变量把这七条当检查表用比当写作指南用更有效。我的习惯是每次模板定稿前逐条打分低于六项的模板不进正式库。2.2 模板骨架角色、资料、技能、目标、规则、工作流、初始化单条指令能解决一次性问题要复用就得有骨架。绿皮书里那套短视频脚本指令其实给出的是一个相当标准的七段式结构专家、资料、技能、目标、规则、工作流、初始化。这个顺序不是随便排的它对应「模型是谁 → 凭什么 → 会什么 → 干什么 → 不能干什么 → 怎么干 → 从哪开始」的推演链条。落成配置文件比写在对话框里更好维护也方便后面做变量替换。# prompt_skeleton.yaml —— 七段式通用指令骨架 role: # 角色定义模型身份与能力边界越窄越稳 name: 短视频脚本创作专家 scope: 只负责脚本结构、开场与文案不负责拍摄执行和投放策略 profile: # 资料版本、语言、能力描述便于溯源与回归对比 version: 1.0 language: 中文 description: 擅长开场设计与叙事节奏服务过泛知识类账号 skills: # 技能写可验证的能力不写形容词 - 撰写 60 秒以内的口播脚本单句不超过 25 字 - 用悬念或冲突设计前三秒开场 - 按标题、正文、标签、话题词四段输出 goals: # 目标交付物 成功标准 - 产出可直接开拍的脚本初稿 - 开场在 3 秒内建立信息差 rules: # 规则硬约束与禁区永远放在目标之后 - 不生成夸大功效、绝对化承诺的表述 - 不输出与主题无关的引流话术 - 信息不足时先追问不要自行补全事实 workflow: # 工作流输入 → 处理 → 输出三段式 - 接收主题、时长、目标人群三个输入 - 先给三种开场方向等我选定再展开 - 按四段结构输出成稿 init: 你好我是短视频脚本助手。请先告诉我主题、目标时长和面向人群。逐段说一下怎么改。role.scope是最值得花时间的地方把「不负责什么」写清楚比写十行「你很专业」有用得多。skills要写成能被检验的行为比如「单句不超过 25 字」可以数「擅长创作」没法数。rules放在goals后面是刻意的先让模型知道要交付什么再告诉它边界在哪如果规则写在最前面长指令里模型容易只记住禁令忘了任务。workflow里加一步「先给方向再展开」是我常用的降返工手段让模型先暴露理解偏差比写完一大篇再推翻省事。init这一段经常被跳过但它决定了首轮对话的质量。初始化时把追问清单说清楚模型第一句就会问你要主题和人群而不是直接开始编。提示骨架里的字段不是越多越好。角色、目标、规则、工作流这四段是必填其余可按场景裁剪。字段一多维护成本会超过收益。2.3 参数与约束怎么量化从「要吸引人」到可检查的数字新手写指令最常见的毛病是用形容词下命令标题要吸引人、正文要简洁、语气要专业。这些词在模型侧没有对应刻度输出自然随机。合格的写法是把每条要求翻译成能数、能查、能判定的参数。绿皮书里那条笔记指令就做对了大半「正文控制在 1000 字以内尽量在 600 到 800 字之间」「至少 5 个表情符号元素」「标题最好带数字」——这些都能一眼核验。维度模糊写法可检查写法长度正文要简洁正文 600 到 800 字分 3 到 4 段标题标题要吸引人标题 18 到 24 字含 1 个阿拉伯数字疑问句或冲突句二选一语气语言要专业使用「你」不用「您」单句不超过 30 字避免三个以上连续术语数量多加一些标签末尾给 3 到 5 个话题标签按相关度从高到低排结构分段写清楚固定四段标题、正文、行动呼唤、配图建议段前加序号禁区别写太夸张禁用「最」「第一」「保证」「稳赚」等绝对化词还有一个容易被忽略的参数是指令本身的长度预算。经验上单条指令超过 1500 字之后模型对后半段的服从度会下降尤其是夹在中间的格式要求最容易被吃掉。所以长指令要分段治理核心约束前置示例单独放在最后中间用明确的分隔标记隔开。这不是玄学是上下文窗口里各段落的注意力分配问题血泪经验是——把最重要的三句话写在第一段和最后一段中间放素材。约束写完还要做一次反向检查把每条要求读一遍问自己「如果模型违反了我能一眼看出来吗」。看不出来的说明还没量化到位回去改。3. 场景化指令库设计新媒体运营、简历、面试、个人发展四条线的拆法3.1 内容运营线笔记、开头、标题、选题四个模板的拆法绿皮书里新媒体运营部分占了最大篇幅这不是偶然——内容生产是 Prompt 复用频率最高、也最容易标准化的场景。它给的四个模板分别对应内容生产链上的四个环节选题、标题、开头、成稿。这个切分方式值得学因为每个环节的输入输出边界都很清楚单独优化一个不会牵连其他。先看笔记成稿模板。原版写得很长我把它改写成带变量的版本去掉了具体平台名保留全部约束逻辑# 模板 ID: OPS-NOTE-01 | 场景: 图文种草笔记 | 版本: 1.2 你是一名【{{领域}}】方向的资深内容创作者在该领域有 3 年以上实操经验。 任务围绕主题「{{主题}}」产出一篇种草笔记面向【{{目标读者}}】 按四段输出标题 / 正文 / 行动呼唤 / 配图建议。 硬约束 1. 标题 18 到 24 字含 1 个阿拉伯数字含 1 个与主题强相关的搜索词 语气词不超过 1 个不得使用「震惊」「必看」类夸张词。 2. 正文 600 到 800 字分 3 到 4 段每段首句是小标题式短句 全篇表情符号 5 到 8 个只放在段首或句末不放在句子中间。 3. 正文结尾列出 3 到 5 个话题标签按相关度排序 需要提及账号时用【同领域账号类型】作为占位不要写具体账号名。 4. 行动呼唤绑定一个与主题强相关的资料诱饵「{{诱饵名称}}」 说明领取条件不得承诺收益、不得使用稀缺性话术。 5. 配图建议给 3 条画面描述 拍摄或制作要点 不要输出任何图片链接。 信息不足时先向我追问不要自行编造数据、案例或引用。逐条解释一下背后的取舍。第 1 条把「吸引人」拆成字数和数字「带数字」是标题模板里最稳的一条因为数字天然制造信息密度感而搜索词决定这篇内容能不能被检索到。第 3 条把账号名换成占位符是为了避免模型编造不存在的账号——这是我在实际项目里翻过车的地方模型很乐意给你一串看起来完全合理的账号名。第 5 条最关键不要向模型要图片链接。原文模板里写的是「尽量直接提供图片 URL」实践中这条几乎必然产出 404 或者张冠李戴的图正确做法是要画面描述由人来配图。开头模板走的是另一条路。绿皮书那套【BPKT】把好开头拆成七条引人入胜、简洁明了、视觉吸引、语言简练、制造悬念、突出价值、快节奏。七条里「视觉吸引」其实模型管不了那是拍摄环节的事真正能落到文本上的只有五条。所以我一般会把这类模板分成「模型负责的」和「人负责的」两栏避免模型对着做不到的要求硬编。标题模板【BPBT】同理留引人入胜、制造悬念、突出价值三条就够多写的部分只会稀释重点。选题模板最有意思它用的是两段式先问模型「我需要定义你哪些角色你才能更好帮我」让它自报十个身份——信息搜集者、趋势分析师、创意发想者、数据解读者、话题挖掘机、受众分析师、热点跟踪者、观点整合者、选题排序者等等第二轮再把这些身份固化进指令然后派活。这个套路的巧妙之处在于角色清单是模型自己列的它对这个角色集合的认同度更高后续输出也更贴。落地时我建议把自报的那一轮结果直接沉淀成模板第二次用就不用再问了。最后是写作风格模板【BPFG】。它的四条要求里真正起作用的是「用你不用您」和「结尾鼓励互动」这两条具体的。风格类指令的通病是太抽象解决办法是给一正一反两个短样本让模型照着仿写比写十条形容词管用。3.2 求职线简历与面试的指令结构差异简历和面试这两个场景绿皮书放在一起讲但它们的指令结构其实完全不同混着写会翻车。简历写作是「压缩型任务」输入是一大堆原始经历输出是高度凝练的几条要点。所以指令的核心是压缩规则和动词约束。# 模板 ID: JOB-RESUME-02 | 场景: 简历经历改写 | 版本: 1.1 你是招聘方视角的简历审阅者熟悉【{{岗位方向}}】的筛选标准。 输入 A. 目标岗位描述JD{{jd_text}} B. 我的原始经历{{raw_exp}} 任务从 B 中挑选与该 JD 最相关的 3 段经历改写成简历条目。 硬约束 1. 每条以动词开头控制在 40 到 60 字单条只讲一件事。 2. 至少 2 条包含可量化结果比例、数量、周期 我未提供的数据一律用【待补充】占位禁止推测。 3. 每条后面用一行小字标注它对应 JD 里的哪项要求。 4. 不要使用「负责」「参与」作为开头动词。 5. 输出后列出你认为我还缺哪 2 项关键信息。第 2 条和第 5 条是重点。模型在简历场景最大的风险是编数字写个「提升 30%」看起来毫无破绽面试一问就露馅所以必须用占位符强制它停下来。第 5 条则把模型从「执行者」变成「审阅者」让它主动指出信息缺口这一步往往比改写本身更有价值。面试准备是「展开型任务」输入是岗位和简历输出是问题清单、回答框架和追问链。这里的指令重点是覆盖度和追问深度我一般会要求「按专业能力、项目深挖、协作沟通、动机匹配四类各出 4 题每题给一个不超过 5 步的回答框架再给 2 个追问」。追问这一层是很多人漏掉的面试真正拉开差距的就是第二问、第三问让模型提前把追问链铺出来准备效率会高很多。3.3 个人发展线与通用沉淀把一次性对话变成可复用资产个人发展场景最容易被写成鸡汤指令什么「帮我规划三年职业路径」出来的东西看着热闹落不了地。真正有用的做法是把目标拆成可验证的阶段性动作并且在指令里写死「不要给建议只给下一步动作和判断标准」。更值得讲的是沉淀方法。绿皮书的价值不在于那几十条模板本身而在于它示范了怎么把一次成功的对话回溯成模板。我的做法是三步第一步翻回那次效果最好的对话标出哪几句是你临时加的——那些就是模板里的变量第二步找出无论什么主题都保持不变的部分——那些是骨架第三步把模型自由发挥得好的部分反过来写成约束条件。走完这三步一条一次性的好指令就变成了能重复用的资产。这套方法的效果在跨场景时最明显。你在内容场景里攒下的「先给方向再展开」「信息不足先追问」「不许编数字」这几条搬到简历、面试、方案写作里几乎原样能用。指令库真正的复利就在这里不在模板数量。3.4 指令库的目录与命名规范模板超过二十条之后靠记忆找模板就不现实了。我一般按「业务线-场景-序号」三段式编号配一张索引表维护。命名规范看着是小事但它是团队协作和版本回溯的前提没有它两周后你自己都分不清哪版是最新的。编号场景适用平台变量数版本回归用例OPS-NOTE-01图文笔记成稿通用41.2CASE-01OPS-OPEN-02短视频开场通用31.1CASE-02OPS-TITLE-03标题优化通用21.3CASE-03JOB-RESUME-02简历经历改写通用21.1CASE-04INT-VIEW-03面试问答通用31.0CASE-05DEV-PLAN-04阶段规划通用31.0CASE-06版本号规则建议用两位大版本改结构小版本改措辞。每次改完必须跑一遍对应的回归用例否则很容易出现「改好了 A 场景、改崩了 B 场景」的情况。4. 指令工程化落地从单条 Prompt 到可维护的指令仓4.1 用变量化模板替代复制粘贴模板写在文档里用的时候还是复制粘贴改文字那等于没做工程化。真正省事的做法是把模板和变量分开存用一个几十行的组装器在发出去之前把变量填进去。这一步看着多余实际能挡掉八成低级错误变量漏填、占位符忘删、平台参数没传。# prompt_builder.py —— 模板 变量 → 可直接发送的指令 from string import Template import re # 每个模板声明自己的必填变量缺一个就拒绝渲染不要发出半成品 TEMPLATES { OPS-NOTE-01: { required: [领域, 主题, 目标读者, 诱饵名称], body: open(templates/ops-note-01.txt, encodingutf-8).read(), }, JOB-RESUME-02: { required: [岗位方向, jd_text, raw_exp], body: open(templates/job-resume-02.txt, encodingutf-8).read(), }, } def render(tpl_id: str, params: dict) - str: tpl TEMPLATES.get(tpl_id) if not tpl: raise KeyError(f模板不存在: {tpl_id}) # 提前失败变量缺失时立刻报错而不是让模型去猜 missing [k for k in tpl[required] if not str(params.get(k, )).strip()] if missing: raise ValueError(f{tpl_id} 缺少必填变量: {missing}) # safe_substitute 不会因未定义变量抛异常适合有多平台可选参数的模板 out Template(tpl[body]).safe_substitute(params) # 渲染后清掉残留占位符避免模型把 {{xxx}} 当正文输出 return re.sub(r\{\{\w\}\}, , out) if __name__ __main__: prompt render(OPS-NOTE-01, { 领域: 求职技巧, 主题: 如何判断一份 offer 值不值得接, 目标读者: 工作三年以内的求职者, 诱饵名称: offer 评估清单, }) print(prompt[:200]) # 发出去前先肉眼扫一眼开头几处说明。required字段是关键设计模板越复杂越需要前置校验模型不会告诉你「你少填了一个变量」它只会按自己的理解补上补出来的东西通常还挺像样等你发现时已经用掉了一轮。safe_substitute和substitute的区别在于前者遇到未定义变量不报错适合有可选参数的模板但代价是可能留下占位符所以后面必须跟一次正则清理。打印开头 200 字这一步别省很多参数错位的问题肉眼一秒能看出来跑回归反而更慢。参数怎么改新增模板时只需往TEMPLATES里加一项把变量名写进required其余逻辑不动。如果你的模板用了$而不是{{ }}作为占位符注意Template默认认$两者混用会冲突选一种统一到底。4.2 版本管理与回归测试同一批用例怎么比对改模板最怕的不是改坏是改坏了还不知道。指令不像代码没有编译器帮你报错唯一的办法是准备一批固定用例每次改版都跑一遍看通过率是升是降。用例本身很轻一个 JSON 就够了输入参数、期望包含的段落标签、字数区间、必须出现的关键词、禁用词。打分也只需要四条硬指标先机器筛一遍人工只看没过的。# regress.py —— 四条硬指标先机器筛再人工看 def score(text: str, case: dict) - tuple[dict, float]: checks { # 结构完整性四段标签是否齐全 has_sections: all(s in text for s in case[sections]), # 长度合规字数落在预设区间内 length_ok: case[min_len] len(text) case[max_len], # 关键词覆盖核心搜索词命中数量达标 kw_hit: sum(k in text for k in case[keywords]) case[kw_need], # 禁用词绝对化表述、承诺性话术一个都不能有 no_banned: not any(b in text for b in case[banned]), } return checks, sum(checks.values()) / len(checks) CASE_01 { sections: [标题, 正文, 行动呼唤, 配图建议], min_len: 700, max_len: 1100, keywords: [offer, 薪资, 团队], kw_need: 2, banned: [保证, 最, 稳赚, 必看], }参数怎么定字数区间要按模板要求留出 10% 到 15% 的余量卡太死会误杀。关键词命中数取「必须覆盖」的那几个别把所有相关词都塞进去。禁用词表建议随项目积累每次发现一次翻车就加一条进去这张表会越来越值钱。这套做法的价值在于把主观判断变成趋势判断。单看一条输出你很难说 1.1 版和 1.2 版哪个好跑十条用例通过率从 60% 到 80%结论就清楚了。我之前带的一个项目就是靠这张表挡住了一次「优化措辞反而让格式全丢」的回归。4.3 平台差异适配同一套模板怎么跑在多个模型上绿皮书里明确说了这套方法不局限于某一个产品同类工具都能用。这话没错但落地时要注意差异直接照搬会踩坑。经验上主要差在三个地方差异点常见表现处理方式指令长度容忍度长指令在部分模型上后半段服从度下降核心约束前置超过 1200 字就拆成两轮结构化标记敏感度序号、分隔线、字段名在部分模型上识别更好用固定分隔符和显式字段名少用自然段罗列角色设定的持久性部分模型多轮后角色会淡化每 3 到 4 轮重贴一次角色和目标追问倾向有的模型爱追问有的直接开写在规则里显式写「信息不足先追问」实践做法是给同一份模板准备两个版本主版本保持完整七段式另一个精简版只留角色、目标、规则、工作流四段用于对长指令不友好的场景。两个版本共用同一套回归用例通过率差异一目了然。这里的判断标准不是哪个模型更强而是同一份模板在哪跑得稳你的方案就该以哪个为基准。5. 常见问题与避坑五类隐性翻车的排查路径5.1 结构漂移聊到第五轮格式全丢了现象第一轮输出的四段结构清清楚楚聊到第五轮模型开始写大段散文标题、行动呼唤全没了。原因多轮对话里上下文被稀释最早那条指令的权重随轮次下降。很多人以为是模型能力问题其实是自己没做锚定。解决两条。一是每轮开头重贴一次骨架只贴结构要求那三行不用整条重发二是在模板里用固定分隔符比如三个等号加段名让结构变成显式标记而不是隐含约定。我一般还会在每轮结尾加一句「下一轮仍按四段结构输出」把预期写死。5.2 指令膨胀写得越细模型反而抓不住重点现象模板从 400 字涨到 1800 字约束列了二十条输出质量反而下降最关键的格式要求经常被忽略。原因模型对长指令的服从不是均匀的中间段落最容易失效。约束一多互相之间还会打架比如同时要求「详细展开」和「控制在 300 字内」。解决做减法。把约束分三档——必须遵守的三条、尽量遵守的五条、参考性的若干条只把第一档放在指令开头和结尾其余降级为示例说明。互相冲突的要求要么删一条要么写清优先级。经验值是单条指令不超过 1200 字超过就拆成两轮第一轮定框架第二轮填内容。5.3 示例反噬给的例子被原样抄进输出现象为了让模型理解风格塞了一个完整示例结果输出跟示例高度雷同只换了两个名词。原因示例越完整模型越倾向于把它当模板复制尤其是内容型任务。这不是模型偷懒是指令没有区分「结构示例」和「内容示例」。解决示例只给结构不给完整内容。比如给「标题数字 痛点 结果」这样的骨架而不是给一个完整标题。如果必须给完整示例就在后面加一句「示例仅用于说明结构内容必须完全重写不得复用示例中的任何短语」。这一句看着笨实际很有效。5.4 事实编造要数据给数据要链接给链接现象要求模型「提供相关数据支持」或者「给出配图链接」输出里数据齐整、链接完整点开全是假的。原因这类要求超出了模型的能力边界它不会说「我不知道」而是按语言概率补一个看起来最合理的东西。绿皮书原版模板里就有「尽量直接提供图片 URL」这一条属于典型的踩坑点。解决把所有「需要外部事实」的要求改成占位或声明。要数据就要求「给出需要哪类数据、去哪里查」而不是要具体数字要图就要求画面描述和拍摄要点引用来源一律要求标注「待核实」。再加一条通用规则信息不足时先追问不要自行补全。5.5 跨平台失效换个模型同一模板全线崩现象一套模板在 A 产品上跑得好好的换到 B 产品格式乱、角色忘、追问变少。原因不同产品对角色设定、结构化标记、多轮记忆的处理方式不一样模板里的隐含约定在另一个环境里不成立。解决别追求「一套模板通吃」做双版本更实际。同时把平台无关的部分抽出来——任务定义、约束条件、输出结构这三块是通用的角色描述和初始化话术按平台各写一份。改版时先跑回归用例通过率不达标就不上线别凭感觉判断。6. 验收与答辩用一张评测表证明这套指令真的有效到了交付环节最怕的是被问一句「你怎么证明改完之后确实更好了」。凭感觉说「我觉得通顺多了」,在答辩场上撑不过一个追问。我的做法是准备一张评测表把主观判断压成几个可打分的维度每个维度给权重和通过线跑十条固定用例取平均。维度权重判定方式通过线结构完整性30%四段标签是否齐全10 条里 9 条通过长度与格式合规20%字数、段落数、标签数量平均达标率 90%内容相关性25%关键词覆盖 人工判相关性平均 4 分以上5 分制禁区命中15%禁用词、编造事实0 次可复用性10%换 3 个主题重跑是否稳定3 次中 2 次达标这张表有两个用法。做方案时用它自检哪一项不达标就回去改对应模块改完重跑答辩时用它做对比演示同一批用例分别跑旧指令和新指令把两列数字摆出来比讲十分钟原理有说服力。演示顺序我建议这样走先用一句话说清痛点同一主题十次输出十个样再展示七段式骨架然后现场跑一条指令最后把评测表摊开。现场跑的那条一定要提前试过选最稳的用例别拿边界情况赌。还有个小技巧答辩材料里留一栏「已知问题」。写清楚这套方案在哪些场景下不稳、为什么、下一步打算怎么改。评审最反感的不是有缺陷是装作没缺陷。主动交代边界反而显得你真的跑过。说个我自己的教训。早年交第一版方案时我把三十条模板整理得整整齐齐觉得工作量足够唬人结果被问「这三十条里哪几条是你验证过的」一条都答不上来。从那以后我每次交付指令类方案都强制走一遍「十条用例 一张评测表 一栏已知问题」的流程模板数量可以少验证记录一条不能缺。希望帮到你。本文还有配套的精品资源点击获取
简介《AI引擎Prompt指令设计绿皮书》面向希望系统掌握ChatGPT、Claude、Bard等对话式AI工具的创作者、运营人员与职场学习者重点解决指令表述含糊、输出质量波动、不同场景难以复用等问题。内容从Prompt写作方法切入讲解如何明确定义需求、补充对话上下文、限定输出格式与篇幅、提供示例、设置内容边界并通过多轮迭代逐步优化指令同时给出小红书笔记、短视频开头、简历写作、求职面试与个人发展等场景模板方便读者对照修改并积累自己的指令库。资源包共1个PDF文件大小约3.64MB结构集中、便于随时查阅。已有6756人学习下载可作为从入门到进阶的Prompt设计参考帮助读者提升与AI引擎的沟通效率和内容产出质量。1. 一个反直觉的现象模型没变指令一改输出就崩某同学拿着一份写好的简历让 AI 润色同一款人工智能工具早上给出的版本条理清楚下午再问一次就变成一堆形容词堆砌某团队的内容编辑天天写 Prompt 指令产出的笔记时好时坏谁也说不清哪一版能过审。这类 Prompt 指令设计问题九成不在模型参数而在指令本身需求含糊、上下文断裂、约束没量化、没有可回滚的模板。《AI 引擎Prompt 指令设计绿皮书》这套方案要解决的正是这件事——把「随手一问」变成有公式、有骨架、有场景库、有验收标准的指令资产让 AI 引擎的输出从碰运气变成可复现。它适合两类人做 AI 应用方向课设、毕设需要一份完整可交付设计文档的学生要给团队沉淀内容生产规范、需要能直接抄模板的从业者。下面按需求、设计、落地、避坑、验收五段把整套方案摊开讲。2. 指令质量的分层模型把「写得好」拆成七个可检查的要素2.1 七要素的职责与先后顺序绿皮书给出的七条原则很多人当成并列的清单写指令时随手挑几条用结果自然是时灵时不灵。我一般把它们分成三层来看前三条决定模型「听懂没」中间三条决定模型「做得对不对」最后一条决定这套指令「能不能稳定复现」。分层之后你会发现输出质量差往往不是模型不行而是某一层整个缺位。第一层是语义对齐明确定义需求、提供足够上下文、使用简单直白的语言。需求定义要直白到没有歧义比如「用简单的语言解释什么是区块链」而不是「聊聊区块链」。上下文这一条最容易被忽略——多轮对话里模型并不会自动记住你三小时前说过的背景你要在新指令里复述关键前提比如「我们之前讨论过人工智能的发展接下来请解释机器学习及其应用」。语言层面则要避免长定语和嵌套从句模型不需要你文采好只需要你指代清楚。第二层是交付控制详细说明要求、举例说明、添加限制条件。这一层直接决定输出的可用率。要求要落到格式、长度、语言风格三件事上「请以不超过 500 字的短文形式介绍孩子如何学习编程」就是一条合格的控制句。举例是性价比最高的手段给一到两个同类示例模型能迅速抓住你想要的风格和颗粒度。限制条件则是安全阀敏感主题、商业文案、对外发布的材料都要显式写明禁区。第三层是迭代优化。这条放在最后不是因为不重要恰恰是因为它是唯一需要在真实输出上做判断的环节。第一版结果不理想常见做法是按「补背景、加示例、拆步骤、改约束」四个方向依次试而不是简单粗暴地重发一遍。同一句话发十次拿到十种答案那不叫迭代叫抽奖。要素缺失时的典型症状自检问句明确定义需求回答正确但偏离目标换成新人他能看懂要交付什么吗提供上下文多轮后答非所问、前后矛盾这条指令单独拎出来还成立吗语言直白输出结构混乱、指代不清有没有超过 30 字的长句详细说明要求长度、格式每次都不一样字数、段落、风格写死了吗举例说明风格漂移越写越像通用模板有没有给一正一反两个样本限制条件出现不该出现的表述禁区列了几条多次迭代靠重发碰运气这一版改的是哪个变量把这七条当检查表用比当写作指南用更有效。我的习惯是每次模板定稿前逐条打分低于六项的模板不进正式库。2.2 模板骨架角色、资料、技能、目标、规则、工作流、初始化单条指令能解决一次性问题要复用就得有骨架。绿皮书里那套短视频脚本指令其实给出的是一个相当标准的七段式结构专家、资料、技能、目标、规则、工作流、初始化。这个顺序不是随便排的它对应「模型是谁 → 凭什么 → 会什么 → 干什么 → 不能干什么 → 怎么干 → 从哪开始」的推演链条。落成配置文件比写在对话框里更好维护也方便后面做变量替换。# prompt_skeleton.yaml —— 七段式通用指令骨架 role: # 角色定义模型身份与能力边界越窄越稳 name: 短视频脚本创作专家 scope: 只负责脚本结构、开场与文案不负责拍摄执行和投放策略 profile: # 资料版本、语言、能力描述便于溯源与回归对比 version: 1.0 language: 中文 description: 擅长开场设计与叙事节奏服务过泛知识类账号 skills: # 技能写可验证的能力不写形容词 - 撰写 60 秒以内的口播脚本单句不超过 25 字 - 用悬念或冲突设计前三秒开场 - 按标题、正文、标签、话题词四段输出 goals: # 目标交付物 成功标准 - 产出可直接开拍的脚本初稿 - 开场在 3 秒内建立信息差 rules: # 规则硬约束与禁区永远放在目标之后 - 不生成夸大功效、绝对化承诺的表述 - 不输出与主题无关的引流话术 - 信息不足时先追问不要自行补全事实 workflow: # 工作流输入 → 处理 → 输出三段式 - 接收主题、时长、目标人群三个输入 - 先给三种开场方向等我选定再展开 - 按四段结构输出成稿 init: 你好我是短视频脚本助手。请先告诉我主题、目标时长和面向人群。逐段说一下怎么改。role.scope是最值得花时间的地方把「不负责什么」写清楚比写十行「你很专业」有用得多。skills要写成能被检验的行为比如「单句不超过 25 字」可以数「擅长创作」没法数。rules放在goals后面是刻意的先让模型知道要交付什么再告诉它边界在哪如果规则写在最前面长指令里模型容易只记住禁令忘了任务。workflow里加一步「先给方向再展开」是我常用的降返工手段让模型先暴露理解偏差比写完一大篇再推翻省事。init这一段经常被跳过但它决定了首轮对话的质量。初始化时把追问清单说清楚模型第一句就会问你要主题和人群而不是直接开始编。提示骨架里的字段不是越多越好。角色、目标、规则、工作流这四段是必填其余可按场景裁剪。字段一多维护成本会超过收益。2.3 参数与约束怎么量化从「要吸引人」到可检查的数字新手写指令最常见的毛病是用形容词下命令标题要吸引人、正文要简洁、语气要专业。这些词在模型侧没有对应刻度输出自然随机。合格的写法是把每条要求翻译成能数、能查、能判定的参数。绿皮书里那条笔记指令就做对了大半「正文控制在 1000 字以内尽量在 600 到 800 字之间」「至少 5 个表情符号元素」「标题最好带数字」——这些都能一眼核验。维度模糊写法可检查写法长度正文要简洁正文 600 到 800 字分 3 到 4 段标题标题要吸引人标题 18 到 24 字含 1 个阿拉伯数字疑问句或冲突句二选一语气语言要专业使用「你」不用「您」单句不超过 30 字避免三个以上连续术语数量多加一些标签末尾给 3 到 5 个话题标签按相关度从高到低排结构分段写清楚固定四段标题、正文、行动呼唤、配图建议段前加序号禁区别写太夸张禁用「最」「第一」「保证」「稳赚」等绝对化词还有一个容易被忽略的参数是指令本身的长度预算。经验上单条指令超过 1500 字之后模型对后半段的服从度会下降尤其是夹在中间的格式要求最容易被吃掉。所以长指令要分段治理核心约束前置示例单独放在最后中间用明确的分隔标记隔开。这不是玄学是上下文窗口里各段落的注意力分配问题血泪经验是——把最重要的三句话写在第一段和最后一段中间放素材。约束写完还要做一次反向检查把每条要求读一遍问自己「如果模型违反了我能一眼看出来吗」。看不出来的说明还没量化到位回去改。3. 场景化指令库设计新媒体运营、简历、面试、个人发展四条线的拆法3.1 内容运营线笔记、开头、标题、选题四个模板的拆法绿皮书里新媒体运营部分占了最大篇幅这不是偶然——内容生产是 Prompt 复用频率最高、也最容易标准化的场景。它给的四个模板分别对应内容生产链上的四个环节选题、标题、开头、成稿。这个切分方式值得学因为每个环节的输入输出边界都很清楚单独优化一个不会牵连其他。先看笔记成稿模板。原版写得很长我把它改写成带变量的版本去掉了具体平台名保留全部约束逻辑# 模板 ID: OPS-NOTE-01 | 场景: 图文种草笔记 | 版本: 1.2 你是一名【{{领域}}】方向的资深内容创作者在该领域有 3 年以上实操经验。 任务围绕主题「{{主题}}」产出一篇种草笔记面向【{{目标读者}}】 按四段输出标题 / 正文 / 行动呼唤 / 配图建议。 硬约束 1. 标题 18 到 24 字含 1 个阿拉伯数字含 1 个与主题强相关的搜索词 语气词不超过 1 个不得使用「震惊」「必看」类夸张词。 2. 正文 600 到 800 字分 3 到 4 段每段首句是小标题式短句 全篇表情符号 5 到 8 个只放在段首或句末不放在句子中间。 3. 正文结尾列出 3 到 5 个话题标签按相关度排序 需要提及账号时用【同领域账号类型】作为占位不要写具体账号名。 4. 行动呼唤绑定一个与主题强相关的资料诱饵「{{诱饵名称}}」 说明领取条件不得承诺收益、不得使用稀缺性话术。 5. 配图建议给 3 条画面描述 拍摄或制作要点 不要输出任何图片链接。 信息不足时先向我追问不要自行编造数据、案例或引用。逐条解释一下背后的取舍。第 1 条把「吸引人」拆成字数和数字「带数字」是标题模板里最稳的一条因为数字天然制造信息密度感而搜索词决定这篇内容能不能被检索到。第 3 条把账号名换成占位符是为了避免模型编造不存在的账号——这是我在实际项目里翻过车的地方模型很乐意给你一串看起来完全合理的账号名。第 5 条最关键不要向模型要图片链接。原文模板里写的是「尽量直接提供图片 URL」实践中这条几乎必然产出 404 或者张冠李戴的图正确做法是要画面描述由人来配图。开头模板走的是另一条路。绿皮书那套【BPKT】把好开头拆成七条引人入胜、简洁明了、视觉吸引、语言简练、制造悬念、突出价值、快节奏。七条里「视觉吸引」其实模型管不了那是拍摄环节的事真正能落到文本上的只有五条。所以我一般会把这类模板分成「模型负责的」和「人负责的」两栏避免模型对着做不到的要求硬编。标题模板【BPBT】同理留引人入胜、制造悬念、突出价值三条就够多写的部分只会稀释重点。选题模板最有意思它用的是两段式先问模型「我需要定义你哪些角色你才能更好帮我」让它自报十个身份——信息搜集者、趋势分析师、创意发想者、数据解读者、话题挖掘机、受众分析师、热点跟踪者、观点整合者、选题排序者等等第二轮再把这些身份固化进指令然后派活。这个套路的巧妙之处在于角色清单是模型自己列的它对这个角色集合的认同度更高后续输出也更贴。落地时我建议把自报的那一轮结果直接沉淀成模板第二次用就不用再问了。最后是写作风格模板【BPFG】。它的四条要求里真正起作用的是「用你不用您」和「结尾鼓励互动」这两条具体的。风格类指令的通病是太抽象解决办法是给一正一反两个短样本让模型照着仿写比写十条形容词管用。3.2 求职线简历与面试的指令结构差异简历和面试这两个场景绿皮书放在一起讲但它们的指令结构其实完全不同混着写会翻车。简历写作是「压缩型任务」输入是一大堆原始经历输出是高度凝练的几条要点。所以指令的核心是压缩规则和动词约束。# 模板 ID: JOB-RESUME-02 | 场景: 简历经历改写 | 版本: 1.1 你是招聘方视角的简历审阅者熟悉【{{岗位方向}}】的筛选标准。 输入 A. 目标岗位描述JD{{jd_text}} B. 我的原始经历{{raw_exp}} 任务从 B 中挑选与该 JD 最相关的 3 段经历改写成简历条目。 硬约束 1. 每条以动词开头控制在 40 到 60 字单条只讲一件事。 2. 至少 2 条包含可量化结果比例、数量、周期 我未提供的数据一律用【待补充】占位禁止推测。 3. 每条后面用一行小字标注它对应 JD 里的哪项要求。 4. 不要使用「负责」「参与」作为开头动词。 5. 输出后列出你认为我还缺哪 2 项关键信息。第 2 条和第 5 条是重点。模型在简历场景最大的风险是编数字写个「提升 30%」看起来毫无破绽面试一问就露馅所以必须用占位符强制它停下来。第 5 条则把模型从「执行者」变成「审阅者」让它主动指出信息缺口这一步往往比改写本身更有价值。面试准备是「展开型任务」输入是岗位和简历输出是问题清单、回答框架和追问链。这里的指令重点是覆盖度和追问深度我一般会要求「按专业能力、项目深挖、协作沟通、动机匹配四类各出 4 题每题给一个不超过 5 步的回答框架再给 2 个追问」。追问这一层是很多人漏掉的面试真正拉开差距的就是第二问、第三问让模型提前把追问链铺出来准备效率会高很多。3.3 个人发展线与通用沉淀把一次性对话变成可复用资产个人发展场景最容易被写成鸡汤指令什么「帮我规划三年职业路径」出来的东西看着热闹落不了地。真正有用的做法是把目标拆成可验证的阶段性动作并且在指令里写死「不要给建议只给下一步动作和判断标准」。更值得讲的是沉淀方法。绿皮书的价值不在于那几十条模板本身而在于它示范了怎么把一次成功的对话回溯成模板。我的做法是三步第一步翻回那次效果最好的对话标出哪几句是你临时加的——那些就是模板里的变量第二步找出无论什么主题都保持不变的部分——那些是骨架第三步把模型自由发挥得好的部分反过来写成约束条件。走完这三步一条一次性的好指令就变成了能重复用的资产。这套方法的效果在跨场景时最明显。你在内容场景里攒下的「先给方向再展开」「信息不足先追问」「不许编数字」这几条搬到简历、面试、方案写作里几乎原样能用。指令库真正的复利就在这里不在模板数量。3.4 指令库的目录与命名规范模板超过二十条之后靠记忆找模板就不现实了。我一般按「业务线-场景-序号」三段式编号配一张索引表维护。命名规范看着是小事但它是团队协作和版本回溯的前提没有它两周后你自己都分不清哪版是最新的。编号场景适用平台变量数版本回归用例OPS-NOTE-01图文笔记成稿通用41.2CASE-01OPS-OPEN-02短视频开场通用31.1CASE-02OPS-TITLE-03标题优化通用21.3CASE-03JOB-RESUME-02简历经历改写通用21.1CASE-04INT-VIEW-03面试问答通用31.0CASE-05DEV-PLAN-04阶段规划通用31.0CASE-06版本号规则建议用两位大版本改结构小版本改措辞。每次改完必须跑一遍对应的回归用例否则很容易出现「改好了 A 场景、改崩了 B 场景」的情况。4. 指令工程化落地从单条 Prompt 到可维护的指令仓4.1 用变量化模板替代复制粘贴模板写在文档里用的时候还是复制粘贴改文字那等于没做工程化。真正省事的做法是把模板和变量分开存用一个几十行的组装器在发出去之前把变量填进去。这一步看着多余实际能挡掉八成低级错误变量漏填、占位符忘删、平台参数没传。# prompt_builder.py —— 模板 变量 → 可直接发送的指令 from string import Template import re # 每个模板声明自己的必填变量缺一个就拒绝渲染不要发出半成品 TEMPLATES { OPS-NOTE-01: { required: [领域, 主题, 目标读者, 诱饵名称], body: open(templates/ops-note-01.txt, encodingutf-8).read(), }, JOB-RESUME-02: { required: [岗位方向, jd_text, raw_exp], body: open(templates/job-resume-02.txt, encodingutf-8).read(), }, } def render(tpl_id: str, params: dict) - str: tpl TEMPLATES.get(tpl_id) if not tpl: raise KeyError(f模板不存在: {tpl_id}) # 提前失败变量缺失时立刻报错而不是让模型去猜 missing [k for k in tpl[required] if not str(params.get(k, )).strip()] if missing: raise ValueError(f{tpl_id} 缺少必填变量: {missing}) # safe_substitute 不会因未定义变量抛异常适合有多平台可选参数的模板 out Template(tpl[body]).safe_substitute(params) # 渲染后清掉残留占位符避免模型把 {{xxx}} 当正文输出 return re.sub(r\{\{\w\}\}, , out) if __name__ __main__: prompt render(OPS-NOTE-01, { 领域: 求职技巧, 主题: 如何判断一份 offer 值不值得接, 目标读者: 工作三年以内的求职者, 诱饵名称: offer 评估清单, }) print(prompt[:200]) # 发出去前先肉眼扫一眼开头几处说明。required字段是关键设计模板越复杂越需要前置校验模型不会告诉你「你少填了一个变量」它只会按自己的理解补上补出来的东西通常还挺像样等你发现时已经用掉了一轮。safe_substitute和substitute的区别在于前者遇到未定义变量不报错适合有可选参数的模板但代价是可能留下占位符所以后面必须跟一次正则清理。打印开头 200 字这一步别省很多参数错位的问题肉眼一秒能看出来跑回归反而更慢。参数怎么改新增模板时只需往TEMPLATES里加一项把变量名写进required其余逻辑不动。如果你的模板用了$而不是{{ }}作为占位符注意Template默认认$两者混用会冲突选一种统一到底。4.2 版本管理与回归测试同一批用例怎么比对改模板最怕的不是改坏是改坏了还不知道。指令不像代码没有编译器帮你报错唯一的办法是准备一批固定用例每次改版都跑一遍看通过率是升是降。用例本身很轻一个 JSON 就够了输入参数、期望包含的段落标签、字数区间、必须出现的关键词、禁用词。打分也只需要四条硬指标先机器筛一遍人工只看没过的。# regress.py —— 四条硬指标先机器筛再人工看 def score(text: str, case: dict) - tuple[dict, float]: checks { # 结构完整性四段标签是否齐全 has_sections: all(s in text for s in case[sections]), # 长度合规字数落在预设区间内 length_ok: case[min_len] len(text) case[max_len], # 关键词覆盖核心搜索词命中数量达标 kw_hit: sum(k in text for k in case[keywords]) case[kw_need], # 禁用词绝对化表述、承诺性话术一个都不能有 no_banned: not any(b in text for b in case[banned]), } return checks, sum(checks.values()) / len(checks) CASE_01 { sections: [标题, 正文, 行动呼唤, 配图建议], min_len: 700, max_len: 1100, keywords: [offer, 薪资, 团队], kw_need: 2, banned: [保证, 最, 稳赚, 必看], }参数怎么定字数区间要按模板要求留出 10% 到 15% 的余量卡太死会误杀。关键词命中数取「必须覆盖」的那几个别把所有相关词都塞进去。禁用词表建议随项目积累每次发现一次翻车就加一条进去这张表会越来越值钱。这套做法的价值在于把主观判断变成趋势判断。单看一条输出你很难说 1.1 版和 1.2 版哪个好跑十条用例通过率从 60% 到 80%结论就清楚了。我之前带的一个项目就是靠这张表挡住了一次「优化措辞反而让格式全丢」的回归。4.3 平台差异适配同一套模板怎么跑在多个模型上绿皮书里明确说了这套方法不局限于某一个产品同类工具都能用。这话没错但落地时要注意差异直接照搬会踩坑。经验上主要差在三个地方差异点常见表现处理方式指令长度容忍度长指令在部分模型上后半段服从度下降核心约束前置超过 1200 字就拆成两轮结构化标记敏感度序号、分隔线、字段名在部分模型上识别更好用固定分隔符和显式字段名少用自然段罗列角色设定的持久性部分模型多轮后角色会淡化每 3 到 4 轮重贴一次角色和目标追问倾向有的模型爱追问有的直接开写在规则里显式写「信息不足先追问」实践做法是给同一份模板准备两个版本主版本保持完整七段式另一个精简版只留角色、目标、规则、工作流四段用于对长指令不友好的场景。两个版本共用同一套回归用例通过率差异一目了然。这里的判断标准不是哪个模型更强而是同一份模板在哪跑得稳你的方案就该以哪个为基准。5. 常见问题与避坑五类隐性翻车的排查路径5.1 结构漂移聊到第五轮格式全丢了现象第一轮输出的四段结构清清楚楚聊到第五轮模型开始写大段散文标题、行动呼唤全没了。原因多轮对话里上下文被稀释最早那条指令的权重随轮次下降。很多人以为是模型能力问题其实是自己没做锚定。解决两条。一是每轮开头重贴一次骨架只贴结构要求那三行不用整条重发二是在模板里用固定分隔符比如三个等号加段名让结构变成显式标记而不是隐含约定。我一般还会在每轮结尾加一句「下一轮仍按四段结构输出」把预期写死。5.2 指令膨胀写得越细模型反而抓不住重点现象模板从 400 字涨到 1800 字约束列了二十条输出质量反而下降最关键的格式要求经常被忽略。原因模型对长指令的服从不是均匀的中间段落最容易失效。约束一多互相之间还会打架比如同时要求「详细展开」和「控制在 300 字内」。解决做减法。把约束分三档——必须遵守的三条、尽量遵守的五条、参考性的若干条只把第一档放在指令开头和结尾其余降级为示例说明。互相冲突的要求要么删一条要么写清优先级。经验值是单条指令不超过 1200 字超过就拆成两轮第一轮定框架第二轮填内容。5.3 示例反噬给的例子被原样抄进输出现象为了让模型理解风格塞了一个完整示例结果输出跟示例高度雷同只换了两个名词。原因示例越完整模型越倾向于把它当模板复制尤其是内容型任务。这不是模型偷懒是指令没有区分「结构示例」和「内容示例」。解决示例只给结构不给完整内容。比如给「标题数字 痛点 结果」这样的骨架而不是给一个完整标题。如果必须给完整示例就在后面加一句「示例仅用于说明结构内容必须完全重写不得复用示例中的任何短语」。这一句看着笨实际很有效。5.4 事实编造要数据给数据要链接给链接现象要求模型「提供相关数据支持」或者「给出配图链接」输出里数据齐整、链接完整点开全是假的。原因这类要求超出了模型的能力边界它不会说「我不知道」而是按语言概率补一个看起来最合理的东西。绿皮书原版模板里就有「尽量直接提供图片 URL」这一条属于典型的踩坑点。解决把所有「需要外部事实」的要求改成占位或声明。要数据就要求「给出需要哪类数据、去哪里查」而不是要具体数字要图就要求画面描述和拍摄要点引用来源一律要求标注「待核实」。再加一条通用规则信息不足时先追问不要自行补全。5.5 跨平台失效换个模型同一模板全线崩现象一套模板在 A 产品上跑得好好的换到 B 产品格式乱、角色忘、追问变少。原因不同产品对角色设定、结构化标记、多轮记忆的处理方式不一样模板里的隐含约定在另一个环境里不成立。解决别追求「一套模板通吃」做双版本更实际。同时把平台无关的部分抽出来——任务定义、约束条件、输出结构这三块是通用的角色描述和初始化话术按平台各写一份。改版时先跑回归用例通过率不达标就不上线别凭感觉判断。6. 验收与答辩用一张评测表证明这套指令真的有效到了交付环节最怕的是被问一句「你怎么证明改完之后确实更好了」。凭感觉说「我觉得通顺多了」,在答辩场上撑不过一个追问。我的做法是准备一张评测表把主观判断压成几个可打分的维度每个维度给权重和通过线跑十条固定用例取平均。维度权重判定方式通过线结构完整性30%四段标签是否齐全10 条里 9 条通过长度与格式合规20%字数、段落数、标签数量平均达标率 90%内容相关性25%关键词覆盖 人工判相关性平均 4 分以上5 分制禁区命中15%禁用词、编造事实0 次可复用性10%换 3 个主题重跑是否稳定3 次中 2 次达标这张表有两个用法。做方案时用它自检哪一项不达标就回去改对应模块改完重跑答辩时用它做对比演示同一批用例分别跑旧指令和新指令把两列数字摆出来比讲十分钟原理有说服力。演示顺序我建议这样走先用一句话说清痛点同一主题十次输出十个样再展示七段式骨架然后现场跑一条指令最后把评测表摊开。现场跑的那条一定要提前试过选最稳的用例别拿边界情况赌。还有个小技巧答辩材料里留一栏「已知问题」。写清楚这套方案在哪些场景下不稳、为什么、下一步打算怎么改。评审最反感的不是有缺陷是装作没缺陷。主动交代边界反而显得你真的跑过。说个我自己的教训。早年交第一版方案时我把三十条模板整理得整整齐齐觉得工作量足够唬人结果被问「这三十条里哪几条是你验证过的」一条都答不上来。从那以后我每次交付指令类方案都强制走一遍「十条用例 一张评测表 一栏已知问题」的流程模板数量可以少验证记录一条不能缺。希望帮到你。本文还有配套的精品资源点击获取
