博客
逃離cursor
Wednesday, April 15, 2026 在 博客
現在才說逃離cursor可能有點晚, 其實我在半年的時間裡已逐漸減少使用cursor, 因為我的編碼習慣已有所變化, cursor的長處已不再是我選擇它的理由. cursor迄今仍然穩居第一的特性, 是其獨有的補全模型, 支援前後左右跨行跨文件的補全, 無論響應速度還是接受率都沒有可匹敵的對手.但我已不再使用補全來手寫程式碼, 轉而購入各種編碼套餐, 大量使用agent來編碼.cursor的agent仍然很強, 可惜沒有和claudecode/codex拉開明顯差距, 而anthropic和 …
Anthropic廣為人知的優勢是常識, 即common sense.
Sunday, April 12, 2026 在 博客
Anthropic廣為人知的優勢是常識, 即common sense. 有些開發工作依賴常識, 有些依賴專有邏輯. opus的推理風格是猜測很多可能, 然後快速驗證.GPT5傾向按照程式碼實作進行推理, 反覆梳理業務.風格上類似廣度優先和深度優先的區別. 隨著程式碼庫體積增大, “常識"會觸及瓶頸, 因此opus的天花板比GPT5低.
智譜又退錢了!誒?我為什麼要說又
Saturday, April 11, 2026 在 博客
又能退錢了，給兄弟們讓出資源。40塊一個月固然便宜，但白天不讓用，晚上我又要睡覺，這不是 lite 套餐，這是 night 套餐啊！ 退款問卷，zhipu-ai.feishu.cn/share/base/form/shrcn8hoW11cnI0PRd7H5VEd9Kc
智譜的服務之差, 無出其右
Thursday, April 09, 2026 在 博客
這是我第三次上智譜的當, 說是挽留老用戶, 給無週限的額度, 就又回來試它一試, 結果又著了道. 它是沒週限, 但我需要的時候根本用不了, 我剛上班和剛下班時, 它就能活過來, 屬於是頂峰相見了.二月我說智譜lite單併發, 智譜拿企業經營證書向xhs舉報要封我的號, 說我誹謗.你家lite服務品質如何, 心裡沒點逼數, 還好意思舉報, 有這功夫不如做點正經事. 現在我再次被騙, lite在東八區整個下午都是0併發, 0可用性, 並非有人說的卡慢.卡慢意味著能用, 0可用性意味著完全不能用, …
Claude Code 的資源黑洞: 從 11.3MB 單檔打包到 1.2TB 磁碟吞噬
Tuesday, April 07, 2026 在 博客
Claude Code 的客戶端是一個沒有資源生命週期管理的 Node.js 單檔應用：啟動時解析 11.3MB 的打包檔案，執行時無限制地寫入磁碟，關閉終端後程序仍持續存活並持續消耗記憶體，直到系統崩潰。基於 GitHub Issues 中的真實使用者報告和社群逆向分析，本文系統梳理其在記憶體、CPU、磁碟三個維度上的資源管理缺陷，揭示打包架構、儲存設計和程序生命週期管理中的結構性問題。這些不是邊緣 case，而是從 2025 年 8 月到 2026 年 4 月持續被社群報告，卻被 stale …
贏家通吃的市場, 敗者都是苟活
Tuesday, April 07, 2026 在 博客
成本敘事不適合大模型行業，大家都在虧，甚至贏家都在虧，輸家覺得不能這樣下去，沒能力勸贏家漲價，決定先將自己的落後產品漲價，這是破罐子破摔，自掘墳墓。 國內開源模型廠商打響名號，在自己的模型有一定競爭力之後都會閉源，qwen3.6/minimax2.7/glm5.1turbo等都未開源，其它小廠在基模上隨便搞搞，蒸餾下贏家模型，這就想收錢，未免想的太容易。
VS Code Dev Container IO 過高: executeInWSL 配置詳解與根因分析
Friday, April 03, 2026 在 博客
在 Windows 上使用 VS Code 的 Dev Container 擴充套件進行容器化開發時，部分使用者會遇到系統明顯卡頓的現象。工作管理員中可以觀察到 Extension Host 程序的 CPU 和磁碟讀 IO 持續偏高，即便在沒有主動操作的情況下也不會回落。本文記錄了從問題現象出發，逐步定位根因並找到核心解決方案的完整排查過程。 問題現象 系統卡頓發生在使用 Dev Container 擴充套件連接到容器之後。透過工作管理員可以觀察到 Extension Host 程序的磁碟讀 …
vscode 增加官方新主題了
Thursday, March 26, 2026 在 博客
我用vscode十年，第一次見到主題更新。 相較原來的預設主題，色塊減少，黑的更黑，白的更白了。 #vscode[話題]#
這種感覺令人沉迷
Thursday, March 26, 2026 在 博客
GPT5系列發布半年來，其邏輯嚴謹程度領先，但最為人詬病的是其速度偏慢，尤其是GPT5.2，慢的令人髮指，很多普通的請求opus可能20秒上下文蒐集就開始上手修改了，而GPT5.2很可能要分析20分鐘才開始動手改。同期的GPT5.2codex模型速度稍快，但邏輯明顯降低。之後GPT5.3codex模型均衡了邏輯和速度，codex模型開始變得可用。GPT5.4程式碼能力融合進主模型，不再單獨發布codex模型，其速度明顯加強。據稱是單位token的有效率增加，因此可以思考的更少到達近似的正確率。 …