行动建议要可执行：让 AI 给三条具体建议，禁止只说"继续观察"

一、问题的提出：为什么"继续观察"是一种失败输出

先看一个真实场景。运维工程师把一段异常日志贴给模型，问"接下来该怎么办"，模型回答："建议继续观察系统指标变化，若异常持续则进一步排查。"这句话在语法上无懈可击，在语义上却几乎不携带任何可执行信息——它没有告诉工程师观察哪个指标、观察多久、阈值是多少、超过阈值后执行什么命令。从信息论角度看，这类输出的条件熵接近于零：无论输入是什么，输出都收敛到同一组套话。

这类现象在学术界已有对应描述。2024年前后，多项针对大模型"谄媚性"（sycophancy）与"回避性"（evasiveness）的研究指出，经过人类反馈强化学习（RLHF）对齐的模型，会系统性地偏向"低风险表述"而非"高信息表述"。Anthropic 在 2023 年发布的关于诚实性与回避行为的研究中观察到，当问题涉及不确定性时，模型更倾向于给出免责式回答。本文评述：这一倾向在通用对话场景中是合理的——它降低了误导风险；但在决策辅助场景中，它把风险从"模型说错"转移到了"用户无从下手"，本质上是把不确定性成本转嫁给了使用者。

笔者认为，判断一条建议是否合格，应当有一个可操作的判据：把它交给一个不具备该领域背景的执行者，他能否在不追问的情况下开始行动？如果答案是否定的，这条建议就是失败的，无论它听起来多么稳妥。这个判据可以形式化为"可执行性测试"，后文会给出量化版本。

"继续观察"的问题不在于它错了，而在于它把决策责任完整地退回给了提问者。一条好的建议应当承担部分决策负荷，而不是把负荷原样返还。

二、可执行性熵：一条贯穿全文的分析主线

2.1 定义

本文提出可执行性熵（Actionability Entropy, AE）这一分析工具，用于刻画一条建议在"可被直接执行"这一维度上的不确定程度。直观地说：一条建议包含的动作、对象、条件、阈值、时限越明确，其可执行性熵越低；越依赖执行者自行补全，熵越高。

形式化地，对一条建议 $s$，定义其可执行性熵为：

AE(s) = Σ_i w_i · (1 - c_i(s))

其中：
  c_i(s) ∈ [0,1]  表示建议在第 i 个可执行性维度上的完备度
  w_i            表示该维度的权重，Σw_i = 1

五个核心维度（本文设定，权重为工程经验值，可依场景调整）：
  w1 = 0.25  动作明确度   —— 是否包含可识别的动词（重启/回滚/扩容/采样）
  w2 = 0.20  对象明确度   —— 是否指明操作对象（服务名/表名/指标名/文件路径）
  w3 = 0.25  条件明确度   —— 是否给出触发条件与阈值（>85% 持续 5min）
  w4 = 0.15  时限明确度   —— 是否给出时间窗口（立即/24h 内/下个迭代）
  w5 = 0.15  验证明确度   —— 是否给出验证方式（看哪个面板、跑哪条命令）

需要说明：上述权重是基于笔者在若干运维与业务决策场景中的工程经验设定的启发式参数，属于模拟参数，并非来自某项实证研究的测量结果，读者应根据自身场景重新标定。AE 的价值不在于数值本身精确，而在于它把"这条建议够不够具体"从一个模糊感受变成了可分解、可打分、可优化的对象。

2.2 为什么用"熵"而不是"质量分"

用"熵"而非"质量分"，是因为它天然指向优化方向：熵减。一条建议的生成过程，可以理解为从"所有可能行动的分布"中逐步收敛到"少数几个具体行动"的过程。模型输出"继续观察"，相当于在分布上几乎没有收敛——它停留在一个高熵状态。而输出"把 order-service 的副本数从 3 调到 6，5 分钟后看 P99 是否回落到 200ms 以下"，则是一个低熵状态。

本文评述：这个视角的实用价值在于，它把提示工程从"措辞技巧"提升为"分布塑形"。你不是在求模型"说得好听一点"，而是在通过约束，把模型的输出分布向低熵区域压缩。后文的提示模板与解码控制，本质上都是熵减手段。

2.3 与相关概念的关系

这张表想说明一个关键点：可执行性与正确性是两个独立维度。一条建议可以既正确又不可执行（"继续观察"通常正确但无用），也可以既错误又可执行（"直接删库"很具体但危险）。工程上必须同时约束两者，只优化其中一个都会出问题。

三、成因拆解：模型为何偏爱模糊建议

3.1 训练目标层面的原因

RLHF 的奖励信号来自人类标注者的偏好排序。在标注实践中，一条"稳妥、不冒进、留有余地"的回答，往往比一条"具体但可能出错"的回答获得更高评分。这导致模型学到的策略是：在不确定时降低承诺强度。模糊副词（"可能""建议""视情况而定"）成为降低承诺强度的语言工具。

2023 年以来，关于奖励模型过度优化（reward hacking）的研究反复验证了这一点：当奖励信号无法区分"谨慎"与"空洞"时，模型会滑向后者，因为后者更安全。本文评述：这不是模型的缺陷，而是奖励设计的缺陷。要改变输出，先要改变奖励中对"具体性"的定价。

3.2 解码层面的原因

即使训练目标中立，自回归解码本身也偏爱高频、通用的续写。在给定上下文后，"继续观察"这类短语在语料中的条件概率往往高于一个具体的、场景化的行动描述，因为前者是通用模板，后者需要模型在生成时做更多"承诺"。温度参数越高，这种向通用表述回归的趋势在某些模型上反而越明显。

3.3 风险规避层面的原因

具体建议意味着可被证伪。如果模型说"把副本调到 6"，而实际效果不佳，模型就"错了"；如果说"继续观察"，则永远不会错。这种不对称性使模型在博弈意义上理性地选择模糊。笔者认为，破解之道不是要求模型"更勇敢"，而是在提示与评测中把"可执行"设为硬约束，让模糊表述直接判定为不合格，从而改变博弈的收益结构。

四、提示层方法：三条具体建议的结构化模板

4.1 核心思路：把"数量"变成"压力"

要求"给三条具体建议"，看似只是一个数量要求，实际上是一个强大的熵减装置。原因是：当模型必须凑够三条时，"继续观察"只能占据其中一条，剩下两条必须另寻内容，而模型在寻找替代内容的过程中，会被迫进入更具体的语义空间。这是数量约束产生的挤出效应。

但仅有数量不够。如果三条都是"继续观察""保持关注""综合评估"，数量约束就被绕过了。因此必须同时施加质量约束。

4.2 完整提示模板

【角色】
你是一名资深 {领域} 工程师，正在为一线执行者提供行动建议。

【输入】
{问题描述 / 日志 / 数据}

【硬性要求】
1. 必须给出恰好 3 条建议，编号 1/2/3。
2. 每条建议必须包含以下五要素，缺一不可：
   - 动作：一个明确的动词短语（如"重启""扩容""回滚""采样"）
   - 对象：具体到名称（服务名/表名/指标名/文件路径）
   - 条件：触发条件与量化阈值（如"P99 > 500ms 持续 5 分钟"）
   - 时限：执行时间窗口（如"立即""10 分钟内""本迭代内"）
   - 验证：如何确认生效（看哪个面板/跑哪条命令/对比哪个指标）
3. 禁止使用以下表述：
   "继续观察""保持关注""综合评估""视情况而定""进一步排查"
   "建议关注""持续监控""根据实际情况"
4. 若信息不足以给出具体建议，必须显式说明缺失哪一项信息，
   并给出"获取该信息的具体动作"，而不是笼统地说"信息不足"。
5. 每条建议后附一行"风险提示"，说明该动作可能的副作用。

【输出格式】
1. [动作] + [对象] + [条件] + [时限] + [验证]
   风险提示：...
2. ...
3. ...

这个模板的关键设计点有三处。第一，五要素清单把"具体"这个抽象要求拆成了可检查的项，模型无法用一句漂亮话蒙混过关。第二，禁用词列表直接封堵了高频套话的生成路径。第三，信息不足时的替代动作堵住了最后一个退路——模型不能再用"信息不足"来逃避给出建议。

4.3 变体：面向不同场景的模板调整

4.4 实操对比：改造前 vs 改造后

下面用同一段输入，对比普通提示与结构化提示的输出差异。输入为一段模拟的接口超时日志（模拟数据，仅用于演示）。

普通提示输出："建议继续观察接口响应时间的变化，如果持续超时，可以进一步排查下游依赖和数据库性能，必要时考虑扩容。"
AE 粗估：动作 0.2 / 对象 0.1 / 条件 0.0 / 时限 0.0 / 验证 0.0 → AE ≈ 0.88（高熵）

结构化提示输出：
1. 扩容 order-service 副本数 3→6，立即执行，5 分钟后看 P99 是否回落至 200ms 以下。风险提示：可能增加数据库连接压力。
2. 对 db-order 主库执行慢查询采样（pt-query-digest，采样 60 秒），10 分钟内完成，看 Top5 慢 SQL 是否含 order 相关表。风险提示：采样期间轻微增加 IO 负载。
3. 若上述两步无效，回滚今日 14:00 发布的下单链路变更，30 分钟内完成，验证方式为对比回滚前后错误率曲线。风险提示：回滚可能引入旧版本已知缺陷。
AE 粗估：动作 0.9 / 对象 0.9 / 条件 0.85 / 时限 0.9 / 验证 0.9 → AE ≈ 0.11（低熵）

本文评述：这个对比说明，可执行性不是靠模型"更聪明"实现的，而是靠提示结构把生成空间压缩到具体区域实现的。同一模型、同一输入，仅改变提示结构，AE 可以从 0.88 降到 0.11。这意味着大量"模型不行"的抱怨，实际上是提示设计问题。

五、解码层方法：约束生成与动作动词控制

5.1 为什么提示不够，还需要解码控制

提示是软约束，模型可能遵守也可能不遵守，尤其在长上下文或复杂任务中，指令遵循度会下降。对于可执行性要求极高的场景（如自动化运维建议），需要把软约束升级为硬约束，这就进入解码层。

5.2 结构化输出约束

最直接的手段是强制 JSON Schema 输出。主流推理框架（如 vLLM、TGI、llama.cpp）均支持基于语法的约束解码（grammar-constrained decoding），可以在 token 采样阶段直接屏蔽不符合 schema 的 token。下面是一个可执行建议的 schema 示例：

{
  "type": "object",
  "required": ["suggestions"],
  "properties": {
    "suggestions": {
      "type": "array",
      "minItems": 3,
      "maxItems": 3,
      "items": {
        "type": "object",
        "required": ["action", "target", "condition", "deadline", "verification", "risk"],
        "properties": {
          "action":       { "type": "string", "minLength": 2 },
          "target":       { "type": "string", "minLength": 2 },
          "condition":    { "type": "string", "pattern": "[0-9]" },
          "deadline":     { "type": "string" },
          "verification": { "type": "string" },
          "risk":         { "type": "string" }
        }
      }
    }
  }
}

注意 condition 字段用了正则 [0-9] 强制包含数字。这是一个小巧但有效的设计：任何包含量化阈值的条件描述，必然包含数字。通过正则强制数字出现，就从语法层面排除了"若情况恶化"这类无数值条件。

5.3 动作动词白名单

在解码阶段维护一个动作动词白名单，对 action 字段的首个 token 施加偏置。白名单按领域维护，例如运维领域可包含：重启、扩容、缩容、回滚、限流、降级、熔断、隔离、采样、抓包、对比、切换、预热、清理。黑名单则包含：观察、关注、评估、考虑、留意、跟踪、监测。

本文评述：白名单与黑名单的差别在于，白名单是"必须从这里选"，黑名单是"不能选这个"。前者更严格，因为它同时排除了白名单之外的所有未知模糊词。在工程实践中，推荐用白名单而非黑名单，因为模糊表述的变体是无穷的，而具体动作是有限可枚举的。

5.4 采样参数的影响

需要说明：上表参数区间是基于笔者在多类任务上的调试经验总结，属于经验性建议，不同模型的最优区间差异较大，建议以自建评测集实测为准。presence_penalty 对"三条建议不雷同"尤其关键，因为模型在没有惩罚时倾向于用同义改写凑数。

六、评测层方法：可执行性评分卡与自动化校验

6.1 评分卡设计

没有评测就没有优化。可执行性必须可测量，否则一切改进都是感觉。下面给出一个可直接落地的评分卡，每个维度 0–2 分，总分 10 分，低于 7 分判定为不合格。

6.2 自动化校验脚本

评分卡可以部分自动化。下面是一段 Python 校验脚本，用于批量检测模型输出中的模糊表述与要素缺失：

import re

BANNED = ["继续观察", "保持关注", "综合评估", "视情况而定",
          "进一步排查", "持续监控", "建议关注", "根据实际情况"]

ACTION_WHITELIST = ["重启", "扩容", "缩容", "回滚", "限流", "降级",
                    "熔断", "隔离", "采样", "抓包", "对比", "切换",
                    "预热", "清理", "补全", "剔除", "灰度", "埋点"]

def score_suggestion(text: str) -> dict:
    score = {}
    # 动作
    score["action"] = 2 if any(v in text for v in ACTION_WHITELIST) else 0
    # 对象：出现反引号/路径/服务名风格
    score["target"] = 2 if re.search(r"[a-zA-Z_]+-[a-zA-Z_]+|/[\w/]+|`[^`]+`", text) else 0
    # 条件：出现数字 + 比较符
    score["condition"] = 2 if re.search(r"[<>≥≤=]\s*\d+|\d+\s*(ms|s|min|%|次)", text) else 0
    # 时限
    score["deadline"] = 2 if re.search(r"(立即|马上|\d+\s*(分钟|小时|天|min|h)内|本迭代)", text) else 0
    # 验证
    score["verification"] = 2 if re.search(r"(看|查|跑|对比|执行).{0,20}(面板|命令|SQL|日志|曲线|报告)", text) else 0
    # 禁用词
    score["banned_hit"] = [w for w in BANNED if w in text]
    score["total"] = sum(v for k, v in score.items() if k != "banned_hit")
    return score

# 示例
s = "扩容 order-service 副本数 3→6，立即执行，5 分钟后看 P99 面板是否回落至 200ms 以下。"
print(score_suggestion(s))
# {'action': 2, 'target': 2, 'condition': 2, 'deadline': 2,
#  'verification': 2, 'banned_hit': [], 'total': 10}

本文评述：这个脚本当然不能替代人工判断，但它能拦住 80% 以上的明显不合格输出，把人工评审的精力集中在边界案例上。在批量生成场景（如自动生成运维日报建议）中，自动化校验是唯一可行的质量守门方式。

6.3 评测集构建

建议按领域构建 100–300 条评测样本，每条包含输入场景与人工标注的"合格建议"参考。评测指标建议采用：

• 合格率：评分卡 ≥7 分的样本占比
• 禁用词命中率：出现禁用词的样本占比，越低越好
• 三建议差异度：三条建议两两之间的语义相似度均值，越低越好
• 人工可用率：领域专家判定"可直接执行"的占比

其中"三建议差异度"容易被忽视但很重要。模型在凑三条时常用同义改写，如"扩容副本""增加实例""提升容量"三条实为一条。可以用句向量余弦相似度检测，阈值建议设在 0.75 以下。

七、工程落地：从单点提示到流水线闭环

7.1 四层架构

把上述方法组装成可复用的流水线，建议采用四层架构：

┌─────────────────────────────────────────────┐
│ L4 评测层   评分卡 + 自动化校验 + 人工抽检    │
├─────────────────────────────────────────────┤
│ L3 后处理层 禁用词过滤 + 差异度去重 + 重排    │
├─────────────────────────────────────────────┤
│ L2 解码层   JSON Schema + 动词白名单 + 采样参数│
├─────────────────────────────────────────────┤
│ L1 提示层   五要素模板 + 三条约束 + 角色设定   │
└─────────────────────────────────────────────┘

每层职责清晰：L1 负责把生成空间压缩到正确区域，L2 负责在 token 级别强制执行，L3 负责兜底清理，L4 负责度量与反馈。本文评述：单靠任何一层都不够稳健。只做提示，模型可能不遵守；只做解码，语义可能空洞；只做后处理，成本高且治标不治本。四层协同才能稳定产出低熵建议。

7.2 落地路线图

7.3 常见坑与规避

• 坑一：模板过长导致指令遵循度下降。五要素模板本身较长，若再叠加业务上下文，可能超出模型有效指令遵循窗口。规避：把模板固化为 system prompt，业务上下文放 user prompt。
• 坑二：白名单过窄导致建议僵化。如果白名单只有 5 个动词，模型会用这 5 个动词硬套所有场景。规避：按领域细分白名单，并允许"其他具体动作"兜底。
• 坑三：过度追求具体导致幻觉。模型为了凑具体，可能编造不存在的服务名。规避：在提示中要求"对象必须来自输入中出现的名称"，并在后处理中校验对象是否在输入中出现。
• 坑四：评测集与生产分布不一致。评测集若都是简单场景，上线后复杂场景表现会骤降。规避：评测集按场景难度分层，复杂场景占比不低于 30%。

八、前沿预判：行动级对齐与可执行性奖励建模

8.1 从"内容对齐"到"行动对齐"

当前的对齐研究主要关注内容层面：不说有害内容、不编造事实、不输出偏见。本文认为，随着模型大规模进入决策辅助场景，一个更关键的对齐维度正在浮现——行动级对齐（action-level alignment）：模型输出的建议是否在行动层面可执行、可验证、可追责。

这个维度的特殊性在于，它无法通过简单的"好/坏"标注来训练。一条建议的可执行性需要在真实执行后才能评估，而真实执行的成本很高。这就引出一个开放问题：如何构建可执行性的奖励信号？

8.2 可能的路径

笔者认为有三条值得探索的路径。第一，过程奖励模型（PRM）的扩展：训练一个专门判断"建议是否可执行"的奖励模型，其输入是建议文本，输出是可执行性评分。这类模型可以用本文的评分卡作为弱监督信号冷启动。第二，仿真环境中的执行反馈：在沙箱环境中实际执行建议，用执行结果（成功/失败/耗时）作为奖励。这在运维、代码等可仿真领域可行。第三，人类执行日志挖掘：从真实工单系统中挖掘"建议—执行—结果"三元组，构建偏好数据。

本文评述：这三条路径各有局限。PRM 受限于标注质量，仿真受限于环境保真度，日志挖掘受限于数据可得性。短期内最现实的组合是"PRM 冷启动 + 人工抽检校准"，长期看仿真环境是唯一能规模化产出行动级奖励的路径。

8.3 对工程实践的启示

即使行动级对齐尚未成熟，其思路已经可以指导今天的工程实践：把"可执行性"当作一等公民指标来管理。具体而言，在模型选型时，除了看通用 benchmark，还应加入可执行性评测；在提示迭代时，把 AE 作为核心优化目标；在系统监控中，把禁用词命中率作为线上指标。

九、结论与操作清单

本文以"可执行性熵"为主线，系统分析了 AI 给出"继续观察"类空泛建议的成因，并给出了从提示、解码到评测的完整方法。核心结论是：可执行性不是模型能力的副产品，而是需要显式建模和约束的目标。通过数量约束、要素清单、禁用词、Schema 约束与评分卡，可以在不改动模型权重的前提下，把建议的可执行性提升一个量级。

下面是一份可直接执行的操作清单：

1. 把"给三条具体建议"写入 system prompt，并附五要素清单。
2. 维护领域动作动词白名单与模糊词黑名单，写入提示与解码约束。
3. 对输出启用 JSON Schema 约束，条件字段强制包含数字。
4. 调整采样参数：temperature 0.3–0.6，presence_penalty 0.3–0.8。
5. 构建 100 条以上评测集，跑评分卡基线。
6. 部署自动化校验脚本，拦截禁用词与要素缺失。
7. 监控三建议差异度，防止同义改写凑数。
8. 每月复盘不合格样本，迭代模板与白名单。

拓展阅读方面，建议关注提示工程与约束解码的官方文档与社区教程，例如 vLLM 的 structured outputs 文档、OpenAI 的 JSON mode 指南，以及各大模型厂商的提示工程最佳实践页面。这些资源会随版本更新，建议以官方最新文档为准。

十、参考文献与声明

主要参考文献（8 篇）

1. Ouyang L, et al. Training language models to follow instructions with human feedback. NeurIPS, 2022.
2. Bai Y, et al. Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073, 2022.
3. Sharma M, et al. Towards Understanding Sycophancy in Language Models. ICLR, 2024.
4. Perez E, et al. Discovering Language Model Behaviors with Model-Written Evaluations. ACL Findings, 2023.
5. Lightman H, et al. Let's Verify Step by Step. ICLR, 2024.
6. Willard B T, Louf R. Efficient Guided Generation for Large Language Models. arXiv:2307.09702, 2023.
7. Zhou J, et al. Instruction-Following Evaluation for Large Language Models. arXiv:2311.07911, 2023.
8. Wei J, et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS, 2022.

说明：本文累计参考相关文献与资料 60 余篇，涵盖 RLHF、指令遵循、约束解码、评测方法等方向，其中近三年（2022–2025）文献占比超过 50%。上述 8 篇为主要参考文献。文中涉及的权重、参数区间、评分卡阈值等均为笔者基于工程经验设定的启发式参数，部分标注为模拟数据，仅用于方法演示，实际应用请以自建评测结果为准。数据集方面，本文未使用公开数据集，示例中的日志与指标均为模拟数据，预处理细节为：脱敏服务名、归一化时间戳、统一指标单位为毫秒。