好上下文产出好代码:StockApp 如何从零构建 AI-Native 工程文化

创办 StockApp 给了团队一个从零构建 AI-native 开发文化的机会。他们的经验:这比手工开发的生产力高出实质性的一截(约 2.5 倍),也比「拿既有开发文化用 AI 增强」高效得多(约 2 倍)。AI-native 开发不是取代工程师,而是通过精心营造的共享上下文,建立系统化的人机协作。为此,他们做了这些改变:

• 把所有代码、技术文档和 agent 指南组织进一个 monorepo——它是人与 agent 的共享工作区。有了 agent,文档和代码一样重要。
• 从高层设计开始,先和 agent 就设计对齐,再一路向下写到代码。
• 能用 agent 的地方尽量用、尽量频繁地用,但要监督和审计它们的工作,并持续把新规则沉淀进它们的指南。
• 配置 MCP 服务器和命令行工具,给 AI 行动所需的上下文,让它以更高质量和信心行事;并把配置在团队内共享,提升所有人产出的一致性与质量。
• 用多个不同的 agent 评审并预批工作,再交人类评审——「人类 + 多 agent」的集成(ensemble)稳定优于单 agent 或纯 agent 方案。

StockApp 于 2025 年 1 月启动,带着一个独特的机会:从第一天起就围绕 AI-native 开发来设计工程文化。他们没有把 AI 工具翻新改装进既有流程,而是把整个开发工作流架构成系统化的人机协作。

衡量开发者生产力出了名地难,但他们的主观体验 + 客观测量(脚注¹)指向约 2.5 倍的增益——远超他们在别处的经历。团队里多位成员来自 Google 这类顶级工程组织,对「高水平开发长什么样」心里有数,而这是他们所有人经历过的最高产环境。而且这个增益还在变大:一方面模型在进步(如 Claude 4.1 发布带来的编码性能提升),另一方面人与 agent 的协作也在磨合。后者很关键:他们大量迭代实验协作方式,即使模型不变,更好的技巧(如下文这些)也带来了可测量的生产力提升。

为了给后面的技术决策提供背景:Web 前端用 TypeScript,后端服务由 Python 和 TypeScript 分担,全部维护在一个 monorepo 里。日常编码辅助主力是 Claude Code,多数队友把它跑在 Cursor 里以获得实时自动补全;Cursor 自带的 AI 很少用。他们也试过 VS Code、Windsurf 和 Gemini CLI,但这套组合被证明对他们的工作流最有效。

五条原则同出一源:人与 agent 必须迭代地创建、打磨、消费共享上下文。做到这一点,伟大的软件就会涌现,代码本身反而成了中间工件——就像汇编语言位于高级语言和机器码之间那样。

他们的仓库是同时为机器和人组织的,因为 AI 的表现高度依赖「够得着的上下文」。这正是如今上下文工程(context engineering)比提示工程更重要的原因,也是 monorepo 成为他们运营流程重要一环的原因。自然语言和编程语言同等关键——他们对待英文文档像对待 TypeScript 或 Python 一样用心。系统状态必须对人和 agent 都可见,所以他们有意往仓库里放比「纯人类团队」更多的东西:仓库不只给人用,也给机器用。

文档驱动的做法把自然语言工件当一等公民,关键上下文存放在:

更好的上下文产出更好的代码,但创建上下文并不简单。他们自顶向下工作,每一层都是人机协作:

• 设计(Design)——人提供关键需求与约束;agent 起草设计文档;双方迭代后提交入库。
• 计划(Plan)——agent 把设计转成分阶段任务;人评审、批准。
• 实现(Implement)——agent 承担大部分编码;人评审结果。
• 后盾(Backstop)——测试等保障机制确保后续修改不会侵蚀来之不易的上下文。最明显的后盾是测试,但广义上包括一切能强制执行已建立上下文的机制。
• 评审(Review)——人与 agent 对功能做最终评审,确保达成原设计文档定下的目标。
• 更新与打磨(Update & refine)——更新文档、CLAUDE.md、schema,让未来的 agent 继承准确的上下文。

他们几乎在工作的每个方面都用 agent,任何任务开工前先问一句「这能用 AI 做吗」。但如前所述,他们极少(如果有过的话)让 agent 无监督地掌方向盘:在按下回车前,他们会一丝不苟地检查 agent 做了什么、建议了什么。他们不搞「vibe code」。这种监督与检查,依然需要他们最深厚的技术专业能力。

一些也许不那么常规的 agent 用法(原文逐条):

他们大量使用 MCP(Model Context Protocol)服务器,也给 AI 开放强大的命令行选项让它自己探索信息。新仓库初始化时会跑一个 install_mcp.sh 脚本安装常用 MCP 服务器——目前装大约 6 个,包括:

如果老派机器学习教会了我们一件事,那就是集成优于个体:随机森林、stacking、bagging、boosting——这些技术都构建多个分类器,再用某种投票机制汇总。只要分类器之间有足够的多样性,集成的结果通常显著好于任何单个个体。

他们手里最有意思的 MCP 服务器可能是 Zen MCP server:它让 Claude Code 能向 Gemini、o3 等其他 LLM 征求反馈。他们用它增强系统表现,发现不同 LLM 各有长短。这与前述开发流程结合使用——比如 Claude Code 写完一份设计后,再让 Gemini 评审一遍。这种多样性在很多地方有用,例如 Gemini 在预先识别安全问题上表现明显更好。

▲ 近期实例:为 MCP 服务器设计鉴权方案时,两个模型给出的不同意见(原文照录)。

原文结尾附招聘信息:他们在找顶尖工程师,共同推进 AI-native 开发的边界,在 AI 与商业的交汇处构建产品(联系 careers@stockapp.com)。

脚注¹ · 开发指标(2025 年 Q2,原文照录)

原文的诚实限定:开发者生产力指标应谨慎解读;且他们正处项目的「build」阶段——通常是最快的阶段——而行业标准是「build + maintain」的平均值。

术语表(增补)

AI-native

从第一天就围绕人机协作设计流程,而非把 AI 塞进旧流程(retrofit)。

上下文工程

系统性地组织「AI 够得着的信息」(文档、schema、指南),原文认为它已比提示工程更重要。

monorepo

把全部代码+文档放进一个仓库,成为人与 agent 的单一共享工作区。

后盾(backstop)

防止后续修改侵蚀既有上下文的强制机制,测试是最典型的一种。

vibe coding

不看代码、光凭感觉放任 AI 生成的开发方式——本文团队明确拒绝这么干。

过度 mock(overmock)

测试里把真实依赖替换得太彻底,以致测试通过也证明不了系统真的能跑。

插桩(instrumentation)

在代码中加日志/探针以观察运行行为;agent 擅长做这类繁琐工作。

ensemble(集成)

机器学习术语:多个模型投票的组合,多样性足够时稳定优于单个模型;本文把「人 + 多个 LLM」也视为一种集成。

Zen MCP server

让 Claude Code 调用 Gemini、o3 等其他 LLM 做评审/参谋的开源 MCP 服务器。

元提示(meta prompt)

「关于如何写提示的提示」——团队用它让 agent 代写具体任务的 prompt。