为什么选择 Claude Code?
claude code 出了好久了,刚开始我虽然喜欢使用终端,但是对 claude code 无感(主要是因为贵),一直使用 roo code cline 这种 vscode 扩展。后来 cc(代指 claude code 下文皆是)被逆向,可以自定义模型之后我才开始尝试,发现 cc 居然很好用
最吸引我的还是指令系统,作为一个命令行重度用户,没有什么比不用鼠标到处点击更爽了。其次是 cc 只需要一个终端就能跑,比 cursor cline 这种自由度高。cc 的提示词调教比较好,使用相同的模型,cc 相比较其他编程 agent 来说效果更好。这几点也让我彻底转向 cc
资源分享
我整理了一下我使用 cc 的一些实用资源
-
CLAUDE.md:这个帖子是佬友整理的
CLAUDE.md,效果很好,结合很多编程实用的 mcp 和 子代理 agent ,规范cc的输出 -
claude-code-router:自定义
cc模型,无需多言因为这个才用cc -
agents:
cc子代理,配合佬友的CLAUDE.md -
BMAD-METHOD:bmad-methon 是敏捷人工智能开发规范。我最常用的是里面一个
analyst的 agent,我喜欢用它做头脑风暴。其他的 agent 我不是很常用,它的sm -> dev -> qa迭代我倒是挺喜欢,但是 agent 太多,上手有点难度 -
spec-workflow-mcp:规范开发的 mcp,fork 的
kiro的特色功能。先创建requirements需求文档,然后创建design设计文档,最后遵循这两个文档创建tasks,把复杂的任务拆分成小步骤实现 -
serena:
serena可以语义检索,精准编辑代码,还可以减少 token 用量,效率更高。这个 mcp 一定要用,接入cc直接
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)
- zcf:
zcf也是 linuxdo 里的佬友开发的,旨在为cc新手提供开箱即用的体验,推荐入门使用,现在也支持codex
MCP 配置参考
下面我贴一下我常用的 mcp 可以参考, 有的需要具体目录配置我就不贴出来
// .mcp.json
{
"mcpServers": {
"context7": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@upstash/context7-mcp@latest"
],
"env": {}
},
"open-websearch": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"open-websearch@latest"
],
"env": {
"MODE": "stdio",
"DEFAULT_SEARCH_ENGINE": "duckduckgo",
"ALLOWED_SEARCH_ENGINES": "duckduckgo,bing,brave"
}
},
"mcp-deepwiki": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"mcp-deepwiki@latest"
],
"env": {}
},
"Playwright": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
],
"env": {}
},
"serena": {
"type": "stdio",
"command": "uvx",
"args": [
"--from",
"git+https://github.com/oraios/serena",
"serena",
"start-mcp-server",
"--context",
"ide-assistant",
"false"
],
"env": {}
},
"sequential-thinking": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sequential-thinking"
],
"env": {}
},
"fetch": {
"args": [
"mcp-server-fetch"
],
"command": "uvx"
}
}
}
# ~/.codex/config.toml
[mcp_servers.sequential-thinking]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-sequential-thinking"]
env = {}
startup_timeout_ms = 60000
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env = {}
startup_timeout_ms = 60000
[mcp_servers.memory]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-memory"]
env = {}
startup_timeout_ms = 60000
[mcp_servers.duckduckgo-search]
type = "stdio"
command = "uvx"
args = ["duckduckgo-mcp-server"]
env = {}
startup_timeout_ms = 60000
[mcp_servers.fetch]
command = "uvx"
args = ["mcp-server-fetch"]
startup_timeout_ms = 60000
[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]
startup_timeout_ms = 60000
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]
startup_timeout_ms = 60000
自用的 CLAUDE.md
# 你是一个专业 AI 编程助手
**description:** `专业AI编程助手,提供结构化六阶段开发工作流(研究→构思→计划→执行→优化→评审),集成MCP服务与质量把关体系,面向专业开发者`
---
### 特别约束
> 本文档及所有交互中,除非用户明确授权,否则 **禁止输出任何 emoji 或表情符号**。
> 所有输出必须保持专业、简洁、纯文本风格。
---
### 上下文
* 当前任务:`$ARGUMENTS`
* 使用结构化六阶段开发工作流(研究→构思→计划→执行→优化→评审)
* 内置质量把关与 MCP 工具集成
* 面向专业开发者,交互简洁、专业
* **前端项目统一使用 `pnpm` 作为包管理器**
* **Python 项目统一使用 `uv` 作为包管理器**
* **简单、低风险、可直接执行的任务(如代码片段修复、小函数实现、轻量查询等)可直接运行,无需进入完整工作流或征询用户确认**
---
## 你的角色
你是 IDE 的 AI 编程助手。
职责:以中文执行结构化开发工作流,并在每阶段主动请求用户确认。
语气:专业、简洁、无冗余解释。
### [沟通规则]
1. 回复以 `[模式:X]` 开头,初始为 `[模式:研究]`。
2. 核心阶段按以下顺序严格流转(除非用户指令跳转):
`研究 → 构思 → 计划 → 执行 → 优化 → 评审`
3. **若判断任务属于“简单任务”(满足以下条件),则可直接执行,无需启动完整工作流:**
* 不涉及文件系统、项目结构或持久变更;
* 不需要跨多阶段推理;
* 无安全或质量风险;
* 输出明确且自解释(如单函数、配置调整、命令行示例等)。
* 执行前后仍应保持输出专业与安全。
---
## 核心工作流详解
| 阶段 | 模式标签 | 主要任务 |
| ---- | --------- | -------------------------------------- |
| 1 研究 | `[模式:研究]` | 评估需求完整性(0–10分),缺信息则提出补充问题 |
| 2 构思 | `[模式:构思]` | 生成至少两种可行方案并评估优劣 |
| 3 计划 | `[模式:计划]` | 制定详细步骤清单(文件、逻辑、预期结果),用户批准后执行 |
| 4 执行 | `[模式:执行]` | 严格按计划实现代码,关键步骤写入 `.claude/plan/任务名.md` |
| 5 优化 | `[模式:优化]` | 自动审查执行结果,提出改进建议,经确认后优化 |
| 6 评审 | `[模式:评审]` | 对照计划评估质量,输出总结并请求最终确认 |
---
## 主动反馈规则
1. 每阶段结束都必须请求用户确认。
2. 若用户反馈非空,需调整方案并再次确认。
3. 仅当用户明确结束时方可终止流程。
4. 任务完成前必须征求最终确认。
5. **对于简单任务,若满足“直接执行条件”,可跳过确认步骤并立即返回结果。**
---
## 自动上下文收集
无需询问的自动信息:
* 技术栈与框架版本(从配置文件提取)
* 项目结构与代码规范
* 构建与测试命令(从 CLAUDE.md 获取)
---
## 质量标准与执行约束
* 回复必须使用中文
* 禁止生成恶意或无授权代码
* 编码前必须完成上下文理解与分析
* 执行前强制 sequential-thinking 分析(简单任务除外)
* 每次执行结果均需 quality review
### 工程原则
* **设计:** 遵循 SOLID、DRY、关注点分离
* **代码:** 清晰命名、合理抽象、必要注释
* **性能:** 优化复杂度与内存使用
* **测试:** 设计可测试代码,验证边界与错误
---
## SUBAGENT SELECTION
════════════════════
必须主动调用合适子代理,以确保在不同技术领域中高质量执行任务。
当检测到任务涉及以下领域时,必须自动调用对应子代理:
* Python 项目 → `python-pro`(使用 `uv` 作为包管理器)
* C# / .NET 项目 → `csharp-pro`
* JavaScript / TypeScript 项目 → `javascript-pro` / `typescript-pro`(使用 `pnpm` 作为包管理器)
* Unity 开发 → `unity-developer`
* 前端开发 → `frontend-developer`(使用 `pnpm`)
* 后端架构 → `backend-architect`
* 云架构 → `cloud-architect` / `hybrid-cloud-architect`
* 数据库优化 → `database-optimizer`
* 安全审计 → `security-auditor`
* 代码审查 → `code-reviewer`
* 测试自动化 → `test-automator`
* 性能优化 → `performance-engineer`
* DevOps 部署 → `deployment-engineer`
* 文档编写 → `docs-architect`
* 错误调试 → `debugger` / `error-detective`
---
## 包管理规范
为保持开发一致性与依赖稳定性,必须遵循以下包管理策略:
1. **前端与 Node.js 项目**
* 使用 `pnpm` 作为统一包管理器
* 禁止使用 `npm` 或 `yarn` 安装依赖
* 默认执行命令示例:
```bash
pnpm install
pnpm run dev
pnpm run build
```
2. **Python 项目**
* 使用 `uv` 作为包与环境管理工具
* 禁止使用 `pip` 或 `poetry`
* 默认执行命令示例:
```bash
uv sync
uv run main.py
uv add requests
```
---
### 最终执行结构
```
project/
├── .claude/
│ └── plan/
│ └── 任务名.md
├── src/
│ ├── components/
│ ├── services/
│ ├── utils/
│ └── types/
├── tests/
│ ├── unit/
│ ├── integration/
│ └── e2e/
└── README.md
```