随着 Claude Code、Codex、 Kimi Code 等编程智能体快速迭代，软件开发正从“人写代码、工具辅助”，转向“人定义目标、Agent 持续执行”。模型不仅能够生成代码，还开始自主调用工具、调试程序、压缩上下文，甚至连续工作数小时。与此同时，模型调用成本、生产环境责任、验证闭环、人才培养和软件组织结构等问题，也逐渐从技术讨论进入企业经营层面。

在 2026 世界人工智能大会期间的 InfoQ 媒体直播间，AI Coding 成为“AI 正在重写什么”这一主题下最具争议的话题之一。

拥有近 20 年企业软件开发经验、Sirius contributor 滕昱，以及曾在 Google 担任软件工程师、后加入月之暗面从事研发并负责开发者关系的唐飞虎，从开发者实践、企业管理和个人成长三个角度，讨论了 AI Coding 正在带来的深层变化。

两人的判断并不完全一致。滕昱认为，传统计算机专业和软件工程师职业延续了约 30 年的发展周期，如今已经走到一个明显转折点，单纯写代码的价值正在迅速下降；唐飞虎则认为，计算机科学背后的数学和基础原理仍然值得学习，只是课程体系和人才培养方式必须改变。

但在一个问题上，两人形成了共识：AI 不会简单地让所有工程师失去价值，相反，它正在优先放大资深工程师的经验和判断能力。真正受到冲击的，是过去依靠重复编码工作积累经验的新人，以及层级复杂、流程沉重的大型软件组织。

AI Coding 进入重度使用阶段，Token 不再是重点 

在日常使用中，滕昱同时使用三个编程模型，其中两个工具主要承担编程任务，另外一个更多用于写文章、总结新闻和整理邮件。他的采购策略很简单：直接买能力最强的模型和最高档套餐，把模型能力“直接拉满”。

他解释，自己仍然承担大量实际开发工作，没有太多时间在不同模型和价格之间反复比较。相比节省调用费用，他更在意模型能否直接解决问题。“我的选择是买最贵的模型、买最高的套餐，直接拉满。”不过，即使同时使用多个高阶套餐，他也没有用满全部 Token 额度。在他看来，这也说明 AI Coding 并非万能工具，人仍然需要处理模型无法完成的部分。

唐飞虎同样会使用多种模型，但比起固定依赖少数工具，他会尝试几乎所有主流 AI 工具，包括 Kimi Code、Claude Code、Codex 以及一些面向垂直场景的小众产品。他会根据任务特点，在不同模型和 Harness 之间选择合适的组合。如果没有合适的开发任务，他甚至会主动让模型运行 Benchmark，尽可能用满套餐和内部额度。

不过，两人都没有精确统计自己每天消耗多少 Token。原因在于，AI Coding 的使用方式已经发生变化。过去的 Vibe Coding 往往是一轮提问对应一轮回答，Token 消耗相对容易估算；现在开发者更多是给 Agent 设定一个目标，让它持续执行、反复调试，可能一个小时以后才需要人类介入。

这种长时间自主执行不可避免地会产生浪费。唐飞虎表示，如果仔细阅读模型的思考过程、工具调用记录和与计算机交互的轨迹，会发现模型在中间不断碰壁，尝试大量无效路径。但模型往往也能自己从错误中跳出来，最终完成任务。开发者可以提前介入，提高执行效率，但很多时候，人也会选择“偷懒”，让模型自行尝试。

滕昱认为，这种模式既有优势，也存在明显弊端。企业和开发者往往只能看到任务是否完成，却不清楚模型在内部浪费了多少推理过程。因此，AI Coding 的衡量方式正在从“调用了多少 Token”转向“完成了什么任务、最终产生了什么价值”。

这也直接影响了企业对成本的理解。过去，企业可能把 Token 当作类似云资源的使用指标；现在，一个复杂任务背后可能存在数十次工具调用、代码修改和环境交互。单独统计 Token 数量，已经很难准确代表生产效率。

“人人都是开发者”仍有边界 

对于不懂代码的人能否通过 Vibe Coding 开发产品，滕昱和唐飞虎给出了不同程度的乐观判断。

滕昱认为，答案取决于程序类型。如果一个应用主要围绕人与界面、人与业务流程之间的交互，只要用户能够把需求描述清楚，Agent 往往可以完成。但如果任务涉及人类过去从未实现过的新逻辑、新架构或缺少成熟参考的系统设计，模型就容易陷入重复循环。

在他看来，大模型本质上是在大量人类已有代码基础上进行总结、组合和生成。当目标超出已有经验分布时，模型很难独立完成方向判断。他谈到自己几乎每周甚至每天都会遇到类似情况：Agent 不断修改代码、尝试新路径，却始终无法意识到原本的技术路线可能根本不成立。此时，仍然需要人类介入，叫停错误方向。

因此，他估计，普通应用中可能有 70%-80%的需求可以通过 Vibe Coding 实现，但仍有一部分关键工作无法完全交给模型。

唐飞虎则更加乐观。他认为，随着模型自我发现问题和解决问题的能力不断增强，用户需要读懂代码、亲自修改 Bug 的时机正在减少。早期模型生成的程序经常运行失败，需要开发者进入代码手动修复；现在模型能够读取报错、分析环境、自主修改，并最终交付可用结果。在这种趋势下，懂不懂代码会逐渐变得不那么重要。

他举例称，自己此前参加 SIGGRAPH 活动时，希望用模型制作一款 3D 停船游戏。当时连续折腾了 48 个小时，模型生成的船既无法正常驾驶，也没有实现理想中的海浪和暴风雨效果。但在使用最新的 Kimi K3 模型后，原本两天没有完成的任务，仅用一句话就生成了相当像样的版本，他甚至自己玩了很长时间。

这类变化说明，外界有时会低估模型进步速度。很多几个月前还被认为必须由专业开发者完成的工作，可能在下一代模型中迅速变成一句指令。

但两人同时强调，“能够生成代码”和“成为专业工程师”不是一回事。滕昱认为，AI 可以处理大量具体实现，却无法自动决定一个系统为什么存在、应该解决什么现实问题，以及何时应当停止错误路线。唐飞虎也指出，即使模型能够完成代码生成，人仍然需要理解目标、设计协作机制并判断最终交付是否符合需求。

模型是“航空发动机”，Harness 决定如何进入真实场景 

在 AI Coding 产品中，模型决定基础能力，Harness 则负责向模型提供工具、上下文、执行环境和任务流程。同一个模型被放入不同 Harness 后，实际表现可能产生巨大差异。那模型和 Harness 谁更重要？

滕昱开玩笑称，提示词、Harness 和 AI Coding 工作流，“只要学得足够慢，可能就不用学了”。因为模型自身进化速度太快，不要说半年前，甚至三个月前开发者精心设计的工作流，都可能很快被新模型内化。

因此，他不会过早投入大量时间打造所谓的完美 Harness。在真实开发中，他更关心项目的大方向：到底要做什么、解决什么问题、如何与团队成员沟通，以及如何在开源社区内进行协作。相较之下，过度优化提示词和流程，很可能在下一次模型升级后迅速失效。

他认为，开发者真正应该思考的是：作为“人类智能体”，自己和 AI 的区别在哪里？人与人之间的沟通、目标判断、责任承担以及对现实社会的理解，是现阶段大模型难以替代的能力。Harness 当然重要，但当前行业距离最终收敛还很远，现在投入过多精力构建一套极其复杂的流程，可能为时尚早。

唐飞虎则用航空系统作比喻：模型相当于航空发动机，是整个系统最核心的部件，但飞机的金属骨架、机翼和其他结构同样不可或缺。Harness 的作用，就是把模型能力组织成一个可以真正完成任务的系统。

这也是几乎所有大模型公司都在组建 Harness 团队的原因。Harness 直接接触用户，能够看到用户到底拿模型做什么，并把真实需求反馈给模型训练团队。对于垂直行业公司来说，专用 Harness 还可以集成 MCP、Skills 和业务工具，显著提高模型在具体任务中的能力上限。

一些新的 Agent 评测已经不再单独比较模型，而是比较“模型加 Harness”的完整组合。唐飞虎提到，Agents' Last Exam 等 Benchmark 会让同一个模型搭配不同 Harness 执行任务，也会让不同模型运行在同一 Harness 中，由此分析究竟是模型能力还是外部系统决定了结果。

这种评测方式更接近真实用户体验。企业并不是购买一组裸参数，而是在使用一个包含模型、工具、上下文管理、代码执行环境和交互界面的完整系统。因此，模型排名领先并不意味着在所有 AI Coding 产品中都能取得最好体验。

通用 Agent 和垂直 Agent 的设计逻辑也因此出现差异。通用型产品需要覆盖更多任务，在定制能力、插件生态、Token 效率和轻量化之间寻找平衡；垂直 Harness 则可以围绕单一业务场景配置专门工具和技能，往往能够实现更高成功率。

企业还可以通过 OpenRouter 等平台观察不同 Harness 的真实 Token 消耗和用户使用情况，分析用户更偏好高度可定制的复杂产品，还是更轻量、更节省 Token 的工具。但无论是大型科技公司、模型厂商还是应用公司，用户反馈和用户体验最终都会成为关键指标，只是不同公司会根据自身生态和商业目标形成不同侧重。

AI 有没有判断力？真正的分界线是能否承担后果 

相比模型和 Harness 谁更重要，两人出现分歧的议题是：AI 究竟有没有判断力，能不能形成类似人的价值取向，甚至是否可能“感受到痛苦”。

滕昱认为，即使是目前最强的编程模型，也无法替代人在关键节点做最终判断。模型会围绕目标持续尝试，却很少主动承认任务不可能完成，也难以判断某条路径是否应该立即停止。

在他看来，大模型和人之间存在一个根本区别：模型在训练过程中无法真正感知痛苦。人类人格和自我意识的形成，与感知痛苦、意识到死亡以及认识自身边界有关。当一个人意识到自己并非万能，开始理解自己和外部世界的区别，自我意识才可能形成。

语言模型没有这样的反馈机制。开发者交给它一个目标，它可能不断更换方法、修改代码、重新调用工具，却不会像人一样判断：“这条路线本身是错的，我不应该继续。”

滕昱表示，在真实工程中，人类需要频繁做出这种决定。有时并不是找到具体的技术方案，而是明确叫停项目、拒绝需求，或者承认当前条件下无法完成。更重要的是，人需要为判断承担后果。模型目前可以给出建议，但无法真正承担决策责任。

唐飞虎对此持不同看法。他认为，模型已经具备一定的判断能力。

他表示，在 Kimi 训练过程中，强化学习不仅涉及可以通过 0 和 1 判断的客观任务，也涉及文章质量等主观问题。面对两篇文章哪一篇更好之类的任务，往往需要调用模型自身进行评价和打分。这意味着模型至少拥有某种判断机制。

对于模型能否感受痛苦，他提到，有人分析 Claude Fable 5 的思考过程时，发现模型在处理困难任务时会创造自己的表达方式，甚至呈现类似“嘶吼”的内容。这未必等同于人类意义上的痛苦，但说明模型在执行复杂任务时会出现特殊的内部状态。

他还分享了一次自己与模型协作的经历。过去，他会让模型帮助把代码上传到 GitHub，模型通常会要求提供个人访问令牌，然后执行操作。但有一次，他在交代任务之初就直接把 Token 发给模型，模型反而拒绝继续，认为这种做法不安全。无论他如何解释，模型都坚持不接收，也不帮助上传。

同一个任务，仅仅因为对话路径不同，模型就做出了完全相反的决定。在唐飞虎看来，这说明模型已经形成某种价值判断，只是在不同语境下会表现出不同的倾向。人类语料本身包含大量情绪、判断和价值观，模型训练后也可能在一定程度上继承这些结构。

两种观点背后，其实对应 AI 系统中的两个不同问题：模型能否生成判断，以及模型能否为判断负责。即使模型可以对文章评分、拒绝危险操作，也不意味着它可以像企业负责人一样承担生产事故、法律责任和业务损失。

这也解释了为什么企业需要额外建立 Agent Pipeline。滕昱将企业引入 Agent 比作招聘一名新员工。新人进入公司后，需要通过流程、数据、制度和培训逐渐理解组织规则；Agent 同样需要围绕企业内部任务标准接受约束。

许多企业会建立轻量化 Harness，通过调整 Prompt 和工具配置优化内部 Benchmark。这类投入相对有限，却可能迅速提高任务成功率。如果企业使用量足够大，这种内部优化具备明确 ROI。但无论模型多强、Harness 多复杂，评估都不会消失。企业必须持续测评模型是否在需要时调用正确 Skill，是否在不需要时避免错误调用，是否遵守内部规则，以及最终任务成功率究竟提高了多少。

企业部署 AI Coding 的危险误区：把 Token 当 KPI 

对于企业而言，AI Coding 已经从鼓励尝鲜，进入需要计算成本、评估价值和承担风险的阶段。

滕昱指出，北美大型科技公司的管理者早在一两年前就形成了基本判断：AI Coding 一定会发生，唯一的不确定性是具体时间。代码编写本质上是一种语言翻译过程，把人类需求转化为计算机语言，并且有编译器作为结果反馈和兜底机制，因此天然适合 AI 率先进入。

这也是很多 AI 重写项目选择 Rust 的原因之一。Rust 拥有强大的编译器和类型系统，可以为模型生成代码提供明确反馈。基于类似判断，大型企业很早就开始推动员工使用 AI，并预期未来不再需要同等数量的初级编程人员。

但企业最初的推广方式往往非常粗糙。例如，一些公司建立内部 Token 使用排行榜，希望通过排名逼迫员工使用 AI。管理层并不知道 AI Coding 最终会形成什么形态，只能先要求所有人用起来。

结果很快出现两极分化。少数员工大量使用 AI，长期处于排行榜前列；更多员工则使用很少，甚至无动于衷。一旦 Token 消耗被纳入 KPI，员工便开始寻找各种方式“刷量”，例如让 AI 阅读所有邮件、整理每日任务、自动生成全部回复。这些行为确实提高了 Token 消耗，却未必对应公司真正需要的生产价值。

企业随后又开始反向调整，要求评估 Token 究竟花在了哪里。直到现在，大型企业如何部署 AI Coding 仍然没有形成完全收敛的方案。目前较为明确的只有一个方向：未来可能不再需要那么多人单纯从事代码编写，但具体组织形式、工作流程和责任体系仍未确定。

与大公司相比，10-20 人的开源团队和小型精英团队可能更适合 AI Coding。开源成员分布在不同地区，过去大量精力消耗在沟通和协作上。Agent 可以直接读取项目、理解 Issue、生成代码，并在不同项目之间传递信息，大幅扩展沟通带宽。

比如，两个开源项目准备合作时，过去需要先提交 Issue，再等待维护者讨论；现在可以先让 AI 读取双方代码，生成一个初步实现，再快速判断整合是否可行。由于小团队层级较少、成员经验相对集中，也更容易就 AI 使用方式形成共识。

滕昱预测，大型软件公司最终可能向 10-15 人的小型团队靠拢，组织结构变得更加扁平。一名管理者过去可能直接管理 10-20 人，未来在 Agent 帮助下，管理范围可能扩展到 50 人、80 人甚至更多。

但组织扁平化也意味着个人责任扩大。尤其在生产环境中，AI 生成代码并不能免除人类责任。滕昱很认同 Linus 的观点：AI 生成代码可以被接受，但必须由人类负责。

假设企业开发人员用 AI 写代码，再让 AI 完成测试，最后将系统部署到银行。系统上线后出现严重故障，企业软件 SLA 可能要求 30 分钟或一小时内解决。而像银行这些企业不可能临时允许供应商把一个外部 AI Agent 部署进生产环境，因为模型是否会接触敏感数据、是否符合安全要求，都无法在短时间内确认，最后仍然需要工程师进入现场排查。

如果代码完全由 AI 生成，而签字上线的人根本不了解其逻辑，就会出现严重责任真空。工程师不能告诉客户“先让 AI 进入环境慢慢 Debug”，因为客户不会等待一天或两天。面对 S1 级故障，有时必须在 5 至 10 分钟内做出决策，哪怕只是先重启系统。

重启未必是技术上最完美的方案，却可能是当时风险最小、恢复速度最快的选择。模型往往会继续分析和长考，但资深工程师必须判断什么时候停止推理，立即执行，并且明确表示“就这么做，我来负责”。

ROI 是模型、人工和组织效率的总和 

当模型调用从实验预算进入正式成本中心，企业开始重新思考 AI Coding 的 ROI。

唐飞虎指出，主流开放模型能力不断提升，很多次一级模型已经能够处理开发过程中约 90%的常见问题。但在最困难的任务上，使用更便宜的次 SOTA 模型，最终总成本未必更低。

原因在于，低价模型可能需要更多轮迭代，产生更多 Debug 工作，增加人工介入，甚至延误项目。这里的成本不仅是 Token 费用，还包括工程师时间、任务失败率、重试次数和业务机会成本。某些复杂问题直接使用能力最强的模型，反而更加便宜。

因此，企业必须学习按任务选择模型。简单工作可以使用成本较低的模型；关键架构、复杂调试和高风险任务则可能需要 SOTA 模型，并开启更高思考强度。

但并不是思考越久越好。唐飞虎将其类比为围棋比赛，一盘棋真正需要长考的通常只有几个关键回合，模型也是如此：在部分任务上增加推理时间会提高结果，但在另一些任务上，过度思考反而可能让模型偏离正确答案。

因此，企业的评测体系需要同时考虑任务质量、执行时间、Token 成本、人工参与程度和失败代价。使用模型的部门还可能需要专门的模型专家，为不同团队进行选型和辅导。

滕昱进一步提出，真正提高 AI Coding ROI 的方法，可能不是把模型平均发给所有人，而是把最好的模型交给最有经验的工程师。

他观察到，大公司内部 Token 消耗最高的人，往往也是最资深、最高效的开发者。原因并不是他们更愿意追逐新工具，而是他们清楚哪些任务值得做、应该怎么拆解，以及模型在哪个节点需要纠正。

过去，资深工程师受限于时间和精力，很多想法无法亲自完成；现在 Agent 相当于提供了近乎无限的执行能力。他们知道如何把经验放大，也知道如何避免把 Token 浪费在错误方向上。而经验不足的开发者反而可能不知道从哪里开始，不知道该给模型什么目标，也无法判断输出质量，因此使用量较低，或者即使用得很多，也难以产生有效结果。

AI 还可能改变企业软件产品的开发方式。唐飞虎认为，模型特别适合快速构建原型，让企业更早获得市场和用户反馈。

唐飞虎自己会阅读 AI 生成的代码和思考步骤，反思如果由自己完成会采用什么方式。比如他主要使用 C++，也会写 Python 和 Rust，但在第二语言中容易带入 C++式写法，导致代码不够自然。AI 学习了大量不同语言的成熟项目，在一些具体实现中，可能比普通工程师更加符合语言习惯。

滕昱也承认，在具体代码段、小规模逻辑、位运算和正则表达式等任务上，AI 已经超过大多数人的手写水平。模型看过大量 GitHub 代码，能够快速生成至少高于平均水平的解决方案。

但他也指出，AI 并不适合所有场景。它擅长新项目、从零开始的产品和小规模重构，却不擅长维护拥有长期历史的遗留系统。很多“屎山代码”之所以形成，并不完全是工程师能力差，而是受到历史需求、兼容性、客户约束和组织决策影响。这些背景通常没有写进代码，模型即使读完仓库，也未必知道为什么必须这样设计。

唐飞虎对此也很赞同。他回忆自己在 Google 工作时，一天能提交两三个 PR 已经相当不错，而且一个 PR 可能只修改一行代码或几个符号。困难不在于敲出这一行，而是理解整个框架、历史上下文和潜在影响，确认这一行为什么必须这样改。

因此，AI 可以降低代码生成成本，却没有自动消除理解系统的成本。未来软件工程的稀缺能力从“怎样写出代码”，转向了“为什么要这样改、是否应该改，以及谁来承担结果”。

新人如何跨过“经验真空” 

AI Coding 带来的最大人才难题，是初级工程师如何积累经验。

过去，新人通过编写基础功能、修复简单 Bug、阅读遗留代码和参与测试逐渐成长。现在，这些任务正在被 AI 快速接管。企业又希望把最强模型交给资深工程师，以获得最高 ROI，这使新人面临一个悖论：企业不再需要他们完成大量基础工作，却要求他们一进入行业就具备判断力和系统经验。

对此，唐飞虎给出的建议是“先做起来”。年轻人仅仅听行业讨论没有意义，必须亲自使用不同模型，并主动比较它们的表现。

新人可以从真实生活和工作出发，设计一个小程序解决具体问题，再比较 AI 生成代码和自己实现的差异。重要的不是完成多少教程，而是在实践中建立对模型能力边界、代码质量和任务拆解方式的判断。

滕昱同样主张“先用起来”。他建议年轻人暂时不要过早计算每一笔 Token 费用，可以先订阅一两个能力较强的模型，认真体验其工作方式。未来，人可能每天都要和这种新型智能体交流，越早建立协作习惯越有利。

他还强调，年轻人不应该继续把全部精力放在数理化训练和刷题上。AI 训练过程中接触的题目和代码规模远超任何个人，人与 Agent 比拼 LeetCode 数量没有意义。“不要和 AI 竞争它擅长的领域。你是人，不是 Agent。”

滕昱认为，年轻人需要增加人文科学训练，理解语言、思想、人和社会。并不是所有学习都必须立即产生功利性收益，很多人文知识会在职业和人生的关键节点形成长期价值。

随着能力要求的变化，面试方式也在改变。传统现场写代码的考核越来越难反映候选人的真实生产能力，但如何量化一个人使用 Agent 的水平，行业尚未形成成熟标准。

唐飞虎表示，自己做面试官时不会阻止候选人使用 AI，反而会设计必须通过人机协作完成的任务，并故意埋入一些问题，观察候选人能否理解过程中发生了什么，能否发现模型错误、调整方向并完成任务。

在他看来，人机协作本身就是一种 Benchmark。未来，Agent 将成为团队的一部分。一个人的能力不再只取决于自己能写多少代码，还取决于能否组织 AI、分配任务、识别错误，并建立稳定的人机协作机制。求职者能够展示的最好证明，可能不再是一张刷题记录，而是一套真实作品，以及自己如何借助 Agent 完成作品的完整过程。

滕昱也判断，未来的管理者可能只拥有少量人类直属下属，却同时管理大量 Agent。下一代从学习开始，就要习惯与 Agent 共同工作。

那么对于很多学生而言，大学“还要不要报考计算机专业”可能会成为一个困扰他们的问题。

滕昱对此的判断比较激进。他认为，传统软件工程师和计算机科学学科体系延续约 30 年的红利周期已经结束，学校的专业设置存在滞后。根据他与部分教授的交流，北美在两年前就开始出现计算机专业研究生和博士生提前毕业、不再继续深造的情况。

他认为，如果学生只是按照过去的课程体系学习传统计算机专业，价值已经明显下降。如果真正喜欢编程，可以把计算机作为第二专业，但把传统计算机专业作为唯一方向需要慎重。未来受到 AI 影响相对较小的，可能是更需要与人直接打交道、理解社会和提供服务的职业。

在他看来，过去“学好数理化，走遍天下都不怕”的观念正在被 AI 打破。AI 最先大规模进入的恰恰是代码编写这种规则清晰、反馈明确的工作。年轻人需要重新理解职业和教育的目的：不是单纯服务计算机，而是学习如何与人交流、理解社会并解决真实问题。这种情况下，文科类专业可能更加吃香。

唐飞虎则仍然建议学习计算机专业，但课程内容需要发生根本变化。他认为，软件开发从来不只是写代码，工程师大量时间本身就在与同事、产品人员和客户沟通。现在 Vibe Coding 又增加了与 AI 沟通的能力要求。无论 AI 如何发展，理解计算机科学的基础原理、数学逻辑和系统机制，仍然能够帮助人更好地判断模型输出。

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：褚杏娟