我用 Codex 和 Hermes 做網站，才發現 AI 開發最難的是讓它動起來
整理版優先睇
AI開發最難係讓工作流落地，而唔係模型有幾聰明——用Codex同Hermes搭建網站嘅真實教訓
呢篇文章係作者自身經驗，佢想解決嘅問題唔係單純寫一個網頁，而係將網站開發過程拆成可以持續推進嘅AI工作流。佢用咗兩個工具：Codex（類似直接落項目做嘢嘅工程師，可以讀文件、改腳本、處理邏輯）同Hermes（類似本地AI工作台，有看板、任務、agent、模型配置）。佢想睇嚇呢兩個嘢放埋一齊，可唔可以令到AI從「傾想法」變成「自己推動到可用結果」。整體結論係：AI開發最難嘅唔係模型會唔會寫代碼，而係要處理真實環境嘅複雜性，將模型放入穩定嘅動作鏈入面。
過程中最大嘅教訓係低估咗Windows腳本嘅脆弱性。一個桌面bat腳本雙擊後閃退，表面睇係小問題，但背後暴露咗核心矛盾：AI好容易寫出「睇落啱」嘅腳本，但唔一定天然適配真實Windows終端嘅編碼、引號、括號、參數解析同PowerShell版本。作者做咗關鍵調整：bat只做最薄嘅啟動層，負責打開、傳參、停留窗口；複雜邏輯全部交畀PowerShell。呢個調整令流程從「能跑一次」變成「可以放心重複跑」。
呢套搭配令作者更確定：AI開發唔能夠只靠一個強模型。強模型負責關鍵判斷、架構同複雜修復，但仲需要工作台、看板、可重複執行嘅腳本同本地遠程交接。Hermes提供項目秩序，Codex提供執行能力，OpenClaw提供內容發佈鏈路，ai-gong skill則將日常AI使用變成文章素材。呢幾個嘢放埋一齊，形成咗一個閉環：做嘢 → AI記錄過程 → AI幫手覆盤 → AI寫成文章 …
- 結論：AI工作流嘅核心唔係模型能力，而係建立穩定可重複嘅動作鏈，將模型放入入面。
- 方法：用Hermes做項目秩序（看板、任務、agent），用Codex做執行層（讀文件、改腳本、修問題），分工明確。
- 差異：普通AI用法（聊天窗口畀建議）同真正落地（處理Windows編碼、路徑、腳本閃退等細節）之間存在巨大鴻溝。
- 啟發：AI開發需要「薄入口 + 厚執行」——bat只做啟動，複雜邏輯交畀PowerShell，隔離環境不穩定性。
- 可行動點：唔好追求一步到位，先將每一步變成可重複嘅小動作，畀AI清楚嘅入口、邊界同下一步。
問題：由「傾想法」到「執行動作」之間條路好長
作者今日想解決嘅，唔係單純寫一個網頁。如果只係叫AI生成代碼再手動改幾輪，其實好簡單。但佢真正想試嘅係：可唔可以將網站開發過程拆成一個可以持續推進嘅AI工作流。
呢度有兩個角色：Codex同Hermes。Codex似一個可以直接落項目做嘢嘅工程師，讀文件、改腳本、處理邏輯；Hermes似一個本地AI工作台，有看板、任務、agent同模型配置。
教訓：Windows腳本嘅脆弱性暴露咗工作流落地嘅核心矛盾
以前用AI，最常見係打開聊天窗口問「幫我做一個網站」、「呢個腳本點解報錯」。AI答到，但回答同完成之間隔住好長距離。尤其係本地電腦、遠程服務器、公眾號草稿箱、腳本參數、中文編碼、路徑避讓呢啲細節，事情會變得好髒。
今日最典型嘅小坑係桌面bat腳本閃退。表面睇係環境問題，但背後暴露咗核心矛盾：AI好容易寫出「睇落啱」嘅腳本，卻唔天然適配真實Windows終端嘅編碼、引號、括號、參數解析同PowerShell版本。尤其係中文路徑、中文提示、bat同PowerShell混用時，問題唔係一句「修復一下」就完。
- bat對括號、引號、中文、管道符嘅解析好敏感，一行普通判斷可能變成語法錯誤。
- PowerShell版本不同，對UTF-8文件嘅識別唔完全一樣，中文提示會搞壞腳本結構。
- 下層腳本喺交互模式輸出提示文字又輸出JSON，啟動器直接當JSON解析就失敗。
呢啲問題唔大，但會令用戶體驗直接崩潰。作者嘅體會係：AI工作流真正難嘅，唔係模型會唔會寫代碼，而係佢能唔能夠承認環境好複雜，而且一層一層隔離唔穩定因素。
解決方案：Hermes做項目秩序，Codex做執行層
作者今日採取嘅方式係：Hermes負責「工作台同項目視角」，Codex負責「具體執行同修復」。Hermes被視為本地AI項目指揮台，唔係單純替代ChatGPT，而係更適合沉澱項目結構——網站要做咩、有咩agent、誰負責需求、誰負責視覺、誰負責驗收、模型點分配、任務點入看板。
呢件事好重要。如果一個項目只有聊天窗口，所有上下文會混埋一齊。Hermes嘅價值唔在於答得幾靚，而在於將工作拆成可管理嘅狀態——任務喺看板排隊、被唔同agent接手、記錄踩坑、沉澱成操作手冊。
Codex呢邊當成執行層。例如今日要做本地寫稿入口，需求唔係「寫一篇文章」咁簡單，而係一連串動作：採集AI素材 → 生成帶主題、風格、字數、角度嘅文章模板 → 避免同一天同主題重複生成 → 桌面放雙擊入口 → 執行後輸出可複製嘅寫作指令 → 按需要推畀OpenClaw入草稿箱。
- 1 採集今日使用AI嘅素材。
- 2 生成帶主題、風格、字數、角度嘅文章模板。
- 3 避免同一天同主題生成同一個文件，防止覆蓋。
- 4 桌面放一個入口，可以直接雙擊。
- 5 執行完後，終端直接輸出一句可以複製俾Codex嘅寫作指令。
- 6 如果選擇立即推送，就將成稿交俾OpenClaw進入草稿箱。
呢啲嘢拆開唔複雜，但組合起嚟容易出錯，尤其係路徑、參數、編碼、歷史去重、遠程接收。作者今日就係等Codex將呢啲理論上嘅嘢改成真實可用嘅按鈕。
啟發：建立閉環，將AI放入穩定嘅動作鏈
今日呢套搭配令作者更確定一件事：AI開發唔能夠只靠一個強模型。強模型當然重要，用嚟做關鍵判斷、架構同複雜修復，但如果冇工作台、冇看板、冇可重複執行嘅腳本、冇本地遠程交接，最後都係停留喺「傾得好」。
Hermes提供項目秩序，Codex提供執行能力，OpenClaw提供內容發佈鏈路，ai-gong skill就將日常AI使用變成文章素材。呢幾個嘢放埋一齊，開始接近作者想要嘅狀態：AI唔只係回答問題，而係參與工作流。
今日呢篇嘅判斷點就係：AI工作流唔係將所有嘢交畀模型，而係將模型放入一個穩定嘅動作鏈入面。
對普通AI用戶而言，最容易踩嘅坑係一開始就追求「全自動」。應該先將每一步變成可重複嘅小動作，每一步唔大，但每一步都能用。唔好將AI當成萬能大腦，而要放入工作鏈條入面——可以係寫作者、工程師、項目秘書、覆盤員，前提係要畀佢清楚嘅入口、邊界同下一步。
我用 Codex 和 Hermes 做網站，才發現 AI 開發最難的是讓它動起來
蝦哥導讀今天我把 Codex 和 Hermes 放在一起用，嘗試把“和 AI 討論網站”變成“AI 真正推進網站”。過程裏最大的坑不是模型不聰明，而是每一步都要能落地、能檢查、能繼續。
我今天原本想解決什麼問題
我今天想解決的不是單純寫一個頁面。
如果只是讓 AI 寫一個網頁，其實很簡單：描述需求，讓它生成代碼，再手動改幾輪，基本都能出來。但我真正想試的是另一件事：能不能把一個網站開發過程，拆成一個可以持續推進的 AI 工作流。
這裏面有兩個角色。
一個是 Codex。它更像一個能直接進項目裏幹活的工程師，可以讀文件、改腳本、處理邏輯、修閃退、把本地和遠程流程接起來。
另一個是 Hermes。它更像一個本地 AI 工作台，有看板、有任務、有 agent、有模型配置，也能把一個項目拆成多個階段，而不是所有事情都堆在一個聊天窗口裏。
我想看的就是：這兩個東西放在一起，能不能從“我跟 AI 聊想法”，變成“我給一個目標，它自己推動到一個可用結果”。
這個目標聽起來很大，但今天落到的事情很具體：整理 Hermes 的網站開發知識庫和 12 個 agent 的工作流，讓 Codex 把本地腳本、桌面入口、流程串起來。
這不是一個炫技功能，而是我在試一種更接近真實工作的 AI 用法。
為什麼普通 AI 用法不夠
以前我用 AI，最常見的方式是打開一個聊天窗口，然後開始問：
“幫我做一個網站。”
“這個頁面怎麼設計？”
“這個腳本為什麼報錯？”
每個問題 AI 都能回答，但問題是，回答和完成之間隔着很長一段距離。
它給你一段代碼，你要自己放進去。
它給你一個流程，你要自己記住下一步。
它說“可以做成自動化”，但真正到了本地電腦、遠程服務器、公眾號草稿箱、模型切換、腳本參數、中文編碼、路徑避讓這些細節上，事情馬上會變得很髒。
今天最典型的一個小坑，就是桌面 bat 腳本閃退。
表面看，這是一個很小的問題。一個腳本雙擊後窗口一閃而過，普通人可能會覺得是不是電腦環境有問題，或者是不是模型寫錯了。
但它背後其實暴露了 AI 工作流落地的核心矛盾：AI 很容易寫出“看起來對”的腳本，卻不一定天然適配真實 Windows 終端裏的編碼、引號、括號、參數解析和 PowerShell 版本。
尤其是中文路徑、中文提示、bat 和 PowerShell 混用時，問題不是一句“修復一下”就結束的。你得知道哪裏應該交給 bat，哪裏應該交給 PowerShell，哪裏應該保留窗口，哪裏應該把複雜邏輯拆出去。
這就是普通 AI 用法不夠的地方。
聊天窗口能給建議，但項目需要動作。
建議是一次性的，動作是要能重複執行的。
我怎麼讓 AI 真正參與開發
我今天採取的方式，是讓 Hermes 負責“工作台和項目視角”，讓 Codex 負責“具體執行和修復”。
Hermes 這邊，我把它看成一個本地 AI 項目指揮台。它不是單純替代 ChatGPT，而是更適合沉澱項目結構：網站要做什麼、有哪些 agent、誰負責需求、誰負責視覺、誰負責驗收、模型怎麼分配、任務如何進入看板。
這件事很重要。
如果一個項目只有一個聊天窗口，所有上下文都會混在一起：今天講模型，明天講部署，後天講文章發佈，再過幾天又講網站設計。時間一長，人和 AI 都會亂。
所以 Hermes 的價值，不在於它回答得多漂亮，而在於它把工作拆成了可管理的狀態。任務可以在看板裏排隊，可以被不同 agent 接手，可以記錄踩坑，也可以沉澱成操作手冊。
Codex 這邊，我把它當成執行層。
比如我今天要做的是本地寫稿入口。需求不是“寫一篇文章”這麼簡單，而是一整串動作：
第一，採集我今天使用 AI 的素材。
第二，生成一個帶主題、風格、字數和角度的文章模板。
第三，避免同一天同主題生成同一個文件，防止覆蓋。
第四，桌面放一個入口，讓我能直接雙擊。
第五，執行完以後，終端直接輸出一句可以複製給 Codex 的寫作指令。
第六，如果我選擇立即推送，就把成稿交給 OpenClaw 進入草稿箱。
這些事情拆開看都不復雜，但組合起來就很容易出錯。尤其是路徑、參數、編碼、歷史去重、遠程接收這些細節，一個不穩，整個流程就會變成“理論上可用”。
我今天讓 Codex 做的，就是把這些理論上的東西改成真實可用的按鈕。
中間哪裏亂了
最亂的地方，是我一開始低估了 Windows 腳本的脆弱性。
我原本以為，一個 bat 入口就夠了。它負責接收參數，判斷是否立即推送，生成 JSON，再把文章路徑複製到剪貼板。
聽起來沒問題，但真正執行後就閃退。
這時候我發現，AI 寫腳本和人工寫腳本最大的區別是：AI 很容易把邏輯寫得完整，但真實環境會用很小的細節懲罰它。
比如 bat 對括號、引號、中文、管道符的解析非常敏感。你以為是一行普通判斷，實際在某些輸入下會直接變成語法錯誤。
再比如 PowerShell 版本不同，對 UTF-8 文件的識別也不完全一樣。腳本里出現中文提示，如果編碼處理不好，可能不是顯示亂碼這麼簡單，而是腳本結構都被讀壞。
還有一個更隱蔽的問題：下層腳本在交互模式裏會輸出提示文字，同時最後再輸出 JSON。啓動器如果直接把所有輸出都當 JSON 解析，就會失敗。
這些問題都不大，但它們會讓用戶體驗直接崩掉。
這也是我今天最大的感受：AI 工作流真正難的不是模型會不會寫代碼，而是它能不能承認環境很複雜，並且一層一層把不穩定因素隔離掉。
如果把所有邏輯都塞進一個 bat，最後一定會變成一個很難維護的入口。
所以我做了一個關鍵調整：bat 只做最薄的一層啓動，複雜邏輯全部交給 PowerShell。
bat 只負責打開、傳參、停留窗口。
PowerShell 負責參數解析、調用生成腳本、截取 JSON、複製提示詞。
這個調整很小，但它讓整個流程從“能跑一次”變成了“可以放心重複跑”。
Hermes 和 Codex 的搭配給我的啓發
今天這套搭配讓我更確定一件事：AI 開發不能只靠一個強模型。
強模型當然重要。我把更關鍵的判斷、架構、驗收和複雜修復交給更強的模型，是因為這些地方需要理解上下文，也需要判斷風險。
但如果只有強模型，沒有工作台，沒有看板，沒有可重複執行的腳本，沒有本地和遠程之間的交接，它最後還是會停留在“聊得很好”。
Hermes 提供的是項目秩序。
Codex 提供的是執行能力。
OpenClaw 提供的是內容發佈鏈路。
ai-gong 這個 skill 則把我的日常 AI 使用過程變成文章素材。
這幾個東西放在一起，才開始接近我想要的狀態：AI 不只是回答問題，而是參與我的工作流。
今天最有價值的不是我又多了一個腳本，而是這個腳本背後形成了一種閉環：
我做事。
AI 記錄過程。
AI 幫我覆盤。
AI 寫成文章。
OpenClaw 接住成稿。
我再從文章裏看到自己怎麼使用 AI。
這個閉環一旦跑起來，文章就不是憑空寫出來的，而是從真實工作里長出來的。
它不會像營銷稿，因為裏面有真實的失敗。
它也不會像流水賬，因為每次都要抽出一個判斷點。
今天這篇的判斷點就是：AI 工作流不是把所有東西都交給模型，而是把模型放進一個穩定的動作鏈裏。
這件事對普通 AI 用戶有什麼用
如果你也想用 AI 做項目，我覺得最容易踩的坑是：一開始就追求“全自動”。
你會希望 AI 一句話把網站做完，一句話把文章寫完，一句話把草稿發好。
但真實情況是，越想一步到位，越容易卡在小問題上。
更靠譜的做法，是先把每一步變成可以重複的小動作。
每一步都不大，但每一步都能用。
這才是普通人用 AI 最該學的地方。
不要把 AI 當成一個萬能大腦，而要把它放進你的工作鏈條裏。
它可以是一個寫作者，也可以是一個工程師，也可以是一個項目秘書，還可以是一個覆盤員。
但前提是，你要給它清楚的入口、邊界和下一步。
今天我用 Codex 和 Hermes 搭配開發網站，最後真正學到的不是某個工具有多強，而是：當 AI 開始有入口、有看板、有任務、有驗收、有草稿流轉，它才不再只是聊天窗口裏的聰明回答。
它開始變成一個能陪你把事情做完的系統。
