Bellroy CTO：把工程当利润中心用大模型

澳大利亚配饰与箱包品牌 Bellroy 的首席技术官 Mike West 日前发表长文，结合公司在日常研发中的实际做法，分享对「大模型该用在哪儿、不该用在哪儿」的方法论思考。文章明确，作者本人手写全文，仅在送审前用 Claude 做过一轮文字反馈。

公司定位决定工程取舍

West 在开篇即强调 Bellroy 不是软件公司，而是「恰好具备技术能力的实体产品公司」。公司自成立起就持续盈利，并不追赶融资节奏，因此一切技术决策都需以长期 ROI 为锚——更快交付代码的收益，必须被未来的维护成本抵消。基于此，Bellroy 把工程团队定位为利润中心而非成本中心，这一思路塑造了他们对大模型的整体态度。

利润中心思维的几个落点

West 列举了几项与 AI 使用无关、但构成其评估 LLM 价值底色的工程实践：

选择静态类型的函数式编程语言，从源头消除整类生产故障
对所有代码仓库做定期依赖更新，避免零日漏洞与「依赖腐烂」造成的紧急救火
采用「时间固定、范围灵活」的项目管理法，杜绝项目空转
用团队自建的蒙特卡洛模拟 NPV 工具评估项目收益，反推优先级与砍掉 scope

West 认为，工程不只是交付功能，还需协助业务方厘清「真正需要什么」而非「嘴上要什么」，因此技术团队不能脱离业务流程独自运转。

对 LLM 的克制使用

在 LLM 使用边界上，Bellroy 给出了相当保守的答案：

维护和 Bug 修复：会用 LLM，但凌晨 3 点的生产事故仍由人类工程师处理，LLM 不被授予生产环境的写入权限
系统架构的可读性：必须由人类工程师掌握，新员工上手坡度是评估工程健康度的硬指标
业务建模与类型设计：先由人精心设计承载业务不变量的类型，再让 LLM 基于这些类型草拟功能代码

West 写道，如果有人擅长商业分析并已验证某项改动的 ROI，他不会绕过工程部自行用 vibe coding 把东西「发出去」——因为这忽略了那个人本可以做的下一件更值的事，也剥夺了技术团队在设计阶段的参与权和后续维护的掌控权。

一个对 Claude 的具体吐槽

文章最后落到一个细节观察：Claude 在生成代码改动时倾向于添加冗长注释，即便被明确要求「不要这样做」。这些注释常常复述代码做了什么、把 prompt 里的上下文抄进文件、或引用已经被取代的上一版状态。West 认为这类「描述代码本身」的注释最危险——一旦实现继续演化，注释就会与代码漂移，制造比不写注释更大的混乱。Bellroy 内部规范要求注释只回答「为什么这样写」，把「做了什么」留给命名和类型自己去表达。

没有基准，只有取舍

通篇没有出现跑分、token 数、上下文长度或定价对比，更接近一份基于长期工程经验的取舍清单。West 想传达的核心结论是：与其争论 LLM 能让开发快多少，不如追问「不写代码的那个人本该在做什么」以及「交出去的代码未来由谁维护」——这两个问题的答案，决定了模型在公司流程里的位置。