其實唔止 New Relic 一個喺度大聲疾呼。2026 年其他行業報告都畫出同一幅圖畫:
歸根結底,個問題唔係 AI 寫嘅碼好差。而係生成速度係人類嘅 5 到 10 倍,但驗證速度仍然係 1 倍 。本來為人類工作節奏設計嘅程式碼審查流程,根本追唔上 AI 嘅輸出量,造成咗一個「驗證瓶頸」,令唔可靠嘅程式碼可以神不知鬼不覺咁走咗入生產環境。
2026 年 6 月 8 日,New Relic 直接回應呢個脫節問題,宣布開發緊一套叫 New Relic AI Coding Observability 嘅開源可觀測性方案,專為 AI 輔助軟件開發而設計 。呢個功能預定喺 2026 年 6 月 23 日推出,而且唔使 New Relic 客戶額外俾錢
。
呢個架構嘅設計好關鍵。New Relic 特登將 AI Coding Observability 建基於兩個開放標準:OpenTelemetry (OTel) 同 模型上下文協議 (MCP) 。咁樣意味住團隊唔會俾 New Relic 嘅遙測格式綁死,亦唔會鎖死喺單一嘅 AI 編碼助手。任何一個能夠曝露 MCP 相容遙測數據嘅助手——例如 GitHub Copilot、Cursor、Claude Code 等等——都可以接入同一個可觀測性層
。喺一個今日嘅主流編碼工具聽日可能就唔係嘅市場入面,唔俾供應商鎖死,係一個好實際嘅需要。
呢個策略嘅核心在於「關聯性」。AI Coding Observability 嘅設計,係要標準化唔同 AI 編碼助手嘅遙測數據,再將佢同現有嘅生產基礎設施無縫關聯起嚟 。個概念係創造一個統一嘅監控儀錶板,等團隊可以追蹤一個 AI 生成嘅改動,由開發環境(IDE)開始,穿過部署管道,一路落到生產環境——然後睇下呢個改動,同幾個鐘頭甚至幾日後出現嘅事故高鋒期有冇關聯。
CTO 們喺 2024 到 2025 年,全部都係聚焦喺 AI 編碼助手嘅採用同生產力提升。但 New Relic、Lightrun、Faros、Sonar 等機構嘅數據講得好清楚,下一個階段,一定要聚焦喺驗證、可靠度同成本問責。
喺程式碼審查階段有 94% 嘅信心,本身未必係錯——AI 好多時的確會生成乾淨、可讀、語法正確嘅代碼,過到靜態分析。失敗嘅模式係環境性嘅:AI 生成嘅代碼喺 Pull Request 呢個狹窄嘅沙箱入面表現良好,但一遇到複雜嘅生產數據、真實用戶行為同系統互動,就會頂唔順。而呢啲嘢,冇一個程式碼審查可以完全模擬到 。如果缺乏一個橫跨兩個階段嘅可觀測性,機構評分就好似用緊一個生產環境根本唔承認嘅「等級曲線」。
New Relic 嘅 AI Coding Observability,正正就係一次直接嘗試,去將呢個循環閉合返,推動成個行業由「信個審查結果」進化到「喺生產環境度驗證」嘅年代。
Comments
0 comments