氛围编程 vibe coding
vibe coding 这是最近很火的一个名词，氛围编程，大概意思就是通过和AI Agent的交互，来让AI负责主要代码的编写，工程师的角色或者说任务从一个主要的写代码的人，变成主要的思考框架输出者。 最近深度使用了这种方式，构建了几个project，有从零开始构建的类型，也有去加插件类的对已有代码的外挂式增强，也有直接去改项目的主要代码的。 这里说一下自己的感受 首先整体的使用方式，使用 Cursor, 通过配置 Cursor Rules 以及一些 MCP Tools 来对cursor进行一定的限制和增强。 这点尤为重要，因为大语言模型的一个问题是一定的不稳定性，而在编程当中，保持代码风格一致性，设计模式的一致性，是非常重要的。没有rules的限制，往往会造成每次生成的结果方差很大，无法在同个项目的多次迭代中保持一致。 Prompt 很重要，需要给出足够的上下文，描述清楚你到底想做什么，甚至是想用什么方式做。这些是需要自己去做研究，做 LLM Deep Research 的 – （可以借助openai o1的deep research 能力，或者grok的能力，去迅速掌握某个话题的一些核心的理念） 反馈机制，需要描述清楚你到底最终想要达到什么状态，让LLM确定出如何就算做完了。当前的agent是有工具调用能力的，可以多次迭代，需要使其清楚到底现在进展到了什么程度，是否真的完成了任务。 在上述的三个场景当中，用的最舒服的还是从零开始构建代码，前提是带着比较合理的cursor rules，对于写一些工具类的脚本的场景，还是很适合的，可以很快完成一个功能的开发； 插件式功能开发只要把如何算作完成这件事情定义好，做的也还okay；对于大型企业级工程项目，表现比较一般，尤其是涉及到多文件的改动的时候，如果需求描述不够明确，往往会改动到你没有设想的地方；以及会有一些风格，逻辑的不一致，这很可能会导致你使用更长的时间去调整cursor写出的代码。 Agent 本质上还是依赖于公开网站上的资料，以及已有的一些代码，很不幸工业级代码所占比例在互联网当中感觉占的还是有点少，直接输出的代码质量还是不太行。最近在探索的就是给更多的retro机制，让cursor把每次做的不好的地方记录下来，放到cursorrules当中，这样子至少同样的问题下次不会再犯。 有效，但是是不是很drama。Agent 解放生产力，但是往往很放荡不羁，于是还是需要人来加很多边界。只要人还需要读懂代码，那么就得按照我们约定俗成的方式，设计模式，MVC等等，来按照这些协议去书写更有边界的代码。 未来来了么？ 我想总有一天，工程师会更像产品，对于技能术的要求会变化，考验的是端到端的思考能力，架构能力。哪怕是Vibe Coding，不同的人生成的代码质量还是会很不一样，vibe依旧不是银弹，但是他可以很大程度去增强一个工程师的能力边界，开发速度。试想一个本身就是10x的工程师，在用了这些工具之后，迅速变成30X，50X，这是一种什么体验！