Talk Text Review

---
name: talk-text-review
version: 1.0.0
description: "讲稿/分享稿的文本验收——查的不是错别字，是**姿态**：这份稿子读起来是「我教你们」还是「我跟你们聊」。用心理逆反、自我暴露、认识论谦逊这几条机制，逐句找出会把听众推到对立面的表达并给出改写。触发词：讲稿验收、分享稿检查、这么讲会不会得罪人、居高临下、技术分享、演讲稿、内部分享、会不会太说教、口吻检查。适用于对内技术分享、公众号、文档开篇、PR 描述等任何「同级或高手在场」的表达场景。"
metadata:
  appliesTo: ["技术分享", "公众号", "内部交流", "文档开篇"]
---

# 讲稿文本验收：先验姿态，再验内容

## 什么时候用

在**同级同事、领域高手、或比你资深的人**面前讲东西之前跑一遍。内容再对，姿态错了也会招敌人——尤其讲「最佳实践」类主题时。

一句话判据：**这份稿子里，听众是「需要被教育的人」还是「我想请教的人」？**

## 核心机制（为什么姿态比内容更容易惹人）

1. **心理逆反（reactance）**：人感到自主权被侵犯时会本能反驳，与内容对错无关。「你应该加 AGENTS.md」是规范性陈述，触发逆反；「我加了 AGENTS.md，然后发现……」是经验陈述——**经验无法被反驳，只能被补充**。这是全篇最重要的一条。
2. **自我暴露（self-disclosure）降低威胁感**：讲自己的失败会触发亲近感而非防御。翻车经历的价值远超它的信息量，因为它同时说明「我不是来立牌坊的」。
3. **出丑效应（pratfall effect）**：有能力的人展示小失误，好感度上升；无能力的人这么做才下降。对在场有产出的人是正向的。
4. **认识论谦逊 → 站位转换**：说「这是我拍的，想听听你们怎么排」，把强者从**审判席**请到**同盟席**。人一旦进入「帮你想」的角色，就不会再进入「挑你错」的角色。站位是讲者分配的。
5. **叙事传输（narrative transportation）**：故事比结论更容易被接受，因为听众在跟随情节时不会同时启动反驳。

## 分级判据

### 🔴 致命（必改，这几处最招敌人）

| 症状 | 为什么致命 | 改法 |
|---|---|---|
| 标题含「如何/怎样/必须/正确姿势/最佳实践」 | 第一秒就把讲者架上讲台 | 换成叙述性：「我做了 X，结果 Y」 |
| 结尾是「结论」「总结」 | 你凭什么下结论 | 换成「我还没想清楚的几个问题」 |
| 行动项主语是听众（「今天就能做的三件事」） | 给同级布置作业 | 主语换成自己：「我接下来打算做的三件事」 |
| 「你的 X 可能……而不自知」 | 字面意思是「你不知道，我知道」 | 换成「我的 X 就是这样，我自己完全没发现」 |
| 拿自己的标准给知名项目/他人工作打分 | 最容易被攻击的一页 | 保留数据，前面加自我限定（见下） |

### 🟡 重要（建议改）

- **第二人称祈使句密度过高**：「你要」「你应该」「记住」「别忘了」「一定要」
- **规范词**：应该 / 必须 / 正确的做法是 / 大家都知道 / 显然 / 其实
- **隐含优越**：「很多人不知道」「大部分项目都没做」「这是个常见误区」
- **无出处的判断**：把个人判断说成客观事实，没标记「我的判断是」

### 🟢 加分（有就更好）

- 开篇 30 秒内出现一次自己的失败
- 数据旁标注来源与局限（样本量、时间、适用范围）
- 至少一处「这点我不确定」
- 结尾的开放问题是**真开放**（你确实没答案），不是明知故问的引导题

## 可执行扫描

```bash
F=<稿子路径>

# 🔴 第二人称祈使 + 规范词密度
grep -nE "你(的|们)?(应该|必须|要|得|需要)|记住|别忘了|一定要|正确的做法" "$F"

# 🔴 隐含优越
grep -nE "而不自知|很多人(不知道|没有)|大部分[项目人]|常见误区|显然|其实很简单" "$F"

# 🔴 布道式标题与结构
grep -nE "^#+ .*(如何|怎样|必须|正确|最佳实践|三件事|结论|总结)" "$F"

# 🟢 反向检查：有没有自我暴露（应该 ≥1 处，最好在前 30%）
grep -nE "我(踩|翻车|以为|没想到|搞错|不知道|完全没发现)|第一刀砍在自己身上" "$F"

# 🟢 反向检查：有没有认识论谦逊标记
grep -nE "我(的判断|自己拍的|不确定|还没想清楚)|想听听|可能不对|只是我的" "$F"
```

前三条命中越多越危险；后两条**一条都没有**才是最危险的信号。

## 改写对照（同一事实，两种姿态）

| 布道 | 交流 |
|---|---|
| 你的站可能被默认屏蔽而不自知 | 我的站就被默认屏蔽了，我自己完全没发现 |
| 应该给仓库加 AGENTS.md | 我给仓库加了 AGENTS.md，这是我的写法 |
| 今天就能做的三件事 | 我接下来打算做的三件事 / 如果你也想自查，一条命令 |
| 结论：别让站被屏蔽 | 我还没想清楚的：放行 AI 爬虫对商业站有没有风险 |
| 这九个维度是…… | 这九个维度和权重都是我自己拍的，想听听你们觉得该怎么排 |
| 常见误区是…… | 我一开始也是这么想的，后来发现…… |

## 结尾开放问题怎么设计

这是全场成败点。合格的开放问题满足三条：

1. **你确实没答案**（假问题会被一眼看穿，比不问更糟）
2. **在场的人有可能答得上**（问一个没人懂的问题等于炫技）
3. **答案会改变你接下来的做法**（说明你真的在征询，不是走过场）

反例：「大家还有什么问题吗？」——把责任推给听众，且默认自己讲完了。
正例：「AGENTS.md、CLAUDE.md、.cursorrules 各写一份，最后是不是在维护五份同样的东西？有没有人趟过这个，怎么收敛的？」

## 输出格式

按 🔴/🟡/🟢 分级列出，每条给：**位置 → 原文 → 为什么 → 改写**。不要只说「语气偏说教」这种没法执行的话；也不要为了凑数把中性表达标成问题——**姿态问题通常集中在标题、结尾、行动项三处**，正文的技术描述一般不需要动。

最后给一句整体判断：这份稿子现在是「分享」还是「交流」，以及改完之后是什么。

## 边界

- 只验姿态与结构，不改技术内容、不核查事实正确性
- **不要把稿子改弱**：谦逊 ≠ 删掉观点。判断该留，只是要标记成「我的判断」而不是「客观事实」
- 对外营销稿、对下培训材料不适用（那些场景本来就该是布道姿态）