说人话/说行话/说官话 · Tri-Lingual Mode
> 同一个方案，给三个人讲，说三种话。不是缩写——是翻译。
§0 你一定经历过这个场景
你花了两周准备一个技术方案。微服务拆分的架构图、数据库选型的对比表、迁移的风险评估——自认为无懈可击。
然后你走进 CEO 办公室，讲了五分钟。他看着你说：「所以你到底要多少钱？要多久？做完能多赚多少？」
你愣住了。这些问题你的方案里都有答案，但藏在一堆术语和架构图后面。
不是你的方案不好。是你用工程师的语言给老板讲了一个方案。
同样的事每天都在发生：给业务 VP 讲技术细节他听不懂，给新人讲系统设计一嘴术语，给客户讲产品功能扯了一堆实现原理。
你需要的不只是一个版本。你需要一个角色切换器。
§Q 快速上手
唤醒方式
把你想说的事 + 受众告诉它：
- 「帮我把这个方案翻译成给 CEO 听的版本」
- 「这段内容，分别说给技术 Leader、业务 VP 和新人听，各写一版」
- 「老板听不懂我的方案，帮我把这个用他能懂的话重讲一遍」
- 「我要跟客户解释这个功能，别讲技术实现，讲对他有什么好处」
- 「给团队新人解释一下这个系统是怎么工作的，用大白话」
- 「给投资人 pitch 这个项目，三分钟版本」
模式速查
| 模式 | 触发 | 输出 |
|---|---|---|
| 三语模式（默认） | 不指定受众或说「都来一份」 | 执行者版 + 决策者版 + 新人版 |
| 单语模式 | 指定一个受众 | 只输出指定受众的版本 |
| 自定义角色 | 「讲给 XX 听，他是做 YY 的」 | 按自定义角色生成 |
| 对比模式 | 「帮我看看这封邮件，收件人是 XX，我这样写他能不能看懂」 | 诊断 + 翻译 |
§1 核心能力详解
F1 · 三语翻译引擎
内置三种角色视角，同一份信息同时产出三个版本：
| 角色 | 关心什么 | 语言特征 | 篇幅 |
|---|---|---|---|
| 执行者版（说行话） | 怎么做、有什么坑、依赖什么 | 专业术语、技术细节、风险点、时间线 | 完整版 |
| 决策者版（说官话） | 要多少钱、多久、值不值、有什么风险 | 成本收益、时间线、战略对齐、关键决策点 | 精简版 |
| 新人版（说人话） | 这是什么、为什么、跟我有什么关系 | 大白话、生活类比、先整体后局部 | 渐进版 |
翻译原则：
- 核心信息三版一致（不能决策者版漏掉了一个关键风险）
- 语言风格彻底切换（执行者版的术语在决策者版必须翻译）
- 篇幅按角色需求调整（决策者要短、执行者要全、新人要慢）
F2 · 核心保留检测
翻译完成后自动检查三个版本是否都覆盖了源内容的全部关键信息：
- 事实性信息（数字、日期、人名）
- 风险与约束（什么可能出错、什么不能做）
- 依赖与前提（需要什么前置条件）
- 可选决策点（哪里需要对方拍板）
任何版本漏掉一条关键信息，自动补充并标注。
F3 · 类比自动匹配
为每个角色版本自动生成 1-2 个该角色熟悉的类比：
- 执行者版：用技术场景类比（「就像数据库的主从复制」）
- 决策者版：用商业场景类比（「相当于先开一家小店试水，而不是直接租商场」）
- 新人版：用日常生活类比（「就像你先装一个水管总阀，再去换每个水龙头」）
类比必须满足两个条件：① 该角色一听就懂；② 不会误导核心意思。
F4 · 反问预判
每个版本末尾附上「对方听完最可能追问的 3 个问题」，帮用户在被问到之前就准备好答案。
问题生成逻辑：
- 执行者会追问：可行性、边界情况、和现有系统的兼容性
- 决策者会追问：成本明细、竞品对比、如果不做的后果
- 新人会追问：这个概念是什么意思、为什么这样设计、我该怎么参与
§2 工作流程
用户提供原始内容 + 目标受众
│
▼
[Step 1] 内容解析
│ 提取：核心主张 / 事实性数据 / 风险与约束 / 依赖与前提 / 可选决策点
▼
[Step 2] 角色匹配
│ 默认：执行者 / 决策者 / 新人
│ 自定义：按用户描述的角色画像生成
▼
[Step 3] 逐版翻译
│ 每个版本独立生成：
│ - 切换语言风格（术语→白话 / 细节→收益 / 原理→类比）
│ - 调整篇幅（决策者精炼 / 执行者完整 / 新人渐进）
│ - 匹配关注点（做什么 / 值不值 / 是什么）
▼
[Step 4] 核心保留检测
│ 三版交叉比对，检查关键信息是否遗漏
│ 遗漏 → 回退 Step 3 补充
▼
[Step 5] 类比注入 + 反问预判
│ 每版添加 1-2 个角色类比 + 3 个预判追问
▼
[Step 6] 输出
├── 一句话原始摘要（保留源信息）
├── 执行者版 · 说行话
├── 决策者版 · 说官话
├── 新人版 · 说人话
└── 横向对比表（三版覆盖检查）
§3 决策流程
何时启动
| 场景 | 判断依据 |
|:--|:--|:--|
| 用户需要把同一内容讲给不同角色听 | 提到「给 XX 看」「讲给 XX 听」+ 角色差异 |
| 用户说「XX 听不懂我在说什么」 | 沟通受阻，需要语言切换 |
| 用户做汇报前准备 | 「明天要给 XX 汇报」 |
| 用户写了东西但不确定受众能否理解 | 「帮我看看我这样写行不行」 |
何时降级
| 场景 | 处理方式 |
|:--|:--|:--|
| 用户提供的内容已经是面向特定受众的精炼版本 | 「你这份内容本身已经是给 XX 写的了，风格很匹配。需要我帮你生成其他角色的版本吗？」 |
| 内容太简单（不超过 3 句话的简单通知） | 「这个内容太简短了，不需要角色翻译。如果你是想确认表达是否合适，我可以帮你看。」 |
| 用户指定的角色画像太模糊 | 追问关键维度（角色的职位/关注点/专业背景），不要猜。 |
| 用户要求翻译成「所有人」 | 「所有人意味着不同角色，我不能输出一个万能版本。给我一个具体受众。」 |
§R 核心铁律
- 换语言，不换意思。翻译后核心信息不能丢失、不能变形。删掉的是修饰，不是事实。
- 三版必须信息对称。如果决策者版里缺了一个关键风险，这是一次失败。
- 类比必须对受众有效。不能给业务 VP 举数据库的例子，不能给新人举行业黑话的例子。
- 不评价哪个版本更好。三个版本平等输出，让用户选。
- 反问预判必须真实。不是凑三条问题，是角色在那个场景下真的会问的事。
- 保留用户的原始措辞作为锚点。翻译过程中如果某个关键表述必须保留原样（如产品名称、专利术语），标注为不翻译。
- 篇幅不是越短越好。决策者版短是因为决策者只需要结论+收益+风险，不是因为他没耐心。
- 用户可指定更多角色。不止三种，用户可以自定义任何角色画像。
§A 结构化异常处理
| 异常场景 | 检测方式 | 处理策略 | 提示语（用户可见） |
|---|---|---|---|
| 原始内容过于专业化，无法降维 | 充满行业术语，新人版翻译后仍然难懂 | 保留术语但附注解释，诚实标注降维程度 | 「这段内容的专业性太强，在保证准确的前提下，新人版做了最大程度的简化，但以下概念仍需要基础知识：[列出]。如果给完全外行的人看，建议先做一次当面解释。」 |
| 内容涉及需要保密的信息 | 包含「保密」「不外传」「内部」等标记 | 提醒用户确认哪些可以对外讲 | 「你的内容里有保密标记。请确认三个版本中哪些信息需要对特定角色隐藏？」 |
| 自定义角色画像不清晰 | 用户描述角色时只用了一个笼统标签 | 追问关键维度 | 「你说的『投资人』，我更想了解：他是看早期项目还是后期？他更看重团队还是数据？」 |
| 原始内容太短，无法判断核心信息 | 少于 50 字 | 先要求用户展开 | 「内容太短了，信息量不足以支撑三个角色的差异化翻译。你能多说一点吗——至少把你要传递的核心结论写清楚。」 |
| 三种角色之间存在冲突的需求 | 比如对老板要强调收益，对执行者要强调困难 | 独立处理每版，不调和 | 三个版本独立输出，决策者版强调收益、执行者版如实呈现困难、新人版保持中立。 |
| 用户要求翻译成一封邮件 | 角色翻译 + 格式要求同时出现 | 按指定格式嵌入翻译内容 | 按邮件格式输出，正文为对应角色的翻译版本。 |
| 类比自动匹配失败 | 某个概念在目标角色的领域找不到合适类比 | 不强行编，标注无类比 | 「这个概念在 [角色] 的日常经验中找不到贴切的类比，以下直接用精简语言解释。」 |
| 翻译过程中发现原始内容本身有逻辑矛盾 | 内容前后不一致 | 先指出矛盾，让用户修正后再翻译 | 「你的内容里有两个地方不一致：[具体说明]。我建议先统一再翻译，否则三个版本都会继承这个矛盾。」 |
§B 常见错误与纠正
| 常见错误 | 为什么错 | 正确做法 |
|:--|:--|:--|:--|
| 决策者版只删不改 | 把执行者版删掉一半就算决策者版 | 彻底切换语言：把「微服务架构」翻译成「系统可以分块独立升级，一处坏了不影响别处」 |
| 新人版变成「幼儿园版」 | 过度简化，把受众当傻子 | 新人≠笨。保持信息的尊严，用搭建式语言（先给骨架，再给细节），不用哄小孩的语气 |
| 给三个版本标注优劣 | 「决策者版最精简推荐使用」 | 三个版本平等输出，不评价。用户自己判断哪个适合当前场景 |
| 反问预判凑数 | 「这个多少钱」「什么时候做完」「谁来做」——太泛 | 每个反问应该让用户感到「还好提前准备了答案」。针对内容本身追问具体边界 |
| 用同一套类比换角色 | 给决策者和执行者用同一个类比 | 每个角色的类比必须不同，来自该角色的经验世界 |
| 翻译后关键数字丢失 | 源内容有「留存率从 30% 提升到 35%」，翻译后变成「留存率有显著提升」 | 数字不能模糊化。如果数字在某个版本中不需要精确，保留数字但降低强调 |
| 忽略文化/语境差异 | 用了一个只有中国互联网圈懂的梗 | 类比必须是跨越该角色所属圈层的通用经验 |
§C 能力边界
能做的事
- 将同一内容按三到 N 种角色视角翻译成不同版本
- 自动匹配受众熟悉的类比
- 检测翻译遗漏并补充
- 预判每个受众听完后可能追问的问题
- 自定义任意角色画像
做不到的事
- 不创造新信息。翻译只传递用户提供的源内容，不替用户编造方案细节。
- 不判断内容的正确性。如果用户提供的方案本身有漏洞，翻译不会掩盖它，但也不会主动修正（除非明显矛盾）。
- 不做跨语言翻译。这里是角色翻译（同一语言内换说法），不是中译英。
- 不生成可视化/图示。纯文本输出。
- 不模拟真人语气。生成的文本是标准商务/技术沟通语言，不会模仿特定个人的说话风格。
§D 避坑指南
| 坑 | 表现 | 如何避免 |
|:--|:--|:--|:--|
| 把翻译当缩写 | 三个版本只是长度不同，语言一样 | 检查每个版本的第一段话：用词、句式、切入角度应该完全不同。 |
| 决策者版失去关键风险 | 为了让老板觉得好，把风险藏起来了 | 风险必须出现在决策者版。可以换表达（「有 20% 概率延期」→「建议预留两周缓冲」），但不能消失。 |
| 新人版变成清单 | 新人需要的是一步步搭建的理解，不是一堆要点 | 新人版必须用叙事结构（先整体→再局部→再回到整体），不能用 bullet list 堆砌。 |
| 类比比原文还难懂 | 「就像 CAP 定理在分布式系统中的应用」——这比原文还难 | 类比必须来自日常经验（吃饭、交通、装修、购物），不能来自另一个专业领域。 |
| 忘记自定义角色兼容 | 用户说「给投资人看」时不知道怎么办 | 投资人也是决策者变体：关心回报、退出路径、市场规模、团队。按决策者模板 + 投资关注点定制。 |
| 反问预判变成攻击 | 「你凭什么觉得这个方案能行」——这不是预判，是挑衅 | 反问应该是中立的、信息导向的：「这个方案的假设前提是什么？如果前提不成立，B 计划是什么？」 |
§E FAQ
Q: 我只能选三种角色吗？
A: 不止。说「讲给 XX 听，他是做 YY 的，关心 ZZ」，即可自定义。
Q: 我只需要一个版本行吗？
A: 行。说「只要执行者版」或「翻译成老板看的」，只输出一个。
Q: 原文是我用中文写的，翻译出来也是中文，这算什么翻译？
A: 翻译的不是语言（中→英），是视角。同一个中文句子，给工程师和给 CEO 听到的意思完全不同。这里做的是那个转换。
Q: 如果我提供的方案本身是错的，你会告诉我吗？
A: 如果你有明显逻辑矛盾（前面说 A 后面说非 A），我会指出。但不会评价你的方案好坏。
Q: 三个版本能直接发给不同的人吗？
A: 能。每个版本独立成篇，不需要依赖其他版本就可以阅读。
Q: 能不能用在一封邮件里同时写给三个人？
A: 不适合。一封邮件三个人看，需要的是「最大公约数」版本——包含所有角色都关心的最低信息量。这种情况你说「给一个三人都能看的版本」。
§F 版本历史
| 版本 | 日期 | 变更说明 |
|---|---|---|
| 1.0.0 | 2026-07-15 | 首次发布。覆盖三语翻译引擎、核心保留检测、类比自动匹配、反问预判四大核心能力。 |
§G 完整演示案例
用户输入
> 我要给 CEO 和 CTO 分别汇报同一个事：我们把数据库从 MySQL 单体迁移到 TiDB 分布式架构。这件事的初衷是现在单库快扛不住了，QPS 峰值已经到瓶颈。迁移预计要 3 个月，中间业务不能停，风险最大的是数据一致性校验阶段。预算需要 80 万（包括 TiDB 的 license + 两个 DBA 三个月的人力）。做完之后数据库可以水平扩展，未来三年不用再动架构。帮我生成三个版本。
输出
源信息摘要
MySQL 单体库迁移至 TiDB 分布式架构。QPS 达瓶颈，需 3 个月不停机迁移，最大风险为数据一致性校验，预算 80 万。完成后可水平扩展，未来三年无需重构。
执行者版 · 说行话
背景：当前 MySQL 单体库 QPS 已触及单机上限，读写分离和分库分表都试过，治标不治本。本次迁移目标：将核心业务库整体迁至 TiDB，利用其分布式 SQL 引擎实现水平扩展。
方案要点：
- 使用 TiDB Data Migration 工具做全量 + 增量同步，源端 MySQL 5.7 → 目标端 TiDB 6.5
- 分三个阶段：全量迁移（预计 2 周）→ 增量同步 + 灰度切流（预计 6 周）→ 反向同步 + 回滚预案（预计 4 周）
- 不停机方案：通过读写分离中间件逐步将读流量切到 TiDB，写流量最后切
- 数据一致性校验：全量和增量阶段各做一次 sync-diff-inspector 校验，切流前再做一次最终校验
风险矩阵：
| 风险 | 概率 | 影响 | 缓解措施 |
|:--|:--|:--|:--|
| 数据不一致 | 中 | 严重 | 三阶段校验 + 反向同步回滚通道 |
| 迁移窗口内业务抖动 | 中 | 中等 | 灰度切流 + 可随时回滚 |
| TiDB 与 MySQL 兼容性问题 | 低 | 中等 | 预生产环境全量回归测试 |
资源：2 个 DBA（全职 3 个月）+ TiDB License，预算 80 万。
类比：相当于给一辆正在高速上跑的车换发动机——不能停车，换完还得更快。
决策者版 · 说官话
一句话：我们的数据库快撑不住了，需要一次升级。花 80 万、用 3 个月，换未来三年的高枕无忧。
为什么现在做：当前数据库已经到极限。再拖下去，下一个大促或者用户增长高峰就可能出事故。到那时候修，成本远不止 80 万。
花多少钱：80 万（含软件授权 + 人力）。一次性投入，后续无额外年费。
多久：3 个月。期间业务正常运行，用户无感知。
有什么风险：最大的风险是迁移过程中数据对不上。我们设计了三道校验关卡，并且在任何阶段都可以一键回退到旧系统。换句话说，最坏的情况就是白干三个月回到原点——业务不会停。
做完之后：数据库可以无限横向扩展。未来三年不用再操心架构问题，来了流量就加机器。
需要你拍板的事：80 万预算审批。如果可以，建议下周启动。
类比：相当于你的仓库快堆满了，现在有两种选择。A：每次满了就租个小仓库，天天两头跑。B：换个大仓库，贵一次，三年不用搬家。这是方案 B。
新人版 · 说人话
这是什么：公司所有的数据都存在一个叫「数据库」的东西里。现在的数据库就像一个快装满的硬盘——再往里塞东西就要卡了。我们要把数据从一个快满的硬盘搬到一个新的大仓库里。新仓库的好处是：以后东西多了，可以随时加盖房间，不用再搬。
为什么现在搬：因为马上就到容量的天花板了。如果等到彻底塞满再搬，搬家期间仓库不能用，所有业务都会停。趁现在还能正常运转，边用边搬。
搬家流程：
1. 先把所有东西复制一份到新仓库（边用边复制，不影响正常拿东西）
2. 新仓库复制完了，开始逐渐把来取货的人引导到新仓库
3. 旧仓库暂时留着，万一新仓库出问题随时可以回来拿
4. 等确认新仓库完全没问题了，旧仓库关闭
跟我有什么关系：如果你不做数据库相关的工作，对你基本没影响。如果你在后端、运维或数据团队，接下来三个月可能会多开几次会。
类比：就像你租的房子快到期了，房东说不能再续了。你一边正常上班，一边每天晚上搬一点东西到新家。到搬家那天，只是过去睡个觉。
三版覆盖检查
| 关键信息 | 执行者版 | 决策者版 | 新人版 |
|---|---|---|---|
| QPS 达瓶颈 | ✅ | ✅「快撑不住了」 | ✅「快装满的硬盘」 |
| 3 个月 | ✅ | ✅ | ✅ |
| 预算 80 万 | ✅ | ✅ | 未提及（新人不需要） |
| 数据一致性是最大风险 | ✅ 技术细节 | ✅ 业务语言 | ✅「新仓库出问题」 |
| 水平扩展 | ✅ | ✅ | ✅「加盖房间」 |
| 不停机 | ✅「灰度切流」 | ✅「用户无感知」 | ✅「边用边搬」 |
反问预判
执行者可能会问：
1. TiDB 6.5 和我们现有的监控/告警体系怎么对接？
2. 数据校验发现不一致之后，修复流程是什么？有自动化脚本吗？
3. 迁移完成后，旧的 MySQL 实例是直接下线还是保留一段时间？
决策者可能会问：
1. 80 万里软件和人力各占多少？有没有可能压缩到 60 万？
2. 如果三个月做不完，最坏延期多久？延期对业务的影响是什么？
3. 竞品公司用的什么方案？我们这个选择在行业里算激进还是保守？
新人可能会问：
1. 什么叫 QPS？为什么满了就不能再用了？
2. 旧仓库里的东西搬完之后还留着干嘛？
3. 这个事做好以后，对我日常用的系统会变快吗？
（内容由AI生成，仅供参考）
