AI 讚美變成 production 債

我把 New Relic 的調查拆成一份可直接套用的 AI code 上線防呆 playbook。

我用 AI 寫 code 一陣子了。review 的時候它常常漂亮得很，命名工整、diff 乾淨、測試也像樣，整個團隊還會有種「這次省到時間了」的錯覺。問題是，這種漂亮很會騙人。它讓你以為自己在做品質管理，其實多半只是在看一份很順眼的草稿。

真正麻煩的地方，是 code 一進 production，事情就開始變味。原本 review 時沒人皺眉的 patch，到了線上可能變成 incident、rework、還有一堆沒人想接的 observability 債。我不是在罵 AI，我是在罵我們太常拿錯的標準去評它。

這次把我拉回現實的，是 IT Brief Asia 轉述的 New Relic 調查；原始報告是 New Relic 2026 State of AI Coding。數字很直白，review 讚歸讚，production 付錢歸付錢。我看到那組數字的時候，心裡只有一句：果然，問題不是 AI 會不會寫，是我們到底在哪個環節驗它。

我先講結論：不要再拿「看起來不錯」當上線標準。你要改的是判斷點，不是情緒。review 只是第一關，真正要管的是失敗模式、可觀測性、責任歸屬，還有這段 code 出事時誰會被叫醒。

review 很會騙人，production 不會

"94% of respondents said they viewed AI-generated code as higher quality than human-written code at the time of review" and "82% of respondents said they had experienced at least one production failure linked to AI-generated code."

翻譯一下就是：大家在 review 當下很買單，但一上線就開始還債。這組數字最刺眼的地方，不是 94% 很高，而是 82% 也很高。也就是說，review 的好感度跟 runtime 的安全感，根本不是同一件事。

我之前也踩過這種坑。某次 AI 幫我做了一段 refactor，diff 乾淨到像是資深工程師手寫的。reviewer 看兩眼就過了，因為它沒有亂改風格，也沒有那種一眼看出來的低級 bug。結果上線後，只有在特定流量與特定錯誤路徑一起出現時才爆。那時候才知道，review 只是在看「像不像對」，不是在看「會不會炸」。

實操寫法很簡單：我現在不把 review 當終點，只把它當進站口。凡是 AI 產出的變更，我至少要求其中一個東西補上：針對性測試、模擬流量驗證、或是 failure-mode 檢查。你要能說出「這段 code 在什麼情況下會壞」，不然它只是長得整齊，不是值得上線。

這裡的關鍵不是更嚴格地罵人，是把「漂亮 diff」跟「可上線」拆開。決策模板、PR review、甚至你們內部的 code review checklist，都應該多一條：這段 code 的 runtime 風險是什麼？沒人答得出來，就先不要急著合。

agent debt 不是技術債，是理解債

New Relic 把這種累積叫做 "agent debt"，也就是 "a massive deficit of unvetted architectural logic that triggers production incidents down the line."

這句話我很認同，因為它講的不是「寫太多 code」，而是「寫太快，理解跟不上」。翻成白話，AI 讓你堆出一堆看起來合理的架構邏輯，但那些邏輯沒有被真正的人腦壓過、想過、反證過。等到出事時，大家才發現自己其實沒那麼懂這段系統。

我最討厭的就是這種債。傳統技術債至少還有個作者，知道當初為什麼這樣寫、哪裡偷懶、哪裡是 trade-off。AI 生成的東西常常不是沒人寫，而是沒人真的「擁有」它。review 的人以為有人懂，實際上每個人都只懂一半。

我之前碰過一個服務，AI 幫忙拆了幾個 function，表面上可讀性變高，大家也很開心。但兩週後出現一個很怪的 race condition，只有在重試與 timeout 交錯時才會發生。最後是 senior engineer 花了半天把整個 call flow 重建起來，才知道問題藏在哪。那一刻我很明白：AI 有時不是省工，是把理解成本延後，然後一次收更大筆。

實操寫法是把「誰懂這段 code」寫進流程。GitLab 那種 merge policy 思維其實就很值得借鑑：不是只看能不能 merge，而是看風險有沒有被標出來。你可以在 PR 裡要求作者加一段 ownership note，至少寫清楚三件事：這段改了什麼、最可能怎麼壞、壞了會出現什麼訊號。這不是官僚，這是逼團隊別裝懂。

• 把 AI 產出的邏輯標記在 PR 裡。
• 要求作者寫出 failure modes，不要只寫功能描述。
• 讓 reviewer 知道哪一段是高風險區。
• 把「理解」當成 merge 條件之一。

政策不是禁不禁，是敢不敢寫清楚

"88% of organisations have incorporated vibe coding into production policies," while "5% restrict it to non-production environments, and none said their organisations ban the practice outright."

翻譯一下就是：大家早就不是在吵要不要用，而是在吵要用到哪裡、怎麼管。這比「全面禁止」實際太多了。因為老實說，禁掉 AI coding 很容易，真正難的是你要怎麼訂規則，讓它不會把 production 搞爛。

我看到這組數字時，第一個感覺不是驚訝，是無奈。因為這很像所有新工具進公司後的老劇本：先偷偷用，接著變成默認，最後才補 policy。等你真的開始寫規範，工具已經變 workflow 了。

實操寫法不要寫那種空話，像「AI 工具應負責任地使用」這種句子完全沒用。你要寫的是可執行規則：哪些類型的 code 可以用 AI、哪些一定要 extra review、哪些區塊必須 line-by-line 驗證、哪些情境要先過 staging 或 shadow traffic。規則越像風險控管，越有用。

如果你們團隊已經在用 GitLab Docs、GitHub Actions 或其他 CI/CD 流程，就直接把 AI policy 疊進去。不要另開一份沒人看的文件。把規則放進 merge gate、pipeline check、甚至 release checklist，才真的會被執行。

• 先允許 scaffold、refactor、test generation。
• 對 auth、billing、data mutation 加嚴審核。
• 把 production 使用條件寫成明確條款。
• 不要管工具喜不喜歡，先管風險高不高。

可觀測性要先寫，別等事故後補

"96% of technology leaders rated observability as very or extremely important" and "nearly 78% of teams said they now routinely prompt AI systems to include telemetry such as logs, traces, and metrics directly in generated code."

這段我其實很喜歡，因為它終於講到正事了。翻譯一下就是：聰明的團隊已經不只要求 AI 寫功能，還要求它順手把 logs、traces、metrics 一起生出來。這才像話。你要它幫忙幹活，就別只叫它寫表面功夫。

我以前最常看到的爛事，就是 code 在 staging 看起來沒事，到了 production 卻像黑盒子。不是不能跑，是你根本看不懂它在幹嘛。AI 如果只優化 happy path，這問題會更嚴重。因為它很會補齊表面結構，但不一定會主動幫你補 runtime 的訊號。

實操寫法很直接：把 observability 寫進 prompt。不要事後再補，不然通常都會拖。你可以要求 AI 產出時同時包含 structured logs、trace propagation、error counters、success/failure metrics。最好連欄位名稱都先講。像 OpenTelemetry 這種標準就很適合當底，至少你不是從零開始亂拼。

我自己現在會把 telemetry 當成 AI code 的第一層安全網。因為我看過太多「功能正確但完全無法觀測」的服務，最後只能靠猜。那種除錯方式很貴，而且很蠢。你如果讓 AI 寫 code，卻不讓它把可觀測性一起寫出來，等於自己把未來的自己推進坑裡。

實操上，我會要求每個 AI 生成的 service handler 都有這些東西：

• request_id / trace_id 透傳
• 關鍵分支的 structured log
• 錯誤碼與失敗原因統計
• 最少一個能反映業務結果的 metric

senior 工程師不是最後一道 lint

"86% said senior staff were spending more time fixing code," and "62% of technology leaders said their engineering teams often trust AI-generated code enough to send it into production without line-by-line manual verification."

這段很狠，因為它把成本藏不住了。翻譯一下就是：AI 沒有把工作消掉，只是把工作換一種方式丟回來，而且通常丟給最貴的人。你本來以為省了 drafting 的時間，結果只是把 cleanup 的時間往後推，還推到 senior engineer 身上。

我最怕的就是團隊開始習慣性相信 AI，然後把 line-by-line verification 當成可選項。62% 的人會這樣做，說真的不意外，但這數字也夠提醒人了。你可以讓 AI 幫你寫第一版，但不能讓它幫你決定風險等級。

我遇過一個團隊，AI 生成的 patch 速度超快，大家一開始都很爽。直到幾個 sprint 後，senior engineer 的時間被大量吃掉：修邊界條件、補測試、補監控、補文件。最後整體 throughput 沒有比較高，只是工作型態變得更碎、更吵、更難追蹤。這種帳很少有人會在 demo 時主動算。

實操寫法是把人工審查留給真正值錢的地方，其他交給自動化。SonarQube、測試、contract check、policy gate，這些工具應該先把低階錯誤清掉。Senior reviewer 的工作應該是看架構、看 side effect、看 edge case，不是拿來當萬用保險絲。

我會建議團隊至少追兩個數字：

• AI-assisted 變更帶來多少 cleanup time
• 這些 cleanup 是否集中在少數資深工程師身上

如果答案是「對，而且很明顯」，那你就不是在提效，你是在把成本往後藏。

我自己的規則很土，但很管用

"With 67% of respondents saying most of their weekly code is now generated or heavily refactored by AI, the question is no longer whether teams use these tools, but how much operational strain they are prepared to absorb once that code reaches production."

翻譯一下就是：AI coding 已經不是要不要用的問題，而是你準備承受多少 production 壓力的問題。這才是重點。很多團隊卡在 adoption 討論裡面出不來，但真正的戰場早就轉到營運成本、事故成本、還有信任成本了。

我自己的規則很土：先看 observability，再看 tests，再看 ownership。只要這三件事有一件缺，我就不會因為 diff 漂亮就放行。因為我太知道漂亮的 patch 有多會騙人了。它可以讓人快速點頭，但它不會替你接 incident call。

實操上，我會把 AI coding 當成一種壓縮技術。它壓縮的是產出第一版的時間，不是理解、驗證、維運的時間。有時候後面三件事還會被拉長。所以你不能只看「寫得快不快」，你要看「整個生命週期有沒有變重」。

如果你要一個最短版結論，我會這樣講：AI code 可以上線，但不能只靠 review 好看就上線。你要先讓它說得清楚、看得見、追得到，最後才輪到它被信任。

可抄的模板

# AI-assisted code shipping policy for production teams

## 1. Default stance
AI may be used for coding, but production trust must be earned through tests, telemetry, and explicit ownership.

## 2. Allowed uses
- Boilerplate and scaffolding
- Refactors with no intended behavior change
- Test generation
- Documentation and comments
- Telemetry and instrumentation additions

## 3. High-risk areas
Any AI-assisted change touching the following requires extra review:
- Authentication / authorization
- Billing / payments
- Data access / mutation
- Incident-path / customer-facing critical flows
- Infrastructure / deployment / rollback logic

## 4. Required PR fields
Every AI-assisted PR must include:
- [ ] Whether AI was used
- [ ] What changed in runtime behavior
- [ ] Known failure modes
- [ ] How failure will be detected in logs / metrics / traces
- [ ] Who owns the code after merge

## 5. Required merge checks
Before merge, confirm:
1. Tests pass
2. Static analysis passes
3. Runtime observability is present
4. A human reviewer can explain the failure modes
5. The rollback path is documented

## 6. Prompt pattern for AI-generated code
Use this prompt shape:

"Write [feature/refactor] for [system].
Constraints:
- Preserve existing behavior except for [explicit change]
- Add structured logs with [fields]
- Emit metrics for [events]
- Propagate trace context
- Add tests for [cases]
- Call out edge cases and assumptions
Return code plus a short explanation of failure modes."

## 7. Post-release check
Within 48 hours of release, review:
- error rate
- latency
- alert volume
- cleanup work required by senior engineers
- whether observability was sufficient to debug issues quickly

## 8. Team rule
If the author cannot explain what breaks when this code fails, it does not ship.

如果我要明天就落地，我會先從 prompt pattern 跟 PR checklist 開始。這兩個最便宜，也最能立刻改變團隊習慣。你不用先把整個組織重寫，只要先讓大家別再拿「看起來不錯」當「可以上線」就夠了。

這篇是我根據 IT Brief Asia 與 New Relic 原始報告 延伸拆解出來的。數字與觀點來自來源，我加的是我的工作流版本與可直接抄的模板。