[討論] 第一次用Claude Code就撞牆

看板Soft_Job (軟體人)作者erspicu (.)時間4小時前 (2026/02/15 02:35)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串1/1

最近開始在摸索vibe coding工具 gemini cli 我是google gemini的pro訂閱戶用google帳號登入方式認證好像條件會比免付戶好些據說是cp值最高的比啟用api key的方式使用起來我切到3的模型好像模型會動態換來換去隨著token用量主機負擔或是問題性質等等我不太清楚因素切換使用模組所以品質好像也是跳來跳去缺點是真的會寫出bug 還信誓旦旦說修好了結果還是壞掉但優點是目前多數它最後都能搞定有時候看不下去幫忙它debug一下通常要幫忙開瀏覽器debug模式抓一些訊息或是靠自己的經驗跟它說哪邊有問題給它提示它修得比較快但也遇過簡單的html css排版問題搞到爛掉修不好我對css之類沒那麼熟最後就給它上移動恢復簡單來說我覺得cp值高反正pro訂閱戶好像很難超額問題是好沒我覺得乾淨俐落甚至我自己還要幫忙它處理問題還有vibe coding 好不好用真的跟專案性質很有關係主要是訓練樣本之前處理winui 3專案常常跟wpf的xaml搞混像是一般web相關技術啥html css .net java php sql之類的技術海量訓練樣本效果就好很多我猜手機app的開發也是很不錯 Claude Code 今天開始用也是付費pro用戶結果token一下就用完了大概就是我想對以前的專案做效能優化測試 https://github.com/erspicu/LanczosWasmDemo 專案下載下來結果我自己環境跟以前有差不能編譯先請它了解專案幫我修正接著開始技術堆疊開aot simd 跟我說啥simd好棒棒然後我請它幫我加上simd優化一下結果慢到整個網頁當掉比原始版本還慢又請它修正原本它是把一個pixel (r,g,b,0) 封裝到 vector 一堆 pack unpack動作搞到根本不能用它修正後說應該是一次處理4顆pixel才對結果還是慢算了好像無解接著往Parallel.For 多核方式平行處理的方向優化反正搞了半天也是gg 就是.net 8不支援換成.net 9 支援了,但還是很多問題有一些ai回覆複製貼上一些分享一些過程給想往這些方向鑽的.NET人一些心理準備覺得無聊下面可以快速略過看最後重點其實原始的 Lanczos.cs 裡就有被註解掉的 Parallel.For： ● Searched for 1 pattern (ctrl+o to expand) ● 原作者已經試過，只是註解掉了。 WASM 的限制不過在 WASM 環境下，多執行緒有額外條件： 1. 需要 SharedArrayBuffer — 瀏覽器要求設定特定 HTTP headers： Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp 2. .NET 8 WASM threading 是實驗性功能 — 需要在 csproj 加： <WasmEnableThreads>true</WasmEnableThreads> 3. AOT + Threading + SIMD 三者同時啟用在 .NET 8 可能有相容性問題結論演算法本身是 embarrassingly parallel（完美平行），但要不要在這個專案啟用取決於你想處理 WASM threading 的額外複雜度。如果是跑在桌面 .NET 而非 WASM，直接把 Parallel.For 打開就能用了。有一點要注意：WASM threading 需要瀏覽器支援 SharedArrayBuffer，你的 Web Server 必須回傳這兩個 HTTP headers： Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp 如果沒有這些 headers，Parallel.For 會退化成單執行緒（和 Original 一樣的速度），不會報錯但也不會加速。 ● 這是 .NET 8 WASM threading 的已知問題 — 啟用 WasmEnableThreads 後， runtime 需要 worker JS 檔案，但非 Blazor 的專案架構沒有自動處理這個。最務實的做法：移除 WasmEnableThreads。Parallel.For 仍然可以編譯和執行，只是在 WASM 單執行緒環境下會退化成循序執行 — 這本身也是一個有意義的比較數據（可以看出 Parallel.For 的排程開銷）。 ● 最直接的路：升到 .NET 9，你已經有 SDK 9.0.310。.NET 9 對 WASM threading 的支援比 8 成熟很多，那個 jsModuleWorker 的問題在 9 已經修正。 ● 問題在第 67 行的 Greet 呼叫。啟用 threading 後，所有 [JSExport] 同步方法都不能從 JS 主執行緒呼叫 — await 沒用，因為錯誤在 binding 層就丟出了，根本還沒回傳 Promise。修法：C# 方法要回傳 Task<T> 讓它原生就是非同步的。 ● Read 1 file (ctrl+o to expand) ● 所有方法都要改成回傳 Task<T>，用 Task.Run 包起來： ● Task<byte[]> 不被 JSExport 的 marshaler 支援。這是 .NET 9 WASM 的限制 — Task<T> 只支援簡單型別（string, int, double 等），不支援 byte[]。這讓 threading + JSExport + byte[] 三者無法同時達成。最務實的做法是移除 WasmEnableThreads，Parallel.For 仍然能編譯和執行（在 WASM 單執行緒下退化成循序），這樣三種演算法的比較還是有意義的： - Original: 基準（double, scalar） - SIMD: SoA + Vector128 加速 - Parallel: 展示 Parallel.For 在 WASM 的排程開銷 ● 建置成功。總結一下現在的狀態：已還原的部分： - C# 方法全部改回同步 byte[] 回傳 - JS 呼叫改回同步（移除 async/await） - 移除 WasmEnableThreads 保留的升級： - .NET 9（兩個 csproj） - WasmEnableSIMD - COOP/COEP headers（Program.cs）為什麼 WASM threading 行不通： [JSExport] 的 source generator 不支援 Task<byte[]> 的 marshaling，而啟用 threading 後又禁止同步呼叫，形成死結。這是 .NET 9 WASM 的已知限制。 Parallel.For 在沒有 threading 的 WASM 環境下會退化成單執行緒循序執行，所以 Parallel 按鈕跑出來的時間會等於或略慢於 Original（因為有 Parallel.For 的排程開銷）。這本身也是一個有價值的比較結果。 ﴠ.net 10 有解決這問題嗎? ● Web Search(".NET 10 WASM threading JSExport Task byte array SYSLIB1072 2026") ﴠid 1 search in 25s ● Fetch(https://github.com/dotnet/runtime/issues/77157) ﴠ衅eceived 331.5KB (200 OK) ● 沒有解決。這是 .NET runtime 的已知限制，官方標記為 Not Planned（不打算修）。問題根源 https://github.com/dotnet/runtime/issues/77157：Task<byte[]>、 Task<ArraySegment<byte>> 等複雜型別在 [JSExport] 的 source-generated marshaller 中不被支援，官方關閉為 Not Planned。 .NET 10 的 WASM threading 現狀根據 https://github.com/dotnet/runtime/issues/68162 和 https://learn.microsoft.com/en-us/aspnet/core/client-side/dotnet-on-webworkers?view=aspnetcore-10.0 ： - [JSExport]/[JSImport] 的 interop 仍然限制在主執行緒 - WasmEnableThreads + WasmBuildNative 在 .NET 10 甚至還有 https://github.com/dotnet/runtime/issues/112926 - WASM 多執行緒仍標記為 experimental 如果真的想在 WASM 跑 Parallel 官方建議的 workaround 是分兩次呼叫 — 先取得 Promise，再另外 marshal 資料。但對我們這種回傳大 byte array 的場景不實用。結論：目前 .NET WASM 要同時做到 threading + JSExport + byte[] 是死路。現階段最有價值的比較還是 Original vs SIMD，這兩個在單執行緒 WASM 下都能正常跑，而且 SIMD 的 SoA + Vector128 才是真正能帶來加速的方向。 ========================================== 使用gpu加速呢? You've hit your limit · resets 5am (Asia/Taipei) 簡單來說一事無成 TOKEN直接被燒光光了.... 然後它覺得好棒棒的SIMD法比原始方式慢了將近10倍我不怪Claude Code 這種東西本來就跟訓練樣本有關我只是沒想到TOKEN燒這麼快.... 其實WASM加速的ISSUE跟GPU遇到的障礙有一部分很像主要是記憶體搬遷交換 PACK UNPACK的成本高然後WASM 的 SIMD Parallel WebGpu 加速技術好像還充滿很多不確定性 AOT目前 .NET 8後應該算成熟了具體快多少我是不太清楚至少編譯過沒問題跑沒問題然後SIMD優化問題真的只能自己設計想鑽研的可以參考 https://github.com/erspicu/LanczosWasmDemo 照這種燒token的速度我可能寧可退回gemini cli -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 182.233.248.16 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1771094133.A.246.html