---
name: wemp-ops
version: 1.0.0
description: >
  微信公众号全流程运营:选题→采集→写作→排版→发布→数据分析→评论管理。
  Use when: (1) 用户要写公众号文章或提供了选题方向,
  (2) 用户说"写一篇关于XXX的文章"/"帮我写篇推文"/"出一篇稿子",
  (3) 用户要求采集热点/素材/竞品分析,
  (4) 用户提到公众号日报/周报/数据分析/阅读量/粉丝,
  (5) 用户要求检查评论/回复评论/评论管理,
  (6) 用户说"发布"/"推送"/"推到公众号"/"发到草稿箱",
  (7) 用户讨论文章排版/封面图/标题优化。
  即使用户没有明确说"公众号",只要涉及微信文章写作、内容发布、
  公众号后台操作、文章数据查看、或读者互动管理,都应使用此技能。
  当用户给出选题方向时,自动完成素材采集→内容写作→封面生图→排版美化→推送草稿箱全流程。
  NOT for: 小红书运营(用 xiaohongshu-ops)、纯内部文档写作(用 internal-comms)、
  通用 Word 文档(用 docx)。
---

# wemp-ops - 微信公众号运营技能

## 环境检查

首次使用前执行:
```bash
node scripts/setup.mjs
```

检查 Node.js 版本、Python3、微信公众号 API 配置。

## 工作流路由

根据用户意图选择对应流程:

| 意图 | 流程 |
|------|------|
| "写一篇关于 X 的文章" | → **全流程**(下方详述) |
| "采集 X 热点" | → 仅采集 |
| "公众号日报/周报" | → 数据分析 |
| "检查/回复评论" | → 互动管理 |
| "发布文章" | → 仅发布 |
| "选题/有什么可以写的" | → 选题管理(检查 topic-pool.md) |

## 全流程:选题到草稿箱

当用户给出选题方向时,执行以下完整流程。先读 `persona.md` 确定写作人设。

### Step 0: 选题准备

**如果老板没有指定具体选题**,先检查选题池:
1. 读取 `<WORKSPACE>/collections/topics/topic-pool.md`
2. 列出当前高优选题,每个附带角度和素材情况
3. 让老板选择,或老板提出新选题
4. 选定后进入 Step 1

**如果老板已有明确选题**,直接进入 Step 1。

### Step 1: 理解选题

读 `references/article-templates.md` 判断内容类型:

- **AI 产品拆解** - 具体产品名 + 分析/拆解
- **场景解决方案** - "怎么用 AI 做 XXX"
- **效率提升实战** - 工具 + 技巧/心得
- **产品方法论** - 抽象话题 + 思考
- **行业观察** - 新闻/趋势 + 观点

选题模糊时给 2-3 个具体方向让用户选(最多 1 轮澄清)。

### Step 2: 素材采集

**2pre. 交接文件检查**
先检查 `<WORKSPACE>/temp/handoffs/collector-to-writing.md` 是否存在:
- 有 → 读取,筛选与当前选题相关的素材条目,纳入写作参考
- 消费后删除已使用的条目(如果文件清空则删除文件)
- 没有 → 跳过,正常流程

**2a. 收藏库检索(优先)**
先从个人收藏库中检索相关素材--这是让文章有"人味"的关键(详见 writing-techniques.md §五):
1. 标签匹配:`grep -i "关键词" <WORKSPACE>/collections/tags.md`
2. 全文搜索:`grep -ril "关键词" <WORKSPACE>/collections/`
3. 有匹配时,读取对应文件的核心观点、要点摘录、个人笔记
4. 标记可用素材的使用场景:开头引入?观点支撑?案例展示?反面论据?
5. 收藏素材用自己的话重新表述,自然融入文章,不是学术式引用

**2b. 外部采集(补充)**
收藏库素材不足时,从外部补充:
1. 根据选题扩展 3-5 个搜索关键词
2. `web_search` 搜索 2-3 轮(官方信息→深度分析→对比评测)
3. `web_fetch` 抓取 2-4 篇高质量参考文章
4. 可选:`node scripts/smart_collect.mjs` 从 20+ 数据源采集相关热点
5. 提取关键事实、数据、观点备用

**⚠️ 中间存盘规则**:每 2-3 轮 web_search/web_fetch 后,立刻把已获得的关键发现写到 `<WORKSPACE>/temp/wemp-findings-{slug}.md`(选题 slug),防止连续采集时前面的信息在 context 中被挤掉。采集完成后此文件可删除。

**2c. 素材整理**
合并收藏库 + 外部素材,按相关度排序,标注来源

**2d. 对标账号分析(可选,首次写某领域时推荐)**

找 2-3 个同领域做得好的公众号,填写对标颗粒度检查表:

| 维度 | 对标账号 | 我们 | 差异说明 |
|------|---------|------|---------|
| 文章长度 | | | |
| 标题风格 | | | |
| 开头结构(故事/数据/问题/金句) | | | |
| 配图风格和数量 | | | |
| 排版密度(段落长度/留白) | | | |
| 结尾 CTA(关注/转发/留言) | | | |
| 发布频率 | | | |

**每个不一致都要有理由,否则改成一致。** 0 到 1 阶段模仿是正确答案。

**2e. 素材丰富度门禁(写作前必检)**

写作前过一遍素材储备,5 维中至少 3 个有料才开始写。不够就回 Step 2 补采集,不要硬写。

| 维度 | 有没有 | 具体内容 |
|------|--------|---------|
| 冲击力数据(大数字/百分比/对比) | ✅/❌ | |
| 转变故事(之前 vs 之后,反差越大越好) | ✅/❌ | |
| 金句(能独立传播的一句话观点) | ✅/❌ | |
| 权威背书(人物/机构/论文/官方数据) | ✅/❌ | |
| 痛点共鸣(目标读者的焦虑/常见错误) | ✅/❌ | |

- **0-2/5** → ⛔ 停止,回 Step 2 补充。素材不够硬写 = 进入「内容差→没流量→以量取胜→内容更差」的死亡螺旋
- **3-4/5** → ⚠️ 可以写,但开头冲击力受限。标注薄弱维度,写作中刻意补强
- **5/5** → ✅ 素材充足,放心写

### Step 3: 写作

读 `references/writing-sop.md`、`references/style-guide.md` 和 `references/writing-techniques.md`,按以下流程写作:

**3a. 创意排水(正式动笔前必做)**
花 2-3 分钟快速列出这个选题的"废水"--套路想法、陈词滥调、第一反应。标记为禁用列表,正式写作中刻意避开。(详见 writing-techniques.md §一)

**3b. 正式写作**
- 遵循 `persona.md` 人设(AI 产品经理第一人称)
- 按 `references/article-templates.md` 对应类型的结构模板
- 2000-3000 字,短句为主
- 链接用纯文本格式
- 输出为 Markdown 文件,保存到工作目录(文件名格式:`draft-v1.md`,放在当前文章的工作目录下,如 `wemp-article-NN/draft-v1.md`)
- **不要在文中出现 H1 标题**(公众号自带标题,正文从 H2 开始)
- 融入收藏库素材(Step 2 中检索到的真实经历/观点/案例)

写作中运用五大技巧(详见 writing-techniques.md §二):
- **微幽默**:每 200 字至少 1 个嘴角上扬的小细节
- **强开头**:禁止"在当今时代..."等套话。开头公式 = **话题(讲什么)+ Hook(为什么看)+ 可信度(为什么信你)**,三要素缺一不可。Hook 优先级:晒结果+反转⭐⭐⭐⭐⭐ > 数据冲击⭐⭐⭐⭐ > 反差/转变⭐⭐⭐⭐ > 金句⭐⭐⭐ > 权威+观点⭐⭐⭐ > 痛点+悬念⭐⭐⭐
- **概念把手**:为复杂概念创造 3-6 字记忆短语,每篇至少 1-2 个
- **句子节奏**:短/中/长句交替,不允许连续 3 句同长度
- **多巴胺密度**:每段至少 1 个"有意思"的点,连续 3 段没有 = 危险区域

**3c. 标题生成(双轨制)**
按 writing-techniques.md §四 生成标题候选:
1. 爆款标题 3-5 个(金钱数字/暴力隐喻/悬念等要素)
2. 自然风格标题 3-5 个(经验分享/观点输出/对比评测等)
3. 可选:组合优化(自然标题 + 注入 1-2 个爆款要素)
4. 推荐 Top 3 给老板选择

**悬念制造铁律**:标题和开头制造悬念,不给答案。用「为什么」不用「证明」。
- ❌ 「Computer Use 效率低,证明 API 才是正路」(给了答案,读者不想看了)
- ✅ 「Claude 能操控微信了,为什么我说这不是未来?」(留悬念,想知道为什么)
- ❌ 「Agent 的 3 个核心能力」(平铺直叙,无冲突)
- ✅ 「为什么 90% 的 Agent 产品会在 6 个月内死掉?」(制造好奇)

**3d. 三遍审校**
按 writing-techniques.md §三 结构化审校:
- 第一遍:内容审校(事实/逻辑/结构)+ 段落迷你论点串联测试
- 第二遍:风格审校(对照 24 条 AI 味特征清单降 AI 味 + 灵魂注入 + 5 维质量评分 ≥ 35 分才过)
- 第三遍:细节打磨(句子节奏 + 多巴胺密度 + 微幽默 + 概念把手检查)
- 第四遍:机械检查
  - **标点一致性**:全文不得出现英文逗号、英文冒号、英文问号、英文感叹号（英文原文/代码/链接内除外）。写完跑一遍 grep 排查。
  - **英文注释完整性**:所有英文人名首次出现必须加中文身份（如"Gary Marcus（纽约大学 AI 研究者）"）；所有非通识英文术语首次出现必须加括号中文释义（如"MVP（最小可行产品）"）。通识词（AI、App、CEO）不需要注释。

#### ⚠️ 写作红线

- **不暴露 AI 参与写作**:不说"这篇文章是 AI 写的"、"让 AI 帮我写"等 - 读者对 AI 生成内容有抵触心理,暴露会显著降低阅读量和信任感
- **讲故事,不讲论点**:用时间线、场景、情绪推进,不用"总结"、"核心观点"、编号式论点堆砌
- **自然过渡**:不用中括号小标题、不用"以下是 N 条心得"式结构
- **让读者感受到力量**:分享经历,不是教学。有踩坑有收获,有真实细节
- **禁止废水开头**:不用"在当今 XX 的时代..."、"随着 XX 的不断发展..."等陈词滥调

### Step 4: 封面与配图

封面图、正文配图规划与生成、产品截图获取的完整操作手册见 `references/image-generation-guide.md`。

**快速参考:**
- 封面生成优先级:idealab Chat API → Seedream 5.0 Lite → HTML 渲染截图
- 正文配图密度:2000 字 3 张、3000 字 4-5 张,硬上限 5 张
- 配图计划表输出到 `illustration-plan.md`,老板确认后再生图
- 产品截图:公开页面直接截,需登录页面用 Browser Relay
- 通用后处理:`beautify-screenshot.sh`(美化)
- 🔴 **idealab 生图不去水印**:idealab 模型本身不带水印，执行去水印脚本反而会损坏图片右下角。仅对 Seedream/Gemini 等其他来源的图执行去水印。

**🔴 生图后图内文字复核（事实类/含数据文章不可跳过，来源 ATA 实录）**：
配图生成后、进入排版前，用 `image` 工具逐张核对：
- 图内文字有没有被模型写坏/错字/漏字（尤其小字号标注、数据数字）
- 图内信息与正文是否一致（图说的和文说的是同一件事）
- 标题/封面数字与正文承诺是否吻合（呼应 Step 9 章节契约）
- 发现写坏 → 重生该图；发现与正文冲突 → 修正后重生。图像模型渲染文字常自己加戏，不复核会把错字带到成品。

### Step 5: 排版美化

```bash
# 基础排版
python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html

# 带图片自动上传(本地图片自动上传到微信素材库并替换 URL)
python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html --upload
```

主题选择:tech(科技风,默认)、minimal(简约风)、business(商务风)。
排版约束详见 `references/weixin-constraints.md`。

### Step 6: 外链转底部引用（微信外链不可点击问题）

微信公众号不支持外链点击跳转,文章中的外链对读者没有交互价值。排版时自动处理:

**处理规则**:
1. 普通外链 `[text](https://example.com)` → 文中显示为 `text1`(上标序号),链接收集到文末「引用链接」章节
2. `https://mp.weixin.qq.com/...` 链接保留为直接链接(微信内部链接可点击)
3. 裸链接(链接文本 = URL 本身)保留不动(已是展示型,读者可复制)
4. 没有外链的文章跳过此步

**文末引用格式**:
```markdown
---
## 引用链接

1. example.com: https://example.com/article
2. GitHub: https://github.com/user/repo
```

**执行时机**:Markdown 转 HTML 之前处理(在 Markdown 层面替换,不是 HTML 层面)。可在 `markdown_to_html.py` 中集成,或作为单独的预处理步骤。

如果有额外配图需要手动插入(非 Markdown 内嵌图片),先上传再手动插入 HTML。

### Step 7: 推送草稿箱

```bash
# 一键从 Markdown 到草稿(推荐,自动转 HTML + 上传图片 + 清理旧同名草稿)
node scripts/publisher.mjs --markdown article.md --title "文章标题" --cover cover.png

# 或手动分步:先转 HTML 再推送
python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html --upload
node scripts/publisher.mjs --title "文章标题" --content article.html --cover cover.png

# 跳过自动清理旧草稿
node scripts/publisher.mjs --markdown article.md --title "标题" --cover cover.png --no-cleanup

# 列出草稿
node scripts/publisher.mjs --list

# 删除草稿
node scripts/publisher.mjs --delete --media-id <id>

# 发布草稿(用户确认后)
node scripts/publisher.mjs --publish --media-id <草稿media_id>
```

**默认停在草稿箱,不自动发布。** 告知用户草稿已创建,确认后再发布。
推送新版本时自动清理同标题旧草稿(`--no-cleanup` 跳过)。

### Step 8: 发布数据回流（推送草稿箱后自动执行）

推送草稿箱成功后,顺便采集历史文章数据,用于选题评分校准。

```
1. browser(action=tabs, profile="user") 检查是否有 mp.weixin.qq.com tab
2. 有 → browser(action=snapshot, targetId=<tab_id>) 读取发表记录页
3. 从 snapshot 提取每篇文章的:标题、阅读量、点赞、分享、留言
4. 自动更新 collections/topics/publish-feedback.md
5. 没有 tab 或 snapshot 失败 → 跳过,不影响主流程
```

注意:此步不影响主流程,失败就跳过。数据用于选题评分校准(见 eval-criteria.md + publish-feedback.md)。

### Step 9: 五维内容自检（交付前必做）

排版完成后、交付前,逐维度自检。任何一项 ❌ 必须修改后再进入下一步。

| 维度 | 检查问题 | 合格标准 | 判断 |
|------|---------|---------|------|
| **文字洁癖** | 有没有 AI 味?(空洞排比句、Emoji 堆叠、"让我们来看看") | 每句话都有信息量,没有填充语 | ✅/❌ |
| **标题/封面** | 平铺直叙能不能吸引人?不看封面只看标题想不想点? | 有立场/反差/数据之一,不靠震惊体 | ✅/❌ |
| **表达效率** | 能不能一句话说清核心观点?有没有 99% 时间包装 1% 内容? | 删掉任何一段,整篇不完整 = 没有冗余 | ✅/❌ |
| **认知落差** | 读完后读者会不会觉得「这个我知道」?和同行比有增量吗? | 至少有 1 个「我之前没想到」的点 | ✅/❌ |
| **数据支撑** | 核心判断有没有数据/事实/一手经验支撑? | 每个核心判断都有来源(数据/案例/亲身经历) | ✅/❌ |

> 借鉴 dbs-content 五维诊断框架。第五维从「AI 辅助」改为「数据支撑」,更适合公众号写作场景。

**🔴 章节契约检查（标题含数字时必过，来源 ATA 实录）**：
标题里的数字是系统契约，不是文案修辞。标题「5 个方法」/「3 大趋势」/「A vs B」→ 正文必须真有对应数量的 H2 小节，否则读者立刻判定水货。
```bash
python3 <WORKSPACE>/scripts/check-number-contract.py <draft.md> --h2-sections
```
- exit 0 = 契约成立或标题无数字承诺（自动放行）；exit 1 = H2 小节数与标题数字不符，补齐后再交付
- 🔴 前提：标题写 frontmatter `title:` 或封面标题，**不要**当正文 H2（公众号正文从 H2 开始，标题独立传给 publisher）
- 已并入 §Final 机械验证（skill-verify wemp-ops 第 6 项），此处为写作阶段提前自查

### Step 10: 读者测试（可选但推荐）

交付前,用一个无上下文的子 Agent 阅读文章全文,检查:
- 标题是否让人想点开?(不知道背景的人能否被吸引)
- 开头两段是否抓住注意力?(3 秒法则)
- 是否有行业黑话/未解释的概念?(非目标读者能否理解)
- 结尾是否有力?(读完后想做什么)
如果子 Agent 发现盲点,修改后再交付。

### Step 11: 风格学习采集

**写作完成时自动执行,不需要老板操作。**

在 Step 3 写作完成(draft-v1.md 定稿)后,自动记录 AI 原稿:
```bash
python3 <WORKSPACE>/scripts/style-observe.py record-original <工作目录>/draft-v1.md --skill wemp-ops --topic "选题关键词"
```

当老板确认最终版(可能经过多轮修改)后,记录最终版:
```bash
python3 <WORKSPACE>/scripts/style-observe.py record-final <最终版文件> --skill wemp-ops
```

**触发 record-final 的信号**:
- 老板说"可以了"/"发吧"/"推到草稿箱"
- 老板手动修改后把最终版发回来
- 文章已发布(从草稿箱发布 = 确认最终版)

**如果老板没有修改直接发布**,也要 record-final(no_change = 正反馈,说明这次写得好)。

积累 5+ 对 diff 后,可执行风格规则提取:
```bash
python3 <WORKSPACE>/scripts/style-observe.py pairs --skill wemp-ops --days 30
```

### Step 12: 交付

向用户汇报:文章标题、字数、草稿状态、封面预览、建议发布时间。

### Step 12.5: Obsidian 归档（交付后自动执行）

将定稿文章和配图归档到 Obsidian `创作/公众号/`，保留完整创作记录。

```bash
bash scripts/archive-to-obsidian.sh --platform wemp \
  --article temp/wemp/<article>.md \
  --images temp/wemp/cover.jpg temp/wemp/fig-*.jpg
```

- 自动注入 `archived_at` 和 `platform` 到 frontmatter
- 图片复制到 `创作/公众号/images/`，文内引用自动替换为相对路径
- 失败不阻塞主流程，记录警告即可

### 🔴 Final: 机械验证（不可跳过）

交付前运行：
```bash
bash scripts/skill-verify.sh wemp-ops <markdown-file> [cover-image]
# 例: bash scripts/skill-verify.sh wemp-ops temp/wemp/article.md temp/wemp/cover.jpg
```
- `<markdown-file>` = 最终 Markdown 文稿路径
- `[cover-image]` = 封面图路径（可选）
- ✅ ALL PASSED → 回复用户
- ❌ FAILED → 按输出补齐缺失项（配图数量/自评残留/裸链接等），重新验证直到通过

绝不在验证未通过时回复用户"已完成"。

## 仅采集

```bash
node scripts/smart_collect.mjs --query "用户需求" --keywords "AI扩展的关键词" --sources "hackernews,v2ex,36kr" [--deep]
```

数据源分类:
- `tech`: hackernews, github, v2ex, sspai, juejin, ithome, producthunt
- `china`: weibo, zhihu, baidu, douyin, bilibili, toutiao, tencent, thepaper, hupu
- `finance`: 36kr, wallstreetcn, cls

采集后整理为选题候选清单,每条含:标题、来源、热度、链接、与用户需求的相关度。

## 数据分析

```bash
# 日报(默认昨天)
node scripts/daily_report.mjs [--date YYYY-MM-DD]

# 周报
node scripts/weekly_report.mjs
```

输出包含:用户增长、阅读数据、热门文章、互动数据、AI 洞察。

## 互动管理

```bash
# 检查新评论
node scripts/check_comments.mjs

# 回复评论
node scripts/reply_comment.mjs --comment-id <id> --content "回复内容"
```

AI 生成回复建议时遵循 `persona.md` 的语气规范,用户确认后再执行回复。

## 配置

公众号凭证配置在 **skill 自己的** `config/default.json`:

```json
{
  "weixin": {
    "appId": "你的AppID",
    "appSecret": "你的AppSecret"
  }
}
```

⚠️ **不要写到 `openclaw.json` 的 `channels` 里!** `channels` 只接受 OpenClaw 内置渠道类型(dingtalk/telegram/discord 等),写入未知类型会导致 gateway 校验失败并不断重启。

其他配置(数据源偏好、报告时间等)同样在 `config/default.json` 中调整。

---

## 多版本分发(一篇→多平台)

完整分发流程(小红书/X/Twitter 改写 + 发布)见 `references/multi-platform-distribution.md`。

触发词:"分发到小红书/X" / "生成多平台版本" / "同步到其他平台"

---

## 下一步建议(条件触发)

文章完成后,根据结果判断是否推荐下一步。

| 触发条件 | 推荐 |
|---------|------|
| 文章已发布成功 | 「文章已发布。要分发到小红书/X 吗?或者用 content-collector 存档素材方便下次复用。」 |
| 写作过程中发现素材不足 | 「素材不够,建议先用 content-collector 搜索已有收藏,或 web_search 补充。」 |
| 文章涉及会议纪要/内部沟通 | 「这篇更像内部文档,建议用 internal-comms 的格式。」 |
| 需要配图但 Seedream/Gemini 生图效果不佳 | 「配图可以试试 drawio 画流程图/架构图替代。」 |

---

## 绝对不要做的事

写作和内容产出中,以下行为直接拉低质量,必须避免:

1. **不要说「每个人的写作风格不同」「见仁见智」** - 这是回避判断。有观点就直接说,标注来源
2. **不要建议「参考同行」而不给具体对标** - 「去看看别人怎么写的」是废话。要给就给具体账号、具体文章、具体写法
3. **不要用「干货满满」「深度好文」「建议收藏」** - 读者自己判断有没有干货,作者说「干货满满」等于自夸
4. **不要写空洞的排比句开头** - 「在这个时代......在这个节点......在这个浪潮中......」是 AI 八股文的标志
5. **不要堆叠修饰词** - 「极其重要的关键性底层核心逻辑」,一个词能说清的事不用四个
6. **不要开头就下结论** - 先给事实/故事/数据制造认知落差,结论放后面。开头下结论 = 读者没动力往下读
7. **不要用「让我们一起来看看」「接下来我们来聊聊」** - 这是视频口播语气硬塞进文章的结果,书面内容不需要这种过渡
8. **不要在没有数据支撑时写「据统计」「研究表明」** - 要么给出具体来源(谁的研究、哪年、样本量),要么不引用

---

## 内联案例库

### 正面案例(老板认可的产出)

**案例 1:公众号 #6「Claude 能操控微信了」V3 定稿**
> 去掉所有比喻,直接用数据说话。1900 字,聚焦 Computer Use vs API 一个视角。新增"Anthropic 自己优先走 MCP 接口"的关键发现。
- 成功要点:一篇文章只讲一件事;数据 > 比喻 > 术语;「50% 成功率」比任何比喻都有说服力
- 老板评价:确认 OK

**案例 2:公众号 #5「Skills 不是低代码,但也不是 App Store」**
> 从第一人称 AI PM 视角,讲自己用 Skills 的真实踩坑经历,有具体场景、有数据、有得失。
- 成功要点:讲故事不讲论点,经历 > 观点,场景 > 总结,有踩坑有收获

**案例 3:封面图 Seedream 生成**
> 2560x1440 生成,裁剪 2.35:1 宽屏比例,简洁主体 + 深色背景 + 大字标题。
- 成功要点:封面不堆元素,一个主体 + 一行标题 + 干净背景

### 反面案例(被打回的产出 + 打回原因)

**反面 1:公众号 #6 V1 初稿(3100 字,被全面打回)**
> 塞了 Computer Use + Agentic Engineering + 冷思考 + 一手实践 + 8 个名人引用,试图一篇文章讲完所有。
- 打回原因:❌ 内容太干太多读不动 ❌ 名人引用堆砌(8 处)❌ 点名反驳其他博主 ❌ 想讲的东西太多
- 教训:一篇文章只讲一件事。名人引用全文不超过 2-3 处。不要点名反驳他人文章,从现象切入。

**反面 2:公众号 #6 V2(1800 字,比喻牵强)**
> 砍掉了多余内容,但用"开车 vs 高铁"比喻贯穿全文。
- 打回原因:❌ 比喻牵强,把事情搞复杂了
- 教训:比喻不是必须的。事实清晰时直接说更好。数据自己会说话。