docs(startup-plan): 重构项目文档结构，整合所有产品决策
- 删除旧版 v0.1 规划，只保留完全版 - 更新全部 7 大模块文档，补充具体决策和实操内容 - 新增 AI架构设计、营销冷启动调研方案、客服设计详案等子文档 - 新增 潜在问题清单（56项技术+方向问题） - 整理图片到 images/ 目录
This commit is contained in:
parent
5e1c5445c7
commit
5c3f493071
BIN
images/logo.png
Normal file
BIN
images/logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
BIN
images/产品图.png
Normal file
BIN
images/产品图.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
BIN
images/产品图2.png
Normal file
BIN
images/产品图2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 842 KiB |
2
个人开发者创业 v0.1/.gitignore
vendored
2
个人开发者创业 v0.1/.gitignore
vendored
@ -1,2 +0,0 @@
|
||||
.claude/
|
||||
.claude*
|
||||
@ -1,46 +0,0 @@
|
||||
# 项目总纲
|
||||
|
||||
## 当前版本
|
||||
|
||||
个人开发者创业计划 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)
|
||||
@ -1,103 +0,0 @@
|
||||
# 方向验证
|
||||
|
||||
## 当前问题
|
||||
|
||||
现在不能直接确定做公考申论，因为创始人对该领域不够熟悉。
|
||||
|
||||
当前需要验证：
|
||||
|
||||
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. 创始人明显不想继续研究该领域。
|
||||
@ -1,721 +0,0 @@
|
||||
---
|
||||
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 天内必须产出可展示版本
|
||||
@ -1,958 +0,0 @@
|
||||
---
|
||||
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 正式版
|
||||
- 支付系统
|
||||
- 复杂数据分析平台
|
||||
@ -1,717 +0,0 @@
|
||||
---
|
||||
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 汇总反馈
|
||||
↓
|
||||
人决定产品方向
|
||||
```
|
||||
|
||||
**一句话：**
|
||||
|
||||
> 当前不做全自动营销，而是做人机协作的低压力用户验证系统。
|
||||
@ -1,101 +0,0 @@
|
||||
# 暂缓事项
|
||||
|
||||
这些事情重要，但不是 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 版本核心体验稳定
|
||||
- 用户明确提出多端需求
|
||||
- 当前平台已经验证留存和付费
|
||||
@ -4,37 +4,96 @@
|
||||
|
||||
定义产品方向、目标用户、核心价值主张和产品路线图。
|
||||
|
||||
## 核心内容
|
||||
---
|
||||
|
||||
### 产品定位
|
||||
## 产品定位
|
||||
|
||||
- 产品是什么
|
||||
- 解决什么问题
|
||||
- 核心价值主张
|
||||
**知习 ZhiXi** 是 AI 驱动的系统化学习工具。
|
||||
|
||||
### 目标用户
|
||||
一句话定位：
|
||||
|
||||
- 第一批目标用户画像
|
||||
- 用户痛点
|
||||
- 用户需求
|
||||
> 帮助有明确学习目标的人，通过 **知识库 + 主动回忆 + AI 分析 + 薄弱点追踪 + 间隔复习** 的完整闭环，从"被动看资料"变成"主动学习、反馈、复习和迭代"。
|
||||
|
||||
### 知识库方向
|
||||
不是笔记软件，不是通用 AI 聊天，不是题库刷题。
|
||||
|
||||
- 第一个垂直知识库选择
|
||||
- 内容来源方案
|
||||
- 内容边界定义
|
||||
---
|
||||
|
||||
### 产品功能
|
||||
## 目标用户
|
||||
|
||||
- MVP 功能清单
|
||||
- 第一版不做清单
|
||||
- 核心学习闭环设计
|
||||
- 有明确学习目标的人（考试、证书、求职、技能提升）
|
||||
- 愿意使用 AI 辅助学习
|
||||
- 不满足于单纯看资料
|
||||
- 希望通过写笔记、回答问题、主动回忆来学习
|
||||
- 第一批优先 iPhone 用户
|
||||
|
||||
---
|
||||
|
||||
## 知识库方向
|
||||
|
||||
**策略：** 先选一个垂直方向做 7 天路径验证，不做泛学习平台。
|
||||
|
||||
### 候选方向
|
||||
|
||||
1. 公考申论 AI 学习教练
|
||||
2. AI 工具学习知识库
|
||||
3. 程序员 / 前端面试学习助手
|
||||
|
||||
### 评估维度
|
||||
|
||||
付费意愿、学习刚需、内容获取难度、AI 价值、竞争强度、获客难度、个人熟悉度、MVP可控性
|
||||
|
||||
### 优先原则
|
||||
|
||||
第一版做：强目标、强结果、强付费意愿、强复习需求、内容边界清晰
|
||||
|
||||
第一版不做：泛学习、用户任意导入资料、大而全个人知识库、类 Notion 笔记系统
|
||||
|
||||
---
|
||||
|
||||
## MVP 核心闭环
|
||||
|
||||
```
|
||||
用户选择学习方向 → 进入结构化知识库 → 今日任务推荐
|
||||
→ 阅读一小节 → 主动回忆/写笔记 → AI 分析理解程度
|
||||
→ 生成待巩固项 → 安排复习计划 → 第二天继续
|
||||
```
|
||||
|
||||
## 第一版核心功能
|
||||
|
||||
| 功能 | 说明 |
|
||||
|------|------|
|
||||
| 知识库选择 | 用户选择学习方向 |
|
||||
| 内容学习 | 展示结构化知识内容 |
|
||||
| 学习笔记 | 用户记录理解、疑问、总结 |
|
||||
| 主动回忆 | 系统引导回忆，不只是看 |
|
||||
| AI 分析 | AI 判断掌握情况 |
|
||||
| 复习计划 | 根据掌握情况安排复习 |
|
||||
| 学习进度 | 展示学习进展和完成情况 |
|
||||
|
||||
## 第一版不做
|
||||
|
||||
复杂笔记编辑器、多人协作、社交、公开知识库广场、复杂知识图谱、完整题库、Web 端学习系统、Android、B 端
|
||||
|
||||
---
|
||||
|
||||
## 核心页面（14 页）
|
||||
|
||||
| 优先级 | 页面 |
|
||||
|--------|------|
|
||||
| P0 | 登录页、学习方向选择页、学习路径页、今日学习任务页、内容阅读页、主动回忆/笔记输入页、AI 分析结果页、AI 对话页、复习计划页 |
|
||||
| P1 | 学习进度页、设置页、反馈页、欢迎页、语言偏好页 |
|
||||
|
||||
---
|
||||
|
||||
## 账号体系
|
||||
|
||||
- 第一版：Sign in with Apple
|
||||
- 暂不做：微信登录、手机号登录、邮箱密码登录、Google 登录
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [阶段路线图](../0-阶段路线图/阶段路线图.md)
|
||||
- [技术与交付模块](../2-技术与交付模块/技术与交付模块.md)
|
||||
|
||||
## 负责人
|
||||
|
||||
[待定]
|
||||
- [商业化与支付模块](../3-商业化与支付模块/商业化与支付模块.md)
|
||||
|
||||
564
个人开发者创业 完全版/2-技术与交付模块/AI架构设计.md
Normal file
564
个人开发者创业 完全版/2-技术与交付模块/AI架构设计.md
Normal file
@ -0,0 +1,564 @@
|
||||
下面这段可以直接写进你的项目文档里。
|
||||
|
||||
---
|
||||
|
||||
# 知习 AI 工作流与学习 Agent 设计总结
|
||||
|
||||
## 一、核心原则
|
||||
|
||||
知习的 AI 能力不应该是一套通用聊天接口，也不应该所有业务都共用同一套 AI 工作流。
|
||||
|
||||
更合理的设计是：
|
||||
|
||||
```text
|
||||
以产品业务流程为主导
|
||||
按业务场景划分 AI 工作流
|
||||
按任务复杂度选择模型
|
||||
用用户学习画像实现“越用越懂你”
|
||||
后期再演进为受控的学习 Agent
|
||||
```
|
||||
|
||||
当前阶段不建议一开始就做完全自治 Agent，也不建议为每个用户单独部署一个真实 Agent 进程。
|
||||
|
||||
更合理的是：
|
||||
|
||||
```text
|
||||
统一 AI Workflow Engine
|
||||
+ 每个用户独立的学习画像
|
||||
+ 每个用户独立的长期学习记忆
|
||||
+ 可复用的 Prompt / Skill / Workflow
|
||||
= 逻辑上的个人学习 Agent
|
||||
```
|
||||
|
||||
用户感知上可以是“我的专属学习 Agent”，但技术实现上不应该是一人一个独立运行的 Agent。
|
||||
|
||||
---
|
||||
|
||||
## 二、为什么不能所有业务共用一套 AI 工作流
|
||||
|
||||
知习里的 AI 任务类型差异很大。
|
||||
|
||||
例如：
|
||||
|
||||
```text
|
||||
知识导入
|
||||
主动回忆分析
|
||||
费曼解释分析
|
||||
待巩固项生成
|
||||
复习卡片生成
|
||||
长期学习趋势分析
|
||||
后台风控和成本监控
|
||||
```
|
||||
|
||||
这些任务的输入、目标、模型要求、成本要求都不同。
|
||||
|
||||
所以不应该设计成：
|
||||
|
||||
```text
|
||||
所有任务 → 同一个 Prompt → 同一个模型 → 同一种分析结果
|
||||
```
|
||||
|
||||
而应该设计成：
|
||||
|
||||
```text
|
||||
不同业务场景 → 不同 AI Workflow → 不同模型策略 → 不同结构化输出
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、业务分级工作流设计
|
||||
|
||||
### 1. 知识导入工作流
|
||||
|
||||
目标：把用户输入的内容整理成可学习结构。
|
||||
|
||||
```text
|
||||
上传文档 / 输入内容
|
||||
→ 文本提取
|
||||
→ 内容清洗
|
||||
→ 知识点切分
|
||||
→ 生成标题 / 摘要 / 标签
|
||||
→ 用户确认
|
||||
→ 入库
|
||||
```
|
||||
|
||||
适合模型：
|
||||
|
||||
```text
|
||||
便宜模型
|
||||
中档模型
|
||||
规则代码
|
||||
```
|
||||
|
||||
不需要一开始就使用最强模型。
|
||||
|
||||
---
|
||||
|
||||
### 2. 主动回忆分析工作流
|
||||
|
||||
目标：判断用户是否真正理解知识点。
|
||||
|
||||
```text
|
||||
用户提交主动回忆回答
|
||||
→ 检查回答质量
|
||||
→ 提取回答覆盖的要点
|
||||
→ 对比知识点关键点
|
||||
→ 判断理解程度
|
||||
→ 找出遗漏 / 误解 / 模糊表达
|
||||
→ 生成待巩固项
|
||||
→ 生成复习建议
|
||||
→ 保存结构化分析结果
|
||||
```
|
||||
|
||||
这是知习最核心的 AI 工作流之一，应该使用主力模型。
|
||||
|
||||
适合模型：
|
||||
|
||||
```text
|
||||
主力模型
|
||||
强模型
|
||||
必要时结合便宜模型做预处理
|
||||
```
|
||||
|
||||
注意：便宜模型可以做清洗和提取，但核心判断最好由主力模型完成。
|
||||
|
||||
---
|
||||
|
||||
### 3. 复习工作流
|
||||
|
||||
目标：低成本、高频地帮助用户完成间隔复习。
|
||||
|
||||
```text
|
||||
读取到期复习项
|
||||
→ 生成复习卡片
|
||||
→ 用户回答
|
||||
→ 判断掌握情况
|
||||
→ 更新复习状态
|
||||
→ 更新 nextReviewAt
|
||||
```
|
||||
|
||||
适合模型：
|
||||
|
||||
```text
|
||||
规则算法
|
||||
便宜模型
|
||||
中档模型
|
||||
少量核心判断使用主力模型
|
||||
```
|
||||
|
||||
复习工作流不应该每一步都调用强模型，否则成本会过高。
|
||||
|
||||
---
|
||||
|
||||
### 4. 长期学习分析工作流
|
||||
|
||||
目标：根据用户一段时间内的学习数据，生成趋势分析和改进建议。
|
||||
|
||||
```text
|
||||
读取最近 7 / 30 天学习记录
|
||||
→ 统计主动回忆表现
|
||||
→ 统计薄弱点类型
|
||||
→ 识别重复错误
|
||||
→ 分析复习完成率
|
||||
→ 生成阶段性学习报告
|
||||
→ 给出下一阶段建议
|
||||
```
|
||||
|
||||
这个工作流可以异步执行，不需要用户实时等待。
|
||||
|
||||
适合模型：
|
||||
|
||||
```text
|
||||
中档模型
|
||||
主力模型
|
||||
异步队列
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. 后台风控与成本分析工作流
|
||||
|
||||
目标：控制 AI 成本、监控异常调用、辅助后台运营。
|
||||
|
||||
```text
|
||||
统计 AI 调用次数
|
||||
→ 计算 token 和成本
|
||||
→ 识别异常用户
|
||||
→ 识别高失败率任务
|
||||
→ 生成后台告警
|
||||
→ 辅助管理员排查问题
|
||||
```
|
||||
|
||||
这个工作流主要靠规则和数据库统计，不一定需要强模型。
|
||||
|
||||
---
|
||||
|
||||
## 四、模型选择原则
|
||||
|
||||
模型选择不应该按“哪个最强”来决定，而应该按任务分级。
|
||||
|
||||
可以分成四类：
|
||||
|
||||
```text
|
||||
轻任务：便宜模型
|
||||
核心分析：主力模型
|
||||
复杂推理：强模型
|
||||
后台异步任务：可低优先级慢慢跑
|
||||
```
|
||||
|
||||
例如：
|
||||
|
||||
```text
|
||||
简单数据清洗、摘要、标签提取：
|
||||
使用便宜模型或规则代码。
|
||||
|
||||
主动回忆薄弱点分析：
|
||||
使用 DeepSeek V4 Pro / V4 Flash 这类主力模型。
|
||||
|
||||
长期学习趋势分析：
|
||||
可以异步使用主力模型。
|
||||
|
||||
复习卡片生成：
|
||||
可以使用中档模型或便宜模型。
|
||||
```
|
||||
|
||||
关键原则：
|
||||
|
||||
```text
|
||||
便宜模型负责客观提取和清洗
|
||||
主力模型负责学习判断和薄弱点诊断
|
||||
强模型必须能看到原始证据，不能只依赖便宜模型的二次总结
|
||||
```
|
||||
|
||||
避免这种高风险流程：
|
||||
|
||||
```text
|
||||
用户原始回答
|
||||
→ 便宜模型总结
|
||||
→ 强模型只看总结后做判断
|
||||
```
|
||||
|
||||
更安全的是：
|
||||
|
||||
```text
|
||||
用户原始回答
|
||||
+ 知识点原文 / 关键点
|
||||
+ 便宜模型提取结果
|
||||
→ 主力模型综合判断
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、用户数据不足时怎么处理
|
||||
|
||||
第一版不应该依赖“海量用户数据”。
|
||||
|
||||
要区分三种分析：
|
||||
|
||||
### 1. 单次回答分析
|
||||
|
||||
不需要大量用户数据。
|
||||
|
||||
依赖的是：
|
||||
|
||||
```text
|
||||
知识点内容
|
||||
用户本次回答
|
||||
知识点关键要点
|
||||
AI 分析规则
|
||||
```
|
||||
|
||||
这个阶段现在就能做。
|
||||
|
||||
---
|
||||
|
||||
### 2. 个人学习趋势分析
|
||||
|
||||
不需要大量平台用户，但需要同一个用户自己的历史数据。
|
||||
|
||||
依赖的是：
|
||||
|
||||
```text
|
||||
最近学习记录
|
||||
主动回忆提交次数
|
||||
AI 分析评分变化
|
||||
待巩固项变化
|
||||
复习完成率
|
||||
重复出现的薄弱点
|
||||
```
|
||||
|
||||
这个需要用户持续使用一段时间后才能更准确。
|
||||
|
||||
---
|
||||
|
||||
### 3. 群体级智能优化
|
||||
|
||||
这个需要大量用户数据。
|
||||
|
||||
例如：
|
||||
|
||||
```text
|
||||
基于大量用户优化学习路径
|
||||
预测某类知识点常见错误
|
||||
优化复习算法
|
||||
做人群画像
|
||||
优化会员转化
|
||||
```
|
||||
|
||||
这不是第一版重点。
|
||||
|
||||
第一版应该聚焦：
|
||||
|
||||
```text
|
||||
基于用户自己的知识内容、主动回忆回答、AI 分析结果和复习表现，逐步形成个人学习画像。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、用户学习画像设计
|
||||
|
||||
知习后期所谓“个人 Agent 成长”，不应该理解为模型自己训练升级，而应该理解为系统持续积累用户学习画像。
|
||||
|
||||
可以记录：
|
||||
|
||||
```text
|
||||
用户常见薄弱类型
|
||||
用户常错知识点
|
||||
用户复习完成率
|
||||
用户主动回忆平均得分
|
||||
用户偏好的解释方式
|
||||
用户经常缺失的回答类型
|
||||
用户最近学习强度
|
||||
用户重复出现的错误模式
|
||||
```
|
||||
|
||||
这些数据可以组成：
|
||||
|
||||
```text
|
||||
UserLearningProfile
|
||||
```
|
||||
|
||||
有了这个画像后，系统可以逐步做到：
|
||||
|
||||
```text
|
||||
分析时更关注用户常犯错误
|
||||
复习时优先安排重复薄弱点
|
||||
生成解释时适配用户偏好
|
||||
学习报告更贴近用户真实表现
|
||||
```
|
||||
|
||||
这就是“学习 Agent 越来越懂用户”的基础。
|
||||
|
||||
---
|
||||
|
||||
## 七、Agent 设计原则
|
||||
|
||||
知习后期可以做 Learning Agent，但应该是受控 Agent，不是完全自治 Agent。
|
||||
|
||||
推荐定义：
|
||||
|
||||
```text
|
||||
Learning Agent
|
||||
= 业务工作流
|
||||
+ 用户学习画像
|
||||
+ 长期学习记忆
|
||||
+ 工具调用能力
|
||||
+ 结构化输出
|
||||
+ 权限控制
|
||||
+ 成本控制
|
||||
+ 审计日志
|
||||
```
|
||||
|
||||
Agent 可以做：
|
||||
|
||||
```text
|
||||
分析用户回答
|
||||
发现薄弱点
|
||||
生成待巩固项
|
||||
安排复习建议
|
||||
追踪重复错误
|
||||
生成阶段性学习报告
|
||||
```
|
||||
|
||||
Agent 不应该随意做：
|
||||
|
||||
```text
|
||||
自动删除用户知识库
|
||||
自动修改订阅
|
||||
自动退款
|
||||
自动封号
|
||||
自动无限调用 AI
|
||||
自动访问其他用户数据
|
||||
```
|
||||
|
||||
所有关键操作都必须有权限控制、日志记录和后台审计。
|
||||
|
||||
---
|
||||
|
||||
## 八、推荐演进路线
|
||||
|
||||
### V0：固定业务工作流
|
||||
|
||||
先不做 Agent。
|
||||
|
||||
只打通最核心的一条链路：
|
||||
|
||||
```text
|
||||
用户提交主动回忆回答
|
||||
→ AI 分析理解程度
|
||||
→ 生成待巩固项
|
||||
→ 生成复习建议
|
||||
→ 记录 token 和费用
|
||||
→ 前端展示结果
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### V1：用户学习画像
|
||||
|
||||
开始记录用户长期学习表现。
|
||||
|
||||
```text
|
||||
薄弱点类型
|
||||
复习完成率
|
||||
主动回忆得分
|
||||
重复错误
|
||||
知识点掌握变化
|
||||
```
|
||||
|
||||
这时系统开始具备“越来越懂用户”的基础。
|
||||
|
||||
---
|
||||
|
||||
### V2：逻辑 Learning Agent
|
||||
|
||||
在统一工作流引擎上加载用户画像和历史记忆。
|
||||
|
||||
```text
|
||||
统一 Workflow Engine
|
||||
+ 用户学习画像
|
||||
+ 用户历史学习记录
|
||||
+ 用户薄弱点
|
||||
= 用户专属学习 Agent 体验
|
||||
```
|
||||
|
||||
对用户来说，它像一个个人学习 Agent。
|
||||
|
||||
但技术上不是每人一个独立进程，而是共享引擎 + 用户级记忆。
|
||||
|
||||
---
|
||||
|
||||
### V3：受控技能成长
|
||||
|
||||
后期可以引入类似 Agent Skill 的能力。
|
||||
|
||||
但不要让 Agent 自由生成并上线技能，而应该：
|
||||
|
||||
```text
|
||||
系统生成候选 Skill
|
||||
→ 后台审核
|
||||
→ 灰度发布
|
||||
→ 监控效果
|
||||
→ 正式启用
|
||||
```
|
||||
|
||||
这样既能成长，又能保持产品稳定和安全。
|
||||
|
||||
---
|
||||
|
||||
## 九、后端概念设计
|
||||
|
||||
后端可以逐步抽象出三个核心概念：
|
||||
|
||||
```text
|
||||
Workflow：业务工作流
|
||||
AgentProfile：用户学习画像
|
||||
Skill：可复用分析策略
|
||||
```
|
||||
|
||||
可以预留的数据结构方向：
|
||||
|
||||
```text
|
||||
ai_workflows
|
||||
- id
|
||||
- key
|
||||
- name
|
||||
- businessType
|
||||
- version
|
||||
- status
|
||||
|
||||
ai_workflow_steps
|
||||
- id
|
||||
- workflowId
|
||||
- stepKey
|
||||
- modelTier
|
||||
- promptKey
|
||||
- order
|
||||
- inputSchema
|
||||
- outputSchema
|
||||
|
||||
user_learning_profiles
|
||||
- userId
|
||||
- weakTypes
|
||||
- preferredExplanationStyle
|
||||
- recallAccuracyAvg
|
||||
- reviewCompletionRate
|
||||
- repeatedMistakes
|
||||
- updatedAt
|
||||
|
||||
ai_skills
|
||||
- id
|
||||
- key
|
||||
- description
|
||||
- workflowKey
|
||||
- version
|
||||
- isActive
|
||||
- source
|
||||
- createdAt
|
||||
```
|
||||
|
||||
第一版不一定全部建表，但设计上要预留这些方向。
|
||||
|
||||
---
|
||||
|
||||
## 十、当前最应该落地的第一版
|
||||
|
||||
当前不应该一上来做完整 Agent 系统。
|
||||
|
||||
第一版最适合落地的是：
|
||||
|
||||
```text
|
||||
主动回忆分析 Workflow V1
|
||||
+ AI Usage Logs
|
||||
+ Prompt Version
|
||||
+ Structured JSON Result
|
||||
+ User Learning Profile V1
|
||||
```
|
||||
|
||||
具体流程：
|
||||
|
||||
```text
|
||||
1. 用户提交主动回忆回答
|
||||
2. 后端保存原始回答
|
||||
3. 规则检查回答是否为空、过短、重复
|
||||
4. 便宜模型或规则提取回答覆盖点
|
||||
5. 主力模型分析薄弱点和理解程度
|
||||
6. 返回结构化 JSON
|
||||
7. 生成待巩固项
|
||||
8. 生成复习建议
|
||||
9. 记录模型、token、费用、耗时、promptVersion
|
||||
10. 更新用户学习画像
|
||||
11. 前端展示 AI 分析结果
|
||||
```
|
||||
|
||||
这条链路跑通后，知习就不再是一个 AI 聊天壳，而是开始具备真正的主动学习系统能力。
|
||||
|
||||
---
|
||||
|
||||
## 一句话总结
|
||||
|
||||
```text
|
||||
知习的 AI 设计应该从“业务分级工作流”开始，而不是一开始做完全自治 Agent；后期通过用户学习画像、长期记忆和受控 Skill 系统，逐步演进成每个用户感知上的专属学习 Agent。
|
||||
```
|
||||
|
||||
这个方向也符合当前项目阶段：现在最重要的是先把 iOS App 和后端真实打通，并围绕最小学习闭环逐步接入真实 AI 分析能力。
|
||||
@ -4,43 +4,65 @@
|
||||
|
||||
确定技术栈、开发流程、交付节奏和质量标准。
|
||||
|
||||
## 核心内容
|
||||
---
|
||||
|
||||
### 技术选型
|
||||
## 技术选型（已决策）
|
||||
|
||||
- iOS 技术栈（Swift/SwiftUI）
|
||||
- 后端技术方案
|
||||
- AI API 集成
|
||||
- 数据库方案
|
||||
| 层级 | 选型 | 说明 |
|
||||
|------|------|------|
|
||||
| iOS | Swift / SwiftUI | Apple 原生，MVVM + Service + Repository |
|
||||
| 后端 | NestJS + TypeScript | 模块化单体架构 |
|
||||
| ORM | Prisma | 类型安全，自动生成 TS 类型 |
|
||||
| 数据库 | MySQL | 服务器已部署 |
|
||||
| 缓存/队列 | Redis + BullMQ | 缓存 + 队列 + 限流 + 临时状态 |
|
||||
| AI | Provider 抽象 + Mock + 真实模型 | MiniMax / DeepSeek / OpenAI 等可替换 |
|
||||
| 部署 | Docker Compose + Nginx | 4核4G 轻量云，域名 api.longde.cloud |
|
||||
| 官网 | Astro | SEO 友好，静态生成 |
|
||||
| 后台管理 | Vite + React + Ant Design + ProComponents + TanStack Query | 预留 |
|
||||
|
||||
### 项目结构
|
||||
---
|
||||
|
||||
- 代码仓库规范
|
||||
- 模块划分
|
||||
- 依赖管理
|
||||
## 前后端协作流程
|
||||
|
||||
### 开发流程
|
||||
1. 选一个业务流程
|
||||
2. 根据流程拆接口
|
||||
3. 后端设计表结构、DTO、接口、Swagger
|
||||
4. 前端根据 Swagger 写 Model / Service
|
||||
5. 前端接页面 → 联调 → 发现问题 → 回头改接口/DTO/表结构
|
||||
6. 稳定后再做下一个流程
|
||||
|
||||
- 日常开发流程
|
||||
- 代码审查规范
|
||||
- CI/CD 配置
|
||||
---
|
||||
|
||||
### 交付计划
|
||||
## iOS 多设备工程策略
|
||||
|
||||
- MVP 开发里程碑
|
||||
- TestFlight 发布计划
|
||||
- App Store 上架计划
|
||||
| 设备 | 策略 |
|
||||
|------|------|
|
||||
| iPhone + iPad | 同一个 Xcode Project，同一个 iOS App Target |
|
||||
| Mac | 单独 Mac 版本 Target |
|
||||
| Watch | watchOS Target |
|
||||
|
||||
### 技术债务
|
||||
---
|
||||
|
||||
- 已知技术债务
|
||||
- 后续优化计划
|
||||
## 第一版技术范围
|
||||
|
||||
**必须：** iOS 客户端、核心功能、简单后端、AI API 调用、本地数据存储、Apple IAP
|
||||
|
||||
**暂不做：** 安卓客户端、微信/支付宝支付、复杂后台管理系统、Web 学习端
|
||||
|
||||
---
|
||||
|
||||
## AI 架构
|
||||
|
||||
> 详见：[AI架构设计](./AI架构设计.md)
|
||||
|
||||
核心原则：从"业务分级工作流"开始，暂不做完全自治 Agent。后期通过用户学习画像、长期记忆和受控 Skill 系统逐步演进。
|
||||
|
||||
模型按任务分级：轻任务用便宜模型，核心分析用主力模型，复杂推理用强模型。
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [阶段路线图](../0-阶段路线图/阶段路线图.md)
|
||||
- [产品与用户模块](../1-产品与用户模块/产品与用户模块.md)
|
||||
|
||||
## 负责人
|
||||
|
||||
[待定]
|
||||
- [AI架构设计](./AI架构设计.md)
|
||||
|
||||
@ -4,43 +4,86 @@
|
||||
|
||||
设计商业模式、定价策略和支付系统。
|
||||
|
||||
## 核心内容
|
||||
---
|
||||
|
||||
### 商业模式
|
||||
## 商业模式（已决策）
|
||||
|
||||
- 订阅模式设计
|
||||
- 免费试用策略
|
||||
- 权益体系
|
||||
**极简结构：免费版 + 单一 Pro 订阅。** 不做多级会员梯度。
|
||||
|
||||
### 定价策略
|
||||
### 定价定位
|
||||
|
||||
- 月订阅定价
|
||||
- 年订阅定价
|
||||
- 早鸟价方案
|
||||
知习应按 **"AI 学习闭环工具"** 定价，不按普通笔记 App 也不按通用 AI 聊天工具。
|
||||
|
||||
### Apple IAP
|
||||
核心竞争力是 **输入 → 主动回忆 → AI 反馈 → 薄弱点 → 间隔复习 → 趋势分析** 完整闭环。
|
||||
|
||||
- 订阅配置
|
||||
- 恢复购买
|
||||
- 订阅管理
|
||||
### 竞品价格区间
|
||||
|
||||
### 支付流程
|
||||
| 类型 | 价格区间 | 知习对标 |
|
||||
|------|----------|----------|
|
||||
| 国内笔记/效率工具 | ¥9–¥20/月 | 应高于此 |
|
||||
| 国内重度 AI 工具 | ¥49–¥138/月 | 第一版不碰 |
|
||||
| 海外学习/知识产品 | $9.99–$24/月 | 对标此档 |
|
||||
| 海外笔记/闪卡工具 | $4–$12/月 | 应高于此 |
|
||||
|
||||
- 支付链路
|
||||
- 订单处理
|
||||
- 退款流程
|
||||
### 第一版定价
|
||||
|
||||
### 财务规划
|
||||
| 渠道 | 月付 | 年付 |
|
||||
|------|------|------|
|
||||
| 中国区 Web | ¥29 | ¥198–228 |
|
||||
| 中国区 iOS | ¥28–30 | ¥228 |
|
||||
| 海外 Web | $9.99 | $79.99 |
|
||||
| 海外 iOS | $11.99 | $89.99 |
|
||||
|
||||
- 收入预测
|
||||
- 成本核算
|
||||
- 盈亏平衡分析
|
||||
**早鸟价：** 中国区 ¥168–198/年，海外 $59.99–69.99/年，限前 100–300 人。
|
||||
|
||||
**暂不做：** 终身买断、家庭版、团队版、学生价、高阶 AI 版、次数包。
|
||||
|
||||
### 核心原则
|
||||
|
||||
1. **卖学习结果，不卖 AI 次数。** 收费页应写"持续追踪薄弱点、完整复习计划、长期趋势"，而非"300次AI分析"
|
||||
2. AI 次数是底层限制，不是主卖点
|
||||
3. 先不开放高阶 AI 版（¥49/月），等真实用户数据验证后再决定
|
||||
|
||||
### 收入测算
|
||||
|
||||
以 ¥29/月定价，扣平台抽成/AI成本/服务器成本后，单用户月净贡献约 ¥15–22。月净收入 ¥2000 需约 **90–140 个稳定付费用户**。建议设阶段性目标：100 个付费用户。
|
||||
|
||||
---
|
||||
|
||||
## 支付流程
|
||||
|
||||
```
|
||||
用户在 iOS App 内付款 → Apple IAP 完成交易 → 后端记录用户权益 → 用户获 Pro 权益
|
||||
```
|
||||
|
||||
核心是自己的 **用户系统 + 订单系统 + 权益系统**，Apple IAP 只是第一阶段的支付通道。
|
||||
|
||||
---
|
||||
|
||||
## 免费版权益
|
||||
|
||||
- 1 个知识库，100–200 个知识点
|
||||
- 每月 3 个文件上传
|
||||
- 每月 10–20 次 AI 学习分析（每日限 3 次）
|
||||
- 1 个复习计划
|
||||
- 保留基础学习记录
|
||||
- **必须能跑完整学习闭环**
|
||||
|
||||
## Pro 版权益
|
||||
|
||||
更多知识库、更多知识点、更多文件上传、更多 AI 学习分析、完整待巩固项、完整复习计划、月度学习报告、长期学习趋势、学习画像。
|
||||
|
||||
---
|
||||
|
||||
## 待补缺口
|
||||
|
||||
1. 算清单次 AI 分析的真实 token 成本
|
||||
2. 免费版加防滥用机制（日限、输入长度限制、高级模型不可用）
|
||||
3. 补查直接竞品价格（RemNote、Quizlet、Mochi、SuperMemo）
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [阶段路线图](../0-阶段路线图/阶段路线图.md)
|
||||
- [合规与公司化模块](../7-合规与公司化模块/合规与公司化模块.md)
|
||||
|
||||
## 负责人
|
||||
|
||||
[待定]
|
||||
@ -4,43 +4,78 @@
|
||||
|
||||
制定获客策略、品牌建设和增长计划。
|
||||
|
||||
## 核心内容
|
||||
---
|
||||
|
||||
### 品牌建设
|
||||
## 品牌建设
|
||||
|
||||
- 品牌定位
|
||||
- 品牌故事
|
||||
- 视觉规范
|
||||
- 品牌名：知习 ZhiXi（统一使用，不再混用"龙德AI学习"）
|
||||
- 品牌定位：AI 驱动的系统化学习工具，核心卖点是"输入 → 主动回忆 → AI 反馈 → 薄弱点 → 间隔复习 → 趋势"闭环
|
||||
- 对外身份：独立开发者，正在和真实用户一起打磨产品，不做硬销售、不装专家
|
||||
|
||||
### 获客渠道
|
||||
---
|
||||
|
||||
- App Store 优化
|
||||
- 社交媒体
|
||||
- 内容营销
|
||||
- 口碑传播
|
||||
## 营销策略（已决策）
|
||||
|
||||
### 官网营销
|
||||
采用 **半自动 AI 辅助模式**：
|
||||
|
||||
- 落地页设计
|
||||
- 等待名单收集
|
||||
- TestFlight 招募
|
||||
```
|
||||
AI 生成内容草稿 → 人审核修改 → 人手动发布 → AI 辅助分析评论和反馈
|
||||
```
|
||||
|
||||
### 内容营销
|
||||
核心：AI 负责选题/草稿/分析，人负责判断发不发、怎么回、反馈有没有用。
|
||||
|
||||
- 博客规划
|
||||
- 学习资源内容
|
||||
- SEO 策略
|
||||
---
|
||||
|
||||
### 增长指标
|
||||
## 获客渠道
|
||||
|
||||
- 下载量目标
|
||||
- 激活率目标
|
||||
- 留存率目标
|
||||
| 渠道 | 定位 | 内容形式 |
|
||||
|------|------|----------|
|
||||
| 小红书 | 早期验证，适合图文/截图/经验贴 | 产品想法验证、学习痛点讨论、Demo 展示 |
|
||||
| B 站 | 建立信任，长内容 | 开发记录、产品思路讲解、Demo 演示 |
|
||||
| 知乎 | 搜索流量，沉淀长文 | 学习方法回答、AI+学习观点 |
|
||||
| 官网 | 承接流量，收集等待名单 | 产品介绍、隐私政策、等待名单、TestFlight 招募 |
|
||||
|
||||
```
|
||||
内容平台种草 → 引导到官网 → 查看产品介绍 → 加入等待名单 / 申请内测
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 正确节奏
|
||||
|
||||
```
|
||||
有想法 → 发内容验证 → 收集潜在用户 → 邀请内测 → 修改产品 → 上架 → 继续增长
|
||||
```
|
||||
|
||||
而不是：闭门开发三个月 → 上架 → 才开始想怎么推广。
|
||||
|
||||
---
|
||||
|
||||
## 第一轮验证目标
|
||||
|
||||
- 收集 50 条真实用户痛点原话
|
||||
- 发布 3 条小红书 + 1 条 B 站内容
|
||||
- 收集 10 份问卷
|
||||
- 获得至少 3 个愿意内测的人
|
||||
|
||||
---
|
||||
|
||||
## 内容频率
|
||||
|
||||
- 每周 3 条小红书
|
||||
- 每周 1 条 B 站动态或视频
|
||||
- 每周 1 个知乎回答
|
||||
- 每周 1 次反馈整理
|
||||
|
||||
---
|
||||
|
||||
## 增长指标
|
||||
|
||||
- 下载量、激活率、次日/7日留存、付费转化率、取消订阅率、退款率
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [阶段路线图](../0-阶段路线图/阶段路线图.md)
|
||||
|
||||
## 负责人
|
||||
|
||||
[待定]
|
||||
- [营销冷启动调研方案](./营销冷启动调研方案.md)
|
||||
|
||||
173
个人开发者创业 完全版/4-营销与增长模块/营销冷启动调研方案.md
Normal file
173
个人开发者创业 完全版/4-营销与增长模块/营销冷启动调研方案.md
Normal file
@ -0,0 +1,173 @@
|
||||
# 调研启动方案
|
||||
|
||||
## 摘要
|
||||
|
||||
你上传的说明其实已经不是“帮我调研一下”级别的模糊需求，而是一份相当完整的研究 brief：主题聚焦「知习 ZhiXi」在 2025–2026 年的产品营销、推广、冷启动与 AI 自动化营销；约束条件是个人开发、低预算、不出镜、iOS 优先；目标是先找到第一批真实用户，并验证持续使用与付费信号，月收入约 2000 元可视为正向信号。fileciteturn0file0
|
||||
|
||||
如果你暂时不补充，我建议直接按“官方/原始信号优先”的默认方案开题，而不是再做一轮长问卷。原因是平台现在已经提供了可直接用于增长研究的一手能力：iOS 侧可直接研究产品页实验、定制产品页、应用分析与评分评论；Android 侧可研究 acquisition/statistics 与测试要求；海外社区发布需要先遵守真实参与与反垃圾规则；国内内容平台也提供创作者后台、内容管理和数据分析入口。对冷启动来说，这些信号比泛化营销文章更接近真实转化。citeturn0search0turn5search1turn7search3turn7search23turn7search7turn6search13turn5search5turn2search0turn2search1
|
||||
|
||||
| 下一步选项 | 适合情况 | 预计时长 | 你会得到什么 |
|
||||
|---|---|---:|---|
|
||||
| 直接按默认方案开题 | 你想马上推进，且现有 brief 已足够清楚 | 5 个工作日 | 一份可执行的完整研究报告框架与证据清单 |
|
||||
| 先缩到最关键问题 | 产品还在 MVP，先只关心“前 100 个真实用户 + 付费信号” | 2 个工作日 | 受众、渠道、内容、验证指标的最小答案 |
|
||||
| 分两阶段推进 | 先定方向，再补执行细节 | 2 + 3 个工作日 | 先出定位/受众/渠道，再出 30/60/90 天计划 |
|
||||
|
||||
## 诊断问卷
|
||||
|
||||
只需回答下面 8 个问题；如果赶时间，只回答“优先市场、成功标准、必看竞品”三项也可以。
|
||||
|
||||
| 要澄清的问题 | 建议回答方式 | 你当前的默认值 |
|
||||
|---|---|---|
|
||||
| 这次调研的主题是什么 | 一句话写清 | 知习 ZhiXi 的营销、推广、冷启动与 AI 自动化营销 |
|
||||
| 这次最想回答的核心问题 | 最多 3 个 | 如何低预算找到首批真实用户；如何验证持续使用与付费；国内/海外先做什么 |
|
||||
| 目标受众是谁 | 先写主受众，再写次受众 | 高学习需求用户 + 愿尝试新工具的人群 |
|
||||
| 优先市场与顺序 | 国内 / 海外 / 同步 / 先国内后海外 | 国内与海外都看，但执行上更适合先定主战场 |
|
||||
| 研究范围 | 明确“要研究”和“不研究” | 要研究渠道、定位、冷启动、内容、自动化；不以大额投放为重点 |
|
||||
| 可接受的证据源 | 官方、原始用户反馈、案例、第三方报告 | 优先官方平台报告、App 商店数据、公开案例、独立开发者复盘 |
|
||||
| 结果将用于什么决策 | 如“决定先做哪 3 个渠道” | 决定首发渠道、内容形式、种子用户获取、是否继续投入 |
|
||||
| 截止时间与输出格式 | 报告 / Notion / PPT / 表格 | 倾向实操型报告，最好能直接转执行清单 |
|
||||
|
||||
表中的“默认值”均根据你上传的说明整理，可直接修改、删除或补充。fileciteturn0file0
|
||||
|
||||
## 调研路径选项
|
||||
|
||||
以下时长为“单人研究”的现实估算，不含等待用户补充信息的时间。
|
||||
|
||||
| 路径 | 目标 | 单人估时 | 典型来源 | 预期输出 |
|
||||
|---|---|---:|---|---|
|
||||
| 快速概览 | 快速判断有没有值得做的机会 | 0.5–1 天 | 官方平台文档、5–8 个竞品页面、20–30 条用户评论 | 4–6 页简报，含方向判断与下一步建议 |
|
||||
| 深度报告 | 给出完整的营销、冷启动与执行框架 | 3–5 天 | 官方文档、竞品矩阵、商店评论、社区帖子、增长案例 | 15–25 页结构化报告，附 30/60/90 天计划 |
|
||||
| 市场/竞品比较 | 看清赛道、定位和差异化空间 | 4–7 天 | 15–25 个竞品、定价页、商店物料、评论、社区讨论 | 竞品地图、定位建议、内容角度与渠道优先级 |
|
||||
|
||||
建议默认选 **“深度报告”**，因为你当前的 brief 已经足以支撑完整研究；如果时间很紧，则先做 **“快速概览”** 的缩窄版。
|
||||
|
||||
## 默认调研方案
|
||||
|
||||
**如果你不再回复，默认核心问题将定义为：**
|
||||
在“不露脸、低预算、个人开发”的约束下，知习如何在接下来的 30–90 天内获得第一批真实用户，并验证持续使用与早期付费信号？fileciteturn0file0
|
||||
|
||||
| 默认项 | 默认值 |
|
||||
|---|---|
|
||||
| 研究对象 | 知习 ZhiXi |
|
||||
| 首阶段目标 | 获取首批真实用户，验证是否有人持续使用并愿意付费 |
|
||||
| 业务信号 | 月收入约 ¥2,000 可视为正向信号 |
|
||||
| 产品阶段 | 开发中，iOS 优先 |
|
||||
| 市场范围 | 国内 + 海外，但执行上先选一个主战场 |
|
||||
| 约束条件 | 个人开发、低预算、不出镜、偏自动化 |
|
||||
|
||||
以上默认项均来自你上传的研究说明。fileciteturn0file0
|
||||
|
||||
| 时间 | 工作内容 | 关键里程碑 | 主要产出 |
|
||||
|---|---|---|---|
|
||||
| 第一天 | 锁定研究问题、成功标准、竞品池、证据分级 | 明确“先回答哪 3 个问题” | 研究地图 + 竞品初表 |
|
||||
| 第二天 | 国内市场：用户、渠道、内容形态、社区入口 | 选出国内前 3 渠道 | 国内冷启动假设 |
|
||||
| 第三天 | 海外市场：用户、社区规则、发布方式、SEO/目录站 | 选出海外前 3 渠道 | 海外试点策略 |
|
||||
| 第四天 | 提炼定位、卖点、内容形式、AI 自动化流程 | 形成传播主线 | 卖点框架 + 内容/自动化方案 |
|
||||
| 第五天 | 拼成执行闭环：漏斗、指标、预算、30/60/90 天计划 | 得出最终建议 | 主报告 + 优先级清单 |
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 默认调研时间线
|
||||
dateFormat YYYY-MM-DD
|
||||
axisFormat %m/%d
|
||||
section 开题
|
||||
研究问题锁定与竞品清单 :a1, 2026-05-13, 1d
|
||||
section 国内
|
||||
国内用户/渠道/内容分析 :a2, after a1, 1d
|
||||
section 海外
|
||||
海外用户/社区/发布规则分析 :a3, after a2, 1d
|
||||
section 方案
|
||||
定位/卖点/自动化流程设计 :a4, after a3, 1d
|
||||
section 交付
|
||||
执行计划/指标/最终报告 :a5, after a4, 1d
|
||||
```
|
||||
|
||||
默认交付标准建议固定为：**国内/海外分开写；所有关键判断标记为 [事实] / [案例] / [推测] / [建议]；变化快的信息都写清日期；每条建议都落到“目标人群—渠道—内容—指标”四项。**
|
||||
|
||||
推荐优先查阅的官方/原始来源如下，先中文，后海外：
|
||||
|
||||
- entity["organization","中国互联网络信息中心","china internet stats org"]：url统计报告下载入口turn1search0
|
||||
- entity["organization","中国信息通信研究院","china telecom think tank"]：url人工智能产业发展研究报告（2025年）turn4search0
|
||||
- entity["organization","小红书","social commerce platform"]：url创作服务平台turn2search0
|
||||
- entity["organization","抖音","short video platform"]：url创作者中心turn2search1；url创作者学院turn2search9
|
||||
- entity["organization","哔哩哔哩","video platform china"]：url创作中心turn1search3
|
||||
- entity["company","Apple","consumer electronics company"]：url产品页优化turn0search0；url定制产品页turn5search1；url应用分析turn7search3；url评分与评论概览turn7search23
|
||||
- entity["company","Google","search and software company"]：urlPlay Console acquisition 报表turn7search7；urlStatistics 指标说明turn7search1；urlSEO Starter Guideturn5search3；urlPeople-first content 指南turn5search9
|
||||
- entity["organization","Product Hunt","product discovery community"]：urlLaunch Guideturn6search0；urlPreparing for launchturn6search6；urlSharing your launchturn6search13
|
||||
- entity["organization","Reddit","social discussion platform"]：urlReddiquetteturn6search1；urlSpam 规则turn5search5
|
||||
|
||||
如果后续要补 Android 首发，还要单独预留测试窗口：对于新创建的个人开发者账号，官方文档说明需要至少 12 名测试者连续 14 天参与 closed test，之后才能申请 production access。citeturn3search16
|
||||
|
||||
如果研究范围包含官网、落地页或 SEO，默认应按“helpful / people-first content”思路做内容结构，而不是先做关键词堆砌。citeturn5search3turn5search9
|
||||
|
||||
## 研究简报模板
|
||||
|
||||
可直接复制并填写：
|
||||
|
||||
**项目名称：**
|
||||
[例如：知习 ZhiXi 产品营销、推广、冷启动与 AI 自动化营销研究]
|
||||
|
||||
**一句话研究问题：**
|
||||
[这次研究最想回答的唯一问题]
|
||||
|
||||
**研究背景：**
|
||||
[为什么现在做、产品处于什么阶段、当前困境是什么]
|
||||
|
||||
**业务目标：**
|
||||
[例如：获取前 100 个真实用户；验证 7 日留存；验证首批付费]
|
||||
|
||||
**成功标准：**
|
||||
[写 3 个以内的硬指标]
|
||||
|
||||
**目标用户：**
|
||||
主受众：
|
||||
次受众：
|
||||
不优先受众：
|
||||
|
||||
**优先市场：**
|
||||
[国内 / 海外 / 先国内后海外 / 先海外后国内]
|
||||
|
||||
**必须覆盖的主题：**
|
||||
[渠道、定位、竞品、内容、自动化、ASO、漏斗、付费转化等]
|
||||
|
||||
**明确不研究的内容：**
|
||||
[例如：大额广告投放、品牌片、复杂 PR]
|
||||
|
||||
**必须覆盖的竞品：**
|
||||
[列 5–10 个]
|
||||
|
||||
**可接受的证据源：**
|
||||
[官方文档 / 商店评论 / 用户社区 / 公开复盘 / 第三方数据库]
|
||||
|
||||
**证据优先级：**
|
||||
[官方 > 原始用户反馈 > 一手平台数据 > 高质量二手资料 > 推断]
|
||||
|
||||
**输出格式：**
|
||||
[报告 / PPT / Notion / 表格 / 执行清单]
|
||||
|
||||
**交付深度：**
|
||||
[快速概览 / 深度报告 / 竞品比较]
|
||||
|
||||
**截止时间：**
|
||||
[具体日期]
|
||||
|
||||
**使用场景：**
|
||||
[用来决定什么，例如先做哪 3 个渠道]
|
||||
|
||||
**标注规范：**
|
||||
所有结论按 **[事实] / [案例] / [推测] / [建议]** 标记；变化快的信息注明日期。
|
||||
|
||||
## 质量检查清单
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
|---|---|
|
||||
| 问题是否清楚 | 能用一句话写出“这份研究要替你做什么决策” |
|
||||
| 范围是否收敛 | 首阶段只服务一个目标，不把“市场、品牌、投放、增长、定价”一次全做完 |
|
||||
| 证据是否足够一手 | 关键结论至少优先来自官方文档、商店页面、用户评论、社区原帖 |
|
||||
| 关键判断是否交叉验证 | 至少有两类证据相互支持，或一条官方证据 + 一条原始用户信号 |
|
||||
| 信息是否新 | 对平台规则、测试要求、商店能力、渠道机制标明日期或版本 |
|
||||
| 事实与建议是否分开 | 报告里明确区分 [事实]、[案例]、[推测]、[建议] |
|
||||
| 结论是否能执行 | 每条建议都能落到“谁、在哪、发什么、看什么指标” |
|
||||
| 国内/海外是否分开 | 不把两个市场混为一谈，至少在用户、渠道、话术上分开写 |
|
||||
| 是否说明不确定性 | 标出缺口、假设、尚待验证项，而不是把猜测写成结论 |
|
||||
| 是否能直接进入行动 | 报告结尾必须有优先级列表、时间线、里程碑和最低执行量 |
|
||||
339
个人开发者创业 完全版/5-运营与客服模块/客服设计详案.md
Normal file
339
个人开发者创业 完全版/5-运营与客服模块/客服设计详案.md
Normal file
@ -0,0 +1,339 @@
|
||||
对，你这个判断是对的。**你一个人做产品，如果没有 App 内客服 / 自动答疑系统，后面会非常累，而且体验也会很怪。**
|
||||
|
||||
用户遇到问题时，他不一定想发邮件，也不一定愿意等你手动回复。尤其是这些基础问题：
|
||||
|
||||
```text
|
||||
怎么创建知识库？
|
||||
为什么 Apple 登录失败？
|
||||
AI 分析结果怎么看？
|
||||
会员怎么取消？
|
||||
退款怎么处理？
|
||||
安卓什么时候上？
|
||||
数据会不会丢？
|
||||
上传文件失败怎么办？
|
||||
```
|
||||
|
||||
这些如果都靠你一个人回，肯定扛不住。
|
||||
|
||||
所以这里应该做一个：
|
||||
|
||||
```text
|
||||
App 内智能客服 + 反馈工单 + 后台处理系统
|
||||
```
|
||||
|
||||
而不是单纯一个“意见反馈表单”。
|
||||
|
||||
## 它在知习里的定位
|
||||
|
||||
你可以这么定义：
|
||||
|
||||
```text
|
||||
Dify 智能客服负责解决常见问题；
|
||||
反馈系统负责收集真实问题；
|
||||
后台管理系统负责处理需要人工介入的问题。
|
||||
```
|
||||
|
||||
它不是学习 Agent，不参与主动回忆、薄弱点分析、复习计划这些核心学习闭环。核心学习 AI 还是走你自己的后端工作流。你的当前主线仍然是把 iOS App 从静态 UI 变成真实功能 App。
|
||||
|
||||
## 我建议的客服流程
|
||||
|
||||
可以这样设计：
|
||||
|
||||
```text
|
||||
用户在 App 内点击“帮助与客服”
|
||||
→ 先进入智能客服
|
||||
→ Dify 根据帮助知识库自动回答
|
||||
→ 如果解决了，结束
|
||||
→ 如果没解决，用户点击“转人工 / 提交反馈”
|
||||
→ 后端创建反馈工单
|
||||
→ 后台显示待处理问题
|
||||
→ 你有空再处理
|
||||
```
|
||||
|
||||
这样你不是所有问题都要立刻回，而是让系统先挡住 70% 的基础问题。
|
||||
|
||||
## 第一版客服应该回答什么
|
||||
|
||||
第一版只回答官方固定内容：
|
||||
|
||||
```text
|
||||
功能使用说明
|
||||
登录问题
|
||||
知识库创建问题
|
||||
文件上传问题
|
||||
AI 分析说明
|
||||
复习计划说明
|
||||
订阅说明
|
||||
退款流程说明
|
||||
隐私政策
|
||||
用户协议
|
||||
备案信息
|
||||
常见错误处理
|
||||
联系方式
|
||||
```
|
||||
|
||||
不要让客服 Bot 去读用户私人知识库内容。
|
||||
|
||||
这点很重要。
|
||||
|
||||
客服 Bot 只应该读：
|
||||
|
||||
```text
|
||||
官方帮助中心知识库
|
||||
```
|
||||
|
||||
不要读：
|
||||
|
||||
```text
|
||||
用户上传的学习资料
|
||||
用户的主动回忆回答
|
||||
用户的私人知识库
|
||||
用户的学习分析结果
|
||||
```
|
||||
|
||||
除非以后你专门做了授权机制。
|
||||
|
||||
## 你真正需要的是三层系统
|
||||
|
||||
### 第一层：App 内智能客服
|
||||
|
||||
用户问基础问题，机器人自动回。
|
||||
|
||||
比如：
|
||||
|
||||
```text
|
||||
“怎么取消订阅？”
|
||||
“怎么导入知识点？”
|
||||
“为什么我的 AI 分析失败？”
|
||||
```
|
||||
|
||||
机器人可以直接回答流程。
|
||||
|
||||
### 第二层：反馈 / 工单系统
|
||||
|
||||
如果机器人解决不了，就创建反馈。
|
||||
|
||||
反馈字段可以有：
|
||||
|
||||
```text
|
||||
用户 ID
|
||||
联系方式
|
||||
问题类型
|
||||
问题内容
|
||||
截图
|
||||
设备型号
|
||||
系统版本
|
||||
App 版本
|
||||
当前页面
|
||||
处理状态
|
||||
创建时间
|
||||
```
|
||||
|
||||
问题类型可以先分成：
|
||||
|
||||
```text
|
||||
功能问题
|
||||
登录问题
|
||||
订阅问题
|
||||
退款问题
|
||||
AI 分析问题
|
||||
上传问题
|
||||
数据问题
|
||||
建议反馈
|
||||
其他
|
||||
```
|
||||
|
||||
### 第三层：后台处理
|
||||
|
||||
你在后台看到：
|
||||
|
||||
```text
|
||||
待处理反馈
|
||||
高频问题
|
||||
用户对话记录
|
||||
是否已解决
|
||||
是否需要回复
|
||||
是否需要更新帮助文档
|
||||
```
|
||||
|
||||
这样你不是被动被消息轰炸，而是集中处理。
|
||||
|
||||
## 哪些问题机器人可以处理
|
||||
|
||||
可以自动处理：
|
||||
|
||||
```text
|
||||
功能怎么用
|
||||
按钮在哪里
|
||||
复习计划怎么理解
|
||||
AI 分析结果是什么意思
|
||||
会员权益说明
|
||||
取消订阅流程
|
||||
退款流程说明
|
||||
隐私政策说明
|
||||
常见错误排查
|
||||
```
|
||||
|
||||
## 哪些问题必须转人工
|
||||
|
||||
这些不要让机器人自己处理：
|
||||
|
||||
```text
|
||||
退款争议
|
||||
账号删除
|
||||
数据丢失
|
||||
订阅权益异常
|
||||
用户投诉
|
||||
隐私问题
|
||||
内容违规问题
|
||||
支付失败但扣款
|
||||
Apple / Google 订单问题
|
||||
```
|
||||
|
||||
机器人可以先收集信息，然后创建工单。
|
||||
|
||||
比如：
|
||||
|
||||
```text
|
||||
这个问题可能需要人工处理。我已经帮你记录反馈，请补充你的订阅平台、订单时间和问题截图。
|
||||
```
|
||||
|
||||
## 技术上怎么接
|
||||
|
||||
推荐结构是：
|
||||
|
||||
```text
|
||||
iOS App
|
||||
→ 你的 NestJS 后端
|
||||
→ Dify API
|
||||
→ Dify 知识库
|
||||
```
|
||||
|
||||
不要让 iOS 直接调用 Dify。
|
||||
|
||||
原因是：
|
||||
|
||||
```text
|
||||
Dify API Key 不能暴露在客户端
|
||||
客服会话需要绑定 userId
|
||||
问题记录要进你的数据库
|
||||
后续要接后台工单
|
||||
要做限流和审计
|
||||
```
|
||||
|
||||
后端接口可以先设计成：
|
||||
|
||||
```text
|
||||
POST /api/support/chat
|
||||
POST /api/support/feedback
|
||||
GET /api/support/conversations
|
||||
GET /api/support/feedbacks/my
|
||||
```
|
||||
|
||||
后台接口：
|
||||
|
||||
```text
|
||||
GET /api/admin/support/tickets
|
||||
GET /api/admin/support/tickets/:id
|
||||
PATCH /api/admin/support/tickets/:id
|
||||
POST /api/admin/support/tickets/:id/reply
|
||||
```
|
||||
|
||||
## 第一版页面建议
|
||||
|
||||
App 里做 3 个页面就够：
|
||||
|
||||
```text
|
||||
帮助与客服页
|
||||
智能客服聊天页
|
||||
提交反馈页
|
||||
```
|
||||
|
||||
“我的”页面里放入口：
|
||||
|
||||
```text
|
||||
帮助与客服
|
||||
问题反馈
|
||||
隐私政策
|
||||
用户协议
|
||||
关于知习
|
||||
```
|
||||
|
||||
后台第一版加：
|
||||
|
||||
```text
|
||||
反馈列表
|
||||
反馈详情
|
||||
客服会话记录
|
||||
问题分类统计
|
||||
```
|
||||
|
||||
## Dify 知识库你可以先准备这些文档
|
||||
|
||||
```text
|
||||
知习是什么
|
||||
如何创建知识库
|
||||
如何添加知识点
|
||||
如何开始主动回忆
|
||||
AI 分析结果怎么看
|
||||
待巩固项是什么
|
||||
复习计划是什么
|
||||
如何修改个人资料
|
||||
如何取消订阅
|
||||
如何申请退款
|
||||
Apple 登录失败怎么办
|
||||
上传文件失败怎么办
|
||||
数据安全说明
|
||||
隐私政策摘要
|
||||
联系客服方式
|
||||
```
|
||||
|
||||
这些文档以后也可以直接变成 App 内帮助中心内容。
|
||||
|
||||
## 最重要的一点
|
||||
|
||||
智能客服不是为了“假装有人回复”，而是为了：
|
||||
|
||||
```text
|
||||
基础问题自动解决
|
||||
复杂问题收集完整信息
|
||||
你只处理真正需要人工判断的问题
|
||||
```
|
||||
|
||||
你一个人做产品，合理的客服策略应该是：
|
||||
|
||||
```text
|
||||
机器人先答
|
||||
答不了再建工单
|
||||
你集中处理高价值问题
|
||||
高频问题沉淀进帮助知识库
|
||||
```
|
||||
|
||||
这样系统会越来越省你的时间。
|
||||
|
||||
## 我的建议
|
||||
|
||||
你现在可以把它加入规划，而且我建议尽早预留后端模块：
|
||||
|
||||
```text
|
||||
support
|
||||
feedback
|
||||
support_tickets
|
||||
support_conversations
|
||||
admin_support
|
||||
```
|
||||
|
||||
但第一版不要做复杂在线客服。先做：
|
||||
|
||||
```text
|
||||
Dify FAQ 客服
|
||||
+ App 内反馈
|
||||
+ 后台工单列表
|
||||
+ 人工状态处理
|
||||
```
|
||||
|
||||
一句话总结：
|
||||
|
||||
```text
|
||||
你确实应该做 App 内智能客服；它的价值就是替你挡住基础问题，把真正需要人工处理的问题变成后台工单，而不是让所有用户消息都直接压到你一个人身上。
|
||||
```
|
||||
@ -4,42 +4,88 @@
|
||||
|
||||
建立用户运营体系和支持服务。
|
||||
|
||||
## 核心内容
|
||||
---
|
||||
|
||||
### 用户运营
|
||||
## 客服体系（已决策）
|
||||
|
||||
- 新用户引导
|
||||
- 用户激活策略
|
||||
- 用户留存计划
|
||||
采用 **Dify 智能客服 + 反馈工单 + 后台处理** 三层架构：
|
||||
|
||||
### 客服支持
|
||||
```
|
||||
用户在 App 内点击"帮助与客服"
|
||||
→ Dify 根据帮助知识库自动回答 FAQ
|
||||
→ 解决了 → 结束
|
||||
→ 未解决 → 用户点"转人工 / 提交反馈"
|
||||
→ 后端创建工单 → 后台显示 → 你有空再处理
|
||||
```
|
||||
|
||||
- 支持渠道
|
||||
- 响应时间标准
|
||||
- 常见问题处理
|
||||
Dify 只读官方帮助知识库，不读用户私人数据（学习资料、回忆回答、私人知识库、分析结果）。
|
||||
|
||||
### 用户反馈
|
||||
---
|
||||
|
||||
- 反馈收集渠道
|
||||
- 反馈处理流程
|
||||
- 用户评价管理
|
||||
## 可自动处理的 FAQ
|
||||
|
||||
### 社区运营
|
||||
功能使用说明、登录问题、知识库创建、文件上传、AI 分析说明、复习计划说明、订阅说明、退款流程、隐私政策、常见错误处理、联系方式
|
||||
|
||||
- 内测用户群
|
||||
- 用户社群
|
||||
- 用户激励
|
||||
## 必须转人工的问题
|
||||
|
||||
### 内容运营
|
||||
退款争议、账号删除、数据丢失、订阅权益异常、用户投诉、隐私问题、内容违规、支付失败但扣款、Apple/Google 订单问题
|
||||
|
||||
- 知识库内容更新
|
||||
- 学习内容质量把控
|
||||
---
|
||||
|
||||
## App 内页面
|
||||
|
||||
- 帮助与客服页
|
||||
- 智能客服聊天页
|
||||
- 提交反馈页
|
||||
- "我的"页面入口：帮助与客服、问题反馈、隐私政策、用户协议、关于知习
|
||||
|
||||
---
|
||||
|
||||
## 后台工单系统
|
||||
|
||||
- 反馈列表 / 详情
|
||||
- 客服会话记录
|
||||
- 问题分类统计
|
||||
- 待处理 / 已解决状态管理
|
||||
|
||||
---
|
||||
|
||||
## 反馈字段
|
||||
|
||||
用户 ID、联系方式、问题类型（功能/登录/订阅/退款/AI分析/上传/数据/建议/其他）、问题内容、截图、设备型号、系统版本、App 版本、处理状态
|
||||
|
||||
---
|
||||
|
||||
## 技术架构
|
||||
|
||||
```
|
||||
iOS App → NestJS 后端 → Dify API → Dify 知识库
|
||||
```
|
||||
|
||||
后端接口：
|
||||
- `POST /api/support/chat`
|
||||
- `POST /api/support/feedback`
|
||||
- `GET /api/support/conversations`
|
||||
- `GET /api/support/feedbacks/my`
|
||||
|
||||
后台接口：
|
||||
- `GET /api/admin/support/tickets`
|
||||
- `GET /api/admin/support/tickets/:id`
|
||||
- `PATCH /api/admin/support/tickets/:id`
|
||||
- `POST /api/admin/support/tickets/:id/reply`
|
||||
|
||||
---
|
||||
|
||||
## 用户运营
|
||||
|
||||
- 新用户引导、激活策略、留存计划
|
||||
- 内测用户群管理
|
||||
- 知识库内容更新和质量把控
|
||||
|
||||
---
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [阶段路线图](../0-阶段路线图/阶段路线图.md)
|
||||
- [数据反馈与迭代模块](../6-数据反馈与迭代模块/数据反馈与迭代模块.md)
|
||||
|
||||
## 负责人
|
||||
|
||||
[待定]
|
||||
- [客服设计详案](./客服设计详案.md)
|
||||
|
||||
@ -1,672 +1,103 @@
|
||||
# 个人开发者互联网产品创业项目拆分文档
|
||||
# 知习 ZhiXi 个人开发者创业计划
|
||||
|
||||
> 适用场景：个人开发者从零开始做互联网产品，第一阶段优先上架 Apple 平台，后续在产品盈利后再考虑国内安卓平台、公司化、微信/支付宝支付、备案等事项。
|
||||
> 适用场景：个人开发者从零开始做互联网产品，Apple-first 策略，先验证后扩张。
|
||||
|
||||
***
|
||||
---
|
||||
|
||||
## 1. 核心判断
|
||||
|
||||
当前最适合的策略不是一开始做全平台、全支付、全合规，而是：
|
||||
|
||||
> **先用 Apple 平台做低成本验证，证明产品有人用、有人愿意付费；等收入稳定后，再公司化并扩展到国内安卓平台。**
|
||||
|
||||
也就是说：
|
||||
|
||||
- Apple 不是终点，而是第一个验证市场。
|
||||
- iOS App 不是整个产品，而是产品的第一个交付渠道。
|
||||
- 你真正要做的是一个能解决用户问题、未来可以跨平台扩展的互联网产品。
|
||||
|
||||
***
|
||||
|
||||
## 2. 总体原则
|
||||
|
||||
### 2.1 长期架构要平台中立
|
||||
|
||||
不要把产品理解成：
|
||||
|
||||
```text
|
||||
我的产品 = iOS App
|
||||
```
|
||||
|
||||
更合理的理解是：
|
||||
|
||||
```text
|
||||
我的产品 = 一个解决某类用户问题的服务
|
||||
|
||||
iOS App = 第一个交付渠道
|
||||
Android App = 第二个交付渠道
|
||||
Web / 小程序 = 未来可能的交付渠道
|
||||
```
|
||||
|
||||
### 2.2 短期执行要 Apple 优先
|
||||
|
||||
第一阶段只做 Apple，是为了减少复杂度：
|
||||
|
||||
- 不用一开始注册公司。
|
||||
- 不用一开始接微信支付、支付宝。
|
||||
- 不用一开始铺国内安卓应用商店。
|
||||
- 不用一开始处理大量国内合规和资质问题。
|
||||
- 先用 App Store 和 Apple IAP 验证用户需求与付费意愿。
|
||||
|
||||
### 2.3 先验证，再扩张
|
||||
|
||||
早期最重要的不是“功能多”，而是证明：
|
||||
|
||||
```text
|
||||
有人需要 → 有人愿意用 → 有人愿意付费 → 收入能覆盖成本
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 3. 推荐的 7 大项目模块
|
||||
|
||||
一个个人开发者创业项目，可以拆成 7 个核心模块。
|
||||
|
||||
```text
|
||||
个人开发者创业项目
|
||||
│
|
||||
├── 1. 产品与用户模块
|
||||
├── 2. 技术与交付模块
|
||||
├── 3. 商业化与支付模块
|
||||
├── 4. 营销与增长模块
|
||||
├── 5. 运营与客服模块
|
||||
├── 6. 数据、反馈与迭代模块
|
||||
└── 7. 合规与公司化模块
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 4. 模块一：产品与用户模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 我到底做什么？给谁做？解决什么问题？
|
||||
|
||||
### 4.1 需要拆分的内容
|
||||
|
||||
| 子模块 | 说明 |
|
||||
| ------ | ----------------- |
|
||||
| 用户画像 | 明确目标用户是谁 |
|
||||
| 使用场景 | 用户在什么情况下需要这个产品 |
|
||||
| 核心痛点 | 用户现在最麻烦、最不爽的问题是什么 |
|
||||
| 替代方案 | 用户现在用什么解决这个问题 |
|
||||
| 产品定位 | 你的产品比现有方案好在哪里 |
|
||||
| MVP 范围 | 第一版只做哪个最核心的功能 |
|
||||
| 产品路线图 | 后续版本逐步增加什么能力 |
|
||||
|
||||
### 4.2 一句话定位模板
|
||||
|
||||
```text
|
||||
我做一个【产品类型】，帮助【目标用户】在【具体场景】下，
|
||||
用【核心功能】解决【核心痛点】，第一版只做【一个关键动作】，
|
||||
通过【订阅 / 买断 / 免费试用 / 点数】变现。
|
||||
```
|
||||
|
||||
### 4.3 示例
|
||||
|
||||
```text
|
||||
我做一个 iOS App，帮助刚开始健身的人每天生成简单训练计划，
|
||||
用打卡和提醒解决坚持困难的问题，第一版只做“生成今日训练 + 完成打卡”，
|
||||
通过年订阅变现。
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 5. 模块二：技术与交付模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 怎么把产品做出来，并且未来能扩展到安卓和其他平台？
|
||||
|
||||
### 5.1 技术模块应该拆成两层
|
||||
|
||||
```text
|
||||
技术与交付模块
|
||||
│
|
||||
├── 跨平台核心能力
|
||||
│ ├── 后端 API
|
||||
│ ├── 数据库
|
||||
│ ├── 用户系统
|
||||
│ ├── 权益系统
|
||||
│ ├── AI / Agent 能力
|
||||
│ ├── Prompt / 内容系统
|
||||
│ └── 数据分析系统
|
||||
│
|
||||
└── 平台客户端
|
||||
├── iOS App
|
||||
├── 未来 Android App
|
||||
└── 未来 Web / 小程序
|
||||
```
|
||||
|
||||
### 5.2 第一阶段建议架构
|
||||
|
||||
如果是 AI 类产品，第一版可以采用：
|
||||
|
||||
```text
|
||||
iOS App + 简单后端 + 大模型 API + 数据库 + Apple IAP
|
||||
```
|
||||
|
||||
### 5.3 技术设计重点
|
||||
|
||||
早期不要把所有核心逻辑都写死在 iOS 客户端里。
|
||||
|
||||
更好的方式是：
|
||||
|
||||
- iOS 负责界面、交互和 Apple 平台能力。
|
||||
- 后端负责用户权益、AI 调用、订单状态、业务规则。
|
||||
- 未来安卓接入时，可以复用后端能力。
|
||||
|
||||
### 5.4 第一版可以包含
|
||||
|
||||
| 子模块 | 是否第一版需要 |
|
||||
| --------- | --------- |
|
||||
| iOS 客户端 | 必须 |
|
||||
| 核心功能 | 必须 |
|
||||
| 简单后端 | 视产品而定 |
|
||||
| AI API 调用 | AI 产品需要 |
|
||||
| 本地数据存储 | 通常需要 |
|
||||
| 用户登录 | 可以延后，除非必须 |
|
||||
| Apple IAP | 如果收费，需要 |
|
||||
| 安卓客户端 | 暂时不做 |
|
||||
| 微信/支付宝支付 | 暂时不做 |
|
||||
| 复杂后台管理系统 | 暂时不做 |
|
||||
|
||||
***
|
||||
|
||||
## 6. 模块三：商业化与支付模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 产品怎么赚钱？用户付费后，如何获得对应权益？
|
||||
|
||||
### 6.1 商业化结构
|
||||
|
||||
```text
|
||||
商业化与支付模块
|
||||
│
|
||||
├── 收费模式
|
||||
│ ├── 免费试用
|
||||
│ ├── 月订阅
|
||||
│ ├── 年订阅
|
||||
│ ├── 一次性买断
|
||||
│ └── 点数 / 额度
|
||||
│
|
||||
├── 支付通道
|
||||
│ ├── Apple IAP
|
||||
│ ├── 未来微信支付
|
||||
│ ├── 未来支付宝
|
||||
│ └── 未来安卓应用商店支付
|
||||
│
|
||||
└── 权益系统
|
||||
├── 免费用户
|
||||
├── Pro 用户
|
||||
├── 订阅有效期
|
||||
├── 点数余额
|
||||
├── 使用额度
|
||||
└── 退款 / 取消后的权限处理
|
||||
```
|
||||
|
||||
### 6.2 第一阶段支付策略
|
||||
|
||||
如果你的 iOS App 内卖的是数字功能、会员、高级内容、AI 次数、订阅等，一般应优先使用：
|
||||
|
||||
```text
|
||||
Apple In-App Purchase / StoreKit
|
||||
```
|
||||
|
||||
第一阶段流程可以是：
|
||||
|
||||
```text
|
||||
用户在 iOS App 内付款
|
||||
↓
|
||||
Apple IAP 完成交易
|
||||
↓
|
||||
你的后端记录用户权益
|
||||
↓
|
||||
用户获得 Pro / 订阅 / 点数 / 高级功能
|
||||
```
|
||||
|
||||
### 6.3 未来国内安卓阶段
|
||||
|
||||
未来扩展到国内安卓后，流程可以变成：
|
||||
|
||||
```text
|
||||
安卓用户付款
|
||||
↓
|
||||
微信支付 / 支付宝 / 应用商店支付
|
||||
↓
|
||||
你的后端记录用户权益
|
||||
↓
|
||||
用户获得 Pro / 订阅 / 点数 / 高级功能
|
||||
```
|
||||
|
||||
### 6.4 最关键的一点
|
||||
|
||||
不要让 Apple IAP 成为你的整个商业系统。
|
||||
|
||||
Apple IAP 只是第一阶段的支付通道。\
|
||||
真正核心的是你自己的：
|
||||
|
||||
```text
|
||||
用户系统 + 订单系统 + 权益系统
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 7. 模块四：营销与增长模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 用户从哪里来？怎么让更多人知道产品？
|
||||
|
||||
### 7.1 营销增长结构
|
||||
|
||||
```text
|
||||
营销与增长模块
|
||||
│
|
||||
├── 内容获客
|
||||
│ ├── 小红书
|
||||
│ ├── 知乎
|
||||
│ ├── B站
|
||||
│ ├── 抖音
|
||||
│ ├── X / Reddit
|
||||
│ └── 微信社群
|
||||
│
|
||||
├── 渠道转化
|
||||
│ ├── 官网落地页
|
||||
│ ├── 等待名单
|
||||
│ ├── TestFlight
|
||||
│ ├── App Store 页面
|
||||
│ └── 未来安卓应用商店页面
|
||||
│
|
||||
└── 品牌资产
|
||||
├── 独立开发者人设
|
||||
├── 产品更新日志
|
||||
├── 公开构建记录
|
||||
├── 用户案例
|
||||
└── 教程 / 内容矩阵
|
||||
```
|
||||
|
||||
### 7.2 早期营销重点
|
||||
|
||||
第一阶段不建议一上来投广告。
|
||||
|
||||
更适合个人开发者的是：
|
||||
|
||||
- 公开构建。
|
||||
- 发产品开发过程。
|
||||
- 发目标用户关心的内容。
|
||||
- 做竞品拆解。
|
||||
- 收集等待名单。
|
||||
- 找 TestFlight 内测用户。
|
||||
- 上架前提前预热。
|
||||
|
||||
### 7.3 营销不是上线后才做
|
||||
|
||||
正确节奏是：
|
||||
|
||||
```text
|
||||
有想法 → 发内容验证 → 收集潜在用户 → 邀请内测 → 修改产品 → 上架 → 继续增长
|
||||
```
|
||||
|
||||
而不是：
|
||||
|
||||
```text
|
||||
闭门开发三个月 → 上架 → 才开始想怎么推广
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 8. 模块五：运营与客服模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 用户来了以后，怎么服务、留住、收集反馈？
|
||||
|
||||
### 8.1 早期运营不用太重
|
||||
|
||||
第一阶段不需要复杂社群、返现活动、客服机器人。
|
||||
|
||||
更适合的是：
|
||||
|
||||
| 子模块 | 第一阶段做法 |
|
||||
| ------ | ------------------ |
|
||||
| 用户反馈 | App 内反馈入口 / 邮箱 |
|
||||
| FAQ | 简单常见问题页面 |
|
||||
| 内测群 | 小规模 TestFlight 用户群 |
|
||||
| 客服 | 邮箱或表单即可 |
|
||||
| 用户留存 | 提醒、打卡、历史记录、核心价值回访 |
|
||||
| Bug 收集 | 崩溃监控 + 用户反馈 |
|
||||
|
||||
### 8.2 运营的核心目的
|
||||
|
||||
早期运营不是为了显得热闹，而是为了回答：
|
||||
|
||||
- 用户有没有完成核心动作？
|
||||
- 用户哪里卡住？
|
||||
- 用户为什么第二天不回来？
|
||||
- 用户为什么不付费？
|
||||
- 用户愿意为哪个功能付费？
|
||||
|
||||
***
|
||||
|
||||
## 9. 模块六：数据、反馈与迭代模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 怎么判断产品方向是否值得继续？
|
||||
|
||||
这是很多新手容易忽略，但非常重要的模块。
|
||||
|
||||
### 9.1 关键数据指标
|
||||
|
||||
| 指标 | 意义 |
|
||||
| ----- | ------------- |
|
||||
| 下载量 | 获客是否有效 |
|
||||
| 激活率 | 用户是否完成第一次核心操作 |
|
||||
| 次日留存 | 产品是否有第一价值 |
|
||||
| 7 日留存 | 产品是否有持续需求 |
|
||||
| 付费点击率 | 用户是否对付费感兴趣 |
|
||||
| 付费转化率 | 商业模式是否成立 |
|
||||
| 取消订阅率 | 持续价值是否不足 |
|
||||
| 退款率 | 用户是否觉得不值 |
|
||||
| 崩溃率 | 产品是否稳定 |
|
||||
| 用户反馈 | 下一版应该改什么 |
|
||||
|
||||
### 9.2 早期最重要的问题
|
||||
|
||||
```text
|
||||
用户是否真的需要？
|
||||
用户是否愿意反复使用？
|
||||
用户是否愿意付费？
|
||||
收入是否覆盖成本？
|
||||
```
|
||||
|
||||
### 9.3 迭代原则
|
||||
|
||||
不要凭感觉加功能。
|
||||
|
||||
每次迭代都应该围绕一个目标：
|
||||
|
||||
- 提高激活率。
|
||||
- 提高留存率。
|
||||
- 提高付费转化。
|
||||
- 降低退款率。
|
||||
- 降低 AI / 服务器成本。
|
||||
- 减少用户操作步骤。
|
||||
- 修复影响体验的核心问题。
|
||||
|
||||
***
|
||||
|
||||
## 10. 模块七：合规与公司化模块
|
||||
|
||||
这个模块回答的是：
|
||||
|
||||
> 怎么合法上架、收款、扩展到国内平台？
|
||||
|
||||
### 10.1 第一阶段：Apple 个人开发者阶段
|
||||
|
||||
第一阶段重点是 Apple 生态内的合规：
|
||||
|
||||
| 项目 | 是否重点 |
|
||||
| ------------------ | ------------------ |
|
||||
| Apple Developer 账号 | 是 |
|
||||
| App Store Connect | 是 |
|
||||
| 隐私政策 | 是 |
|
||||
| 用户协议 | 建议 |
|
||||
| App Privacy 数据声明 | 是 |
|
||||
| 权限说明 | 是 |
|
||||
| IAP / 订阅说明 | 如果收费，必须重视 |
|
||||
| 第三方 SDK 数据说明 | 如果用了 SDK，需要 |
|
||||
| 公司注册 | 暂时不急 |
|
||||
| 对公账户 | 暂时不急 |
|
||||
| ICP 备案 | 暂时不急，视国内网站/服务器情况而定 |
|
||||
| 微信/支付宝商户 | 暂时不急 |
|
||||
|
||||
### 10.2 第二阶段：国内安卓 / 公司化阶段
|
||||
|
||||
等 Apple 端验证出收入后，再考虑：
|
||||
|
||||
- 注册公司。
|
||||
- 开对公账户。
|
||||
- 申请微信支付商户。
|
||||
- 申请支付宝商户。
|
||||
- 国内安卓应用商店开发者账号。
|
||||
- APP 备案。
|
||||
- ICP 备案。
|
||||
- 国内版隐私政策。
|
||||
- 国内版用户协议。
|
||||
- SDK 合规清单。
|
||||
- 如果是 AI 产品，还要关注内容安全、生成式 AI 相关要求。
|
||||
|
||||
### 10.3 公司化的触发条件
|
||||
|
||||
不是一开始就公司化，而是出现这些信号后再考虑：
|
||||
|
||||
- Apple 端有稳定收入。
|
||||
- 用户不是朋友，而是陌生人自然付费。
|
||||
- 月收入能覆盖服务器、AI API、工具等成本。
|
||||
- 退款率不高。
|
||||
- 获客渠道能持续带来用户。
|
||||
- 你已经验证了这个方向值得投入更多时间和钱。
|
||||
|
||||
***
|
||||
|
||||
## 11. 推荐阶段路线图
|
||||
|
||||
### 阶段 0：确定方向
|
||||
|
||||
目标：找到一个值得做的小切口。
|
||||
|
||||
要做：
|
||||
|
||||
- 选 2-3 个产品想法。
|
||||
- 找竞品。
|
||||
- 看差评。
|
||||
- 找目标用户聊天。
|
||||
- 明确第一版 MVP。
|
||||
- 写一句话定位。
|
||||
|
||||
产出：
|
||||
|
||||
```text
|
||||
目标用户 + 使用场景 + 核心痛点 + MVP 功能 + 收费方式假设
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### 阶段 1：iOS MVP 开发
|
||||
|
||||
目标：做出第一个可测试版本。
|
||||
|
||||
要做：
|
||||
|
||||
- iOS 客户端。
|
||||
- 核心功能。
|
||||
- 简单数据存储。
|
||||
- 必要的后端。
|
||||
- AI API 接入。
|
||||
- 反馈入口。
|
||||
- 基础数据统计。
|
||||
- 崩溃监控。
|
||||
- 如果收费，接 Apple IAP。
|
||||
|
||||
不做：
|
||||
|
||||
- 安卓。
|
||||
- 微信支付。
|
||||
- 支付宝。
|
||||
- 复杂后台。
|
||||
- 大规模社群。
|
||||
- 公司化。
|
||||
- 国内应用商店。
|
||||
|
||||
***
|
||||
|
||||
### 阶段 2：TestFlight 内测
|
||||
|
||||
目标：找到真实用户测试。
|
||||
|
||||
要做：
|
||||
|
||||
- 邀请 20-50 个真实用户。
|
||||
- 观察他们是否完成核心动作。
|
||||
- 收集反馈。
|
||||
- 修 Bug。
|
||||
- 简化流程。
|
||||
- 验证是否有人愿意付费。
|
||||
|
||||
重点问题：
|
||||
|
||||
```text
|
||||
用户会不会第二天回来？
|
||||
用户会不会主动反馈？
|
||||
用户会不会觉得这个产品值得付费？
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### 阶段 3：App Store 上架
|
||||
|
||||
目标：正式发布 Apple 版本。
|
||||
|
||||
要做：
|
||||
|
||||
- App Store Connect 信息。
|
||||
- App 名称。
|
||||
- 副标题。
|
||||
- 关键词。
|
||||
- 截图。
|
||||
- 描述。
|
||||
- 隐私政策。
|
||||
- 用户协议。
|
||||
- 审核说明。
|
||||
- IAP 产品审核。
|
||||
- 首发推广内容。
|
||||
|
||||
***
|
||||
|
||||
### 阶段 4：验证盈利
|
||||
|
||||
目标：证明产品不是玩具，而是小生意。
|
||||
|
||||
要看：
|
||||
|
||||
- 下载量。
|
||||
- 激活率。
|
||||
- 次日留存。
|
||||
- 7 日留存。
|
||||
- 付费转化率。
|
||||
- 取消订阅率。
|
||||
- 退款率。
|
||||
- AI API 成本。
|
||||
- 服务器成本。
|
||||
- 月利润。
|
||||
|
||||
判断标准：
|
||||
|
||||
```text
|
||||
是否有人持续使用？
|
||||
是否有人自然付费？
|
||||
收入是否能覆盖成本？
|
||||
是否值得继续投入？
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### 阶段 5：公司化与安卓扩展
|
||||
|
||||
目标：在 Apple 跑通后，扩大市场。
|
||||
|
||||
要做：
|
||||
|
||||
- 注册公司。
|
||||
- 对公账户。
|
||||
- 微信支付。
|
||||
- 支付宝。
|
||||
- 国内安卓客户端。
|
||||
- 国内应用商店上架。
|
||||
- APP 备案。
|
||||
- ICP 备案。
|
||||
- 国内合规材料。
|
||||
- 多支付通道统一到后端权益系统。
|
||||
|
||||
***
|
||||
|
||||
## 12. 最小可执行任务清单
|
||||
|
||||
### 12.1 今天可以做
|
||||
|
||||
- 写出一句话产品定位。
|
||||
- 列出 5 个竞品。
|
||||
- 看竞品差评。
|
||||
- 写出第一版只做的 1 个核心功能。
|
||||
- 判断是否需要 AI。
|
||||
- 判断是否需要后端。
|
||||
- 判断第一版是否收费。
|
||||
|
||||
### 12.2 本周可以做
|
||||
|
||||
- 画 5-8 个核心页面草图。
|
||||
- 写 MVP 功能清单。
|
||||
- 写不做清单。
|
||||
- 找 5-10 个目标用户聊天。
|
||||
- 做一个简单落地页或等待名单。
|
||||
- 注册或准备 Apple Developer 账号。
|
||||
- 规划数据指标。
|
||||
|
||||
### 12.3 一个月内可以做
|
||||
|
||||
- 做出 iOS MVP。
|
||||
- 接入基础统计和崩溃监控。
|
||||
- 准备隐私政策和用户协议。
|
||||
- 发起 TestFlight 内测。
|
||||
- 收集第一批真实反馈。
|
||||
|
||||
***
|
||||
|
||||
## 13. 不做清单
|
||||
|
||||
早期一定要克制。
|
||||
|
||||
第一阶段不要急着做：
|
||||
|
||||
- 安卓端。
|
||||
- 小程序。
|
||||
- Web 完整版。
|
||||
- 微信支付。
|
||||
- 支付宝。
|
||||
- 复杂后台。
|
||||
- 积分系统。
|
||||
- 排行榜。
|
||||
- 社交系统。
|
||||
- 大规模社群。
|
||||
- 自动客服机器人。
|
||||
- 复杂活动运营。
|
||||
- 公司注册。
|
||||
- 国内全渠道上架。
|
||||
|
||||
除非这些是产品核心，否则都可以延后。
|
||||
|
||||
***
|
||||
|
||||
## 14. 最终总结
|
||||
|
||||
你的整体路线可以总结为：
|
||||
|
||||
```text
|
||||
先做一个小而清晰的 iOS MVP
|
||||
↓
|
||||
用 Apple 平台验证需求和付费
|
||||
↓
|
||||
通过数据判断产品是否值得继续
|
||||
↓
|
||||
收入稳定后再公司化
|
||||
↓
|
||||
扩展国内安卓、微信支付、支付宝和国内应用商店
|
||||
```
|
||||
|
||||
一句话：
|
||||
## 一、核心策略
|
||||
|
||||
> **长期按完整互联网产品架构设计，短期按 Apple-first 路线执行；先验证，后扩张。**
|
||||
|
||||
当前最需要验证的是：
|
||||
|
||||
```
|
||||
有人需要 → 有人愿意用 → 有人愿意付费 → 收入能覆盖成本
|
||||
```
|
||||
|
||||
**不是一开始做全平台、全支付、全合规**，而是先用 Apple 平台做低成本验证。
|
||||
|
||||
---
|
||||
|
||||
## 二、产品总览
|
||||
|
||||
| 维度 | 决策 |
|
||||
|------|------|
|
||||
| 产品名 | 知习 ZhiXi |
|
||||
| 定位 | AI 驱动的系统化学习工具 |
|
||||
| 核心闭环 | 知识库 → 主动回忆 → AI 分析 → 薄弱点 → 间隔复习 → 趋势 |
|
||||
| 第一版平台 | iPhone + 官网 |
|
||||
| 变现模式 | 免费版 + 单一 Pro 订阅 |
|
||||
| 定价 | 中国 ¥29/月，海外 $9.99/月 |
|
||||
| 当前阶段 | 方向验证 + iPhone MVP |
|
||||
|
||||
---
|
||||
|
||||
## 三、7 大项目模块
|
||||
|
||||
```
|
||||
个人开发者创业项目
|
||||
│
|
||||
├── 1. 产品与用户模块 → 方向、用户、MVP 闭环
|
||||
├── 2. 技术与交付模块 → 技术栈、AI 架构、工程策略
|
||||
├── 3. 商业化与支付模块 → 定价、订阅、权益
|
||||
├── 4. 营销与增长模块 → 获客、内容、冷启动
|
||||
├── 5. 运营与客服模块 → Dify 客服、工单、用户运营
|
||||
├── 6. 数据反馈与迭代模块 → 指标、埋点、迭代
|
||||
└── 7. 合规与公司化模块 → 上架合规、公司化时机
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、阶段路线图
|
||||
|
||||
| 阶段 | 目标 | 状态 |
|
||||
|------|------|------|
|
||||
| 0 | 项目定盘 + 官网基础设施 | ✅ 官网基础页面已完成 |
|
||||
| 1 | 选择第一个垂直知识库方向 | 🔲 待打分决策 |
|
||||
| 2 | 设计 MVP 学习闭环 | ✅ 已设计 |
|
||||
| 3 | iPhone MVP 开发 | 🔲 前后端待接通 |
|
||||
| 4 | TestFlight 内测 | 🔲 Apple 账号审核中 |
|
||||
| 5 | App Store 上架 | 🔲 |
|
||||
| 6 | 验证盈利 | 🔲 |
|
||||
| 7 | iPad / Mac 扩展 | 🔲 |
|
||||
| 8 | 公司化与安卓扩展 | 🔲 |
|
||||
|
||||
> 详见：[阶段路线图](./0-阶段路线图/阶段路线图.md)
|
||||
|
||||
---
|
||||
|
||||
## 五、当前状态
|
||||
|
||||
| 模块 | 进度 | 关键缺口 |
|
||||
|------|------|----------|
|
||||
| iOS App | 21 页面 UI 完成 | NavigationLink 编译问题、API Service 未接通、MVVM 未分层 |
|
||||
| 后端 API | 13 模块骨架 | Repository 未接 MySQL、BullMQ 未接 Redis、AI 走 Mock |
|
||||
| 官网 | 基础页面上线 | Waitlist/Support 表单未接后端、品牌名不统一、CSS 变量缺失 |
|
||||
| 数据库 | MySQL + Redis 已部署 | 代码未走 Prisma |
|
||||
| 方向验证 | 3 个候选方向 | 未打分选定，未准备知识库内容 |
|
||||
|
||||
> 详见：[潜在问题清单](../潜在问题清单.md)
|
||||
|
||||
---
|
||||
|
||||
## 六、各模块文档索引
|
||||
|
||||
| 模块 | 主文档 | 子文档 |
|
||||
|------|--------|--------|
|
||||
| 1. 产品与用户 | [产品与用户模块](./1-产品与用户模块/产品与用户模块.md) | — |
|
||||
| 2. 技术与交付 | [技术与交付模块](./2-技术与交付模块/技术与交付模块.md) | [AI架构设计](./2-技术与交付模块/AI架构设计.md) |
|
||||
| 3. 商业化与支付 | [商业化与支付模块](./3-商业化与支付模块/商业化与支付模块.md) | — |
|
||||
| 4. 营销与增长 | [营销与增长模块](./4-营销与增长模块/营销与增长模块.md) | [营销冷启动调研方案](./4-营销与增长模块/营销冷启动调研方案.md) |
|
||||
| 5. 运营与客服 | [运营与客服模块](./5-运营与客服模块/运营与客服模块.md) | [客服设计详案](./5-运营与客服模块/客服设计详案.md) |
|
||||
| 6. 数据反馈与迭代 | [数据反馈与迭代模块](./6-数据反馈与迭代模块/数据反馈与迭代模块.md) | — |
|
||||
| 7. 合规与公司化 | [合规与公司化模块](./7-合规与公司化模块/合规与公司化模块.md) | — |
|
||||
|
||||
---
|
||||
|
||||
## 七、下一步行动
|
||||
|
||||
1. **选定垂直知识库方向**（3 候选 → 打分 → 选 1）
|
||||
2. **准备第一个 7 天路径的内容**
|
||||
3. **修复 iOS 编译问题 + Repository 接 Prisma + iOS 换 HTTPS**
|
||||
4. **做 3-5 个竞品拆解**
|
||||
5. **跑一次真实用户触达**（小红书/B站发内容，收集等待名单）
|
||||
|
||||
161
潜在问题清单.md
Normal file
161
潜在问题清单.md
Normal file
@ -0,0 +1,161 @@
|
||||
# 潜在问题清单
|
||||
|
||||
> 基于 `思路梳理.md` 的 9 项已知问题之外，逐层审查代码后发现的问题。
|
||||
> 更新时间：2026-05-12
|
||||
|
||||
---
|
||||
|
||||
## 🔴 严重（会阻断编译 / 上线 / 安全）
|
||||
|
||||
| # | 位置 | 问题 | 后果 |
|
||||
|---|------|------|------|
|
||||
| 1 | 后端 13 个 Repository 全部 | 数据只存内存 `Map`，没有调 Prisma 写 MySQL。服务器上已有 MySQL，但代码不走它。 | 服务重启 = 全量数据丢失 |
|
||||
| 2 | 后端 `infrastructure/queue/queue.service.ts` | 队列是内存数组 `push/shift`，不是 BullMQ，没接 Redis | 队列任务重启丢失，无可靠异步处理 |
|
||||
| 3 | 后端 3 个 Worker 文件 | 全是空壳（只有 `console.log` + `setInterval`），没有真正消费队列 | 异步任务（AI分析/导入/通知）全部未生效 |
|
||||
| 4 | 后端 `.gitea/workflows/deploy.yml` | 数据库密码、Redis 密码、JWT Secret、Swagger 密码全部明文硬编码 | 任何人拿到仓库就能访问生产环境 |
|
||||
| 5 | 后端 `服务器密钥/WangDL.pem` | SSH 密钥已提交到 Git，`.gitignore` 没排除 | 密钥泄露风险 |
|
||||
| 6 | iOS 全部 View 文件 | 自定义 `NavigationLink(destination:label:)` 没有定义，SwiftUI 原生签名不同 | **项目无法编译** |
|
||||
| 7 | iOS `Core/Network/APIConfig.swift` + `Info.plist` | `baseURL` 使用 `http://` 明文，`NSAllowsArbitraryLoads = true` | **App Store 审核必然被拒** |
|
||||
|
||||
---
|
||||
|
||||
## 🟠 高危（功能主链路断裂）
|
||||
|
||||
| # | 位置 | 问题 | 后果 |
|
||||
|---|------|------|------|
|
||||
| 8 | 后端 `auth.service.ts` L154-158 | Apple 登录实际未接入，走 mock（`verifyRealApple` 直接抛异常） | 用户认证链无效（虽账号刚开通，但代码需要准备好） |
|
||||
| 9 | 后端 `modules/` 大部分 Controller | 10 个 Controller 没有 `@UseGuards(JwtAuthGuard)`，或使用 `user?.id \|\| 'anonymous'` 降级 | 未登录可调用知识库/AI分析/学习记录等接口 |
|
||||
| 10 | 后端 `ai-analysis.service.ts` L61-78 | `.then().catch()` 未 await，fire-and-forget | AI 分析异常静默丢失 |
|
||||
| 11 | iOS `Core/Network/APIClient.swift` L11 | Token 只存 `actor` 内 `var token: String?`，没写 Keychain | 杀进程重启就要重新登录 |
|
||||
| 12 | iOS 全部 View | `APIService` 有 8 个 Service 类（20+ 方法），但没有任何 View 调用它们。所有数据硬编码。 | 前后端完全断开 |
|
||||
| 13 | iOS Tests 全部 4 个文件 | 引用的 `ReviewPlanViewModel`、`StudyHomeViewModel`、`AIChatViewModel`、`FileCache` 全不存在 | 测试无法编译 |
|
||||
| 14 | 官网 `WaitlistForm.astro` L83-95 | 提交事件只 `e.preventDefault()` 然后显示假成功，没有 `fetch()` | 等待名单完全无效 |
|
||||
| 15 | 官网 `support.astro` | 反馈表单无任何 JS 处理，无 `action`/`method`，提交即刷新丢失 | 支持/反馈功能无效 |
|
||||
|
||||
---
|
||||
|
||||
## 🟡 中危（体验 / 架构债务）
|
||||
|
||||
| # | 位置 | 问题 | 后果 |
|
||||
|---|------|------|------|
|
||||
| 16 | iOS 全部 View | 零 ViewModel 分层，所有逻辑写在 View `@State` 里，无 `@StateObject`/`@Published` | 代码不可测试，日后重构极其困难 |
|
||||
| 17 | iOS 全部 View | 零加载态（Loading）、零错误态（Error）、零空态（Empty） | 用户体验极差，网络出错无提示 |
|
||||
| 18 | iOS 无任何持久化 | 没有 CoreData/SwiftData/UserDefaults 持久层，无离线缓存 | 断网完全不能用 |
|
||||
| 19 | iOS `SettingsView` / `LibrarySubpages` | 所有保存/提交按钮的闭包是 `{}` 空的，点了无任何反应 | 设置和创建知识库等全部失效 |
|
||||
| 20 | iOS `zh-Hans.lproj/Localizable.strings` | 180+ key 已写好，但没有一个 View 用 `NSLocalizedString` | 多语言架构白写了 |
|
||||
| 21 | 后端 `common/utils/rate-limit.service.ts` | 限流 Service 写好了但没在任何 Module 注册，没在任何 Controller 使用 | 零限流保护 |
|
||||
| 22 | 后端 `common/interceptors/response.interceptor.ts` | 拦截器写好了但没全局或局部注册 | 响应格式不一致 |
|
||||
| 23 | 后端 大部分 Controller | `@Body() body: any` 无 DTO class | 无输入校验，恶意 payload 直通 |
|
||||
| 24 | 后端 `document-import.service.ts` | 用 3 层 `setTimeout` 模拟处理，无真正文件解析 | 资料导入完全无效 |
|
||||
| 25 | 后端 `infrastructure/storage/` | 只有 `getUploadPath()` 和 `healthCheck()`，没有真正的读写/上传 | 文件上传完全无效 |
|
||||
| 26 | 后端 `main.ts` | 无 `enableShutdownHooks()` | SIGTERM 时请求被硬断，连接不排空 |
|
||||
| 27 | 后端 ID 类型 | Prisma schema 用 `BigInt`，所有代码生成 `string` ID | 接 Prisma 时全部 ID 逻辑要重写 |
|
||||
| 28 | 后端 所有 list 接口 | `PaginationDto` 写好了但无接口使用 | 无分页，数据量大时撑不住 |
|
||||
| 29 | 后端 `prisma/migrations/` | 无 migration 目录 | 数据库 schema 变更无版本管理 |
|
||||
|
||||
---
|
||||
|
||||
## 🟢 低危（清理 / 微调）
|
||||
|
||||
| # | 位置 | 问题 |
|
||||
|---|------|------|
|
||||
| 30 | 官网 `src/styles/global.css` | 7 个 CSS 自定义属性（`--color-accent`、`--color-text` 等）未定义，Tailwind v4 变量名不一致 |
|
||||
| 31 | 官网品牌名 | "知习 AI" 和 "龙德AI学习" 两个名字混用，约各占一半页面 |
|
||||
| 32 | 官网 `sitemap.xml.astro` | 缺少 `/product` 和 `/philosophy`，`lastmod` 生成时间全是"今天" |
|
||||
| 33 | 官网 `BaseLayout.astro` L12 | `og-default.png` 不存在，所有页面社交分享无缩略图 |
|
||||
| 34 | 官网 `robots.txt` | 写死 `Sitemap: http://localhost:4321/sitemap.xml` |
|
||||
| 35 | 官网 `support.astro` / `privacy.astro` | 绕过 `BaseLayout`，缺失所有 SEO meta 标签 |
|
||||
| 36 | 后端 Swagger | 生产环境 `ENABLE_SWAGGER=true`，且密码硬编码在 deploy.yml |
|
||||
| 37 | 后端 无 `docker-compose.yml` | 文档写了但没创建，本地无法一键起全栈 |
|
||||
| 38 | 后端 E2E 测试 | `test/app.e2e-spec.ts` 期望 `Hello World!` 但根路径返回的是健康检查 JSON |
|
||||
| 39 | iOS 无崩溃监控 | 无 Crashlytics / Sentry / 自建监控 |
|
||||
| 40 | iOS 无推送 | 无 `BGTaskScheduler`，无 Push Notification 注册 |
|
||||
|
||||
---
|
||||
|
||||
## 📊 统计
|
||||
|
||||
| 等级 | 数量 |
|
||||
|------|------|
|
||||
| 🔴 严重 | 7 |
|
||||
| 🟠 高危 | 8 |
|
||||
| 🟡 中危 | 14 |
|
||||
| 🟢 低危 | 11 |
|
||||
|- **合计（技术向）** | **40** |
|
||||
|
||||
---
|
||||
|
||||
## 🧭 项目方向 / 策略层遗漏（非技术问题）
|
||||
|
||||
> 这些是你现有的规划文档中提到但未实质性推进、或根本没被覆盖的问题。
|
||||
|
||||
| # | 类别 | 问题 | 现状 | 为什么重要 |
|
||||
|---|------|------|------|-----------|
|
||||
| D1 | **方向决策** | 3 个候选方向至今未选定 | `方向验证.md` 列出了公考申论 / AI工具学习 / 前端面试三个方向，评分维度也写了，但没打分没结论 | 代码已经写了 21 个页面 + 13 个后端模块，但还不知道往哪个垂直方向走。按计划"先选方向再做产品"，现在反了 |
|
||||
| D2 | **竞品分析** | 零竞品拆解 | 文档多次提"做竞品分析表""看竞品差评"，但没有任何竞品文档 | 没有竞品分析就无法定义差异化，也不知道当前方向是否已红海 |
|
||||
| D3 | **第一个知识库内容** | 没有开始准备内容 | 计划反复强调"只做一个7天路径"，但没有任何内容草稿 | 产品核心价值是 AI + 结构化知识库，AI 链路通了但内容没准备，学什么？ |
|
||||
| D4 | **范围失控** | 实际代码远超 MVP 计划 | 计划要求 8 个 P0 模块、8-14 页、不做 Worker/导入/通知；实际做了 13 模块、21 页、3 Worker、文档导入骨架 | 每多做一个未验证的模块都是成本，而且在方向没确定前做这些是风险 |
|
||||
| D5 | **AI 成本模型** | 没算过真实的 AI 调用成本 | 计划提了"成本失控"的警惕，但没有具体数字：每用户每天几次调用、每次多少 token、月成本预估 | 不收钱还好，一旦内测量大或定价，成本算不清就没办法定价，也没办法判断盈亏 |
|
||||
| D6 | **验证的硬性退出条件** | 没有"什么是验证失败"的定义 | `方向验证.md` 有最低目标（50条原话、10份问卷等），但没有明确时间节点和放弃标准 | 容易陷进"再试试"的循环，没有止损线 |
|
||||
| D7 | **定价策略** | `商业化与支付模块.md` 只是目录骨架 | 没有月订阅/年订阅的具体金额、没有竞品价格对比、没有用户付费意愿数据 | 这是你 `思路梳理.md` 第 9 条自己写的，但完全没推进 |
|
||||
| D8 | **季节性风险** | 公考/面试方向有强时间窗口 | 公务员考试有固定报名和考试周期，错过窗口期获客成本急剧上升 | 如果选定公考方向但不卡时间发布，第一波内测可能完全找不到备考用户 |
|
||||
| D9 | **用户输入意愿风险** | 没提出降低输入门槛的方案 | `Demo与MVP.md` 自己写了"用户不愿意主动输入内容"是最大风险之一，但没有给缓解策略 | 学习闭环的核心是用户写笔记/回答，如果用户跳过这一步，整个链条断了 |
|
||||
| D10 | **内容持续供给** | 知识库由谁维护、更新节奏 | 产品定位是"AI驱动的学习系统"，但内容来源方案停在"合法整理"这四个字上 | 一个 7 天路径学完就没新内容了，用户不回来。没有持续的内容生产计划 |
|
||||
| D11 | **AI 分析质量的验证标准** | 没有产品侧的 AI 效果验收机制 | AI 分析输出的是掌握度/薄弱点/建议，但没有说"多准确算合格"，谁来验收 | 如果 AI 分析结果用户觉得不靠谱，产品核心价值崩塌。需要真人验证标准 |
|
||||
| D12 | **Prompt 管理策略** | 没有 Prompt 版本管理和效果追踪 | `BACKEND-PLAN.md` 设计了 prompts/ 目录和 Provider 抽象，但没有 prompt A/B 测试、效果对比、迭代机制 | Prompt 是这个产品的核心资产之一，随缘改会越来越差 |
|
||||
| D13 | **品牌定位** | 品牌名都不统一 | 官网页面和 app 里"知习 AI"和"龙德AI学习"混用，没有正式品牌命名文档 | 内测用户看到两个名字会很困惑，不利于口碑传播 |
|
||||
| D14 | **内测用户获取** | 没有用户触达的路径验证 | 计划写了小红书/B站/知乎 + 等待名单，但等待名单在官网上是假的，没有跑过一次真实用户获取 | 方向验证的第一步"看评论区"还没批量执行过 |
|
||||
| D15 | **上线后运营** | 零运营准备 | 计划有 `运营与客服模块.md` 但只是目录，没有客服响应 SLA、没有内测群管理方案、没有版本发布沟通流程 | TestFlight 内测用户遇到问题找谁？等多久？怎么反馈给你？全没定义 |
|
||||
| D16 | **隐私合规落空** | 官网隐私政策是用 AI 生成的模板 | `privacy.astro` 内容很长但法律有效性存疑；`App Privacy` 数据声明没准备 | App Store 上架时 Apple 会严格审查隐私声明，模板可能被退回 |
|
||||
|
||||
---
|
||||
|
||||
## 📊 统计（含方向）
|
||||
|
||||
| 等级 | 数量 |
|
||||
|------|------|
|
||||
| 🔴 严重（技术） | 7 |
|
||||
| 🟠 高危（技术） | 8 |
|
||||
| 🟡 中危（技术） | 14 |
|
||||
| 🟢 低危（技术） | 11 |
|
||||
| 🧭 方向/策略 | 16 |
|
||||
| **合计** | **56** |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 建议优先修复顺序
|
||||
|
||||
```
|
||||
第 0 批（现在，不写代码）：
|
||||
D1 选定一个垂直方向并打分 → 不选方向后面都是浪费
|
||||
D2 做 3-5 个竞品拆解 → 知道差异化在哪
|
||||
D3 准备第一个 7 天路径的内容 → 没内容验证不了学习闭环
|
||||
D4 砍掉 MVP 不需要的模块和页面 → 别再继续膨胀了
|
||||
|
||||
第 1 批（技术底线，本周）：
|
||||
#6 iOS NavigationLink 编译问题 → 让项目能跑
|
||||
#1 Repository 接 Prisma + MySQL → 数据能落库
|
||||
#4 CI/CD 密钥脱敏 → 安全底线
|
||||
#5 删除或 gitignore WangDL.pem → 安全底线
|
||||
#7 iOS 换 HTTPS → App Store 上架要求
|
||||
|
||||
第 2 批（功能链路，下周）：
|
||||
D5 算清 AI 单用户月成本 → 为定价打底
|
||||
#2 Queue 接 BullMQ + Redis → 异步链路通
|
||||
#8 Apple 登录接入 → 认证链路通
|
||||
D14 跑一次真实用户获取 → 开始验证方向
|
||||
#14 官网 Waitlist 接后端 API → 等待名单能用
|
||||
#12 iOS View 调 APIService → 前后端打通
|
||||
D13 统一品牌名 → 知习 or 龙德，选一个
|
||||
|
||||
第 3 批（内测前）：
|
||||
D6 设定验证退出条件和时间节点 → 有止损线
|
||||
D9 设计输入降门槛方案 → 解决最大风险
|
||||
D11 定 AI 分析质量验收标准 → 产品核心价值要可控
|
||||
#9 各 Controller 加 Auth Guard → 接口安全
|
||||
#11 Token 写 Keychain → 登录持久化
|
||||
#16 iOS MVVM 分层 → 代码可维护
|
||||
#17 iOS 加载/错误/空态 → 体验完整
|
||||
D15 准备内测运营方案 → TestFlight 用户有处可去
|
||||
D16 检查隐私政策合规性 → App Store 审核不被拒
|
||||
```
|
||||
Loading…
x
Reference in New Issue
Block a user