@tmkook 主要看模型能力，如果模型太小的话可能会抽卡，可以加个 context7 这个 MCP 服务 https://github.com/upstash/context7 ，对话时需要参考文档的话就在末尾加一句 use context7 ，插件检测到就会和 context7 沟通来判断要读取什么文档然后去读取

@tmkook 随手写的 https://chat.qwen.ai/s/2514668b-48cd-4046-b530-e706bb5faf4b?fev=0.0.201 ，在 vscode 里我一般结合 Roo Code 让它自己读写文件，包括参考已有的页面就直接 at 那个文件让大模型参考

@tmkook 我开发的时候体验还好，一个窗口打开 api 项目，一个窗口打开前端项目，文件跳转也不会跳错。至于 AI 写 amis ，我测试本地跑的 GLM-4.5 Air 和 Qwen Coder 30B 都能写出不错的 amis json 页面，我现在都懒得手写了。

我的一个现成也是基于 amis 做后台页面的项目结构，前后端仓库分开，pages 随意扩展也不影响 api 的开发，喜欢打包放一起（ site.json 加鉴权防止偷页面）或者前端直接丢对象存储托管都可以(方便直接顺藤摸瓜拿走所有页面，不过现阶段页面都是大模型写的也没什么价值了)

├── web-api # 后端 api
└── wwwroot # 前端 amis 项目
├── index.html # 首页
├── login.html # 登录页
   ├── site.json # 路由
├── pages # 各种后台页面
│   ├── account
│   │   ├── list.json
│   │   ├── detail.json
│   │   ├── edit.json
│   │   ├── create.json
└── public # 前端公共资源
├── history
│   └── 4.10.1
│   └── history.js
└── sdk
└── 6.7.0

@tmkook 做成文件另一个好处是发布的时候可以加个简单的压缩打包机制，加个版本号，结合浏览器缓存机制基本上页面请求一次之后就缓存在本地了，至于难不难读都是 LLM 干的事情，我现在用 amis 做页面都是让大模型做的

amis 这部分不如直接写 json 文件来得直接，在 static 目录放个 pages 之类的文件夹就行了，不然去文档里抄一个 demo 快速预览下还得转换成你那个 js 风格太蛋疼了

@jjustwin 我实测也是发现 A3B 补全效果确实拉跨，现在用 jetbrains mellum 为主，A3B 的话配合 Roo Code 自己完成一些任务还不错。现在我对于自动化完成功能的需求比补全大多了

brave 浏览器自带这个功能

怕被运营商制裁那就先传到运营商做的网盘服务，然后开个阿里云同城的 200MB 峰值带宽的轻量云机器来跑网盘客户端中转咯

比较折腾而且和模型要适配，我测了 Claude Code 结合本地的 GLM-4.5-Air 、Qwen3-235B-A22B-Instruct-2507 、Qwen3-Coder-30B-A3B-Instruct ，经常会消耗了几十 K 的 token 但是活都没开始干，不能一个 prompt 就让它“自己动”完成所有事情，连把大模型给的代码写入文件都做不好，同样的 prompt 丢到 Roo Code 就不同了，结合上面几个本地跑的模型完成度非常高，人工干预极少

@BingoXuan 24 小时输出的话，库克和阿里都亏麻了

最佳性价比就是蹲苹果官方翻新的 Mac Studio Apple M3 Ultra 芯片 512GB + 1TB 版本，价格 6.3w ，24 期免息每个月 2.6k ，然后跑 Qwen3-Coder-480B-A35B-Instruct ，5bit 量化速度 19token/s 左右，一天可以输出 150w 左右的 token ，约等于调用价值 400RMB 的官方 API 。

等预计今天发布的 Qwen3 Coder 30B-A3B 结合 https://www.continue.dev/ 本地部署

根据 Qwen 系列的一贯表现，大杯模型和超大杯模型的差距很小，等个 Qwen3-Coder 其它尺寸的模型本地部署玩玩。

目前这个尺寸的模型跑 4bit 动态量化也要 270GB 的 vram ，前几天 M3 Ultra 512GB + 1T 的官方翻新突然有货，只要 6.3w ，免息分 24 期一个月只要 2600+，还能找点员工渠道折扣更便宜，拿来本地部署一个接近 Sonnet 4 的编码模型往死里用其实挺划算

@liuhai233 以 basic 这档 1GiB 内存、1/4 CPU 和 4GB 磁盘规格的 instance 为例子，如果是长期运行的话

一个月 = 30 天 x 24 小时 x 每小时 3600 秒 = 2592000 秒
内存的免费额度：25 GiB-小时 = 25 × 3600=90000 秒
超出的部分就是(2592000 - 90000) * 1GiB 内存 * $0.0000025 = $6.255

同理，CPU 额度超出部分就是（ 2592000 秒 - 375 分钟 * 60 秒）* 1/4 vCPU * $0.000020 = $12.8475

磁盘额度超出部分就是（ 2592000 秒 - 200 小时 * 3600 秒）* 4GB 磁盘 * $0.00000007 = $0.52416

一个月接近$20 ，从目前文档看，容器的 IO 等待时间也是计算在内的，而 worker 的 IO 等待是不计费的，这个可以说是最显著的区别了，所以想用的话得识别好业务的实际形态

从定价上来说其实很贵，如果长时间运行的话比同配置包月的 vps 和云服务器贵上非常多（当然流量还是比各种云服务便宜很多，云厂商普遍 0.8 元/GB 的国际流量，它在付费计划里有 1TB 的默认额度）。这种 serverless 赌的就是你会不会长期运行。

没啥意义，qwen3-30B-A3B 的 4bit 量化在 M2 Ultra 上以 85 token/s 的速度秒了这一题，显存占用 18GB 左右。
prompt：从架构师角度分析这个问题"js 不使用 promise 完成一个 sleep 函数，必须支持 await 调用，还要能在浏览器使用"，本地不跑大模型可以去官网 https://chat.qwen.ai/ 问

当你掌握很多门语言之后，就知道那些屎一样的临时过渡方案就知道压根没必要看，JavaScript 的 async/await 都是抄 2012 年 C#发布的 5.0 语法，而且还没一次性抄对，中间搞那个 yield 恶心方案和过渡的 promise 方案，当时很流行的库有 co/bluebird/async 不知道有多少人记得。到了 2017 年 6 月 async/await 才正式并入规范，而 2017 年 5 月 Node.js 8.0 都正式支持 async/await 了，之前 6.x 都能通过参数开实验性支持了。

我从 8.0 开始用 Node.js ，当时直接上 TypeScript 写后端，根本懒得吃那些设计缺陷造的屎，原型链和这种 then 地狱风格的代码压根没写过一行，项目规范都禁止写这种代码。

至于你补充那个 python 例子，和异步也没啥关系，就一个默认递归深度，在带 GC 的语言中敢写递归之前不看限制或者有没有尾递归优化吗？

早期 sublime text 用多了，现在都是统一 sublime text 风格