Category: 氛围编程

最近有个朋友问我：“为什么我在小项目上用Vibe Coding得心应手，一碰到公司那个几百万行代码的老系统就感觉AI突然变笨了？”这个问题让我想起了一个经典的比喻：让一个只读过几页书的人去参加博士论文答辩。 这个比喻恰好揭示了Vibe Coding在大型代码库中面临的核心挑战——语境窗口限制。就像人脑的短期记忆有限一样，AI模型每次能处理的代码量也有上限。当你的代码库规模超过这个上限时，AI就变成了那个只读过几页书的“考生”。 我最近在重构一个金融系统的支付模块时深有体会。这个模块涉及用户管理、风控、账务等十几个子系统，总代码量超过50万行。刚开始，我试图让AI一次性理解整个模块，结果就像让一个人同时记住整本百科全书——根本不可能。 但问题总要解决。经过反复试验，我总结出了一套“分而治之”的策略。首先，我把整个支付流程拆解成独立的意图单元：用户验证、风险评估、资金划转、交易记录。每个意图单元都配有清晰的接口规范和能力描述，就像给AI提供了一张精确的地图。 这里有个关键技巧：建立“能力目录”。我把每个微程序的核心功能、输入输出、依赖关系都记录在一个结构化的文档中。当需要修改某个功能时，AI只需要查阅目录，然后专注于相关的几个模块，而不是试图理解整个系统。 另一个重要发现是：代码注释的质量直接影响AI的理解能力。那些写着“这里很重要”或者“TODO”的注释，对AI来说毫无意义。而像“此函数用于验证用户交易权限，依赖风控系统的风险评估结果”这样的描述，才能帮助AI建立正确的上下文关联。 说到工具，我发现现代IDE的代码导航功能变得前所未有的重要。快速跳转到定义、查找引用、查看调用链——这些功能帮助AI（和开发者）在庞大的代码迷宫中保持方向感。有时候，一个好的IDE插件比更强大的AI模型更有用。 但最让我兴奋的是，这个问题反过来推动了Vibe Coding理念的进化。我们开始意识到：在大型系统中，清晰的架构边界和接口契约比代码本身更重要。就像城市规划，重要的不是每栋建筑的具体结构，而是道路网络和功能区划分。 现在，当我面对新的大型项目时，第一件事不是急着写代码，而是花时间定义系统的“语义地图”。哪些模块是核心业务逻辑？哪些是基础设施？它们之间如何通信？这张地图不仅帮助AI理解系统，也让我自己对架构有更清晰的认识。 有时候我在想，这或许正是Vibe Coding带给我们的最大价值：它迫使我们用更抽象、更系统的方式思考软件设计。当代码不再是需要逐行维护的资产，而是可以按需生成的临时产物时，我们才能真正专注于那些具有长期价值的东西——架构、接口和业务意图。 那么，你在面对大型代码库时，是选择继续深陷在代码的海洋里，还是开始绘制自己的语义地图？

最近有个创业公司的CTO向我抱怨：他们用AI助手生成了十几个微服务，结果发现这些服务之间的调用关系复杂得像一团乱麻。一个简单的用户注册功能，竟然要经过5个服务间的相互调用才能完成。这让我想起了微服务架构领域那句经典名言：“分布式单体是比单体应用更糟糕的架构”。 在传统的微服务开发中，我们靠架构师的智慧和团队间的紧密协作来确保服务的高内聚、低耦合。但在Vibe Coding时代，当AI成为主要的代码生成者时，这种平衡该如何维持？ 在我看来，问题的根源在于我们仍然在用“代码思维”指导AI。我们给AI的提示词往往是“写一个用户服务”、“生成订单处理模块”，却没有告诉AI这些服务应该如何协作、彼此间的边界在哪里。这就好比让一个不了解城市规划的建筑师去设计城市，每个建筑单独看都很漂亮，但组合在一起就成了交通噩梦。 那么，Vibe Coding应该如何解决这个问题？关键在于从“代码解耦”转向“意图解耦”。 首先，我们需要为AI定义清晰的“能力契约”。这不是传统意义上的API文档，而是更高层次的意图描述。比如，与其说“生成用户服务”，不如说：“这个服务负责用户生命周期管理，需要提供注册、登录、信息查询能力，但不能直接访问订单数据，所有跨领域操作必须通过事件驱动完成”。这样的描述让AI在生成代码时就有了明确的边界意识。 其次，我强烈建议采用“自底向上”的服务定义方法。先让AI生成最小化的能力单元，然后再由AI根据业务需求将这些单元组装成服务。这就像玩乐高积木——先有标准化的基础模块，再根据图纸搭建复杂结构。在这个过程中，人类开发者的角色从“代码编写者”转变为“意图定义者”和“组装规则制定者”。 亚马逊的“两个披萨团队”原则在这里给了我很大启发。每个微服务应该小到能够被一个两个披萨就能喂饱的团队完全理解和管理。在Vibe Coding中，这个原则可以演变为“单一意图原则”——每个服务应该专注于一个明确的业务意图，而且这个意图要简单到AI能够完全理解并在生成代码时保持专注。 但这里有个陷阱：过度解耦。我曾经见过一个项目，为了追求极致的解耦，把原本简单的用户查询拆成了三个服务，结果性能下降了70%。Vibe Coding不是要把所有东西都拆开，而是要在内聚和耦合之间找到最佳平衡点。这个平衡点的判断标准是什么？我认为是“变更成本”。如果修改一个功能需要同时改动多个服务，说明耦合度太高；如果一个服务的内部修改频繁影响到其他服务，说明内聚度不够。 在实际操作中，我总结了一套“三层提示词”方法：第一层是业务意图描述，定义服务要解决什么问题；第二层是架构约束，明确服务的边界和协作方式；第三层是实现规范，包括技术栈选择、代码风格等。通过这种分层的方式，AI在生成代码时就有了清晰的指导原则。 举个例子，当我们要开发电商系统的库存服务时，给AI的提示词可能是这样的：“这是一个库存管理服务，需要支持库存查询、扣减、回滚操作。它不能直接调用订单服务，所有库存变更必须通过事件通知其他服务。使用Redis作为缓存，MySQL作为持久化存储……”这样的描述既明确了服务的职责范围，也规定了与其他服务的协作方式。 不过，我也要提醒大家，Vibe Coding不是银弹。AI生成的代码质量很大程度上取决于我们提供的提示词质量。就像著名的“垃圾进，垃圾出”原则，如果我们的意图描述模糊不清，AI生成的服务自然也会边界模糊、职责混乱。 在微服务架构演进的历史上，我们经历了从单体到微服务，再到服务网格的变革。现在，我们正站在一个新的转折点：从人工设计的微服务到AI组装的意图服务。这个转变不仅仅是技术层面的，更是思维方式的重构。 想想看，当每个微服务都源于清晰的业务意图，当服务间的协作都基于明确的契约，当整个系统能够通过调整意图描述来自动重构和优化——这样的架构不就是我们一直追求的理想状态吗？ 那么，你现在准备如何用Vibe Coding重构你的微服务架构？是继续让AI盲目生成代码，还是开始认真思考每个服务背后的业务意图？这个选择，可能决定了你未来几年的架构演化路径。

最近有个问题一直在我脑子里打转：当AI让编程变得像说话一样简单时，这个世界会变成什么样？特别是对那些原本不会写代码的人来说，这到底是在打开新世界的大门，还是在加深数字时代的鸿沟？ 记得去年我在一个创业活动上，遇到一个做服装设计的小伙子。他用ChatGPT写了个小程序，把自己设计的图案自动生成到不同的服装模板上。他说：“以前要找程序员帮忙，现在自己动动嘴皮子就行。”这件事让我想了很多——如果连设计师都能随手写程序，那传统的技术壁垒是不是正在瓦解？ 但事情没那么简单。就在上个月，我看到麦肯锡的一份报告显示，全球范围内，发达国家对AI工具的使用率是发展中国家的3倍以上。这个数字让我有点坐立不安。这意味着什么？意味着当我们在讨论“人人都是程序员”的时候，有些人连讨论的资格都没有。 从系统角度看，这其实是个典型的“马太效应”。那些原本就掌握技术资源的地区，能更快地拥抱AI编程，形成正向循环；而技术基础薄弱的地区，可能连追赶的机会都没有。就像哈佛商学院教授克莱顿·克里斯坦森说的：“颠覆性技术最初总是服务于未被满足的需求，但最终会重塑整个产业格局。” 不过，我始终相信技术本身是中立的，关键在于我们怎么用它。Vibe Coding的理念之一就是“人人编程，专业治理”。这意味着我们要做的不是把所有人都变成专业程序员，而是让每个人都能用自然语言表达自己的需求，让AI来帮忙实现。 举个例子，印度有个叫“AI for Villages”的项目，培训农村妇女用简单的提示词生成农业管理小程序。她们不需要懂什么数据结构、算法，只需要告诉AI：“帮我记录每块田的施肥时间”或者“提醒我什么时候该浇水”。结果呢？这些小程序让他们的农作物产量提高了20%。 但问题又来了：这样的项目能规模化吗？能持续吗？这就是为什么我认为，在Vibe Coding时代，我们需要建立更完善的技术普惠生态。不仅仅是提供工具，还要有培训、有支持、有持续迭代的机制。 从架构层面看，我们需要思考几个关键问题：如何降低AI编程的学习曲线？如何确保生成代码的质量和安全性？最重要的是，如何让这些技术真正惠及全球各个角落，而不是只停留在硅谷和几个科技中心？ 我有个大胆的预测：未来5年，我们会看到“技术平权”成为全球议题。就像互联网普及过程中出现数字鸿沟一样，AI编程的普及也会面临类似的挑战。但不同的是，这次我们有机会提前布局。 在我看来，解决这个问题的关键不在于技术本身，而在于教育、基础设施和治理模式的创新。我们需要建立更开放的技术共享平台，设计更友好的用户界面，更重要的是，要培养一种“技术共治”的文化。 说到这里，我想起经济学家埃斯特·迪弗洛的一句话：“技术的价值不在于它有多先进，而在于它能在多大程度上改善普通人的生活。”这句话用在AI编程上再合适不过了。 那么，回到最初的问题：AI编码是在加剧不平等，还是在创造新的机会？我的答案是：两者都在发生，但最终走向取决于我们今天的选择。我们是选择筑起更高的技术围墙，还是搭建更宽广的技术桥梁？这个问题，值得每个关注技术发展的人深思。

最近有个话题特别火：Vibe Coding（氛围编程）和Visual Programming（可视化编程），到底谁能更好地赋能非专业开发者？作为一个在编程领域摸爬滚打多年的老手，我觉得这个问题就像在问“自行车和电动车哪个更适合通勤”一样有趣。 记得我第一次接触可视化编程是在2010年，当时被拖拽式界面惊艳到了。MIT的Scratch项目让小学生都能编游戏，Salesforce的Lightning Platform让销售人员能搭建CRM系统——这些都是可视化编程的经典案例。但说实话，这些工具就像乐高积木，你能拼出什么，完全取决于厂家给了你什么形状的积木块。 而Vibe Coding则完全是另一个维度的存在。它不关心你怎么拖拽积木，而是让你直接告诉AI：“我想要一个能自动识别发票并归档的系统”。剩下的，AI会帮你组装代码、测试、部署。这就像是从“拼积木”进化到了“用意念造物”。 为什么我说Vibe Coding更适合非开发者？让我用个比喻：可视化编程就像给你一套预制菜，你能做出不错的饭菜，但永远做不出米其林三星。Vibe Coding则是给你一个顶级厨师当助手，你只需要描述想吃什么，他就能给你做出来。 举个真实案例：某电商公司的市场总监用Vibe Coding工具，仅用自然语言描述需求，就搭建了一个智能客服系统。而在传统的可视化编程平台上，同样的系统需要专业开发团队数周时间。这不是魔法，这是范式革命。 但别误会，我并不是全盘否定可视化编程。在特定场景下，它仍然很有价值。比如教育领域，可视化编程是理解编程思维的绝佳入门工具。就像学骑车先用辅助轮一样，可视化编程能帮助非开发者建立计算思维。 关键在于，Vibe Coding解决了一个根本问题：它把编程从“语法记忆”变成了“意图表达”。你不必记住if-else的写法，只需要清楚地表达业务逻辑。这正好契合了Qgenius提出的Vibe Coding原则——代码是能力，意图才是长期资产。 说到这里，可能有读者会问：那可视化编程会不会被淘汰？我的看法是，它会进化。未来的可视化工具可能会集成Vibe Coding的能力，形成混合模式。就像现在的汽车，既有方向盘（可视化交互），也有自动驾驶（AI驱动）。 不过，Vibe Coding也面临挑战。最大的问题是如何确保AI准确理解人类意图。这需要更好的提示词工程、更完善的数据治理，以及更可靠的验证机制——这些都是我们正在努力的方向。 最后，我想说的是：技术进化的本质是让复杂的事情变简单。从打孔卡到高级语言，从命令行到图形界面，每一次进步都在降低使用门槛。Vibe Coding不是终点，而是这个进化过程中的重要里程碑。 […]

前几天有个创业者朋友问我：”现在AI写代码这么厉害，我们还需要学习编程吗？”这个问题让我思考了很久。在我看来，AI辅助开发不是要取代程序员，而是开启了一种全新的软件开发范式——我称之为”氛围编程”（Vibe Coding）。 氛围编程的本质是什么？简单说，就是从”写代码”转向”定义意图”。就像建筑师不需要亲自搬砖砌墙，而是专注于设计蓝图和规范一样。在氛围编程中，开发者的核心工作是清晰地表达需求、定义约束、制定规范，然后让AI来组装和执行。 但这里有个关键问题：如果人人都能通过AI”编程”，我们如何确保软件的质量、安全和可维护性？这正是我们需要一套原则的原因。经过长时间的实践和思考，我总结出了氛围编程的十大核心原则。 首先，”一切皆数据”。在AI时代，代码、提示词、运行日志、配置参数都是数据。我们需要建立统一的数据治理体系，就像GitHub联合创始人Tom Preston-Werner说的：”所有重要的软件最终都会演变成一个数据问题。” 第二，”避免数据删除”。这听起来有点反直觉，但在遵循隐私法规的前提下，保留数据意味着保留可追溯性。想象一下，如果每次AI生成的代码都能被完整追踪，调试会变得多么简单。 第三点可能是最具颠覆性的：”代码是能力，意图与接口才是长期资产”。传统软件开发中，我们花费大量时间维护代码；而在氛围编程中，代码可能是临时性的，真正重要的是那些定义清晰的需求描述、接口规范和约束条件。 这就引出了第四原则：”不手改代码”。听起来很激进，但想想看，如果AI生成的代码有问题，你是应该直接修改代码，还是应该优化产生这个代码的提示词？后者显然更符合长期利益。 第五，”用标准连接一切能力”。就像USB接口标准化了设备连接，我们需要标准化的通信协议和数据格式，让不同的AI能力和组件能够无缝协作。 第六原则”AI组装，对齐人类”强调了一个关键平衡：AI负责执行，人类负责决策。就像自动驾驶中的”驾驶员在环”概念，人类始终是最终的责任主体。 第七，”依靠自组织的微程序来搭积木”。这让我想起生物系统中的细胞，每个细胞都很简单，但组合起来却能形成复杂的生命体。软件系统也应该如此。 第八，”验证与观测是系统成功的核心”。如果不能观测、不能测试、不能追责，再智能的系统也是不可靠的。Google的Site Reliability Engineering理念在这里同样适用。 第九，”人人编程，专业治理”。当业务人员也能通过自然语言创建软件时，专业开发者的角色就转向了制定标准、确保安全和维护生态。 最后，”从软件工程到软件生态”。我们不再只是构建单个软件，而是在培育一个充满活力的软件生态系统。 这些原则听起来很理想化，但正如亚马逊CEO Andy Jassy所说：”好的领导力需要固执的愿景和灵活的细节。”我们现在需要的正是这种固执的愿景。 当然，实现这些原则还面临很多挑战。模型能力的限制、安全治理的复杂性、工程工具的缺失……但正因为有这些挑战，才更需要明确的方向。 在我看来，氛围编程不是遥远的未来，而是正在发生的现实。每次你用自然语言让AI完成一个任务，每次你通过优化提示词获得更好的结果，你都在实践氛围编程。 […]