模型能力不足時，流程看起來有 agent、有 ticket、有 tool call，也有 PR；實際運作起來，卻是：
Coding agent 提出問題
→ Orchestrator 知道需要人類決策
→ Relay 失敗或 timeout
→ Orchestrator 開始自作主張
→ 人類手動開 terminal、貼 ticket、搬答案、搬 PR link
最後，人類被迫成為整條 loop 的 breakpoint，還要 on-call 當文件小弟。
往高情商想，這讓人類很有參與感。往工程角度看，這是讓整個系統裡最昂貴、最容易被打斷的節點，負責最不需要思考的 copy-and-paste。堪稱業界創舉。
Grok 4.5 和 GPT‑5.6 Sol 帶給我的最大 Culture Shock，不是 benchmark 分數，而是 Orchestrator 第一次能穩定地…..
三個禮拜，我幫自己找了一群 AI 同事。薪水不高，脾氣不錯，不適用勞基法，但會吐槽我。
Hermes 當 TPM 負責開票，Codex 當工程師負責寫 code，Grok 當那個 review時話很多的吃瓜群眾。我？我就負責在它們吵起來的時候出來說「你們都給我冷靜」。
整件事最可怕的發現是：AI 寫的 code 測試全過、lint 全綠——然後功能全錯。
Andrej Karpathy 前陣子提了一個概念：LLM Wiki——把 wiki 的結構化知識和 LLM 的語言能力結合，讓 AI 不只是生出看似合理的文字，而是基於你真正寫過的、整理過的、沉澱過的知識來回答問題。
老實講，這概念一看就覺得「對啊，為什麼沒有人這樣做？」於是我自己刻了一個。
一個基於 Karpathy LLM Wiki 哲學的雲端知識庫服務。把素材丟進去，AI 自動讀懂、重組成結構化 wiki，然後你可以用自然語言查詢整個知識庫——每個答案都有 citation，點擊就能追回原始文章。跟 RAG 最大的差別：不是查詢時才匆匆翻幾頁，而是入庫當下就讓 LLM 把知識整理好。
從排斥 vibe coding 到把 AI Agent 當成個人基礎設施：Morning Brief 自動化、WP-CLI 遠端管理、Skill 體系、多 Agent 分工模式。與其當做個會對話的 AI，這更像是個人 AI 作業系統。
