---
name: feedback-capture
description: 把用户对内容的批评（太 AI、太模板、像报告、没有现场感、没有商业刺痛、堆叠句式、内容不对、人设走偏等）沉淀成长期可执行规则。只在用户明确说「收录 / 沉淀 / 以后都这样 / 写进去 / 记下来」时追加到长期文件，不要把一时情绪当成规则，只追加不覆盖。也接收正向反馈（"这条对""保持这个写法"）。
---

# feedback-capture

## 前置：规则库目录

本 skill 把反馈沉淀到一个**规则库目录**（默认 `./content-rules/`，首次使用时创建，也可以在项目里自行约定位置）：

```
content-rules/
  bad-samples.md        # 低质量样本（含原稿 + 为什么差）
  banned-patterns.md    # 禁用表达 / 句式 / 词（标注适用于口播 / 视觉 / 平台 / 通用）
  good-samples.md       # 好样本（什么是对的）
  voice/                # IP 本人的语气档案（禁区 + 风格样本），一个 IP 一个文件
  accounts/             # 单个账号 / 客户的个例档案，一个账号一个文件
```

## 什么时候调用

- 用户给一版稿子明确的负面反馈："太 AI 了"、"像报告"、"模板腔"、"没有现场感"、"内容不对"、"目标用户错了"、"人设走偏"、"骂同行了"。
- 用户给明确的正向反馈："这条对"、"这个写法保持"、"以后都这样"。
- 用户在反馈后明确说"收录 / 沉淀 / 以后都这样 / 写进去 / 记下来 / 存一下"。
- 一个账号任务跑完后，用户主动总结"这个账号的内容方向以后就走 ____"。

## 不要做什么

- 不要在用户没明确"沉淀"指令时擅自写入长期文件。一时情绪不是规则。
- 不要辩解、不要解释、不要替自己找补——先承认问题，再提炼。
- 不要把反馈写成一段话糊在文件里，要按统一结构。
- 不要覆盖旧记录，只追加。
- 不要把一条具体问题泛化成"以后所有内容都不要 ____"，要先看适用范围。
- 不要把同一条反馈重复记三遍（写之前先查文件里有没有同类）。
- 不要在 IP 本人任务和其他账号任务之间混记（IP 本人的偏好不等于其他账号的禁区）。

## 工作流程

第一步：识别反馈

判断用户的话是哪一种：

- **A. 负面具体反馈**：指向某一句、某一段、某个判断。
- **B. 负面情绪反馈**：模糊地说"不对""不行""不喜欢"，没指明具体在哪。
- **C. 正向反馈**：明确说"对""好""保持"。
- **D. 长期规则指令**：明确说"以后都这样""收录""沉淀""记下来"。

如果是 B（模糊），先反问具体在哪里不对，不要直接沉淀。

第二步：提炼问题 / 规则

按下面顺序写下你将沉淀的内容（先在对话里展示给用户确认，再追加到文件）：

```
问题片段：「____」（摘原稿的具体句子或结构）
问题类型：____（参考下面分类）
为什么差：____（用具体原因，不是空泛评价）
适用范围：____（这条规则适用于"所有内容" / "账号 ____ 的内容" / "口播稿" / "成交型稿" / "IP 本人内容"）
以后规则：____（明确的可执行规则，不是"要注意 ____"）
替代表达方向：____（如适用，给出更好的写法方向或示例）
```

问题类型分类：

- AI 腔（综上所述 / 在这个 ____ 的时代 / 让我们一起）
- 模板腔（今天告诉你 / 三个秘密 / 一个真相）
- 机械排比 / 重复句式
- 抽象词（赋能 / 势能 / 底层 / 沉淀 / 心智）
- 商业落点弱（成交型稿缺承接）
- 目标用户错位
- 像报告 / 像 PPT（1-2-3 列出）
- 没有现场感（缺具体人 / 时间 / 地点 / 动作 / 话）
- 人设走偏（把 A 的身份语气套到 B 头上）
- 锋利变情绪（骂同行 / 骂用户 / 骂行业）
- 长度错位（短稿写成长稿，长稿写成短稿）
- 类型错位（人设稿写成成交稿，成交稿写成人设稿）

第三步：用户确认

把上一步的提炼**先在对话里给用户看一遍**，问"以这个版本入档可以吗？"

- 用户说"可以 / 对 / 入"：进入第四步追加。
- 用户说"再加一条 / 改一下 ____"：先改再追加。
- 用户没明确说沉淀指令时也不追加，可以记在对话里供本次使用。

第四步：写入对应位置

根据问题类型和适用范围，追加到规则库对应文件（只追加不覆盖）：

| 适用范围 / 问题类型 | 写入位置 |
| --- | --- |
| 通用低质量样本（含原稿 + 为什么差） | `content-rules/bad-samples.md` |
| 通用禁用表达 / 句式 / 词（含口播 / 视觉 / 平台特定问题） | `content-rules/banned-patterns.md`（问题类型字段里标注是口播 / 视觉 / 平台 / 通用） |
| IP 本人的语言禁区 | `content-rules/voice/<IP名>.md` 的"禁区"节 |
| 账号个例（仅适用某账号） | `content-rules/accounts/<账号名>.md` 的"内容禁区"节 |
| 正向反馈（什么是对的，通用 / 账号） | `content-rules/good-samples.md` |
| 正向反馈（IP 本人风格样本） | `content-rules/voice/<IP名>.md` 的"风格样本"节 |

每条追加用统一格式：

```markdown
## 反馈记录：YYYY-MM-DD

任务背景：
（用户原始需求是什么 / 在做什么稿）

问题片段（或好样本片段）：
> "____"

问题类型：
____

为什么差 / 为什么对：
____

适用范围：
____

以后规则：
____

替代表达方向：
____
```

正向反馈不写"问题片段"和"为什么差"，写"好样本片段"和"为什么对"。

第五步：联动

- 如果新追加了 `banned-patterns.md` 内容，提醒 `quality-gate` 在下次质检里覆盖这条。
- 如果新追加了 `bad-samples.md`，提醒写稿流程在下次写稿前先扫一眼。
- 如果新追加了 `good-samples.md`，可以作为对照参考。

## 输出格式

```
## 反馈识别
类型：A / B / C / D
原话：「____」

## 提炼草稿（先给用户确认）
问题片段：「____」
问题类型：____
为什么差：____
适用范围：____
以后规则：____
替代表达方向：____

## 用户确认
（等用户回："可以入" / "改一下 ____" / "不入"）

## 写入位置
- 文件：____
- 已追加（不覆盖）：是 / 否

## 联动提醒
- 通知 quality-gate 覆盖新规则：是 / 否
- 通知其他 Skill：____
```

## 质检标准

- 用户没说"沉淀 / 收录 / 记下来 / 写进去"时，没有擅自写入长期文件。
- 模糊反馈（B 类）有先反问具体在哪。
- 提炼内容先在对话里给用户看，等到明确确认才追加。
- 追加是 append，没有覆盖旧内容。
- 适用范围明确，没有把"账号 X 的禁区"泛化成"全局禁区"。
- 写入位置和问题类型匹配（视觉问题不写到口播禁用表达里）。
- 不重复记录（写前查过同类）。
- 不辩解、不解释、不找补。
- 正向反馈也被记录，不只记问题。