不知道科技業的大家有沒有遇過這種人，學歷很漂亮，T 大純血 CS/EE，但四五十歲了也沒待過什麼叫得出名字的大公司。每天早上 5:56 就在 FB 自拍打卡，大家進辦公室還要被他酸一句「我都來多久了」。結果呢？Daily Stand-up 不來，Planning Meeting 說在忙，等大家開完會把決策都定好了，他才在 Slack 丟一句「為什麼我不知道有這個？@tech_lead」。這種人不是來寫 Code 的，是來刷存在感跟製造溝通災難的。

這位自封戰神的大老，最喜歡吹噓以前做過多大的分散式系統、流量幾百億，現在的專案對他來說太簡單。但他處理 Code 的方式簡直是產線奇觀：演算法跟邏輯他不管，最愛計較這是誰寫的。他可以花好幾個小時在那邊 git blame，然後把人叫進會議室一行一行拷問「憑什麼」、「為什麼」。

QA 最怕遇到他的案子。Test cases 退回去請他檢查，他連看都不看就暴怒咆哮：「我有欠你嗎？你們這什麼等級憑什麼跟我對接？」然後到處吹噓他們 team 隨便一個新人就能電爆大家。

在工業工程裡，這叫「標準作業程序（SOP）崩壞」。當一個工程師拒絕參與同步會議，又拒絕看非同步的文件與 Test Case 時，他產出的每一行 Code 都是沒有經過品管的黑箱作業。

面對這種拒絕溝通、只會事後諸葛的巨嬰，我們不能用「道德勸說」，必須用「架構決策紀錄（ADR）」與「非同步防呆機制」來反制

1. 強制實作 ADR (Architecture Decision Record)：
   把所有架構的改動、API 規格的決定，全部寫成 Markdown 放進 Repo 裡一起版控。他不來開會沒關係，PR 發出去，要求他強制 Approve。他如果按了 Approve 事後又吵「為什麼我不知道」，直接把 git blame 他的 Approve 紀錄貼在 Slack 臉上。

2. 把 Test Cases 變成 Executable Specifications：
   他不想看 QA 寫的 Test Case？沒關係。我們用 BDD 工具（例如 Behave 或 Cucumber）把測試規格寫成 Gherkin 語法，直接綁定在他的 CI Pipeline 裡。他不看？他的 Code 就永遠過不了 CI，永遠無法 Merge。

# CI 防呆：拒絕通靈，沒過 BDD 測試直接擋下
name: Specification Check
on: [pull_request]

jobs:
  bdd_test:
    runs-on: ubuntu-latest
    steps:
      - name: do something
        run: behave features/