简介与能力边界

本文概览 Claude 的编码能力与边界，明确适用场景与预期，为后续系统化使用奠定基础。

核心定位

• 面向“可审阅的代码改动”，而不是纯聊天输出
• 以项目仓库为上下文，支持查阅、生成、修改与验证的闭环
• 强调小步提交、可回滚与可验证（tests/lint/build）

能力边界

• 代码生成与修改依赖上下文质量与仓库结构清晰度
• 不替代工程实践：测试用例、代码审查、风格约束仍需落实
• 对于长上下文与跨仓库改动，需显式给出“边界与验收”
• 安全与隐私需在项目层面设定底线（密钥、账号、生产数据）

适用场景（高收益）

• 修复缺陷：复现→定位→最小修复→回归验证
• 小功能开发：改动范围明确、验收命令可执行
• 重构与清理：拆分长函数、消除重复、补充测试
• 代码理解：梳理入口、调用链与关键约定
• PR 预审：风险点识别、缺失测试、最小修复建议

不适用场景（需谨慎）

• 需求与边界完全不清，只靠模型“猜”
• 涉及高风险权限或生产数据，但缺少门禁与审查
• 依赖图复杂且无测试与构建基线

推荐工作流

• 目标/约束/验收三件套先写清
• 先“调查”再“修改”：入口、证据、最小修复方案
• 小步提交：每次只解决一个主题，保证可审阅与可回滚
• 在关键节点使用 diff 审阅，并运行测试/构建命令

高频命令

/help                查看可用命令
/login               登录或切换账号
/resume              恢复最近会话
/diff                查看当前改动的可审阅 diff
/run <command>       运行项目命令（tests/lint/build 等）

安全与隐私基线

• 禁止提交密钥/私钥/生产账号等敏感信息
• 明确允许修改的目录与禁止修改的目录（例如：只改 src/ 与 tests/）
• 明确验收命令并可实际运行（如 npm test / mvn test / pytest）

常见坑与规避

• 上下文不清：进入会话前先给“入口与约束”
• 一次改太多：拆分为多轮，每轮都要 diff 审阅
• 不跑验证：把 tests/lint/build 写进验收并执行
• 缺少回滚计划：每步改动都可还原，避免扩散

下一步

• 前往第二章，完成安装与账号配置，并在项目根目录稳定运行
  入口：/ai/ClaudeCode/02-installation-setup.html