【軟體工程師英文】從 LeetCode 面試、Daily Scrum 到 Code Review 的技術英語攻略
你可以在 Stack Overflow 上讀完一整串英文討論、看懂原文技術文件、把 RFC 從頭啃到尾。但每天早上那個十五分鐘的站會，輪到你講的時候，腦中先跑一遍中文再翻成英文，講完自己都覺得卡。
這不是你的英文差，是你的英文長歪了。工程師的英文輸入量遠大於輸出量，久了就變成「讀寫沒問題、開口就當機」。這篇文章不教你背單字，而是給你四個真實工作場景的句型結構：Daily Scrum、Code Review、PR 描述、技術面試——每一段都建立在 Google、Meta、Scrum Guide 的官方文件上，不是網路上流傳的模板。
為什麼工程師「看得懂但說不出口」？先看數據
這個感覺不是錯覺，ETS 官方的全球考生報告裡有三個數字，把台灣工程師的處境講得很清楚：
| 官方數據 | 意義 |
|---|---|
| 台灣考生有 41% 把「閱讀」列為最常使用的英文技能，比例全球最高（全球平均 32%） | 我們是靠讀在用英文 |
| 台灣有 42% 的考生表示，每天只有 1 到 10% 的時間需要用到英文 | 輸出機會極少 |
| 主修工程的考生全球平均 582 分，是所有主修類別中最低（社會科學 638、文科 627、商管 622、理科 613） | 工程背景在語言上本來就吃虧 |
同一份報告還有一組對照很值得看：把英文四項技能都用上的考生平均 695 分，只用閱讀的 606 分。技能單一化的代價，直接反映在分數上。
所以問題不在你懂得不夠多，而在於你缺的是「輸出的肌肉記憶」。而工作場景中的英文輸出，其實高度模式化——把模式練熟，開口的門檻會低很多。
Daily Scrum 怎麼講？先破除「三個問題」的迷思
幾乎每篇中文的站會英文教學，都會教你回答三個問題：昨天做了什麼、今天要做什麼、有沒有遇到阻礙。
這個格式在現行的 Scrum 規範裡，已經不是規定了。翻開 2020 年 11 月版的 Scrum Guide，官方寫的是：
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
官方的修訂說明更直接把「removed Daily Scrum questions」列為 2020 版的變動之一，整體方向定調為「Even Less Prescriptive」。順帶更正另外兩個常見錯誤：站會的時間盒是15 分鐘（不是 10 分鐘、也不是 15 到 30 分鐘），而且它是給 Developers 的活動。Scrum Guide 也有繁體中文官方版可以對照。
那實際上該怎麼講？
既然重點是「朝 Sprint Goal 的進度」和「明天可執行的計畫」，發言就照這個邏輯組。三個問題仍然是很好用的句型練習框架，只是別把它當成規定：
- 報進度：I wrapped up the payment validation logic yesterday. / The migration script is done and merged.
- 講今天：Today I’m picking up the retry mechanism. / I’ll be working on the caching layer for the rest of the day.
- 提阻礙（最重要）：I’m blocked on the staging credentials. / I need someone from the platform team to review the config change before I can move forward.
- 要幫忙但不打斷會議：Let’s take this offline. / Can we sync after standup?
最後那兩句特別實用。站會只有 15 分鐘，母語者遇到需要深入討論的話題，會用 take it offline 把話題移出去，而不是佔用全隊時間。學會這句，你會顯得很懂節奏。
Code Review 留言怎麼寫才不會得罪人？
這是最容易踩雷的場景。同一個意思，寫法不同，收到的人感受天差地遠。Google 官方的 Code Review 指南把原則講得很白：
Be sure that you are always making comments about the code and never making comments about the developer.
官方自己給的對照範例，值得逐字比對：
| 官方範例 | |
|---|---|
| 不好 | Why did you use threads here when there’s obviously no benefit to be gained from concurrency? |
| 好 | The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. |
差別有兩層。第一，主詞從 you 換成 the code——批評的對象變成程式而不是人。第二，把指控換成觀察：結尾那句 that I can see 留了餘地，等於承認「也許我沒看到全貌」。這兩個技巧套用在任何留言上都成立。
用前綴標示嚴重度，省掉一半的解釋
Google 官方定義了幾個留言前綴，讓對方一眼知道這則留言有多重要：
| 前綴 | 官方定義 | 白話 |
|---|---|---|
Nit: | This is a minor thing. Technically you should do it, but it won’t hugely impact things. | 小事，改一下但不影響大局 |
Optional: / Consider: | I think this may be a good idea, but it’s not strictly required. | 建議，你可以不接受 |
FYI: | I don’t expect you to do this in this CL, but you may find this interesting to think about for the future. | 這次不用改，供你參考 |
這正是英文技術溝通裡「禮貌」的真正做法：不是靠疊加客套字，而是靠給理由與留選擇權。Google 指南另外強調要 Explaining Why——說明你的意圖或這樣改如何讓 code health 變好，而不是丟一句命令。
被 review 之後，怎麼回覆才專業？
收到一串挑剔的留言，人難免不舒服。Google 給作者方的官方指南第一條就是：
Never respond in anger to code review comments.
官方直言，在情緒中回覆屬於嚴重的專業失當，而且這些紀錄會永久留著。太生氣就先離開，冷靜再回。
另外兩個很實用的官方原則：
- 對方看不懂，先改程式而不是在留言區解釋。官方原文是：if a reviewer says that they don’t understand something in your code, your first response should be to clarify the code itself. 你在留言區解釋得再清楚，下一個讀這段程式的人還是看不懂。
- 不同意時，先給理由再把球拋回去。官方建議的句型是：I went with X because of [these pros/cons]… Are you suggesting [alternative]? 這個結構之所以有效，是因為它先展示你思考過，再用問句邀請對方補充，而不是正面對撞。
其他好用的回覆句型：Good catch, fixed in the latest commit.（承認並修正）／That makes sense, but I’m worried about [X]. Thoughts?（部分同意）／Could you elaborate on what you’d expect here?（要求說清楚）。
PR 描述與 commit message 怎麼寫？
Google 官方對 PR 第一行的要求是：完整句子，而且用祈使語氣寫，像在下指令。
- 正確：Delete the FizzBuzz RPC and replace it with the new system
- 錯誤：Deleting the FizzBuzz RPC and replacing it…（現在分詞開頭）
官方還列了一串反面教材，看看你有沒有中槍：Fix bug、Fix build、Add patch、Moving code from A to B、Phase 1、Add convenience functions、kill weird URLs。共同問題是沒說清楚改了什麼、為什麼改。
至於 commit message 的格式，Conventional Commits 有官方繁體中文版可讀。格式是 <type>[optional scope]: <description>。這裡有個常被寫錯的細節：規範本身只正式定義了 feat 與 fix 兩種類型，其餘像 docs、refactor、test、chore 是沿用 Angular 社群慣例，不是規範強制的清單。
寫技術文件的整體邏輯，可以延伸參考英文商務文書寫作指南與英文寫作萬用指南的架構原則。
技術面試怎麼「邊寫邊講」？
白板題最大的難關，往往不是題目本身，而是要一邊想演算法一邊用英文解釋。Meta 官方的面試準備說明把期待講得很清楚：
We pay a lot of attention to the way you solve problems, which can be as important as having the right answer. Thinking out loud gives the interviewer insight into your thinking process.
Meta 也明講，卡住的時候要問問題：面試官通常夠熟悉題目，能給你往下走的線索。Microsoft 官方的面試建議則說得更具體：先問清楚模糊之處、講出你的假設，再開始寫。
為什麼明知道要講，現場還是講不出來
這裡有個反直覺的研究發現。Behroozi 等人發表於 ESEC/FSE 2022 並獲得最佳論文獎的研究指出，在有人即時盯著的情況下 think aloud，反而會壓抑受試者的表達；改成非同步錄製、移除即時監督後，表達的清晰度顯著提升、壓力下降，而且解題策略與程式碼品質不降反升。
換句話說：邊寫邊講是一項在壓力下更難執行的口語能力，不是靠意志力就能臨場發揮。可行的做法是事先把句型練成反射：
- 釐清題目：Before I start, can I clarify a couple of things? / Should I assume the input is always sorted?
- 講出假設：I’m going to assume the array fits in memory. / Let me know if that assumption doesn’t hold.
- 說明思路：My first thought is a brute-force approach, then I’ll look at how to optimize it. / The trade-off here is time versus space.
- 卡住時：I’m not sure this is the cleanest way. Let me think about it out loud for a second. / Am I on the right track?
- 收尾：This runs in O(n log n) because of the sort. / One edge case I’d want to test is an empty input.
第四點特別重要：說出「我卡住了」在英文面試裡不是扣分，Meta 官方甚至鼓勵你這時候提問。真正扣分的是沉默。
面試的整體結構與自我介紹，可以搭配英文簡報完整架構指南一起準備。
台灣工程師最常見的三個英文毛病
一、please 和 kindly 疊太多
Please kindly help to check this PR 這種句子，在台灣的工作信件裡很常見，但在英文技術語境中反而顯得不自然。Google 的開發者文件風格指南直接寫：
Using please in a set of instructions is overdoing the politeness.
官方建議的寫法是直接說 To view the document, click View.，而不是 please click View。真正的禮貌，是前面講過的：給理由、留選擇權、用 Nit / Optional 標示輕重。Could you take a look when you get a chance? 比三個 please 疊起來自然得多。
二、中文語序直譯，句子沒有主角
「這個 function 裡面有一個 bug」直譯成 There is a bug in this function，文法沒錯，但資訊量很低。Microsoft 的寫作風格指南建議刪掉 there is / there are、讓句子從動詞或主角開始。改成 This function throws when the input is null，讀的人立刻知道發生什麼事。
三、過度道歉，把自己講小
Sorry for my poor English、Sorry to bother you 開頭幾乎是台灣工程師的反射動作。問題是英文語境裡，開場道歉會讓對方預期接下來是壞消息，也會削弱你論點的份量。把它換成中性的框架句：Quick question about the deploy process. 或 Following up on the API change. 直接進主題，反而更專業。
順帶一提，把技術討論寫成英文不只是慣例問題。一份分析 2015 到 2025 年 GitHub 上超過 91 億則 issue、PR 與 discussion 的研究發現，非英語或多語專案的能見度與參與度明顯較低——語言同時是資源，也是門檻。
從哪裡開始練最有效率？
回到最前面那組數據：問題出在輸出量太少，不是輸入量不夠。所以練習的重點不是再讀更多技術文件，而是刻意製造開口的場合。
- 先把四個場景的句型各背三句：站會報進度、Code Review 留言、不同意時的回覆、面試釐清問題。數量少才練得起來。
- 自己錄站會發言。前面那份研究已經證明，沒人盯著的時候表達會更清楚——先在低壓力環境把流暢度練出來，再上場。
- 從寫開始帶動說。下一則 Code Review 留言，強迫自己用
Nit:或Optional:開頭，並補上一句理由。寫順了，講的時候句型就在腦子裡。 - 找真人對話補回饋。自己練最大的盲點是不知道哪裡不自然，而這正是需要有人即時指出來的部分。
如果你的需求不只是技術場景，想把整體職場英文一起補起來，可以延伸閱讀職場商務英文大全、開會英文完整句型攻略，以及英文口說訓練白皮書。
如果你的目標是把英文用在自己的產業裡，選課時要注意一個差別：一般商務英文教的是通用的會議與簡報技巧，而產業別課程教的是你所屬領域的專業語言——對工程師來說，就是 sprint、deployment、technical debt 這些真正每天在用的詞怎麼放進句子裡。
姓名
國碼
手機
