作者 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
推 cancelpc: 試過簡單的程式，只能拿來交作業。隨便知道的安全漏洞，就能舉出4個
有些語言的語病，造出的bug,也修不好
提示太長，就會忘了之前的。類似腦容量問題，越接近50%，幻覺，亂掰就很嚴重
用於圖，影片可以人眼檢查那邊壞掉
但若是拿來開車，生產運作(動態環境)，出現AI沒想到的，就好笑了28F 02/15 16:28
→ guanting886: 冷門領域的產出來的東西大概會是像Pseudo code只能看不能用
不過大內的東西就是文件給希望 實作時讓你認清事實看看未來在Nested Learning LLM的遺忘問題會不會獲得明顯改善36F 02/15 17:51
→ DrTech: 跟我的經驗差不多，c#, xaml, cs常常錯誤，連最基礎都錯。AI相關程式碼，向量轉換幾乎都會錯。CV或影像處理，，即使沒錯，基本上演算法或向量處理都不是最佳做法。
vibe coding,或AI好不好用，真的很吃領域。真的不是說你的領域很好用，就可以套在所有人工作。
遊戲，矩陣處理，模擬，科學運算，許多工業領域基本上AI寫的程式碼全掛。41F 02/15 18:58
→ kaltu: 個人經驗，除了訓練樣本數之外，business logic 跟code只有間接關聯的領域AI全死，上面提到的整排都是，矩陣旋轉為什麼要這樣轉，跟你本來的矩陣長什麼樣子和後面要轉成什麼樣子有直接的關聯，但code內沒辦法直接看出來或資訊不足的AI只能瞎雞巴亂轉，再來跟你信心滿滿的說他看懂了沒轉錯，各種科學計算都是這樣
反而在webui這種套件發展到有種code層面就能「所見即所得」的感覺的這種特別強
結論就是但凡只要你會在白板上作推導然後再寫code的領域AI都吃屎，他的訓練資料只有code沒有那塊白板48F 02/15 21:57
推 tung3567752: 我敢說覺得ai 相關的code還覺得 claude 很難用，九成九是使用者的問題58F 02/15 22:41
推 umum29: 之前改wpf介面改的亂七八糟 但純html/js 表現超強60F 02/16 00:51
→ mucoci: 習慣就好，我作遊戲，功能類可以，但架構和有關視覺的難領域還是有差61F 02/16 00:57
推 jack529: 之前接過一個vibe 出來的專案，重構到快瘋，幾乎程式碼都是workaround出來達成某個目地，這種反而比人寫出來還難知道當初在幹嘛==相信為了這種slop會越來越多64F 02/16 08:01
→ dildoe: 資訊少的沒輒 連參數都會下錯 直接google能google到倒是方便不易出錯67F 02/16 08:53
--