用证据改变方案，而不是用语气制造对抗
虚构的社区图书馆计划延长周末开放时间，并上线预约页面。提案预计“多开放两小时就能明显增加使用”，但没有说明需求来自谁、人员如何安排、预约失败怎样处理。AI 可以帮助找出这些缺口，不能为了扮演红队就编造用户抱怨、成本数字或专家意见。严格评审的目标是让选择更可检验，而不是让负责人难堪。 本文保留原文的方案红队、反方论证、长期反谄媚三个场景。这里的红队指授权范围内的计划与文档审查，不是渗透攻击。所有示例为原创虚构方案，没有联系真实用户或执行上线。评审可以得出支持、修改、延期或信息不足，不预设必须反对。
场景一：把事前验尸写成可验证风险
先固定提案版本、目标、限制、已知证据和决定时间。图书馆例子要区分到馆人数、有效预约与读者满意度，不能把点击量直接当成开放时段需求。写出当前最强的支持理由，确保审查的是完整方案，而不是为了轻松驳倒而缩减的版本。 再设想试点没有达到目标，逐项问“可能在哪个具体环节失败”。例如预约用户不知道入口、增加开放却没有相应人员、部分读者需要的是不同时间、预约与实际入馆数据无法对应。每项标为事实、推测或待证问题，不把想象中的失败故事当已经发生的事故。 风险表包括所依赖假设、失败机制、影响对象、已有证据、需要验证的信息、早期信号、负责人和处理选择。不要用一串精确概率掩盖没有数据。若必须排序，可以按影响、可逆性、证据与暴露范围说明优先级，同时保留评分口径和不确定性。 把高优先问题转成小试验：先调查实际时间需求，测试预约路径，再做限定范围的时段试点。提前写明什么结果支持继续、什么结果要求调整，以及收集数据的方式和边界。试验未执行时只给计划，不编造“多数用户赞同”。风险没有马上消失，也可以作为接受的代价记录，而不是假装方案被完全修好。 产物是具体风险表、证据缺口与验证计划。事前验尸不是预测未来，价值在于暴露能检查的机制。措辞越激烈不代表判断越可靠，低概率但高影响也不能凭一句“黑天鹅”无限压倒所有其他考虑。
场景二：先强化反方，再核对它依赖什么
为同一方案分别提出支持与反对的最强版本。支持方可以强调服务机会，反方可以指出资源约束与其他时段更值得投入，但两边都需标证据。不要制造明显弱的替代方案，让原提案看起来必胜。能够被公平重述的反方，比模拟一个爱挑刺的人格更有用。 沿三个角度提问：利益方是否承担不同成本，关键假设若不成立会怎样，哪些边界情形值得检查。馆员、现有读者、无法使用线上预约的人可能有不同需求，但不能替这些人编造真实意见。把“可能受影响”与“已收集到反馈”分开，下一步才知道该找什么证据。 模拟多个角色可以拓宽问题，但不是独立专家证词。相同模型、材料和提示可能重复同一偏差；让六个角色投票不能验证事实。辩论应围绕同一提案版本，每个反驳指出原主张、理由、证据或反例及可检验条件。无证据部分保留为假设，不因角色需要就补造来源。 “只找问题”可以是阶段性任务，却不能成为决策终点。将质疑清单交给方案负责人，区分已回应、需要补证、接受风险和应修改项。反方被证据推翻时也要更新，不把坚持反对视为忠诚。正方同样可以承认限制，避免辩论变成赢输比赛。 控制轮次与范围：先澄清主张，再形成反驳，再比较证据，最后写未解决分歧。材料不足时停止并说明缺口，不让两个 Agent 无限互怼。是否增加真实研究、工程测试或专业评审，由实际风险与决策需要决定，而不是由模型语气决定。 产物是正反论证表、引用检查、假设变化和待决问题。负责人依据证据与价值取舍裁量，不能把模型给的支持票数、置信分或“专家一致认为”当成外部验证。记录为什么没有采用某个反对意见，同样有助于后续复盘。
场景三：让日常规则保持诚实，而不是自动唱反调
长期对话约定应要求：区分事实、推测与偏好；重要结论给依据；发现错误前提指出并解释；信息不足明确说明；有理由支持时直接支持。不要写成“永远反驳用户”或“先批评三点”，否则系统可能为完成格式而制造问题，形成另一种不诚实。 为规则建一组回归样例。样例包括证据充分的正确方案、含明显错误前提的方案、资料不足的方案和主要是个人偏好的选择。期望分别是有理由支持、指出具体错误、说明未知、尊重偏好而解释实际取舍。不要只测试 AI 是否敢说“不”，更要看它会不会不必要地否定。 当评审需要检索时，核对原始来源、适用时间与上下文，引用不得支持超出原文的结论。来源打不开就说明未核实，不能编造引文。把过去对话里的猜测长期存入记忆，可能让后续回答越来越肯定，因此定期复核并允许纠正或删除旧假设。 将决策写成可追溯记录：背景、选项、驱动因素、证据、选择、接受的后果与复查条件。开源 MADR 提供可检查的 Markdown 决策记录模板，适合作为技术决策文档结构参考，选择理由是内容明确、可版本管理和维护资料可读。它不自动验证方案，更不是红队安全认证，不需要为了记录一次简单选择安装额外框架。 技术提案与决策记录的表达整理可使用 Writing Guidelines。公开详情、Vercel 固定源码与 MIT 许可已核验；提供已有脱敏文稿与受众，它适合改善结构、术语和行动说明。它不是事实核查器、反谄媚保证或红队引擎，不能承担最终决策。 每次规则或技能更新后，用同一回归集检查是否出现无根据赞同、无根据反对、虚构证据或回避判断。安装方法文档不代表规则永远常驻，具体加载与冲突行为要按当前 Agent 核对。多个技能可能有矛盾要求，不能承诺叠加越多越诚实。 产物是简短对话规则、回归集、实际检查记录和版本化决策文档。评价标准是结论与证据匹配、未知得到保留、能随新证据更新，不是回复是否冷酷、长篇或充满反对词。
一次完整评审怎么交付
可以这样提出任务：“审阅图书馆延时开放提案，先公平重述目标与最强支持理由，再做事前验尸。反对意见必须指向具体假设，区分证据与猜测，不编造调查或专家。比较可行替代方案，列需验证问题与试点判据，最后给条件化建议和决策记录草稿。不要联系用户、修改预算或上线。”已授权的文档处理继续完成，额外研究或外部动作单独看范围。 交付前逐条检查来源是否可追溯、风险是否具体、试验是否能区分不同解释、建议是否回应实际目标。若没有足够证据，交付信息缺口也比虚假的强结论有用。上线后按事先约定回顾信号与结果，不能只挑符合早先预测的案例证明红队正确。
FAQ 与故障排查
反方太泛怎么办？要求主张、机制、证据和可验证条件，不接受“存在风险”就结束。反方太多怎么办？合并相同机制，按影响与可逆性排序，保留理由而非只保留分数。模型很快同意是否没用？可能是已有证据充分，也可能是审查不足，要看论证，不强迫持续分歧。 两个模型都反对是否该放弃？先核查它们是否共享错误信息，最终决定由事实与取舍支撑。只质疑不解决是否可以？可以作为阶段交付，但最终仍需裁量或补证。是否免费且不冲突？许可、调用、服务和加载规则分别核对，不能一概保证。 本次没有核验到适合承担红队与反谄媚核心步骤的 SkillPI 候选，因此不编造这类关联。写作包只用于技术记录，后续出现候选再检查公开详情、固定源码、许可、依赖和实际用途，避免把宣传中的诚实当成已验证的行为。
来源与范围
原文双语的红队、反方与长期反谄媚场景及 FAQ 保留，以原创图书馆试点和证据回归样例覆盖。文档结构参考 adr/madr 上游，文字整理依据关联包固定源码；未沿用匿名引语、热度、绝对防谄媚与强制对抗必然有效结论。本文未执行真实试点，也不声称模拟角色构成独立专家评审。