不知道是不是天生基因的問題，warp第一天使用就是擅長軟件安裝與故障排除，真到了coding還是各種不適配 比如，它的會話機制其實是幾乎感覺不到的，或者說不清晰，其他編程工具無論是chat還是終端，都有一個明確的會話過程，warp因為要照顧到命令行的兼容，這個過程含糊了，雖然有一個reset按鈕也是存在感很低 Coding測試過幾次，之前其實有一個需求就是配合cc做o3 review,不過對比了一下使用chatgpt滿血版本o3還是差不少 Warp家最近各種送，也是槽點，cursor收購送一波，什麼newsletter送一年，這是降智的信號，沒聽說過量大質量還好的，迴歸常識吧

Warp 與claude code什麼區別？ 一個是終端，一個是終端裡運行的命令 導致的區別就是warp重cc輕，輕的可以輕易實現類似cc sdk這樣的可組合性 舉一個例子，cc就像一個揹包客，搭乘什麼交通工具都行，warp就像開著房車旅行 開車不挺好嗎？ 有限制，比如途中不能喝酒

Kiro的基於spec驅動的開發流程，我感覺並不適合使用claude code的slash commands. 因為這個意味著你綁定了claude模型，而claude模型擅長coding可未必擅長文本工作，這方面還得是o3-pro. 並且---設計工作怎麼能夠讓ai按照模板幾乎一分鐘內就生成呢，我打心底裡不放心，最起碼電力都沒怎麼消耗的設計感覺不太嚴肅😎ི 嚴肅的方法來了，用chatgpt deep research,選擇 o3-pro. 我測試了一下，比我用opus 4詳細很多 另外，其實prompt有時候太具體反而是限制，這是後話，有空接著聊，簡單說，我在prompt裡主要是給它幾個kio相關的鏈接

claude code 的sub agent 還是要小心使用， 我剛纔測試了發現一個問題， 即這個增加了子agent和父agent之間的溝通難度，以前都是一個人自己和自己溝通， 沒有信息損失， 現在存在的問題是： 它說執行完了， 我不知道到底有沒有完，犯了大企業綜合徵。 要保證質量，還的上一套監管機制。 還有一個情況， sub agent如果你通過esc打斷也是一個潛在的問題。

claude code 輕鬆突破1百萬窗口.

Claude code 子代理目前在編程領域用處還不是很明顯，但還是帶來了兩個使用場景的優勢: 1.在cc上做dr,這個可以發揮立即可見的並行優勢 2.對於coding, 子代理如果是獨立上下文，一個意外的好處是擴展了上下文，你甚至可以用相同的角色複製多份，然後讓他們接力也是可行的.

接著claude code最近的降智問題聊一下，我的反饋是，你得有手段哪怕cc不行了你也能保證軟件開發質量 如何做到？ 我們先不說如何做到，先說vibe的常見缺陷，是開盲盒的問題，每次都是黑箱操作，鬼打牆了一圈才發現不對勁，情緒瞬間不爽 說到這裡解決方案也基本明確了 將黑箱過程變成透明化過程，不是立即coding,而是將更多時間花在plan和解決方案上 1. 解決方案如果味道不對勁，基本coding質量不會好到哪裡去 2.在解決方案階段有很多手段，多模型review就是一個利器，不要相信cc一家之言，相信同行評審 3 代碼寫完了，編譯通過和功能滿足的基礎上，再加一次評審 這些手段大家可以擴展開去，cc降智怕什麼，我還有warp和cline. 另一個比較玄學的問題是，什麼時候容易降智，直覺可能是算力不足的時候，感覺+8區的工作時間有可能概率比較大，那換換時區測試一下

這就搞笑了，用了ai寫代碼，還要請另一個ai檢測錯誤

Claude code可能將5小時刷新的方式換成每週重置 這個方式對每天高強度使用的來說應該不太友好---但對普通開發者更友好，意味著你不用擔心夜裏時間浪費了，前兩天閒置，第三天可以集中用一週的額度

這個出發點是好的，但是結果走歪了 1. o3 做規劃設計確實是共識 2. Repoprompt本來是一個repo summary工具，現在升級為mcp,並且內置o3模型，規劃就是基於這個做的 3. 問題出在執行階段，居然不是cc做執行，而是cc調用repo 的mcp工具做合併 4. 鬧了半天cc是個傀儡，這工具逗我呢，你這麼自信？