上午见了朋友，下午回来听了字节火山引擎的 FORCE 大会。
发什么模型、产品，我不展开了，你随便 AI 一下就都有了；有个数字，外面聊得少，字节技术副总裁洪定坤说的。
01
洪定坤，在字节研发线的级别是最高的那一档，也是 AI 编程工具 TRAE 的负责人；他在台上扔了一个数据：他们团队过去半年，代码贡献率超过了 90%。
什么概念？
就是他们写的代码，十行里面有九行是 AI 搞出来的，这个数字后面，还跟了另一个；人均需求吞吐率，提升了 60%，大概 1.6 倍。
第一眼看，60%，不错啊。再一想，不对。
股票投资配资AI 写代码比人快，快十倍都说少了；你一个团队 90% 的代码都是 AI 写的，效率提升应该是几倍，往少了说也该翻个两三番。
为什么只有 60%？
洪定坤没藏着掖着，台上说得很实在：这个数字不代表我们 AI Coding 就搞得很好了，恰恰是越用，越知道里面的坑在哪。
90% 跟 60% 之间，夹着什么？
我翻了一下资料，有个叫 METR 的非营利机构，做过一个特别严的实验。
2025 年，找了 16 位资深的开源项目维护者，在自己最熟的代码库上干活，一半任务能上 AI，一半不行，纯随机分配。
结果呢？用 AI 那组，反而慢了 19%；更绝的是，这帮人自己觉得快了 24%。
自己觉得自己快了四分之一，实际上慢了快五分之一；中间差了四十多个百分点，你就说离谱不离谱？
这个实验在圈子里炸了一大片。2026 年 2 月 METR 更新了数据，样本放大了，结果好看了点，变成大概慢 4%，统计上已经说不上显著了。
METR 自己也认，说他们相信 2026 年初的 AI 工具应该是真的有提升的。
好玩的是这实验后来自己把自己玩没了，30% 到 50% 的受邀开发者，直接拒绝在没有 AI 的条件下干活，对照组凑不齐人了。METR 只能宣布重新设计整套实验方法。
这事本身就挺说明问题的，对吧？
我又扒了另一份报告；今年年初的，Opsera 出的行业基准报告，分析了 25 万开发者的数据。
AI 工具在全行业的用上率已经到 90% 了，行业平均的 ROI 大概在 2.5 到 3.5 倍；注意，是 2.5 到 3.5 倍，不是厂商天天吹的那个 10 倍，差着好几条街。
有一家叫 Larridin 的研究机构，2026 年 3 月的基准报告里有一句话说得很到位。大意是：
AI 编程工具确实让你更快了，但它同时也让你觉得自己比实际上更快，老一套的衡量方法，分不清这两件事。
洪定坤在字节内部拿到的 60%，放全球来看已经是顶尖了。
这也是为什么我非得聊这事，一个全球范围内 AI Coding 实践最猛的团队，代码贡献率干到了 90%，效率提升是 60%。
一个全球范围内最严格的对照实验，连稳定正向都测不出来，问题显然不在模型，今天前沿模型在代码评测上，分数一个比一个高。
那问题出在哪？我先说结论：不在写代码这件事上。
02
洪定坤在台上当场做了一个实验。
他选了三家国内外比较能打的 Coding 模型，配上现在主流的三种 Agent 框架，三三得九，排列组合出来九种情况，每种情况用同一个需求跑一百遍，看结果。
这个需求不算特别难，他自己说中等复杂度；豆包马上要上线的一个视频创作页面的预览编辑功能。不是那种一眼就能写完的小活，也没难到离谱。
先说好消息。
九种组合，功能正确率全部过了 80%。就是说，不管你用哪个模型配哪个框架，跑五次至少有四次功能是对的，代码能跑。
这个数字说实话，挺让人满意的。
坏消息在后面，他把结果按另外几个维度又拆开看了一眼：UI 好不好用，交互逻辑对不对，性能扛不扛得住，后面好不好维护，兼容性有没有坑。
所有模型、组合，这几个维度的得分只有 40 到 60 分；功能正确率八十多分，一到「能不能交付」就掉到不及格线附近。
而且，九百次跑下来，每一次出的问题都不一样，随机性极强，你拦都拦不住。
洪定坤举了几种他们在开发中反复碰到的毛病：
AI 有时候会过度设计，一个特别简单的功能，给你抽象好几层，绕一大圈，有时候只是一个很小的参数改动，它能给你复制一大段一模一样逻辑的代码出来。
防御性编程、异常处理这些事，AI 经常不管；它只关心结果能不能跑出来，别的顾不上。
还有一种情况，AI 在局部做了优化；单看这一块代码没毛病，放回整体链路里面，未必是最优解，甚至可能搞出新问题。
每条单独拎出来都不算大事，攒在一块，就是代码「能跑」跟代码「能上线」之间的距离。
能跑，说明功能是对的；能上线，你还得性能扛得住、安全没漏洞、别的模块不会被你带崩、半年后换个人接手还能看懂、还能改。
洪定坤讲了一个他自己碰到的事：
一个产品经理跑来找他，展示了一个自己用 AI 搞出来的功能。页面能看，流程也能跑。
产品经理问：你看这个能用吧？直接给我代码仓库权限，我自己提交上线不就行了？
洪定坤跟团队认真看了看那段代码；能跑，没问题，性能不够好，扩展性没考虑，权限和安全也有隐患。
这个故事太典型了，AI 让每个人都能把想法变成代码了，这本身有价值；问题是，写出来的代码跟能上线的代码之间，隔着一整套软件工程。
Opsera 那份报告里还有一组数据，跟洪定坤说的是同一件事。
AI 生成的代码，提交到合并这一步确实快了，快了快六成。代价是什么呢？代码审查环节的等待时间，是普通 PR 的 4.6 倍。同时，安全漏洞多了 15% 到 18%。
也就说：写得更快了，审得更慢了，漏洞更多了。
这个现象有个说法，我觉得挺形象。
想象一条高速公路，AI 把四车道拓宽到了八车道，车确实跑得更快了，收费站还是那一个窗口，车到了收费站全堵上了，端到端的通行时间没怎么变。
AI 加速了写代码这段路，代码审查、测试、安全扫描、跟已有架构对齐，这些「收费站」没有同步扩容，代码量反而因为生成太快而膨胀了，收费站前面排的队更长了。
洪定坤在台上有一个判断，大意是：
Vibe Coding 的问题是只盯着眼前这一块代码对不对，很容易局部正确、全局失控；这也解释了为什么 90% 的代码贡献率只换来了 60% 的效率提升。
快了的地方确实快了，慢了的地方，因为代码量暴涨反而更慢了。一加一减，净效果就是这样。
03
有意思的是，洪定坤在台上讲这些的同一场大会，字节在讲一个完全不同的故事。
火山引擎总裁谭待，在主论坛上甩出了豆包大模型 2.1 Pro；开场就亮了一组数：
豆包大模型日均 Token 调用量突破 180 万亿，两年涨了 1500 倍；中国公有云上每烧掉两个 Token，就有一个走的是火山引擎。
谭待给了一个判断，叫「生产级质变点」。意思是模型能力跨过了一条线，真能进企业生产环境了。
他举的例子是：
全球第一个在视频生成领域过线的，是 Seedance 2.0；Coding 和 Agent 领域过线的，是 Claude Opus 4.6，现在豆包 2.1 Pro 在多项评测上超了 Opus 4.6，也过了。
字节跳动 CEO 梁汝波也录了一段视频，这些你都看到了，他说字节今年的年度关键词是「勇攀高峰」，过去几年一直在收缩业务宽度，把精力聚到 AI 上。
火山引擎的 MaaS 业务正在变成字节的基础业务，投入会长期、坚定。
这些是大会的主旋律；180 万亿 Token，1500 倍增长，质变点，勇攀高峰。
可是，隔了不到一个小时，洪定坤上台了；同一个舞台，同一群观众，他说的是：那个 Gap 是真实存在的，AI Coding 还在探索期，远远没形成固定范式。
两个叙事搁一块，乍一看像在打架。我也很好奇，但认真看了一下，也确实不是。
谭待讲模型能力的供给侧；模型确实更强了，Token 用的人确实更多了，评测分数确实越来越高了，这些是事实。
洪定坤讲企业落地的需求侧，模型够好了，用起来了，90% 的代码都是 AI 写的。可从「AI 能写代码」到「AI 能帮企业交付软件」，中间还有一大截路，这也是事实。
一个在说门槛已经过了，一个在说过了门槛之后的路才刚开始。
然后，我去翻了翻洪定坤去年的分享，2025 年 6 月，也是火山引擎 FORCE 大会，同一个舞台。
那一次他做了一件事：自己用 TRAE 花了三天搞了一个英语学习 App，85% 的代码是 AI 生成的，演讲的调性是兴奋的、展示性的。
一年过去了，代码贡献率从 85% 推到了 90%，Token 消耗量涨了 50 倍，他反而开始讲挑战、痛点、失真了。
这个转变本身很有意思，一年前是「AI 能写代码太棒了」，现在是「写代码只是开始」，乐观还在，只是往前踩了一步。
要我说，「质变点」是真的，「Gap」也是真的。
它俩不矛盾，同一张地图上的两个不同坐标。你只盯着质变点，容易盲目乐观；只盯着 Gap，容易过度悲观。
真正有用的问题是：过了质变点之后，下一步该做什么？
04
洪定坤给了一个很明确的回答：在基建。他用了一个词，Harness，这个词在 AI Coding 圈今年高频出现。
字面意思是马的缰绳、马鞍、套具。模型是马，Harness 是让你骑上去、控制方向的那一套东西；马跑得再快，没这一套，你骑不上去，也拐不了弯。
洪定坤在台上特别敲了一件事：Harness 不等于 Agent 框架。
他觉得这个坑很多团队都会踩，一提 Harness，马上就想着设计一套 Agent 框架，是 single agent 还是 multi agent，角色怎么分，工具怎么配等等。
这些当然重要，可在真实业务里，真正决定 AI 能不能落地的，是更底层的几样东西。
他列了出来：
上下文工程，你给 AI 的信息够不够、准不准；架构约束，你的代码规范、依赖规则有没有明明白白告诉 AI。
团队的知识沉淀，过去踩过的坑、定过的规，有没有存进 AI 能读到的地方；还有技术债的梳理，老系统里埋了哪些雷，AI 是不知情的。
这些事看不见，不性感，没人会在发布会上拿出来讲，可它们是底座。决定 AI 输出的代码能不能直接用。
前面那个实验，裸跑的结果已经看了。加上他们团队做的 Harness 基建之后，同样的九种组合，全部往上提，正确率从 80% 提到了 90% 左右，涨了，但不夸张。
真正飙起来的是可交付性，从 40 到 60 分，普遍拉到了 80 分左右，从不及格到能用，就差了这层基建。
我查了一下，这不是洪定坤一个人这么说。
LangChain 做过类似实验，他们的 Coding Agent 在一个叫 Terminal Bench 2.0 的评测上，只换 Harness，模型完全不动，得分从 52.8% 跳到了 66.5%。
同一个模型，换个套法，十几个点的差距就出来了。
一家叫 Faros AI 的研究机构，今年 5 月出了一篇文章，把 AI 编程的发展切成了三个阶段。
2022 到 2023 年，是 Prompt Engineering，研究怎么跟 AI 说话；2024 到 2025 年，是 Context Engineering，研究给 AI 看什么。
2026 年，进入 Harness Engineering，研究怎么搭一整套系统让 AI 在里面可靠地转。
按这个框架看，洪定坤讲的就是从第二阶段跨进第三阶段的那一步，具体怎么走，他在台上分享了两个方向。
第一个方向，他叫「原型驱动开发」。
过去的做法是这样：
产品经理先写需求文档，设计师画图，技术做方案，最后才写代码；所有讨论全围着一个文档、一张图在转。问题是，文档上看着挺合理的东西，做出来经常是两回事。
AI 改变了一件事：做原型的成本变得极低，以前做个能点的原型可能要几天，现在跟 AI 聊几轮就出来了。
洪定坤举了一个实战例子。
大会前四天，他觉得 TRAE 的用户问题反馈功能做得不行。传统做法是填表单：问题类型、问题描述、截图、联系方式，一项一项填完再点发送。
他跟团队讨论，能不能把反馈直接融进对话流程里；想法有了之后，他们先用 AI 搞了一版原型，很糙，性能也不行，大概要等二三十秒，可它是真东西，能点能用。
团队围着这个原型讨论，一下发现了文档阶段根本想不到的问题：
为什么生成完还要用户自己点开？能不能做成多轮对话？能不能自动打标签？
讨论完，几个小时就搞出了第二版原型，功能比第一版完善了一大截；这就是第一个方向：用原型代替文档来驱动讨论和开发。
第二个方向，他叫「系统化的 AI Development」。
说人话就是：不能用 AI 单一的去写代码，它应该像齿轮一样，嵌进软件开发的每一道工序里。
他在台上放了一段视频，把那个反馈功能从头到尾走了一遍。
先由 AI 把需求拆成一个个小活，然后写代码；写完自己打开浏览器跑一遍，看到问题自己改，改完再跑，来回几轮，确认没问题了，自动把代码交上去。
交完之后，AI 自己再查一遍：
这块逻辑有没有坑，有没有漏掉的情况没考虑到，测试够不够。查完了标出来，工程师看一眼，没问题就上线。
从需求到上线，AI 参与了每一步，不是只参与了「写代码」那一步。
元股证券:ygzq.hk
这个思路跟 OpenAI Codex 团队说的是一回事，他们的判断是：软件工程团队的首要工作是设计环境、明确意图、构建反馈循环，让 AI 能在里面可靠地干活。
洪定坤在最后透露了 TRAE 的几个数字。
Token 消耗量同比涨了 50 倍，现在到了 5.6 万亿。用户群也在变，越来越多非工程师背景的人在用 TRAE 干日常的活，他们最近推出了 TRAE Work，专门面向非技术用户。
从 AI 写代码，到 AI 做软件工程，到 AI 走进所有人的工作流。这条路，刚走到第二步。
我认为，去年洪定坤在这个舞台上，用了三天做了一个 App，证明了 AI 能写代码。
今年他用 1.6 倍效率提升这个不那么漂亮的数字，加上一场 3×3×100 的实验，讲了一个更真实故事：知道自己在哪，比假装已经到了有价值得多。
AI 已经能写出 90% 的代码了实盘炒股交易，剩下那 10%，叫软件工程，注意是：工程。
热门股票配资开户提示：本文来自互联网，不代表本网站观点。
