網站時好時壞、一直跳 Error 1102?我跟 AI 花一天追出真正的原因
昨天剛上線的網站,今天就時好時壞、一直跳 Error 1102。我不是工程師,跟 Claude 一起花一天追出原因——不是某個 bug,是架構:內容型網站卻每次現場重算。附我的除錯五步筆記。
網站一直壞 原來是架構問題
Error 1102?跟 AI 一天追到根
今天打開昨天才剛上線的網站,想試試訂閱功能。email 打一打、按下去——沒反應。重新整理,網站自己還時好時壞,有時候乾脆直接跳出 Error 1102 的白畫面。
於是跟 Claude 一起開始修。好了又壞、壞了又好,來來回回一整天,最後終於搞定了!這篇就是分享那整個過程——我不是工程師,但跟 AI 一起,把一個很煩的問題挖到了根。
先搞懂 Error 1102 到底是什麼
我沒有一上來就叫它修,而是先搞懂這是什麼。問了 Claude 之後我大概懂了:Error 1102 是伺服器一次做太多、超過上限,做不出來就中斷;而它會時好時壞,是因為伺服器閒著會睡著,有人來要先「叫醒」(工程上叫冷啟動),叫醒那下最容易爆。
這一步對我很重要——看不懂的時候,我不會急著讓它動手,先問到自己能用大白話講出來為止。
我平常怎麼跟 AI 工作
我不是想到什麼就丟什麼。我把偏好、規則寫成檔案讓它每次先讀;大事會先讓它寫一份計畫、我核可再動手;也做了幾個固定流程的 skill。盡量讓它照規矩來,不天馬行空。
有一套規矩,為什麼還是亂試
1102 一出來,Claude 很快丟出一堆解法:查金鑰(結果有設)、升級付費方案($5/月)、換一個平台重架……
但這些我大多沒採用。要花錢的我不想花,也懷疑花了有沒有用(後來查證,升級真的救不了);換平台這種大動作我更不想輕易動。我沒多懂技術,但心裡一直有個直覺:這些好像都只是先擋著。後來證明,這個直覺是對的。
這也是為什麼會「好了又壞」——每個看起來能擋一下的方法,試完都發現沒解決到根本。
回頭想,為什麼有一套規矩還會這樣?因為那套設定管的是「怎麼做」,沒在管「這問題該站多高來看」。1102 一跳出來,我跟 AI 都本能地開始修它,沒有人先退一步問:這東西本來該長怎樣。
換個問題問,方向就對了
轉折是我開始問一個不一樣的問題——不是「怎麼讓錯誤消失」,而是「這樣是不是治本?它本來該長怎樣?」方向一換,才挖到真正的原因。
真正的原因:每頁都「現場重算」(冷啟動)
我的網站是部落格,內容只有發文才會變。但我目前的做法是:每個讀者、每次打開,系統都現場重算一次。
Claude 用一個比喻我才懂:像一間餐廳,菜單很久才換一次,卻讓每位客人點餐都「從零現煮」,還用一個免費小爐子。沒客人時爐子熄火省電,有人上門得先重新開火——那幾秒小爐子有時撐不過,那份餐就失敗。那個「開火失敗」就是 1102,冷的時候爆、熱的時候順,所以時好時壞。
修法就跟著清楚了:既然內容平常不變,把每頁先做好、放著(工程上叫「靜態」),讀者直接拿,不用叫醒任何爐子。改完之後,我從冷的狀態連開二十次,沒再壞過,訂閱也一起好了。
把教訓寫回規則,讓下次更聰明
這次我沒有修好就算了,而是把學到的寫回自己的規則檔:以後遇到問題,先分清楚「這是表面症狀、還是根本原因、還是架構本來就搭錯」再動手。這樣下次那套設定就會自己提醒我。對我來說,這件事跟修好 bug 一樣重要。
跟 AI 除錯的五個步驟(SOP)
如果你也想這樣跟 AI 一起除錯,我這次的做法是這五步:
- 先搞懂,再動手 — 看不懂就先問到自己能用大白話講出來,別急著叫它修。
- 表面原因排一排,但先別花錢或搬家 — 升級、換平台這種大動作,通常不是第一步。
- 卡住就退一步問方向 — 別只問「怎麼讓錯誤消失」,問「這是不是治本?它本來該長怎樣?」
- 從對的那一層改 — 這次真正的問題在架構,就從架構改成靜態。
- 把教訓寫回規矩 — 這次踩的坑,記進你給 AI 的規則裡,下次它會自己提醒你。
如果你也遇到
我不是工程師,但這是我實際走一遍、真的有效的做法。網站從三不五時就壞,到現在連開二十次都穩;那套跟 AI 合作的規矩,也因為這次多學會一件事。
你會怎麼處理?或你也踩過類似的坑嗎?在下面留言跟我說吧!
留言
載入留言中…