技术英语的失败,往往不是因为语法出错,而是因为动词用得太笼统。«We made the system better»和«we reduced query latency by 40%»描述的是同一项工作,但说服力完全不在一个量级。
有技术分量的动词
| 笼统的说法 | 精确的说法 |
|---|---|
| make faster | optimise, accelerate, streamline |
| make smaller | reduce, compress, consolidate |
| fix | resolve, patch, mitigate |
| change | refactor, migrate, restructure |
| check | validate, verify, audit |
| set up | configure, provision, deploy |
| join together | integrate, consolidate, merge |
| find the cause | diagnose, trace, isolate |
We isolated the bottleneck and refactored the query layer.
如何描述各部分之间的关系
要口头讲清楚一套架构,需要一小组表达关系的动词,而恰恰是在这里,措辞笼统会让原本清晰的讲解变得难以理解:
- The API sits behind a load balancer.
- The service depends on the auth layer. · Nothing else relies on it.
- It talks to the database directly.(口语化,但属于标准说法)
- The queue decouples ingestion from processing.
- Sessions are backed by Redis.
- That module is responsible for validation.
请注意:depend on 和 rely on 都搭配 on,而 consist of 搭配 of。这是三个固定的介词搭配,也是常见的出错点。
描述取舍
技术讨论在很大程度上就是在权衡取舍,英语里对此有一套现成的表达:
- There's a trade-off between speed and accuracy.
- We prioritised reliability over raw performance.
- That approach scales better, but at the cost of complexity.
- It's a reasonable compromise given the constraints.
- The downside is that it adds a dependency.
缓和技术性陈述的确定程度
夸大其词会削弱技术听众对你的信任。精确性不仅体现在用词上,也体现在你对确定程度的表达上。
- This should reduce load significantly.(预期效果)
- It appears to be a race condition.(可能,但尚未确认)
- We suspect the issue originates in the cache layer.
- As far as we can tell, the data is consistent.
对比一下夸大的说法:This will definitely fix it. 这种说法很少站得住脚,一旦说错,代价也很大。
解释原因
- The failure stems from an unhandled edge case.
- This was triggered by a schema change.
- The root cause turned out to be a timeout setting.
- These issues are symptomatic of a deeper design problem.
出故障的时候
事故场景的用语高度约定俗成,用错一个词就会让情况显得比实际更严重,或者更轻微:
| 术语 | 含义 |
|---|---|
| outage | 服务完全宕机 |
| degradation | 仍在运行,但变慢或部分不可用 |
| intermittent | 时好时坏 |
| regression | 原本能用的功能坏了 |
| workaround | 临时的绕过方案 |
| mitigation | 减轻影响,但没有解决根本原因 |
| rollback | 回退到之前的版本 |
| postmortem | 事后复盘 |
We've mitigated the impact with a workaround; the root cause is still open.——这句话恰好准确地告诉了上级你目前的处境。
评估工作量和时间
- That's out of scope for this release.
- Roughly — ballpark — two weeks.
- We're seeing some scope creep.
- I'd want to spike on it before committing to an estimate.
- It's blocked on the API change.
量化表达
笼统的估计会削弱一段本来不错的技术英语。
- ❌ It got a lot faster.
- ✅ Latency dropped from 800 ms to roughly 200 ms.
- ✅ That's an improvement of around 75%.
- ✅ Error rates fell by an order of magnitude.
精确和确定程度是两回事。 We reduced p99 latency by roughly 60%, though we haven't confirmed why 既精确,又恰如其分地保留了不确定性。技术听众信任的正是这种组合,而不信任相反的做法——没有一个数字支撑的、却语气笃定的断言。
事故复盘
A: What are we seeing?
B: Intermittent 500s on checkout since about nine. It's degradation, not a full outage.
A: Do we know why?
B: Not yet. It appears to be connection-pool exhaustion, but that's a guess. We've rolled back the deploy as a mitigation and errors dropped by around 90%.
A: Good. Root cause can wait for the postmortem.
每一句话都标明了确定程度,给出了一个具体数字,并且每个位置都用对了词。
自测
下面的测验考查的是精确度和恰当的谨慎措辞,而不是花哨却笼统的说法。