方法论
AI-Native 创业的核心方法论和最佳实践。
核心理念
1. AI First，不是 AI Only
┌─────────────────────┐
│ AI First │
│ ┌─────────────────┐ │
│ │ AI 优先处理 │ │
│ │ 重复性任务 │ │
│ └────────┬────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 人类专注于 │ │
│ │ 创造性工作 │ │
│ └─────────────────┘ │
└─────────────────────┘
❌ 错误理解：用 AI 替代所有人
✅ 正确理解：让 AI 处理重复工作，人专注创造2. 迭代速度是核心竞争力
传统模式:
需求 ──────────────────────────────────► 上线
规划 设计 开发 测试 部署
1周 1周 2周 1周 3天
总计: 5周+
AI-Native 模式:
需求 ──────────────────► 上线
AI执行 审核 部署
1天 2h 1h
总计: 1-2天3. 文档即代码
所有知识都应该被文档化，成为 AI 可理解的上下文：
项目结构:
├── docs/ # 文档 (给人和 AI 看)
│ ├── architecture.md # 架构设计
│ ├── api-spec.md # API 规范
│ └── decisions/ # 决策记录
├── src/ # 代码
└── CLAUDE.md # AI 上下文 (关键!)CLAUDE.md 示例:
markdown
# Mooting Backend 项目
## 技术栈
- Spring Boot 4.0.2
- SQL Server
- JWT 认证
## 代码规范
- Controller 只做参数校验和返回值包装
- 业务逻辑放在 Service 层
- 使用 @Validated 进行参数校验
## 常见任务
- 新增 API: 参考 UserController
- 新增表: 参考 entity/User.java工作流最佳实践
需求表达
使用结构化模板:
markdown
## 需求背景
用户反馈登录流程太复杂，希望支持手机验证码登录。
## 功能描述
1. 用户输入手机号
2. 点击发送验证码
3. 输入验证码完成登录
## 验收标准
- [ ] 验证码 60 秒后可重发
- [ ] 验证码 5 分钟有效
- [ ] 错误 5 次后锁定 30 分钟
## 技术约束
- 使用阿里云短信服务
- 验证码存储在 Redis任务分解
让 AI 将大任务分解为可执行的小任务：
用户: @莫扎特 实现手机验证码登录功能
莫扎特: 任务分解如下：
□ 后端任务
├── □ 创建 VerifyCodeController
├── □ 实现发送验证码 API
├── □ 实现校验验证码 API
├── □ 集成阿里云短信 SDK
├── □ Redis 存储验证码
└── □ 编写单元测试
□ 前端任务
├── □ 创建验证码登录页面
├── □ 实现倒计时组件
└── □ 集成后端 API
□ 其他任务
├── □ 更新 API 文档
└── □ 配置阿里云短信模板代码审查清单
AI 应该检查：
markdown
## 安全性 ✅
- [ ] 无 SQL 注入风险
- [ ] 无 XSS 风险
- [ ] 敏感信息未硬编码
- [ ] 日志不包含密码
## 代码质量 ✅
- [ ] 遵循项目代码规范
- [ ] 命名清晰有意义
- [ ] 无重复代码
- [ ] 异常处理完善
## 测试覆盖 ✅
- [ ] 有单元测试
- [ ] 覆盖主要分支
- [ ] 边界条件测试
## 文档 ✅
- [ ] API 文档已更新
- [ ] 关键逻辑有注释持续集成
yaml
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: 运行测试
run: ./gradlew test
- name: AI 代码审查
uses: anthropics/claude-code-review@v1
with:
api_key: ${{ secrets.ANTHROPIC_API_KEY }}
- name: 构建
run: ./gradlew build知识管理
决策记录 (ADR)
每个重要决策都应该记录：
markdown
# ADR-001: 使用 JWT 进行身份认证
## 状态
已采纳
## 背景
需要选择 API 认证方案。
## 决策
采用 JWT (JSON Web Token) 无状态认证。
## 原因
1. 无需服务端存储 Session
2. 便于水平扩展
3. 移动端友好
## 后果
- 需要处理 Token 刷新
- Token 无法主动失效（除非使用黑名单）
## 相关
- ADR-002: JWT 刷新策略项目上下文同步
定期更新 AI 的项目理解：
bash
# 每周更新项目摘要
@莫扎特 请总结本周的代码变更，更新项目文档
# 新成员加入时
@莫扎特 帮新同事 Alice 介绍项目架构和开发流程质量保障
分层测试
┌─────────────────────────────────────┐
│ E2E 测试 (5%) │ ← 关键流程
├─────────────────────────────────────┤
│ 集成测试 (15%) │ ← API 层
├─────────────────────────────────────┤
│ 单元测试 (80%) │ ← 业务逻辑
└─────────────────────────────────────┘AI 生成代码的审查原则
- 不盲目信任 - AI 也会犯错
- 重点审查:
- 安全相关代码
- 数据处理逻辑
- 边界条件
- 运行测试 - 确保测试通过
- 人工抽查 - 定期深入审查
效率度量
关键指标
| 指标 | 说明 | 目标 |
|---|---|---|
| 需求响应时间 | 从需求提出到开始开发 | < 2 小时 |
| 功能交付周期 | 从开始开发到上线 | < 3 天 |
| Bug 修复时间 | 从报告到修复 | < 4 小时 |
| 代码审查时间 | PR 创建到合并 | < 2 小时 |
| 部署频率 | 每周部署次数 | > 5 次 |
度量工具
bash
# 使用 AI 生成周报
@莫扎特 生成本周开发效率报告，包括：
- 完成的功能数量
- 修复的 Bug 数量
- 平均 PR 审查时间
- 代码变更统计常见陷阱
❌ 过度依赖 AI
问题: 让 AI 做所有决策，失去对项目的掌控
解决:
- 人类保持对架构的理解
- 定期 review AI 的代码
- 关键决策人类做❌ 上下文丢失
问题: AI 不了解历史决策，重复讨论
解决:
- 维护 ADR (决策记录)
- 更新 CLAUDE.md
- 定期同步项目知识❌ 安全疏忽
问题: AI 可能生成有安全漏洞的代码
解决:
- 安全代码必须人工审查
- 使用自动化安全扫描
- 不让 AI 直接操作生产环境