用 Claude Code 开发项目这件事，听起来很美好：你动动嘴，AI 把代码写了。但实际用下来你会发现，如果没有一套自己的流程，很容易陷入"AI 写了一大堆，但没一个能用的"尴尬局面。
这半年我用 Claude Code 做了几个项目，从最开始瞎折腾到慢慢摸出一套相对靠谱的工作流，踩过的坑不少。分享一下我现在是怎么做的。
第一阶段：规划
最蠢的死法是什么？项目做了一半发现做的东西根本不是自己想要的。
所以我现在不管做什么项目，第一步都是先想清楚两件事：
这玩意儿到底要解决什么问题？ 如果只是想验证一个想法，那就只做验证需要的部分，别想着什么异常处理、代码规范——MVP 的意义就是用最少的成本验证想法能不能跑通。
核心功能有哪些？ 把功能拆成几个阶段，第一版只做最核心的。比如做博客系统，第一版就是能写能发，别的都是锦上添花。
想清楚了之后，我会让 Claude 对着我的想法反复提问，把那些我没考虑到的地方挖出来。有时候你觉得想得很清楚了，被问几个问题才发现全是漏洞。
最后产出三个文档：
- 产品需求——目标用户是谁、解决什么痛点、具体要做什么。注意"具体"这两个字很重要。还是说博客系统，你不能只说"博主可以写文章"，要说明：写文章有没有模板？能不能插图片？发布后能不能改？流程说得越细，Claude Code 自由发挥的空间就越小。
- 技术选型——用什么语言、框架、数据库、云服务。不确定的话直接问 Claude，它比你自己纠结半天靠谱。
- 技术架构——系统怎么设计的、模块之间怎么交互、数据库怎么设计的、API 有哪些。这些细节都写清楚，后面开发的时候 Claude Code 才有据可依。
第二阶段：配置
项目文档写好了，别急着开干。先把环境搭好：
- 建 GitHub 仓库——不用多说。
- 配环境变量文件——敏感信息统一管理。
- 写 CLAUDE.md——这是 Claude Code 的项目说明书，告诉它项目结构、代码规范、常用命令。
- 搭自动化文档系统——我习惯维护几个文档让 Claude Code 随时参考：架构说明、变更记录、项目进度、核心功能参考。在 CLAUDE.md 里配好这些文档的链接，并让 Claude 每次改完代码自动更新它们。
- 装插件——MCP、钩子这些，按需配置。
- 配子代理——比如专门管变更日志的、专门做前端测试的。各司其职。
这里有几个实操建议：
- 提前把权限配好，不然开发的时候 Claude Code 隔三差五问你要权限，很打断节奏。
- 配个钩子，Claude Code 申请权限时发通知给你，不用一直盯着屏幕。
- 做网页应用的话，强烈推荐配 Playwright 的 MCP，能让 Claude 自己跑浏览器看效果。
第三阶段：构建
MVP 实现这一步最简单——直接让 Claude Code 开干就行。
关键是后面的迭代。试过几种工作流，目前觉得好用的有三种：
通用工作流——调研 → 规划 → 开发 → 测试。小功能一轮就搞定，大功能按这个节奏反复循环。
基于 Issue 的工作流——所有需求、缺陷、优化都以 GitHub Issue 为准。把 Issue 扔给 Claude 处理就行，适合团队协作。
多代理工作流——同时开几个 Claude Code 实例做不同功能。这里有个坑：多个实例同时改代码会冲突。解决方案是用 git worktree 建隔离的工作树，每个代理在自己的树里改，改完再合并。
四个建议
- 用好模型——复杂任务别省那点钱，好的模型和差的模型在复杂场景下的差距非常大。
- 持续优化 CLAUDE.md——它不是写一次就完事的。项目在发展，你的偏好也在变，随时往里面加东西。
- 犯错后记下来——Claude 犯了什么错、怎么纠正的，记到 CLAUDE.md 里。下次它就不会再犯同样的错了。
- 大胆推倒重来——有时候代码堆到一定地步就是不如重写。别舍不得，重写往往比重构快得多。