挑战用 AI 开发 App 从 0 到上架全过程 | 第 01 篇 ·产品定位与功能架构

一个人也要把需求画清楚：星尘笔记的产品定位与功能架构

「AI 写代码很快，但写什么代码，AI 替你决定不了。」

这是我开始这个挑战前，对自己说的第一句话。

写在前面

我是一名公众号创作者，也算是个半路出家的全栈工程师。过去几年里，我用过 Vue 写过管理后台，用过 Spring Boot 写过后端接口，也用 UniApp 提交过几个小工具到安卓应用市场。但从没一个人真正独立完成过一款”像样的”App——从需求到设计、从数据库到接口、从 App 端到管理后台、从打包到上架。

2026 年，AI 编程工具已经强到让人发指。Trae、Cursor、Copilot 这些工具能读懂整个工程，能一次写出完整的 CRUD 模块，能帮你定位诡异的 Bug。我决定做一个实验：

一个人 + 一个 AI 助手，30 天，能不能做出一款能上架的 App？

这款 App 叫 「星尘笔记」。

这篇是系列的第 1 篇，我想先聊聊在敲下第一行代码之前，我做了一件看似最无聊、却最重要的事——把需求画清楚。

一、为什么”先写需求文档，再敲代码”不是废话

我知道，看到”需求文档”四个字，80% 的独立开发者已经准备关掉这篇文章了。

毕竟我们听过太多遍这套说辞：「敏捷开发」「快速迭代」「先做 MVP 再说」「代码即文档」。我也曾是这样的人——拿到一个想法，打开 IDE，三分钟内写出 Hello World，然后一边写一边改，最后做出一个连自己都看不懂的怪物。

但这次不一样。这次我要借助 AI 写代码，而 AI 是一个需要明确指令的执行者，不是一个能陪你模糊探索的合伙人。

1.1 一个人开发，也要写需求的三条理由

理由一：AI 写代码之前，你得先告诉它”写什么”。

当我打开 Trae，对它说：”帮我写一个笔记 App 的后端接口。”它只会反问我：

笔记有几种类型？
字段是什么？
需要分页吗？分页规则是什么？
权限怎么控制？
数据要存几张表？

如果我答不上来，它就会开始”自由发挥”——生成的代码看起来很专业，但完全不符合我的业务。AI 的下限很高，但上限取决于你给的上下文有多清晰。

理由二：一个人开发最大的敌人不是技术，是遗忘。

这个项目我预计要做 4-5 个月。一个月前我决定”记账模块要支持账单导入”，一个月后我还能记得这个决定吗？还能记得为什么我选了 direction 字段而不是 type 字段来区分收礼随礼吗？

需求文档是”未来的自己”写给”现在的自己”的备忘录。

理由三：需求文档就是产品的”宪法”。

每次我想加新功能，我都会回到需求文档问自己一句：这个功能在原来的规划里吗？ 如果不在，要么修改文档（正式变更），要么砍掉（保持克制）。这能避免 App 像滚雪球一样越做越大、最后什么都做不好。

1.2 我的做法：一份能被 AI 读懂的需求文档

我没有写 Word，没有画 UML，没有用 Axure。我写的是一份 Markdown 文档，放在项目的 docs/ 目录下。

为什么选 Markdown？因为：

AI 读得懂：直接把文档丢给 Trae，它能立刻解析字段、接口、数据结构
Git 可追踪：每次修改需求都有 commit 记录，比 Word 改版靠谱
写起来快：不用纠结排版，专注内容
可引用：后期的所有技术文档都可以用相对路径引用它

这份文档写了 800 多行，覆盖了产品定位、功能架构、界面设计、数据结构四个部分。下面我拆解其中最关键的几块。

二、产品定位三要素：用户群体 / 使用场景 / 核心差异化

做产品最忌讳的是”我想做一个所有人都能用的 App”。这句话翻译过来就是”我不知道我的用户是谁”。

2.1 用户群体：5 类人，1 个共同点

我没有画一个复杂的人物画像，而是用一张表把目标用户列出来：

用户群体	使用场景	核心需求
创意工作者	记录灵感、创意草图	快速、手绘、AI 分析
学生群体	课堂笔记、学习心得	多媒体记录、分类整理
职场人士	会议记录、工作备忘	语音转文字、待办关联
记账用户	日常消费记录	快速记账、账单导入
随性记录者	生活感悟、随想	简洁、无压力记录

这 5 类人看起来很杂，但他们有一个共同点：他们记录的不是”文档”，是”碎片”。

这正是「星尘笔记」和 Notion、印象笔记这些”重型”笔记软件的本质区别。Notion 适合写一篇 5000 字的项目方案，星尘笔记适合记一句”今天下午三点开会”。一句话能记完的，绝不开一个文档。

2.2 使用场景：30 秒内完成一次记录

我在需求文档里给自己定了一条硬指标：从用户打开 App 到完成一次记录，不超过 30 秒。

这意味着：

App 启动后首页必须直接显示”快速记录”入口，不能是登录页
浮动按钮点击后必须直接展开记录方式选择面板，不能跳转页面
记录完成后必须自动保存并关闭，不能让用户点”保存”按钮

这条指标后来影响了整个 App 的交互设计。首页布局、浮动按钮的位置、动画效果、快捷入口的排列，都是围绕”30 秒内完成记录”这个目标设计的。

2.3 核心差异化：多元记录 + AI 整理

市面上笔记 App 已经够多了。我为什么还要做一款？答案在产品定位里写得很清楚：

星尘笔记

是一款融合了 AI 智能的随手记应用，主打”记录生活每一刻的灵感”。不同于传统的笔记软件，我们强调多元化记录（文字、语音、视频、图片、手绘）和智能化管理（AI 自动整理、智能标签、多维度检索）。

两个关键词：多元和智能。

多元

市面上大部分笔记 App 只支持文字 + 图片。我要做的是：

文字（富文本）
语音（带转写）
图片（带 OCR）
手绘（带画笔工具栏）
AI 对话（让 AI 帮你整理成笔记）

这 5 种记录方式背后是 5 张独立的数据库表。每种记录方式有自己独特的字段，但它们又共享一套统一的元信息。这个设计决策后来引出了一个让我吃了大亏的性能问题——多表分页查询。

智能

用户记完一条笔记后，可以一键让 AI 帮他生成：

笔记标题（如果用户没写）
笔记摘要
推荐标签
推荐分类
从笔记内容里提取待办事项（这是我最得意的功能）

但 AI 能做的远不止”整理新笔记”。更打动我的是另一个场景——查找老笔记。

传统笔记 App 的查找方式是：用户打开列表 → 翻页 → 搜索关键词 → 再翻页。笔记越多，找起来越痛苦。星尘笔记的做法是：

我

「上周我记过一条关于账单导入的笔记，帮我找一下」

已为你找到 2 条相关笔记：

《账单导入功能设计思路》

语音笔记 · 2026-07-15 · 时长 2 分 30 秒

原文摘录：「想支持支付宝和微信账单导出的 CSV 文件导入，需要做字段映射…」

✅ 关联待办（1 条）

研究支付宝账单 CSV 字段格式 · 截止 2026-07-20

支持跨类型检索：不管是文字、语音、图片还是手绘笔记，AI 都能从笔记库里捞出来，并给出原文引用和定位。

这意味着 所有的笔记记录都可以通过与 AI 对话直接调取。用户不需要一个一个去翻列表，只需要用自然语言描述”我大概记得什么时候记过什么”，AI 就能帮你捞出来。这是星尘笔记和传统笔记软件最本质的体验差异——记录入口多元，查找入口统一。

这意味着每条笔记都可以被”二次加工”。原始记录是粗糙的，AI 整理后的版本是结构化的。我在数据库里用单独的表存储整理后的版本，并保留指向原始笔记的引用，这样既不丢失原始数据，又能让用户看到”AI 加工后的版本”。

三、功能架构图：5 大模块 + 10 张核心表

光有定位还不够，得拆成可执行的功能模块。我在需求文档里画了这样一棵功能树：

星尘笔记 ├── 首页 (快速记录入口 + 今日动态) ├── 笔记中心 (全部笔记管理) │ ├── AI 智能记录 │ ├── 文本记录 │ ├── 语音记录 │ ├── 视频记录 │ ├── 图片记录 │ └── 手绘记录 ├── AI 助手 (与 AI 对话 + 对话历史) ├── 记账本 (消费记录 + 账单导入) └── 个人中心 (设置 + 数据管理)

这棵树看起来很简单，但它背后对应的是 10 张数据库表：

模块	数据库表	说明
文本笔记	`note_text`	标题、正文、分类、标签、字数
语音笔记	`note_voice`	转写文本、时长、音频路径
图片笔记	`note_photo`	图片 JSON、备注、OCR 文本
手绘笔记	`note_drawing`	图片路径
AI 整理	`note_ai_organized`	标题、内容、摘要、标签、待办、版本
AI 对话	`note_ai_chat_message`	角色、类型、内容、媒体 URL
待办事项	`note_todo`	状态、优先级、截止日期、提醒、重复规则
记账	`note_account`	类型、金额、分类、支付方式
礼单	`note_gift`	方向、人名、关系、场合、金额
用户设置	`note_user_setting`	通知、自动保存、流式回复开关

注意我砍掉了视频记录。需求文档里原本规划了视频记录功能，但实际开发时我做了取舍：

视频文件存储成本太高
视频录制不是高频场景
UniApp 的视频组件在小程序端兼容性差

所以最终我只保留了 5 种笔记类型（文字、语音、图片、手绘、AI 整理）。砍功能比加功能更重要——这是独立开发者必须学会的克制。

除了笔记相关的 10 张表，还有 2 张重要的”基础设施”表：

note_base：聚合索引表，解决多表分页问题
note_view_history：浏览历史表，用于”最近看过”功能

加上 pig 框架自带的系统表，整个项目的数据库一共 20+ 张表。这个规模一个人扛下来，没有 AI 是不可想象的。

四、多元记录方式的设计哲学

这一节我想重点聊聊「多元记录」背后的设计思考，因为这是整个 App 的灵魂。

4.1 为什么是这 5 种记录方式？

我在需求文档里列了 5 种记录方式，但没说为什么是这 5 种。这里补上思考过程：

记录方式	适用场景	解决的痛点
文字	长想法、会议记录	标准记录方式，兜底方案
语音	走路、开车、不方便打字	手指不方便时的快速记录
图片	白板、书页、名片	文字描述不清的内容
手绘	草图、流程图、思维导图	文字和图片都表达不了的创意
AI 对话	模糊想法、需要梳理的思路	不知道怎么记，让 AI 帮你问出来

这 5 种方式覆盖了”输入效率”和”表达力”两个维度的不同象限：

输入效率高：语音、AI 对话（说几句就行）
输入效率低：手绘、文字（需要专注操作）
表达力强：手绘、图片（能表达复杂结构）
表达力弱：语音、文字（线性表达）

用户在不同场景下会自动选择最合适的方式。比如开会时用文字，走路时用语音，看到白板用图片，讨论方案时用手绘，思绪混乱时和 AI 聊聊。

4.2 多元记录背后的数据库设计

5 种记录方式，5 张表，怎么设计？

方案 A：单表继承

所有笔记存一张表，用 type 字段区分，用 JSON 字段存不同类型的特有数据。

优点：查询简单，分页容易

缺点：字段冗余严重，JSON 字段无法走索引

方案 B：每类型一张表（最终选择）

note_text、note_voice、note_photo、note_drawing、note_ai_organized 各自独立。

优点：字段清晰，每张表只存自己需要的数据

缺点：跨表查询困难，首页”最近 5 条笔记”需要 UNION ALL 5 张表

我最终选了方案 B，因为字段差异太大。语音有 duration 和 transcript，图片有 ocr_text 和 images，手绘只有 image_path。塞进一张表会有大量空字段。

但方案 B 的代价是多表分页噩梦。首页要展示”最近 5 条笔记”，不管什么类型，要按 update_time 倒序混合展示。5 张表 UNION ALL，分页性能会随着数据量增长急剧下降。这个问题的解决方案是 note_base 聚合索引表——每张子表增删改时，同步维护一张索引表，查询时只查这张表。

4.3 每种记录方式的独特字段

在需求文档里，我详细列出了每种记录方式的字段设计。这里挑几个关键的讲：

语音笔记 note_voice：

– transcript: 语音转写文本 – duration: 音频时长（秒） – audio_path: 音频文件路径

为什么 transcript 要单独存而不是放到 content 字段？因为转写文本是可编辑的，用户可能想修改 AI 转写的结果。存成独立字段，方便前端区分”原始转写”和”用户编辑后”的版本。

AI 整理 note_ai_organized：

– title: AI 生成的标题 – content: AI 整理后的内容 – summary: 摘要 – tags: 标签数组（JSON） – todos: 待办数组（JSON） – source_id: 原始笔记 ID – source_type: 原始笔记类型（text/voice/photo） – style: 整理风格（detail/summary/meeting/todo/study） – version: 版本号

这张表是整个项目最复杂的表。它要能表达”AI 把一条语音笔记整理成了结构化的标题 + 摘要 + 标签 + 待办”这个完整的过程。source_id 和 source_type 指向原始笔记，version 支持多次整理，用户可以对比不同风格的整理结果。

五、界面设计规范：简约但不简单

需求文档里有一整节是界面设计规范。我知道很多开发者会跳过这一节，但我觉得它很重要——因为 App 的第一印象决定了用户会不会继续用下去。

5.1 配色方案：紫蓝为主，语义色辅助

主色我选了 #4F46E5（紫蓝色），这是一个介于蓝和紫之间的颜色，既有蓝色的专业感，又有紫色的创意感，符合”星尘笔记”的调性。

主色

#4F46E5

主要按钮、强调

成功色

#10B981

收入、成功状态

警示色

#F59E0B

支出、警告

强调色

#EC4899

收藏、特殊

5.2 关键界面布局：首页 ASCII 原型

需求文档里我画了首页的 ASCII 原型图：

┌──────┐ │ 状态栏 │

├──────────────┤

│ LOGO 搜索框通知图标 │ Header (56px)

├─────────┤ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ 今日 │ │ 笔记 │ │ 记账 │ │ 快捷统计卡片 │ │ 3条 │ │ 12条 │ │ ¥250 │ │ │ └─────┘ └─────┘ └─────┘ │ ├──────────┤ │ 快速记录 │ │

┌────┐ │ │ │ 点击开始记录你的灵感 │

│ 快速记录入口 │

└─────────────────┘ │

├──────────┤ │

今日灵感 │

│ ┌───────┐ │ │

│ • 想到一个新的App界面… │ │ │

│ • 下午要开会讨论… │

│ 最近记录预览 │

│ • 周末去图书馆… │

│ ├──────────────┤

│ TabBar (固定底部)

└────────────┘

很多人可能觉得画 ASCII 原型很 Low，但它的好处是：能直接写在 Markdown 里、AI 能读懂、修改快。这个原型后来在首页里被实现了，最终的 UI 比原型精致很多，但骨架完全一致。

六、技术选型：让 AI 帮我做完苦力活

需求文档里没有专门写技术选型，但我在动手前已经在脑子里定了方案。这里也简单分享一下：

技术栈	选型	为什么
前端	UniApp + Vue 3	一套代码多端发布，可上小程序
后端	Spring Boot 4 + pig 框架	pig 自带权限、字典、代码生成器
AI	Spring AI 2.0	原生支持流式响应、Function Call
数据库	MySQL 8 + Redis	pig 默认方案，AI 也能直接生成 DDL
AI 助手	Trae IDE	上下文感知强，能读懂整个工程

这套组合最大的好处是：AI 友好。

Spring Boot 是 AI 训练数据里最多的后端框架，Trae 几乎能自动生成 80% 的 CRUD 代码
pig 框架的代码生成器配合 AI，一个模块从建表到接口上线只要半小时
UniApp 的 Vue 3 语法 AI 也很熟悉，写页面组件几乎不用查文档
Spring AI 2.0 让我不需要手写 SSE、不需要拼接 Prompt 模板，直接用注解就能调 LLM

这套选型的具体取舍，这里只说一句：选 AI 能帮上忙的技术栈，比选最新的技术栈更重要。

七、写在最后：文档是写给 AI 看的

这篇我想用一句话收尾：

在 AI 编程时代，需求文档不是写给人看的，是写给 AI 看的。

这不是说人不用看——人当然要看，但人是”评审者”，AI 是”执行者”。文档要让 AI 能解析出字段、能生成代码、能跑通流程。

这份需求文档我写了整整两天，800 多行。写完之后，把它丢给 Trae，对它说”按这份文档生成 note_text 表的 DDL 和对应的 Entity / Mapper / Service / Controller”，10 分钟后，一个完整的笔记文本模块就跑起来了。

如果我没有写文档，直接对 AI 说”帮我做一个笔记 App”，可能三个月后还在和它来回掰扯”笔记到底有几种类型”。

磨刀不误砍柴工，这句话在 AI 时代依然成立。

下一篇预告

下一篇我会写：《02 – 工欲善其事必先利其器：AI 时代的开发工具链搭建》。

我会聊一聊：

为什么我选了 Trae 而不是 Cursor / Copilot
本地开发环境的搭建（JDK 21、Node 20、MySQL 8、Redis）
如何用 AI 配置 pig 框架的微服务环境
UniApp + HBuilderX 的多端调试技巧
Git 仓库的分支策略（一个人也要规范）

如果你对 AI 编程、独立开发、UniApp、Spring Boot 这些话题感兴趣，欢迎关注我的公众号，一起见证这款 App 从 0 到上架的全过程。

互动一下

你做独立开发时，会写需求文档吗？还是直接开干？欢迎在评论区聊聊你的做法。

#AI编程#独立开发#需求文档#星尘笔记#UniApp