微信公众号地址,大佬们可以帮忙点点赞 https://mp.weixin.qq.com/s/FO0DdYGV6rVdQOfwPZPQfw
最近在折腾 Claude Code 的时候,发现这玩意儿确实能够系统性地解决软件开发中的问题。不是那种玩具级别的代码助手,而是真正能够从需求分析到代码部署全流程覆盖的工具。今天就来聊聊如何通过自定义命令把整个软件工程流程跑通。
整个工作流的核心逻辑很简单:先把需求搞清楚,再写代码,最后验证。但实际操作中,大部分团队都是直接上手写代码,需求文档要么没有,要么写完就束之高阁。Claude Code 通过自定义命令可以强制执行这个流程。
需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)
这不是什么新鲜概念,但关键在于每个环节都有明确的输入输出,而且可以自动化执行。
这个命令的作用是把模糊的业务需求转化为技术文档。不是简单的问答,而是系统性的架构分析。
实际使用场景:
/ask 设计一个支持千万级用户的电商平台的微服务架构
输出会包含:
系统边界定义
技术栈选择理由
非功能性需求分析
潜在风险点识别
关键在于它会强制你思考那些平时容易忽略的问题,比如数据一致性、服务间通信、故障恢复等。输出的文档直接保存到docs
目录,后续所有开发工作都以此为准。
有了需求文档,/code
命令会基于文档内容生成具体的代码实现。不是那种简单的代码片段,而是完整的、可运行的代码。
实际使用场景:
/code @/docs/points_system.md 基于技术方案文档生成代码
请一定要开启 Plan 模式
工作机制:
读取docs
目录下的需求文档
分析现有代码库结构
生成符合项目规范的代码
确保与现有系统的兼容性
这里有个细节很重要:它不会凭空生成代码,而是基于你的项目上下文。比如你用的是 Spring Boot ,它就会生成 Spring Boot 风格的代码;你用的是 Node.js ,它就会生成 Express 风格的代码。
测试驱动开发( TDD )说了这么多年,真正执行的团队不多。主要原因是写测试用例太费时间,而且很多开发者不知道该测什么。
/test
命令解决的就是这个问题:
基于需求文档自动生成测试用例
覆盖单元测试、集成测试、边界条件测试
生成可执行的测试代码,不是伪代码
实际使用场景:
/test @/docs/points_system.md 基于技术方案文档生成单元测试
实际效果:如果你写了一个用户认证模块,它会自动生成:
正常登录流程测试
密码错误测试
账号锁定测试
并发登录测试
SQL 注入防护测试
这是整个流程中最关键的一环。很多项目的问题就在于代码和文档不一致,时间长了就没人知道系统到底是怎么设计的。
实际使用场景:
/review @/docs/points_system.md 基于技术方案文档检查代码是否符合 列出不符合内容以及二次优化方案
/review
命令会:
对比需求文档和实际代码
检查代码质量和安全问题
验证性能和可扩展性
识别架构偏离
如果发现问题,会明确指出哪里不符合预期,以及具体的修改建议。
当/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
![]() |
1
cexll OP 全部的 commands https://github.com/cexll/myclaude
|
2
seeleywang123 21 天前
为什么我今天感觉他突然变傻了,跟 cursor 一样,给了计划开了深度思考,也是先改了再说
|
![]() |
3
datiewang 21 天前
谢谢,正好今天刚开始用
|
5
mokecc 21 天前
|
6
hex2en 21 天前
「 LLM 上下文限制每个命令执行时必须要使用/clear 清理上下文,否则被 Claude code 自动压缩后质量降低非常多。」
不经常使用/clear ,而是定期/compact 是否也可行? |
7
hex2en 21 天前
以及对 clear 命令的一个担忧:我常常担心 clear 后我的上下文就完全没有了。后面都是我的猜想:导致我让 cc 去做一些任务时,是没有足够的上下文的。是否应该在 clear 之后重新 init ,更新 claude.md 文件?
|
![]() |
8
ricklei2777 21 天前
|
9
kamisama 21 天前
@seeleywang123 是的。这两天都这个感觉,质量很差
|
![]() |
10
cexll OP @seeleywang123 除非 claude 官方 api 降智,不然应该不会和 cursor 自己单独处理一次动手脚
|
![]() |
13
cexll OP @ricklei2777 好的,github 仓库只是方便兄弟们取
|
14
seeleywang123 20 天前
@kamisama 就这两天,之前不会,而且我用 poe 去跟 4 聊天也有感觉
|
![]() |
15
magic3584 19 天前 via iPhone
虽然说是 TDD ,你这为啥还是先写代码再写的测试。。。
|