W50-明年在 AI Coding 上团队应该干什么

这周读到 a16z 和 OpenRouter 的《State of AI》，他们用 OpenRouter 平台上 100 万亿级别的真实 token 做了实证研究。 看了个开头就有种时间错乱的感觉，o1 正式版是 2024-12-05 发布，离现在也就刚好一年。推理型模型承载的 token 占比在 2025 年一路上升，最近已经超过一半。

假设未来几年模型能力仍会持续变强（多模态、记忆、Agentic 都会继续外溢），那团队在 AI Coding 上的核心目标，就不应该只是引入几个工具、攒几套提示词，而是建设 AI-Ready 的工程基础。让模型越强，我们的交付能力越能被解锁。

让工作可以长期发生在主航道上，以下五个方面都具备可积累性。

1）架构

一个讲不清道不明的项目，AI 也很难发挥。不仅消耗大量 token，而且极易因忽略隐式依赖而引发回归 Bug。前端架构里的主要问题，就是视图和业务逻辑混在一起，逻辑与副作用的纠缠，易变的和不易变的拆不开。不是用了 MVVM、MVC 就能解决的。

项目应该能明确回答“核心代码是什么”。核心代码承载所有业务逻辑与状态演化，理想情况下，是纯函数、框架无关、零环境依赖、可单测、输入输出确定的。其余部分处理网络I/O、副作用、UI渲染。这样 AI 才有稳定的着力点，改动也更可控。

2）上下文显性化

如果缺乏历史背景，AI 也无法理解为什么代码中存在某些奇怪的 hack。文档和注释的重要性，已经不只是知识沉淀，而是直接影响代码生成质量。

更具体一点，业务领域信息、架构约束、技术栈偏好、团队工程规范都应该被显性化，最好能沉淀成 AI 更容易消费的形式，例如 ADR、约束清单、README 的“不可破坏项”，配合合适的工具链，把上下文喂给模型。

3）约束左移

我很认同通过编译器/静态分析把问题左移的思路。严格编译的代表语言是 Rust，但前端多数场景并不是非要 Rust 才能避免事故。真正的问题是 TS 的语言优势没有被充分地用起来。这个主要原因是历史上为了更快的普及TS，允许以很宽松的方式使用TS，但事实上很多项目在类型和编译约束上并没有开全。

TS的 strict 模式是基础，是不可协商的，必须激进地禁止像 any 这种无意义类型。统一自定义 Lint 规则是必要的，编写自定义 ESLint 规则以强制执行架构边界，统一语言风格，例如强制 Composition API 、禁止跨层依赖。

4）程序化验证

代码生成会越来越便宜，真正昂贵的是验证代码是否正确，让低成本验证的工作先发生。这既顺应了 TDD 的思想，也解决了过往 TDD 落地成本高的痛点。

有了良好的架构就能很好地识别出核心代码，对核心代码做单测覆盖就变成了性价比很高的事情。前后端是依据契约完成协作的，加入 Zod 保证对 Schema 的运行时验证是有必要的。前端和 QA 是通过测试用例协作的，在实现前写清楚验收条件或自然语言测试用例，这看起来很无趣，但可能很有效。

5）可观测性与排查

客诉响应、线上问题排查会随着组织扩张和分工细化效率越来越低。各个服务日志信息分散，群里来回收集事实信息就能耗掉几个小时。

打通日志与可观测性，让 AI 能看到完整上下游数据。至少做到结构化日志、统一 trace、关键链路可回放。先把事实收集自动化，工程师的响应才能更敏捷。同时也是 AI 自动化诊断的必要前置。