---
title: "团队 AI Native 建设真实进展分享"
subtitle: "从基础设施、工具普及到生产协作的一次内部观察"
last_updated: 2026-05-23
---

# 团队 AI Native 建设真实进展分享

团队 AI Native 建设真实进展分享，效果惊人，产品经理提出的 PR 直接上线？

目前所在的团队，几个月前就开始推进 AI Native 建设，不是说说的那种，是有专人负责建设，开发工具，开展分享培训，近期一个取得了一些进展，分享一下。

## 先说效果

从一个需求完成切入。早先我们先后完成了两个需求。

在用户完成创作以后，会帮用户生成一句话，作为作品的总结。

用户记忆系统开发完成，每个用户有一份独有的记忆文档。

这两个是顺序完成的，现在希望用户的记忆可以用于前一个场景，生成的作品总结有用户自身的说话风格。这是一个相对简单的需求，在我们团队里，之前是要由两个研发和产品分工完成的。

研发：需要打通基本的链路，在生成作品总结的时候，连上用户记忆的查询功能。

模型产品：负责调 prompt，效果把关。

这次模型产品在调 prompt 效果经过内部展示和优化，本来下一步是需要研发基于他们的 demo 做后续开发。但这次是：产品直接给出了一个 Git Branch，在研发 review 之后，觉得这个 MR 完全可以直接合入，没有任何问题。

你知道这说明什么吗？小需求已经在产品侧直接闭环了。

## 发展路径

回头看，这个发展大概分成了几个阶段。

## 第一阶段是基础设施建设

这一步看起来不太性感，但很关键：统一 AI 工具账号，完善内部知识库，开放必要的代码仓库，整理项目文档和开发环境，把团队使用 AI 的基础条件补齐。

它解决的不是“某个人会不会用 AI”，而是“整个团队有没有条件稳定地用 AI”。如果账号、权限、文档、仓库、环境都不清楚，AI 再强也只能停留在个人尝试。

## 第二阶段是工具使用普及

当 Cursor、Claude Code、Codex、Git 这些工具开始被培训和推广后，变化开始变得更明显。大家不只是用 AI 写文档、总结信息，也开始自己做 demo、写脚本、处理日常工作中的小问题。

这一步的意义是：写代码开始不再完全属于研发序列。很多人未必会成为专业工程师，但他们开始能用代码解决自己的问题。

## 第三阶段是进入生产协作

前两个阶段是团队内有专门负责 AI Native 的同学建设，他们打好了基础，现在是化学反应发生的时候了。

我是团队的Agent开发，在今年3月开始Agent的重构，因为早些时间野蛮发展，代码仓库已经有点难以维护了。我自认为我个人的开发习惯比较好，写出来的代码比较优雅，模块分得也比较清晰。这次重构是在 AI 的协助下进行的，但我全程把把关了架构设计。并且配套了完善的指南，包括

- 代码架构说明
- 开发环境一键配置指南
- 开发功能典型入口
- 自测和AI驱动全流程测试文档

上述功能都包装成了代码仓库说明，通过文档， CLAUDE.md，skill组织在一起。并且最后经过测试，一个完全不懂代码的人进入这个仓库，跟 CodeX 说一句“我想要 XX 功能”，AI 就可以进入开发。

## 效果已经出现

重构大概在 5 月完成了。我们让第一批产品经理开始试水这个开发，效果非常成功，他们已经能够搭一些简单的 demo 了。

但是也必须得承认当前的缺陷：如果涉及到一些调用流程比较大的改动，AI 会写出比较垃圾的代码。产品经理可以依赖这些代码去看到产生的效果，但研发在 review 之后不能直接合入，必须做些清理，避免技术债的快速积累。但是对于小需求，PR 在Review 后已经可以直接合入了。

所以最终产生的效果是，产品的奇思妙想不再需要研发配合，他们可以快速实现demo，验证效果。对于复杂需求，这是个还需要研发review的demo，对于简单需求，这直接就完成了。

下一步应该是继续建设，可能是把更多流程接入。目前完成代码开发后，上线和测试接入还是手动连接的，那么如果这部分也完成了，那真是一路畅通无阻啊。

程序员在砸自己饭碗这件事上，真的非常积极。
