腾讯团队 AI Native 研发实践
从"AI 辅助编码"到"0 人工 Coding"的完整方法论
核心洞察
腾讯团队在 2025-2026 年的实践中发现：把 AI 当打字员用，天花板很低；把 AI 当施工队用，才有真正的效率革命。
传统 AI 辅助编码的四大痛点：
| 痛点 | 表现 | 根因 |
|---|---|---|
| 人机协作无标准 | 效果取决于个人提示词功力 | 没有统一的 AI 交互规范 |
| 流程断点 | 工程师在文档和 IDE 之间人肉搬运 | 设计工具和编码工具数据隔离 |
| 上下文缺失 | AI 不认识项目，可能重复造轮子 | AI 无法主动读取项目代码库 |
| 文档脱节 | 方案写进 Wiki 就再没更新 | 文档和代码不在同一个版本控制系统 |
OpenSpec：机器和人都能理解的"研发契约"
核心理念
把开发比作盖房子：
- 旧做法：你像个包工头，跑到砖厂喊"来100块砖"，AI 不知道你要盖什么
- OpenSpec 做法：和 AI 一起把建筑图纸画清楚，AI 施工队按图纸全自动施工
目标态：人做什么，AI 做什么？
| 阶段 | AI 负责 | 人负责 |
|---|---|---|
| 需求分析 | 提炼需求、发现遗漏、结构化输出 | 优先级判断，审批需求边界 |
| 方案设计 | 生成技术方案、架构图、接口定义 | 技术选型拍板，安全审查 |
| 代码开发 | 多文件编码、补充注释和单测 | 评审关键代码，控制合并门禁 |
| 测试验证 | 生成测试脚本、执行回归测试 | 审核高风险场景，最终放行决策 |
| 发布上线 | 校验实现与需求一致性 | 审批发布窗口，处理事故升级 |
人的核心角色只有三个：决策、审批、把关。
三步核心工作流
Step 1: /opsx:propose — 先想清楚，再动手
/opsx:propose 帮我生成一个关于 [新增用户权限控制模块] 的变更
AI 在 openspec/changes/[变更名]/ 目录生成：
| 文件 | 作用 |
|---|---|
proposal.md |
需求背景与目标（"为什么做"和"做什么"） |
design.md |
技术方案与架构决策（"怎么做"） |
tasks.md |
带复选框的实施清单（AI 的"施工单"） |
specs/ |
规范增量（本次变更的"差异记录"） |
原则：严禁直接让 AI 写大段业务代码，必须先生成规划文档。
Step 2: /opsx:apply — 让 AI 按图施工
/opsx:apply [变更名称]
AI 会：
- 读取
tasks.md清单 - 结合
design.md和proposal.md完整上下文 - 跨文件批量生成/修改代码
- 每完成一项自动在
tasks.md里打钩 ✓
开发者此时只需要做一件事：Code Review。
Step 3: /opsx:archive — 让规范活起来
/opsx:archive [变更名称]
系统自动将规范增量合并到 openspec/specs 主目录。
意义：项目文档永远和代码保持同步。没有"僵尸 Wiki"。
三大武器库：让 AI "懂"你的项目
1. 知识库（核心记忆 + 辅助记忆）
通道一：OpenSpec specs/（核心记忆）
- AI 执行
/opsx:apply时自动读取 - 每次
/opsx:archive后自动更新 - 始终与代码保持同步
通道二：MCP 外部知识（辅助记忆）
- 通过 MCP 连接 Knot 知识库平台
- 存放业务术语表、架构决策历史、踩坑记录等
| 知识类别 | 内容 | 来源 |
|---|---|---|
| 业务知识 | 产品功能说明、核心业务流程 | iWiki |
| 架构知识 | 系统架构图、模块依赖、技术选型 | iWiki + Git |
| 项目规范 | 目录结构约定、数据模型定义、接口契约 | OpenSpec specs/ |
| 历史决策 | 技术选型原因、已知限制 | iWiki + OpenSpec |
2. MCP：AI 的工具连接层
| MCP 工具 | 连接目标 | AI 获得的能力 |
|---|---|---|
| TCS Component | 前端组件库 | 查询组件使用规则，确保风格统一 |
| TAPD MCP | 需求平台 | 直接查询原始需求/Bug 单 |
| iWiki MCP | 文档平台 | 直接检索设计文档、架构文档 |
| 极光流水线 MCP | 部署平台 | 触发构建、查看部署状态 |
效果：信息零损耗传递，消除"复制粘贴"式跨工具搬运。
3. Skills：AI 的专业技能包
团队沉淀的标准化操作流程（SOP），封装成 AI 可复用的"技能包"。
示例：openspec-installer Skill
把新人入职环境搭建的 8 步压缩成一句话：
请执行 curl -fsSL http://...（安装指令）
AI 自动完成：检测 OS → 安装 Node.js → 安装 OpenSpec CLI → 生成项目结构 → 配置 MCP → 批量安装 Skills → 搭建知识库目录
关键设计模式
Bridge Rule：解决"链路断裂"问题
问题：openspec/config.yaml 中配置的 rules，AI 不知道要去读。
解法：在安装时自动生成 Bridge Rule 文件到 .codebuddy/rules/，像"指路牌"告诉 AI：
"当你执行 OpenSpec 操作时，先去读
openspec/config.yaml中的 rules。"
原则：只做"指路"，保持 config.yaml 作为 single source of truth。
Token 交互：在 SKILL.md 指令层完成
问题：MCP 需要 PAT Token，bash 脚本的 read -p 在 CodeBuddy 非 TTY 环境会挂起。
解法：把 Token 交互写在 SKILL.md 的 SOP 里，让 AI 在对话中完成获取，再用 Python 脚本写入配置。
安全防护：自动将 .mcp.json 加入 .gitignore，防止凭证泄漏。
三级降级策略
场景：openspec-installer 自身版本检查需要访问工蜂仓库。
1. 优先：通过工蜂 MCP 服务查询 version.json（需 Token）
2. 降级：如果在仓库目录内，直接读取本地 version.json
3. 兜底：静默跳过版本检查，不阻塞安装
原则：辅助功能的失败不应该阻塞核心功能。
团队协同规矩
原子化变更原则
| 规则 | 说明 |
|---|---|
| 一次变更解决一个需求 | 每次 Change 只对应一个明确的业务需求或 Bug |
| tasks.md 控制在 15 项以内 | 避免 AI 因上下文过长产生遗忘或幻觉 |
| 小步快跑 | 确保人工 Code Review 在可控范围内 |
"规范即文档"原则
openspec/specs/目录就是永远与代码保持一致的"活体文档"，替代传统的沉睡 Wiki。
要求：禁止绕过 OpenSpec 直接手写大量核心业务逻辑，否则会破坏"规范与代码"的同步性。
MR 审查双重视角
| 审查维度 | 内容 | 对照文件 |
|---|---|---|
| 代码逻辑 | AI 生成的代码是否遵守约束条件 | design.md |
| 架构合规 | 技术方案是否符合团队底线 | proposal.md |
| 需求覆盖 | 所有规范中定义的行为是否已实现 | specs/ |
认知升级：AI 不是来替代程序员的
AI 是来重新定义"程序员"这个角色的。
- 以前：核心价值是"能写代码"
- 现在：核心价值是"能指挥 AI 写出正确的代码"
这像极了软件工程发展史上的跃迁：
- 从机器码到汇编：不再关心寄存器
- 从汇编到高级语言：不再关心内存地址
- 从写代码到 AI Native：不再关心具体代码实现，而是关心需求定义和架构决策
指令速查表
| 指令 | 阶段 | 说明 |
|---|---|---|
/opsx:explore |
探索 | 与 AI 讨论需求，沉淀文档，不写代码 |
/opsx:propose |
规划 | 一键生成全套规划文档 |
/opsx:apply |
编码 | 严格按 tasks.md 清单自动编码 |
/opsx:archive |
归档 | 合并规范增量到主干，清空草稿 |
/opsx:new |
准备 | 创建空脚手架（扩展版） |
/opsx:continue |
步进 | 逐文件生成，逐步审查（扩展版） |
/opsx:ff |
快进 | 一次性补全所有规划（扩展版） |
/opsx:verify |
审计 | AI 代码审计，比对 design.md（扩展版） |
项目目录结构
项目根目录/
└── openspec/
├── config.yaml ← 项目配置（技术栈、规范风格、业务背景）
├── specs/ ← 归档区：系统功能的"活文档"
│ └── [功能名称]/
│ └── spec.md
└── changes/ ← 工作区：进行中的变更提案
└── [任务名称]/
├── proposal.md ← 为什么做、做什么
├── design.md ← 怎么做
├── tasks.md ← AI 的施工清单
└── specs/ ← 变更增量
Sources
- 当整个团队开始 0 人工Coding：一份万字AI Native研发实战手册 — 腾讯程序员/binxiong