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

本文来自微信公众号： InfoQ ，编辑：宇琪，作者：褚杏娟、Tina，原文标题：《停招初级工程师！大厂样板无实战价值、软件黑灯工厂死路一条，三位AI 编程老炮：AI越骂越灵！》

在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会发展成什么样并没有太大意义，因为三年内会发生太多变化。更重要的是用好当下的工具和模型，尽快把问题解决，交付一个能够在生产环境中稳定运行的系统，这是我目前最关注的事情。

松子：以我自己为例，技术团队写完代码后，我再用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写代码、并把握方向的人。

责任编辑：

文章来源：http://www.jingmeijuzi.com/2026/0201/2155.shtml