AI、Ashby Engineering 与未来

# AI、Ashby 工程与未来 来源：https://www.ashbyhq.com/blog/engineering/ai-ashby-engineering-and-the-future **自 2025 年 8 月起，Ashby 生产系统中超过一半的新代码均来自 AI 生成**，而客户问题数量整体保持稳定。见下图。客户变多了，AI 写的代码变多了，天并没有塌下来。 *每年 3 月到 4 月会有一个小高峰；这些周期性模式与本主题无关，不再赘述。Cursor 提供了我们的代码中有多少由 AI 生成的统计数据。* 在代码质量、开发速度或新工程师的入职时间方面，我们也没有发现任何退化（根据非正式观察，工程师对代码库的理解反而有所提升！）。 这并不是一个玩具项目。Ashby 是一套人才招聘软件，拥有超过 10 万周活跃用户，每周处理数百万份求职申请，其功能涵盖相当于整个公司的产品（如 Calendly 和 Looker）。 我是 Colin，Ashby 的 EMEA 工程负责人。我想与你分享 Ashby 工程团队如何思考 AI 以及它给我们的工作方式带来的变化。我假设你是一名工程师。 **我们的论点是：生成代码的成本正在趋近于零**。AI 不是来抢我们饭碗的，而是来接手工作中机械化的部分：语法、胶水代码、以及键盘上的那些敲敲打打。那些不那么有趣、不那么有挑战的部分。 而对工程师来说真正重要的东西——你的判断力、你的品味、你对客户的理解——正变得比以前更重要，而不是相反。你作为工程师的价值，从来都更多地体现在你的判断力上。每一次高质量代码生产效率的提升，都让这个角色朝着这个方向更进一步。AI 将带来比以往任何时候都更大的转变。 这种转变已经到来。“现在我的 PR 几乎全是 AI 写的。我用 AI 完整实现了一套数据摄取流程……大概有 40 个 PR。”——我们的工程师 Tom。 与任何新兴技术一样，行业正在摸索如何有效利用 AI 来构建软件。何时信任它，何时推翻它，以及我们的系统需要做哪些改变，才能让“快速行动”不会变成“鲁莽行事”。这是一个共享的心智模型，并且我预计它会随着我们的学习而演变。 ## 基本原则 随着我们越来越多地使用 LLM，以及周围世界的变化，我们认为有两条基本原则： - 共情无法被 AI 取代 - 你对你交付的东西负责 ### 共情无法被 AI 取代 **构建产品是一项人类活动**。LLM 没有品味。它们不了解我们的客户。它们无法感受或理解使用糟糕产品的挫败感，也无法体会使用卓越产品时的愉悦感。这仍然需要判断力，而且在一个能极其快速地构建出功能性产品的世界里，打造出伟大产品的能力甚至更加重要。 **我们也重视个人专注，所以当我们协作时，最重要的是高效地协作**。我们不做无意义的每日站会。我们不做计划扑克。我们确实会为同事编写文档以便阅读和理解。我们确实会在变更评审时寻求帮助。 共情意味着要记住为将要阅读这些文档的人而写。LLM 可以帮忙写作，但如果没有指导，LLM 会写出看似有说服力但人类难以阅读的文档，充斥着不重要的细节，缺乏乐趣和智慧。以下是我让 LLM 写的一段 PR 描述摘录： `` 1已添加 .github/workflows/pr-relevant-test-coverage.yml： 2 - 在 pull_request（不包括 master）时触发， 3 以及带有 pr_number 的 workflow_dispatch。 4 - 解析 PR 编号，收集变更文件，然后要求 5 Claude 输出最多 15 个相关测试文件。 `` 这些都是我们可以通过阅读 PR 轻易获取的信息，而完整的描述接近 30 行。最有用的那一句仍然没有切中要害： `` 1覆盖范围故意不是全套测试；它只反映 2Claude 针对变更文件选择的 3相关测试。 `` 为什么？为什么这没有运行全套测试覆盖？**这个描述没有尊重我们同事的时间**。它缺乏对我们作为评审者和未来代码维护者的共情。 `` 1覆盖范围故意不是全套测试。完整的 2带覆盖的测试套件需要数小时才能运行完毕。我们 3用这个来给工程师提供风险所在 4的指导。 `` 记住是什么让你的同事能够帮助你。不要将为人编写文档的工作拱手让给 LLM。 ### 你对你交付的东西负责 LLM 可能会错得离谱。自信但错误。莫名其妙地粗心。**AI 最大的风险不是它错了，而是它听起来好像是对的**。 *“我不是故意要移除 tar-stream 包的——那是在我编辑 backend/package.json... 时意外的牺牲品。”*——Claude Code **你对你交付的东西负责**。无论每一行都是手写的，还是 LLM 生成了整个 PR。你都有责任理解代码做了什么、为什么这么做、以及当它出问题时会发生什么。 随着我们越来越多地使用 LLM，怀疑态度必须增加，而不是减少。要求提供替代方案。要求考虑边界情况。让它自我批评。在接受输出之前，先理解其推理过程。 ### 多思考，更深入思考 **我们必须比以前思考得更多、更深**。LLM 让你很容易不动脑子就完成一件事。抵制这种冲动。保持警惕。很容易就会把一个 issue 丢给 LLM，让 PR 描述自动生成，让 LLM 写测试，然后把 PR 扔出去评审……与此同时，可能解决的根本是错误的 issue，或者构建了一个较差的解决方案。 一个特别恶毒的体现是并行运行大量 agent 处理不相关的任务。这就像是打了鸡血的多任务处理。多任务处理效率低下，因为人类大脑无法同时专注于多个高层级任务。让五个 agent 处理五个 issues，然后在它们之间频繁切换，可能会感觉很高效，但你真的在做出最佳决策吗？你能深入思考每个 agent 需要的指导吗？你真的理解正在构建什么吗？ 当前的热潮常常将数量和速度置于一切之上，同时忽视质量和独创性，或者承诺这些结果会随之而来。在 Ashby，我们不会屈服于这种压力。这是一种短视的世界观，认为一切都可以并且应该走捷径。捷径一直存在，但其中许多会降低我们工作的质量和独创性： 这些外部引述反映了我们自身的成功之路。在 AI 之前，我们本可以一直更快：我们可以将工作外包给承包商，可以构建功能而非构建模块，可以更早发布。但我们花在招聘优秀人才而非外包、花在思考抽象而非编码、花在对产品保持耐心上的时间，往往比替代方案更有成效。深入思考是我们今天能成为一家成功初创公司的部分原因，我们不会停止。 ### 规格说明书仍然是为人类写的 我们观察到的一个变化是，有人打算将规格说明书直接喂给 LLM。我们一直重视规格说明书。它们能降低开发风险并确保目标一致。LLM 也能从规格说明书提供的上下文中受益。 然而，**人类需要从规格说明书中得到的东西，与 LLM 需要的东西是不同的**。作为人类，我们需要一份顾及我们时间、能吸引我们阅读、并将注意力集中在重要决策上的文档。例如，一份能告诉你为什么决定使用 Redis 而不是 Postgres 的文档，而不是一份详细列出新枚举每个可能值的文档。 我们需要一份对我们有共情的文档。 **我们必须继续为人编写规格说明书**。规格说明书侧重于那些修改成本高昂的决策。规格说明书降低了我们构建错误东西的风险。它们识别出我们将需要的抽象。例如，我曾与一位工程师讨论一个需求：需要对可能数百万份表单执行一个操作，而我们的框架不支持这一点。他们是针对自己的用例创建一个一次性实现，还是想出如何改进批量操作这个构建模块？这正是我们需要捕捉的那种决策。它完全改变了实现方式。它影响到其他所有人。做对了，我们就为下一个人创造了可复用的成果。 **规格说明书是为人类写的**。LLM 可能会将其作为有用的额外上下文来进行消费。 ## 如何看待 LLM 我们已经设定了基本原则，并讨论了我们希望如何作为人类进行互动。现在来谈谈我们如何看待与 LLM 协作。 外面有很多优秀的材料介绍了 LLM 的工作原理（Sam Rose 的这篇文章（https://ngrok.com/blog/prompt-caching） 就很不错）。 首先，LLM 并不懒惰。它们会生成代码，而且会一直生成下去。它们不会停下来问：“我应该为这个创建一个抽象吗？”它们擅长总结大量信息。但它们不是创新思考者。它们不会做出那种让你能简化某件事并删除数千行代码的思维跳跃。 我用一个简单的模型来看待 LLM：把它看作一套骰子，而不是被炒作的那种超级智能。 有些问题 LLM 很擅长，你甚至不需要掷出高分。它们擅长总结文档、发现模式并延续模式。 有些问题它们非常不擅长。你永远无法连续掷出足够多的六点。数出“strawberry”里有几个字母 r、计算大数乘法、或者在一连串转向后判断自己脸朝哪个方向——这些看似简单，但需要一种骰子无法可靠提供的精准度。 还有一些方法可以给骰子增加重量，让胜算更有利于你，比如给它们一个“优秀答案”的示例。 带着这个模型，我们来看看与 LLM 协作在实践中是如何展开的。 ## 两种使用 AI 的模式 我发现与 LLM 协作有两种截然不同的模式：作为副手或作为代表。识别你当前处于哪种模式，以及你应该处于哪种模式，是关键的技能。 **默认使用副手模式**。你使用 AI 来探索代码库、查找和消化大量信息，并实现你写好的详细规格说明书。**你**在做大部分决策。 这种模式适用于任何高风险事项：数据库迁移、候选人数据处理、安全敏感代码以及架构决策。在这些地方，“看起来没问题”是不够的。你需要坐在驾驶座上。 **当爆炸半径很小时，切换到代表模式**。你会审查输出——或者有时不审查。原型开发、本地工具和运维工具都是很好的候选场景。你可以快速行动，因为失败的代价很低。 大多数工程师一开始会过度授权（代表模式）。然后他们会过度纠正，又授权不足。问题从来不是“我该不该用 AI？”——而是“在这里我应该在多大程度上信任它？”想想如果代码错了会发生什么。是令人尴尬？代价高昂？还是**关乎存亡**？ **两种模式之间的融合**会是很常见的。这正是你的判断力起作用的地方，也是将任务分解开来会有回报的地方。你可能会让 LLM 先搭建你正在开发的新功能的脚手架，然后手写一些 SQL 查询，最后再完全授权给 AI 去编写几个单元测试。 ## 今天我们如何使用 AI 我们积极鼓励工程师使用 AI 工具来支持他们的工作。我们通过教育、研讨会、结对编程以及慷慨的 token 预算来做到这一点。**我们不强制使用 AI，也不衡量 token 使用量**。我们相信这样做会导致产出低质量内容。 随着编写代码成本降低，安全性变得更加重要。**安全性必须构建在基础设施中，而不是作为纪律强加于人**。我们使用瑞士奶酪模型来思考安全性。每一层都有漏洞，但漏洞出现在不同的地方。测试能捕获评审遗漏的问题，特性开关能捕获测试遗漏的问题，而可观测性能捕获从所有其他层面溜过去的问题。 **我们首先让所有工程师都能使用 AI 代码生成工具**。工程师可以轻松申请访问 Cursor、Claude Max、Codex 以及各种 agent 框架，并且在 Cursor 中没有 token 限制。 **我们也在使用 linter、****DangerJS** (https://github.com/danger/danger-js) **和 AI 来辅助代码评审**。许多常见问题由我们的 linter 和 Danger 规则捕获，我们的团队积极努力扩展这些自动化检查。我们使用像 CodeRabbit (https://www.coderabbit.ai/) 这样的第三方工具来进行第一轮检查，然后才由人工介入。我们还构建了自己的代码评审工具，专注于发现那些在生产环境中很难处理的边界情况 bug。我们发现它在这一点上比第三方工具更好，因为我们可以使用更多 token 并严格控制上下文。 **我们还为 AI 工具（包括第三方和自研的）提供共享基础设施**，让它们能够蓬勃发展。我们的技能文件存放在我们的代码仓库中，团队成员每周都会贡献更新。工程师可以访问一个仓库，该仓库将我们主仓库的 Git 元数据克隆到 SQLite 数据库中。所有的 issue、拉取请求和评论都在那里。这使工程师和内部的 LLM 工具能够更快地回答诸如“有人以前见过这样的 bug 吗？解决方案是什么？”之类的问题——它比通过 GitHub API 交互更快、更准确。 **我们还使用 AI 来改善与其他部门的协作**。我们训练了一个内部模型来自动分类客户问题，并将其发送到正确的产品团队。我们有一个自动化流程，让 Claude Code 审查传入的 bug，并生成一份报告，说明可能的原因、需要咨询的人员以及进一步探索的途径。在某些情况下，这帮助支持团队在十分钟内解决问题，而不是需要几个小时。例如，用户的录用通知书模板中缺少了一个替换标签——这类问题工程师通常需要花很长时间盯着看。Claude Code 一眼就发现了。 ## 下一步 我们将继续投资于开发者体验和工具，以确保 AI 生成高质量的代码，同时减轻人类的负担。从概念上讲，我们是这么考虑的： ### 变更评审 在 Ashby，我们已经对代码变更进行评审。我们的评审范围相当广泛，涵盖了从 bug 发现、抽象机会到代码文档等各个方面。未来产出的大幅增长将超出我们的评审能力。我们需要批判性地思考为什么我们要评审代码。我们需要确保将评审时间花在最有价值的目标上。 人类不擅长发现 bug。工程师不应该花时间思考别人是否在某个组件中正确使用了 useMemo。我们不是来做人类 linter 的。人类不应该花费大量时间逐行评审别人写的代码。自我评审和其他工具（如 linter）应该处理掉 90% 的工作。如果你在 2026 年还在评审一个自动化的提取函数的重构，那我们就失败了。 那么，我们评审什么呢？ - 这个**变更**有意义吗？ - 高风险区域在哪里？我们如何降低这些风险？ - 性能特征是什么？ - 抽象是否合理？我们是否进行了足够的抽象？ 最后一点关于合理抽象值得强调。LLM 倾向于生成新代码，而不是重用现有代码。如果不加控制，它们会为你构建出一个能工作但没人能驾驭的代码库。LLM 并不关心它们生成的代码是否复杂。推动代码走向简洁，现在已经成为评审者能做的最有价值的事情之一。我在一个副项目上就遇到过这种情况——有两个“界面模式”，LLM 在每个模式下都复制了所有东西！我只 r