Clef 不是拿来聊天就行的：它是否合适，取决于你手头是决策任务还是生成任务。若需求是“在几个方案里选一个、排个序、打个分”，Clef 往往比通用聊天模型更对路；若需求是“写一段文案、陪我聊几轮、安慰情绪”，把 Clef 当通用聊天模型用，通常效果差，不是调提示词就能解决。

把需求先归到决策任务还是生成任务，再决定是否用 Clef。决策任务的输入通常包含目的、候选、约束、评分口径，期望输出是选择、排序或评分；生成任务的输入偏向风格、语气、上下文，期望输出是连续文本。若手头需求落在后者，改用通用生成模型；若落在前者，用 Clef 跑一次最小候选选择，观察返回是否给出候选标识和理由，再决定是否接入。

在任务描述里找决策关键词：目的、约束、候选、评分

决策任务在描述里会留下明显痕迹。可以在需求文本中圈出四类词：目的词、约束词、候选词、评分词。目的词如“选择、推荐、排序、打分、裁决、优先级”；约束词如“必须、不能、预算不超过、需要兼容、本周内”；候选词如“A/B/C、三个方案、两台机器、多个供应商”；评分词如“按成本、按风险、按交付速度、综合评分”。如果一段需求只能写出目的和风格要求，写不出候选和约束，通常不是 Clef 的强项。

操作动作：把原始需求改写成“目标-候选-约束-评分”四元组。例如“帮忙选个部署方式”不够，改成“从 A 单机、B 容器、C 托管三个候选里选一个，约束是本周内可上线且不新增数据库，评分看上线速度、运维复杂度、回滚成本”。验证方式：看这个四元组是否能让另一个人按同样口径选出结果；如果不同人理解差异很大，需要先补口径，而不是直接交给模型。风险边界：约束如果互相冲突，Clef 可能仍会返回选择，但需要人工确认冲突是否已解决。

对比生成任务和决策任务的输出形态

生成任务和决策任务的输出形态不同。生成任务通常要连续文本：输入品牌调性、受众、渠道，输出一段可发布的文案；没有唯一正确答案，验证靠人读。决策任务通常要离散结果：输入候选和约束，输出被选项、排序或评分，验证靠候选标识、评分口径和约束是否被满足。

用两个具体例子看差异。例子一，生成任务：给一款咖啡写三条朋友圈文案，输入是语气和卖点，输出是三条自然语言文本。例子二，决策任务：从三家物流供应商中选一家，输入是报价、时效、覆盖区域和必须支持冷链的约束，输出是“选第二家”、排序和排除理由。两者不能靠同一种评价方式混用。

判断 Clef 返回的是选择、评分还是文本，可以先看返回体里有没有候选编号、排序或评分字段；字段名以你本地日志和接入文档为准。如果只有长段解释、没有候选标识，当前请求可能更接近生成任务。解释文本可以作为决策理由，但不要把理由当成创作结果。风险边界：有些决策任务也需要自然语言说明，说明应附着在选择上，不能反过来让模型自由发挥。

用 Clef 跑一个最小决策示例：从三个选项中选一个

先用最小请求验证 Clef 是否适合当前场景。下面是一段自然语言请求，提交方式按你环境里的 HTTP、CLI 或 SDK 替换，字段名不要照抄；这里只描述输入内容和期望输出。

任务：从三个方案中选一个。
候选：
A 方案：在现有服务上增加只读查询接口
B 方案：新建独立查询服务
C 方案：先人工导出固定报表
约束：
1. 本周内可上线
2. 不新增数据库实例
3. 必须保留回滚路径
评分口径：
1. 上线速度
2. 运维复杂度
3. 回滚成本
请输出：被选候选、候选排序或评分、排除理由、未满足的约束提醒。

提交后观察返回：是否出现 A、B、C 候选名，是否给出排序或评分，是否明确提到约束。验证方式：把候选顺序打乱再提交一次，看选择是否随顺序剧烈变化；查看运行日志里的原始输入和返回，确认约束没有被截断或漏掉。风险边界：一次最小示例只能判断当前场景是否匹配，不能替代完整选型。若返回只有散文，先怀疑任务不是决策任务，或输入缺少候选和约束。

记录不适用场景：开放式创作、多轮闲聊、情感陪伴

有三类任务不适合优先交给决策模型。第一类是开放式创作：写故事、起名、写营销文案，期望的是多样文本，而不是从有限候选里选一个。第二类是多轮闲聊：需要上下文延续、语气和记忆，决策模型容易反复给方案，不适合陪聊。第三类是情感陪伴：需要共情和边界，决策模型可能把情绪当成待解决问题，直接给建议。

这些场景失效的原因不是提示词写得不好，而是任务本身缺少可比较的候选、约束和评分口径。没有比较对象时，模型很难稳定排序；评分口径主观时，排序会随表述变化；多轮上下文和人格化也不是选择问题。记录方式：在选型笔记或 issue 模板里标注“任务类型=开放式创作/多轮闲聊/情感陪伴，不接 Clef；改接生成模型或人工处理”。验证方式：如果强行使用，页面行为通常表现为回答生硬、反复列方案、忽略情绪或上下文。风险边界：不是所有生成任务都不能用决策模型，但需要先确认输出要求是否包含有限候选和评分。

把判断结果写成一张适用性检查表

把每次选型都填成一张表，避免只凭印象决定是否接入 Clef。表可以复制到选型文档或 issue 模板里，每次新需求先填列，再决定模型。

操作动作：新需求先填“任务类型、输出要求、是否含约束条件、候选是否有限、是否需要排序/评分、是否接受唯一选择”。如果任务类型是决策，输出要求是选择、排序或评分，候选有限，约束可列，再把 Clef 纳入候选；否则先用通用生成模型。验证方式：每次接入前至少跑一次最小决策请求，并查看日志中的输入输出。风险边界：检查表只记录判断依据，不能替代安全、成本和合规评审。