科技Bestblogs·浮之静··AI 生成
编程心得：Vibe 上百亿 Token 后，我收获了什么?
作者分享使用 Codex 消耗约 440 亿 Token 进行 AI 辅助编程的深度实战经验。核心结论是 Token 消耗更多用于上下文、推理与验证，而非直接产出代码，人的判断与方向把控仍是关键。文章详细分析了 Rust、TypeScript/React/Tailwind 等技术栈为何更适合 AI 高频生成-修改-验证循环，并介绍了 Opsail 项目中在 Electron 里实现 Chrome 插件兼容层的工程挑战。适合有大量 AI 编程实践经验、希望优化工作流和架构决策的开发者阅读。原文 ↗原文 ↗
核心观点
- ▍AI 辅助编程的核心是人的判断与验证，Token 消耗不能直接等同于产出价值，大部分 Token 用于上下文、推理和验证，而非直接产出可交付代码。
- ▍Rust、TypeScript+React+Tailwind、Electron 等技术栈因强类型、快速反馈和完整生态，更适合 AI 高频生成‑修改‑验证循环，能帮助 AI 在闭环中快速收敛。
- 01作者在 Opsail 项目中，通过在 Electron 中实现 Chrome 插件兼容层，验证了复杂的运行时适配方案，涉及进程、环境、权限和生命周期的精细管理。
- 02作者通过不断重构 keel 和 coding‑protocol 等 harness，降低了架构重写成本，使 AI 辅助更聚焦于价值工作，而非重复劳动。
- 03作者指出 Anthropic 的 Sonnet 模型在长任务推理（如 Sol 的长任务推理能力）和 Computer-Use 在 UI/Debug 类任务处理上表现突出。
- 04作者观察到，在高频 Token 使用中，架构演进与 harness 设计比单纯依赖 AI 生成更能提升代码质量和降低重复劳动。
反方 / 局限
- — 文章虽强调人的判断，但未深入讨论当模型能力远超个人判断力时（如超级对齐问题），该工作流可能失效的边界情况。
- — 作者推荐的特定技术栈（如 Rust/Electron）可能不适用于所有项目，特别是快速原型或资源受限的移动端场景，文章未充分展开这些局限性。
前置背景
技术原理
平行视角
未来推演
延伸追问