前面几篇都在讲读写。这一篇讲说。
先说一个可能让你松口气的结论：技术场景的口语，是四个英语能力里最容易补的。 因为它需要的词汇最少、句式最固定、容错率最高。
一、先破除一个误解
流利 ≠ 说得快。
很多人不敢开口，是觉得自己"说不快、想不起来词"。但技术会议里，说得快反而容易出问题——对方听不懂，你还要重说一遍。
技术口语真正的要求只有三条：
| 要求 | 说明 |
|---|---|
| 说对 | 对方能准确理解你在说什么 |
| 简短 | 不占别人的时间 |
| 可打断 | 说完一段要有停顿，让人能插话 |
第三条最容易被忽略。 一口气讲三分钟不停，别人想插嘴都插不进来——这在英语会议里是很不礼貌的。
二、你需要掌握的，其实只有五种场景
技术口语的场景高度重复。把这五个练熟，覆盖 90% 的日常：
| 场景 | 时长 | 难度 |
|---|---|---|
| Daily standup | 1–2 分钟/人 | ★☆☆ 最容易 |
| 技术讨论 / design review | 20–60 分钟 | ★★★ |
| 一对一（1:1） | 30 分钟 | ★★☆ |
| 事故复盘（postmortem） | 30–60 分钟 | ★★★ |
| 面试 / 技术面 | 45 分钟 | ★★★★ |
从 standup 开始练，因为它有固定格式、时间短、就算说砸了也没人在意。
三、Standup：三段式，背下来就能用
每日站会的标准三问：做了什么 / 要做什么 / 有没有阻塞。
极简模板
Yesterday I <做了什么>.
Today I'll <要做什么>.
No blockers. ← 或者 → I'm blocked on <什么>.
真实例子：
Yesterday I finished the retry logic and got it reviewed.
Today I'll write the integration tests.
No blockers.
三十秒说完。 这就够了。
更自然的说法（不用 I 开头）
老手通常不这么工整，说的是：
So, still on the upload retry thing — logic's done, tests
are next. Nothing blocking.
still on、logic's done、nothing blocking —— 这些是真实口语，比模板更自然，但模板的骨架是一样的。
说"没有进展"的时候
这是最容易卡的时刻。 昨天啥也没干成，怎么说？
❌ I did nothing yesterday.（听着像承认失误）
✅ 三种说法，按诚实程度递增：
| 说法 | 含义 |
|---|---|
Still working on the same thing. | 中性，不解释 |
Spent yesterday debugging the flaky test — no fix yet. | 说明在干吗 |
Didn't make much progress — I was blocked on <X>. | 直说 |
推荐第二种。 它诚实地说了在干什么，又没有自我评判。
说"受阻"的时候
I'm blocked on <具体的东西>.
关键是把"具体"说清楚。 不要只说 I'm blocked——那等于给对方出了个谜题。
✅ I'm blocked on access to the staging database — I filed a ticket but haven't heard back.
一句话包含了：卡在哪、你做了什么、现在什么状态。
四、技术讨论：先给结论，再给理由
这是中英口语最大的结构差异。
中文习惯：铺垫 → 分析 → 结论。 英语技术讨论习惯：结论 → 理由 → 细节。
一个例子
❌ 中式顺序：
So I was looking at the logs, and I noticed that the timeout was set to 30 seconds, but the actual response takes about 45 seconds under load, and also the retry logic doesn’t kick in because the error is caught too early, so I think we should…
听的人到第二句就不知道你要说什么了。
✅ 英式顺序：
I think we should increase the timeout to 60 seconds. Two reasons: the actual response takes ~45s under load, and the retry doesn’t trigger because of where the error’s caught.
先说结论，再说"两个理由"，然后展开。
万能开场句
| 场合 | 说法 |
|---|---|
| 提建议 | I think we should <X>. |
| 表达不确定 | I'm not sure, but I think <X>. |
| 提替代方案 | What if we <X> instead? |
| 反对 | I see it differently — <理由>. |
| 请求澄清 | Can you say more about <X>? |
| 确认理解 | So what you're saying is <X>? |
最后一句特别有用：So what you're saying is...
它有两个作用：确认你没听错，以及给对方一个纠正的机会。会议里高频出现。
五、听不懂的时候：四句话救场
这是最多人的死穴。 听不懂就沉默，越沉默越听不懂。
四句必备：
| 情况 | 说法 |
|---|---|
| 完全没听清 | Sorry, could you repeat that? |
| 听清了但没懂 | Sorry, I don't follow — could you say that again? |
| 大概懂了 | So you mean <你的理解>? |
| 需要一个具体的点 | Could you go back to the part about <X>? |
重点：不要假装听懂。 技术讨论里假装懂，后果是后面全错，而且更丢人。
另一个技巧：把对方的话复述一遍。
Let me make sure I got that — you're saying the cache
is invalidated on every write?
对方会立刻确认或纠正。 这句话看起来是"确认"，实际上是给自己争取了思考时间。
六、事故复盘：一个有风险但要练的场景
Postmortem 是技术口语里压力最大的场景，因为它涉及责任。
描述问题，不描述人
核心原则：说系统怎么样，不说谁做的。
| ❌ 说人 | ✅ 说系统 |
|---|---|
I deployed the bad config. | The config was deployed without validation. |
Bob pushed to prod. | A push reached production outside the review process. |
We forgot to test. | The test coverage didn't include this path. |
注意：这不是推卸责任。 这是复盘的标准做法——关注系统缺陷，不追究个人。这是工程文化，也是语言习惯。
时间线的说法
At 14:02 UTC the first error appeared.
At 14:07 the alert fired.
At 14:15 we identified the cause.
At 14:21 the rollback completed.
每个节点用过去时，简洁陈述。 不要加"然后我们很着急地……“这类情绪描述。
七、让口语听起来"专业"的几个小习惯
1. 用 we 而不是 I（在团队场合）
We should probably add a timeout here.
比 I think you should add a timeout 更容易被接受。
2. 用 might / could 降低断言强度
| 强 | 弱 |
|---|---|
This is wrong. | This might be wrong. |
That won't work. | That might not work. |
We need to X. | We probably want to X. |
技术讨论里，“弱断言"不是不自信，是留余地。
3. 用 let's 拉近距离
Let's take this offline.
Let's circle back on this.
Let's not block on this.
这三句在会议里极高频，意思是"这个话题现在不讨论”、“回头再说”、“别卡在这”。
4. 承认不知道，很加分
I don't know off the top of my head — let me check and get back to you.
off the top of my head（不查资料的话）是很好用的一句。说完立刻承诺"我去查”，比硬编一个答案强一百倍。
八、怎么练：三个能坚持的办法
办法一：跟读 + 复述（每天 10 分钟）
找一段技术演讲（ conference talk，比如 GitHub Universe、PyCon），不看字幕听一遍，然后自己复述三十秒。
复述不是背诵，是"用自己的话讲一遍"。 讲不出来说明没听懂。
办法二：给自己讲代码（每天 5 分钟）
打开你正在写的一个函数，用英语说一遍它在干吗：
This function takes a list of URLs and downloads them in
parallel, with a limit of ten at a time.
没有人听，所以不怕错。 这是最没有心理负担的练法。
办法三：写下来再读出来（每周一次）
把一次 standup 的发言先写成文字，改到通顺，然后读出来，录音。
听回放会发现问题：很多你以为说清楚的地方，其实没清楚。
九、三句实话
第一，口音不重要，清楚才重要。 技术会议里没人因为你有口音听不懂——听不懂是因为句子结构乱、语速太快、不给人插话的机会。
第二，说得慢一点，会显得更专业。 真的。快语速传递的是紧张，慢语速传递的是把握。
第三，技术口语的核心不是英语，是"把事讲清楚"。 你能用中文把一个技术问题讲明白，换成英语只是词汇问题；用中文都讲不清，换成英语也不会清楚。
这是我的个人整理，句式来自公开的技术会议、standup 录像和工程团队写作规范。
这个系列的其他几篇
- GitHub 是最好的英语老师：从读 Issue 到能开口 —— 从哪儿练
- 技术文档有四种，读法完全不同 —— 读之前先认类型
- 读不懂一句技术英语时，真正该查的不是单词 —— 句子怎么拆
- 在 PR 里把话说清楚：一来一回的完整样本 —— 怎么写
- 计算机英语高频术语对照表 —— 随时查