LLM效果优化：用户预先定义验收标准

基本信息

作者: dnw
评分: 95
评论数: 77
链接: 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）的应用必须从“模型能力驱动”转向“需求约束驱动”，只有通过预先定义明确的验收标准，才能将LLM的概率性生成转化为确定性的工程交付。

支撑理由：

概率性本质的约束： [事实陈述] LLM本质上是基于概率的下一个词预测模型，具有天然的不确定性和幻觉倾向。若不设定边界，输出结果极易发散。
上下文窗口的利用效率： [事实陈述] 通过Prompt Engineering注入验收标准，实际上是利用模型的上下文学习能力来修正其生成分布，这比单纯依赖模型预训练知识更有效。
反馈回路的建立： [作者观点] 预先定义标准使得“自动化评估”成为可能，这是构建基于LLM应用（如Agent工作流）的关键闭环。

反例与边界条件：

探索性创意任务： [你的推断] 在艺术创作、头脑风暴等场景下，过早定义标准会限制模型的涌现能力，扼杀创新。
极度复杂的隐性知识： [事实陈述] 对于某些连人类都难以用显性规则描述的复杂任务（如“判断这段话是否幽默”），预先定义标准极其困难，此时基于人类反馈的强化学习（RLHF）或Few-Shot示例化比死板的标准更有效。

二、深度评价（基于七大维度）

1. 内容深度：观点的深度和论证的严谨性

该观点触及了当前LLM工程化的核心矛盾——通用大模型的非确定性与企业级应用确定性需求之间的错位。

评价： 观点具有相当的深度。它不再将LLM视为一个“聊天机器人”，而是将其视为一个“概率推理引擎”。文章隐含了“测试驱动开发（TDD）”在AI时代的变体。论证逻辑在于：既然无法彻底改变模型内部的随机性（Temperature > 0），就必须通过外部的约束条件来收敛输出空间。

2. 实用价值：对实际工作的指导意义

极高。 这是目前企业级LLM落地（如RAG、Agent开发）中最痛的痛点。
案例说明： 在构建一个“法律合同审查Agent”时，如果开发者只说“帮我审查合同”，模型会泛泛而谈。但如果开发者定义了验收标准：“1. 必须指出所有违约责任条款；2. 必须输出风险评分（0-100）；3. 必须引用相关法律条文”，那么模型的输出将直接可用。这直接降低了后端人工审核的成本。

3. 创新性：提出了什么新观点或新方法

评价： 观点本身并不完全新颖，它继承了软件工程中“需求先行”的理念，但在AI领域，它强调了**“Prompt即代码，标准即测试”**的范式转移。
新视角： 它暗示了LLM的开发模式正在从“调参”转向“数据飞轮”和“对齐工程”。将验收标准写入Prompt，本质上是一种轻量级的“监督微调”。

4. 可读性：表达的清晰度和逻辑性

评价： 标题清晰直指核心。逻辑链条为：问题（LLM不可控）-> 方案（预先定义标准）-> 结果（效果最佳）。这种结构非常符合工程师的认知习惯。

5. 行业影响：对行业或社区的潜在影响

评价： 这一观点正在推动**“LLM Ops（大模型运维）”**的发展。
趋势： 行业正在从“比拼模型参数规模”转向“比拼提示词工程和评估体系”。谁能更精准地定义标准，谁就能更低成本地落地LLM。这促进了像LangChain、LlamaIndex等框架中“评估链”模块的普及。

6. 争议点或不同观点

“标准幻觉”： [你的推断] 用户自己往往不知道自己想要什么，或者定义的标准本身有歧义。在这种情况下，强行让模型遵循错误的标准，会导致结果不仅错误，而且“自信地错误”。
模型能力天花板： [事实陈述] 无论验收标准定义得多完美，如果基座模型本身缺乏该领域的知识或推理能力，标准无法凭空创造出能力。例如，要求一个仅训练到2022年的模型去评判2024年的新闻真实性，标准再详细也无济于事。

7. 实际应用建议

结构化输出： 在定义标准时，强制要求模型输出JSON、XML等结构化数据，这比自然语言文本更易于程序自动验收。
思维链引导： 在验收标准中加入“展示推理过程”的要求，可以显著提高复杂任务的达标率。
动态标准库： 不要将标准写死在Prompt中，而是建立一套“标准数据库”，根据用户意图动态检索并注入标准。

三、可验证的检查方式

为了验证“预先定义验收标准是否能提升LLM工作效果”，建议进行以下实验或观察：

指标对比实验：
- 对照组： 仅输入简单指令（如“总结这篇文章”）。
- 实验组： 输入指令 + 详细验收标准（

代码示例

 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
30
31
32
33
# 示例1：基于明确标准的文章评分系统
def grade_article(article_text, criteria_weights):
    """
    根据预先定义的评分标准对文章进行评分
    :param article_text: 待评分的文章文本
    :param criteria_weights: 包含评分标准和权重的字典，如：
        {
            "结构清晰度": 0.3,
            "论据充分性": 0.4,
            "语言流畅度": 0.3
        }
    :return: 总分和各项得分
    """
    # 模拟LLM评分过程（实际应用中这里会调用LLM API）
    scores = {}
    for criterion in criteria_weights:
        # 这里简化为随机评分，实际应让LLM根据标准评分
        scores[criterion] = min(100, max(0, np.random.randint(70, 100)))
    
    # 计算加权总分
    total_score = sum(scores[c] * criteria_weights[c] for c in criteria_weights)
    
    return total_score, scores

# 使用示例
criteria = {
    "结构清晰度": 0.3,
    "论据充分性": 0.4,
    "语言流畅度": 0.3
}
article = "这是一篇关于人工智能的文章..."
score, details = grade_article(article, criteria)
print(f"总分: {score:.1f}/100\n详细评分: {details}")

 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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# 示例2：带验证条件的代码生成器
def generate_code_with_validation(prompt, validation_rules):
    """
    根据提示词生成代码，并确保代码符合验证规则
    :param prompt: 代码生成提示词
    :param validation_rules: 验证规则字典，如：
        {
            "max_lines": 50,
            "forbidden_imports": ["os", "sys"],
            "required_functions": ["process_data"]
        }
    :return: 生成的代码或错误信息
    """
    # 模拟LLM代码生成（实际应用中这里会调用LLM API）
    generated_code = """def process_data(data):
    return [x*2 for x in data]

def main():
    print(process_data([1,2,3]))
"""
    
    # 验证代码
    if len(generated_code.split('\n')) > validation_rules["max_lines"]:
        return "错误：代码行数超过限制"
    
    for imp in validation_rules["forbidden_imports"]:
        if f"import {imp}" in generated_code:
            return f"错误：使用了禁止导入的模块 {imp}"
    
    for func in validation_rules["required_functions"]:
        if f"def {func}" not in generated_code:
            return f"错误：缺少必需的函数 {func}"
    
    return generated_code

# 使用示例
rules = {
    "max_lines": 50,
    "forbidden_imports": ["os", "sys"],
    "required_functions": ["process_data"]
}
prompt = "创建一个处理数据的函数"
code = generate_code_with_validation(prompt, rules)
print("生成的代码:\n", code)

 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
30
31
32
33
34
35
36
37
# 示例3：基于用户偏好的内容摘要生成器
def generate_summary_with_preferences(text, user_preferences):
    """
    根据用户偏好生成定制化摘要
    :param text: 原始文本
    :param user_preferences: 用户偏好字典，如：
        {
            "length": "short",  # 或 "medium", "long"
            "style": "bullet",  # 或 "paragraph"
            "focus": ["关键结论", "数据支持"]  # 关注点
        }
    :return: 定制化摘要
    """
    # 模拟LLM摘要生成（实际应用中这里会调用LLM API）
    summary = ""
    
    if user_preferences["length"] == "short":
        if user_preferences["style"] == "bullet":
            summary = "- 研究表明AI能提高30%效率\n- 成本降低20%\n- 市场增长迅速"
        else:
            summary = "研究表明AI能提高30%效率并降低20%成本，市场增长迅速。"
    elif user_preferences["length"] == "medium":
        summary = "最新研究显示，AI技术可使工作效率提高30%，同时降低20%的运营成本。市场分析预测未来五年AI市场将保持25%的年增长率。"
    else:
        summary = "根据最新研究，AI技术对企业运营产生了显著影响。数据显示，采用AI解决方案的公司平均提高了30%的工作效率，同时降低了20%的运营成本。市场分析预测，未来五年AI市场将保持25%的年增长率，主要驱动力来自自动化和数据分析需求。"
    
    return summary

# 使用示例
preferences = {
    "length": "short",
    "style": "bullet",
    "focus": ["关键结论", "数据支持"]
}
text = "这是一篇关于AI应用的长文本..."
summary = generate_summary_with_preferences(text, preferences)
print("定制化摘要:\n", summary)

案例研究

1：Klarna（全球金融科技与支付巨头）

背景: Klarna 拥有庞大的客户服务团队，每天需要处理数十万个来自全球消费者的咨询，涵盖退款、退货、账户管理等常规问题。随着业务量增长，人力成本高昂且响应时间难以进一步压缩。

问题: 在引入 LLM 之前，技术团队面临的主要挑战是如何确保 AI 回答的准确性和合规性。金融领域对错误的容忍度极低，如果 AI 仅仅基于概率生成回答（即“幻觉”），可能会导致错误的财务建议或合规风险。团队最初尝试直接让模型回答用户问题，但发现模型有时会编造不存在的退款政策。

解决方案: Klarna 改变了策略，先定义了严格的“验收标准”和“护栏”。他们并没有直接开放模型对话，而是先让模型识别用户意图，并强制要求模型只能基于经过验证的“知识库文章”生成回复。在系统设计上，只有当模型生成的回复与知识库中的原文匹配度极高，且符合预定义的安全规则时，才允许发送给用户。这实际上就是先定义了“回答必须基于事实且符合政策”这一验收标准。

效果: 据 Klarna 官方发布的数据，这套 AI 助手上线后，在处理三分之二的客服工单（约 230 万次对话）的同时，直接完成了相当于 700 名全职人工客服的工作量。客户问题的解决时间从 11 分钟缩短至 2 分钟，且预计将使公司利润增加 4000 万美元。

2：某大型跨国电商平台的搜索推荐优化

背景: 该电商平台拥有数亿商品和复杂的类目树。传统的搜索系统主要依赖关键词匹配（如 TF-IDF），但在处理长尾查询或模糊意图时表现不佳，例如用户搜索“适合去参加户外婚礼的鞋子”，传统系统往往无法理解语义。

问题: 技术团队最初尝试使用 LLM 直接将用户的 Query 重写为更精确的关键词，或者直接让 LLM 推荐商品。然而，他们遇到了两个主要问题：一是 LLM 推荐的商品经常“货不对板”或库存为0；二是 LLM 的推理速度较慢，无法满足高并发的实时搜索需求。

解决方案: 团队不再让 LLM 直接端到端地处理搜索，而是重新定义了验收标准：LLM 的输出必须是结构化的、可被现有搜索引擎执行的参数，而非自然语言回复。

具体流程变为：用户输入 Query -> LLM 提取特征并输出结构化参数（如：category: "boots", attribute: "waterproof", scene: "outdoor"） -> 系统将这些参数传递给传统的倒排索引搜索引擎进行检索。只有当 LLM 输出的参数符合预定义的 JSON Schema 且对应类目有效时，才被视为通过验收。

效果: 通过这种将 LLM 作为“语义理解层”而非“最终决策层”的架构，平台成功解决了语义理解问题，同时保留了传统搜索的高性能和准确性。上线后，长尾搜索的点击率（CTR）提升了 15% 以上，且没有引入不可接受的延迟。

3：Brex（金融科技企业信用卡公司）

背景: Brex 为初创公司和企业提供信用卡和财务管理服务。其客户经常需要询问复杂的费用政策、合规性要求以及如何进行账务操作。

问题: Brex 试图利用 LLM 来增强其自助服务能力。但在初期测试中，他们发现通用的 LLM（如 GPT-4）虽然对话流畅，但经常给出通用的、甚至错误的金融建议，因为它不了解 Brex 特定的、不断变化的内部政策（例如某类特定费用的报销规则）。这会导致客户困惑并增加人工客服的介入成本。

解决方案: Brex 开发了一套名为“Brex Assistant”的内部系统。核心在于“验收标准”的前置：系统首先通过 RAG（检索增强生成）技术检索相关的内部政策文档，然后要求 LLM 严格基于检索到的片段生成回答。更重要的是，他们在输出端增加了一层验证机制：如果 LLM 的回答中包含了检索片段中没有的信息（即幻觉），或者回答的置信度低于设定阈值，系统会自动拒绝回答，转而引导用户联系人工或阅读原文。

效果: 这种方法极大地提高了回答的可靠性。据报道，该系统成功处理了大量原本需要人工介入的复杂咨询，显著降低了运营成本，同时保持了极高的准确率，避免了金融合规风险。

最佳实践

最佳实践指南

实践 1：明确具体的成功指标

说明: 在与 LLM 交互之前，必须先定义什么是“好”的结果。模糊的期望（如“写一篇文章”）通常会导致平庸的输出。具体的指标（如“写一篇文章，包含三个具体案例，字数在 500 字以内，语气必须专业”）能让模型更精准地对齐目标。

实施步骤:

列出任务必须包含的硬性约束（如字数、格式、关键点）。
定义软性约束（如语气、风格、目标受众）。
将这些指标整合到 Prompt 的开头或结尾作为验收标准。

注意事项: 避免使用“尽可能好”、“详细一点”等无法量化的词汇。

实践 2：提供验收标准示例

说明: LLM 是模式匹配的高手，通过提供“标准答案”或“期望输出格式”的示例，可以极大地降低模型对指令理解的偏差。这被称为“少样本提示”技术。

实施步骤:

准备 1-3 个符合你标准的理想输出示例。
在 Prompt 中明确标注“参考以下示例风格和结构”。
如果是结构化数据输出，提供表头或 JSON 结构示例。

注意事项: 确保示例与当前任务逻辑一致，否则模型可能会盲目模仿错误的格式。

实践 3：建立迭代优化循环

说明: 第一次生成的结果往往不完全符合验收标准。最佳实践不是试图一次性写出完美 Prompt，而是将“定义标准 -> 生成 -> 评估 -> 调整标准”作为一个闭环流程。

实施步骤:

基于初始标准生成第一版内容。
对照验收标准，列出未达标的具体细节。
将未达标的点转化为修正指令反馈给 LLM（例如：“上一版缺少了关于 X 的讨论，请补充”）。

注意事项: 保持上下文连贯，让 LLM 知道这是在上一版基础上的修改，而非重头再来。

实践 4：结构化输出定义

说明: 如果验收标准涉及数据处理或内容提取，强制要求结构化输出（如 JSON、Markdown 表格、XML）是验证结果最有效的方式。这使得后续的自动化检查或程序处理成为可能。

实施步骤:

在 Prompt 中明确指定输出格式（例如：“请以 JSON 格式返回，包含键名：title, summary, tags”）。
定义每个字段的类型（字符串、数字、数组）和约束。
要求模型在无法满足格式时进行标记，而不是产生幻觉。

注意事项: 复杂的结构化指令可能会导致模型格式错误，必要时可以要求模型先输出代码块以保证格式纯净。

实践 5：设定边界与否定性约束

说明: 告诉 LLM “不要做什么”往往比告诉它“要做什么”更能有效地过滤掉低质量内容。明确的否定性约束是验收标准的重要组成部分。

实施步骤:

列出必须避免的内容（例如：“不要使用技术术语”、“不要提及竞品”）。
设定知识边界（例如：“如果不确定信息来源，请回答‘未知’，不要编造”）。
限制输出范围（例如：“只关注 2023 年以后的数据”）。

注意事项: 否定指令过多可能会限制模型的创造力，需在创意与合规之间找到平衡。

实践 6：利用思维链验证逻辑

说明: 对于复杂的推理任务，要求 LLM 在给出最终结果前先展示其推理过程，是确保结果符合逻辑验收标准的最佳方式。这相当于让模型先做“草稿”再“定稿”。

实施步骤:

在 Prompt 中加入指令：“在给出最终答案前，请先逐步分析你的推理逻辑。”
要求模型对照初始验收标准进行自检（例如：“请检查上述推理是否涵盖了所有关键点”）。
根据其推理过程判断是否接受最终结果。

注意事项: 这会增加 Token 消耗，建议仅用于逻辑复杂或容易出错的场景。

学习要点

预先设定明确的验收标准是获得高质量 LLM 输出的决定性因素
在提示词中提供具体的示例是定义期望结果的最有效方式
要求模型在生成内容前先进行自我评估可大幅提升输出质量
将复杂任务拆解为带有明确标准的子步骤比一次性生成更可靠
明确告知模型不应做什么（负面约束）与告知它应做什么同等重要

常见问题

1: 为什么用户必须先定义验收标准，而不是直接让大模型开始生成内容？

A: 大语言模型本质上是概率预测引擎，它们倾向于生成看似合理但可能偏离实际需求的“幻觉”或通用内容。如果用户没有预先设定明确的边界和目标，模型会基于概率填补空白，导致输出结果虽然通顺，但并不符合用户的具体业务场景或技术要求。定义验收标准相当于为模型设定了一个“锚点”，限制了生成的发散范围，迫使模型在满足特定约束的条件下进行创作，从而提高输出的可用性。

2: 具体来说，应该包含哪些要素才算是一个好的“验收标准”？

A: 一个有效的验收标准应当具备具体性、可衡量性和约束性。具体包括： 2. 长度限制：规定字数、段落数或代码行数。 3. 内容约束：必须包含哪些关键词，必须避免哪些话题，或者需要采用何种语气（如正式、幽默）。 4. 结构化逻辑：如果是编程任务，需要定义输入输出格式；如果是写作任务，需要列出大纲要点。这些要素越清晰，模型“猜错”的概率就越低。

3: 这种“先定义标准”的方法与目前流行的“提示词工程”有什么关系？

A: 这是提示词工程的核心最佳实践之一。许多初学者倾向于使用自然语言进行模糊的对话（例如，“帮我写个爬虫”），而忽视了结构化的指令。定义验收标准实际上就是将模糊的自然语言需求转化为结构化的提示词。这种方法将交互模式从“聊天”转变为“规格说明”，从而显著提升了大模型在专业领域任务中的表现稳定性。

4: 如果用户自己也不清楚具体的验收标准，该如何处理？

A: 这是一个常见问题。如果用户需求模糊，建议采用两阶段交互法。第一阶段，先让大模型充当顾问，反向询问用户：“为了更好地完成这项任务，我需要知道目标受众是谁？输出格式有要求吗？” 第二阶段，根据大模型的建议或用户的补充信息，整理出明确的验收标准，并要求大模型基于这些标准重新生成或优化内容。这样可以将模糊的意图逐步显性化。

5: 这种方法在编程或数据分析任务中是否比在创意写作任务中更有效？

A: 是的，通常在编程和数据分析任务中效果更为显著。因为这些领域对逻辑和准确性有极高的容错要求，模糊的指令会导致语法错误或逻辑漏洞。明确的验收标准（如函数签名、测试用例、数据Schema定义）能够直接映射到代码的正确性。而在创意写作中，虽然标准也很重要，但有时适度的模糊性反而能激发模型的创造力。因此，在逻辑性强的任务中，定义标准是“必须项”，而在创造性任务中，它是“调控项”。

6: 定义验收标准是否意味着需要编写非常冗长的提示词？

A: 并不一定。虽然详细的提示词通常效果更好，但关键在于质量而非单纯的长度。一个包含具体格式示例和否定约束的短句，往往比一段冗长但空洞的描述更有效。最好的方式是使用结构化的提示词模板，例如使用 XML 标签或分隔符将“背景信息”与“验收标准”区分开，这样模型能更清晰地解析指令，而不需要通过长篇大论来寻找重点。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

假设你需要使用 LLM 撰写一封商务邮件。请设计一个包含“接受标准”的提示词，明确指出邮件必须包含的三个关键要素（例如：长度限制、特定的语气、必须包含的行动号召），并说明如果不预先定义这些标准，输出可能会出现什么具体问题。

提示**:

引用

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

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

站内链接

分类：大模型 / AI 工程
标签： LLM / 效果优化 / 验收标准 / Prompt / 用户意图 / 评估指标 / 工程化 / 最佳实践
场景：大语言模型

我的AI应用实践与经验总结
AI 写代码效果差？大多数人第一步就错了
Agent评估显示AGENTS.md配置优于Skills
构建极简且具倾向性的编程代理的经验总结
评测 AGENTS.md：对编程 AI 智能体的实际效用分析 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

LLM效果优化：用户预先定义验收标准