告别瞎提问 | 建立标准化使用习惯 | 实现高效结对编程
# 进入你的项目目录（这决定了 Claude 的作用域）
cd ~/my-project
# 确认在正确的目录
pwd
ls -la# 启动 Claude，它会自动加载项目上下文
claude
# 首次进入新项目时，让 Claude 全面了解项目
# 输入："请阅读整个项目的文件结构，理解项目架构"
# Claude 会：
# 1. 读取 package.json / requirements.txt 等配置文件
# 2. 浏览 src/ 目录结构
# 3. 理解模块关系
# 4. 识别技术栈和框架# 验证 Claude 的理解
# 输入："用你的理解，描述一下这个项目的架构"
# 如果理解有误，纠正它：
# "/read src/main.js —— 这是入口文件，你漏看了"
# "实际上这个项目用了 Vue 而不是 React"# 任务：<一句话描述>
# 目标文件：src/xxx.js
# 具体要求：
# 1. <具体改动1>
# 2. <具体改动2>
# 约束条件：
# - 不要修改测试文件
# - 保持现有 API 接口不变
# - 遵循项目现有的代码风格
# 期望输出：
# - 修改后的代码
# - 改动说明# === 好的需求描述（推荐） ===
"在 src/api/users.js 中添加一个 getUserById 函数，
接收用户 ID，返回用户对象。使用 async/await，
错误处理参考项目中已有的 getUserByEmail 函数。
不要修改其他文件。"
# === 差的需求描述（避免！） ===
"帮我加个用户查询功能"
# ↑ 太模糊，Claude 会猜测你的意图，结果可能不符预期# === 迭代循环 ===
# 1. 提出需求
# 2. Claude 生成代码
# 3. 你审查代码
# 4. 提出修改意见
# 5. 重复 2-4 直到满意
# 示例对话流程：
# 你："生成 getUserById 函数"
# AI：生成代码...
# 你："第 15 行用类型检查替代 try-catch"
# AI：修改代码...
# 你："再加一个 JSDoc 注释"
# AI：补充注释...
# 你：✅ 满意# 让 Claude 自查代码
"请检查你刚才写的代码，找出可能的问题"
# 让 Claude 运行测试
"运行 npm test，如果失败请自动修复"
# Claude 会：
# 1. 执行测试命令
# 2. 分析失败的测试
# 3. 定位代码问题
# 4. 修复代码
# 5. 重新运行测试验证# 创建 checkpoint
/checkpoint
# 或直接提交到 git
/commit每次你和 Claude 的对话都会累积在上下文窗口中。上下文窗口有大小限制（token 上限）。当上下文接近上限时：
核心原则：保持上下文干净、聚焦、高效。
# === 错误做法：一个会话做所有 ===
# 会话1：创建项目 + 写前端 + 写后端 + 部署 + 文档
# → 上下文很快溢出
# === 正确做法：按模块拆分会话 ===
# 会话1：创建项目结构，配置基础框架
# /exit
# 会话2：开发用户认证模块
# /clear → 开发数据库模型
# 会话3：开发 API 路由
# /clear → 开发前端组件
# 会话4：写测试
# /clear → 写文档# === 清理时机判断 ===
# 当你发现：
# - Claude 开始重复之前说过的内容
# - 回答质量明显下降
# - 执行 /cost 发现 token 使用超过 60%
# → 该清理了
# === 清理方法 ===
# 轻量清理：保留项目理解，清空对话
/clear
# 深度压缩：保留关键信息，释放空间
/compact
# 完全重置：重来
/reset# 创建 .claudeignore（与 .gitignore 格式相同）
cat > .claudeignore << 'EOF'
node_modules/
dist/
build/
.next/
*.min.js
*.min.css
*.map
package-lock.json
yarn.lock
coverage/
.git/
EOF
# Claude 会忽略这些文件，大幅减少上下文消耗# === 不推荐：让 Claude 读所有文件 ===
"分析整个项目"
# → Claude 可能读了 100+ 个不必要的文件
# === 推荐：精确指定范围 ===
"只分析 src/api/ 目录下的文件，关注错误处理逻辑"
"修改 src/components/Button.jsx，不要看其他文件"CLI 中的提示词不是"聊天"，而是工程指令。好的提示词 = 精确的执行规格。
生成 <语言> 代码，实现 <功能>
文件路径：<path>
要求：
1. <具体要求1>
2. <具体要求2>
使用 <框架/库>，遵循 <风格指南>
包含错误处理、类型注解、JSDoc 注释
参考项目中已有的 <类似文件> 的代码风格修改 <文件路径> 的 <函数名/行号范围>
将 <当前行为> 改为 <目标行为>
约束：
- 不改动函数签名
- 保持向后兼容
- 参考 <其他文件> 中的类似实现修复 <文件路径> 中的 bug
错误现象：<描述错误>
错误日志：
<<<
粘贴完整报错堆栈
>>>
复现步骤：
1. <步骤1>
2. <步骤2>
期望行为：<描述正确行为>审查 <文件路径 或 git diff>
重点关注：
1. 安全问题（XSS、注入、权限）
2. 性能问题（N+1 查询、内存泄漏）
3. 代码规范（命名、结构、重复）
输出格式：按严重程度排列，每条附修复建议# === 日常开发高频提示词 ===
# 理解代码
"逐行解释这个函数的作用，特别标注关键逻辑"
# 重构
"重构这个函数，提取可复用的工具函数，不改动外部行为"
# 添加测试
"为这个模块生成 Jest 单元测试，覆盖主要分支和边界情况"
# 性能优化
"分析这个函数的性能瓶颈，给出优化方案，标注复杂度变化"
# 生成文档
"为这个 API 模块生成 OpenAPI 3.0 文档"
# 代码翻译
"把这个 Python 函数翻译成等价的 JavaScript，保持相同的逻辑"# === 完整报错处理示例 ===
# 步骤1：提交报错信息
# 把完整报错日志粘贴给 Claude：
"运行 npm run build 时出现以下错误，帮我分析并修复：
[粘贴完整错误堆栈]"
# Claude 会：
# 1. 读取报错中提到的文件
# 2. 分析根因
# 3. 提出修复方案
# 步骤2：让 Claude 自己执行修复
"请直接修复这个错误"
# 步骤3：让 Claude 验证修复
"修复后重新运行 npm run build，确认错误已解决"
# 步骤4：让 Claude 做回归检查
"确保你的修改没有破坏其他功能，运行完整测试套件"# === 方法1：直接管道传入报错 ===
npm run build 2>&1 | claude -p "分析构建报错，给出修复方案"
# === 方法2：从日志文件分析 ===
cat build.log | claude -p "分析日志中的错误，按严重程度排列"
# === 方法3：实时报错捕捉 ===
your-command 2>&1 | tee error.log
cat error.log | claude -p "分析所有错误并给出修复代码"# === 让 Claude 反复试错直到成功 ===
# 在交互模式中输入：
"运行 npm test，如果有失败的测试，分析原因并修复代码。
修复后重新运行测试。重复这个过程直到所有测试通过。
最多尝试 3 次，如果 3 次后仍有失败，列出剩余问题和建议。"# === 步骤1：让 Claude 建立项目地图 ===
"请浏览项目的关键文件，建立整体理解：
1. 先读 package.json 了解依赖和脚本
2. 读 src/ 目录结构
3. 读主入口文件
4. 读核心模块
然后用你的理解总结项目架构"
# === 步骤2：验证理解 ===
"画出项目的模块依赖关系图（用 ASCII art）"# === 错误做法：同时改20个文件 ===
"把所有文件里的 var 改成 const"
# → 容易遗漏、出错、上下文爆炸
# === 正确做法：按模块分批修改 ===
# 第一轮：
"把 src/models/ 下所有文件的 var 改成 const"
# /clear 后第二轮：
"把 src/routes/ 下所有文件的 var 改成 const"
# 依此类推，每轮处理一个模块# === 1. 创建 git 分支保护 ===
git checkout -b refactor/xxx
# === 2. 启动隔离工作树 ===
claude --worktree
# === 3. 在隔离环境中重构 ===
"重构 src/ 下所有文件的错误处理，统一使用 try-catch 模式"
# === 4. 审查重构结果 ===
"列出你做的所有修改，逐一说明原因"
# === 5. 验证后合并 ===
# 退出 worktree，确认修改，合并到主分支# === 修改一个函数签名后，更新所有调用处 ===
"我把 src/utils/formatDate.js 中的 formatDate 函数签名改了，
现在接受 (date, options) 两个参数。
请找出项目中所有调用 formatDate 的地方，并更新调用方式。"