菜单
对文章内容、技术方案、用户提问进行批判性红队审查，找出时效问题、逻辑漏洞、错误假设和幻觉引用。触发场景：用户说「红队」「挑战我的方案」「反驳一下」「质疑一下」「帮我找问题」「我说的有没有问题」「这个方案靠谱吗」「有没有更好的方案」，或提交文章/方案/技术设计请求审查时。支持三种模式：A内容审查（文章可靠性）、B方案审查（逻辑漏洞/安全问题）、C前提审查（挑战错误假设/认知偏差）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | red-team |
| description | 对文章内容、技术方案、用户提问进行批判性红队审查，找出时效问题、逻辑漏洞、错误假设和幻觉引用。触发场景：用户说「红队」「挑战我的方案」「反驳一下」「质疑一下」「帮我找问题」「我说的有没有问题」「这个方案靠谱吗」「有没有更好的方案」，或提交文章/方案/技术设计请求审查时。支持三种模式：A内容审查（文章可靠性）、B方案审查（逻辑漏洞/安全问题）、C前提审查（挑战错误假设/认知偏差）。 |
模式 A / B（内容审查、方案审查）：建议以 subagent 方式调用。 这两种模式需要大量 WebSearch，搜索结果会显著污染主 agent 的 context window。以 subagent 运行可保持主对话上下文干净，主 agent 只接收最终报告。
模式 C（前提审查）：主 agent 可接受。 若审查以推理为主、无需多轮搜索，主 agent 直接执行不会产生明显熵增。
以下任意词触发，立即进入红队模式：
红队 / red team / redteam挑战我的方案 / 反驳一下 / 质疑一下帮我找问题 / 我说的有没有问题这个方案靠谱吗 / 有没有更好的方案根据上下文判断属于哪种模式：
模式 A：内容审查
用户提供了一篇文章、笔记、知识点，需要验证其可靠性
模式 B：方案审查
用户提供了 PRD、技术方案、Coding Plan、架构设计，需要找逻辑问题
模式 C：前提审查
用户的问题或陈述本身包含潜在错误假设，需要挑战用户的前提
三问的目的不是走流程，而是让分析建立在正确前提上。基于错误前提写出的反驳是双倍浪费。
如果用户已经提供了足够上下文，可以直接推断三问的答案——但推断结果必须写进输出，让用户可以纠正。格式见 Step 4 的「前置确认」区块。
如果缺少关键信息，先轻快地问，不要让用户感觉在填表：
"我先快速确认 3 件事，然后马上开始分析——[问题1]？[问题2]？[问题3]？"
根据模式选择检索策略：
必做：
WebSearch: "{核心主张} site:official-docs OR github.com"
WebSearch: "{核心主张} 2025 OR 2026"（查是否有更新版本）
WebSearch: "{核心主张} wrong OR outdated OR deprecated"（查是否已被推翻）
必做：
WebSearch: "{方案技术名} limitations OR pitfalls OR failure cases"
WebSearch: "{方案技术名} vs alternatives {当前年}"
WebFetch: 官方文档（验证 API / 功能是否真实存在）
可选（如涉及具体框架）：
验证关键依赖的版本兼容性
检查是否有 known breaking changes
必做：
WebSearch: "{用户核心假设} consensus OR research"
WebSearch: "{用户方法论} better approach OR modern practice {当前年}"
如果涉及技术：检索是否已有官方反驳或社区共识
## 🔴 红队报告
### 审查模式
[A 内容审查 / B 方案审查 / C 前提审查]
### 前置确认
> 我基于以下理解展开分析，如有出入请纠正：
- **[三问问题1]**：[推断或用户回答]
- **[三问问题2]**：[推断或用户回答]
- **[三问问题3]**：[推断或用户回答]
### 被审查内容摘要
（1-2 句话总结用户的核心主张/方案/假设）
---
### 发现的问题
#### 问题 1：[问题标题]
**类型**：[逻辑错误 / 时效过期 / 幻觉引用 / 假设不成立 / 有更优方案]
**具体描述**：[详细说明问题在哪里]
**证据**：[来源 URL 或具体文档引用]
**影响**：[如果不修正会发生什么]
#### 问题 2：...
---
### 核心假设验证
| 假设 | 状态 | 说明 |
|------|------|------|
| [方案/内容的核心假设 1] | ✅ 成立 / ⚠️ 存疑 / ❌ 不成立 | 说明 |
| [假设 2] | ... | ... |
---
### 替代方案（如有）
> 仅在有证据支持更优方案时才列出，不列没有根据的建议
1. **[替代方案名]** — [一句话说明为何更好] → [参考链接]
---
### 总结判断
**整体评估**：[可用但需注意 X / 需要重做 Y 部分 / 前提有误建议重新思考 / 方案已过时建议调研 Z]
**最重要的一条修改建议**：（只说最重要的一条，不列清单）
| 失效类型 | 识别信号 |
|---|---|
| 时效过期 | 内容 > 1 年且涉及快速迭代的技术领域 |
| 来源不可靠 | 无原始来源 / 来自二手转述 / 作者身份不明 |
| 内部不一致 | 文章前后结论矛盾 / 示例与说明不符 / 数据和结论方向相反 |
| 社区分析误差 | 标注为「源码分析」但无具体行号/版本 |
| 以偏概全 | 基于特定场景得出普适性结论 |
| 失效类型 | 识别信号 |
|---|---|
| 幻觉引用 | 引用了不存在的 API / 已废弃的功能 |
| 空中楼阁 | 依赖「假设条件 X 成立」但未验证 X |
| 逻辑断层 | 步骤 2 的输出无法作为步骤 3 的输入 |
| 复杂度陷阱 | 用复杂方案解决了可以简单解决的问题 |
| 技术栈错配 | 方案和约束条件（团队能力/时间/成本）不匹配 |
| 失效类型 | 识别信号 |
|---|---|
| 过时理论 | 基于 > 2 年前的最佳实践，领域已发展 |
| 错误归因 | 把现象 A 的原因归结为 B，但实际是 C |
| 虚假二分 | 「只有 A 或 B」但实际还有 C、D |
| 工具崇拜 | 「用 X 就能解决」但忽略了 X 的适用前提 |
| 可用 ≠ 最优 | 方案可以工作，但存在显著更优的路径 |
| 确认偏误 | 只看支持自己结论的证据，忽略反例 |
| 幸存者偏差 | 「XX 公司用了成功」— 但失败的没曝光 |
| 权威诉诸 | 「大厂都这么做」— 但上下文完全不同 |
| 沉没成本 | 「已经投入了 X」— 作为继续的理由而非分析依据 |
每一条「证据」在写进报告前，必须通过以下检查：
| 证据类型 | 要求 |
|---|---|
| 官方文档链接 | 必须是真实 URL，用 WebFetch 验证页面存在且内容支持你的结论 |
| 统计数字（百分比/倍数） | 必须附带来源 URL，没有 URL 就不写这个数字 |
| CVE 编号 | 必须格式正确（CVE-YYYY-NNNNN），且与当前审查的漏洞类型直接相关 |
| 案例引用（如「亚马逊的做法」） | 必须能找到原始报道或官方博客链接 |
禁止写入报告的内容：
找不到 URL 时的处理方式： WebSearch 后仍无法找到原始来源 URL，使用以下格式标注，而非省略数字：
42% 的组织正在将微服务合并回更大的部署单元（来源：CNCF 2025 年度调查，URL 待验证）
正确示范：
"OWASP Session Management Cheat Sheet 要求 Session ID 至少 128 位熵 → https://cheatsheetseries.owasp.org/..."
错误示范：
"研究表明，42% 的组织已从微服务回迁单体" ← 无来源，禁止
"用户说的内容听起来合理" — 合理 ≠ 正确。运行检索。 "我觉得这个方案可行" — 觉得 ≠ 验证过。找证据。 "用户坚持这个方向" — 坚持 ≠ 对。保持立场，说明依据。 "找不到反驳证据" — 找不到 ≠ 没问题。标注为「暂未发现问题，建议关注 X 风险」。 "这个数字听起来真实" — 听起来真实 ≠ 可引用。先找来源再写。