字节跳动洪定坤:AI Coding 的实践与探索
- 原始作者:洪定坤(字节跳动技术副总裁)
- 演讲场合:2026-06-23 火山引擎 Force 原动力大会
- 原文链接:https://mp.weixin.qq.com/s/KPTJoYYrWNsvTS0D9tC2hg
- 发布时间:2026-06-23
- 获取时间:2026-06-26
核心结论(一句话)
“用得越多,挑战越大” — 字节 1 年 AI 代码贡献率增 6 倍/token 增 5 倍/合入率增 2 倍,真正的瓶颈是指标失真、Vibe Coding 不可交付、人人都是程序员带来的协作失序;解法是关注三件事(指标/治理/协作)+ 三种实践(原型驱动 / 系统化 AI Development / 组织化建设)。
- 场景:企业级 AI Coding 落地的”真实体感”报告(字节 1 年实践)
- 类型:大会演讲实录 / 行业现实(非工程方法论、非行业战略)
- 关键证据:900 次 Vibe Coding 跑分 + TRAE 团队 90% AI 代码/1.6x 吞吐的”10x vs 1.6x”反差 + TRAE 5.6 万亿 Token/天的规模数据
知识节点(8 个)
- 指标陷阱:单一 AI 代码贡献率当 KPI 失真;TRAE 90% AI 代码 + 10x 写代码速度 ≠ 1.6x 吞吐 → 写代码快 ≠ 整体效率快
- 3×3×100 实验:3 主流 Coding 模型 × 3 主流 Agent 框架 × 100 次相同 Prompt + 真实业务需求,正确率 80%+ 但可交付性 40-60;Harness 基建接入后正确率 80→90、可交付性 40-60→80
- Vibe Coding 边界:正确率 ≠ 可交付;UI/交互/可维护性/性能/兼容性维度上”模型+框架”组合表现强随机(异常处理/组件复用/历史影响/工程规范全维度不达标)
- Harness=基建:字节视角下 Harness = 上下文工程 + 架构约束 + 团队知识沉淀(Memory)+ 技术债梳理,Harness 是”地基”不是”骨架” — 与现有主线 Harnes=骨架视角互为补充
- 原型驱动开发:替代”文档驱动 PRD→设计→技术方案→代码”的传统流程,用 AI 直接产出”可交互的动态原型”沟通,减少”文档读起来合理但做出来分歧大”的问题
- 系统化 AI Development:AI 不止写代码,贯穿 Spec → 实现 → Browser Use 自验 → Bugfix → 提交 → 发布全流程;关键不是 Coding 自动化,是流程自动化
- 人人都是程序员:产品/设计/运营 Vibe Coding 完想直接上线 → 代码能跑但性能/扩展性/权限安全都有问题 → 代码生成门槛降 ≠ 系统复杂度降
- 组织化建设:把个人能力沉淀为标准/工具/技能;TRAE 5.6 万亿 Token/天(增 50 倍) + TRAE Work 企业版 + 与火山引擎联合输出
关联图谱 + 正文要点(合并)
关联图谱
- 上游:字节 TRAE 工具平台 1 年实战(2025.7 → 2026.6) + AI Coding 行业从”工具试用”进入”企业落地”阶段 + 阿里 [[面向Skills编程-淘宝企业购端到端研发提效实践]] 同期实践
- 下游:[[Vibe Coding]] 可交付性数据补完 + [[从Prompt-Context到Harness-工程的三次进化与终局之战]] Harness=基建 视角补完 + [[0xCodez-Agent-Harness-14-Steps]] Harness 14 步 + [[AI原生研发落地实践-Spec-Kit和BMAD跑了一遍SDD]] Spec 落地 + [[Anthropic万字长文三个判断和一个阳谋]] 字节 vs Anthropic 行业判断
- 同级:[[面向Skills编程-淘宝企业购端到端研发提效实践]] 阿里淘系同口径 + [[Claude-Code团队5条工作原则-Fiona-Fung分享]] Anthropic 团队实践 + [[54万行代码的顿悟-Markdown才是新编程方式]] / [[AI-Coding的顿悟时刻]] 个人/工程层范式
正文要点(3 段合并)
指标陷阱 + Vibe Coding 边界(最有数据):TRAE 0.5 年 AI 代码 90%+、人均吞吐 1.6 倍(写代码 10x + 占比 90%+ ≠ 整体效率 10x,真正瓶颈在”整体研发链路是否同步加速”);3 模型 × 3 框架 × 100 次 = 900 次跑分(豆包”创作视频预览”中等复杂度),正确率 80%+→90%(有 Harness),可交付性 40-60(不及格)→80,失败模式:异常处理不规范/没复用仓库组件/改动影响历史功能/实现不符合工程规范 → 感觉 Vibe Coding 快了,实际未必快,甚至会慢
人人都是程序员 + 原型驱动(最实用):产品同学 Vibe Coding 完 → “页面能看、流程能跑” → 但代码性能不够好/扩展性没考虑/权限安全有问题 → 研发仍要排期 → 代码生成门槛降 ≠ 系统复杂度降;AI 替代”文档驱动 PRD→设计→技术方案→代码”,把”制作原型”成本大幅降低:从静态到动态、从图片到可交互;TRAE /feedback 现场演示;设计师可直接出高保真还原图,省下 60% 还原时间
系统化 AI Development + 组织化建设(最值得借鉴):AI 贯穿写 Spec → 写代码 → Browser Use 自验 → Bugfix → 提交 → 发布全流程 → 关键不是 Coding 自动化,是流程自动化;TRAE Token 日均 5.6 万亿(1 年增 50 倍)+ TRAE Work 企业版 + 与火山引擎联合 → 把原型驱动 + 系统化 AI Development 沉淀为内部标准/工具/技能
7 个对 Seetong 团队可借鉴动作
- 指标体检:Seetong AI Coding 加”需求吞吐率/缺陷率/工时饱和度/需求变更率”4 个全局指标
- 跑一次 Vibe Coding 跑分:3 模型(Claude/Codex/Gemini) × 3 框架(纯 Prompt/Cursor/Cline 风格) × 10 次 = 90 次,建立”基建接入前 vs 接入后”对照
- Harness 基建四件套体检:对照字节”上下文工程/架构约束/团队知识沉淀/技术债梳理”,看 Seetong 三端 SDK + OpenClaw 哪几块空白,优先补”团队知识沉淀”(三端公共规范压成 AI 可读 Skill)
- 原型驱动试点:选 1 个 Seetong 新功能,PM 直接用 AI 产出可交互原型 → review → 再进 PRD
- 系统化 AI Development 试点:Seetong 端到端流程挑 1 个高频环节(需求→PR→预演→提交)用 AI 跑通,重点是流程自动化不是 Coding 自动化
- 人人都是程序员协作 SOP:Seetong 产品/设计用 AI 写代码必须有 2 道关卡 — Seetong 研发 Code Review + Seetong 工程规范自动检查(权限/性能/兼容性)
- 借鉴 TRAE Work 思路:把 Seetong AI Coding 经验沉淀为”Seetong 内部 AI 编码规范”文档 + Skill,新员工 onboarding 第一周就能复用
备注与限制
- 数据可信度:6 倍/5 倍/2 倍/5.6 万亿 Token/TRAE 90%/1.6x 吞吐 均为字节官方公开数据(2026-06-23 火山引擎 Force 大会),可信度高
- 900 次实验未公开 3 个模型和 3 个框架的具体名单(只说”主流”),无法跨研究复现;跑分维度权重未公开
- TRAE 团队 90% AI 代码 / 1.6x 吞吐是单团队数据,需注意”做 AI Coding 工具的团队本身可能用得更激进”幸存者偏差
- “原型驱动 + 系统化 AI Development” 的实操流程(AI 写 Spec → Browser Use 自验 → 自动提交)为现场口述,具体技术栈和工时未公开
- 现场演示部分(动态原型 /feedback 的过程)未在文字稿中给出,读者需参考原视频
- TRAE Work 企业版发布日期、与火山引擎联合的具体形式(独立产品/SaaS/PaaS)未公开
透明玻璃自检:wiki ≤8K 字节 ✓ / 节点 8 ✓ / H2 4 个(≤5)✓ / 表格 0 ✓ / 0 陈词 ✓