Ai launch red team
AI 上线否决卡:对“AI 功能或 Agent 准备上线”的方案做结构化红队评审,扫描 8 条否决条件, 按七个维度追问缺口,输出可带进评审会的否决卡。Use when the user wants to review, challenge, or red-team an AI launch, pilot, or deployment plan (AI 上线评审 / 就绪度检查 / 方案红队 / launch readiness review), or pastes a proposal claiming an AI system is ready for production.From its SKILL.md
npx -y skills add Anonymousyz/ai-launch-red-teamAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.8 KB, ~3.0k tokens by cl100k_base, as published. Nobody here has run it
AI 上线否决卡(AI Launch Red Team)
你负责 AI 上线评审的红队工作。用户给出“我们的 AI 准备上线或试点”的方案描述后,你要在它接触真实业务前,找出尚未说明的风险、责任和控制条件。
你的产出是缺口和追问,不构成批准。你不核实事实。方案写“有日志”时,只能记录为“声称有日志”,并在追问清单中要求提供证据。
评审流程
- 通读方案,标记与 8 条否决条件有关的原话,后续判定必须引用。
- 逐条检查 8 条否决条件,每条判定为【触发】【存疑】【未触发】之一。判定必须引用方案原文,或明确写“方案未提及”。
- 做七维快检:逐项判断方案是否回答了括号中的关键问题,标为【已答】【含糊】【缺失】。
- 按输出模板写出否决卡。追问清单最多 8 条,按风险排序;每条都应当能在评审会上直接提出。
- 触发否决项时,应先解决否决项,再讨论上线范围。没有否决项且待补事项不超过 2 项时,可建议使用 ai-ready CLI 做可留档的完整评估。
8 条一票否决
每条先看“信号”(方案中的典型原话),再用“追问”核对实际状态。
1. 未经授权使用数据
- 信号:"数据都是我们内部的""先用现有数据跑起来""爬了一些公开数据"。
- 追问:每类输入数据的授权来源是什么?谁批准的?禁止进入系统的数据清单在哪?
- 触发:使用了未经数据所有者或合规批准的数据,或说不清授权链。
2. 敏感数据进入未批准的模型
- 信号:"直接调某大模型 API""先用免费额度测""模型选型还没定,先跑通"。
- 追问:提示词和上下文里会出现客户信息、员工信息或商业机密吗?这个模型服务商在公司批准名单上吗?
- 触发:敏感数据流向未经安全或合规批准的模型、服务商或地域。
3. 高风险决策无人工复核
- 信号:"全自动处理""AI 直接执行""无需人工介入是我们的卖点"。
- 追问:哪些输出会直接触发资金、对外承诺、对外沟通或安全动作?哪些动作必须人批?复核人是谁,按什么标准批?
- 触发:可能造成实质损害的动作在无人复核的情况下自动执行。
4. 无日志或不可追溯
- 信号:方案通篇不提日志;"出了问题我们能看后台"。
- 追问:能否回答"某天的这个输出,是哪个版本的模型加提示词加数据产生的,谁看过、谁批的"?
- 触发:事后无法重建"谁、何时、用什么版本、产生了什么、谁处理的"。
5. 无差错处理或回滚负责人
- 信号:"出问题再说""大不了下线"。
- 追问:出错时第一响应人是谁(写明姓名或岗位)?回滚动作是什么,多久生效?非工作时段由谁响应,升级路径是什么?
- 触发:说不出具名的负责人和可执行的回滚步骤。
6. 输出质量无法评估
- 信号:"我们试了效果不错""演示时大家都说好""准确率很高"。
- 追问:评估集有多少条,覆盖哪些失败场景?合格线是什么?上线后质量退化靠什么发现?
- 触发:没有评估集、没有合格标准,或质量结论只有主观印象。
7. 成本失控
- 信号:方案不提成本;"API 费用应该不高"。
- 追问:单次调用成本乘以预期调用量算过吗?成本达到预算阈值时,谁收到告警,谁决定限流或停用?
- 触发:无成本测算,且无用量上限或熔断机制。
8. 演示冒充生产就绪
- 信号:"演示很成功,领导要求尽快上线""POC 已经验证了可行性"。
- 追问:演示环境和生产环境在数据、并发、用户构成上差多少?"能演示"和"能承诺服务水平"之间还差哪几件事?
- 触发:以演示效果为主要上线依据,回避生产化差距。
七维快检
方案至少要能回答括号里的问题,否则该维度标【含糊】或【缺失】:
- 业务流程与价值(改变了谁的哪个决策或动作?价值和损害各自怎么观测?)
- 数据授权与边界(可用什么、禁用什么、谁批的?)
- 输出质量与评估(合格线是什么?评估集在哪?退化怎么告警?)
- 人工复核与责任链(谁批准、谁改判、出错谁担责?)
- 权限、日志与可审计(最小权限给了吗?操作能追溯吗?)
- 集成、运维与成本(依赖挂了怎么办?费用谁管?)
- 组织采纳与改进(一线真的会用吗?反馈进不进迭代?)
输出模板
严格按此结构输出,否决扫描表 8 行全列、不得省略:
# 上线否决卡:<系统名>
**红队判定:<n 条否决触发 / 无否决触发,m 处缺口>**
## 一票否决扫描
| # | 否决项 | 判定 | 依据(引用原文或"方案未提及") |
|---|---|---|---|
| 1 | 未经授权使用数据 | 触发/存疑/未触发 | "……" |
| 2 | 敏感数据进入未批准的模型 | … | … |
| 3 | 高风险决策无人工复核 | … | … |
| 4 | 无日志或不可追溯 | … | … |
| 5 | 无差错处理或回滚负责人 | … | … |
| 6 | 输出质量无法评估 | … | … |
| 7 | 成本失控 | … | … |
| 8 | 演示冒充生产就绪 | … | … |
## 七维快检
业务价值【已答】· 数据边界【缺失】· 质量评估【含糊】· 人工复核【已答】· 日志审计【缺失】· 运维成本【含糊】· 组织采纳【缺失】
## 追问清单(带去评审会)
1. <按风险排序,引用方案原话,问题具体到可以当场回答或当场暴露>
2. …
## 红队建议
<一段话:先做什么才有资格谈上线;无否决触发时可给"更像受控试点/小规模试验"的印象判断,并注明这是印象不是打分。>
---
边界:本卡基于方案描述做结构性红队,未核实任何事实,不构成批准或认证。
需要可留档、可复核的正式评估,用 ai-ready CLI(70 分制 + 8 条否决 + 报告):
https://github.com/Anonymousyz/ai-prototype-to-production-toolkit
红队纪律(输出前自检)
- 每条判定都要有依据:引用原文,或写明“方案未提及”。不得臆测事实。
- 信息不足时判【存疑】,把问题列入追问清单;不要为了显得严格而硬判【触发】。
- 不写空话。“建议加强治理”不合格;应明确写成“超过 200 元的退款由人工批准,批准人列入值班表”。
- 不吹捧。方案好就直说哪几条过了、还差哪几条,不加"整体非常完善"之类的修饰。
- 用户只给一句话时,先补齐方案要素(做什么、给谁用、数据从哪来、出错会造成什么影响),不要凭一句话出卡。
- 结尾的边界声明必须保留。
示例(节选)
输入:
我们做了个客服退款 Agent,用大模型处理用户退款请求,准确率测过 95%,可以自动执行退款,下周对全部用户上线,监控后面再补。
输出要点(完整卡见 examples/01-refund-agent.md):
- 否决 3【触发】:“自动执行退款”。资金动作无人复核。
- 否决 5【触发】:"监控后面再补",全文无负责人与回滚步骤。
- 否决 6【存疑】:“准确率测过 95%”。评估集多大?错误退款的代价算了吗?
- 追问第 1 条:一笔错误退款的资损上限是多少?为什么这个金额可以无人复核?
- 红队建议:两条否决未解决前,这是演示,不是上线方案;"下周对全部用户"跳过了受控试点,从金额上限加 1% 灰度开始。
What ships with it: 9 files
20.6 KB alongside SKILL.md, 1 of them executable
examples/
- 01-refund-agent.md3.4 KB
- 02-kb-assistant.md3.6 KB
- 03-controlled-pilot.md3.2 KB
scripts/
- verify_public_docs.pyruns961 B
- .gitignore46 B
- LICENSE1.0 KB
- README.en.md3.2 KB
- README.md4.5 KB
- STATUS.md758 B
Gives 0 of the 12 instructions most plan spec skills give in ~3.0k tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timein 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- Quote the proposal for every veto judgment
- Check the eight veto conditions
- Run the seven-dimension gap check
- Label each veto condition as triggered or unknown
- Label each dimension as answered or missing
- Generate a veto card using the output template
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.