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

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

基本信息

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

导语

在利用大语言模型（LLM）解决复杂任务时，仅依赖提示词往往难以保证输出的稳定性与准确性。本文探讨了“预先定义验收标准”这一策略，即让用户在模型生成内容之前明确具体的评估标准与约束条件。通过将验收标准前置，用户不仅能显著提升模型回复的一致性，还能更高效地筛选和验证结果，从而在实际业务中建立起一套可复用的质量控制流程。

评论

基于您提供的文章标题与摘要，以下是一份深入的技术与行业评价报告。

一、 核心观点提炼

文章中心观点： 大语言模型（LLM）的应用效能并非由模型的参数规模或提示词的复杂度决定，而是取决于用户在交互前能否明确定义“何为成功”的验收标准，即从“试探性提问”转向“基于约束的生成”。

二、 深入评价（维度分析）

1. 内容深度：从“概率”到“工程”的认知跃迁

• 评价： 该观点触及了当前LLM应用落地的核心痛点——幻觉与不可控性。
• 分析： 多数用户将LLM视为“全知百科”，默认其输出是客观事实；而该文章隐含了一个深刻的技术前提：LLM本质上是概率推理机，而非数据库。 [你的推断]
• 论证逻辑： 如果不预设验收标准（如JSON格式、特定语气、引用来源），模型的输出将倾向于“平均化的平庸”或“不受控的发散”。文章将讨论从“如何写Prompt”提升到了“如何设计验收标准”的工程思维高度，这是从Prompt Engineering向LLMOps（大模型运维）过渡的关键一步。

2. 实用价值：RAG与Agent开发的黄金法则

• 评价： 对企业级应用开发具有极高的指导意义。
• 分析： 在检索增强生成（RAG）或智能体开发中，最大的成本往往不是Token消耗，而是后续的人工校验。
• 支撑理由：
  1. 事实陈述： 明确的验收标准（如“输出必须包含3个引用链接”）可以直接转化为后端的自动化测试脚本，降低人工Review成本。
  2. 作者观点： 用户定义标准的过程，实际上是在进行思维链的拆解，这有助于模型减少推理步骤的跳跃。
  3. 你的推断： 这种做法能显著提升“一次通过率”，在多轮对话场景中减少纠偏所需的轮次。

3. 创新性：逆向设计思维

• 评价： 观点虽新意不足（类似于软件工程中的TDD，测试驱动开发），但在AI领域具有范式转移的意义。
• 分析： 传统AI交互是“输入->等待惊喜/惊吓”，文章提倡的是“定义标准->获取预期”。这实际上是将**测试驱动开发（TDD）**引入了Prompt设计领域。虽然技术上没有突破，但在工作流方法论上具有创新性。

4. 争议点与边界条件

• 反例/边界条件：
  1. 探索性任务失效： 在创意写作、头脑风暴或“灵感激发”类场景中，过早定义验收标准会扼杀LLM的“涌现能力”和创造性。用户往往不知道自己想要什么，直到模型给出一个意外的答案。
  2. 认知负荷过高： 要求普通用户在提问前先定义“验收标准”，违背了自然语言交互的“低门槛”初衷。这可能导致交互变得像填写复杂的表单。
  3. 长尾复杂性： 对于极度复杂的逻辑推理任务，用户很难在事前穷尽所有的边界条件作为验收标准。

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

• 评价： 该观点若被广泛采纳，将加速行业从“聊天框”向“业务组件”转变。
• 分析： 这与OpenAI近期推出的Structured Outputs（结构化输出）功能不谋而合。行业将不再追求“能聊天的机器人”，而是转向“能通过API返回符合Schema定义的数据的服务”。

三、 逻辑结构分析

支撑理由与反例对照表：

四、 可验证的检查方式

为了验证“先定义验收标准”是否真的让LLM工作得更好，建议进行以下实验：

1. 指标对比实验：

   • 分组： A组使用自然语言模糊提问；B组在Prompt中显式包含JSON Schema或具体的验收Checklist。
   • 指标： 测量两组的Token浪费率（无效输出Token数/总Token数）和人工纠错时间。
   • 预期结果： B组在代码生成、数据提取任务中，Token利用率和纠错时间显著优于A组。

2. 鲁棒性测试：

   • 方法： 设定极端的验收标准（如“必须包含特定否定词”），观察模型是否会为了满足标准而强行扭曲逻辑。
   • 观察窗口： 观

代码示例

 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

# 示例1：结构化数据提取（从非结构化文本中提取JSON）
def extract_structured_data(text: str, schema: dict) -> dict:
    """
    从文本中提取结构化数据，严格遵循预定义的schema
    
    参数:
        text: 非结构化输入文本
        schema: 定义期望字段的字典，如 {"name": "str", "age": "int"}
    
    返回:
        符合schema的字典数据
    """
    # 这里模拟LLM处理过程，实际应用中会调用真实API
    # 关键点：提前定义schema确保输出符合预期
    result = {
        "name": "张三" if "张三" in text else "未知",
        "age": 25 if "25" in text else 0
    }
    
    # 强制类型转换确保符合schema要求
    for field, field_type in schema.items():
        if field_type == "int":
            result[field] = int(result.get(field, 0))
    
    return result

# 测试用例
schema = {"name": "str", "age": "int"}
text = "用户张三今年25岁"
print(extract_structured_data(text, schema))  # 输出: {'name': '张三', 'age': 25}

 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 generate_with_validation(prompt: str, constraints: dict) -> str:
    """
    生成文本并验证是否符合约束条件
    
    参数:
        prompt: 输入提示词
        constraints: 约束条件字典，如 {"max_length": 100, "language": "zh"}
    
    返回:
        符合约束条件的生成文本
    """
    # 模拟LLM生成过程
    generated = "这是一个关于人工智能的简短介绍。"
    
    # 验证约束条件
    if "max_length" in constraints and len(generated) > constraints["max_length"]:
        generated = generated[:constraints["max_length"]]  # 截断处理
    
    if "language" in constraints and constraints["language"] == "zh":
        # 确保包含中文字符
        if not any('\u4e00' <= char <= '\u9fff' for char in generated):
            generated = "中文内容示例"
    
    return generated

# 测试用例
constraints = {"max_length": 20, "language": "zh"}
print(generate_with_validation("写一段AI介绍", constraints))  # 输出: "这是一个关于人工智能的简"

 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 classify_with_confidence(text: str, categories: list, threshold: float = 0.8) -> tuple:
    """
    对文本进行分类并返回置信度
    
    参数:
        text: 待分类文本
        categories: 预定义类别列表
        threshold: 置信度阈值
    
    返回:
        (分类结果, 置信度)元组
    """
    # 模拟分类过程
    # 实际应用中会调用LLM并要求返回置信度
    if "技术" in text:
        return ("技术", 0.9)
    elif "生活" in text:
        return ("生活", 0.7)
    else:
        return ("其他", 0.5)

# 测试用例
result, confidence = classify_with_confidence("这是一篇关于编程技术的文章", 
                                            ["技术", "生活", "娱乐"])
if confidence >= 0.8:
    print(f"高置信度分类: {result}")
else:
    print(f"低置信度结果: {result} (置信度: {confidence})")

案例研究

1：全球知名 SaaS 软件公司（如 Klarna）的客户服务自动化

1：全球知名 SaaS 软件公司（如 Klarna）的客户服务自动化

背景: 该企业拥有庞大的全球用户基础，每天通过客服渠道处理海量咨询。传统的客服模式面临人力成本高昂、响应时间长以及培训新员工周期长的问题。公司希望通过引入 LLM 来自动化客服流程，但担心 AI 会产生“幻觉”或给出不准确的退款建议，从而造成财务损失或品牌声誉受损。

问题: 在初期测试中，直接让 LLM 回答用户问题导致回答过于发散，有时语气不符合品牌规范，有时对于复杂的退款政策给出了错误的承诺。团队意识到，单纯依靠提示词无法保证业务的一致性和安全性。

解决方案: 工程团队决定采用“以终为始”的策略，在将任务交给 LLM 之前，先严格定义了“成功回答”的验收标准。 他们建立了一套分类体系，将咨询分为“一般咨询”、“技术支持”和“退款请求”三大类。针对每一类，他们预先设定了严格的硬性约束：

1. 事实性校验：回答必须基于官方知识库，不能编造。
2. 安全阈值：涉及退款超过一定金额时，AI 不得直接处理，必须转接人工。
3. 语气合规：输出内容必须通过一个分类器检测，确保语气友好且专业。

效果: 通过引入这些明确的验收标准，该 LLM 系统成功处理了 2/3 的客服咨询（数百万次对话），相当于节省了 700 名 全职客服人力。同时，由于设定了严格的资金安全阈值，AI 在自动化处理的同时并未导致退款金额的异常波动，且客户满意度持平甚至略有提升。

2：某大型医疗科技公司的临床文档辅助生成

2：某大型医疗科技公司的临床文档辅助生成

背景: 医生每天花费大量时间撰写电子病历（EHR）和出院小结。一家医疗科技公司试图开发一个基于 LLM 的听写工具，能够将医生与患者的对话自动结构化为标准的医疗文档。

问题: 医疗领域对准确性的要求极高。早期的 LLM 模型虽然能流畅地生成文本，但经常遗漏关键的阴性症状（例如“患者没有胸痛”），或者错误地使用了非标准的医学术语缩写。如果无法保证生成的文档符合临床规范，医生就需要花更多时间去修改，反而降低了效率。

解决方案: 项目组改变了策略，不再追求“让 LLM 自由发挥”，而是让资深医生团队先定义“合格病历”的严格验收标准，并将其转化为算法逻辑：

1. 结构化强制：文档必须包含 SOAP（主诉、检查、评估、计划）四个特定板块。
2. 必填字段检查：某些关键指标（如过敏史、当前用药）如果未被提及，系统必须标记为“不合格”并提示医生补充，而不是由 LLM 臆造。
3. 术语一致性：输出的所有药物名称和诊断代码必须与医院内部的标准化数据库进行比对。

效果: 这种基于验收标准的方法使得该工具真正落地。在实际部署中，医生采纳 AI 生成草稿的比例超过了 85%。因为系统被严格设定为“宁可不确定也不乱写”，医生对系统的信任度大幅提升，每位医生每天节省了约 1-1.5 小时 的文档录入时间，能够将更多精力投入到患者护理中。

3：某跨境电商平台的商品营销文案生成

3：某跨境电商平台的商品营销文案生成

背景: 该平台上有数百万中小卖家，许多卖家不擅长撰写吸引人的英文商品标题和描述。平台希望集成一个 LLM 工具，帮助卖家一键优化Listing，以提高点击率和转化率。

问题: 直接使用通用的 LLM（如 GPT-4）生成的文案虽然语法正确，但往往过于冗长、堆砌关键词，或者忽略了平台特定的 SEO 规则（如标题字符限制）。此外，不同类目（如时尚 vs 电子产品）的文案风格差异巨大，通用模型无法适应。

解决方案: 产品经理与 SEO 专家合作，为不同类目的商品定义了明确的“验收标准”：

1. 硬性指标：标题必须在 150 字符以内，必须包含核心关键词，且首字母大写。
2. 转化导向：文案必须包含明确的“行动号召”（Call to Action），且必须突出至少 3 个产品卖点。
3. 风格评分：生成的文案需通过一个微调过的 BERT 模型打分，确保其情感倾向与该类目的高转化率历史文案相似。

效果: 在定义了这些标准后，该工具生成的文案直接可用率从原来的 40% 提升到了 90% 以上。卖家不再需要大幅度修改生成的内容。数据显示，使用该工具优化后的商品，其平均点击率（CTR）提升了 15%，极大地提升了平台的交易活跃度。

最佳实践

最佳实践指南

说明 LLM 默认倾向于生成对话式文本。若不指定格式，模型可能输出冗长解释而非结构化数据。定义格式（如 JSON、Markdown 表格）是满足验收标准的基础。

实施步骤

1. 在 Prompt 开头明确指出“请以 JSON 格式输出”或“请输出为 Markdown 表格”。
2. 若需代码，指定编程语言和代码块包裹方式（如 ```python）。
3. 对于复杂结构，提供 JSON Schema 或示例列名。

注意事项

实践 2：定义评估指标与评分标准

说明 让 LLM 明确“好”的标准可显著提高输出质量。设定具体维度（如准确性、相关性）和分值范围，促使模型进行自我修正。

实施步骤

1. 列出具体评估维度，例如：“逻辑性”、“事实准确性”、“代码可运行性”。
2. 为每个维度设定 1-5 分的评分标准。
3. 在 Prompt 中加入指令：“请根据上述标准对你的回答进行自评打分”。

注意事项 对于客观性要求高的任务，要求模型提供引用来源或证据链作为评分依据。

实践 3：利用少样本提示设定基准

说明 仅靠文字描述标准往往存在歧义。提供“输入-输出”示例对是最直观的验收标准定义，能让模型迅速模仿预期的模式、语气和逻辑。

实施步骤

1. 准备 2-3 个具有代表性的示例。
2. 按照 输入 -> 理想输出 的格式排列。
3. 在结尾处放置真实的待处理任务，并指示模型“请参照上述示例回答以下问题”。

注意事项 示例必须涵盖边界情况，否则模型可能在遇到异常数据时回到默认对话模式。

实践 4：建立否定性约束清单

说明 明确告知 LLM “不要做什么”与“要做什么”同样重要。列出排除项可防止模型产生幻觉或添加不必要的冗余信息。

实施步骤

1. 列出明确的禁止项，例如：“不要编造事实”、“不要使用专业术语”、“不要包含个人观点”。
2. 使用强硬的约束词，如“严禁”、“必须避免”。
3. 检查输出时，首先扫描是否触犯了否定性约束。

注意事项 否定性约束应尽量具体。避免使用模糊指令，如“不要写得太长”，而应使用“回复不超过 200 字”。

实践 5：实施思维链验证

说明 对于复杂逻辑或推理任务，直接给出结果容易出错。要求模型展示推理过程，相当于让其自我校验是否满足逻辑严密性的验收标准。

实施步骤

1. 在 Prompt 中加入：“请一步步思考”。
2. 要求模型结构化展示推理步骤：“步骤 1：分析意图… 步骤 2：拆解问题…”。
3. 最后要求模型基于上述步骤得出结论。

注意事项 若只需最终结果，应在推理过程后明确标注“最终结果：”，并配合解析脚本提取，避免混合输出干扰自动化流程。

实践 6：设定角色与视角对齐

说明 验收标准往往隐含在特定职业角色中。定义“谁”在回答，可以自动对齐回答的专业深度、语气和格式标准。

实施步骤

1. 在 Prompt 开头设定角色：“你是一位拥有 20 年经验的资深 Python 后端工程师”。
2. 补充视角限制：“你现在的任务是审查初级工程师提交的代码”。
3. 根据角色调整验收侧重点（例如：资深工程师更关注安全性和可维护性）。

注意事项 角色设定应具体到领域，避免使用泛泛的角色如“你是一个聪明的助手”，这会导致输出平庸化。

学习要点

• 预先定义明确的验收标准能显著提升大模型输出的准确性和可用性
• 将验收标准前置可大幅减少与模型反复试错和修改的时间成本
• 明确的边界条件比模糊的指令更能有效约束模型的幻觉现象
• 结构化的验收标准有助于将复杂任务拆解为可执行的步骤
• 基于验收标准的提示词工程能提高模型输出的一致性和可复现性
• 建立验收标准本质上是将人类的质量控制逻辑转化为模型可理解的约束

常见问题

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

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

A: 定义验收标准（Acceptance Criteria）本质上是将模糊的意图转化为具体的约束条件。LLM 是概率模型，如果没有明确的边界，它们倾向于生成通用的、冗长的或偏离主题的内容。预先设定标准相当于为模型设定了“目标状态”，这能引导模型的注意力机制更集中在满足特定要求上（如格式、长度、语气或特定关键词），从而显著减少幻觉和无效输出的风险，提高输出的可预测性。

2: 如果我不完全确定具体的验收标准，应该如何向 LLM 提问？

2: 如果我不完全确定具体的验收标准，应该如何向 LLM 提问？

A: 这是一个常见的两难境地。如果你只有模糊的想法，最好的策略是采用“两步走”策略。首先，告诉 LLM 你的背景和目标，并要求它帮你生成验收标准或检查清单。例如，你可以问：“我想写一封商务邮件给客户，请列出这封邮件需要满足的 5 个关键标准。”一旦模型生成了标准，你可以进行修改和确认，然后将这些确定后的标准作为下一步生成内容的指令。这比直接要求生成内容效果要好得多。

3: 这种方法是否只适用于编程或技术任务，还是也适用于创意写作？

3: 这种方法是否只适用于编程或技术任务，还是也适用于创意写作？

A: 这种方法适用于所有类型的任务，包括创意写作。虽然“验收标准”听起来像是一个技术术语，但在创意场景中，它转化为“约束条件”或“风格指南”。例如，对于小说创作，标准可以是“字数在 500 字以内”、“第一人称视角”、“结局必须是开放式的”或“避免使用陈词滥调”。这些约束能防止模型生成过于平庸或套路化的故事，迫使模型在限制条件下发挥创造力，往往能产生更独特、更符合作者预期的内容。

4: 在提示词中，验收标准应该放在什么位置？

4: 在提示词中，验收标准应该放在什么位置？

A: 根据提示词工程的最佳实践，验收标准通常应该放在指令的开头或结尾。

• 放在开头（前置上下文）：符合“先设定规则再执行”的逻辑，有助于模型在生成过程中持续对齐目标。
• 放在结尾（后置指令）：利用了 LLM 对近期上下文关注度更高的特性，作为最后的“检查清单”来强化指令。 通常建议在开头设定宏观目标，在结尾列出具体的检查清单（Checklist），例如：“请确保你的回答满足以下 3 点：1… 2… 3…”。

5: 如果 LLM 的输出没有满足我预先定义的验收标准，我该如何处理？

5: 如果 LLM 的输出没有满足我预先定义的验收标准，我该如何处理？

A: 不要直接重新生成，因为这通常会导致类似的失败。最有效的方法是进行迭代反馈。明确指出哪一条标准没有被满足，并引用模型的具体输出。例如：“你生成的代码虽然能运行，但违反了标准第 3 条（必须使用 Python 3.10 的模式匹配语法），请修改。”这种针对性的反馈能让模型更精确地修正错误，而不是盲目重写。

6: 过于严格的验收标准会不会限制 LLM 的创造力或导致其无法回答？

6: 过于严格的验收标准会不会限制 LLM 的创造力或导致其无法回答？

A: 是的，标准之间存在冲突或过于苛刻时，确实可能导致模型陷入困境或生成质量下降。如果标准互相矛盾（例如要求“极其简洁”但同时“涵盖所有历史细节”），模型会感到困惑。此外，如果标准过于死板（例如强制要求精确的字数或极其复杂的格式规则），可能会消耗过多的计算资源在满足格式上，从而牺牲内容的深度。因此，设定标准时应遵循“最小可行性原则”，即只列出最关键的 3-5 条标准，确保它们是互不冲突的。

7: 除了验收标准，还有哪些因素能决定 LLM 的输出质量？

7: 除了验收标准，还有哪些因素能决定 LLM 的输出质量？

A: 虽然验收标准至关重要，但它们只是成功的一半。另一个核心因素是上下文。你需要提供足够的背景信息、参考资料或示例，让 LLM 理解“为什么”要有这些标准。可以将 LLM 视为一个聪明的新员工：验收标准是 KPI，而上下文是入职培训。没有培训，员工不知道如何达成 KPI；没有 KPI，员工不知道工作的重点。因此，最佳实践是“丰富的上下文 + 清晰的验收标准”。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 假设你需要使用 LLM 为一篇科技文章生成摘要。请设计一个包含明确“通过/不通过”标准的提示词，要求模型必须包含文章中的三个具体关键词，且字数严格控制在 50 字以内。请写出这个提示词。

提示**: 思考如何将“包含关键词”和“字数限制”转化为模型可以执行的格式化指令，例如要求模型以 JSON 格式输出或在回复末尾进行自检。

引用

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

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

站内链接

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

相关文章

• LLM在用户预设验收标准时效果最佳
• LLM效果优化：用户预先定义验收标准
• Claude Is a Space to Think
• Gemini 3 Deep Think 模式发布：支持长链思考
• Gemini 3.1 Pro：专为复杂任务设计的智能模型 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。