技能介绍

从模糊需求到可编码设计

需求评审会上，很多人以为大家对产品功能达成了一致，直到开发排期时才发现，什么叫“支持订单导出”、数据量多大、是手动还是定时？这种未经加工的原始需求直接扔给开发团队，往往导致返工、补课以及各种范围蔓延。Req2Design 致力于解决这个问题。它是一个纯逻辑驱动的设计工作流技能，把用户的一句话想法或一份 Word/Markdown 文档，转化为可以直接交给研发团队落地的结构化技术设计文档。它不生成华丽但无用的演示文稿，只输出能写进代码库的硬核设计。

递进式交互工作流

这个技能最大的特点是极其严格的“确认机制”。它内部拆解了八个执行阶段（从阶段 0 到阶段 8）。为了保证每一步都不跑偏，它遵循不猜测原则：只要解释不清的需求点，都会化作结构化的选择题让你确认。

输入解析与对齐：读取输入后提炼功能与非功能需求摘要，并主动列出模糊点让你勾选过滤。
硬核工程设计：进入核心产出后，技能会为你提供可直接执行的 DDL 语句、Mermaid 架构图、时序图与符合 RESTful 规范的接口定义。不只是画个大饼，而是落实 InnoDB 引擎、索引建在哪几个字段上、分页参数如何规范。
全生命周期规划：从数据库模型一直覆盖到 CI/CD 流水线配置、资源开销预估。最后输出按周划分的开发任务拆解表，甚至连上线前的账号申请等待办事项都列好。

每一节产出后你都可以直接确认，拒绝一次性抛出万字长文让人看晕。

适用边界与注意点

尽管设计严密，它依然有着明确的适用范围限制。它本质上是需求分析师和后端架构师的结合体，前端跨端原生 UI 样式完全不在其考虑范围内。它不预设技术栈偏好，你必须要在早期沟通中明确是 Java/Spring Boot、Go/Gin 还是 Python/FastAPI。如果你“一句话甩需求”然后迫不及待想跳过提问，那你会失望的，它会有强烈的“提问依赖”。另外，在字段确认上它极其死板：金额必须标注 DECIMAL，软删除必须带 is_deleted。它是一个帮你理清技术细节的执行引擎，而非替代思考的魔法盒。