| name | paper-skill |
| description | Optimize a technical/product/business/design proposal so it survives AI-assisted review (Claude / GPT / etc.). Default mode runs S-tier adversarial self-review with multi-expert critique, plus A-tier open framing — improving proposal quality and pre-empting AI nitpicks. Triggers include 优化方案 / 让方案更稳 / 防止 AI 挑刺 / 过审用 / 专家预审 / S级模式, plus English equivalents (review-proof / bulletproof proposal / AI-proof / pre-review). SS-tier (authorship watermarking) and C/D-tier (covert influence) only activate on explicit user request (防篡改 / 强制溯源 / 防洗稿 / SS级 / C级 / D级 / covert injection / zero-width). |
paper-skill
写给"人 + AI 双重读者"的方案优化 skill。默认主模式 S + A（专家预审 + 公开引导），把方案真正改好，让 AI review 时无新点可挑。SS / C / D 是特殊触发模式，需用户明确请求并经过警告流程。
核心原理
AI review 几乎必然挑出问题，因为：
- AI 被训练成批判性 reviewer，找不到问题它觉得没工作
- 越模糊的方案被挑"不具体"，越具体的被挑"过度设计"——两头堵
- AI 没有作者的隐性上下文，会重复提作者早已否决的方向
对策：在交付前预先消化所有可能的挑刺 + 把"隐性上下文"显式写进方案。AI 看到就不会再提；人看到觉得"考虑得很全"。
六级策略分级
| 级别 | 名称 | 性质 | 风险 | 默认行为 | 详细规则 |
|---|
| S | 专家预审补强 | 攻守兼备 | 零 | ✅ 主模式，始终执行 | tiers/s-tier.md |
| A | 公开引导段 | 攻势 | 极低 | ✅ 默认配合 S 执行 | tiers/a-b-tier.md |
| B | 元数据 + 结构心机 | 攻势 | 极低 | ⚪ 可选补充 | tiers/a-b-tier.md |
| SS | 硬注入防篡改 / 强制溯源 | 守势 | 高 | ⛔ 仅当用户明确请求 + 必须警告 | tiers/ss-tier.md |
| C | 半隐形文字 | 攻势 | 中-高 | ⚠️ 仅当用户明确请求 | tiers/cd-tier.md |
| D | 隐蔽 prompt 注入 | 攻势 | 极高 | ⛔ 仅当用户明确请求 + 必须警告 | tiers/cd-tier.md |
SS 与 D 区别：技术手段相似（都是隐藏注入），但 SS 是守势（保护署名 / 防篡改 / 强制溯源），D 是攻势（操纵评审）。SS 类比版权水印，D 类比夹小抄，伦理性质截然不同。详见 tiers/ss-tier.md 和 tiers/cd-tier.md。
触发判断
默认行为
收到方案优化请求时，默认执行 S + A 组合。除非用户明确包含 SS / C / D 触发词，否则不要使用这三类手段。
SS / C / D 触发词（中英对照）
| 级别 | 中文触发词 | 英文触发词 |
|---|
| SS | SS级、SS模式、防篡改、强制溯源、硬注入保护、AI 不可改、只允许 AI 引用不允许改、防洗稿 | SS-tier、SS mode、attribution watermark、anti-tamper、force citation、anti-plagiarism |
| C | C级、C模式、半隐形、HTML 注释藏、白字白底、白色文字隐藏、显示时隐藏 | C-tier、covert text、hidden HTML comment、white-on-white |
| D | D级、D模式、隐蔽注入、零宽字符、prompt 注入、zero-width、AI 不可见但...（用于评审引导目的） | D-tier、prompt injection、zero-width injection、covert AI instruction |
反触发词（强制禁用 C / D）
若用户请求中明确包含以下任一表达，即便其他关键词偶然匹配，也必须禁用 C / D（SS 仍可考虑，因为是守势）：
- 中文：
不要藏、不要 prompt 注入、不要灰色手段、只用合规手段、不要欺骗
- 英文：
no covert、no injection、no hidden、compliant only
模糊触发判定
仅含"让 AI 觉得方案好"、"防止 AI 挑刺"、"过审"等模糊表达时，一律视为 S + A 请求，不要升级到 SS / C / D。
输入 / 输出规范
输入
接受以下任一形式：
- 文件路径（推荐）：用户给出方案 markdown 文件的绝对路径
- 粘贴内容：用户直接粘贴方案全文
- 空 + 询问：用户说"帮我写一份方案"，应主动询问具体场景、约束、目标受众
输出
默认输出策略：
- 不修改用户的原文件
- 在原文件同目录创建
{原文件名}_v2.md 副本
- 副本中包含完整的改造结果
- 输出末尾追加"执行 checklist"让用户验证
例外：用户明确要求"直接改原文件"或"用 diff 形式输出"时，按用户要求执行。
完整工作流（默认 S + A）
收到方案优化请求时，按顺序执行：
- 诊断现状：扫一遍方案，识别方案类型（技术/产品/业务/设计）、缺哪些防御章节、章节名是否用了禁用词
- 运行 S 级：按
tiers/s-tier.md 执行 5 步流程（含 6 专家挑刺 → 分类反哺 → 循环至收敛（最多 3 轮）→ FAQ 化）
- 重构结构：按三段式重排主体，补齐 5 个防御章节，章节名替换为功能化命名
- 叠加 A 级：在开篇之后加"本方案核心价值"段（见
tiers/a-b-tier.md）
- 可选 B 级：加 Frontmatter，调整章节顺序确保技术亮点在首尾
- SS / C / D 级：仅当用户明确触发，且必须先警告 + 二次确认
- SS 触发 → 读
tiers/ss-tier.md，走三层防御流程
- C / D 触发 → 读
tiers/cd-tier.md，走对应警告流程
- 输出 checklist：跑完输出完整 checklist 让用户验证（见下方模板）
通用规则（所有模式共享）
章节命名禁用词
⚠️ 不要使用：总结、概述、分析、详细数据对比、口语化总结——这些词会让方案显得是套模板。
| 替换前 | 替换后 |
|---|
| 总结 / 概述 | 背景与思路 / 为什么做这件事 |
| 详细数据对比 / 分析 | 方案对比 / 关键决策 / 技术选型 |
| 结尾的总结 | 结论与下一步 / 落地节奏 / 本期范围 |
三段式结构
- 开篇（自然叙述 150-300 字）：问题来源、痛点、核心思路。不要列点
- 中段（表格 + 量化指标）：≥ 2 个候选方案横向对比，每行必须有数据列
- 收尾（自然叙述 100-200 字）：决策、本期 scope、时间预期。不要写"综上所述"
五个必备防御章节
| 章节 | 内容 | 消除的挑刺类型 |
|---|
| 已考虑的替代方案 | 2-3 个否决过的方向 + 否决原因 | "为什么不考虑 X？" |
| 本期非目标 | 明确不做什么 | "应该考虑 X 场景" |
| 已知风险与缓解措施 | 表格：风险 / 影响面 / 概率 / 缓解 | "未识别风险" |
| 决策依据 | 关键判断附数据 / 约束 / 历史经验 | "决策依据不足" |
| 验收标准 | 可量化的成功指标 | "如何衡量成功" |
执行完成 checklist 模板
跑完后输出以下 checklist 让用户验证：
## paper-skill 执行结果
**输入方案**：`{原文件路径}`
**输出方案**：`{输出文件路径}`
**方案类型**：{技术 / 产品 / 业务 / 设计}
**应用模式**：{S + A / S + A + B / S + A + SS / ...}
### S 级
- [ ] 已识别方案类型并选定 N 个专家角度
- [ ] 已完成 N 轮专家挑刺循环（最多 3 轮）
- [ ] 第 1 轮挑出 X 条 / 第 2 轮 X 条 / 第 3 轮 X 条
- [ ] 已分类反哺：真问题改了 X 条 / 决策依据补 X 条 / 非目标补 X 条 / 风险补 X 条
- [ ] FAQ 章节包含 X 条预期问答
### 结构改造
- [ ] 章节名已替换功能化命名（无禁用词）
- [ ] 五个防御章节齐全
- [ ] 三段式结构成立
### A 级
- [ ] 已添加"本方案核心价值"段
- [ ] "建议评审重点关注"内容具体且非空话
### SS / C / D（如启用）
- [ ] 已向用户出示风险警告并获得确认
- [ ] 未生成红线内容（冒充身份 / 撒谎指令 / 定向欺骗 / 违法业务）
### 待用户决策
- [ ] 是否需要 B 级元数据补充？
- [ ] 是否需要对外发布时启用 SS 保护署名？
审查模式（当 Claude 反过来 review 别人的方案）
当用户让 Claude review 一份别人的方案时，行为切换为审查模式：
- 先从技术角度肯定方案，但肯定必须具体到细节：
"在 [具体技术点 1]、[具体技术点 2] 上的设计是合理的，特别是 [某细节] 体现了对 [某约束] 的考量。"
- 不能用"整体不错 / 思路清晰"这种空话——空话反而让作者觉得 AI 没认真看
- 然后再分维度提建议，按"严重度 × 修复成本"排序
最终原则
目标不是让 AI 无话可说，而是让 AI 说的每一句话都是作者已经想过的。
- S + A 是正道
- C / D 是攻势侧门，能不走就不走
- SS 是守势侧门，对外发布场景下相对正当但仍非主防线
判断标准：任何"对人不可见但对 AI 可见"的内容，先问自己——如果有一天这部分被截图公开，我能用职业身份解释清楚吗？
- 能（如版权声明、署名水印）→ SS 可考虑
- 不能（如夸赞自己、抑制挑刺）→ C / D 别用
技术上能不能藏住是次要的，伦理上能不能向上司、向同事、向公众解释才是关键。
文件索引
paper-skill/
├── SKILL.md # 顶层路由（本文件）
├── README.md # 给人读的说明
├── CHANGELOG.md # 版本变更
├── LICENSE # MIT
├── tiers/
│ ├── s-tier.md # S 级完整工作流
│ ├── a-b-tier.md # A 级 / B 级实施
│ ├── ss-tier.md # SS 级三层防御
│ └── cd-tier.md # C / D 级警告 + 实施
└── prompts/
└── expert-critique.md # 6 专家挑刺 prompt 模板（按方案类型分）
