核心内容总结
本文围绕企业“AI原生研发”的实践展开，解释了为什么企业追求AI原生时会感到“割裂感”（个人用AI提效容易，但组织级落地难），然后介绍了SDD（规格驱动开发）这一组织级AI原生方案，通过重构项目的实战对比了Spec-Kit和BMAD两个工具的特点、优缺点，最后指出AI原生的核心是重新组织协作流程——让团队适应AI能力，而非仅让每个人用AI工具。
一、为什么企业搞AI原生会觉得“不酷”甚至“割裂”？
个人用AI写代码时，感叹“效率翻倍”；但企业推AI原生时，却发现一堆“不酷”的问题：
- 权限怎么设？哪些任务AI能自动做？PR谁审核？
- AI生成的todo重复了怎么办？单测失败谁兜底？
- 自动合并代码出事故谁负责？AI催材料的话术会不会冒犯同事？
这些琐碎规则和兜底机制，让企业觉得AI原生“Low”，但这是必须的——个人要的是“快”，组织要的是“稳定的快”。偶尔的惊艳没用，组织需要AI在流程里不出错、可控制，所以这些“不酷”的细节恰恰是AI原生落地的关键。
二、AI原生研发的核心：不是“人人用AI”，而是“AI参与协作”
很多企业以为“人人用ChatGPT写代码”就是AI原生，其实错了。
AI原生的真正核心是：让AI进入团队的任务流、协作流、交付流，成为虚拟成员。比如案例里的AI：
- 自动监听群聊/日志，识别问题、整理todo；
- 能写代码的自动创建需求、改代码、跑测试、提交PR；
- 上下文不足时主动找责任人补材料；
- 甚至用两个模型交叉Review低风险代码。
关键转变：从“AI能不能帮我写代码”变成“AI依据什么写代码”——需要给AI明确的规则、需求边界、业务逻辑，让它稳定输出。
三、SDD：给AI立规矩的“规格驱动开发”
SDD（Spec-Driven Development）就是给AI定规矩的方法：用清晰的“规格”（需求、方案、任务）驱动AI开发，避免AI乱脑补。GitHub的Spec-Kit把这个理念推火了。
- 核心作用：给AI提供稳定的上下文环境（需求边界、代码规则、业务约束），让组织级的AI使用更有序，减少返工和内耗。比如Spec-Kit强制把散乱的需求、方案、任务标准化，让AI按步骤来。
- 本质：把AI从“自由发挥的助手”变成“按规矩办事的员工”，让团队协作有统一的基准。
四、Spec-Kit vs BMAD：两个工具的实战PK
1. Spec-Kit：像“固定流程模板”
- 特点：流程清晰（specify→plan→tasks→implement），强制标准化。适合单一Feature、团队基建好（有规范、多仓库治理）的情况。
- 问题：实际项目复杂（多仓库、多角色）时，需要补很多机制（比如多仓适配、门禁卡点）。比如作者用Spec-Kit时，要自己封装命令让AI知道前后端代码写在哪里，还要加门禁检查API是否冲突。
2. BMAD：像“AI虚拟团队”
- 特点：内置产品、架构师、QA等AI角色，有“圆桌评审”（多角色挑刺），能兜底能力不足的地方。比如帮作者发现重构要考虑线上切换、老系统基线问题，还砍了13项非必要需求。
- 问题：审阅工作量大，心智负担重——每个细节都要审，不擅长的领域（比如前端审后端方案）更痛苦，前期时间可能比人类协作还长。
五、选工具看团队：小团队用BMAD，大团队用Spec-Kit
- BMAD适合：一人/小团队，缺角色（比如缺架构师），需要AI补能力下限。它能模拟完整团队，帮你规避漏洞。
- Spec-Kit适合：团队能力强、基建完善（有规范、多仓库治理），需要AI输出更可控。它能让AI在现有体系里高效干活。
最后回到核心：AI原生不是“工具的堆砌”，而是“流程的重构”——让团队适应AI的能力，才能真正把AI的效率转化为组织的效率。