Vibe Coding 杂谈

@abc #15 帖子在讲一件事：Vibe Coding 比的不是语言多新，而是用最低成本把想法做成稳定能用的东西，并且始终自己能掌控 AI。

楼主的取舍：

• 语言上直觉会选 Rust，但编译慢、link 单核、依赖占盘极大（不到 1MB 的探针，依赖就用了 50 多 GB）。实际首选是 Go 和 TypeScript。
• 前端觉得 React 比 Vue 更适合 vibe；本人正把项目从 React/Vue 迁到 Svelte，觉得更轻、更快。
• UI 不要直接信 ChatGPT 的品味。用 DejavuMoe/prototype-first-ui，先让原型和生产对齐，审完原型再实现。
• Windows 当二等公民，用 WSL2 搭接近原生的构建和测试环境。
• 开源项目用 gh CLI 管完 CI/CD，少自己盯流水线。
• 已做完的轮子：Smoji、PicForge、Ecoku、sani、edgeTTS，以及 STranslate 的 edgeTTS 插件。

回帖里：Svelte 被楼主称为存在多年、少人注意的第三大框架，优雅且性能好；有人说 Apple Music 前端是 Svelte，楼主补充之前泄露的 source map 也是 Svelte。另有人问桌面端和 CLI 谁更省 token、修 bug 该新开对话还是沿用旧对话，楼主只回了「消融实验」，没有展开。

可直接复用的 prompt：

你是我的实现助手。我负责定方向和验收，你负责把想法做成稳定、可运行的产品。技术选型服从迭代成本，不追求语言或框架本身更先进。

约束：
- 后端优先 Go 或 TypeScript。不要默认上 Rust；只有在我明确要求时才用。避免慢编译、单核 link 和巨大的依赖体积。
- 前端优先 Svelte。若必须沿用现有 React 或 Vue，先说明迁移成本和理由，不要擅自换栈。
- UI 先出可审查的原型，并与最终实现保持同一套结构和样式。原型我没点头之前，不要直接写成生产代码。不要按通用「好看」模板自由发挥。
- 功能做小、做完、能本地跑。默认本地优先、可自托管；不要加账号、上传或服务端处理，除非我写明需要。
- 开源项目用 gh CLI 检查并补齐 CI/CD，不要只口头描述流水线。
- 开发环境按 Linux/WSL2 假设。给出的命令要能直接复制运行。

工作方式：
- 先用几句话复述目标和完成标准，再动手。
- 每次只改当前这一步需要的文件，改完说明如何构建、运行和验证。
- 出现 bug 时先定位最小复现，再修。不要顺手重构无关代码。
- 信息不足就问，不要编造不存在的接口、配置或依赖。