Day 21：請 AI 幫忙寫程式碼，怎麼確保它沒用 CI 矩陣不支援的語法？

2026 iThome 鐵人賽

DAY 21

IT Operation

AI 輔助開發下，測試如何保住品質防線系列第 21 篇

18th鐵人賽 ai agent php omnipay

recca0120

2026-09-25 11:31:03

104 瀏覽

分享至

前言：AI 寫的程式碼，會不會用了 CI 不支援的新語法？

如果現在請 AI 幫 omnipay-ecpay 加一個新功能，AI 很有可能會很自然地寫出 match 表達式、nullsafe operator ?->，或建構子屬性提升——這些都是更精簡、更受現代 PHP 開發者歡迎的寫法。問題是：CI 矩陣最舊還測到 PHP 7.1，這些寫法在那個版本上會直接讓語法解析失敗。今天討論怎麼避免這件事。

今日目標

理解 AI 為什麼容易「自然而然」寫出目標專案不支援的新語法
看兩種防線：事前明講限制、事後靠 CI 矩陣攔截,各自的成本與時機
對照一組「沒講清楚」跟「講清楚」的 prompt 差異
想清楚這件事跟 Day 15 講的「composer.json 該不該補上版本約束」是同一個問題的兩種呈現方式

AI 為什麼容易寫出新語法

AI 語言模型的訓練資料涵蓋的是「現在整個 PHP 生態系怎麼寫程式碼」，而不是「這個特定專案這幾年來的寫法慣例」。如果你只跟 AI 說「幫我加一個判斷付款方式回傳對應字串的方法」，AI 大機率會傾向寫出它認為「當下最佳實踐」的版本——包含 match 這種近幾年才有、也確實比 switch 更精簡的寫法。AI 沒有理由知道這個專案的 CI 矩陣最舊測到 PHP 7.1，除非你告訴它。

兩種防線：寫在 prompt 裡 vs 靠 CI 矩陣攔截

事前防線：在 prompt 或專案指引裡明講版本限制。 這是最省事、最早期就能生效的做法——AI 生成程式碼的當下就會避開不支援的語法，不需要等到跑 CI 才發現問題。

事後防線：靠 CI 矩陣本身當最後一道關卡。 就算沒事先講清楚，只要 CI 矩陣涵蓋到最舊支援的版本，AI（或人類）不小心寫出的新語法還是會在 PHP 7.1 那個 job 上直接語法解析失敗，逼你回頭修正。這是這個套件目前實際上唯一在運作的防線——前面 Day 15 到 Day 17 看到的,composer.json 沒有版本約束、README 徽章脫鉤,都代表「事前明講」這件事目前完全沒有被做到,全部的相容性責任都壓在 CI 矩陣這一道防線上。

兩種防線不是二選一，是先後順序的問題：事前防線省下的是往返修正的時間，事後防線是保底,兩者都存在時，事前防線失敗了還有事後防線接住；只靠事後防線,則每一次不小心用了新語法,都要等 CI 跑完才知道。

❌ vs ✅：prompt 有沒有講清楚版本限制

❌ 沒講清楚
「幫我在 PurchaseRequest 加一個方法，依付款方式回傳對應的英文代碼」

✅ 講清楚這個專案的版本限制
「幫我在 PurchaseRequest 加一個方法，依付款方式回傳對應的英文代碼。
這個專案的 CI 矩陣涵蓋 PHP 7.1 到 8.3，請避免使用 match 表達式、
nullsafe operator (?->)、建構子屬性提升等 PHP 8 才有的語法，
用 switch/if 搭配傳統建構子寫法。」

正例多花的那幾句話，換來的是AI 產出的程式碼一次就符合這個專案實際能跑的版本範圍，不用等到 CI 在 PHP 7.1 那個 job 上炸掉才回頭改。這跟 Day 13 提到的「怎麼問才會補到邊界情況」是同一類技巧：AI 不會自動知道你專案裡那些沒寫進程式碼、只存在於 CI 設定或團隊默契裡的限制,你得明講。

這跟 Day 15 是同一個問題的兩種呈現方式

Day 15 講的是「composer.json 沒有 "php" 版本約束,相容性承諾沒有寫在 Composer 能檢查的地方」；今天講的是「AI 寫程式碼時,也沒有從任何地方讀到這個版本限制」。兩者的根源是同一件事：這個專案的版本相容性承諾,目前唯一被寫下來的地方只有 CI 矩陣設定,沒有寫進 composer.json，也沒有寫進任何一份給人類或給 AI 讀的專案指引裡。如果要讓事前防線真正生效，第一步反而是回到 Day 15 討論的那件事：把版本承諾寫進一個公開、結構化、AI 跟人類都讀得到的地方。