PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (.)時間2周前 (2026/02/15 02:35), 編輯推噓17(17推 0噓 56→)
留言73則, 23人參與, 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
推
02/15 03:22, 2周前 , 1F
WASM還是稍冷門，冷門的東西幻覺很多
02/15 03:22, 1F
推
02/15 04:17, 2周前 , 2F
也許是慢的那個做法反而thread safe
02/15 04:17, 2F
→
02/15 04:21, 2周前 , 3F
.net可能還未支援比較泛用的實作方法
02/15 04:21, 3F
推
02/15 04:37, 2周前 , 4F
最終目的還是要讓瀏覽器正常解析
02/15 04:37, 4F
推
02/15 07:31, 2周前 , 5F
推
02/15 07:31, 5F
推
02/15 10:21, 2周前 , 6F
LLM的先天限制 無法跳脫思考 因為跳脫思考往往低機率
02/15 10:21, 6F
推
02/15 10:24, 2周前 , 7F
我覺得工程師以後就專注在寫spec 讓AI寫代碼
02/15 10:24, 7F
→
02/15 10:24, 2周前 , 8F
99%的代碼AI都可以寫 剩下的人類再補完
02/15 10:24, 8F
→
02/15 10:35, 2周前 , 9F
.NET的問題 基本就是個垃圾
02/15 10:35, 9F
→
02/15 10:49, 2周前 , 10F
不會用就先用Cursor 最易用的
02/15 10:49, 10F
推
02/15 12:14, 2周前 , 11F
補充，現在cursor不能用ms的套件
02/15 12:14, 11F
推
02/15 13:04, 2周前 , 12F
剛入門一定撞牆 需要持續更新CLAUDE檔, rules等檔案
02/15 13:04, 12F
推
02/15 13:34, 2周前 , 13F
vibe最常見就是問題不知道在哪
02/15 13:34, 13F
→
02/15 13:34, 2周前 , 14F
陪著AI撞牆到token沒有也一事無成
02/15 13:34, 14F
→
02/15 13:34, 2周前 , 15F
Claude 的Code品質已經是最好的了
02/15 13:34, 15F
→
02/15 13:34, 2周前 , 16F
但使用者的提示詞也非常非常重要
02/15 13:34, 16F
→
02/15 13:34, 2周前 , 17F
懂Code的人能精準列出AI該怎麼做、做什麼
02/15 13:34, 17F
→
02/15 13:34, 2周前 , 18F
剩的由AI完成再小修修即可
02/15 13:34, 18F
→
02/15 13:34, 2周前 , 19F
Antigravity+Claude 模型我覺得最讚惹
02/15 13:34, 19F
→
02/15 13:34, 2周前 , 20F
Gemini 還是算了
02/15 13:34, 20F
→
02/15 13:34, 2周前 , 21F
你這不是撞牆 純粹就是 沒 token XD
02/15 13:34, 21F
→
02/15 13:35, 2周前 , 22F
另外Claude token是真的貴，但也值得
02/15 13:35, 22F
→
02/15 13:35, 2周前 , 23F
AI 沒有厲害到每一次都可以幫你一次搞定
02/15 13:35, 23F
→
02/15 13:35, 2周前 , 24F
但你根本還沒試到一次 XD 再累積點時間會比較知道別人在說
02/15 13:35, 24F
→
02/15 13:35, 2周前 , 25F
什麼 XD
02/15 13:35, 25F
推
02/15 14:29, 2周前 , 26F
有時候做不出來就會燒金紙(X 燒token希望跑出個能動的
02/15 14:29, 26F
推
02/15 15:30, 2周前 , 27F
推一樓
02/15 15:30, 27F
推
02/15 16:28, 2周前 , 28F
試過簡單的程式，只能拿來交作業。隨便知道的安全漏洞，
02/15 16:28, 28F
→
02/15 16:28, 2周前 , 29F
就能舉出4個
02/15 16:28, 29F
→
02/15 16:28, 2周前 , 30F
有些語言的語病，造出的bug,也修不好
02/15 16:28, 30F
→
02/15 16:30, 2周前 , 31F
提示太長，就會忘了之前的。類似腦容量問題，越接近50%
02/15 16:30, 31F
→
02/15 16:30, 2周前 , 32F
，幻覺，亂掰就很嚴重
02/15 16:30, 32F
→
02/15 16:31, 2周前 , 33F
用於圖，影片可以人眼檢查那邊壞掉
02/15 16:31, 33F
→
02/15 16:32, 2周前 , 34F
但若是拿來開車，生產運作(動態環境)，出現AI沒想到的，
02/15 16:32, 34F
→
02/15 16:33, 2周前 , 35F
就好笑了
02/15 16:33, 35F
→
02/15 17:51, 2周前 , 36F
冷門領域的產出來的東西大概會是像Pseudo code只能
02/15 17:51, 36F
→
02/15 17:51, 2周前 , 37F
看不能用
02/15 17:51, 37F
推
02/15 17:54, 2周前 , 38F
不過大內的東西就是文件給希望 實作時讓你認清事實
02/15 17:54, 38F
→
02/15 17:56, 2周前 , 39F
看看未來在Nested Learning LLM的遺忘問題會不會獲
02/15 17:56, 39F
→
02/15 17:56, 2周前 , 40F
得明顯改善
02/15 17:56, 40F
→
02/15 18:58, 2周前 , 41F
跟我的經驗差不多，c#, xaml, cs常常錯誤，連最基礎都錯。
02/15 18:58, 41F
→
02/15 18:58, 2周前 , 42F
AI相關程式碼，向量轉換幾乎都會錯。CV或影像處理，，即使
02/15 18:58, 42F
→
02/15 18:58, 2周前 , 43F
沒錯，基本上演算法或向量處理都不是最佳做法。
02/15 18:58, 43F
→
02/15 19:01, 2周前 , 44F
vibe coding,或AI好不好用，真的很吃領域。真的不是說你的
02/15 19:01, 44F
→
02/15 19:01, 2周前 , 45F
領域很好用，就可以套在所有人工作。
02/15 19:01, 45F
→
02/15 19:07, 2周前 , 46F
遊戲，矩陣處理，模擬，科學運算，許多工業領域基本上AI寫
02/15 19:07, 46F
→
02/15 19:07, 2周前 , 47F
的程式碼全掛。
02/15 19:07, 47F
→
02/15 21:57, 2周前 , 48F
個人經驗，除了訓練樣本數之外，business logic 跟code只有
02/15 21:57, 48F
→
02/15 21:57, 2周前 , 49F
間接關聯的領域AI全死，上面提到的整排都是，矩陣旋轉為什
02/15 21:57, 49F
→
02/15 21:57, 2周前 , 50F
麼要這樣轉，跟你本來的矩陣長什麼樣子和後面要轉成什麼樣
02/15 21:57, 50F
→
02/15 21:57, 2周前 , 51F
子有直接的關聯，但code內沒辦法直接看出來或資訊不足的AI
02/15 21:57, 51F
→
02/15 21:57, 2周前 , 52F
只能瞎雞巴亂轉，再來跟你信心滿滿的說他看懂了沒轉錯，各
02/15 21:57, 52F
→
02/15 21:57, 2周前 , 53F
種科學計算都是這樣
02/15 21:57, 53F
→
02/15 21:57, 2周前 , 54F
反而在webui這種套件發展到有種code層面就能「所見即所得」
02/15 21:57, 54F
→
02/15 21:57, 2周前 , 55F
的感覺的這種特別強
02/15 21:57, 55F
→
02/15 21:59, 2周前 , 56F
結論就是但凡只要你會在白板上作推導然後再寫code的領域AI
02/15 21:59, 56F
→
02/15 21:59, 2周前 , 57F
都吃屎，他的訓練資料只有code沒有那塊白板
02/15 21:59, 57F
推
02/15 22:41, 2周前 , 58F
我敢說覺得ai 相關的code還覺得 claude 很難用，九
02/15 22:41, 58F
→
02/15 22:41, 2周前 , 59F
成九是使用者的問題
02/15 22:41, 59F
推
02/16 00:51, 2周前 , 60F
之前改wpf介面改的亂七八糟 但純html/js 表現超強
02/16 00:51, 60F
→
02/16 00:57, 2周前 , 61F
習慣就好，我作遊戲，功能類可以，但架構和有關視覺的難
02/16 00:57, 61F
→
02/16 00:57, 2周前 , 62F
領域還是有差
02/16 00:57, 62F
→
02/16 01:50, 2周前 , 63F
kaltu講的滿好的
02/16 01:50, 63F
推
02/16 08:01, 2周前 , 64F
之前接過一個vibe 出來的專案，重構到快瘋，幾乎程式碼都
02/16 08:01, 64F
→
02/16 08:01, 2周前 , 65F
是workaround出來達成某個目地，這種反而比人寫出來還難
02/16 08:01, 65F
→
02/16 08:01, 2周前 , 66F
知道當初在幹嘛==相信為了這種slop會越來越多
02/16 08:01, 66F
→
02/16 08:53, 2周前 , 67F
資訊少的沒輒 連參數都會下錯 直接google能google到倒是
02/16 08:53, 67F
→
02/16 08:53, 2周前 , 68F
方便不易出錯
02/16 08:53, 68F
→
02/16 18:10, 2周前 , 69F
現在用AI開發後端體感還不錯 但開發App就真的爛到不行
02/16 18:10, 69F
推
02/24 19:52, 1周前 , 70F
我目前的工作經驗是claude code超強，但不要用vibe coding
02/24 19:52, 70F
→
02/24 19:52, 1周前 , 71F
的心態使用他。寫程式終究是一門工程，工程講究的是spec,
02/24 19:52, 71F
→
02/24 19:52, 1周前 , 72F
穩定,可驗證。先去釐清你想要搭建的東西目標是怎樣，腦中
02/24 19:52, 72F
→
02/24 19:52, 1周前 , 73F
架構，跟AI一起做planning，規劃好再讓他工作
02/24 19:52, 73F
‣ 更多 erspicu 的文章
文章代碼(AID): #1faC1r96 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 erspicu 的文章
文章代碼(AID): #1faC1r96 (Soft_Job)