LLM在用户预设验收标准时效果最佳

LLM在用户预设验收标准时效果最佳

基本信息

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

导语

在构建基于大语言模型的应用时，明确验收标准往往比单纯优化提示词更为关键。这一前置步骤不仅能有效减少模型输出的不确定性，还能显著降低后期调试与迭代的时间成本。本文将探讨如何在交互前确立清晰的判定逻辑，帮助开发者建立更稳定、可预期的自动化工作流。

评论

深度评价：LLMs work best when the user defines their acceptance criteria first

文章中心观点 LLM 的应用效果不应仅依赖于模型能力的提升，更取决于用户在交互前是否明确定义了“成功”的标准（即验收标准），这一观点将 LLM 的使用范式从“生成式探索”转向了“约束式求解”。

一、 核心论证与支撑理由

支撑理由：

1. 收敛性效率提升

   • [事实陈述] LLM 本质上是概率分布模型，其输出空间具有极高的发散性。
   • [作者观点] 如果不预设验收标准，模型容易陷入“看似合理但无用”的幻觉长尾。预设标准相当于在向量空间中划定了一个高概率的“目标区域”，显著减少了通过多次 Prompt 迭代来寻找答案的时间成本。

2. 可解释性与调试便利

   • [你的推断] 在工程化落地（如 RAG 或 Agent 流程）中，当输出结果不符合预期时，明确的验收标准可以作为“断点”进行回溯。
   • [作者观点] 如果标准在前，开发者可以清晰地判断是模型能力不足，还是上下文信息缺失，亦或是标准本身定义模糊。这解决了黑盒模型难以调试的痛点。

3. 从“内容生成”转向“功能验证”

   • [行业背景] 当前行业正从“玩梗”转向 B 端落地。
   • [你的推断] 只有当验收标准先于生成存在时，LLM 的输出才能被视为通过了某种“图灵测试”的功能性输出，而非仅仅是文本续写。这是将 LLM 视为“逻辑引擎”而非“修辞引擎”的关键转变。

反例与边界条件：

1. 探索性创意任务

   • [反例] 在艺术创作、头脑风暴或寻找“意外发现”时，过早定义验收标准会扼杀 LLM 的发散性思维优势。用户往往不知道自己想要什么，直到 LLM 给出一个惊喜。
   • [边界] 此时，验收标准应当是“模糊的”或“后置的”，而非预先定义的硬性指标。

2. 极度复杂的长链推理

   • [反例] 对于数学证明或复杂代码生成，用户虽然定义了“正确运行”这一宏观标准，但无法定义中间步骤的微观验收标准。
   • [边界] 如果验收标准无法被分解为可验证的中间态，预设标准对模型推理能力的提升微乎其微，甚至可能因为模型无法一次性满足所有严苛标准而导致输出崩溃。

二、 多维度深度评价

1. 内容深度：从“Prompt Engineering”到“Requirement Engineering”的升维

文章的深度在于它切中了当前 AI 落地的核心痛点：人类意图的对齐难题。

• 论证严谨性： 文章隐含引用了软件工程中“测试驱动开发（TDD）”的思想。将 LLM 视为一个需要被测试的接口，而非一个需要被调教的黑盒，这种视角转换非常具有洞察力。它指出了许多 Prompt Engineering 失败的根本原因——并非技巧不足，而是需求不清。

2. 实用价值：B 端落地的“定海神针”

• 指导意义： 对于企业级应用开发，该观点极具指导意义。在构建 RAG 系统或客服机器人时，先定义 JSON Schema 或评分卡，再让模型生成，能大幅降低后端处理的难度。
• 案例： 在构建合同审查 Agent 时，如果用户先定义“必须包含不可抗力条款”这一硬性标准，模型的召回率和准确率将远高于让模型“检查合同风险”这种模糊指令。

3. 创新性：重构交互范式

• 新观点： 文章提出了一种“逆向工作流”。传统的 LLM 交互是 Input -> LLM -> Output -> Evaluation，而文章建议的是 Acceptance Criteria -> LLM -> Output -> Verification。这与目前兴起的 DSPy（Declarative Self-improving Language Programs） 等框架的理念不谋而合，即“断言优于生成”。

4. 行业影响：推动“结构化输出”成为标配

• 潜在影响： 这一观点将加速行业从“聊天框”向“表单化/结构化交互”的转变。未来的 AI 应用可能不再是一问一答，而是用户填写需求表单（定义标准），AI 返回结构化结果。这会倒逼模型厂商优化 Structured Output 的能力（如 OpenAI 最近推出的 JSON Mode）。

5. 争议点与批判性思考

• 认知负荷转移： 这是一个显著的争议点。[你的推断] 将验收标准前置，实际上是把“理解需求”的难度从模型转移给了用户。如果用户具备清晰定义标准的能力，他往往自己就能解决问题（或使用传统代码）。LLM 的魅力在于处理模糊性，强制前置标准可能会降低 AI 对非专业用户的友好度。
• “标准”本身的幻觉： 用户定义的标准可能本身就有逻辑漏洞或冲突。LLM 在面对冲突的约束时，表现往往比面对模糊的意图时更差。

三、 实际应用建议与验证

实际应用建议

1. 采用“三明治”策略： 即使是探索性任务，也应在一轮发散后，引入验收

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 示例1：文本分类器（情感分析）
def sentiment_analyzer(text, positive_keywords, negative_keywords):
    """
    根据预定义的关键词判断文本情感
    :param text: 待分析文本
    :param positive_keywords: 正面关键词列表
    :param negative_keywords: 负面关键词列表
    :return: 情感分类结果
    """
    text_lower = text.lower()
    pos_score = sum(1 for word in positive_keywords if word in text_lower)
    neg_score = sum(1 for word in negative_keywords if word in text_lower)
    
    if pos_score > neg_score:
        return "正面"
    elif neg_score > pos_score:
        return "负面"
    else:
        return "中性"

# 使用示例
positive_words = ["优秀", "满意", "推荐", "高效"]
negative_words = ["差", "慢", "失望", "问题"]
print(sentiment_analyzer("这个服务非常高效，我很满意！", positive_words, negative_words))

 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

# 示例2：代码质量检查器
def code_quality_checker(code, rules):
    """
    根据预定义规则检查代码质量
    :param code: 待检查代码
    :param rules: 质量检查规则字典
    :return: 检查结果列表
    """
    issues = []
    lines = code.split('\n')
    
    for i, line in enumerate(lines, 1):
        # 检查行长度
        if len(line) > rules['max_line_length']:
            issues.append(f"第{i}行过长: {len(line)}字符")
            
        # 检查禁止使用的函数
        for func in rules['forbidden_functions']:
            if func in line:
                issues.append(f"第{i}行使用了禁止函数: {func}")
                
    return issues

# 使用示例
quality_rules = {
    'max_line_length': 80,
    'forbidden_functions': ['eval', 'exec']
}
code_sample = "result = eval(user_input)\n" + "x = 1\n" + "print('This is a very long line that exceeds the maximum allowed length of 80 characters')"
print(code_quality_checker(code_sample, quality_rules))

 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

# 示例3：数据验证器
def data_validator(data, schema):
    """
    根据预定义模式验证数据
    :param data: 待验证数据字典
    :param schema: 验证模式字典
    :return: 验证结果和错误信息
    """
    errors = []
    
    for field, rules in schema.items():
        # 检查必填字段
        if rules['required'] and field not in data:
            errors.append(f"缺少必填字段: {field}")
            continue
            
        # 检查字段类型
        if field in data and not isinstance(data[field], rules['type']):
            errors.append(f"{field}类型错误，应为{rules['type'].__name__}")
            
        # 检查字符串长度
        if field in data and isinstance(data[field], str) and 'max_length' in rules:
            if len(data[field]) > rules['max_length']:
                errors.append(f"{field}超过最大长度{rules['max_length']}")
                
    return len(errors) == 0, errors

# 使用示例
user_schema = {
    'username': {'type': str, 'required': True, 'max_length': 20},
    'age': {'type': int, 'required': True},
    'email': {'type': str, 'required': False}
}
user_data = {'username': 'john_doe_123456789012345', 'age': '25'}
print(data_validator(user_data, user_schema))

案例研究

1：Klarna (客服自动化)

1：Klarna (客服自动化)

背景: Klarna 是一家欧洲领先的金融科技和“先买后付”服务公司，拥有庞大的全球用户基础，每天需要处理海量涉及退款、支付状态查询和账户管理的客户咨询。

问题: 在引入大模型（LLM）之前，传统的聊天机器人往往只能处理预设的简单关键词匹配，一旦用户表达稍微偏离脚本，机器人就会失效并转人工，导致用户体验差且人工成本高企。直接使用通用 LLM 虽然流畅，但容易产生幻觉（胡乱承诺退款）或语气不专业，无法直接上线。

解决方案: Klarna 定义了严格的“护栏”和验收标准。他们并没有直接让 LLM 自由发挥，而是明确了“必须基于内部知识库回答”、“不得承诺未经授权的退款”以及“必须识别意图并执行特定 API 操作”等标准。基于这些标准，他们微调了模型并构建了系统，使 LLM 在回答每一个问题时都必须先匹配这些预设的业务规则。

效果: 据 Klarna 官方发布的数据，该 AI 助手上线后直接处理了三分之二的客户咨询（约 230 万次对话），相当于 700 名全职客服的工作量。客服 Resolution（问题解决率）从传统的聊天机器人的极低水平提升至与人工相当的水平，且重复查询率下降了 25%，预计每年可为公司节省 4000 万美元的成本。

2：某大型跨国制造企业 (内部知识检索)

2：某大型跨国制造企业 (内部知识检索)

背景: 该企业拥有数十年的技术积累，数百万份 PDF 格式的技术手册、维修指南和合规文档分散在不同部门的系统中。工程师和现场维修人员经常需要查找特定零件的兼容性或故障排除步骤。

问题: 员工在内部搜索时，使用传统关键词搜索往往返回大量不相关的文档，需要逐个点开阅读才能找到答案，效率极低。直接引入通用 LLM（如 GPT-4）进行问答时，虽然能总结文档，但经常“编造”不存在的零件型号或给出过时的安全建议，这在工业场景下是绝对不可接受的。

解决方案: 企业 IT 部门与业务部门首先确立了“零容忍幻觉”的验收标准：所有回答必须严格基于检索到的原文片段，且必须包含文档来源出处。 基于此标准，他们采用了 RAG（检索增强生成）架构，强制 LLM 在生成回答前必须先检索相关文档片段，并使用 Prompt Engineering 要求模型：“仅基于提供的上下文回答，如果上下文中没有答案，请直接说不知道，不要编造。”

效果: 系统上线后，技术人员的平均问题解决时间从原来的 30 分钟以上缩短至 2 分钟以内。由于强制要求引用来源，员工可以直接点击来源链接验证准确性，对 AI 回答的信任度大幅提升。内部调研显示，该工具被认为是年度最有价值的效率工具，解决了“知识存在于文档中但找不到”的长期痛点。

3：Brex (金融风控与审批)

3：Brex (金融风控与审批)

背景: Brex 是一家为初创公司和企业提供金融服务的公司，专注于企业信用卡和支出管理软件。他们需要处理大量的商户代码（MCC）分配、交易风险评估以及客户合规性审查。

问题: 金融领域的合规性要求极强，且逻辑复杂。使用通用 LLM 辅助分析交易时，模型可能会因为缺乏最新的合规法规或对特定商业语境理解不足，而给出错误的分类建议。例如，将高风险交易误判为低风险，导致合规问题。

解决方案: Brex 的工程团队采取了“以输出为导向”的策略。他们并不直接询问 LLM“这笔交易是否有风险”，而是定义了结构化的验收标准。他们将复杂的业务逻辑转化为 JSON Schema 或 Pydantic 模型，强制 LLM 输出必须符合特定的数据结构（如 risk_score: float, reasoning: str, category: enum）。只有当 LLM 的输出能够通过这些严格的类型检查和逻辑校验时，才会被系统接受并执行。

效果: 这种结构化输出的方法极大地提高了 LLM 在生产环境中的可靠性。通过将验收标准前置为代码级别的约束，Brex 成功地将 LLM 集成到了其核心的风控流程中，实现了对复杂交易场景的自动化分析，将人工审核的介入率降低了 40% 以上，同时保持了极高的合规准确性。

最佳实践

最佳实践指南

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

说明: 在向 LLM 发出请求前，必须定义“好”的具体标准。模糊指令会导致意图猜测，而明确指标（如案例数量、字数限制、语气要求）能确立清晰的优化目标。

实施步骤:

1. 列出硬性指标（字数、格式、关键数据）。
2. 定义软性指标（风格、语气、受众）。
3. 将指标转化为具体约束写入 Prompt。

注意事项: 避免主观词汇，应使用可度量描述，如“无需专业知识即可读懂”。

实践 2：提供评估范例

说明: 提供 1-2 个具体样本能帮助模型快速建立对齐，理解期望的格式和深度，有效处理复杂任务。

实施步骤:

1. 准备理想输出样本。
2. 标注“期望输出示例”。
3. 必要时提供“反面教材”并标注“避免此类输出”。

注意事项: 示例需与实际任务难度和类型一致，防止误导。

实践 3：引入结构化验证机制

说明: 对于高难度任务，要求模型在生成前进行自我检查或列出清单，能强制对照标准审核，提高通过率。

实施步骤:

1. 增加“预检”步骤，要求列出核对清单。
2. 要求末尾附上自我评估。
3. API 调用时可要求输出 JSON 格式验证结果。

注意事项: 验证会增加 Token 消耗，建议仅在关键任务中使用。

实践 4：迭代式细化标准

说明: 建立“设定-测试-调整”闭环。将未达标部分转化为新约束，持续优化 Prompt。

实施步骤:

1. 记录不符合预期的具体部分。
2. 分析原因（指令缺失、歧义或偏差）。
3. 将修正规则添加到下一轮对话。

注意事项: 保存有效的 Prompt 版本，建立模板库。

实践 5：定义输出格式与边界条件

说明: 明确呈现方式（Markdown、JSON）和内容边界（如“不涉及 X”），减少幻觉和不可用内容。

实施步骤:

1. 指定结构（如 XML 格式）。
2. 设定否定性约束（“不要做什么”）。
3. 规定异常处理方式（如“信息不足时请提问”）。

注意事项:

实践 6：角色扮演与视角设定

说明: 设定专家角色（如“资深编辑”）可隐性植入专业标准，自动调用领域规范满足要求。

实施步骤:

1. 定义角色：“10 年经验 [领域] 专家”。
2. 赋予职责：“确保符合 [行业标准]”。
3. 结合具体验收标准使用。

注意事项: 角色需与任务高度相关，避免无关设定导致风格混乱。

学习要点

• 基于您提供的主题，以下是关于“LLMs work best when the user defines their acceptance criteria first”的 5 个关键要点总结：
• 在与LLM交互前预先定义验收标准，是获得高质量输出的最关键前置步骤。
• 明确的“完成定义”能将模糊的意图转化为可执行的指令，显著减少模型产生幻觉或跑题的概率。
• 设定具体的格式、长度或内容限制等约束条件，能大幅降低后续人工审核与修改的时间成本。
• 这种“以终为始”的提示策略能将AI从被动的生成者转变为符合特定标准的可靠协作者。
• 通过预先确立评估基准，用户可以更客观地判断模型输出是否满足业务或技术需求。

常见问题

1: 为什么在提示词中明确定义“验收标准”能显著提升大模型的输出质量？

1: 为什么在提示词中明确定义“验收标准”能显著提升大模型的输出质量？

A: 大语言模型本质上是基于概率进行预测的，如果没有明确的约束，它们倾向于生成通用的、冗长的或“安全”的回答。当用户预先定义了验收标准时，实际上是在为模型设定了一个明确的“目标状态”和“边界条件”。这使得模型能够将计算资源集中在满足这些特定条件上，而不是发散到无关的细节中。例如，告诉模型“生成一段代码”与“生成一段时间复杂度为 O(n)、包含错误处理且符合 PEP8 规范的 Python 代码”，后者会迫使模型进行更深层的逻辑推理和自我审查，从而大幅提高输出的可用性。

2: 什么是定义验收标准的最佳实践？

2: 什么是定义验收标准的最佳实践？

A: 定义验收标准的核心在于具体化和可度量性。最佳实践包括：

1. 格式约束：明确指定输出格式（如 JSON、Markdown 表格、纯文本列表）。
2. 长度限制：设定字数或段落的上下限，防止模型生成冗余信息。
3. 结构化要求：如果需要代码，指定编程语言和编码规范；如果需要文本，指定语气（正式、非正式）和受众群体。
4. 负面约束：明确列出“不要做什么”，例如“不要使用被动语态”或“不要包含外部链接”。
5. 示例：提供“少样本”示例，展示符合标准的输出和不符合标准的输出的区别。

3: 这种方法是否适用于所有类型的任务？

3: 这种方法是否适用于所有类型的任务？

A: 虽然定义验收标准对绝大多数任务都有帮助，但其重要性和表现形式有所不同。

• 中等适用：创意写作、头脑风暴。此时标准应更多关注风格、情节走向或包含的关键元素，而非死板的限制，以免扼杀创造力。
• 低度适用：纯粹的开放式探索或闲聊。过度的标准限制可能会让对话显得生硬和机械。

4: 如果我不懂技术术语，应该如何描述我的验收标准？

4: 如果我不懂技术术语，应该如何描述我的验收标准？

A: 你不需要使用技术术语，只需要使用自然语言清晰地描述“好的结果”是什么样的。采用“角色扮演”和“类比”的方法非常有效。例如，你可以对模型说：“假设你是一位拥有20年经验的资深编辑，请重写这段文章。我的验收标准是：文章读起来要像《华尔街日报》的报道一样专业，没有语法错误，并且能让一个高中生也能看懂其中的金融概念。”大模型非常擅长理解这种基于上下文和角色的自然语言描述。

5: 在提示词工程中，验收标准应该放在开头还是结尾？

5: 在提示词工程中，验收标准应该放在开头还是结尾？

A: 这取决于任务的复杂度和模型的架构，但通常有两种有效的策略：

1. 前置法：将标准放在最开头。这种做法符合“先设定目标再执行”的逻辑，有助于模型在生成整个回答的过程中始终保持对目标的关注，特别适合长文本生成任务。
2. 后置法：将标准放在指令的最后。由于模型在处理上下文时，对结尾的信息给予的权重往往更高（近因效应），将关键约束放在最后可以起到强提醒的作用，适合防止模型在最后时刻“胡言乱语”或忽略格式。 对于复杂任务，最稳妥的方式是首尾呼应，即在开头设定目标，在结尾再次强调关键的否定性约束。

6: 大模型真的能“检查”自己的输出是否符合验收标准吗？

6: 大模型真的能“检查”自己的输出是否符合验收标准吗？

A: 现代的大模型具备一定的元认知能力，但完全依赖它们自我检查是有风险的。更有效的方法是引入“两步走”机制：

1. 生成阶段：让模型根据标准生成内容。
2. 验证阶段：在提示词中要求模型在生成内容后，强制增加一个步骤，让其列出“输出内容如何满足了上述验收标准”的对照表。 这种显式的验证步骤能迫使模型再次审视自己的输出，修正之前遗漏的细节。如果验收标准非常严格（如代码安全），建议还是使用外部工具或人工进行最终复核。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 假设你需要让 LLM 为一篇科技文章写摘要。请设计一个包含“通过标准”的提示词，要求摘要必须包含三个关键要素，且字数限制在 100 字以内。

提示**: 思考如何将“三个关键要素”和“100 字以内”转化为明确的指令，并告诉 AI 如果不满足这些条件应该怎么做（例如：重写）。

引用

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

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

站内链接

• 分类： 大模型 / 产品与创业
• 标签： LLM / 验收标准 / Prompt / 用户需求 / AI交互 / 工程化 / 效果优化 / HackerNews
• 场景： 大语言模型 / AI/ML项目

相关文章

• LLM效果优化：用户预先定义验收标准
• Claude：打造用于深度思考的交互空间
• Claude：一个用于深度思考的交互空间
• Claude：打造用于深度思考的AI交互空间
• AI对工程类岗位的影响或与预期不同 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。