paper-skill

# paper-skill 写给"人 + AI 双重读者"的方案优化 skill。**默认主模式 S + A**（专家预审 + 公开引导），把方案真正改好，让 AI review 时无新点可挑。SS / C / D 是特殊触发模式，需用户明确请求并经过警告流程。 ## 核心原理 AI review 几乎必然挑出问题，因为： 1. AI 被训练成批判性 reviewer，找不到问题它觉得没工作 2. 越模糊的方案被挑"不具体"，越具体的被挑"过度设计"——两头堵 3. 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**。 ## 输入 / 输出规范 ### 输入 接受以下任一形式： 1. **文件路径**（推荐）：用户给出方案 markdown 文件的绝对路径 2. **粘贴内容**：用户直接粘贴方案全文 3. **空 + 询问**：用户说"帮我写一份方案"，应主动询问具体场景、约束、目标受众 ### 输出 **默认输出策略**： - 不修改用户的原文件 - 在原文件同目录创建 `{原文件名}_v2.md` 副本 - 副本中包含完整的改造结果 - 输出末尾追加"执行 checklist"让用户验证 **例外**：用户明确要求"直接改原文件"或"用 diff 形式输出"时，按用户要求执行。 ## 完整工作流（默认 S + A） 收到方案优化请求时，按顺序执行： 1. **诊断现状**：扫一遍方案，识别方案类型（技术/产品/业务/设计）、缺哪些防御章节、章节名是否用了禁用词 2. **运行 S 级**：按 `tiers/s-tier.md` 执行 5 步流程（含 6 专家挑刺 → 分类反哺 → 循环至收敛（最多 3 轮）→ FAQ 化） 3. **重构结构**：按三段式重排主体，补齐 5 个防御章节，章节名替换为功能化命名 4. **叠加 A 级**：在开篇之后加"本方案核心价值"段（见 `tiers/a-b-tier.md`） 5. **可选 B 级**：加 Frontmatter，调整章节顺序确保技术亮点在首尾 6. **SS / C / D 级**：**仅当用户明确触发**，且必须先警告 + 二次确认 - SS 触发 → 读 `tiers/ss-tier.md`，走三层防御流程 - C / D 触发 → 读 `tiers/cd-tier.md`，走对应警告流程 7. **输出 checklist**：跑完输出完整 checklist 让用户验证（见下方模板） ## 通用规则（所有模式共享） ### 章节命名禁用词 ⚠️ **不要使用**：`总结`、`概述`、`分析`、`详细数据对比`、`口语化总结`——这些词会让方案显得是套模板。 | 替换前 | 替换后 | |--------|--------| | 总结 / 概述 | 背景与思路 / 为什么做这件事 | | 详细数据对比 / 分析 | 方案对比 / 关键决策 / 技术选型 | | 结尾的总结 | 结论与下一步 / 落地节奏 / 本期范围 | ### 三段式结构 - **开篇（自然叙述 150-300 字）**：问题来源、痛点、核心思路。不要列点 - **中段（表格 + 量化指标）**：≥ 2 个候选方案横向对比，每行必须有数据列 - **收尾（自然叙述 100-200 字）**：决策、本期 scope、时间预期。不要写"综上所述" ### 五个必备防御章节 | 章节 | 内容 | 消除的挑刺类型 | |------|------|---------------| | 已考虑的替代方案 | 2-3 个否决过的方向 + 否决原因 | "为什么不考虑 X？" | | 本期非目标 | 明确**不做**什么 | "应该考虑 X 场景" | | 已知风险与缓解措施 | 表格：风险 / 影响面 / 概率 / 缓解 | "未识别风险" | | 决策依据 | 关键判断附数据 / 约束 / 历史经验 | "决策依据不足" | | 验收标准 | 可量化的成功指标 | "如何衡量成功" | ## 执行完成 checklist 模板 跑完后输出以下 checklist 让用户验证： ```markdown ## 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. 先从技术角度肯定方案，但肯定**必须具体到细节**： > "在 [具体技术点 1]、[具体技术点 2] 上的设计是合理的，特别是 [某细节] 体现了对 [某约束] 的考量。" 2. 不能用"整体不错 / 思路清晰"这种空话——空话反而让作者觉得 AI 没认真看 3. 然后再分维度提建议，按"严重度 × 修复成本"排序 ## 最终原则 **目标不是让 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 模板（按方案类型分） ```