AI Coding大有可为，但Vibe Coding还是先洗洗睡吧

在正文开始之前，先说一个结论：AI Coding 和 Vibe Coding 不是一回事。AI Coding 大有可为，但 Vibe Coding 劝你先冷静。前者面向专业开发者，后者面向非专业开发者。

近期，有非常多所谓 “ Vibe Coding 奇迹 ” 出现。

不论是曾经的 AI 怀疑论者、Rust 大牛 Steve Klabnik 用 AI 写出新的编程语言 Rue，还是对 AI 敌意颇大、曾嘲讽 “ AI 编程是垃圾 ” 的 Linux 发明者 Linus Torvalds 亲自下场 Vibe Coding。甚至近期有不少 Vibe Coding 出来的 ToC App 或网页游戏一夜爆火，被切中痛点的用户还相当愿意买单。

AI 编程产品王者 Claude Code 也频创神话，比如 1 小时复现 Gemini API 负责人 Jaana Dogan 的团队花费一年构思的分布式 Agent 编排器，10 天复刻 “ Manus ” 也就是 Cowork 。

Redis 作者 Antirez 近期坦言道，大部分项目不再需要写代码了，除非是为了兴趣或好玩。

随着 Anthropic 等厂商不断完善编程工具套件，比如 Code Simplifier 等，代码编写阶段的难度也将变得越来越低。

越来越强大的 AI 编程工具甚至让曾提供原始养料即 “ 代码数据 ” 的厂商变得越来越难过，比如让 Stack Overflow 流量 “ 一夜回到刚发布 ”，比如 AI 让 TailWind 使用量越来越大，却让发明者本人 Adam Wathan 的公司越来越难赚钱，被迫大幅裁员。

但实际上，大部分人关注到表面的喧嚣，而没有关注到一个极其重要的点——代码复杂度。

那些复杂度很高的 Vibe Coding 产品，背后都有专业的工程师兜底和指引。那些复杂度很低又很火的 Vibe Coding 产品，几乎秒被抄袭，且存在大量缺陷，比如可维护性、可扩展性、安全风险等。

专业程序员也都会时刻强调，写代码一直是开发中最不重要的一步，决定代码质量上限的是 AI 尚不具备的深层业务理解和复杂架构设计能力。

甚至近期 Cursor 让 GPT-5.2 连续运行 7 天写出的数百万行代码的 Chrome 项目，最终被社区发现只是无法运行、无法修复、无法复现的 “ AI 泔水 ”，连被称为 “ 屎山代码 ” 的资格都没有，体现出复杂度提升给 AI 带来的压力。

确实当下 AI 能验证可行的场景并不多，编程场景整体已经算乐观的了。Replit CEO Amjad Masad 前一阵子还坦言，现在真正能赚钱的 Agent 只有两类，一类是 AI 客服，另一类是 AI 编程。

所以 AI 编程为何可行，天花板又在哪里？AI Coding 和 Vibe Coding 可行性判断的底层逻辑是什么？为解答这些问题，知危与多名业内专家进行了交流。

整体来看，专家们对 AI Coding 保持乐观，对 Vibe Coding 的当下表示质疑。但专家们没有否定 Vibe Coding 这个目标的长期合理性，只是我们需要清楚，Vibe Coding 目前只是资本市场的 “ AGI 愿景 ” 下的产物，和 “ 通用 Agent ” 概念一样，有被过度炒作的风险。

认清现状，并解答如何以更理性的方式逐步达到 “ Vibe Coding ” 这个理想的结局，才是本次探讨的目标。这不仅适用于 Coding Agent 产品创业者和软件产品创业者，也适用于当下最焦虑的程序员。

本文有以下 9 个章节，您可按需观看：

• 什么是 AI Coding 和 Vibe Coding？
• 对 AI Coding 乐观的本质
• 对 Vibe Coding 悲观的本质
• 国内外差距依然存在
• 关键落地场景：旧代码重构
• 对传统 SaaS 市场的冲击
• AI Coding 对程序员的影响
• 与 AI 协作之道
• 展望未来

在正式进入讨论前，还是要先把概念彻底理清楚。

平安保险技术平台组负责人张森森对知危表示，“从概念上来说，AI Coding 就是开发者利用大模型语言辅助开发软件，主要涵盖：代码编写、代码调试、代码重构、测试过程等，目前最典型的工具其实还是 GitHub Copilot。” “这其中最重要的是，整个开发流程基本上还是由系统的架构师和负责人主导。AI 扮演的角色，如果按照敏捷研发的角度，更多是一个 ‘ 角色程序员 ’。AI Coding 的核心工作目标，还是针对工程效率的提升。” “到了 Vibe Coding 这个层面，有了新的变化。过去是人去适应代码，但 Vibe Coding 提倡的是 ‘ 拥抱这种指数级增长 ’，甚至可以完全忘记代码的存在。它的基本逻辑是：程序员要适应这种 ‘ Vibe（ 氛围 ）’，通过感性和直觉去驱动开发。在这个模式下，用户大部分是非专业开发者，当然不能简单地称之为 ‘ 小白 ’，他们更多是业务人员、产品经理或非技术背景的从业者在承担开发角色。”

“Vibe Coding 重点强调通过 ‘ 自然语言描述意图 ’ 来完成开发，让 AI 实现端到端的代码生成，比如从理解需求到 UI 设计，从前端代码生成到后端数据库连接，甚至包括最后的部署工作。”

可以理解为，知危与各位专家在本文中定义的 “ AI Coding ” 和 2 月 5 日 Andrej Karpathy 回顾 Vibe Coding 一周年时提到的Agentic Engineering意思相近。

在 GitMe.ai 联合创始人王威看来，以Claude Code、Cursor等产品为代表的AI Coding方向，并不存在泡沫，他向知危表示：“ 原因是，业界对于未来 AI 的发展、AI 技术加持下的软件交付和研发最终形态仍然没有达成共识。”

“ 同时，虽然目前 AI 的迭代速度可能没有 2022、2023 年那么快，但在 AI 编程赛道里，迭代速度仍然比较快。无论是 OpenAI、Anthropic 还是 Anysphere（ Cursor 所属公司 ），每个月至少会有一两个对市场有吸引力或者冲击力的产品发布。”

“ 既然技术还在持续迭代，意味着用户体验仍然不稳定，也就是说用户在 AI 上的工作流程还没有共识，还需要探索。探索阶段没有泡沫。”

“ 如果资本都注意到这个赛道，都愿意投资，可能会让赛道略微喧嚣，这是难免的。”

“倒退五年，当时对于软件工程，大家的共识是 ‘ DevOps 一定是行业未来 ’，而且 DevOps 是可以讲清楚的：从组织协作到 CI/CD 流水线，再到具体工程实践，都有体系化描述。而今天 AI Coding 没有这样的体系化描述，因此我不认为市场需求远小于创业公司和资本的投入，整个市场空间仍然很大。”

相对地，对于以 Lovable、Bolt.New 等产品为代表的主打 ‘ 一句话生成可用网站 ’ 的 Vibe Coding 方向，张森森并不看好，“Vibe Coding 的端到端特性，说明它更多想通过略过技术层，提升创新速度，加速从想法到成品的转化。所以Vibe Coding 其实真正在推动的是全民研发，这是国外非常常见的概念，即让非专业背景的人也能参与研发。”

“ 但是 Vibe Coding 在实践中存在一个核心问题，它完全依赖自然语言驱动，并且是端到端生成的，这必然导致中间的很多生成环节具有高度的不可确定性。一旦程序复杂度一上去，且需要长期维护，这种模式的弊端就会显现。”

“用户无法对系统进行非常确定性的校验或掌控，系统非常脆弱，充满各种漏洞，从而不可维护。所以我不是特别看好 Vibe Coding 方向，这类软件本质上就是即用即弃的一次性软件。” 创新偏好和产出即用即弃的特点，分别表明了 Vibe Coding 产品的需求刚性和用户持续付费意愿都是存疑的。

在效率提升方面，AI Coding 的使用体验确实是惊人的，王威分享了很具体的例子，“最惊艳的点是它能够完成新项目的快速启动。原来新项目的快速启动是很耗时的。比如我们过去做一个可交互原型需要一个四人团队两周的时间，相当于 40 人天，成本是很高的。”

“ 现在情况完全不同，AI 工具的月费可能只有 10 美金、20 美金，可能只需要花 5 分钟甚至更少时间就能完成这个工作。提升如此明显，以至于我们都认为这已经不能称为效率提升，而是完全颠覆了原来的工作方式。这意味着我们对人、流程、组织都需要重新做反复的思考。”

比如在人和流程这些方面，AI 编程对于促进团队协作也能提供帮助，OneHouse Hudi Flink 负责人陈玉兆向知危表示，“ 比如代码分析这一块，尤其是对于新手或刚入行的应届生。如果是过去，面对复杂项目时，需要一行行跟新同学解释代码是干嘛的，其实挺花时间的。如果现在有 AI 的帮忙，能让新同学快速融入团队，并且对代码有更深入的了解。”

“ 另外，在编程过程中，像 Cursor 有代码提示功能，可以让团队保持比较固定的代码风格。如果不断告诉它团队趋向于用什么样的风格，那么代码风格层面也会更加统一。”

“ 最后，在测试这一块，现在 AI 写测试的能力挺强的。Cursor 和 Claude Code 在这方面已经比较成熟。复杂的端到端可能比较难，但是对于基础类的、带 Mock 上下文的那种单元测试，是没有问题的。我们甚至还在用国内阿里的通义千问来生成测试集，只需要简单改一下，基本上就可以直接去提 PR 了。”

“ 单元测试的代码生成确实能节省很多 ‘ 苦活、脏活、累活 ’ 的时间，让大家用来干别的事情。原来那种单元测试，要么是有同学懒得写，要么是写得不够充分。现在有了 AI 工具，大家下意识地都会先用 AI 生成一遍，所以测试内容写得更加丰富。”

Claude Code 曾经分享过 13 个使用技巧，其中之一是 “ 给 Claude 一种验证工作的方式，最终结果质量能提升 2-3 倍。” 现在这个质量提升机制甚至能由模型自己完成，效率提升幅度也很大，“ 在写测试这一块，大概帮我们节省了 30% 到 40% 左右的时间。”

专业的软件开发不会满足于完成一个可行的原型或较为简单的测试场景，最终的目的是将原型重构为企业级、生产级代码，AI Coding 在这一块也展现出了很强的执行水平和协同能力。

陈玉兆表示，“ 代码重构主要是为了提升可用性和扩展性（ 比如当用户从 10 万增长到 100 万，需要相应提升系统容量 ）而进行的重构。Claude Code确实比较擅长代码重构。但要做好这一步，需要一个非常好的输入和交互过程。”

“ 比如需要提供团队积累了十几年的代码风格偏好，再给予足够的上下文参考后，它会很好地帮你进行重构。但这个过程必须经过 Review。比如它会在 GitHub 上提 PR，由你来 Review，这样 Review 的粒度就会很细致。对每一个 PR，只有当你告诉它 ‘ OK，可以合并 ’ 时，它才会执行，而不是无脑地直接把整个代码库全部替换掉，是一个受控的过程。它相当于是一个程序员在和你沟通、协作。” “ 甚至你可以尝试让AI先写一些样例代码，然后告诉它哪里符合预期、哪里不符合预期。”

“ 通过这种不断的沟通和调整过程来积累上下文，可以逐渐地调教AI到你想要的样子。如果调教得比较好，除了代码分析之外，代码重构应该是 Claude Code 非常突出的一个能力。”

作为专业的开发者，能非常清晰感受到 AI Coding 过程中，AI 模型本身的上限，比如单次独立执行任务的复杂度上限，对新增功能的理解能力，以及更广义上的 Context 理解能力，这些感知也是开发者把控何时接手、如何接手的标尺。

比如在代码重构场景下，通常涉及的项目规模会很庞大，那么AI模型目前的单次独立执行复杂度上限是什么？

陈玉兆表示，“ 复杂度不能按整个仓库的代码行数来评估，重构应该是按功能模块为单位的。即使项目有 100 万行，也可以切分成 10 个 10 万行的模块，甚至更细。项目越大，代码文件间的引用和依赖关系就越像树状或图状，AI 工具会自行分析重构功能覆盖了哪些类及其复杂度。”

“AI 最擅长的重构场景包括：基础逻辑转换，比如重命名、代码风格变换；跨语言重构，比如从 Java 切换到 Python，或者从 Scala 切换到 Java，这种逻辑对等的跨语言实现是 AI 最擅长的事情；还有一种技巧是渐进式重构，可以先尝试让它重构一个文件，通过 ‘ 调教 ’ 让它符合预期，再让它按同样的方式处理剩下的文件。”

“ 只要 Scope（ 作用域 ）足够小，逻辑没那么复杂，但需要投入大量精力去手动处理的事情，AI 表现得非常出色，能节省很多时间。”

“AI 难以处理的重构场景包括：高耦合核心逻辑，比如存储引擎的内核代码，逻辑千丝万缕，‘ 剪不断理还乱 ’；带大量 ‘ 补丁 ’ 的边缘场景，如果核心功能上下游依赖非常多，且有很多历史遗留的边缘 Case，打了很多补丁，重构时必须非常仔细地 Review，小心这些补丁被 AI 忽略或重构掉。”

“ 如果要更加精确、量化地描述，从模块间依赖角度，比如覆盖了四五十个模块、两百多个文件的这种代码规模，尤其如果逻辑本身非常复杂，边边角角的逻辑又多，这种重构就很难了，还是需要人来主导完成。”

基于金融业务场景，张森森提供了另一个层面的描述，“关于代码复杂度的量化，可以根据项目的规模和业务深度来看 AI 的胜任可能性。Demo 级别基本上所有的 AI 都能胜任，成功率可以达到 95% - 99%。中型/独立项目（ 如企业内部小工具 ）AI 的表现依然不错，胜任率大概在 70% - 80% 左右。复杂业务系统（ 如涉及微服务、支付、鉴权、高并发系统 ），这种情况下，AI 基本上只能做一些代码补全。指望它通过理解来帮你完成代码生成是不太现实的，胜任率最高可能只有 40% - 50% 。极高复杂度场景（ 如银行系统重构 ），这种系统的代码非常脆弱，任何微小的改动都可能引发无法接受的后果，重构需要 ‘ 手术刀式 ’ 的精细化操作，AI 的胜任率非常低，估计最多只有 20%。”

相对于代码重构主要面向旧代码的处理，新增功能则需要添加大量新的业务逻辑。

陈玉兆明确表示，“ AI并不擅长开发新功能。我们开发新功能都没有用过 AI。”

“ 因为开发新功能的逻辑更加复杂。作为高级工程师或资深工程师，我们都要耗费很长时间。首先是立项一个 Idea，然后大家出初始方案，进行一轮轮的讨论。我们需要权衡 A、B、C 好几种方案，分析每种方案的优势和缺点。最后拍板决定选哪种方案，定下基本的架构框架和接口（ API ）长什么样子。写代码只是最后一步。这么复杂的决策和设计过程， AI 是 Cover 不了的。”

“ 它无法完成这个过程，因为需要的上下文不仅多，也很难从工程师思维中显式地提取。决策的过程非常复杂，高度依赖工程师本身的技术敏感度和经验，比如在进行技术选型时，工程师会有很多的权衡，AI 目前还没有办法完全像人一样去思考，也不具备人类那种长年累月积累的经验和敏感性。”

即便隐性上下文能提取出来，如果规模太大，目前的模型大概率也承载不下，张森森表示，“ Cursor 目前采用 RAG 来缓解这个问题，但业内其实还没有针对长上下文完全完美的解决方案。虽然像 Gemini 这样的模型正在尝试通过不断扩大上下文长度来解决，但长度终归是有上限的。在早期，Cursor 的对话进行到 10 轮左右，逻辑就开始出现偏差，目前国内大部分 AI 编程软件基本也处于这个水平。”

“ 不过，随着 Claude 或 Gemini 的长上下文能力的提升，这个问题正在逐步改善。未来，我们只能期盼大模型技术对 Token 容量支持的进一步发展，从底层技术层面来彻底解决细节遗忘的问题。”

Vibe Coding 的产出基本都是一次性软件，但也不代表这个方向的所有产品都一无是处，其中 Lovable 是比较受到认可的。

张森森表示，“ Lovable 相比 Cursor 有一些创新，比如它能实时地把业务界面跑给用户看，让用户看到即时的效果。生成完成后，用户还可以用 UI 交互的方式直接在界面上进行框选，指出具体的问题在哪里，并直接教 AI 怎么去修改。”

尽管有这些亮点，但 Lovable 也避免不了 Vibe Coding 天生的问题，“ 它的代码维护性极差，基本上产生的都是 ‘ 屎山代码 ’。比如到第十轮生成时，把第一轮的一个底层逻辑搞坏了，之后就根本无法进行有效的 Debug。”

“ 在产品开发上，普通的 Dashboard 落地确实非常快，一旦涉及到复杂算力、高并发处理、特殊硬件交互，或者是非常精细的动画逻辑，Web 开发就显得很吃力。对于具有复杂跳转和状态关联的逻辑（ 例如：从点 A 跳到 B、C、D，且 D 与 A 之间存在逻辑闭环，需保证特定状态同步 ），目前市面上没有一个产品做得好。”

“ 虽然 Claude 算是不错的，Gemini 最近的前端表现也让人感到 Surprise。但如果要处理复杂的工程项目，指望用 Vibe Coding 来搞简直是天方夜谭。”

“ 所以 Lovable 再优秀，做的也仍然是一次性工程的生成。”

尽管 Vibe Coding 有如此大的限制，但类似产品依然层出不穷，更广义来看，“ 一句话生成 ” 或 “ 端到端 ” 的 AI 产品频繁在社交媒体上爆火、号称数千万甚至上亿美元估值，这背后的底层逻辑是什么？

张森森表示，“ 对于 Vibe Coding 的应用边界，我的建议非常明确：如果一定要用 Lovable 去做一个复杂的项目，我建议立即 ‘ 停手 ’。”

“ 但资本市场的思考逻辑完全不同。资本市场看重的是 ‘ 端到端 ’ 的愿景。在投资者眼中，这是未来必须发展的方向。就像现在大家谈论大模型时，已经不再只谈论模型本身，而是直接指向 AGI。资本市场对 AI 的热望已经上升到了全新的层面，投资逻辑早已超越了简单的代码补全，到了让 ‘ 具身智能 ’ 满世界飞、满世界跑的层面了。”

“ 所以，从资本角度来看，Lovable（ 或同类 Vibe Coding 产品 ）的逻辑是一定成立的，这代表了未来。”

“ 但它能不能活到资本实现宏大目标的那一天，全看它自己的造化。”

“ 相比之下，Cursor、Windsurf 以及一些新兴的集成开发工具（ 如 Google Antigrativity ），生存逻辑就很务实，他们也认同 Lovable 的端到端逻辑是长远趋势，但为了 ‘ 当下能活下去 ’，为了适配现有的技术实践，他们选择了超级编辑器这种模式。”

“ 在专业工程师眼里，那些 Vibe Coding 产品东西更像是个玩具，但资本愿意买账。”

“因此，我预计 Cursor 目前的营收能力一定会远强于 Lovable。Cursor 面向的是实实在在的开发者，是在为能创造价值的生产力过程做增值。 Lovable 这类产品的逻辑完全不同，它主要收割资本、股民、想走捷径的小白用户。”

“ 当然，在这场资本游戏中，投资人也不一定会是 ‘ 倒霉 ’ 的那一个，关键看谁在玩这出‘击鼓传花’的游戏。投资人可能也根本不在乎这个事（ 产品能不能最终落地 ），他们只要是第一个把这个故事推出来、讲得很明白的人就行。只要确保自己不是最后一个接棒的人，他们就能在泡沫破裂前成功套现退出。”

“和创业者一样，投资人也在赌，赌自己投的方向能够随着技术的快速迭代，最终把那些现在听起来不可思议甚至是纯粹 ‘ 做梦 ’ 的故事，转化为真实的生产力。”

“ 而之所以这个游戏能玩下去，也是因为现在 AI 技术发展的速度确实已经基本上超过了想象。”

在理清 AI Coding 和 Vibe Coding 在工程和资本层面的本质之后，也要了解到，当前国内外 AI Coding 的差距仍然客观存在。

某大型金融科技公司 AI 技术专家李楠（ 化名 ）向知危表示，“目前国内大厂的 Coding Agent 产品整体表现都不太行，大家都在努力做一个国外产品的 ‘ 平替 ’。比如做 Claude Code 或 Cursor 的国内替代版本。”

“目前还没有看到哪家公司能真正从行业逻辑或者从编程范式发展的深度，提出比较有创新性的见解。当然这跟底层模型的理解与能力有直接关系。”

“ 国内 AI 编程模型虽然跑分上表现得很好，随时跑到 SOTA 水平，但其实有一个限制使得最后要达到天花板是非常吃力的，因为大部分国产大模型公司十之有九做的都是蒸馏模型，他们自己有没有能力去做训练数据呢？其实很困难。”

“困难不在于技术，大模型在技术上是没有秘密的，而在于硬件的匮乏，工程整合能力可能稍微弱一些，以及训练数据没有国外丰富。我们虽然也有码云这样的平台做代码管理和存储，但里面高质量的代码还是非常少的，比不上 GitHub。”

近年来，国内大厂也纷纷推出自己的 AI Coding 产品，产品结构和 Cursor 等 AI IDE 都是类似的，面向全球市场，可以使用国内外的开源、闭源大模型，“ 国内大厂纷纷发力 AI Coding 海外版产品，背后的逻辑非常现实：付费意愿。海外用户（ 尤其是欧美市场 ）已经培养了良好的 SaaS 付费习惯，出海是实现商业变现的 ‘ 捷径 ’。更何况，在海外市场，这些产品可以无缝套用 GPT-5 或Gemini 等国际顶尖模型。”

“我亲自试用了国内某大厂的 AI Coding 产品，整体评价是 ‘ 还行 ’。目前该产品还处于免费阶段，即便要订阅也比 Cursor 更便宜。我在其海外版官方 Discord 社区观察到，外国人的使用者非常多，很多外国人也不想花钱订阅 Cursor。”

“ 即便调用的模型是一样的，从结果来看，至少我用 Cursor 写的代码，质量会比这个产品高非常多。虽然它被视为 Cursor 的免费平替，但两者的差距非常明显。”

“ 具体而言，Cursor 比较厉害的点在于它更倾向于对研发行为的预测，它通过阅读代码，能大概预知你下一步要做什么。而这个产品更像是 Lovable 和 Cursor 的中间态，两者在上下文管理上的差距很明显。Cursor 的索引管理技术非常成熟，加上基于 RAG 的代码库检索，能让开发者遵循一定的 I/O 行为规则，使得它在处理超大型规模代码时，速度快很多。相比之下，这个产品目前在处理超大项目时不如 Cursor 快。”

“ 总体来看，这个产品还是更倾向于全自动、端到端地完成所有任务，实际上更接近 Lovable 的定位。甚至可以说，国内大厂的 AI Coding 产品，本质上也是在面向未来的资本方收割市场，偏向 Vibe Coding，而不是 AI Coding。”

“但其实最终绕不开的，还是数据安全问题。这虽然是全球性的问题，比如 Cursor 在应用内直接提供了隐私选项，可以保证代码不存储在云端，也不作为训练数据。而国内的情况有所不同。”

“ 为什么国内公司不太愿意把编程工具换成国内大厂的 AI Coding 产品？这不仅仅是技术问题，更是更复杂的商业考量，即担心自己的代码泄漏或被这些编程产品厂商获取。”

“很多公司非常注重自己的知识产权保护。使用这种需要扫描全量代码的 AI IDE，用户心理上会感到害怕。目前大家确实有在讨论这个产品可能会有数据的回传，如果是一些金融科技类的公司，担忧会更加强烈。”

“ 那么使用国内产品时如何应对这个风险呢？面上和实际操作不一样。面上的话，企业可以跟模型厂商签合同，表明厂商不可以把用户数据用于自己的模型训练，此外模型厂商需要做出所谓“ memory in read committed ”的技术记忆清除承诺。但是让企业跟国内大厂签，企业会放心吗？各种商业瑕疵、实际丑闻让这事变得几乎无意义。我们的商业环境不足以支撑这个信任度。”

“ 所以，公司跟供应商去谈数据安全承诺没用，还是要回到公司内部如何解决外部威胁的问题上。解决办法就是在公司内部做一个网关。通过这个网关去管控，明确哪些数据能够流出，哪些不能。除此之外，其实没有任何方式能够真正约束这些供应商。”

不仅是不敢用，面对发展迅猛的 AI Coding 技术，国内企业的落地方式总是显得更加保守。毕竟，创新用途也不是 Vibe Coding 的专属，效率提升本来就会促进创新增长。

王威表示，“ 过去因为开发成本很高，我们需要尽可能把想法先想清楚，避免浪费，然后再进入交付管道。今天如果 AI Coding 带来的交付成本足够低，就可以做更多探索，产品交付的形式或者与客户的交互节奏也可以更快。这里的成本主要指时间成本。”

“ 这其实给企业带来了更多快速创新的可能，而不仅仅是帮助企业减员。”

“ 但今天很多行业，尤其在国内，可能因为环境或竞争态势，新需求并不多。大家不太愿意创新。”

“如果只是想着节省时间、减少人手，实际上并不能真正推动业务增长。减再多的人，也解决不了企业在市场上能否做得好的问题。”

即便有足够强的动力，要利用好 AI Coding 也不是没有门槛的，但有些企业的 Context 环境还够不上让 AI 正常发挥的下限，一大原因就是没有挖掘出企业中的隐性知识，但又希望 AI 直接能理解。

王威表示，“ 要为 AI Coding 构建一个好的 Context，需要先做企业知识提取和管理。其实这个方向并不新，从上世纪 70、80 年代起，很多企业包括一些咨询公司甚至 IBM ，都在做企业知识管理，这是一个很专业的咨询范畴。这个方向市场空间还很大，目前从行业来看，还没有太好的解决办法。”

“ 现在这个行业的做法有一些问题，大部分咨询公司、产品公司、AI 公司仍然希望用 AI 暴力破解，相当于大力出奇迹的方式，得到一个准确的结果，我不太看好这种方式。”

“AI 理解 Context 的能力虽然越来越好，但理解不了代码背后蕴藏的隐性知识。它只能挖掘现有代码的结构，用自然语言解释代码在做什么，很难真正理解代码为什么当初要写成这个样子。”

“ 很多时候，代码里一些比较麻烦或复杂的地方，之所以写成那样，是有背后的原因的，而这些原因显然也是知识的一部分。”

“ 如果不了解背后的原因，仅仅按照一些标准建议去做，比如说 ‘ 这两个代码不应该被拆开 ’，很可能就会触发在五六年前已经解决过的问题，又把它复现出来。”

“ 知识管理有一个很重要的原则，就是要区分哪些是大家有共识的标准，哪些只是偶然情况或不得不临时处理的情况。有些企业虽然有代码规范，但每个人写代码时都有自己的偏好。”

“ 规范性比较强的企业，在接入像 Glean 这样的文档生成工具，或者 DeepWiki 这样的源码分析工具时，效果就比较好。这样的代码容易被 AI 理解，输出结果也更加准确。”

“ 我估计，在整个行业里，这样的规范代码库最多占到 30% 到 40%，而在国内可能最多只有 5%。”

“ 这当然是老问题了。大部分代码，大家戏称为 ‘ 屎山代码 ’，过去我们叫它遗留代码、烂代码。因为时间和各种压力，开发者没办法把代码写得整齐，也没时间去做重构，这样代码就很难和业务语义保持一致，于是就需要在业务、技术、代码之间不停做翻译。”“ 这种情况下，其实就是 AI Coding 不太能发挥作用的地方，至少今天的基座模型不太能应付。”

“ 我们通过自己的方案，在一些案例中，能把这项工作的耗时从一个月压缩到 5 到 10 分钟。但即便如此，有些企业可能受限于所在行业的发展，或者上下游供应链的情况，缺乏创新或改变的动力。即便企业知识管理对他们有价值，优先级也不高。当然，随着经济的恢复和发展，这类需求的优先级应该会被提高，并进一步促进 AI Coding 的落地。”

从企业知识管理到旧代码重构，都能为 AI Coding 提供良好的 Context。这个关系甚至能形成一个闭环，比如今年就有言论表示旧代码重构是 AI Coding 落地的投资回报率最高的场景。

陈玉兆表示，“ 旧代码重构本身是非常痛苦且耗时的，尤其对新人极不友好。现在行业离职率挺高，很多项目维护了十几年，老员工相继离职，招进来的应届生想要快速深入了解代码并进行重构非常困难。”

“如果能有一个 AI 工具，快速把基础类的风格统一、清除冗余方法，是一件非常好的事情。在此基础之上再去重构复杂功能，会节省大量时间。即便是平时开发中碰到旧代码风格不一致或实现低效，把这些小的代码片段交给 AI 重构成更高效的实现，收益也很明显。”

“ 如果是我的话，我有意愿去购买这种服务。”

“ 归根结底，这个场景 ROI 最高的核心原因在于：现在的 AI 还没那么智能，它能做的就是这种逻辑简单但极其费时、琐碎的事情。而这些事情恰恰又是程序员最不愿意做的。”

张森森则认为，基于 AI Coding 做旧代码重构是有场景限制的，“ 旧代码重构是 AI 编程中投资回报率最高的，这在逻辑上没有问题。像银行那样的系统，代码是经过 10 年、20 年层层堆叠出来的，系统极其脆弱。越是复杂的场景，可能越是当下迫切需要的功能，逻辑上它的 ROI 确实很高。当然我不认为现在的 AI 水平能完全支撑把这件事真正落地。它本质上解决的是业务价值判断和避开 ‘ 局部最优陷阱 ’ 的问题，而只有人才能判断出哪里改起来快、哪里改起来慢，所以全局的洞察必须由人来把握。”

“ 那么，市场上到底有多少程序员拥有看透复杂逻辑并主导重构的能力？我对这个人才储备量是持怀疑态度的。”

生成、重构的良性循环模式，或许能带来一个希望。国内 SaaS 行业的老问题是各公司甚至各部门之间技术标准不统一、重复造轮子。以 AI 为效率驱动器，来推动旧代码重构和规范化，能解决这个老问题吗？

对此，陈玉兆给出了完全否定的回答，“ 我觉得不能，国内没有任何希望，因为这是国内的行业风气导致的，不是技术的问题。”

“ 不光是软件领域，商业领域也是一样，不管是短视频平台、外卖平台，大家最后都是做电商。国内的风格就是什么赚钱快就先做什么，做大做强之后就什么都想做，想吃掉对方。”

“ 即便在技术行业，比如做数据库也是一样，功能越堆越多。国内的风格不是走 ‘ 垂直 ’ 路线，而是想把所有东西都塞进去：既想支持倒排索引、文档功能，又想支持 AI 向量检索，同时还想兼顾传统的 OLTP 场景和 OLAP 场景。这种 ‘ 大杂烩 ’ 趋势和国外完全不同。”

“ 国外的系统相对纯粹很多，追求小而精、可扩展、可部署。尤其是在 AWS 等云厂商上对接时，他们倾向于把平台做得尽量垂直。”

“ 由于这种根深蒂固的差异，想在国内推技术标准，实在是太难太难。”

技术驱动让位于行业风气，或许又从某种角度解释了国内 ToB 企业为何创新动力不足。当然 AI 确实能先激发企业的竞争焦虑，张森森表示，“ 为了在市场竞争和效率竞争中不掉队，使用 AI Coding 这件事没有回旋余地，必须 100% 推进。”

但若创新动力不足或无暇顾及，实际上在 AI Coding 浪潮下，很多传统 SaaS 公司将面临更深刻的危机。

张森森表示，“很多 SaaS 公司现在其实活得 ‘ 战战兢兢 ’。因为有大量 SaaS 产品的程序和代码质量非常差，以前大家可能需要买他们的软件，但现在利用 AI，可能几天时间用户就能自己做出一个类似的东西。对于这些 SaaS 公司来说，最大的风险在于，他们系统所能提供的端到端解决问题的能力其实非常有限。一旦 AI 降低了开发门槛，他们原有的技术壁垒就会迅速瓦解。”

“ 具体而言，这些公司可以分为两种：第一种是 SaaS 化产品做得非常复杂的公司。这种产品的逻辑 AI 是无法简单复刻的，这类公司可以考虑利用 AI 来优化代码或提升内部流程。第二种是做小工具的公司。比如以前上架到 App Store 的番茄钟，这种东西现在人人都能自己做一个。在 AI 辅助下，通过 Cursor 之类的工具 ‘ 咔咔一下 ’ 就出来了。那现在的番茄钟还能卖钱吗？”

番茄钟或许门槛太低，但有一类 SaaS 产品门槛不低，却因为和 AI Coding 定位太过于接近，正面临最大生存危机。

王威表示，“ 原来的低代码、零代码平台效果其实都不好。以我们过去做咨询的经验来看，这类低代码平台对企业来说，并不是最佳投资策略。低代码最终只能实现一些排列组合式的功能，难以满足真正个性化的需求。如果你想做一个软件产品，最核心的是理解用户需求和逻辑（ 他们的 journey 是怎样的 ）。真正理解这些的时候，你就会发现低代码平台要么封装颗粒度太大，不够灵活，要么颗粒度太小，又需要花大量时间去做编排，还不如自己写代码。”

“ 另外，我个人看过的低代码平台普遍存在一个问题：可测性不够好，尤其是单元测试和模块间的集成测试，复杂度反而上去了。”

“ 而今天有了 AI，你可以特别快地生成原型。只需要告诉 AI 我想要什么样的 App，用户习惯大概如何，界面大概长什么样，原型就出来了。所以在 AI 时代，低代码的优势可能会被 AI 的快速原型和高度定制化能力所取代。

张森森的观点基本一致，“低代码平台很有可能被 AI 取代。低代码平台最大的问题，和现在的 Agent 是一样的，就是一帮程序员自我感动想出来的东西。他们希望搞一个平台，让业务人员通过拖拉拽就能搞出 Agent 或者页面。”

“ 但实际上，没有一个业务人员真的愿意用这种工具去拖拉拽出一个端到端的结果。大家都是迫于公司需要，或者没人帮忙干，才只能自己干。但凡业务人员能找到研发人员来干活，都不会自己动手的。”

“实际上，这个需求存在了很多年，因为这个故事讲得很通顺：通过业务人员拖拉拽生成页面来减少开发人员。资本市场认可这个故事，在公司内部只要疯狂推行、压迫业务人员去用，最终也会有人用。”

“ 但大部分情况下，都变成了一种尴尬境地：业务人员真的不想用，觉得拖拉拽太扯淡、太恶心。即便是实现一些简单的逻辑，它可能能帮你做，但做完之后又实现不了真正的业务目标，业务人员就卡在一个两难之间了。”

“ 最重要的是，拖拉拽操作是有学习成本的，业务人员为什么要学呢？对于一个计算机小白，这等于疯狂地学一样新东西。但有些业务人员说不定连学 Excel 都觉得费劲，精通 Excel 的人本来也不多。拖拉拽在程序员或懂技术的人看来是很简单的，但他们完全没有站在真正用户的角度看问题。”

“ 至于大模型和 AI Coding 出来后会不会替代它，要看低代码平台是否有动力对内核进行升级，总之不能再以过去那种 ‘ 拖拉拽 ’ 的方式设计产品了。毕竟现在业务人员通过自然语言描述一下，AI 就能把拖拉拽的工作做好，把页面生成好。所以这个逻辑依然会存在，但本质上是真正解决了 ‘ 费劲 ’ 这个痛点。” 王威补充道，“在企业应用或者软件交付场景下，我们团队一直不太推荐用低代码平台。这也引出了一个问题：在 AI 时代，它会变成什么样？”

“ 与其在低代码上做封装，如果今天的低代码平台只是基于基座模型再封装一层、变成一个 Agent，倒可能是可行的。这样可能会让整个软件构建过程最终变成一个 Agent，不再受原来模块颗粒度高低的限制。”

进一步，在 AI Coding 快速吞噬低代码平台生存空间的当下，软件开发工具、平台层面还有更多创新空间吗？

王威认为是有的，但要建立在 AI Coding 的语境下，“ 在软件研发的整个链路里，不管是需求分析、架构设计、代码编写、测试用例的设计与执行，还是配置管理、环境管理、DevOps 等，我们都应该去思考：在每一个环节，AI 能帮我做什么？我怎么让 AI 参与进来？”

“ 当你先把 ‘ 如何让 AI 融入我的日常工作流程’这件事想明白之后，下一步其实就是抽象与沉淀。也就是把你在工作中用得特别顺的一些东西提炼出来，比如一个始终有效的 Prompt 结构、一个特别清晰的问题框架、一个真正能提升效率的工作流、或者一套验证过的最佳实践。把这些东西从 ‘ 经验 ’ 变成 ‘ 工具 ’。”

“真正有价值的创新都来自一线，来自那些能解决企业真实问题的场景。所以当你把这些工作中的好模式封装出来、工具化、体系化，它不仅能让你在企业内部产生更大的价值，甚至可能在企业之外变成一门新生意、一个新产品。”

“ 今天的行业其实还没有共识，大家对未来的形态也没有统一答案。既然如此，不如把你手里最好的工具拿出来试试，把它产品化，把它武器化。”

另一方面，如果要在产品中深度结合 AI，作为非大模型厂商创业者，死磕模型不一定是好选择。

比如 Cursor 推出了自研的编程模型 Composer 1，试图从套壳 AI 应用厂商升级为大模型厂商，但目前行业整体评价是比较一般的，比如一些 Reddit 网友反馈 Composer 1 非常快，但只是更擅长简单而繁琐的任务，智能上限不高，所以规划能力不如顶尖模型，还有 Reddit 网友认为它应该对标的是小模型比如 Grok Code Fast 1，甚至还不如后者。

张森森表示，“ Composer 1刚发布的时候我用过，个人体感是 ‘ 特别难用 ’。Cursor 之所以做这个事，是因为 Cursor 每年的盈利中，大部分钱是要交给那些大模型厂商的，我预计他们每年亏损得很严重。所以他们会想，与其把钱交给别人，不如自己做个模型，自己挣这个钱，这是它的商业考量。而且 Cursor 也是在跟资本讲一个故事，说它能活到最后的目的，是以后能实现 Vibe Coding，目前离真正盈利还早得很。”

相比传统企业和创业公司，还有一个远为更庞大的群体正受到 AI Coding 的剧烈冲击，也就是程序员。那么在 AI Coding 时代，程序员如何更好地生存和发展呢？

首先明晰一点，程序员当前确实存在一些职业危机，但不是全方位被覆盖的。

陈玉兆认为需要按工种划分，“做基础测试的人更可能会面临淘汰。目前来看，写基础测试代码的工作确实可以由 AI 完成。”

“ 但稍微复杂一点、带有业务逻辑的测试工作，目前 AI 还很难替换人的作用。”

王威持类似观点，“ 有些公司可能会说，因为我有 AI 工具，就可以裁掉 60% 或 80% 的程序员，但我觉得今天很难有公司真的会做出这样的操作。” 并且按从业经验进行了划分，“ 相比安全感最高、能轻易驾驭 AI 的专家级别或资深程序员，中级程序员（ 工作年限大概在三到五年之间 ）的危机最大。”

“ 尤其在国内，在过去十年互联网热潮中，很多外包团队的程序员，因为企业对 IT 人员需求量大，通过速成方式进入了 IT 行业。这些人可能只能按客户需求写代码，却不了解客户业务，也不了解技术底层逻辑。”

“对于这样的同学，随着年龄和工作年限增长，和 AI 相比，他们确实需要思考如何更好与 AI 共存、协作，思考自己的竞争力在哪里。”

“无论是中级程序员还是新手程序员，今天的最低门槛、最底线的要求是：学会和 AI 协作。”

张森森则认为关键在于长期积累的工作和思维习惯，“ 在 AI Coding 时代，程序员本身也要完成素质上的提升和转型。未来的程序员的生存之道是，不能只精通某一项语言（ 比如 Java 或 C ），而是要转型为 ‘ 全栈 ’ 甚至 ‘ 全语言 ’ 掌控者。程序员或许不需要深入了解每种语言的所有细节，但必须能看懂 AI 生成的每一行代码，并清楚它在整个程序架构中发挥的作用。”

“ 未来的软件开发不再需要 ‘ 代码搬运工 ’。如果一个程序员只会写一种语言，或者过去的工作习惯只是写一些边角余料，甚至是那种别人给好框架、只负责往里填逻辑的 ‘ 填充式编程 ’，这类程序员 100% 会被开掉。”

“这种工作模式已经完全不符合技术发展的需要，在 AI 已经能高效完成填充和补全工作的今天，这类程序员将不再被定义为 ‘ 程序员 ’。”

从另一个角度看，AI Coding 不一定是危机来源，也可以是新的自我提升和成长的机会，陈玉兆表示，“ 比如对于程序员的个人学习，用 AI 来做源码分析是非常擅长且适合的。”

即便是对于新手程序员，只要建立正确的认知，就不用担心过度依赖 AI，阻碍自身成长，陈玉兆表示，“ 现阶段的 AI 编程并不具备资深工程师的全部技能，它相当于是一个高中生或应届毕业生的水平。”

“ 它能帮助你的是那些容易量化、模块化、模板化的重复性工作。它能帮你更高效地组织代码，并用更接近人类自然语言的方式进行交互。它本质上是对已有工具的集成和加速，而不是取代。如果新手能熟练运用这种新工具，反而更好。”

“ 时代是在发展的，程序员不可能永远拿着文本编辑器编程，就像 IDE 也在发展，就像以前用 Photoshop 处理图片超级复杂，现在用谷歌的 Nano Banana Pro 说几句话就能处理。”

“ 当然，如果想更深入地了解某个领域的行业经验、发展历史等深层次内容，还是需要和专业领域的人员进行深入的沟通，这些东西 AI 应该是提供不了的。”

王威也持类似观点，“对于新手程序员或刚从学校出来的年轻人，其实AI是机会。今天 AI 可以帮助新人迅速达到原来中级程序员的水平。”

“ 无论是通过 Prompt Engineer 还是 Context Engineer 构建良好的和 AI 协作的模式，那么入职第一个月甚至前两周，就能建立起和过去中级程序员相似的输出能力。”

“我们经常会和客户反复强调，千万不要裁掉年轻程序员。因为只有这些年轻人，随着他们对业务的了解加深，随着在企业的工作时间增长，才能逐渐成长为专家。”

“虽然理论上，中级程序员也可以培养成专家，但其实最合理的方式是在 AI 的加持下，让年轻人快速成长为专家。因此，行业内很多海内外专家一直大力建议企业不要放松对毕业生的招聘。毕业生是有前途的一代，而专家这一层也不能抛弃。所以我才说最危险的是中间那一层程序员。”

这不只是预言，其实已经体现在目前一些软件公司的实际招聘需求变化上了，“ 根据一些统计报告，确实显示过去一年尤其是最近半年，整个软件行业开放的 Headcount 都比去年下降了。并且他们确实是会增加对略微资深程序员和校招的 Headcount。”

“ 但更坦白地说，如果预算有限，我们都会建议至少校招不能停。”

“ 因为从企业未来发展的角度，总要为未来储备人才。年轻人需要在真实业务里慢慢培养、累积经验。如果完全不招新人，只靠外部招聘有经验的程序员，那么企业内部的关键上下文和知识的传承、人才梯队，很可能会出现断档，长期来看对企业反而是更大的风险。”

“这在今天可能还看不太出来，有些企业可能觉得与其招十个甚至一百个校招生，不如直接招两三个专家程序员，看上去更省钱、更直接。但实际上，当时间拉长到五年甚至更久的时候，都会出现明显的问题。”

当然，工种、经验等都是表面判据，任何程序员都不必然会因为这些因素被淘汰，“ 我会建议大家先问自己一个很本质的问题：对这个行业到底有没有真正的兴趣？”

“ 我始终认为，真正能把一个人推向 ‘ 专家 ’ 层级的，从来不是日常的任务堆积，不是写了多少行代码，也不是做了多少 CRUD。 ”

“ 能让一个人愿意深入理解每一项技术，愿意把技术栈往底层学，愿意去追根究底地研究 Java 的运行机制、JVM 的内部结构、Redis 的底层实现，这些动力绝对不是源于 ‘ 工作需要 ’，而是对计算机、对技术本身的热爱。很多五十多岁的程序员对这个行业依然保持热情，只要有新技术出来，他们都会第一时间去看资料、读文档、阅读开源代码，去看别人到底是怎么实现的。”

“ 这样的人，无论是新手程序员、中级程序员，还是现在已经是个专家，都是非常有前途的。”

“历史也能证明，蒸汽机出现以后，很多手工作坊都消失了，但真正没有被取代的，是那些老匠人、热爱做事的人、把自己的作品看作艺术去钻研的人，即使到了工厂，他们也能指导机器，通过改造流水线或零部件制造新的产品。这样的人，在市场上永远有价值。而因为铁匠这个行业能挣很多钱所以去当学徒打铁的人，从历史上看都会面临比较大的危机。”

“ 所以，如果只是因为过去这个行业溢价很高，坦白讲就是‘很容易赚钱’，比如学个 Java、学个 Python 就能进到大公司做程序员，可以思考一下，是否需要换一个赛道。”

使用 AI 写代码、与AI协作，已经是大势所趋。那么一个很关键的问题就是，如何与 AI 协作，才能最大化个人的产出，最大化对 AI 的利用，同时避免 AI 技术限制带来的额外成本。

在具体执行层面，核心是 Context 管理和人机交互模式的打磨。

王威表示，“ 这一年多，我们看到的是 LLM 的能力在逐渐趋于稳定，接近一个 ‘ 可预期的上限 ’。也就是说，它主要的能力还是基于你给它的 Context，来做更精准的预测和生成。”

“ 围绕这些已经相对成熟的能力，每个程序员都应该建立起自己的一套 ‘ 和 AI 协作的打法 ’。 比如：我如何与 AI 交互？我如何通过 Prompt 让 AI 帮我生成原型？我如何让 AI 帮我改代码？我如何让 AI 帮我整理数据、总结知识？这些其实都是今天软件行业的从业者必须掌握的基本能力。”

在一些典型场景中这些原则可以体现得很明显。比如 AI Coding 过程中由于模型的知识偏差和知识盲区，总会带来一些很根本的不确定性，比如前者带来对编程语言（ 比如 Python、Swift ）熟悉度的偏差，后者带来幻觉的可能性，这就很依赖 Context 管理来解决。

陈玉兆表示，“ 就算存在比较严重的知识偏差，只要给它足够的引用、上下文、参考文档，并告诉它想生成的代码风格，基本不会出太大问题。”

张森森补充道，“ 关于 AI 编程模型在不同编程语言上的侧重，这种现象肯定存在。国外的 AI 模型通常 React 写得比较好，Vue 稍微差一点。这跟训练语料有直接关系，因为国外大部分前端软件都是用 React 写的，而国内用 Vue 写的更多。”

“ 针对这种不平衡，目前行业内主要有两种做法。首先是语料层优化，在模型训练阶段，针对性地增加特定语言（ 如 Vue 或 Flutter ）的语料权重。其次是逻辑转换，采用 ‘ 先生成再转换 ’ 的模式。比如先让 AI 用它更擅长的 React 逻辑写完，再通过特定的转换工具或二次 Prompt，将其逻辑转译成 Vue 代码。”

“ 关于这一点，Lovable 还有一个不太令人满意的地方，就是它严重的技术栈绑定。国内前端大部分习惯用 Vue，后端很多已经用 Java 写好了。像 Lovable 这种面向海外市场的工具，前端必须是 React，后端绑定了 Supabase。这导致国内现有的企业级存量代码根本没法拿过来用。”

至于一些最令人头疼和心累的问题，比如 “ 按下葫芦浮起瓢 ”，想修改一个特定的 Bug，但 AI 在修改过程中造成了新的 Bug。陈玉兆认为，这种情况在良好的交互模式和开发实践下，可能性不是很大，“ 这取决于你原来的测试集写得是否全面。首先你得有一个自己的基础测试集，系统的稳定性和可用性首先应该由你的基础测试集来保证。不可能让 AI 帮你写所有的测试，那不太现实。”

当然，其中也会存在一些 “ 是否必须用 AI ” 的权衡，“ 对于一些逻辑比较复杂的代码块，需要给它正确的引用，在搜集这些引用、提供足够的 Context 以及反复纠正的过程中，它有一个回馈、撤回、再纠正的过程，如果这个过程花费的时间太长，反而有时还不如自己直接写来得快。”

在原则层面，需要时刻记住 “ AI 在不断发展，AI 永远存在天花板 ”，张森森认为，与 AI 协作需要结合 AI 的发展现状，才能发挥最好的效果，无论是程序员和企业管理者都需要建立这样的认知，“虽然 AI 编程是必然趋势，但 AI 的能力上限和天花板是随着技术发展动态变化的。不能忽视这个天花板的存在，如果盲目追求效率而无限度地压榨程序员，公司是无法进入良性发展轨道的。正确的做法应该是，持续寻找合适的场景让 AI 去替代那些重复、乏味的工作。”

“ 从原型开发到生产级、大型企业级项目的过渡中，如何将 AI 的利用率最大化？按目前现状，可以参考几个关键的比例分配经验。比如样本代码与文档可以 100% 委托给 AI 生成，人工只需进行抽检。单元测试 70%-80% 可以交给 AI 完成，但人工需要补充一些边界条件。核心逻辑（ 算法实现 ）最多只能给 AI 四成，因为涉及到复杂的架构设计和异常处理，AI 目前完全做不了。安全审计 AI 可以负责初审和针对性的漏洞扫描，但这必须保证 Human-in-the-Loop，一定需要人工复核。”

对安全风险把控的重要性再怎么强调也不为过，风险包括 AI 幻觉和企业机密数据泄漏，应对前者的核心原则是 “ 永远要人工审查代码 ”。

如果太依赖 AI 编程，可能会导致程序员记不住代码的细节，当真的出现高风险事故时，安全风险排查会变得比往常更加困难，陈玉兆表示，“程序员可以不写这段代码，但需要深入了解这段代码是干嘛的。对于每一段 AI 生成的代码，都要了解它的作用，而不是 ‘ 无脑 ’ 地直接合并。”

“ 如果长期看都不看就直接合并，一年两年之后，程序员肯定不知道代码里到底写了什么，出了 Bug 也就修不了。但如果每次都站在 Reviewer 或项目维护者的角度仔细审查，追踪代码的时间线、迭代过程以及生成逻辑，是不存在这种风险的。即便招一个真实的程序员来开发，也是同样的流程。”

关于如何应对企业机密数据泄漏风险，以网站开发为例，张森森表示，“ 完全使用 AI 开发网站并部署到 Supabase这类平台时，身份验证、注册系统及安全风控可能是较难解决的痛点。AI 并非完全没能力做，而是风险极大。敏感数据绝不可以作为 AI 的上下文，否则一旦被外部获取，会导致商业机密和公司安全风险泄露。因此，简单一些的比如鉴权系统的代码 AI 可以写，但若涉及数据库的数据必须慎重考量，比如数据库安全规则、权限规则等逻辑，AI 能提供方向或生成部分代码，但具体的公司级业务逻辑是机密的，通常需要手工编写。”

到这里，我们基本了解了 AI Coding 和 Vibe Coding 的区别和发展现状，张森森总结道，“目前 AI Coding 的最佳实践不是 ‘ 全自动生成 ’，而是 ‘ 部分生成+ 程序员修改 ’ 的模式。这种模式在短期内不会被改变。AI Coding 的未来确实是Vibe Coding，但 Vibe Coding 也确实存在泡沫，完全是吹给老板和资本方听的，他们听了确实会很兴奋，但行业内真正的程序员对此非常困惑，因为大家心里清楚，全自动化的端到端开发在短时间内根本做不到。”

对于非常激进、重度依赖 AI 编程来做产品的创业者，陈玉兆也建议道，“ 至少还是要招一个比较资深的程序员来控制项目的质量。如果一个项目完全、一直由 AI 来生成，最后基本上会变得不可维护。”

那么决定未来的是哪些关键因素呢？

“大模型本身的 ‘ 幻觉 ’ 问题，是目前阻碍全自动化生成的最大屏障，短期内很难完全消除。但随着 Gemini 等模型能力的进化，大家在应用生成（ 如 App 生成 ）上的实操经验越来越丰富，这种 ‘ 行不通 ’ 的固有印象正在慢慢改观。目前行业正处于一个 ‘ 寻找平衡点 ’ 的阶段。”张森森向知危说道。

“ 最终的目标一定是：不再需要专门的程序员，产品经理一个人就能搞定从设计到交付的全过程。这个最终局面的到来，三年还是五年？没人敢断言。马斯克的预测比较乐观，但国内可能相对悲观一些，多少年都有可能。”

AI 编程模型要降低幻觉，自然需要吸收更多代码数据，但当前行业在数据供应和质量方面已经存在一些不可忽视的潜在风险，“ GitHub 现在已经快变成 ‘ AI 代码的天堂 ’ 了。这对普通使用者来说影响不大，因为大家只是把 AI 写的项目放上去分享，只要能跑通，使用者其实并不介意。真正核心的问题在于未来模型训练的‘ 数据污染 ’ 风险。当我们再次使用 GitHub 上的数据去训练新一代 AI 模型时，要弄清楚如何从这些海量的 AI 生成内容中，甄别并剔除出那些 ‘ 不干净 ’ 的数据，会变得非常困难。”

“ 这种 ‘ 数据污染 ’ 不仅存在于编程界，在整个模型训练领域都是一个巨大挑战。当 AI 开始学习由 AI 生成的内容时，逻辑的退化和多样性的丧失就不可避免。这就是为什么国家层面要强调建设高质量数据集的原因。”

在 Context 理解能力层面，AI 也存在比较普遍意义上的局限性，可能未来还需要在技术上做出更多突破。

王威表示，“ 近期 Andrej Karpathy 在播客访谈中提到一个很有趣的现象：在 Claude Code 中，你会发现一开始 Context 不够，AI 理解不全面导致生成不准。但到后来 Context 越多，生成反而也不准。” “ Andrej Karpathy 用了一个类比，如果把 Agent 或 AI 看作 ‘人’，那么人之所以能够记住信息、学会技能、理解上下文并做出决策，很大程度上依赖于记忆。”

“ 但人不仅有记忆，还有 ‘ 睡觉 ’ 这个过程，‘ 睡觉 ’ 的本质是一次信息的压缩和重组。 此外，人的记忆有时候不只是存在脑子里，还存在外部。人会忘掉很多东西，但这些被遗忘的信息可以在特定时间、地点和环境下被触发。比如你在北京，看到秋天飘落的银杏叶，可能会突然想起二十年前经历的某个场景。如果不在当时的环境下，你可能完全想不起来，以为自己已经忘了。

“所以，人的大脑有这样的能力：一是通过睡眠对信息进行压缩和重组；二是通过环境触发存储在脑内外的多模态记忆，从而唤起过去的经验。这些能力都能让人的决策更加高效，大模型不具备这种能力。”

“这些问题可能不是 Context Engineering 能解决的，而是需要深入理解人是如何思考的，才能进一步推进。这意味着未来无论是 Agent 公司还是基础模型公司，都是有机会的。谁能够帮助大模型更好理解 Context，更像人一样思考、构建机制，谁就有机会开拓未来市场。”

除了模型本身，软件行业也会有一个更核心的演变趋势，张森森表示，“ 现在的 Vibe Coding 和 AI Coding 用的还是 JavaScript、Vue、React 或者 Java，但我相信在未来一到两年之内，一定会产生一种全新的编程语言。这种语言将直接把现有的传统语言全部干掉，它是完全为了 AI 编程而生的。”

甚至更进一步，软件工程的范式或许也需要彻底改写，才能最大化 AI 带来的价值。

王威表示，“ 要理解这个变革的必要性，需要回到场景本身：到底为什么要写代码？为什么要做软件？原来人是怎么做软件的？”

“ 在没有大模型之前，我们做软件其实有两种不同的形态。第一种是个人独立开发者。个人开发者需要不断学习新的技术、工具、框架，比如从 C++ 换到 Go 再到 Rust，总是要跟上最新一波技术。”

“ 另外一种是企业场景。企业场景要解决的问题不仅仅是个人开发者的问题，更重要的是规模化的问题。也就是如何让一群人一起高效地开发软件。一个人高效相对简单，而在团队中，即使每个人都是非常优秀的独立开发者，也有可能出现 1 + 1 小于 2，甚至只有 1.1、1.2 左右。”

“ 所以过去的软件工程，从早期的瀑布模型，到敏捷迭代，再到 DevOps，其实都在试图解决同一个问题：一群人要怎么一起把软件开发好。”

“ 而今天的 Code Generation 工具，本质上仍然更多关注个人开发者。但要让一群人在组织里更好、更高效地完成代码生成或代码编写，把 Code Agent 真正带入企业内部，并让它发挥真正的价值，还需要很长的时间。”

“ 这不仅在于技术层面，更重要的是人的层面。未来的开发者、产品经理、测试人员，这些角色还存不存在？他们的技能会变成什么样？这些都是问号。”

“ 如果回头看，DevOps 、敏捷迭代之所以能在过去十到二十年里推得快和顺利，主要原因还是当年那些互联网公司，比如 BAT、谷歌、亚马逊，他们在行业还不成熟的时候就率先采用了新技术和新组织形态，去实践最新的软件研发模式，然后这种模式逐渐被传统企业、金融、制造等行业接受。他们天生就在用这种模式做事，所以才会成功。”

“ 当时国内也想学国外的微服务，可见这种标杆效应非常强。如果没有这样的标杆，现有组织的惯性就很大，在组织内部很难推动这种变化。除非集团公司单独投资搞一个 AI Native 公司，那才有可能。否则在现有业务里推动，先不说技术的惯性，人的惯性就足以让迭代周期以十年计。十年后，国内大厂内部的模式才可能真正发生变化，这是很有可能的。”

“ 所以我不会认为现在的国内大厂，会首先出现这一代新的实践，更可能是类似 Winsurf、Perplexity 这样的 AI Native 公司带来新的变化。大家都说现在要讲人效，其实创业公司最讲人效。他们会用最少的人，用最新的技术，用看起来最省力的实践模式，去打造完整的交付链条。AI Native 公司从一开始就不是在旧范式里改造，而是在新范式里长出来的，他们可能会率先实现真正完全依赖 AI 来生成代码，而不是继续手写代码，也许关键还是在于如何管理好 Context 。并且，这种模式是可复制、可复现的，那么AI才有可能推动整个行业去跟进。”

“目前国内很多行业会议或专家在讲 AI 2.0、AI for SE、下一代软件工程、下一代软件研发模式，但其实这些论调太不成熟。因为当下我完全没有看到任何可复现的实践模式。既然如此，就很难谈所谓新的宣言或者最佳实践。”

“就像当年的敏捷宣言、Scrum那样真正能被行业接受的技术实践。敏捷宣言、Scrum 的第一篇论文是 1986 年写的。而敏捷宣言是在 2001 年定下来的，也就是经历了 15 年时间。当然今天时代发展更快了，可能不用 15 年，但 5 年、10 年仍然是需要的。”

“ 可能某一天，大家会忽然意识到： 原来未来的软件工厂应该是这么运转的，原来自动化的流水线应该是这样搭起来的。到那个时候，新的行业范式就会逐渐清晰：什么是下一代的工厂，什么是 AI 驱动的软件生产方式，什么才是自动化时代真正的 ‘ 基础设施 ’。”