【必须】先完整输出判断标准，再进行方案对比；未输出标准前，禁止出现任何方案名称、得分或优劣结论。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Claude在输出技术方案对比前，先明确一套可执行、可验证、不依赖主观判断的检查标准，而不是直接甩出一堆带权重的表格——没有标准的对比等于没对比。
第一步：强制Claude先输出标准再对比
在提示词最开头用【必须】锁定动作顺序：“【必须】先完整输出判断标准，再进行方案对比；未输出标准前，禁止出现任何方案名称、得分或优劣结论。”
Claude默认倾向跳过标准定义直奔结论，不加这道硬闸，它会在第一行就写“方案A更优”，后面全是理由堆砌。
第二步：标准必须含三类硬性要素
明确要求标准包含且仅包含以下三类要素，缺一不可：
① 可量化指标：如“P99响应时间≤180ms”“冷启动耗时≤3.2秒”“单节点最大连接数≥8000”。【模糊描述会导致标准失效】
② 约束条件：如“团队无Rust开发经验”“现有CI流水线不支持Bazel”“必须兼容Windows Server 2016+”。这些不是性能参数，而是落地前提。
③ 业务目标对齐项：如“支撑Q4大促期间并发用户量达120万”“满足未来18个月内日志保留周期从7天延长至90天”。必须绑定时间锚点和数字目标。
第三步：用结构化格式切断自由发挥路径
在提示词末尾追加格式指令：
请严格按以下格式分段输出：
① 判断标准（仅列出条目，每条以“-”开头，不解释）
② 各标准权重说明（用百分比，总和为100%，每条权重须基于你已知的上下文推导，如“因当前DB连接池已告警，‘连接复用率’权重设为35%”）
③ 方案对比表（含方案名称、各标准得分、综合得分）
这个结构能防止Claude把标准混在分析段落里带过，也避免它擅自添加“易用性”“扩展性”这类无法测量的虚词。
第四步：注入真实锚点堵住幻觉漏洞
方法一：嵌入技术栈限制
直接写明：“当前系统已用Python 3.11 + Django 4.2 + PostgreSQL 15，运维团队熟悉Prometheus但未部署OpenTelemetry Collector。”
方法二：绑定业务节奏
加入时间锚点：“本方案需在2026年8月31日前上线，灰度周期严格限定为10个工作日。”
方法三：引用既定决策
写清：“上月架构委员会已否决引入新中间件，所有方案必须基于现有Kafka集群与Redis 7.0.12实现。”
没有这些锚点，Claude可能在标准里塞进“eBPF可观测性支持度”，而你们连eBPF内核模块都没开。
