分享claude code技巧，让Claude Code分别担任架构师、开发者、测试和文档工程师

开发调优
1

微信公众号地址，大佬们可以帮忙点点赞 https://mp.weixin.qq.com/s/FO0DdYGV6rVdQOfwPZPQfw

软件工程开发如何在Claude Code上实现

最近在折腾Claude Code的时候，发现这玩意儿确实能够系统性地解决软件开发中的问题。不是那种玩具级别的代码助手，而是真正能够从需求分析到代码部署全流程覆盖的工具。今天就来聊聊如何通过自定义命令把整个软件工程流程跑通。

核心思路：从文档驱动到代码实现

整个工作流的核心逻辑很简单：先把需求搞清楚，再写代码，最后验证。但实际操作中，大部分团队都是直接上手写代码，需求文档要么没有，要么写完就束之高阁。Claude Code通过自定义命令可以强制执行这个流程。

主要工作流程

需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)

这不是什么新鲜概念，但关键在于每个环节都有明确的输入输出，而且可以自动化执行。

核心命令详解

/ask - 需求分析和架构设计

这个命令的作用是把模糊的业务需求转化为技术文档。不是简单的问答，而是系统性的架构分析。

实际使用场景：

/ask 设计一个支持千万级用户的电商平台的微服务架构

输出会包含：

  • 系统边界定义

  • 技术栈选择理由

  • 非功能性需求分析

  • 潜在风险点识别

关键在于它会强制你思考那些平时容易忽略的问题，比如数据一致性、服务间通信、故障恢复等。输出的文档直接保存到docs目录，后续所有开发工作都以此为准。

/code - 从文档到代码实现

有了需求文档，/code命令会基于文档内容生成具体的代码实现。不是那种简单的代码片段，而是完整的、可运行的代码。

实际使用场景：

/code @/docs/points_system.md 基于技术方案文档生成代码

请一定要开启Plan模式

工作机制：

  • 读取docs目录下的需求文档

  • 分析现有代码库结构

  • 生成符合项目规范的代码

  • 确保与现有系统的兼容性

这里有个细节很重要：它不会凭空生成代码，而是基于你的项目上下文。比如你用的是Spring Boot，它就会生成Spring Boot风格的代码；你用的是Node.js，它就会生成Express风格的代码。

/test - 测试用例生成

测试驱动开发（TDD）说了这么多年，真正执行的团队不多。主要原因是写测试用例太费时间，而且很多开发者不知道该测什么。

/test命令解决的就是这个问题：

  • 基于需求文档自动生成测试用例

  • 覆盖单元测试、集成测试、边界条件测试

  • 生成可执行的测试代码，不是伪代码

实际使用场景：

/test @/docs/points_system.md 基于技术方案文档生成单元测试

**实际效果：**如果你写了一个用户认证模块，它会自动生成：

  • 正常登录流程测试

  • 密码错误测试

  • 账号锁定测试

  • 并发登录测试

  • SQL注入防护测试

/review - 文档与代码一致性检查

这是整个流程中最关键的一环。很多项目的问题就在于代码和文档不一致，时间长了就没人知道系统到底是怎么设计的。

实际使用场景：

/review @/docs/points_system.md 基于技术方案文档检查代码是否符合 列出不符合内容以及二次优化方案

/review命令会：

  • 对比需求文档和实际代码

  • 检查代码质量和安全问题

  • 验证性能和可扩展性

  • 识别架构偏离

如果发现问题，会明确指出哪里不符合预期，以及具体的修改建议。

/optimize 和 /refactor - 问题修复和优化

当/review发现问题后，就需要用这两个命令来修复：

实际使用场景：

/refactor @/docs/points_system.md 基于技术方案文档优化/重构代码

/optimize 主要处理性能问题：

  • 算法复杂度优化

  • 资源使用优化

  • 并发处理优化

  • 缓存策略调整

/refactor 主要处理代码结构问题：

  • 设计模式应用

  • 代码复用性提升

  • 可维护性改进

  • 技术债务清理

实际开发案例

举个具体例子，开发一个用户认证系统：

第一步：需求分析

/ask 设计支持JWT的用户认证系统，包含登录、注册、密码重置功能

输出文档包含：

  • API接口设计

  • 数据库表结构

  • 安全策略

  • 错误处理机制

第二步：代码实现

/code 实现用户认证系统的后端API

生成完整的后端代码，包括：

  • Controller层接口

  • Service层业务逻辑

  • Repository层数据访问

  • JWT工具类

  • 异常处理

第三步：测试用例

/test 用户认证功能的全面测试

自动生成：

  • 单元测试（每个方法）

  • 集成测试（API接口）

  • 安全测试（注入攻击防护）

  • 性能测试（并发场景）

第四步：代码审查

/review 用户认证模块

检查结果可能包括：

  • 密码加密强度不够

  • 缺少请求频率限制

  • 错误信息泄露敏感信息

  • 数据库查询可以优化

第五步：问题修复

/optimize 用户认证API性能优化

针对review发现的问题进行修复和优化。

实际使用体验

用了一段时间后，发现几个明显的好处：

1. 强制规范化流程不能再随意跳过文档和测试环节，因为后续的命令都依赖前面的输出。

2. 提高代码质量自动化的review能发现很多人工容易忽略的问题，特别是安全和性能方面。

3. 减少返工前期把需求和架构想清楚，后面写代码就很少需要大改。

4. 知识沉淀每个项目都有完整的文档记录，新人接手或者后期维护都很方便。

当然也有一些限制：

1. 学习成本需要适应这种工作方式，习惯了直接写代码的开发者可能不太适应。

2. 命令设计复杂每个命令的提示词都很长，需要仔细调优才能达到理想效果。

3. 上下文依赖命令之间有强依赖关系，中间某个环节出问题会影响后续流程。

4. LLM上下文限制每个命令执行时必须要使用/clear清理上下文，否则被Claude code自动压缩后质量降低非常多。

自定义commands 提示词文档 https://claude.ai/public/artifacts/e2725e41-cca5-48e5-9c15-6eab92012e75

168 个赞
2

感谢分享

2 个赞
3

一起探讨

1 个赞
4

感觉AI无法避免的问题就是上下文长度，在前期需求明确没有太多Input的时候速度很快也很准确，所以现在我都会要求大模型维护一个文档，用来描述每个业务的调用流程，在进行Agent的时候把文档的一部分作为输入，对问题描述要清晰，这样解决的比较高效 :face_with_monocle:

8 个赞
5

感谢感谢

1 个赞
6

这样处理感觉是最佳的实践方案，很灵动 :sunny:

1 个赞
7

感谢佬友的分享，有时间了试试

1 个赞
8

是的 接下来分享如何用好 claude code memory

1 个赞
9

感谢分享。

1 个赞
10

其实就是架构师的角色由开发者和大模型共同维护，全部交给大模型感觉还是有点难度

2 个赞
11

感谢大佬

1 个赞
12

感谢佬友分享，学习了

1 个赞
13

这个方向挺对的，但是感觉对于比较大的项目有点吃力。即便全开task，大概率一个窗口也只能完善一个部分而不能包圆所有的部分。类似的方案尝试过，很容易出现由于没有全局视野导致的技术债务。

1 个赞
14

感谢大佬 学习了

1 个赞
15

cc体验下来规范的文件化读档和归档很有必要。分享reddit上看到的一个方案（我稍微改动了一下）：

  • Foundation（基础层）：存放项目稳定且核心的文档和知识沉淀，每类文档通常仅一份。例如项目愿景、整体架构设计、技术规范、编码标准等。这些文档变更频率低，作为团队共识的权威信息，确保各阶段都有可靠参考。
  • Context（上下文层）：存放项目动态上下文信息，随开发进展持续更新。例如阶段状态记录（stage.md）、当前开发焦点（focus.md）、待办事项清单（todo.md）、决策记录（decisions.md）、活动日志（activity.log）、任务执行日志（tasks.log）等。这些文档反映项目实时状态和过程，使团队随时掌握当前进度与问题，全局上下文清晰透明。多数上下文层文档由工具自动生成或更新（如日志），保持对实际活动的持久记录。
  • Components（组件层）：存放各功能模块的详细文档，每个模块对应独立文件，通常通过模板生成。例如 module-*.md 记录模块的设计与实现细节，api-*.md 描述接口规范，test-*.md 记录模块的测试方案等。组件层文档按需创建和维护，确保模块化开发中每个模块都有配套文档，从而降低模块耦合度，防止知识遗失。
6 个赞
16

查看另外一个文章分享，上下文的连接通过CLAUDE.md 不同的action执行都需要清理上下文 /clear

17

好了，技术全学了，就是没有Claude

18

可以使用kimi k2

19

佬友给的提示词不太方便下载啊(不是)

1 个赞
20

需要梯子