Claude Code 日常开发工作流 | Claude Code 原理与实战

预计阅读时间: 16 分钟

Claude Code 的日常使用可以很简单：在项目目录里启动，描述任务，让它读代码、修改、运行检查。但如果想长期稳定，就需要一套固定节奏。

这一篇给出从需求到交付的标准流程。

起手式

在项目目录中：

claude

然后给任务：

帮我新增一个学习专题入口。
要求：
- 复用现有学习模块结构。
- 新专题要进入 sitemap。
- 中英文路由都要支持。
- 完成后运行 lint 和 build。

这类提示包含目标、技术边界、SEO 要求和验证标准，比“加个页面”可靠得多。

可以先让 Claude Code 只读不改：

先不要修改文件。请读相关代码，说明当前学习模块的数据、路由、SEO 是怎么组织的。

探索阶段建议关注：

等它理解结构后，再让它实现。这样能减少“看错架构还继续写”的问题。

对于多文件任务，要求 Claude Code 输出计划：

请列出你将修改的文件、每个文件的目的、验证方式。计划确认后再开始。

计划应该具体到文件层级，而不是泛泛说“更新前端和文档”。

实现时坚持几个原则：

如果它准备引入新依赖，要求先解释：

如果需要新依赖，请先说明已有方案为什么不够、依赖大小、维护成本和替代方案。

让 Claude Code 根据任务选择验证：

完成后运行与改动相关的检查。至少需要 lint 和 build；如果有页面改动，请检查生成后的 HTML 是否包含关键内容。

常见验证组合：

改动	验证
文案或 Markdown	build、HTML 关键字检查
React/TypeScript	lint、build
SEO	sitemap、metadata、canonical、hreflang
UI	本地浏览器截图、移动端宽度检查
部署	配置测试、live curl

验证失败时，不要直接继续堆改动。先让它解释失败原因。

长任务会跨多轮。要让 Claude Code 保持上下文，可以明确说：

继续刚才未完成事项，先总结当前进度和未完成检查，再继续。

如果上下文很长，要求它整理状态：

请把当前任务的决策、已改文件、待验证项和风险整理成一个短清单。

这能减少长会话里的方向漂移。

完成后，交付总结应该包含：

改了什么。
为什么这样改。
运行了哪些检查。
部署到哪里。
还有哪些风险或未做项。

如果是提交代码，还应该说明 commit hash 和 push 状态。如果是部署，还应该说明 live URL 和检查结果。

实现 <功能>。
约束：
- 遵循现有架构。
- 不引入新依赖，除非先说明理由。
- 同步更新相关 docs。
- 完成后 lint/build。

现象：<错误>
复现：<步骤>
请先定位根因，再给最小修复。不要做无关重构。

发布 <内容路径> 到学习模块。
要求：
- 保持文件随站点版本管理。
- 生成静态路由和 sitemap。
- 图片使用公开静态资源。
- 检查备案号仍在页脚。