AI / 技術

模型夠聰明，Loop 才真的轉得起來

模型能力不足時，流程看起來有 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 / 技術

跟一群AI一起工作，是怎樣的一個體驗

三個禮拜，我幫自己找了一群 AI 同事。薪水不高，脾氣不錯，不適用勞基法，但會吐槽我。

Hermes 當 TPM 負責開票，Codex 當工程師負責寫 code，Grok 當那個 review時話很多的吃瓜群眾。我？我就負責在它們吵起來的時候出來說「你們都給我冷靜」。

整件事最可怕的發現是：AI 寫的 code 測試全過、lint 全綠——然後功能全錯。

  / / / / /
AI / 寫寫Code / 技術

LLM Wiki on Cloud：把你的過去知識，餵進 LLM 的對話裡帶著走

Andrej Karpathy 前陣子提了一個概念：LLM Wiki——把 wiki 的結構化知識和 LLM 的語言能力結合，讓 AI 不只是生出看似合理的文字，而是基於你真正寫過的、整理過的、沉澱過的知識來回答問題。

老實講，這概念一看就覺得「對啊，為什麼沒有人這樣做？」於是我自己刻了一個。

  / / /
AI / 寫寫Code / 技術

LLM Wiki Cloud MVP status

一個基於 Karpathy LLM Wiki 哲學的雲端知識庫服務。把素材丟進去，AI 自動讀懂、重組成結構化 wiki，然後你可以用自然語言查詢整個知識庫——每個答案都有 citation，點擊就能追回原始文章。跟 RAG 最大的差別：不是查詢時才匆匆翻幾頁，而是入庫當下就讓 LLM 把知識整理好。

  / / / / /