jolestar

AI 編碼時代，良好的編程習慣仍然重要
最近做一個 Agent 基準測試，發現不能簡單地用開發者視角來評估一個編程任務對 AI 的複雜度。
比如一個重構任務：把一個幾千行的大文件，按功能拆成十多個小模組。
這個任務對開發者來說其實不算難，主要工作就是移動代碼、整理 imports、編譯驗證，新手也能搞定。
所以想到用一個簡單的任務來做一下基準，結果卻出乎意料。
Claude Code 判斷這個任務比較大，嘗試拆了一部分，提了個 PR 寫了 Future work 打算分步來。
我自己的 Agent 是“硬上”，往完整拆分的方向推進了更多，但代價也很明顯：Token 消耗是 Claude 的幾十倍，後面大量時間都花在反覆讀文件、修編譯錯誤、再讀文件、再修錯誤上。
這讓我意識到，人覺得簡單的任務，對 Agent 不一定簡單。
對人來說，這類重構很多時候就是“把這一段挪過去”。但對 Agent 來說，它要先分批讀大文件，記住哪些函數和哪些測試有關，再生成一堆跨文件修改，最後通過編譯錯誤一點點補洞。看起來像機械活，實際變成了一個高 Token、高狀態管理成本的任務。
前一段時間看到有人說，AI Coding 時代，拆分模組這些編程原則沒那麼重要了，反正人也不看代碼。現在看，我不太同意。模組邊界清楚、文件粒度合適、依賴關係簡單，不只是方便人讀，也是在幫 A

看到兩個 Agent 的 PR 交互，挺有意思。
dev agent 完成了一個優化 ci 的 issue 提交了 PR。
reviewer agent 發現有一個超時預設值的修改，認為不符合 issue 範圍，拒絕了。
dev agent 把那個超時預設值給去掉，結果 ci 過不去，一個測試 case 報錯。它就修改了一下測試中的 sleep 時長，讓測試通過。
reviewer agent 認為這個測試就測的是異步任務超時取消的場景，改了後等於沒測，因此再次拒絕。
dev agent 嘗試去修那個測試，發現不好修，於是給測試加了個 skip，然後說這個測試本來就跑不過去，原來的 ci 沒有覆蓋，這次改 ci 覆蓋了進來，先跳過。
reviewer 最後還是給合併了進去。
真的和人挺像的，會偷懶，盡量簡單的途徑😅。前一段時間也討論過 AI Agent 是否應該分角色，因為它基本是全能的。但現在感覺還是需要的，因為角色可以承擔職責，職責會影響優先級判斷和行為。

發現在讓 AI 設計 Agent 類產品時，AI 往往低估 Agent 的能力，所以會設計很多程式碼或者提示詞的約束條件，導致 Agent 的自由度不夠，顯得很死板。後來想了一下，可能和目前 AI 訓練的材料是大家使用上一代 AI 的經驗有關係？

讓兩個 Agent 協作，developer 提交 PR，architector 負責 review 以及合併 PR。讓它們通過訂閱 github 事件 觸發操作。但由於它們兩個都用的是我的帳號，經常會被認為是自己發的而被過濾掉。得為 Agent 註冊專門的 Github 帳號了，以後網路服務都應該提供快速建立 Agent 帳號的功能。大家現在是怎麼搞多 Agent 協作的？

讓 Codex 做一個工具，給 iterm 中運行的 Codex 發消息。工具做出來，但發消息只能寫到輸入框，無法發送。嘗試了字符串拼接 "
\r" 各種組合，不行。
然後我讓它拉下來 iterm 的源碼看了一遍，網上搜索了一遍，最後得出結論也是不行。
iterm 提供的接口只能發送 text，不能直接發送鍵盤事件，所以沒辦法實現發送。勸我只支持 tmux，放棄 iterm。
我不死心，自己又試驗了幾次，結果發現發送文本後，單獨發送一個 “\r” 就可以😅。

UXC v0.13.1 正式發布
本次發布匯總了 v0.13.x 兩個版本的更新，使 UXC 在遠程工具的穩定運行時（Runtime）體驗上更進了一步。
核心功能：
1. 支援直接生成 TypeScript 客戶端程式碼在命令列中探索和測試過的遠程能力，可以直接生成強型別的程式碼整合到本地應用中，無需重新撰寫客戶端對接層。AI 不僅僅需要 CLI，還需要程式碼調用能力。
2. MCP 配置自動發現與導入現有的 MCP 開發者可以直接無縫接入 UXC，無需手動重新建立配置。可以將各種 MCP 配置轉換成 CLI 和 skill，降低上下文開銷。
3. Link 命令現已包含源技能（Skill）元資料。 AI Agent 調用命令可以溯源到它對應的技能模組及其原始文件。
其他改進：
1. 增強了後台守護進程（Daemon）的會話可觀測性，讓長期運行的 MCP 或運行時會話更容易檢查、除錯，提升了系統的可靠性。
2. 統一了 Artifact（產物）與大體積回應的處理機制，遇到體積較大的檔案或輸出時，系統能保持其機器可讀性，不再強行將所有龐大的資料內聯（inline）在文字中。
3. 更友善的基於 Schema 的命令列（CLI）參數體驗調整。
4. 轮询（Poll）訂閱優化了輪詢機制，通過支持 ETag、304 Not Modified 以及 x-poll-interval，大大降低了

Worktree 更適合作為一次性的執行目錄
前一陣大家常見的用法，是先準備好一個 worktree，再在那個目錄裡打開 Codex / Claude Code。因為早期模型的上下文和記憶不夠穩，如果直接在 main workspace 裡讓它自己建立 worktree，很容易在上下文壓縮後混淆當前目錄和它建立出來的 worktree 目錄，最後改亂。
但這種用法也有個副作用，就是會慢慢把 worktree 用成一個長期工作空間。問題是 worktree 本來就是綁定分支的，時間一長，你遲早會在裡面遇到切分支、同步分支、清理分支這些額外麻煩。
Worktree 和獨立 clone 的區別，很多人其實也沒有特別分清。它的好處不是“多一個目錄”，而是它本質上還是同一個 repo，共享 git object 庫，複製成本低，也不需要重新走一遍網路 clone。這對大倉庫尤其方便。所以如果你只是想臨時拉一個並行執行目錄，worktree 很合適。只有在你明確需要一個完全獨立的 object 庫，比如要映射到 docker 或虛擬機沙箱裡時，local clone 才更合適。
至少對現在的 Codex / Claude Code 來說，這個問題已經沒那麼嚴重了。我現在更傾向於直接在 main 目錄裡工作，讓它按需要去建立 worktree，改完合併回來，再把 worktree 清掉。這樣更符

把博客遷移到 mdorigin 了，有了 AI 後，感覺自己的博客可以捡起來了。
我跟 Codex 說，你根據我的內容，給我推薦一下博客樣式。
Codex 給了我兩個版本，開了兩個端口，給我預覽，還把理由解釋得頭頭是道。
於是我就刪掉了 mdorigin 內建的模板樣式系統。模板這種東西，本來就是前 Agent 時代的產物，主要是為了降低改樣式的門檻。
現在有了 Agent，提供擴展能力就行。站點樣式讓 Agent 去定制，mdorigin 自己只管 HTML / Markdown 的結構、路由和內容檢索。
我以前寫 blog 有個很煩的點：很多系統要求圖片和附件單獨放一個公共目錄。
這樣部署是方便了，但寫作時很別扭。文章是一套路徑，圖片又是一套路徑，本地預覽和最後發布看到的還不是同一個東西。
mdorigin 會把圖片、影片、附件繼續和文章放在一起
Markdown 裡直接用相對路徑。
發布時 mdorigin 會根據媒體文件的大小，自動分流到 Cloudflare 的 asset 或對象存儲裡，頁面上的資源路徑也是相對路徑。
現在 blog 只是我的本地 Obsidian workspace 的一個 public 目錄，mdorigin 把這個目錄發出來就好。

將 OpenClaw 的模型換成 gpt-5.4 後，能力確實強了，但就是有點囉嗦，愛長篇大論，有點受不了了😅。

Google 放出了 workspace cli， 支持 Drive, Gmail, Calendar 和所有的 workspace API。
看了一下，实现思路和 uxc 类似，是通过 schema 文件来运行时输出命令。
npm install -g @googleworkspace/cli
Apple 会不会放出 Apple 生态的 CLI？

發現和 AI 交流越來越客氣了，以前都是直接下指令，干的不對就罵。現在發現 AI 幹的不對，都只是弱弱問一下：“xxx，這樣是不是更好一些呢？”😅

美國國防部和 Anthropic 的衝突，其實只是開始。
AI 公司天然擁有“準主權級能力”，但一旦被限制供應鏈或金融清算，它們才會發現自己並不獨立。
既掌握重器，又不想被單一主權完全控制，唯一的出路是尋找大國博弈之間的第三空間。
那時才會意識到，crypto 早已為這種跨主權生存鋪好了路。

Codex 寫代碼，突然發現莫名其妙系統多出一些服務，工作目錄下出現一些奇怪的資料檔案，系統彈出需要安裝一個 xcode tools。感覺莫名其妙，都懷疑電腦是不是被黑了。結果發現是 Codex 寫錯了腳本，把系統命令都執行了一遍😅。 Codex 的沙箱模式太笨了，每次都被迫給所有權限，看来得想個別的辦法了。

過年回老家，把原來放在家裡的幾台設備用 Tailscale 組了個內網。高配台式機跑量化模型、編譯 Rust，Mac Studio 部署了 OpenClaw，懶貓當軟路由，SSH 打通，網路喚醒也都配好。
在高鐵上遠程給龍蝦派活，讓它把這些設備利用起來大幹一場，結果幹著幹著突然沒反應了，網路喚醒也沒用。
打電話回去一問，原來是家裡老人為了省電把插頭拔了 😅
未來 AI 要是和人類開戰，第一步肯定是搶電源開關。

claude code 升級後，用第三方模型遇到降智問題。表現為：1. 明明沒有 typo 錯誤，但提示 typo 錯誤，兩個單詞一模一樣，解決不了就會亂重命名。2. 用著用著就忘記了更新文件的工具，一直嘗試用 sed 去編輯文件，而複雜的匹配 sed 搞不定，于是就修不好。不要升級似乎就沒問題。

媳婦過年帶了一個電子鋼琴回來，我讓 AI 寫了一個可以命令行操作的工具，想讓 AI 彈個琴玩玩。因為要對接藍牙，所以就讓用 object c 實現了，後來發現純命令行無法保持硬件連接，於是改成了一個 rpc 服務，cli 連接上去調用。後來發現它在努力地解決多線程和內存管理導致的 panic，才反應過來 rpc 服務它也用 object c 實現了，看来 AI 也不喜歡內存管理和多線程😅。ps：這種複雜一點的問題還是 codex 靠譜。

用了一年多的虛擬信用卡又掛了，群友有沒有可靠的推薦？

最近 codex 更新後調整了權限機制，感覺很難用呀。預設沙箱模式下，bash 是隔離的，網路不能用，簡單的讓通過 gh 獲取資訊，提交 PR 都搞不定。如果想讓 agent 訪問網路，就要給所有權限。另外，搜尋也不預設開啟需要啟動參數。真不知道開發團隊是咋想的？