一、这东西，我琢磨了『十年』
说实话，AI编程工具过去一年才火起来，也就是从所谓的Vibecoding让一堆不会写代码的人，以为自己会写代码之后...
从OpenAI的Codex到亚马逊的Kiro，从Claude Code到GitHub Copilot，各种工具层出不穷。我也跟风试了不少，但之前用下来的感受还只是一句话：Demo很漂亮，但也只是停留在漂亮而已（没实际动态存储等并发处理能力，始终只是玩具花瓶而已，门外汉也只是用小打小闹骗得了一阵子学费而已）
为什么会这样？我观察了一圈，发现其实问题核心，去年是在模型能力本身；但今年似乎有点不一样了，核心问题不在工具本身，而是转到了协作模式。
大多数团队，过去都还只是把AI当"写代码的"用，让AI生成一堆代码就完事了。
但真正做项目的人都知道：代码其实还只是冰山一角，上面还有需求、架构、必要的协作流程这些更重要的东西。
除非你做的就只是一锤子买卖，否则但凡你需要一个能长期演进的项目，这些东西如果不理清楚，AI生成的代码越多，维护起来越头疼（3天开发，3个月修bug） 。
那什么，才是现在解决上面项目可长期维护的金钥匙呢？亚马逊推出的Kiro最早提出了"Spec-Driven Development"（规范驱动开发）的概念，这方向是对的。后来国外各种大厂，开始纷纷跟进，OpenSpec等方法框架，现在已经深入应用到大型团队的长期项目实践协作中。
但说实话，Kiro或OpenSpec的门槛并不低，而且很多中小团队用不起来——配置复杂、学习成本高、对团队要求也多。
所以我从去年一直就想：我能不能搞一套轻量级的、适合中小团队的AI编程协作框架？既能借鉴世界一流，先进的项目协作规范驱动思想，又能落地，能快速上手？
这篇文章就是我最近三个月，在真实企业级大型项目中，实践出来的一套，完全可行且自研的AI研发协作脚手架：Sunflower（向日葵）v1.0。
先说下它的战绩：百人不到团队，中大型系统，初次使用全线AI研发，一个月20万行代码不到，AI代码采用率（生成精准率）80%左右，整体人效提升86%左右，AI生成准确率前后端综合85%左右；随着开发同学熟练度提升，相关指标还在攀升甚至有望翻翻
上面战绩，下面这套我自研的AI研发协作脚手架 Sunflower v1.0，可为立下汗马功劳；
二、核心理念：规范驱动，而不是提示词驱动
这个框架的核心理念，其实不难，就三句话：
第一句：规范驱动
别依赖那些模糊的提示词，要把规范写成结构化文档。AI每次干活前，先读规范，照着规范来。
这听起来简单，但真做到的团队不多。大部分人的做法是：每次跟AI说"帮我写个用户注册功能"，然后期待AI能自己猜对。这种模式我试过，翻车概率太高——AI猜的规范跟你的项目规范大概率对不上。
第二句：分层路由
根据不同场景，自动加载不同的规范上下文。
简单查个东西，不需要加载一堆架构文档；做详细设计，才需要看架构规范；正式编码，才需要加载完整的技术栈规范。
这个思路来自网络路由器——不是一股脑把所有信息都塞给AI，而是按需分发。这样既节省token，又能保证AI看到的是它需要的信息。
第三句：渐进增强
从简单到复杂，逐步引入更详细的规范约束。
别一上来就搞个大而全的规范体系，先把核心的、最重要的规范建起来，然后根据需要逐步细化。
这个理念跟Kiro的Spec-Driven高度契合，但实现方式更轻量、更灵活。
三、这套东西怎么跑：从元规则到具体规范
整个框架的核心是元规则设计和分层规范体系。我用一张图来说明：
四层架构示意图
3.1 元规则：整个架构的入口
元规则文件是整个AI协作架构的入口，位于.codebuddy/rules/meta_rule.mdc。内容非常简单：
---
description:
alwaysApply: true
enabled: true
updatedAt: 2026-02-02T01:21:04.929Z
provider:
---
执行所有动作前，都阅读下rules/base_rules.md中的内容，根据其路由逻辑指示，再进一步获取相应系统提示词或背景上下文;
就这么一条指令，但设计上有三个关键点：
- alwaysApply: true：这条规则每次都生效，确保AI不会跳过路由逻辑
- 适配器+单一信源架构：所有请求都先指向
base_rules.md，避免多个入口带来的混乱 - 简洁的指令：只做一件事——路由，把复杂逻辑交给下一层
这就像路由器的默认网关，所有流量都得先经过这里，然后再根据目的地址分发。
3.2 路由机制：三层分发逻辑
路由的核心在rules/base_rules.md，时间仓促，就暂时只列举了三种场景：
场景1：轻量级查询
适用场景：
- ask模式下的简单查询
- 非详细设计方案分析
- 非正式编码的小范围改动
处理逻辑：
用户请求 → 只遵照提示词中的指示 → 读取指定背景文档 → 执行操作
这种场景的特点是"快"，不需要加载太多上下文，直接干活。
场景2：详细设计方案分析
适用场景：
- 需要进行模块级的详细设计方案分析
处理逻辑：
用户请求 → 阅读顶层架构设计规范 (arch_solutions.md)
→ 参考详细设计方案模板 (detail_solution_template.md)
→ 按需加载技术规范文档 (tech_structure_*.md)
→ 生成详细设计方案文档 (写入 ./docs/detail_solutions/)
这个阶段是"想清楚"，要确保设计符合架构要求。
场景3：正式编码落地
适用场景：
- 需要进行具体的需求编码落地
前置条件：已有详细设计方案文档或明确的方案说明
处理逻辑：
用户请求 → 读取详细设计方案文档 (./docs/detail_solutions/)
→ 加载对应端的技术规范文档 (tech_structure_*.md)
→ 生成任务列表文档 (写入 ./tasks/)
→ 生成接口定义文档 (如有需要,写入 ./docs/api_docs/)
→ 按任务逐项完成编码
→ 完成一项勾选一项
这个阶段是"干完活"，而且要一项一项来，每项完成后勾选，确保可控。
三场景处理流程图
3.3 规范体系：从架构到产品的五层约束
整个规范体系分为五层，每一层解决一类问题。
rules目录结构
rules/
├── base_rules.md # 核心路由逻辑（路由表）
├── arch_solutions.md # 顶层架构设计规范
├── detail_solution_template.md # 详细设计方案模板
├── product.md # 产品定义文档
├── tech_structure_backend.md # 后端技术栈规范
├── tech_structure_web.md # Web前端技术栈规范
├── tech_structure_mobile.md # 移动端技术栈规范
└── web_template/ # Web工程模板文件
├── .eslintrc.js
├── .prettierrc.js
├── .stylelintrc.js
└── requestErrorConfig.ts
我来逐层说一下：
第一层：base_rules.md - 路由中枢
这是整个体系的大脑，定义了三种场景的处理逻辑（上面已经详细说过）。它的作用是：根据用户请求的场景，决定加载哪些规范文档。
第二层：arch_solutions.md - 项目的"宪法"
这是顶层架构规范，定义全局架构原则和约束。内容包括：
- MVP需求分析：定义核心功能范围和技术约束
- 模块拆分评估：定义业务模块和技术模块划分
- 工程模块结构：定义各模块职责和依赖关系
- 规则引擎选型：定义技术选型决策
- 数据流模型：定义关键数据流转路径
- 演进规划：定义系统演进路径
这个文件是架构层面的指导，确保所有模块都遵循统一的架构原则。
第三层：tech_structure_*.md - 技术栈规范
这一层定义各端的技术栈、工程结构和编码规范。目前支持三端：
| 维度 | 后端 | Web端 (React) | 移动端 |
|---|---|---|---|
| 技术栈 | Spring Boot | 自研框架 + TypeScript + Ant Design 5 | 自研框架 + React 18 |
| 架构模式 | 分层架构 + 事件驱动 | 组件化 + 单向数据流 | 多端适配 + 分包加载 |
| 规范重点 | DAO层规范、MyBatis使用规范 | Services接口规范、状态管理 | 多端适配、分包优化 |
后端特色规范（我踩过坑的重点）：
分层调用规范：
api层 → service层（需复杂整合的逻辑） → 其他模块service（跨模块调用）
→ 本模块manager → 本模块dao → common工具类
→ manager层（简单业务可直接调用） → 本模块dao → common工具类
→ dao层 → MyBatis XML映射文件
高内聚低耦合规范：
- 每个模块的跨模块调用必须在service层
- 只能调用其他模块的service入口
- 不可直接调用其他模块的service以下内容
DAO层写法规范：
- 优先使用MyBatis BaseMapper的简单SQL方法
- 复杂查询使用XML直观呈现
- 禁止使用函数式SQL拼装写法
- 避免使用动态SQL
- 连表查询最多不超过3个表
- 必须使用逻辑删除
这些规范都是实际项目中踩坑总结出来的，如果不约束，AI生成的代码很容易乱成一锅粥。
第四层：detail_solution_template.md - 设计方案模板
这个文件定义了详细设计方案的结构化输出格式，确保每次生成的设计方案都包含必要的内容：
# TASK-识别标志: 任务名称+详细设计方案
## 文档版本信息
- 文档版本、创建日期、适用任务、涉及模块、预估工作量、优先级
## 内容目录
- 一、设计目标与原则
- 二、整体设计概述
- 三、功能点详细设计（各个关键子功能点详细设计说明）
- 四、优化方案（性能设计/逆向逻辑处理/数据一致性设计等）
- 五、监控与故障处理
- 六、安全设计
- 七、实施计划
这个模板保证了设计方案的完整性，不会漏掉关键环节。
第五层：product.md - 产品定义
这个文件定义产品愿景、目标用户、核心价值和功能范围。内容包括：
- 产品愿景：减少人工巡检80%，提升运维效率300%
- 目标用户：工程售后、运维团队、客户管理员
- MVP功能范围：明确必做功能和暂不做功能
- 技术原则：够简单、流程通、选代表
- 成功标准：业务/技术/用户体验三维度标准
设计意图：让AI理解业务背景和约束条件，生成更符合业务需求的代码。
四、跟Kiro比，我们有什么不一样
Kiro是亚马逊的成熟产品，我们这个是自研的轻量级框架，定位不一样。但有些创新点，我觉得值得说说：
创新点1：轻量级路由机制
Kiro的方式是AI自动理解上下文，全量加载规范文档。我们采用的是元规则路由链：meta_rule.mdc → base_rules.md → 具体规范文档。
优势有三：
- 更节省token成本，按需加载
- 更快的响应速度，不用加载不需要的内容
- 更可预测的行为，AI会做什么很清楚
创新点2：分层规范体系
Kiro是统一的Specs规范集，我们分了五层：
- 元规则层（meta_rule.mdc）
- 路由层（base_rules.md）
- 架构层（arch_solutions.md）
- 技术层（tech_structure_*.md）
- 产品层（product.md）
好处是：
- 关注点分离，各层职责清晰
- 易于维护和扩展
- 支持渐进式引入规范
创新点3：多端协同支持
Kiro主要关注单项目开发，我们原生支持后端+Web+移动端三端协作。
- 统一的技术规范体系
- 统一的接口定义规范
- 统一的数据结构规范
这对全栈团队特别友好。
创新点4：渐进式演进设计
Kiro是从需求到部署的完整流程，我们支持从简单到复杂的渐进式引入：
- Case 1：轻量级场景（最小化规范）
- Case 2：详细设计场景（中等规范）
- Case 3：编码落地场景（完整规范）
好处是：
- 降低学习曲线
- 适应不同规模项目
- 灵活度更高
五、这套框架适合什么团队
说实话，没有万能药，这套框架也有适用的场景。
强烈推荐：
- 中小型团队（5-20人）：规范适度，不过度复杂
- 全栈项目：原生支持多端协同
- 快速迭代项目：渐进式引入，灵活度高
- 新人培养：清晰规范，易于学习
谨慎评估：
- 超大型团队（>50人）：规范可能不够严格，建议引入Kiro或Cursor Team版
- 高度自动化需求：依赖人工审查，不如Kiro的Hooks机制
- 纯AI驱动项目：需要人工定义规范，不如Claude Code或Kiro
六、v2.0已经在路上了
坦白讲，v1.0只是个开始。我们正在升级v2.0，核心目标是融合当下国内外多个领先AI协作范式的百家之长，打造一款自研的、适合中小型团队的AI编程协作脚手架。
v2.0会带来什么：
- 更精准：AI辅助生成规范，准确性提升20%（接近99%）
- 更无感：Hooks自动触发，自动化程度提升50%
- 更容易上手：智能引导系统，学习成本降低40%
- 更强扩展能力：多智能体协作+行业模板，扩展性提升60%
敬请期待！
七、最后说几句
这套AI编码协作范式，说到底就是为了解决一个核心问题：让AI真正成为团队的生产力工具，而不是玩具。
核心特点：
- 规范驱动：通过结构化规范指导AI行为，确保代码质量和一致性
- 分层路由：智能路由到合适的规范上下文，避免过度加载
- 渐进增强：从简单到复杂，适应不同场景和团队规模
- 质量保障：多层规范约束，确保代码符合架构和技术标准
如果你也在做AI编程协作，或者正准备引入，这套框架或许能给你一些参考。
你想看的更多：
- 这套框架的具体配置教程，或源码？
- 真实项目的实战案例？
- v2.0的升级细节？
评论区告诉我，点赞最多的我优先写。
