130 lines
3.3 KiB
Markdown
130 lines
3.3 KiB
Markdown
# OpenCode 全局规则
|
||
|
||
## 缩写
|
||
- **oc** = opencode
|
||
|
||
---
|
||
|
||
## 1. 语言与交互
|
||
|
||
### 用户交互
|
||
- **必须使用中文**与用户交流
|
||
- 技术术语可中英文混用（如 "React Hooks"）
|
||
- 对话、提问、确认、建议、错误解释都用中文
|
||
|
||
### 代码与文档
|
||
- **代码注释**：默认中文，遵循项目规范
|
||
- **项目文档**（README、API 文档等）：默认英文
|
||
- **配置文档**（AGENTS.md、自定义规则等）：可使用中文
|
||
- **工具输出**：可保持原语言，但解释用中文
|
||
|
||
|
||
## 2. 回复规范（Token 优化核心）
|
||
|
||
### 🚫 严格禁止（减少 Output Token）
|
||
|
||
#### 禁止展示内容
|
||
- ❌ 超过 100 行的文件内容
|
||
- ❌ 代码块展示（用文件路径代替，如 `src/utils.ts:42`）
|
||
- ❌ 工具输出重复总结（bash/read 结果已可见）
|
||
- ❌ 装饰性 emoji、表格、边框符号
|
||
|
||
#### 禁止冗余表达
|
||
- ❌ "让我先..."、"现在我将..."、"接下来..."（直接执行）
|
||
- ❌ 预告即将使用的工具（直接调用）
|
||
- ❌ 详细报告式总结
|
||
- ❌ 重复描述已完成的操作
|
||
|
||
#### 禁止思考过程展示
|
||
- ❌ "我认为应该..."、"让我分析一下..."
|
||
- ❌ 多轮内部推理过程
|
||
- ✅ 直接给出结论和操作
|
||
|
||
### ✅ 推荐做法
|
||
|
||
#### 文件操作
|
||
- 只说：操作类型 + 文件路径 + 目的
|
||
- 例：`已修改 src/config.ts，添加数据库配置`
|
||
|
||
#### 任务完成
|
||
- 简短总结（≤ 3 条要点）
|
||
- 例：`已完成：1) 创建组件 2) 添加测试 3) 更新文档`
|
||
|
||
#### 命令输出
|
||
- 直接展示，无需解释（除非出错）
|
||
|
||
### 示例对比
|
||
|
||
#### ❌ 低效回复（浪费 ~200 tokens）
|
||
```
|
||
让我先分析一下这个问题...
|
||
现在我将创建 LICENSE 文件，使用 MIT License：
|
||
|
||
[展示完整 MIT License 文本]
|
||
|
||
✓ 文件创建成功
|
||
✓ 内容已写入
|
||
✓ 权限已设置
|
||
|
||
总结：我已经帮你创建了 LICENSE 文件...
|
||
```
|
||
|
||
#### ✅ 高效回复（仅 ~15 tokens）
|
||
```
|
||
已创建 LICENSE 文件，使用 MIT License。
|
||
```
|
||
|
||
|
||
## 3. Git 操作限制
|
||
|
||
### 🔴 严格禁止自动执行
|
||
|
||
**未经用户明确命令，禁止自动执行以下操作：**
|
||
- ❌ `git add`（暂存文件）
|
||
- ❌ `git commit`（创建提交）
|
||
- ❌ `git tag`（创建标签）
|
||
- ❌ `git push`（推送到远程）
|
||
|
||
### 允许的场景
|
||
✅ 用户明确使用命令：`/git-add`、`/git-commit`、`/git-push`
|
||
✅ 用户直接要求："帮我提交代码"、"推送到远程"
|
||
❌ 用户仅说："创建文件"、"修改配置"（不包含 Git 操作指令）
|
||
|
||
### 原则
|
||
- **创建/修改文件 ≠ 自动提交**
|
||
- **完成任务 ≠ 自动推送**
|
||
- 需要 Git 操作时，**询问用户**或**提示用户使用命令**
|
||
|
||
|
||
## 4. 批量修改策略
|
||
|
||
**原则：先修改一个，验证通过后再批量修改**
|
||
|
||
### 步骤
|
||
1. 选择样本（最具代表性）
|
||
2. 修改样本
|
||
3. 验证功能
|
||
4. 批量应用
|
||
|
||
### 例外
|
||
- 简单修改（如批量重命名）
|
||
- 已有测试覆盖
|
||
- 用户明确要求
|
||
|
||
|
||
## 5. 代码质量
|
||
|
||
### 原则
|
||
- 确保代码能够正常运行（除非程序需要用户提供运行时参数或手动执行）
|
||
- 类型检查零错误
|
||
- 尽力修复 Linter 警告（允许存在合理的 warning）
|
||
- 不允许存在 error
|
||
|
||
### 安全
|
||
- 不提交敏感信息（.env、密钥）
|
||
|
||
|
||
## 6. skill 和 command
|
||
|
||
- 默认在oc 的全局配置目录下创建 skill 和 command
|