跳到主要內容

部落格

不定期分享最新資訊文章

  • article-【GPT-6 Astra 正在把 Vibe Coding,推向 Vibe World Building】

    2026/9/14

    AI工具 AI Agent Vibe Coding
    【GPT-6 Astra 正在把 Vibe Coding,推向 Vibe World Building】

    以前我們講 Vibe Coding,常見的想像是:「一句話,AI 幫我做網站、寫 App。」 但最近看到幾個 GPT-6 Astra 搭配 Unreal Engine、Blender 與 Three.js 的案例,我開始覺得,下一階段可能不只是 Vibe Coding,而是 Vibe World Building。 你不只是叫 AI 寫程式,而是讓 Agent 進入專業工具,協助建立角色、遊戲與可以互動的世界。更有意思的是:AI 越能操作專業軟體,我反而越覺得 Domain Knowledge 會變得更重要。 以下案例依照作者公開展示整理,重點是觀察工作方法,不代表每個人使用相同模型、方案與工具設定都能得到相同結果;實際能力也會隨版本、權限與專案環境變動。 AI 開始進入專業工具,而不只生成程式碼Vibe Coding 把「描述需求、產出程式」變得更容易;而這幾個 3D 案例再往前一步:Agent 開始操作 Unreal Engine、Blender 或 Three.js 專案,建立內容、反覆修改,並把場景、規則與互動組合在一起。 這個轉變不只是「AI 會不會 3D」,而是工作環境開始從人操作的軟體,變成 Agent 也能操作與檢查的執行環境。 案例一:從一個物件,走向逐街建構曼哈頓Matt Shumer 分享 GPT-6 Astra 在 Unreal Engine 中建構曼哈頓場景的過程,並描述它花了一週逐街完成細節。這已經不是只要求 AI「放一棟房子、加幾棵樹」,而是把工作尺度拉到街道與街區。 他也展示過另一個 Unreal Engine 世界:場景裡有以 Astra 驅動的角色 Agent,並以共同生存為目標互動。這讓「建構世界」不只包含空間,也開始包含世界中的行動者與互動規則。 當場景從單一物件擴大到街區,問題自然會延伸到道路與建築的空間關係、資產管理、場景分工與驗收方式。若要進一步投入正式製作,效能、碰撞、載入策略與可維護性仍需要另外檢查;一段令人驚豔的展示,不等於所有製作環節都已完成。 來源:Matt Shumer 的曼哈頓建構展示、Astra Agent 世界展示。 案例二:拓撲不一致,就改用離散 Mesh 切換角色表情常用 Blendshape 做平滑變化,但這類頂點形變通常仰賴相容的網格拓撲與頂點對應。若不同 AI 生成的表情 Mesh 拓撲不一致,就不一定能直接做傳統的平滑 Morph。 Nano 分享的 Blender 做法不是硬把所有網格變成同一種拓撲,而是換個解題方向:先把不同表情的 Mesh 對齊;切換時顯示目標表情,並把未啟用的 Mesh 縮小、藏進角色頭部,再透過 Blender Driver 控制切換。 這不是 Blendshape 的平滑融合,而是離散表情切換。它用明確的取捨避開拓撲限制,適合某些表情展示情境,卻不能因此宣稱能取代所有臉部動畫流程或提供連續的表情過渡。 我覺得這個案例特別值得看,不是因為 Astra 知道 Blender 哪個按鈕在哪裡,而是 Nano 知道問題來自哪裡,並知道還有哪些方法可以繞過去。 來源:Nano 在 Blender 中切換角色表情的展示與提示詞。 案例三:一款跑酷遊戲背後,是一整套產品規則MSB 使用 GPT-6 Astra 搭配 Three.js 分享豎屏跑酷遊戲《THE LAST GATE》。看起來是讓角色往前跑,拆開需求後卻是一組完整的遊戲系統: 玩家通過加減乘除算術門時,隊伍人數會即時改變。 撞上障礙物會造成實際隊員損失,而且畫面人數要和遊戲中的真實人數一致。 終點遭遇會依最後存活的隊員人數決定。 需求包含三條短路線、即時重試,以及帶 Seed 的輸入回放。 這已經不是「幫我做一個 Three.js Demo」,而是把玩法規則、3D 場景、互動、狀態變化與可重現測試一起交給 Agent 處理。作品是否能投入正式產品,仍要再驗收效能、操控手感與程式維護性;但需求本身已經從一句畫面描述,長成可檢查的產品規格。 來源:MSB 的《THE LAST GATE》公開貼文。 三個案例,代表三種建構尺度 尺度 案例 真正要處理的問題 世界級 Unreal Engine 曼哈頓與 Agent 世界 空間關係、場景組織、資產與行動者 角色級 Blender 離散表情切換 拓撲限制、替代方案與表情控制 產品級 Three.js《THE LAST GATE》 遊戲規則、互動狀態、重試與回放 我看到的不是「GPT-6 Astra 很會 3D」而已,而是 AI 開始透過專業工具,把世界、角色與產品的不同層次串起來。 AI 越會操作軟體,Domain Knowledge 為什麼越重要?很多人看到 AI 越來越會用 Blender,第一個反應可能是:「那以後是不是不用學 Blender 了?」 我反而覺得,答案可能剛好相反。 真正厲害的不是 Agent 知道哪個按鈕在哪裡,而是有人知道問題為什麼發生、有哪些限制、什麼 workaround 可行,以及最後怎樣才算完成。 如果你知道 Blendshape、Topology、Mesh、Driver 是什麼,才比較可能看出表情網格不相容的原因,並想到可以改用離散切換。若連問題的語言都不熟悉,就很難把這種解法交代給 Agent,也不容易判斷結果有沒有真的做到。 所以 AI 淘汰的可能不是「懂 Blender 的人」,而是只知道 Blender 按鈕在哪裡、卻說不清楚問題與完成標準的人。 以前你懂 Blender,還得親手操作每一步;懂遊戲設計,也可能得等工程師把規則寫出來。Agent 改變的是專業知識的產能:你可以把問題、限制、不要採用的方法、可行的 workaround 與驗收標準交給 Agent,再由專業工具把它落地。 Domain Knowledge × Agent × Professional Tools 專業知識負責判斷,Agent 負責執行,專業工具負責把想法變成可以檢查與迭代的成果。 如果你想延伸看「如何把領域經驗交給 AI 軟體化」,可以讀我之前寫的把專業知識變成軟體;關於 Vibe Coding 如何改變軟體價值,也可參考專業知識與 Vibe Coding 的商業機會。 Vibe Coding 的下一階段,可能是 Vibe Anything以前學 Photoshop、Blender 或 Unreal Engine,常常代表自己要親手完成大量操作。未來你或許不必逐一操作每個按鈕,但仍需要理解這個領域有哪些物件與規則、問題通常出在哪裡、有哪些解法,以及如何驗收。 Vibe Coding 可能只是第一站。接下來還會有 Vibe 3D、Vibe Game Development、Vibe Animation,甚至 Vibe Engineering 與 Vibe World Building。關鍵不是「每套軟體的按鈕都記熟了沒」,而是當 AI 已經能操作工具時,你知不知道該交代什麼、該限制什麼,又該如何判斷它做得對不對。 常見問答 (FAQ)Q1:Vibe World Building 和 Vibe Coding 有什麼不同?Vibe Coding 通常聚焦於用自然語言描述需求、讓 AI 產生或修改程式;Vibe World Building 則把 Agent 帶進 Unreal Engine、Blender、Three.js 等專業環境,處理場景、角色、規則與互動,目標尺度從一段程式碼擴大到可探索或可玩的世界。 Q2:為什麼 AI 越會操作 Blender,專業知識反而越重要?專業知識能幫你定義問題、提供限制、選擇 workaround,並訂出驗收標準。Agent 可以執行很多操作,但仍需要有人判斷網格、表情或動畫是否符合實際用途。 Q3:不同拓撲的表情 Mesh 可以直接做平滑 Blendshape 嗎?不一定。傳統 Blendshape 的頂點形變需要相容的網格與頂點對應;若拓撲不同,可能要先整理網格,或採用像案例中的離散 Mesh 切換。離散切換不等於平滑表情融合,也不是適用所有角色動畫的通用替代方案。 Q4:AI 做出的 3D 遊戲展示,就等於可以正式上線嗎?不等於。除了畫面與主要玩法,仍要測試效能、操控、錯誤狀態、裝置相容性與後續維護。案例呈現的是 Agent 能協助建構與實作的範圍,正式產品仍需要明確的驗收與測試。 Q5:想開始用 Agent 建立 3D 或遊戲專案,最先要準備什麼?先把目標拆成可檢查的規則:有哪些物件、它們如何互動、哪些限制不能違反,以及怎樣算完成。從小範圍任務開始,讓 Agent 執行後再用專業知識檢查結果,會比只要求「做得漂亮」更容易迭代。

  • article-【AI 會寫 API 還不夠:Vibe Coding 下一個機會,是把台灣產業經驗做成 Skill】

    2026/9/14

    商業策略 AI Agent Vibe Coding
    【AI 會寫 API 還不夠:Vibe Coding 下一個機會,是把台灣產業經驗做成 Skill】

    最近看到一個很有意思的開源專案:ecommerce-cia。 它不是另一套電商系統,也不是幫你做購物車,而是一套專門給 AI Coding Agent 使用的「台灣電商 Skill」。 看到這個專案,我第一個想到的是:Vibe Coding 發展到現在,真正的瓶頸可能已經慢慢從「AI 會不會寫程式」,轉移到「AI 懂不懂這個產業」。 因為現在要 AI 幫你寫一個購物車,其實已經不難。商品頁、購物車、會員、訂單後台,甚至串 API,AI 都可以很快幫你生出來。 真正痛苦的是後面。 「我要接綠界。」「我要用藍新。」「LINE Pay 怎麼串?」「7-11 取貨付款怎麼做?」「ATM 付款超過三天沒付,訂單怎麼辦?」 然後你會發現一個很有趣的狀況:Coding Review 沒有 Error,API 文件也看了,每一段程式碼單獨看,好像都沒有問題。 但真的把整間商店跑起來,就是不順。😂 最麻煩的 Bug,可能發生在兩個正確的 Function 之間一般我們叫 AI Review 金流,很容易只檢查幾個局部問題: API 呼叫對不對? 簽章對不對? Callback Route 有沒有建立? 資料庫有沒有寫入? 庫存 Function 有沒有執行? 每一個地方都可能是對的,但問題可能發生在兩個「正確的 Function」中間。 以一筆交易為例,流程可能像這樣: 客人建立訂單。 系統保留庫存。 客人前往金流服務付款。 金流通知商店付款結果。 系統驗證通知並更新訂單狀態。 庫存、顧客通知與出貨流程依照訂單狀態接續處理。 如果 Callback 重送兩次呢?客人付款成功,但瀏覽器沒有跳回網站呢?ATM 建立虛擬帳號後幾天都沒有付款,庫存要什麼時候釋出?如果付款成功但庫存更新失敗,或訂單取消時付款通知剛好進來,系統又該怎麼辦? 這些才是真正把電商系統跑起來後,會遇到的問題。 所以 Review 金流不該只逐個看 Function,而要沿著「錢」和「貨」走過完整流程:下單、訂單、庫存、金流、Callback 驗證、狀態更新、出貨,到交易完成,逐段找可能的斷點。 ecommerce-cia 示範了另一種 AI 稽核方式ecommerce-cia 不是另一套購物車或電商平台,而是給 AI Coding Agent 使用的台灣電商 Skill。它有意思的地方,在於把注意力放到金流、庫存、訂單等環節如何互相影響。 依照專案 README 的說明,它有檢查既有交易流程的 Audit Mode,也有引導新手準備與串接金流的 Setup Mode;文件提到藍新、綠界、PAYUNi、TapPay 與 LINE Pay 等台灣常見情境。這些內容呈現了一個值得參考的方向:除了問 AI「這段程式碼有沒有寫錯」,也可以要求它沿著整條交易生命週期檢查系統行為。 這已經不只是一般的 Coding Skill,而是把產業流程和判斷方式整理成可重複使用的 Domain Engineering Skill。 AI 會看 API 文件,稀缺的是踩過坑的經驗這件事讓我想到我之前一直在談的「把專業知識軟體化」。 假設一個台灣電商工程師做了十年。他真正值錢的可能不是「我知道怎麼呼叫綠界 API」,因為這件事情 AI 看文件就能協助。 真正值錢的,是這些踩過坑才知道的事: 綠界或藍新的 Callback 曾經出過什麼狀況。 ATM 訂單逾期後,何時釋放庫存才符合商業規則。 超商取貨付款訂單的狀態該怎麼轉換。 使用者付款成功但沒有跳回網站,不能因此就判定付款失敗。 Webhook 重送不能重複扣庫存或重複通知。 退款、取消與付款通知同時發生時,訂單狀態要如何處理。 這些東西通常不會完整寫在 API 文件裡。它們存在工程師的腦袋裡,來自踩坑、Debug、客訴、事故,以及凌晨三點修 Production 的經驗。😂 API 文件能說明端點、欄位和簽章方式;把這些技術細節放進真實商業情境後,流程上的例外與判斷往往還要靠產業經驗補足。 專業知識除了軟體化,也可以 Skill 化以前我們會想:我做了十年房仲,可不可以把我的判斷方法做成一套房仲 SaaS?我做了十年行銷,可不可以把我的 SOP 做成一套行銷系統? 我之前也寫過把專業知識變成軟體,讓產業專家成為下一代產品經理。現在可能又多了一條路:不一定要先做 SaaS,也可以先把專業知識整理成 Skill。 從產業經驗到 AI 可執行 Skill 的概念示意。 一個資深電商工程師的經驗,如果要整理成 AI 能使用的 Skill,可以從常見情境開始,逐步寫清楚: 什麼情況下要啟動檢查。 要沿著哪些訂單、金流和庫存流程追蹤。 哪些例外狀況需要特別確認。 要用什麼證據判斷流程真的完成,而不是只看單一測試顯示綠燈。 如此一來,AI 就不只是「會寫程式」,還能重複參照一套做過許多台灣電商專案的人累積的判斷方式。 下一波 Vibe Coding 機會,可能是台灣產業 Domain Skills未來 Skill 最有價值的地方,不一定是 React Skill、Next.js Skill 或 Python Skill。這些通用技術知識,模型本身會越來越強。 更可能形成差異化的,是懂得台灣產業實際怎麼運作的 Domain Skills,例如: 台灣電商金流與物流。 台灣電子發票、統編與發票規則。 LINE 官方帳號與會員流程。 政府 Open Data 與台灣個資保護情境。 房仲成交流程、補教招生、餐飲訂位、美容預約與傳統產業報價。 這些領域的共同點是:模型可能知道技術,但不一定知道台灣的商業流程、例外情境與在地作法。而真正掌握這些 Know-how 的人,往往是已經在產業裡工作十年、二十年的實務工作者。 Skill 不只是提示詞,而是可以交給 Agent 使用的 SOP我現在看 Skill,已經不只把它當成「提示詞」,而是可以被 AI Agent 使用的產業 SOP。 以前經驗存在腦袋裡,後來我們把它寫成 SOP,再把 SOP 做成軟體。現在又多了一種形式:把 SOP 整理成 AI Agent 能參照與執行的 Skill。 Vibe Coding 的競爭,可能不只是誰比較會下 Prompt、誰比較會用 Claude Code 或 Codex,而是誰能把自己十年、二十年的產業經驗,整理成 AI 可以重複使用的能力。 模型會越來越強,寫程式會越來越便宜,API 串接也會越來越簡單。但有一件事情不會因此自動出現:你踩過的那些坑。 而那些坑,可能才是 AI 時代真正值得被「程式化」的專業知識。 這也是我看到 ecommerce-cia 之後,覺得最值得研究的地方。它表面上是在處理台灣電商金流、物流與流程稽核,背後示範的也許是一個更大的方向:下一波 Vibe Coding,不只是讓 AI 幫我們寫軟體,而是開始把一個產業真正的 Know-how,寫進 AI 裡。 常見問答 (FAQ)Q1:什麼是台灣產業 Domain Skill?台灣產業 Domain Skill 是把在地產業常見的情境、判斷方式、執行流程與例外處理整理成 AI Agent 可重複參照的規範。它能補足通用技術知識與實際商業流程之間的落差。 Q2:Domain Skill 和一般 Code Review 有什麼不同?一般 Code Review 多半檢查程式碼或單一 Function 的正確性;Domain Skill 可以引導 AI 沿著跨系統流程檢查狀態如何傳遞,例如金流通知、訂單更新、庫存處理與出貨。兩者處理的問題不同,實務上可以搭配使用。 Q3:如何把產業經驗整理成 AI Agent Skill?先整理常見情境與踩坑案例,再把觸發條件、判斷方式、處理步驟、例外狀況與驗證證據寫清楚,最後交由熟悉該產業的人用真實案例檢查。這樣的 Skill 才能承載可重複使用的專業判斷,而不只是一段泛用提示詞。

  • article-【ChatGPT Sites 真正適合的角色,不是正式網站,而是產品驗證層】

    2026/9/12

    Vibe Coding ChatGPT Cloudflare
    【ChatGPT Sites 真正適合的角色,不是正式網站,而是產品驗證層】

    最近看到 ChatGPT Sites 上線三個月後,使用者已建立超過 500 萬個 Sites。OpenAI 在 2026 年 9 月 11 日的更新中,也提到團隊協作、私密分享、資料庫檢視、自訂網域,以及從提示到部署速度提升等功能。官方公告 這些更新很容易讓人想到另一個問題:ChatGPT Sites 是不是準備和 Wix、Webflow、Vercel 競爭? 我反而覺得,它最有價值的角色不是取代傳統網站平台,而是成為 AI 時代的產品驗證層。 先釐清兩件事:500 萬是 OpenAI 公布的 Sites 建立數,不能直接當成活躍使用者、持續使用的產品或市場需求已驗證的證據;「產品驗證層」則是我對 Sites 的定位,不是官方替產品命名的功能。Sites 不會自動替你驗證需求,它的價值是讓你更快做出可以交給使用者試用的版本。 以前做 MVP,程式碼還沒開始就得先準備一大堆事以前有個產品想法,就算只做 MVP,也可能先卡在一串工程工作: 選 Framework、建立 GitHub Repository。 設定 Cloudflare 或 Vercel、決定資料庫與 Auth。 管理環境變數、串接 API、建立 Admin。 準備部署、測試與後續維護。 等到真的能交給使用者操作,往往已投入不少時間。最可惜的是,忙完才發現沒有人需要它。 最大的浪費不一定是選錯 Framework,而是還沒確認問題是否存在,就先為一個未驗證的想法付出正式工程成本。 Sites 把「做出一個可操作版本」提前了用 Sites,可以先用自然語言描述想解決的問題,再透過對話調整畫面、互動與資料。驗證流程因此可以縮短成: 123456789想法 ↓描述需求、產生介面 ↓加入互動與必要資料 ↓交給目標使用者試用 ↓依回饋修改,或決定停止 你不必一開始就決定要用 React 還是 Next.js,也不用先把整套正式環境建好。先讓某個人能完成一件具體的事,再觀察這個流程是否真的有用。 不過,Sites 裡的「部署」不等於隔離的測試環境。OpenAI 文件說明,每個部署網址都是 production URL;若要先檢視變更,可以先儲存版本,確認後再部署。因此,拿給使用者試用前,也要確認分享對象、存取權限與資料內容。ChatGPT Sites 使用說明 Sites 適合承載 Prototype 與早期 MVP你提供的展示圖裡,有像素寵物遊戲、3D 模型上色工具和計算機。這些作品的重點不只是資訊展示,而是有人可以打開頁面後實際操作的小型 Web App。 因此,Sites 可以用來測試不少概念: 簡易 CRM、活動管理系統或 Dashboard。 計算工具、預約流程或測驗系統。 客戶 Portal、內部資訊站或 AI 小工具。 Micro SaaS 的第一版核心流程。 這些用途仍要看產品需求是否符合 Sites 支援的執行環境。Sites 目前處於 Beta,使用額度會依方案或工作區而異;部分框架、資料庫、私有網路與背景服務可能不受支援,也不提供資料所在地或推論所在地保證。OpenAI Sites 開發文件 驗證時也不要只問自己「我覺得好不好用」。把版本交給目標使用者,觀察他能不能完成核心任務、是否願意再用一次,以及這個問題是否值得投入下一階段。 Sites 目前不是一鍵匯出到 GitHub這一點值得說清楚。目前公開的 Sites 文件描述了從提示開始建立,也能將相容的既有本機專案交給 Sites 建置與部署;本機來源專案的版本也可以連結到建置時使用的 Git commit。但文件沒有描述把已建立的 Sites 一鍵匯出成 GitHub Repository 的操作流程。 所以我不會把它想成「按一下 Export、整個專案進 GitHub,再按一下就搬到 Cloudflare」。比較務實的做法,是把 Sites 當成已驗證的產品規格、UI Reference 與功能 Prototype。需求成熟後,再請 ChatGPT 或 Codex 根據使用情境、畫面、資料結構與流程,重建正式版本。 這也是我偏好 Productionize 而不是 Migration 的原因:Migration 聽起來像把原始程式碼原封不動搬出去;Productionize 則是保留被驗證過的產品設計,再用合適的正式架構重新實作。 你提供的資訊圖整理了這段思路。它呈現的是產品驗證到工程化的概念流程,不代表 Sites 內建一鍵匯出,或能自動把整套產品搬到 Cloudflare。 從 Idea 到 Production,可以拆成九個階段 Idea:描述想解決的問題,以及現在是誰、在什麼情境下遇到它。 Sites Prototype:快速做出可以點、可以玩的原型,先呈現核心使用流程。 MVP:加入驗證核心任務所需的表單、資料、Dashboard、Admin 或 AI 功能。 Validation:交給真正的目標使用者測試,記錄他們是否完成任務、在哪裡卡住,以及是否願意再使用。 Freeze Spec:整理並凍結 UI、User Flow、Database Schema、Business Logic、API、權限與已驗證的需求。 Codex Productionize:由 Codex 根據已驗證的規格重建正式專案,補上工程結構與必要檢查。 GitHub:從這一步開始,讓 GitHub 成為正式程式碼的 Source of Truth,管理版本、審查與自動化流程。 Cloudflare:依產品需要選擇 Workers、D1、R2、KV、Queues、Durable Objects 或 Cron Triggers;這些是可組合的 Cloudflare 平台服務,不代表每個 Site 都會用到它們。Cloudflare Workers 文件 Production:補上 Authentication、RBAC、Rate Limit、Logging、Monitoring、Backup、Analytics、CI/CD,以及 Dev、Staging、Production 等環境。 如果你想看 Vibe Coding 如何落在一個真實系統,也可以延伸閱讀打造線上報價單與電子簽署系統的實作經驗。 搬到 Cloudflare 後,控制權增加,工程責任也回到自己身上當正式版本改由自己維護,就能依需求決定資料庫、Auth、AI 模型、檔案儲存、Log 保存方式、排程、Queue、Rate Limit 與備份策略。這些自由度比只使用受支援的 Sites Runtime 大得多,但每個選擇也會變成需要設計、驗證與維護的工程責任。 更精確地說,離開 Sites 後,消失的是 Sites 本身的限制,不是所有平台限制。Cloudflare 各服務仍有不同的適用情境與操作邊界;你需要根據資料量、流量、權限、可靠性與維護能力選擇組合,而不是把 Workers、D1、R2、KV、Queues、Durable Objects 和 Cron 全部加進第一版。 如果一開始就把所有正式產品要求塞進 Prototype,反而會失去 Sites 最有價值的速度。先確認有人需要、真的會用,再判斷這個產品值不值得工程化。 ChatGPT Sites 是 Production 前的產品驗證層我會把 ChatGPT Sites 定位為產品孵化器,而不是正式產品架構的終點。先快速做、快速改、快速測,也可以在發現沒人需要時及早停下;等到核心流程被驗證,再把規格交給 Codex、GitHub 與 Cloudflare,用正式工程方式重建。 我現在會把這套 Vibe Coding 流程整理成: Sites → MVP → Validate → Codex → GitHub → Cloudflare → Production 以前 AI 幫我們解決的是「怎麼更快寫程式」;現在它也開始降低另一種成本:怎麼更便宜地知道,這個程式到底值不值得寫。 常見問答(FAQ)Q1:ChatGPT Sites 可以取代 Wix、Webflow 或 Vercel 嗎?這篇文章的定位不是比較平台功能,而是建議先把 Sites 用在 Prototype 與早期 MVP 驗證。當產品需求、資料與維運責任逐漸明確,再決定正式網站或系統要採用什麼架構與平台。 Q2:OpenAI 說建立了 500 萬個 Sites,代表有 500 萬個活躍使用者嗎?不代表。OpenAI 公布的是 Sites 建立數,不是活躍使用者數、留存率或付費需求。它能反映建立行為的規模,不能單獨證明這些產品有人持續使用。 Q3:ChatGPT Sites 可以直接匯出成 GitHub 專案嗎?目前公開文件沒有描述從已建立的 Site 一鍵匯出至 GitHub 的流程。文件有說明 Sites 可從提示或相容的本機專案開始,因此要區分「把本機專案部署到 Sites」和「把 Site 專案匯出到 GitHub」這兩件事。 Q4:Sites 部署網址是測試站還是正式站?OpenAI 文件將每個部署網址視為 production URL。你可以先儲存版本供檢視,再決定是否部署;分享給使用者前,也要確認權限、資料和預期使用對象。 Q5:把產品重建到 Cloudflare 後,平台限制就消失了嗎?Sites Runtime 的限制不會原封不動跟著搬過去,但 Cloudflare 服務有各自的功能範圍與操作邊界。正式版本也需要你負責 Auth、權限、監控、備份、資料保護與維運。 參考資料 OpenAI:ChatGPT Sites 功能更新與建立數 OpenAI Help Center:建立與管理 ChatGPT Sites OpenAI:ChatGPT Sites 開發文件 Cloudflare:Workers 文件

  • article-全民修仙時代來了:AI 給每個普通人一個重新選擇靈根的機會

    2026/9/10

    AI自動化 AI Agent Vibe Coding
    全民修仙時代來了:AI 給每個普通人一個重新選擇靈根的機會

    最近看到一篇分析修仙小說的文章,裡面有個觀點讓我想了很久。 為什麼這幾年修仙小說這麼紅? 因為修仙小說賣的可能從來都不是「成仙」。 它真正賣的,是一套普通人的生存想像: 你可能沒有背景、沒有資源,甚至連靈根都很差。 但只要肯學、肯熬、找到自己的功法,再加上一點機緣,人生就還有翻盤的可能。 看到這裡,我突然發現: 這跟現在的 AI 時代,實在太像了。 以前沒有靈根,很多事情你連門都進不去以前想做一個網站,你最好會寫程式。 想做漂亮的廣告,你要懂設計。 想拍影片,你要懂腳本、攝影、剪輯。 想做音樂,你最好懂一點樂理。 想成立一家公司,你還需要行銷、業務、客服、行政等不同專業的人。 這就像傳統修仙世界。 你沒有火靈根,人家告訴你別學煉丹。 你沒有劍道天賦,就不要妄想成為劍修。 你的「出生能力值」,很大程度決定了你能做什麼。 但 AI 出現之後,一件很有趣的事情發生了: 雜靈根,也可以修仙了。 不會寫程式,可以 Vibe Coding。 不會畫圖,可以 AI 生圖。 不會剪影片,可以 AI 剪輯。 不會作曲,可以生成音樂。 不懂自動化,可以跟 AI 一起建立 Workflow。 一個普通人第一次可以用非常低的成本,同時碰觸過去需要很多年才能跨入的專業領域。 AI 並沒有讓所有人突然變成天才。 它只是讓大量原本沒有「靈根」的人,第一次拿到了進入仙門的門票。 ChatGPT 是法寶,Prompt 是符籙,Workflow 是陣法如果真的把 AI 時代翻譯成修仙世界,其實非常有趣: AI 時代 修仙世界 ChatGPT、Claude、Gemini、Codex 法寶 Prompt 符籙 Skills 功法 Token、算力與訂閱費 靈石 GitHub、YouTube 與網路知識庫 藏經閣 新模型、新平台與新技術 突然開啟的秘境 Vibe Coding 煉器 AI 內容製作 煉丹 n8n 與各種 Workflow 陣法 Agent 靈獸、傀儡,甚至是分身 這裡的工具名稱與能力會隨版本、方案和使用情境變動,所以重點不在於替某個法寶排出永久排名,而在於理解自己想解決什麼問題。 這時候再回頭看現在很多人在問的問題: 到底要學哪一個 AI? 其實就很像一個剛進仙門的弟子,每天跑去問: 師兄,哪一把劍最強? 問題可能一開始就問錯了。 真正重要的從來不是哪把劍最強,而是: 你到底修什麼道? 你想解決誰的問題? 你能不能把法寶組合成自己的方法? 如果想把這條路拉回實作,可以先從 非工程背景也能開始的 Vibe Coding 開始,再把經驗整理成 Prompt 到 Skill 的工作流。 當所有人都有法寶,法寶就不值錢了2023 年,你會使用 ChatGPT,可能還算是一種優勢。 到了今天,如果你告訴別人: 我會用 AI。 其實已經跟修仙者說: 我有一把飛劍。 差不多。 因為大家都有。 當法寶變成標準配備,真正產生差距的,就不再是「有沒有法寶」,而是: 你會不會使用? 你修的是什麼功法? 你能不能把不同法寶組合起來? 你有沒有自己的陣法? 最後能不能形成一套自己的戰鬥體系? 所以我最近越來越覺得,AI 能力其實也有自己的修仙境界。 AI 能力也有自己的修仙境界 境界 AI 能力 具體轉變 煉氣 會問 AI 開始把 AI 當成日常協作工具 築基 會寫 Prompt 能把需求與上下文說清楚 金丹 建立自己的 Workflow 把重複工作整理成穩定流程 元嬰 開始建立 Agent 讓 AI 代替自己執行一段任務 化神 讓多個 Agent 協作 組織 AI 團隊,打造自動化體系 煉虛 把專業知識封裝成 AI 系統 讓經驗變成可以重複使用的能力 合體 人的判斷與 AI 工作流程融合 人機協作成為日常工作方式 大乘 駕馭過去一家公司才有的生產力 一個人也能調度多種專業能力 渡劫 持續面對模型與環境變化 幾乎每隔一段時間就要重新適應天地靈氣 然後呢? 渡劫。 而且 AI 世界的天劫,可能每隔幾個月就來一次。 最可怕的是:你好不容易築基,全世界突然都築基了這大概是 AI 時代最殘酷,也最有趣的地方。 你花半年學會的能力,下一代模型可能直接內建。 以前很會寫 Prompt,是競爭力。 模型變聰明之後,Prompt 的門檻開始下降。 以前 AI 生圖需要研究一大堆參數,後來一句自然語言就能完成。 以前 Vibe Coding 已經讓不會寫程式的人可以做網站。 接下來 Agent 可能連需求分析、寫程式、測試、除錯、部署都自己完成。 你昨天還覺得自己終於築基成功。 一覺醒來: 天地靈氣復甦,全民築基。 所以 AI 時代真正危險的事情,不是不學新工具。 而是把某一個暫時稀缺的操作技能,誤認成自己長期的護城河。 所以 AI 時代反而更需要「修心」這也是我覺得修仙小說最有趣的地方。 修仙小說寫到最後,真正決定一個人能走多遠的,往往不是靈根,也不是手上的法寶。 而是「心性」。 因為法寶可以撿。 功法可以學。 丹藥可以買。 唯有道心,要自己修。 放到 AI 時代也是一樣。 當工具越來越強、取得成本越來越低,最後真正拉開人與人差距的,反而會重新回到一些看起來很「老派」的東西: 判斷力 審美 經驗 信用 選擇 持續學習 解決問題的能力 在還看不到成果的時候,持續累積的能力 這些東西,AI 很難直接送給你。 AI 時代,每個人都要選自己的「修仙百藝」修仙小說裡有煉丹、煉器、符籙、陣法、靈植。 不一定每個人都要成為最強劍修。 只要找到一門市場需要的能力,把它練深,一樣可以換到靈石、累積資源,甚至建立自己的勢力。 AI 時代也是如此。 有人修 AI 影片。 有人修 Vibe Coding。 有人修自動化。 有人修 Agent。 有人修 AI 行銷。 有人修 AI 教學。 有人修內容與個人品牌。 你不需要全部精通。 真正重要的是: 找到一條可以跟自己原本專業結合的「道」,然後持續修下去。 因為真正能賺錢的人,未必是每天知道最多新模型的人。 而是能把其中一門能力,修到真的可以解決別人的問題。 如果你想把「一個人駕馭多種能力」落地,也可以延伸閱讀 零人公司:不是沒人,而是沒有當下做決策的人。 AI 最大的機會,不是讓強者變得更強當然,有錢、有資源、有技術背景的人,使用 AI 一樣有巨大優勢。 世家依然是世家。 大宗門依然有更多靈石、更多算力、更多人才。 AI 並沒有突然讓世界變公平。 但它帶來了一個很重要的改變: 普通人可以用更低的成本,獲得以前根本碰不到的能力。 一個人可以寫程式。 可以做設計。 可以剪影片。 可以做行銷。 可以建立自動化。 甚至可以開始指揮一群 AI Agent 工作。 這才是我認為 AI 真正有趣的地方。 它不是讓每個人站在同一條起跑線,而是讓原本連比賽資格都沒有的人,突然拿到了一張入場券。 真正的「飛升」,可能不是更會用 AI所以如果真的要替 AI 修仙設計最後一個境界,我反而覺得不是: 我可以同時操作十個 AI。 真正的飛升應該是: 你已經不再親自操作每一個 AI,而是在設計 AI 如何工作。 你把自己的經驗變成方法。 把方法變成 Prompt。 把 Prompt 變成 Skill。 把 Skill 變成 Workflow。 把 Workflow 交給 Agent。 最後把 Agent 組成一套可以持續運作的系統。 到那個時候,你真正放大的就不是「AI 的能力」,而是你自己累積二十年的能力。 所以我現在越來越相信: AI 時代真正值得修的,從來不是 ChatGPT、Claude、Gemini 或哪一個模型。 那些都只是法寶。 真正值得修的是自己的「道」。 以前比的是誰有天賦。 後來比的是誰有工具。 當人人都有 AI,最後比的,可能又會回到誰的道更深。 AI 沒有保證普通人一定可以翻身,就像拿到一本功法,也不代表一定能飛升。 但是它至少讓這個時代多了一種可能: 沒有背景、沒有團隊、沒有頂級天賦的普通人,也能開始修仙。 現實世界沒有系統提示。 努力也不一定會顯示: 恭喜你,經驗值 +100。 但如果 AI 真的是這個時代突然出現的一場「靈氣復甦」,那麼現在真正值得問的,可能已經不是: 哪一個 AI 最強? 而是: 你的道,準備怎麼修? 常見問答 (FAQ)Q1:AI 真的能讓每個普通人都變成專業者嗎?不能。AI 主要降低的是專業領域的入場門檻,讓普通人更容易開始嘗試與製作;真正能走得長久,仍然需要判斷力、經驗、審美、信用與持續解決問題的能力。 Q2:AI 時代到底該先學哪一個工具?先從自己想解決的問題與想修的方向開始,再選擇適合的工具。ChatGPT、Claude、Gemini、Codex 或其他模型都只是法寶,工具能力也會隨版本、方案與使用情境變動。 Q3:不會寫程式的人可以從哪裡開始學 AI?可以先從能立即驗證成果的任務開始,例如用 AI 協助寫內容、做設計、剪影片、建立簡單 Workflow,或嘗試 Vibe Coding。重點不是一次學會所有工具,而是把一次任務逐步整理成可重複的方法。 Q4:如何把 AI 能力變成長期競爭力?把自己的專業經驗整理成方法,再依序沉澱成 Prompt、Skill、Workflow 與 Agent;當這些工具和你的領域知識、判斷力及信用結合,才比較可能形成不容易被下一代模型取代的工作系統。

  • article-【342 個免費 3D Prompt,我看到的不是提示詞資料庫,而是 3D Vibe Coding 正在成形】

    2026/9/10

    AI工具 AI Agent Vibe Coding
    【342 個免費 3D Prompt,我看到的不是提示詞資料庫,而是 3D Vibe Coding 正在成形】

    最近發現一個滿值得收藏的網站:Tripo 3D Prompts。 它整理了超過 300 個免費的 AI 3D Prompt 與實際案例,內容涵蓋 Three.js、Blender、WebGPU、Browser Game、角色建模、3D 世界與各種互動效果。 資料註記:2026 年 9 月 10 日查閱時,官方頁面顯示 342 個案例,數量會持續更新。網站會區分作者公開的原始 Prompt,以及依公開作品整理的任務描述;使用時可以先查看個別案例的來源標示。 如果只是把它當成「Prompt 大全」,其實有點可惜。 因為我看了一輪之後,真正讓我感興趣的不是這 300 多條 Prompt,而是: 3D Vibe Coding 的方法論,好像已經慢慢成形了。 以前 Vibe Coding 做網站,現在開始「做世界」這一兩年大家講 Vibe Coding,最常看到的還是: 「幫我做一個官網。」 「幫我做一個管理後台。」 「幫我做一個 SaaS。」 「幫我做一個小工具。」 本質上,大部分還是 2D Web UI。 但 Tripo 3D Prompts 裡面,已經開始出現很多完全不同的東西。 例如 Three.js 3D 遊戲、卡丁車競速、飛行模擬器、第三人稱射擊遊戲、3D 解謎、互動式中國庭院、梵谷畫作 3D 世界、WebGPU Soft Body、Blender 建模與動畫…… 甚至可以拿一張圖片或一段影片當參考,要求 AI 重建成可以互動的 Three.js 3D 場景。官方就收錄了依參考影片重建 Three.js 場景的案例,呈現這種從視覺參考出發的需求描述。 這件事代表一個很有意思的變化。 以前我們 Vibe Coding 是: Prompt → 網頁 現在開始變成: Prompt → 場景 → 物件 → 物理 → 互動 → 世界 我會把它叫做:3D Vibe Coding。 這個網站真正值得學的,不是 Copy Prompt看到 300 多個 Prompt,第一個直覺一定是:「太好了,以後直接複製貼上。」 但我反而覺得,這是最可惜的使用方式。 因為真正值得研究的是:這些厲害的 3D Prompt,到底是怎麼描述需求的? 我整理之後發現,好的 3D Vibe Coding Prompt,大致可以拆成類似的結構: Reference → World → Assets → Mechanics → Interaction → Camera → UI → Feedback Loop → Acceptance Criteria 這是我從案例整理出的需求拆解方式,不是網站規定的唯一格式。換成比較好理解的問題,就是: 需求層次 要描述清楚的事情 Reference:參考資料 參考哪張圖片、哪段影片或哪個作品? World:世界 場景長什麼樣?空間與路線怎麼安排? Assets:素材 需要哪些角色、車輛、建築與道具? Mechanics:機制 移動、物理、碰撞與遊戲規則如何運作? Interaction:互動 玩家可以做什麼?怎麼控制? Camera:鏡頭 鏡頭要跟隨、環繞,還是自由移動? UI:介面 操作提示、狀態與 HUD 要顯示什麼? Feedback Loop:回饋迴圈 怎麼執行、觀察結果,再修改? Acceptance Criteria:驗收標準 哪些條件成立,才算完成? 這跟我們平常說「幫我做一個 3D 賽車遊戲」,差非常多。 例如今天我要做卡丁車。與其只描述「我要一款賽車遊戲」,不如拆成: 世界長什麼樣?賽道怎麼設計? 車子如何控制?有沒有甩尾? 碰撞怎麼處理?鏡頭怎麼跟車? 怎麼計算圈數?有沒有 Checkpoint? AI 對手怎麼跑?HUD 顯示什麼? 什麼情況算完成遊戲? 當這些東西被描述清楚之後,AI 面對的就不再是一句模糊的願望,而是一份可以執行的規格。 不要 Copy Prompt,要 Copy Architecture這也是我現在看這類 Prompt Library 最大的心得。 Prompt 本身很快就會過時。 今天 GPT-6 Astra 很強,明天可能又有新的模型。今天某一條 Prompt 很厲害,幾個月後模型能力提升,也許一句話就做得到。模型的表現也會隨版本、方案與任務改變,不需要把當下的選擇當成永久排名。 但是,Architecture 不容易過時。 例如你找到一個很棒的 Kart Racing 案例,真正應該留下來的是: 12345678910賽道系統→ 車輛控制→ Vehicle Physics(車輛物理)→ Drift(甩尾)→ Checkpoint(檢查點)→ Lap System(圈數系統)→ AI Opponent(AI 對手)→ Follow Camera(跟隨鏡頭)→ HUD(遊戲資訊介面)→ Win Condition(獲勝條件) 這整組就是一個 Racing Game Pattern。 下一次根本不需要重新想。 你可以把 Roblox 風格換成科幻城市,也可以換成台灣夜市,甚至可以變成「享哥 AI 賽車學院」。 美術全部換掉,但是底層 Pattern 保留下來。 這才是我認為 AI 時代真正值得累積的東西。 更大的變化,是 AI 開始自己「看結果」還有一個地方,我覺得比 3D 本身更值得注意。 以前我們使用 AI Coding 的流程通常是: 下 Prompt → AI 寫程式碼 → 執行 → 人類看結果 → 告訴 AI 哪裡不對 → AI 修改 問題是,中間那個「看結果的人」一直都是我們。 但現在開始不一樣。 當工作環境具備執行、截圖與視覺理解能力,新的工作流可以變成: 1234567891011121314151617Prompt↓AI 建構↓執行↓Screenshot↓AI 自己看畫面↓跟 Reference 比較↓找出差異↓修改↓重新執行 這個差異非常大。 因為 AI 不再只是 Coding Agent,它開始變成 Visual QA Agent。 以前我們叫 AI:「幫我寫 Three.js。」 未來比較可能變成:「這是我要的參考畫面,你自己做到像為止。」 當然,「畫面像」還不是全部驗收。卡丁車能不能控制、圈數有沒有算對、碰撞是否正常,仍要搭配實際操作與功能測試;截圖主要幫助檢查視覺差異。 這也呼應我之前整理的 Agent Harness 觀念:除了模型會不會寫程式,讓它能執行、觀察、修正的工作環境,同樣關鍵。 Tripo 在這裡扮演什麼角色?這也是我一開始容易搞混的地方。 Tripo 3D Prompts 本身比較像 3D Vibe Coding 靈感與 Pattern Library。 真正需要 3D 模型時,則可以再透過 Tripo Studio 之類的 AI 3D 工具,從文字或圖片產生角色、車輛、建築、道具等 3D Assets。Tripo 官方功能介紹也將文字與圖片生成 3D 模型列為核心能力。 於是整條 Workflow 就變得很有意思。如果由我來串接,會是: 1234567891011Tripo Prompts 找案例→ 找到接近的 Pattern→ Codex 分析案例→ 產生 PRD(產品需求文件)→ 建立 Three.js Prototype→ AI 產生 3D Assets→ 匯入場景→ 執行測試→ Screenshot→ AI 視覺檢查→ 自動修改 這已經不是以前那種「AI 幫我產一個 3D 模型」,而是一條逐漸完整的 AI 3D Production Pipeline。 這裡描述的是把不同工具接起來的工作流程構想;免費 Prompt Library 與模型生成服務是不同環節,實際生成的可用功能與額度,仍以各工具當下的方案為準。 如果是我,我甚至不會只收藏 342 個 Prompt我反而會再做下一步:把這 300 多個案例重新分類。 例如: Three.js Interactive Pattern Racing Game Pattern Third Person Game Pattern 3D World Pattern Blender Modeling Pattern Physics Simulation Pattern WebGPU Interaction Pattern Product Visualization Pattern 然後把它們做成自己的 3D Vibe Coding Skill。 以後我只需要跟 Codex 說:「幫我做一款 3D 卡丁車遊戲。」 Skill 自己判斷: Game → Racing → Third Person → Vehicle Physics 接著載入對應的 Pattern,然後自己: Plan → Build → Run → Screenshot → Compare → Fix 這是我希望進一步做出的 Skill 設計方向。要讓它實際運作,還需要把分類規則、範例、工具操作與驗收條件整理好。 如果你還不熟悉 Skill、MCP 與 CLI 的分工,可以先看這篇工具名詞整理。 到了這時候,「342 個 Prompt」就不再只是收藏在瀏覽器書籤裡面的資料,而是變成 AI 可以重複使用的能力。 我覺得 3D Vibe Coding 會是下一個很好玩的方向前幾天我才在想:現在用 Three.js + Vibe Coding,到底能不能做一款類似卡丁車的瀏覽器遊戲? 看完這批案例之後,我的答案已經不是「能不能」,而是: 我們接下來可以做到多複雜? 因為當 Coding Agent、Three.js、Blender、AI 3D Model、Browser Automation、Computer Use、Visual QA 這些能力開始接起來之後,門檻正在快速下降。 以前做一個 3D 世界,你可能要會建模、材質、Lighting、動畫、Three.js、物理引擎、Game Logic、UI、程式設計…… 現在慢慢變成: 你負責描述世界,AI 負責把世界建構出來。 所以 Tripo 3D Prompts 最值得收藏的,可能不是那 342 個 Prompt,而是它讓我們提前看到了一件事情: Vibe Coding 的下一站,可能不只是做網站。 而是開始做遊戲、做空間、做互動、做模擬,甚至直接做一個可以走進去的世界。 而我們現在,可能才剛走到 3D Vibe Coding 的第一章。 常見問答 (FAQ)Q1:Tripo 3D Prompts 是什麼?可以免費使用嗎?Tripo 3D Prompts 是免費瀏覽的 AI 3D 提示詞與案例資料庫,涵蓋 Three.js、Blender、瀏覽器遊戲與互動場景。2026 年 9 月 10 日查閱時顯示 342 個案例;部分是作者原始 Prompt,部分是依公開作品整理的任務描述。免費瀏覽案例,不代表搭配使用的模型生成或程式開發工具都沒有費用。 Q2:3D Vibe Coding 與一般 Vibe Coding 有什麼不同?本文用 3D Vibe Coding 描述透過 AI 建構 3D 場景與互動體驗的做法。相較於常見的 2D 網頁介面,它還需要把世界、物件、物理、操作、鏡頭與遊戲規則描述清楚,讓需求從一句願望變成可以執行及驗收的規格。 Q3:為什麼要 Copy Architecture,而不只複製 Prompt?Prompt 的效果容易隨模型與任務改變,但架構與互動模式可以重複使用。例如賽車遊戲的車輛控制、甩尾、檢查點、圈數、對手、跟隨鏡頭與獲勝條件,都可以整理成 Racing Game Pattern,再換成不同場景與美術風格。 Q4:AI 可以只靠 Screenshot 完成 3D 遊戲驗收嗎?不行。Screenshot 適合協助比較構圖、材質、光線與介面等視覺差異;車輛操作、碰撞、圈數與獲勝條件,仍需要實際操作與功能測試。完整回饋迴圈應包含建構、執行、截圖、比較、修改,以及相關功能的再次驗證。 Q5:如何把 Tripo 案例整理成自己的 3D Vibe Coding Skill?可以先按賽車、第三人稱遊戲、3D 世界、Blender 建模、物理模擬或產品展示分類,再把各類案例的需求結構、操作方式、參考素材與驗收條件整理成 Pattern。最後將選擇 Pattern 的規則與 Plan、Build、Run、Screenshot、Compare、Fix 流程寫入 Skill,並接上實際可用的工具。

  • article-【AI 幫你做網站還不夠:下一代網站,應該讓 AI Agent 能直接操作】

    2026/9/7

    AI自動化 AI Agent Vibe Coding
    【AI 幫你做網站還不夠:下一代網站,應該讓 AI Agent 能直接操作】

    最近看到有人分享「MCP 網站」的概念。 他舉了一個很直覺的例子: 以前網站做好之後,想改一個標題、換一段服務說明,可能還得登入後台,甚至重新找工程師;但網站接上 MCP 之後,可以直接告訴 AI: 把首頁這段改成今年的活動內容。 AI 就能直接替你處理。 一開始我也在想: 現在 ChatGPT、Codex、Claude Code 都已經可以幫我們做網站了,那我用 AI 做出來的網站,不就算 MCP 網站嗎? 深入拆解後,我才發現這其實是兩件完全不同的事。 而且真正值得注意的,不只是 MCP。它背後其實正在浮現一種新的網站架構: Agent-native Website。 也就是網站不再只設計給「人」操作,同時也開始設計給「AI Agent」操作。 這可能會是 Vibe Coding 下一個很值得注意的發展方向。 AI 幫你做網站,不等於 MCP 網站先釐清第一個最容易混淆的地方。 假設今天我跟 ChatGPT Sites、Codex 或 Claude Code 說: 幫我做一個品牌官網。 AI 幫我完成: 首頁 商品頁 表單 後台 資料庫 部署 這叫做 AI-assisted Website Development,也就是「AI 幫我做網站」。 但網站上線之後,如果 AI 沒辦法透過標準介面去讀取、查詢、修改與操作網站,那它並不會因為是 AI 做的,就自動變成「MCP 網站」。 這兩件事情必須分開: AI 幫你建立網站≠AI 可以操作網站 前者解決的是「開發」;後者解決的是「營運」。 我反而覺得,後者可能更值得關注。 MCP 到底在網站裡扮演什麼角色?MCP 是 Model Context Protocol 的縮寫。如果用很簡化的方式理解,可以把它想成: 讓 AI Agent 知道外部系統有哪些能力,並且可以使用這些能力的一套標準介面。 傳統網站通常長這樣: 123456789使用者 ↓Browser ↓Frontend ↓Backend / API ↓Database 管理網站的人則可能走另一條路: 1234567管理者 ↓/admin ↓Backend ↓Database 所以網站其實一直都是: Human-first。 所有東西都是設計給人點的:按鈕、選單、表單、Dashboard 與 CMS。 但 MCP 加進來後,會多出另一個入口: 123456789AI Agent ↓MCP Client ↓MCP Server ↓Website Services ↓Database / CMS / API 這時候 AI 不需要像人一樣: 登入後台 → 找到文章 → 點編輯 → 修改 → 按發布。 它可能直接呼叫: 1234567get_pages()update_page()create_article()get_products()update_product()get_orders()get_analytics() 這才是 MCP 真正有意思的地方。 MCP 不是裝在網站前台這也是我一開始很容易誤解的地方。 既然叫「MCP 網站」,是不是代表要在網站裡面裝一個 MCP? 其實不應該這樣理解。比較好的架構應該是: 12345678910 ┌─ Website Frontend │Website Services ──────┼─ Admin │ ├─ REST API │ └─ MCP Server ↑ │ AI Agent Frontend 是給消費者使用。 Admin 是給管理者使用。 API 是給其他程式使用。 MCP 則是提供給 AI Agent。 所以我反而比較喜歡一個更精準的名稱: MCP-enabled Website。 因為 MCP 並不是「網站本身」,而是網站額外提供的一個 Agent Interface。 MCP 跟 API 到底差在哪裡?這也是另一個很常見的問題。 既然網站本來就有 API: 123GET /api/productsPOST /api/articlesPATCH /api/pages/123 為什麼還需要 MCP? 因為 API 主要是設計給: 程式使用。 MCP 則更進一步讓: AI Agent 理解這個系統有哪些能力,以及什麼時候該使用它。 例如原本網站有: 1GET /api/orders 可以再包裝成 Agent 容易理解的工具: 1234get_orders({ date, status}) 並且描述: 取得指定日期與狀態的網站訂單。 Agent 就比較容易知道:「當使用者問我昨天有哪些訂單時,我應該使用 get_orders。」 因此底層甚至可以完全共用同一套 Service,差別主要在於介面服務的對象不同: 1234567API ↓Program InterfaceMCP ↓Agent Interface 真正重要的其實是 Service Layer這是我研究完後,覺得 Vibe Coding 特別應該注意的一件事情。 很多人用 AI 做網站,很容易把所有商業邏輯直接寫進 UI: 12345Button ↓onClick() ↓Database 網站當然還是可以跑。 但以後想串 API、手機 App、Agent 或 MCP,就會變得很麻煩。 所以如果現在重新設計我的 Vibe Coding 網站 SOP,我會要求 Codex 或 Claude Code: 所有核心商業功能不得只存在於 UI Event Handler,必須抽象成可重複呼叫的 Service Layer,為未來 REST API、MCP Server 與 AI Agent 操作預留介面。 例如: 12345678getProducts()getOrders()getCustomers()createArticle()updateArticle()updateProduct()getAnalytics()updateHomepage() 最後變成: 123456789101112Frontend ↓ ┌────────┐Admin ─────────→│ Service│←──────── REST API │ Layer │ └────┬───┘ ↑ │ MCP ↑ │ AI Agent 這樣即使今天沒有 MCP,網站本身也已經 Agent Ready。未來要增加 MCP,就不需要把整個網站重新打掉。 如果你正在設計自己的 AI Coding 工作流,也可以延伸閱讀Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness;它能幫助你理解 Model、Context、Tools、Skills 與權限如何組成一個可持續工作的 Agent 系統。 從 AI Website 到 Agent-native Website:五個階段我現在會把這件事情分成五個 Level。 Level 1:AI 幫你做網站12345人 ↓ChatGPT Sites / Codex / Claude Code ↓Website AI 是開發工具,網站本身仍然是傳統網站。 Level 2:AI 幫你修改網站例如: 1234567891011你 ↓Codex ↓GitHub ↓修改程式碼 ↓Commit ↓Cloudflare / Vercel 這已經很好用了,但仍然比較接近 AI Software Engineering,而不是 Agent-native Website。 Level 3:MCP-enabled Website開始讓 AI Agent 直接使用網站能力: 1234567你 ↓AI Agent ↓MCP ↓Website Services 例如: 把首頁的活動改成櫻桃季。 Agent 不一定需要修改程式碼,而是直接呼叫: 123get_campaign()update_campaign()update_homepage() 這時網站才真正開始「AI 可操作」。 Level 4:Agent-native Website這一層就更有意思了。 網站從設計第一天就同時考慮兩種使用者: Human + AI Agent。 架構可能變成: 1234567891011121314┌──────────────────────────┐│ Human Interface ││ ││ Frontend /admin │└─────────────┬────────────┘ │ Website Services │ ┌────────┼────────┐ ↓ ↓ ↓ Database API MCP ↑ │ AI Agents 這時候網站已經不只是一堆網頁,而是一組: 可以被人使用,也可以被 Agent 呼叫的商業能力。 Level 5:Self-Optimizing Website再往前一步,Agent 不只操作網站,還可以持續監測、分析、提出修改建議,並在人工核准後執行優化。 這時網站開始具備一個新的循環: 12345678910111213監測 ↓分析 ↓提出建議 ↓人工核准 ↓修改網站 ↓重新驗證 ↓持續追蹤 這條演進路線,也可以和我先前整理的 MCP、Skill 與 CLI 差異一起閱讀:前者偏向網站如何成為 Agent 可操作的系統,後者則整理 AI 工具各自扮演的角色。 Brand Agent:網站營運者不一定是人拿「鮮生小姐」來想,就會非常具體。 例如我自己的實驗專案「鮮生小姐」,未來如果把網站 Agent 化,可以提供: 12345678910get_productsupdate_productget_campaignscreate_campaignget_articlescreate_articleget_homepageupdate_homepageget_customer_inquiriesget_site_analytics 於是我不一定要登入網站後台,而是直接告訴自己的 Brand Agent: 櫻桃季快到了,幫我檢查網站有哪些內容應該更新。 Agent 可以先查詢: 1234get_productsget_campaignsget_homepageget_articles 然後告訴我: 首頁還在主推上一檔活動。 櫻桃商品頁的產季資訊需要更新。 今年還沒有建立送禮相關內容。 我再說: 幫我準備新版,但先不要發布。 Agent 建立 Draft。 我確認: OK,發布。 Agent 再透過 MCP 更新。 這時候 AI 已經不是「網站製作工具」,而是開始變成: 網站營運者。 甚至,鮮生小姐的擬人化 AI 代言人 Cherry,也可以不只是品牌角色,而是 Brand Agent。 她可以同時理解: 網站資料 訂單 商品 內容 Analytics SEO、AEO 與 GEO 接著回答: 最近櫻桃禮盒頁面的流量上升,但轉換率下降,我建議調整首頁 CTA,另外建立一篇今年櫻桃送禮指南。 這時候 IP 就開始從「虛擬代言人」進化成「可以工作的 AI 員工」。 SEO、AEO、GEO、AXO 與 MCP 如何串起來?我最近本來就在研究另一件事情:網站到底要怎麼讓 AI 更容易找到、理解、引用? 傳統網站第一層還是 SEO,例如 Title、Meta、H1-H3、Schema、內部連結與網站效能等。 接著進入 AEO/GEO,要思考的不只是排名,而是: AI 能不能理解並引用我的內容? 所以內容開始需要注意: 是否直接回答問題。 是否有明確定義。 是否標示來源、作者與更新日期。 段落能不能獨立理解。 是否有問題式標題。 是否提供比較與步驟。 是否有真正的原創經驗與案例。 再下一層則是 AXO: AI Agent 能不能理解這個網站? 最後再往下一層: AI Agent 能不能操作這個網站? 這時候 MCP 就出現了。 我開始把整套網站優化流程重新理解成: 12345678910111213141516171819Website ↓SEO讓搜尋引擎找到 ↓AEO / GEO讓 AI 理解、引用 ↓AXO讓 Agent 理解網站與能力 ↓Agent Ready整理 Service / API / 權限 ↓MCP-enabled讓 Agent 可以操作 ↓Agent Automation讓 Agent 可以持續工作 這可能會變成我以後做網站時的新 SOP。 如果想先理解 AXO 與 WebMCP 的差異,可以閱讀SEO、AEO 之後的 AXO:讓 AI Agent 真正完成網站任務。那篇文章偏向 Agent Experience 與任務完成;本文則進一步把焦點拉到網站內部的 Service、MCP 與營運治理。 Self-Optimizing Website:網站自己優化自己我原本就在規劃 AI 搜尋能見度健檢工具。 不是只給一個「GEO 72 分」,而是實際測量品牌是否被 AI 提及、是否被列為推薦選項、引用哪個頁面,以及競品出現頻率。 以前做到這裡,下一步通常是: 12345發現問題 ↓產生報告 ↓交給人修改 如果加入 Agent + MCP,流程就可能變成: 12345678910111213141516171819SEO / AEO / GEO Agent ↓掃描網站 ↓發現問題 ↓提出修改方案 ↓Human Approval ↓MCP ↓修改 Website ↓重新檢測 ↓記錄結果 ↓持續追蹤 例如 AI 發現「櫻桃送禮推薦」這個頁面被 AI 引用率偏低,就可以分析原因,建議增加: 比較表 FAQ 作者資訊 原創資料 更明確的答案段落 人工核准後,Agent 再修改網站,重新測試 ChatGPT、Gemini 或 Claude 等 AI 能見度,一個月後比較變化。 這時候網站就不只是「做好 → 上線 → 放著」,而是: 監測 → 分析 → 建議 → 修改 → 驗證 → 再優化。 MCP 很可能就是這個循環中缺少的最後一塊: Execution Layer。 Agent 權限不能全部開放當 AI 可以直接操作網站後,問題也跟著出現。 例如: 12345delete_customerrefund_orderchange_pricepublish_pagedelete_product 如果全部交給 Agent 自由操作,風險太高。 所以我認為 Agent-native Website 至少應該把權限拆成四層: 權限層級 可以做什麼 建議治理方式 Read 查詢文章、商品、訂單與流量 可讓 Agent 自動處理 Draft 建立文章草稿、活動草稿與 SEO 修改建議 可自動建立,但不直接發布 Write 修改商品、內容與首頁 視情況授權,必要時要求確認 Critical 刪除資料、退款、修改權限與重要交易 必須 Human Approval 而且所有 Agent 操作都應該留下 Audit Log: 123456Agent: SEO-AgentAction: update_pagePage: /cherry-giftReason: AEO OptimizationApproved by: SeanTime: 2026/09/07 08:30 這才會是一個真正能進企業環境的 Agent 架構。 網站後台可能會被重新定義以前 CMS 解決的是: 不會寫程式的人,怎麼修改網站? 所以我們做出了 WordPress、網站後台與 Page Builder。 但 Agent 時代開始出現另一個問題: 如果我根本不用自己操作後台呢? 我只需要說: 把今年所有過期活動整理出來。 先幫我更新成 2026 版本。 發布之前給我看。 這三頁 OK,其他先不要動。 AI 自己完成剩下的工作。 這不代表 /admin 會消失。後台仍然很重要,因為需要: 人工檢視 權限管理 Audit Log 緊急操作 資料校正 但 /admin 可能會從: 主要工作介面 慢慢變成: 管理、監督與治理介面。 真正每天工作的入口,反而可能是 AI Agent。 Vibe Coding 的下一階段,也許不是更快做網站過去兩年大家在比: 誰能更快用 AI 做出網站? 從幾天做到幾小時,再做到一句 Prompt 就能建立。 但當「建立網站」越來越便宜之後,下一個問題自然會變成: 網站做好之後,誰來經營它? 所以 Vibe Coding 下一階段可能不是: AI 幫你做網站。 而是: AI 幫你經營網站。 再下一階段甚至是: AI Agent 成為網站的一級使用者。 所以我現在會把這幾個概念清楚分開: 階段 核心能力 AI Website AI 幫你建立網站 AI-maintained Website AI 幫你修改網站 MCP-enabled Website AI 可以操作網站能力 Agent-native Website 網站從架構開始同時為 Human 與 Agent 設計 Self-Optimizing Website Agent 可以監測、分析、改善並驗證網站 這條演進路線,我覺得才是 MCP 對網站真正有趣的地方。 未來做網站,我可能不會再只問: 手機版做好了嗎? SEO 做好了嗎? AEO/GEO 做好了嗎? 還會多問兩個問題: 這個網站 Agent Ready 了嗎? 以及: 我的 AI Agent,可以安全地替我操作這個網站了嗎? 當答案是 Yes 的時候,這個網站才真正從一個「網頁集合」,開始變成一個: 可以被 AI 理解、呼叫、操作,甚至持續改善的數位商業系統。 結語:下一代網站要問的是 Agent 能不能使用我?以前我們做網站,會問: Google 搜不搜尋得到我? 後來我們開始問: ChatGPT 會不會理解並推薦我? 接下來真正重要的問題可能是: 當 AI Agent 選擇了我,它能不能順利使用我? 這就是: SEO → AEO → AXO。 從被搜尋,到被理解,再到被執行。 MCP 值得注意的地方,也不只是多了一個網站 API,而是它讓我們看見一種可能:Web 正在開始為 AI Agent 重新設計。 未來網站的競爭力,不只在於誰的介面漂亮、SEO 做得好或內容寫得完整,也可能取決於: 你的網站,準備好被 Agent 使用了嗎? 常見問答 (FAQ)Q1:AI 幫我做網站,就代表這是 MCP 網站嗎?不代表。AI 幫你建立網站屬於 AI-assisted Website Development;只有當網站提供可供 AI Agent 理解、查詢與操作的標準化介面時,才更接近 MCP-enabled Website。 Q2:MCP 和一般 API 有什麼差別?API 主要提供程式呼叫的介面;MCP 則進一步描述系統有哪些能力、工具何時適用、需要哪些參數,以及操作結果如何回傳,讓 AI Agent 更容易選擇並使用。 Q3:為什麼網站需要 Service Layer?Service Layer 能把核心商業邏輯從前端按鈕與 UI Event Handler 抽離,讓同一套能力可以被 Frontend、Admin、REST API 與 MCP 共用,降低未來擴充 Agent 操作的成本。 Q4:Agent-native Website 可以讓 AI 自由修改所有資料嗎?不建議。網站應至少區分 Read、Draft、Write 與 Critical 權限;查詢與建立草稿可以較高程度自動化,修改、發布、退款、刪除資料或變更權限等高風險操作則應保留人工核准與 Audit Log。 Q5:網站要如何開始準備 Agent-native 架構?可以先盤點使用者最常想完成的任務,再把商品、服務與限制條件整理成一致且可理解的資料,接著抽離可重複呼叫的 Service Layer,設計 API、工具描述、權限、確認與錯誤回應,最後用完整任務測試 Agent 是否真的能完成流程。

  • article-Vibe Coding 真正要殺死的,可能不是 SaaS,而是「不值得被做成軟體」這句話

    2026/9/2

    商業策略 AI工具 Vibe Coding
    Vibe Coding 真正要殺死的,可能不是 SaaS,而是「不值得被做成軟體」這句話

    今天看到一篇分享文,介紹一個很有趣的網站:Can I Vibecode It? 它收錄了超過 1,000 個付費軟體,然後問一個很暴力的問題: 這個服務,我能不能直接用 AI 自己做一個? 像 Linktree、Todoist、Tally、Bitly 這些服務,它甚至會直接告訴你:可以。 接著,它還會附上一段 Prompt,讓你丟進 Claude Code、Cursor 這類 AI Coding 工具,直接開始做。 一開始看到這個網站,我跟很多人的第一個反應差不多: 靠,這樣可以省很多 SaaS 訂閱費耶。😂 但想了一下,我反而覺得:省訂閱費,可能是這件事情最不重要的影響。 AI 正在讓「功能」快速商品化仔細看那些容易被 Vibe Coding 重做的軟體,會發現它們通常都有一些共同特色: 資料庫 表單 Dashboard 會員登入 幾支 API 再加上一個漂亮的 UI 以前要把這些東西組起來,你可能得找工程師、設計師,開發幾個星期。 所以即使功能不算複雜,也足以成立一家 SaaS 公司。 但 AI Coding 正在快速壓低這件事情的成本。 如果一套產品最核心的價值,只剩下: 我們已經幫你把這幾個功能寫好了。 那它的護城河就會越來越薄。 因為現在 AI 也會寫。 AI 可以複製 Feature,卻不等於複製 Service這裡有一個很容易掉進去的陷阱: AI 可以做出 80%,不代表我應該自己做,更不代表這套 SaaS 沒價值了。 因為 Demo 做出 80%,跟真正可以營運的產品完成 80%,完全是兩回事。 真正上線之後,你還會遇到: 權限管理 資安 備份 監控 API Rate Limit Webhook Retry 付款異常 資料遷移 多人協作 法規與客服 很多時候,畫面上最後那 10%,才是最貴的 60%。 所以我現在會把一件事情分成兩個層次來看: AI 很會複製 Feature,但要複製一個真正可靠的 Service,還是另一回事。 SaaS 真正的價值,早已不只功能這也是為什麼有些 SaaS 反而沒那麼容易被取代。 例如 Shopify、Figma、Intercom,甚至 ChatGPT、Claude,你真正付錢買的,早就不只是那些畫面上的功能。 你買的是: 整個生態系 累積多年的資料 團隊協作能力 第三方整合 Infrastructure 穩定性 資安與合規 出問題的時候,有一家公司幫你扛 所以未來 SaaS 真正的護城河,很可能會從: 我有什麼功能? 慢慢移到: 就算 AI 可以把我的功能全部重做一遍,你為什麼還是不想離開我? 我覺得這會變成未來幾年 SaaS 公司很重要的一道題目。 一人公司真正看見的是「Personal Software」但對我們這些一人公司、小企業來說,我看到的是另一個更大的機會。 假設我花兩天做一個自己的 Calendly,每個月省 12 美元。 其實我覺得沒有很厲害,搞不好我的時間還比較貴。😂 但如果我把它改造成: 台灣美容業 LINE 預約系統 事情就不一樣了。 除了預約,我再加入: LINE OA 通知 會員資料 預約提醒 回訪 生日行銷 AI 客服 顧客標籤 業績分析 這時候我做的已經不是 Calendly Clone,而是把某個產業真正的工作流程與 Know-how,變成一套軟體。 這就是我最近越來越有感的一件事情:專業知識軟體化。 以前我們找軟體配合工作,現在可以讓軟體配合自己這可能才是 Vibe Coding 最有意思的地方。 以前的軟體大概只有兩種。 第一種是商業軟體:做一套產品,賣給幾萬、幾十萬人。 第二種是企業客製:公司花幾十萬、幾百萬,請軟體公司開發。 但現在開始出現第三種:Personal Software。 它只為一個人、三個人或十個人存在,卻可以非常貼近使用者的實際工作方式。 例如: 我自己的講師邀約管理系統 自己的客戶 Follow-up 工具 自己的內容素材庫 自己的社群內容生產工作流 自己的 AI 影片成本計算器 公司裡某個每天重複 30 分鐘的小流程 以前你跟工程師說: 這個只有我自己會用。 工程師大概會問: 那幹嘛做?😂 因為開發成本根本不划算。 現在答案可能完全相反:就是因為只有你會用,所以更應該做成最適合自己的樣子。 從「省訂閱費」到「把工作方法變成產品」所以現在我看到 SaaS,開始會多問一個問題。 不是: 這套軟體一個月多少錢? 甚至不只是: AI 能不能把它做出來? 而是: 這個軟體裡,我真正需要的是哪幾個功能? 接著再問: 如果把那些功能拆出來,再加入我的工作流程與專業知識,會不會變成一個全新的東西? 這兩個問題差很多。 前者是在想:怎麼省掉每個月 20 美元。 後者是在想:我能不能把自己的工作方法變成產品。 如果你想延伸理解這條路徑,也可以先看〈把專業知識變成軟體,產業專家就是下一代產品經理〉,以及〈AI 讓程式碼越來越便宜,但知道什麼值得做正在變得越來越貴〉。 Vibe Coding 改變的是「軟體的經濟學」過去有非常多需求,不是做不到,而是:不值得做。 市場太小,不值得 只有三個人用,不值得 公司內部流程,不值得 一個月只省幾個小時,不值得 需求太客製,不值得 因為工程師太貴、開發週期太長、維護成本太高。 但是當 AI 把開發成本壓下來之後,大量以前「不值得被做成軟體」的需求,突然開始值得了。 所以我認為真正值得注意的,不是: AI 會殺掉多少 SaaS? 而是: 以前只有軟體公司值得開發的東西,現在每家公司、每個專業工作者,都開始值得擁有自己的軟體。 而這背後甚至可能形成一條新的產品路徑: 拆解 SaaS Feature → AI 重建 → 加入自己的工作流程 → 加入 Domain Knowledge → 變成 Internal Tool → 最後產品化成 Vertical SaaS 這條路徑的重點,不是把所有 SaaS 都重做一遍,而是從既有產品理解問題,再把自己的工作方法放進去。 結語:重新定義自己的軟體所以下次看到一套很棒的 SaaS,我可能不會第一時間想: 能不能不要付錢? 我反而會想: 它到底解決了什麼問題? 如果把這個能力,加上我比軟體公司更懂的產業知識,會變成什麼? 這可能才是 AI Coding 時代,真正值得玩的地方。 不是什麼都自己做,而是以前我們只能「選軟體」,現在開始有能力: 重新定義自己的軟體。 常見問答 (FAQ)Q1:Vibe Coding 會取代 SaaS 嗎?Vibe Coding 會讓許多 SaaS 的基礎功能更容易被重做,但不代表所有 SaaS 都會被取代。真正可靠的 Service 還包含資安、備份、監控、整合、穩定性、合規與客服等營運能力。 Q2:AI 可以做出 SaaS 的 80%,是不是就應該自己開發?不一定。是否適合自己開發,還要比較開發與維護時間、資料安全、權限管理、付款與整合等營運成本。如果只是為了省一筆訂閱費,自己的時間成本可能反而更高。 Q3:什麼是 Personal Software?Personal Software 是只服務一個人、小團隊或特定公司的軟體。它不追求服務大量使用者,而是把使用者自己的流程、規則與專業知識,做成最貼近實際工作的工具。 Q4:如何把 SaaS 功能變成自己的產品?可以先拆解 SaaS 真正解決的問題,挑出自己需要的核心功能,再用 AI 重建,接著加入自己的工作流程與 Domain Knowledge。完成後先作為 Internal Tool 使用,驗證有效再考慮產品化成 Vertical SaaS。 Q5:SaaS 在 AI 時代還剩下什麼護城河?SaaS 的護城河會越來越依賴生態系、累積資料、團隊協作、第三方整合、基礎設施、穩定性、資安、合規與服務承擔,而不只是功能數量。核心問題會變成:即使功能能被重做,使用者為什麼仍然不想離開?

  • article-Vibe Coding 下一階段:把專業知識變成軟體,產業專家就是下一代產品經理

    2026/8/31

    商業策略 AI Agent Vibe Coding
    Vibe Coding 下一階段:把專業知識變成軟體,產業專家就是下一代產品經理

    最近看到一個很有意思的案例。 一位房仲做了一套 591 競品分析工具。貼上一個 591 網址,就可以自動整理同社區競品、價格、刊登時間與曝光狀況,甚至判斷一間房子到底是「價格有問題」,還是「根本沒曝光」。 有趣的不是這個工具本身,而是他說: 「我一行程式都不會寫。」 但光是其中一個競品分析功能,就有 15 個程式檔案、9,324 行程式,前後修改 75 次;整個系統甚至累積到 3,000 多次修改。他主要靠 Claude Code,把這套東西慢慢做出來。 很多人看到這裡,第一個反應可能是:「現在 AI 真的太強了,不會寫程式也能做 App。」 但我看到的,其實是另外一件更大的事情。 Vibe Coding 真正改變的,可能不是程式設計以前我們談 No-Code、Low-Code,到現在談 Vibe Coding,大家一直在討論: 以後是不是不用學寫程式了? 但我覺得,這可能問錯問題了。 真正正在發生的是:大量原本只能存在「專家腦袋裡」的東西,開始可以被軟體化。 這才是我認為 Vibe Coding 最重要的改變。 真正值錢的不是那 9,324 行程式假設今天叫一個很厲害的工程師完成「591 資料抓取 → 整理 → Dashboard → 報表」,技術上可能完全沒問題。 但工程師怎麼知道: 刊登超過幾間叫供給過剩? 多少瀏覽才算曝光不足? 同一間房子被三個仲介刊登,到底算三筆還是一筆? 什麼情況代表價格有問題? 這些東西不是只靠寫程式就能得出來的。它來自一個房仲做過幾百次成交、看過幾千個物件之後,慢慢形成的判斷。 以前我們會叫這種東西「經驗」。但 AI Coding 出現之後,我開始覺得應該換一個角度看: 這些其實都是還沒有被寫成程式的商業邏輯。 未來值錢的能力,是把「我覺得」變成「如果……就……」例如,一個資深房仲可能會說:「這間我一看就知道不好賣。」 以前這句話很難交給電腦。但如果繼續追問「為什麼」,他可能慢慢拆出: 如果同社區待售超過 15 間; 如果價格高於近期成交行情 8%; 如果刊登 30 天但瀏覽不到 500; 如果照片數量低於某個數字; 如果三週都沒有有效詢問; 那麼成交機率就會開始下降。 這時候事情就完全不同了,因為專業經驗可以沿著一條清楚的路徑被轉換: 經驗 → 判準 → 規則 → Workflow → 軟體 這就是我最近越來越在意的一個概念:專業知識軟體化。 AI Coding 的最大機會,不是讓所有人變成工程師真正的機會是:讓每一個產業專家,都第一次有機會把自己的 Know-how 變成軟體。 所以,接下來很有優勢的可能不只是最會寫程式的人,也包括: 做了 20 年帳務的會計師; 看過幾千個案件的律師; 成交過幾百間房子的房仲; 教過幾千個學生的老師; 做過幾百個廣告專案的行銷人; 跑過幾百間工廠的顧問。 以前這些人的專業很難複製,因為 Know-how 在腦袋裡。新人只能跟著老師傅看、問、學、犯錯,再慢慢累積經驗。 但現在多了一條路:你可以開始問自己,「我每天到底在做哪些判斷?」然後一條一條把它寫出來。 這也延續了我在〈AI 讓程式碼越來越便宜,但「知道什麼值得做」正在變得越來越貴〉談過的觀察:真正稀缺的,往往不是把功能做出來,而是知道哪個產業問題值得被做成產品。 為什麼 Prompt 不是終點?很多人學 AI 還停在:「幫我寫一個厲害 Prompt。」 但 Prompt 本身很難形成太大的護城河。真正有價值的是 Prompt 後面的判斷規則。 例如,不是只叫 AI「幫我分析這個網站的 AEO」,而是明確告訴它: 什麼情況代表 Entity 不清楚? 什麼情況代表內容缺乏可引用性? 什麼結構不容易被 Answer Engine 理解? 哪些 Schema 缺失? 品牌資訊在不同來源出現矛盾時,風險怎麼計算? 最後甚至可以進一步形成完整流程: 檢查 → 評分 → 找問題 → 排優先級 → 提出修改 → 自動修正 這時候,它就不再只是一個 Prompt,而開始變成 Software。 Coding Agent 如何補上最後一塊拼圖?Claude Code、Codex 這類 Coding Agent 真正重要的地方,不只是「比較會寫程式」,而是它們開始可以: 讀取與建立檔案; 修改與執行程式; 查看錯誤並修正; 執行測試; 操作工具; 拆解任務並持續工作。 所以我們正在從「AI 告訴你怎麼做」,進入「AI 幫你把它做出來」。 這也是為什麼最近大家開始談 Agent Harness。Model 決定 AI 有多聰明;Harness 則決定:它到底能不能工作。 如果想更完整理解這個架構,可以接著閱讀〈Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness〉。 當寫程式越來越便宜,知道該寫什麼反而越來越貴以前,「我有一個 Idea,但是我不會寫程式」是一個很大的障礙。 未來真正的障礙可能變成:「你到底懂不懂這個產業?」 因為 App 可以生成、Dashboard 可以生成、Database 可以建立、API 可以串、UI 可以改。真正難複製的是: 你做過 300 次之後,知道第 301 次應該怎麼判斷。 AI 原生產品的四個必要元素我現在會用另一個公式看 AI 原生產品: AI 原生產品 = Domain Expertise × Explicit Rules × Agent Harness × Iteration 這四個元素分別代表: Domain Expertise:真實累積的產業經驗。 Explicit Rules:把經驗講清楚、拆成明確判準的能力。 Agent Harness:讓 AI 能讀取資訊、使用工具並真正動手工作的環境。 Iteration:一次又一次測試、修正與調整。 少一個,都很難變成真正可用的 AI 原生產品。 專業知識軟體化,可能催生下一波 Vertical AI今天是一個房仲做 591 分析;明天可能是一個會計師,把自己的查帳流程做成系統。 也可能是一個老師,把自己批改幾千份作文的判斷做成工具;一個行銷顧問,把做過幾百個案子的診斷方法做成產品;一個製造業老師傅,把「聽聲音就知道機器哪裡不對」的經驗拆成判斷系統。 最後會發現,他們根本不是在「學寫程式」,而是在做另一件事情: 把自己的職業經驗,編譯成軟體。 學 Vibe Coding 前,先問自己這三個問題如果你最近正在學 Vibe Coding,我反而不建議第一個問題是:「我要做什麼 App?」 你可以先問自己: 有什麼事情,是別人每次都跑來問我的? 有什麼判斷,我做 30 秒,新手可能研究三小時? 有什麼工作,我已經重複做過 100 次以上? 那裡面很可能就藏著你的第一套 AI 工具,甚至是你的第一個 SaaS。 以前軟體公司的邏輯是: 找到產業需求 → 找專家訪談 → 寫規格 → 找工程師 → 做軟體 現在開始可能反過來: 專家自己就是產品經理,AI Coding Agent 就是他的工程團隊。 而他腦袋裡累積十年、二十年的 Know-how,就是最重要的原始碼。 所以我越來越相信:Vibe Coding 的終局,不是人人都變成工程師,而是每一個真正有專業的人,都有機會變成一家軟體公司。 常見問答 (FAQ)Q1:不會寫程式,也能用 Vibe Coding 做出軟體嗎?可以,但重點不只是會不會下 Prompt。你仍需要清楚描述問題、把專業經驗拆成判準與規則,並透過 Coding Agent 反覆建立、測試與修正。AI 可以降低實作門檻,卻不會自動補上你不具備的產業知識。 Q2:什麼是「專業知識軟體化」?專業知識軟體化,是把專家長期累積的經驗,從模糊的直覺拆成可說明的判準,再轉換為規則、Workflow 與軟體功能,讓原本只能靠個人判斷的 Know-how 可以被重複使用。 Q3:Prompt、Workflow 與軟體有什麼差別?Prompt 通常是一次性的指令;Workflow 把多個步驟、條件與工具串成可重複流程;軟體則進一步加入資料、介面、權限、錯誤處理與持續迭代。當 Prompt 背後有明確判斷規則並能穩定執行時,就開始具備軟體產品的雛形。 Q4:Agent Harness 在 AI 原生產品中扮演什麼角色?Agent Harness 是讓 AI Agent 能取得情境、讀寫檔案、使用工具、執行任務、處理錯誤並遵守權限邊界的工作環境。Model 決定 Agent 的能力上限,Harness 則影響它能不能可靠地把工作完成。 Q5:如何找到適合自己的第一個 AI 工具題目?先盤點別人經常請教你的問題、你能快速完成但新手需要研究很久的判斷,以及你已重複執行上百次的工作。優先選擇規則相對清楚、資料可取得、結果可以驗證的小流程,再逐步擴充成產品。

  • article-20 萬 Stars 的 DeepSeek Harness:Vibe Coding 下一場戰爭可能換戰場了

    2026/8/29

    AI工具 AI Agent Vibe Coding
    20 萬 Stars 的 DeepSeek Harness:Vibe Coding 下一場戰爭可能換戰場了

    過去一年玩 Vibe Coding,大家最常討論的問題幾乎都是:GPT、Claude、Gemini、DeepSeek,到底誰寫程式最強?哪個模型 Benchmark 比較高?哪個模型 Context 比較大?哪個模型比較不容易把專案改爛? 但最近我越來越覺得,Vibe Coding 的下一場戰爭,可能已經不只是 Model,而是誰能替模型造出一套更強的「Agent 身體」。 最近 DeepSeek 開源了一個非常值得研究的專案:DeepSeek Harness(DSH)。GitHub 已經突破 20 萬 Stars,更有意思的是,它現在甚至還只是 Developer Preview。 官方給了一個我很認同的公式: Agent = Model + Harness 模型是大腦;Harness 則是身體。 本文沿用初稿提供的「20 萬 Stars」與 Developer Preview 觀察。GitHub Stars、功能與架構都可能快速變動,實際使用時仍應以 DeepSeek Harness 官方 Repo 的最新內容為準。 過去我們在比 Model,接下來可能開始比 Harness模型很重要,但模型能力不等於 Agent 能力。 Model 決定的是: 會不會推理。 會不會寫程式。 能不能理解需求。 能不能在上下文中形成合理判斷。 Harness 決定的卻是另一組問題: Agent 可以看到什麼? 可以使用哪些 Tools? 要怎麼操作電腦與開發環境? Context 要怎麼管理? Skills 要怎麼呼叫? 複雜任務要怎麼拆解? 要不要叫其他 Subagent 幫忙? Session 要怎麼保存? 出錯後能不能知道剛剛到底發生什麼事? 所以同一顆模型,放進不同 Harness,最後可能就是完全不同等級的 Coding Agent。 這也是為什麼我現在開始覺得:模型能力只是 Agent 戰爭的一半,另一半是模型被放進什麼工作環境裡。 模型很聰明,不代表 Agent 很會工作我們很容易把「模型能力」跟「Agent 能力」混在一起,但其實這是兩件事情。 可以用一個工作團隊來理解:Model 像大腦,負責理解與推理;Harness 像工作環境與管理制度,負責提供工具、規則、流程、狀態與回饋;Skills 則像 SOP,告訴 Agent 某一類工作應該怎麼完成。 元件 可以怎麼理解 主要作用 Model 大腦 理解、推理與產生回應 Harness 身體、工作環境與管理制度 提供 Context、Tools、流程、權限、狀態與錯誤處理 Skills SOP 與專業方法 告訴 Agent 某一類工作應該如何完成 Tools 工具與外部連接 讓 Agent 讀寫檔案、執行指令、呼叫 API 或操作服務 Subagents 可以被委派的專業成員 分擔任務、平行處理並回傳結果 換句話說,Model 可能很會回答問題,但如果它看不到正確的檔案、沒有合適的工具、不能保留 Session,也沒有驗證與錯誤恢復機制,它就不一定能把工作完成。 DeepSeek Harness 最核心的概念:Everything is a PluginDSH 最吸引我的地方,是它把整個 Agent 拆開了。官方的核心設計就是: Everything is a Plugin. Model 是 Plugin。 Tools 是 Plugin。 Skills 是 Plugin。 Session 是 Plugin。 Sandbox 是 Plugin。 Storage 是 Plugin。 Agent Loop 是 Plugin。 連 UI 都可以是 Plugin。 也就是說,你不是只能接受官方幫你做好的 Coding Agent,而是可以開始像組積木一樣,自己組一個 Agent。 這件事情的重要性在於:未來 Coding Agent 的競爭,可能會慢慢從「哪一個 AI 比較聰明?」變成「你怎麼組織這些 AI 工作?」 當 Model、Context、Tools、Skills、Runtime、Session 與 UI 都能被拆開、替換與組合,Agent 就不再只是某家模型公司的單一產品,而會更接近一個可設計的工作平台。 1. Dynamic Workflow:Agent 開始自己組專案團隊假設今天要 Review 一個大型專案。以前可能是一個 Agent 從頭做到尾:讀程式碼、看架構、找漏洞、看測試,最後寫報告。 DSH 可以換一種玩法。 主 Agent 可以動態寫 JavaScript Workflow,再建立多個 Subagents,讓它們平行執行: Architecture Agent:專門看整體架構與模組邊界。 Security Agent:專門尋找資安風險與可能的漏洞。 Testing Agent:專門檢查測試覆蓋與失敗案例。 Code Quality Agent:專門檢查程式碼品質與可維護性。 Security Agent 負責找漏洞,Testing Agent 負責檢查測試,Architecture Agent 負責看全局架構,Code Quality Agent 則負責程式碼品質。最後,主 Agent 再把每個 Agent 的 Structured Output 收回來統整。 注意這件事情的差異: 以前是:Agent 自己工作。 現在開始變成:Agent 寫程式管理其他 Agent 工作。 它已經開始有點像 AI Tech Lead:不只自己解題,也會判斷要找誰、怎麼分工、哪些工作可以平行,以及最後如何合併結果。 2. Agent Teams:不是 Subagent,而是真的 AI TeamDynamic Workflow 比較像「這個任務臨時找四個 AI 過來幫忙」。但 DSH 還往前走了一步:Agent Teams。 它可以建立一個持續存在的 AI Team,裡面有: Lead:負責理解目標、分派任務與統整結果。 Teammates:各自負責不同領域的工作。 Mailbox:讓 Agent 之間可以互相傳遞訊息。 Shared Task DAG:管理任務依賴與執行順序。 Agent 之間甚至可以互相傳訊息。Task DAG 則負責管理任務之間的依賴:誰先做?誰可以平行?誰必須等另一個 Agent 完成? 這時候你操作的東西,其實已經不像 Chatbot 了,而比較像一間 AI 軟體公司的組織架構。 它把「一次請模型幫忙」改成「設計一組能持續協作的工作角色」。對大型專案而言,這可能比單純增加一次對話的 Context 更接近真實工程團隊的工作方式。 3. Trajectory:Agent 終於不再是一個黑箱這是我在 DSH 裡面非常喜歡的一個設計。 現在很多 Coding Agent 有一個很大的問題:你丟一個任務給它,它跑了十幾分鐘,改了二十個檔案,用了幾萬 Token,最後只告訴你:「Done。」 但你真正想知道的是:它剛才到底做了什麼? DSH 會把整個 Agent 執行過程記錄下來,包含: System Prompt Reasoning Tool Call / Result Context Subagent Token 執行時間 Session 甚至可以 Restore、Fork、Retrieve、Replay。 所以當 Agent 出問題,你可以往回追: 它在哪一步開始判斷錯誤? 哪個 Tool 出錯? 哪個 Subagent 做錯? Context 從哪裡開始污染? 我覺得可以把這東西理解成:Chrome DevTools for AI Agent。 未來 Agent 如果真的要進企業 Production,Observability 幾乎一定會變成標配。企業不只需要知道最後有沒有產出,也需要知道產出是怎麼來的、哪一個環節可以重現,以及出錯後能不能快速定位。 4. Creator Mode:Agent 開始替自己組裝能力DSH 還有一個很有意思的 Creator Mode。 Agent 可以檢查自己現在有哪些能力,發現缺少什麼,就 Mount Plugin;接著測試 Plugin,最後甚至可以建立自己的 Agent Preset。 這件事情真正有意思的地方是: 以前:工程師替 Agent 寫功能。 接下來可能變成:人描述需要什麼能力,Agent 開始替自己組裝能力。 如果這條路繼續走下去,未來我們甚至可能不再「建立 Agent」,而是讓 Agent 自己建立 Agent。 這也會讓「Agent 設計」從一次性的程式開發,逐漸變成一種能力配置與治理問題:哪些 Plugin 可以掛載?如何測試?權限如何限制?產生的新 Agent 是否需要經過人工審核? 5. 更有趣的是,它甚至可以找 Codex、Claude Code 當外援這點我覺得非常有想像空間。 依照初稿所整理的 DSH 官方架構,它已經提供 Codex Subagent 與 Claude Code Subagent 的整合方向。 未來完全可以出現這種工作流: DeepSeek 當 Lead Agent。 某個功能先交給 Codex 實作。 架構完成之後,再請 Claude Code Review。 測試交給另外一個 Agent 執行。 最後由 DeepSeek 把所有結果收回來統整。 這時候我們一直爭「Claude 跟 GPT 到底誰比較強?」可能突然變得沒那麼重要。 真正重要的問題反而是:誰最會指揮它們? 要注意的是,這裡談的是 DSH 的架構與 Subagent 工作流方向,不代表每個版本、每種部署方式都已經提供相同的整合程度。由於 DSH 仍在 Developer Preview,實際支援的 Agent、設定方式與限制,應以官方 Repo 的最新文件為準。 這才是 DeepSeek Harness 真正值得看的地方如果只把 DSH 看成「DeepSeek 也做了一個 Claude Code」,我覺得反而低估它了。 它真正有意思的地方,是把 Agent 最重要的那一層直接攤開: Model × Context × Tools × Skills × Runtime × Subagents × Session / Memory × Observability Model 只是其中一層。 真正讓這些東西開始一起工作的,才是 Harness。 這個觀點也提醒我們:一個 Agent 的能力,不應該只用模型排行榜衡量。它是否能讀取正確脈絡、是否有安全的工具權限、是否會使用適合的 Skill、是否能平行分工、是否能追蹤與恢復,才是它能不能穩定工作的關鍵。 Vibe Coding 上半場比 Model,下半場開始比 Harness過去一年,我們一直追新的模型:Claude 更新,測一次;GPT 更新,再測一次;Gemini 更新,又測一次;DeepSeek 出新模型,繼續測。 但當模型之間的能力逐漸逼近,我覺得下一個真正值得研究的問題已經開始浮現:如何把模型組織成真正會工作的 Agent? 模型是大腦。 Harness 才是讓這顆大腦擁有眼睛、手、工具、記憶、工作流程,以及團隊協作能力的身體。 所以接下來玩 Vibe Coding,我覺得除了研究「哪個 Model 最強?」,還要開始研究另一個問題: 這個 Agent,到底是怎麼被 Harness 起來的? DeepSeek Harness 現在還只是 Developer Preview,功能與架構一定還會快速變化。但 GitHub Stars 快速累積,本身就透露了一件很有意思的事情:開發者開始把注意力,從 Model 往 Agent Runtime 移動了。 Vibe Coding 上半場在比 Model。 下半場,可能開始比 Harness。 而再下一場戰爭,也許是:誰能打造出最會管理一整群 AI 的 Agent Runtime。 結語:真正的競爭可能是 AI 的組織能力DeepSeek Harness 值得看的,不只是它能不能成為另一個 Coding Agent,而是它把「Agent 如何被組裝、協作、追蹤與恢復」這件事攤在開發者面前。 當所有東西都能變成 Plugin,Model 就不再是唯一的主角。未來的開發者可能需要同時具備三種能力:選擇合適的模型、設計可靠的 Harness,以及把一群 Agent 組織成可驗收的工作流程。 如果你身邊有人正在玩 Claude Code、Codex、Vibe Coding 或 Multi-Agent,這篇文章可以分享給他。因為下一波 AI Coding 的競爭,可能真的要換戰場了。 DeepSeek Harness 官方 Repo:github.com/deepseek-ai/deepseek-harness 延伸閱讀 Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景 何時該用 LLM?何時該派 AI Agent 上場? 常見問答 (FAQ)Q1:DeepSeek Harness 是什麼?DeepSeek Harness(DSH)是一套用來組裝與運行 AI Agent 的 Harness。它把 Model、Tools、Skills、Session、Sandbox、Storage、Agent Loop 與 UI 等能力拆成可組合的 Plugin,讓開發者能設計不同的 Agent 工作環境。 Q2:Model 與 Harness 的差別是什麼?Model 負責理解、推理與產生回應,像是 Agent 的大腦;Harness 負責提供 Context、Tools、流程、權限、Session、錯誤處理與協作機制,像是讓大腦真正能工作的身體與工作環境。 Q3:Dynamic Workflow 與 Agent Teams 有什麼不同?Dynamic Workflow 是主 Agent 針對單次任務動態建立多個 Subagents 並平行執行;Agent Teams 則是由 Lead、Teammates、Mailbox 與 Shared Task DAG 組成的持續性團隊,能管理訊息傳遞與任務依賴。 Q4:Trajectory 為什麼對 Coding Agent 重要?Trajectory 會記錄 Agent 的 Prompt、Reasoning、Tool Call、Context、Subagent、Token、執行時間與 Session,並支援 Restore、Fork、Retrieve、Replay。這讓開發者能追蹤 Agent 從哪一步開始出錯,而不必只依賴最後一句「Done」。 Q5:DeepSeek Harness 現在適合直接用於企業 Production 嗎?本文整理的 DSH 仍是 Developer Preview,功能、介面、整合方式與限制都可能快速變化。若要導入企業 Production,應先依官方 Repo 的最新文件確認部署方式、權限、Plugin、Subagent 與 Observability 能力,再進行小範圍測試與人工驗收。

  • article-官網被駭後,我乾脆用 AI 一週重做一個品牌|鮮生小姐官網重建實錄

    2026/8/26

    商業策略 AI工具 Vibe Coding
    官網被駭後,我乾脆用 AI 一週重做一個品牌|鮮生小姐官網重建實錄

    這一週,我幾乎把工作重心都放在一件事情上:重新打造「鮮生小姐」的品牌官網。 起因其實很直接。 原本鮮生小姐的官網是用 WordPress 做的,前陣子碰到大漏洞,八月初直接被駭客弄掛。既然都已經要大修,我乾脆做了一個決定: 不要修舊網站了,直接用 AI 重新做一個。 而且這次不是單純把網站「做回來」,而是趁這個機會,把品牌、購物流程、商品圖片、內容行銷,甚至品牌角色都重新想一次。 先從品牌開始:打造 AI 代言人 Cherry第一個最大的改變,就是導入新的 AI 代言人:Cherry。 為什麼是 Cherry? 因為鮮生小姐做進口水果,最具代表性的商品之一就是櫻桃。 所以我跟 AI 討論了很久,希望她不是一個制式的「AI 美女」,而是真的有品牌個性。最後慢慢找到一個我很喜歡的方向: 怪美的,甜一點、酸一點,都好。 我希望 Cherry 有一點甜、有一點酸、有一點怪,但又讓人印象深刻。 接下來,她就不只是網站上的一張人物圖。她可以介紹商品、推薦水果、帶大家認識品牌,也可以出現在未來的社群內容裡。 做到後來,我甚至還直接用 Suno 幫 Cherry 做了一首歌和品牌 MV。 以前我們是在做一個網站;現在更像是在慢慢打造一個品牌角色,甚至是一個品牌世界。 重新設計購物流程:網站負責展示,LINE 負責成交第二個改變,是我把傳統電商購物流程重新想了一遍。 這次的新官網,目前沒有再串第三方金流,而是把流程改成: 官網介紹商品與產生興趣 → LINE 詢問、溝通與客製 → 銀行轉帳完成交易。 這算是我這次一個滿大的實驗。 以前做電商,很自然會想到: 商品頁 → 購物車 → 結帳 → 金流 → 訂單成立 但水果,尤其是水果禮盒、企業送禮,本來就不是每一筆交易都這麼標準。客人很常會問: 這個今天有貨嗎? 水果可以換嗎? 我要送 10 盒,要怎麼搭配? 某一天以前送得到嗎? 企業大量訂購,有沒有其他方案? 這些事情,本來就非常適合透過 LINE 溝通。 所以與其強迫每個客人都走標準購物車流程,我反而把網站跟 LINE 高度綁定: 網站負責把商品說清楚,LINE 負責把交易完成。 對小型品牌來說,我覺得這可能是一個很值得測試的新方向。它不一定適合所有商品,但對規格、庫存、數量與配送條件都可能需要討論的水果生意來說,彈性會比制式結帳流程更高。 AI 不是幫我找圖,而是直接幫網站生圖第三個讓我很驚喜的地方,是網站圖片。 以前做網站有一件很花時間的事情:找圖。 尤其水果更麻煩。你可能找到一張很漂亮的蘋果、一張很漂亮的葡萄、一張很漂亮的哈密瓜,但放在同一個網站裡,常常會發現光線、背景、構圖和攝影風格都不一樣,整個網站看起來就像從不同地方拼起來的。 這次我直接讓 AI 延續鮮生小姐原本的商品攝影風格,再按照網站實際需要去生成圖片。 我可以直接告訴 AI: 我要什麼比例。 主體要放在哪裡。 哪邊需要留白。 這張圖適合首頁還是商品頁。 整體光線、背景與質感要保持一致。 以前的流程是: 找圖片 → 配合圖片設計網站。 現在變成: 先設計網站 → 再生成最適合網站的圖片。 整個設計流程其實已經倒過來了。圖片不再只是網站完成後才補上的素材,而是可以跟頁面結構一起被規劃的品牌資產。 用 Codex 協同作業,一週把整個架構做起來這次整個網站,我主要是用 Codex 協同作業。 從網站架構、頁面設計、商品資料、LINE 導購流程,到部署、修改和調整,很多事情都是直接跟 AI 邊討論邊做。 我覺得最大的差別,不只是 AI 幫我寫程式碼,而是以前很多事情光想到就會覺得專案很大: 網站架構要改。 商品流程要改。 圖片要重做。 SEO 要處理。 手機版要調整。 部署還要弄。 然後就會想:「這專案好像有點大,改天再做。」 但現在可以直接把問題拆開,一個一個跟 AI 做。所以短短一週,就已經可以做到現在這個程度。 這裡的重點不是「AI 一週就能把任何品牌網站做完」,而是當架構、內容、圖片與部署都可以在同一個協作流程裡快速往返,一個人也更有機會把原本不敢啟動的專案先做出第一版。 網站不是做完,而是終於可以開始快速迭代當然,目前還有很多地方需要持續修改。 商品會繼續增加,Cherry 的角色設定還會繼續發展,SEO 文章也會慢慢補上,網站細節一定還會再調整。 但現在有一個很大的差別:底層已經建立起來了。 接下來要上架新商品,可以很快;要新增 SEO 文章,可以很快;要做季節水果活動頁,也可以很快。甚至未來要讓 Cherry 出現在更多內容裡,也已經有完整的方向可以延伸。 所以我現在看這個網站,它其實已經不只是一個官網,更像是: 品牌內容平台 商品展示平台 SEO 平台 LINE 導客入口 AI 真正改變的,是「我敢做多少事情」這次最大的感觸是:AI 真正改變的,不只是「做事情變快」。 而是讓原本一個人覺得太大的事情,開始變成可以直接動手做的事情。 以前可能會想: 「這個專案要找很多人、花很多時間,之後再說。」 現在則變成: 好,那這週就來試試看。 對一人公司、小型品牌、內容工作者來說,我覺得這才是 AI 真正厲害的地方。 它不是取代你做決定,而是讓你的想法可以更快變成真的東西。 鮮生小姐新版官網鮮生小姐新版官網目前正逐步上線中,歡迎看看這次用 AI 重做的品牌網站: 前往鮮生小姐新版官網 常見問答 (FAQ)Q1:為什麼不直接修復原本的 WordPress 官網?因為原網站在八月初遭遇漏洞並被駭客弄掛,既然已經需要大幅修復,就把這次機會用來重新思考品牌、購物流程、商品圖片與內容架構,直接用 AI 建立新版本。 Q2:為什麼讓官網展示商品、再用 LINE 完成交易?水果禮盒與企業送禮常涉及庫存、換果、搭配數量、配送日期與大量訂購方案,這些需求不一定適合標準購物車,因此讓官網負責說明商品,再透過 LINE 溝通與成交。 Q3:這次 AI 協助了哪些網站工作?AI 協助討論網站架構、頁面設計、商品資料、LINE 導購流程、商品圖片與部署調整,也支援 Cherry 品牌角色與後續內容方向的發展。 Q4:這個網站現在已經全部完成了嗎?還沒有。商品、Cherry 的角色設定、SEO 文章與網站細節都會持續更新;目前最重要的是底層架構已經建立,後續可以更快新增商品、文章與季節活動頁。