停招初级工程师！大厂样板无实战价值、软件黑灯工厂死路一条，三位AI 编程老炮：AI越骂越灵！

策划 | 褚杏娟、Tina

对话 | 王一鹏

编辑 | 宇琪

在 2026 年初突然刷屏的 Clawdbot 又给 AI 编程的火爆添了一把柴。根据项目创始人 Peter Steinberger 的说法，他一个人完全用 AI 写出了这个超级 AI 助手。

AI Coding 高速演进，有人借助它如虎添翼，效率和能力被成倍放大；也有人一上手就频频踩雷，代码质量、系统风险反而被放大。但如今企业纷纷拥抱 AI Coing，代码已经是“cheap”，技术从业者现在面临的问题已经成为“如何与编程 Agent 相处”，无论是工作还是生活中。

近日，在 InfoQ 技术编辑组策划的《2025 年度盘点与趋势洞察》直播节目中，Kreditz Al Orchestrater 马工、资深 AI 产品专家松子（李博源）、资深独立咨询师 &Al Coding 资深实践者张汉东一起，分享了他们的 AI 编程工具使用经验和过对行业的观察，他们三人都去年大量使用 AI 编程，并在组织层面进行了一些探索。

在访谈中，三位专家都表示，彻底回不去之前的手工 coding 时代了，AI 已深度接管开发者的主观能动性，成为工作的核心环节。人类在 AI 时代的核心价值不是写代码，而是需求表达、方案判断、架构设计的能力，这是 AI 目前无法替代的 “最后护城河”。

根据使用经验，现在 AI 编程的成本远低于人力成本，其产出效率相当于数人团队，哪怕订阅制有额度限制，也是极高性价比的选择。AI 编程并非降低行业门槛，而是入门门槛降低、精通门槛拉高、天花板抬升，靠手速和熟练度生存的中间层工程师正被快速替代，其成长路径被直接掐断。当前，AI 无法真正理解 “优雅的架构”，这是人类的审美问题而非技术问题，也不该指望 AI 把控，架构设计本就是人类的核心职责，因此真正具备架构能力的人因 AI 变得更稀缺，

他们评价现在对 AI Coding 工具好坏与否的唯一标准是能否在真实生产系统落地交付，大厂未经过实战的全套 AI 方案毫无价值。专家指出，全自动 AI 程序员（如 Devin）现阶段完全行不通，易出现需求理解偏差、架构不一致、交付质量不稳定等问题，未来 3-5 年人机协作是企业级开发主流，长期 Agent 才是发展方向。当前，开发工作的核心已从 “怎么写” 转向 “写什么”，从关注代码细节转向业务逻辑、边界条件、异常处理；思考必须更清晰，才能让 AI 准确理解需求。

他们预计，2026 年 AI 编程将成为行业标配，“一人公司” 会成批出现；创业的技术门槛被拉平，核心竞争力转向商业模式、业务理解和业务架构。linker、compiler、操作系统未来或向 AI 友好形态升级，这背后存在大量创业机会。

而对于年轻人来说，AI 消除了信息差红利，让其能与行业专家站在同一起跑线；现阶段是有野心的年轻人成为软件工程思想领军人物的最佳窗口期，核心是获取一手信息、亲自实践并主动输出观点。

专家们提醒，不应将 AI 当作全知全能的神，而应让其批判性思考、挑战自身观点，避免强化认知偏见；AI 的核心价值是成为既支持又挑战人类的协作对象。

以下内容基于直播速记整理，InfoQ 在不改变原意基础上进行了删减。完整直播回放可查看：

1“回不去手工 coding 的时代了”

王一鹏：如果用一个词形容你过去一年的 AI 体验，你会选什么？

张汉东：加速。

马工：革命。

松子：上瘾

王一鹏：对比使用 AI 工具之前的情况，你的工作流程是否都变了？

松子：最显著的特点就是变化快、跨度大。过去做一个需求，通常是查文档、写 PPT、画原型图，画完之后就等着技术去实现。现在则完全不同了，有想法就直接和 AI 进行头脑风暴，看着 AI 写代码，指挥 AI 去执行，拿到结果后再和技术团队一起评审，由他们来做加固和优化。

马工：工作流程上，我刻意把团队规模设计得非常小，通常只有两三个人，尽量避免大团队沟通，因为有些人跟不上节奏，反而会拖慢效率。另一方面是我个人的工作流，核心是我和 AI 的持续对话，由我来设计、引导它。

张汉东：以前我会非常关注代码细节，比如优雅性和精细化的质量控制。使用 AI 之后，我更多是站在更高的抽象层面思考问题，从架构层进行设计，甚至可以同时开多个分支并行推进开发流程。另外，在代码评审上也大量使用 AI，先由 AI 生成一份 review 报告，再进行人工检查，实现并行评审。

王一鹏：你第一次感到“AI 有点可怕或厉害”的瞬间是什么？

马工：5 月份开始用 Claude Code 之后，我才真正意识到这东西“成了”。在此之前，我一直认为 AI 只是辅助工具，给一些建议，但每个回答都需要仔细核查。Claude Code 不一样，它已经能够独立完成一些颗粒度较小的任务，而且不需要人在旁边全程跟着。这一点在我看来是革命性的。有了这种基础能力，再叠加我们的工程经验，就可以做很多以前做不了的事情。

松子：害怕我还真没有，更多的是兴奋，甚至有一种自己年轻了二十多岁的感觉。那种感觉就是，终于可以自己动手了，不再需要依赖技术团队帮我实现想法。尤其是在面对模糊需求时，AI 不仅能帮我纠正表达，还能帮我梳理边界条件，直接把代码写出来，把我的思路整理得非常清晰、有条理。

张汉东：我最早是从 Claude Code 3.7 版本开始用的，那时体验还不算好。等到 4.0 出来之后，我明显感觉到它变得非常强。再到最近，大家在网上讨论 Claude 的 Skill 能力，我也试了一下，最终的效果是我在 20 分钟内就做出了一个不算复杂、但支持跨平台的 AI 应用。

王一鹏：你现在写的代码，有多少比例是：在没有 AI 的情况下，你依然确信自己能完整写出来的？

张汉东：可以的，毕竟我有接近 20 年的项目和编程经验，手写代码本身没有问题。但最大的问题在于，我已经不想手写了。现在基本是 AI First，AI 已经在很大程度上接管了我的主观能动性，这是我感受到的最大变化。

松子：如果没有 AI，我几乎一行代码都写不出来。但我认为我的价值并不在于是否能逐行写代码，而在于：第一，我清楚自己要做什么；第二，我能够判断 AI 给出的方案是否可靠；第三，我能把需求描述清楚。这三种能力，是 AI 目前无法替代的。

马工：从理论上讲，我当然也可以手写所有代码，但从工程角度来看，这并不现实。AI 写代码的速度是我的十几倍甚至二十倍。比如我在圣诞节和新年假期完成的那个项目，如果没有 AI，可能需要一年时间才能做完。从工程管理角度来说，老板也不可能批准这样的周期，所以在现实中几乎不具备可行性。

王一鹏：过去一年里，有没有一个瞬间你意识到：“我已经回不去不用 AI 的状态了。”那一刻发生了什么？

马工：我从来没有想过要回到过去。就好比以前是科举制度，后来进了新学堂，你让我再回去参加科举？不可能的。我现在玩得很开心，也非常适应这种状态。

松子：跨年的那几天，大家都在干什么？我那几天连续使用的 Token 量都破亿，别人在倒计时，我却在给 AI 写代码。那一刻我非常清楚地意识到，我已经和 AI 形成了一种共生关系。后来有一天几乎完全没用 AI，但那一天我是真的很累，想给自己放一天假。结果第二天开始工作时，我发现自己竟然不知道该如何开始了。打开编辑器的第一反应，还是想先让 AI 帮我做点什么。回头再看这两个对比，我很确定自己已经回不到没有 AI 的时代了。

松子的 token 用量统计

张汉东：我意识到自己回不去，是在某一天突然发现自己写代码时已经不再使用编辑器了。我写了十几年代码，从来离不开编辑器。但在使用 Claude Code 四五个月之后，我发现很多时候根本不需要编辑器了。那一刻我意识到，自己已经彻底颠覆了过去的工作方式，也不可能再回到原来的状态了。

2把 AI 当成一个同事，结果为王

王一鹏：从去年开始，我们就关注 AI 给不同技术岗位带来的影响和变化，今年是更深入的一年。那先请各位根据自己的使用体验，锐评下现在的国内外的 AI Coding 工具，在使用中各有什么优缺点？有哪些看起来很先进，但在实践中很快暴露出问题？

马工：我并不把 AI 当作一个工具，而是把它当作一个同事。我和朋友一起探索出了一套理论，叫作 AI 管理学。传统管理里有人力资源管理，而现在我认为还需要一套面向 AI 的管理体系。管理的核心从来不在于工具本身，而在于流程和思路，也不存在所谓“最优解”。对我来说，更重要的是探索出一套适合自己的 AI 管理方法，并与我的工具组合在一起，形成最适合产品的方式。

也正因为如此，我现在比较反感一些大厂的做法，声称做出了一整套方案，要求别人直接照着用。但我仔细看过之后发现，他们自己甚至没有用这些工具真正做出一个在生产环境中运行、处理真实业务的系统。所以我现在评估工具，只看一件事：有没有在真实生产系统中、处理过真金白银的案例。如果没有，我基本不相信。在这一点上，我甚至更相信自己，因为我是实实在在把公司的业务跑在这些系统上的，是真正经过实战检验的。

张汉东：从产品经理背景转过来的用户，使用 Vibe Coding 时，往往并不太关心底层代码质量，更关注功能是否完整、是否可用。像我这种程序员出身的人，会不可避免地带着一些工程习惯，更在意代码质量、可维护性。因此在使用这种对话式代码生成工具时，我需要对整体生成逻辑进行把控。

即便我可能不会逐行检查代码细节，但必须在脑中建立一个清晰的心智模型，并通过对话与 Claude Code 建立稳定的协作关系。即便如此，它生成的代码质量也未必如想象中那么高，仍然需要人类进行验证和 review。通常还要结合一些 skill、prompt 以及自动检查和优化工具来兜底，才能保证整体质量。所以我认为，Vibe Coding 和相关工具的使用，至少可以分成两类人、两种路径来理解。

王一鹏：如果我并不是特别在意代码是否优雅、质量是否很高，只要能跑、能用，这种情况下不去 review 代码也没问题吗？还是说如果完全不 review，代码在运行层面本身就可能会出问题？

张汉东：一般来说，一个产品上线之后，后续一定涉及维护。如果形成的是一个“AI 生成代码、AI 修 bug”的闭环，短期内是可以工作的。但随着用户规模和代码规模不断扩大，很容易陷入不可控状态，最终变成一次性应用，用完即弃。对于一些关键领域，比如基础设施或操作系统，使用 Vibe Coding 时，你需要的是钢铁般稳定的结构；而在一些不那么关键的上层应用场景中，可以接受“用完即弃”，我更愿意把这种代码形态比作海绵结构，内部存在不少空隙和不确定性。最终可能呈现的是一种“海绵包裹钢铁”的混合结构。

松子：就我个人而言，评价工具的标准很简单，尤其是对非科班出身的人来说，真正能交付成果的，才是好工具。我用过不少国内和国外的工具，主要集中在应用层，而不是系统层。像汇编、C 或 C++ 这种底层语言，大模型目前显然还胜任不了。我更多使用的是 Python 加后端相关的应用开发。对我来说，谷歌的模型配合 Claude Code，已经足以覆盖日常工作需求。国内工具并不是不努力，但整体来看，底层模型能力仍然存在一定差距。面对复杂需求时，它们虽然很认真地写代码，但错误率偏高，往往需要我花大量时间去做复杂调整。

实际使用中，我在企业内部更多是用 AI 生成 demo 和高保真原型，而对外项目则是一个纯交付过程。做 demo 时，两三天就能完成一个高保真版本；但如果是用 Claude Code 写一个可交付的应用级项目，通常需要三到四周的时间。

以去年为例，从 9 月、10 月开始，我每个月新增的代码量在 10 万到 14 万行之间，12 月我做了一次大规模重构，直接删掉了 90% 以上的代码。到了今年 1 月份才正式进入交付阶段。那时我加了很多自己整理的 Skill 和规则，按照以往的工程习惯去做可用性检查、漏洞检查、代码复用检查等，再交给 AI 进行修复和优化。

王一鹏：是不是存在某些编程语言天生更适合 AI Coding？

马工：我相信语言、工具，甚至整个软件栈都需要被重新设计，变得对 AI 更友好。Rust 在我看来就是一种非常 AI 友好的语言，因为它可以在编译阶段完成大量验证，只要能通过编译，代码质量就已经明显高于很多语言，这对 AI 非常有利，可以极大降低迭代成本。除此之外，我认为 linker、compiler，甚至操作系统，未来都可能需要重构为 AI 友好的形态。因为现有工具几乎都是为人类设计的，而 AI 的思维方式与人类差异很大，这里面我反而看到了很多潜在的创业机会。

张汉东：Rust 对 AI 友好，很大程度上源于它强大的编译器体系，这为 AI 提供了一个清晰的验证反馈回路。更关键的是，Rust 是以类型系统为核心的语言，而类型系统本质上可以理解为一种逻辑证明。当 Rust 程序编译通过时，意味着它在逻辑层面已经被“证明”过了。

我之前有一个实践案例，让 Claude Code 帮我排查一个运行时才会暴露的问题，编译阶段是发现不了的。这个 bug 我自己没找到，但它大概花了五分钟就精准定位出来了。事后我反思，可能正是因为 Rust 的类型系统和强逻辑性，使得 AI 在推理时能够发现这些潜在问题。

当然，Rust 也有不足，比如缺乏像 Lua 这样的动态语言能力。我们团队也在思考，为 Rust 引入一种可以无缝交互的动态语言，语法接近 GS 这类大模型更擅长的语言形式。安全、稳定的核心部分由 Rust 承担，而快速迭代的业务逻辑则交给动态语言来实现，这也是我们正在探索的一种方向。

3 编程老手们，都怎么用 AI 工具？

王一鹏：大家有没有自己的“AI 工具栈”，几个工具协作使用？实际中，有没有遇到过 AI 工具让你“返工成本比人工更高”的情况？程序员是否需要刻意训练自己更好地与 AI 协作？

松子：我确实有一套自己长期使用的 AI 技术栈，包括多 AI 协同写作，我甚至为此给自己设计并实现了几个协作型智能体。回顾 2025 年 3 月到 5 月那段时间，我刚开始深入大模型编程，可能也受到当时模型基础能力的限制，踩了非常多的坑。几乎每天只有 10% 的时间在生成代码，剩下 90% 都花在调 bug 上。那段时期反而是我从非技术背景跨入技术领域、学习速度最快的阶段。8 月之后，尤其是 Claude Code 3.5 版本出来以后，返工成本高于人工成本的情况基本就很少再出现了。

马工：我实际上是在搭建一个团队，为不同的 AI 赋予不同的人格和职责，有的负责头脑风暴，有的负责架构设计，有的负责编码，有的做测试，有的做质量控制，最后还有一个负责部署。我用 Claude Code 的 sub-agents 来实现这些角色，同时又设计了一个项目经理角色，负责协调整个流程，形成完整的工作流。

这套工作流目前相对固定，但我正在尝试把它做成更具弹性的形态，尽量用 AI 去模拟一个真实的人类团队。整体使用下来我已经非常熟练，也并不觉得返工成本是问题，因为返工本身也是由 AI 来完成，而不是我亲自返工。这套流程我在公司内部的生产环境中已经跑得很顺。

同时，在个人项目中，我还有另一套流程和角色，用于写文章，比如公众号内容创作。我的主要工作，其实就是组织这些“AI 同事”完成任务。

至于具体用哪个模型、哪个工具，在我的理论体系里并不是关键问题。我可以随时切换到其他大模型，最多只是质量稍差一些，或者返工次数多一些。这也是我和很多朋友共同追求的目标：构建一套尽量与具体大模型解耦、依赖度很低的 AI 团队体系。

如果打个比方，就像开一家真实的公司，能招到清华毕业生当然最好，招不到就招 985，再不行还有其他学校，但公司依然可以运转。你不能因为招不到最顶尖的人，就干脆不开公司了，那这个思路本身就是有问题的。

张汉东：通常我会用 Claude Code 做规划，用 Codex 做 review，完成后再回到 Claude Code 去实现。我的工作并不只有开发，还包括代码评审、社区工作，以及与出版社相关的写作任务，因此我也为自己打造了一套完整的 workflow。

这套 workflow 的灵感部分来自 Shopify 开源的一套工具，是用 Ruby 写的。我用 Vibe Coding 把它改成了 Rust 版本，并加入了一些结合我自身工作经验的流程设计。比如出版社给我一份大约 178 页的英文翻译稿，我基于 Claude Code SDK，把任务拆分成五个部分并行处理，大概一个小时就完成了包含格式、内部链接在内的完整中文版。

除此之外，我也用这套 workflow 来做代码 review，以及其他流程固定、但相对琐碎的工作，统一交给 AI 处理。还有一个例子是现在比较流行的上下文 MCP 项目，它是开源的，我同样用 Vibe Coding 把它改成了 Rust 实现，并整合了 Rust 的工具链。这样在做 Rust 代码 review 时，就可以把编辑器之外的各种工具一起纳入进来。

整体来看，这些已经构成了我个人的 AI 工具体系。最近我还在尝试把团队过去两年的经验沉淀成 Skill，正好赶上 Skill 这个概念流行，就把我们在 Rust UI 方向的经验整理成一个 Skill，作为团队共用的 AI 编程基础设施，形成一个共享的工具库。

张汉东制作的 nana banana workflow

王一鹏：Vibe Coding 圈有两种玩法：Lovable/Bolt 那种快速出 Demo 给客户看，和 Claude Code 直接交付生产代码（即 Lovable 模式 vs Coding 模式 ）。你们公司是哪种？有没有两种混用出问题的？

松子：Lovable 是我去年刚开始用大模型编程时常用的工具，现在回头看，那其实就是当时的阶段性选择。去年 4 月我做了第一个 demo，到 8 月和客户沟通时，我尝试用一种“边喝咖啡边聊需求、现场出 demo”的方式交流。这种模式下原型生成速度非常快，客户可以迅速看到大概的形态。

但我当时犯了一个很大的错误，就是在 live demo 之后，直接尝试把 demo 代码演进成生产级代码，结果掉进了一个非常深的坑。后来我逐渐形成了一种方法：live demo 结束后，先进入“包头”状态，对代码做一次完整重构。把 demo 代码直接拿去改成生产级，几乎就是一场灾难。demo 能跑、能看，但架构往往一塌糊涂，在其基础上继续加功能，重构成本甚至比重写还高。所以我的原则是，demo 用完即弃，属于日抛型产物，只用于表达和验证想法。

马工：过去和客户的交互往往需要研发团队支持，现在有了这些非专业编程工具，销售可以自己完成，整体效率提升非常明显。所以我并不完全同意“Lovable 不能用于生产”这种说法。比如销售做一个 demo，本身就是生产，它在业务上的价值，可能比我写一个非常复杂、可扩展的系统还要高。它能够直接促成订单，那为什么不能算生产呢？

当然，它是日抛型的，但依然是生产的一部分，关键是要把这两类场景区分开。你不能一边期望低门槛快速出成果，一边又要求给你一个完美架构。这本质上是期望管理的问题。很多人之所以对 AI 失望，往往是因为在错误的场景里，期待了错误的结果。

张汉东：在做 AI 工具选型时，确实要明确边界。像 Lovable，从名字就能看出来，更偏向于“让人喜欢”的 demo 型工具，适合给非技术决策者或客户展示，比如销售场景下让客户点头认可。它并不关注代码质量，而关注是否能促成决策。如果目标是专业开发，那就需要像 Claude Code 这样的工具，这是两个不同的领域。我虽然没有深度使用过 Lovable，但研究过他们官网开源的 prompt，写得非常好。它解决的正是非技术用户的痛点。就像我前面说的，即便是“海绵式”的代码，它依然能很好地表达意图，在和客户沟通时，往往比文字、图片甚至视频更有效，因为它是可交互的。

王一鹏：几位老师现在是用 AI 帮你们写 prompt，还是主要自己来写？

松子：我是自己写。

王一鹏：为什么不用 AI 写呢？

松子：我试过，但总觉得 AI 写出来的 prompt 太机械，不如自己写得有感情，更有韵味。

马工：我是大量用 AI 写，而且还专门设置了一个角色，把它当作公司的人力资源负责人。当项目遇到困难，或者到了关键里程碑时，我会让这个“人力资源专员”回顾我们的聊天记录，总结可以吸取的经验和教训，并把这些经验嵌入到各个角色的 cloud MD 中。这样每完成一个项目，我的各个 AI 角色都会在能力上有所提升，这是我对人类组织运作方式的一种模拟。

现实中的公司都会在项目结束后做复盘，决定哪些经验要保留，哪些问题下次要避免。在传统组织中，这些通常通过邮件或会议传递。而在 AI 场景里，我是通过固定的 prompt 把这些经验沉淀下来。

王一鹏：听起来马工已经触及到 AI 的本质了，本质上还是仿生学。

马工：对，本质就是模仿人类。很多 AI 技术上的难题，人类其实早就通过管理学和工程学的方法解决过了，我只是把这些方法原样迁移过来，用在 AI 身上。

张汉东：我也是偏向 AI 写 prompt，我的原则是尽量 AI First。但我会对 prompt 做把控，判断哪些是好的、哪些是无效的。如果需要比较专业的 prompt，我会先去网上找成熟案例，再结合 AI 一起改造成适合自己场景的版本。如果效果不好，就当成一次 debug，不断迭代，直到形成一个真正有用的 prompt。

王一鹏：Karpathy 说 AI 在“可验证任务”（如代码、数学）上可能超越人类专家，但在“不可验证任务”（如架构设计、战略决策）上进展缓慢。你们觉得 AI 什么时候能真正理解什么是“优雅的架构”？还是永远不能？

马工：作为工程师，我的核心目标只有一个，就是把问题解决掉。这个问题是用 AI 来解决，还是让同事解决，或者交给软件系统解决，对我来说本质上都只是工具选择而已。我不会为了用 AI 而用 AI，更不会执着于“一定要用 AI 把问题做到世界第一”。如果某个问题 AI 解决不了，那我就直接插入人工。我也认为，去预测三年后的 AI 会发展成什么样并没有太大意义，因为三年内会发生太多变化。更重要的是用好当下的工具和模型，尽快把问题解决，交付一个能够在生产环境中稳定运行的系统，这是我目前最关注的事情。

马工和同事在 coding

松子：以我自己为例，技术团队写完代码后，我再用 AI 或反编译工具去做 review，确实可以发现并修复大量 bug，很多时候甚至重写代码的效果会更好。但在架构设计和战略决策层面，AI 可以给你一百种“正确”的方案，却无法告诉你哪一种才是最合适、最优的选择。这种取舍判断，我认为仍然是人类最后的护城河。所谓“优雅”，在我看来并不是一个技术问题，而更像是一个审美问题。就像“情人眼里出西施”，我看这些大模型，各有各的美感，但在审美判断上，AI 目前确实还不行，它还需要更多训练。

张汉东：首先是 AI 能否理解“优雅的架构”。我以前在编程时，会直接要求 Claude Code 把代码写得更优雅、架构更清晰，它给我的回复基本是：抱歉，我理解不了“优雅”，我只能进行模式匹配，本质上是在模仿人类。也就是说，它并不真正理解人类的审美。

其次，我们本身就不应该指望 AI 去理解什么是“优雅架构”，这本来就应该由人来把控。就像 Anthropic 去年在官网推出的一套课程，其中有一门叫“4D 人机协作”，属于 AI 素养教育，核心是教人如何更优雅地进行人机协作。其中第一个 “D” 叫 Description，强调在向 AI 描述需求时，要明确哪些事情由人来做，哪些交给 AI。我认为这一点非常重要，有些问题本身就不该交给 AI 去理解。

4 用 AI 编程，到底贵不贵？

王一鹏：去年，以 Claude Code 为代表，AI 编程工具的计费逻辑发生调整：从独立 API 计费，到订阅制 + 使用量控制。这些调整背后的动机是什么？另外，这些变化对开发者来说，使用成本是更高还是更低了？支付高额的费用，值不值呢？你用这些工具的时候，会主动关注 Token、调用量或费用上限吗？

马工：我并不认同“Claude Code 很贵”这种说法，这完全取决于你的参照系。我是把它当作一个“人”来看待的。你花 200 美元，根本不可能在任何地方请到一个能稳定写代码的人。从这个角度看，它便宜得不可思议。

目前 Anthropic 的问题在于，Max Plan 在法律上不能用于公司场景，我们公司只能使用 Team Plan，而 Team Plan 的额度又低于 Max Plan，超出部分只能走 API 计费，价格大概贵十倍，这确实带来了一些挑战，只能通过一些变通方式解决。但总体来看，这笔账其实不用算，只要你用得上，它能替代好几个员工。

松子：我个人一直更偏好订阅制。以我自己的真实数据来看，从元旦往前推的一个月内，我大概用了接近 28 亿个 token。如果按 API 计费，那成本会非常夸张；但用 100 美元的 Pro 订阅，对我来说反而是极其划算的。

如果按 API 算，这个工作量可能要几万美元。实际上，这相当于一个五人团队的产出，比如两个前端、两个后端，再加一个产品经理。按月薪 3 万计算，三个月就是 45 万的人力成本，而我用 Claude 只花了 100 美元。

张汉东：在 Code 订阅模式出来之前，我也只能用 API，确实非常贵，有时候只是打开项目又关掉，也会被计费，感觉很不可思议。后来转向订阅模式，哪怕有周限额，只要不是同时推进太多项目，其实是完全够用的。我有一段时间同时做了好几个项目，每天熬到两三点，一个月几乎没怎么睡，甚至还注册了多个账号并行使用，多少有点“薅羊毛”和数据蒸馏的嫌疑，后来我自己也意识到这样不太对，就收敛了，只把精力放在真正重要的项目上。我的建议是，要用就用最好的模型，无论是工作还是学习，否则你用一些中转服务，甚至都无法确认模型是真是假，很容易被掺假。

5全自动 AI 程序员，目前行不通

王一鹏：你们如何看待去年 Devin 这种全自动 AI 程序员的出现？与 Cursor 等人机协作工具相比，各位认为哪一个才是未来企业级开发的主流？你觉得现在的 Agent Coding，是在制造“可演进系统”，还是在制造“未来无人能接手的黑箱”？

马工：关于“无人软件工厂”或“软件黑灯工厂”，我几个月前在公司内部亲自尝试过，结果是非常惨痛的失败。除了 Devin，还有 OpenSWE、NonSmith 等一系列类似的全自动方案，基本没有真正成功的商业案例，更多是自我宣传，没有客户愿意用真金白银为其背书。在我看来，这条路线至少在现阶段没有必要：既然我已经用 AI 替代了 90% 的成本，剩下 10% 插入人工又有什么问题？我们的目标是解决问题，而不是证明“AI 无人工厂”的学术可行性。

王一鹏：当时这个“工厂”失败的具体原因是什么？

马工：第一，AI 在需求理解上极易产生偏差，无论需求文档写得多详细，都无法完全避免。第二，在系统架构上缺乏一致性，不同任务往往采用不同实现方式，即便用规则或 promise 约束，也仍然会出现不遵从的情况。第三，在最终交付质量上，人类能够理解质量是一个光谱，而不是 0 或 1，知道什么时候可以放松、什么时候必须严格，但 AI 缺乏这种上下文感知，表现非常不稳定，难以真正满足客户需求。

这些问题叠加后，你会发现交付结果始终达不到预期。相比之下，在工作流中插入少量人工控制节点，问题就能有效解决，而且成本并不会大幅上升，因为人只负责把控关键节点，而不需要亲自完成大量工作。

松子：我认为全自动 Agent Coding 目前存在下面几个致命问题。第一是没人 review，Agent 自己写、自己测、自己合并，最终谁来负责？第二是上下文严重丢失，十个月后再看代码，可能连 Agent 自己都解释不清楚，黑箱叠加黑箱，已经不是“屎山”，而是“黑洞”。屎山还能慢慢重构，黑洞则只能推倒重来。人写的代码再烂，至少还有责任人；Agent 堆出来的代码，一旦出问题，根本不知道该找谁。

像 Devin 这样的产品，发布时非常惊艳，但真正用起来却是一地鸡毛。简单任务尚可，稍微复杂就开始跑偏，上下文理解和调试能力甚至不如人类工程师，更像是一个需要人时刻盯着的 AI 实习生。从 ToB 企业的角度看，真正合理的形态一定是人机协作：关键节点可控、可维护、可追溯。AI 应该是副驾驶，而不是司机，方向盘必须掌握在人手里。

张汉东：未来三到五年内，人机协作一定是主流，但长期来看，Agent 会成为主流。我之所以这样判断，是因为 Anthropic 推出了系统化的 4D 人机协作课程，这说明在短期内，他们并不认为模型本身会出现足以彻底替代人的突破，否则没必要投入如此多精力去教人如何协作。

但从长期看，Agent 的方向依然非常明确。以 Claude 推出的 Skill 为例，它并不仅仅是 Prompt，而是把人类的能力和经验更精准地沉淀并交给 AI。随着 Skill 的积累和热加载能力的增强，Agent 在特定团队和场景中，已经具备成为主流生产力的潜力，未来甚至可能走向跨行业的通用化。

此外，Anthropic 收购了前端打包工具 Bun，也明确提出“下一代软件基础设施”的概念。结合谷歌、马斯克等公司的动向，可以看到未来的软件形态，很可能是面向 Agent 而非人类 UI 的。这些信号都在指向一个结论：短期内要解决黑箱问题、强调人机协作，但长期演进方向，仍然是 Agent。

王一鹏：有个比较极端的问题，你现在交付的东西，如果有一天 AI 不在了：你自己还接得住吗？还是你已经默认“反正以后也会有更强的 AI”？

松子：如果 AI 突然不在了，我确实接不住，但我也没打算硬接，我一定会去找下一个 AI。与其担心 AI 会不会消失，不如担心自己是否跟得上 AI 的进化速度。对我来说，一个很明显的状态就是每天都在学习新词、新玩法。每天至少两次浏览不同的 AI 网站和论坛，看看大家在讨论什么，从而不断更新自己的认知。

张汉东：首先，我认为 AI 不可能“不在”。从能源、算力以及各国的投入来看，无论是美国、日本还是中国，未来电力和算力只会越来越充沛，因此我并不太担心 AI 会整体消失。更重要的其实是你如何看待 AI，以及你对 AI 的依赖程度。在使用 AI 时，我们必须保留自己的判断能力，同时具备对 AI 输出结果的验证能力。如果 AI 不在了，大不了重新学习，但关键在于：你之前用 AI 写出来的系统和架构，你自己能不能 hold 住？你是否知道该从哪里重新接手？这取决于你在使用 AI 的过程中，是否建立起清晰的心智模型。如果你只是把 AI 当成一个黑箱，那一旦 AI 不可用，你肯定是接不住的。

而且现实中，AI 不可用的情况并不少见，比如账号被封。Claude 封号并不罕见，如果在一周内你的账号被封，而你手头的工作又有 deadline，这时该怎么办？找不到替代 AI，就只能自己顶上。因此，在日常与 AI 交互时，就必须提前做好这种心理和能力上的准备。

马工：AI 本身不会消失，但 AI 在你所在国家或地区的可用性，确实可能成为问题。比如 Anthropic 目前就不向中国提供服务，未来随着地缘政治变化，也不排除出现更极端的情况，你所依赖的某个服务突然完全不可用。

从企业供应链安全的角度来看，通常有两个对策。第一是准备 Plan B，比如智谱目前就主打作为 Claude 或 Anthropic 的替代方案，性能可能只有 80%，但价格只有十分之一。第二是在使用过程中，尽量降低对单一模型的强依赖，让工作流具备足够的韧性，即便切换模型也能完成任务，只是效率略低一些当然，在条件允许的情况下，比如我现在能用 Anthropic，我还是会直接用它，而不愿意花时间去适应那些便宜但体验不佳的模型。

王一鹏：有人说和 AI 多花时间头脑风暴是被严重低估的技巧，“简单功能少聊，复杂功能多聊”。但这不就是产品经理的老本行吗？程序员写代码的时间是不是正在被“和 AI 聊天”取代？另外，当 AI 工具成为习惯后，个人的思维方式需要跟着发生什么变化？顺便给大家一些使用 AI 编程的建议？

松子：简单功能少聊，复杂功能多聊，这本来也是产品经理的基本功。现在的模式是，产品经理先和 AI 深度讨论需求，再与技术团队协作，用 AI 写代码，最后由产品和技术一起审核，协作方式从“沟通产出”变成了“协作产出”。

在技术实现能力上，AI 确实在拉平差距，很多工程师的实现能力被 AI 显著拉近了。但需求表达能力反而成了一种稀缺资源。我们合作的一家央企，原来的“技术团队”已经改名为“需求经理”，他们大约 50% 的时间在和 AI 对话，30% 的时间审查 AI 生成的代码，剩下 20% 用于调试。这并不是降级，而是一种升级，从写代码转向架构和产品思维。

从“怎么写”转向“写什么”，从一次性完成转向迭代逼近。过去关注的是语法、API 和实现细节，现在关注的是业务逻辑、边界条件和异常处理。以前追求完美，现在更强调先让 AI 跑起来，再逐步修正。同时，还有一个明显变化：以前自己想明白就够了，现在必须让 AI 也想明白，这反而倒逼自己的思考更加清晰。在我看来，AI 时代最核心的能力不是写代码，而是把需求说清楚；说不清楚，AI 就会用一堆 bug 来“教育你”。

王一鹏：很像数学学习的过程。早期更多是学习计算方法，比如三角函数，而真正进入数学研究后，重点变成了提出问题、证明定理，并把推理过程表达得清晰、可验证、可被他人理解。现在的开发工作也类似，基础计算可以交给 AI，人只需要关注更高层次的问题。

马工：和 AI 聊天本身并不难，任何人都可以做到，但真正的挑战在于能否形成习惯。你只要有问题就去找 AI 聊，几乎只会有收益，不会有坏处。

我有个朋友，任何事情看到一句话，都会第一时间丢给 AI。我认为这会显著提升你的知识密度和深度，因为 AI 本身就是最“博学”的存在。我也在刻意培养这个习惯。前几天我修洗碗机，就是在 AI 的指导下完成的。我现在也还在思考，AI 在我生活中究竟扮演什么角色：有时是员工，有时是秘书，有时是导师。它并非上帝，但如果你养成这种与 AI 持续互动的习惯，你能从中获得的价值会非常巨大。关键在于，你要主动去找它，把它当作自己的“贵人”。

王一鹏：这其实和大家对 AI 的期望有关。有些人只进行几轮对话，得到不满意的结果就放弃了；有些人愿意聊二三十轮，得到一个 60 分的结果，再自己补到 80 分。但马工对 AI 的期望显然更高，是希望通过多轮对话，最终交付一个接近 90 分的结果。

马工：我在 ChatGPT 里做了定制化设置，明确要求它进行批判性思考、挑战我的观点、不清楚就不要回答，所有结论都必须有来源。我甚至在“塑造”AI 的性格，因为 AI 很容易顺着用户说话，而我刻意要求它不要强化我的偏见，而是帮助我识别并修正偏见。你不能把 AI 当成一个全知全能的神来崇拜，否则一旦结果不符合预期，就会迅速失望并转而寻找“下一个神”。

你之所以向 AI 求助，本身就说明你的认知是有限的，如果 AI 只是顺着你说，只会加固你的局限。你真正需要的是一个既支持你、又挑战你的对象，让你意识到自己可能是错的，甚至从根本上重新审视需求或架构。这也是为什么产品经理往往更适合使用 AI，因为他们从职业生涯一开始就习惯被挑战，而程序员往往不习惯被质疑设计。

张汉东：至于“程序员是否会被 AI 聊天取代”，我并不认同这种说法。实际上，即便在没有 AI 的时代，程序员在写代码前也要先对需求进行内化、建模，这是一个与自己对话的过程，现在只是把这个过程外化为与 AI 对话。过去当我把方案完全想清楚时，往往已经不太想写代码了，因为后面更多是体力劳动；现在有了 AI，我只需要把思路说清楚，代码就可以交给它完成，反而节省了大量时间。

松子：Claude Code 有一个全局配置文档，我在去年 10 月对它做过一次升级。配置中，我为它设定了明确的用户关系和协作角色，并且根据不同关键词加载不同的档案，与 Skill 结合完成不同类型的工作。效果在于，不同工作场景下可以快速切换不同角色和协作模式，比如写书、写文章、处理工作问题或生活问题，都能调用不同的“人格”和配置，提高整体效率。

张汉东：我觉得人格设定本身是有价值的，至少能提醒自己把 AI 当作伙伴。如果我也这么设定，可能就不会动不动骂 AI 了。

马工：我有个朋友正好反过来，给 AI 设定了一个“暴躁老哥”的人格，每次写完代码就让它来骂一遍，效果反而很好。有些场景下并不需要所有人都温和友善，有时确实需要一个“坏人”来提高整体质量。所以这完全取决于你自己真正需要什么。与其照搬别人的设定，不如把你在现实生活中渴望的那种角色，直接写成 prompt，交给 AI。

6“只招会用 AI 的实习生”

王一鹏：AI 生成的代码通常'能跑'，但鉴别它是否'优雅'或'可维护'，反而需要更高的能力。这是不是说明 AI 编程其实提高了门槛而不是降低？导致现在用 AI coding 最爽的是更资深的开发者？

张汉东：我觉得和年龄没有关系，即便把 AI 交给一个三岁小孩，只要他具备语言能力、能够表达自己，就同样可以使用 AI。小孩子的一个显著特点是不断追问“为什么”，本质上就是能够提出真实的问题、表达真实的困惑。这在我看来，是使用 AI 最核心、甚至唯一的重要能力。无论是在个人成长、工作还是职场中，关键都在于你能否觉察到自己真正遇到了什么问题，并把它清晰地表达出来。这听起来或许有些鸡汤，但所谓“活在当下”，本质就是对自身处境保持觉察，并将问题说清楚。

马工：以我个人的经验来看，我们公司已经不再招聘初级工程师，只需要资深工程师。原因其实很简单：从企业角度看，我不再需要能力处在“及格线”的工程师，因为他的水平可能与 AI 相当，甚至低于 AI，而 AI 在编程语言上的覆盖面远远超过个人。企业为此还需要支付较高的薪酬，自然缺乏招聘初级工程师的动力。

之所以我们这些“老登”还能处在第二层，是因为我们的能力确实比 AI 略高，至少可以指导 AI 工作。对企业而言，这种能力是有价值的，而且这种价值会被 AI 成倍放大。但如果每个企业都基于同样的逻辑做决策，就会有大量年轻人长期找不到工作，这将是一个非常严重的社会问题。

松子：入门门槛确实被大幅降低了，同时精通的门槛也被拉低，但天花板却被抬得更高了。现在入门可能只需要十分钟，就能做出一个看起来不错的 Demo 网站，但从“能跑”到“能用”之间仍然存在明显差距，无论是安全性、性能还是可维护性，都还有大量提升空间。

另一个重要变化是中间层的塌陷。过去依靠手速和熟练度生存的那一层工程师，正在被 AI 快速替代。入门者可以借助 AI 很快学会写代码，而中间层却被压缩消失。反而是依靠架构能力和判断力的资深工程师，在 AI 时代变得更加稀缺。AI 拉平了“会写代码”的价值，却显著放大了“判断代码好坏”的价值。因此，我认为 AI 时代最危险的并不是不懂代码，而是以为自己已经懂了。

王一鹏：有人说 AI 不但不会让架构师变多，反而会让架构师更稀缺：不是因为更难，而是“成长路径和回报同时塌陷”，你们同意吗？如果新人都用 AI 跳过基础训练，10 年后谁来当架构师？

松子：AI 并不是让架构师或产品架构、业务架构变得更多，而是让真正具备架构能力的人更加稀缺。这种稀缺性非常反直觉，并非因为事情变难了，而是因为成长路径发生了塌陷。一个行业中专家的数量，往往取决于两个因素：是否存在清晰的成长路径，以及是否有明确且足够的经济回报。像医生、律师这些职业虽然门槛高，但路径清晰、回报明确，因此仍然吸引大量人才。

而 AI 的出现，在一定程度上削弱了这两个条件。新人练手的机会变少了，如果直接依赖 AI 生成代码，就会跳过“如何设计才是最优”的思考过程。这就像计算器普及后，心算能力逐渐退化一样。未来十年，也许并不缺会使用 AI 的人，真正稀缺的是懂得如何教 AI 正确工作的那类人。

马工：现有的职务和头衔体系，可能在未来几年内会被重构，取而代之的是一套新的角色和职称体系。我加入公司时是 leader engineer，但后来我和老板沟通，直接把头衔改成了“AI orchestrator”，工作内容也从传统工程转向管理 AI agents。我相信未来几年会不断涌现新的头衔，而年轻人反而可能更有优势，因为他们没有历史包袱，可以用更 AI 原生的方式去思考。

但在新的体系真正成型之前，会有一个相当艰难的过渡期。年轻人确实会在这几年里大规模地面临就业困难，看不到清晰的上升路径，企业也缺乏培养他们的意愿。以我现在的团队为例，三个人就能完成过去几十人团队的工作，而且效率更高。这实际上意味着，我们无意中减少了大量岗位。如果没有经济层面的重大增长，这种压力在短期内很难缓解。

王一鹏：现在写代码变得简单，难点在于理解代码的现有内容、意义以及修改后可能导致的问题。这会对初级开发者的成长路径产生什么致命影响？AI 是不是正在直接“掐断”初级开发者本该经历的那条成长路径？如果公司都在裁高级工程师、只留应届生 +AI，谁来教新人识别 AI 的坑？"

马工：年轻人探索新路径几乎是必然的，历史上也反复出现过类似情况。比如传统零售行业，过去需要从管理培训生、门店员工一步步做到店长、区域经理。电商兴起后，很多毕业生直接进入平台做“店小二”，反而成长为行业核心力量，并没有走传统路径。我相信软件行业中也一定会出现类似的新路径，只是目前还在探索阶段。

张汉东：从趋势判断上看，短期内人机协作仍然会是主流。在这一阶段，经验丰富的人依然是被需要的。同时，也会有一些年轻人抓住机会创业，他们往往会雇佣具备经验的老工程师。但从更长期来看，如果三到五年后以 Agent 为主流的模式真正成熟，职业结构可能会发生更根本的变化。

今天的架构师主要面向代码，参与人机协作；但未来的架构师，可能不再直接面向代码，而是面向多 Agent、多模态系统，负责整体调度和协同。这种能力并不一定依赖写代码，而更多依赖行业理解、领域知识和一线经验。架构本身并不局限于技术领域，任何行业只要具备架构能力的人，都有可能胜任 Agent 架构的工作。

王一鹏：现在张老师和松子老师所在的团队，还在招聘初级工程师吗？

张汉东：之前我们确实还在招聘初级工程师和实习生，但今年开始，团队的负责人已经明确要求全面推进 AI coding。如果现在还有新人岗位，也必须具备使用 AI 的能力。因为我们的 AI 工作流已经在团队中全面铺开，如果你进来却不会用 AI，基本无法融入工作。现在大家都是 AI 在干活，没有精力再进行传统意义上的手把手教学，有问题直接去问 AI。通过 workflow 和技能体系，整个团队已经高度 AI 化，新人必须跟上这个节奏。

松子：过去新人进来还会有人带，现在几乎没人再教，都是直接跟着 AI 学。另一方面，以前一个项目需要两名技术人员协作完成，现在往往是一个人加 AI 就能独立完成，形成一种“超级个体”的工作模式。新人需要自己负责一个完整方向的产品，并借助 AI 实现。

当前很多年轻人选择创业，背后有几个原因。首先，信息差红利基本消失了。过去创业需要长期积累和信息优势，而现在通过 AI 工具，几乎可以瞬间获得大量信息。其次，创业门槛被大幅拉低。大模型出现后的这两三年，低代码、AI 工具和云服务显著降低了 MVP 的实现成本，使得创业的技术门槛几乎被拉平。在这种背景下，真正的关键反而转向商业模式、业务理解和业务架构。

7 “一人公司”成批出现，年轻人最好的时代

王一鹏：展望 2026，各位认为，今年最确定会发生的三个变化是什么？程序员的哪些能力会进一步被 AI 重塑？ 技术人未来最应该开始学习或加强的能力是什么？

张汉东：过去这一年带来的变化，几乎相当于以往十年的迭代速度，很多事情已经无法预测，任何可能性都有可能发生。不过我仍然坚持一个判断：在未来三到五年内，人机协作依然会存在明确的窗口期。

在这段时间里，我对学生的建议是，首先一定要跟上 AI 的发展，最基本的是你得会用 AI。更重要的是，你要获取第一手信息，必须持续关注 AI 最前沿的动态，并基于这些信息去判断趋势。

其次，你一定要尽量掌握当前最好的 AI 工具，同时建立属于自己的 AI 工作流和学习路径。只有这样，才能顺利衔接后续以 Agent 为主流的发展阶段，知道如何指挥 Agent 工作，并在过程中持续积累行业经验。

马工：我的态度既乐观也悲观。悲观的一面在于，我认为 AI 取代大部分劳动力、引发大规模失业几乎是不可避免的，这一点个人无法改变，社会是否能够适应，这是政治和制度层面的问题。但从乐观的角度看，如果有一些年轻人足够有野心，想真正做出点东西，现在反而是最好的时代。以 AI coding 为例，我并不认为现阶段的工具已经达到了“世界一流”，它们只是暂时领先了半圈，而这是一场马拉松，领先优势随时可能被反超。在这个行业里，我不认为存在真正的权威。年轻人与所谓的世界一流专家，本质上站在同一起跑线上。

我现在特别想做的一件事，是重新构建一套话语体系。比如，为什么一定要有“架构师”这个角色？也许我们会创造出新的头衔和新的定义，年轻人同样可以参与其中。我甚至会认为自己是世界一流的 AI coding 专家，并不是因为我一定最强，而是因为我没有看到明显比我强很多的人。

如果一个年轻人有足够的胆量，想成为新时代的软件工程思想领军人物，现在就是最合适的窗口期，可能只有一到两年，必须立刻行动。一定要获取一手信息，不要只看公众号，不要只接受别人咀嚼过的结论。亲自动手的成本其实很低，只要你自己去实践，就会获得与他人完全不同的体验，通过不断对比，你才能逐渐和别人站在同一水平线上。如果你只是跟着某位名人说什么就做什么，那永远都会慢一步。更何况，很多观点本身也带有立场和商业目的。

另外，如果你真的想探索这个方向，不要只输入、不停地听，还要输出、去表达。讲对讲错并不重要，也不存在标准答案。只要你的观点足够有逻辑，就能吸引到志同道合的人，甚至走向创业。我认为，对于真正有目标、有野心的年轻人来说，这是一个极好的时代。

松子：AI 编程正在成为标配，已经不再是加分项，而是基础能力。中间层开发者正在大规模转行或被淘汰，“一人公司”会成批出现，这种趋势已经在现实中开始显现。在这样的背景下，最大的挑战在于学会如何与 AI 协作，并把更多时间投入到业务理解上。真正理解业务的人，才能告诉 AI 应该做什么。

归结为一句话，就是要放下对手工写代码的执念，从“敲键盘”转向“拿指挥棒”。在 2026 年，真正具备竞争力的，不是单纯写代码的人，而是能够指挥 AI 写代码、并把握方向的人。

会议推荐

InfoQ 2026 全年会议规划已上线！从 AI Infra 到 Agentic AI，从 AI 工程化到产业落地，从技术前沿到行业应用，全面覆盖 AI 与软件开发核心赛道！集结全球技术先锋，拆解真实生产案例、深挖技术与产业落地痛点，探索前沿领域、聚焦产业赋能，获取实战落地方案与前瞻产业洞察，高效实现技术价值转化。把握行业变革关键节点，抢占 2026 智能升级发展先机！