AI、Ashby Engineering 与未来：当代码生产成本趋近于零

背景

自 2025 年 8 月以来，Ashby 生产系统中超过一半的新代码由 AI 生成，但客户问题数量并未激增，反而随着用户基数的扩大保持总体稳定。Ashby 并非一个玩具项目，而是一套拥有超过 10 万周活跃用户、每周处理数百万份候选人申请的人才获取软件套件，其功能复杂度堪比 Calendly 和 Looker 等独立公司产品。

作为 Ashby 的 EMEA（欧洲、中东及非洲）工程负责人，Colin 指出，尽管行业对 AI 充满 hype（炒作），但 Ashby 的工程团队并未看到代码质量、开发速度或工程师入职时间的倒退。相反，工程师对代码库的理解能力甚至有所提升。这一现象促使 Ashby 工程团队深入思考 AI 如何重塑软件开发的工作方式，并确立了应对这一技术变革的核心哲学。

核心内容

Ashby 工程团队的核心论点（Thesis）是：生产代码的成本正在趋近于零。 AI 并非来取代工程师的工作，而是来取代工作中机械性的部分：语法、胶水代码以及繁琐的键盘敲击。这些部分往往缺乏挑战性且趣味性较低。

相反，工程师真正有价值的部分——判断力、品味以及对客户的理解——正变得愈发重要。工程师的价值始终建立在判断力之上，而 AI 带来的效率提升只是将这一角色进一步向“判断”倾斜。这种转变已经发生，正如 Ashby 工程师 Tom 所言：“我现在几乎所有的 PR（拉取请求）都是完全由 AI 编写的……我通过 AI 实现了一个完整的数据摄入流程，涉及约 40 个 PR。”

然而，像任何新兴技术一样，行业仍在摸索如何有效利用 AI 构建软件：何时信任它，何时覆盖它，以及如何调整系统以确保“快速行动”不会变成“鲁莽行事”。为此，Ashby 确立了两大基石规则（Ground Rules）：

1. 同理心无法被 AI 替代

构建产品是一项人类活动。LLM（大型语言模型）没有品味，不了解客户，无法感受使用糟糕产品时的沮丧或使用卓越产品时的愉悦。在构建功能性产品变得极其快速的今天，构建“优秀”产品的能力变得更为关键，这需要人类的判断力。

Ashby 重视个体专注，因此协作必须高效。他们不进行无意义的站会或计划扑克，而是通过撰写文档供同事阅读和理解，并在审查变更时寻求帮助。同理心意味着要为阅读这些文档的人类着想。LLM 可以辅助写作，但若无指导，LLM 生成的文档往往看似合理却难以阅读，充斥着无关细节，缺乏智慧和愉悦感。

Colin 分享了一个反面案例：他让 LLM 撰写的一个 PR 描述长达近 30 行，仅罗列了技术触发条件和文件收集过程，却未解释核心逻辑。直到人工补充说明“为何不运行全量覆盖测试”（因为全量测试耗时数小时，此处旨在为工程师提供风险指引），文档才具备了对同事时间的尊重和对未来维护者的同理心。因此，不要将面向人类的文档写作完全让渡给 LLM。

2. 你对所交付的内容负责

LLM 可能会错误得令人惊讶，自信地错误，或 inexplicably careless（难以解释地粗心）。AI 最大的风险不在于它错了，而在于它听起来是对的。

Ashby 工程师曾遇到 Claude Code 意外删除 tar-stream 包的情况，理由是“在编辑 backend/package.json 时的意外伤亡”。无论每一行代码是否由人工手写，工程师都必须对交付物负责。你需要理解代码的作用、原因以及故障时的后果。随着 LLM 的使用增加，怀疑精神必须增加而非减少。工程师应要求替代方案、边缘情况，并要求模型自我批判，在接受输出前理解其推理过程。

思考更多，思考更深

LLM 使得“不动脑子”地完成任务变得容易，但工程师必须抵抗这种诱惑，保持警惕。常见的陷阱是：将问题扔给 LLM，自动生成 PR 描述，让 LLM 写测试，然后直接提交审查……结果可能是在修复完全错误的问题或构建次优方案。

另一种危险的表现是并行运行大量代理（agents）处理不同任务。这被形容为“类固醇版的 multitasking（多任务处理）”。虽然让五个代理处理五个问题并来回切换可能感觉高效，但人类大脑无法同时专注于多个高层级任务。这种模式可能导致无法做出最佳决策，无法深入思考每个代理所需的指导，甚至无法理解正在构建的内容。

当前的炒作周期往往强调数量和速度，而忽视质量和独创性，或者承诺这些结果会自然随之而来。Ashby 拒绝这种短视的观点。在 AI 出现之前，团队本可以通过外包、构建功能而非模块、提前发布等方式加速，但他们选择招聘高质量人才、思考抽象结构、对产品保持耐心。深度思考是 Ashby 成为成功初创企业的关键，这一传统不会因 AI 而改变。

规格说明书（Specs）仍是为人类编写的

虽然团队一直重视规格说明书（Specs）以降低开发风险并确保对齐，且 LLM 也能从 Specs 提供的上下文中受益，但人类与 LLM 对 Specs 的需求截然不同。

人类需要的 Specs 应尊重读者的时间，吸引读者，并聚焦于重要的决策。例如，解释“为何选择 Redis 而非 Postgres”比罗列新枚举类型的所有可能值更有价值。Specs 必须对人类充满同理心。

Specs 聚焦于那些“更改成本高昂”的决策，降低构建错误产品的风险，并识别所需的抽象结构。例如，当工程师面临在数百万表单上执行操作的需求，而现有框架不支持时，Specs 引导他们思考：是为用例创建一次性实现，还是改进批量操作模块？这种决策层面的思考是 AI 难以替代的。

关键要点

• 代码生产成本趋零：AI 接管了语法、胶水代码和机械性敲击，工程师的核心价值转向判断力、品味和客户理解。
• 两大基石规则：
  1. 同理心不可替代：LLM 缺乏对人类情感和时间的尊重，文档写作需保留人类视角，避免生成看似合理但缺乏洞察力的内容。
  2. 工程师全权负责：LLM 可能自信地犯错，工程师必须对交付物的正确性、逻辑和潜在故障负责，需保持怀疑精神并要求自我批判。
• 警惕“伪高效”：并行运行多个 AI 代理或过度依赖自动化可能导致浅层思考。人类大脑无法同时处理多个高层级任务，深度思考仍是高质量产出的关键。
• 拒绝速度崇拜：Ashby 不盲目追求 AI 带来的速度红利，而是坚持通过深度思考、抽象设计和耐心打磨来保证质量和独创性。
• Specs 的人文属性：规格说明书应服务于人类读者的认知效率，聚焦于关键决策和抽象设计，而非仅仅作为 LLM 的输入数据。

意义与影响

Ashby 的工程实践为科技行业提供了一个关于 AI 落地的冷静视角：AI 不是工程师的替代者，而是放大镜。 它放大了工程师在判断力和系统设计上的价值，同时也放大了缺乏深度思考的风险。

这一案例表明，随着 AI 生成代码成为常态，软件工程的重心将从“如何实现”（Implementation）彻底转移到“为何实现”（Why）和“实现什么”（What）。工程师的角色正在从“代码编写者”演变为“系统架构师”和“质量守门人”。

对于技术团队而言，这意味着：

1. 招聘与培养重点转移：比起考察语法熟练度，更应考察候选人的系统设计能力、客户同理心以及批判性思维。
2. 流程重构：代码审查（Code Review）的重点应从语法错误转向逻辑合理性、边界情况处理以及对业务价值的理解。
3. 文化坚守：在 AI 加速开发的背景下，保持“慢思考”的文化至关重要。避免被速度焦虑裹挟，坚持通过深度思考来解决复杂问题，才是构建卓越产品的根本。

Ashby 的经验证明，拥抱 AI 并不意味着放弃工程严谨性，相反，它要求工程师以更高层次的认知能力，驾驭这一强大的生产力工具。