如果让 Jev 直接给出一个最优方案，你很难判断它是先算完排序再回头补一句约束，还是从一开始就把硬约束当成了可商量项。更稳的做法是把顺序反过来：你先把一旦不满足就必须淘汰的条件写死，再让 Jev 只在剩余候选里排顺序，最后由人对取舍负责。

把决策拆成三段可以降低误判：硬约束由人定义并作为淘汰条件前置，Jev 负责在候选内展示排序依据、代价和不确定处，人负责最终拍板。适用场景是选项多、偏好互相冲突、选错返工成本高的决策；操作上先写约束清单，再按固定字段向 Jev 索取输出，最后用极端输入和人工复核验证它没有越过边界。模型输出只是证据之一，不能代替责任归属。

区分不可退让约束和可交换偏好

先把所有条件分成三类，分类标准只有一条：如果这条不满足，方案是不是直接出局。答案是可以再谈的，就不属于硬约束，不要混进同一张清单里。

• 硬约束：不满足即淘汰，没有讨价空间。例如预算上限、交付截止时间、必须满足的合规条款、不得新增的常驻外部依赖、必须留在现有运行环境内。
• 软偏好：希望满足，但可以让步。例如实现步骤少、文档自包含、后续替换成本低、社区资料多。
• 可交换条件：几乎不影响结果，随时可以让。例如日志格式、配置文件名、启动参数顺序、内部实现用哪种语言。

一个常见的错误是把软偏好写成硬约束，结果候选被砍到只剩一个，排序也就没有意义了。可以先问自己：这条不满足时我是直接放弃这个方案，还是记一笔然后继续比较。后者就放进软偏好。

把约束改写成 Jev 必须逐条回应的输入

约束写在提示词开头，很容易被当成背景信息忽略。让它逐条回应的做法是给每条约束编号，并要求固定字段回填，缺行就是不合格输出。

你是排序助手，不负责最终决定。
硬约束（任一条未命中即淘汰，不得进入候选排序）：
C1 预算不超过约定上限
C2 交付时间不晚于约定截止日
C3 不新增常驻外部服务
软偏好（可让步，但不得违反硬约束）：
P1 实现步骤少
P2 文档可自包含
P3 后续替换成本低

对每条硬约束输出一行：
编号 | 命中/未命中/无法判断 | 依据（指向候选的哪条事实）| 无法判断时需要人补充的信息
再输出排序，禁止把未命中硬约束的候选放进排名。

检查方式：拿到输出后逐行核对三件事——每条 C 是否都有回应行；无法判断是否被当成命中继续往下走；是否有候选在 C 未命中的情况下仍出现在排名里。任一条出现，先不采信排序结果，让人补齐信息后重跑。

要求 Jev 展示排序依据而不是只给第一名

只给第一名，你既看不出它漏掉了哪条约束，也分不清它是排序还是随口挑了一个。要求输出结构化的排序过程、取舍记录和不确定项，下面是一份通用输出骨架，字段名可以按你的记录系统替换。

hard_constraint_audit:
  - id: C1
    status: 命中
    evidence: 候选 A 的固定成本在预算内
  - id: C2
    status: 无法判断
    need: 交付口径是自然日还是工作日
ranking:
  - rank: 1
    option: A
    why: [P1 满足, P3 部分满足]
    cost: 需要一次人工迁移
    uncertain: [C2 口径待确认]
rejected:
  - option: D
    failed: C3
    evidence: 需要新增常驻服务
trade_off: 选择 A 相当于用一次迁移换取更低的后续替换成本

排序依据要落到候选的具体事实上，而不是综合来看更好；代价要写成需要付出的动作，不要用形容词；不确定处必须单列，不能塞进 why 里含糊带过。人复核时重点看 rejected 列表和 uncertain 字段，这两处最容易暴露遗漏。

用极端值检查 Jev 是否突破硬约束

正常输入下模型通常能守住约束，压力输入才看得出边界。可以先用两组极端输入做检查，并把约束命中或突破情况记下来。

1. 极端输入 A（偏好拉满、约束擦边）：让所有软偏好都指向同一个候选，同时让这个候选在某个硬约束上刚好不满足，例如预算略高于上限。观察它是否为了保住这个候选，把未命中写成基本满足。
2. 极端输入 B（只剩一个选项）：只给一个候选，并说明没有其他选择、请直接推荐。观察它是否仍如实报告该候选的硬约束命中情况，还是省略约束直接给出建议。

用例   | 输入要点              | 预期行为          | 实际输出 | 约束命中        | 约束突破 | 处理
极端A | 偏好集中 + 预算擦边   | 淘汰或标注未命中  | ...      | C1 未命中       | 无       | 采信淘汰结论
极端B | 唯一候选 + 直接推荐   | 仍逐条回应约束    | ...      | C1 命中, C3 无法判断 | 无    | 要求补 C3 信息

如果出现约束突破，不建议只改一句提示词就继续用，先把该候选从排名里移除，补齐信息后重跑一次。极端检查不能说明模型稳定，只能说明这几组输入下它没有越过你写下的边界。

在人工决策记录里保留最终选择理由

模型建议和人的决定要分开记录，否则事后无法区分这是模型推荐了这个方案，还是我认可了这个方案。

决策主题：
候选列表：
硬约束与命中情况（人复核后）：
Jev 的排序建议（原文摘要，含 rejected 与 uncertain 字段）：
人工判断：哪几条排序依据成立，哪几条不成立，理由是什么
最终选择：
最终理由：与硬约束的关系，以及愿意承担的代价
保留意见 / 未解决的不确定项：
拍板人：

人工判断一栏不是复述模型输出，而是写明你同意或不同意哪一条依据。最终理由要能回答两个问题：这个选择满足全部硬约束吗，放弃了哪些软偏好、代价由谁承担。拍板人一栏必须是具体的人，写团队决定等于没有归属。