你現在看到的這個網站
叫 Jev Atlas
它裡面收集了上百個真實的 Jev 項目
你可以直接搜索一個項目
也可以按照不同的分類去找
更有意思的是
網站背後這張不斷變化的圖
並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類
都來自真實的數據
它們之間有關係，才會在圖上連起來
但今天我真正想講的
其實不是這個網站
而是呢做出這個網站的這台 Mac 上的 Omarchy
在視頻的後面
我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了
它真的能提高工作效率嗎？
話說在幾天之前
我把一台已經閒置的 M1 Mac mini 找了出來
在上面裝了 Omarchy
對這台舊電腦
我當時呢也沒對它抱太大的希望
但是，結果完全出乎我的意料
我剛剛才把平時用的 Mac Studio 升級到 macOS 15
按理來說
最應該讓我喊一聲“Wow”的應該是它
可這幾天真正讓我一邊用、一邊不斷喊“Wow”的
反而是這台舊 M1 上跑起來的 MacOmarchy
後來我在 X 上發了一條帖子
我說：“幾天前
我用馬塞洛（Marcelo）開發的 Omarchy
讓一台舊 M1 Mac mini 獲得了第二次生命
現在又看到 ChatGPT 來到 Linux
感覺這個時間點剛剛好
沒想到
Omarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了
他不但回應了這條帖子，還轉發了它
當時我說
我好像給這台舊 M1 找到了第二次生命
但那時候，這其實還只是一種感覺
裝一個很酷的系統，讓 Codex 跑起來
讓 AI 可以在裡面工作
這些當然都是很有意思的
可一台所謂的“AI-native computer”，
如果最後只是讓我多了幾個和 AI 聊天的窗口
好像又差了點什麼
所以這幾天
我真的給它安排了一份工作
那這期視頻呢是由 Hostinger 贊助的
而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台
就直接把 Agent 在本地完成的工作送到真實的互聯網
我沒有讓 Codex 給我寫一個 Todo List
也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo
我給了它一個真的項目，就是：
我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來
做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站
那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站
再自己打開瀏覽器檢查結果
後來
它又通過 Hostinger Connector (MCP)
把網站真正部署到了互聯網上
整個過程從想法、到代碼、到部署到互聯網
也就半天的時間
然後我又在 X 上發了一條推文
我說：“那台舊 M1 Mac mini
現在有工作了
它運行著 Omarchy
我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖
每個項目都鏈接到真實的來源
還可以搜索
並通過一張實時動態圖展示整個生態
Codex 完成了網站的構建和測試
通過 Hostinger MCP 把它部署到互聯網上
然後又對公開網站進行了驗證——整個過程
都是從這台 M1 上完成和調度的
這開始讓我覺得
這才像是一台 AI 原生電腦（AI-native computer）該有的樣子
所以這期視頻，我們就從頭看看
這台被我叫作 MacOmarchy 的 AI-native computer
到底是怎麼開始真正乾活的
其實一開始
我並沒有打算讓這台 M1 做什麼特別複雜的事情
我只是很好奇
當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後
它到底會有什麼不一樣？
很快，我就碰到了一個很小的問題
就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下
我不想專門跑下去拿
書桌上倒是有一隻 Magic Mouse
但問題就變成了：
我怎麼把它連到這台 MacOmarchy 上呢？
Omarchy 本身的設計
其實已經刻意減少了很多對鼠標的依賴
很多操作直接用鍵盤就能完成
但是，如果真要選一段文字
或者做一些細一點的操作
我還是覺得鼠標方便
所以我想到了 Codex
我按下 Ctrl + 回車打開終端
輸入 Codex
然後直接告訴它：幫我把這只 Magic Mouse 連上
接下來它自己去掃描藍牙設備、添加設備、完成連接
鼠標連上以後
我又發現指針移動得太快了
和我平時在 macOS 上的手感差很多
我就繼續告訴 Codex
讓它把速度降下來
然後還有滾動方向
我不喜歡那種更像 Windows 的反向滾動習慣
所以也讓它一起調成我平時用 Mac 的感覺
整個過程，我當時就覺得很有意思
因為呢如果是在傳統的電腦使用方式裡面
我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向
那套界面本來就是給人設計的
但對 AI 來說
它其實根本就不需要先學會在屏幕上找到那個藍牙圖標
再模擬我去點哪個按鈕
它可以直接和系統本身打交道
對我們人來說
瀏覽、點擊、拖動當然很自然
但對 AI 來說，屏幕上的這些按鈕
很多時候反而只是繞了一層
這一下就讓我第一次很明顯地感覺到
這台舊 M1 和我其他幾台蘋果電腦
好像開始有了一點不一樣了
但就是這個很小的體驗
就讓我開始想：
如果這台電腦不只是幫我改幾個設置
而是真的讓它做一個完整的項目
那會發生什麼呢？
所以我想給它一個真的任務
剛好這幾天，我一直在關注 Jev
如果你還不知道 Jev 是什麼
這裡呢你也暫時不用管它的技術原理
你只需要知道，Jev 開放以後
X 上就很快出現了大量開發者做出來的實驗和項目
有人把它接進 Coding Agent
有人拿它做瀏覽器操作、工具選擇、模型路由
也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情
問題是，這些東西散得到處都是
有些在 X 的帖子里
有些藏在 GitHub 里
有些有自己的網站
還有一些你可能今天刷到一次
過兩天想找就已經找不到了
所以我冒出了一個很簡單的想法：
就是能不能把這些正在出現的 Jev 項目
整理成一張地圖呢？
我想要的是一個以後還能繼續生長的東西——項目有真實的來源
能搜索、能分類；
如果以後發現新的項目
還可以繼續加進去；
然後最好打開首頁的時候
還能直接看到這個生態到底長成了什麼樣子
於是我把這個想法交給了 Codex
我來決定方向和品味，Codex負責乾活
比如這個網站
我最後把它叫作 Jev Atlas
我希望首頁最顯眼的不是一堆項目卡片
而是一張 Obsidian 那樣的關係圖
我還有一個要求：
就是這張圖不能是裝飾
如果屏幕上有一個節點
它就必須對應真實的數據
如果兩個節點之間有一條線
也必須真的存在關係
所以最後這張圖里的連接
全部來自真實的項目數據
這也是為什麼你現在看到它的時候
會覺得這張圖好像一直在“長”。
因為它呢不是預先畫死的一張背景圖
這張圖本身也會跟著變化
點擊分類
星圖上對應的區域就會點亮
做到這裡
其實一個普通的 AI Demo 已經可以結束了
但這恰恰是我不想停下來的地方
因為只要它還運行在 localhost
這件事本質上仍然只是發生在我的電腦里
我真正想測試的是下一步
也就是：這台電腦里的 Agent
能不能自己把剛剛完成的工作
送到真實的互聯網上呢？
這一步聽起來好像只是“部署一個網站”，
但對於我來說
它其實是整個實驗里很關鍵的一步
因為在 localhost 裡面
一切都很安全——代碼寫壞了
可以重來；
頁面打不開，可以繼續改；
哪怕整個項目跑不起來
也只是影響到我自己的這台電腦
可一旦你把它發佈到互聯網上
事情就不一樣了
它要面對真實的服務器環境、真實的構建過程、真實的運行日誌
最後
還有一個所有人都能打開的網址
也就是說，從這裡開始
Codex 做的就不再只是一個本地 Demo 了
它要真的把一個結果交付出去
而這一層
過去經常意味著你得去碰雲服務商的管理後台
說實話
我自己並不喜歡這些流程式的操作
打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值
但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼
我就會開始想：
為什麼到了服務器這裡
我又要重新變回那個點菜單的人呢？
我後來咨詢了自己的雲服務商 Hostinger
剛好發現他們有一個叫 Hostinger Connector 的東西
它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent
授權也很簡單
通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來
不需要自己折騰 API Key
我這次的測試用的是 Hostinger 的 Web App Hosting 套餐
這也是他們在這次 Connector 流程里推薦的方案
那如果你自己也想試試
可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面
點擊這裡，輸入優惠碼 WOWINSIGHT
就能拿到對應的折扣
好、那以前呢如果我要把這樣一個項目部署出去
最常規的方式當然還是打開網頁後台、上傳文件、配置 Node
js，確認入口文件
然後再去看部署狀態
你現在畫面里看到的這些截圖
其實就是我前面手動配置時留下來的
為了和後面 Codex 自己運維網站做個對比
我特意把它們保留了下來
其實呢這些事情本身並不難
但這一次不一樣了
所以我想試試看
我是不是只需要面對自己的 Agent
就能把後面的事情做完
既然我已經有了一台所謂的 AI-native computer
那服務器這一邊
能不能也直接變成 Agent 工作環境的一部分呢？
所以我先把 Hostinger 官方的 MCP 接進 Codex
然後通過瀏覽器完成授權
接上以後
它看到的就不再只是我這台 M1 上的文件
它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs
比如我只需要問一句：「查看 Hostinger Connector (MCP) 有哪些功能？
」
”
Codex 就會直接把當前可用的能力列出來
我這裡一共能看到 74 個工具
我不會在這裡把 74 個工具一個一個念給你聽
你只需要知道
像網站、域名、SSL、Node.
js、靜態站點
js、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力
基本上都已經在裡面了
而且 Codex 還可以直接告訴我：
為了部署 Jev Atlas
它實際調用過哪些工具
我覺得呢雲服務商能配套這些功能
其實是很重要的
因為在沒有 MCP 的時候
Codex 寫完代碼，到了“上線”這一步
工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去
如果出了問題
我還要再把錯誤信息複製回來告訴它
人在中間一直充當著那個搬運信息的人
這其實也是 Hostinger Connector (MCP) 對我最有價值的地方
它讓我不用離開現在這個 Agent 的工作環境
就能處理網站部署和運維的事情
網站上線以後
SSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了
有了 MCP 以後
這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；
確認以後
它可以繼續調用 Hostinger Connector (MCP)，
把同一個項目送到服務器
在這裡呀我更想告訴你我的實際體驗！
就是你不需要先學會 Hostinger 後台所有的菜單
你哪裡不明白
你就直接問 Codex 就好了
不過，這裡我還是要提醒一句：
在真正部署之前
我仍然還是讓 Codex 先把本地版本完整的檢查了一遍
不是簡單看一眼首頁能不能打開那種哦
我是讓它真的用瀏覽器去操作和檢查
到了這裡
到了這裡，我們手裡已經有一個本地可以正常工作的版本了——它有 171 個項目、569 個節點、和 701 條真實關係
搜索可以用
圖譜里的連接來自真實數據
數據也能正常加載
本地測試通過，於是我告訴 Codex：
把它部署到 Hostinger
不過第一次請求呢甚至還沒有真正走到構建
網絡連接在 TLS 階段斷了一次
Codex 拿到錯誤以後
又重新試了一次
第二次，文件成功上傳
Build 也成功了
當時看起來，一切都很順利
然後我打開那個網址，顯示的卻是503
這個時候
這個實驗才真正開始變得有意思
因為接下來
我沒有去登錄服務器後台查問題
我也沒有把 503 截圖丟給 Codex
然後自己到處找日誌
我只是繼續看著它
服務器明明告訴它 Build completed
為什麼網站還是掛了呢？
下一步
就輪到這台 MacOmarchy 自己去找答案了
Codex 直接通過 Hostinger Connector (MCP) 去讀取這次部署的 Runtime Logs
很快就找到了一行錯誤：
問題也很快被定位到了項目根目錄的 app
js
它修的過程很快，我們就略過吧！
這裡
我覺得關鍵的已經不是這個錯誤本身了
而是它找到問題以後
接下來還可以繼續往下做
修改完成以後
Codex 先在這台 M1 上把 Jev Atlas 重新跑起來
再用瀏覽器檢查頁面、數據、圖譜和搜索
確認本地沒有問題之後
它才再次通過 Hostinger Connector 發起部署
但它沒有停在“部署成功”這幾個字上
Codex 接著打開真正公開的 Jev Atlas
把頁面加載、搜索和數據讀取重新檢查了一遍
到這裡，這個實驗才真正閉環了：
在本地做出來，送到服務器；
線上出錯以後自己讀日誌
回到本地修復
再重新部署，最後去公開網站驗收
也就是從這一刻開始
我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了
它開始能夠把本地的工作
真正延伸到外面的服務和互聯網
現在整個過程走完以後
我想解釋一下，為什麼我會覺得
這才開始像一台 AI-native computer
因為真正發生變化的
並不是這台 M1 突然變快了
也不是它多了什麼新的硬件能力
其實真正變掉的
是我和這台電腦相處的方式
前面連接 Magic Mouse 的時候
我已經有過一次這種感覺了
到了 Jev Atlas 的時候
這種變化呢就更明顯了
一開始
我只是讓 Codex 把網站做出來、跑起來
再通過 Hostinger Connector (MCP) 把它送到互聯網上
但網站真正上線以後
我馬上又碰到了一個更現實的問題：
就是 Jev 生態還在不斷出現新的項目
那這個網站以後誰來維護呢？
所以我又往前走了一步
把 Jev 本身也放進了維護流程
它負責的事情其實很簡單
普通代碼先處理那些完全可以確定的重復；
如果新項目和現有項目之間真的出現了一個“看起來很像”的對象
那再讓 Jev 判斷它們到底是什麼關係；
只有更模糊和更複雜的例外
才繼續交給 Codex
我呢就先拿了一批昨天的真實數據跑了一次
原本需要 Codex 深度閱讀的項目有 13 個
把這套流程加進去以後
最後只剩下 1 個
而且不只是 Codex 少看了幾個項目
同一輪處理的總時間
也從大約 36.
9 秒
降到了 10.
2 秒
這不是一個嚴格的 benchmark
但差別已經非常明顯
以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；
而現在大部分的簡單情況
在前面就已經被處理掉了
接下來
我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里
然後
又拿一輪全新的 Grok 增量調查真正跑了一次
這一次一共有 28 個候選身份
最後真正需要 Codex 深度檢查的
只有 3 個
而到了這一步
我實際上要做的事情反而越來越少了
你看啊：第一步
讓 Grok 去找新的 Jev 項目
第二步，把最新的調查交給 Codex
讓它按照 Jev Atlas 自己的維護流程
也就是已經包含 Jev 調用的這套流程
去查重、篩選、判斷
再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認
我審核完以後
只需要告訴它一句：「應用這次審核通過的更新
我在本地預覽一下
”
Codex 就會把更新寫進去
重新跑驗證
再把本地版本打開給我看
本地確認沒問題
我再說一句：「發佈到 Hostinger
”
後面的提交、部署、Build、Runtime Logs
再到公開網站的檢查
就沿著我們前面已經搭好的這條鏈繼續走下去
最後
我又去 Hostinger 上已經公開的網站重新驗收了一遍
最開始呢，這個網站只有 171 個項目
而現在，它已經變成了 200 個項目
剛開始
我只是覺得這台舊電腦跑 Omarchy 很有意思
但現在，它真的進入了我的工作流
我前面的視頻里
我已經試過 ThinkPad X230i
也試過呢用 Dell 台式機跑 Omarchy
而現在呢
蘋果電腦也能跑 Omarchy 了！
其實這些硬件門檻都不高
你完全可以自己去試一試
那麼所以
我們未來真正需要重新設計的
到底是“應用”，
還是整台電腦的工作方式呢？
那今天就聊到這裡啦
那如果你喜歡這支影片的話
就記得幫我訂閱按贊分享
我們就下一支影片再見囉，拜拜