用 SDD + OpenSpec + Cursor 开发 SaaS：SoloFlow AI 前三个阶段的实践

最近我在开发一个自己的 SaaS 项目------SoloFlow AI。

它是一个面向自由职业者、独立开发者和 Solo Founder 的个人生产力工作空间。

产品希望把：

• Goals
• Projects
• Tasks
• Schedule
• Review
• AI-assisted Planning

逐步整合到同一个工作空间中。

目前产品仍然处于开发阶段，但已经完成了前三个主要功能阶段。

这次我想分享的重点不是某个具体 API 或 UI，而是我在这个项目中正在实践的一种开发方式：

Specification-Driven Development（SDD）+ OpenSpec + AI Coding。

以及为什么我最终选择：

一个功能一个功能完成前端、后端、数据库和测试，而不是先把所有页面做完，再统一补后端。

---

一、为什么开始做 SoloFlow AI？

独立开发时，我经常需要同时处理很多事情：

• 产品想法
• 项目开发
• 每日任务
• 时间安排
• 内容输出
• 客户工作
• 复盘与下一步计划

很多工具分别解决了其中一部分问题，但信息往往分散在不同地方。

所以我开始思考一个问题：

能不能把 Goal → Project → Task → Schedule → Review 形成一个连续的工作流程？

SoloFlow AI 就从这个想法开始。

AI 会是产品未来的重要能力之一，但我并不希望它成为一个"AI 自动替用户做所有决定"的工具。

我目前坚持的一个原则是：

AI 可以提出计划和修改建议，但真正改变用户数据之前，应由用户先预览并确认。

所以 AI 的目标更接近：

AI Suggestion
      ↓
Preview
      ↓
User Review
      ↓
Accept
      ↓
Commit

而不是直接修改用户的任务和计划。

---

二、技术栈

SoloFlow AI 当前采用的主要技术包括：

层	技术
Frontend	Next.js、React、TypeScript
Backend	.NET 10、ASP.NET Core Web API
ORM	Entity Framework Core
Database	PostgreSQL
UI	Tailwind CSS、shadcn/ui、Lucide
Specification	OpenSpec
AI Coding	Cursor

在技术选型之外，我更关注的是：

如何让需求、设计、实现和测试之间保持一致。

这也是后来引入 SDD 的主要原因。

---

三、为什么我开始使用 SDD？

使用 AI 辅助开发之后，一个很明显的问题是：

写代码变快了，但"做错东西"的速度也可能变快。

如果只告诉 AI：

帮我开发一个任务管理系统。

AI 很快就可以生成大量代码。

但很快就会遇到问题：

• Task 到底有哪些状态？
• Task 和 Calendar Event 是不是同一个实体？
• 删除应该物理删除还是软删除？
• Project 和 Task 是什么关系？
• Task 是否一定需要开始和结束时间？
• AI 是否允许直接修改用户数据？

这些都不是代码问题。

它们首先是产品和业务规则问题。

如果这些问题没有先确定，代码写得越多，后面返工可能越严重。

所以我现在采用的基本流程是：

Product Requirement
        ↓
OpenSpec Proposal
        ↓
Specification
        ↓
Design
        ↓
Tasks
        ↓
Implementation
        ↓
Browser / API Testing
        ↓
Review
        ↓
Archive

只有当当前 Change 达到约定的验收标准之后，才进入下一个阶段。

---

四、Change 1：Authentication & Personal Workspace

第一个阶段不是 Dashboard，也不是 AI。

而是最基础的：

用户身份和个人工作空间。

这个阶段主要解决：

• 用户注册与登录
• ASP.NET Core Identity
• HttpOnly Cookie
• CSRF 防护
• 每个用户拥有自己的 Personal Workspace
• 用户数据隔离

这里有一个很重要的设计原则：

后端不能信任前端提交的 userId 或 workspaceId。

数据归属应该根据当前经过认证的用户身份确定。

这看起来是一个很基础的功能，但对于 SaaS 来说，它决定了后面所有业务数据的安全边界。

这个 Change 完成、测试并归档后，我才继续下一阶段。

---

五、Change 2：Task & Calendar Event Quick Add

第二阶段开始进入真正的业务功能：

Quick Add。

最初看起来只是一个"添加内容"的弹窗，但真正梳理需求时，很快遇到了一个重要问题：

Task 和 Calendar Event 到底是不是同一个东西？

最后我的决定是：

不是。

Task 表示：

有一件事情需要完成。

Calendar Event 表示：

某段时间已经被某件事情占用。

因此它们使用不同的业务模型。

Task 可以有：

• Priority
• Status
• Due Date
• Estimated Duration
• Optional Schedule

而 Calendar Event 更关注：

• Start Time
• End Time
• Busy / Free

普通日程也不是所谓的"P5 Task"。

它就是一个独立的 Calendar Event。

这个看起来很小的产品决定，对后续 Planner 和 AI Scheduling 都非常重要。

---

六、Task 是否必须有开始时间和结束时间？

Quick Add 阶段还讨论了另一个问题：

创建 Task 时，要不要强制选择时间？

最后我的设计是：

不需要。

用户完全可以先创建：

Prepare project proposal

而不知道具体什么时候做。

因此 Task 可以处于：

Task
└── No Schedule

如果用户填写执行时间，则：

Start Time + End Time

必须同时存在，而且：

End Time > Start Time

这也为后面的 Planner 留下了空间。

Task 表示"需要做什么"。

Schedule 表示"什么时候做"。

两者不应该完全绑定。

---

七、Change 3：Task Management

第三阶段是在 Quick Add 的基础上，真正建立完整的任务管理能力。

这一阶段加入了：

• Tasks 页面
• 任务列表
• 搜索
• 筛选
• 状态管理
• 编辑
• 删除
• 恢复
• Statistics
• Detail Drawer

任务状态从之前的固定初始状态，扩展为：

待处理
进行中
已完成

同时增加了软删除机制。

我没有简单地把删除理解为：

DELETE FROM Tasks

而是使用类似：

DeletedAt

这样的删除标记。

这样用户可以恢复任务，而且恢复后仍然保留原来的业务状态。

---

八、为什么我没有先把所有前端页面做完？

这是最近我重新思考比较多的一个问题。

SoloFlow AI 后面还有：

• Dashboard
• Goals
• Projects
• Planner
• Reviews
• Settings
• AI Planning

一种开发方式是：

先把所有页面全部做出来，然后统一补 API 和数据库。

这种方式短期看起来进度很快。

因为很快就可以看到很多页面。

但问题是：

UI 会提前假设大量尚未确定的业务规则。

例如 Planner。

界面上看起来可能只是把 Task 放到时间轴。

但真正开发后端时，很快会出现：

• 一个 Task 可以安排几段时间？
• 一个 Task 可以跨多天吗？
• Calendar Event 和 Task Time Block 怎么区分？
• 数据库存 UTC 还是 Local Time？
• 用户修改时区怎么办？
• 删除 Task 后 Schedule 怎么处理？

如果这些问题是在所有前端完成以后才发现，就很容易产生大量返工。

---

九、我现在选择 Vertical Slice

所以接下来我会继续采用：

SDD + Vertical Slice

简单来说，一个功能不只是一个页面。

一个真正完成的 Feature 应该包括：

User Interaction
       ↓
Frontend
       ↓
API
       ↓
Application / Domain
       ↓
EF Core
       ↓
PostgreSQL
       ↓
Read Back
       ↓
Real UI Result

例如未来的一个 Planner 功能：

用户把一个 Task 安排到周三上午 10 点。

这个 Feature 至少需要完成：

• Planner UI
• TaskTimeBlock 数据模型
• API
• 数据库迁移
• 保存
• 查询
• 页面重新读取
• 测试
• 浏览器验收

做到这里，它才算真正完成。

而不是：

Planner 页面已经画好了，所以完成 80%。

---

十、Design First 不等于 Frontend First

这里还有一个容易混淆的地方。

我仍然认为：

设计可以提前。

例如：

Mockup
   ↓
User Flow
   ↓
Interaction

这些都可以在开发前确定。

但：

UI Design First

并不等于：

Frontend Production Code First。

我的做法更接近：

先设计用户体验
        ↓
确定业务规则
        ↓
确定 API / Data Model
        ↓
完成一个完整 Vertical Slice

这样既可以避免"后端决定一切"，也可以避免"前端做了一大堆假数据页面"。

---

十一、为什么这种方法适合 AI 辅助开发？

我现在使用 Cursor 辅助开发。

AI 编码最大的优势之一是：

执行速度非常快。

但这也意味着需求如果模糊，错误实现同样会非常快地扩大。

如果一个 Prompt 是：

完成整个项目管理系统。

上下文会非常大。

AI 需要同时理解：

• Goals
• Projects
• Tasks
• Scheduling
• Permissions
• UI
• Database
• Business Rules

很容易发生上下文漂移。

但如果当前 OpenSpec Change 只有：

Manual Task Scheduling

AI 的上下文就会明显更小。

需要理解的核心可能只是：

Task
  ↓
TaskTimeBlock
  ↓
Planner

这会让开发、测试和验收都更加明确。

所以我现在越来越认同：

AI Coding 的速度越快，需求边界反而越需要清晰。

---

十二、前三个阶段完成后，我学到了什么？

目前 SoloFlow AI 已经完成三个 Change：

personal-workspace-auth ✅

task-event-quick-add ✅

task-management ✅

这几个阶段让我有几个比较明显的体会。

1. 不要让 AI 替代产品决策

AI 可以给出方案。

但：

Task 和 Event 是否应该分开？

这种问题最终还是应该由产品目标决定。

2. Specification 可以降低返工

很多问题如果在写代码之前讨论清楚，实现阶段会顺利很多。

3. 小 Change 比大 Change 更适合 AI Coding

一个 Change 越聚焦，AI 越容易保持完整上下文。

4. 浏览器结果才是最终产品

Specification、代码和测试都重要。

但对于用户来说：

最终看到和操作的是产品。

所以真实浏览器中的交互结果仍然是我最终的验收依据之一。

---

十三、下一步

接下来 SoloFlow AI 会继续进入 Scheduling / Planner 相关开发。

一个重要方向是：

Task
 ↓
TaskTimeBlock
 ↓
Planner

逐步支持任务时间安排、日历事件、Planner 和之后的 AI-assisted Planning。

不过我不会一开始就让 AI 自动修改用户的日程。

未来的 AI Planning 会继续遵守：

AI Generate
     ↓
Preview
     ↓
User Accept
     ↓
Commit

因为我认为：

好的 AI 产品，不只是 AI 能做多少，而是用户是否仍然拥有最终控制权。

---

总结

SoloFlow AI 目前还只是一个正在开发中的产品。

但相比一次性生成大量代码，我更希望通过一个个完整的功能切片，把它逐步做成真正可以使用的 SaaS。

当前开发方式可以总结为：

Product Thinking + SDD + OpenSpec + Vertical Slice + AI Coding

AI 提高了开发速度。

而 Specification 帮助我控制方向。

Vertical Slice 则确保每一个阶段完成后，都拥有一个真正可以运行和验收的产品版本。

这是我目前在 AI 辅助软件开发过程中最有价值的体会之一。

后续我也会继续记录 SoloFlow AI 的开发过程。