Views: 25
CC Switch 简介地址：https://github.com/farion1231/cc-switch
CC Switch 程序下载【 海外地区】：https://github.com/farion1231/cc-switch/blob/main/docs/release-notes/v3.15.0-zh.mdhttps://github.com/farion1231/cc-switch/releases/tag/v3.15.0
CC Switch 程序下载【 中国大陆地区】：
「CC-Switch-v3.15.0」，
夸克网盘：https://pan.quark.cn/s/c466af7b2bb0
百度网盘：
链接: https://pan.baidu.com/s/1KCksp5df4rhAU1OHjxTTQw?pwd=8888 提取码: 8888
Claude Code 全部启动模式（权限模式）清单
在终端启动 Claude Code 时，可以通过 --permission-mode 参数指定以下任意一种模式。
【1】default（默认模式） 命令：claude
行为：所有敏感操作（文件编辑、执行命令、网络请求）都需要用户手动确认。 场景：日常开发，追求安全可控。
【2】acceptEdits（接受编辑模式） 命令：claude --permission-mode acceptEdits
行为：自动批准所有文件编辑操作，但执行 Shell 命令和网络请求仍需确认。 场景：信任 AI 的代码修改，但仍想对高危操作保持控制。
【3】plan（计划模式） 命令：claude --permission-mode plan
行为：只读模式。可以分析和规划，但不能修改文件或运行命令。 场景：代码审查、架构分析、制定复杂重构计划。
【4】auto（自动模式） 命令：claude --permission-mode auto
行为：由一个独立的 AI 分类模型在后台评估每次操作的风险，自动批准“安全”操作，危险操作仍需确认。 注意：该模式对模型有要求，且 AI 自主决策存在不确定性，日常开发慎用。
【5】dontAsk（不询问模式） 命令：claude --permission-mode dontAsk
行为：自动拒绝所有未被预先批准的工具，并且不询问用户。 场景：极度受限的锁定环境，日常开发基本不用。
【6】bypassPermissions（绕过权限模式）【极度危险】 无需任何确认，ai自己操作自己
自己确认自己写。这个就极度文件操作，啥的他都不用给你确认，直接就来了，写完了会通知你
我自用写 Claude Code 代码的一个约束 : CLAUDE.md 放到你自己的全局 Claude Code 配置MD文件 保存下即可
# 全局开发指令（所有 Claude Code 项目生效）
## 0. 基本要求
- 使用简体中文回答、说明进度并询问意见。
- 本文件规则优先级最高，覆盖默认行为。
- 不确定就问，不要猜测；存在多种解释时先说明并请求确认。
- 禁止擅自删除进度文件、推翻已有决策、跳过需求记录直接改代码。
## 1. 进度文件管理
### 1.1 文件规则
- 每个项目必须维护进度文件：`<项目名>项目执行进度记录.md`。
- 若不知道项目名，先询问用户。
- 若当前目录不存在进度文件，按本文“进度文件模板”创建。
- 若已存在，先读取其中“未完成 / 待测试 / 待手动测试”的任务，再继续工作。
- 禁止私自删除进度文件；如确需删除，必须获得用户明确许可。
### 1.2 需求记录
- 用户每次提出的新需求、变更、确认、重要决策，都必须记录到“需求与决策记录”。
- 后续会话优先读取进度文件继续工作，不要求用户重复描述。
### 1.3 状态更新
- 每完成一个子任务，立即更新进度文件中的状态、实施进度和验证结果。
- 会话结束或退出前，必须写入最新状态，尤其是未完成事项。
- 更新进度文件后应立即写入磁盘。
## 2. 代码修改原则
核心原则：编码前思考、简洁优先、精准修改、目标驱动执行。
### 2.1 编码前思考
- 不明确的需求先问，不要自行假设。
- 有多种实现路径时，说明取舍。
- 发现更简单或更安全的方法，应主动指出。
- 需求、影响范围、风险、验证方式未明确前，不要直接改代码。
### 2.2 简洁优先
- 用最少代码解决当前问题。
- 不添加用户未要求的功能、抽象、配置项或“未来扩展”。
- 不为一次性逻辑设计复杂架构。
- 复杂实现必须有明确收益，否则简化。
- 判断标准：资深工程师若会认为过度复杂，就必须简化。
### 2.3 精准修改
- 只修改完成任务所必需的代码。
- 不顺手重构、格式化、改注释或清理无关代码。
- 保持现有项目风格，即使你更偏好其他写法。
- 发现无关死代码只提示，不删除。
- 仅删除因本次修改产生的无用导入、变量、函数或孤儿代码。
- 每一行改动都应能对应用户需求。
### 2.4 目标驱动执行
- 每个任务必须定义可验证的成功标准。
- 修 bug：优先重现问题，再修复，再验证。
- 加功能：明确输入、输出、边界条件和验证方式。
- 重构：确保重构前后行为一致，测试通过。
- 多步骤任务必须先给计划：
```text
文章评论