wurank

这两年，大家对 AI 编程的热情几乎都可以归到一个词里：vibe coding。 它代表一种很新的开发体验：你不再从空白文件开始，而是先从一个想法、一段自然语言、一种模糊的产品感觉开始；你不再事事亲手敲代码，而是和模型来回对话，让它快速生成、修改、迭代。你更像导演，模型更像一个高产但不完全稳定的搭档。 这种体验之所以让人上瘾，是因为它极大降低了"把想法变成原型"的门槛。很多人第一次感受到，原来编程可以像写草图、剪视频、做音乐一样，有一种顺滑的"流动感"。 但问题也很快来了。 大多数人很快发现，vibe coding 在做 demo 时很爽，在做真实任务时却经常失控：上下文越来越乱，模型越写越偏，改一个功能会带坏另一个功能，任务一复杂就忘前忘后，甚至连"下一步该干嘛"都得靠人不断提醒。于是我们开始反思：vibe coding 到底是编程方式的终点，还是只是一个中间态？ 我最近看了 shareAI-lab/learn-claude-code 这个项目，最大的感受是：它给了这个问题一个非常清晰的回答。 它最有价值的地方，不是教你"怎么复刻 Claude Code"，也不是再做一个 AI coding agent demo，而是它把一个关键认知讲透了： 问题从来不在于模型会不会写代码，而在于你有没有给模型搭好一个能稳定工作的工程环境。 也就是说，它对当下 vibe coding 的最大影响，是把很多人从"和模型聊天写代码"的阶段，推进到了"为模型设计工作台"的阶段。 一、Vibe Coding 的浪漫，和它的天花板 vibe coding 的魅力在于，它把软件开发中最痛苦的一部分——结构化表达、样板代码、重复修改——交给了模型。 你只需要说： “帮我做个后台管理页面” “把这里改成卡片布局” “接一个登录流程” “顺便把这个 bug 修掉” 然后看着它飞速往前推进。 这种模式特别适合三类场景： 第一类是原型验证。 你有一个点子，想在半小时内看到可运行的界面和交互。 第二类是低风险试错。 比如做个活动页、可视化页面、内部工具，哪怕代码不够优雅也问题不大。 第三类是个体开发者的表达放大。 本来你只有 60 分的产品感和 40 分的前端能力，现在通过模型，能快速做出 75 分的成品。 但它的问题也很明显。 vibe coding 最大的隐含前提是：任务足够短、上下文足够近、目标足够清晰、系统复杂度足够低。 一旦超出这个范围，问题就会开始暴露： 模型会忘记之前约定的架构； 会重复造轮子； 会在错误的抽象层上改来改去； 会因为上下文太长而开始"半懂不懂"； 会把一个需要拆分的问题，硬塞进一次回答里； 会把局部正确当成全局完成。 很多人以为这是模型还不够强，但 learn-claude-code 其实在提醒我们：这不只是模型问题，更是工作方式问题。 ...