不懂PHP的人用AI寫了9.5萬行WordPress代碼

一個連函數是什么都不知道的人，三個月后用對話式AI搭建了一個完整的產品篩選平臺。沒有IDE，沒有Git，沒有代碼基礎——只有Claude和一個文本編輯器。這件事是怎么發生的？代碼質量到底怎么樣？

事件現場：9.5萬行代碼的誕生

作者坦承：「我不懂PHP。從沒打開過計算機科學課本。連自己網站運行的大部分代碼都讀不懂。」

但數據擺在這里：95,510行自定義代碼，分布在129個文件中。一個84,272行的自定義WordPress主題。兩個插件共8,000行。一個3,238行的分析儀表盤。沒有頁面構建器，沒有Yoast，沒有RankMath，沒有父主題。

每一行都是與Claude對話的產物。

這不是教程，是一份事后剖析：非開發者完全用AI搭建生產級WordPress站點，什么能跑通，什么會崩，以及代碼庫為什么長成現在這樣。

清單1：到底造了個什么東西

SleekNova是一個禮品篩選平臺。產品要經過17個AI智能體驗證流程，在四個維度上打分后才能發布。

技術需求清單：

? 自定義文章類型：產品、實驗筆記、智能體、指南

? 6個自定義分類法：品類、風格、場合、關系、價格層級、主題

? 每個產品145個自定義字段（通過ACF實現）

? JSON導入器：接收AI流程輸出的結構化數據

? 完整SEO引擎：元標簽、規范鏈接、開放圖譜、Twitter卡片、AI元標簽

? JSON-LD模式生成：Product、Review、FAQ、BreadcrumbList、Organization

? AJAX篩選、禮品測試、數據完整性反饋循環

? 自定義站點地圖引擎

? llms.txt文件：針對AI爬蟲優化，目前已迭代到第60版

核心文件體積：

? seo.php：7,362行（45次以上迭代，完全替代Yoast）

? schema.php：5,059行（JSON-LD生成器）

? class-importer.php：2,249行（接收智能體流程的"黃金文件"）

? single-sn_product.php：2,208行（產品頁模板）

? functions.php：4,891行（主題函數）

? taxonomy-*.php：約800行每個（10個分類法模板）

清單2：開發流程有多原始

沒有IDE。沒有終端（一開始）。沒有GitHub。只有Claude的聊天窗口和一個用來粘貼代碼的文本編輯器。

每個功能的流程一模一樣：

第一步：用 plain language 描述想要什么

第二步：Claude寫代碼

第三步：粘貼到文件里

第四步：加載頁面

第五步：如果報錯，把錯誤信息貼回給Claude

第六步：重復直到能跑

「就這樣。這就是完整的開發方法論。」

前三個月，作者連函數是什么都不知道。不理解為什么有些代碼放functions.php，有些放模板文件。只是照做，觀察規律。

第四個月，變化發生了。開始識別代碼的"形狀"——不是語法，仍然不會寫PHP——而是結構。能看出這塊處理查詢，這塊格式化輸出，這塊捕獲錯誤。寫不出來，但能讀懂意圖。

「這就是'氛圍編程'（vibe coding）沒人討論的部分。你不是在學寫代碼。你是在學架構。學什么東西該放哪，什么依賴什么，改了上游什么會崩。」

清單3：最驕傲也最恐懼的7,362行

seo.php是作者最復雜的產物。45次以上迭代，完全替代了Yoast。

這個文件的規模暴露了純AI驅動開發的典型問題：沒有重構壓力，只有"讓它工作"的壓力。每次新需求都往上堆，而不是拆分成模塊。

作者描述了一個典型迭代：發現某個邊緣情況的元描述生成有問題，把整段邏輯貼給Claude，得到"修復版"貼回去。循環往復。沒有單元測試，沒有版本控制，沒有代碼審查。

結果是能跑，但沒人敢動。作者自己也不敢。「我知道它脆弱。我知道里面肯定有重復邏輯和死代碼。但它工作了，而且比Yoast更適合我的數據模型。」

清單4：什么真的崩過

JSON導入器是災難高發區。2,249行的class-importer.php接收"黃金文件"——AI流程輸出的結構化產品數據。

早期版本的問題：字段映射錯誤導致產品數據錯位；分類法層級嵌套過深觸發WordPress查詢超時；ACF字段更新與WordPress原生字段沖突造成數據丟失。

修復方式永遠是同一個循環：貼錯誤信息給Claude，拿新代碼，測試，再貼新錯誤。

「我花了兩周才理解，有些錯誤是數據問題，不是代碼問題。Claude會'修復'代碼，但根源是輸入數據格式變了。我學會了在貼錯誤前先問：這是代碼bug還是數據問題？」

另一個反復崩的點：內存限制。95,000行自定義代碼加145個ACF字段，產品頁加載時頻繁觸及PHP內存上限。解決方案是Claude寫的分批加載邏輯——作者至今不理解具體怎么實現的，但知道放在哪里、怎么調參數。

清單5：llms.txt的60次迭代

這個細節暴露了AI驅動開發的另一個特征：對AI生態本身的過度優化。

llms.txt是為AI爬蟲設計的站點說明文件，類似robots.txt但針對大語言模型。作者迭代了60版。

「我 obsessed over 這個文件，因為我就是AI輔助開發的用戶。我知道AI怎么處理網頁內容，所以我想讓我的內容被AI最好地理解。」

諷刺的是，這種優化本身也是通過與Claude對話完成的。作者描述需求，Claude生成llms.txt，作者測試效果（用Claude讀自己的網站），反饋問題，迭代。

一個為AI優化網站的文件，由AI幫助編寫，用于幫助其他AI更好地理解網站——這是2024年特有的遞歸。

清單6：代碼質量的真實狀態

作者沒有美化。直接列出問題：

? 重復代碼：seo.php里肯定有處理元標簽的函數被寫了多次，因為不同迭代沒復用舊邏輯

? 無文檔：除了Claude對話歷史，沒有注釋說明某個函數為什么存在

? 魔法數字：硬編碼的ID、閾值、超時時間散落各處

? 無測試：驗證"能跑"的唯一方式是手動點頁面

? 版本控制缺失：前三個月沒有Git，"備份"是復制整個文件夾加日期后綴

但也列出意外收獲：

? 高度定制化：沒有插件的通用邏輯負擔，每個功能精確匹配業務需求

? 數據模型一致：145個ACF字段的命名、類型、驗證規則完全統一，因為全是Claude按同一套指令生成的

? 快速迭代：新功能從想法到上線平均2-3天，傳統外包流程需要2-3周

實用指向：這件事到底改變了什么

這不是"AI取代程序員"的故事。9.5萬行代碼能跑，但作者明確說：「我雇了一個PHP開發顧問做代碼審查。三周后他提交的報告中，重構建議比功能建議多四倍。」

真正改變的是啟動門檻。一個不懂代碼的人，用對話式AI驗證了商業模式、積累了用戶、產生了收入——在傳統路徑下，這至少需要6個月找技術合伙人或攢外包預算。

更深層的變化是技術決策權的轉移。作者學會了"架構直覺"：不能寫代碼，但能判斷某個功能該用插件、自定義字段還是完全重寫。這種判斷力以前只能來自多年開發經驗，現在可以通過高強度AI協作壓縮到幾個月。

對科技從業者的直接啟示：

如果你在做產品決策——測試一下你的團隊里"最不懂技術"的人，用Claude或類似工具能獨立完成什么。邊界可能比預期遠得多。但別被騙：能啟動不等于能維護，能跑通不等于能擴展。作者的下一步是找專業開發重構核心模塊，AI生成的代碼作為精確的需求原型。

如果你在寫代碼——觀察這種新型"產品經理"的需求表達方式。他們描述的是業務結果（"讓AI能讀懂我的產品頁"），不是技術方案（"實現JSON-LD Product schema"）。能翻譯這兩種語言的人，價值在上升。

最后的判斷：這個案例的價值不在技術可行性（已經驗證了），而在成本結構的永久性改變。驗證階段的代碼成本趨近于零，但技術債務的償還成本沒有變。新游戲的規則是：用AI跑得足夠快，在債務崩盤前產生足夠現金流，然后雇人還債。