OpenCode 中文教程
首页
教程
生态
FAQ
对比
文章
  • 官方网站
  • 官方下载
  • 官方文档
  • 关于我们
  • 联系我们
  • 隐私政策
  • 服务协议
  • 免责声明
  • 商标声明
  • 简体中文
  • English
  • Deutsch
首页
教程
生态
FAQ
对比
文章
  • 官方网站
  • 官方下载
  • 官方文档
  • 关于我们
  • 联系我们
  • 隐私政策
  • 服务协议
  • 免责声明
  • 商标声明
  • 简体中文
  • English
  • Deutsch
  • 生态与集成

    • Opencode 生态集成 - Docker, MCP, Antigravity
  • 最佳实践

    • Opencode 最佳实践中心 - 10x 效率提升指南
  • 故障排除

    • Opencode 故障排除中心 - 快速解决使用中的问题

工作流最佳实践

掌握正确的工作流程,能让你的开发效率提升 10 倍。本文将分享社区验证过的 Opencode 最佳实践。

核心理念:从对话到调度

传统 AI 编程工具的思维模式:

我问 → AI 回答 → 我再问 → AI 再答

Opencode 的思维模式:

我下指令 → AI 拆任务 → 多个 Agent 协作 → 自动完成

当你掌握了"调度"而非"对话",你就从 AI 的使用者变成了 AI 团队的管理者。

基础工作流:五步法

适合所有开发任务的通用流程:

1. 方案设计

让 AI 先思考,而不是直接动手:

@architect 设计一个用户认证系统,要求:
1. 支持邮箱和手机号登录
2. 支持 OAuth(Google、GitHub)
3. 包含 JWT 令牌管理
4. 考虑安全性和可扩展性

请给出:
- 系统架构图
- 数据库表结构
- API 接口设计
- 安全措施
- 潜在风险

为什么这样做?

  • 避免返工:先确认方案再实施
  • 发现问题:在设计阶段就能发现潜在问题
  • 便于讨论:你可以和 AI 讨论方案的优劣

2. 收集证据

让 AI 搜索现有代码和最佳实践:

@explorer 搜索项目中:
1. 现有的认证相关代码
2. 数据库连接配置
3. 中间件的使用方式

@librarian 查找:
1. JWT 的最佳实践
2. OAuth 2.0 的实现示例
3. 常见的安全漏洞

为什么这样做?

  • 保持一致:遵循项目现有的代码风格
  • 避免重复:复用已有的代码
  • 学习最佳实践:站在巨人的肩膀上

3. 明确边界

定义清晰的任务边界:

@plan 制定实施计划,注意:
1. 不要修改现有的用户表结构
2. 保持与现有 API 的兼容性
3. 添加完整的错误处理
4. 每个步骤都要可以独立测试

请给出详细的 Todo 列表

为什么这样做?

  • 控制范围:避免 AI 修改不该修改的代码
  • 降低风险:每步都可验证,出错容易回滚
  • 便于追踪:清晰的 Todo 列表

4. 逐步实现

按计划逐步推进:

@build 按照计划实现第一步:创建数据库表

完成后,让 @reviewer 审查代码

然后继续下一步

为什么这样做?

  • 及时发现问题:每步完成后立即验证
  • 保持专注:一次只做一件事
  • 便于调试:问题范围小,容易定位

5. 代码审查

让 AI 审查自己的代码:

@reviewer 审查刚才实现的代码,重点检查:
1. 安全性:SQL 注入、XSS、CSRF
2. 性能:数据库查询优化、缓存策略
3. 错误处理:边界条件、异常情况
4. 代码质量:可读性、可维护性

给出详细的审查报告和改进建议

为什么这样做?

  • 发现隐藏问题:AI 能发现人类容易忽略的问题
  • 学习机会:理解什么是好代码
  • 持续改进:不断优化代码质量

进阶工作流:场景化实践

场景一:新功能开发

完整的功能开发流程:

# 第一阶段:需求分析
我要开发一个博客评论功能,支持:
- 用户评论和回复
- 点赞和举报
- Markdown 格式
- 实时通知

@architect 分析需求并设计方案

# 第二阶段:技术调研
@explorer 搜索项目中:
- 现有的评论相关代码
- 通知系统的实现
- Markdown 渲染器的使用

@librarian 查找:
- 评论系统的最佳实践
- 防止垃圾评论的方法
- 实时通知的实现方案

# 第三阶段:方案确认
基于调研结果,@architect 更新设计方案

我会和你讨论方案的细节,确认后再实施

# 第四阶段:任务拆解
@plan 制定详细的实施计划,包括:
1. 数据库表设计
2. API 接口实现
3. 前端组件开发
4. 实时通知集成
5. 测试用例编写

# 第五阶段:逐步实现
@build 按计划实现,每完成一步:
1. 运行测试
2. 让 @reviewer 审查
3. 确认无误后继续下一步

# 第六阶段:集成测试
@tester 编写集成测试,覆盖:
- 正常流程
- 边界条件
- 异常情况

# 第七阶段:文档编写
@documenter 编写:
- API 文档
- 使用说明
- 部署指南

场景二:Bug 修复

高效的 Bug 修复流程:

# 问题描述
用户登录时偶尔会失败,错误信息:
"Token validation failed"

复现步骤:
1. 用户登录
2. 等待 5 分钟
3. 刷新页面
4. 出现错误

# 第一步:问题定位
@explorer 搜索所有与 Token 验证相关的代码

@architect 分析可能的原因:
- Token 过期时间设置
- 时区问题
- 缓存问题
- 并发问题

# 第二步:复现问题
@build 编写测试用例复现问题

# 第三步:根因分析
基于测试结果,@architect 确定根本原因

# 第四步:修复实施
@build 实施修复方案

# 第五步:回归测试
@tester 运行所有相关测试,确保:
- Bug 已修复
- 没有引入新问题
- 边界条件都正常

# 第六步:代码审查
@reviewer 审查修复代码,确认:
- 修复方案合理
- 没有遗漏的场景
- 代码质量符合标准

场景三:代码重构

安全的重构流程:

# 重构目标
auth 模块代码混乱,需要重构

要求:
1. 拆分成更小的模块
2. 提高可测试性
3. 保持 API 兼容性

# 第一步:现状分析
@explorer 分析 auth 模块:
- 代码结构
- 依赖关系
- 调用方式

@architect 评估:
- 存在的问题
- 重构风险
- 重构方案

# 第二步:制定计划
@plan 制定重构计划:
1. 添加测试覆盖(确保重构前有测试)
2. 提取公共逻辑
3. 拆分大函数
4. 优化数据结构
5. 更新文档

每一步都要:
- 保持测试通过
- 保持功能不变
- 可以独立提交

# 第三步:逐步重构
@build 按计划重构,每完成一步:
1. 运行所有测试
2. 手动验证核心功能
3. 提交代码

# 第四步:性能测试
@tester 对比重构前后的性能

# 第五步:代码审查
@reviewer 审查重构后的代码:
- 代码质量是否提升
- 是否引入新问题
- 是否达到重构目标

场景四:技术选型

理性的技术决策流程:

# 需求
项目需要选择一个状态管理库

候选方案:
- Redux
- MobX
- Zustand
- Jotai

# 第一步:需求分析
@architect 分析项目需求:
- 状态复杂度
- 团队技术栈
- 性能要求
- 学习成本

# 第二步:方案调研
@librarian 调研每个方案:
- 核心特性
- 优缺点
- 适用场景
- 社区活跃度
- 学习资源

# 第三步:对比分析
@architect 对比分析,给出推荐

# 第四步:原型验证
@build 用推荐的方案实现一个小原型

# 第五步:团队讨论
基于原型和分析报告,团队讨论决策

高级技巧

1. 使用 AGENTS.md

在项目根目录创建 AGENTS.md,让 AI 记住项目规范:

# 项目规范

## 技术栈
- 前端:React 18 + TypeScript + Vite
- 后端:Node.js + Express + PostgreSQL
- 部署:Docker + AWS

## 编码规范
- 使用 ESLint + Prettier
- 组件使用函数式 + Hooks
- 状态管理使用 Zustand
- API 调用使用 React Query

## 目录结构
- `/src/components` - 可复用组件
- `/src/features` - 功能模块
- `/src/hooks` - 自定义 Hooks
- `/src/utils` - 工具函数

## 命名规范
- 组件:PascalCase
- 函数:camelCase
- 常量:UPPER_SNAKE_CASE
- 文件:kebab-case

## 提交规范
- feat: 新功能
- fix: Bug 修复
- refactor: 重构
- docs: 文档更新

2. 使用 Todo 驱动开发

让 AI 创建 Todo 列表,然后逐项完成:

@plan 为这个功能创建详细的 Todo 列表

然后 @build 逐项完成,每完成一项:
1. 标记为完成
2. 运行测试
3. 提交代码
4. 继续下一项

3. 并行开发

让多个 Agent 同时工作:

同时进行:
1. @build 实现后端 API
2. @frontend-dev 实现前端组件
3. @documenter 编写 API 文档

完成后集成测试

4. 增量式提交

每个小改动都提交:

@build 实现功能,每完成一个小步骤就提交:

git commit -m "feat: add user model"
git commit -m "feat: add user controller"
git commit -m "feat: add user routes"
git commit -m "test: add user tests"

好处:

  • 便于回滚
  • 便于 Code Review
  • 清晰的提交历史

常见陷阱

陷阱一:一次性完成大任务

❌ 错误做法:

帮我实现一个完整的电商系统

✅ 正确做法:

第一步:设计电商系统的架构
第二步:实现用户模块
第三步:实现商品模块
...

陷阱二:没有明确边界

❌ 错误做法:

优化这个模块的性能

✅ 正确做法:

优化这个模块的性能,要求:
1. 不要修改 API 接口
2. 保持向后兼容
3. 添加性能测试
4. 目标:响应时间 < 100ms

陷阱三:跳过代码审查

❌ 错误做法:

实现功能 → 直接提交

✅ 正确做法:

实现功能 → 代码审查 → 修复问题 → 提交

陷阱四:忽略测试

❌ 错误做法:

功能实现完就算完成

✅ 正确做法:

功能实现 → 单元测试 → 集成测试 → 手动测试

效率提升技巧

1. 使用快捷键

  • Cmd/Ctrl + K - 快速唤起 AI
  • Cmd/Ctrl + L - 打开聊天面板
  • Cmd/Ctrl + . - 代码解释

2. 使用命令

  • /models - 切换模型
  • /agents - 切换 Agent
  • /compact - 压缩上下文
  • /share - 分享会话

3. 使用模板

创建常用的提示词模板:

# 功能开发模板
@architect 设计 [功能名称]
@explorer 搜索相关代码
@plan 制定实施计划
@build 实现功能
@reviewer 审查代码

# Bug 修复模板
@explorer 定位问题
@architect 分析原因
@build 修复 Bug
@tester 回归测试

# 代码审查模板
@reviewer 审查代码,检查:
1. 安全性
2. 性能
3. 可维护性
4. 测试覆盖

团队协作

1. 统一配置

团队共享 opencode.json:

{
  "model": "anthropic/claude-sonnet-4-5",
  "permission": {
    "edit": "ask",
    "bash": "ask"
  },
  "watcher": {
    "ignore": ["node_modules/**", "dist/**"]
  }
}

2. 统一规范

团队共享 AGENTS.md,确保 AI 遵循团队规范。

3. 代码审查

使用 AI 辅助 Code Review:

@reviewer 审查这个 PR,重点关注:
1. 是否符合团队规范
2. 是否有安全问题
3. 是否有性能问题
4. 测试覆盖是否充分

总结

好的工作流程应该:

  1. 先思考再动手 - 设计方案 → 收集证据 → 实施
  2. 小步快跑 - 拆分任务 → 逐步实现 → 及时验证
  3. 持续审查 - 代码审查 → 测试验证 → 持续改进
  4. 明确边界 - 清晰的任务范围 → 可控的风险
  5. 团队协作 - 统一配置 → 统一规范 → 统一流程

下一步

  • Agent 配置指南
  • 权限与安全配置
  • 常见问题排查

本文由 OpenCodex 社区整理,欢迎分享你的工作流程经验。

最近更新: 2026/2/28 14:48