科技 Bestblogs · 腾讯云开发者 · 昨天 08:45 · AI 生成
一个人用 AI 像开挂，团队协作就打架？问题不在工具，在组织 嘀嗒出行 CEO 王晓波复盘千人研发团队两年四条 AI 编程路线：单点提效、精益流程、全民造物均因事实不共享、责任无归属而失败，根因是编码仅占研发 30% 却吸走几乎全部 AI 投入。第四条路用企业本体统一业务语义，把管理对象从人/任务转为目标/上下文/依赖/证据链，让组织围绕 Agent 重新分配验证与决策。适合关注 AI 工程化落地与组织变革的技术管理者。原文 ↗ 原文 ↗
核心观点
▍ AI 编程提效的瓶颈不在工具本身，而在组织没有解决「谁知道事实、谁组织下一步、谁负责结果」三个结构性问题；只有把项目事实从人脑抽离成可共享上下文，并围绕 Agent 重组执行-验证责任链，才能实现组织级倍增。 ▍ 编码仅占研发全流程约 30% 时间，却吸纳了几乎所有 AI 投入，且各岗位 AI 互不相通，导致整体提效被锁死在个体层面；70% 的非编码工作（需求澄清、信息传递、联调返工）才是效率黑洞。 01 第一条路「老城改造」在单点引入 AI 编码工具，结果单点提效但整体效率反降，质量失控。 02 第二条路「精益流程」把业务切分成知识块，随场景变化知识块数量爆炸，复用率极低，沦为「电子垃圾」。 03 第三条路「全民造物」让业务人员自建系统，缺乏治理导致新的信息孤岛回归。 04 第四条路引入本体论（TBox/ABox/Rule/Action）统一全公司业务语义，把管理对象从「人/任务/工期」转为「目标/上下文/依赖/证据链」，状态来源从晨会汇报转为事实与证据。 05 体系跑通后出现岗位融合：驱动 AI 写代码的研发人员同时承担测试验证职责；架构「秘方」被基模内置的业界最佳实践替代；质量先降后升，最终在规范化团队中超越人工；交付全链路留痕使效能数据首次可统计。 06 作者用机械工业化类比软件工业化：当前 AI Coding 仅处于机械化阶段（单人单工具），真正的流水线需要多 Agent 并行生产；高 T 程序员将蜕变为流水线设计者，普通程序员转型知识工程师，管理者成为目标定义者。 反方 / 局限
— 文章承认质量在引入 AI 后先下降，需要经过一段时间才回升并超越人工，这意味着组织要承受过渡期的质量风险，但文章未量化过渡期长度与代价。 — 「AI 不怕屎山代码」的论断建立在 AI 能持续理解并修改遗留代码的假设上，但文章未讨论当模型能力边界、上下文窗口或知识时效性受限时，这一假设是否依然成立。 — 第四条路高度依赖企业本体的构建与维护，这本身需要大量前期投入和持续的语义治理，文章未说明中小团队或业务变化极快的组织是否具备可复制性。
概念锚点 本体论到底是不是新瓶装旧酒
把 TBox/ABox 翻成大白话：TBox 是「户口本模板」，规定有哪些类、什么关系不可逆；ABox 是「一家家的真实信息」。百度那类技术公司把本体做成核心壁垒，而 Palantir 的做法是把静态对象关系和动态 Action 规则焊在同一个 Object 上——这正是嘀嗒第四条路里「Rule/Action」那一层的由来。缺的不是 AI 能力，是先有一份说得清的概念体系。
▸ 2 条关联资料
▼
前置背景 AI 研发效能到底该怎么量
「效率首次可统计」这句话背后是一整套没定论的方法论。中国信通院 2025 年 1 月发布智能研发效能度量征求意见稿，用运营、行为、效果、效能四维、30 余项指标衡量 AI4SE；DORA 看交付结果、SPACE 解释机制成因。更棘手的是识别：代码是人机混写的，业界至今没有靠谱办法拆清边界，只能在生成窗口内用采纳率近似。
▸ 2 条关联资料
▼
论证骨架 30% 编码省下 3 天，工期只快 1 天
吉利拆过一个 30 天项目：编码原本占 10 人天，AI 后压到 7 人天，提效 30%；可落到 30 天总工期只提效 10%。剩下 20 天卡在 V 字右半边——CAN 报文时序跑 HIL 台架、域控制器在零下 30 度烤到 85 度、整车标定跑几万公里，缺的不是写代码的手，是真车和时间。作者「编码只占 30%」的判断，在这里有了算术形状。
▸ 2 条关联资料
▼
平行视角 效率前置，成本后移，账本算不过来
METR 对 16 名资深开源开发者的对照实验：用 AI 编程助手完成任务的时间反而多了 19%，但受试者自评「快了 20%」。Faros AI 汇总 2.2 万名开发者遥测发现，高采用 AI 的团队任务完成数涨 34%，Bug 涨 54%，PR 审查中位时间涨 5 倍，31.3% 的 PR 无人审就合了。这和「单点提效拖垮整体」是同一笔账，只是这次有数字。
▸ 2 条关联资料
▼
未来推演 多 Agent 流水线还差一层编排
单 Agent 跑单步任务已经够用，但一旦要让多个角色并行写、审、测，暴露的是编排问题而非 Prompt 问题：角色混淆、上下文爆炸、无法并行、没有检查点。眼下成熟的形态是 DAG 依赖图 + 分层并行 + 失败闭环回灌，而支撑「证据链」的关键工程是上下文分层——任务层、证据层、约束层各管一件事。这套还没定型，要等真实生产案例跑出稳定范式。
▸ 2 条关联资料
▼
延伸追问 AI 怕不怕屎山，这判断站得住吗
「你怕屎山是因为你要看要写，AI 不怕」——这个判断成立的前提是 AI 能稳定绕过历史包袱。反过来看，GitClear 分析 1.53 亿行代码改动发现，AI 时代两周内被撤销或重写的代码比例预计翻倍，重复代码也在增加。真正值得问的是：当 AI 大量复用旧代码时，谁来承担遗留系统的语义债务？这可能是第四条路最贵的一笔隐性成本。
▸ 2 条关联资料
▼