作者 erspicu (.)標題 [討論] 第一次用Claude Code就撞牆時間 Sun Feb 15 02:35:26 2026
最近開始在摸索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 (臺灣)
※ 作者: erspicu 2026-02-15 02:35:26
※ 文章代碼(AID): #1faC1r96 (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1771094133.A.246.html
推 Litfal: WASM還是稍冷門，冷門的東西幻覺很多1F 02/15 03:22
推 jhjhs33504: 也許是慢的那個做法反而thread safe
.net可能還未支援比較泛用的實作方法
最終目的還是要讓瀏覽器正常解析2F 02/15 04:17
推 gofigure: LLM的先天限制 無法跳脫思考 因為跳脫思考往往低機率
我覺得工程師以後就專注在寫spec 讓AI寫代碼
99%的代碼AI都可以寫 剩下的人類再補完6F 02/15 10:21
→ Obama19: .NET的問題 基本就是個垃圾9F 02/15 10:35
→ ma721: 不會用就先用Cursor 最易用的10F 02/15 10:49
推 chita0258: 剛入門一定撞牆 需要持續更新CLAUDE檔, rules等檔案12F 02/15 13:04
推 stepnight: vibe最常見就是問題不知道在哪
陪著AI撞牆到token沒有也一事無成
Claude 的Code品質已經是最好的了
但使用者的提示詞也非常非常重要
懂Code的人能精準列出AI該怎麼做、做什麼
剩的由AI完成再小修修即可
Antigravity+Claude 模型我覺得最讚惹
Gemini 還是算了13F 02/15 13:34
→ TonyQ: 你這不是撞牆 純粹就是 沒 token XD21F 02/15 13:34
→ stepnight: 另外Claude token是真的貴，但也值得22F 02/15 13:35
→ TonyQ: AI 沒有厲害到每一次都可以幫你一次搞定
但你根本還沒試到一次 XD 再累積點時間會比較知道別人在說什麼 XD23F 02/15 13:35
推 labbat: 有時候做不出來就會燒金紙(X 燒token希望跑出個能動的26F 02/15 14:29
--