ERP 通用 PHP 客戶端快速開發 — AI輔助程式設計示範案例

以下工作內容 perplexity.ai Pro帳戶/主要模型 Cluade Sonnet 5 人工描述目標及問題,口語化描述由生成式AI產出PHP程式碼及相關說明文件輔助完成

本文件以《ERP通用PHP客戶端架構說明及佈署及使用方法-整合版V4.1》為唯一事實基礎重新整理, 延續前版《AI輔助程式設計示範案例》的方法論骨架,但補齊V16~V20階段最關鍵的一段插曲—— 一次由AI自己造成、又由AI自己協助抓出的重寫退化bug,以及後續AI維護的文件本身也曾落後於實際程式碼這件事。這兩段插曲,是整份文件裡最不該被省略的部分:它們共同說明了AI輔助開發不是「問一次就對」的過程, 而是持續踩坑、持續用證據(封包、diff、對照測試)反覆校正的過程。

為保護商業機敏資訊,文中已移除所有帳號、密碼、內部網址、實際單位識別碼等敏感內容, 案例企業以「某股份有限公司」代稱,不揭露真實公司名稱。

1. 案例背景與示範目的

某股份有限公司(製造業,ERP系統採用ASP.NET WebForms技術棧建置多年)內部有一項重複性極高的人工作業:在ERP系統中為產品逐筆手動輸入「原廠編號建檔」資料。該功能僅提供瀏覽器操作介面,原廠並未提供任何正式API或SDK,若要串接自動化流程(如批次建檔、外部系統整合),只能自行開發橋接程式。

本案例示範如何借助AI協作,在完全不具備該ERP系統內部文件的前提下,從一個最簡單的表單腳本開始,透過反覆提問、貼上真實錯誤訊息、貼上瀏覽器封包給AI分析,逐步疊代出一套結構完整、具備除錯能力的通用PHP客戶端框架——並且在中途親眼看著AI把自己寫過、已驗證能動的程式碼悄悄改壞,再一起用證據把它找回來。

示範重點在於呈現與AI協作時的提問策略、疊代節奏、除錯思路,以及AI犯錯時該怎麼發現、怎麼收拾,而非展示具體帳密或內部系統細節。

2. AI輔助開發的協作模式

整個專案並非一次性讓AI「生成完整程式」,而是採用漸進式、證據驅動的協作節奏,大致可歸納為以下幾種提問模式:

需求描述型:先描述原系統的操作邏輯,請AI提出初版架構與程式碼骨架。
錯誤貼上型:實測後遇到失敗,直接把ERP回應的原始內容、HTTP狀態碼貼給AI,請其分析可能根因,而非自己先猜測再驗證。
封包比對型:使用瀏覽器開發者工具(F12 Network)擷取真實請求的Header、Body,貼給AI逐項與目前程式碼比對,找出結構差異。
重構請求型:當功能持續增加、程式碼開始重複時,主動要求AI提出模組化、抽離共用邏輯的重構方案。
對照實驗型(V16~V20階段新增):當懷疑「是版本差異還是資料差異」時,不直接問AI「哪裡錯了」,而是先要求固定資料、只切換版本,取得兩組獨立證據後再讓AI比對。
diff驗證型(V16~V20階段新增,源自一次教訓):任何AI宣稱「只改了一處」的修改,都要求附上或自行跑一次diff,確認實際差異真的只有預期的那幾行。

這種協作模式的核心價值在於:AI補足了開發者對ASP.NET WebForms底層機制、IIS行為特徵的知識空白,但AI本身也會在協作過程中犯錯,而且犯的錯往往不是明顯的語法錯誤,是那種「看起來完全合理、實測才爆炸」的隱性錯誤。下面第3節會完整呈現這一段。

3. 開發歷程:五階段疊代示範

階段一:最小可行版本 — 先讓核心流程跑起來

提問切入點:「原系統的建檔表單按下保存會呼叫一個叫saveit()的JS函式,送出XML到後端,我要用PHP模擬這個登入+送出的過程。」

AI協助產出最初版本:PHP表單頁+cURL登入橋接,全程假設UTF-8編碼。實測後,中文欄位出現亂碼。描述現象給AI後,判斷出原系統前端以Big5編碼服務,新增編碼轉換層,並改用mb_convert_encoding()而非iconv()(生僻字容錯更好)。

示範要點:先驗證「登入→送出→取得回應」這個最小流程能走通,再針對實測發現的具體問題逐一解決,避免一開始就過度設計。

階段二:功能完善與模組化重構

隨著需求增加,程式碼開始出現重複。主動請AI審視現有結構並提出重構建議:批次多行輸入、除錯回應顯示、UI子模板抽離、驗證規則集中到field_rules.php單一來源,讓PHP後端/HTML5屬性/JavaScript三層共用同一份規則。

示範要點:主動要求「幫我檢視這段程式有沒有可以模組化的地方」,能及早發現架構債,避免技術債累積到後期才處理。

階段三:對接真實系統的除錯攻堅

真正對接時發現前兩階段的許多合理推測其實是錯的。關鍵轉折——貼真實封包給AI比對:F12擷取的完整Header/Body,逐項比對後揪出Content-Type寫法、XML結構、資料節點完整屬性數量等多處落差。

設計出「登入→開啟功能頁驗證登入狀態→再送出資料」的三段式驗證流程,每一段都有明確可觀察的驗證點。過程中還遇到一個經典教訓:除錯記錄因為顯示時做了截斷處理,反而遮蔽了問題根源——舊系統網頁原始碼裡有一處屬性寫法沒加引號,而原本比對邏輯預設所有屬性都會加引號,因此讀不到。改用全文搜尋、完整內容保存與顯示層截斷分離設計後,才真正找到根因。

也在此階段加入請求節流機制,應對批次送出時觸發的IIS請求頻率保護。

示範要點:對接沒有文件的舊系統時,真實封包永遠比理論推測可靠。

階段四:多版本並行測試框架 — 當「是版本差異還是資料差異」變成關鍵問題

V15完成除錯基礎設施成熟化後,新的問題出現了:某個新版本開始出現批次送出100%失敗,ERP只回傳短短一句「並未將物件參考設定為物件的執行個體。」——這是.NET的NullReferenceException,不含任何欄位名稱、不含錯誤碼,是整個專案遇過資訊量最少的錯誤回應。

過程中第一個要解決的問題,反而不是「這個bug是什麼」,而是「這個問題到底跟版本有沒有關係」。因為過去每次重測,往往版本也換了、測試資料也換了,兩個變因混在一起,永遠無法確定問題根源在哪一層。於是提出控制變因的對照實驗:要求用「完全相同的一批測試資料」分別測舊版本(成功)與新版本(失敗)。這個簡單的要求,反而是排查過程中最重要的一步——它把「資料問題」這個競爭假設徹底排除,鎖定問題確實在版本本身。

接著設計了index.php裡的$availableEngineVersions陣列作為單一維護點,同時驅動白名單驗證與畫面單選按鈕UI,讓使用者可以固定資料、只切換版本,即時對照測試。

逐輪排查記錄:

輪次	假設	結果
1	Content-Type標頭多餘空格	修正後仍失敗,推翻
2	測試資料本身有問題	對照實驗證明資料無關,推翻
3	Header結構差異	新增`erp_header_diag.php`逐行比對,Header逐字元相同,推翻
4	POST body內容差異	發現Content-Length相差13 bytes,找到決定性線索
5	XML根結構寫法錯誤	逐字元比對body原文後確認根因

階段五:AI自己捅的洞 — 一次真正的「重寫退化」事故

這是整份文件裡最需要誠實面對的一段。

第5輪查到的根因是:新版本的buildRowXml()回傳的XML根結構被誤寫為<rsdata>...</rsdata>,漏掉了<rs:data>容器,而正確結構應該是<xml><rs:data><z:row/></rs:data></xml>。ERP後端拿<rs:data>節點做選取時選到null,後續程式碼沒做null檢查就直接呼叫方法,於是爆出那句沒頭沒尾的.NET例外。

這段程式碼是怎麼壞的? 不是人手動改壞的,是AI在被要求「新增除錯功能」時,把這個完全不相關的既有函式一起重新生成了。當時的請求只是「幫我加一個追蹤序號跟更詳細的trace記錄」,AI確實加上去了,但同時也把buildRowXml()的return那一行,從逐字保留改成了看起來語意相同、實際結構卻錯誤的新寫法。這種行為在文件中被正式命名為「重寫退化」(regression by rewrite)——AI在完成「這次要達成的目標」時,傾向於把整個函式或整段程式碼重新生成一遍,而不是只動真正需要改的那一行,於是不相關的、原本已驗證正確的程式碼就在「順手」之間被改壞了,而且改壞的方式往往連AI自己都不會主動提及,因為從AI的角度看,新寫法「語意上」是等價的。

修正時吸取的教訓,變成了兩條正式的編程原則:

添加任何新功能,以最小化修改為基準,不得過度工程化。
修改任何舊功能,以原始代碼為基準,只改真正需要改的那幾行,其餘逐字元保留,不做「順手」的省略或簡化。

修正後的版本,只改了buildRowXml()最後一行return陳述式,其餘所有函式逐字元保留前一版原文——這個修正本身,也是拿著兩個版本的完整原始碼跑diff,肉眼確認差異只有一行,才敢確定改對了。

但故事還沒完。這個原則被寫成文件之後,同一類型的問題還是又發生了一次。

在後續一次「順手」修正無引號HTML屬性解析函式inputValue()的過程中,經人工用diff重新逐字元比對「穩定基準版」與「現行版」兩份完整原始碼才發現:現行版的inputValue(),相較基準版少了一段正規表達式邊界斷言。基準版對無引號屬性值有明確的右邊界檢查(確保比對到id=userno時不會誤配到id=userno2這種前綴相同但實際不同的欄位),現行版這段邊界檢查在某次疊代中悄悄消失了,而功能表面上看起來完全正常——因為手上的測試資料剛好沒有踩到這個邊界情境。

這件事帶來一個更誠實的領悟:即使團隊已經明文寫下「最小化修改」「以原始代碼為基準」兩條原則,AI仍然不會每次都主動遵守,除非每一次修改都真的拿diff去核對,而不是相信AI在回覆裡宣稱「其餘完全不變」這句話本身。原則寫在文件裡,不代表原則會被自動執行——它必須靠人工用工具持續驗證,才會真的變成保障。

同一時期,還發生了第三件事,層級不同但性質相同:文件本身也會過期。 舊版本檔案在完成任務後依標準流程被移除,但描述這套系統的AI輔助生成的架構文件,卻在多個章節仍然沿用「三版本並存」「預設載入舊版本」的舊敘述,足足落後了一個版本迭代週期才被人工發現並修正。這說明AI維護的說明文件,跟AI維護的程式碼,會犯同一種病——都需要有人拿「實際狀態」去對照校正,而不能假設AI上次寫對的東西,這次還會自動保持同步。

示範要點:AI輔助開發最危險的地方,不是AI寫不出程式碼,而是AI寫出的程式碼「看起來」是對的。防禦手段不是要求AI更小心,而是把「diff比對」「對照實驗」「固定測試資料」變成每次修改後的強制驗證動作,不管AI在回覆裡怎麼描述這次改了什麼。

4. 最終技術架構(去識別化版本,對應V20實際部署狀態)

erp-client/
├── config.php               ← 連線層共用設定(登入、編碼、節流、除錯路徑、Header診斷開關)
├── modules.php               ← 功能模組登錄檔(每個ERP功能對應一筆網址/欄位/XML範本定義)
├── field_rules.php           ← 表單驗證規則單一定義(必填/格式/錯誤訊息)
├── debug_set.php             ← 除錯開關與資料夾/檔名規則唯一定義處
├── debug_writer.php          ← 除錯紀錄落地存檔工具
├── erp_header_diag.php       ← Header/POST body診斷工具(獨立開關,跨版本共用)
├── ErpClient_v18.php         ← 穩定基準版引擎(刻意保留作為歷史對照基準)
├── ErpClient_v20.php         ← 目前現行使用版本
├── acc.php                   ← 連線設定UI子模板
├── index.php                 ← 主表單頁(含引擎版本切換、批次送出、除錯顯示控制)
├── lookup_part.php           ← 料號查詢輔助介面(選配)
└── debug_logs/                ← 落地存檔根目錄(需限制外部存取權限)

設計原則摘要:

帳號密碼一律由使用者於表單當次輸入,不寫入任何設定檔或程式碼。
每個ERP功能的網址與資料結構定義集中於modules.php查表管理,核心引擎不含任何特定功能的專屬字串。
驗證規則集中於單一設定檔,三層共用同一份定義。
曾經一度並存三份引擎版本檔案(基準版/故障對照版/修正版)供對照測試;故障對照版在修正確認穩定後,依「先改陣列、確認畫面不再顯示、再刪檔案」的標準流程正式下架,目前僅保留基準版與現行版兩份。
流程結束一律呼叫登出端點釋放Session,登出失敗不影響主流程結果顯示。

5. 可複用的AI協作方法論總結

開發挑戰	與AI協作的應對策略
無官方API文件	以瀏覽器F12封包作為「真實規格」貼給AI比對,取代憑空推測
編碼/亂碼問題	描述現象讓AI判斷可能的編碼層問題,而非直接套用單一函式
除錯資訊不足	主動要求AI設計「可觀測」的除錯機制,而非僅在出錯時才臨時加log
特定狀態碼原因不明	提供現象模式讓AI交叉排除可能根因,而非直接假設是權限問題
無法確定是版本差異還是資料差異	設計「固定資料、只切換版本」的對照實驗機制,取得雙份證據後再交給AI比對
AI在新增功能時悄悄改壞了不相關的既有程式碼	不相信AI回覆裡「其餘不變」的說法,每次修改後都跑diff逐字元核對
AI維護的說明文件本身跟不上程式碼的實際變動	任何觸發程式碼版本清單變動的操作,都同步列出受影響文件章節清單並逐一核對
程式碼漸趨複雜	定期主動請AI檢視並提出模組化、去重複建議

核心心得:AI輔助開發在對接無文件舊系統這類任務上的價值,不在於「一次生成完整答案」,而在於加速「假設—驗證—修正」的疊代循環。但這個循環裡有一個容易被忽略的風險——AI本身也是疊代過程的一部分,也會在疊代中引入新的錯誤,而且這類錯誤通常隱藏得很好,不會在AI的回覆文字裡被誠實揭露。真正讓這個框架能穩定運作的,不是「相信AI這次做對了」,而是把diff比對、對照實驗、固定測試資料這些不信任AI自我陳述、只信任可重現證據的習慣,變成整個團隊的日常紀律。

6. 已知限制(去識別化版本)

並發編輯保護機制尚未實作,多人同時批次操作同一資料時仍有風險。
若目標系統資料庫存在歷史編碼包袱,現有單層編碼轉換無法完全處理。
登入表單欄位名稱等設定需依實際目標系統人工核對,無法通用假設。
批次送出目前為同步逐筆執行,大量資料時前端等待時間較長。
落地存檔目前未設自動清理機制,長期運行需另行規劃保留期限與清理排程。
Header/POST body診斷工具若忘記排查結束後關閉,會持續佔用硬碟空間,且內容含Cookie等敏感資訊,務必落實存取限制。
多版本並存本身有維護成本,已下架的過渡版本不應無限期保留,但每次下架都必須同步核對說明文件是否有相應章節需要更新——這是本案例親身踩過的坑,值得寫進任何團隊的標準作業流程。
本框架屬於模擬前端行為的橋接方案,若目標系統前端頁面結構日後調整,需同步更新對應邏輯;長期建議仍以取得正式API文件為優先目標。

*本文件為《ERP通用PHP客戶端架構說明及佈署及使用方法-整合版V4.1》之去識別化AI協作方法論示範版本,已移除所有帳號、密碼、內部網址、公司與系統識別資訊。*