最近开始在摸索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