LLM 之間會長出人類看不懂的語言：語言壓縮現象的工程含意
在封閉環境與共享目標下，模型的溝通會偏離自然語言，走向高壓縮的協定式表達。這對多代理系統設計與 AI 安全是重要訊號。
LLM
別把 Claude 當聊天：你其實在管理 context window
長時間對話把 context window 塞滿，模型就會分心、漏指示、錯誤變多。把任務拆分、用 /compact 與 /clear 管理工作記憶，才是穩定輸出的關鍵。
Karpathy 的 LLM Agent 寫程式體感：改變的不是速度，是工作的邊界
Karpathy 的 LLM Agent 寫程式體感：改變的不是速度，是工作的邊界
很多人把 AI 在軟體開發裡的價值，理解成「寫程式更快」。
但真正用上一段時間之後，你會發現它動到的不是加速，而是整個工作方式：你不再把時間花在逐行產出，而是花在定義、檢查、修正與決策。
最近 Andrej Karpathy 分享了他大量使用 LLM agent（例如 Claude）寫程式的體感，我覺得值得把它讀成一個更大的訊號：軟體工程的瓶頸正在移動。
出處（Andrej Karpathy 貼文）：https://x.com/karpathy/status/2015883857489522876
從「手寫」到「審稿」：工程師的手感正在改變
Karpathy 的描述很直白：在很短的時間內，他從「大多數程式都親手寫」
超長 Context 不是萬靈丹：MIT 提醒我們小心「Context Rot」
最近看到一個很典型的科技流量標題：
「別再迷信超長 context 了！救星竟然是 Python？」
標題很會抓眼球，但我更在意的是它背後那個更實際的訊息：你把更多文字塞進模型，不等於模型就更懂你要它做什麼。
## 「超長 context」的幻想：把整本書丟進去就能推理
很多產品在推長 context 時，大家腦中想像的使用情境往往是：
* 把一堆文件丟進去
* 然後要求模型做跨段落、跨頁碼、跨章節的推理
* 最後得到一個精準可追溯的答案
但這裡有一個被忽略的現實：Transformer 的注意力機制對「資訊量」很敏感，你越塞越多，模型越容易把關鍵線索當成噪音。
MIT 這類研究（或你在實務中做的長文件 QA）常會遇到一種現象：
* 單點查找還行
* 一旦需要跨段落組合、比對、推理，表現會明顯崩掉
社群把它稱為 Context Rot（上下文腐爛）：context 變長，理解能力沒有等比例提升，反而像在一堆紙堆裡找針。
## 真正該問的問題：你要的是「