渐进式 AI 编程

上周六腾讯内部组织了一个线下培训，叫做

渐进式 AI 编程 Workshop

今天和大家聊一聊我学到了啥。

现在相信大部分小伙伴都会在开发中引入 AI 工具来辅助开发，无论是 cc 还是一些国产工具，松哥也有在用这样一些工具，我经常会想，其他人是咋用 AI 工具的，跟我一样吗？他们会不会还掌握了其他的 AI 编程工具使用窍门？这些疑惑会促使我去参加一些 AI 相关的技术分享，我很想知道别人是咋用 AI 工具的，这也是本次参加腾讯线下活动的缘由。

腾讯的这次培训主要是利用腾讯自己的 CodeBuddy 工具，在不写一行代码的情况下，仅仅通过提示词，带领大家一起开发一个外卖网站，这个网站要支持下单、有客户端、有商家端。

给大家看下松哥最后做出来的效果：

这场培训最直观的感受：

AI 让“从 idea 到可运行产品”的链路被大幅缩短了。以前脑子里冒出一个产品想法，从梳理需求、设计架构，到敲写代码、调试功能，光是前期准备就要耗上不少时间，更别说从零搭建一个外卖平台的 PC Web 端。但借助 CodeBuddy 的 Plan Mode 做规划、用 Hooks 做自动化校验，再配合 MCP 连接和 Subagents 分工，一个包含餐厅浏览、购物车下单、订单追踪的外卖平台雏形，能通过分阶段实战快速落地。AI 能接手重复性的编码工作，把我们从机械的代码书写中解放出来，让我们把注意力集中在需求拆解、架构设计这些高价值的决策上。就像培训里说的，把“垃圾先做出来”，先实现核心功能再迭代优化，这一点对创业项目、内部原型验证太重要了——AI 让我们不用再为基础开发耗费过多精力，能最快验证想法的可行性，这是 AI 编程最亮眼的价值。

目前来说，AI 写代码是没啥稀奇的，但是让 AI 创建一个符合团队开发规约、满足质量保证的产品还是有一些挑战。而 CodeBuddy 就在做这样的事情。

CodeBuddy 不是单点的 AI 工具，而是通过 CODEBUDDY.md 给 AI 植入项目上下文，让它理解团队规范和架构决策；用 ESLint+Hooks 做自动化质量门禁，让 AI 生成的代码符合团队标准；靠 OpenSpec 实现规约驱动开发，把产品、开发和 AI 的认知对齐，避免多轮对话后的上下文漂移，让变更可追踪、协作更有序；甚至通过 Skills 把个人和团队的经验封装成可复用的能力包，让 AI 从“通用助手”变成贴合业务的“专家”。我也是第一次看到 AI 做了很多 Coding 之外的事情，AI 编程的核心不是“让 AI 写代码”，而是“让 AI 融入研发工作流”，它能做代码生成，也能做质量检验、流程管理、经验沉淀，成为开发全流程的协作伙伴。

但是回到松哥目前实际项目的场景中，还是能清晰感受到 AI 编程目前的局限，这些局限不是技术本身的问题，而是企业项目的特性与 AI 工具现阶段能力的适配问题。

首先，企业级项目讲究“严谨性”，远非原型验证的“快速落地”可比。培训中说“先做垃圾再重构”，在原型开发中完全可行，但企业核心业务项目，尤其是金融、政务这类对稳定性要求极高的行业，根本没有“做垃圾”的空间。AI 生成的代码虽然能一次跑通，但在高并发、高可用、数据安全等方面的考虑往往不够周全，后续人工精调的成本可能超出预期；而且 AI 不擅长拆分函数、拆分文件，生成的代码对人类阅读和维护不友好，企业项目动辄数年的维护周期，要求代码具备极强的可读性和扩展性，这一点上 AI 还需要人工大量介入。

其次，企业项目的“协作复杂性”，让 AI 的团队协作能力还需打磨。培训中介绍的 AgentTeams、Subagents 能实现多 AI 的分工协作，但实际企业项目中，不仅是开发人员之间的协作，还有产品、测试、运维、业务方的多方联动，需求会不断变更，边界会不断调整，很多决策需要人类基于业务经验做判断。就像培训里说的，业务对齐、架构设计这类宏观问题的 Review，终究需要人类把关，AI 只能作为辅助。而且企业项目中大量的私有代码、内部业务逻辑，即便有 CodeWiki 和记忆系统，AI 也很难完全理解，难免会出现“幻觉”，生成不符合业务实际的代码，这在企业项目中是不可接受的。

再者，企业项目的“标准化与合规性”要求，让 AI 编程的落地多了一层约束。金融、政务等行业的项目，不仅要符合代码规范，还要满足行业合规、数据隐私、安全审计等要求。AI 生成的代码可能在语法上没问题，但在安全漏洞、权限控制、数据加密等方面的考虑往往不够细致，需要人工进行全面的安全审查；而且企业项目的开发流程有严格的审批、测试、上线规范，AI 编程的自动化流程如何融入企业现有的 DevOps 体系，如何保证 AI 生成的代码可追溯、可审计，这些都是实际落地中需要解决的问题，不是单纯掌握 AI 工具就能实现的。

还有一点很现实，就是企业团队的“适配成本”。AI 编程需要开发者转变思维，从“自己写代码”变成“教 AI 写代码、审 AI 代码”，这对开发者的要求其实更高了——需要更精准的需求描述、更清晰的架构设计、更专业的代码评审能力。培训中的讲师是深耕技术架构的专家，能精准把控 AI 的输出，但企业中不同层级的开发者能力参差不齐，要让整个团队都掌握 AI 编程的方法论，形成体系化的工作流，需要一定的培训和磨合成本。而且企业现有的技术栈、开发规范已经成型，要把 CodeBuddy、MCP、OpenSpec 这些工具融入现有体系，而不是推翻重来，这也是实际落地中需要权衡的问题。

当然，这些局限并不是说 AI 编程不适合企业项目，而是说 AI 编程目前在企业中的应用，还处于“辅助增效”的阶段，而非“完全替代”。培训中有一句话说得特别好：“根据自己业务的实际情况，选择适合自己的工具和方法，不建议盲目追求最新最潮的工具，重要的是形成体系化的工作。”这正是 AI 编程落地企业的核心思路——不照搬培训中的所有玩法，而是结合企业的业务特性、技术栈、团队能力，做适配和取舍。比如，用 AI 做原型开发、需求验证，快速落地 idea；用 AI 接手重复的 CURD 开发、单元测试编写，提升开发效率；用 OpenSpec 实现产品和开发的认知对齐，减少协作成本；用 Skills 和记忆系统沉淀团队经验，让 AI 成为团队的“知识宝库”。把 AI 用在合适的场景，让它成为开发者的“左膀右臂”，而不是强求 AI 包揽所有工作，这才是企业落地 AI 编程的理性选择。

这场培训让我看到了 AI 编程的未来，也让我对 AI 与开发者的关系有了更清晰的认知。未来的开发者，不再是单纯的“代码书写者”，而是“AI 协作管理者”——要懂业务、懂架构、懂需求，能精准向 AI 下达指令，能高效评审 AI 的输出，能把个人和团队的经验沉淀成体系，让 AI 的价值最大化。AI 的输出上限，终究是开发者的认知边界，你的描述有多精准、思考有多深刻，AI 的输出就有多贴合实际。而 AI 编程的核心，从来都是“人”，AI 只是工具，是让我们把能力放大、把效率提升的工具。

从快速落地 idea 到平稳落地企业项目，AI 编程还有一段路要走，但这段路不是“摸着石头过河”，而是像这场培训一样，先掌握工具、再构建体系、最后结合实际做适配。作为开发者，我们既要拥抱 AI 带来的变化，主动学习和尝试 AI 编程的方法论，也要保持理性，不盲目神化 AI，也不低估 AI 的价值。让 AI 成为研发工作流中不可或缺的一部分，让我们在创意落地时更高效，在企业开发时更严谨，这大概就是 AI 编程最美好的样子。