自2025年8月起，Ashby超过一半的生产代码由AI生成——但客户问题数量保持稳定。这不是玩具项目，而是一家拥有10万+周活用户的企业级SaaS。他们公开了完整的方法论。
事件回顾
6月2日，Ashby公司EMEA工程负责人Colin Howe发布了一篇深度博文：《AI, Ashby Engineering, and the Future》，迅速登上Hacker News热榜（206分），引发工程师社区激烈讨论。
Ashby是一家人才招聘SaaS公司，产品功能涵盖相当于Calendly和Looker体量的独立产品线，每周处理数百万份候选人申请。就是这样一个严肃的企业级产品，从2025年8月开始，超过50%的新增代码由AI生成。他们使用的工具包括Cursor、Claude Max、Codex以及多种Agent框架，工程师拥有无限制的token预算。
但最让人意外的是数据：代码量暴增，客户问题没涨。Colin在文章中直接附上了图表——更多的客户、更多的AI生成代码，但客户支持工单数量保持平稳。唯一的波动是每年3-4月的季节性周期，与AI无关。
Ashby没有强制要求使用AI，也不追踪token使用量。他们的逻辑很直接：「强制使用AI会鼓励滥竽充数（slop）。」
为什么重要
这篇文章之所以引爆HN，是因为它回答了一个整个行业都在焦虑的问题：AI写代码到底靠不靠谱？
过去一年，我们看到了大量的AI编程工具涌现——Cursor、Claude Code、GitHub Copilot、Codex——但绝大多数讨论停留在个人开发者的体验层面。一个人用AI写了个Side Project觉得爽，不代表企业级产品能扛住。
Ashby提供了稀缺的企业级生产数据：
- 10万+周活用户
- 数百万候选人申请/周
- 超过50%生产代码由AI生成
- 客户问题未增加
- 工程师入职上手速度未下降
- 代码质量未退化
这是一组反直觉的数据。按照很多人的担忧，AI写代码应该导致质量下降、Bug增多、新人看不懂代码。Ashby的经验证明：问题不在AI，而在你怎么用。
Colin在文章中提出了一个核心命题：「代码的生产成本正在趋近于零。AI不是来抢我们工作的，它来抢的是工作中那些机械的部分——语法、胶水代码、重复敲击键盘。」真正值钱的永远是工程师的判断力、品味、对客户的理解。
两个核心原则
Ashby的方法论建立在两个不可动摇的基石之上：
1. 同理心不能被AI替代
AI没有品味。它不理解客户。它无法感受使用糟糕产品的挫败感，也无法体会使用优秀产品的愉悦感。在一个「做出能用的产品」变得极其便宜的时代，「做出好产品」的能力更加稀缺。
Colin举了一个非常具体的例子：AI写的PR描述往往是30行充满废话的清单——「新增.github/workflows文件」「触发条件为pull_request」——这些信息看PR本身就能知道，完全不尊重同事的时间。而真正有用的信息——「为什么不做全量测试」——AI反而遗漏了。
2. 你对你发布的代码负责
AI可以非常自信地犯错。最大的风险不是AI错了，而是AI听起来特别对。Colin分享了Claude Code的一次实际操作：它在编辑backend/package.json时「不小心」删除了tar-stream包。不是有意的，但确实发生了。
Ashby的原则是：无论代码是手写的还是AI生成的，你必须理解它在做什么、为什么这样做、出问题了会怎样。
两种协作模式：Sidekick vs Delegate
Ashby将人与AI的协作分为两种模式，这是全文最实用的框架：
Sidekick模式（副驾驶）：你做大多数决策，AI辅助。适用于高风险场景——数据库迁移、候选人数据处理、安全敏感代码、架构决策。这些地方「看起来对」远远不够。
Delegate模式（委托）：你审核输出（有时甚至不审核）。适用于低风险场景——原型开发、本地工具、运维工具。失败成本低，可以快速行动。
Colin观察到一个普遍的规律：大多数工程师一开始会过度委托（什么都让AI做），然后矫枉过正（什么都不让AI碰）。关键问题不是「该不该用AI」，而是「这里我该信任AI多少？」
最简单的心智模型：问自己如果代码错了会怎样？尴尬？昂贵？还是生死攸关？
AI时代的工程安全：瑞士奶酪模型
当代码生产成本趋近于零，安全就不再是个人纪律问题，而是基础设施问题。Ashby采用经典的「瑞士奶酪模型」：每一层都有漏洞，但漏洞在不同位置。
- 测试：捕获代码审查遗漏的边界情况
- 代码审查：捕获测试无法覆盖的逻辑错误
- 功能开关（Feature Flags）：捕获测试和审查都漏掉的线上问题
- 可观测性（Observability）：兜底捕获一切
Ashby还自研了内部代码审查工具，专门寻找生产环境中难以处理的边界Bug。Colin认为自研工具在这一点上优于第三方工具，因为他们可以使用更多token并严格控制上下文。
此外，他们还使用AI辅助客户问题分类，Claude Code自动审查新Bug并生成报告——在某些案例中，这让支持团队在10分钟内修复了原本需要数小时的问题。
一个被忽视的隐忧：AI偏好「造新」而非「复用」
全文最有洞察力的一段话可能是这个：
「LLM偏向于生成新代码而非复用已有代码。如果不加约束，它会给你一个能跑、但没人能读懂的代码库。AI不关心它生成的代码是否复杂。推动简洁性现在是审查者能做的最有价值的事情之一。」
Colin在Side Project中亲身踩过这个坑：一个双模式界面，AI为每个模式单独复制了一份完整的组件代码。他直到修复同一个Bug两次才发现。
这意味着AI时代对代码审查的要求不降反升。但审查的重点必须转移——不再纠结于某人是否用对了useMemo，而是聚焦于：这个改动合理吗？高风险区域在哪？抽象合理吗？性能特征如何？
代码质量从未如此重要——而且会自我强化
Ashby提出了一个让所有工程师脊背发凉的观点：
「我们的代码库有了一个新读者。每个模式、每个命名、每个模块边界现在同时被人类和AI阅读——而AI会照单全收。一个混乱的代码库不仅拖慢你的同事，它还会降低每一个接触它的AI生成代码的质量。代码质量一直很重要。现在它会自我放大。」
这句话的潜台词是：如果你的代码库很乱，AI会学着乱写；如果你的代码库很干净，AI会学着干净。技术债务的利息在AI时代按复利计算。
对AI创业者的启示
Ashby的经验对AI创业圈有三层启示：
第一层：AI编程工具已进入生产就绪阶段。 当一家10万用户的企业级SaaS敢让AI生成超过一半的生产代码，且客户问题不增加时，这意味着「AI编码」已跨过从玩具到工具的鸿沟。对于一人公司和AI创业者来说，这是降维打击——你的竞争对手可能已经用AI把开发速度提到了你无法企及的水平。
第二层：工程文化的升级比工具更重要。 Ashby的成功不在于用了Cursor还是Claude Code，而在于他们建立了清晰的使用原则、安全模型和审查机制。工具是表，方法论是本。
第三层：产品判断力成为终极护城河。 Colin反复强调他们招聘的不是「技术能力强」的工程师，而是「产品意识强、善于沟通、有判断力」的工程师。理由很简单：当AI可以搞定代码实现之后，知道该做什么比知道怎么做稀缺一万倍。工程师不再是写代码的人，而是理解客户、定义问题、做出决策的人。
Ashby正在招聘欧洲和美洲的远程工程师。他们的要求清单暗示了AI时代的工程师画像：产品思维 > 编码速度，判断力 > 技术栈广度，沟通能力 > 刷题能力。
这场变革的速度比大多数人预想的更快。2025年8月开始，2026年6月已经超过50%。这个曲线还在上升。当你还在犹豫要不要让AI写代码时，你的竞争对手可能已经让AI写了半年的生产代码——而且客户没觉得有什么问题。
问题从来不是AI能不能写代码。问题是：你准备好当一个「做决策的人」了吗？
#AI创业 #AI编程 #Cursor #一人公司 #工程文化
本文由AI辅助创作，经人工审核编辑发布