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

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

基本信息

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

导语

在利用大语言模型（LLM）解决复杂任务时，许多开发者往往忽视了“前置验收标准”的重要性。本文探讨了为何在提示词中预先明确成功标准，能显著引导模型生成更精准、可验证的结果。通过这一视角的转变，读者将学会如何从被动接收模型输出，转变为主动定义质量边界，从而在工程实践中有效提升交付的一致性与可控性。

评论

核心论点： 文章主张将大语言模型（LLM）的应用模式从“开放式生成”转变为“基于标准的验证”。其核心逻辑是，只有当用户预先定义明确的验收标准时，LLM 才能从基于概率的生成器转化为可靠的工程工具。

支撑理由与边界分析：

1. 概率性本质的控制

   • 支撑理由： LLM 的底层机制是下一个 token 的概率预测。预设验收标准实际上是在数学上缩小了解空间，通过“约束引导生成”来提高输出的确定性，减少幻觉和平庸内容的产生。
   • 边界条件： 对于创造性探索类任务（如头脑风暴、艺术构思），过早设定严格的标准可能会限制模型的发散性思维，扼杀潜在的“涌现能力”。

2. 工程化：从“黑盒”到“白盒”

   • 支撑理由： 这一理念符合软件工程中的“测试驱动开发（TDD）”。先定标准后生成，使得 LLM 的输出可被量化评估，这是将 LLM 从实验性工具推向企业级生产环境的关键步骤。
   • 边界条件： 在高度复杂的逻辑推理任务中，用户往往难以在执行前定义出完美无缺的标准。若标准存在逻辑漏洞，模型可能会产生形式上符合标准但实质错误的输出。

3. 反馈回路的构建

   • 支撑理由： 明确的验收标准是实现自动化评估（如 LLM-as-a-Judge）的前提。清晰的标准使得“生成-评估-修正”的高效闭环成为可能，这对于开发复杂的 Agent 类应用至关重要。
   • 边界条件： 对于主观性极强的任务（如心理咨询、高情商沟通），成功往往依赖上下文感知而非硬性指标。强行量化标准可能会破坏对话的自然性和有效性。

事实陈述 / 作者观点 / 深度推断：

• [事实陈述]：目前的 LLM 架构存在固有的不确定性，业界正从单纯的 Prompt Engineering 转向包含 Evaluation 的系统工程。
• [作者观点]：用户必须掌握主动权，通过预先定义标准来解决模型输出的不可靠问题。
• [深度推断]：这预示了 AI 开发模式的转变——从单纯追求模型参数规模的“模型中心论”，转向追求更精准对齐和验证的“数据与评估中心论”。

多维度深入评价：

1. 内容深度：工程化视角的引入 文章触及了当前 AI 落地的核心痛点：如何将非确定性的 AI 融入确定性的业务流程。其深度在于没有停留在“如何写 Prompt”的操作层面，而是上升到了“AI 质量管理”的方法论层面。文章指出，LLM 在实际应用中的表现不仅由模型能力决定，更由“验证机制的严谨度”决定。这一逻辑符合控制论中的闭环控制原理。

2. 实用价值：解决信任赤字 对于企业级应用，该观点具有较高的参考价值。它通过引入“验收标准”，将 AI 的输出纳入现有的 QA（质量保证）体系，有助于缓解业务方对 AI 产生幻觉的担忧。例如，在代码生成场景中，要求输出必须通过单元测试，能显著提升交付的可信度。

3. 创新性：逆向设计思维 虽然“设定目标”并非新概念，但将其前置于 LLM 交互作为核心范式，是对传统“先提问后筛选”模式的修正。这实际上提倡一种**“逆向 Prompt 设计”**：先设计评估器，再设计生成器。这与学术界关注的“过程监督”而非单纯的“结果监督”相一致。

4. 可读性：逻辑的线性简化 此类观点将复杂的模型行为问题简化为“输入标准 vs 输出质量”的线性关系，逻辑链条清晰，降低了非技术背景决策者的认知门槛，便于在组织内部推行。

5. 行业影响：推动工具链演进 这一观点正在影响 AI 工具链的发展方向。主流框架（如 LangChain、LlamaIndex）均在加强“评估”和“追踪”功能。RAG（检索增强生成）架构的演进也体现了这一点：优化重点正从单纯的检索准确性转向“如何验证检索内容是否被正确使用”。

6. 争议点或不同观点

• 认知负荷的转移： 批评者认为，如果定义标准的成本过高，甚至接近于人工完成任务的成本，那么 AI 的工具价值将大打折扣。
• 标准的僵化性： 严格的标准可能导致 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
34
35
36
37
38
39
40
41
42

# 示例1：定义验证标准的数据清洗工具
def clean_data_with_criteria(raw_data, criteria):
    """
    根据预定义标准清洗数据
    :param raw_data: 原始数据列表
    :param criteria: 验证标准字典 {'min_length': int, 'required_fields': list}
    :return: 清洗后的数据和错误报告
    """
    cleaned_data = []
    errors = []
    
    for idx, item in enumerate(raw_data):
        # 检查最小长度要求
        if len(item.get('content', '')) < criteria['min_length']:
            errors.append(f"Item {idx} 内容长度不足")
            continue
            
        # 检查必填字段
        missing_fields = [f for f in criteria['required_fields'] if f not in item]
        if missing_fields:
            errors.append(f"Item {idx} 缺少字段: {missing_fields}")
            continue
            
        cleaned_data.append(item)
    
    return cleaned_data, errors

# 使用示例
raw_data = [
    {'id': 1, 'content': '有效数据', 'title': '示例'},
    {'id': 2, 'content': '短', 'title': '无效'},
    {'id': 3, 'content': '缺少标题'}
]

criteria = {
    'min_length': 3,
    'required_fields': ['id', 'content', 'title']
}

cleaned, errors = clean_data_with_criteria(raw_data, criteria)
print("清洗后数据:", cleaned)
print("错误报告:", errors)

 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

# 示例2：带验收标准的API请求处理
def fetch_data_with_validation(url, acceptance_criteria):
    """
    发起API请求并根据验收标准验证响应
    :param url: API端点
    :param acceptance_criteria: 验收标准字典 {'status_code': int, 'required_keys': list}
    :return: 验证后的数据或错误信息
    """
    import requests
    
    try:
        response = requests.get(url)
        
        # 验证状态码
        if response.status_code != acceptance_criteria['status_code']:
            return {'error': f'状态码不符合预期: {response.status_code}'}
            
        data = response.json()
        
        # 验证必需字段
        missing_keys = [k for k in acceptance_criteria['required_keys'] if k not in data]
        if missing_keys:
            return {'error': f'响应缺少必需字段: {missing_keys}'}
            
        return {'success': True, 'data': data}
        
    except Exception as e:
        return {'error': f'请求失败: {str(e)}'}

# 使用示例
criteria = {
    'status_code': 200,
    'required_keys': ['userId', 'id', 'title']
}

result = fetch_data_with_validation('https://jsonplaceholder.typicode.com/todos/1', criteria)
print("处理结果:", result)

 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

# 示例3：带质量标准的文本生成器
def generate_text_with_quality_check(prompt, quality_standards):
    """
    生成文本并根据质量标准验证
    :param prompt: 输入提示
    :param quality_standards: 质量标准字典 {'min_words': int, 'forbidden_words': list}
    :return: 生成的文本和质量报告
    """
    # 模拟LLM生成过程（实际应用中替换为真实API调用）
    generated_text = f"这是根据提示'{prompt}'生成的示例文本，包含足够的内容。"
    
    # 质量检查
    word_count = len(generated_text.split())
    has_forbidden = any(word in generated_text for word in quality_standards['forbidden_words'])
    
    quality_report = {
        'word_count': word_count,
        'passes_min_words': word_count >= quality_standards['min_words'],
        'no_forbidden_words': not has_forbidden,
        'score': 0
    }
    
    # 计算质量分数
    quality_report['score'] = sum([
        quality_report['passes_min_words'] * 50,
        quality_report['no_forbidden_words'] * 50
    ])
    
    return generated_text, quality_report

# 使用示例
standards = {
    'min_words': 5,
    'forbidden_words': ['错误', '失败']
}

text, report = generate_text_with_quality_check("写一段示例文本", standards)
print("生成文本:", text)
print("质量报告:", report)

案例研究

1：某跨国软件开发团队的代码重构项目

1：某跨国软件开发团队的代码重构项目

背景: 该团队负责维护一个拥有十年历史的核心业务系统，代码库庞大且包含大量遗留代码。团队希望利用 LLM 辅助进行代码重构，以提高代码可读性和维护性，但担心 AI 会引入难以察觉的逻辑错误。

问题: 初期，工程师直接让 LLM“优化这段代码”。结果 LLM 虽然生成了语法更现代、更简洁的代码，但往往改变了原有的异常处理逻辑，或者引入了不符合公司内部规范的命名方式。代码审查人员需要花费大量时间逐行检查，导致“AI 辅助”反而增加了审查负担，团队对 AI 生成代码的信任度极低。

解决方案: 团队改变了策略，在 Prompt 中预先定义了严格的“验收标准”。他们要求工程师在提交代码前，必须明确告诉 LLM：

1. 功能约束：必须保持现有的输入输出签名不变，且通过所有现有的单元测试。
2. 风格规范：必须遵守 Google Java Style Guide，且不得引入外部库。
3. 注释要求：必须为复杂的逻辑块添加解释性注释，说明修改原因。

效果: 通过预先设定这些硬性指标，LLM 生成的代码不再需要大幅度返工。代码审查的时间缩短了 40%，因为 AI 产出的代码已经符合了 90% 的规范要求。更重要的是，由于明确了“通过单元测试”这一强制标准，重构导致的线上 Bug 数量降至零。

2：某金融科技公司的客户服务自动化

2：某金融科技公司的客户服务自动化

背景: 该公司计划部署 LLM 驱动的客服机器人来处理复杂的理财产品咨询。由于金融行业的合规性要求极高，任何不准确的建议都可能导致法律风险。

问题: 在早期的测试中，LLM 虽然能够流畅地回答用户问题，但经常出现“幻觉”，编造不存在的理财产品，或者给出了过时的利率信息。此外，模型有时为了讨好用户，会给出不符合公司风险偏好（例如向保守型用户推荐高风险产品）的建议。

解决方案: 工程团队在系统层面引入了“护栏”，并在 Prompt 中植入了基于 RAG（检索增强生成）的验收标准：

1. 事实核查：LLM 必须仅基于检索到的知识库内容生成回答，如果知识库中没有答案，必须直接回复“无法回答”，不得自行编造。
2. 合规性校验：输出内容必须经过一个分类器检查，确保不包含承诺收益率、夸大宣传等违规词汇。
3. 结构化输出：回答必须包含具体的条款引用来源，以便人工审核。

效果: 引入验收标准后，机器人的回答准确率从 60% 提升至 95% 以上。由于模型学会了在不确定时拒绝回答，而非胡乱猜测，合规部门最终批准了该系统上线。实际运营中，客户投诉率相比人工客服时期下降了 15%，且成功拦截了 100% 的合规性风险话术。

3：电商营销文案的批量生成

3：电商营销文案的批量生成

背景: 一家大型电商平台的商家运营部门，需要在“双11”大促期间为成千上万的商品生成短标题和推广文案。人工撰写不仅耗时，而且风格难以统一。

问题: 运营人员最初尝试直接使用 LLM 生成文案，但发现模型生成的内容过于冗长、辞藻华丽但缺乏重点（如没有包含核心卖点“包邮”或“折扣”），且经常超出平台的字数限制（例如限制在 20 个字以内，模型却生成了 50 个字）。这导致运营人员仍需大量人工修改，效率提升不明显。

解决方案: 运营团队与技术人员合作，设计了一套包含明确约束的 Prompt 模板，定义了清晰的验收标准： 2. 关键词包含：必须包含特定变量 {折扣} 和 {核心卖点}。 3. 风格指南：语气必须紧迫且具有吸引力，禁止使用消极词汇。 4. 自我审查：要求 LLM 在生成文案后，自行检查是否满足上述条件，如果不满足则重新生成。

效果: 通过定义这些标准，LLM 生成文案的“可用率”（即无需修改即可直接上线的比例）从 30% 飙升到 85%。运营人员的工作重点从“撰写文案”转变为“审核和选择文案”，处理效率提升了 5 倍。此外，由于严格遵守了字数和关键词要求，商品的点击转化率相比人工撰写时期提升了 10%，因为机器生成的文案更直接地击中了用户痛点。

最佳实践

最佳实践指南

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

说明：在与 LLM 交互前，必须清晰定义“好的回答”的具体指标。模糊的期望会导致模糊的输出。

实施步骤：

1. 识别关键要素：在提问前明确回答必须包含的核心内容。
2. 转化为硬性约束：将要素转化为具体限制（如字数、格式、关键词）。
3. 显式列出：在提示词中明确写出这些约束条件。

注意事项：避免使用“写一篇好文章”等模糊指令，应改为“写一篇 500 字以内的文章，包含三个具体案例”。

实践 2：提供参考范例

说明：利用“少样本提示”，通过提供输入-输出示例，让 LLM 直观理解预期的质量标准和风格。

实施步骤：

1. 准备示例：筛选 1-3 个高质量示例。
2. 构建结构：按照“示例输入 -> 示例输出 -> 当前输入 ->”的逻辑编排提示词。
3. 确保一致性：保证示例的风格、语气与期望结果完全一致。

注意事项：示例质量至关重要。低质量示例会被 LLM 模仿，导致输出质量下降。

实践 3：建立评估清单

说明：建立验收机制，根据预设标准验证 LLM 输出，避免盲目接受结果。

实施步骤：

1. 设定指标：列出 3-5 个核心验收点（如事实准确性、代码可运行性）。
2. 逐一比对：对照指标严格检查输出内容。
3. 针对性修正：若未达标，明确指出具体偏差并要求修正。

注意事项：将评估标准直接写入提示词可提升准确率，例如：“请确保回答满足：1… 2… 3…”。

实践 4：采用迭代式优化策略

说明：将交互视为迭代循环，通过多轮对话逐步逼近完美结果，而非试图一次成型。

实施步骤：

1. 基线测试：第一轮仅定义核心需求，观察模型表现。
2. 识别偏差：分析输出，找出缺失或不满意的部分。
3. 追加约束：第二轮增加具体修正指令（如“压缩为三句话”）。

注意事项：迭代时需保留有效约束，仅增加新条件，防止指令冲突。

实践 5：定义负面约束

说明：明确“不想要什么”，通过负面约束剔除不符合标准的内容，提升精确度。

实施步骤：

1. 内容排除：列出禁止提及的内容（如特定术语、过时信息）。
2. 形式限制：规定禁止使用的格式（如“不使用 Markdown 表格”）。
3. 位置强调：将负面约束置于提示词末尾以增强效果。

注意事项：使用正向描述替代否定词以减少歧义，例如用“保持语气生动”代替“不要写得无聊”。

说明：强制要求特定输出结构，便于快速验收和后续程序化处理。

实施步骤：

1. 指定格式：明确要求 JSON、XML 或特定 Markdown 格式。
2. 定义字段：若为 JSON，须指定必须包含的字段名称。
3. 自我验证：要求 LLM 在输出末尾列出符合预设标准的自检信息。

注意事项：此方法可能限制创造性，建议仅在需要严格标准或数据集成时使用。

学习要点

• 根据您提供的内容（基于Hacker News关于“LLMs work best when the user defines their acceptance criteria first”的讨论），以下是总结出的关键要点：
• 明确验收标准是使用大模型获取高质量结果的最关键前置步骤，它能将模糊的意图转化为可执行的具体指令。
• 采用“逆向提示”策略，即先定义理想的输出形式和评估标准，再据此构建提示词，能显著提高输出的准确性。
• 通过提供具体的成功示例作为标准，可以引导模型更精准地理解任务需求，减少幻觉和偏差。
• 交互过程中应遵循“迭代优化”原则，根据预设标准对模型输出进行快速测试和反馈，以逐步逼近目标。
• 将复杂的任务目标拆解为具体的评估维度（如格式、语气、长度），有助于模型更稳定地满足预期。
• 建立清晰的“拒绝标准”与“接受标准”同样重要，这能帮助模型有效规避错误路径。

常见问题

1: 为什么在开始使用 LLM 之前定义验收标准如此重要？

1: 为什么在开始使用 LLM 之前定义验收标准如此重要？

A: 大语言模型（LLM）本质上是概率性的，即使用相同的提示词，模型也可能生成不同的输出。如果没有预先定义的验收标准，用户往往会陷入无休止的“试错循环”，不断微调提示词却不知道目标是什么。预先定义标准（例如“输出必须少于100字”或“必须包含三个具体例子”）可以将模糊的期望转化为可测试的指标，从而显著提高迭代效率，确保生成的结果真正符合业务或逻辑需求。

2: 什么是“验收标准”，在提示词工程中具体包含哪些内容？

2: 什么是“验收标准”，在提示词工程中具体包含哪些内容？

A: 在 LLM 的语境下，验收标准是指用来判断模型输出是否合格的一组规则或条件。具体内容通常包括： 2. 长度限制：字数或段落的上下限。 3. 内容约束：必须包含或禁止出现特定的关键词、语气（如正式、幽默）或语言风格。 4. 逻辑完整性：是否覆盖了问题的所有方面，或推理步骤是否完整。 将这些标准写入提示词，能帮助模型在生成内容时进行自我约束。

3: 如果我不定义验收标准，通常会发生什么问题？

3: 如果我不定义验收标准，通常会发生什么问题？

A: 如果缺乏明确标准，LLM 倾向于生成“看似合理”但“不可用”的内容。常见问题包括：

• 幻觉风险增加：模型可能为了填充篇幅而编造事实。
• 输出冗余：模型可能会生成大量无关的客套话或重复性解释。
• 格式混乱：输出的代码无法运行，或数据格式无法被后端程序直接解析。
• 评估困难：由于缺乏“合格”的基准，人工审核时容易产生主观偏差，导致返工率极高。

4: 如何将验收标准有效地写入提示词中？

4: 如何将验收标准有效地写入提示词中？

A: 最有效的方法是采用“角色设定 + 任务描述 + 约束条件 + 输出示例”的结构。

• 明确指令：不要只说“写一段简介”，而要说“写一段不超过50字的简介”。
• 使用负面约束：明确告诉模型“不要做什么”，例如“不要使用专业术语”或“不要包含任何法律免责声明”。
• 提供 Few-Shot 示例：给模型展示一个符合标准的输入和输出样例，这是让模型理解抽象标准的最快方式。

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

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

A: 是的，但具体侧重点不同。

• 对于生成式任务（如写作、翻译）：标准侧重于风格、语气、长度和创意限制。
• 对于分析式任务（如提取数据、分类）：标准侧重于准确率、格式（如 JSON/XML）和边界情况的处理（如遇到空值如何处理）。
• 对于代码生成：标准侧重于语法正确性、依赖库的限制以及是否通过特定的测试用例。 无论任务类型如何，明确“好的结果长什么样”都是成功的关键。

6: 定义验收标准是否意味着我就不需要检查 LLM 的输出了？

6: 定义验收标准是否意味着我就不需要检查 LLM 的输出了？

A: 不是。定义验收标准是为了提高 LLM 输出“一次性通过”的概率，但由于 LLM 的概率特性，它并不能保证 100% 的准确性。 实际上，定义标准更有利于后续的自动化测试。你可以根据预先定义的标准编写脚本（例如检查输出是否为有效 JSON，是否包含特定字段）来验证结果，这比人工逐字阅读要高效得多。因此，标准是连接“LLM 生成”与“程序验证”的桥梁。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 请尝试解决一个常见的写作任务：写一封商务邮件拒绝一位供应商的报价。请先在 Prompt 中明确列出三条具体的“验收标准”（例如：语气、必须包含的信息、字数限制），然后再让 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/ML项目

相关文章

• LLM效果优化：用户预先定义验收标准
• LLM在用户预设验收标准时效果最佳
• LLM 效果优化：用户需预先定义验收标准
• LLM效果优化：用户预先定义验收标准
• Agent评估显示AGENTS.md配置优于Skills 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。