wangdl/startup-plan
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: 个人开发者创业 v0.1 阶段路线图

Browse Source
This commit is contained in:
WangDL 2026-05-04 14:16:50 +08:00
commit b070efdfb7
7 changed files with 2648 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
.claude/
.claude*

46
0-项目总纲/项目总纲.md Normal file
View File

@ -0,0 +1,46 @@
# 项目总纲
## 当前版本
个人开发者创业计划 v0.1
## 当前目标
先不做完整产品，也不做完整公司规划。
当前只做三件事：
1. 确定第一个学习方向是否值得做。
2. 做出一个 14 天验证型 Demo。
3. 用 Demo 找到第一批真实反馈。
## 产品长期方向
AI 驱动的系统化学习产品：
- 知识库
- 笔记
- AI 学习教练
- 复习计划
## 当前候选方向
1. 公考申论 AI 学习教练
2. AI 工具学习知识库
3. 程序员 / 前端面试学习助手
## 当前原则
- 不做完整平台
- 不做泛学习大而全产品
- 不做 Android
- 不注册公司
- 不接微信/支付宝支付
- 不做复杂后端
- 不做完整知识库
- 先做 Demo 和验证
## 相关文档
- [方向验证](../1-方向验证/方向验证.md)
- [Demo与MVP](../2-Demo与MVP/Demo与MVP.md)

103
1-方向验证/方向验证.md Normal file
View File

@ -0,0 +1,103 @@
# 方向验证
## 当前问题
现在不能直接确定做公考申论，因为创始人对该领域不够熟悉。
当前需要验证：
1. 公考申论用户是否真的需要 AI 学习工具。
2. 公考用户里 iPhone 用户是否足够。
3. 用户是否愿意为 AI 批改、学习计划、复习提醒付费。
4. 这个方向的内容是否能合法整理。
5. 创始人是否愿意持续研究这个领域。
## 候选方向
### 方向 A：公考申论 AI 学习教练
**优点：**
- 用户目标强
- 付费意愿可能较高
- 申论适合 AI 分析
- 小红书/B站有获客可能
**风险：**
- 创始人不熟悉领域
- 资料版权风险
- 竞品强
- 不确定 iPhone 用户比例
### 方向 B：AI 工具学习知识库
**优点：**
- 创始人熟悉
- 内容更容易原创
- AI 价值明显
- 版权风险较低
**风险：**
- 用户付费意愿可能不如考试类
- 泛学习容易散
### 方向 C：程序员 / 前端面试学习助手
**优点：**
- 创始人有前端背景
- 用户目标较明确
- 可以结合 AI 面试反馈
**风险：**
- 市场竞争强
- 付费意愿需要验证
## 当前验证方式
不主动高压私聊用户。
先采用低社交压力验证：
1. 看评论区
2. 整理用户痛点
3. 发小红书/B站内容
4. 做等待名单
5. 只联系主动感兴趣的人
## 相关文档
- [项目总纲](../0-项目总纲/项目总纲.md)
- [Demo与MVP](../2-Demo与MVP/Demo与MVP.md)
## 第一轮验证目标
v0.1 阶段不追求大规模用户，只做低成本方向验证。
第一轮最低目标：
- 收集 50 条真实用户痛点原话
- 发布 3 条小红书 / B站内容
- 收集 10 份问卷或等待名单
- 找到 3 个愿意内测的人
- 至少确认 1 个方向存在真实需求
## 方向选择标准
某个方向满足以下条件，可以进入 Demo 开发：
1. 用户痛点集中，不是很分散。
2. 有用户主动评论、私信或填写等待名单。
3. 至少有 3 个用户愿意试用。
4. 用户过去为类似问题花过钱。
5. 创始人愿意持续研究这个方向至少 3 个月。
6. 内容可以合法整理，不严重依赖侵权资料。
## 暂缓或放弃标准
如果某个方向出现以下情况，暂缓：
1. 内容发布后几乎没有反馈。
2. 用户只是觉得有趣，但没有强需求。
3. 用户不愿意留下联系方式。
4. 内容生产成本过高。
5. 版权风险太大。
6. 创始人明显不想继续研究该领域。

721
2-Demo与MVP/Demo与MVP.md Normal file
View File

@ -0,0 +1,721 @@
---
version: v0.1
status: draft
updated: 2026-05-03
---
# Demo 与 MVP
## 1. 产品定位
> 一个具备长期架构基础的最小可用学习产品雏形，不是一次性演示，也不是完整商业化产品。
第一版只验证一个核心问题：
> AI 驱动的知识库学习系统，是否能帮助用户从"被动看资料"变成"主动学习、反馈、复习和迭代"。
---
## 2. 核心原则
### 2.1 功能少，但闭环完整
第一版必须跑通完整学习闭环：
```text
注册 / 登录
↓
选择学习方向
↓
进入学习路径
↓
阅读知识内容
↓
主动回忆 / 写笔记 / 写答案
↓
AI 分析
↓
生成学习状态
↓
给出复习和下一步建议
↓
进入下一次学习
```
### 2.2 架构要可迭代
第一版需要提前考虑：
- 用户系统
- 学习记录
- 知识库结构
- AI 分析结果结构
- 用户学习画像
- 多语言文案
- 后续订阅权益
- 后续 iPad / Mac / Android 扩展
### 2.3 AI 是核心
第一版 AI 要承担三个核心职责：
1. 分析用户输入
2. 判断用户当前学习状态
3. 给出下一步学习建议
---
## 3. 第一版目标用户
当前候选方向：
1. 公考申论 AI 学习教练
2. AI 工具学习知识库
3. 程序员 / 前端面试学习助手
第一版用户画像：
- 有明确学习目标的人
- 愿意使用 AI 辅助学习的人
- 不满足于单纯看资料的人
- 希望系统帮自己制定学习路径的人
- 愿意通过写笔记、回答问题、主动回忆来学习的人
---
## 4. 第一版产品形态
```text
iPhone App
+
官网基础页面
+
最小后端
+
AI API
```
第一版暂不做：
- Android
- Web 学习端
- iPad 完整适配
- Mac 完整版
- B 端后台
- 内容创作者后台
- 社群系统
- 支付系统
---
## 5. 账号体系
### 5.1 第一版需要登录
原因：
1. 学习记录需要跟随用户
2. AI 分析结果需要沉淀到用户画像
3. 复习计划需要长期保存
4. 未来订阅权益需要绑定用户
5. 后续多设备同步需要统一用户身份
### 5.2 第一版登录方式
```text
Sign in with Apple
```
暂不做：微信登录、手机号登录、邮箱密码登录、Google 登录、复杂账号安全系统。
### 5.3 用户身份模型
```text
User
├── id
├── appleUserId
├── displayName
├── email
├── preferredLanguage
├── createdAt
├── lastLoginAt
└── status
```
### 5.4 账号边界
第一版账号只解决：登录、识别用户、保存学习记录、保存 AI 分析结果、保存基础偏好。
暂不做：好友系统、用户主页、头像上传、账号注销自动化、多登录方式绑定、复杂权限系统。
---
## 6. 多语言基础
### 6.1 需要多语言结构
原因：
1. Apple 生态用户可能存在中英文环境
2. 后续做海外市场不希望大量重构
3. UI 文案、系统提示、AI Prompt 都需要可维护
4. 多语言越晚做，返工成本越高
### 6.2 第一版多语言范围
- App UI 文案支持多语言结构
- 代码层面使用本地化资源
- 默认语言为中文
- 预留英文文案位置
### 6.3 支持语言
```text
默认：简体中文
预留：英文
```
---
## 7. 知识库设计
### 7.1 知识库不是资料堆积
第一版知识库是结构化学习路径，包含：
```text
KnowledgeBase
├── 学习方向
├── 学习路径
├── 模块
├── 小节
├── 学习任务
├── 主动回忆问题
├── 示例内容
└── 复习节点
```
### 7.2 第一版知识库结构
```text
知识库
└── 学习路径
└── 模块
└── 小节
├── 正文内容
├── 学习目标
├── 重点概念
├── 主动回忆问题
├── 练习输入
└── AI 分析规则
```
### 7.3 第一版内容范围
第一版只做一个小路径，例如：
- "申论小白 7 天入门路径"
- 或 "AI 工具入门 7 天路径"
### 7.4 知识库最小数据模型
```text
KnowledgeBase
├── id
├── title
├── description
├── language
├── targetUser
├── createdAt
└── updatedAt
LearningPath
├── id
├── knowledgeBaseId
├── title
├── description
├── estimatedDays
└── order
Lesson
├── id
├── pathId
├── title
├── content
├── objectives
├── keyPoints
├── recallQuestions
├── practicePrompt
├── order
└── estimatedMinutes
```
---
## 8. 学习闭环设计
### 8.1 核心闭环
```text
用户选择学习路径
↓
系统展示今日任务
↓
用户阅读内容
↓
系统提出主动回忆问题
↓
用户输入回答 / 笔记
↓
AI 分析用户输入
↓
系统生成学习状态
↓
系统给出复习建议
```
### 8.2 主动回忆
用户不能只是看资料。系统需要引导用户：
- 用自己的话复述
- 回答关键问题
- 写出理解
- 写出答案
- 暴露自己的薄弱点
### 8.3 AI 分析维度
```text
理解程度
要点覆盖
逻辑结构
表达清晰度
错误理解
遗漏内容
下一步建议
```
---
## 9. AI 学习状态模型
### 9.1 为什么需要
如果 AI 不能准确判断用户状态，后续学习计划、复习建议、个性化推荐都会失效。
第一版不追求完全准确，只追求：能用结构化方式记录用户当前学习情况，并支持后续迭代。
### 9.2 第一版学习状态维度
```text
理解程度
记忆程度
表达能力
完成情况
薄弱点
复习需求
学习稳定性
```
### 9.3 用户学习画像
```text
UserLearningProfile
├── userId
├── currentKnowledgeBaseId
├── currentPathId
├── currentLessonId
├── overallLevel
├── weakPoints
├── strengths
├── recentMistakes
├── reviewQueue
├── learningStreak
└── updatedAt
```
### 9.4 单次学习记录
```text
LearningSession
├── id
├── userId
├── lessonId
├── startedAt
├── endedAt
├── userInput
├── aiAnalysis
├── masteryScore
├── weakPoints
├── nextSuggestion
└── reviewAt
```
### 9.5 掌握度评分（0-5分）
```text
0 = 没有作答 / 无法判断
1 = 基本没理解
2 = 理解较弱
3 = 基本理解
4 = 理解较好
5 = 掌握很好
```
注意：这不是考试分数，只是产品内部用于安排复习和学习建议的参考值。
### 9.6 AI 输出结构
```json
{
"masteryScore": 3,
"understandingLevel": "基本理解",
"summary": "用户能说出核心意思，但要点不够完整。",
"strengths": ["能识别主要问题", "表达比较清楚"],
"weakPoints": ["遗漏关键要点", "逻辑层次不够清晰"],
"suggestions": ["补充材料中的第二个要点", "回答时先概括问题，再展开原因"],
"reviewNeeded": true,
"nextAction": "建议明天复习本节，并重新回答主动回忆问题。"
}
```
---
## 10. AI 对话页面
### 10.1 需要 AI 对话页
原因：
1. 用户会天然期待 AI 产品能提问
2. 知识库学习中，用户经常会有即时疑问
3. 对话页可以提升产品感知价值
4. 对话数据可以反向帮助判断用户困惑点
### 10.2 对话页定位
```text
围绕当前知识库和当前学习内容的学习助手
```
它应该回答：
- 这节内容是什么意思？
- 我这个回答哪里不对？
- 这个概念能不能举例？
- 我应该怎么记？
- 这个知识点和前面有什么关系？
- 我下一步该怎么学？
### 10.3 对话页边界
```text
只能围绕当前知识库
只能围绕学习主题
不能承诺考试结果
不能生成违规内容
不能替代专业老师
```
### 10.4 推荐快捷问题
```text
帮我解释这一节
用更简单的话讲
给我举个例子
我哪里理解错了
帮我总结重点
生成一个复习问题
```
---
## 11. 页面结构
### 11.1 第一版页面列表
1. 启动页 / 欢迎页
2. 登录页
3. 语言与基础偏好页
4. 学习方向选择页
5. 学习路径页
6. 今日学习任务页
7. 内容阅读页
8. 主动回忆 / 笔记输入页
9. AI 分析结果页
10. AI 对话页
11. 复习计划页
12. 学习进度页
13. 设置页
14. 反馈页
### 11.2 页面优先级
**P0 必须做：**
- 登录页
- 学习方向选择页
- 学习路径页
- 今日学习任务页
- 内容阅读页
- 主动回忆 / 笔记输入页
- AI 分析结果页
- AI 对话页
- 复习计划页
**P1 建议做：**
- 学习进度页
- 设置页
- 反馈页
**P2 可以延后：**
- 个人主页
- 成就系统
- 统计图表
- 多知识库市场
- 复杂搜索
- 社群入口
### 11.3 底部 Tab 设计
```text
学习 | 知识库 | AI助手 | 我的
```
- 学习：今日任务、复习计划
- 知识库：学习路径和内容
- AI 助手：围绕知识库的对话
- 我的：学习进度、设置、反馈
---
## 12. UI 风格
### 12.1 设计关键词
```text
安静、清晰、克制、学习感、低干扰、Apple原生感、卡片式结构、适合长时间阅读
```
### 12.2 设计原则
- 不做花哨视觉
- 不做复杂动画
- 不做社交信息流
- 不做游戏化过重设计
- 优先保证阅读体验
- 优先保证学习任务清晰
- 优先保证 AI 分析结果可理解
---
## 13. MVP 功能清单
### P0 必须完成
1. Sign in with Apple 登录
2. 多语言结构
3. 一个学习方向
4. 一个 7 天学习路径
5. 内容阅读
6. 主动回忆 / 笔记输入
7. AI 分析
8. 用户学习状态记录
9. 复习建议
10. AI 对话页面
11. 反馈入口
### P1 尽量完成
1. 学习进度页
2. 设置页
3. 简单本地缓存
4. 等待名单 / 内测入口
5. 基础错误提示
6. 基础 AI 调用日志
### P2 暂时不做
1. 支付
2. 完整订阅权益
3. 完整题库
4. 完整知识库市场
5. 社群
6. 排行榜
7. 成就系统
8. 文件上传
9. 复杂搜索
10. 多端同步
---
## 14. 后端需求
### 第一版需要最小后端
原因：
1. 不能把 AI API Key 放在客户端
2. 需要保存用户学习状态
3. 需要保存 AI 分析结果
4. 需要收集反馈
5. 后续订阅权益需要后端基础
### 第一版后端能力
```text
用户身份记录
AI 请求代理
学习记录保存
AI 分析结果保存
反馈提交
等待名单
基础日志
```
### 第一版不做的后端能力
```text
复杂权限系统
管理后台
内容管理系统
支付系统
订阅校验
多端同步
复杂推荐系统
高并发架构
```
---
## 15. 核心实体
```text
User
KnowledgeBase
LearningPath
Lesson
LearningSession
AIAnalysis
ReviewTask
Feedback
```
### ReviewTask
```text
ReviewTask
├── id
├── userId
├── lessonId
├── sourceSessionId
├── reviewType
├── scheduledAt
├── completedAt
└── status
```
### AIAnalysis
```text
AIAnalysis
├── id
├── userId
├── sessionId
├── inputText
├── outputJson
├── masteryScore
├── weakPoints
├── suggestions
├── modelName
├── createdAt
└── costEstimate
```
---
## 16. AI Prompt 设计原则
### Prompt 目标
AI Prompt 不是为了生成漂亮文字，而是为了稳定产出结构化学习判断。
Prompt 需要让 AI 输出：
- 用户理解程度
- 用户薄弱点
- 用户表达问题
- 下一步建议
- 是否需要复习
- 复习时间建议
### 输出格式
第一版要求 AI 尽量输出 JSON。如果 JSON 不稳定，后端需要做容错处理。
### Prompt 边界
AI 不允许：
- 承诺考试结果
- 给出绝对权威评分
- 编造不存在的资料来源
- 输出和学习主题无关的内容
- 引导用户作弊
---
## 17. 成功标准
### 产品可用标准
第一版必须做到：
- 用户能登录
- 用户能选择学习路径
- 用户能完成一节学习
- 用户能输入内容
- AI 能返回分析
- 系统能生成复习建议
- 用户知道下一步该干什么
### 验证成功标准
第一轮验证目标：
- 至少 10 个用户愿意试用
- 至少 3 个用户完整走完学习闭环
- 至少 3 条有效反馈
- 至少 1 个用户表示愿意继续用
- 至少 1 个用户表示未来愿意付费
---
## 18. 当前不做清单
- 完整公考题库
- 完整课程体系
- 完整知识库市场
- 用户上传资料
- 文件解析
- 复杂笔记编辑器
- 社交系统
- 打卡排行榜
- 支付订阅
- Android
- Web 学习端
- Mac 正式版
- B 端后台
- 内容创作者后台
---
## 19. 当前最大风险
1. 产品范围继续膨胀
2. AI 判断用户状态不稳定
3. 用户不愿意主动输入内容
4. 内容质量不足以支撑学习
5. 用户认为 AI 分析不专业
6. 方向还没验证就投入过多开发
7. 登录、多语言、架构设计增加早期开发成本
8. AI 对话页变成泛聊天，稀释产品定位
---
## 20. 解决策略
1. 登录只做 Apple 登录
2. 多语言只做架构，不做完整翻译运营
3. 知识库只做一个 7 天路径
4. AI 对话只围绕当前知识库
5. 学习状态模型先做基础版本
6. 后端只做最小 API 和数据保存
7. 不接支付
8. 不做完整题库
9. 不做完整知识库平台
10. 14 天内必须产出可展示版本

958
3-官网与技术基础/官网与技术基础.md Normal file
View File

@ -0,0 +1,958 @@
---
version: v0.1
status: draft
updated: 2026-05-03
---
# 官网与技术基础
## 1. 当前技术目标
v0.1 阶段的技术目标不是做完整大系统，而是搭建一个可持续迭代的最小技术底座。
**当前需要支持：**
1. iPhone App Demo / MVP
2. Sign in with Apple 登录
3. AI API 调用
4. 用户学习记录保存
5. AI 分析结果保存
6. 学习状态模型
7. 官网基础页面
8. 等待名单和反馈入口
9. 后续可扩展到 TestFlight、App Store、iPad、Mac、Android
**当前不追求：**
- 高并发
- 完整后台管理系统
- 完整支付系统
- 完整内容管理系统
- 复杂微服务
- 复杂云原生架构
- 多端同步
- 企业级权限系统
---
## 2. 技术总原则
### 2.1 用熟悉技术优先
当前是个人开发者阶段，技术选型优先考虑：
- 自己能理解
- AI Agent 容易生成
- 出问题容易排查
- 部署简单
- 成本低
- 后续能扩展
### 2.2 架构要清晰，但不能过度设计
原则：
```text
代码结构清晰 > 技术炫技
可维护 > 复杂
能上线 > 完美
能验证 > 大而全
```
### 2.3 前后端职责分离
| 端 | 职责 |
|---|------|
| iOS 客户端 | 页面展示、用户交互、本地状态、登录入口、学习流程体验 |
| 后端 | 用户身份记录、AI API 代理、学习记录保存、AI 分析结果保存、学习画像更新、反馈收集、等待名单 |
| AI 模型 | 分析用户输入、生成学习反馈、识别薄弱点、生成复习建议、辅助学习对话 |
| 官网 | 产品介绍、SEO、隐私政策、用户协议、支持页面、等待名单、TestFlight 招募、未来 Mac DMG 下载 |
---
## 3. 当前推荐最终选型
```text
iOS：SwiftUI
iOS 架构：MVVM + Service + Repository
设计规范：Apple Human Interface Guidelines
UI 风格：Apple 原生感、安静、克制、学习感
动效策略：轻量、有意义、服务学习体验
官网：Astro
官网域名：longde.cloud
后端：NestJS + TypeScript
数据库：MySQL
缓存：Redis，先预留，可延后
AI：Provider 抽象 + 一个真实模型 + MockProvider
AI 记忆：结构化学习画像，不急着做复杂 Agent Memory
部署：现有 4 核 4G 轻量云
反向代理：Nginx
进程/容器：Docker Compose 或 PM2
```
当前不买新服务器，不做复杂架构，先把最小闭环跑通。
---
## 4. 整体技术架构
```text
iPhone App
├── SwiftUI
├── Sign in with Apple
├── 本地缓存
└── API Client
↓
后端 API
├── 用户模块
├── 学习记录模块
├── AI 代理模块
├── 学习画像模块
├── 反馈模块
└── 等待名单模块
↓
数据库
├── MySQL
└── Redis（可选）
↓
AI 服务
├── MiniMax / DeepSeek / 通义 / OpenAI / Claude / Gemini
└── 后续可替换
↓
官网
├── Astro
├── SEO 页面
├── 隐私政策
├── 用户协议
└── 等待名单
```
---
## 5. iOS 客户端技术选型
### 5.1 技术选择
```text
Swift
SwiftUI
Xcode
MVVM
Service 层
Repository 层
```
**选择原因：**
1. 当前第一阶段只做 Apple 平台
2. SwiftUI 适合快速做原型和 MVP
3. 原生体验更适合长期做 iPhone、iPad、Mac
4. Apple 生态的动画、交互、系统组件体验好
5. 后续可以逐步学习和沉淀原生开发能力
### 5.2 SwiftUI 学习策略
学习顺序：
1. Swift 基础语法
2. SwiftUI 页面布局
3. NavigationStack 页面跳转
4. TabView 底部导航
5. Form / List / ScrollView
6. ObservableObject / State / Binding
7. 网络请求
8. 本地存储
9. Sign in with Apple
10. 简单动画和转场
第一版 UI 优先使用系统组件，尽量做出 Apple 原生感。
### 5.3 iOS 目录结构
```text
AIStudyApp/
├── App/
│ ├── AIStudyApp.swift
│ ├── AppConfig.swift
│ └── AppRouter.swift
│
├── Core/
│ ├── Network/
│ │ ├── APIClient.swift
│ │ ├── APIEndpoint.swift
│ │ └── APIError.swift
│ │
│ ├── Auth/
│ │ ├── AppleSignInService.swift
│ │ └── AuthSession.swift
│ │
│ ├── Storage/
│ │ ├── LocalStorage.swift
│ │ └── KeychainService.swift
│ │
│ ├── Localization/
│ │ └── LocalizationManager.swift
│ │
│ └── DesignSystem/
│ ├── AppColors.swift
│ ├── AppTypography.swift
│ ├── AppSpacing.swift
│ └── Components/
│
├── Features/
│ ├── Onboarding/
│ │ ├── Views/
│ │ ├── ViewModels/
│ │ └── Models/
│ │
│ ├── Auth/
│ │ ├── Views/
│ │ └── ViewModels/
│ │
│ ├── Learning/
│ │ ├── Views/
│ │ ├── ViewModels/
│ │ └── Models/
│ │
│ ├── KnowledgeBase/
│ │ ├── Views/
│ │ ├── ViewModels/
│ │ └── Models/
│ │
│ ├── AIAssistant/
│ │ ├── Views/
│ │ ├── ViewModels/
│ │ └── Models/
│ │
│ ├── Review/
│ │ ├── Views/
│ │ ├── ViewModels/
│ │ └── Models/
│ │
│ └── Profile/
│ ├── Views/
│ ├── ViewModels/
│ └── Models/
│
├── Shared/
│ ├── Components/
│ ├── Extensions/
│ ├── Utils/
│ └── Constants/
│
└── Resources/
├── Localizable.xcstrings
├── Assets.xcassets
└── PreviewData/
```
### 5.4 iOS 模块说明
| 模块 | 说明 |
|------|------|
| App | 负责 App 入口、全局配置、路由 |
| Core | 负责底层能力：网络请求、登录、本地存储、Keychain、多语言、设计系统 |
| Features | 按业务模块拆分：Onboarding、Auth、Learning、KnowledgeBase、AIAssistant、Review、Profile |
| Shared | 存放通用组件、工具函数、扩展 |
| Resources | 存放资源文件、多语言、图片、测试数据 |
### 5.5 iOS 第一版不做
- 复杂动画系统
- 自定义复杂控件
- iPad 专门布局
- Mac Catalyst
- Watch App
- Widget
- 离线完整知识库
- 复杂搜索
- 文件导入
- 推送通知
- 支付订阅
---
## 6. Apple 设计规范与动效原则
### 6.1 设计基准
本产品第一阶段优先做 Apple 平台，因此 UI/UX 设计需要参考 Apple Human Interface Guidelines。
第一版设计目标不是做复杂视觉，而是做出：
- 原生感
- 安静感
- 学习感
- 清晰的层级
- 流畅的交互
- 适度高级感
- 符合 Apple 用户习惯的体验
### 6.2 HIG 设计原则
1. **内容优先** — 学习内容、任务和 AI 分析结果应该是页面中心
2. **层级清晰** — 用户应该很清楚当前在哪、今天要做什么、下一步做什么
3. **交互克制** — 不做过多按钮，不堆功能，不制造干扰
4. **系统一致** — 尽量使用 Apple 原生组件、系统字体、系统导航、系统交互
5. **可访问性** — 字体大小、颜色对比、动态效果都要考虑不同用户
6. **动效有意义** — 动效用于反馈、状态变化、页面过渡和学习进度表达，不做无意义炫技
### 6.3 动效优先级
**P0 必须做：**
- 页面进入 / 返回的自然过渡
- 按钮点击反馈
- 加载状态
- AI 分析中状态
- 学习完成反馈
**P1 建议做：**
- 今日任务卡片动效
- 进度条更新动效
- AI 分析结果分块出现
- 复习建议卡片出现
**P2 延后做：**
- 启动页品牌动画
- 高级图表动效
- 大范围转场动画
- 自定义复杂动画
### 6.4 SwiftUI 动效实现策略
第一版优先使用 SwiftUI 原生能力：
```text
withAnimation
transition
opacity
scaleEffect
ProgressView
```
谨慎使用：
```text
matchedGeometryEffect
PhaseAnimator
SymbolEffect
```
第一版不追求复杂自定义动画系统。目标是让 App 看起来顺滑、有质感，而不是炫技。
---
## 7. SwiftUI + AI Agent 开发策略
### 7.1 基本判断
创始人当前没有 SwiftUI 实战经验，但可以借助 AI Agent 完成开发。
这不影响第一版使用 SwiftUI。原因：
1. SwiftUI 适合快速构建 Apple 原生界面
2. AI Agent 对 SwiftUI 页面、组件、ViewModel 的生成能力较强
3. 只要目录结构清晰、任务拆分明确，AI 可以辅助完成大量开发
4. 创始人需要掌握的是架构、产品逻辑、代码审查和调试能力
### 7.2 AI 开发原则
使用 AI 开发 SwiftUI 时，必须遵守：
1. 每次只让 AI 修改一个模块
2. 每次生成前先说明目录和目标文件
3. 不允许 AI 随意改全局架构
4. 不允许 AI 把所有代码写进一个 View
5. 页面、ViewModel、Model、Service 分开
6. 复杂逻辑放到 Service，不堆在 View 里
7. UI 组件尽量复用
8. 每完成一个页面就真机预览或模拟器运行
### 7.3 推荐开发顺序
1. 创建项目骨架
2. 建立 DesignSystem
3. 建立 Tab 结构
4. 建立 Onboarding 页面
5. 建立 Apple 登录页面
6. 建立学习路径页面
7. 建立今日任务页面
8. 建立内容阅读页面
9. 建立主动回忆输入页面
10. 建立 AI 分析结果页面
11. 建立 AI 助手页面
12. 建立我的 / 设置 / 反馈页面
### 7.4 AI 生成代码时的提示原则
每次让 AI 写代码时，要明确：
- 当前模块
- 目标文件
- 不要修改哪些文件
- 使用 SwiftUI
- 使用 MVVM
- 使用已有 DesignSystem
- 不写死颜色和字体
- 支持多语言 key
- 页面要支持深色模式
- 页面要适配不同 iPhone 尺寸
### 7.5 第一版代码质量底线
底线：
- 不把业务逻辑写在 View 里
- 不把 API Key 写在客户端
- 不写大量重复 UI
- 不写死所有文案
- 不把 AI Prompt 写死在 iOS 端
- 不让一个文件超过过大规模
- 不做无法维护的一次性 Demo
---
## 8. 官网技术选型
### 8.1 官网定位
官网不是 Web 学习系统，而是产品基础设施。
官网第一阶段承担：
- 产品介绍
- SEO 收录
- 等待名单
- TestFlight 招募
- 隐私政策
- 用户协议
- 支持页面
- 更新日志
- 未来 Mac DMG 下载
### 8.2 框架选择
| 框架 | 优点 | 缺点 |
|------|------|------|
| Astro | 适合内容型网站、SEO 友好、静态页面性能好、适合官网博客文档、比 Nuxt/Next 更轻 | 未来做 Web App 需要另起项目 |
| Nuxt | Vue 生态、适合 SSR/SSG | 对纯官网来说稍重 |
| Next.js | React 生态强、SSR/SSG 成熟 | 对当前阶段偏重 |
| VitePress | 文档站很快 | 视觉自由度不如 Astro |
**推荐：Astro**
### 8.3 官网页面结构
```text
website/
├── src/
│ ├── pages/
│ │ ├── index.astro
│ │ ├── privacy.astro
│ │ ├── terms.astro
│ │ ├── support.astro
│ │ ├── waitlist.astro
│ │ ├── download.astro
│ │ └── changelog.astro
│ │
│ ├── layouts/
│ │ └── BaseLayout.astro
│ │
│ ├── components/
│ │ ├── Hero.astro
│ │ ├── FeatureCard.astro
│ │ ├── CTA.astro
│ │ └── Footer.astro
│ │
│ ├── content/
│ │ └── posts/
│ │
│ └── styles/
│ └── global.css
│
├── public/
│ ├── images/
│ └── favicon.svg
│
└── package.json
```
### 8.4 SEO 规划
**第一版 SEO 重点：**
- 首页标题、描述、关键词
- Open Graph 分享图
- sitemap.xml
- robots.txt
- 清晰 URL 结构
- 更新日志内容
- 长尾关键词页面
**当前不做：**
- 复杂 SEO 工具链
- 大量采集文章
- 自动生成垃圾内容
- 过度关键词堆砌
---
## 9. 后端技术选型
### 9.1 是否需要后端
v0.1 需要最小后端，原因：
1. AI API Key 不能放在 iOS 客户端
2. 用户登录后需要保存用户身份
3. 学习记录需要保存
4. AI 分析结果需要保存
5. 学习状态模型需要后端维护
6. 等待名单和反馈需要收集
7. 后续订阅权益需要后端基础
### 9.2 技术对比
| 技术 | 优点 | 缺点 |
|------|------|------|
| NestJS | 模块清晰、适合长期、TypeScript 生态好、AI Agent 容易按模块生成代码 | 学习成本稍高 |
| Express | 简单、学习成本低、快速启动 | 大项目容易混乱、AI Agent 写多了容易堆代码 |
| FastAPI | Python 生态适合 AI、写 API 很快、后续接 AI/RAG 方便 | 两个语言栈分散注意力 |
| Spring Boot | 企业级成熟 | 太重、不擅长 |
**推荐：Node.js + NestJS + TypeScript**
### 9.3 后端目录结构
```text
server/
├── src/
│ ├── main.ts
│ ├── app.module.ts
│ │
│ ├── common/
│ │ ├── filters/
│ │ ├── guards/
│ │ ├── interceptors/
│ │ ├── decorators/
│ │ └── utils/
│ │
│ ├── config/
│ │ ├── app.config.ts
│ │ ├── database.config.ts
│ │ └── ai.config.ts
│ │
│ ├── modules/
│ │ ├── auth/
│ │ ├── users/
│ │ ├── knowledge/
│ │ ├── learning/
│ │ ├── ai/
│ │ │ ├── prompts/
│ │ │ └── providers/
│ │ ├── review/
│ │ ├── feedback/
│ │ └── waitlist/
│ │
│ └── database/
│ ├── migrations/
│ └── seeds/
│
├── .env
├── package.json
└── docker-compose.yml
```
### 9.4 后端第一版模块
**P0 模块：**
- Auth 模块
- User 模块
- Knowledge 模块
- Learning 模块
- AI 模块
- Review 模块
- Feedback 模块
- Waitlist 模块
**P1 模块：**
- Admin 简单管理
- Analytics 简单日志
- Subscription 订阅预留
**P2 暂不做：**
- 支付、完整后台、多租户、企业账号、复杂权限
---
## 10. 数据库设计
### 10.1 数据库选型
```text
v0.1：MySQL + Redis（预留）
后续：向量数据库（PostgreSQL pgvector / Milvus / Qdrant）
```
### 10.2 为什么用 MySQL
MySQL 适合保存结构化业务数据：
- 用户、登录信息
- 知识库、学习路径
- 学习记录、AI 分析结果
- 复习任务、反馈、等待名单
### 10.3 为什么用 Redis
Redis 第一版可以先不急着重度使用，但可以预留：
- 缓存
- 限流
- AI 请求频控
- 短期会话
- 验证码（未来如果有）
- 队列（后续如果需要）
### 10.4 是否需要向量数据库
**第一版暂不急着上向量数据库。**
原因：
1. 第一版知识库内容很小
2. 可以先用结构化课程上下文传给 AI
3. RAG 系统会增加复杂度
4. 当前重点是验证学习闭环，而不是做大规模知识检索
**后续再考虑：** PostgreSQL + pgvector、Qdrant、Milvus
---
## 11. AI 长期记忆与知识库能力
### 11.1 名词澄清
| 概念 | 说明 |
|------|------|
| 长期记忆 Long-term Memory | 记录用户长期偏好、历史行为、薄弱点 |
| 学习画像 Learning Profile | 记录用户在具体学习领域里的状态 |
| 知识库 Knowledge Base | 产品提供的结构化内容（课程小节、知识点、示例、练习、复习问题） |
| RAG | 当知识库内容变多后，通过检索相关内容，再交给 AI 回答 |
| 向量数据库 | 用于存储文本向量，实现语义检索 |
| Agent Memory | Agent 为了长期协作，保存用户目标、偏好、任务历史等 |
### 11.2 v0.1 推荐做法
第一版不要急着做复杂 Agent Memory。
v0.1 只做：
```text
结构化学习画像
+
学习记录
+
AI 分析结果
+
复习队列
```
也就是：
- UserLearningProfile
- LearningSession
- AIAnalysis
- ReviewTask
### 11.3 AI 对话上下文
第一版 AI 对话上下文包括：
```text
当前用户
当前知识库
当前学习路径
当前小节
用户最近一次输入
最近一次 AI 分析
用户薄弱点
当前复习任务
```
暂不做全局长期聊天记忆。
---
## 12. AI 模型与 API 选型
### 12.1 模型选择原则
1. 中文能力好
2. 成本可控
3. API 稳定
4. 支持结构化输出
5. 速度可以接受
6. 容易接入
7. 可替换
### 12.2 候选模型
```text
MiniMax
DeepSeek
通义千问
OpenAI
Claude
Gemini
```
### 12.3 AI Provider 层设计
后端需要设计 AI Provider 层：
```text
AIService
├── MiniMaxProvider
├── DeepSeekProvider
├── OpenAIProvider
└── MockProvider
```
### 12.4 MockProvider
v0.1 强烈建议做一个 MockProvider。
作用：
- 没有 API Key 时也能开发
- AI 服务出问题时能测试流程
- 降低开发成本
- 方便录 Demo
### 12.5 核心 AI 接口
**POST /ai/analyze-learning-input**
输入：
```json
{
"userId": "user_001",
"lessonId": "lesson_001",
"userInput": "用户写下的答案或笔记",
"context": {
"lessonTitle": "材料阅读方法",
"objectives": ["理解材料结构", "提取关键要点"],
"keyPoints": ["问题", "原因", "影响", "对策"]
}
}
```
输出：
```json
{
"masteryScore": 3,
"understandingLevel": "基本理解",
"summary": "用户能理解主要内容，但要点不完整。",
"strengths": ["表达清楚"],
"weakPoints": ["遗漏关键要点", "逻辑层次不足"],
"suggestions": ["补充第二个要点", "先概括再展开"],
"reviewNeeded": true,
"nextAction": "明天重新回答本节主动回忆问题。"
}
```
**POST /ai/chat**
输入：
```json
{
"userId": "user_001",
"lessonId": "lesson_001",
"message": "这节内容能不能举个例子？"
}
```
输出：
```json
{
"reply": "可以。你可以这样理解……",
"suggestedActions": ["生成复习问题", "重新解释", "给我一个例子"]
}
```
---
## 13. 域名规划
### 13.1 当前已有域名
```text
longde.cloud
```
v0.1 阶段使用该域名作为产品基础设施域名。
### 13.2 子域名规划
```text
longde.cloud 官网首页
www.longde.cloud 官网首页（可跳转）
api.longde.cloud 后端 API
git.longde.cloud Gitea 代码仓库
download.longde.cloud 未来 Mac DMG 下载（可选）
status.longde.cloud 未来服务状态页（可选）
```
### 13.3 官网 URL 规划
| 路径 | 说明 |
|------|------|
| / | 首页 |
| /privacy | 隐私政策 |
| /terms | 用户协议 |
| /support | 支持与反馈 |
| /waitlist | 等待名单 / 内测申请 |
| /changelog | 更新日志 |
| /download | 未来 Mac DMG 下载页 |
| /blog | 后续 SEO 内容文章 |
---
## 14. 部署方案
### 14.1 当前服务器情况
- 4 核 4G 轻量云服务器
- 当前运行 Gitea
### 14.2 是否需要新买服务器
**v0.1 阶段不建议立刻买新 ECS。**
原因：
1. 当前没有真实用户
2. v0.1 请求量很低
3. 官网、后端、数据库可以先小规模部署
4. 先验证产品，不增加固定成本
### 14.3 当前推荐部署方式
```text
Nginx
Docker Compose 或 PM2
MySQL
Redis（可选）
NestJS 后端
Astro 静态官网
Gitea 继续保留
```
### 14.4 什么时候买新服务器
满足以下情况再考虑新服务器：
1. Gitea 和产品服务互相影响
2. 官网访问开始明显增加
3. 后端 AI 请求明显增多
4. MySQL 占用资源明显
5. 需要更稳定的生产环境
6. App Store 正式上线前想隔离开发服务
---
## 15. 开发环境与仓库规划
### 15.1 仓库策略
**推荐 monorepo：**
```text
ai-study-product/
├── apps/
│ ├── ios/
│ └── website/
│
├── services/
│ └── api/
│
├── packages/
│ ├── shared-types/
│ └── prompts/
│
├── docs/
│ └── planning/
│
└── README.md
```
**原因：**
1. 早期项目小，放一起方便管理
2. AI Agent 更容易读取完整上下文
3. Prompt、类型定义、文档可以共享
4. 后续大了再拆仓库
---
## 16. 技术里程碑
### 技术里程碑 1：可点击 iOS Demo
- SwiftUI 项目
- 基础页面
- Tab 导航
- 学习路径页面
- 内容阅读页面
- AI 分析结果假数据
### 技术里程碑 2：最小后端
- NestJS 项目
- MySQL 连接
- 用户表
- 学习记录表
- AI MockProvider
- 反馈接口
### 技术里程碑 3：真实 AI 接入
- AI Provider 抽象
- 接入一个真实模型
- AI 分析接口
- AI 对话接口
- 结构化输出保存
### 技术里程碑 4：官网上线
- Astro 官网
- 首页
- 隐私政策
- 用户协议
- 支持页
- 等待名单
- SEO 基础配置
### 技术里程碑 5：TestFlight 前准备
- Sign in with Apple
- 后端用户身份记录
- 基础错误处理
- 数据隐私检查
- 反馈入口
- 内测版本构建
---
## 17. 当前技术不做清单
- Spring Boot
- 微服务
- Kubernetes
- 多云部署
- 完整后台管理系统
- 完整 CMS
- 完整 RAG
- 向量数据库
- 多模型自动路由
- AI Agent 工具调用系统
- 文件上传解析
- Web 学习端
- Android
- Mac 正式版
- 支付系统
- 复杂数据分析平台

717
4-用户验证与增长/用户验证与增长.md Normal file
View File

@ -0,0 +1,717 @@
---
version: v0.1
status: draft
updated: 2026-05-03
---
# 用户验证与增长
## 1. 当前定位
v0.1 阶段的用户验证与增长，不是大规模营销，也不是正式商业化投放。
**当前目标是：**
> 用最低社交压力、最低成本的方式，验证产品方向是否有人需要，并找到第一批愿意试用的人。
**当前不追求：**
- 大规模涨粉
- 大规模投流
- 大规模社群运营
- 自动化私信轰炸
- 全平台铺量
- 精致品牌营销
**当前只追求：**
1. 收集真实用户痛点
2. 验证用户是否对产品感兴趣
3. 找到愿意内测的人
4. 判断哪个知识库方向更值得做
5. 为 Demo / TestFlight 获取第一批反馈
---
## 2. 当前增长原则
### 2.1 不做硬销售
当前不卖课、不卖资料、不卖会员。
对外表达应该是：
> 我是一个独立开发者，正在验证一个 AI 学习工具的想法，希望听听真实用户的意见。
不要一开始就说：赶紧下载、立即购买、限时优惠、保证提分、权威批改、上岸神器。
### 2.2 不装专家
对外身份应该是：
> 做 AI 学习工具的独立开发者，正在和真实备考用户一起打磨产品。
不要伪装成：申论老师、公考名师、权威机构、教培专家。
### 2.3 先验证，再增长
```text
观察用户痛点
↓
发布验证内容
↓
收集评论 / 问卷 / 等待名单
↓
找到愿意内测的人
↓
根据反馈调整 Demo
↓
再扩大内容发布
```
### 2.4 人参与最终判断
AI 可以辅助大量工作，但关键动作必须由人确认：
- 是否发布
- 如何回复
- 是否私信
- 是否邀请内测
- 是否采纳反馈
- 是否调整产品方向
---
## 3. AI / Agent 在增长中的角色
### 3.1 AI 可以做的事情
AI 可以负责：
1. 选题生成
2. 标题优化
3. 文案草稿
4. 小红书笔记草稿
5. B 站视频脚本
6. 知乎回答草稿
7. 评论截图分析
8. 用户痛点归类
9. 回复建议
10. 问卷设计
11. 反馈总结
12. 竞品评论分析
13. 内容复盘
14. 下一步建议
### 3.2 AI 不应该完全自动做的事情
AI 不应该完全自动：
1. 批量发布内容
2. 批量评论
3. 批量私信
4. 冒充真人互动
5. 伪造用户反馈
6. 用脚本刷量
7. 自动加入大量群聊
8. 自动爬取和搬运平台内容
9. 自动生成大量低质量 SEO 内容
### 3.3 推荐模式：半自动增长
```text
AI 生成内容草稿
↓
人审核修改
↓
人手动发布
↓
用户评论 / 私信
↓
截图给 AI 分析
↓
AI 生成回复草稿
↓
人确认后回复
↓
AI 汇总反馈
↓
更新产品计划
```
**一句话总结：**
> 不是让 AI 代替你做营销，而是让 AI 把营销里最消耗你的部分变成草稿、模板、分析和建议。
真正需要你做的只有三件事：
```text
判断发不发
判断怎么回
判断这个反馈对产品有没有用
```
---
## 4. 当前验证渠道
### 4.1 小红书
**定位：**
- 最适合早期验证学习类、备考类、工具类内容
- 适合图文、截图、短视频、经验贴
- 适合收集评论和私信
**适合内容：**
- 产品想法验证
- 学习痛点讨论
- AI 工具截图
- Demo 过程记录
- 公考申论学习痛点
- AI 学习方法
- 独立开发者公开构建
### 4.2 B 站
**定位：**
- 适合长一点的解释、开发记录、产品演示
- 适合建立信任
- 适合做"我如何做一个 AI 学习 App"系列内容
**适合内容：**
- Demo 演示
- 开发记录
- 产品思路讲解
- AI 学习工具评测
- 公考申论 AI 批改实验
- 独立开发者创业记录
### 4.3 知乎
**定位：**
- 适合回答问题、沉淀长文
- 适合做搜索流量
- 适合验证用户痛点和观点
**适合内容：**
- 申论怎么学
- AI 能不能辅助学习
- 普通人怎么系统学习 AI 工具
- 知识库学习是不是伪学习
- 学习软件怎么提高效率
### 4.4 官网
**定位：**
- 承接流量
- 收集等待名单
- 展示产品定位
- 提供隐私政策、支持页
- 为后续 App Store 上架做基础
```text
内容平台种草
↓
引导到官网
↓
查看产品介绍
↓
加入等待名单 / 申请内测
```
---
## 5. 当前内容方向
v0.1 阶段暂时围绕三个候选方向做内容测试。
### 方向 A：公考申论 AI 学习教练
1. 申论小白最难的是不会写，还是没人批改？
2. 如果 AI 每天帮你批改申论答案，你会用吗？
3. 我想做一个 AI 申论学习工具，有人需要吗？
4. 申论为什么看了很多资料还是不会写？
5. 申论学习是不是存在大量伪学习？
6. AI 能不能帮你发现申论答案的问题？
7. 申论学习最缺的是资料，还是反馈？
8. 我用 AI 做了一个申论学习 Demo。
### 方向 B：AI 工具学习知识库
1. 普通人到底该怎么系统学习 AI 工具？
2. 不会写 Prompt 的人，真的需要一个 AI 学习 App 吗？
3. 我想做一个 AI 工具学习知识库，有人需要吗？
4. AI 工具太多，普通人该从哪里开始？
5. 用 AI 学习 AI，是不是更高效？
6. 普通人学 AI 最容易踩哪些坑？
7. 我做了一个 AI 工具学习路径 Demo。
### 方向 C：程序员 / 前端面试学习助手
1. 前端面试为什么刷了很多题还是不会答？
2. AI 能不能模拟面试官？
3. 我想做一个 AI 前端面试学习助手。
4. 程序员面试最缺的是题库，还是反馈？
5. AI 帮你分析面试回答，有没有价值？
6. 前端八股文怎么学才不是死背？
---
## 6. 内容生产流程
### 6.1 每条内容的生产流程
```text
确定方向
↓
AI 生成 5 个选题
↓
人选择 1 个
↓
AI 生成草稿
↓
人改成自己的语气
↓
AI 优化标题和结构
↓
人最终审核
↓
手动发布
↓
截图评论给 AI 分析
↓
整理反馈
```
### 6.2 内容不要太精致
v0.1 阶段内容不追求精致品牌感。
更适合真实表达：
- 我正在做一个产品
- 我还不确定有没有人需要
- 我想听真实用户意见
- 这是我做的 Demo
- 你觉得这个功能有用吗
早期真实感比精致感更重要。
### 6.3 内容频率
**建议频率：**
```text
每周 3 条小红书
每周 1 条 B 站动态或视频
每周 1 个知乎回答
每周 1 次反馈整理
```
**最低频率：**
```text
每周 2 条小红书
每周 1 次反馈整理
```
---
## 7. 小红书内容模板
### 7.1 产品想法验证型
**标题方向：**
- 我想做一个 AI 申论学习工具，有人需要吗？
- 如果 AI 每天帮你批改申论答案，你会用吗？
- 申论最痛苦的是不会写，还是没人批改？
**正文结构：**
```text
我最近在做一个 AI 学习工具的方向验证。
想法很简单：
不是卖课，也不是做题库，而是想做一个能帮用户完成学习、反馈和复习的 AI 学习助手。
比如申论学习里，很多人不是没资料，而是：
1. 不知道怎么写
2. 写完没人批改
3. 不知道自己错在哪
4. 不知道每天该学什么
5. 看了很多资料但还是不会用
我想验证一个问题：
如果有一个 App，每天给你一个小任务，
你写完后 AI 帮你分析问题，
再告诉你明天该复习什么，
你会愿意试试吗？
正在备考的朋友可以评论告诉我：
你学申论最痛苦的是哪一步？
```
### 7.2 Demo 展示型
**标题方向：**
- 我做了一个 AI 申论学习 Demo，想听听真实反馈
- 一个人做 App 第 X 天：AI 申论学习助手雏形
- 这是我做的 AI 学习工具第一版
**正文结构：**
```text
今天做了一个很早期的 Demo。
目前只有一个核心流程：
选择学习路径 → 阅读一小节内容 → 写下自己的理解 → AI 分析薄弱点 → 生成复习建议
现在还不是正式产品，只是想验证：
这个流程对学习有没有帮助。
如果你正在备考，或者对 AI 学习工具感兴趣，
可以帮我看看这个方向有没有价值。
```
---
## 8. B 站内容模板
### 8.1 开发记录型
**视频标题：**
- 我打算做一个 AI 学习 App，第 1 版先验证这个功能
- 一个人做 AI 学习产品：为什么我不想做普通笔记软件？
- 从 0 做一个 AI 申论学习助手，我先做了这个 Demo
**视频结构：**
```text
1. 我为什么想做这个产品
2. 现在的学习软件有什么问题
3. 我想验证的核心假设
4. Demo 当前做到了什么
5. 我最不确定的问题
6. 邀请真实用户反馈
```
### 8.2 观点型
**视频标题：**
- 为什么很多知识库学习其实是伪学习？
- AI 学习工具真正有价值的地方不是总结，而是反馈
- 普通人学习最缺的不是资料，而是下一步决策
---
## 9. 评论与私信回复策略
### 9.1 回复原则
1. 真诚
2. 不推销
3. 不争辩
4. 不装专家
5. 不承诺效果
6. 多问真实情况
7. 少说产品多强，多问用户怎么学
### 9.2 AI 辅助回复流程
```text
用户评论截图
↓
发给 AI
↓
AI 判断评论类型
↓
AI 生成 3 个回复草稿
↓
人选择一个并修改
↓
人手动回复
```
### 9.3 评论分类
```text
感兴趣 / 质疑 / 吐槽痛点 / 提供建议 / 询问价格 / 询问内测 / 无效评论 / 负面评论
```
### 9.4 回复示例
**用户说：这个有点意思，怎么用？**
> 还在早期验证阶段，目前在做 Demo 和内测准备。现在主要想先确认这个流程对真实学习有没有帮助。如果你愿意，我后面可以发你 TestFlight 内测链接，想听听你的真实反馈。
**用户说：AI 批改靠谱吗？**
> 我也不打算把它包装成权威批改。现在更想做成学习辅助，帮用户发现表达、结构、遗漏要点这些问题。真正的效果还需要拿真实用户反馈来验证。
**用户说：申论不是 AI 能搞定的。**
> 认同，申论肯定不能完全靠 AI。我现在的想法不是替代老师，而是解决一些基础问题，比如写完没人看、不知道哪里表达不清楚、不知道第二天该复习什么。
**用户说：多少钱？**
> 现在还没正式定价，早期会先做内测。因为 AI 有调用成本，未来大概率会是订阅制，但现阶段重点是验证功能有没有用。
---
## 10. 问卷设计
### 10.1 问卷目标
问卷不是为了做复杂市场调研，而是为了判断：
1. 用户是谁
2. 用户用什么设备
3. 用户痛点是什么
4. 用户现在花不花钱
5. 用户是否愿意试用
6. 用户是否愿意付费
### 10.2 公考申论方向问卷
```text
1. 你现在是否在备考公考 / 事业编？
2. 你主要使用 iPhone 还是 Android？
3. 你学申论最痛苦的问题是什么？
4. 你现在买过哪些申论资料 / 课程 / App 会员？
5. 你是否需要 AI 帮你分析答案和安排复习？
6. 如果有内测版，你愿意试用吗？
7. 如果未来收费，你能接受的价格区间是多少？
8. 是否愿意留下邮箱或联系方式用于内测通知？
```
### 10.3 AI 工具学习方向问卷
```text
1. 你现在是否在学习 AI 工具？
2. 你主要想用 AI 解决什么问题？
3. 你现在最大的问题是不会选工具、不会 Prompt，还是不知道怎么系统学？
4. 你是否愿意使用一个系统化 AI 工具学习 App？
5. 你主要使用 iPhone 还是 Android？
6. 如果有内测版，你愿意试用吗？
7. 如果未来收费，你能接受的价格区间是多少？
8. 是否愿意留下邮箱或联系方式用于内测通知？
```
---
## 11. 等待名单设计
官网需要提供等待名单页面。
**路径：** `/waitlist`
**字段：**
```text
昵称（可选）
邮箱
使用设备：iPhone / Android / iPad / Mac
感兴趣方向：公考申论 / AI 工具学习 / 程序员面试 / 其他
当前最大痛点
是否愿意参加内测
是否接受后续邮件通知
```
**提交后提示：**
```text
感谢你加入等待名单。
当前产品还在早期验证阶段，如果你的需求匹配第一批内测方向，
我会优先联系你参与 TestFlight。
```
---
## 12. 反馈整理格式
每次收集到反馈，都统一记录。
```text
来源平台：
用户类型：
使用设备：
用户原话：
痛点分类：
是否感兴趣：
是否愿意内测：
是否愿意付费：
对产品的启发：
下一步动作：
```
**示例：**
```text
来源平台：小红书
用户类型：公考备考用户
使用设备：iPhone
用户原话：申论最难的是写完不知道哪里错。
痛点分类：缺少反馈
是否感兴趣：是
是否愿意内测：待确认
是否愿意付费：未知
对产品的启发：AI 分析答案可能是核心卖点
下一步动作：后续内容重点展示 AI 如何分析答案
```
---
## 13. AI 辅助增长工作流
### 13.1 每日 30 分钟流程
```text
10 分钟：看评论 / 私信 / 数据
10 分钟：截图给 AI 总结
10 分钟：回复用户或记录反馈
```
### 13.2 每周 2 小时流程
```text
30 分钟：AI 生成下周选题
30 分钟：挑选和修改内容
30 分钟：整理用户反馈
30 分钟：更新产品计划
```
### 13.3 Agent 可做任务
未来可以让 Agent 做：
1. 读取本地反馈表
2. 总结用户痛点
3. 生成内容选题
4. 生成小红书草稿
5. 生成 B 站脚本
6. 生成回复草稿
7. 维护内容日历
8. 输出每周复盘
但发布和回复仍由人确认。
---
## 14. 第一轮验证目标
### 最低目标
```text
收集 50 条用户痛点原话
发布 3 条小红书内容
发布 1 条 B 站内容或动态
收集 10 份问卷
获得 3 个愿意内测的人
```
### 理想目标
```text
收集 100 条用户痛点原话
发布 6 条小红书内容
发布 2 条 B 站内容
收集 30 份问卷
获得 10 个愿意内测的人
```
---
## 15. 2 周验证计划
### 第 1-2 天：观察
- 搜索小红书、B站、知乎相关内容
- 收集申论 / AI 工具学习 / 程序员面试用户痛点
- 整理至少 30 条用户原话
### 第 3-4 天：整理
- 用 AI 对用户原话分类
- 找出高频痛点
- 生成 10 个内容选题
- 确定第一批要发的 3 条内容
### 第 5-7 天：发布第一轮内容
- 发 2 条小红书
- 发 1 条 B 站动态或视频
- 不主动私信陌生人
- 只回复评论区用户
### 第 8-10 天：上线等待名单
- 官网上线 /waitlist
- 内容中引导感兴趣用户加入等待名单
- 收集设备类型和方向偏好
### 第 11-14 天：复盘
- 汇总评论、问卷、等待名单
- 判断哪个方向反馈更强
- 判断是否值得继续做 Demo
- 更新方向验证文档
---
## 16. 判断标准
### 方向继续的信号
某个方向满足以下条件，可以继续：
- 有用户主动评论或私信
- 有人愿意填写问卷
- 有人愿意加入等待名单
- 有人明确表示愿意内测
- 用户痛点集中
- 用户说得出现在怎么解决
- 用户过去为类似问题花过钱
- iPhone 用户比例不低
### 方向暂缓的信号
出现以下情况，需要暂缓：
- 内容没人看、没人评论
- 问卷没人填
- 用户痛点很分散
- 用户只是觉得有趣，但没有强需求
- 用户不愿意留下联系方式
- 用户不愿意付费
- 内容生产成本太高
- 创始人对领域长期没有兴趣
---
## 17. 当前不做清单
v0.1 用户验证与增长阶段暂不做：
- 自动批量发帖
- 自动批量评论
- 自动批量私信
- 投放广告
- 建大社群
- 付费买粉
- 购买水军
- 搬运他人内容
- 承诺学习效果
- 伪装成机构老师
- 大规模 SEO 内容站
- 多平台全量铺开
---
## 18. 当前最终策略
v0.1 用户验证与增长采用：
```text
AI 辅助生产
↓
人审核发布
↓
AI 辅助分析评论
↓
人确认回复
↓
AI 汇总反馈
↓
人决定产品方向
```
**一句话：**
> 当前不做全自动营销，而是做人机协作的低压力用户验证系统。

101
99-暂缓事项/暂缓事项.md Normal file
View File

@ -0,0 +1,101 @@
# 暂缓事项
这些事情重要，但不是 v0.1 阶段要做的。
## 暂缓商业化
- Apple IAP
- 月订阅
- 年订阅
- 免费试用
- 订阅权益系统
- AI 成本精算
等 TestFlight 有真实用户后再细拆。
## 暂缓运营
- 社群运营
- 客服机器人
- 用户分层
- 活动运营
- 打卡活动
等有第一批用户后再做。
## 暂缓数据系统
- 完整埋点
- 留存分析
- 付费转化分析
- 用户画像分析
v0.1 只记录最基础反馈。
## 暂缓合规与公司化
- 注册公司
- 对公账户
- 微信支付
- 支付宝
- 国内 Android 上架
- APP 备案
- ICP 备案
等 Apple 端验证收入后再考虑。
## 暂缓多端
- iPad
- Mac
- Android
- Web C 端
- B 端后台
当前只做 iPhone Demo 和官网基础设施。
## 解冻条件
以下事项不是永远不做，而是在满足条件后再做。
### 商业化解冻条件
满足以下条件后，再细拆 Apple IAP、订阅、免费试用：
- TestFlight 有真实用户
- 有用户明确表示愿意付费
- Demo 核心学习闭环已经跑通
- AI 成本大致可控
### 运营解冻条件
满足以下条件后，再考虑社群、客服、打卡活动：
- 有 10 个以上内测用户
- 用户开始持续反馈
- 需要集中管理用户问题
### 数据系统解冻条件
满足以下条件后，再做完整埋点和留存分析：
- App Store MVP 准备上线
- 用户量开始增长
- 需要判断留存和付费转化
### 合规与公司化解冻条件
满足以下条件后，再考虑公司、支付、备案、安卓：
- Apple 端有稳定收入
- 产品方向已经验证
- 用户不是朋友，而是陌生人自然使用或付费
- 收入能覆盖基础成本
### 多端解冻条件
满足以下条件后，再考虑 iPad、Mac、Android、Web 学习端：
- iPhone 版本核心体验稳定
- 用户明确提出多端需求
- 当前平台已经验证留存和付费