Tag: 意图设计

最近我在想，我们是不是把编程这件事想得太复杂了？或者说，我们一直在用错误的方式思考编程的边界。当我第一次接触Vibe Coding这个概念时，就像哥伦布发现了新大陆——原来代码可以不是终点，而只是一个临时的中间产物。 让我用一个简单的例子来说明。假设你要开发一个电商网站的购物车功能。传统的做法是：写代码定义数据结构、实现添加商品、删除商品、计算总价等功能。但在Vibe Coding的世界里，你只需要清晰地描述意图：“创建一个购物车系统，支持添加商品、移除商品、计算总价，并能与库存系统实时同步”。剩下的，交给AI去组装合适的微程序来完成。 这听起来很美好，但问题来了：如果一切都是AI自动组装，那开发者的价值在哪里？边界又在哪里？ 在我看来，Vibe Coding的核心边界在于“意图的清晰度”和“约束的完整性”。就像建筑师不需要亲手砌每一块砖，但必须确保设计图纸的精确和施工规范。我们正在从“代码工匠”转变为“系统设计师”。 还记得那个著名的布鲁克斯定律吗？“往一个已经延期的项目中增加人手，只会让项目更加延期”。但在Vibe Coding的范式下，这个定律可能需要重写。因为增加的不是传统意义上的“程序员”，而是能够清晰表达业务需求的“意图设计师”。 不过，这里有个有趣的悖论：越是依赖AI自动生成代码，我们越需要严格的逻辑思维。因为模糊的意图会产生模糊的代码，而模糊的代码在AI组装时会产生指数级的复杂性。这就像告诉一个孩子“把房间收拾干净”和“把书放回书架，衣服叠好放进衣柜，玩具收到箱子里”的区别。 我特别喜欢Qgenius提出的那个比喻：把提示词看作过去的代码，把代码看作过去的可执行文件。这个视角转换让我恍然大悟——我们一直在维护错误的东西！就像你会在意Word文档的二进制编码吗？不会，你在意的是文档的内容和格式规范。 但这里有个关键问题：如果代码可以随时被AI重写，那我们如何确保系统的稳定性和可追溯性？答案就在“一切皆数据”的原则里。所有的意图描述、生成的代码、运行日志都是数据，都需要统一的数据治理。这让我想起亚马逊的“API优先”文化，只不过现在升级成了“意图优先”。 说到边界，不得不提“不手改代码”这个原则。刚开始我觉得这太极端了，但仔细想想，这不正是我们追求的终极目标吗？就像现代飞行员不会直接操控飞机引擎的燃油混合比，而是通过飞行管理系统设定目标，让计算机自动优化。 不过，我必须要说，Vibe Coding不是银弹。它要求我们重新思考软件开发的每一个环节。从需求分析到系统设计，从测试验证到运维监控，所有的边界都在重新定义。 最后，我想用一个问题结束：当代码不再是稀缺资源，什么才是真正值得投资的资产？我的答案是：清晰的业务理解、精确的意图表达，以及能够连接一切能力的标准化接口。这些，才是Vibe Coding时代真正的核心竞争力。

最近有个朋友问我：为什么你总是在谈论Vibe Coding？这玩意儿真的能改变编程的本质吗？我笑着回答：因为它不仅仅是一种技术，更是一种生活哲学。 记得我第一次接触氛围编程时，心里也在犯嘀咕。不就是让AI写代码吗？但当我真正开始用意图描述代替代码编写时，突然意识到：这就像是从手动驾驶升级到了自动驾驶。你不再需要关心每个油门和刹车的细节，而是专注于告诉系统你要去哪里、以什么方式到达。 在传统编程中，我们常常陷入一个误区：把代码当成最终产物。但仔细想想，代码真的那么重要吗？就像著名计算机科学家Donald Knuth所说：“程序是写给人看的，只是顺便让机器执行。”在Vibe Coding的世界里，这个观点被推向了极致——代码成了临时工，而意图描述才是真正的管理者。 让我给你讲个真实的案例。去年，我帮助一家创业公司重构他们的用户系统。按照传统方式，这需要3个工程师工作两周。但我们采用了氛围编程的方法：先用自然语言描述系统需求，然后让AI生成代码，最后通过严格的测试验证。结果呢？整个过程只用了3天，而且系统的可维护性提升了数倍。 这背后的逻辑其实很简单：当我们把编程的重心从“怎么写”转移到“要什么”时，整个思维模式都发生了转变。就像建筑师不再亲自搅拌水泥，而是专注于设计蓝图和施工规范。 但我要强调，这并不意味着程序员会失业。恰恰相反，我们需要更多懂得如何与AI协作、如何设计清晰意图、如何建立验证体系的人才。就像汽车普及后，司机没有消失，而是变成了更专业的驾驶员。 有个现象特别有意思：很多非技术背景的人反而更容易接受氛围编程。因为他们没有被传统的编程思维束缚，能够更自然地用业务语言描述需求。这让我想起亚马逊的“六页纸”文化——用清晰的文档代替花哨的PPT，本质上都是在追求更直接的意图表达。 不过，氛围编程也不是万能药。它要求我们建立更严格的数据治理体系，确保每个意图描述都能被准确理解和执行。就像城市规划需要完善的交通法规，否则再好的自动驾驶技术也会乱套。 说到这里，你可能要问：那我们现在该怎么做？我的建议是：开始练习用自然语言精确描述你的编程需求。试着把“我要一个用户登录功能”细化为“我需要一个安全的用户认证系统，支持邮箱和手机号登录，具备防暴力破解机制，并且符合GDPR规范”。你会发现，当你越能清晰地表达意图，AI就越能帮你实现理想的效果。 最后，我想用个比喻结束：传统编程像是在迷宫里找路，而氛围编程更像是拥有了迷宫的俯视图。我们依然需要决定走哪条路，但至少不用在每个岔路口都重新研究地图了。你说，这样的转变，难道不值得期待吗？

最近在AI编程圈子里流传着一个有趣的对比：Michelangelo Coding vs Vibe Coding。乍一听像是两种不同的编程风格，但在我看来，这其实是软件工程发展史上两个截然不同的时代。 让我们先聊聊米开朗基罗式的编程。这个名字来源于文艺复兴大师米开朗基罗的那句名言：“雕像本来就在大理石里，我只是把多余的部分去掉。”传统的编程不就是这样吗？开发者就像雕塑家，在脑海中构想出完整的软件架构，然后用代码一点一点地“雕刻”出来。每个函数、每个类、每个模块都需要精心设计，反复打磨。这种方式的优势很明显——严谨、可控、可预测。但问题也在于此：当需求变化时，我们往往需要重新雕刻整块“大理石”。 而氛围编程（Vibe Coding）则完全是另一种思维模式。我不再是那个拿着凿子的雕塑家，而是变成了一个“意图设计师”。我的工作重心从编写具体的代码，转向定义清晰的意图和规范。举个例子，以前我需要写几十行代码来实现一个用户注册功能，现在可能只需要告诉AI：“创建一个安全的用户注册流程，需要邮箱验证，密码强度要求中等，防止机器人注册。”剩下的就让AI去组装实现了。 这种转变带来的影响是深远的。在米开朗基罗时代，代码就是我们的核心资产；而在氛围编程时代，意图描述、接口规范、安全策略这些“黄金契约”才是真正值得长期维护的财富。代码本身可能只是临时生成的一次性产物——今天生成，明天可能就被AI重新改写或替换了。 我特别喜欢Vibe Coding的一个原则：不手改代码。刚开始接触这个理念时，我也觉得不太适应。毕竟我们这代程序员都是摸着代码长大的。但仔细想想，这个原则背后有着深刻的逻辑——我们应该把提示词当作过去的代码，把代码当作过去的可执行文件。修改软件的正确方式应该是修改意图描述，而不是直接改动实现代码。 另一个让我兴奋的变化是“人人编程”的可能性。在传统开发模式下，非技术人员很难参与软件开发。但在氛围编程中，业务人员、管理人员甚至终端用户都能通过自然语言描述他们的需求，由AI来将其转化为可运行的软件。这不是降低了编程的门槛，而是重新定义了什么是编程。 当然，这种转变也带来了新的挑战。当代码可以随时被AI重写时，我们如何确保软件的质量？当每个人都能“编程”时，如何维护系统的安全性和稳定性？这正是专业开发者的新使命——从代码工匠转变为系统生态的治理者。 在我看来，从米开朗基罗编程到氛围编程的转变，就像是从手工业时代进入工业时代。我们不再需要亲手打造每个零件，而是要学会设计生产线和质量标准。这不仅是技术的进步，更是思维方式的革命。 那么，你准备好迎接这场编程范式的革命了吗？或许在不久的将来，我们回顾今天，会发现自己正站在软件开发历史的一个重要转折点上。