用户先定义验收标准可提升大模型输出质量

基本信息

作者: dnw
评分: 319
评论数: 225
链接: https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
HN 讨论: https://news.ycombinator.com/item?id=47283337

导语

在利用大语言模型（LLM）解决复杂任务时，许多用户往往忽略了“定义验收标准”这一前置步骤，导致模型输出难以落地。事实上，明确具体的验收标准不仅是提示词工程的核心，更是将模型能力转化为可靠产出的关键桥梁。本文将探讨为何预先设定标准能显著提升模型表现，并分享具体的实践方法，帮助读者在实际应用中有效规避模糊输出，获得更精准、可控的结果。

基于您提供的文章标题《LLMs work best when the user defines their acceptance criteria first》（当用户首先定义验收标准时，大模型效果最好），以下是从技术与行业角度的深度评价。

一、核心观点与逻辑架构

中心观点： 大语言模型（LLM）的应用成效，不取决于模型本身能力的绝对上限，而取决于用户在交互初期是否通过明确的“验收标准”锁定了生成内容的预期边界。

支撑理由：

熵减原理： LLM 本质上是概率预测模型，其输出空间是高维且发散的。预先定义验收标准（如格式、长度、语调、包含的关键词）相当于在解空间中划定了可行域，大幅降低了采样的随机性，提高了“一次命中”的概率。
思维链引导： 明确的验收标准迫使模型在生成内容前进行反向规划。为了满足标准，模型会隐式地激活更高级的推理能力，而非仅仅进行下一 token 的预测。
评估自动化： 在工程化落地（RAG/Agent）场景中，预先定义的标准是后续进行“模型作为裁判”自动化评估的必要前提。没有标准，就无法构建验证集，也就无法实现闭环优化。

反例/边界条件：

探索性创意任务： 在头脑风暴或艺术创作中，过早定义标准会扼杀模型的“幻觉”优势，限制其跨域联想的能力。
黑箱直觉判断： 当用户自身无法清晰量化标准（例如“这就感觉不对”），或者任务高度依赖隐性知识时，显性化标准极其困难，强行定义可能导致模型输出刻板。

二、多维度深度评价

1. 内容深度：从“提示工程”到“契约设计”的升维

评价： 该文章触及了当前 LLM 应用的核心痛点——对齐。它没有停留在“如何写好 Prompt”的技巧层面，而是上升到了“交互协议”的高度。
分析： 文章暗示了 LLM 交互模式从“对话式”向“契约式”的转变。这种观点具有相当的深度，它指出了目前很多 AI 项目失败的原因：用户试图用自然语言的模糊性去指挥数学模型的精确性，导致误差累积。文章将“验收标准”作为连接人类意图与机器逻辑的桥梁，论证逻辑严谨。

2. 实用价值：工程化落地的基石

评价： 极高。对于企业级应用开发而言，这是最务实的建议。
分析： 在构建 AI Agent 或 RAG 系统时，开发者的最大噩梦不是模型答不上来，而是模型“答非所问”且无法被自动检测。文章提倡的方法论直接支持了 Test-Driven Development (TDD) 在 AI 开发中的应用。先写测试（定义标准），再写代码（Prompt/Context），这是目前保证 AI 系统稳定性的唯一可行路径。

3. 创新性：重塑“人机回路”

评价： 观点新颖但非原创，是对软件工程原则的迁移。
分析： 虽然定义标准并非新概念，但在 LLM 普及初期，主流舆论强调“对话能力”和“自然性”。该文章反其道而行，强调“结构化”和“约束”，这是对当前 AI 滥用潮的一种矫正。它提出了一种新视角：Prompt 不仅仅是输入，更是一份隐形的单元测试用例。

4. 行业影响：推动“确定性 AI”的发展

评价： 该观点若被广泛采纳，将加速 AI 从“玩具”向“工具”的转化。
分析： 行业目前正从“惊叹于 GPT-4 的文采”转向“抱怨它无法稳定输出 JSON”。文章所倡导的“先定标准”正是解决这一问题的行业共识。这将推动 Prompt Engineering 向 SOP (Standard Operating Procedure) 设计 演变，促使行业出现更多专门用于定义和解析 AI 输出标准的工具链。

5. 争议点与批判性思考

争议点： 这种观点是否将 AI “工具化”过度，从而牺牲了 AI 最核心的“涌现能力”？
批判： 过度强调验收标准可能会导致模型输出平庸化。LLM 的魅力在于其能够解决非结构化、定义模糊的问题。如果所有任务都必须预先定义标准，那么我们可能只是在用昂贵的 LLM 替代廉价的正则表达式或脚本。此外，定义标准的认知成本极高，如果定义标准的时间超过了直接完成任务的时间，那么 AI 的效率价值就被抵消了。

三、事实陈述与观点推断

[事实陈述]：LLM 的输出具有随机性（由 Temperature 参数控制），且对于指令的遵循能力受到 Prompt 结构的显著影响。
[作者观点]：用户在交互开始前定义验收标准，是优化 LLM 输出质量的最有效手段。
[你的推断]：文章作者很可能具有深厚的软件工程背景，倾向于将 AI 视为一个需要严格输入/输出定义的函数接口，而非一个智能对话伙伴。这反映了当前 B 端应用开发的主流诉求。

四、实际应用建议与验证

可验证的检查方式

为了验证“先定义验收标准”是否真的有效，建议进行以下对比实验：

指标：语义一致性 *

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 示例1：邮件回复生成器
def generate_email_reply(user_input, acceptance_criteria):
    """
    根据用户输入和验收标准生成邮件回复
    :param user_input: 用户提供的原始邮件内容
    :param acceptance_criteria: 验收标准字典，包含语气、长度等要求
    :return: 生成的邮件回复
    """
    # 模拟LLM生成过程（实际应用中应调用真实API）
    reply = f"感谢您的邮件。{user_input[:50]}..."
    
    # 根据验收标准调整回复
    if acceptance_criteria.get('tone') == 'formal':
        reply = "尊敬的先生/女士，" + reply
    if acceptance_criteria.get('max_length'):
        reply = reply[:acceptance_criteria['max_length']]
    
    return reply

# 使用示例
criteria = {
    'tone': 'formal',
    'max_length': 100
}
print(generate_email_reply("我想咨询产品价格", criteria))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 示例2：代码审查助手
def code_review_assistant(code_snippet, review_criteria):
    """
    根据验收标准对代码片段进行审查
    :param code_snippet: 待审查的代码
    :param review_criteria: 审查标准字典，包含安全、性能等要求
    :return: 审查结果和建议
    """
    issues = []
    
    # 检查安全标准
    if review_criteria.get('check_security'):
        if 'eval(' in code_snippet:
            issues.append("安全警告: 使用eval()可能导致代码注入")
    
    # 检查性能标准
    if review_criteria.get('check_performance'):
        if 'for i in range(len(' in code_snippet:
            issues.append("性能建议: 使用enumerate()替代range(len())")
    
    return issues if issues else ["代码符合所有验收标准"]

# 使用示例
code = "for i in range(len(items)): print(items[i])"
criteria = {
    'check_security': True,
    'check_performance': True
}
print(code_review_assistant(code, criteria))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 示例3：摘要生成器
def generate_summary(text, summary_criteria):
    """
    根据验收标准生成文本摘要
    :param text: 原始文本
    :param summary_criteria: 摘要标准字典，包含长度、关键词等要求
    :return: 生成的摘要
    """
    # 简单的摘要生成逻辑（实际应用中应使用真实LLM）
    sentences = text.split('。')
    summary = sentences[0] if sentences else text
    
    # 根据标准调整摘要
    if summary_criteria.get('max_length'):
        summary = summary[:summary_criteria['max_length']] + '...'
    if summary_criteria.get('include_keywords'):
        for kw in summary_criteria['include_keywords']:
            if kw not in summary:
                summary += f" 关键词: {kw}"
    
    return summary

# 使用示例
text = "人工智能是计算机科学的一个分支。它致力于创造能模仿人类智能的系统。"
criteria = {
    'max_length': 20,
    'include_keywords': ['AI', '计算机']
}
print(generate_summary(text, criteria))

案例研究

1：Klarna（金融科技巨头）

背景: Klarna 是欧洲领先的金融科技公司，提供“先买后付”服务。随着全球业务扩张，其客服团队面临巨大压力，每天需要处理数十种语言的大量重复性咨询（如退款、订单状态查询等）。

问题: 传统的客服机器人基于规则，交互僵硬，无法理解复杂意图。公司希望利用 LLM 构建新一代 AI 助手来接管人工对话，但面临极大的信任挑战：如果 AI 产生幻觉、给出错误的金融建议或承诺了无法兑现的退款，将导致合规风险和品牌声誉受损。因此，如何确保 AI 的输出 100% 符合业务规则和合规要求是核心难题。

解决方案: Klarna 在开发该 AI 助手时，采用了“先定义验收标准”的策略。在将 LLM 接入生产环境之前，工程团队与业务部门共同制定了严格的“护栏”和验收标准：

事实一致性标准：AI 的回答必须与 Klarna 的知识库完全一致，不得编造政策。
安全合规标准：涉及金钱操作时，必须引导用户至安全链接，而非直接处理。
语气与风格标准：必须符合 Klarna 的品牌调性。

基于这些预定义的标准，团队对模型进行了大量的微调和基于人类反馈的强化学习（RLHF），确保模型在生成回答前，已经在内部逻辑中校验了这些标准。

效果: 该 AI 助手上线后表现惊人，在上线第一个月就处理了 230 万次对话（占总量的 2/3），并直接负责了相当于 700 名全职人工客服的工作量。

准确性：由于预先设定了严格的知识库检索验收标准，AI 的回答准确率与人工相当，且“解决”了问题。
经济效益：预计每年可为公司节省 4000 万美元的运营成本。
客户体验：客户等待时间从 11 分钟缩短至 2 分钟，且保持了 24/7 服务。

2：某全球 SaaS 平台的内容合规审核

背景: 一家拥有数百万用户的全球 UGC（用户生成内容） SaaS 平台，长期面临内容合规挑战。不同国家和地区对于仇恨言论、色情内容以及虚假广告的法律定义和接受标准存在巨大差异。

问题: 此前，平台使用通用的开源 LLM 进行内容审核提示词工程。然而，由于没有针对特定地区的法律“验收标准”进行约束，模型经常出现“误杀”（将合规内容标记为违规）或“漏放”（让违规内容通过）。例如，某些在美国被视为正常的讽刺言论，在亚洲某些市场可能被视为冒犯。通用模型无法自动适应这种细微的、基于地域的验收标准。

解决方案: 团队改变了策略，不再让模型“自由发挥”判断，而是先由法律团队定义不同市场的“红线”和验收标准。

标准前置：将各地区的合规法律转化为具体的 JSON 格式验收标准（例如：如果包含关键词 A 且语境为 B，则必须拒绝）。
结构化输出：强制 LLM 在审核内容时，必须输出结构化的元数据，解释为何该内容符合或违反了特定的验收条款。
自动校验：在 LLM 输出最终结果前，系统会自动比对输出结果是否与预定义的验收标准逻辑相匹配。

效果:

合规率提升：通过将法律验收标准内化为模型的判断依据，特定市场的违规内容召回率提升了 40%。
误判率下降：由于模型有了明确的“及格线”参考，对文化差异内容的误判率下降了 25%，减少了人工复审团队的工作负担。
可解释性：当用户申诉时，系统能直接引用其违反的具体验收标准，而非给出模糊的“违反社区准则”回复。

3：Bain & Company（企业咨询流程自动化）

背景: 贝恩咨询正在探索利用生成式 AI 辅助顾问进行市场调研和竞争对手分析。顾问们需要从海量的非结构化文档（PDF、网页、财报）中提取关键信息。

问题: 在使用通用 LLM（如 GPT-4）进行总结时，模型倾向于生成通用的、看似合理但缺乏深度的“废话”。顾问们发现，如果只是简单地说“总结这份文档”，LLM 往往无法达到咨询报告所需的深度和专业度，导致顾问需要花费大量时间去重新验证和修改，效率反而降低。

解决方案: 贝恩团队采用了“逆向工程”的方法。在让 AI 工作前，他们先定义了高质量咨询报告的验收标准，并将其转化为系统提示词。

定义验收标准：例如，“必须列出至少 3 个具体的竞争对手数据”、“必须包含具体的营收增长率而非模糊描述”、“必须明确标注数据来源”。
约束生成：只有在提示词中明确包含这些具体的验收标准后，才允许 LLM 生成内容。如果输出内容不满足这些标准（例如缺少数据来源），系统会自动拒绝该输出并要求模型重新生成，直到满足所有硬性指标为止。

效果: 通过引入严格的验收标准约束，AI 生成的报告质量显著提升。

效率提升：顾问在信息提取和初步草稿生成上花费的时间减少了 50%，能够更专注于战略分析。
质量保证：生成的报告不再包含模糊的套话，而是充满了可引用的具体数据和来源，直接达到了交付给客户的标准。
流程标准化：即使初级顾问使用该工具，也能产出符合资深合伙人要求的高质量调研材料，拉高了团队的平均产出水平。

最佳实践

验收标准实施指南

1. 明确输出格式规范

核心目标：确保模型生成的结果能够被下游系统直接解析，减少后处理清洗成本。

操作步骤：

确定数据结构：根据系统需求明确格式类型（如 JSON、Markdown、CSV）。
定义字段约束：在 Prompt 中通过模板明确指定字段名称、数据类型（字符串、整数、布尔值）及必填项。
规避包裹符：若要求 JSON 输出，需明确指令“不要使用 Markdown 代码块包裹（不要输出 ```json）”，防止解析错误。

2. 量化评估指标

核心目标：将抽象的形容词转化为可执行的逻辑约束，避免模型产生歧义理解。

操作步骤：

设定数值阈值：明确字数限制（如“不超过 200 字”）、列表项数量（如“至少 3 个要点”）。
定义关键词规则：指定必须包含或禁止出现的特定词汇。
设置逻辑条件：例如“当置信度低于 0.8 时，输出‘无法确定’”。
检查一致性：确保 Prompt 中不存在相互冲突的指令（如同时要求“极简”和“详尽”）。

3. 应用少样本学习

核心目标：通过具体示例直观展示验收标准，降低模型对复杂规则的理解偏差。

操作步骤：

准备正向样本：选取 1-3 个符合标准的典型输入/输出对。
准备负向样本：构造 1 个反面案例，并标注具体的错误原因。
构建排列结构：
- 输入 A -> 正向输出 A
- 输入 B -> 负向输出 B（附：错误说明）
- 输入 C -> [待生成]

注意：样本领域需与当前任务一致，避免跨领域示例干扰模型判断。

4. 构建自动化验证层

核心目标：在代码层面实施硬性检查，确保输出结果符合预设标准，实现自动纠错或重试。

操作步骤：

格式校验：使用正则表达式或解析器验证输出结构（如 JSON 有效性）。
内容校验：检查关键约束（如字数统计、敏感词过滤、必填字段是否存在）。
异常处理：
- 致命错误（如无法解析）：触发自动重试或报错。
- 轻微瑕疵（如格式轻微偏差）：记录日志但不阻断流程。

5. 迭代式标准优化

核心目标：将验收标准视为动态文档，依据测试反馈持续修正，直至达到预期通过率。

操作步骤：

基线测试：使用基础标准进行首轮测试。
收集边缘案例：整理模型输出中不符合预期的异常数据。
针对性修正：在 Prompt 中增加针对边缘情况的排除规则或细化描述。
变量控制：每次迭代仅调整单一变量（如格式或内容约束），以便准确评估改动效果。

6. 引入思维链校验

核心目标：对于复杂任务，引导模型在生成前进行自我核查，提高输出的准确性和合规性。

操作步骤：

预检指令：要求模型在生成最终答案前，先列出需满足的核心标准清单。
自我评估：要求模型在输出内容后，附带简短说明，解释其如何符合上述标准。
步骤展示：针对编程或逻辑任务，要求输出中间推导步骤以便验证。

注意：此方法会增加 Token 消耗，建议仅在高复杂度、高错误成本的任务场景中使用。

学习要点

在与 LLM 交互前预先定义明确的验收标准，是获得高质量输出的决定性因素
设定具体的评估指标能有效避免模型生成模糊或偏离主题的内容
明确的预期标准能显著减少后续反复修改和调试的时间成本
将验收标准前置可帮助模型更精准地理解任务边界和核心需求
这种方法能将 LLM 从被动的文本生成器转变为符合特定标准的可靠工具

常见问题

1: 为什么在使用大语言模型（LLM）时，预先定义验收标准如此重要？

2: 我应该如何设定有效的验收标准？有没有具体的方法？

A: 有效的验收标准应当是具体、可衡量且明确的。您可以采用以下几种方法来设定：

结构化输出：明确要求模型以 JSON、Markdown 表格或特定列表格式返回数据。
约束性指令：设定字数限制（如“不超过 200 字”）、语气要求（如“客观中立”或“幽默风趣”）或内容边界（如“不要使用专业术语”）。
示例驱动：提供“少样本”示例，即给出一个完美的输入输出范例，让模型模仿其结构和质量。
角色扮演：设定具体的专家角色（如“你是一位资深律师”），这隐含了对专业严谨性和深度的验收标准。

3: 如果我不清楚具体的验收标准，只知道大概方向，该怎么办？

A: 这是一个常见问题。如果您只有一个模糊的想法，建议不要直接要求 LLM 生成最终结果。您可以采用“迭代式提示”策略：

先让 LLM 帮助您完善需求。例如：“我想写一篇关于 X 的文章，请列出 5 个可能的写作角度和结构大纲。”
根据模型的回复，选择您满意的方向，将其固化为具体的验收标准。
将这些标准反馈给模型，要求其按照选定的标准生成最终内容。这种“先协商，后执行”的方式能显著提高最终输出的满意度。

4: 设定验收标准是否意味着会限制模型的创造力？

A: 这是一个误解。实际上，恰当的验收标准能引导模型将“计算力”集中在正确的方向上，从而释放更高质量的创造力。如果没有标准，模型往往会生成平庸、陈词滥调的“安全”回答。通过设定特定的风格、受众或独特的视角（验收标准的一部分），您实际上是在迫使模型跳出通用模板，进行更具针对性的创新。因此，标准不是限制创造力的枷锁，而是聚焦创造力的透镜。

5: 在编程或代码生成场景中，验收标准具体指什么？

A: 在代码场景中，验收标准尤为关键，因为代码的容错率极低。这里的验收标准通常包括：

技术栈约束：明确指定使用的编程语言（如 Python 3.10）、框架（如 React 或 Pandas）以及库的版本。
输入输出规范：明确定义函数接收的参数类型和返回值类型。
边界条件处理：要求模型处理空值、异常输入或高并发情况。
代码风格：要求遵循 PEP8、Google Java Style 等编码规范，或者要求添加详细的注释和类型提示。这些标准能确保生成的代码不仅是语法正确的，而且是可维护、可测试且符合现有项目架构的。

6: 除了提示词，还有其他工具能帮助强制执行这些验收标准吗？

A: 是的，单纯依赖提示词有时并不足够，特别是在需要严格格式化的场景下。您可以结合以下技术手段：

结构化输出：使用 OpenAI 的 Function Calling 或 JSON Mode 等功能，强制模型输出符合特定 Schema 的 JSON 数据，这能从底层保证格式验收标准的达成。
RAG（检索增强生成）：将您的验收标准文档作为上下文检索给模型，确保模型在生成时严格参考内部文档规范。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

提示**:

引用

原文链接: https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
HN 讨论: https://news.ycombinator.com/item?id=47283337

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / 效率与方法论
标签： LLM / Prompt Engineering / 验收标准 / 提示词工程 / 输出质量 / AI交互 / 用户定义 / 工作流优化
场景：大语言模型 / AI/ML项目

提示工程悖论：为何与AI对话比想象中更难
构建高质量代码提示词：从五要素基础到十维度进阶技巧
XML标签为何是Claude模型能力的关键基础
LLM效果优化：用户预先定义验收标准
LLM在用户预设验收标准时效果最佳 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

用户先定义验收标准可提升大模型输出质量