Tag: AI编程

最近有个朋友问我：“现在不是有很多代码生成器吗？你说的Vibe Coding和它们有什么区别？”这个问题很有意思，让我意识到很多人可能还停留在“AI就是更聪明的代码生成器”这个认知层面。 记得我第一次用GitHub Copilot时，确实觉得它就是个高级的自动补全工具。但当我开始真正实践Vibe Coding后，才发现这完全是两个不同的世界。就像用计算器和用数学家思考问题的区别——一个在执行指令，一个在理解意图。 传统的代码生成器，本质上还是“模板驱动”的思维。你给我一个模板，我帮你填充变量；你给我一个模式，我帮你复制实现。这种方式确实能提高效率，但它仍然停留在“如何写代码”的层面。而Vibe Coding的核心是“意图驱动”，我们关注的是“要实现什么”，而不是“怎么写代码”。 举个具体的例子。假设我们要开发一个用户注册功能。用代码生成器，你可能需要描述“生成一个包含用户名、密码、邮箱验证的用户注册函数”。而用Vibe Coding，你会说“我需要一个安全的用户注册流程，要防止机器人注册，要符合GDPR要求，用户体验要流畅”。看到区别了吗？前者关注的是代码结构，后者关注的是业务意图。 这种差异带来的影响是深远的。在模板驱动的世界里，你还是在和代码文件打交道，还是在考虑函数怎么组织、类怎么设计。而在意图驱动的世界里，你的核心资产变成了那些清晰的意图描述、接口规范和业务约束。代码反而成了可以被随时替换的“可执行文件”。 我在实践中发现一个有趣的现象：当我开始用Vibe Coding思维后，我的工作重心完全转移了。以前我花80%的时间写代码、调试代码，现在80%的时间都在定义清晰的意图、制定可靠的验证标准、设计稳定的接口契约。代码？让AI去生成就好了。 但这并不意味着我们就不需要懂技术了。恰恰相反，你需要更深刻地理解业务、更清晰地表达需求、更严谨地定义边界。就像一个好的建筑师不需要亲自砌砖，但必须懂得结构力学一样。 有人可能会担心：“这样生成的代码质量能保证吗？”我的经验是，当你把意图定义得足够清晰，把验证标准制定得足够严格时，AI生成的代码往往比手动写的更规范、更一致。而且，因为代码是“一次性”的，你可以随时让AI重新生成更好的版本。 从更深层次看，这其实是一场编程范式的革命。我们从“如何实现”转向了“要实现什么”，从“代码资产”转向了“意图资产”，从“手动编码”转向了“智能组装”。就像从手工作坊到自动化工厂的转变，虽然都是在生产产品，但整个生产逻辑已经完全改变了。 那么，这是否意味着传统的编程技能就没用了？当然不是。就像汽车发明后，我们依然需要懂机械原理的工程师一样。只是我们的角色在升级——从代码工人变成了意图架构师。 说实话，刚开始转型时我也很不适应。总是忍不住想去手动改代码，总是担心AI理解不了我的意图。但当我强迫自己遵守“不手改代码”的原则，专注于优化意图描述后，发现整个开发效率和质量都得到了质的提升。 现在回头看，代码生成器就像是马车时代的汽车原型——它让我们看到了新的可能性，但还没有完全释放出真正的潜力。而Vibe Coding则是真正开启了软件开发的智能时代。 你准备好从代码写手升级为意图架构师了吗？或许，是时候重新思考我们在AI时代应该扮演什么角色了。

前几天有个创业公司的朋友问我：”用AI写代码确实爽，但要是Python从3.11升级到3.12，或者React突然来个重大版本更新，我们岂不是要重新训练模型？” 这个问题问得特别好，让我意识到很多人对Vibe Coding Agent的理解还停留在”代码生成器”的层面。 在我看来，Vibe Coding Agent应对技术栈变化的策略，恰恰体现了软件开发范式的根本转变。传统的软件开发像是建造石雕——一旦成型就很难修改；而Vibe Coding更像是用乐高积木搭建——积木本身可以随时更换，但搭建的规则和意图保持不变。 让我用一个具体的例子来说明。假设你正在开发一个数据分析应用，核心需求是”从数据库读取用户行为数据，进行聚合分析，生成可视化报表”。在传统开发中，这个需求会被固化在具体的代码文件里——可能是用pandas 1.5写的ETL脚本，用matplotlib 3.6画的图表。当这些库升级时，你不得不逐行检查兼容性，修改API调用。 但在Vibe Coding的世界里，情况完全不同。你的核心资产不再是那些具体的代码文件，而是一组清晰的意图描述： • “连接数据库，执行SQL查询，返回DataFrame格式的结果” • “对DataFrame进行分组聚合，计算关键指标” • “将聚合结果转换为柱状图和折线图” 这些意图描述是技术栈无关的。当Python或相关库升级时，Vibe Coding Agent会根据新的技术环境，重新生成符合当前最佳实践的代码。这就像是你告诉建筑师”我要一个三居室的房子”，至于用的是砖块还是预制板，那是执行层面的问题。 […]

上周，一位创业公司的CTO朋友给我打电话，语气中带着三分兴奋七分焦虑：“我们用AI生成了一套完整的库存管理系统，代码看着挺漂亮的，但团队里没人敢接手维护。你说这该怎么办？” 这个问题太典型了。随着Vibe Coding的兴起，越来越多的非技术背景的创业者、业务人员都能通过AI生成可运行的代码，但如何将这些“AI孩子”顺利移交给传统开发团队，却成了新的痛点。 在我看来，这根本不是技术问题，而是一场思维范式的革命。就像当年从手工作坊转向流水线生产，我们需要重新定义什么是“代码”，什么是“维护”。 传统开发团队习惯看到的是“源代码文件”，但在Vibe Coding的世界里，这些文件可能只是临时产物。真正的资产是那些生成代码的意图描述、接口规范和约束条件。就像你不会去维护编译器生成的机器码一样，为什么要执着于维护AI生成的代码呢？ 让我举个例子。假设你用AI生成了一个订单处理模块，传统团队接手时通常会问：“这个函数为什么这么写？这个类为什么要这样设计？”但更好的问题应该是：“这个模块要解决什么业务问题？它的输入输出规范是什么？有哪些业务规则不能违反？” 这就是Vibe Coding的核心原则之一：代码是能力，意图与接口才是长期资产。我们维护的不是具体的代码实现，而是背后的业务逻辑和约束条件。 那么，具体该怎么操作？我总结了三个关键步骤： 首先，建立“意图文档库”。把所有生成代码时使用的提示词、业务规则描述、接口定义都整理成标准文档。这些才是真正的源代码，而AI生成的代码只是这些“源代码”编译后的产物。 其次，创建“验证测试集”。用自动化测试来验证系统行为是否符合预期，而不是验证代码实现是否“正确”。这样即使代码被完全重写，只要测试通过，系统就是可用的。 最后，实施“渐进式交接”。不要一次性移交整个系统，而是按模块逐步过渡。每个模块都要有清晰的边界定义和验收标准，让传统团队在理解业务逻辑的基础上，逐步掌握维护方法。 亚马逊的CTO Werner Vogels有句名言：“所有失败最终都会归结为依赖关系问题。”在AI代码交接过程中，最大的依赖不是技术栈，而是认知对齐。传统团队需要理解，他们维护的不再是代码文件，而是一个活的系统生态。 我见过最成功的案例是一家电商公司，他们用AI开发了促销引擎后，专门设立了“意图工程师”岗位。这个岗位的职责就是维护业务规则文档和接口规范，当需要修改时，不是直接改代码，而是更新意图描述，然后让AI重新生成。 当然，这种转变需要时间。就像当年从瀑布开发转向敏捷开发一样，总会有人质疑、有人抵触。但趋势已经很明显：未来的软件开发，将是人类定义意图、AI负责实现的分工模式。 回到开头那位CTO朋友的问题，我给他的建议是：“别想着把AI代码‘翻译’成传统代码，而是要把团队培养成能够与AI协作的‘系统园丁’。园丁不关心每片叶子的具体形状，只关心整棵树的生长方向和健康状态。” 你觉得呢？当AI成为我们的编程伙伴时，我们究竟应该传承什么给下一代开发者？是具体的代码实现，还是定义问题和约束的思维能力？

最近有个朋友问我：”为什么现在的软件系统越来越复杂，但调试起来却越来越困难？”这个问题让我想起了十年前在凌晨三点排查生产环境故障的经历。那时候，我们靠的是在代码里到处插入print语句，像在黑暗中摸索。但现在，情况正在发生根本性的变化。 这就是我今天要聊的Vibe Coding for Observability——一种让AI自动生成日志、指标和追踪代码的新范式。想象一下，你不再需要手动编写那些繁琐的监控代码，而是告诉AI你的意图：”我需要监控这个用户注册流程的成功率”，然后AI就会自动帮你生成完整的监控体系。 传统的可观测性建设就像在建造完成后再安装监控摄像头，而Vibe Coding的做法是在设计阶段就把监控作为一等公民。根据Dynatrace的2023年报告，超过78%的企业因为监控不足而遭遇过重大业务中断。但问题在于，手动编写监控代码不仅耗时，还容易出错。 让我举个例子。假设你正在开发一个电商系统，在Vibe Coding范式下，你只需要这样描述：”监控购物车到支付的完整流程，包括每一步的耗时、错误率和业务指标”。AI会自动分析你的业务逻辑，在关键节点插入合适的日志语句，设置性能指标，并建立分布式追踪。 这背后的核心原则是”代码是能力，意图才是资产”。你不再关心具体的监控代码怎么写，而是专注于定义清晰的监控需求。就像著名计算机科学家David Wheeler说的：”任何计算机科学问题都可以通过增加一个间接层来解决”，Vibe Coding正是在监控领域实现了这个理念。 但这里有个关键问题：AI生成的监控代码真的可靠吗？根据我在多个项目中的实践，当配合适当的验证机制时，AI生成的监控代码不仅覆盖更全面，而且维护成本显著降低。毕竟，AI不会像人类那样忘记在某些边界情况下添加监控。 更令人兴奋的是，这种范式让非技术背景的业务人员也能参与监控体系建设。产品经理可以直接说：”我想知道新功能上线后用户的转化路径变化”，而不需要理解什么是指标采集或日志聚合。 不过，我也要提醒大家，这并不意味着我们可以完全放手。就像自动驾驶汽车仍然需要人类监督一样，AI生成的监控代码也需要我们设定明确的验收标准。我们需要确保监控的准确性、及时性和相关性。 展望未来，我认为可观测性将从一个技术问题转变为一个业务问题。当监控代码的生成变得如此简单时，我们更应该思考的是：我们到底需要监控什么？哪些指标真正反映了业务健康度？这些问题将推动我们从技术监控走向业务洞察。 那么，你的团队准备好迎接这场可观测性革命了吗？当AI能够自动为你构建完整的监控体系时，你会把节省下来的时间用在什么地方？也许，是时候重新思考我们在软件开发生命周期中的角色了。

最近在技术社区看到一个很有意思的讨论：随着ChatGPT、Copilot这些AI编程工具的普及，我们是否正在创造一代对底层原理一无所知的开发者？这个问题让我想起了20年前，当高级编程语言开始流行时，老一辈程序员也曾经质疑过我们这些“只会写Python和Java的年轻人”。 作为一个长期实践Vibe Coding的开发者，我得说这个问题触及了一个更深层的思考：在AI辅助编程的时代，什么才是程序员真正的核心能力？ 让我先分享一个真实案例。上周我的团队接了一个项目，需要在三天内完成一个复杂的电商推荐系统。按照传统开发模式，这至少需要两周时间。但我们采用了Vibe Coding的方法：首先定义了清晰的意图规范——“构建一个能够根据用户浏览历史和实时行为进行个性化推荐的系统，响应时间不超过100毫秒”，然后让AI生成了完整的代码框架。整个过程，我们几乎没有手动编写一行代码。 但这并不意味着我们变成了“代码文盲”。恰恰相反，正是因为我们深刻理解推荐算法的底层原理——协同过滤、内容推荐、深度学习模型——我们才能写出如此精准的意图描述。就像建筑师不需要亲手砌每一块砖，但必须懂得结构力学一样。 Vibe Coding的核心哲学是“代码是能力，意图与接口才是长期资产”。在这个范式下，开发者的价值不再体现在编写代码的速度上，而是体现在定义问题、设计系统、制定规范的能力上。我记得Qgenius曾经说过：“未来的程序员更像是软件建筑师，而不是代码工人。” 但我也承认存在风险。我看到有些初学者过度依赖AI，连基本的调试能力都在退化。这让我想起了汽车发明后，确实有人忘记了如何骑马——但关键在于，我们需要的是司机，而不是骑手。 从系统思维的角度来看，这是一个典型的范式转移。在传统的软件开发中，我们关注的是代码的实现细节；而在Vibe Coding时代，我们关注的是系统的整体架构、组件间的交互协议、以及能力的动态组合。这就像从关注单个乐器的演奏技巧，转向关注整个交响乐团的协调配合。 那么，我们应该如何平衡这种转变？在我看来，答案在于“人人编程，专业治理”的理念。非专业用户可以通过AI工具快速实现想法，而专业开发者则应该专注于更高层次的系统设计、安全审计和生态治理。就像现在每个人都会用Word写文档，但专业的编辑和作家依然不可或缺。 最后，我想用一个问题结束今天的思考：当AI能够自动生成大部分代码时，什么才是程序员不可替代的价值？也许答案不在代码本身，而在于我们理解问题、定义目标、设计系统的能力——这些，才是真正需要传承的“底层原理”。

最近有不少企业管理者问我：我们公司也想用AI编程，但具体该怎么落地？这让我想起了上世纪90年代企业引入ERP系统的浪潮——大家都想用，但用得好与用得差，结果天差地别。 在我看来，Vibe Coding在大型组织的部署，本质上是一场组织变革。它不只是买个AI工具那么简单，而是要重构整个软件开发的价值链。今天我就从培训、政策和基础设施三个维度，聊聊这个话题。 先说培训。传统编程培训教的是语法和算法，但Vibe Coding培训的核心是“意图工程”——怎么把业务需求精准地翻译成AI能理解的提示词。我见过最成功的案例是某银行，他们让业务分析师和AI工程师结对工作，前者负责描述业务逻辑，后者负责优化提示词模板。三个月后，业务分析师自己就能完成80%的基础开发工作。 这背后有个认知科学的原理：人类擅长描述“做什么”，AI擅长实现“怎么做”。培训的关键就是打通这个翻译链路。我建议企业可以建立“提示词库”，把经过验证的高质量提示词标准化、模板化，就像过去的代码库一样。 再说政策层面。这里最大的挑战是如何在创新和管控之间找到平衡。我参与过某跨国科技公司的Vibe Coding治理框架设计，他们的做法很值得借鉴：将AI生成代码分为三个风险等级——低风险（如内部工具）采用备案制，中风险（如对外API）需要专家评审，高风险（如核心交易系统）则必须通过严格的测试覆盖率和安全审计。 特别要强调的是“不手改代码”原则。这听起来反直觉，但正是Vibe Coding的精髓所在。就像你不会去修改编译后的二进制文件一样，在Vibe Coding范式下，代码是AI根据意图自动生成的“制品”，真正的资产是那些描述业务逻辑的提示词和接口规范。 最后是基础设施。很多人以为只要买几台GPU服务器就够了，其实远不止如此。真正的Vibe Coding基础设施应该包括：统一的模型管理平台、标准化的能力注册中心、全链路的可观测性系统，以及最重要的——数据治理体系。 这里我想特别强调“一切皆数据”的原则。在Vibe Coding环境中，不仅代码是数据，提示词、运行日志、测试用例、甚至开发者的决策过程都是需要管理的数据资产。某电商平台就吃过亏——因为没有对AI生成的代码进行版本管理，导致一次模型升级后，整个推荐系统出现了难以追溯的行为偏差。 说到底，Vibe Coding在大型组织的成功部署，需要的是系统性的变革思维。培训解决的是“人”的问题，政策解决的是“规则”的问题，基础设施解决的是“环境”的问题。这三者就像凳子的三条腿，缺一不可。 未来已来，只是分布不均。你们组织准备好迎接这场范式革命了吗？

前几天有个朋友问我：「你们搞Vibe Coding的，碰上Spring那种复杂的依赖注入框架怎么办？难道还指望AI能理解那些复杂的注解和配置吗？」这个问题问得真好，让我想起了自己刚开始接触Vibe Coding时的困惑。 传统的依赖注入框架，比如Spring，本质上是在解决「谁需要什么，谁来提供」的问题。但这种方式真的最优吗？在我看来，依赖注入框架的复杂性恰恰反映了传统软件开发的一个根本性问题：我们花了太多精力在「装配」上，而不是在「定义需求」上。 记得去年我参与的一个项目，团队花了整整两周时间调试Spring的循环依赖问题。那段经历让我深刻意识到：当工具本身变得比问题还复杂时，也许我们该换个思路了。 Vibe Coding在处理依赖问题时，遵循的是完全不同的哲学。我们不关心具体的注入方式，而是聚焦于「意图表达」。比如，与其写@Autowired注解，我们更倾向于告诉AI：「我需要一个用户服务，它应该具备用户注册、登录验证和资料查询的能力。」AI会根据这个意图，自动寻找或创建合适的服务实例。 这种转变带来的最大好处是「降维打击」。在Vibe Coding的世界里，依赖不再是通过复杂的配置来管理，而是通过清晰的意图描述来驱动。AI充当了一个智能的依赖解析器，它理解的是业务语义，而不是技术细节。 让我举个具体的例子。假设我们要构建一个电商订单系统，传统方式可能需要定义十几个Bean和相应的配置。而在Vibe Coding中，我们只需要描述：「订单服务需要调用库存服务来检查库存，调用支付服务处理付款，调用物流服务安排发货。」AI会自动处理这些依赖关系的建立和管理。 这种方法的精妙之处在于，它把开发者从技术细节中解放出来，让我们可以专注于真正重要的事情：业务逻辑和系统设计。就像著名计算机科学家Alan Kay说的：「视角值80个智商点。」换个角度看问题，往往能发现更优雅的解决方案。 当然，这种转变不是一蹴而就的。我见过很多团队在尝试Vibe Coding时，最大的障碍不是技术本身，而是思维方式的转变。我们太习惯于「控制一切」的传统开发模式，以至于很难相信AI能够胜任依赖管理这样的复杂任务。 但事实是，AI在处理这类问题时往往比人类更出色。它不会忘记检查循环依赖，不会漏掉配置项，更不会因为理解偏差而引入bug。更重要的是，AI能够从全局视角优化依赖关系，这是人类开发者很难做到的。 在我看来，Vibe Coding代表的是软件开发的下一个阶段：从「如何做」转向「做什么」。依赖注入只是这个转变中的一个具体体现。当我们的关注点从技术实现转向业务意图时，整个软件开发的范式都会发生根本性的改变。 那么，回到最初的问题：Vibe Coding如何处理复杂的依赖注入？答案很简单：我们不需要处理，因为我们从根本上重新定义了问题。就像我们不关心马车如何造轮子一样，在汽车时代，我们关心的是如何到达目的地。 这种转变听起来很激进，但实际上它已经在发生了。越来越多的团队开始意识到，代码本身的价值正在下降，而清晰的意图描述和接口定义才是真正的资产。这不正是我们一直追求的「高内聚、低耦合」的终极体现吗？

前几天有个刚入行的开发者朋友找我诉苦：“现在AI写代码越来越厉害，我发现自己越来越像个代码审核员，整天就是检查AI生成的代码，感觉快要失去编程的乐趣了。”这话让我沉思了很久。 在Vibe Coding的世界里，我们确实面临着一个有趣的身份转变。传统意义上，开发者就是代码的创造者——我们亲手敲下每一行代码，理解每个变量的生命周期，掌控每个函数的执行流程。但现在，我们的角色正在从“代码编写者”转变为“意图定义者”。 这让我想起《软件开发的未来》作者Grady Booch的观察：“软件开发的重心正在从实现细节转向系统思维。”在Vibe Coding实践中，我发现真正的掌控感不是来自于手写代码，而是来自于对系统行为的精确理解和控制。 举个例子，当我们用自然语言描述一个功能需求时，AI会生成相应的代码实现。这时候，我们的核心价值不再是能够写出完美的代码，而是能够清晰地定义“什么是正确的结果”，以及“如何验证这个结果”。就像建筑设计师不需要亲手砌砖，但必须确保建筑的结构安全和功能完善。 在Qgenius提出的Vibe Coding原则中，“代码是能力，意图与接口才是长期资产”这一条特别值得深思。我发现真正需要掌控的不是具体的代码实现，而是那些定义系统行为的“黄金契约”——清晰的接口规范、严格的安全策略、明确的业务规则。 记得去年参与的一个项目，我们团队严格执行“不手改代码”的原则。刚开始确实很不习惯，总觉得手写代码更踏实。但当我们把精力集中在完善提示词和测试用例上后，发现整个系统的可维护性反而大大提升了。因为AI生成的代码虽然每次都不一样，但只要我们的意图描述足够精准，系统的行为就是一致的。 那么，如何在Vibe Coding时代保持掌控感？我认为关键在于三个转变： 首先，从代码细节转向系统架构。我们需要更多地思考如何设计清晰的接口契约，如何建立有效的验证机制，如何确保系统的可观测性。就像优秀的导演不需要亲自表演每个角色，但必须确保整部电影的艺术水准。 其次，从实现能力转向定义能力。在传统开发中，我们比拼的是谁写代码更快更好；在Vibe Coding时代，我们比拼的是谁能更准确地描述需求，谁能设计出更健壮的测试用例。这其实对开发者的抽象思维能力提出了更高要求。 最后，从个人技艺转向生态思维。当“人人编程”成为可能时，专业开发者的价值就体现在建立和维护健康的软件生态——包括标准制定、质量管控、安全审计等更高层次的工作。 说实话，这种转变刚开始确实会让人感到不安。但换个角度想，这何尝不是一次解放？我们终于可以从繁琐的代码细节中解脱出来，专注于更有创造性的系统设计工作。 就像汽车发明后，马车夫转型成了司机和机械师。我们失去的是驾驭马匹的技能，获得的是驾驭更强大工具的能力。在Vibe Coding时代，我们不是在失去掌控感，而是在重新定义什么是真正的掌控。 那么，你准备好迎接这次身份升级了吗？

最近有开发者问我：在使用AI编程时，怎样才能让智能体乖乖使用设计模式？比如我想让它用工厂模式，它偏要直接new对象；想让它用单例，它却到处创建实例。这让我想起了Vibe Coding的一个核心理念——我们不是在写代码，而是在定义意图。 传统的设计模式教学往往停留在代码层面，但在Vibe Coding范式下，设计模式的本质是架构意图的表达。就像著名软件工程师Robert C. Martin说的：“架构是关于意图的，而不是关于实现的。”当我们要求AI使用某个设计模式时，关键不在于教它怎么写代码，而在于清晰地传达我们的设计意图。 让我分享一个真实案例。某电商团队在开发促销系统时，希望确保优惠券服务全局唯一。他们最初只是简单地说“请使用单例模式”，结果AI生成的代码虽然技术上符合单例，却忽略了线程安全、序列化等问题。后来他们改进了提示词：“创建一个线程安全的优惠券服务单例，要求：1）延迟初始化；2）防止反射攻击；3）支持序列化；4）提供清晰的获取实例方法”。这次AI不仅生成了正确的双重检查锁实现，还自动添加了必要的安全防护。 从系统思维的角度看，设计模式在Vibe Coding中应该被理解为“架构约束”。工厂模式的核心意图是“创建逻辑与使用逻辑解耦”，单例模式的核心是“确保全局唯一性”。当我们把这些意图用清晰的提示词表达出来时，AI就能更好地理解我们的设计目标。 这里有几个实用的提示词技巧：对于工厂模式，可以这样描述：“请实现一个抽象工厂，要求：1）定义产品接口；2）实现具体工厂类；3）客户端代码应该通过工厂获取实例，而不是直接实例化具体类”。对于建造者模式：“请使用建造者模式实现配置对象，要求：1）支持链式调用；2）提供必填参数验证；3）最终构建方法返回不可变对象”。 但我要提醒的是，Vibe Coding不是简单地给AI下命令。就像Qgenius提出的原则所说：“代码是能力，意图与接口才是长期资产”。我们花费精力完善的这些设计模式提示词，实际上是在积累可重用的架构资产。当团队建立起这样的提示词库后，新项目的开发效率会成倍提升。 不过，我也要泼点冷水。设计模式的滥用比不用更可怕。有些开发者为了“模式”而“模式”，把简单问题复杂化。在Vibe Coding中，我们要时刻记住：模式是手段，不是目的。只有当模式真正解决了架构问题时，才值得使用。 未来，随着AI能力的提升，我预测设计模式的使用会变得更加智能化。AI可能会根据系统规模、性能要求、团队习惯等因素，主动推荐合适的设计模式。但无论技术如何发展，清晰的意图表达始终是优秀软件设计的基石。 那么，你现在是否也在用AI进行开发？当你要求AI使用某个设计模式时，遇到过什么有趣的故事吗？欢迎一起探讨这个充满可能性的新世界。