20 changed files with 3411 additions and 1646 deletions
--- a/images/logo.png
+++ b/images/logo.png
--- a/images/产品图.png
+++ b/images/产品图.png
--- a/images/产品图2.png
+++ b/images/产品图2.png
--- a/v0.1/.gitignore
+++ b/v0.1/.gitignore
@ -0,0 +1,2 @@
 .claude/
 .claude*
--- a/v0.1/0-项目总纲/项目总纲.md
+++ b/v0.1/0-项目总纲/项目总纲.md
@ -0,0 +1,46 @@
 # 项目总纲
 ## 当前版本
 个人开发者创业计划 v0.1
 ## 当前目标
 先不做完整产品，也不做完整公司规划。
 当前只做三件事：
 1. 确定第一个学习方向是否值得做。
 2. 做出一个 14 天验证型 Demo。
 3. 用 Demo 找到第一批真实反馈。
 ## 产品长期方向
 AI 驱动的系统化学习产品：
 - 知识库
 - 笔记
 - AI 学习教练
 - 复习计划
 ## 当前候选方向
 1. 公考申论 AI 学习教练
 2. AI 工具学习知识库
 3. 程序员 / 前端面试学习助手
 ## 当前原则
 - 不做完整平台
 - 不做泛学习大而全产品
 - 不做 Android
 - 不注册公司
 - 不接微信/支付宝支付
 - 不做复杂后端
 - 不做完整知识库
 - 先做 Demo 和验证
 ## 相关文档
 - [方向验证](../1-方向验证/方向验证.md)
 - [Demo与MVP](../2-Demo与MVP/Demo与MVP.md)
--- a/v0.1/1-方向验证/方向验证.md
+++ b/v0.1/1-方向验证/方向验证.md
@ -0,0 +1,103 @@
 # 方向验证
 ## 当前问题
 现在不能直接确定做公考申论，因为创始人对该领域不够熟悉。
 当前需要验证：
 1. 公考申论用户是否真的需要 AI 学习工具。
 2. 公考用户里 iPhone 用户是否足够。
 3. 用户是否愿意为 AI 批改、学习计划、复习提醒付费。
 4. 这个方向的内容是否能合法整理。
 5. 创始人是否愿意持续研究这个领域。
 ## 候选方向
 ### 方向 A：公考申论 AI 学习教练
 **优点：**
 - 用户目标强
 - 付费意愿可能较高
 - 申论适合 AI 分析
 - 小红书/B站有获客可能
 **风险：**
 - 创始人不熟悉领域
 - 资料版权风险
 - 竞品强
 - 不确定 iPhone 用户比例
 ### 方向 B：AI 工具学习知识库
 **优点：**
 - 创始人熟悉
 - 内容更容易原创
 - AI 价值明显
 - 版权风险较低
 **风险：**
 - 用户付费意愿可能不如考试类
 - 泛学习容易散
 ### 方向 C：程序员 / 前端面试学习助手
 **优点：**
 - 创始人有前端背景
 - 用户目标较明确
 - 可以结合 AI 面试反馈
 **风险：**
 - 市场竞争强
 - 付费意愿需要验证
 ## 当前验证方式
 不主动高压私聊用户。
 先采用低社交压力验证：
 1. 看评论区
 2. 整理用户痛点
 3. 发小红书/B站内容
 4. 做等待名单
 5. 只联系主动感兴趣的人
 ## 相关文档
 - [项目总纲](../0-项目总纲/项目总纲.md)
 - [Demo与MVP](../2-Demo与MVP/Demo与MVP.md)
 ## 第一轮验证目标
 v0.1 阶段不追求大规模用户，只做低成本方向验证。
 第一轮最低目标：
 - 收集 50 条真实用户痛点原话
 - 发布 3 条小红书 / B站内容
 - 收集 10 份问卷或等待名单
 - 找到 3 个愿意内测的人
 - 至少确认 1 个方向存在真实需求
 ## 方向选择标准
 某个方向满足以下条件，可以进入 Demo 开发：
 1. 用户痛点集中，不是很分散。
 2. 有用户主动评论、私信或填写等待名单。
 3. 至少有 3 个用户愿意试用。
 4. 用户过去为类似问题花过钱。
 5. 创始人愿意持续研究这个方向至少 3 个月。
 6. 内容可以合法整理，不严重依赖侵权资料。
 ## 暂缓或放弃标准
 如果某个方向出现以下情况，暂缓：
 1. 内容发布后几乎没有反馈。
 2. 用户只是觉得有趣，但没有强需求。
 3. 用户不愿意留下联系方式。
 4. 内容生产成本过高。
 5. 版权风险太大。
 6. 创始人明显不想继续研究该领域。
--- a/v0.1/2-Demo与MVP/Demo与MVP.md
+++ b/v0.1/2-Demo与MVP/Demo与MVP.md
@ -0,0 +1,721 @@
 ---
 version: v0.1
 status: draft
 updated: 2026-05-03
 ---
 # Demo 与 MVP
 ## 1. 产品定位
 > 一个具备长期架构基础的最小可用学习产品雏形，不是一次性演示，也不是完整商业化产品。
 第一版只验证一个核心问题：
 > AI 驱动的知识库学习系统，是否能帮助用户从"被动看资料"变成"主动学习、反馈、复习和迭代"。
 ---
 ## 2. 核心原则
 ### 2.1 功能少，但闭环完整
 第一版必须跑通完整学习闭环：
 ```text
 注册 / 登录
        ↓
 选择学习方向
        ↓
 进入学习路径
        ↓
 阅读知识内容
        ↓
 主动回忆 / 写笔记 / 写答案
        ↓
 AI 分析
        ↓
 生成学习状态
        ↓
 给出复习和下一步建议
        ↓
 进入下一次学习
 ```
 ### 2.2 架构要可迭代
 第一版需要提前考虑：
 - 用户系统
 - 学习记录
 - 知识库结构
 - AI 分析结果结构
 - 用户学习画像
 - 多语言文案
 - 后续订阅权益
 - 后续 iPad / Mac / Android 扩展
 ### 2.3 AI 是核心
 第一版 AI 要承担三个核心职责：
 1. 分析用户输入
 2. 判断用户当前学习状态
 3. 给出下一步学习建议
 ---
 ## 3. 第一版目标用户
 当前候选方向：
 1. 公考申论 AI 学习教练
 2. AI 工具学习知识库
 3. 程序员 / 前端面试学习助手
 第一版用户画像：
 - 有明确学习目标的人
 - 愿意使用 AI 辅助学习的人
 - 不满足于单纯看资料的人
 - 希望系统帮自己制定学习路径的人
 - 愿意通过写笔记、回答问题、主动回忆来学习的人
 ---
 ## 4. 第一版产品形态
 ```text
 iPhone App
 +
 官网基础页面
 +
 最小后端
 +
 AI API
 ```
 第一版暂不做：
 - Android
 - Web 学习端
 - iPad 完整适配
 - Mac 完整版
 - B 端后台
 - 内容创作者后台
 - 社群系统
 - 支付系统
 ---
 ## 5. 账号体系
 ### 5.1 第一版需要登录
 原因：
 1. 学习记录需要跟随用户
 2. AI 分析结果需要沉淀到用户画像
 3. 复习计划需要长期保存
 4. 未来订阅权益需要绑定用户
 5. 后续多设备同步需要统一用户身份
 ### 5.2 第一版登录方式
 ```text
 Sign in with Apple
 ```
 暂不做：微信登录、手机号登录、邮箱密码登录、Google 登录、复杂账号安全系统。
 ### 5.3 用户身份模型
 ```text
 User
 ├── id
 ├── appleUserId
 ├── displayName
 ├── email
 ├── preferredLanguage
 ├── createdAt
 ├── lastLoginAt
 └── status
 ```
 ### 5.4 账号边界
 第一版账号只解决：登录、识别用户、保存学习记录、保存 AI 分析结果、保存基础偏好。
 暂不做：好友系统、用户主页、头像上传、账号注销自动化、多登录方式绑定、复杂权限系统。
 ---
 ## 6. 多语言基础
 ### 6.1 需要多语言结构
 原因：
 1. Apple 生态用户可能存在中英文环境
 2. 后续做海外市场不希望大量重构
 3. UI 文案、系统提示、AI Prompt 都需要可维护
 4. 多语言越晚做，返工成本越高
 ### 6.2 第一版多语言范围
 - App UI 文案支持多语言结构
 - 代码层面使用本地化资源
 - 默认语言为中文
 - 预留英文文案位置
 ### 6.3 支持语言
 ```text
 默认：简体中文
 预留：英文
 ```
 ---
 ## 7. 知识库设计
 ### 7.1 知识库不是资料堆积
 第一版知识库是结构化学习路径，包含：
 ```text
 KnowledgeBase
 ├── 学习方向
 ├── 学习路径
 ├── 模块
 ├── 小节
 ├── 学习任务
 ├── 主动回忆问题
 ├── 示例内容
 └── 复习节点
 ```
 ### 7.2 第一版知识库结构
 ```text
 知识库
 └── 学习路径
    └── 模块
        └── 小节
            ├── 正文内容
            ├── 学习目标
            ├── 重点概念
            ├── 主动回忆问题
            ├── 练习输入
            └── AI 分析规则
 ```
 ### 7.3 第一版内容范围
 第一版只做一个小路径，例如：
 - "申论小白 7 天入门路径"
 - 或 "AI 工具入门 7 天路径"
 ### 7.4 知识库最小数据模型
 ```text
 KnowledgeBase
 ├── id
 ├── title
 ├── description
 ├── language
 ├── targetUser
 ├── createdAt
 └── updatedAt
 LearningPath
 ├── id
 ├── knowledgeBaseId
 ├── title
 ├── description
 ├── estimatedDays
 └── order
 Lesson
 ├── id
 ├── pathId
 ├── title
 ├── content
 ├── objectives
 ├── keyPoints
 ├── recallQuestions
 ├── practicePrompt
 ├── order
 └── estimatedMinutes
 ```
 ---
 ## 8. 学习闭环设计
 ### 8.1 核心闭环
 ```text
 用户选择学习路径
        ↓
 系统展示今日任务
        ↓
 用户阅读内容
        ↓
 系统提出主动回忆问题
        ↓
 用户输入回答 / 笔记
        ↓
 AI 分析用户输入
        ↓
 系统生成学习状态
        ↓
 系统给出复习建议
 ```
 ### 8.2 主动回忆
 用户不能只是看资料。系统需要引导用户：
 - 用自己的话复述
 - 回答关键问题
 - 写出理解
 - 写出答案
 - 暴露自己的薄弱点
 ### 8.3 AI 分析维度
 ```text
 理解程度
 要点覆盖
 逻辑结构
 表达清晰度
 错误理解
 遗漏内容
 下一步建议
 ```
 ---
 ## 9. AI 学习状态模型
 ### 9.1 为什么需要
 如果 AI 不能准确判断用户状态，后续学习计划、复习建议、个性化推荐都会失效。
 第一版不追求完全准确，只追求：能用结构化方式记录用户当前学习情况，并支持后续迭代。
 ### 9.2 第一版学习状态维度
 ```text
 理解程度
 记忆程度
 表达能力
 完成情况
 薄弱点
 复习需求
 学习稳定性
 ```
 ### 9.3 用户学习画像
 ```text
 UserLearningProfile
 ├── userId
 ├── currentKnowledgeBaseId
 ├── currentPathId
 ├── currentLessonId
 ├── overallLevel
 ├── weakPoints
 ├── strengths
 ├── recentMistakes
 ├── reviewQueue
 ├── learningStreak
 └── updatedAt
 ```
 ### 9.4 单次学习记录
 ```text
 LearningSession
 ├── id
 ├── userId
 ├── lessonId
 ├── startedAt
 ├── endedAt
 ├── userInput
 ├── aiAnalysis
 ├── masteryScore
 ├── weakPoints
 ├── nextSuggestion
 └── reviewAt
 ```
 ### 9.5 掌握度评分（0-5分）
 ```text
 0 = 没有作答 / 无法判断
 1 = 基本没理解
 2 = 理解较弱
 3 = 基本理解
 4 = 理解较好
 5 = 掌握很好
 ```
 注意：这不是考试分数，只是产品内部用于安排复习和学习建议的参考值。
 ### 9.6 AI 输出结构
 ```json
 {
  "masteryScore": 3,
  "understandingLevel": "基本理解",
  "summary": "用户能说出核心意思，但要点不够完整。",
  "strengths": ["能识别主要问题", "表达比较清楚"],
  "weakPoints": ["遗漏关键要点", "逻辑层次不够清晰"],
  "suggestions": ["补充材料中的第二个要点", "回答时先概括问题，再展开原因"],
  "reviewNeeded": true,
  "nextAction": "建议明天复习本节，并重新回答主动回忆问题。"
 }
 ```
 ---
 ## 10. AI 对话页面
 ### 10.1 需要 AI 对话页
 原因：
 1. 用户会天然期待 AI 产品能提问
 2. 知识库学习中，用户经常会有即时疑问
 3. 对话页可以提升产品感知价值
 4. 对话数据可以反向帮助判断用户困惑点
 ### 10.2 对话页定位
 ```text
 围绕当前知识库和当前学习内容的学习助手
 ```
 它应该回答：
 - 这节内容是什么意思？
 - 我这个回答哪里不对？
 - 这个概念能不能举例？
 - 我应该怎么记？
 - 这个知识点和前面有什么关系？
 - 我下一步该怎么学？
 ### 10.3 对话页边界
 ```text
 只能围绕当前知识库
 只能围绕学习主题
 不能承诺考试结果
 不能生成违规内容
 不能替代专业老师
 ```
 ### 10.4 推荐快捷问题
 ```text
 帮我解释这一节
 用更简单的话讲
 给我举个例子
 我哪里理解错了
 帮我总结重点
 生成一个复习问题
 ```
 ---
 ## 11. 页面结构
 ### 11.1 第一版页面列表
 1. 启动页 / 欢迎页
 2. 登录页
 3. 语言与基础偏好页
 4. 学习方向选择页
 5. 学习路径页
 6. 今日学习任务页
 7. 内容阅读页
 8. 主动回忆 / 笔记输入页
 9. AI 分析结果页
 10. AI 对话页
 11. 复习计划页
 12. 学习进度页
 13. 设置页
 14. 反馈页
 ### 11.2 页面优先级
 **P0 必须做：**
 - 登录页
 - 学习方向选择页
 - 学习路径页
 - 今日学习任务页
 - 内容阅读页
 - 主动回忆 / 笔记输入页
 - AI 分析结果页
 - AI 对话页
 - 复习计划页
 **P1 建议做：**
 - 学习进度页
 - 设置页
 - 反馈页
 **P2 可以延后：**
 - 个人主页
 - 成就系统
 - 统计图表
 - 多知识库市场
 - 复杂搜索
 - 社群入口
 ### 11.3 底部 Tab 设计
 ```text
 学习 | 知识库 | AI助手 | 我的
 ```
 - 学习：今日任务、复习计划
 - 知识库：学习路径和内容
 - AI 助手：围绕知识库的对话
 - 我的：学习进度、设置、反馈
 ---
 ## 12. UI 风格
 ### 12.1 设计关键词
 ```text
 安静、清晰、克制、学习感、低干扰、Apple原生感、卡片式结构、适合长时间阅读
 ```
 ### 12.2 设计原则
 - 不做花哨视觉
 - 不做复杂动画
 - 不做社交信息流
 - 不做游戏化过重设计
 - 优先保证阅读体验
 - 优先保证学习任务清晰
 - 优先保证 AI 分析结果可理解
 ---
 ## 13. MVP 功能清单
 ### P0 必须完成
 1. Sign in with Apple 登录
 2. 多语言结构
 3. 一个学习方向
 4. 一个 7 天学习路径
 5. 内容阅读
 6. 主动回忆 / 笔记输入
 7. AI 分析
 8. 用户学习状态记录
 9. 复习建议
 10. AI 对话页面
 11. 反馈入口
 ### P1 尽量完成
 1. 学习进度页
 2. 设置页
 3. 简单本地缓存
 4. 等待名单 / 内测入口
 5. 基础错误提示
 6. 基础 AI 调用日志
 ### P2 暂时不做
 1. 支付
 2. 完整订阅权益
 3. 完整题库
 4. 完整知识库市场
 5. 社群
 6. 排行榜
 7. 成就系统
 8. 文件上传
 9. 复杂搜索
 10. 多端同步
 ---
 ## 14. 后端需求
 ### 第一版需要最小后端
 原因：
 1. 不能把 AI API Key 放在客户端
 2. 需要保存用户学习状态
 3. 需要保存 AI 分析结果
 4. 需要收集反馈
 5. 后续订阅权益需要后端基础
 ### 第一版后端能力
 ```text
 用户身份记录
 AI 请求代理
 学习记录保存
 AI 分析结果保存
 反馈提交
 等待名单
 基础日志
 ```
 ### 第一版不做的后端能力
 ```text
 复杂权限系统
 管理后台
 内容管理系统
 支付系统
 订阅校验
 多端同步
 复杂推荐系统
 高并发架构
 ```
 ---
 ## 15. 核心实体
 ```text
 User
 KnowledgeBase
 LearningPath
 Lesson
 LearningSession
 AIAnalysis
 ReviewTask
 Feedback
 ```
 ### ReviewTask
 ```text
 ReviewTask
 ├── id
 ├── userId
 ├── lessonId
 ├── sourceSessionId
 ├── reviewType
 ├── scheduledAt
 ├── completedAt
 └── status
 ```
 ### AIAnalysis
 ```text
 AIAnalysis
 ├── id
 ├── userId
 ├── sessionId
 ├── inputText
 ├── outputJson
 ├── masteryScore
 ├── weakPoints
 ├── suggestions
 ├── modelName
 ├── createdAt
 └── costEstimate
 ```
 ---
 ## 16. AI Prompt 设计原则
 ### Prompt 目标
 AI Prompt 不是为了生成漂亮文字，而是为了稳定产出结构化学习判断。
 Prompt 需要让 AI 输出：
 - 用户理解程度
 - 用户薄弱点
 - 用户表达问题
 - 下一步建议
 - 是否需要复习
 - 复习时间建议
 ### 输出格式
 第一版要求 AI 尽量输出 JSON。如果 JSON 不稳定，后端需要做容错处理。
 ### Prompt 边界
 AI 不允许：
 - 承诺考试结果
 - 给出绝对权威评分
 - 编造不存在的资料来源
 - 输出和学习主题无关的内容
 - 引导用户作弊
 ---
 ## 17. 成功标准
 ### 产品可用标准
 第一版必须做到：
 - 用户能登录
 - 用户能选择学习路径
 - 用户能完成一节学习
 - 用户能输入内容
 - AI 能返回分析
 - 系统能生成复习建议
 - 用户知道下一步该干什么
 ### 验证成功标准
 第一轮验证目标：
 - 至少 10 个用户愿意试用
 - 至少 3 个用户完整走完学习闭环
 - 至少 3 条有效反馈
 - 至少 1 个用户表示愿意继续用
 - 至少 1 个用户表示未来愿意付费
 ---
 ## 18. 当前不做清单
 - 完整公考题库
 - 完整课程体系
 - 完整知识库市场
 - 用户上传资料
 - 文件解析
 - 复杂笔记编辑器
 - 社交系统
 - 打卡排行榜
 - 支付订阅
 - Android
 - Web 学习端
 - Mac 正式版
 - B 端后台
 - 内容创作者后台
 ---
 ## 19. 当前最大风险
 1. 产品范围继续膨胀
 2. AI 判断用户状态不稳定
 3. 用户不愿意主动输入内容
 4. 内容质量不足以支撑学习
 5. 用户认为 AI 分析不专业
 6. 方向还没验证就投入过多开发
 7. 登录、多语言、架构设计增加早期开发成本
 8. AI 对话页变成泛聊天，稀释产品定位
 ---
 ## 20. 解决策略
 1. 登录只做 Apple 登录
 2. 多语言只做架构，不做完整翻译运营
 3. 知识库只做一个 7 天路径
 4. AI 对话只围绕当前知识库
 5. 学习状态模型先做基础版本
 6. 后端只做最小 API 和数据保存
 7. 不接支付
 8. 不做完整题库
 9. 不做完整知识库平台
 10. 14 天内必须产出可展示版本
--- a/v0.1/3-官网与技术基础/官网与技术基础.md
+++ b/v0.1/3-官网与技术基础/官网与技术基础.md
@ -0,0 +1,958 @@
 ---
 version: v0.1
 status: draft
 updated: 2026-05-03
 ---
 # 官网与技术基础
 ## 1. 当前技术目标
 v0.1 阶段的技术目标不是做完整大系统，而是搭建一个可持续迭代的最小技术底座。
 **当前需要支持：**
 1. iPhone App Demo / MVP
 2. Sign in with Apple 登录
 3. AI API 调用
 4. 用户学习记录保存
 5. AI 分析结果保存
 6. 学习状态模型
 7. 官网基础页面
 8. 等待名单和反馈入口
 9. 后续可扩展到 TestFlight、App Store、iPad、Mac、Android
 **当前不追求：**
 - 高并发
 - 完整后台管理系统
 - 完整支付系统
 - 完整内容管理系统
 - 复杂微服务
 - 复杂云原生架构
 - 多端同步
 - 企业级权限系统
 ---
 ## 2. 技术总原则
 ### 2.1 用熟悉技术优先
 当前是个人开发者阶段，技术选型优先考虑：
 - 自己能理解
 - AI Agent 容易生成
 - 出问题容易排查
 - 部署简单
 - 成本低
 - 后续能扩展
 ### 2.2 架构要清晰，但不能过度设计
 原则：
 ```text
 代码结构清晰 > 技术炫技
 可维护 > 复杂
 能上线 > 完美
 能验证 > 大而全
 ```
 ### 2.3 前后端职责分离
 | 端 | 职责 |
 |---|------|
 | iOS 客户端 | 页面展示、用户交互、本地状态、登录入口、学习流程体验 |
 | 后端 | 用户身份记录、AI API 代理、学习记录保存、AI 分析结果保存、学习画像更新、反馈收集、等待名单 |
 | AI 模型 | 分析用户输入、生成学习反馈、识别薄弱点、生成复习建议、辅助学习对话 |
 | 官网 | 产品介绍、SEO、隐私政策、用户协议、支持页面、等待名单、TestFlight 招募、未来 Mac DMG 下载 |
 ---
 ## 3. 当前推荐最终选型
 ```text
 iOS：SwiftUI
 iOS 架构：MVVM + Service + Repository
 设计规范：Apple Human Interface Guidelines
 UI 风格：Apple 原生感、安静、克制、学习感
 动效策略：轻量、有意义、服务学习体验
 官网：Astro
 官网域名：longde.cloud
 后端：NestJS + TypeScript
 数据库：MySQL
 缓存：Redis，先预留，可延后
 AI：Provider 抽象 + 一个真实模型 + MockProvider
 AI 记忆：结构化学习画像，不急着做复杂 Agent Memory
 部署：现有 4 核 4G 轻量云
 反向代理：Nginx
 进程/容器：Docker Compose 或 PM2
 ```
 当前不买新服务器，不做复杂架构，先把最小闭环跑通。
 ---
 ## 4. 整体技术架构
 ```text
 iPhone App
  ├── SwiftUI
  ├── Sign in with Apple
  ├── 本地缓存
  └── API Client
        ↓
 后端 API
  ├── 用户模块
  ├── 学习记录模块
  ├── AI 代理模块
  ├── 学习画像模块
  ├── 反馈模块
  └── 等待名单模块
        ↓
 数据库
  ├── MySQL
  └── Redis（可选）
        ↓
 AI 服务
  ├── MiniMax / DeepSeek / 通义 / OpenAI / Claude / Gemini
  └── 后续可替换
        ↓
 官网
  ├── Astro
  ├── SEO 页面
  ├── 隐私政策
  ├── 用户协议
  └── 等待名单
 ```
 ---
 ## 5. iOS 客户端技术选型
 ### 5.1 技术选择
 ```text
 Swift
 SwiftUI
 Xcode
 MVVM
 Service 层
 Repository 层
 ```
 **选择原因：**
 1. 当前第一阶段只做 Apple 平台
 2. SwiftUI 适合快速做原型和 MVP
 3. 原生体验更适合长期做 iPhone、iPad、Mac
 4. Apple 生态的动画、交互、系统组件体验好
 5. 后续可以逐步学习和沉淀原生开发能力
 ### 5.2 SwiftUI 学习策略
 学习顺序：
 1. Swift 基础语法
 2. SwiftUI 页面布局
 3. NavigationStack 页面跳转
 4. TabView 底部导航
 5. Form / List / ScrollView
 6. ObservableObject / State / Binding
 7. 网络请求
 8. 本地存储
 9. Sign in with Apple
 10. 简单动画和转场
 第一版 UI 优先使用系统组件，尽量做出 Apple 原生感。
 ### 5.3 iOS 目录结构
 ```text
 AIStudyApp/
 ├── App/
 │   ├── AIStudyApp.swift
 │   ├── AppConfig.swift
 │   └── AppRouter.swift
 │
 ├── Core/
 │   ├── Network/
 │   │   ├── APIClient.swift
 │   │   ├── APIEndpoint.swift
 │   │   └── APIError.swift
 │   │
 │   ├── Auth/
 │   │   ├── AppleSignInService.swift
 │   │   └── AuthSession.swift
 │   │
 │   ├── Storage/
 │   │   ├── LocalStorage.swift
 │   │   └── KeychainService.swift
 │   │
 │   ├── Localization/
 │   │   └── LocalizationManager.swift
 │   │
 │   └── DesignSystem/
 │       ├── AppColors.swift
 │       ├── AppTypography.swift
 │       ├── AppSpacing.swift
 │       └── Components/
 │
 ├── Features/
 │   ├── Onboarding/
 │   │   ├── Views/
 │   │   ├── ViewModels/
 │   │   └── Models/
 │   │
 │   ├── Auth/
 │   │   ├── Views/
 │   │   └── ViewModels/
 │   │
 │   ├── Learning/
 │   │   ├── Views/
 │   │   ├── ViewModels/
 │   │   └── Models/
 │   │
 │   ├── KnowledgeBase/
 │   │   ├── Views/
 │   │   ├── ViewModels/
 │   │   └── Models/
 │   │
 │   ├── AIAssistant/
 │   │   ├── Views/
 │   │   ├── ViewModels/
 │   │   └── Models/
 │   │
 │   ├── Review/
 │   │   ├── Views/
 │   │   ├── ViewModels/
 │   │   └── Models/
 │   │
 │   └── Profile/
 │       ├── Views/
 │       ├── ViewModels/
 │       └── Models/
 │
 ├── Shared/
 │   ├── Components/
 │   ├── Extensions/
 │   ├── Utils/
 │   └── Constants/
 │
 └── Resources/
    ├── Localizable.xcstrings
    ├── Assets.xcassets
    └── PreviewData/
 ```
 ### 5.4 iOS 模块说明
 | 模块 | 说明 |
 |------|------|
 | App | 负责 App 入口、全局配置、路由 |
 | Core | 负责底层能力：网络请求、登录、本地存储、Keychain、多语言、设计系统 |
 | Features | 按业务模块拆分：Onboarding、Auth、Learning、KnowledgeBase、AIAssistant、Review、Profile |
 | Shared | 存放通用组件、工具函数、扩展 |
 | Resources | 存放资源文件、多语言、图片、测试数据 |
 ### 5.5 iOS 第一版不做
 - 复杂动画系统
 - 自定义复杂控件
 - iPad 专门布局
 - Mac Catalyst
 - Watch App
 - Widget
 - 离线完整知识库
 - 复杂搜索
 - 文件导入
 - 推送通知
 - 支付订阅
 ---
 ## 6. Apple 设计规范与动效原则
 ### 6.1 设计基准
 本产品第一阶段优先做 Apple 平台，因此 UI/UX 设计需要参考 Apple Human Interface Guidelines。
 第一版设计目标不是做复杂视觉，而是做出：
 - 原生感
 - 安静感
 - 学习感
 - 清晰的层级
 - 流畅的交互
 - 适度高级感
 - 符合 Apple 用户习惯的体验
 ### 6.2 HIG 设计原则
 1. **内容优先** — 学习内容、任务和 AI 分析结果应该是页面中心
 2. **层级清晰** — 用户应该很清楚当前在哪、今天要做什么、下一步做什么
 3. **交互克制** — 不做过多按钮，不堆功能，不制造干扰
 4. **系统一致** — 尽量使用 Apple 原生组件、系统字体、系统导航、系统交互
 5. **可访问性** — 字体大小、颜色对比、动态效果都要考虑不同用户
 6. **动效有意义** — 动效用于反馈、状态变化、页面过渡和学习进度表达，不做无意义炫技
 ### 6.3 动效优先级
 **P0 必须做：**
 - 页面进入 / 返回的自然过渡
 - 按钮点击反馈
 - 加载状态
 - AI 分析中状态
 - 学习完成反馈
 **P1 建议做：**
 - 今日任务卡片动效
 - 进度条更新动效
 - AI 分析结果分块出现
 - 复习建议卡片出现
 **P2 延后做：**
 - 启动页品牌动画
 - 高级图表动效
 - 大范围转场动画
 - 自定义复杂动画
 ### 6.4 SwiftUI 动效实现策略
 第一版优先使用 SwiftUI 原生能力：
 ```text
 withAnimation
 transition
 opacity
 scaleEffect
 ProgressView
 ```
 谨慎使用：
 ```text
 matchedGeometryEffect
 PhaseAnimator
 SymbolEffect
 ```
 第一版不追求复杂自定义动画系统。目标是让 App 看起来顺滑、有质感，而不是炫技。
 ---
 ## 7. SwiftUI + AI Agent 开发策略
 ### 7.1 基本判断
 创始人当前没有 SwiftUI 实战经验，但可以借助 AI Agent 完成开发。
 这不影响第一版使用 SwiftUI。原因：
 1. SwiftUI 适合快速构建 Apple 原生界面
 2. AI Agent 对 SwiftUI 页面、组件、ViewModel 的生成能力较强
 3. 只要目录结构清晰、任务拆分明确，AI 可以辅助完成大量开发
 4. 创始人需要掌握的是架构、产品逻辑、代码审查和调试能力
 ### 7.2 AI 开发原则
 使用 AI 开发 SwiftUI 时，必须遵守：
 1. 每次只让 AI 修改一个模块
 2. 每次生成前先说明目录和目标文件
 3. 不允许 AI 随意改全局架构
 4. 不允许 AI 把所有代码写进一个 View
 5. 页面、ViewModel、Model、Service 分开
 6. 复杂逻辑放到 Service，不堆在 View 里
 7. UI 组件尽量复用
 8. 每完成一个页面就真机预览或模拟器运行
 ### 7.3 推荐开发顺序
 1. 创建项目骨架
 2. 建立 DesignSystem
 3. 建立 Tab 结构
 4. 建立 Onboarding 页面
 5. 建立 Apple 登录页面
 6. 建立学习路径页面
 7. 建立今日任务页面
 8. 建立内容阅读页面
 9. 建立主动回忆输入页面
 10. 建立 AI 分析结果页面
 11. 建立 AI 助手页面
 12. 建立我的 / 设置 / 反馈页面
 ### 7.4 AI 生成代码时的提示原则
 每次让 AI 写代码时，要明确：
 - 当前模块
 - 目标文件
 - 不要修改哪些文件
 - 使用 SwiftUI
 - 使用 MVVM
 - 使用已有 DesignSystem
 - 不写死颜色和字体
 - 支持多语言 key
 - 页面要支持深色模式
 - 页面要适配不同 iPhone 尺寸
 ### 7.5 第一版代码质量底线
 底线：
 - 不把业务逻辑写在 View 里
 - 不把 API Key 写在客户端
 - 不写大量重复 UI
 - 不写死所有文案
 - 不把 AI Prompt 写死在 iOS 端
 - 不让一个文件超过过大规模
 - 不做无法维护的一次性 Demo
 ---
 ## 8. 官网技术选型
 ### 8.1 官网定位
 官网不是 Web 学习系统，而是产品基础设施。
 官网第一阶段承担：
 - 产品介绍
 - SEO 收录
 - 等待名单
 - TestFlight 招募
 - 隐私政策
 - 用户协议
 - 支持页面
 - 更新日志
 - 未来 Mac DMG 下载
 ### 8.2 框架选择
 | 框架 | 优点 | 缺点 |
 |------|------|------|
 | Astro | 适合内容型网站、SEO 友好、静态页面性能好、适合官网博客文档、比 Nuxt/Next 更轻 | 未来做 Web App 需要另起项目 |
 | Nuxt | Vue 生态、适合 SSR/SSG | 对纯官网来说稍重 |
 | Next.js | React 生态强、SSR/SSG 成熟 | 对当前阶段偏重 |
 | VitePress | 文档站很快 | 视觉自由度不如 Astro |
 **推荐：Astro**
 ### 8.3 官网页面结构
 ```text
 website/
 ├── src/
 │   ├── pages/
 │   │   ├── index.astro
 │   │   ├── privacy.astro
 │   │   ├── terms.astro
 │   │   ├── support.astro
 │   │   ├── waitlist.astro
 │   │   ├── download.astro
 │   │   └── changelog.astro
 │   │
 │   ├── layouts/
 │   │   └── BaseLayout.astro
 │   │
 │   ├── components/
 │   │   ├── Hero.astro
 │   │   ├── FeatureCard.astro
 │   │   ├── CTA.astro
 │   │   └── Footer.astro
 │   │
 │   ├── content/
 │   │   └── posts/
 │   │
 │   └── styles/
 │       └── global.css
 │
 ├── public/
 │   ├── images/
 │   └── favicon.svg
 │
 └── package.json
 ```
 ### 8.4 SEO 规划
 **第一版 SEO 重点：**
 - 首页标题、描述、关键词
 - Open Graph 分享图
 - sitemap.xml
 - robots.txt
 - 清晰 URL 结构
 - 更新日志内容
 - 长尾关键词页面
 **当前不做：**
 - 复杂 SEO 工具链
 - 大量采集文章
 - 自动生成垃圾内容
 - 过度关键词堆砌
 ---
 ## 9. 后端技术选型
 ### 9.1 是否需要后端
 v0.1 需要最小后端，原因：
 1. AI API Key 不能放在 iOS 客户端
 2. 用户登录后需要保存用户身份
 3. 学习记录需要保存
 4. AI 分析结果需要保存
 5. 学习状态模型需要后端维护
 6. 等待名单和反馈需要收集
 7. 后续订阅权益需要后端基础
 ### 9.2 技术对比
 | 技术 | 优点 | 缺点 |
 |------|------|------|
 | NestJS | 模块清晰、适合长期、TypeScript 生态好、AI Agent 容易按模块生成代码 | 学习成本稍高 |
 | Express | 简单、学习成本低、快速启动 | 大项目容易混乱、AI Agent 写多了容易堆代码 |
 | FastAPI | Python 生态适合 AI、写 API 很快、后续接 AI/RAG 方便 | 两个语言栈分散注意力 |
 | Spring Boot | 企业级成熟 | 太重、不擅长 |
 **推荐：Node.js + NestJS + TypeScript**
 ### 9.3 后端目录结构
 ```text
 server/
 ├── src/
 │   ├── main.ts
 │   ├── app.module.ts
 │   │
 │   ├── common/
 │   │   ├── filters/
 │   │   ├── guards/
 │   │   ├── interceptors/
 │   │   ├── decorators/
 │   │   └── utils/
 │   │
 │   ├── config/
 │   │   ├── app.config.ts
 │   │   ├── database.config.ts
 │   │   └── ai.config.ts
 │   │
 │   ├── modules/
 │   │   ├── auth/
 │   │   ├── users/
 │   │   ├── knowledge/
 │   │   ├── learning/
 │   │   ├── ai/
 │   │   │   ├── prompts/
 │   │   │   └── providers/
 │   │   ├── review/
 │   │   ├── feedback/
 │   │   └── waitlist/
 │   │
 │   └── database/
 │       ├── migrations/
 │       └── seeds/
 │
 ├── .env
 ├── package.json
 └── docker-compose.yml
 ```
 ### 9.4 后端第一版模块
 **P0 模块：**
 - Auth 模块
 - User 模块
 - Knowledge 模块
 - Learning 模块
 - AI 模块
 - Review 模块
 - Feedback 模块
 - Waitlist 模块
 **P1 模块：**
 - Admin 简单管理
 - Analytics 简单日志
 - Subscription 订阅预留
 **P2 暂不做：**
 - 支付、完整后台、多租户、企业账号、复杂权限
 ---
 ## 10. 数据库设计
 ### 10.1 数据库选型
 ```text
 v0.1：MySQL + Redis（预留）
 后续：向量数据库（PostgreSQL pgvector / Milvus / Qdrant）
 ```
 ### 10.2 为什么用 MySQL
 MySQL 适合保存结构化业务数据：
 - 用户、登录信息
 - 知识库、学习路径
 - 学习记录、AI 分析结果
 - 复习任务、反馈、等待名单
 ### 10.3 为什么用 Redis
 Redis 第一版可以先不急着重度使用，但可以预留：
 - 缓存
 - 限流
 - AI 请求频控
 - 短期会话
 - 验证码（未来如果有）
 - 队列（后续如果需要）
 ### 10.4 是否需要向量数据库
 **第一版暂不急着上向量数据库。**
 原因：
 1. 第一版知识库内容很小
 2. 可以先用结构化课程上下文传给 AI
 3. RAG 系统会增加复杂度
 4. 当前重点是验证学习闭环，而不是做大规模知识检索
 **后续再考虑：** PostgreSQL + pgvector、Qdrant、Milvus
 ---
 ## 11. AI 长期记忆与知识库能力
 ### 11.1 名词澄清
 | 概念 | 说明 |
 |------|------|
 | 长期记忆 Long-term Memory | 记录用户长期偏好、历史行为、薄弱点 |
 | 学习画像 Learning Profile | 记录用户在具体学习领域里的状态 |
 | 知识库 Knowledge Base | 产品提供的结构化内容（课程小节、知识点、示例、练习、复习问题） |
 | RAG | 当知识库内容变多后，通过检索相关内容，再交给 AI 回答 |
 | 向量数据库 | 用于存储文本向量，实现语义检索 |
 | Agent Memory | Agent 为了长期协作，保存用户目标、偏好、任务历史等 |
 ### 11.2 v0.1 推荐做法
 第一版不要急着做复杂 Agent Memory。
 v0.1 只做：
 ```text
 结构化学习画像
 +
 学习记录
 +
 AI 分析结果
 +
 复习队列
 ```
 也就是：
 - UserLearningProfile
 - LearningSession
 - AIAnalysis
 - ReviewTask
 ### 11.3 AI 对话上下文
 第一版 AI 对话上下文包括：
 ```text
 当前用户
 当前知识库
 当前学习路径
 当前小节
 用户最近一次输入
 最近一次 AI 分析
 用户薄弱点
 当前复习任务
 ```
 暂不做全局长期聊天记忆。
 ---
 ## 12. AI 模型与 API 选型
 ### 12.1 模型选择原则
 1. 中文能力好
 2. 成本可控
 3. API 稳定
 4. 支持结构化输出
 5. 速度可以接受
 6. 容易接入
 7. 可替换
 ### 12.2 候选模型
 ```text
 MiniMax
 DeepSeek
 通义千问
 OpenAI
 Claude
 Gemini
 ```
 ### 12.3 AI Provider 层设计
 后端需要设计 AI Provider 层：
 ```text
 AIService
  ├── MiniMaxProvider
  ├── DeepSeekProvider
  ├── OpenAIProvider
  └── MockProvider
 ```
 ### 12.4 MockProvider
 v0.1 强烈建议做一个 MockProvider。
 作用：
 - 没有 API Key 时也能开发
 - AI 服务出问题时能测试流程
 - 降低开发成本
 - 方便录 Demo
 ### 12.5 核心 AI 接口
 **POST /ai/analyze-learning-input**
 输入：
 ```json
 {
  "userId": "user_001",
  "lessonId": "lesson_001",
  "userInput": "用户写下的答案或笔记",
  "context": {
    "lessonTitle": "材料阅读方法",
    "objectives": ["理解材料结构", "提取关键要点"],
    "keyPoints": ["问题", "原因", "影响", "对策"]
  }
 }
 ```
 输出：
 ```json
 {
  "masteryScore": 3,
  "understandingLevel": "基本理解",
  "summary": "用户能理解主要内容，但要点不完整。",
  "strengths": ["表达清楚"],
  "weakPoints": ["遗漏关键要点", "逻辑层次不足"],
  "suggestions": ["补充第二个要点", "先概括再展开"],
  "reviewNeeded": true,
  "nextAction": "明天重新回答本节主动回忆问题。"
 }
 ```
 **POST /ai/chat**
 输入：
 ```json
 {
  "userId": "user_001",
  "lessonId": "lesson_001",
  "message": "这节内容能不能举个例子？"
 }
 ```
 输出：
 ```json
 {
  "reply": "可以。你可以这样理解……",
  "suggestedActions": ["生成复习问题", "重新解释", "给我一个例子"]
 }
 ```
 ---
 ## 13. 域名规划
 ### 13.1 当前已有域名
 ```text
 longde.cloud
 ```
 v0.1 阶段使用该域名作为产品基础设施域名。
 ### 13.2 子域名规划
 ```text
 longde.cloud           官网首页
 www.longde.cloud       官网首页（可跳转）
 api.longde.cloud       后端 API
 git.longde.cloud       Gitea 代码仓库
 download.longde.cloud  未来 Mac DMG 下载（可选）
 status.longde.cloud    未来服务状态页（可选）
 ```
 ### 13.3 官网 URL 规划
 | 路径 | 说明 |
 |------|------|
 | / | 首页 |
 | /privacy | 隐私政策 |
 | /terms | 用户协议 |
 | /support | 支持与反馈 |
 | /waitlist | 等待名单 / 内测申请 |
 | /changelog | 更新日志 |
 | /download | 未来 Mac DMG 下载页 |
 | /blog | 后续 SEO 内容文章 |
 ---
 ## 14. 部署方案
 ### 14.1 当前服务器情况
 - 4 核 4G 轻量云服务器
 - 当前运行 Gitea
 ### 14.2 是否需要新买服务器
 **v0.1 阶段不建议立刻买新 ECS。**
 原因：
 1. 当前没有真实用户
 2. v0.1 请求量很低
 3. 官网、后端、数据库可以先小规模部署
 4. 先验证产品，不增加固定成本
 ### 14.3 当前推荐部署方式
 ```text
 Nginx
 Docker Compose 或 PM2
 MySQL
 Redis（可选）
 NestJS 后端
 Astro 静态官网
 Gitea 继续保留
 ```
 ### 14.4 什么时候买新服务器
 满足以下情况再考虑新服务器：
 1. Gitea 和产品服务互相影响
 2. 官网访问开始明显增加
 3. 后端 AI 请求明显增多
 4. MySQL 占用资源明显
 5. 需要更稳定的生产环境
 6. App Store 正式上线前想隔离开发服务
 ---
 ## 15. 开发环境与仓库规划
 ### 15.1 仓库策略
 **推荐 monorepo：**
 ```text
 ai-study-product/
 ├── apps/
 │   ├── ios/
 │   └── website/
 │
 ├── services/
 │   └── api/
 │
 ├── packages/
 │   ├── shared-types/
 │   └── prompts/
 │
 ├── docs/
 │   └── planning/
 │
 └── README.md
 ```
 **原因：**
 1. 早期项目小，放一起方便管理
 2. AI Agent 更容易读取完整上下文
 3. Prompt、类型定义、文档可以共享
 4. 后续大了再拆仓库
 ---
 ## 16. 技术里程碑
 ### 技术里程碑 1：可点击 iOS Demo
 - SwiftUI 项目
 - 基础页面
 - Tab 导航
 - 学习路径页面
 - 内容阅读页面
 - AI 分析结果假数据
 ### 技术里程碑 2：最小后端
 - NestJS 项目
 - MySQL 连接
 - 用户表
 - 学习记录表
 - AI MockProvider
 - 反馈接口
 ### 技术里程碑 3：真实 AI 接入
 - AI Provider 抽象
 - 接入一个真实模型
 - AI 分析接口
 - AI 对话接口
 - 结构化输出保存
 ### 技术里程碑 4：官网上线
 - Astro 官网
 - 首页
 - 隐私政策
 - 用户协议
 - 支持页
 - 等待名单
 - SEO 基础配置
 ### 技术里程碑 5：TestFlight 前准备
 - Sign in with Apple
 - 后端用户身份记录
 - 基础错误处理
 - 数据隐私检查
 - 反馈入口
 - 内测版本构建
 ---
 ## 17. 当前技术不做清单
 - Spring Boot
 - 微服务
 - Kubernetes
 - 多云部署
 - 完整后台管理系统
 - 完整 CMS
 - 完整 RAG
 - 向量数据库
 - 多模型自动路由
 - AI Agent 工具调用系统
 - 文件上传解析
 - Web 学习端
 - Android
 - Mac 正式版
 - 支付系统
 - 复杂数据分析平台
--- a/v0.1/4-用户验证与增长/用户验证与增长.md
+++ b/v0.1/4-用户验证与增长/用户验证与增长.md
@ -0,0 +1,717 @@
 ---
 version: v0.1
 status: draft
 updated: 2026-05-03
 ---
 # 用户验证与增长
 ## 1. 当前定位
 v0.1 阶段的用户验证与增长，不是大规模营销，也不是正式商业化投放。
 **当前目标是：**
 > 用最低社交压力、最低成本的方式，验证产品方向是否有人需要，并找到第一批愿意试用的人。
 **当前不追求：**
 - 大规模涨粉
 - 大规模投流
 - 大规模社群运营
 - 自动化私信轰炸
 - 全平台铺量
 - 精致品牌营销
 **当前只追求：**
 1. 收集真实用户痛点
 2. 验证用户是否对产品感兴趣
 3. 找到愿意内测的人
 4. 判断哪个知识库方向更值得做
 5. 为 Demo / TestFlight 获取第一批反馈
 ---
 ## 2. 当前增长原则
 ### 2.1 不做硬销售
 当前不卖课、不卖资料、不卖会员。
 对外表达应该是：
 > 我是一个独立开发者，正在验证一个 AI 学习工具的想法，希望听听真实用户的意见。
 不要一开始就说：赶紧下载、立即购买、限时优惠、保证提分、权威批改、上岸神器。
 ### 2.2 不装专家
 对外身份应该是：
 > 做 AI 学习工具的独立开发者，正在和真实备考用户一起打磨产品。
 不要伪装成：申论老师、公考名师、权威机构、教培专家。
 ### 2.3 先验证，再增长
 ```text
 观察用户痛点
        ↓
 发布验证内容
        ↓
 收集评论 / 问卷 / 等待名单
        ↓
 找到愿意内测的人
        ↓
 根据反馈调整 Demo
        ↓
 再扩大内容发布
 ```
 ### 2.4 人参与最终判断
 AI 可以辅助大量工作，但关键动作必须由人确认：
 - 是否发布
 - 如何回复
 - 是否私信
 - 是否邀请内测
 - 是否采纳反馈
 - 是否调整产品方向
 ---
 ## 3. AI / Agent 在增长中的角色
 ### 3.1 AI 可以做的事情
 AI 可以负责：
 1. 选题生成
 2. 标题优化
 3. 文案草稿
 4. 小红书笔记草稿
 5. B 站视频脚本
 6. 知乎回答草稿
 7. 评论截图分析
 8. 用户痛点归类
 9. 回复建议
 10. 问卷设计
 11. 反馈总结
 12. 竞品评论分析
 13. 内容复盘
 14. 下一步建议
 ### 3.2 AI 不应该完全自动做的事情
 AI 不应该完全自动：
 1. 批量发布内容
 2. 批量评论
 3. 批量私信
 4. 冒充真人互动
 5. 伪造用户反馈
 6. 用脚本刷量
 7. 自动加入大量群聊
 8. 自动爬取和搬运平台内容
 9. 自动生成大量低质量 SEO 内容
 ### 3.3 推荐模式：半自动增长
 ```text
 AI 生成内容草稿
        ↓
 人审核修改
        ↓
 人手动发布
        ↓
 用户评论 / 私信
        ↓
 截图给 AI 分析
        ↓
 AI 生成回复草稿
        ↓
 人确认后回复
        ↓
 AI 汇总反馈
        ↓
 更新产品计划
 ```
 **一句话总结：**
 > 不是让 AI 代替你做营销，而是让 AI 把营销里最消耗你的部分变成草稿、模板、分析和建议。
 真正需要你做的只有三件事：
 ```text
 判断发不发
 判断怎么回
 判断这个反馈对产品有没有用
 ```
 ---
 ## 4. 当前验证渠道
 ### 4.1 小红书
 **定位：**
 - 最适合早期验证学习类、备考类、工具类内容
 - 适合图文、截图、短视频、经验贴
 - 适合收集评论和私信
 **适合内容：**
 - 产品想法验证
 - 学习痛点讨论
 - AI 工具截图
 - Demo 过程记录
 - 公考申论学习痛点
 - AI 学习方法
 - 独立开发者公开构建
 ### 4.2 B 站
 **定位：**
 - 适合长一点的解释、开发记录、产品演示
 - 适合建立信任
 - 适合做"我如何做一个 AI 学习 App"系列内容
 **适合内容：**
 - Demo 演示
 - 开发记录
 - 产品思路讲解
 - AI 学习工具评测
 - 公考申论 AI 批改实验
 - 独立开发者创业记录
 ### 4.3 知乎
 **定位：**
 - 适合回答问题、沉淀长文
 - 适合做搜索流量
 - 适合验证用户痛点和观点
 **适合内容：**
 - 申论怎么学
 - AI 能不能辅助学习
 - 普通人怎么系统学习 AI 工具
 - 知识库学习是不是伪学习
 - 学习软件怎么提高效率
 ### 4.4 官网
 **定位：**
 - 承接流量
 - 收集等待名单
 - 展示产品定位
 - 提供隐私政策、支持页
 - 为后续 App Store 上架做基础
 ```text
 内容平台种草
        ↓
 引导到官网
        ↓
 查看产品介绍
        ↓
 加入等待名单 / 申请内测
 ```
 ---
 ## 5. 当前内容方向
 v0.1 阶段暂时围绕三个候选方向做内容测试。
 ### 方向 A：公考申论 AI 学习教练
 1. 申论小白最难的是不会写，还是没人批改？
 2. 如果 AI 每天帮你批改申论答案，你会用吗？
 3. 我想做一个 AI 申论学习工具，有人需要吗？
 4. 申论为什么看了很多资料还是不会写？
 5. 申论学习是不是存在大量伪学习？
 6. AI 能不能帮你发现申论答案的问题？
 7. 申论学习最缺的是资料，还是反馈？
 8. 我用 AI 做了一个申论学习 Demo。
 ### 方向 B：AI 工具学习知识库
 1. 普通人到底该怎么系统学习 AI 工具？
 2. 不会写 Prompt 的人，真的需要一个 AI 学习 App 吗？
 3. 我想做一个 AI 工具学习知识库，有人需要吗？
 4. AI 工具太多，普通人该从哪里开始？
 5. 用 AI 学习 AI，是不是更高效？
 6. 普通人学 AI 最容易踩哪些坑？
 7. 我做了一个 AI 工具学习路径 Demo。
 ### 方向 C：程序员 / 前端面试学习助手
 1. 前端面试为什么刷了很多题还是不会答？
 2. AI 能不能模拟面试官？
 3. 我想做一个 AI 前端面试学习助手。
 4. 程序员面试最缺的是题库，还是反馈？
 5. AI 帮你分析面试回答，有没有价值？
 6. 前端八股文怎么学才不是死背？
 ---
 ## 6. 内容生产流程
 ### 6.1 每条内容的生产流程
 ```text
 确定方向
        ↓
 AI 生成 5 个选题
        ↓
 人选择 1 个
        ↓
 AI 生成草稿
        ↓
 人改成自己的语气
        ↓
 AI 优化标题和结构
        ↓
 人最终审核
        ↓
 手动发布
        ↓
 截图评论给 AI 分析
        ↓
 整理反馈
 ```
 ### 6.2 内容不要太精致
 v0.1 阶段内容不追求精致品牌感。
 更适合真实表达：
 - 我正在做一个产品
 - 我还不确定有没有人需要
 - 我想听真实用户意见
 - 这是我做的 Demo
 - 你觉得这个功能有用吗
 早期真实感比精致感更重要。
 ### 6.3 内容频率
 **建议频率：**
 ```text
 每周 3 条小红书
 每周 1 条 B 站动态或视频
 每周 1 个知乎回答
 每周 1 次反馈整理
 ```
 **最低频率：**
 ```text
 每周 2 条小红书
 每周 1 次反馈整理
 ```
 ---
 ## 7. 小红书内容模板
 ### 7.1 产品想法验证型
 **标题方向：**
 - 我想做一个 AI 申论学习工具，有人需要吗？
 - 如果 AI 每天帮你批改申论答案，你会用吗？
 - 申论最痛苦的是不会写，还是没人批改？
 **正文结构：**
 ```text
 我最近在做一个 AI 学习工具的方向验证。
 想法很简单：
 不是卖课，也不是做题库，而是想做一个能帮用户完成学习、反馈和复习的 AI 学习助手。
 比如申论学习里，很多人不是没资料，而是：
 1. 不知道怎么写
 2. 写完没人批改
 3. 不知道自己错在哪
 4. 不知道每天该学什么
 5. 看了很多资料但还是不会用
 我想验证一个问题：
 如果有一个 App，每天给你一个小任务，
 你写完后 AI 帮你分析问题，
 再告诉你明天该复习什么，
 你会愿意试试吗？
 正在备考的朋友可以评论告诉我：
 你学申论最痛苦的是哪一步？
 ```
 ### 7.2 Demo 展示型
 **标题方向：**
 - 我做了一个 AI 申论学习 Demo，想听听真实反馈
 - 一个人做 App 第 X 天：AI 申论学习助手雏形
 - 这是我做的 AI 学习工具第一版
 **正文结构：**
 ```text
 今天做了一个很早期的 Demo。
 目前只有一个核心流程：
 选择学习路径 → 阅读一小节内容 → 写下自己的理解 → AI 分析薄弱点 → 生成复习建议
 现在还不是正式产品，只是想验证：
 这个流程对学习有没有帮助。
 如果你正在备考，或者对 AI 学习工具感兴趣，
 可以帮我看看这个方向有没有价值。
 ```
 ---
 ## 8. B 站内容模板
 ### 8.1 开发记录型
 **视频标题：**
 - 我打算做一个 AI 学习 App，第 1 版先验证这个功能
 - 一个人做 AI 学习产品：为什么我不想做普通笔记软件？
 - 从 0 做一个 AI 申论学习助手，我先做了这个 Demo
 **视频结构：**
 ```text
 1. 我为什么想做这个产品
 2. 现在的学习软件有什么问题
 3. 我想验证的核心假设
 4. Demo 当前做到了什么
 5. 我最不确定的问题
 6. 邀请真实用户反馈
 ```
 ### 8.2 观点型
 **视频标题：**
 - 为什么很多知识库学习其实是伪学习？
 - AI 学习工具真正有价值的地方不是总结，而是反馈
 - 普通人学习最缺的不是资料，而是下一步决策
 ---
 ## 9. 评论与私信回复策略
 ### 9.1 回复原则
 1. 真诚
 2. 不推销
 3. 不争辩
 4. 不装专家
 5. 不承诺效果
 6. 多问真实情况
 7. 少说产品多强，多问用户怎么学
 ### 9.2 AI 辅助回复流程
 ```text
 用户评论截图
        ↓
 发给 AI
        ↓
 AI 判断评论类型
        ↓
 AI 生成 3 个回复草稿
        ↓
 人选择一个并修改
        ↓
 人手动回复
 ```
 ### 9.3 评论分类
 ```text
 感兴趣 / 质疑 / 吐槽痛点 / 提供建议 / 询问价格 / 询问内测 / 无效评论 / 负面评论
 ```
 ### 9.4 回复示例
 **用户说：这个有点意思，怎么用？**
 > 还在早期验证阶段，目前在做 Demo 和内测准备。现在主要想先确认这个流程对真实学习有没有帮助。如果你愿意，我后面可以发你 TestFlight 内测链接，想听听你的真实反馈。
 **用户说：AI 批改靠谱吗？**
 > 我也不打算把它包装成权威批改。现在更想做成学习辅助，帮用户发现表达、结构、遗漏要点这些问题。真正的效果还需要拿真实用户反馈来验证。
 **用户说：申论不是 AI 能搞定的。**
 > 认同，申论肯定不能完全靠 AI。我现在的想法不是替代老师，而是解决一些基础问题，比如写完没人看、不知道哪里表达不清楚、不知道第二天该复习什么。
 **用户说：多少钱？**
 > 现在还没正式定价，早期会先做内测。因为 AI 有调用成本，未来大概率会是订阅制，但现阶段重点是验证功能有没有用。
 ---
 ## 10. 问卷设计
 ### 10.1 问卷目标
 问卷不是为了做复杂市场调研，而是为了判断：
 1. 用户是谁
 2. 用户用什么设备
 3. 用户痛点是什么
 4. 用户现在花不花钱
 5. 用户是否愿意试用
 6. 用户是否愿意付费
 ### 10.2 公考申论方向问卷
 ```text
 1. 你现在是否在备考公考 / 事业编？
 2. 你主要使用 iPhone 还是 Android？
 3. 你学申论最痛苦的问题是什么？
 4. 你现在买过哪些申论资料 / 课程 / App 会员？
 5. 你是否需要 AI 帮你分析答案和安排复习？
 6. 如果有内测版，你愿意试用吗？
 7. 如果未来收费，你能接受的价格区间是多少？
 8. 是否愿意留下邮箱或联系方式用于内测通知？
 ```
 ### 10.3 AI 工具学习方向问卷
 ```text
 1. 你现在是否在学习 AI 工具？
 2. 你主要想用 AI 解决什么问题？
 3. 你现在最大的问题是不会选工具、不会 Prompt，还是不知道怎么系统学？
 4. 你是否愿意使用一个系统化 AI 工具学习 App？
 5. 你主要使用 iPhone 还是 Android？
 6. 如果有内测版，你愿意试用吗？
 7. 如果未来收费，你能接受的价格区间是多少？
 8. 是否愿意留下邮箱或联系方式用于内测通知？
 ```
 ---
 ## 11. 等待名单设计
 官网需要提供等待名单页面。
 **路径：** `/waitlist`
 **字段：**
 ```text
 昵称（可选）
 邮箱
 使用设备：iPhone / Android / iPad / Mac
 感兴趣方向：公考申论 / AI 工具学习 / 程序员面试 / 其他
 当前最大痛点
 是否愿意参加内测
 是否接受后续邮件通知
 ```
 **提交后提示：**
 ```text
 感谢你加入等待名单。
 当前产品还在早期验证阶段，如果你的需求匹配第一批内测方向，
 我会优先联系你参与 TestFlight。
 ```
 ---
 ## 12. 反馈整理格式
 每次收集到反馈，都统一记录。
 ```text
 来源平台：
 用户类型：
 使用设备：
 用户原话：
 痛点分类：
 是否感兴趣：
 是否愿意内测：
 是否愿意付费：
 对产品的启发：
 下一步动作：
 ```
 **示例：**
 ```text
 来源平台：小红书
 用户类型：公考备考用户
 使用设备：iPhone
 用户原话：申论最难的是写完不知道哪里错。
 痛点分类：缺少反馈
 是否感兴趣：是
 是否愿意内测：待确认
 是否愿意付费：未知
 对产品的启发：AI 分析答案可能是核心卖点
 下一步动作：后续内容重点展示 AI 如何分析答案
 ```
 ---
 ## 13. AI 辅助增长工作流
 ### 13.1 每日 30 分钟流程
 ```text
 10 分钟：看评论 / 私信 / 数据
 10 分钟：截图给 AI 总结
 10 分钟：回复用户或记录反馈
 ```
 ### 13.2 每周 2 小时流程
 ```text
 30 分钟：AI 生成下周选题
 30 分钟：挑选和修改内容
 30 分钟：整理用户反馈
 30 分钟：更新产品计划
 ```
 ### 13.3 Agent 可做任务
 未来可以让 Agent 做：
 1. 读取本地反馈表
 2. 总结用户痛点
 3. 生成内容选题
 4. 生成小红书草稿
 5. 生成 B 站脚本
 6. 生成回复草稿
 7. 维护内容日历
 8. 输出每周复盘
 但发布和回复仍由人确认。
 ---
 ## 14. 第一轮验证目标
 ### 最低目标
 ```text
 收集 50 条用户痛点原话
 发布 3 条小红书内容
 发布 1 条 B 站内容或动态
 收集 10 份问卷
 获得 3 个愿意内测的人
 ```
 ### 理想目标
 ```text
 收集 100 条用户痛点原话
 发布 6 条小红书内容
 发布 2 条 B 站内容
 收集 30 份问卷
 获得 10 个愿意内测的人
 ```
 ---
 ## 15. 2 周验证计划
 ### 第 1-2 天：观察
 - 搜索小红书、B站、知乎相关内容
 - 收集申论 / AI 工具学习 / 程序员面试用户痛点
 - 整理至少 30 条用户原话
 ### 第 3-4 天：整理
 - 用 AI 对用户原话分类
 - 找出高频痛点
 - 生成 10 个内容选题
 - 确定第一批要发的 3 条内容
 ### 第 5-7 天：发布第一轮内容
 - 发 2 条小红书
 - 发 1 条 B 站动态或视频
 - 不主动私信陌生人
 - 只回复评论区用户
 ### 第 8-10 天：上线等待名单
 - 官网上线 /waitlist
 - 内容中引导感兴趣用户加入等待名单
 - 收集设备类型和方向偏好
 ### 第 11-14 天：复盘
 - 汇总评论、问卷、等待名单
 - 判断哪个方向反馈更强
 - 判断是否值得继续做 Demo
 - 更新方向验证文档
 ---
 ## 16. 判断标准
 ### 方向继续的信号
 某个方向满足以下条件，可以继续：
 - 有用户主动评论或私信
 - 有人愿意填写问卷
 - 有人愿意加入等待名单
 - 有人明确表示愿意内测
 - 用户痛点集中
 - 用户说得出现在怎么解决
 - 用户过去为类似问题花过钱
 - iPhone 用户比例不低
 ### 方向暂缓的信号
 出现以下情况，需要暂缓：
 - 内容没人看、没人评论
 - 问卷没人填
 - 用户痛点很分散
 - 用户只是觉得有趣，但没有强需求
 - 用户不愿意留下联系方式
 - 用户不愿意付费
 - 内容生产成本太高
 - 创始人对领域长期没有兴趣
 ---
 ## 17. 当前不做清单
 v0.1 用户验证与增长阶段暂不做：
 - 自动批量发帖
 - 自动批量评论
 - 自动批量私信
 - 投放广告
 - 建大社群
 - 付费买粉
 - 购买水军
 - 搬运他人内容
 - 承诺学习效果
 - 伪装成机构老师
 - 大规模 SEO 内容站
 - 多平台全量铺开
 ---
 ## 18. 当前最终策略
 v0.1 用户验证与增长采用：
 ```text
 AI 辅助生产
        ↓
 人审核发布
        ↓
 AI 辅助分析评论
        ↓
 人确认回复
        ↓
 AI 汇总反馈
        ↓
 人决定产品方向
 ```
 **一句话：**
 > 当前不做全自动营销，而是做人机协作的低压力用户验证系统。
--- a/v0.1/99-暂缓事项/暂缓事项.md
+++ b/v0.1/99-暂缓事项/暂缓事项.md
@ -0,0 +1,101 @@
    # 暂缓事项
    这些事情重要，但不是 v0.1 阶段要做的。
    ## 暂缓商业化
    - Apple IAP
    - 月订阅
    - 年订阅
    - 免费试用
    - 订阅权益系统
    - AI 成本精算
    等 TestFlight 有真实用户后再细拆。
    ## 暂缓运营
    - 社群运营
    - 客服机器人
    - 用户分层
    - 活动运营
    - 打卡活动
    等有第一批用户后再做。
    ## 暂缓数据系统
    - 完整埋点
    - 留存分析
    - 付费转化分析
    - 用户画像分析
    v0.1 只记录最基础反馈。
    ## 暂缓合规与公司化
    - 注册公司
    - 对公账户
    - 微信支付
    - 支付宝
    - 国内 Android 上架
    - APP 备案
    - ICP 备案
    等 Apple 端验证收入后再考虑。
    ## 暂缓多端
    - iPad
    - Mac
    - Android
    - Web C 端
    - B 端后台
    当前只做 iPhone Demo 和官网基础设施。
 ## 解冻条件
 以下事项不是永远不做，而是在满足条件后再做。
 ### 商业化解冻条件
 满足以下条件后，再细拆 Apple IAP、订阅、免费试用：
 - TestFlight 有真实用户
 - 有用户明确表示愿意付费
 - Demo 核心学习闭环已经跑通
 - AI 成本大致可控
 ### 运营解冻条件
 满足以下条件后，再考虑社群、客服、打卡活动：
 - 有 10 个以上内测用户
 - 用户开始持续反馈
 - 需要集中管理用户问题
 ### 数据系统解冻条件
 满足以下条件后，再做完整埋点和留存分析：
 - App Store MVP 准备上线
 - 用户量开始增长
 - 需要判断留存和付费转化
 ### 合规与公司化解冻条件
 满足以下条件后，再考虑公司、支付、备案、安卓：
 - Apple 端有稳定收入
 - 产品方向已经验证
 - 用户不是朋友，而是陌生人自然使用或付费
 - 收入能覆盖基础成本
 ### 多端解冻条件
 满足以下条件后，再考虑 iPad、Mac、Android、Web 学习端：
 - iPhone 版本核心体验稳定
 - 用户明确提出多端需求
 - 当前平台已经验证留存和付费
--- a/个人开发者创业完全版/1-产品与用户模块/产品与用户模块.md
+++ b/个人开发者创业完全版/1-产品与用户模块/产品与用户模块.md
@ -4,96 +4,37 @@
 定义产品方向、目标用户、核心价值主张和产品路线图。
---
+## 核心内容
-## 产品定位
+### 产品定位
-**知习 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)
+
 ## 负责人
 [待定]
--- a/个人开发者创业完全版/2-技术与交付模块/AI架构设计.md
+++ b/个人开发者创业完全版/2-技术与交付模块/AI架构设计.md
@ -1,564 +0,0 @@
 下面这段可以直接写进你的项目文档里。
 ---
 # 知习 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 分析能力。
--- a/个人开发者创业完全版/2-技术与交付模块/技术与交付模块.md
+++ b/个人开发者创业完全版/2-技术与交付模块/技术与交付模块.md
@ -4,65 +4,43 @@
 确定技术栈、开发流程、交付节奏和质量标准。
---
+## 核心内容
-## 技术选型（已决策）
+### 技术选型
-| 层级 | 选型 | 说明 |
+- iOS 技术栈（Swift/SwiftUI）
-|------|------|------|
+- 后端技术方案
-| iOS | Swift / SwiftUI | Apple 原生，MVVM + Service + Repository |
+- AI API 集成
-| 后端 | 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 发布计划
-| iPhone + iPad | 同一个 Xcode Project，同一个 iOS App Target |
+- App Store 上架计划
 | 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)
+
 ## 负责人
 [待定]
--- a/个人开发者创业完全版/3-商业化与支付模块/商业化与支付模块.md
+++ b/个人开发者创业完全版/3-商业化与支付模块/商业化与支付模块.md
@ -4,86 +4,43 @@
 设计商业模式、定价策略和支付系统。
---
+## 核心内容
-## 商业模式（已决策）
+### 商业模式
-**极简结构：免费版 + 单一 Pro 订阅。** 不做多级会员梯度。
+- 订阅模式设计
 - 免费试用策略
 - 权益体系
-### 定价定位
+### 定价策略
-知习应按 **"AI 学习闭环工具"** 定价，不按普通笔记 App 也不按通用 AI 聊天工具。
+- 月订阅定价
 - 年订阅定价
 - 早鸟价方案
-核心竞争力是 **输入 → 主动回忆 → AI 反馈 → 薄弱点 → 间隔复习 → 趋势分析** 完整闭环。
+### Apple IAP
-### 竞品价格区间
+- 订阅配置
 - 恢复购买
 - 订阅管理
-| 类型 | 价格区间 | 知习对标 |
+### 支付流程
 |------|----------|----------|
 | 国内笔记/效率工具 | ¥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)
 ## 负责人
 [待定]
--- a/个人开发者创业完全版/4-营销与增长模块/营销与增长模块.md
+++ b/个人开发者创业完全版/4-营销与增长模块/营销与增长模块.md
@ -4,78 +4,43 @@
 制定获客策略、品牌建设和增长计划。
---
+## 核心内容
-## 品牌建设
+### 品牌建设
- 品牌名：知习 ZhiXi（统一使用，不再混用"龙德AI学习"）
+- 品牌定位
- 品牌定位：AI 驱动的系统化学习工具，核心卖点是"输入 → 主动回忆 → AI 反馈 → 薄弱点 → 间隔复习 → 趋势"闭环
+- 品牌故事
- 对外身份：独立开发者，正在和真实用户一起打磨产品，不做硬销售、不装专家
+- 视觉规范
---
+### 获客渠道
-## 营销策略（已决策）
+- App Store 优化
 - 社交媒体
 - 内容营销
 - 口碑传播
-采用 **半自动 AI 辅助模式**：
+### 官网营销
-```
+- 落地页设计
-AI 生成内容草稿 → 人审核修改 → 人手动发布 → AI 辅助分析评论和反馈
+- 等待名单收集
-```
+- TestFlight 招募
-核心：AI 负责选题/草稿/分析，人负责判断发不发、怎么回、反馈有没有用。
+### 内容营销
---
+- 博客规划
 - 学习资源内容
 - SEO 策略
-## 获客渠道
+### 增长指标
-| 渠道 | 定位 | 内容形式 |
+- 下载量目标
-|------|------|----------|
+- 激活率目标
-| 小红书 | 早期验证，适合图文/截图/经验贴 | 产品想法验证、学习痛点讨论、Demo 展示 |
+- 留存率目标
 | B 站 | 建立信任，长内容 | 开发记录、产品思路讲解、Demo 演示 |
 | 知乎 | 搜索流量，沉淀长文 | 学习方法回答、AI+学习观点 |
 | 官网 | 承接流量，收集等待名单 | 产品介绍、隐私政策、等待名单、TestFlight 招募 |
 ```
 内容平台种草 → 引导到官网 → 查看产品介绍 → 加入等待名单 / 申请内测
 ```
 ---
 ## 正确节奏
 ```
 有想法 → 发内容验证 → 收集潜在用户 → 邀请内测 → 修改产品 → 上架 → 继续增长
 ```
 而不是：闭门开发三个月 → 上架 → 才开始想怎么推广。
 ---
 ## 第一轮验证目标
 - 收集 50 条真实用户痛点原话
 - 发布 3 条小红书 + 1 条 B 站内容
 - 收集 10 份问卷
 - 获得至少 3 个愿意内测的人
 ---
 ## 内容频率
 - 每周 3 条小红书
 - 每周 1 条 B 站动态或视频
 - 每周 1 个知乎回答
 - 每周 1 次反馈整理
 ---
 ## 增长指标
 - 下载量、激活率、次日/7日留存、付费转化率、取消订阅率、退款率
 ---
 ## 相关文档
 - [阶段路线图](../0-阶段路线图/阶段路线图.md)
- [营销冷启动调研方案](./营销冷启动调研方案.md)
+
 ## 负责人
 [待定]
--- a/个人开发者创业完全版/4-营销与增长模块/营销冷启动调研方案.md
+++ b/个人开发者创业完全版/4-营销与增长模块/营销冷启动调研方案.md
@ -1,173 +0,0 @@
 # 调研启动方案
 ## 摘要
 你上传的说明其实已经不是“帮我调研一下”级别的模糊需求，而是一份相当完整的研究 brief：主题聚焦「知习 ZhiXi」在 2025–2026 年的产品营销、推广、冷启动与 AI 自动化营销；约束条件是个人开发、低预算、不出镜、iOS 优先；目标是先找到第一批真实用户，并验证持续使用与付费信号，月收入约 2000 元可视为正向信号。fileciteturn0file0
 如果你暂时不补充，我建议直接按“官方/原始信号优先”的默认方案开题，而不是再做一轮长问卷。原因是平台现在已经提供了可直接用于增长研究的一手能力：iOS 侧可直接研究产品页实验、定制产品页、应用分析与评分评论；Android 侧可研究 acquisition/statistics 与测试要求；海外社区发布需要先遵守真实参与与反垃圾规则；国内内容平台也提供创作者后台、内容管理和数据分析入口。对冷启动来说，这些信号比泛化营销文章更接近真实转化。citeturn0search0turn5search1turn7search3turn7search23turn7search7turn6search13turn5search5turn2search0turn2search1
 | 下一步选项 | 适合情况 | 预计时长 | 你会得到什么 |
 |---|---|---:|---|
 | 直接按默认方案开题 | 你想马上推进，且现有 brief 已足够清楚 | 5 个工作日 | 一份可执行的完整研究报告框架与证据清单 |
 | 先缩到最关键问题 | 产品还在 MVP，先只关心“前 100 个真实用户 + 付费信号” | 2 个工作日 | 受众、渠道、内容、验证指标的最小答案 |
 | 分两阶段推进 | 先定方向，再补执行细节 | 2 + 3 个工作日 | 先出定位/受众/渠道，再出 30/60/90 天计划 |
 ## 诊断问卷
 只需回答下面 8 个问题；如果赶时间，只回答“优先市场、成功标准、必看竞品”三项也可以。
 | 要澄清的问题 | 建议回答方式 | 你当前的默认值 |
 |---|---|---|
 | 这次调研的主题是什么 | 一句话写清 | 知习 ZhiXi 的营销、推广、冷启动与 AI 自动化营销 |
 | 这次最想回答的核心问题 | 最多 3 个 | 如何低预算找到首批真实用户；如何验证持续使用与付费；国内/海外先做什么 |
 | 目标受众是谁 | 先写主受众，再写次受众 | 高学习需求用户 + 愿尝试新工具的人群 |
 | 优先市场与顺序 | 国内 / 海外 / 同步 / 先国内后海外 | 国内与海外都看，但执行上更适合先定主战场 |
 | 研究范围 | 明确“要研究”和“不研究” | 要研究渠道、定位、冷启动、内容、自动化；不以大额投放为重点 |
 | 可接受的证据源 | 官方、原始用户反馈、案例、第三方报告 | 优先官方平台报告、App 商店数据、公开案例、独立开发者复盘 |
 | 结果将用于什么决策 | 如“决定先做哪 3 个渠道” | 决定首发渠道、内容形式、种子用户获取、是否继续投入 |
 | 截止时间与输出格式 | 报告 / Notion / PPT / 表格 | 倾向实操型报告，最好能直接转执行清单 |
 表中的“默认值”均根据你上传的说明整理，可直接修改、删除或补充。fileciteturn0file0
 ## 调研路径选项
 以下时长为“单人研究”的现实估算，不含等待用户补充信息的时间。
 | 路径 | 目标 | 单人估时 | 典型来源 | 预期输出 |
 |---|---|---:|---|---|
 | 快速概览 | 快速判断有没有值得做的机会 | 0.5–1 天 | 官方平台文档、5–8 个竞品页面、20–30 条用户评论 | 4–6 页简报，含方向判断与下一步建议 |
 | 深度报告 | 给出完整的营销、冷启动与执行框架 | 3–5 天 | 官方文档、竞品矩阵、商店评论、社区帖子、增长案例 | 15–25 页结构化报告，附 30/60/90 天计划 |
 | 市场/竞品比较 | 看清赛道、定位和差异化空间 | 4–7 天 | 15–25 个竞品、定价页、商店物料、评论、社区讨论 | 竞品地图、定位建议、内容角度与渠道优先级 |
 建议默认选 **“深度报告”**，因为你当前的 brief 已经足以支撑完整研究；如果时间很紧，则先做 **“快速概览”** 的缩窄版。
 ## 默认调研方案
 **如果你不再回复，默认核心问题将定义为：**  
 在“不露脸、低预算、个人开发”的约束下，知习如何在接下来的 30–90 天内获得第一批真实用户，并验证持续使用与早期付费信号？fileciteturn0file0
 | 默认项 | 默认值 |
 |---|---|
 | 研究对象 | 知习 ZhiXi |
 | 首阶段目标 | 获取首批真实用户，验证是否有人持续使用并愿意付费 |
 | 业务信号 | 月收入约 ¥2,000 可视为正向信号 |
 | 产品阶段 | 开发中，iOS 优先 |
 | 市场范围 | 国内 + 海外，但执行上先选一个主战场 |
 | 约束条件 | 个人开发、低预算、不出镜、偏自动化 |
 以上默认项均来自你上传的研究说明。fileciteturn0file0
 | 时间 | 工作内容 | 关键里程碑 | 主要产出 |
 |---|---|---|---|
 | 第一天 | 锁定研究问题、成功标准、竞品池、证据分级 | 明确“先回答哪 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"]：urlPlay Console acquisition 报表turn7search7；urlStatistics 指标说明turn7search1；urlSEO Starter Guideturn5search3；urlPeople-first content 指南turn5search9  
 - entity["organization","Product Hunt","product discovery community"]：urlLaunch Guideturn6search0；urlPreparing for launchturn6search6；urlSharing your launchturn6search13  
 - entity["organization","Reddit","social discussion platform"]：urlReddiquetteturn6search1；urlSpam 规则turn5search5  
 如果后续要补 Android 首发，还要单独预留测试窗口：对于新创建的个人开发者账号，官方文档说明需要至少 12 名测试者连续 14 天参与 closed test，之后才能申请 production access。citeturn3search16
 如果研究范围包含官网、落地页或 SEO，默认应按“helpful / people-first content”思路做内容结构，而不是先做关键词堆砌。citeturn5search3turn5search9
 ## 研究简报模板
 可直接复制并填写：
 **项目名称：**  
 [例如：知习 ZhiXi 产品营销、推广、冷启动与 AI 自动化营销研究]
 **一句话研究问题：**  
 [这次研究最想回答的唯一问题]
 **研究背景：**  
 [为什么现在做、产品处于什么阶段、当前困境是什么]
 **业务目标：**  
 [例如：获取前 100 个真实用户；验证 7 日留存；验证首批付费]
 **成功标准：**  
 [写 3 个以内的硬指标]
 **目标用户：**  
 主受众：  
 次受众：  
 不优先受众：
 **优先市场：**  
 [国内 / 海外 / 先国内后海外 / 先海外后国内]
 **必须覆盖的主题：**  
 [渠道、定位、竞品、内容、自动化、ASO、漏斗、付费转化等]
 **明确不研究的内容：**  
 [例如：大额广告投放、品牌片、复杂 PR]
 **必须覆盖的竞品：**  
 [列 5–10 个]
 **可接受的证据源：**  
 [官方文档 / 商店评论 / 用户社区 / 公开复盘 / 第三方数据库]
 **证据优先级：**  
 [官方 > 原始用户反馈 > 一手平台数据 > 高质量二手资料 > 推断]
 **输出格式：**  
 [报告 / PPT / Notion / 表格 / 执行清单]
 **交付深度：**  
 [快速概览 / 深度报告 / 竞品比较]
 **截止时间：**  
 [具体日期]
 **使用场景：**  
 [用来决定什么，例如先做哪 3 个渠道]
 **标注规范：**  
 所有结论按 **[事实] / [案例] / [推测] / [建议]** 标记；变化快的信息注明日期。
 ## 质量检查清单
 | 检查项 | 通过标准 |
 |---|---|
 | 问题是否清楚 | 能用一句话写出“这份研究要替你做什么决策” |
 | 范围是否收敛 | 首阶段只服务一个目标，不把“市场、品牌、投放、增长、定价”一次全做完 |
 | 证据是否足够一手 | 关键结论至少优先来自官方文档、商店页面、用户评论、社区原帖 |
 | 关键判断是否交叉验证 | 至少有两类证据相互支持，或一条官方证据 + 一条原始用户信号 |
 | 信息是否新 | 对平台规则、测试要求、商店能力、渠道机制标明日期或版本 |
 | 事实与建议是否分开 | 报告里明确区分 [事实]、[案例]、[推测]、[建议] |
 | 结论是否能执行 | 每条建议都能落到“谁、在哪、发什么、看什么指标” |
 | 国内/海外是否分开 | 不把两个市场混为一谈，至少在用户、渠道、话术上分开写 |
 | 是否说明不确定性 | 标出缺口、假设、尚待验证项，而不是把猜测写成结论 |
 | 是否能直接进入行动 | 报告结尾必须有优先级列表、时间线、里程碑和最低执行量 |
--- a/个人开发者创业完全版/5-运营与客服模块/客服设计详案.md
+++ b/个人开发者创业完全版/5-运营与客服模块/客服设计详案.md
@ -1,339 +0,0 @@
 对，你这个判断是对的。**你一个人做产品，如果没有 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 内智能客服；它的价值就是替你挡住基础问题，把真正需要人工处理的问题变成后台工单，而不是让所有用户消息都直接压到你一个人身上。
 ```
--- a/个人开发者创业完全版/5-运营与客服模块/运营与客服模块.md
+++ b/个人开发者创业完全版/5-运营与客服模块/运营与客服模块.md
@ -4,88 +4,42 @@
 建立用户运营体系和支持服务。
---
+## 核心内容
-## 客服体系（已决策）
+### 用户运营
-采用 **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)
+
 ## 负责人
 [待定]
--- a/个人开发者创业完全版/个人开发者创业计划.md
+++ b/个人开发者创业完全版/个人开发者创业计划.md
@ -1,103 +1,672 @@
-# 知习 ZhiXi 个人开发者创业计划
+# 个人开发者互联网产品创业项目拆分文档
-> 适用场景：个人开发者从零开始做互联网产品，Apple-first 策略，先验证后扩张。
+> 适用场景：个人开发者从零开始做互联网产品，第一阶段优先上架 Apple 平台，后续在产品盈利后再考虑国内安卓平台、公司化、微信/支付宝支付、备案等事项。
---
+***
-## 一、核心策略
+## 1. 核心判断
-> **长期按完整互联网产品架构设计，短期按 Apple-first 路线执行；先验证，后扩张。**
+当前最适合的策略不是一开始做全平台、全支付、全合规，而是：
-当前最需要验证的是：
+> **先用 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
 有人需要 → 有人愿意用 → 有人愿意付费 → 收入能覆盖成本
 ```
-**不是一开始做全平台、全支付、全合规**，而是先用 Apple 平台做低成本验证。
+***
---
+## 3. 推荐的 7 大项目模块
-## 二、产品总览
+一个个人开发者创业项目，可以拆成 7 个核心模块。
-| 维度 | 决策 |
+```text
 |------|------|
 | 产品名 | 知习 ZhiXi |
 | 定位 | AI 驱动的系统化学习工具 |
 | 核心闭环 | 知识库 → 主动回忆 → AI 分析 → 薄弱点 → 间隔复习 → 趋势 |
 | 第一版平台 | iPhone + 官网 |
 | 变现模式 | 免费版 + 单一 Pro 订阅 |
 | 定价 | 中国 ¥29/月，海外 $9.99/月 |
 | 当前阶段 | 方向验证 + iPhone MVP |
 ---
 ## 三、7 大项目模块
 ```
 个人开发者创业项目
 │
-├── 1. 产品与用户模块     → 方向、用户、MVP 闭环
+├── 1. 产品与用户模块
-├── 2. 技术与交付模块     → 技术栈、AI 架构、工程策略
+├── 2. 技术与交付模块
-├── 3. 商业化与支付模块   → 定价、订阅、权益
+├── 3. 商业化与支付模块
-├── 4. 营销与增长模块     → 获客、内容、冷启动
+├── 4. 营销与增长模块
-├── 5. 运营与客服模块     → Dify 客服、工单、用户运营
+├── 5. 运营与客服模块
-├── 6. 数据反馈与迭代模块 → 指标、埋点、迭代
+├── 6. 数据、反馈与迭代模块
-└── 7. 合规与公司化模块   → 上架合规、公司化时机
+└── 7. 合规与公司化模块
 ```
---
+***
-## 四、阶段路线图
+## 4. 模块一：产品与用户模块
-| 阶段 | 目标 | 状态 |
+这个模块回答的是：
 |------|------|------|
 | 0 | 项目定盘 + 官网基础设施 | ✅ 官网基础页面已完成 |
 | 1 | 选择第一个垂直知识库方向 | 🔲 待打分决策 |
 | 2 | 设计 MVP 学习闭环 | ✅ 已设计 |
 | 3 | iPhone MVP 开发 | 🔲 前后端待接通 |
 | 4 | TestFlight 内测 | 🔲 Apple 账号审核中 |
 | 5 | App Store 上架 | 🔲 |
 | 6 | 验证盈利 | 🔲 |
 | 7 | iPad / Mac 扩展 | 🔲 |
 | 8 | 公司化与安卓扩展 | 🔲 |
-> 详见：[阶段路线图](./0-阶段路线图/阶段路线图.md)
+> 我到底做什么？给谁做？解决什么问题？
---
+### 4.1 需要拆分的内容
-## 五、当前状态
+| 子模块    | 说明                |
 | ------ | ----------------- |
 | 用户画像   | 明确目标用户是谁          |
 | 使用场景   | 用户在什么情况下需要这个产品    |
 | 核心痛点   | 用户现在最麻烦、最不爽的问题是什么 |
 | 替代方案   | 用户现在用什么解决这个问题     |
 | 产品定位   | 你的产品比现有方案好在哪里     |
 | MVP 范围 | 第一版只做哪个最核心的功能     |
 | 产品路线图  | 后续版本逐步增加什么能力      |
-| 模块 | 进度 | 关键缺口 |
+### 4.2 一句话定位模板
 |------|------|----------|
 | iOS App | 21 页面 UI 完成 | NavigationLink 编译问题、API Service 未接通、MVVM 未分层 |
 | 后端 API | 13 模块骨架 | Repository 未接 MySQL、BullMQ 未接 Redis、AI 走 Mock |
 | 官网 | 基础页面上线 | Waitlist/Support 表单未接后端、品牌名不统一、CSS 变量缺失 |
 | 数据库 | MySQL + Redis 已部署 | 代码未走 Prisma |
 | 方向验证 | 3 个候选方向 | 未打分选定，未准备知识库内容 |
-> 详见：[潜在问题清单](../潜在问题清单.md)
+```text
 我做一个【产品类型】，帮助【目标用户】在【具体场景】下，
 用【核心功能】解决【核心痛点】，第一版只做【一个关键动作】，
 通过【订阅 / 买断 / 免费试用 / 点数】变现。
 ```
---
+### 4.3 示例
-## 六、各模块文档索引
+```text
 我做一个 iOS App，帮助刚开始健身的人每天生成简单训练计划，
 用打卡和提醒解决坚持困难的问题，第一版只做“生成今日训练 + 完成打卡”，
 通过年订阅变现。
 ```
-| 模块 | 主文档 | 子文档 |
+***
 |------|--------|--------|
 | 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) | — |
---
+## 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 路线执行；先验证，后扩张。**
 1. **选定垂直知识库方向**（3 候选 → 打分 → 选 1）
 2. **准备第一个 7 天路径的内容**
 3. **修复 iOS 编译问题 + Repository 接 Prisma + iOS 换 HTTPS**
 4. **做 3-5 个竞品拆解**
 5. **跑一次真实用户触达**（小红书/B站发内容，收集等待名单）
--- a/潜在问题清单.md
+++ b/潜在问题清单.md
@ -1,171 +0,0 @@
 # 潜在问题清单
 > 逐层审查代码和策略后发现的问题。
 > 更新时间：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` 只是目录骨架~~ | 已写入完整定价方案：¥29/月、$9.99/月，免费版+Pro版权益、竞品价格区间、收入测算 | ✅ 已决策，详见 `商业化与支付模块.md` |
 | 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 | ✅ **品牌定位** | ~~品牌名都不统一~~ | 已决策统一用"知习 AI"（官网代码和页面尚未全部更新） | ✅ 已决策，官网待执行 |
 | D14 | **内测用户获取** | 没有用户触达的路径验证 | 计划写了小红书/B站/知乎 + 等待名单，但等待名单在官网上是假的，没有跑过一次真实用户获取 | 方向验证的第一步"看评论区"还没批量执行过 |
 | D15 | **上线后运营** | 零运营准备 | 计划有 `运营与客服模块.md` 但只是目录，没有客服响应 SLA、没有内测群管理方案、没有版本发布沟通流程 | TestFlight 内测用户遇到问题找谁？等多久？怎么反馈给你？全没定义 |
 | D16 | **隐私合规落空** | 官网隐私政策是用 AI 生成的模板 | `privacy.astro` 内容很长但法律有效性存疑；`App Privacy` 数据声明没准备 | App Store 上架时 Apple 会严格审查隐私声明，模板可能被退回 |
 ---
 ## 📊 统计（含方向）
 | 等级 | 数量 |
 |------|------|
 | 🔴 严重（技术） | 7 |
 | 🟠 高危（技术） | 8 |
 | 🟡 中危（技术） | 14 |
 | 🟢 低危（技术） | 11 |
 | 🧭 方向/策略 | 14 |
 | **合计** | **54** |
 ---
 ## 🎯 建议优先修复顺序
 ```
 第 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       → 前后端打通
 第 3 批（内测前）：
  D6   设定验证退出条件和时间节点     → 有止损线
  D9   设计输入降门槛方案            → 解决最大风险
  D11  定 AI 分析质量验收标准        → 产品核心价值要可控
  #9   各 Controller 加 Auth Guard  → 接口安全
  #11  Token 写 Keychain            → 登录持久化
  #16  iOS MVVM 分层                → 代码可维护
  #17  iOS 加载/错误/空态           → 体验完整
  D15  准备内测运营方案             → TestFlight 用户有处可去
  D16  检查隐私政策合规性           → App Store 审核不被拒
 ```
 ---
 ## ✅ 已解决问题
 | # | 问题 | 决策 |
 |---|------|------|
 | D7 | 定价策略空缺 | 免费+单一Pro订阅，中国¥29/月、海外$9.99/月，已写入 `商业化与支付模块.md` |
 | D13 | 品牌名不统一 | 统一使用"知习 AI" |