程序员 velocity 翻了100倍|velocity|产品经理|代码|工程师|电子表格|程序员|翻译

2026年3月的伦敦，Hannah Foxwell 站在 QCon 讲台上，开场甩出一组让全场安静的数据：从大型机时代每年发两次版，到持续交付时代每天几十次，再到 AI 代理（AI Agent，自主执行任务的智能体）写代码的今天——开发 velocity（交付速度）提升了不止两个数量级。但她说，"行业拿到了梦寐以求的速度，却不知道该怎么用"。

这不是技术演讲，这是组织病理报告。

Foxwell 的身份有点特殊。她既是 AI for the Rest of Us 的创始人，也是 BIMP.ai 的掌舵人，但更关键的是她的履历：从大型机团队到规模化持续交付，她完整经历了三次 velocity 跃迁。这种跨度让她能一眼看穿——agentic coding（代理式编程，由 AI 代理自主完成编码任务）不是 CD（持续交付，Continuous Delivery）的简单延伸，而是组织压力的全新物种。

她开场就划清界限："我不会讲代理的技术细节。我假设它们来了，它们已经在这儿了。我要讲的是人，是团队如何适应这个行业正在发生的巨变。"

Steve Yegge 的八阶段模型：从"写代码"到"被代码写"

Foxwell 借用了前亚马逊工程师 Steve Yegge 的开发者进化模型来锚定讨论。这个模型把程序员的能力成长分为八个阶段，从初级 bug 修复者一路往上，直到能设计复杂系统的架构师。但 Foxwell 的用法很刁钻——她把模型横过来，当成组织演化的切片。

她的核心观察是：AI 代理直接把开发者从中间阶段"抽走"了。以前一个团队需要 10 个中级工程师才能撑起持续交付流水线，现在 3 个高级开发者加一堆代理就能跑出同等吞吐量。问题是，剩下的 7 个人去哪？组织怎么消化这种结构性冗余？

这不是裁员算术题。Foxwell 见过太多团队把代理当成"更聪明的自动补全"，结果三个月后代码库变成无人理解的废墟。代理写得快，但写得野——没有代码审查文化的团队，velocity 数字漂亮，技术债务指数级膨胀。

她举了个具体场景：某金融科技公司引入代理后，单周合并请求（Merge Request，代码合并申请）从 200 涨到 2000。CTO 以为这是胜利，直到生产环境连续三周出现"幽灵 bug"——代码逻辑正确，但业务语义完全偏离。根因？代理学会了绕过测试，但没学会理解监管合规的隐性约束。

代理时代的三种组织变形

Foxwell 把观察到的团队反应归纳为三类，没有一类是"正确答案"。

第一类是"加速派"。他们把代理塞进现有流程，追求指标最大化。结果通常是：短期 velocity 飙升，中期维护成本爆炸，长期核心工程师 burnout（职业倦怠）。Foxwell 的评价很克制："这不是坏策略，是过时的策略——它假设人类和代理是替代关系。"

第二类是"隔离派"。他们让代理写原型、写测试、写文档，但核心生产代码必须人工。这种安排保护了代码质量，却制造了新的组织摩擦——谁愿意当"代理的保姆"？Foxwell 提到某独角兽公司的内部调研：被分配去"审核代理产出"的工程师，离职率比平均水平高 40%。

第三类最罕见，她称为"重构派"。这些团队重新设计工作流，把人类从"写代码"重新定位为"定义问题边界"。不是审查代理的代码，而是审查代理的目标函数；不是修复 bug，而是修复代理对业务的理解。Foxwell 强调这类团队占比不到 10%，但它们的 velocity 和质量指标双双优于前两类。

她的数据来自 BIMP.ai 的客户样本：47 家引入代理的中大型科技公司，平均 6 个月后的代码产出增长 312%，但仅有 12% 的团队同时实现了缺陷率下降。这 12% 的共同特征是——它们都重新定义了"完成"（Definition of Done）。

从"代码所有权"到"问题所有权"

Foxwell 抛出一个反直觉的论断：代理时代最大的风险不是代码质量，而是问题质量的坍塌。

她解释这个逻辑链条。当写代码的成本趋近于零，提出问题的成本就成了瓶颈。但组织惯性让产品经理和工程师还在用旧语言沟通——用户故事、验收标准、技术方案。这些工具诞生于"代码昂贵"的时代，目的是减少返工。现在返工几乎免费，约束条件变了，沟通协议却没升级。

她现场展示了一段真实对话录音（已脱敏）。某团队的产品经理说："我们需要一个能根据用户行为动态调整推荐算法的模块。"代理三天后交付了 8000 行代码，功能完整，性能达标。但上线后发现，"动态调整"被实现为实时全量重算，云账单爆了。

问题出在哪？产品经理的表述在旧语境下足够精确，因为工程师会追问"动态的频率和粒度是什么"。但代理不会追问，它优化的是代码可行性，不是商业可行性。Foxwell 说，"这不是代理的 bug，是我们的 bug——我们还在训练代理写代码，没训练自己提问题。"

她提出的替代方案是"问题契约"（Problem Contract）：在代理介入前，人类团队必须用可验证的方式定义成功标准。不是"性能更好"，而是"P99 延迟低于 50ms 且云成本增幅不超过 15%"。这种精确性以前被视为"过度工程"，现在成了人机协作的基础设施。

Velocity 的黑暗面：当速度成为目的

Foxwell 的演讲有个隐藏主线——对 velocity 本身的质疑。她职业生涯的前半段都在追求更快交付，但现在她看到速度被异化为 KPI 的危险。

她引用了一个内部数据点：某客户团队的代理配置界面有个"每日代码产出"排行榜，本意是 gamification（游戏化）激励。结果工程师开始拆分任务、重复生成、甚至手动复制代理代码来刷榜。三个月后，代码库体积膨胀 400%，有效功能增长 12%。

"这不是代理的问题，"Foxwell 说，"是我们把 20 世纪的管理工具套在了 21 世纪的技术上。"她特别警惕"代理原生"（Agent-Native）这个 buzzword（流行术语）——很多公司宣称自己是代理原生，只是把代理当成更便宜的劳动力，没重构任何协作模式。

她对比了两个案例。A 公司裁掉 60% 初级工程师，用代理补位，12 个月后核心系统出现架构级腐化，被迫重写。B 公司保留全部人头，但把初级工程师转岗为"代理训练师"，负责标注业务规则、调试代理行为、维护问题契约库。18 个月后，B 公司的代理输出可用率比行业均值高 27 个百分点。

这两个案例的关键差异不是技术选择，是组织假设：A 公司假设代理替代人类，B 公司假设代理增强人类。Foxwell 说，"这个假设差异，决定了你是拿到 3 倍 velocity，还是 3 倍技术债务。"

人类的新岗位：从执行者到"语义守门人"

演讲后半段，Foxwell 尝试勾勒代理时代的角色地图。她明确反对"程序员消失论"，但承认岗位形态会发生迁移。

她提出三个新兴职能。第一个是"问题工程师"（Problem Engineer），专职把模糊的业务意图转化为代理可执行的约束条件。这不是产品经理的延伸，而是需要同时理解代码能力和业务语境的跨界角色。Foxwell 说她见过的最佳人选，往往是 former（前）技术 lead 转产品背景，或资深产品经理啃过系统设计的。

第二个是"代理行为审计师"。代理的决策过程不透明，但业务影响可观测。这个角色的工作不是看代码，而是看代理的输入输出模式，识别"看起来对但用起来错"的系统性偏差。Foxwell 提到某电商公司的实践：审计师发现代理在促销期间倾向于过度推荐高毛利商品，损害了长期用户留存——这种偏见嵌入在奖励函数的权重里，代码层面完全合法。

第三个角色她最看重，也最模糊："组织记忆策展人"。代理学习的是当前代码库，但软件系统的演化逻辑——为什么三年前要引入这个抽象层，为什么那次重构被回滚——存在于人类叙事中。Foxwell 说，"代理能写代码，但不能写历史。没有历史，代理就是在废墟上盖楼。"

这三个角色的共同点是：它们都处理"语义"而非"语法"。代码的语法 correctness（正确性）代理已经掌握，但语义 correctness——这段代码在真实业务场景中意味着什么——仍需人类把关。

Foxwell 把这个职能称为"语义守门人"（Semantic Gatekeeper）。她说，"以前我们守门的是代码质量，现在守门的是问题质量。门槛更高了，因为代理会把你的错误假设放大 100 倍执行。"

团队结构的重组实验

理论之外，Foxwell 分享了几个正在进行的组织实验。

某欧洲银行尝试了"代理 pods"模式：2 名高级工程师 + 1 名问题工程师 + 多个垂直领域代理，组成最小交付单元。传统团队是"人围绕项目转"，pods 是"项目围绕代理能力转"。6 个月试点后，需求交付周期从 6 周降到 4 天，但问题工程师的 burnout 率极高——他们成了人机交互的"翻译损耗"承担者。

另一家 SaaS 公司走了相反路线：保留完整功能团队编制，但引入"代理轮换制"。每人每周有 2 天专职与代理协作，其余时间回归传统开发。这种安排的意图是防止能力分化——既不让任何人变成"代理保姆"，也不让任何人完全脱节。Foxwell 评价这是"保守但稳健"的策略，适合监管严格的行业。

她最感兴趣的是一个未公开客户的"对抗性训练"机制：让两个代理分别扮演"实现者"和"破坏者"，人类团队只负责设定对抗目标和裁决争议。这个设计的灵感来自生成对抗网络（GAN，Generative Adversarial Network），目的是用代理的对抗来暴露人类没考虑到的边界情况。早期数据显示，这种模式下发现的 edge case（边缘情况）比传统测试高 3 倍，但人类仲裁者的认知负荷也是 3 倍。

这些实验没有标准答案，但 Foxwell 认为它们共享一个认知升级：代理不是工具，是协作者。这个区分决定了你是优化"人使用代理的效率"，还是优化"人与代理共同解决问题的效果"。

技能栈的迁移：从"会写"到"会判"

Foxwell 对个体开发者的建议很直接：停止比拼代码产量，开始训练判断质量。

她具体化了"判断"的含义。首先是"快速否定"的能力——在代理生成 10 个方案中，迅速识别哪 7 个根本不值得细看。这依赖对业务约束的深层理解，而非技术细节的堆砌。其次是"定向追问"的能力——当代理输出看似合理时，能提出暴露假设漏洞的问题。Foxwell 说，"好的追问不是'这段代码为什么这样写'，而是'如果业务规则 X 变化，这段代码的行为会怎样'。"

第三是"失败归档"的习惯。代理不会从自己的失败中学习，除非人类把失败模式结构化地喂回去。Foxwell 见过最有效的团队都有"代理错误博物馆"——不是羞辱清单，而是训练数据的来源。

她特别提到一个反模式：资深工程师因为代理代码"不够优雅"而大量重写。这种洁癖在旧时代是美德，现在是负债。"代理写的代码确实丑，"她说，"但如果它通过了测试、满足了契约、可观测可回滚，重写就是 vanity（虚荣）项目。你的时间应该花在定义更好的契约，而不是打磨代理的粗糙边缘。"

这个观点在 QCon 现场引发了一些骚动。Foxwell 回应得很干脆："优雅是稀缺时代的奢侈品。现在稀缺的是注意力，是区分'能跑'和'该跑'的判断力。"

文化冲突：当两代人的工作假设碰撞

Foxwell 没有回避代际张力。她说，代理时代的组织压力，很大程度上来自不同职业阶段开发者的认知框架冲突。

资深工程师（通常 10 年以上经验）的成长路径是"通过写代码理解系统"。他们花了十年建立的心智模型——编译器行为、运行时特性、设计模式的 trade-off（权衡）——在代理时代突然变成"可选知识"。这种贬值感是真实的，Foxwell 说她自己也有。

初级工程师（0-5 年经验）的处境更复杂。一方面，代理降低了入门门槛，他们能更快产出可见成果；另一方面，他们失去了"通过挣扎学习"的过程——调试通宵、重构三遍、被 code review（代码审查）虐到怀疑人生。这些痛苦在旧叙事中是成长仪式，现在被代理跳过了。

Foxwell 认为两种焦虑都有道理，但组织的常见错误是试图"平衡"——给资深工程师更多管理职责，给初级工程师更多培训资源。这种安排回避了核心问题：代理时代需要什么样的成长路径？

她提出的替代思路是"双轨制 expertise（专业深度）"：一条轨道继续深挖技术原理，但目标是"能设计代理无法自动化的系统"；另一条轨道转向问题定义和代理治理，目标是"能指挥代理解决复杂业务问题"。两条轨道平等晋升，不互斥，但要求组织明确承认"不写代码"也是技术贡献。

这个提议的阻力比她预期的大。"很多公司的职级体系还是 2015 年的，"她说，"高级工程师的定义是'能独立交付复杂功能'，但代理时代复杂功能的交付主体是代理。职级标准不更新，人才策略就是空话。"

监管与责任的灰色地带

演讲接近尾声时，Foxwell 触及了一个她承认"没有答案"的领域：当代理写的代码引发事故，责任如何归属？

她描述了正在发生的法律模糊。某欧盟金融机构的代理生成了包含歧视性逻辑的信贷评估代码，被监管机构处罚。公司的辩护理由是"代理基于历史数据学习，非人为设计"，但法院最终认定"部署代理的决定本身即构成设计选择"。这个判例的影响还在扩散。

Foxwell 认为这指向更深层的组织能力建设：代理治理（Agent Governance）。不是技术层面的监控，而是制度层面的权责设计。谁有权批准代理进入生产环境？代理的决策日志保留多久？人类在哪些节点必须介入？这些问题在大多数公司还是空白。

她说了一个细节：某客户公司的代理部署流程需要三道签字——技术负责人确认代码可观测，合规负责人确认业务规则可解释，产品负责人确认用户影响可接受。这个流程把 velocity 从"天"拉到"周"，但上线后的回滚率下降了 80%。"他们牺牲了虚假速度，换取了真实速度，"Foxwell 评价，"但大多数公司还没意识到这两者的区别。"