AI Coding 重塑开发：Token 不再是核心，资深工程师更值钱

随着 Claude Code、Codex、Kimi Code 等编程智能体快速迭代，软件开发正从「人写代码、工具辅助」，转向「人定义目标、Agent 持续执行」。模型不仅能生成代码，还开始自主调用工具、调试程序、压缩上下文，甚至连续工作数小时。在 2026 世界人工智能大会（WAIC）期间的 InfoQ 媒体直播间，拥有近 20 年企业开发经验的 Sirius 贡献者滕昱，以及曾在 Google 任软件工程师、现就职于月之暗面负责开发者关系的唐飞虎，围绕 AI Coding 正在带来的深层变化展开对话。

Token 不再是衡量标尺

滕昱同时使用三款编程模型，其中两款主攻代码，一款用于写作、新闻摘要和邮件整理。他采取的采购策略很直接：买能力最强的模型和最高档套餐，把能力「拉满」。即便如此，他也没有用完全部 Token 额度，说明 AI Coding 并非万能，人仍需处理模型无法完成的部分。

唐飞虎则会广泛尝试 Kimi Code、Claude Code、Codex 等主流工具及部分垂直产品，按任务特点在模型与 Harness 之间组合搭配。

两人都未精确统计每日 Token 消耗。原因在于使用方式已从「一轮提问、一轮回答」的 Vibe Coding，转向「设定目标、Agent 持续执行」，可能一小时才需要人类介入。这种长时间自主执行难免产生浪费：如果细看模型的思考过程和工具调用轨迹，会发现它不断碰壁、尝试大量无效路径，但最终也能自己跳出错误完成任务。

因此，AI Coding 的衡量方式正从「消耗了多少 Token」转向「完成了什么任务、产生了什么价值」，企业也必须重新理解单次复杂任务背后数十次工具调用所对应的真实成本与效率。

「人人都是开发者」仍有边界

对不懂代码的人能否用 Vibe Coding 做出产品，两人给出了不同判断。

滕昱认为，如果应用主要围绕人与界面、业务流程的交互，只要需求描述清楚，Agent 通常可以完成；但遇到新逻辑、新架构或缺少成熟参考的系统设计，模型容易陷入重复循环。他估计普通应用中约 70%–80% 的需求可由 Vibe Coding 实现，仍有关键工作无法完全交给模型。

唐飞虎则更乐观。他举例称，此前在 SIGGRAPH 期间用模型做 3D 停船游戏，连续折腾 48 小时也未能让船正常驾驶或生成理想海浪；使用最新的 Kimi K3 模型后，仅用一句话就生成了相当像样的版本。他指出，很多几个月前还被认为必须由专业开发者完成的工作，可能在下一代模型中迅速变成一句指令。

但两人同时强调，「能生成代码」与「成为专业工程师」不是一回事。AI 可以处理大量实现，却无法自动决定系统为什么存在、应解决什么现实问题，以及何时应当叫停错误路线。

模型是「航空发动机」，Harness 决定如何落地

滕昱开玩笑说，提示词、Harness 和工作流「只要学得足够慢，可能就不用学了」，因为模型自身进化太快，三个月前精心设计的工作流就可能被新模型内化。他更关注项目大方向、团队沟通与开源协作，而非过度优化流程。

唐飞虎用航空系统作比喻：模型相当于发动机，Harness 则是把模型能力组织成可执行系统的金属骨架与机翼。这也是几乎所有大模型公司都在组建 Harness 团队的原因——直接接触用户、收集真实需求并反馈给训练团队。

新的 Agent 评测方式也在改变。例如 Agents' Last Exam 等基准会让同一模型搭配不同 Harness、或让不同模型运行在同一 Harness 中，以分辨能力究竟来自模型还是外部系统。这种评测更贴近真实体验：企业买的不是裸参数，而是包含模型、工具、上下文管理、代码执行环境和交互界面的完整系统。

AI 有没有判断力：分界线是能否承担后果

滕昱认为，即便是当前最强编程模型，也无法在关键节点替代人的最终判断：模型会持续尝试，却很少主动承认任务不可能完成，也难以判断某条路径是否应立即停止。在他看来，大模型与人之间存在根本区别——模型在训练中无法真正感知痛苦，缺乏形成自我意识的反馈机制。人类需要为判断承担后果，而模型目前可以给出建议，却无法真正承担决策责任。

唐飞虎持不同看法。他提到，在 Kimi 训练中，强化学习涉及文章质量等主观任务，模型需对自身输出进行评价打分，说明它已具备一定判断机制。他还分享了一次协作经历：以往让模型帮忙上传代码到 GitHub 时，模型会索取个人访问令牌；有一次他主动把 Token 发给模型，模型反而拒绝执行，认为做法不安全。同一任务，仅因对话路径不同，模型就做出完全相反的决定。

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

企业部署陷阱：别把 Token 当 KPI

滕昱指出，北美大型科技公司管理者早在一两年前就判断 AI Coding 一定会发生，唯一不确定的是时间——代码本质上是人类需求到计算机语言的翻译，且有编译器作为结果反馈，因此天然适合 AI 率先进入。

但企业最初的推广方式往往粗糙，例如建立内部 Token 使用排行榜，逼迫员工使用 AI。结果两极分化：少数人大量使用并长期居榜首，更多人使用很少或无动于衷。一旦 Token 消耗被纳入 KPI，员工便开始「刷量」，如让 AI 阅读所有邮件、自动生成全部回复，提高了消耗却未必对应真实生产价值。企业随后又反向调整，开始评估 Token 究竟花在了哪里。

目前大型企业如何部署 AI Coding 仍未完全收敛，较为明确的方向只有一个：未来可能不再需要那么多人单纯从事代码编写，但具体组织形式、工作流程与责任体系仍在探索之中。