【Claude code workflow】实现你的工作流,项目开发更得心应手~~(超详细流程)

张开发
2026/5/4 3:57:06 15 分钟阅读
【Claude code workflow】实现你的工作流,项目开发更得心应手~~(超详细流程)
优化你的项目开发流程以下经验来源于油管博主Avtharhttps://www.youtube.com/watch?vaQvpqlSiUIQ本博客旨在吸收经验基于此总结出一套可以实地落地的开发方案看完你也可以按照我的步骤进行项目初期的部署~~他总结出项目开发的具体流程总结为PSBPlan、Setup and Build阶段一Plan这个阶段的核心是在编写任何代码之前为项目设定好清晰的成功路径实现细节进行头脑风暴通过文档记录如docs/discovery/brainstorm.md你想通过项目实现的具体内容Tips在项目开始前总要问自己两个问题“你到底想做什么或者你的项目目标是什么”明确自己真正想要什么会彻底改变你处理项目的方式这决定了你需要重点构建什么以及可以省略什么“你想要实现的功能里程碑是什么”将项目分解为清晰的阶段如先确立最小可行性产品 MVP 以及后续的改进版本如增加框架润色优化AI完善ProjectPlan向 Claude 或 ChatGPT 描述你的想法让 AI 帮你梳理思路并总结成 Markdown 文件因为你那时的想法还很模糊甚至很难写出来用语言输入大声说出来能更容易理清你的思路创建项目规格文档 (​​docs/project_spec.md​​)这里建议放到docs/​根目录下它要求Agent所有逻辑推导必须以此为最高准则也利于多Agent并行协作。文档中包含两个关键部分包含有PRD产品需求文档三个关键问题目标用户是谁、解决什么问题、产品该做什么有时候你需要思考目标用户是什么想为他们解决什么样的问题有时候那个目标用户是你自己。所以要花些时间想想提出具体的描述避免Claude去提出假设做出不尽人意的产品。你对用户体验的流程描述的越具体Claude就能越好的帮你实现EDD工程需求文档技术栈选择、系统设计、数据库模式、API 设计等重要提示​需求必须具体具体描述用户体验和交互细节例如工作流是怎样的能否加照片避免 Claude 自行假设。让 AI 向你提问将头脑风暴内容(brainstorm.md​)发给 AI让它反问你可能没有想到的边界问题这能帮你发现未考虑周全的盲点。明确你的技术栈如果不明确说明Claude 可能会随机注入你不需要的技术不要试图一次性构建所有内容先构建版本一 (MVP)然后根据反馈迭代为每个里程碑定义完成的标准以便Claude明确目标。阶段二Set up设置 GitHub 仓库通常在Claud.md要求Claude为他开发的每个项目创建一个新的分支完成后将分支merge或向主分支发起PR。**分支** - 在开始重大更改之前始终创建功能分支 - 切勿直接提交在主分支 master - 分支命名feature/description 或者 fix/description多利用Issue设置claude.md文件作为项目的“记忆”包含项目目标、架构概述、设计规范、安全约束和仓库礼仪等。它的内容不宜过多要确保重点放在最重要的信息上避免变得臃肿Claude会​/init创建环境变量文件 (.env)让 Claude 生成模板(.env.example)后并填入 API 密钥避免它在编码时停下来向你索要prompt请基于当前项目规范和技术栈创建一个示例ENV文件根据创建的模板来填写所需的凭据和API密钥接下来使用相关技术栈的配置则从这里获取维护Memory定期更新项目的上下文信息每隔一个重要节点让Claude及时更新这些文档这样会话中始终掌握最新的上下文信息。promptupdate memory in ./claude.md配置三个核心文件​docs/architecture.md结构文档记录你的系统设计应用程序结构以及主要组件的交互方式并保持功能更新​docs/changelog.md变更日志用于记录项目随时间推移而发生变化​docs/project_status.md项目状态文档主要维护三个维度项目的里程碑有哪些在这些里程碑里你完成了哪些工作你上次完成了什么你接下来要做的是什么设置 MCP服务器 和 必要插件连接外部工具如数据库、Playwright用于前端测试和 Vercel。设置子代理 (subagents)用于自动化特定任务如生成变更日志、前端测试和复盘优化。这里推荐设置三个子agent变更日志在完成一项功能后创建和更新变更日志changelog.md前端测试用于测试前端并能自动运行的脚本测试的代理回顾代理在开发会议结束后反思哪些地方可以改进然后将这些建议更新到Claude.md​或prompt中高级设置Hooks预先配置权限避免等待授权并设置 Hooks如失败重试或 Slack 通知以实现高级自动化阶段三构建 (Build)开始利用 Claude 编写代码涵盖从 MVP 到复杂功能的开发工作流介绍常规工作流 (General workflow)建议在开发单一功能时使用包含四个步骤研究 - 计划 - 实施 - 测试在研究与计划环节中建议将研究报告放到docs/research/目录下。将Claude plan mode打开prompt让我们处理第14个问题即提升Nano Banana Pro生成缩略图的质量。你的任务是首先撰写一份研究报告报告放到docs/research/banana_research.md中阐述如何引导模型生成优质的图像。同时请参考nano_banana_transcript.txt文件这是一段关于这一理念的YouTube视频内容。但请结合网络搜索结果来补充你的研究内容请将研究报告保存在文档文件夹中在实施和测试过程中使用官方插件的/feature-dev命令确保阶段工作流开发不翻车它包含代码库探索、架构设计和质量审查的专用代理在内的全面功能开发工作流参考prompt/feature-dev 请读取 xxx 文件夹下关于“Nano Banana Pro 缩略图质量提升”的研究报告根据报告中的优化策略修改基于 Github Issue 工作流 (Issue-based workflow)将 GitHub Issues 作为 Bug 和新功能的“事实来源”让 Claude 直接处理特定的 Issue。可以自定义命令行或子代理让它接受文件或文件夹作为输入并使用github cli输出我的仓库中的github issue这里我自定义了一个命令行/create-issue这样每次有需求都可以创建github issue。你可以让Claude自定义一个这是参考prompt你的任务是为 Claude 添加一个名为 create-issue 的自定义命令模式要求全局生效 逻辑要求该模式需具备分析用户通过 引入的文件或文件夹的能力。具备能根据用户的要求理解要求并创建对应Issue的能力。它需要调用 gh issue list检索当前仓库的 Issue 以进行去重校验。确认无误后构造 gh issue create 命令。Issue正文需包含问题描述、受影响的文件路径及改进建议并输出对应仓库中的github issue。请直接修改配置文件并应用更改当要创建Issue时可这样说请分析 (或你的核心代码目录) 以及之前的研究报告文档。针对提升 Nano Banana Pro 缩略图质量的目标识别出代码中尚未实现的 3 个关键工程点并为它们分别创建 GitHub Issue。标签使用 enhancement并在正文中引用docs/research/banana_report.md中的结论当要处理Issue时可这样说// 快速开发版本处理 Issue #14// 先计划后实施开启 plan mode针对 Issue #14 制定实施细节这套工作流的优势是可以将项目里程碑或问题让Claude帮你拆分成若干个Github Issue而不必在项目上留下大量的文档。多代理工作流 (Multi-agent workflow)利用 Git Worktrees技术在隔离的目录和分支中同时运行多个 Claude Code 实例从而并行开发多个功能最后再合并这是先进的开发流程。多代理工作流利用​​claude.md​​文件配置的开发准则与自定义命令行的方式实现。能达到虽然多个会话的​​memory​​进度不同但由于它们处于同一个 Git 仓库的不同 worktree​**通过同步​​​claude.md​​​并在提交时拉取最新文档可以实现不同 Agent 实例间的知识对齐。**先要进行前置配置​claude.md三条约束在项目完成里程碑或主要新增内容后更新docs/project_spec.md文件。在git进行提交时使用/update-docs-and-commit命令。所有的逻辑实现必须溯源至docs/project_spec.md。若代码实现与规格说明不符以规格说明为准若需要修改则需要询问用户是否要更新文档再写代码。自定义命令​/setup​内置/init​命令初始claude.md后自动增加以上三条约束。创建prompt定义 /setup 命令要求全局生效。逻辑检查 claude.md 是否存在若无则执行/init 命令等待/init 命令成功执行后再向claude.md 添加三条开发核心准则提示此时claude.md文件由于执行了/init 命令所以是肯定会存在的若已经存在则在 ##Documentation 章节后追加三条开发核心准则。三条开发核心准则分别为-在项目完成里程碑或主要新增内容后更新docs/project_spec.md文件。-在git进行提交时使用 /update-docs-and-commit 命令。-所有的逻辑实现必须溯源至docs/project_spec.md。若代码实现与规格说明不符以规格说明为准若需要修改则需要询问用户是否要更新文档再写代码。另外严格要求 所有的文件写入操作必须是幂等的Idempotent即重复运行 /setup 不会导致内容重复堆叠。二改后续增加了维护文档的需要升级/setup命令升级我之前配置的 /setup 自定义命令行的执行逻辑使其在执行时除了原有的功能外另外包含以下自动化行为1.文件模板初始化在项目根目录自动创建/docs文件夹如果不存在并生成以下三个文件的初始结构-docs/architecture.md包含系统架构图占位、核心组件说明、技术栈清单。-docs/changelog.md包含版本记录表格日期、变更项、作者、关联Issue。-docs/project_status.md包含三个固定的 Markdown 标题## 里程碑、## 已完成工作、## 待办与后续计划2.设定更新准则在 claude.md 中Project Rules中加入以下逻辑-架构对齐每当引入新的第三方库、修改核心类交互或调整数据库模式时必须同步更新 docs/architecture.md。-变更溯源每次 Git 提交前需在 docs/changelog.md 中追加一条简要变更记录。-进度锚定在每个任务Issue开始前先读取docs/project_status.md确认当前里程碑任务完成后更新该文件的“上次完成”与“接下来要做”部分3.要求依旧是确保 setup逻辑是幂等Idempotent的如果文件已存在仅检查缺失的部分并补齐不要覆盖用户已写的内容​/update-docs-and-commit这个命令的作用是当git提交的时候会自动更新claude.md文件同时进行一次git提交确保文档和代码保持同步也有利于并行agent处理。创建prompt配置自定义命令要求全局生效新增 update-docs-and-commit命令逻辑如下首先分析自上次提交以来的代码变更及实现的关键里程碑。其次将这些摘要自动追加或更新到 claude.md的“进度记录”或“架构变更”章节中。最后执行 git add . 并根据刚才生成的摘要自动撰写 commit message 运行 git commit实现流程Step 1创建docs/discoverybrainstorm.md写下你的所有直觉、痛点和核心功能点。Step 2给 Claude 发送指令根据 Claude 的反馈完善想法然后让它基于对话结果直接生成docs/project_spec.mdprompt你现在是一名具备严谨学术标准和深厚工程背景的资深架构师。请阅读docs/research/brainstorm.md。任务目标不要止步于浅层的几个问题。你的目标是通过递归式提问挖掘我未考虑到的工程风险与产品边界问题。在回答我的问题前请按以下维度发起询问本质意图明确该项目的终极目标。是技术验证、学习性练习、还是准备投入生产的 MVP不同的目标决定了后续技术栈的容错率。里程碑规划识别功能依赖链。请问如何定义 MVP 的硬性边界后续的扩展版本中哪些是“必须有”而哪些是“锦上添花”工程规格技术栈选择是否存在对特定框架或模型的依赖偏好 接口设计系统之间是同步阻塞调用还是异步事件驱动产品契约目标用户画像解决的是开发者的效能问题还是最终用户的业务痛点 核心指标如何量化该项目的成功如响应延迟低于 200ms。交互要求可以基于问题提出用户建议或让用户自行描述。持续向我提问直至你有95%的信心能够执行项目。请分批次提出问题确保逻辑链条严密。在我完成所有回答后请将我的回答与头脑风暴内容整合最终输出为项目规格文档docs/project_spec.md里面包含PRD产品需求文档和 EDD工程设计文档部分。Step 3接下来就可以进行你的工作了~~推荐目录结构.├── .claudecode.json├── claude.md # 项目动态记忆├── docs/ # 静态规格与研究成果库│ ├── project_spec.md # PRD EDD│ ├── /discovery/brainstorm.md # 存放自己写的头脑风暴 brainstorm.md│ └── architecture.md # 结构文档记录你的系统设计应用程序结构以及主要组件的交互方式并保持功能更新│ └── changelog.md # 变更日志用于记录项目随时间推移而发生变化│ └── project_status.md # 维护项目状态文档├── src/ # 项目源代码└── pom.xml重要提示善用plan mode模式通过shift tab开启让 Claude 思考任务、拆解步骤并提问然后再开始构建这样能获得好得多的结果。尽可能使用最好的模型用Claude去进行规划和复杂任务开发任务可以交给codex修bug时则用简单的模型修复这会大大节省你的时间和token定期维护你的文档不要害怕舍弃代码成本很低。如果在原型阶段效果不是很满意的话大胆撤销甚至直接丢弃该功能重新开始这能更快找到满意的解决方案~~希望对你有帮助祝您身体健康。

更多文章