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

基本信息

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

导语

在利用大语言模型（LLM）解决复杂任务时，单纯依赖模型往往难以保证输出质量，而预先定义明确的验收标准则是提升一致性的关键。本文将探讨为何“标准先行”能有效引导模型生成符合预期的结果，并分享具体的实施策略。通过阅读本文，读者将学会如何通过设定清晰的评估指标，将 LLM 从随意的对话工具转变为稳定可靠的工程化组件。

以下是对文章《LLMs work best when the user defines their acceptance criteria first》（LLM在用户预先定义验收标准时效果最佳）的深度评价。

一、核心观点与结构分析

1. 中心观点 文章主张，大语言模型（LLM）的应用效能不仅仅取决于模型本身的参数规模或提示词的巧妙程度，更关键在于用户在交互之初是否明确定义了可衡量的“验收标准”，即通过将模糊的意图转化为结构化的约束条件，使模型输出从“概率性续写”转向“目标导向的求解”。

2. 支撑理由（基于文章逻辑及行业视角）

降低幻觉风险： [事实陈述] LLM本质上是基于概率预测下一个token的模型。若不设定边界，模型倾向于“创造性补全”，导致编造事实。设定验收标准（如“仅基于提供的上下文回答”）相当于在推理空间中划定了可行域。
提升可复现性： [作者观点] 工程化应用的核心是稳定性。明确的验收标准使得输出可以通过自动化测试，从而将LLM从“聊天玩具”转变为“可靠组件”。
优化Token经济与调试效率： [你的推断] 当标准前置时，模型收敛速度更快，减少了多轮对话的Token消耗。同时，明确的失败标准（反例）能帮助开发者快速定位Prompt的缺陷，而非在模糊的“不好用”中反复试错。

3. 反例与边界条件

探索性创意任务： [你的推断] 在头脑风暴、艺术创作或寻找“意外发现”的场景下，过早设定严格的验收标准会扼杀LLM的发散性思维优势，导致输出平庸。
复杂黑箱推理： [事实陈述] 对于某些深度推理链极长的任务（如复杂的数学证明或奥德赛级别的代码重构），用户往往难以在事前定义出完备的中间过程验收标准，此时“事后评估”比“事前定义”更现实。

二、多维度深度评价

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

文章并未停留在“如何写好Prompt”的技巧层面，而是触及了AI工程化的本质——控制论。

论证严谨性： 文章隐含地指出了LLM的不确定性本质。通过引入“验收标准”，实际上是引入了一个负反馈机制。这种观点非常深刻，它揭示了当前LLM应用的一个痛点：我们试图用不确定性的模型去构建确定性的系统。
深度见解： 文章实际上是在倡导一种**“测试驱动开发（TDD）”在AI领域的变体**。正如TDD要求先写测试再写代码，文章要求先定标准再进行生成。这是将软件工程的最佳实践迁移到了AI工程领域，具有很高的理论契合度。

2. 实用价值：连接业务与技术的桥梁

对实际工作的指导： 极高。在实际企业落地中，最大的摩擦往往源于业务方说“我要一篇好的文章”，技术方调参后交付，业务方说“不对，这不是我想要的”。
解决痛点： 文章提出的方法论强制业务方在交互开始前进行结构化思考（例如：字数限制、必须包含的关键词、禁止出现的语气等）。这不仅是技术优化，更是需求管理的工具。它将模糊的主观感受转化为客观的通过/不通过指标，极大地降低了项目返工率。

3. 创新性：范式转换的呼吁

新观点： 虽然RAG（检索增强生成）和Agent技术中常提及“Grounding”（接地气/基于事实），但专门将“Acceptance Criteria”（验收标准）作为核心变量单独提出，强调了**“约束即智能”**的理念。
新方法： 文章暗示了一种新的交互范式：Standard -> Generation -> Verification，取代了传统的 Trial -> Error -> Modification。这种范式对于构建自动化Agent工作流尤为重要，因为Agent无法像人类一样通过直觉理解“再试一次”的模糊指令。

4. 可读性与逻辑性

表达清晰度： 标题直击要害，逻辑链条清晰（问题：LLM不可控 -> 方案：预设标准 -> 结果：效能提升）。
逻辑性： 文章逻辑自洽，但可能略显理想化。它假设用户具备清晰定义标准的能力，而在实际操作中，定义标准往往比解决问题本身更难（即“ specification problem”）。

5. 行业影响：推动“AI工程化”进程

潜在影响： 如果该观点被广泛采纳，将推动Prompt Engineering向更规范化的LLMOps方向发展。未来的Prompt模板可能不再仅仅是自然语言，而是包含YAML格式的元数据字段，专门用于定义验收指标（如Accuracy > 0.9, Tone < 0.5 aggressive）。这将催生新的工具链，专注于“标准定义”与“结果验证”的闭环。

三、争议点与批判性思考

标准的悖论：
- [你的推断] 如果用户能够完美定义验收标准，他往往已经清楚问题的答案，或者该问题的逻辑结构已经非常清晰，不再需要LLM的强推理能力。LLM最大的价值在于处理非结构化和定义模糊的问题。过分强调标准前置，可能限制了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 validate_output():
    prompt = """
    请分析以下客户反馈并提取关键信息，严格按照JSON格式输出：
    反馈内容："产品很好，但物流太慢了，客服态度也不错"
    
    要求输出格式：
    {
        "sentiment": "正面/负面/中性",
        "issues": ["问题列表"],
        "rating": 1-5
    }
    """
    
    # 模拟LLM响应（实际应用中替换为真实API调用）
    response = """
    {
        "sentiment": "正面",
        "issues": ["物流慢"],
        "rating": 4
    }
    """
    
    # 验证输出是否符合要求
    import json
    try:
        result = json.loads(response)
        assert all(k in result for k in ["sentiment", "issues", "rating"])
        print("✅ 输出符合要求:", result)
    except:
        print("❌ 输出格式不符合要求")

validate_output()

 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
# 示例2：多步骤任务分解
def task_decomposition():
    """演示如何将复杂任务分解为明确步骤"""
    prompt = """
    任务：分析这份销售报告并给出建议
    要求分步骤完成：
    1. 首先列出3个关键数据点
    2. 然后分析数据趋势（上升/下降）
    3. 最后给出2条具体建议
    
    每步用"步骤X："开头
    """
    
    # 模拟LLM响应
    response = """
    步骤1：关键数据点
    - 总销售额120万（同比+15%）
    - 新客户占比30%（同比+5%）
    - 客户流失率8%（同比-2%）
    
    步骤2：趋势分析
    销售额和新客户获取呈上升趋势，客户流失率有所改善
    
    步骤3：建议
    1. 加大对新客户的营销投入
    2. 继续优化客户服务流程
    """
    
    # 验证输出结构
    steps = [line for line in response.split('\n') if line.startswith('步骤')]
    if len(steps) == 3:
        print("✅ 任务分解完成，共3个步骤")
    else:
        print("❌ 步骤不完整")

task_decomposition()

 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 constraint_checking():
    """演示如何添加约束条件确保输出质量"""
    prompt = """
    请写一段关于Python的介绍，要求：
    - 总字数不超过100字
    - 必须包含"易学"和"强大"两个关键词
    - 避免使用技术术语
    """
    
    # 模拟LLM响应
    response = """
    Python是一种易学且强大的编程语言，广泛应用于数据分析、人工智能等领域。
    它的语法简洁清晰，适合初学者快速入门。
    """
    
    # 检查约束条件
    word_count = len(response.split())
    has_keywords = all(word in response for word in ["易学", "强大"])
    no_jargon = not any(term in response for term in ["面向对象", "动态类型"])
    
    checks = [
        (word_count <= 100, f"字数检查通过 ({word_count}/100)"),
        (has_keywords, "关键词检查通过"),
        (no_jargon, "术语检查通过")
    ]
    
    if all(c[0] for c in checks):
        print("✅ 所有约束条件满足")
        for c in checks:
            print(f"  - {c[1]}")
    else:
        print("❌ 约束条件不满足")
        for c in checks:
            print(f"  - {c[1]}")

constraint_checking()

案例研究

1：某全球知名 SaaS 软件供应商（客户支持部门）

背景: 该公司的客户支持团队每天需要处理数千工单，且涉及复杂的 B2B 技术问题。团队尝试引入 LLM 来辅助工程师生成回复草稿，以提高工单处理效率。

问题: 在初期试点中，模型生成的回复虽然流畅，但往往过于冗长或语气过于机械，甚至包含过时的产品功能信息。支持工程师不得不花费大量时间去修改和核实这些草稿，导致“使用 AI 反而比直接手写更慢”，团队对工具的接受度极低。

解决方案: 管理层改变了策略，不再直接让模型“写回复”，而是先定义了严格的“验收标准”并注入到系统提示词中。这些标准包括：

语气必须符合“简洁、专业、同理心”的品牌指南。
任何涉及产品功能的信息必须与内部知识库完全匹配，不得编造。
回复必须明确列出具体的“下一步行动建议”。

效果: 通过预先设定这些明确的验收标准，模型生成的回复可用性从 40% 提升至 85% 以上。工程师现在只需进行微调即可发送，平均工单处理时间（AHT）缩短了 30%，且客户满意度（CSAT）评分因回复更加标准化而有所提升。

2：某跨国金融科技公司的合规部门

背景: 该金融科技公司需要处理大量的信贷政策文档和监管报告。合规团队希望利用 LLM 自动审查内部交易记录，以识别潜在的违规行为。

问题: 由于金融监管规则极其细致且充满法律术语，通用的 LLM 经常产生“幻觉”，将正常的商业交易误判为违规（误报），或者漏掉复杂的违规模式（漏报）。业务部门因为担心法律责任，不敢采纳 AI 的分析结果。

解决方案: 技术团队与合规官合作，不再让模型进行“开放式分析”，而是预先定义了通过/不通过的“硬性标准”。他们构建了一个包含具体规则（如“涉及特定高风险国家的交易必须标记”）的验证层。LLM 的任务被重新定义为：仅根据这些预定义的规则清单提取证据并打分。

效果: 这种基于明确标准的实施方式，使得 AI 审查系统的误报率降低了 60%。合规部门开始信任该系统，并将其作为初级筛选工具，让资深合规官能够集中精力处理模型标记出的高风险案例，大幅提升了审计效率。

3：某电商平台的个性化推荐算法团队

背景: 该平台希望利用 LLM 根据用户的浏览历史，生成更加人性化的商品推荐理由，而不仅仅是展示商品列表。

问题: 早期的生成结果往往千篇一律（例如频繁出现“这款产品非常适合您”），缺乏针对性，有时还会对用户的某些浏览行为产生奇怪的解读，导致用户感到被冒犯或困惑，点击率不升反降。

解决方案: 产品经理定义了具体的“成功标准”，即生成的推荐语必须包含三个要素：引用用户具体的浏览行为（如“您昨天查看了跑鞋”）、结合当前商品的特定属性（如“缓震技术”）、以及一个明确的购买理由。只有同时满足这三点的生成内容才会被推送到前端。

效果: 在引入这些硬性约束条件后，推荐语的点击通过率（CTR）提升了 20%。用户反馈显示，这种基于具体行为和明确理由的推荐语显得更加“智能”和“贴心”，直接带动了转化率的增长。

最佳实践

最佳实践指南

实践 1：在交互前明确具体的成功标准

说明: 在向 LLM 发送提示词之前，必须先在脑海中或文档中定义清楚什么样的输出才算“好”。这包括内容的格式、长度、语调以及必须包含的关键信息点。模糊的目标会导致模糊的结果。

实施步骤:

在提问前，列出 3-5 个输出必须满足的具体条件。
将这些条件转化为明确的约束性语句。
在提示词的“系统指令”或“要求”部分明确告知模型这些标准。

注意事项: 避免使用“写一篇关于 X 的好文章”这种模糊指令，应改为“写一篇关于 X 的文章，字数在 500 字以内，必须包含三个具体案例，语调需客观中立”。

实践 2：提供结构化的评估标准

说明: 将抽象的质量要求转化为可量化的指标。如果任务涉及评分、分类或逻辑推理，应预先定义评分细则或分类标准，并让 LLM 在生成内容时遵循这些细则。

实施步骤:

定义输出内容的评分维度（如：准确性、相关性、创造性）。
为每个维度设定具体的分值范围或通过/失败阈值。
要求 LLM 在生成内容后，自行根据这些标准进行自我检查或打分。

注意事项: 确保标准之间没有冲突，且术语定义在上下文中是一致的。

实践 3：利用“反向提示”定义负面约束

说明: 除了定义“什么是好的”，还需要明确“什么是不可接受的”。通过列出负面清单，可以大幅减少 LLM 产生幻觉、格式错误或不符合预期内容的风险。

实施步骤:

列出绝对不希望出现的内容类型（例如：不得包含假设性数据、不得使用特定术语）。
在提示词中加入“不要…”或“避免…”的指令。
明确指出如果无法满足条件，模型应如何响应（例如：直接回答“我不知道”，而不是编造）。

注意事项: 负面约束不应过多，以免限制模型的创造力或导致指令冲突，通常聚焦于最关键的 2-3 个底线即可。

实践 4：要求模型输出符合标准的推理过程

说明: 对于复杂的逻辑或分析任务，仅要求结果往往难以验证其是否符合标准。要求模型展示其思考过程（Chain of Thought），可以更容易地判断其是否遵循了你的预设逻辑和标准。

实施步骤:

在提示词中增加“请一步步思考”或“展示你的推理过程”的指令。
检查模型输出的推理步骤是否严丝合缝地符合你的业务逻辑标准。
如果推理步骤偏离，及时纠正提示词。

注意事项: 确保推理过程简洁且切中要害，防止模型生成冗长且无关的内心独白。

实践 5：建立迭代式的反馈循环

说明: 一次性定义完美的标准很难。最佳实践是先定义初始标准，根据 LLM 的第一版输出，识别标准中的漏洞，然后更新标准并要求 LLM 修改。

实施步骤:

生成初版后，对照初始验收标准进行严格审查。
标记出不符合预期的具体部分。
构造反馈提示词：“上一版内容不符合标准 [X]，请修正。修改后的内容必须满足 [Y]。”
重复此过程直到满足所有核心标准。

注意事项: 将修正过程中发现的新标准补充到你的提示词模板中，以便下次直接使用。

实践 6：使用少样本示例来具象化标准

说明: 文字描述的标准往往存在歧义。提供 1-3 个具体的“输入-输出”示例，是让 LLM 理解验收标准最高效的方式。这被称为“Few-Shot Prompting”。

实施步骤:

准备一个符合标准的理想输出样本。
准备一个不符合标准的样本（可选，用于对比）。
在提示词中展示这些样本，并明确标注：“请参考示例 A 的风格和格式进行输出。”

注意事项: 示例必须与当前任务的难度和类型高度相似，否则模型可能会模仿错误的特征。

学习要点

基于您提供的标题和来源，以下是关于“LLMs work best when the user defines their acceptance criteria first”这一主题的关键要点总结：
在使用大语言模型（LLM）之前，用户必须预先明确具体的验收标准，以避免模型生成模糊或偏离目标的输出。
清晰的验收标准充当了提示词的边界条件，能显著减少模型产生幻觉或逻辑错误的可能性。
设定标准有助于将模糊的意图转化为可执行的指令，从而提高模型在首次尝试中生成高质量结果的概率。
这种方法将交互模式从“反复试错”转变为“精准交付”，大幅降低了优化提示词所需的时间成本。
预先定义标准实际上是在为模型建立评估逻辑，使其输出结果更符合特定领域或任务的专业要求。
明确的预期让用户更容易对模型输出进行客观验证，从而在人机协作中建立更有效的反馈闭环。

常见问题

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

A: 定义验收标准本质上是将模糊的意图转化为具体的指令。LLM 是概率模型，如果没有明确的边界，它们倾向于生成通用、冗长或偏离主题的内容。预先设定标准（例如“输出不超过 200 字”、“必须包含三个具体例子”或“采用正式商务语气”）相当于为模型设定了明确的“成功指标”。这能显著减少模型产生幻觉或输出格式不符合要求的情况，从而减少用户反复修改和提示词工程的次数，提高一次性生成高质量结果的概率。

2: 如果我不确定具体的验收标准，应该如何开始与 LLM 交互？

A: 如果一开始没有明确的标准，建议采用迭代式的方法。首先，输入一个宽泛的请求，让模型生成初稿。然后，基于初稿中不满意的部分（如结构、语气、深度等）来反向制定标准。例如，如果你发现模型生成的回复太随意，你就可以在下一轮对话中增加“使用学术性语言”这一标准。通过几轮“生成-反馈-修正”的循环，你就可以逐渐完善并固化出一套清晰的验收标准，用于后续的批量处理或精确任务。

3: 在提示词中定义验收标准有哪些具体的方法或技巧？

A: 常见且有效的定义验收标准的方法包括：

格式约束：明确要求输出 JSON、Markdown 列表或特定的表格格式。
长度限制：指定字数或段落数量（例如“将总结限制在 3 点以内”）。
角色与语气设定：指定模型扮演的角色（如“资深 Python 工程师”）或语气（如“客观、中立”）。
输出示例：提供“少样本”示例，展示符合标准的输入和输出，让模型模仿其结构和风格。

4: “验收标准”和“提示词工程”有什么区别？

A: 这两者是相辅相成但侧重点不同的概念。“提示词工程”是一个广泛的技术和艺术，旨在设计能够引导模型生成最佳结果的输入指令。而“验收标准”是提示词工程中的一个关键组成部分，它侧重于输出的质量控制和边界定义。你可以把提示词工程看作是整个驾驶过程，而验收标准则是交通规则和目的地坐标。强调验收标准，实际上是提倡一种“以终为始”的提示词设计思维，即先想好什么样的结果是好的，再倒推如何编写提示词。

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

A: 虽然定义验收标准对大多数任务都有益，但其重要性程度因任务类型而异。

高适用性场景：创意写作（需指定风格）、代码生成（需指定语言和库）、数据提取（需指定格式）、摘要生成（需指定长度）。在这些场景中，标准是决定成败的关键。
低适用性场景：开放式的头脑风暴、探索性学习或简单的问答。在这些场景中，过严的标准可能会限制模型的创造力或探索范围。但在这些情况下，定义“范围”或“深度”作为一种宽松的标准，依然有助于防止模型跑题。

6: 为什么即使给出了详细的验收标准，LLM 有时仍然无法满足要求？

A: 这通常涉及几个因素：

指令冲突：提示词中的不同部分可能存在相互矛盾的指令（例如要求“简洁”但又要求“详细解释”），模型会陷入两难。
模型能力限制：某些标准可能超出了模型的上下文窗口长度或逻辑推理能力。
权重问题：在长提示词中，验收标准如果被淹没在大量背景信息中，模型可能会给予较低的注意力权重。
模糊性：自然语言本身具有模糊性，“高质量”或“专业”对不同的人有不同的含义。解决这一问题的办法是使用更结构化的提示词（如使用 XML 标签或分节符）来突出验收标准，并使用尽可能量化的描述。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 假设你需要让 LLM 为你撰写一封商务邮件，邀请合作伙伴参加产品发布会。请设计一个包含“验收标准”的提示词，明确指出邮件必须包含的三个关键要素（例如时间、地点、回复方式），并要求 LLM 在生成内容后进行自我核查，确认这些要素是否齐全。

提示**: 思考如何将“验收标准”转化为具体的指令。你可以尝试使用结构化的提示词格式，例如“要求：1… 2… 3…”，并要求模型在输出末尾添加一个“检查清单”部分。

引用

原文链接: 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在用户预设验收标准时效果最佳
为什么 XML 标签对 Claude 模型如此关键
评测 AGENTS.md：对编程 AI 智能体的实际效用分析 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

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