设想你走进一家口碑极好的私房菜馆，大厨手艺一流，却有一个怪癖：从不主动揣测你的心思，你说什么，他就做什么。你说“随便来点好吃的”，他端上来的可能是一盘你碰都不碰的香菜拌折耳根；你说“来份番茄炒蛋，少油少盐，不要葱花，半小时内上桌”，他就能一次做出让你竖起大拇指的菜。这家菜馆就是今天的大语言模型，那张“点菜单”就是提示词（Prompt）。Prompt 设计原则，正是教你写好这张点菜单的学问：如何把需求说清楚、怎么告诉大厨你希望他以什么身份来做、划清哪些不能碰的红线、把常用菜单固化成模板反复复用，以及上桌后如何通过测试迭代让味道越来越好。 这篇文章会用这套点菜逻辑，带你零基础掌握 Prompt 设计原则与工程规范。你不需要懂任何数学或代码背景，只需要跟着“大厨做菜”这条故事线，就能理解 AI 应用开发者每天都在研究的提示词工程。

岗位关联

对 AI 应用开发者、技术团队和产品经理而言，掌握 Prompt 设计原则意味着能用最少的 token 成本换来最稳定、最可控的模型输出，把“看运气”的 AI 交互变成可测试、可复用、可迭代的工程能力。

目录
  1. 可视化演示
  2. 核心设计原则
  3. 角色设定法
  4. 约束条件书写
  5. 模板复用
  6. 测试与迭代
  7. 工程规范
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Prompt设计的三大核心原则、结构化模板构建流程与测试迭代闭环，帮助建立系统化的Prompt工程规范。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Prompt三大设计原则 清晰性：指令明确无歧义，模型能准确理解任务目标 具体性：提供充足上下文与示例，减少模糊空间 质量 = f（清晰，具体，可验） 可验证性确保输出可量化评估

核心设计原则

你第一次走进那家私房菜馆，服务员递过菜单，你随口说“随便来点好吃的”——大厨端上来一碗你最讨厌的香菜。第二次你学乖了，说要点番茄炒蛋，但他不知道你要咸口还是甜口、要不要辣、几个人吃。直到你说：“来一份番茄炒蛋，两人份，少油少盐，微辣，不要葱，30 分钟内上桌。”他一次就做对了。区别不在菜本身，而在于你写的点菜单是否够清楚。

大语言模型本质上就是那位“才华横溢但不读心”的大厨。它见过海量文本知识，却没有任何读心术，只能根据你给出的文字推测意图。Prompt 设计的第一条主线，就是让指令具备三个核心属性：清晰性（clarity）、具体性（specificity）、可验证性（verifiability）。清晰指任务目标没有歧义，“写个文案”远不如“写一段 50 字以内的朋友圈文案”；具体指给出情境、对象、载体等关键信息，“介绍产品”远不如“用比喻向 40 岁的家庭主妇介绍这款豆浆机”；可验证指输出能被客观检查，“至少列出 3 个理由”“每条不超过 20 字”“结尾附对比表格”都是可验证的描述。

三者可以量化为一个简易评分模型：给每条提示词的清晰度、具体度、可验证度分别打分（0～1），再按你的业务侧重配权重，加权求和就是这条提示词的质量分。质量分高，说明“一次做对”的概率大。

记住那张点菜单：清晰是“不要香菜”这种无歧义的短句，具体是“两人份、微辣”这种可执行的细节，可验证是“30 分钟上桌”这种能掐表检查的承诺。三把尺子量一遍，大厨几乎不可能端错菜。

Q=wc×C+ws×S+wv×V\displaystyle Q = w_c \times C + w_s \times S + w_v \times V
  1. 质量总分 Q整条提示词的文本质量得分，取值通常在 0～1 之间，得分越高说明越接近“一次做对”。
    Q\displaystyle Q
  2. 清晰度权重项 w_c×CC 表示清晰度评分（0～1），w_c 是它的权重，比如你设 w_c=0.4，说明你最怕产生歧义。
    wc×C\displaystyle w_c \times C
  3. 具体度权重项 w_s×SS 表示具体度评分，w_s 是权重。给足情境与细节，大厨才知道往哪个方向发挥而不跑偏。
    ws×S\displaystyle w_s \times S
  4. 可验证度权重项 w_v×VV 表示可验证度评分，w_v 是权重。输出能否被客观检查，决定了你后续做测试时是否容易。
    wv×V\displaystyle w_v \times V

角色设定法

同一道番茄炒蛋，你告诉大厨“按家常做法”，他会做出你妈妈的味道；你说“请以五星级酒店主厨的身份来设计”，他会开始考虑摆盘和层次感；你补一句“我口味偏清淡，是第一次吃这道菜的外地人”，他会放弃重油改走温和路线。同样一个大厨、同样一道菜，只因“身份设定”不同，出品风格截然不同。

大模型在训练时接触了大量不同身份、不同场景的文本，因此“角色”是它切换知识范围与语言风格的开关。在 Prompt 中显式声明角色，相当于给模型安装了一个“视角滤镜”，这就是角色设定法（Role Prompting）。一个完整的角色设定通常包含四件事：角色定义（“你是一名资深英文校对”）、知识范围（“只依据我提供的产品资料回答，不引用外部数据”）、输出风格（“用正式书面语，不使用表情符号”）、身份一致（“全程保持该身份，不要跳出角色解释你是 AI”）。角色设定不是装饰性客套话，它直接改变模型从参数空间中检索知识的路径，相当于告诉大厨“今天你按哪个菜系、哪套标准来掌勺”。

下次点菜时别只报菜名，先说清“我是谁、希望你以谁的标准来做”。给大厨一个身份，比催促他一百遍“做好吃一点”更管用。

Y=fθ(R,  T,  E)\displaystyle Y = f_{\theta}\left(R,\; T,\; E\right)
  1. 输出 Y模型最终生成的回答文本，就是那道“上桌的菜”。
    Y\displaystyle Y
  2. 模型能力 f_θθ 代表大模型的数十亿级参数，它决定了模型“厨艺”的天花板，但具体如何发挥由输入决定。
    fθ\displaystyle f_{\theta}
  3. 角色 R你在开头设定的身份，如“资深文案编辑”，它让模型进入对应的知识子空间，切换说话的腔调。
    R\displaystyle R
  4. 任务 T 与范例 ET 是具体要完成的事，E 是给的一两个范例（few-shot），相当于告诉大厨“上次这样做就很好”。
    T,  E\displaystyle T,\; E

约束条件书写

你在点菜单上写“多加辣”，大厨照做了，结果你被辣哭——因为没写“辣度控制在微辣”。写“不要香菜”，他确实没放香菜，却放了一把你同样讨厌的芹菜。约束条件就是厨房墙上挂的“红线清单”：白纸黑字写明哪些不能碰、输出长什么样、边界在哪里。没有红线的点菜单，等于把自由发挥权全交给了大厨。

约束条件（Constraints）是 Prompt 中限定输出范围的指令，包括四类：边界限定（“仅基于以下文本回答”）、格式要求（“用 Markdown 表格输出”）、禁止事项（“不得提供法律建议”）、长度控制（“不超过 200 字”）。约束写得越明确，模型的自由度越小，输出越可控。需要特别注意的是，负面指令（“不要……”）威力有限，因为模型并不真正执行“取反”逻辑，它只是在概率上避开某些词。更稳妥的做法是“正面规定 + 强格式约束”：与其说“不要啰嗦”，不如说“每段不超过 3 句”；与其说“不要编造”，不如要求“每一步附数据来源”。你可以用一个完备度公式检查四类约束是否齐全，任何一类缺失，整条约束体系都视为不合格。

就像在点菜单背面印上“厨房红线”：不放香菜、微辣、20 分钟内、必须热盘上桌。四条红线写全，大厨的自由发挥就被锁进了安全区，出错的概率大幅下降。

M=mboundary×mformat×mforbid×mlength\displaystyle M = m_{\text{boundary}} \times m_{\text{format}} \times m_{\text{forbid}} \times m_{\text{length}}
  1. 约束完备度 M整体约束是否覆盖四个维度，取值为 0 或 1，任何一项缺失，乘出来的结果直接归零。
    M\displaystyle M
  2. 边界项 m_boundary是否声明了回答的信息来源边界，例如“仅依据文档回答”，防止大厨自由发挥。
    mboundary\displaystyle m_{\text{boundary}}
  3. 格式项 m_format是否指定了输出的结构，例如标题、表格、编号列表，让结果便于解析与排版。
    mformat\displaystyle m_{\text{format}}
  4. 禁止项 m_forbid是否列明禁区，例如“不得给出投资建议”，明确告知哪些事绝对不能做。
    mforbid\displaystyle m_{\text{forbid}}
  5. 长度项 m_length是否限制了字数或篇幅，例如“正文 300 字以内”，把成本的缰绳握在自己手里。
    mlength\displaystyle m_{\text{length}}

模板复用

常客发现，每次手写点菜单太累，而且不同服务员转述容易走样。于是菜馆干脆印了一批“标准点菜单”：菜名、口味、辣度、忌口、期望时间都是空栏，客人只需勾选填数。填空的过程快、一致、不容易漏项。如果某道菜改进了做法，就把旧表单作废，发新版。Prompt 工程也是一样：把验证过的高质量提示词固化成模板，让团队里的每个人都在同一张“表单”上填空。

在工程实践中，Prompt 模板（Prompt Template）就是把高质量提示词固化成“填空表单”。模板由固定指令段和占位符（Placeholder）组成，运行时用真实参数替换占位符。复用模板能统一团队的提示词标准，降低每次编写的心智负担。一个规范的模板结构通常包含：角色声明段、任务描述段、约束列表段、示例段、输出格式段，各段之间用清晰的分隔符（如 ### 或 XML 标签）隔开。占位符要语义化命名，如 {{product_name}}、{{target_audience}}。版本管理建议遵循语义化版本号：1.0.0 → 1.1.0 表示功能增强，2.0.0 表示破坏性修改，并配套 changelog 记录每次改了什么、为什么改。

标准点菜单让每位新客人都能在一分钟内点好菜，还防止服务员记错。团队里每人维护一份带版本号的 Prompt 模板库，效果也一样：稳定、一致、可回溯，换任何一个人来填空，出品都不走样。

Pfinal=render⁡(Ttpl,  ⋃i=1n{ki:vi})\displaystyle P_{\text{final}} = \operatorname{render}\left(T_{\text{tpl}},\; \bigcup_{i=1}^{n} \{k_i : v_i\}\right)
  1. 最终提示词 P_final模板渲染后真正发送给模型的完整文本，也就是最后那张写满答案的点菜单。
    Pfinal\displaystyle P_{\text{final}}
  2. 渲染函数 render把占位符替换成实际值的运算，本质就是一次字符串替换，把空栏填上内容。
    render⁡\displaystyle \operatorname{render}
  3. 模板本体 T_tpl包含固定指令与占位符的模板文本，固定部分是经过验证的“框架”，不可随意改动。
    Ttpl\displaystyle T_{\text{tpl}}
  4. 键值对集合并集一组参数映射，如 {product_name: “豆浆机”}，一个占位符对应一个值，缺一个模板就填不完整。
    ⋃i=1n{ki:vi}\displaystyle \bigcup_{i=1}^{n} \{k_i : v_i\}

测试与迭代

菜端上来了，你尝了一口，发现盐放多了。你不会掀桌子，而是对服务员说：“请回锅加一小勺糖去咸，另外汤里别放姜。”大厨照着调整，第二版终于完美。这就是测试迭代：把每一版菜当作可评审的版本，给出具体的、可执行的反馈，一轮轮逼近满意。Prompt 很少能一次写对，高手与新手的分水岭，往往在于谁会系统地迭代。

正规做法是建立“测试用例集”——一组覆盖典型场景的输入输出对，像单元测试一样运行。每次修改 Prompt 后，在同一组用例上回归，对比新旧版本的输出质量，这叫对比评估。发现问题后要分析失败原因：是格式漂移、信息缺失，还是越界发挥？然后针对性修改，再回归。评估分数可以由两部分组成：客观规则分（格式是否符合、关键词是否缺失）加上人工评分（语气、逻辑是否自然）。每次迭代都计算新旧版本在固定用例集上的平均分差，只有正收益的改动才值得合并进正式模板。测试用例要兼顾正常场景和边界场景：超长输入、敏感词、空值，一样都不能少。

回锅、试吃、再回锅——一道菜稳定下来通常要三四轮。Prompt 迭代也是这样：先有基线，再改，再测，用数字而不是感觉决定这次改动留还是不留。每一次“回锅”都要有具体改法，正如每一版 Prompt 都要有明确的修改理由。

Δ=1n∑i=1nsinew−1n∑i=1nsiold\displaystyle \Delta = \frac{1}{n}\sum_{i=1}^{n} s_i^{\text{new}} - \frac{1}{n}\sum_{i=1}^{n} s_i^{\text{old}}
  1. 迭代增量 Δ新版与旧版在同一套用例上的平均得分之差，正数说明这次改动确实有效。
    Δ\displaystyle \Delta
  2. 新版平均分把新版 Prompt 在 n 个用例上的得分 s_i^new 求和再取平均，代表新版整体水平。
    1n∑i=1nsinew\displaystyle \frac{1}{n}\sum_{i=1}^{n} s_i^{\text{new}}
  3. 旧版平均分旧版本在同一批用例上的平均得分，作为对比的基线（baseline）。
    1n∑i=1nsiold\displaystyle \frac{1}{n}\sum_{i=1}^{n} s_i^{\text{old}}
  4. 用例数 n测试用例集的大小，n 越大，评估结果越可信，偶然性越小。
    n\displaystyle n

工程规范

菜馆火了，每天几百桌客人，不能再靠大厨临场发挥。老板开始立规矩：复杂的菜拆成备料、烹饪、装盘三道工序；每道菜核算固定成本；所有客人的忌口统一登记；后厨保留每个版本的菜单台账。这样即便换了新厨师，出品依然稳定。Prompt 工程进入团队协作阶段，也需要同样的规矩。

工程规范是把 Prompt 设计从“个人手艺”升级为“团队流水线”的保障，主要包括四个方面。任务分解：把复杂任务拆成多个子 Prompt（如先规划、再改写、最后润色），降低单次输出的失误率，就像大菜拆工序一样。成本控制：用 token 估算每次调用的费用，控制 Prompt 长度与调用次数，给每个模块设 token 预算。用户沟通：面向非技术用户时，把 Prompt 封装成表单或按钮，用户只需要点选，不接触原始模板。隐私合规：不把敏感信息写进模板，日志做脱敏处理，避免用户数据进入不可控的传输链路。一次完整的第三方模型调用费用，可以按下面的公式估算，模板固定部分加上变量输入部分都会消耗 token，都要计入预算。

就像饭店的标准化流水线，Prompt 工程规范把“大厨的手艺”沉淀为“餐厅的制度”：分解工序、核算成本、登记忌口、保存菜单台账。做到这四件事，AI 应用才能从一个人的灵感变成一家公司的稳定出品。

Cost=Ntoken×Ptoken×Ncalls\displaystyle \mathrm{Cost} = N_{\text{token}} \times P_{\text{token}} \times N_{\text{calls}}
  1. 总成本 Cost一段时间内调用该 Prompt 的总花费，单位是元，是工程上要定期核算的指标。
    Cost\displaystyle \mathrm{Cost}
  2. Token 消耗 N_token单次请求消耗的 token 数量，中文汉字约为“汉字数×1.7”，英文单词约为“单词数×1.3”。
    Ntoken\displaystyle N_{\text{token}}
  3. 单价 P_token每千 token 的价格，由模型供应商定价，不同模型差异很大，选型时要对比。
    Ptoken\displaystyle P_{\text{token}}
  4. 调用次数 N_calls单位时间内的请求次数，三者相乘即总成本，任何一个乘数翻倍，成本就跟着翻倍。
    Ncalls\displaystyle N_{\text{calls}}

AI 应用场景

智能客服的 Prompt 规范池

阶段：提示词工程（角色设定 + 约束条件 + 模板复用）

解决的问题：传统客服机器人使用松散 prompt，“自由度”太高导致回答风格飘忽、甚至超纲承诺。通过角色设定（“资深客服专员”）、约束条件（“仅依据知识库回答，不承诺赔付”）和模板复用，输出变得稳定可控，就像给大厨规定了菜系和红线。

具体案例：某电商售后团队建立 20 个 prompt 模板（退款咨询、物流查询、发票申请等），每个模板带占位符和版本号，每次发版前用测试用例集回归，答非所问率从 18% 降到 4%。

内容团队的统一文案模板

阶段：模板复用 + 版本管理

解决的问题：市场部五个文案各自写 prompt，风格不一、效果看运气。把优秀的 prompt 固化为模板库，配合占位符（产品名、卖点、平台），新员工也能产出合格的投放文案，相当于把“老师傅的点菜单”印成标准表单。

具体案例：某 SaaS 公司用“角色 + 任务 + 示例 + 格式”四段模板生成小红书种草文，模板 v1.2 在 100 条用例上通过率 91%，随即写入部门内容生产规范。

Prompt 回归测试平台

阶段：测试与迭代

解决的问题：模型升级或系统改版后，老 prompt 可能悄悄失效。建立 prompt 测试平台，定期用固定用例集回归，自动输出质量分变化报告，分数掉点就预警，就像定期让老顾客回店试菜，确保味道没有变。

具体案例：某金融问答机器人每月对 300 条用例自动回归，覆盖空输入、敏感词、超长问题等边界场景，基线分掉点超过 5% 即触发人工 review，曾在一次模型升级后提前三天发现格式漂移问题。

Python 演示

python57 行
# -*- coding: utf-8 -*-"""Prompt template rendering and quality scoring demo."""  class PromptTemplate:    def __init__(self, name, version, template):        self.name = name        self.version = version        self.template = template     def render(self, **kwargs):        prompt = self.template        for key, value in kwargs.items():            prompt = prompt.replace("{{" + key + "}}", str(value))        return prompt  def quality_score(prompt):    """Score a prompt from 0 to 1 by design principles."""    score = 0.0    if len(prompt) >= 60:        score += 0.30                # 信息量足够    if "你是一位" in prompt or "你是" in prompt:        score += 0.25                # 有角色设定    if "不要" in prompt or "避免" in prompt:        score += 0.20                # 有禁止项    if "格式" in prompt:        score += 0.15                # 有格式要求    if "例如" in prompt or "不超过" in prompt:        score += 0.10                # 有示例或长度控制    return round(score, 2)  def main():    tpl = PromptTemplate(        name="种草文案",        version="1.2",        template=(            "你是一位资深小红书编辑, 擅长写种草文案.\n"            "请介绍产品: {{product}}, 目标用户: {{audience}}.\n"            "要求: 突出卖点{{feature}}, 语气轻松, 不超过{{limit}}字,\n"            "不要使用夸大词汇, 输出格式: 标题+正文.\n"            "例如: 标题有趣, 正文分三段."        ),    )    prompt = tpl.render(        product="AI 自动摘要笔",        audience="职场白领",        feature="一键生成会议纪要",        limit="80",    )    print(prompt)    print("---- 质量分:", quality_score(prompt), "----")  if __name__ == "__main__":    main()
目的：演示 Prompt 模板的渲染（占位符替换）与按设计原则计算质量分的完整流程，对应正文第 1、4 节的核心思想。
  1. class PromptTemplate:定义模板类，name / version / template 分别对应模板库里的名称、版本号和文本。
  2. prompt = prompt.replace("{{" + key + "}}", str(value))把模板中的占位符替换为真实参数，这是模板复用的核心操作。
  3. score += 0.30 # 信息量足够按规则累计质量分，对应“清晰、具体、可验证”的设计原则。
  4. tpl = PromptTemplate(新建一个带版本号的模板实例，模拟团队模板库中的一条记录。

常见误区

误区“我把背景、历史、注意事项全都写进去，三五千字的大长 prompt 肯定最稳，输出质量跟字数成正比。”

正解信息密度比字数重要。满屏冗余背景就像点菜单上写满整页废话，大厨反而抓不住重点。关键信息应该结构化、前置；无关信息会稀释模型的注意力，甚至诱发“过度关联”式的发挥。刻意加长往往徒增 token 成本，收益却趋近于零。

为何常见：人们把“大模型能处理长文本”误解为“长文本 = 高质量”，忽略了指令聚焦才是关键。

误区“你是一名资深专家”这种开头就是心理暗示，跟写“请认真回答”没区别，加不加无所谓。"

正解角色设定会真实改变模型生成的条件概率分布：它把回答空间从“通用模式”切换到“专家模式”，影响用词深度和论述框架。没有角色设定的输出更像百科全书，有角色设定的输出更像一个具体岗位的人在干活。

为何常见：角色设定没有立竿见影的格式变化，效果主要体现在风格与语气上，容易被误认为装饰。

误区“我写得很详细，模型第一次就给出了满意的答案，直接上线就行。”

正解单次成功不等于稳定可靠。模型有随机性，不同输入、不同版本下同一 prompt 都可能漂移。正规做法是建立测试用例集做回归，就像只凭一次试吃就把菜写进正式菜单，是对口碑的不负责任。

为何常见：开发者在 demo 阶段看到一次好结果，就形成了“已经写好了”的错觉，忽略了样本量的重要性。

误区“我写了'不要编造数据'，模型就一定不会编。”

正解负面指令更像是“降低概率”而不是“执行取反”。模型仍可能犯错。更可靠的是正面规定加格式约束：要求“每个数据标注来源”，或限定“只能从文档摘录”。把不想要的行为替换成想要的行为，比单纯禁止更有效。

为何常见：人们习惯用人类思维理解“不要”，但语言模型没有真正的否定逻辑，它只是在字符层面做概率选择。

面试题

Q1. Prompt 设计的三大核心原则通常指（ ）

单选题 · easy

  • A.清晰性、具体性、可验证性← 正确答案
  • B.简单化、自动化、抽象化
  • C.快速、稳定、低成本
  • D.情感、节奏、感染力

答案：A。三大核心原则是清晰性、具体性、可验证性，对应正文里“点菜单”的三种写法：无歧义、给细节、能检查。B 的自动化是工程手段而非原则，C 是工程指标，D 是风格维度，都不属于设计原则的范畴。

Q2. 在 Prompt 中声明“你是一位资深英文校对”属于哪类设计？（ ）

单选题 · easy

  • A.角色设定法的一种应用← 正确答案
  • B.约束条件法的典型应用
  • C.测试迭代流程的一个步骤
  • D.成本控制策略的重要手段

答案：A。这句声明是在给大厨设定身份，让他按“资深英文校对”的知识范围和风格来输出，正是角色设定法。约束条件法侧重限定范围与格式，测试迭代是后续验证环节，成本控制是工程规范，均与此句无关。

Q3. 负面指令“不要啰嗦”效果有限，更可靠的做法是（ ）

单选题 · mid

  • A.增加更多感叹号强调语气
  • B.正面规定格式和字数限制← 正确答案
  • C.把提示词翻译成英文再写
  • D.重复写三遍不要啰嗦

答案：B。模型没有真正的否定逻辑，“不要啰嗦”只是在概率上避开部分字词。正面规定“每段不超过 3 句”“正文 300 字以内”提供了可执行的边界，效果远好于反复强调“不要”，这正是约束条件书写中“正面规定 + 强格式约束”的原则。

Q4. Prompt 模板中"{{product_name}}"这类标记称为（ ）

单选题 · mid

  • A.占位符，运行时替换成真实参数← 正确答案
  • B.注释符，用于解释模板用途
  • C.分隔符，用于切分模板段落
  • D.转义符，用于特殊字符处理

答案：A。双花括号包裹的内容是占位符（Placeholder），渲染时用真实参数替换，就像点菜单上的空栏。注释符、分隔符、转义符在模板中是其他符号承担的职责，不用于参数填充。

Q5. 一份完整的角色设定通常包含哪些要素？（ ）

多选题 · mid

  • A.角色定义与身份描述← 正确答案
  • B.知识范围与数据来源← 正确答案
  • C.输出风格与语言习惯← 正确答案
  • D.模型参数量与训练数据

答案：ABC。角色设定四要素是角色定义、知识范围、输出风格、身份一致，对应 A、B、C。D 的模型参数量与训练数据是模型本身的属性，不写在用户侧的角色设定里，属于工程选型范畴。

Q6. 关于 Prompt 测试迭代中的基线分（baseline），正确的是（ ）

单选题 · hard

  • A.每次修改后都必须严格高于旧版本
  • B.基线分是衡量迭代有效性的参照← 正确答案
  • C.基线分越高说明提示词一定越好
  • D.基线分只能由人工打分来计算

答案：B。基线分是旧版本在固定用例集上的得分，作为本次改动的对比参照。A 太绝对，持平或微降的改动有时也要保留；C 忽略了基线只在同一用例集内有意义；D 不对，客观规则也可以自动打分，人工只是其中一部分。

Q7. 下列哪些属于 Prompt 工程规范的内容？（ ）

多选题 · mid

  • A.复杂任务拆分为多个子提示词← 正确答案
  • B.估算 token 成本与控制调用次数← 正确答案
  • C.对用户敏感信息进行脱敏处理← 正确答案
  • D.把提示词写得越长越显专业

答案：ABC。工程规范包含任务分解、成本控制、用户沟通、隐私合规四项。A 是任务分解，B 是成本控制，C 是隐私合规。D 与“信息密度比字数重要”的原则相悖，不是规范而是误区。

Q8. 模型升级后旧 Prompt 输出质量明显下滑，首先应做什么？（ ）

单选题 · hard

  • A.立即停用全部旧模板避免风险
  • B.在固定用例集上回归定位差距← 正确答案
  • C.直接回滚到上一个模型版本
  • D.把所有提示词长度再增加一倍

答案：B。模型升级导致输出漂移是常见问题，正确做法是先跑固定用例集做回归，量化“哪里变了、变多少”，再针对性修改 Prompt。一上来就停用或回滚是过度反应，加长提示词更是无依据的猜测。

Q9. “每段不超过 3 句，结尾必须给出两个备选标题”属于哪类约束？（ ）

单选题 · easy

  • A.长度控制与格式要求← 正确答案
  • B.边界限定与禁止事项
  • C.角色设定与知识范围
  • D.模板复用与版本管理

答案：A。“不超过 3 句”是长度控制，“给出两个备选标题”是格式要求，两者同属约束条件书写。边界限定管信息来源，禁止事项管禁区，角色设定管身份，均与题干描述不符。

Q10. 编写高质量 Prompt 时可以验证输出的手段包括（ ）

多选题 · hard

  • A.要求输出结构化格式方便校验← 正确答案
  • B.要求每个结论附带数据出处← 正确答案
  • C.限定只从给定文档中摘录← 正确答案
  • D.完全依赖模型自我感觉是否准确

答案：ABC。可验证性来自可检查的约束：结构化格式让程序能校验，数据出处让事实有据可查，限定摘录范围让内容可回溯，分别对应 A、B、C。D 把验证责任完全交给模型本身，既不可靠也无法自动化，正是要避免的做法。