使用场景

FennoAI 在你需要将意图转化为代码、又不想离开 Git 工作流时最为强大。以下是团队每天都在用的场景。

场景 1：Bug 报告变成修复 PR

现状：用户报了一个 Bug。团队需要分类、指派、有人克隆仓库、调试、写修复、写测试、提 PR。至少半天。

用 FennoAI：在 Issue 里评论一句，几分钟拿到 PR。

Issue #142: Safari 移动端首页崩溃

/code viewport meta 标签缺失，导致移动端 Safari 布局溢出。请修复。

FennoAI 做了什么：

1. 在隔离容器中克隆仓库
2. 定位相关文件（src/pages/home/mobile.tsx、viewport.ts）
3. 编写修复（+42 −3 行）
4. 运行完整测试套件 —— 47 个测试全部通过
5. 提交 PR #143，带有清晰的描述和 diff

你：审查 PR，批准，合并。完成。

场景 2：先规划再编码

现状：一个功能需求来了。在写代码之前，团队想先做设计评审 —— 改哪些文件、迁移路径是什么、有什么风险？

用 FennoAI：在 Issue 里获得实施方案。

Issue #200: 添加 OAuth2 支持（Google 和 GitHub 登录）

@fennoai 帮我设计实现方案，考虑现有的 JWT 认证和 User 模型。

你会得到：

• 架构概述（新路由、中间件、数据库 Schema 变更）
• 分步实施计划，精确到文件路径
• 现有用户迁移策略
• 风险评估（破坏性变更、安全注意事项）
• 影响范围和复杂度估算

然后：团队达成共识后，用 /code 开始实现。

场景 3：AI 驱动的代码审查

现状：一个 PR 等了两天没人看。终于有人审查时，发现了 SQL 注入漏洞。

用 FennoAI：每个 PR 都能获得即时、全面的审查。

PR #456: 添加用户搜索接口

/review 重点关注安全和性能。

审查输出：

## 安全 ⚠️
 
- 第 34 行：用户输入直接传入 SQL 查询 —— SQL 注入风险
- 第 67 行：API Key 在 debug 日志中输出 —— 密钥泄露
 
## 性能
 
- 第 45 行：N+1 查询模式 —— 建议使用 JOIN 或批量加载
- 第 89 行：搜索查询缺少 `users.email` 索引
 
## 代码质量 ✅
 
- 关注点分离清晰
- 错误处理模式良好
- 建议将搜索逻辑抽取到独立的 service 层

场景 4：放心重构

现状：一个 Service 类已经膨胀到 800 行。大家都同意需要拆分，但没人想做这个繁琐的工作。

PR #101: UserService 太大了

/simplify 将 UserService 拆分为 AuthService、ProfileService
和 NotificationService。确保所有现有测试通过。

FennoAI：

1. 分析类的依赖关系
2. 抽取三个职责明确的 Service
3. 更新代码库中所有的引用路径
4. 运行现有测试套件确认无破坏
5. 提交变更，每个 commit 信息清晰

场景 5：新人快速上手

现状：新人加入团队，想参与贡献但对代码库不够熟悉。

用 FennoAI：描述他们想做的事情，FennoAI 基于完整的代码库上下文来实现。

Issue #300: 为 API 添加速率限制

@fennoai 我想给所有公开 API 接口添加速率限制，
对我们的技术栈来说最佳方案是什么？

新人获得一份可以学习参考的详细方案 —— 如果他们愿意，也可以让 FennoAI 直接实现。

什么时候用什么命令