在工程團隊中，尤其是處理 Web 應用、分散式系統與各種 runtime 環境時，語言不只是溝通工具，而是系統的一部分。
在每日與印度工程師團隊遠距開發實務經驗中反覆觀察到一個問題：問題描述時用語不精確，會讓除錯成本呈指數級上升。原本只需要幾十秒釐清的事情，往往因為模糊敘述，演變成數小時的溝通、驗證與無效排查。
這篇文章將說明：
- 為什麼精確語言在工程中是硬需求
- 模糊用語如何實際製造技術風險
- 工程師可以如何避免這類成本浪費
一個簡單但關鍵的例子：意圖（Intent）vs Runtime 行為（Runtime Behavior）
請比較以下兩句話：
❌「我不能在這個資料夾裡寫入任何檔案。」
✅「我的 PHP 程式碼在 runtime 期間無法在這個資料裡夾寫入任何檔案。」
乍看之下意思相近，但在工程層面，這兩句話完全不同。
為什麼第一句溝通的語句較短(比較口語化)其實是問題敘述錯誤
描述的是「人的意圖」，不是系統行為，指的是開發者角色，而非實際執行中的程式，無法被 logs、權限或執行路徑驗證。
在正式系統中，人的意圖毫無意義。系統只會回應「哪些程式、在什麼權限下、實際做了什麼事」。
為什麼第二句需要打比較長的文字才是正確工程語言？明確指向 runtime 行為，限定可驗證的執行上下文、可透過 logs、檔案權限與程式碼路徑確認。
這個區分，是所有有效除錯的基礎，尤其是在有時差的遠距工作上。
Runtime 的現實：系統不在乎你是誰，在 runtime 層級：PHP 是「行程（process）」，不是人，系統不知道誰是開發者，任何擁有寫入權限的程式碼（包含 plugin、背景任務、非預期路徑，甚至惡意程式）都可以寫入檔案。
因此：
- 描述人的行為，不等於描述系統行為。
- 工程溝通必須對齊這個現實：模糊用語的隱形成本。
在最近一次實際案例中：
原本只需要 30 秒 馬上就能釐清的問題
因為用語不精確，因為遠距非同步關係，演變成至少 1 小時以上的來回溝通與確認，這個成本不是來自系統複雜度，而是來自語言模糊。
成本拆解（實務觀察）
- 初始模糊敘述：10 秒
- 補充詢問與澄清：10–15 分鐘
- 驗證、對齊理解與重複說明與非同步等待：30–45 分鐘
這樣的浪費會在團隊中持續累積。
為什麼語言品質會反映工程品質
在工程角度：
- 語言是思維模型的外顯
- 思維模型決定抽象邊界
- 抽象邊界決定程式碼結構
當語言不精確時，往往伴隨著：
- 假設外洩
- 責任邊界模糊
- Side effect 被隱藏
這也是為什麼模糊敘述會合理地引發對於提問者本身所撰寫程式碼可靠性的憂慮。
常見需要避免的反模式（Anti-patterns）
請避免以下描述方式：
- 「我沒有做某件事」這類以人為中心的敘述
- 「應該是某某東西造成的」的猜測語言
以角色或職稱代替系統行為描述
請優先使用：
- runtime 行為描述
- 可觀測、可驗證的事實
- logs、headers、執行結果等證據
一個常見但危險的「便宜解法」：把目錄權限改成 777
在實務中，當系統出現寫入權限相關問題時，經常會看到一種快速但危險的處理方式：
「先把目錄權限改成 777，看能不能解決。」
表面上，這個做法似乎可以「立刻讓問題消失」，但從工程與系統安全的角度來看，這其實是在為未來埋下高風險地雷。
為什麼 777 看起來有效？所有使用者與行程都具備讀 / 寫 / 執行權限
- 權限錯誤暫時不會再出現
- 問題「看起來」被解決了
為什麼這是工程上的錯誤決策
它掩蓋了真正的 root cause（例如錯誤的 ownership、錯誤的 runtime 使用者、或 plugin 行為異常）
任何能執行的程式碼（包含 plugin、背景程序，甚至惡意程式）都可以寫入該目錄
系統失去最基本的防線，debug 訊號也被一併抹除
長期後果
- 安全風險大幅提升
- 問題一旦再次發生，更難追查來源
- 系統行為變得不可預測
從工程角度來看，777 不是解法，而是把問題延後並放大。
工程師的簡單自我檢查規則
在送出任何問題描述前，請先問自己一句話：
「這句話，能不能用 logs、程式碼或系統行為來驗證？」
如果不能，請重寫。
結語
精確用語不是吹毛求疵，也不是文字潔癖。
它是在：
- 保護工程時間
- 降低系統風險
- 維持團隊信任
- 每一句模糊描述，都會把成本往下游推。
- 每一句精確描述，都是在預防不必要的工作。
- 在工程世界裡：
清楚不是軟實力，而是硬需求。
