AI原生工程团队的工作流重构：Ashby的实践路径与可落地参数

现象观察：AI 代码过半后的质量悖论

2025 年 8 月起，Ashby 超过 50% 的新代码由 AI 生成。这个数据背后有一个反直觉的事实：客户问题数量保持稳定，代码质量、发布速度和工程师入职时间没有退化，反而代码库的理解度有所提升。这是一个拥有 10 万周活用户、每周处理数百万候选人申请的复杂系统，而非玩具项目。

这一观察挑战了行业对 AI 代码生成的普遍担忧。问题的关键不在于 AI 生成了多少代码，而在于团队如何重构工作流来适应这种变化。

核心论点：从 "写代码" 到 "做判断" 的价值转移

Ashby 的核心判断是：代码生产成本正趋近于零。AI 不是来取代工程师的工作，而是来取代工作中的机械部分 —— 语法、胶水代码、键盘敲击。真正重要的部分 —— 判断力、品味、对客户的理解 —— 变得比以往更重要。

这个判断基于一个历史规律：每一次代码生产效率的提升，都会将工程师的价值进一步推向决策端。AI 带来的将是比以往更大的 shift。这意味着工程师的核心竞争力正在从 "能写多少代码" 转向 "能做多好的决策"。

工作流重构：Sidekick 与 Delegate 双模式

Ashby 提出了两种与 LLM 协作的模式，这是工作流重构的核心框架：

Sidekick 模式（副驾驶）：AI 辅助探索代码库、消化大量信息、实现详细规格，但工程师保留大部分决策权。这是高风险场景的默认模式：数据库迁移、候选人数据处理、安全敏感代码、架构决策。在这些地方，"看起来正确" 远远不够，工程师必须坐在驾驶座。

Delegate 模式（委托）：仅在爆炸半径小的场景使用，如原型开发、本地工具、运维脚本。工程师可以快速推进，因为失败的成本很低。

大多数工程师会经历一个矫正曲线：一开始过度委托，然后过度矫正为过度控制。关键问题不是 "是否使用 AI"，而是 "在这里应该给予多少信任"。判断标准是：如果代码错了，后果是尴尬、昂贵，还是生存危机？

实践中，两种模式常常混合使用。工程师可能让 AI 搭建新功能的脚手架，手写关键 SQL 查询，然后回到委托模式写单元测试。这种切换点的判断，正是工程师新价值的核心体现。

协作原则：同理心与责任归属

在 AI 重构工作流的过程中，Ashby 确立了两条底线原则：

同理心不能被 AI 取代。产品构建是人类事业，LLM 没有品味，不了解客户，无法感受使用糟糕产品的挫败或使用出色产品的愉悦。这要求工程师在撰写 PR 描述、技术规格时，必须为人类读者而非 AI 优化 —— 聚焦关键决策，尊重同事时间，传递思考过程而非罗列细节。

你对你发布的内容负责。无论代码是手写还是 AI 生成，工程师都必须理解代码做什么、为什么这样做、出问题时会发生什么。AI 可能自信地犯错，听起来正确但实际错误。随着 AI 使用增加，怀疑主义必须增强而非减弱 —— 要求替代方案、询问边界情况、让 AI 自我批评。

一个特别危险的陷阱是同时运行多个 AI 代理处理不同任务。多任务处理本就低效，而多代理并行是 steroids 版本的多任务。虽然同时有五个代理在五个问题上工作看起来很高效，但工程师是否真的能深入思考每个代理需要的指导？是否理解正在构建的内容？

质量保障体系：审查重心转移与自动验证

随着代码生成成本趋近于零，验证成为瓶颈。Ashby 采用 "瑞士奶酪模型"：测试、代码审查、功能开关、可观测性，每一层都有漏洞，但漏洞位置不同，层层叠加形成防护。

代码审查的重心转移：人类不擅长抓 bug，工程师不应该花时间思考别人是否正确使用了 useMemo。自审和工具（linting）应该处理 90% 的这类问题。审查的重点应该转向：变更是否合理？高风险区域在哪里？性能特征如何？抽象是否合适？

特别值得注意的是，LLM 偏向生成新代码而非复用现有代码。如果不加控制，AI 会构建一个能运行但无人能导航的代码库。推动简化现在是审查者能做的最有价值的事情之一。

自动验证的投资：Ashby 的 QA 团队创建了技能文件，描述如何持续可持续地创建测试同时避免脆弱测试。工程师现在使用 Playwright 编写端到端测试，过去 4 周内创建了 65 个新测试用例，其中 70% 来自非 QA 团队成员。未来需要更多模糊测试、前端单元测试、静态分析，以及 AI 审查 AI 的自动化流程。

团队能力模型：客户理解成为核心技能

AI 重构工作流对团队能力模型提出了新要求。Ashby 的工程师现在花更多时间做 "非编码" 工作：观看用户会话回放、观看客户访谈、与内部用户交流、阅读支持对话。客户理解成为核心工程技能。

这改变了招聘标准。Ashby 招聘工程师时，不仅看重技术能力，更看重产品思维、沟通能力和判断力。在 AI 时代，执行速度成为良好判断力的乘数 —— 而 AI 即将让 "接单型团队" 过时，同时让具备这些能力的团队更强大。

代码质量的重要性也在被重新定义。过去，混乱的代码库只是拖慢同事速度；现在，它还会降低接触它的每段 AI 生成代码的质量。每个模式、每个命名、每个模块边界都被 LLM 字面理解。代码质量一直重要，现在它产生复利效应。

实践清单与可落地参数

基于 Ashby 的实践，以下是可立即落地的参数与检查清单：

协作模式决策树：

• 数据库迁移 / 候选人数据处理 / 安全代码 → Sidekick 模式
• 原型 / 本地工具 / 运维脚本 → Delegate 模式
• 混合场景：AI 搭脚手架 + 手写关键逻辑 + AI 写测试

代码审查检查清单：

• 变更逻辑是否合理（而非语法是否正确）
• 是否复用了现有抽象而非创建重复代码
• 高风险区域是否已识别并缓解
• 性能特征是否可接受
• 是否过度复杂，可以简化

质量保障基线：

• 自动化工具处理 90% 的格式 / 语法审查
• 端到端测试覆盖关键用户路径
• 功能开关控制新功能发布
• 可观测性覆盖生产环境异常

工程师时间重分配：

• 每周固定时间观看用户会话回放
• 参与客户访谈或阅读访谈记录
• 定期阅读支持对话理解痛点
• 技术规格撰写前完成客户场景验证

风险预警指标：

• 同时运行多个 AI 代理处理不同任务
• PR 描述由 AI 生成未经过人工优化
• 代码库出现重复抽象或相似功能
• 测试创建速度跟不上代码生成速度

资料来源：

• Ashby Engineering Blog: "AI, Ashby Engineering, and the Future" (June 2, 2026)

ai-systems