很多人第一次把 Claude Code 接进真实项目，会直接丢一句“帮我看一下这个项目”。它通常能读懂一部分代码，但后面很容易出现三个问题：读错入口、改到不该改的文件、改完不知道怎么验收。真正稳定的 AI 编程，不是让模型自由探索，而是先把项目初始化做好。
这篇文章讲一套适合个人开发者和小团队的 Claude Code 项目初始化流程：从 CLAUDE.md、仓库结构说明、权限边界，到任务拆分和验收命令。你也可以把它和 Claude专题、AI编程工具专题 放在一起看，形成自己的 AI 编程工作流。
先说结论：初始化的目标是减少误读
Claude Code 项目初始化不是写一份漂亮说明文档，而是让 AI 在开始动手前知道四件事：
- 这个项目是做什么的，核心目录在哪里；
- 哪些文件可以改，哪些文件只读，哪些文件不要碰；
- 常用的安装、开发、测试、构建命令是什么；
- 完成任务后，要用什么标准判断“真的可交付”。
如果这些信息都靠对话临时补充，长会话一压缩，后面就容易丢上下文。站内写过 Claude Code compact 长会话整理方法，但更好的做法，是把稳定规则前置到项目初始化阶段。
第一步：写一份短而硬的CLAUDE.md
CLAUDE.md 不需要写成产品手册，它应该像项目的“操作规程”。建议至少包含这几块：
- 项目定位：一句话说明项目用途、主要用户和当前维护目标。
- 目录地图：列出核心目录，比如前端、后端、脚本、配置、测试、文档。
- 运行命令：安装依赖、启动开发环境、运行测试、构建、格式化。
- 编辑边界：说明密钥、生产配置、生成物、历史数据等不要随意修改。
- 验收标准：完成任务后必须跑哪些检查，哪些结果算失败。
关键是要短。太长的规则文件会让 AI 抓不到重点，也会增加后续维护成本。对一个普通 Web 项目来说，几百字到一千字通常够用。
第二步：把仓库入口讲清楚
AI 最怕的是项目入口不清。比如同一个仓库里有旧版页面、实验目录、构建产物和真正线上代码，如果不说明，Claude Code 可能会认真阅读错误目录。
建议在初始化时明确三类入口：
- 业务入口：用户实际访问的页面、接口或命令入口。
- 开发入口：本地调试从哪里启动，端口、脚本和环境变量在哪里配置。
- 测试入口：单元测试、端到端测试、类型检查或页面截图检查怎么运行。
这一步和 AI编程上下文管理 很相关。上下文管理不是多塞文件，而是把正确文件放到前面，让 AI 少猜。
第三步：权限边界要提前写，不要出事后补
Claude Code 能读写文件，也可能执行命令。项目初始化时，要把权限边界说清楚，尤其是这些内容：
- 不要修改真实密钥、生产数据库连接、服务器凭据；
- 不要随意重写锁文件、迁移脚本和历史数据；
- 需要安装依赖、删除文件、批量格式化时先说明理由；
- 涉及线上发布、付费接口、群发通知等动作必须人工确认。
很多 AI 编程翻车不是模型不会写代码，而是它不知道哪些动作风险高。把边界写在初始化文件里，比每次口头提醒更稳定。
第四步：任务要拆成可验收的小块
初始化完成后，不建议直接给 Claude Code 一个大而泛的任务，比如“优化整个项目”。更稳的方式是按交付结果拆分：
- 先让它阅读相关文件并复述理解；
- 再让它给出修改计划，列出会动哪些文件；
- 确认后只改一个功能点或一个问题；
- 最后运行检查，并说明哪些检查通过、哪些没跑。
如果任务涉及测试，可以参考 Claude Code 测试验收流程。AI 改完代码不是结束，能不能用清晰命令验证，才是交付质量的分水岭。
第五步：把常用命令变成固定检查清单
一个好用的初始化清单，最后一定要落到命令上。比如：
npm run lint：检查格式和基础代码规范；npm test：跑关键测试；npm run build：确认构建不失败；- 页面类项目再加截图或浏览器检查；
- 文档类项目再加链接、标题层级和图片 alt 检查。
不要假设 Claude Code 知道你项目的真实命令。很多仓库里同时存在 npm、pnpm、bun、Makefile 和脚本目录，如果不指定，它可能会选错。
老达点评：AI编程拼的是交付纪律
Claude Code 的能力很强，但越强的工具越需要边界。项目初始化做得好，AI 就像一个刚加入项目但很守规矩的协作者；初始化做得差，它就只能边猜边改。
我的建议是：每个长期维护的项目都准备一份简短的 CLAUDE.md，每次大任务开始前先让 AI 读取规则、确认范围、列出验收命令。这样做不会让速度变慢，反而能减少返工、误改和“看起来完成了但其实没交付”的问题。
