M1 Mac mini 安装 Omarchy：Jev 真实工作流实测

wow 首頁 每日列表 原始影片
實際影片長度：19:45.000。原文、繁中、雙語可點擊句子跳轉影片。
0:11.233–0:12.766
zh你現在看到的這個網站
0:12.766–0:14.000
zh叫 Jev Atlas
0:14.100–0:16.866
zh它裡面收集了上百個真實的 Jev 項目
0:16.900–0:18.433
zh你可以直接搜索一個項目
0:18.433–0:20.533
zh也可以按照不同的分類去找
0:20.700–0:21.833
zh更有意思的是
0:21.833–0:24.400
zh網站背後這張不斷變化的圖
0:24.400–0:30.933
zh並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類
0:30.933–0:32.366
zh都來自真實的數據
0:32.633–0:35.633
zh它們之間有關係，才會在圖上連起來
0:35.933–0:37.866
zh但今天我真正想講的
0:37.900–0:39.366
zh其實不是這個網站
0:39.366–0:43.400
zh而是呢做出這個網站的這台 Mac 上的 Omarchy
0:43.800–0:44.800
zh在視頻的後面
0:44.800–0:50.600
zh我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了
0:50.600–0:52.633
zh它真的能提高工作效率嗎？
0:53.200–0:54.600
zh話說在幾天之前
0:54.600–0:58.233
zh我把一台已經閒置的 M1 Mac mini 找了出來
0:58.233–0:59.933
zh在上面裝了 Omarchy
1:00.133–1:01.366
zh對這台舊電腦
1:01.433–1:04.400
zh我當時呢也沒對它抱太大的希望
1:04.566–1:07.933
zh但是，結果完全出乎我的意料
1:08.033–1:12.633
zh我剛剛才把平時用的 Mac Studio 升級到 macOS 15
1:12.833–1:13.866
zh按理來說
1:13.900–1:16.533
zh最應該讓我喊一聲“Wow”的應該是它
1:16.733–1:20.466
zh可這幾天真正讓我一邊用、一邊不斷喊“Wow”的
1:20.500–1:24.233
zh反而是這台舊 M1 上跑起來的 MacOmarchy
1:24.633–1:26.966
zh後來我在 X 上發了一條帖子
1:26.966–1:28.333
zh我說：“幾天前
1:28.333–1:32.033
zh我用馬塞洛（Marcelo）開發的 Omarchy
1:32.033–1:35.700
zh讓一台舊 M1 Mac mini 獲得了第二次生命
1:35.833–1:38.633
zh現在又看到 ChatGPT 來到 Linux
1:38.800–1:40.900
zh感覺這個時間點剛剛好
1:41.166–1:41.966
zh沒想到
1:42.233–1:46.266
zhOmarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了
1:46.300–1:48.966
zh他不但回應了這條帖子，還轉發了它
1:49.433–1:50.300
zh當時我說
1:50.300–1:53.733
zh我好像給這台舊 M1 找到了第二次生命
1:53.733–1:56.833
zh但那時候，這其實還只是一種感覺
1:57.033–1:59.866
zh裝一個很酷的系統，讓 Codex 跑起來
1:59.900–2:01.833
zh讓 AI 可以在裡面工作
2:01.833–2:04.133
zh這些當然都是很有意思的
2:04.133–2:06.733
zh可一台所謂的“AI-native computer”，
2:06.733–2:10.666
zh如果最後只是讓我多了幾個和 AI 聊天的窗口
2:10.700–2:12.300
zh好像又差了點什麼
2:12.366–2:13.400
zh所以這幾天
2:13.400–2:15.533
zh我真的給它安排了一份工作
2:15.733–2:18.466
zh那這期視頻呢是由 Hostinger 贊助的
2:18.500–2:28.000
zh而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台
2:28.000–2:32.600
zh就直接把 Agent 在本地完成的工作送到真實的互聯網
2:32.800–2:35.433
zh我沒有讓 Codex 給我寫一個 Todo List
2:35.700–2:41.500
zh也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo
2:41.566–2:43.933
zh我給了它一個真的項目，就是：
2:43.933–2:49.433
zh我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來
2:49.433–2:55.400
zh做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站
2:55.633–3:01.700
zh那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站
3:01.766–3:04.400
zh再自己打開瀏覽器檢查結果
3:04.400–3:04.966
zh後來
3:04.966–3:07.133
zh它又通過 Hostinger Connector (MCP)
3:07.133–3:10.033
zh把網站真正部署到了互聯網上
3:10.433–3:14.200
zh整個過程從想法、到代碼、到部署到互聯網
3:14.200–3:15.600
zh也就半天的時間
3:15.766–3:18.033
zh然後我又在 X 上發了一條推文
3:18.033–3:20.033
zh我說：“那台舊 M1 Mac mini
3:20.033–3:21.400
zh現在有工作了
3:21.400–3:23.133
zh它運行著 Omarchy
3:23.166–3:29.433
zh我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖
3:29.500–3:32.366
zh每個項目都鏈接到真實的來源
3:32.366–3:33.533
zh還可以搜索
3:33.533–3:37.233
zh並通過一張實時動態圖展示整個生態
3:37.566–3:40.600
zhCodex 完成了網站的構建和測試
3:40.600–3:44.200
zh通過 Hostinger MCP 把它部署到互聯網上
3:44.233–3:48.366
zh然後又對公開網站進行了驗證——整個過程
3:48.366–3:51.766
zh都是從這台 M1 上完成和調度的
3:51.933–3:53.133
zh這開始讓我覺得
3:53.133–3:56.633
zh這才像是一台 AI 原生電腦（AI-native computer）該有的樣子
3:57.000–3:59.800
zh所以這期視頻，我們就從頭看看
3:59.800–4:03.733
zh這台被我叫作 MacOmarchy 的 AI-native computer
4:03.733–4:06.133
zh到底是怎麼開始真正乾活的
4:06.566–4:07.533
zh其實一開始
4:07.533–4:11.300
zh我並沒有打算讓這台 M1 做什麼特別複雜的事情
4:11.333–4:12.566
zh我只是很好奇
4:12.566–4:17.033
zh當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後
4:17.033–4:18.766
zh它到底會有什麼不一樣？
4:19.000–4:21.700
zh很快，我就碰到了一個很小的問題
4:22.033–4:27.133
zh就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下
4:27.300–4:29.433
zh我不想專門跑下去拿
4:29.800–4:32.233
zh書桌上倒是有一隻 Magic Mouse
4:32.233–4:33.666
zh但問題就變成了：
4:33.700–4:37.033
zh我怎麼把它連到這台 MacOmarchy 上呢？
4:37.333–4:38.600
zhOmarchy 本身的設計
4:38.600–4:42.166
zh其實已經刻意減少了很多對鼠標的依賴
4:42.166–4:45.333
zh很多操作直接用鍵盤就能完成
4:45.500–4:47.966
zh但是，如果真要選一段文字
4:47.966–4:49.866
zh或者做一些細一點的操作
4:49.900–4:51.566
zh我還是覺得鼠標方便
4:51.766–4:53.366
zh所以我想到了 Codex
4:53.533–4:56.033
zh我按下 Ctrl + 回車打開終端
4:56.033–4:57.133
zh輸入 Codex
4:57.200–5:00.900
zh然後直接告訴它：幫我把這只 Magic Mouse 連上
5:01.100–5:06.033
zh接下來它自己去掃描藍牙設備、添加設備、完成連接
5:06.366–5:07.633
zh鼠標連上以後
5:07.633–5:10.266
zh我又發現指針移動得太快了
5:10.266–5:13.333
zh和我平時在 macOS 上的手感差很多
5:13.533–5:15.200
zh我就繼續告訴 Codex
5:15.233–5:16.766
zh讓它把速度降下來
5:16.833–5:18.333
zh然後還有滾動方向
5:18.333–5:21.700
zh我不喜歡那種更像 Windows 的反向滾動習慣
5:21.933–5:25.333
zh所以也讓它一起調成我平時用 Mac 的感覺
5:25.700–5:28.233
zh整個過程，我當時就覺得很有意思
5:28.400–5:32.166
zh因為呢如果是在傳統的電腦使用方式裡面
5:32.166–5:38.800
zh我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向
5:39.000–5:41.500
zh那套界面本來就是給人設計的
5:41.533–5:42.666
zh但對 AI 來說
5:42.700–5:47.333
zh它其實根本就不需要先學會在屏幕上找到那個藍牙圖標
5:47.500–5:49.900
zh再模擬我去點哪個按鈕
5:49.966–5:52.333
zh它可以直接和系統本身打交道
5:52.566–5:53.833
zh對我們人來說
5:54.633–5:56.533
zh瀏覽、點擊、拖動當然很自然
5:56.566–5:59.366
zh但對 AI 來說，屏幕上的這些按鈕
5:59.366–6:01.833
zh很多時候反而只是繞了一層
6:02.100–6:04.733
zh這一下就讓我第一次很明顯地感覺到
6:04.733–6:07.600
zh這台舊 M1 和我其他幾台蘋果電腦
6:07.600–6:10.033
zh好像開始有了一點不一樣了
6:10.200–6:11.866
zh但就是這個很小的體驗
6:11.900–6:13.033
zh就讓我開始想：
6:13.100–6:16.400
zh如果這台電腦不只是幫我改幾個設置
6:16.400–6:19.200
zh而是真的讓它做一個完整的項目
6:19.200–6:20.600
zh那會發生什麼呢？
6:20.833–6:22.933
zh所以我想給它一個真的任務
6:22.933–6:25.600
zh剛好這幾天，我一直在關注 Jev
6:25.733–6:27.566
zh如果你還不知道 Jev 是什麼
6:27.566–6:30.333
zh這裡呢你也暫時不用管它的技術原理
6:30.333–6:32.633
zh你只需要知道，Jev 開放以後
6:32.633–6:37.433
zhX 上就很快出現了大量開發者做出來的實驗和項目
6:37.433–6:40.033
zh有人把它接進 Coding Agent
6:40.033–6:44.233
zh有人拿它做瀏覽器操作、工具選擇、模型路由
6:44.300–6:50.366
zh也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情
6:50.600–6:53.833
zh問題是，這些東西散得到處都是
6:53.900–6:55.366
zh有些在 X 的帖子里
6:55.366–6:57.066
zh有些藏在 GitHub 里
6:57.100–6:58.733
zh有些有自己的網站
6:58.733–7:01.166
zh還有一些你可能今天刷到一次
7:01.166–7:03.533
zh過兩天想找就已經找不到了
7:03.600–7:05.666
zh所以我冒出了一個很簡單的想法：
7:05.700–7:09.166
zh就是能不能把這些正在出現的 Jev 項目
7:09.166–7:10.933
zh整理成一張地圖呢？
7:11.233–7:16.400
zh我想要的是一個以後還能繼續生長的東西——項目有真實的來源
7:16.400–7:18.233
zh能搜索、能分類；
7:18.233–7:19.766
zh如果以後發現新的項目
7:19.766–7:21.433
zh還可以繼續加進去；
7:21.433–7:23.733
zh然後最好打開首頁的時候
7:23.733–7:27.500
zh還能直接看到這個生態到底長成了什麼樣子
7:27.733–7:30.166
zh於是我把這個想法交給了 Codex
7:30.233–7:33.800
zh我來決定方向和品味，Codex負責乾活
7:33.966–7:35.133
zh比如這個網站
7:35.133–7:37.533
zh我最後把它叫作 Jev Atlas
7:37.700–7:41.033
zh我希望首頁最顯眼的不是一堆項目卡片
7:41.033–7:43.933
zh而是一張 Obsidian 那樣的關係圖
7:44.100–7:45.166
zh我還有一個要求：
7:45.166–7:47.200
zh就是這張圖不能是裝飾
7:47.733–7:49.333
zh如果屏幕上有一個節點
7:49.333–7:51.833
zh它就必須對應真實的數據
7:51.833–7:53.733
zh如果兩個節點之間有一條線
7:53.933–7:56.100
zh也必須真的存在關係
7:56.500–7:58.766
zh所以最後這張圖里的連接
7:58.766–8:01.000
zh全部來自真實的項目數據
8:01.233–8:03.666
zh這也是為什麼你現在看到它的時候
8:03.700–8:06.000
zh會覺得這張圖好像一直在“長”。
8:06.233–8:13.000
zh因為它呢不是預先畫死的一張背景圖
8:13.000–8:15.233
zh這張圖本身也會跟著變化
8:15.566–8:16.600
zh點擊分類
8:16.600–8:18.933
zh星圖上對應的區域就會點亮
8:19.333–8:20.133
zh做到這裡
8:20.233–8:23.200
zh其實一個普通的 AI Demo 已經可以結束了
8:23.200–8:25.900
zh但這恰恰是我不想停下來的地方
8:25.933–8:28.833
zh因為只要它還運行在 localhost
8:28.833–8:32.333
zh這件事本質上仍然只是發生在我的電腦里
8:32.433–8:34.333
zh我真正想測試的是下一步
8:34.333–8:36.666
zh也就是：這台電腦里的 Agent
8:36.700–8:38.966
zh能不能自己把剛剛完成的工作
8:38.966–8:40.966
zh送到真實的互聯網上呢？
8:41.333–8:44.133
zh這一步聽起來好像只是“部署一個網站”，
8:44.133–8:45.333
zh但對於我來說
8:45.333–8:48.366
zh它其實是整個實驗里很關鍵的一步
8:48.433–8:49.933
zh因為在 localhost 裡面
8:49.933–8:52.466
zh一切都很安全——代碼寫壞了
8:52.466–8:53.400
zh可以重來；
8:53.400–8:55.433
zh頁面打不開，可以繼續改；
8:55.433–8:57.766
zh哪怕整個項目跑不起來
8:57.766–9:00.033
zh也只是影響到我自己的這台電腦
9:00.500–9:03.166
zh可一旦你把它發佈到互聯網上
9:03.166–9:04.633
zh事情就不一樣了
9:04.700–9:10.200
zh它要面對真實的服務器環境、真實的構建過程、真實的運行日誌
9:10.200–9:11.000
zh最後
9:11.000–9:13.900
zh還有一個所有人都能打開的網址
9:14.033–9:15.766
zh也就是說，從這裡開始
9:15.766–9:18.733
zhCodex 做的就不再只是一個本地 Demo 了
9:18.733–9:21.133
zh它要真的把一個結果交付出去
9:21.300–9:22.333
zh而這一層
9:22.333–9:26.966
zh過去經常意味著你得去碰雲服務商的管理後台
9:27.366–9:28.033
zh說實話
9:28.033–9:31.033
zh我自己並不喜歡這些流程式的操作
9:31.100–9:39.200
zh打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值
9:39.200–9:43.666
zh但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼
9:43.700–9:44.833
zh我就會開始想：
9:44.833–9:46.533
zh為什麼到了服務器這裡
9:46.533–9:49.366
zh我又要重新變回那個點菜單的人呢？
9:49.633–9:52.366
zh我後來咨詢了自己的雲服務商 Hostinger
9:52.366–9:56.433
zh剛好發現他們有一個叫 Hostinger Connector 的東西
9:56.766–10:01.800
zh它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent
10:02.100–10:03.366
zh授權也很簡單
10:03.366–10:07.866
zh通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來
10:07.900–10:09.933
zh不需要自己折騰 API Key
10:09.933–10:14.333
zh我這次的測試用的是 Hostinger 的 Web App Hosting 套餐
10:14.533–10:17.700
zh這也是他們在這次 Connector 流程里推薦的方案
10:17.766–10:19.366
zh那如果你自己也想試試
10:19.366–10:24.633
zh可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面
10:25.033–10:27.533
zh點擊這裡，輸入優惠碼 WOWINSIGHT
10:27.533–10:29.166
zh就能拿到對應的折扣
10:29.333–10:33.333
zh好、那以前呢如果我要把這樣一個項目部署出去
10:33.333–10:39.100
zh最常規的方式當然還是打開網頁後台、上傳文件、配置 Node
10:39.100–10:41.166
zhjs，確認入口文件
10:41.166–10:42.800
zh然後再去看部署狀態
10:43.200–10:45.566
zh你現在畫面里看到的這些截圖
10:45.566–10:48.400
zh其實就是我前面手動配置時留下來的
10:48.433–10:51.966
zh為了和後面 Codex 自己運維網站做個對比
10:51.966–10:53.900
zh我特意把它們保留了下來
10:54.233–10:56.933
zh其實呢這些事情本身並不難
10:56.933–10:58.466
zh但這一次不一樣了
10:58.500–10:59.766
zh所以我想試試看
10:59.766–11:02.633
zh我是不是只需要面對自己的 Agent
11:02.633–11:04.500
zh就能把後面的事情做完
11:04.933–11:08.066
zh既然我已經有了一台所謂的 AI-native computer
11:08.100–11:09.400
zh那服務器這一邊
11:09.400–11:13.200
zh能不能也直接變成 Agent 工作環境的一部分呢？
11:13.500–11:17.300
zh所以我先把 Hostinger 官方的 MCP 接進 Codex
11:17.366–11:19.833
zh然後通過瀏覽器完成授權
11:20.133–11:21.000
zh接上以後
11:21.000–11:24.600
zh它看到的就不再只是我這台 M1 上的文件
11:24.733–11:33.633
zh它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs
11:33.933–11:38.266
zh比如我只需要問一句：「查看 Hostinger Connector (MCP) 有哪些功能？」
11:38.266–11:38.633
en”
11:38.633–11:42.566
zhCodex 就會直接把當前可用的能力列出來
11:42.633–11:45.000
zh我這裡一共能看到 74 個工具
11:45.200–11:49.200
zh我不會在這裡把 74 個工具一個一個念給你聽
11:49.300–11:50.266
zh你只需要知道
11:50.300–11:53.566
zh像網站、域名、SSL、Node.js、靜態站點
11:53.566–12:02.933
zhjs、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力
12:02.933–12:04.666
zh基本上都已經在裡面了
12:04.666–12:07.300
zh而且 Codex 還可以直接告訴我：
12:07.300–12:09.200
zh為了部署 Jev Atlas
12:09.200–12:11.566
zh它實際調用過哪些工具
12:11.566–12:14.633
zh我覺得呢雲服務商能配套這些功能
12:14.633–12:16.266
zh其實是很重要的
12:16.266–12:18.033
zh因為在沒有 MCP 的時候
12:18.033–12:20.633
zhCodex 寫完代碼，到了“上線”這一步
12:20.633–12:27.933
zh工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去
12:28.000–12:29.000
zh如果出了問題
12:29.133–12:32.333
zh我還要再把錯誤信息複製回來告訴它
12:32.533–12:36.466
zh人在中間一直充當著那個搬運信息的人
12:36.833–12:40.866
zh這其實也是 Hostinger Connector (MCP) 對我最有價值的地方
12:41.033–12:44.666
zh它讓我不用離開現在這個 Agent 的工作環境
12:44.666–12:48.166
zh就能處理網站部署和運維的事情
12:48.366–12:49.633
zh網站上線以後
12:49.633–12:58.000
zhSSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了
12:58.033–12:59.400
zh有了 MCP 以後
12:59.666–13:06.133
zh這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；
13:06.233–13:06.966
zh確認以後
13:06.966–13:10.000
zh它可以繼續調用 Hostinger Connector (MCP)，
13:10.000–13:12.533
zh把同一個項目送到服務器
13:12.866–13:16.166
zh在這裡呀我更想告訴你我的實際體驗！
13:16.366–13:20.200
zh就是你不需要先學會 Hostinger 後台所有的菜單
13:20.266–13:21.366
zh你哪裡不明白
13:21.366–13:23.366
zh你就直接問 Codex 就好了
13:23.533–13:26.000
zh不過，這裡我還是要提醒一句：
13:26.000–13:27.633
zh在真正部署之前
13:27.633–13:32.900
zh我仍然還是讓 Codex 先把本地版本完整的檢查了一遍
13:32.933–13:35.866
zh不是簡單看一眼首頁能不能打開那種哦
13:35.866–13:39.666
zh我是讓它真的用瀏覽器去操作和檢查
13:39.933–13:40.733
zh到了這裡
13:40.733–13:49.800
zh到了這裡，我們手裡已經有一個本地可以正常工作的版本了——它有 171 個項目、569 個節點、和 701 條真實關係
13:50.200–13:51.333
zh搜索可以用
13:51.333–13:53.733
zh圖譜里的連接來自真實數據
13:53.733–13:55.666
zh數據也能正常加載
13:55.833–13:58.266
zh本地測試通過，於是我告訴 Codex：
13:58.266–13:59.900
zh把它部署到 Hostinger
14:00.000–14:03.733
zh不過第一次請求呢甚至還沒有真正走到構建
14:03.933–14:07.533
zh網絡連接在 TLS 階段斷了一次
14:07.566–14:09.200
zhCodex 拿到錯誤以後
14:09.200–14:10.666
zh又重新試了一次
14:11.033–14:13.000
zh第二次，文件成功上傳
14:13.133–14:14.266
zhBuild 也成功了
14:14.266–14:16.433
zh當時看起來，一切都很順利
14:16.433–14:19.800
zh然後我打開那個網址，顯示的卻是503
14:20.266–14:21.066
zh這個時候
14:21.133–14:23.800
zh這個實驗才真正開始變得有意思
14:23.866–14:24.866
zh因為接下來
14:24.866–14:27.766
zh我沒有去登錄服務器後台查問題
14:28.033–14:30.700
zh我也沒有把 503 截圖丟給 Codex
14:30.733–14:32.533
zh然後自己到處找日誌
14:32.533–14:34.166
zh我只是繼續看著它
14:34.466–14:37.133
zh服務器明明告訴它 Build completed
14:37.200–14:39.100
zh為什麼網站還是掛了呢？
14:39.200–14:39.866
zh下一步
14:39.866–14:43.133
zh就輪到這台 MacOmarchy 自己去找答案了
14:43.366–14:49.066
zhCodex 直接通過 Hostinger Connector (MCP) 去讀取這次部署的 Runtime Logs
14:49.066–14:50.733
zh很快就找到了一行錯誤：
14:51.033–14:55.033
zh問題也很快被定位到了項目根目錄的 app
14:55.033–14:55.800
enjs
14:56.133–14:58.366
zh它修的過程很快，我們就略過吧！
14:58.466–14:59.033
zh這裡
14:59.033–15:02.000
zh我覺得關鍵的已經不是這個錯誤本身了
15:02.000–15:04.000
zh而是它找到問題以後
15:04.000–15:06.000
zh接下來還可以繼續往下做
15:06.366–15:07.433
zh修改完成以後
15:07.433–15:12.166
zhCodex 先在這台 M1 上把 Jev Atlas 重新跑起來
15:12.166–15:16.600
zh再用瀏覽器檢查頁面、數據、圖譜和搜索
15:16.633–15:18.266
zh確認本地沒有問題之後
15:18.266–15:22.100
zh它才再次通過 Hostinger Connector 發起部署
15:22.433–15:25.366
zh但它沒有停在“部署成功”這幾個字上
15:25.466–15:29.166
zhCodex 接著打開真正公開的 Jev Atlas
15:29.200–15:33.800
zh把頁面加載、搜索和數據讀取重新檢查了一遍
15:34.133–15:36.966
zh到這裡，這個實驗才真正閉環了：
15:36.966–15:39.200
zh在本地做出來，送到服務器；
15:39.366–15:41.866
zh線上出錯以後自己讀日誌
15:41.866–15:43.033
zh回到本地修復
15:43.033–15:46.700
zh再重新部署，最後去公開網站驗收
15:47.000–15:48.566
zh也就是從這一刻開始
15:48.566–15:54.433
zh我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了
15:54.433–15:56.566
zh它開始能夠把本地的工作
15:56.566–15:59.300
zh真正延伸到外面的服務和互聯網
15:59.433–16:01.366
zh現在整個過程走完以後
16:01.366–16:03.866
zh我想解釋一下，為什麼我會覺得
16:03.866–16:07.166
zh這才開始像一台 AI-native computer
16:07.600–16:09.666
zh因為真正發生變化的
16:09.666–16:11.866
zh並不是這台 M1 突然變快了
16:11.866–16:14.466
zh也不是它多了什麼新的硬件能力
16:14.566–16:16.100
zh其實真正變掉的
16:16.100–16:18.866
zh是我和這台電腦相處的方式
16:19.066–16:21.200
zh前面連接 Magic Mouse 的時候
16:21.233–16:23.366
zh我已經有過一次這種感覺了
16:23.366–16:25.066
zh到了 Jev Atlas 的時候
16:25.200–16:27.366
zh這種變化呢就更明顯了
16:27.433–16:28.200
zh一開始
16:28.200–16:31.600
zh我只是讓 Codex 把網站做出來、跑起來
16:31.600–16:35.333
zh再通過 Hostinger Connector (MCP) 把它送到互聯網上
16:35.366–16:37.733
zh但網站真正上線以後
16:37.733–16:40.033
zh我馬上又碰到了一個更現實的問題：
16:40.033–16:43.733
zh就是 Jev 生態還在不斷出現新的項目
16:43.733–16:45.966
zh那這個網站以後誰來維護呢？
16:46.066–16:48.066
zh所以我又往前走了一步
16:48.066–16:50.933
zh把 Jev 本身也放進了維護流程
16:51.233–16:53.400
zh它負責的事情其實很簡單
16:53.666–16:57.733
zh普通代碼先處理那些完全可以確定的重復；
16:57.733–17:02.833
zh如果新項目和現有項目之間真的出現了一個“看起來很像”的對象
17:02.833–17:06.366
zh那再讓 Jev 判斷它們到底是什麼關係；
17:06.366–17:08.600
zh只有更模糊和更複雜的例外
17:08.600–17:10.300
zh才繼續交給 Codex
17:10.633–17:14.733
zh我呢就先拿了一批昨天的真實數據跑了一次
17:14.833–17:18.766
zh原本需要 Codex 深度閱讀的項目有 13 個
17:18.766–17:21.000
zh把這套流程加進去以後
17:21.000–17:22.466
zh最後只剩下 1 個
17:22.466–17:25.733
zh而且不只是 Codex 少看了幾個項目
17:25.733–17:27.333
zh同一輪處理的總時間
17:27.333–17:29.600
zh也從大約 36.9 秒
17:29.600–17:31.166
zh降到了 10.2 秒
17:31.233–17:32.833
zh這不是一個嚴格的 benchmark
17:32.833–17:34.866
zh但差別已經非常明顯
17:35.133–17:41.066
zh以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；
17:41.166–17:43.133
zh而現在大部分的簡單情況
17:43.133–17:45.400
zh在前面就已經被處理掉了
17:45.533–17:46.266
zh接下來
17:46.266–17:51.266
zh我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里
17:51.266–17:51.866
zh然後
17:51.866–17:56.066
zh又拿一輪全新的 Grok 增量調查真正跑了一次
17:56.333–17:58.566
zh這一次一共有 28 個候選身份
17:58.566–18:01.566
zh最後真正需要 Codex 深度檢查的
18:01.566–18:02.566
zh只有 3 個
18:02.566–18:03.600
zh而到了這一步
18:03.600–18:06.400
zh我實際上要做的事情反而越來越少了
18:06.400–18:07.666
zh你看啊：第一步
18:07.666–18:09.933
zh讓 Grok 去找新的 Jev 項目
18:09.933–18:13.166
zh第二步，把最新的調查交給 Codex
18:13.166–18:16.233
zh讓它按照 Jev Atlas 自己的維護流程
18:16.233–18:19.633
zh也就是已經包含 Jev 調用的這套流程
18:19.633–18:22.333
zh去查重、篩選、判斷
18:22.333–18:27.200
zh再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認
18:27.600–18:29.033
zh我審核完以後
18:29.033–18:32.733
zh只需要告訴它一句：「應用這次審核通過的更新
18:32.733–18:33.966
zh我在本地預覽一下
18:33.966–18:34.400
en”
18:34.400–18:36.933
zhCodex 就會把更新寫進去
18:36.933–18:38.066
zh重新跑驗證
18:38.133–18:40.400
zh再把本地版本打開給我看
18:40.633–18:41.700
zh本地確認沒問題
18:41.766–18:43.800
zh我再說一句：「發佈到 Hostinger
18:43.800–18:44.133
en”
18:44.133–18:47.633
zh後面的提交、部署、Build、Runtime Logs
18:47.633–18:49.400
zh再到公開網站的檢查
18:49.400–18:53.266
zh就沿著我們前面已經搭好的這條鏈繼續走下去
18:53.366–18:54.033
zh最後
18:54.033–18:58.266
zh我又去 Hostinger 上已經公開的網站重新驗收了一遍
18:58.566–19:02.033
zh最開始呢，這個網站只有 171 個項目
19:02.033–19:04.900
zh而現在，它已經變成了 200 個項目
19:05.033–19:05.833
zh剛開始
19:05.833–19:09.566
zh我只是覺得這台舊電腦跑 Omarchy 很有意思
19:09.566–19:12.300
zh但現在，它真的進入了我的工作流
19:12.533–19:13.733
zh我前面的視頻里
19:13.733–19:16.600
zh我已經試過 ThinkPad X230i
19:16.666–19:19.766
zh也試過呢用 Dell 台式機跑 Omarchy
19:19.800–19:20.800
zh而現在呢
19:20.800–19:23.300
zh蘋果電腦也能跑 Omarchy 了！
19:23.333–19:25.933
zh其實這些硬件門檻都不高
19:25.933–19:27.966
zh你完全可以自己去試一試
19:28.066–19:28.866
zh那麼所以
19:28.866–19:31.433
zh我們未來真正需要重新設計的
19:31.433–19:32.533
zh到底是“應用”，
19:32.533–19:35.066
zh還是整台電腦的工作方式呢？
19:35.600–19:37.233
zh那今天就聊到這裡啦
19:37.233–19:39.366
zh那如果你喜歡這支影片的話
19:39.366–19:42.133
zh就記得幫我訂閱按贊分享
19:42.133–19:44.800
zh我們就下一支影片再見囉，拜拜
0:11.233–0:12.766
你現在看到的這個網站
0:12.766–0:14.000
叫 Jev Atlas
0:14.100–0:16.866
它裡面收集了上百個真實的 Jev 項目
0:16.900–0:18.433
你可以直接搜索一個項目
0:18.433–0:20.533
也可以按照不同的分類去找
0:20.700–0:21.833
更有意思的是
0:21.833–0:24.400
網站背後這張不斷變化的圖
0:24.400–0:30.933
並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類
0:30.933–0:32.366
都來自真實的數據
0:32.633–0:35.633
它們之間有關係，才會在圖上連起來
0:35.933–0:37.866
但今天我真正想講的
0:37.900–0:39.366
其實不是這個網站
0:39.366–0:43.400
而是呢做出這個網站的這台 Mac 上的 Omarchy
0:43.800–0:44.800
在視頻的後面
0:44.800–0:50.600
我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了
0:50.600–0:52.633
它真的能提高工作效率嗎？
0:53.200–0:54.600
話說在幾天之前
0:54.600–0:58.233
我把一台已經閒置的 M1 Mac mini 找了出來
0:58.233–0:59.933
在上面裝了 Omarchy
1:00.133–1:01.366
對這台舊電腦
1:01.433–1:04.400
我當時呢也沒對它抱太大的希望
1:04.566–1:07.933
但是，結果完全出乎我的意料
1:08.033–1:12.633
我剛剛才把平時用的 Mac Studio 升級到 macOS 15
1:12.833–1:13.866
按理來說
1:13.900–1:16.533
最應該讓我喊一聲“Wow”的應該是它
1:16.733–1:20.466
可這幾天真正讓我一邊用、一邊不斷喊“Wow”的
1:20.500–1:24.233
反而是這台舊 M1 上跑起來的 MacOmarchy
1:24.633–1:26.966
後來我在 X 上發了一條帖子
1:26.966–1:28.333
我說：“幾天前
1:28.333–1:32.033
我用馬塞洛（Marcelo）開發的 Omarchy
1:32.033–1:35.700
讓一台舊 M1 Mac mini 獲得了第二次生命
1:35.833–1:38.633
現在又看到 ChatGPT 來到 Linux
1:38.800–1:40.900
感覺這個時間點剛剛好
1:41.166–1:41.966
沒想到
1:42.233–1:46.266
Omarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了
1:46.300–1:48.966
他不但回應了這條帖子，還轉發了它
1:49.433–1:50.300
當時我說
1:50.300–1:53.733
我好像給這台舊 M1 找到了第二次生命
1:53.733–1:56.833
但那時候，這其實還只是一種感覺
1:57.033–1:59.866
裝一個很酷的系統，讓 Codex 跑起來
1:59.900–2:01.833
讓 AI 可以在裡面工作
2:01.833–2:04.133
這些當然都是很有意思的
2:04.133–2:06.733
可一台所謂的“AI-native computer”，
2:06.733–2:10.666
如果最後只是讓我多了幾個和 AI 聊天的窗口
2:10.700–2:12.300
好像又差了點什麼
2:12.366–2:13.400
所以這幾天
2:13.400–2:15.533
我真的給它安排了一份工作
2:15.733–2:18.466
那這期視頻呢是由 Hostinger 贊助的
2:18.500–2:28.000
而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台
2:28.000–2:32.600
就直接把 Agent 在本地完成的工作送到真實的互聯網
2:32.800–2:35.433
我沒有讓 Codex 給我寫一個 Todo List
2:35.700–2:41.500
也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo
2:41.566–2:43.933
我給了它一個真的項目，就是：
2:43.933–2:49.433
我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來
2:49.433–2:55.400
做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站
2:55.633–3:01.700
那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站
3:01.766–3:04.400
再自己打開瀏覽器檢查結果
3:04.400–3:04.966
後來
3:04.966–3:07.133
它又通過 Hostinger Connector (MCP)
3:07.133–3:10.033
把網站真正部署到了互聯網上
3:10.433–3:14.200
整個過程從想法、到代碼、到部署到互聯網
3:14.200–3:15.600
也就半天的時間
3:15.766–3:18.033
然後我又在 X 上發了一條推文
3:18.033–3:20.033
我說：“那台舊 M1 Mac mini
3:20.033–3:21.400
現在有工作了
3:21.400–3:23.133
它運行著 Omarchy
3:23.166–3:29.433
我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖
3:29.500–3:32.366
每個項目都鏈接到真實的來源
3:32.366–3:33.533
還可以搜索
3:33.533–3:37.233
並通過一張實時動態圖展示整個生態
3:37.566–3:40.600
Codex 完成了網站的構建和測試
3:40.600–3:44.200
通過 Hostinger MCP 把它部署到互聯網上
3:44.233–3:48.366
然後又對公開網站進行了驗證——整個過程
3:48.366–3:51.766
都是從這台 M1 上完成和調度的
3:51.933–3:53.133
這開始讓我覺得
3:53.133–3:56.633
這才像是一台 AI 原生電腦（AI-native computer）該有的樣子
3:57.000–3:59.800
所以這期視頻，我們就從頭看看
3:59.800–4:03.733
這台被我叫作 MacOmarchy 的 AI-native computer
4:03.733–4:06.133
到底是怎麼開始真正乾活的
4:06.566–4:07.533
其實一開始
4:07.533–4:11.300
我並沒有打算讓這台 M1 做什麼特別複雜的事情
4:11.333–4:12.566
我只是很好奇
4:12.566–4:17.033
當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後
4:17.033–4:18.766
它到底會有什麼不一樣？
4:19.000–4:21.700
很快，我就碰到了一個很小的問題
4:22.033–4:27.133
就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下
4:27.300–4:29.433
我不想專門跑下去拿
4:29.800–4:32.233
書桌上倒是有一隻 Magic Mouse
4:32.233–4:33.666
但問題就變成了：
4:33.700–4:37.033
我怎麼把它連到這台 MacOmarchy 上呢？
4:37.333–4:38.600
Omarchy 本身的設計
4:38.600–4:42.166
其實已經刻意減少了很多對鼠標的依賴
4:42.166–4:45.333
很多操作直接用鍵盤就能完成
4:45.500–4:47.966
但是，如果真要選一段文字
4:47.966–4:49.866
或者做一些細一點的操作
4:49.900–4:51.566
我還是覺得鼠標方便
4:51.766–4:53.366
所以我想到了 Codex
4:53.533–4:56.033
我按下 Ctrl + 回車打開終端
4:56.033–4:57.133
輸入 Codex
4:57.200–5:00.900
然後直接告訴它：幫我把這只 Magic Mouse 連上
5:01.100–5:06.033
接下來它自己去掃描藍牙設備、添加設備、完成連接
5:06.366–5:07.633
鼠標連上以後
5:07.633–5:10.266
我又發現指針移動得太快了
5:10.266–5:13.333
和我平時在 macOS 上的手感差很多
5:13.533–5:15.200
我就繼續告訴 Codex
5:15.233–5:16.766
讓它把速度降下來
5:16.833–5:18.333
然後還有滾動方向
5:18.333–5:21.700
我不喜歡那種更像 Windows 的反向滾動習慣
5:21.933–5:25.333
所以也讓它一起調成我平時用 Mac 的感覺
5:25.700–5:28.233
整個過程，我當時就覺得很有意思
5:28.400–5:32.166
因為呢如果是在傳統的電腦使用方式裡面
5:32.166–5:38.800
我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向
5:39.000–5:41.500
那套界面本來就是給人設計的
5:41.533–5:42.666
但對 AI 來說
5:42.700–5:47.333
它其實根本就不需要先學會在屏幕上找到那個藍牙圖標
5:47.500–5:49.900
再模擬我去點哪個按鈕
5:49.966–5:52.333
它可以直接和系統本身打交道
5:52.566–5:53.833
對我們人來說
5:54.633–5:56.533
瀏覽、點擊、拖動當然很自然
5:56.566–5:59.366
但對 AI 來說，屏幕上的這些按鈕
5:59.366–6:01.833
很多時候反而只是繞了一層
6:02.100–6:04.733
這一下就讓我第一次很明顯地感覺到
6:04.733–6:07.600
這台舊 M1 和我其他幾台蘋果電腦
6:07.600–6:10.033
好像開始有了一點不一樣了
6:10.200–6:11.866
但就是這個很小的體驗
6:11.900–6:13.033
就讓我開始想：
6:13.100–6:16.400
如果這台電腦不只是幫我改幾個設置
6:16.400–6:19.200
而是真的讓它做一個完整的項目
6:19.200–6:20.600
那會發生什麼呢？
6:20.833–6:22.933
所以我想給它一個真的任務
6:22.933–6:25.600
剛好這幾天，我一直在關注 Jev
6:25.733–6:27.566
如果你還不知道 Jev 是什麼
6:27.566–6:30.333
這裡呢你也暫時不用管它的技術原理
6:30.333–6:32.633
你只需要知道，Jev 開放以後
6:32.633–6:37.433
X 上就很快出現了大量開發者做出來的實驗和項目
6:37.433–6:40.033
有人把它接進 Coding Agent
6:40.033–6:44.233
有人拿它做瀏覽器操作、工具選擇、模型路由
6:44.300–6:50.366
也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情
6:50.600–6:53.833
問題是，這些東西散得到處都是
6:53.900–6:55.366
有些在 X 的帖子里
6:55.366–6:57.066
有些藏在 GitHub 里
6:57.100–6:58.733
有些有自己的網站
6:58.733–7:01.166
還有一些你可能今天刷到一次
7:01.166–7:03.533
過兩天想找就已經找不到了
7:03.600–7:05.666
所以我冒出了一個很簡單的想法：
7:05.700–7:09.166
就是能不能把這些正在出現的 Jev 項目
7:09.166–7:10.933
整理成一張地圖呢？
7:11.233–7:16.400
我想要的是一個以後還能繼續生長的東西——項目有真實的來源
7:16.400–7:18.233
能搜索、能分類；
7:18.233–7:19.766
如果以後發現新的項目
7:19.766–7:21.433
還可以繼續加進去；
7:21.433–7:23.733
然後最好打開首頁的時候
7:23.733–7:27.500
還能直接看到這個生態到底長成了什麼樣子
7:27.733–7:30.166
於是我把這個想法交給了 Codex
7:30.233–7:33.800
我來決定方向和品味，Codex負責乾活
7:33.966–7:35.133
比如這個網站
7:35.133–7:37.533
我最後把它叫作 Jev Atlas
7:37.700–7:41.033
我希望首頁最顯眼的不是一堆項目卡片
7:41.033–7:43.933
而是一張 Obsidian 那樣的關係圖
7:44.100–7:45.166
我還有一個要求：
7:45.166–7:47.200
就是這張圖不能是裝飾
7:47.733–7:49.333
如果屏幕上有一個節點
7:49.333–7:51.833
它就必須對應真實的數據
7:51.833–7:53.733
如果兩個節點之間有一條線
7:53.933–7:56.100
也必須真的存在關係
7:56.500–7:58.766
所以最後這張圖里的連接
7:58.766–8:01.000
全部來自真實的項目數據
8:01.233–8:03.666
這也是為什麼你現在看到它的時候
8:03.700–8:06.000
會覺得這張圖好像一直在“長”。
8:06.233–8:13.000
因為它呢不是預先畫死的一張背景圖
8:13.000–8:15.233
這張圖本身也會跟著變化
8:15.566–8:16.600
點擊分類
8:16.600–8:18.933
星圖上對應的區域就會點亮
8:19.333–8:20.133
做到這裡
8:20.233–8:23.200
其實一個普通的 AI Demo 已經可以結束了
8:23.200–8:25.900
但這恰恰是我不想停下來的地方
8:25.933–8:28.833
因為只要它還運行在 localhost
8:28.833–8:32.333
這件事本質上仍然只是發生在我的電腦里
8:32.433–8:34.333
我真正想測試的是下一步
8:34.333–8:36.666
也就是：這台電腦里的 Agent
8:36.700–8:38.966
能不能自己把剛剛完成的工作
8:38.966–8:40.966
送到真實的互聯網上呢？
8:41.333–8:44.133
這一步聽起來好像只是“部署一個網站”，
8:44.133–8:45.333
但對於我來說
8:45.333–8:48.366
它其實是整個實驗里很關鍵的一步
8:48.433–8:49.933
因為在 localhost 裡面
8:49.933–8:52.466
一切都很安全——代碼寫壞了
8:52.466–8:53.400
可以重來；
8:53.400–8:55.433
頁面打不開，可以繼續改；
8:55.433–8:57.766
哪怕整個項目跑不起來
8:57.766–9:00.033
也只是影響到我自己的這台電腦
9:00.500–9:03.166
可一旦你把它發佈到互聯網上
9:03.166–9:04.633
事情就不一樣了
9:04.700–9:10.200
它要面對真實的服務器環境、真實的構建過程、真實的運行日誌
9:10.200–9:11.000
最後
9:11.000–9:13.900
還有一個所有人都能打開的網址
9:14.033–9:15.766
也就是說，從這裡開始
9:15.766–9:18.733
Codex 做的就不再只是一個本地 Demo 了
9:18.733–9:21.133
它要真的把一個結果交付出去
9:21.300–9:22.333
而這一層
9:22.333–9:26.966
過去經常意味著你得去碰雲服務商的管理後台
9:27.366–9:28.033
說實話
9:28.033–9:31.033
我自己並不喜歡這些流程式的操作
9:31.100–9:39.200
打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值
9:39.200–9:43.666
但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼
9:43.700–9:44.833
我就會開始想：
9:44.833–9:46.533
為什麼到了服務器這裡
9:46.533–9:49.366
我又要重新變回那個點菜單的人呢？
9:49.633–9:52.366
我後來咨詢了自己的雲服務商 Hostinger
9:52.366–9:56.433
剛好發現他們有一個叫 Hostinger Connector 的東西
9:56.766–10:01.800
它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent
10:02.100–10:03.366
授權也很簡單
10:03.366–10:07.866
通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來
10:07.900–10:09.933
不需要自己折騰 API Key
10:09.933–10:14.333
我這次的測試用的是 Hostinger 的 Web App Hosting 套餐
10:14.533–10:17.700
這也是他們在這次 Connector 流程里推薦的方案
10:17.766–10:19.366
那如果你自己也想試試
10:19.366–10:24.633
可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面
10:25.033–10:27.533
點擊這裡，輸入優惠碼 WOWINSIGHT
10:27.533–10:29.166
就能拿到對應的折扣
10:29.333–10:33.333
好、那以前呢如果我要把這樣一個項目部署出去
10:33.333–10:39.100
最常規的方式當然還是打開網頁後台、上傳文件、配置 Node
10:39.100–10:41.166
js，確認入口文件
10:41.166–10:42.800
然後再去看部署狀態
10:43.200–10:45.566
你現在畫面里看到的這些截圖
10:45.566–10:48.400
其實就是我前面手動配置時留下來的
10:48.433–10:51.966
為了和後面 Codex 自己運維網站做個對比
10:51.966–10:53.900
我特意把它們保留了下來
10:54.233–10:56.933
其實呢這些事情本身並不難
10:56.933–10:58.466
但這一次不一樣了
10:58.500–10:59.766
所以我想試試看
10:59.766–11:02.633
我是不是只需要面對自己的 Agent
11:02.633–11:04.500
就能把後面的事情做完
11:04.933–11:08.066
既然我已經有了一台所謂的 AI-native computer
11:08.100–11:09.400
那服務器這一邊
11:09.400–11:13.200
能不能也直接變成 Agent 工作環境的一部分呢？
11:13.500–11:17.300
所以我先把 Hostinger 官方的 MCP 接進 Codex
11:17.366–11:19.833
然後通過瀏覽器完成授權
11:20.133–11:21.000
接上以後
11:21.000–11:24.600
它看到的就不再只是我這台 M1 上的文件
11:24.733–11:33.633
它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs
11:33.933–11:38.266
比如我只需要問一句：「查看 Hostinger Connector (MCP) 有哪些功能？」
11:38.266–11:38.633
”
11:38.633–11:42.566
Codex 就會直接把當前可用的能力列出來
11:42.633–11:45.000
我這裡一共能看到 74 個工具
11:45.200–11:49.200
我不會在這裡把 74 個工具一個一個念給你聽
11:49.300–11:50.266
你只需要知道
11:50.300–11:53.566
像網站、域名、SSL、Node.js、靜態站點
11:53.566–12:02.933
js、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力
12:02.933–12:04.666
基本上都已經在裡面了
12:04.666–12:07.300
而且 Codex 還可以直接告訴我：
12:07.300–12:09.200
為了部署 Jev Atlas
12:09.200–12:11.566
它實際調用過哪些工具
12:11.566–12:14.633
我覺得呢雲服務商能配套這些功能
12:14.633–12:16.266
其實是很重要的
12:16.266–12:18.033
因為在沒有 MCP 的時候
12:18.033–12:20.633
Codex 寫完代碼，到了“上線”這一步
12:20.633–12:27.933
工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去
12:28.000–12:29.000
如果出了問題
12:29.133–12:32.333
我還要再把錯誤信息複製回來告訴它
12:32.533–12:36.466
人在中間一直充當著那個搬運信息的人
12:36.833–12:40.866
這其實也是 Hostinger Connector (MCP) 對我最有價值的地方
12:41.033–12:44.666
它讓我不用離開現在這個 Agent 的工作環境
12:44.666–12:48.166
就能處理網站部署和運維的事情
12:48.366–12:49.633
網站上線以後
12:49.633–12:58.000
SSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了
12:58.033–12:59.400
有了 MCP 以後
12:59.666–13:06.133
這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；
13:06.233–13:06.966
確認以後
13:06.966–13:10.000
它可以繼續調用 Hostinger Connector (MCP)，
13:10.000–13:12.533
把同一個項目送到服務器
13:12.866–13:16.166
在這裡呀我更想告訴你我的實際體驗！
13:16.366–13:20.200
就是你不需要先學會 Hostinger 後台所有的菜單
13:20.266–13:21.366
你哪裡不明白
13:21.366–13:23.366
你就直接問 Codex 就好了
13:23.533–13:26.000
不過，這裡我還是要提醒一句：
13:26.000–13:27.633
在真正部署之前
13:27.633–13:32.900
我仍然還是讓 Codex 先把本地版本完整的檢查了一遍
13:32.933–13:35.866
不是簡單看一眼首頁能不能打開那種哦
13:35.866–13:39.666
我是讓它真的用瀏覽器去操作和檢查
13:39.933–13:40.733
到了這裡
13:40.733–13:49.800
到了這裡，我們手裡已經有一個本地可以正常工作的版本了——它有 171 個項目、569 個節點、和 701 條真實關係
13:50.200–13:51.333
搜索可以用
13:51.333–13:53.733
圖譜里的連接來自真實數據
13:53.733–13:55.666
數據也能正常加載
13:55.833–13:58.266
本地測試通過，於是我告訴 Codex：
13:58.266–13:59.900
把它部署到 Hostinger
14:00.000–14:03.733
不過第一次請求呢甚至還沒有真正走到構建
14:03.933–14:07.533
網絡連接在 TLS 階段斷了一次
14:07.566–14:09.200
Codex 拿到錯誤以後
14:09.200–14:10.666
又重新試了一次
14:11.033–14:13.000
第二次，文件成功上傳
14:13.133–14:14.266
Build 也成功了
14:14.266–14:16.433
當時看起來，一切都很順利
14:16.433–14:19.800
然後我打開那個網址，顯示的卻是503
14:20.266–14:21.066
這個時候
14:21.133–14:23.800
這個實驗才真正開始變得有意思
14:23.866–14:24.866
因為接下來
14:24.866–14:27.766
我沒有去登錄服務器後台查問題
14:28.033–14:30.700
我也沒有把 503 截圖丟給 Codex
14:30.733–14:32.533
然後自己到處找日誌
14:32.533–14:34.166
我只是繼續看著它
14:34.466–14:37.133
服務器明明告訴它 Build completed
14:37.200–14:39.100
為什麼網站還是掛了呢？
14:39.200–14:39.866
下一步
14:39.866–14:43.133
就輪到這台 MacOmarchy 自己去找答案了
14:43.366–14:49.066
Codex 直接通過 Hostinger Connector (MCP) 去讀取這次部署的 Runtime Logs
14:49.066–14:50.733
很快就找到了一行錯誤：
14:51.033–14:55.033
問題也很快被定位到了項目根目錄的 app
14:55.033–14:55.800
js
14:56.133–14:58.366
它修的過程很快，我們就略過吧！
14:58.466–14:59.033
這裡
14:59.033–15:02.000
我覺得關鍵的已經不是這個錯誤本身了
15:02.000–15:04.000
而是它找到問題以後
15:04.000–15:06.000
接下來還可以繼續往下做
15:06.366–15:07.433
修改完成以後
15:07.433–15:12.166
Codex 先在這台 M1 上把 Jev Atlas 重新跑起來
15:12.166–15:16.600
再用瀏覽器檢查頁面、數據、圖譜和搜索
15:16.633–15:18.266
確認本地沒有問題之後
15:18.266–15:22.100
它才再次通過 Hostinger Connector 發起部署
15:22.433–15:25.366
但它沒有停在“部署成功”這幾個字上
15:25.466–15:29.166
Codex 接著打開真正公開的 Jev Atlas
15:29.200–15:33.800
把頁面加載、搜索和數據讀取重新檢查了一遍
15:34.133–15:36.966
到這裡，這個實驗才真正閉環了：
15:36.966–15:39.200
在本地做出來，送到服務器；
15:39.366–15:41.866
線上出錯以後自己讀日誌
15:41.866–15:43.033
回到本地修復
15:43.033–15:46.700
再重新部署，最後去公開網站驗收
15:47.000–15:48.566
也就是從這一刻開始
15:48.566–15:54.433
我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了
15:54.433–15:56.566
它開始能夠把本地的工作
15:56.566–15:59.300
真正延伸到外面的服務和互聯網
15:59.433–16:01.366
現在整個過程走完以後
16:01.366–16:03.866
我想解釋一下，為什麼我會覺得
16:03.866–16:07.166
這才開始像一台 AI-native computer
16:07.600–16:09.666
因為真正發生變化的
16:09.666–16:11.866
並不是這台 M1 突然變快了
16:11.866–16:14.466
也不是它多了什麼新的硬件能力
16:14.566–16:16.100
其實真正變掉的
16:16.100–16:18.866
是我和這台電腦相處的方式
16:19.066–16:21.200
前面連接 Magic Mouse 的時候
16:21.233–16:23.366
我已經有過一次這種感覺了
16:23.366–16:25.066
到了 Jev Atlas 的時候
16:25.200–16:27.366
這種變化呢就更明顯了
16:27.433–16:28.200
一開始
16:28.200–16:31.600
我只是讓 Codex 把網站做出來、跑起來
16:31.600–16:35.333
再通過 Hostinger Connector (MCP) 把它送到互聯網上
16:35.366–16:37.733
但網站真正上線以後
16:37.733–16:40.033
我馬上又碰到了一個更現實的問題：
16:40.033–16:43.733
就是 Jev 生態還在不斷出現新的項目
16:43.733–16:45.966
那這個網站以後誰來維護呢？
16:46.066–16:48.066
所以我又往前走了一步
16:48.066–16:50.933
把 Jev 本身也放進了維護流程
16:51.233–16:53.400
它負責的事情其實很簡單
16:53.666–16:57.733
普通代碼先處理那些完全可以確定的重復；
16:57.733–17:02.833
如果新項目和現有項目之間真的出現了一個“看起來很像”的對象
17:02.833–17:06.366
那再讓 Jev 判斷它們到底是什麼關係；
17:06.366–17:08.600
只有更模糊和更複雜的例外
17:08.600–17:10.300
才繼續交給 Codex
17:10.633–17:14.733
我呢就先拿了一批昨天的真實數據跑了一次
17:14.833–17:18.766
原本需要 Codex 深度閱讀的項目有 13 個
17:18.766–17:21.000
把這套流程加進去以後
17:21.000–17:22.466
最後只剩下 1 個
17:22.466–17:25.733
而且不只是 Codex 少看了幾個項目
17:25.733–17:27.333
同一輪處理的總時間
17:27.333–17:29.600
也從大約 36.9 秒
17:29.600–17:31.166
降到了 10.2 秒
17:31.233–17:32.833
這不是一個嚴格的 benchmark
17:32.833–17:34.866
但差別已經非常明顯
17:35.133–17:41.066
以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；
17:41.166–17:43.133
而現在大部分的簡單情況
17:43.133–17:45.400
在前面就已經被處理掉了
17:45.533–17:46.266
接下來
17:46.266–17:51.266
我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里
17:51.266–17:51.866
然後
17:51.866–17:56.066
又拿一輪全新的 Grok 增量調查真正跑了一次
17:56.333–17:58.566
這一次一共有 28 個候選身份
17:58.566–18:01.566
最後真正需要 Codex 深度檢查的
18:01.566–18:02.566
只有 3 個
18:02.566–18:03.600
而到了這一步
18:03.600–18:06.400
我實際上要做的事情反而越來越少了
18:06.400–18:07.666
你看啊：第一步
18:07.666–18:09.933
讓 Grok 去找新的 Jev 項目
18:09.933–18:13.166
第二步，把最新的調查交給 Codex
18:13.166–18:16.233
讓它按照 Jev Atlas 自己的維護流程
18:16.233–18:19.633
也就是已經包含 Jev 調用的這套流程
18:19.633–18:22.333
去查重、篩選、判斷
18:22.333–18:27.200
再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認
18:27.600–18:29.033
我審核完以後
18:29.033–18:32.733
只需要告訴它一句：「應用這次審核通過的更新
18:32.733–18:33.966
我在本地預覽一下
18:33.966–18:34.400
”
18:34.400–18:36.933
Codex 就會把更新寫進去
18:36.933–18:38.066
重新跑驗證
18:38.133–18:40.400
再把本地版本打開給我看
18:40.633–18:41.700
本地確認沒問題
18:41.766–18:43.800
我再說一句：「發佈到 Hostinger
18:43.800–18:44.133
”
18:44.133–18:47.633
後面的提交、部署、Build、Runtime Logs
18:47.633–18:49.400
再到公開網站的檢查
18:49.400–18:53.266
就沿著我們前面已經搭好的這條鏈繼續走下去
18:53.366–18:54.033
最後
18:54.033–18:58.266
我又去 Hostinger 上已經公開的網站重新驗收了一遍
18:58.566–19:02.033
最開始呢，這個網站只有 171 個項目
19:02.033–19:04.900
而現在，它已經變成了 200 個項目
19:05.033–19:05.833
剛開始
19:05.833–19:09.566
我只是覺得這台舊電腦跑 Omarchy 很有意思
19:09.566–19:12.300
但現在，它真的進入了我的工作流
19:12.533–19:13.733
我前面的視頻里
19:13.733–19:16.600
我已經試過 ThinkPad X230i
19:16.666–19:19.766
也試過呢用 Dell 台式機跑 Omarchy
19:19.800–19:20.800
而現在呢
19:20.800–19:23.300
蘋果電腦也能跑 Omarchy 了！
19:23.333–19:25.933
其實這些硬件門檻都不高
19:25.933–19:27.966
你完全可以自己去試一試
19:28.066–19:28.866
那麼所以
19:28.866–19:31.433
我們未來真正需要重新設計的
19:31.433–19:32.533
到底是“應用”，
19:32.533–19:35.066
還是整台電腦的工作方式呢？
19:35.600–19:37.233
那今天就聊到這裡啦
19:37.233–19:39.366
那如果你喜歡這支影片的話
19:39.366–19:42.133
就記得幫我訂閱按贊分享
19:42.133–19:44.800
我們就下一支影片再見囉，拜拜
0:11.233–0:12.766
zh你現在看到的這個網站
你現在看到的這個網站
0:12.766–0:14.000
zh叫 Jev Atlas
叫 Jev Atlas
0:14.100–0:16.866
zh它裡面收集了上百個真實的 Jev 項目
它裡面收集了上百個真實的 Jev 項目
0:16.900–0:18.433
zh你可以直接搜索一個項目
你可以直接搜索一個項目
0:18.433–0:20.533
zh也可以按照不同的分類去找
也可以按照不同的分類去找
0:20.700–0:21.833
zh更有意思的是
更有意思的是
0:21.833–0:24.400
zh網站背後這張不斷變化的圖
網站背後這張不斷變化的圖
0:24.400–0:30.933
zh並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類
並不是我為了好看隨便生成的動畫哦——這裡的每一個項目、作者、標籤和分類
0:30.933–0:32.366
zh都來自真實的數據
都來自真實的數據
0:32.633–0:35.633
zh它們之間有關係，才會在圖上連起來
它們之間有關係，才會在圖上連起來
0:35.933–0:37.866
zh但今天我真正想講的
但今天我真正想講的
0:37.900–0:39.366
zh其實不是這個網站
其實不是這個網站
0:39.366–0:43.400
zh而是呢做出這個網站的這台 Mac 上的 Omarchy
而是呢做出這個網站的這台 Mac 上的 Omarchy
0:43.800–0:44.800
zh在視頻的後面
在視頻的後面
0:44.800–0:50.600
zh我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了
我還把這幾天爆火的 Jev 本身也加入到了工作流程里——那麼問題來了
0:50.600–0:52.633
zh它真的能提高工作效率嗎？
它真的能提高工作效率嗎？
0:53.200–0:54.600
zh話說在幾天之前
話說在幾天之前
0:54.600–0:58.233
zh我把一台已經閒置的 M1 Mac mini 找了出來
我把一台已經閒置的 M1 Mac mini 找了出來
0:58.233–0:59.933
zh在上面裝了 Omarchy
在上面裝了 Omarchy
1:00.133–1:01.366
zh對這台舊電腦
對這台舊電腦
1:01.433–1:04.400
zh我當時呢也沒對它抱太大的希望
我當時呢也沒對它抱太大的希望
1:04.566–1:07.933
zh但是，結果完全出乎我的意料
但是，結果完全出乎我的意料
1:08.033–1:12.633
zh我剛剛才把平時用的 Mac Studio 升級到 macOS 15
我剛剛才把平時用的 Mac Studio 升級到 macOS 15
1:12.833–1:13.866
zh按理來說
按理來說
1:13.900–1:16.533
zh最應該讓我喊一聲“Wow”的應該是它
最應該讓我喊一聲“Wow”的應該是它
1:16.733–1:20.466
zh可這幾天真正讓我一邊用、一邊不斷喊“Wow”的
可這幾天真正讓我一邊用、一邊不斷喊“Wow”的
1:20.500–1:24.233
zh反而是這台舊 M1 上跑起來的 MacOmarchy
反而是這台舊 M1 上跑起來的 MacOmarchy
1:24.633–1:26.966
zh後來我在 X 上發了一條帖子
後來我在 X 上發了一條帖子
1:26.966–1:28.333
zh我說：“幾天前
我說：“幾天前
1:28.333–1:32.033
zh我用馬塞洛（Marcelo）開發的 Omarchy
我用馬塞洛（Marcelo）開發的 Omarchy
1:32.033–1:35.700
zh讓一台舊 M1 Mac mini 獲得了第二次生命
讓一台舊 M1 Mac mini 獲得了第二次生命
1:35.833–1:38.633
zh現在又看到 ChatGPT 來到 Linux
現在又看到 ChatGPT 來到 Linux
1:38.800–1:40.900
zh感覺這個時間點剛剛好
感覺這個時間點剛剛好
1:41.166–1:41.966
zh沒想到
沒想到
1:42.233–1:46.266
zhOmarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了
Omarchy MX Mac 的開發者馬塞洛（Marcelo）真的看到了
1:46.300–1:48.966
zh他不但回應了這條帖子，還轉發了它
他不但回應了這條帖子，還轉發了它
1:49.433–1:50.300
zh當時我說
當時我說
1:50.300–1:53.733
zh我好像給這台舊 M1 找到了第二次生命
我好像給這台舊 M1 找到了第二次生命
1:53.733–1:56.833
zh但那時候，這其實還只是一種感覺
但那時候，這其實還只是一種感覺
1:57.033–1:59.866
zh裝一個很酷的系統，讓 Codex 跑起來
裝一個很酷的系統，讓 Codex 跑起來
1:59.900–2:01.833
zh讓 AI 可以在裡面工作
讓 AI 可以在裡面工作
2:01.833–2:04.133
zh這些當然都是很有意思的
這些當然都是很有意思的
2:04.133–2:06.733
zh可一台所謂的“AI-native computer”，
可一台所謂的“AI-native computer”，
2:06.733–2:10.666
zh如果最後只是讓我多了幾個和 AI 聊天的窗口
如果最後只是讓我多了幾個和 AI 聊天的窗口
2:10.700–2:12.300
zh好像又差了點什麼
好像又差了點什麼
2:12.366–2:13.400
zh所以這幾天
所以這幾天
2:13.400–2:15.533
zh我真的給它安排了一份工作
我真的給它安排了一份工作
2:15.733–2:18.466
zh那這期視頻呢是由 Hostinger 贊助的
那這期視頻呢是由 Hostinger 贊助的
2:18.500–2:28.000
zh而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台
而這次合作剛好也給了我一個機會來測試這台 AI-native computer 能不能不經過我手動操作服務器後台
2:28.000–2:32.600
zh就直接把 Agent 在本地完成的工作送到真實的互聯網
就直接把 Agent 在本地完成的工作送到真實的互聯網
2:32.800–2:35.433
zh我沒有讓 Codex 給我寫一個 Todo List
我沒有讓 Codex 給我寫一個 Todo List
2:35.700–2:41.500
zh也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo
也沒有讓它生成一個看起來很漂亮、然後永遠停在 localhost 的 Demo
2:41.566–2:43.933
zh我給了它一個真的項目，就是：
我給了它一個真的項目，就是：
2:43.933–2:49.433
zh我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來
我們要把散落在 X、GitHub 和其他地方的 Jev 項目整理出來
2:49.433–2:55.400
zh做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站
做成一個可以長期維護、可以搜索、以及呢可以不斷加入新項目的網站
2:55.633–3:01.700
zh那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站
那Codex就開始在這台 M1 上寫代碼、整理數據、運行網站
3:01.766–3:04.400
zh再自己打開瀏覽器檢查結果
再自己打開瀏覽器檢查結果
3:04.400–3:04.966
zh後來
後來
3:04.966–3:07.133
zh它又通過 Hostinger Connector (MCP)
它又通過 Hostinger Connector (MCP)
3:07.133–3:10.033
zh把網站真正部署到了互聯網上
把網站真正部署到了互聯網上
3:10.433–3:14.200
zh整個過程從想法、到代碼、到部署到互聯網
整個過程從想法、到代碼、到部署到互聯網
3:14.200–3:15.600
zh也就半天的時間
也就半天的時間
3:15.766–3:18.033
zh然後我又在 X 上發了一條推文
然後我又在 X 上發了一條推文
3:18.033–3:20.033
zh我說：“那台舊 M1 Mac mini
我說：“那台舊 M1 Mac mini
3:20.033–3:21.400
zh現在有工作了
現在有工作了
3:21.400–3:23.133
zh它運行著 Omarchy
它運行著 Omarchy
3:23.166–3:29.433
zh我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖
我和 Codex 一起做出了 Jev Atlas——一個收錄了 171 個 Jev 項目的地圖
3:29.500–3:32.366
zh每個項目都鏈接到真實的來源
每個項目都鏈接到真實的來源
3:32.366–3:33.533
zh還可以搜索
還可以搜索
3:33.533–3:37.233
zh並通過一張實時動態圖展示整個生態
並通過一張實時動態圖展示整個生態
3:37.566–3:40.600
zhCodex 完成了網站的構建和測試
Codex 完成了網站的構建和測試
3:40.600–3:44.200
zh通過 Hostinger MCP 把它部署到互聯網上
通過 Hostinger MCP 把它部署到互聯網上
3:44.233–3:48.366
zh然後又對公開網站進行了驗證——整個過程
然後又對公開網站進行了驗證——整個過程
3:48.366–3:51.766
zh都是從這台 M1 上完成和調度的
都是從這台 M1 上完成和調度的
3:51.933–3:53.133
zh這開始讓我覺得
這開始讓我覺得
3:53.133–3:56.633
zh這才像是一台 AI 原生電腦（AI-native computer）該有的樣子
這才像是一台 AI 原生電腦（AI-native computer）該有的樣子
3:57.000–3:59.800
zh所以這期視頻，我們就從頭看看
所以這期視頻，我們就從頭看看
3:59.800–4:03.733
zh這台被我叫作 MacOmarchy 的 AI-native computer
這台被我叫作 MacOmarchy 的 AI-native computer
4:03.733–4:06.133
zh到底是怎麼開始真正乾活的
到底是怎麼開始真正乾活的
4:06.566–4:07.533
zh其實一開始
其實一開始
4:07.533–4:11.300
zh我並沒有打算讓這台 M1 做什麼特別複雜的事情
我並沒有打算讓這台 M1 做什麼特別複雜的事情
4:11.333–4:12.566
zh我只是很好奇
我只是很好奇
4:12.566–4:17.033
zh當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後
當 Omarchy 這樣的系統真正放到一台 Mac 電腦裡面以後
4:17.033–4:18.766
zh它到底會有什麼不一樣？
它到底會有什麼不一樣？
4:19.000–4:21.700
zh很快，我就碰到了一個很小的問題
很快，我就碰到了一個很小的問題
4:22.033–4:27.133
zh就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下
就是我之前呢臨時給這台電腦配的羅技鼠標放在了樓下
4:27.300–4:29.433
zh我不想專門跑下去拿
我不想專門跑下去拿
4:29.800–4:32.233
zh書桌上倒是有一隻 Magic Mouse
書桌上倒是有一隻 Magic Mouse
4:32.233–4:33.666
zh但問題就變成了：
但問題就變成了：
4:33.700–4:37.033
zh我怎麼把它連到這台 MacOmarchy 上呢？
我怎麼把它連到這台 MacOmarchy 上呢？
4:37.333–4:38.600
zhOmarchy 本身的設計
Omarchy 本身的設計
4:38.600–4:42.166
zh其實已經刻意減少了很多對鼠標的依賴
其實已經刻意減少了很多對鼠標的依賴
4:42.166–4:45.333
zh很多操作直接用鍵盤就能完成
很多操作直接用鍵盤就能完成
4:45.500–4:47.966
zh但是，如果真要選一段文字
但是，如果真要選一段文字
4:47.966–4:49.866
zh或者做一些細一點的操作
或者做一些細一點的操作
4:49.900–4:51.566
zh我還是覺得鼠標方便
我還是覺得鼠標方便
4:51.766–4:53.366
zh所以我想到了 Codex
所以我想到了 Codex
4:53.533–4:56.033
zh我按下 Ctrl + 回車打開終端
我按下 Ctrl + 回車打開終端
4:56.033–4:57.133
zh輸入 Codex
輸入 Codex
4:57.200–5:00.900
zh然後直接告訴它：幫我把這只 Magic Mouse 連上
然後直接告訴它：幫我把這只 Magic Mouse 連上
5:01.100–5:06.033
zh接下來它自己去掃描藍牙設備、添加設備、完成連接
接下來它自己去掃描藍牙設備、添加設備、完成連接
5:06.366–5:07.633
zh鼠標連上以後
鼠標連上以後
5:07.633–5:10.266
zh我又發現指針移動得太快了
我又發現指針移動得太快了
5:10.266–5:13.333
zh和我平時在 macOS 上的手感差很多
和我平時在 macOS 上的手感差很多
5:13.533–5:15.200
zh我就繼續告訴 Codex
我就繼續告訴 Codex
5:15.233–5:16.766
zh讓它把速度降下來
讓它把速度降下來
5:16.833–5:18.333
zh然後還有滾動方向
然後還有滾動方向
5:18.333–5:21.700
zh我不喜歡那種更像 Windows 的反向滾動習慣
我不喜歡那種更像 Windows 的反向滾動習慣
5:21.933–5:25.333
zh所以也讓它一起調成我平時用 Mac 的感覺
所以也讓它一起調成我平時用 Mac 的感覺
5:25.700–5:28.233
zh整個過程，我當時就覺得很有意思
整個過程，我當時就覺得很有意思
5:28.400–5:32.166
zh因為呢如果是在傳統的電腦使用方式裡面
因為呢如果是在傳統的電腦使用方式裡面
5:32.166–5:38.800
zh我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向
我可能會打開設置、找到藍牙、再去找鼠標、再去調指針速度和滾動方向
5:39.000–5:41.500
zh那套界面本來就是給人設計的
那套界面本來就是給人設計的
5:41.533–5:42.666
zh但對 AI 來說
但對 AI 來說
5:42.700–5:47.333
zh它其實根本就不需要先學會在屏幕上找到那個藍牙圖標
它其實根本就不需要先學會在屏幕上找到那個藍牙圖標
5:47.500–5:49.900
zh再模擬我去點哪個按鈕
再模擬我去點哪個按鈕
5:49.966–5:52.333
zh它可以直接和系統本身打交道
它可以直接和系統本身打交道
5:52.566–5:53.833
zh對我們人來說
對我們人來說
5:54.633–5:56.533
zh瀏覽、點擊、拖動當然很自然
瀏覽、點擊、拖動當然很自然
5:56.566–5:59.366
zh但對 AI 來說，屏幕上的這些按鈕
但對 AI 來說，屏幕上的這些按鈕
5:59.366–6:01.833
zh很多時候反而只是繞了一層
很多時候反而只是繞了一層
6:02.100–6:04.733
zh這一下就讓我第一次很明顯地感覺到
這一下就讓我第一次很明顯地感覺到
6:04.733–6:07.600
zh這台舊 M1 和我其他幾台蘋果電腦
這台舊 M1 和我其他幾台蘋果電腦
6:07.600–6:10.033
zh好像開始有了一點不一樣了
好像開始有了一點不一樣了
6:10.200–6:11.866
zh但就是這個很小的體驗
但就是這個很小的體驗
6:11.900–6:13.033
zh就讓我開始想：
就讓我開始想：
6:13.100–6:16.400
zh如果這台電腦不只是幫我改幾個設置
如果這台電腦不只是幫我改幾個設置
6:16.400–6:19.200
zh而是真的讓它做一個完整的項目
而是真的讓它做一個完整的項目
6:19.200–6:20.600
zh那會發生什麼呢？
那會發生什麼呢？
6:20.833–6:22.933
zh所以我想給它一個真的任務
所以我想給它一個真的任務
6:22.933–6:25.600
zh剛好這幾天，我一直在關注 Jev
剛好這幾天，我一直在關注 Jev
6:25.733–6:27.566
zh如果你還不知道 Jev 是什麼
如果你還不知道 Jev 是什麼
6:27.566–6:30.333
zh這裡呢你也暫時不用管它的技術原理
這裡呢你也暫時不用管它的技術原理
6:30.333–6:32.633
zh你只需要知道，Jev 開放以後
你只需要知道，Jev 開放以後
6:32.633–6:37.433
zhX 上就很快出現了大量開發者做出來的實驗和項目
X 上就很快出現了大量開發者做出來的實驗和項目
6:37.433–6:40.033
zh有人把它接進 Coding Agent
有人把它接進 Coding Agent
6:40.033–6:44.233
zh有人拿它做瀏覽器操作、工具選擇、模型路由
有人拿它做瀏覽器操作、工具選擇、模型路由
6:44.300–6:50.366
zh也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情
也有人在研究它還能替 Agent 處理哪些原本需要大模型反復判斷的事情
6:50.600–6:53.833
zh問題是，這些東西散得到處都是
問題是，這些東西散得到處都是
6:53.900–6:55.366
zh有些在 X 的帖子里
有些在 X 的帖子里
6:55.366–6:57.066
zh有些藏在 GitHub 里
有些藏在 GitHub 里
6:57.100–6:58.733
zh有些有自己的網站
有些有自己的網站
6:58.733–7:01.166
zh還有一些你可能今天刷到一次
還有一些你可能今天刷到一次
7:01.166–7:03.533
zh過兩天想找就已經找不到了
過兩天想找就已經找不到了
7:03.600–7:05.666
zh所以我冒出了一個很簡單的想法：
所以我冒出了一個很簡單的想法：
7:05.700–7:09.166
zh就是能不能把這些正在出現的 Jev 項目
就是能不能把這些正在出現的 Jev 項目
7:09.166–7:10.933
zh整理成一張地圖呢？
整理成一張地圖呢？
7:11.233–7:16.400
zh我想要的是一個以後還能繼續生長的東西——項目有真實的來源
我想要的是一個以後還能繼續生長的東西——項目有真實的來源
7:16.400–7:18.233
zh能搜索、能分類；
能搜索、能分類；
7:18.233–7:19.766
zh如果以後發現新的項目
如果以後發現新的項目
7:19.766–7:21.433
zh還可以繼續加進去；
還可以繼續加進去；
7:21.433–7:23.733
zh然後最好打開首頁的時候
然後最好打開首頁的時候
7:23.733–7:27.500
zh還能直接看到這個生態到底長成了什麼樣子
還能直接看到這個生態到底長成了什麼樣子
7:27.733–7:30.166
zh於是我把這個想法交給了 Codex
於是我把這個想法交給了 Codex
7:30.233–7:33.800
zh我來決定方向和品味，Codex負責乾活
我來決定方向和品味，Codex負責乾活
7:33.966–7:35.133
zh比如這個網站
比如這個網站
7:35.133–7:37.533
zh我最後把它叫作 Jev Atlas
我最後把它叫作 Jev Atlas
7:37.700–7:41.033
zh我希望首頁最顯眼的不是一堆項目卡片
我希望首頁最顯眼的不是一堆項目卡片
7:41.033–7:43.933
zh而是一張 Obsidian 那樣的關係圖
而是一張 Obsidian 那樣的關係圖
7:44.100–7:45.166
zh我還有一個要求：
我還有一個要求：
7:45.166–7:47.200
zh就是這張圖不能是裝飾
就是這張圖不能是裝飾
7:47.733–7:49.333
zh如果屏幕上有一個節點
如果屏幕上有一個節點
7:49.333–7:51.833
zh它就必須對應真實的數據
它就必須對應真實的數據
7:51.833–7:53.733
zh如果兩個節點之間有一條線
如果兩個節點之間有一條線
7:53.933–7:56.100
zh也必須真的存在關係
也必須真的存在關係
7:56.500–7:58.766
zh所以最後這張圖里的連接
所以最後這張圖里的連接
7:58.766–8:01.000
zh全部來自真實的項目數據
全部來自真實的項目數據
8:01.233–8:03.666
zh這也是為什麼你現在看到它的時候
這也是為什麼你現在看到它的時候
8:03.700–8:06.000
zh會覺得這張圖好像一直在“長”。
會覺得這張圖好像一直在“長”。
8:06.233–8:13.000
zh因為它呢不是預先畫死的一張背景圖
因為它呢不是預先畫死的一張背景圖
8:13.000–8:15.233
zh這張圖本身也會跟著變化
這張圖本身也會跟著變化
8:15.566–8:16.600
zh點擊分類
點擊分類
8:16.600–8:18.933
zh星圖上對應的區域就會點亮
星圖上對應的區域就會點亮
8:19.333–8:20.133
zh做到這裡
做到這裡
8:20.233–8:23.200
zh其實一個普通的 AI Demo 已經可以結束了
其實一個普通的 AI Demo 已經可以結束了
8:23.200–8:25.900
zh但這恰恰是我不想停下來的地方
但這恰恰是我不想停下來的地方
8:25.933–8:28.833
zh因為只要它還運行在 localhost
因為只要它還運行在 localhost
8:28.833–8:32.333
zh這件事本質上仍然只是發生在我的電腦里
這件事本質上仍然只是發生在我的電腦里
8:32.433–8:34.333
zh我真正想測試的是下一步
我真正想測試的是下一步
8:34.333–8:36.666
zh也就是：這台電腦里的 Agent
也就是：這台電腦里的 Agent
8:36.700–8:38.966
zh能不能自己把剛剛完成的工作
能不能自己把剛剛完成的工作
8:38.966–8:40.966
zh送到真實的互聯網上呢？
送到真實的互聯網上呢？
8:41.333–8:44.133
zh這一步聽起來好像只是“部署一個網站”，
這一步聽起來好像只是“部署一個網站”，
8:44.133–8:45.333
zh但對於我來說
但對於我來說
8:45.333–8:48.366
zh它其實是整個實驗里很關鍵的一步
它其實是整個實驗里很關鍵的一步
8:48.433–8:49.933
zh因為在 localhost 裡面
因為在 localhost 裡面
8:49.933–8:52.466
zh一切都很安全——代碼寫壞了
一切都很安全——代碼寫壞了
8:52.466–8:53.400
zh可以重來；
可以重來；
8:53.400–8:55.433
zh頁面打不開，可以繼續改；
頁面打不開，可以繼續改；
8:55.433–8:57.766
zh哪怕整個項目跑不起來
哪怕整個項目跑不起來
8:57.766–9:00.033
zh也只是影響到我自己的這台電腦
也只是影響到我自己的這台電腦
9:00.500–9:03.166
zh可一旦你把它發佈到互聯網上
可一旦你把它發佈到互聯網上
9:03.166–9:04.633
zh事情就不一樣了
事情就不一樣了
9:04.700–9:10.200
zh它要面對真實的服務器環境、真實的構建過程、真實的運行日誌
它要面對真實的服務器環境、真實的構建過程、真實的運行日誌
9:10.200–9:11.000
zh最後
最後
9:11.000–9:13.900
zh還有一個所有人都能打開的網址
還有一個所有人都能打開的網址
9:14.033–9:15.766
zh也就是說，從這裡開始
也就是說，從這裡開始
9:15.766–9:18.733
zhCodex 做的就不再只是一個本地 Demo 了
Codex 做的就不再只是一個本地 Demo 了
9:18.733–9:21.133
zh它要真的把一個結果交付出去
它要真的把一個結果交付出去
9:21.300–9:22.333
zh而這一層
而這一層
9:22.333–9:26.966
zh過去經常意味著你得去碰雲服務商的管理後台
過去經常意味著你得去碰雲服務商的管理後台
9:27.366–9:28.033
zh說實話
說實話
9:28.033–9:31.033
zh我自己並不喜歡這些流程式的操作
我自己並不喜歡這些流程式的操作
9:31.100–9:39.200
zh打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值
打開控制台、找菜單、配置參數、上傳文件、看日誌——這些界面當然有它們存在的價值
9:39.200–9:43.666
zh但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼
但如果我已經習慣了直接用自然語言告訴 Agent 我要做什麼
9:43.700–9:44.833
zh我就會開始想：
我就會開始想：
9:44.833–9:46.533
zh為什麼到了服務器這裡
為什麼到了服務器這裡
9:46.533–9:49.366
zh我又要重新變回那個點菜單的人呢？
我又要重新變回那個點菜單的人呢？
9:49.633–9:52.366
zh我後來咨詢了自己的雲服務商 Hostinger
我後來咨詢了自己的雲服務商 Hostinger
9:52.366–9:56.433
zh剛好發現他們有一個叫 Hostinger Connector 的東西
剛好發現他們有一個叫 Hostinger Connector 的東西
9:56.766–10:01.800
zh它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent
它把 Hostinger 的這些能力通過 MCP 接給 AI Coding Agent
10:02.100–10:03.366
zh授權也很簡單
授權也很簡單
10:03.366–10:07.866
zh通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來
通過瀏覽器 OAuth 把 Agent 和 hPanel 連起來
10:07.900–10:09.933
zh不需要自己折騰 API Key
不需要自己折騰 API Key
10:09.933–10:14.333
zh我這次的測試用的是 Hostinger 的 Web App Hosting 套餐
我這次的測試用的是 Hostinger 的 Web App Hosting 套餐
10:14.533–10:17.700
zh這也是他們在這次 Connector 流程里推薦的方案
這也是他們在這次 Connector 流程里推薦的方案
10:17.766–10:19.366
zh那如果你自己也想試試
那如果你自己也想試試
10:19.366–10:24.633
zh可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面
可以通過我放在視頻簡介和置頂評論里的專屬鏈接進入這個頁面
10:25.033–10:27.533
zh點擊這裡，輸入優惠碼 WOWINSIGHT
點擊這裡，輸入優惠碼 WOWINSIGHT
10:27.533–10:29.166
zh就能拿到對應的折扣
就能拿到對應的折扣
10:29.333–10:33.333
zh好、那以前呢如果我要把這樣一個項目部署出去
好、那以前呢如果我要把這樣一個項目部署出去
10:33.333–10:39.100
zh最常規的方式當然還是打開網頁後台、上傳文件、配置 Node
最常規的方式當然還是打開網頁後台、上傳文件、配置 Node
10:39.100–10:41.166
zhjs，確認入口文件
js，確認入口文件
10:41.166–10:42.800
zh然後再去看部署狀態
然後再去看部署狀態
10:43.200–10:45.566
zh你現在畫面里看到的這些截圖
你現在畫面里看到的這些截圖
10:45.566–10:48.400
zh其實就是我前面手動配置時留下來的
其實就是我前面手動配置時留下來的
10:48.433–10:51.966
zh為了和後面 Codex 自己運維網站做個對比
為了和後面 Codex 自己運維網站做個對比
10:51.966–10:53.900
zh我特意把它們保留了下來
我特意把它們保留了下來
10:54.233–10:56.933
zh其實呢這些事情本身並不難
其實呢這些事情本身並不難
10:56.933–10:58.466
zh但這一次不一樣了
但這一次不一樣了
10:58.500–10:59.766
zh所以我想試試看
所以我想試試看
10:59.766–11:02.633
zh我是不是只需要面對自己的 Agent
我是不是只需要面對自己的 Agent
11:02.633–11:04.500
zh就能把後面的事情做完
就能把後面的事情做完
11:04.933–11:08.066
zh既然我已經有了一台所謂的 AI-native computer
既然我已經有了一台所謂的 AI-native computer
11:08.100–11:09.400
zh那服務器這一邊
那服務器這一邊
11:09.400–11:13.200
zh能不能也直接變成 Agent 工作環境的一部分呢？
能不能也直接變成 Agent 工作環境的一部分呢？
11:13.500–11:17.300
zh所以我先把 Hostinger 官方的 MCP 接進 Codex
所以我先把 Hostinger 官方的 MCP 接進 Codex
11:17.366–11:19.833
zh然後通過瀏覽器完成授權
然後通過瀏覽器完成授權
11:20.133–11:21.000
zh接上以後
接上以後
11:21.000–11:24.600
zh它看到的就不再只是我這台 M1 上的文件
它看到的就不再只是我這台 M1 上的文件
11:24.733–11:33.633
zh它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs
它可以直接讀取 Hostinger 上的網站和部署信息、可以發起新的部署、也可以查看Build Logs 和 Runtime Logs
11:33.933–11:38.266
zh比如我只需要問一句：「查看 Hostinger Connector (MCP) 有哪些功能？」
比如我只需要問一句：「查看 Hostinger Connector (MCP) 有哪些功能？」
11:38.266–11:38.633
en”
”
11:38.633–11:42.566
zhCodex 就會直接把當前可用的能力列出來
Codex 就會直接把當前可用的能力列出來
11:42.633–11:45.000
zh我這裡一共能看到 74 個工具
我這裡一共能看到 74 個工具
11:45.200–11:49.200
zh我不會在這裡把 74 個工具一個一個念給你聽
我不會在這裡把 74 個工具一個一個念給你聽
11:49.300–11:50.266
zh你只需要知道
你只需要知道
11:50.300–11:53.566
zh像網站、域名、SSL、Node.js、靜態站點
像網站、域名、SSL、Node.js、靜態站點
11:53.566–12:02.933
zhjs、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力
js、靜態站點、WordPress、Git 自動部署、數據庫、定時任務、文件、診斷這些常見的網站維護能力
12:02.933–12:04.666
zh基本上都已經在裡面了
基本上都已經在裡面了
12:04.666–12:07.300
zh而且 Codex 還可以直接告訴我：
而且 Codex 還可以直接告訴我：
12:07.300–12:09.200
zh為了部署 Jev Atlas
為了部署 Jev Atlas
12:09.200–12:11.566
zh它實際調用過哪些工具
它實際調用過哪些工具
12:11.566–12:14.633
zh我覺得呢雲服務商能配套這些功能
我覺得呢雲服務商能配套這些功能
12:14.633–12:16.266
zh其實是很重要的
其實是很重要的
12:16.266–12:18.033
zh因為在沒有 MCP 的時候
因為在沒有 MCP 的時候
12:18.033–12:20.633
zhCodex 寫完代碼，到了“上線”這一步
Codex 寫完代碼，到了“上線”這一步
12:20.633–12:27.933
zh工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去
工作呢通常還是要交還給我——我要去打開瀏覽器、登錄服務器後台、把文件傳上去
12:28.000–12:29.000
zh如果出了問題
如果出了問題
12:29.133–12:32.333
zh我還要再把錯誤信息複製回來告訴它
我還要再把錯誤信息複製回來告訴它
12:32.533–12:36.466
zh人在中間一直充當著那個搬運信息的人
人在中間一直充當著那個搬運信息的人
12:36.833–12:40.866
zh這其實也是 Hostinger Connector (MCP) 對我最有價值的地方
這其實也是 Hostinger Connector (MCP) 對我最有價值的地方
12:41.033–12:44.666
zh它讓我不用離開現在這個 Agent 的工作環境
它讓我不用離開現在這個 Agent 的工作環境
12:44.666–12:48.166
zh就能處理網站部署和運維的事情
就能處理網站部署和運維的事情
12:48.366–12:49.633
zh網站上線以後
網站上線以後
12:49.633–12:58.000
zhSSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了
SSL、CDN、WAF 和 DDoS 防護這些 hosting 層面的基礎能力也已經包含在裡面了
12:58.033–12:59.400
zh有了 MCP 以後
有了 MCP 以後
12:59.666–13:06.133
zh這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；
這條鏈就完整了——Codex 在本地修改代碼、本地運行、本地打開瀏覽器檢查；
13:06.233–13:06.966
zh確認以後
確認以後
13:06.966–13:10.000
zh它可以繼續調用 Hostinger Connector (MCP)，
它可以繼續調用 Hostinger Connector (MCP)，
13:10.000–13:12.533
zh把同一個項目送到服務器
把同一個項目送到服務器
13:12.866–13:16.166
zh在這裡呀我更想告訴你我的實際體驗！
在這裡呀我更想告訴你我的實際體驗！
13:16.366–13:20.200
zh就是你不需要先學會 Hostinger 後台所有的菜單
就是你不需要先學會 Hostinger 後台所有的菜單
13:20.266–13:21.366
zh你哪裡不明白
你哪裡不明白
13:21.366–13:23.366
zh你就直接問 Codex 就好了
你就直接問 Codex 就好了
13:23.533–13:26.000
zh不過，這裡我還是要提醒一句：
不過，這裡我還是要提醒一句：
13:26.000–13:27.633
zh在真正部署之前
在真正部署之前
13:27.633–13:32.900
zh我仍然還是讓 Codex 先把本地版本完整的檢查了一遍
我仍然還是讓 Codex 先把本地版本完整的檢查了一遍
13:32.933–13:35.866
zh不是簡單看一眼首頁能不能打開那種哦
不是簡單看一眼首頁能不能打開那種哦
13:35.866–13:39.666
zh我是讓它真的用瀏覽器去操作和檢查
我是讓它真的用瀏覽器去操作和檢查
13:39.933–13:40.733
zh到了這裡
到了這裡
13:40.733–13:49.800
zh到了這裡，我們手裡已經有一個本地可以正常工作的版本了——它有 171 個項目、569 個節點、和 701 條真實關係
到了這裡，我們手裡已經有一個本地可以正常工作的版本了——它有 171 個項目、569 個節點、和 701 條真實關係
13:50.200–13:51.333
zh搜索可以用
搜索可以用
13:51.333–13:53.733
zh圖譜里的連接來自真實數據
圖譜里的連接來自真實數據
13:53.733–13:55.666
zh數據也能正常加載
數據也能正常加載
13:55.833–13:58.266
zh本地測試通過，於是我告訴 Codex：
本地測試通過，於是我告訴 Codex：
13:58.266–13:59.900
zh把它部署到 Hostinger
把它部署到 Hostinger
14:00.000–14:03.733
zh不過第一次請求呢甚至還沒有真正走到構建
不過第一次請求呢甚至還沒有真正走到構建
14:03.933–14:07.533
zh網絡連接在 TLS 階段斷了一次
網絡連接在 TLS 階段斷了一次
14:07.566–14:09.200
zhCodex 拿到錯誤以後
Codex 拿到錯誤以後
14:09.200–14:10.666
zh又重新試了一次
又重新試了一次
14:11.033–14:13.000
zh第二次，文件成功上傳
第二次，文件成功上傳
14:13.133–14:14.266
zhBuild 也成功了
Build 也成功了
14:14.266–14:16.433
zh當時看起來，一切都很順利
當時看起來，一切都很順利
14:16.433–14:19.800
zh然後我打開那個網址，顯示的卻是503
然後我打開那個網址，顯示的卻是503
14:20.266–14:21.066
zh這個時候
這個時候
14:21.133–14:23.800
zh這個實驗才真正開始變得有意思
這個實驗才真正開始變得有意思
14:23.866–14:24.866
zh因為接下來
因為接下來
14:24.866–14:27.766
zh我沒有去登錄服務器後台查問題
我沒有去登錄服務器後台查問題
14:28.033–14:30.700
zh我也沒有把 503 截圖丟給 Codex
我也沒有把 503 截圖丟給 Codex
14:30.733–14:32.533
zh然後自己到處找日誌
然後自己到處找日誌
14:32.533–14:34.166
zh我只是繼續看著它
我只是繼續看著它
14:34.466–14:37.133
zh服務器明明告訴它 Build completed
服務器明明告訴它 Build completed
14:37.200–14:39.100
zh為什麼網站還是掛了呢？
為什麼網站還是掛了呢？
14:39.200–14:39.866
zh下一步
下一步
14:39.866–14:43.133
zh就輪到這台 MacOmarchy 自己去找答案了
就輪到這台 MacOmarchy 自己去找答案了
14:43.366–14:49.066
zhCodex 直接通過 Hostinger Connector (MCP) 去讀取這次部署的 Runtime Logs
Codex 直接通過 Hostinger Connector (MCP) 去讀取這次部署的 Runtime Logs
14:49.066–14:50.733
zh很快就找到了一行錯誤：
很快就找到了一行錯誤：
14:51.033–14:55.033
zh問題也很快被定位到了項目根目錄的 app
問題也很快被定位到了項目根目錄的 app
14:55.033–14:55.800
enjs
js
14:56.133–14:58.366
zh它修的過程很快，我們就略過吧！
它修的過程很快，我們就略過吧！
14:58.466–14:59.033
zh這裡
這裡
14:59.033–15:02.000
zh我覺得關鍵的已經不是這個錯誤本身了
我覺得關鍵的已經不是這個錯誤本身了
15:02.000–15:04.000
zh而是它找到問題以後
而是它找到問題以後
15:04.000–15:06.000
zh接下來還可以繼續往下做
接下來還可以繼續往下做
15:06.366–15:07.433
zh修改完成以後
修改完成以後
15:07.433–15:12.166
zhCodex 先在這台 M1 上把 Jev Atlas 重新跑起來
Codex 先在這台 M1 上把 Jev Atlas 重新跑起來
15:12.166–15:16.600
zh再用瀏覽器檢查頁面、數據、圖譜和搜索
再用瀏覽器檢查頁面、數據、圖譜和搜索
15:16.633–15:18.266
zh確認本地沒有問題之後
確認本地沒有問題之後
15:18.266–15:22.100
zh它才再次通過 Hostinger Connector 發起部署
它才再次通過 Hostinger Connector 發起部署
15:22.433–15:25.366
zh但它沒有停在“部署成功”這幾個字上
但它沒有停在“部署成功”這幾個字上
15:25.466–15:29.166
zhCodex 接著打開真正公開的 Jev Atlas
Codex 接著打開真正公開的 Jev Atlas
15:29.200–15:33.800
zh把頁面加載、搜索和數據讀取重新檢查了一遍
把頁面加載、搜索和數據讀取重新檢查了一遍
15:34.133–15:36.966
zh到這裡，這個實驗才真正閉環了：
到這裡，這個實驗才真正閉環了：
15:36.966–15:39.200
zh在本地做出來，送到服務器；
在本地做出來，送到服務器；
15:39.366–15:41.866
zh線上出錯以後自己讀日誌
線上出錯以後自己讀日誌
15:41.866–15:43.033
zh回到本地修復
回到本地修復
15:43.033–15:46.700
zh再重新部署，最後去公開網站驗收
再重新部署，最後去公開網站驗收
15:47.000–15:48.566
zh也就是從這一刻開始
也就是從這一刻開始
15:48.566–15:54.433
zh我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了
我覺得這台 MacOmarchy 已經不只是讓我用自然語言操作一台電腦了
15:54.433–15:56.566
zh它開始能夠把本地的工作
它開始能夠把本地的工作
15:56.566–15:59.300
zh真正延伸到外面的服務和互聯網
真正延伸到外面的服務和互聯網
15:59.433–16:01.366
zh現在整個過程走完以後
現在整個過程走完以後
16:01.366–16:03.866
zh我想解釋一下，為什麼我會覺得
我想解釋一下，為什麼我會覺得
16:03.866–16:07.166
zh這才開始像一台 AI-native computer
這才開始像一台 AI-native computer
16:07.600–16:09.666
zh因為真正發生變化的
因為真正發生變化的
16:09.666–16:11.866
zh並不是這台 M1 突然變快了
並不是這台 M1 突然變快了
16:11.866–16:14.466
zh也不是它多了什麼新的硬件能力
也不是它多了什麼新的硬件能力
16:14.566–16:16.100
zh其實真正變掉的
其實真正變掉的
16:16.100–16:18.866
zh是我和這台電腦相處的方式
是我和這台電腦相處的方式
16:19.066–16:21.200
zh前面連接 Magic Mouse 的時候
前面連接 Magic Mouse 的時候
16:21.233–16:23.366
zh我已經有過一次這種感覺了
我已經有過一次這種感覺了
16:23.366–16:25.066
zh到了 Jev Atlas 的時候
到了 Jev Atlas 的時候
16:25.200–16:27.366
zh這種變化呢就更明顯了
這種變化呢就更明顯了
16:27.433–16:28.200
zh一開始
一開始
16:28.200–16:31.600
zh我只是讓 Codex 把網站做出來、跑起來
我只是讓 Codex 把網站做出來、跑起來
16:31.600–16:35.333
zh再通過 Hostinger Connector (MCP) 把它送到互聯網上
再通過 Hostinger Connector (MCP) 把它送到互聯網上
16:35.366–16:37.733
zh但網站真正上線以後
但網站真正上線以後
16:37.733–16:40.033
zh我馬上又碰到了一個更現實的問題：
我馬上又碰到了一個更現實的問題：
16:40.033–16:43.733
zh就是 Jev 生態還在不斷出現新的項目
就是 Jev 生態還在不斷出現新的項目
16:43.733–16:45.966
zh那這個網站以後誰來維護呢？
那這個網站以後誰來維護呢？
16:46.066–16:48.066
zh所以我又往前走了一步
所以我又往前走了一步
16:48.066–16:50.933
zh把 Jev 本身也放進了維護流程
把 Jev 本身也放進了維護流程
16:51.233–16:53.400
zh它負責的事情其實很簡單
它負責的事情其實很簡單
16:53.666–16:57.733
zh普通代碼先處理那些完全可以確定的重復；
普通代碼先處理那些完全可以確定的重復；
16:57.733–17:02.833
zh如果新項目和現有項目之間真的出現了一個“看起來很像”的對象
如果新項目和現有項目之間真的出現了一個“看起來很像”的對象
17:02.833–17:06.366
zh那再讓 Jev 判斷它們到底是什麼關係；
那再讓 Jev 判斷它們到底是什麼關係；
17:06.366–17:08.600
zh只有更模糊和更複雜的例外
只有更模糊和更複雜的例外
17:08.600–17:10.300
zh才繼續交給 Codex
才繼續交給 Codex
17:10.633–17:14.733
zh我呢就先拿了一批昨天的真實數據跑了一次
我呢就先拿了一批昨天的真實數據跑了一次
17:14.833–17:18.766
zh原本需要 Codex 深度閱讀的項目有 13 個
原本需要 Codex 深度閱讀的項目有 13 個
17:18.766–17:21.000
zh把這套流程加進去以後
把這套流程加進去以後
17:21.000–17:22.466
zh最後只剩下 1 個
最後只剩下 1 個
17:22.466–17:25.733
zh而且不只是 Codex 少看了幾個項目
而且不只是 Codex 少看了幾個項目
17:25.733–17:27.333
zh同一輪處理的總時間
同一輪處理的總時間
17:27.333–17:29.600
zh也從大約 36.9 秒
也從大約 36.9 秒
17:29.600–17:31.166
zh降到了 10.2 秒
降到了 10.2 秒
17:31.233–17:32.833
zh這不是一個嚴格的 benchmark
這不是一個嚴格的 benchmark
17:32.833–17:34.866
zh但差別已經非常明顯
但差別已經非常明顯
17:35.133–17:41.066
zh以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；
以前很多候選都要 Codex 自己重新打開來源、再判斷一遍；
17:41.166–17:43.133
zh而現在大部分的簡單情況
而現在大部分的簡單情況
17:43.133–17:45.400
zh在前面就已經被處理掉了
在前面就已經被處理掉了
17:45.533–17:46.266
zh接下來
接下來
17:46.266–17:51.266
zh我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里
我們把這套流程正式寫進了 Jev Atlas 自己的維護規則里
17:51.266–17:51.866
zh然後
然後
17:51.866–17:56.066
zh又拿一輪全新的 Grok 增量調查真正跑了一次
又拿一輪全新的 Grok 增量調查真正跑了一次
17:56.333–17:58.566
zh這一次一共有 28 個候選身份
這一次一共有 28 個候選身份
17:58.566–18:01.566
zh最後真正需要 Codex 深度檢查的
最後真正需要 Codex 深度檢查的
18:01.566–18:02.566
zh只有 3 個
只有 3 個
18:02.566–18:03.600
zh而到了這一步
而到了這一步
18:03.600–18:06.400
zh我實際上要做的事情反而越來越少了
我實際上要做的事情反而越來越少了
18:06.400–18:07.666
zh你看啊：第一步
你看啊：第一步
18:07.666–18:09.933
zh讓 Grok 去找新的 Jev 項目
讓 Grok 去找新的 Jev 項目
18:09.933–18:13.166
zh第二步，把最新的調查交給 Codex
第二步，把最新的調查交給 Codex
18:13.166–18:16.233
zh讓它按照 Jev Atlas 自己的維護流程
讓它按照 Jev Atlas 自己的維護流程
18:16.233–18:19.633
zh也就是已經包含 Jev 調用的這套流程
也就是已經包含 Jev 調用的這套流程
18:19.633–18:22.333
zh去查重、篩選、判斷
去查重、篩選、判斷
18:22.333–18:27.200
zh再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認
再告訴我哪些應該新增、哪些已經存在、哪些真的需要我確認
18:27.600–18:29.033
zh我審核完以後
我審核完以後
18:29.033–18:32.733
zh只需要告訴它一句：「應用這次審核通過的更新
只需要告訴它一句：「應用這次審核通過的更新
18:32.733–18:33.966
zh我在本地預覽一下
我在本地預覽一下
18:33.966–18:34.400
en”
”
18:34.400–18:36.933
zhCodex 就會把更新寫進去
Codex 就會把更新寫進去
18:36.933–18:38.066
zh重新跑驗證
重新跑驗證
18:38.133–18:40.400
zh再把本地版本打開給我看
再把本地版本打開給我看
18:40.633–18:41.700
zh本地確認沒問題
本地確認沒問題
18:41.766–18:43.800
zh我再說一句：「發佈到 Hostinger
我再說一句：「發佈到 Hostinger
18:43.800–18:44.133
en”
”
18:44.133–18:47.633
zh後面的提交、部署、Build、Runtime Logs
後面的提交、部署、Build、Runtime Logs
18:47.633–18:49.400
zh再到公開網站的檢查
再到公開網站的檢查
18:49.400–18:53.266
zh就沿著我們前面已經搭好的這條鏈繼續走下去
就沿著我們前面已經搭好的這條鏈繼續走下去
18:53.366–18:54.033
zh最後
最後
18:54.033–18:58.266
zh我又去 Hostinger 上已經公開的網站重新驗收了一遍
我又去 Hostinger 上已經公開的網站重新驗收了一遍
18:58.566–19:02.033
zh最開始呢，這個網站只有 171 個項目
最開始呢，這個網站只有 171 個項目
19:02.033–19:04.900
zh而現在，它已經變成了 200 個項目
而現在，它已經變成了 200 個項目
19:05.033–19:05.833
zh剛開始
剛開始
19:05.833–19:09.566
zh我只是覺得這台舊電腦跑 Omarchy 很有意思
我只是覺得這台舊電腦跑 Omarchy 很有意思
19:09.566–19:12.300
zh但現在，它真的進入了我的工作流
但現在，它真的進入了我的工作流
19:12.533–19:13.733
zh我前面的視頻里
我前面的視頻里
19:13.733–19:16.600
zh我已經試過 ThinkPad X230i
我已經試過 ThinkPad X230i
19:16.666–19:19.766
zh也試過呢用 Dell 台式機跑 Omarchy
也試過呢用 Dell 台式機跑 Omarchy
19:19.800–19:20.800
zh而現在呢
而現在呢
19:20.800–19:23.300
zh蘋果電腦也能跑 Omarchy 了！
蘋果電腦也能跑 Omarchy 了！
19:23.333–19:25.933
zh其實這些硬件門檻都不高
其實這些硬件門檻都不高
19:25.933–19:27.966
zh你完全可以自己去試一試
你完全可以自己去試一試
19:28.066–19:28.866
zh那麼所以
那麼所以
19:28.866–19:31.433
zh我們未來真正需要重新設計的
我們未來真正需要重新設計的
19:31.433–19:32.533
zh到底是“應用”，
到底是“應用”，
19:32.533–19:35.066
zh還是整台電腦的工作方式呢？
還是整台電腦的工作方式呢？
19:35.600–19:37.233
zh那今天就聊到這裡啦
那今天就聊到這裡啦
19:37.233–19:39.366
zh那如果你喜歡這支影片的話
那如果你喜歡這支影片的話
19:39.366–19:42.133
zh就記得幫我訂閱按贊分享
就記得幫我訂閱按贊分享
19:42.133–19:44.800
zh我們就下一支影片再見囉，拜拜
我們就下一支影片再見囉，拜拜

影片筆記：M1 Mac mini 安装 Omarchy：Jev 真实工作流实测

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 全文快速校讀發現待確認修正

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

  • 待修正：⚠️ 全文快速校讀：已套用暫定修正，請確認（segment=12 已先套用暫定修正：而是呢做出這個網站的這台 MacOmarchy 電腦 → 而是呢做出這個網站的這台 Mac 上的 Omarchy；segment=22 已先套用暫定修正：我剛剛才把平時用的 Mac Studio 升級到 macOS 27 → 我剛剛才把平時用的 Mac Studio 升級到 macOS 15）
  • 待修正：逐字稿可先使用，但有待校正清單（segment=42 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=182 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

影片記錄了作者在一台閒置的 M1 Mac mini 上安裝 Omarchy 系統，並透過 AI Coding Agent Codex 與 Hostinger Connector (MCP)，將本地開發的 Jev Atlas 網站自動化部署至互聯網，實現從代碼編寫、故障修復到線上驗證的完整閉環，以此探討「AI 原生電腦」的實際工作流價值。

核心重點

  1. AI 原生電腦的定義：並非硬體性能的提升，而是人與電腦互動方式的改變。從「人搬運信息」轉變為「AI 延伸工作至互聯網服務」，讓舊硬體也能透過 AI Agent 獲得第二次生命。
  2. 自動化部署閉環：利用 Hostinger Connector (MCP) 將雲端服務能力賦予本地 AI Agent。流程涵蓋本地編碼、本地測試、自動部署、線上驗證，以及出錯時自動讀取日誌修復並重新部署，全程無需人工介入雲服務器後台。
  3. 效能優化策略：針對項目維護，引入 Jev 作為過濾層處理確定性重複工作，僅將複雜例外情況交給 Codex 深度檢查，顯著降低 AI 處理時間與成本。
  4. 硬體普及性：Omarchy 系統不僅限於 Mac，也可運行於 ThinkPad、Dell 台式機等硬體上，顯示該工作流對硬體門檻要求不高。

詳細大綱

一、 實驗背景與初衷

  • 硬體準備：使用閒置的 M1 Mac mini，安裝 Omarchy 系統。
  • 核心疑問：舊電腦運行新系統是否能提高效率？這台電腦是否僅是多了一個聊天窗口，還是能成為真正的「AI 原生電腦」？
  • 贊助合作：由 Hostinger 贊助，測試 AI Agent 能否不經手動操作服務器後台，直接將本地工作部署至互聯網。

二、 初步體驗：從設置到項目構建

  • 基礎設置測試：
  • 透過終端輸入 Codex，指令其連接藍牙鼠標（Magic Mouse）。
  • 調整指針速度與滾動方向，體驗 AI 直接與系統打交道，而非模擬點擊圖標的差異。
  • 項目定義：Jev Atlas：
  • 目標：整理散落在 X、GitHub 等地的 Jev 項目，製作可搜索、可分類、可長期維護的網站。
  • 視覺要求：首頁需呈現類似 Obsidian 的關係圖，且圖中節點與連線必須對應真實數據關係，非預先畫死的背景。
  • 執行者：作者決定方向與品味，Codex 負責編寫代碼、整理數據、運行網站及本地測試。

三、 部署與運維：本地到互聯網的閉環

  • 部署工具：使用 Hostinger Connector (MCP)，透過瀏覽器 OAuth 授權，將 Hostinger 的能力接給 AI Coding Agent。
  • 自動化流程：
  1. 本地開發：Codex 在 M1 上寫代碼、整理數據、運行網站。
  2. 本地驗證：Codex 自行打開瀏覽器檢查結果。
  3. 自動部署：透過 Hostinger Connector (MCP) 將網站部署至互聯網。
  4. 線上驗證：Codex 打開公開網址進行最終檢查。
  • 故障排除實例：
  • 初次部署出現 503 錯誤。
  • 作者未手動查日誌，Codex 透過 Hostinger Connector (MCP) 讀取 Runtime Logs，定位到 app.js 錯誤。
  • Codex 在本地修復、重新測試，確認無誤後再次部署，並最終在公開網站驗證成功。
  • 體驗總結：無需離開 Agent 工作環境即可處理部署與運維，無需手動操作雲服務商後台。

四、 維護流程優化：引入 Jev

  • 問題：Jev 生態持續增長，網站需長期維護。
  • 解決方案：將 Jev 納入維護流程，作為過濾層。
  • 普通代碼：處理確定性的重複工作。
  • Jev：判斷新項目與現有項目間的關係（處理「看起來很像」的對象）。
  • Codex：僅處理更模糊、複雜的例外情況。
  • 效能數據：
  • 加入流程前：Codex 需深度閱讀 13 個項目，耗時約 36.9 秒。
  • 加入流程後：Codex 僅需檢查 1 個項目，耗時降至 10.2 秒。
  • 後續測試：28 個候選身份中，僅剩 3 個需 Codex 深度檢查。
  • 最終成果：項目數從 171 個增至 200 個，實現自動化維護與部署的完整閉環。

五、 結論與展望

  • AI 原生電腦的定義：並非硬體變快，而是人與電腦相處方式的改變——從「人搬運信息」轉變為「AI 延伸工作至互聯網服務」。
  • 硬體普及性：Omarchy 可在 ThinkPad、Dell 台式機及 Mac 上運行，硬體門檻不高。
  • 核心提問：未來需要重新設計的究竟是「應用」，還是整台電腦的工作方式？

工具 / 模型 / 名詞整理

  • 系統/環境：
  • Omarchy（影片中被稱為 MacOmarchy 的系統）
  • macOS 15
  • M1 Mac mini
  • Mac Studio
  • Linux
  • localhost
  • AI 模型/Agent：
  • Codex（AI Coding Agent）
  • Jev（開放後的開發者實驗與項目生態）
  • Grok（用於增量調查）
  • ChatGPT
  • 平台/服務：
  • Hostinger（雲服務商）
  • Hostinger Connector (MCP)（MCP 工具/連接器）
  • hPanel（Hostinger 管理面板）
  • Web App Hosting（Hostinger 套餐）
  • X（前 Twitter）
  • GitHub
  • Obsidian（用於比喻關係圖風格）
  • 技術/概念：
  • MCP（Model Context Protocol，模型上下文協議）
  • OAuth
  • SSL, CDN, WAF, DDoS 防護
  • Node.js
  • Build Logs, Runtime Logs
  • 503 錯誤
  • AI-native computer（AI 原生電腦）

操作流程整理

  1. 環境初始化：在 M1 Mac mini 上安裝 Omarchy 系統。
  2. AI 連接測試：透過終端啟動 Codex，連接藍牙設備並調整系統設置（指針速度、滾動方向）。
  3. 項目開發：
  • 定義 Jev Atlas 網站目標與視覺風格（類似 Obsidian 關係圖）。
  • Codex 編寫代碼、整理數據、運行本地網站。
  1. 本地驗證：Codex 打開本地瀏覽器檢查網站運行狀況。
  2. 自動部署：
  • 透過 Hostinger Connector (MCP) 進行 OAuth 授權。
  • Codex 將本地網站部署至 Hostinger 服務器。
  1. 線上驗證與修復：
  • Codex 打開公開網址檢查。
  • 若出現錯誤（如 503），Codex 透過 MCP 讀取 Runtime Logs。
  • 定位錯誤文件（如 app.js），在本地修復並重新測試。
  • 確認無誤後再次部署，直至線上驗證成功。
  1. 長期維護優化：
  • 引入 Jev 作為過濾層，處理確定性重複工作。
  • Codex 僅處理複雜例外情況，減少深度閱讀項目數量與時間。

值得注意的限制或風險

  • AI 依賴性：整個流程高度依賴 AI Agent（Codex）的穩定性與能力，若 AI 出現誤判或無法正確讀取日誌，可能導致部署失敗或修復延遲。
  • 數據準確性：首頁的關係圖節點與連線必須對應真實數據關係，若 AI 整理的數據有誤，視覺呈現將產生誤導。
  • 硬體兼容性：雖然 Omarchy 宣稱可在多種硬體上運行，但實際體驗可能因硬體規格（如 M1 Mac mini 的閒置狀態）而有所不同。
  • 安全性：透過 OAuth 授權 AI Agent 訪問 Hostinger 服務器，需確保授權範圍與權限管理適當，避免未經授權的操作。

逐字稿辨識疑點

  • 警告：根據可讀性檢核，以下片段存在斷句或語義問題，請謹慎解讀：
  • segment 42: unnatural_sentence_boundary — 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
  • segment 182: unnatural_sentence_boundary — 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
  • segment 269: unnatural_sentence_boundary — 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
  • segment 417: unnatural_sentence_boundary — 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
  • segment 22: rapid_semantic_review — 全文速讀上下文判斷；尚未回聽或交叉比對
  • segment 12: rapid_semantic_review — 影片標題為「M1 Mac mini 安装 Omarchy」，且第26段明確區分「舊 M1 上跑起來的 MacOmarchy」，疑為口語連讀。
  • 名詞與技術疑點：
  • Jev：逐字稿中多次出現「Jev」，指代一種開放的技術或生態系統，具體技術原理作者表示「暫時不用管」，但提及它涉及 Coding Agent、瀏覽器操作、模型路由等。此名稱可能為聽寫錯誤或特定小眾技術名稱，需查證。
  • MacOmarchy：作者將運行 Omarchy 的 Mac 電腦稱為「MacOmarchy」，此為影片中的特定稱呼，非官方產品名稱。
  • Omarchy：系統名稱，逐字稿中未詳細說明其具體技術架構，僅提及為一種讓舊電腦獲得「第二次生命」的系統。
  • Hostinger Connector (MCP)：具體工具名稱，指 Hostinger 提供的 MCP 連接器。
  • app js：日誌中提到的錯誤文件，標準寫法可能為 app.js，但逐字稿顯示為空格分隔，標記為疑點。
  • 171 個項目 / 200 個項目：影片開頭提及網站收集了上百個項目，後文具體數字為 171 個，結尾增至 200 個。數字變化符合敘事邏輯，但「上百個」與「171」的對應關係需留意。
  • 36.9 秒 / 10.2 秒：效能測試數據，標記為影片中的具體測量值，非嚴格 benchmark。

可延伸追問

  1. Omarchy 的技術架構：Omarchy 系統具體基於什麼技術棧？它如何實現讓舊硬體運行現代 AI 工作流？
  2. Jev 的具體定義：Jev 作為過濾層，其具體算法或邏輯是什麼？它如何判斷項目間的關係？
  3. MCP 的擴展性：Hostinger Connector (MCP) 是否支援其他雲服務商？AI Agent 能否跨平台進行部署與運維？
  4. 安全性與權限：在自動化部署過程中，如何確保 AI Agent 的權限最小化，避免對生產環境造成意外破壞？
  5. 未來應用場景：除了網站部署，這種 AI 原生電腦的工作流還可應用於哪些其他領域（如數據分析、自動化測試等）？

尚未產生學習筆記

請在 Telegram 指令最後加上「學習」，例如：videonote 網址 英文 雙語 學習