在这些时刻，你需要一位“设计军师”

好的工具不仅仅是帮你干活，更是帮你思考。看看在这些真实的工作瞬间，Brainstorming 是如何发光发热的。

场景 1：当新需求只有一句话时

你是一个快速迭代中的产品团队成员。早会上老板突然提议：“咱们那个文件上传功能，能不能限制一下不同部门的配额？”你觉得这事儿不难，但深究起来，配额怎么存、怎么更高效地校验，其实都有讲究。

“帮我设计一个基于部门的文件上传配额管理功能，每个部门配额不一样。”

它没有直接吐出一堆代码。它先核实了你现有的“部门”数据结构，随后提出了三种存储配额的方案：从简单的静态配置到可扩展的数据库字段。最终，你花 10 分钟确认了方案，拿到了一份可以直接在周会上汇报的设计初稿。

场景 2：面对“陈年旧债”要重构时

项目里有个老的缓存模块，当初写得太乱，现在想用 Redis 重构一下。你很担心直接改会把现有的业务逻辑搞挂。

“我想把现在的本地 LruCache 模块重构为分布式 Redis 缓存，需要考虑单点故障和并发穿透的问题。”

它会像剥洋葱一样带你拆解。它会先问你目前的缓存命中率要求，然后引导你确定 key 的命名规范。接着，它会分章节给你看：连接池配置、防击穿策略、回流加载逻辑。每一步你都点头后，它才会把这些拼成完整的技术规格书。

场景 3：从 0 到 1 打造自己的小工具

你想写一个命令行工具，用来自动压缩并上传项目的静态资源到 CDN。这事儿虽小，但涉及到的依赖和路径处理其实挺琐碎。

“我想写个 CLI 工具，能扫描 dist 目录，把大于 1MB 的图片压缩并上传到阿里云 OSS。”

它会先确认你的开发语言偏好，然后一步步设计：如何遍历文件流、如何优雅地处理压缩错误、如何保护你的密钥不被硬编码。最后它不仅给了设计，还顺便提醒了你 YAGNI 原则——“如果只是为了自己用，要不要先去掉那些复杂的 UI 回显？”