WEBVTT
Kind: captions
Language: zh

00:00:11.233 --> 00:00:12.766
你現在看到的這個網站

00:00:12.766 --> 00:00:14.000
叫 Jev Atlas

00:00:14.100 --> 00:00:16.866
它裡面收集了上百個真實的 Jev 項目

00:00:16.900 --> 00:00:18.433
你可以直接搜索一個項目

00:00:18.433 --> 00:00:20.533
也可以按照不同的分類去找

00:00:20.700 --> 00:00:21.833
更有意思的是

00:00:21.833 --> 00:00:24.400
網站背後這張不斷變化的圖

00:00:24.400 --> 00:00:30.933
並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類

00:00:30.933 --> 00:00:32.366
都來自真實的數據

00:00:32.633 --> 00:00:35.633
它們之間有關係，才會在圖上連起來

00:00:35.933 --> 00:00:37.866
但今天我真正想講的

00:00:37.900 --> 00:00:39.366
其實不是這個網站

00:00:39.366 --> 00:00:43.400
而是呢做出這個網站的這台 MacOmarchy 電腦

00:00:43.800 --> 00:00:44.800
在視頻的後面

00:00:44.800 --> 00:00:50.600
我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了

00:00:50.600 --> 00:00:52.633
它真的能提高工作效率嗎？

00:00:53.200 --> 00:00:54.600
話說在幾天之前

00:00:54.600 --> 00:00:58.233
我把一台已經閒置的 M1 Mac mini 找了出來

00:00:58.233 --> 00:00:59.933
在上面裝了 Omarchy

00:01:00.133 --> 00:01:01.366
對這台舊電腦

00:01:01.433 --> 00:01:04.400
我當時呢也沒對它抱太大的希望

00:01:04.566 --> 00:01:07.933
但是，結果完全出乎我的意料

00:01:08.033 --> 00:01:12.633
我剛剛才把平時用的 Mac Studio 升級到 macOS 27

00:01:12.833 --> 00:01:13.866
按理來說

00:01:13.900 --> 00:01:16.533
最應該讓我喊一聲“Wow”的應該是它

00:01:16.733 --> 00:01:20.466
可這幾天真正讓我一邊用、一邊不斷喊“Wow”的

00:01:20.500 --> 00:01:24.233
反而是這台舊 M1 上跑起來的 MacOmarchy

00:01:24.633 --> 00:01:26.966
後來我在 X 上發了一條帖子

00:01:26.966 --> 00:01:28.333
我說：“幾天前

00:01:28.333 --> 00:01:32.033
我用馬塞洛（Marcelo）開發的 Omarchy MX Mac

00:01:32.033 --> 00:01:35.700
讓一台舊 M1 Mac mini 獲得了第二次生命

00:01:35.833 --> 00:01:38.633
現在又看到 ChatGPT 來到 Linux

00:01:38.800 --> 00:01:40.900
感覺這個時間點剛剛好

00:01:41.166 --> 00:01:41.966
沒想到

00:01:42.233 --> 00:01:46.266
Omarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了

00:01:46.300 --> 00:01:48.966
他不但回應了這條帖子，還轉發了它

00:01:49.433 --> 00:01:50.300
當時我說

00:01:50.300 --> 00:01:53.733
我好像給這台舊 M1 找到了第二次生命

00:01:53.733 --> 00:01:56.833
但那時候，這其實還只是一種感覺

00:01:57.033 --> 00:01:59.866
裝一個很酷的系統，讓 Codex 跑起來

00:01:59.900 --> 00:02:01.833
讓 AI 可以在裡面工作

00:02:01.833 --> 00:02:04.133
這些當然都是很有意思的

00:02:04.133 --> 00:02:06.733
可一台所謂的“AI-native computer”，

00:02:06.733 --> 00:02:10.666
如果最後只是讓我多了幾個和 AI 聊天的窗口

00:02:10.700 --> 00:02:12.300
好像又差了點什麼

00:02:12.366 --> 00:02:13.400
所以這幾天

00:02:13.400 --> 00:02:15.533
我真的給它安排了一份工作

00:02:15.733 --> 00:02:18.466
那這期視頻呢是由 Hostinger 贊助的

00:02:18.500 --> 00:02:28.000
而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台

00:02:28.000 --> 00:02:32.600
就直接把 Agent 在本地完成的工作送到真實的互聯網

00:02:32.800 --> 00:02:35.433
我沒有讓 Codex 給我寫一個 Todo List

00:02:35.700 --> 00:02:41.500
也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo

00:02:41.566 --> 00:02:43.933
我給了它一個真的項目，就是呢：

00:02:43.933 --> 00:02:49.433
我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來

00:02:49.433 --> 00:02:55.400
做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站

00:02:55.633 --> 00:03:01.700
那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站

00:03:01.766 --> 00:03:04.400
再自己打開瀏覽器檢查結果

00:03:04.400 --> 00:03:04.966
後來

00:03:04.966 --> 00:03:07.133
它又通過 Hostinger Connector(MCP)，

00:03:07.133 --> 00:03:10.033
把網站真正部署到了互聯網上

00:03:10.433 --> 00:03:14.200
整個過程從想法、到代碼、到部署到互聯網

00:03:14.200 --> 00:03:15.600
也就半天的時間

00:03:15.766 --> 00:03:18.033
然後我又在 X 上發了一條推文

00:03:18.033 --> 00:03:20.033
我說：“那台舊 M1 Mac mini

00:03:20.033 --> 00:03:21.400
現在有工作了

00:03:21.400 --> 00:03:23.133
它運行著 Omarchy

00:03:23.166 --> 00:03:29.433
我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖

00:03:29.500 --> 00:03:32.366
每個項目都鏈接到真實的來源

00:03:32.366 --> 00:03:33.533
還可以搜索

00:03:33.533 --> 00:03:37.233
並通過一張實時動態圖展示整個生態

00:03:37.566 --> 00:03:40.600
Codex 完成了網站的構建和測試

00:03:40.600 --> 00:03:44.200
通過 Hostinger MCP 把它部署到互聯網上

00:03:44.233 --> 00:03:48.366
然後又對公開網站進行了驗證——整個過程

00:03:48.366 --> 00:03:51.766
都是從這台 M1 上完成和調度的

00:03:51.933 --> 00:03:53.133
這開始讓我覺得

00:03:53.133 --> 00:03:56.633
這才像是一台 AI 原生電腦（AI-native computer）該有的樣子

00:03:57.000 --> 00:03:59.800
所以這期視頻，我們就從頭看看

00:03:59.800 --> 00:04:03.733
這台被我叫作 MacOmarchy 的 AI-native computer

00:04:03.733 --> 00:04:06.133
到底是怎麼開始真正乾活的

00:04:06.566 --> 00:04:07.533
其實一開始

00:04:07.533 --> 00:04:11.300
我並沒有打算讓這台 M1 做什麼特別複雜的事情

00:04:11.333 --> 00:04:12.566
我只是很好奇

00:04:12.566 --> 00:04:17.033
當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後

00:04:17.033 --> 00:04:18.766
它到底會有什麼不一樣？

00:04:19.000 --> 00:04:21.700
很快，我就碰到了一個很小的問題

00:04:22.033 --> 00:04:27.133
就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下

00:04:27.300 --> 00:04:29.433
我不想專門跑下去拿

00:04:29.800 --> 00:04:32.233
書桌上倒是有一隻 Magic Mouse

00:04:32.233 --> 00:04:33.666
但問題就變成了：

00:04:33.700 --> 00:04:37.033
我怎麼把它連到這台 MacOmarchy 上呢？

00:04:37.333 --> 00:04:38.600
Omarchy 本身的設計

00:04:38.600 --> 00:04:42.166
其實已經刻意減少了很多對鼠標的依賴

00:04:42.166 --> 00:04:45.333
很多操作直接用鍵盤就能完成

00:04:45.500 --> 00:04:47.966
但是，如果真要選一段文字

00:04:47.966 --> 00:04:49.866
或者做一些細一點的操作

00:04:49.900 --> 00:04:51.566
我還是覺得鼠標方便

00:04:51.766 --> 00:04:53.366
所以我想到了 Codex

00:04:53.533 --> 00:04:56.033
我按下 Ctrl + 回車打開終端

00:04:56.033 --> 00:04:57.133
輸入 Codex

00:04:57.200 --> 00:05:00.900
然後直接告訴它：幫我把這只 Magic Mouse 連上

00:05:01.100 --> 00:05:06.033
接下來它自己去掃描藍牙設備、添加設備、完成連接

00:05:06.366 --> 00:05:07.633
鼠標連上以後

00:05:07.633 --> 00:05:10.266
我又發現指針移動得太快了

00:05:10.266 --> 00:05:13.333
和我平時在 macOS 上的手感差很多

00:05:13.533 --> 00:05:15.200
我就繼續告訴 Codex

00:05:15.233 --> 00:05:16.766
讓它把速度降下來

00:05:16.833 --> 00:05:18.333
然後還有滾動方向

00:05:18.333 --> 00:05:21.700
我不喜歡那種更像 Windows 的反向滾動習慣

00:05:21.933 --> 00:05:25.333
所以也讓它一起調成我平時用 Mac 的感覺

00:05:25.700 --> 00:05:28.233
整個過程，我當時就覺得很有意思

00:05:28.400 --> 00:05:32.166
因為呢如果是在傳統的電腦使用方式裡面

00:05:32.166 --> 00:05:38.800
我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向

00:05:39.000 --> 00:05:41.500
那套界面本來就是給人設計的

00:05:41.533 --> 00:05:42.666
但對 AI 來說

00:05:42.700 --> 00:05:47.333
它其實根本就不需要先學會在屏幕上找到那個藍牙圖標

00:05:47.500 --> 00:05:49.900
再模擬我去點哪個按鈕

00:05:49.966 --> 00:05:52.333
它可以直接和系統本身打交道

00:05:52.566 --> 00:05:53.833
對我們人來說

00:05:54.633 --> 00:05:56.533
瀏覽、點擊、拖動當然很自然

00:05:56.566 --> 00:05:59.366
但對 AI 來說，屏幕上的這些按鈕

00:05:59.366 --> 00:06:01.833
很多時候反而只是繞了一層

00:06:02.100 --> 00:06:04.733
這一下就讓我第一次很明顯地感覺到

00:06:04.733 --> 00:06:07.600
這台舊 M1 和我其他幾台蘋果電腦

00:06:07.600 --> 00:06:10.033
好像開始有了一點不一樣了

00:06:10.200 --> 00:06:11.866
但就是這個很小的體驗

00:06:11.900 --> 00:06:13.033
就讓我開始想：

00:06:13.100 --> 00:06:16.400
如果這台電腦不只是幫我改幾個設置

00:06:16.400 --> 00:06:19.200
而是真的讓它做一個完整的項目

00:06:19.200 --> 00:06:20.600
那會發生什麼呢？

00:06:20.833 --> 00:06:22.933
所以我想給它一個真的任務

00:06:22.933 --> 00:06:25.600
剛好這幾天，我一直在關注 Jev

00:06:25.733 --> 00:06:27.566
如果你還不知道 Jev 是什麼

00:06:27.566 --> 00:06:30.333
這裡呢你也暫時不用管它的技術原理

00:06:30.333 --> 00:06:32.633
你只需要知道，Jev 開放以後

00:06:32.633 --> 00:06:37.433
X 上就很快出現了大量開發者做出來的實驗和項目

00:06:37.433 --> 00:06:40.033
有人把它接進 Coding Agent

00:06:40.033 --> 00:06:44.233
有人拿它做瀏覽器操作、工具選擇、模型路由

00:06:44.300 --> 00:06:50.366
也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情

00:06:50.600 --> 00:06:53.833
問題是，這些東西散得到處都是

00:06:53.900 --> 00:06:55.366
有些在 X 的帖子里

00:06:55.366 --> 00:06:57.066
有些藏在 GitHub 里

00:06:57.100 --> 00:06:58.733
有些有自己的網站

00:06:58.733 --> 00:07:01.166
還有一些你可能今天刷到一次

00:07:01.166 --> 00:07:03.533
過兩天想找就已經找不到了

00:07:03.600 --> 00:07:05.666
所以我冒出了一個很簡單的想法：

00:07:05.700 --> 00:07:09.166
就是能不能把這些正在出現的 Jev 項目

00:07:09.166 --> 00:07:10.933
整理成一張地圖呢？

00:07:11.233 --> 00:07:16.400
我想要的是一個以後還能繼續生長的東西——項目有真實的來源

00:07:16.400 --> 00:07:18.233
能搜索、能分類；

00:07:18.233 --> 00:07:19.766
如果以後發現新的項目

00:07:19.766 --> 00:07:21.433
還可以繼續加進去；

00:07:21.433 --> 00:07:23.733
然後最好打開首頁的時候

00:07:23.733 --> 00:07:27.500
還能直接看到這個生態到底長成了什麼樣子

00:07:27.733 --> 00:07:30.166
於是我把這個想法交給了 Codex

00:07:30.233 --> 00:07:33.800
我來決定方向和品味，Codex負責乾活

00:07:33.966 --> 00:07:35.133
比如這個網站

00:07:35.133 --> 00:07:37.533
我最後把它叫作 Jev Atlas

00:07:37.700 --> 00:07:41.033
我希望首頁最顯眼的不是一堆項目卡片

00:07:41.033 --> 00:07:43.933
而是一張 Obsidian 那樣的關係圖

00:07:44.100 --> 00:07:45.166
我還有一個要求：

00:07:45.166 --> 00:07:47.200
就是這張圖不能是裝飾

00:07:47.733 --> 00:07:49.333
如果屏幕上有一個節點

00:07:49.333 --> 00:07:51.833
它就必須呢對應真實的數據；

00:07:51.833 --> 00:07:53.733
如果兩個節點之間有一條線

00:07:53.933 --> 00:07:56.100
也必須呢真的存在關係

00:07:56.500 --> 00:07:58.766
所以最後這張圖里的連接

00:07:58.766 --> 00:08:01.000
全部來自真實的項目數據

00:08:01.233 --> 00:08:03.666
這也是為什麼你現在看到它的時候

00:08:03.700 --> 00:08:06.000
會覺得這張圖好像一直在“長”。

00:08:06.233 --> 00:08:13.000
因為它呢不是預先畫死的一張背景圖——隨著項目的增加、數據的變化

00:08:13.000 --> 00:08:15.233
這張圖本身也會跟著變化

00:08:15.566 --> 00:08:16.600
點擊分類

00:08:16.600 --> 00:08:18.933
星圖上對應的區域就會點亮

00:08:19.333 --> 00:08:20.133
做到這裡

00:08:20.233 --> 00:08:23.200
其實一個普通的 AI Demo 已經可以結束了

00:08:23.200 --> 00:08:25.900
但這恰恰是我不想停下來的地方

00:08:25.933 --> 00:08:28.833
因為只要它還運行在 localhost

00:08:28.833 --> 00:08:32.333
這件事本質上仍然只是發生在我的電腦里

00:08:32.433 --> 00:08:34.333
我真正想測試的是下一步

00:08:34.333 --> 00:08:36.666
也就是：這台電腦里的 Agent

00:08:36.700 --> 00:08:38.966
能不能自己把剛剛完成的工作

00:08:38.966 --> 00:08:40.966
送到真實的互聯網上呢？

00:08:41.333 --> 00:08:44.133
這一步聽起來好像只是“部署一個網站”，

00:08:44.133 --> 00:08:45.333
但對於我來說

00:08:45.333 --> 00:08:48.366
它其實是整個實驗里很關鍵的一步

00:08:48.433 --> 00:08:49.933
因為在 localhost 裡面

00:08:49.933 --> 00:08:52.466
一切都很安全——代碼寫壞了

00:08:52.466 --> 00:08:53.400
可以重來；

00:08:53.400 --> 00:08:55.433
頁面打不開，可以繼續改；

00:08:55.433 --> 00:08:57.766
哪怕整個項目跑不起來

00:08:57.766 --> 00:09:00.033
也只是影響到我自己的這台電腦

00:09:00.500 --> 00:09:03.166
可一旦你把它發佈到互聯網上

00:09:03.166 --> 00:09:04.633
事情就不一樣了

00:09:04.700 --> 00:09:10.200
它要面對真實的服務器環境、真實的構建過程、真實的運行日誌

00:09:10.200 --> 00:09:11.000
最後

00:09:11.000 --> 00:09:13.900
還有一個所有人都能打開的網址

00:09:14.033 --> 00:09:15.766
也就是說，從這裡開始

00:09:15.766 --> 00:09:18.733
Codex 做的就不再只是一個本地 Demo 了

00:09:18.733 --> 00:09:21.133
它要真的把一個結果交付出去

00:09:21.300 --> 00:09:22.333
而這一層

00:09:22.333 --> 00:09:26.966
過去經常意味著你得去碰雲服務商的管理後台

00:09:27.366 --> 00:09:28.033
說實話

00:09:28.033 --> 00:09:31.033
我自己並不喜歡這些流程式的操作

00:09:31.100 --> 00:09:39.200
打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值

00:09:39.200 --> 00:09:43.666
但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼

00:09:43.700 --> 00:09:44.833
我就會開始想：

00:09:44.833 --> 00:09:46.533
為什麼到了服務器這裡

00:09:46.533 --> 00:09:49.366
我又要重新變回那個點菜單的人呢？

00:09:49.633 --> 00:09:52.366
我後來咨詢了自己的雲服務商 Hostinger

00:09:52.366 --> 00:09:56.433
剛好發現他們有一個叫 Hostinger Connector 的東西

00:09:56.766 --> 00:10:01.800
它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent

00:10:02.100 --> 00:10:03.366
授權也很簡單

00:10:03.366 --> 00:10:07.866
通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來

00:10:07.900 --> 00:10:09.933
不需要自己折騰 API Key

00:10:09.933 --> 00:10:14.333
我這次的測試用的是 Hostinger 的 Web App Hosting 套餐

00:10:14.533 --> 00:10:17.700
這也是他們在這次 Connector 流程里推薦的方案

00:10:17.766 --> 00:10:19.366
那如果你自己也想試試

00:10:19.366 --> 00:10:24.633
可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面

00:10:25.033 --> 00:10:27.533
點擊這裡，輸入優惠碼 WOWINSIGHT

00:10:27.533 --> 00:10:29.166
就能拿到對應的折扣

00:10:29.333 --> 00:10:33.333
好、那以前呢如果我要把這樣一個項目部署出去

00:10:33.333 --> 00:10:39.100
最常規的方式當然還是打開網頁後台、上傳文件、配置 Node

00:10:39.100 --> 00:10:41.166
js，確認入口文件

00:10:41.166 --> 00:10:42.800
然後再去看部署狀態

00:10:43.200 --> 00:10:45.566
你現在畫面里看到的這些截圖

00:10:45.566 --> 00:10:48.400
其實就是我前面手動配置時留下來的

00:10:48.433 --> 00:10:51.966
為了和後面 Codex 自己運維網站做個對比

00:10:51.966 --> 00:10:53.900
我特意把它們保留了下來

00:10:54.233 --> 00:10:56.933
其實呢這些事情本身並不難

00:10:56.933 --> 00:10:58.466
但這一次不一樣了

00:10:58.500 --> 00:10:59.766
所以我想試試看

00:10:59.766 --> 00:11:02.633
我是不是只需要面對自己的 Agent

00:11:02.633 --> 00:11:04.500
就能把後面的事情做完

00:11:04.933 --> 00:11:08.066
既然我已經有了一台所謂的 AI-native computer

00:11:08.100 --> 00:11:09.400
那服務器這一邊

00:11:09.400 --> 00:11:13.200
能不能也直接變成 Agent 工作環境的一部分呢？

00:11:13.500 --> 00:11:17.300
所以我先把 Hostinger 官方的 MCP 接進 Codex

00:11:17.366 --> 00:11:19.833
然後通過瀏覽器完成授權

00:11:20.133 --> 00:11:21.000
接上以後

00:11:21.000 --> 00:11:24.600
它看到的就不再只是我這台 M1 上的文件

00:11:24.733 --> 00:11:33.633
它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs

00:11:33.933 --> 00:11:38.266
比如我只需要問一句：“查看 Hostinger Connector(MCP) 有哪些功能？

00:11:38.266 --> 00:11:38.633
”

00:11:38.633 --> 00:11:42.566
Codex 就會直接把當前可用的能力列出來

00:11:42.633 --> 00:11:45.000
我這裡一共能看到 74 個工具

00:11:45.200 --> 00:11:49.200
我不會在這裡把 74 個工具一個一個念給你聽

00:11:49.300 --> 00:11:50.266
你只需要知道

00:11:50.300 --> 00:11:53.566
像網站、域名、SSL、Node

00:11:53.566 --> 00:12:02.933
js、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力

00:12:02.933 --> 00:12:04.666
基本上都已經在裡面了

00:12:04.666 --> 00:12:07.300
而且 Codex 還可以直接告訴我：

00:12:07.300 --> 00:12:09.200
為了部署 Jev Atlas

00:12:09.200 --> 00:12:11.566
它實際調用過哪些工具

00:12:11.566 --> 00:12:14.633
我覺得呢雲服務商能配套這些功能

00:12:14.633 --> 00:12:16.266
其實是很重要的

00:12:16.266 --> 00:12:18.033
因為在沒有 MCP 的時候

00:12:18.033 --> 00:12:20.633
Codex 寫完代碼，到了“上線”這一步

00:12:20.633 --> 00:12:27.933
工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去

00:12:28.000 --> 00:12:29.000
如果出了問題

00:12:29.133 --> 00:12:32.333
我還要再把錯誤信息複製回來告訴它

00:12:32.533 --> 00:12:36.466
人在中間一直充當著那個搬運信息的人

00:12:36.833 --> 00:12:40.866
這其實也是 Hostinger Connector (MCP) 對我最有價值的地方

00:12:41.033 --> 00:12:44.666
它讓我不用離開現在這個 Agent 的工作環境

00:12:44.666 --> 00:12:48.166
就能處理網站部署和運維的事情

00:12:48.366 --> 00:12:49.633
網站上線以後

00:12:49.633 --> 00:12:58.000
SSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了

00:12:58.033 --> 00:12:59.400
有了 MCP 以後

00:12:59.666 --> 00:13:06.133
這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；

00:13:06.233 --> 00:13:06.966
確認以後

00:13:06.966 --> 00:13:10.000
它可以繼續調用 Hostinger Connector (MCP)，

00:13:10.000 --> 00:13:12.533
把同一個項目送到服務器

00:13:12.866 --> 00:13:16.166
在這裡呀我更想告訴你我的實際體驗！

00:13:16.366 --> 00:13:20.200
就是你不需要先學會 Hostinger 後台所有的菜單

00:13:20.266 --> 00:13:21.366
你哪裡不明白

00:13:21.366 --> 00:13:23.366
你就直接問 Codex 就好了

00:13:23.533 --> 00:13:26.000
不過，這裡我還是要提醒一句：

00:13:26.000 --> 00:13:27.633
在真正部署之前

00:13:27.633 --> 00:13:32.900
我仍然還是讓 Codex 先把本地版本完整的檢查了一遍

00:13:32.933 --> 00:13:35.866
不是簡單看一眼首頁能不能打開那種哦

00:13:35.866 --> 00:13:39.666
我是讓它真的用瀏覽器去操作和檢查

00:13:39.933 --> 00:13:40.733
到了這裡

00:13:40.733 --> 00:13:49.800
我們手裡已經有一個本地可以正常工作的版本了——它有171 個項目、569 個節點、和 701 條真實關係

00:13:50.200 --> 00:13:51.333
搜索可以用

00:13:51.333 --> 00:13:53.733
圖譜里的連接來自真實數據

00:13:53.733 --> 00:13:55.666
數據也能正常加載

00:13:55.833 --> 00:13:58.266
本地測試通過，於是我告訴 Codex：

00:13:58.266 --> 00:13:59.900
把它部署到 Hostinger

00:14:00.000 --> 00:14:03.733
不過第一次請求呢甚至還沒有真正走到構建

00:14:03.933 --> 00:14:07.533
網絡連接在 TLS 階段斷了一次

00:14:07.566 --> 00:14:09.200
Codex 拿到錯誤以後

00:14:09.200 --> 00:14:10.666
又重新試了一次

00:14:11.033 --> 00:14:13.000
第二次，文件成功上傳

00:14:13.133 --> 00:14:14.266
Build 也成功了

00:14:14.266 --> 00:14:16.433
當時看起來，一切都很順利

00:14:16.433 --> 00:14:19.800
然後我打開那個網址，顯示的卻是503

00:14:20.266 --> 00:14:21.066
這個時候

00:14:21.133 --> 00:14:23.800
這個實驗才真正開始變得有意思

00:14:23.866 --> 00:14:24.866
因為接下來

00:14:24.866 --> 00:14:27.766
我沒有去登錄服務器後台查問題

00:14:28.033 --> 00:14:30.700
我也沒有把 503 截圖丟給 Codex

00:14:30.733 --> 00:14:32.533
然後自己到處找日誌

00:14:32.533 --> 00:14:34.166
我只是繼續看著它

00:14:34.466 --> 00:14:37.133
服務器明明告訴它 Build completed

00:14:37.200 --> 00:14:39.100
為什麼網站還是掛了呢？

00:14:39.200 --> 00:14:39.866
下一步

00:14:39.866 --> 00:14:43.133
就輪到這台 MacOmarchy 自己去找答案了

00:14:43.366 --> 00:14:49.066
Codex 直接通過 Hostinger Connector（MCP）去讀取這次部署的 Runtime Logs

00:14:49.066 --> 00:14:50.733
很快就找到了一行錯誤：

00:14:51.033 --> 00:14:55.033
問題也很快被定位到了項目根目錄的 app

00:14:55.033 --> 00:14:55.800
js

00:14:56.133 --> 00:14:58.366
它修的過程很快，我們就略過吧！

00:14:58.466 --> 00:14:59.033
這裡

00:14:59.033 --> 00:15:02.000
我覺得關鍵的已經不是這個錯誤本身了

00:15:02.000 --> 00:15:04.000
而是它找到問題以後

00:15:04.000 --> 00:15:06.000
接下來還可以繼續往下做

00:15:06.366 --> 00:15:07.433
修改完成以後

00:15:07.433 --> 00:15:12.166
Codex 先在這台 M1 上把 Jev Atlas 重新跑起來

00:15:12.166 --> 00:15:16.600
再用瀏覽器檢查頁面、數據、圖譜和搜索

00:15:16.633 --> 00:15:18.266
確認本地沒有問題之後

00:15:18.266 --> 00:15:22.100
它才再次通過 Hostinger Connector 發起部署

00:15:22.433 --> 00:15:25.366
但它沒有停在“部署成功”這幾個字上

00:15:25.466 --> 00:15:29.166
Codex 接著打開真正公開的 Jev Atlas

00:15:29.200 --> 00:15:33.800
把頁面加載、搜索和數據讀取重新檢查了一遍

00:15:34.133 --> 00:15:36.966
到這裡，這個實驗才真正閉環了：

00:15:36.966 --> 00:15:39.200
在本地做出來，送到服務器；

00:15:39.366 --> 00:15:41.866
線上出錯以後自己讀日誌

00:15:41.866 --> 00:15:43.033
回到本地修復

00:15:43.033 --> 00:15:46.700
再重新部署，最後去公開網站驗收

00:15:47.000 --> 00:15:48.566
也就是從這一刻開始

00:15:48.566 --> 00:15:54.433
我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了

00:15:54.433 --> 00:15:56.566
它開始能夠把本地的工作

00:15:56.566 --> 00:15:59.300
真正延伸到外面的服務和互聯網

00:15:59.433 --> 00:16:01.366
現在整個過程走完以後

00:16:01.366 --> 00:16:03.866
我想解釋一下，為什麼我會覺得

00:16:03.866 --> 00:16:07.166
這才開始像一台 AI-native computer

00:16:07.600 --> 00:16:09.666
因為真正發生變化的

00:16:09.666 --> 00:16:11.866
並不是這台 M1 突然變快了

00:16:11.866 --> 00:16:14.466
也不是它多了什麼新的硬件能力

00:16:14.566 --> 00:16:16.100
其實真正變掉的

00:16:16.100 --> 00:16:18.866
是我和這台電腦相處的方式

00:16:19.066 --> 00:16:21.200
前面連接 Magic Mouse 的時候

00:16:21.233 --> 00:16:23.366
我已經有過一次這種感覺了

00:16:23.366 --> 00:16:25.066
到了 Jev Atlas 的時候

00:16:25.200 --> 00:16:27.366
這種變化呢就更明顯了

00:16:27.433 --> 00:16:28.200
一開始

00:16:28.200 --> 00:16:31.600
我只是讓 Codex 把網站做出來、跑起來

00:16:31.600 --> 00:16:35.333
再通過 Hostinger Connector(MCP) 把它送到互聯網上

00:16:35.366 --> 00:16:37.733
但網站真正上線以後

00:16:37.733 --> 00:16:40.033
我馬上又碰到了一個更現實的問題：

00:16:40.033 --> 00:16:43.733
就是 Jev 生態還在不斷出現新的項目

00:16:43.733 --> 00:16:45.966
那這個網站以後誰來維護呢？

00:16:46.066 --> 00:16:48.066
所以我又往前走了一步

00:16:48.066 --> 00:16:50.933
把 Jev 本身也放進了維護流程

00:16:51.233 --> 00:16:53.400
它負責的事情其實很簡單

00:16:53.666 --> 00:16:57.733
普通代碼先處理那些完全可以確定的重復；

00:16:57.733 --> 00:17:02.833
如果新項目和現有項目之間真的出現了一個“看起來很像”的對象

00:17:02.833 --> 00:17:06.366
那再讓 Jev 判斷它們到底是什麼關係；

00:17:06.366 --> 00:17:08.600
只有更模糊和更複雜的例外

00:17:08.600 --> 00:17:10.300
才繼續交給 Codex

00:17:10.633 --> 00:17:14.733
我呢就先拿了一批昨天的真實數據跑了一次

00:17:14.833 --> 00:17:18.766
原本需要 Codex 深度閱讀的項目有 13 個

00:17:18.766 --> 00:17:21.000
把這套流程加進去以後

00:17:21.000 --> 00:17:22.466
最後只剩下 1 個

00:17:22.466 --> 00:17:25.733
而且不只是 Codex 少看了幾個項目

00:17:25.733 --> 00:17:27.333
同一輪處理的總時間

00:17:27.333 --> 00:17:29.600
也從大約 36.9 秒

00:17:29.600 --> 00:17:31.166
降到了 10.2 秒

00:17:31.233 --> 00:17:32.833
這不是一個嚴格的 benchmark

00:17:32.833 --> 00:17:34.866
但差別已經非常明顯

00:17:35.133 --> 00:17:41.066
以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；

00:17:41.166 --> 00:17:43.133
而現在大部分的簡單情況

00:17:43.133 --> 00:17:45.400
在前面就已經被處理掉了

00:17:45.533 --> 00:17:46.266
接下來

00:17:46.266 --> 00:17:51.266
我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里

00:17:51.266 --> 00:17:51.866
然後

00:17:51.866 --> 00:17:56.066
又拿一輪全新的 Grok 增量調查真正跑了一次

00:17:56.333 --> 00:17:58.566
這一次一共有 28 個候選身份

00:17:58.566 --> 00:18:01.566
最後真正需要 Codex 深度檢查的

00:18:01.566 --> 00:18:02.566
只有 3 個

00:18:02.566 --> 00:18:03.600
而到了這一步

00:18:03.600 --> 00:18:06.400
我實際上要做的事情反而越來越少了

00:18:06.400 --> 00:18:07.666
你看啊：第一步

00:18:07.666 --> 00:18:09.933
讓 Grok 去找新的 Jev 項目

00:18:09.933 --> 00:18:13.166
第二步，把最新的調查交給 Codex

00:18:13.166 --> 00:18:16.233
讓它按照 Jev Atlas 自己的維護流程

00:18:16.233 --> 00:18:19.633
也就是已經包含 Jev 調用的這套流程

00:18:19.633 --> 00:18:22.333
去查重、篩選、判斷

00:18:22.333 --> 00:18:27.200
再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認

00:18:27.600 --> 00:18:29.033
我審核完以後

00:18:29.033 --> 00:18:32.733
只需要告訴它一句：“應用這次審核通過的更新

00:18:32.733 --> 00:18:33.966
我在本地預覽一下

00:18:33.966 --> 00:18:34.400
”

00:18:34.400 --> 00:18:36.933
Codex 就會把更新寫進去

00:18:36.933 --> 00:18:38.066
重新跑驗證

00:18:38.133 --> 00:18:40.400
再把本地版本打開給我看

00:18:40.633 --> 00:18:41.700
本地確認沒問題

00:18:41.766 --> 00:18:43.800
我再說一句：“發佈到 Hostinger

00:18:43.800 --> 00:18:44.133
”

00:18:44.133 --> 00:18:47.633
後面的提交、部署、Build、Runtime Logs

00:18:47.633 --> 00:18:49.400
再到公開網站的檢查

00:18:49.400 --> 00:18:53.266
就沿著我們前面已經搭好的這條鏈繼續走下去

00:18:53.366 --> 00:18:54.033
最後

00:18:54.033 --> 00:18:58.266
我又去 Hostinger 上已經公開的網站重新驗收了一遍

00:18:58.566 --> 00:19:02.033
最開始呢，這個網站只有 171 個項目

00:19:02.033 --> 00:19:04.900
而現在，它已經變成了 200 個項目

00:19:05.033 --> 00:19:05.833
剛開始

00:19:05.833 --> 00:19:09.566
我只是覺得這台舊電腦跑 Omarchy 很有意思

00:19:09.566 --> 00:19:12.300
但現在，它真的進入了我的工作流

00:19:12.533 --> 00:19:13.733
我前面的視頻里

00:19:13.733 --> 00:19:16.600
我已經試過 ThinkPad X230i

00:19:16.666 --> 00:19:19.766
也試過呢用 Dell 台式機跑 Omarchy

00:19:19.800 --> 00:19:20.800
而現在呢

00:19:20.800 --> 00:19:23.300
蘋果電腦也能跑 Omarchy 了！

00:19:23.333 --> 00:19:25.933
其實這些硬件門檻都不高

00:19:25.933 --> 00:19:27.966
你完全可以自己去試一試

00:19:28.066 --> 00:19:28.866
那麼所以

00:19:28.866 --> 00:19:31.433
我們未來真正需要重新設計的

00:19:31.433 --> 00:19:32.533
到底是“應用”，

00:19:32.533 --> 00:19:35.066
還是整台電腦的工作方式呢？

00:19:35.600 --> 00:19:37.233
那今天就聊到這裡啦

00:19:37.233 --> 00:19:39.366
那如果你喜歡這支影片的話

00:19:39.366 --> 00:19:42.133
就記得幫我訂閱按贊分享

00:19:42.133 --> 00:19:44.800
我們就下一支影片再見囉，拜拜