最近在给 CabloyJS 全栈框架做 SMS 套件，先把通用底座、短信验证码和手机号认证这几块拆开。期间试了下 Claude Code，输入的提示词和它给出的开发方案还挺有代表性，整理一份实际记录。

我当时给的提示词大概是：

有如下开发任务，请仔细分析并整理合理方案：

1. 目标：先实现 SMS 系统底座，再基于底座实现多个业务能力。

- 系统底座：SMS provider / clients / scene。

- sms captcha：短信验证码。

- sms auth：用户注册与登录。

2. 套件和模块结构：

- 套件：cabloy-sms。

- cabloy-sms：提供 SMS 系统底座。

- sms-captcha：短信验证码。

- sms-auth：用户注册与登录。

- sms-mock：提供 Mock SMS Provider，在控制台打印验证码，并把验证码发给前端，让前端直接把验证码显示到输入框里。

Claude Code 给出的拆分是保留 cabloy-sms 套件和四个模块：

- cabloy-sms：负责短信传输底座，处理使用哪个供应商账号、哪个模板发短信。

- sms-captcha：处理验证码发给谁、用于什么操作，以及验证码校验。

- sms-auth：处理验证成功后登录哪个账号，是否创建新账号。

- sms-mock：开发和测试时使用的短信 Provider，替代真实发送，但不改验证码校验和认证流程。

我比较认可的一点是它把几层之间的依赖分得比较清楚：底座不依赖验证码，验证码不依赖用户认证，Mock 也不改变真实业务流程。sms-captcha 依赖短信底座和现有验证码体系，sms-auth 依赖短信验证码和现有认证体系，sms-mock 只依赖短信底座。Mock 是否启用交给应用组合和服务端配置决定，业务模块不用默认依赖它。

当前仓库是 Cabloy Basic，方案里建议复用 Vona 现有的 provider/client/scene 扩展方式、a-captcha 验证码体系和 a-auth 认证链，不另起一套短信验证码缓存和会话系统。现有 a-captcha 还缺手机号绑定、原子消费这类短信登录需要的能力，后面做有限扩展，尽量保持向后兼容。

目录也按现有结构来：

后端：vona/src/suite/cabloy-sms/modules/

前端：zova/src/suite/cabloy-sms/modules/

四个模块不需要都建前端目录，首期主要是 sms-captcha 的验证码交互和 sms-auth 的登录表单。sms-mock 直接在服务端打印并回填验证码，不再单独做一套前端 Mock 系统。

Provider 代表发送协议的实现，比如：

- sms-mock:mock

- 后续的阿里云短信 Provider

- 后续的腾讯云短信 Provider

Provider 只负责把统一发送请求转换成供应商请求，调用 SDK 或 HTTP API，再把结果转回统一格式，同时隐藏供应商错误和敏感信息。验证码生成、注册登录判断、用户查找都放在上层。

Client 是某个 Provider 下的命名账号配置，不单独做成业务服务。比如同一个真实 Provider 可以有 default、marketing 两个 client，分别对应默认账号、另一套供应商账号或专用发送配置。Client 里保存凭据、区域、接入地址、供应商默认选项和启用状态。

Provider 和 scene 这块准备沿用现有的 decorator、类型注册、onion metadata 和 CLI 模板机制，参考代码是：

vona/src/suite-vendor/a-pay/modules/a-pay/src/types/payProvider.ts:6

目前这份方案还停在 cabloy-sms 的 provider / clients / scene 划分这里，后面再继续细化发送接口、验证码消费和认证流程。

用 Claude Code 给 CabloyJS 做 SMS 套件，提示词和模块拆分记录