用户场景与决策取舍
围绕独立开发者 / 产品经理缺少即时评审伙伴这个真实痛点展开。6 个角色覆盖商业、用户、数据、技术、执行、风险；星宝采用主动召唤而非自动打断；发言人数自适应 1-3 人而非固定三人组。
🎯 独立设计 · Vibe Coding 落地 · 已上线可体验
快乐星球
一个多角色 AI 产品评审群——把「找一组同事帮我评审产品想法」这个过程产品化。
用户输入一个想法，系统自动召集商业 · 用户 · 数据 · 技术 · 执行 · 风险六位 AI 角色参与讨论，串行生成、质量门控、记忆沉淀，并在用户召唤时收束为结论与行动项。
React 19 · TypeScript · Vite · Node/Vercel Function · Supabase Auth/DB
自动组局
角色分工
质量门控
星宝收束
产品总览
快乐星球把真实产品评审会抽象成 AI 编排系统——从事件分类到质量门控，从角色分工到记忆沉淀，全部串联为一个可上线的产品。
快乐星球是一个独立设计并完整落地的多角色 AI 产品评审群。它解决的是：一个人做产品时，很难同时拥有商业、用户、技术、数据、执行、风险这些视角。系统自动选角色、分配职责、串行讨论、控制质量，并在用户需要时收束为结论和行动项。
核心思路：不是”做了一个聊天页”，而是把产品评审方法、AI 编排、工程闭环做成可上线、可真实使用的产品。多层次编排与质量控制
不是靠一个大 Prompt，而是由事件分类器、任务路由器、讨论编排器、串行生成器、质量门和防幻觉硬拦截组成的系统链路。每个模块独立负责，可观测、可调试、可演进。
全链路上线闭环
React 19 + TypeScript + Vite 前端，Node 本地服务与 Vercel Function 复用同一套后端代理，Supabase Auth/DB 账号体系，管理员调试面板，生产部署全链路已调通。
我观察到的问题
产品不是从“我要做一个 AI 群聊”开始，而是从独立做产品时的真实协作缺口开始。
一个人做产品时，视角天然不完整
想法刚出现时，最缺的不是答案，而是有人从不同角度追问：用户是否真需要、商业是否成立、技术边界在哪里、第一步怎么验证。
单助手容易给“完整但单线”的建议
普通 AI 助手可以列方案，但它常常把问题包装得很完整，却缺少真实评审里的冲突、反证、分工和追问。
AI 应该像一组可调度的同事
如果 AI 能按任务自动组织不同角色，并且每个角色只承担一个清晰职责，用户更容易看见盲区并推进下一步。
产品定位
先用最短路径说明：这个产品解决谁的问题，为什么不是普通聊天助手，以及它当前做到什么程度。
独立开发者 / 产品经理 / 创业者
他们经常需要快速评审一个想法，但没有随时可用的商业、用户、技术、数据、执行和风险同事。
把多专家评审变成低成本流程
用户输入一个问题，系统自动拆分视角、选择角色、控制轮次质量，并沉淀记忆与结论。
不是”一个人 AI 扮演多人”，而是一个编排系统
每个角色有独立人设提示词、独立模型调用、分配唯一职责、串行感知前面发言。不是用一个大 Prompt 写”群戏”，而是像真实评审会一样逐个表达、互相看见。
最终目标：快乐星球最终要成为一个能持续推进产品项目的人工智能评审工作台。它不只是回答问题，而是帮助用户把想法拆清楚、把风险暴露出来、把决策沉淀下来，并推动下一步行动。
最小可行版本做了什么
当前版本的边界是：先把真实可用的多角色评审闭环跑通，再做可视化、登录、持久化和权限化。
6
人工智能角色：商业、用户、数据、技术、执行、风险
1-3
每轮自适应发言人数，避免固定三人组生硬
50
登录用户每日可使用的 AI 调用次数
6
AI 编排模块：事件分类 / 任务路由 / 讨论编排 / 串行生成 / 质量门 / 记忆
用户侧能力
- 邮箱注册、登录、退出、刷新后登录状态恢复。
- 本机演示模式，无需账号即可体验。
- 首轮任务入口：拆想法、找风险、做取舍、定行动。
- 聊天、私聊、引用、复制、删除、结构化回复渲染。
- 主动召唤星宝：总结本轮、提炼缺口、生成 1-2 个行动项。
系统侧能力
- 多模型服务商代理，支持主流 AI 接口格式。
- 对话事件分类器、任务路由器、讨论编排器共同组织讨论。
- 质量门检查跑题、重复、空泛、编造、结构僵硬。
- 记忆相关性召回，避免旧话题污染当前问题。
- 账号数据库持久化聊天、记忆、配置版本、星宝卡。
产品设计思考
这个项目的核心不是堆功能，而是围绕“AI 怎么参与真实产品评审”做了一系列取舍。
先组织讨论，再生成答案
普通 AI 产品往往直接回答。我把流程拆成事件分类、任务路由、角色编排、质量检查，让系统先判断“现在应该由谁、以什么职责发言”。
角色要有分工，不只是有人设
角色不只是换口吻。每轮讨论里，商业、用户、技术、数据、执行、风险角色会被分配唯一职责，避免多人重复同一套建议。
收束要由用户主动触发
早期自动总结看起来智能，但会打断用户思考。当前把星宝改成主动召唤，让用户在需要结论或行动项时再收束。
上下文要相关，不是越多越好
长期记忆只按当前问题召回相关偏好、项目事实、决策和开放问题，避免旧话题污染新一轮讨论。
防幻觉要有后端硬边界
仅靠提示词不够。对项目历史、实时信息、天气新闻价格等缺少证据的问题，后端直接拦截并说明资料不足。
先验证核心价值，再优化视觉复杂度
首页用静态场景和角色工位建立识别度，但没有优先做复杂动画，把主要工程投入放在对话质量、数据闭环和生产可用性。
用户流程图
这张图说明用户进入产品后如何完成一次“想法评审”。
进入产品登录 / 注册 / 本机演示
选择入口拆想法 / 找风险 / 做取舍 / 定行动
提交问题描述业务、想法或当前困惑
自动编排判断事件、任务类型、回复强度
角色讨论1-3 位角色串行发言并互相感知
质量控制必要时重写一次或跳过低质回复
用户追问点名、纠错、换话题、补齐视角
星宝收束主动召唤后生成结论和行动项
系统架构
核心是“前端体验层 + 人工智能编排层 + 后端代理与数据层”的分层，而不是把所有逻辑塞进一个提示词。
前端体验层 React 19（前端框架）
🎯 登录入口组件：邮箱注册/登录 + 本机演示 + 中文校验
💬 主应用：发送闭环、登录状态恢复、消息状态管理
🖼️ 首页场景 / 聊天背景：场景可视化 + 6 角色工位
📋 消息气泡：结构化回复、Markdown 预览、私聊、引用
⚙️ 配置面板：普通用户偏好 + 管理员配置测试 + 版本管理
AI 编排层 人格引擎
🔍 对话事件分类器：识别点名、纠错、困惑、星宝召唤等
🧭 任务路由器：识别早期想法、风险评审、执行计划等 8 种任务
📐 回复策略：决定自然短答、轻结构或强结构
👥 讨论编排器：决定 1-3 人发言、顺序、唯一职责
✅ 质量门：检查跑题、重复、空泛、编造，必要时重写/跳过
服务与数据层 后端服务 + Supabase
🔄 后端 API：本地 Node 服务 + Vercel Function 复用同一套代码
🛡️ 防幻觉硬拦截：无证项目历史 / 实时信息直接返回缺资料
🗄️ 数据仓库层：聊天 / 记忆 / 星宝 / 配置版本持久化
📊 model_logs：模型调用日志，支持排查与用量分析
完整对话链路
这部分回答“多角色到底怎么选、怎么避免复读、怎么避免胡编”。
用户输入业务问题 / 点名 / 困惑 / 换话题
事件分类先判断当前对话动作
任务路由识别早期想法、风险评审、执行计划等
回复策略决定自由、轻结构或强结构
候选角色规则引擎按关键词、意图和冷却时间初筛
可选导演微调只微调候选角色，不负责最终计划
最终编排讨论编排器分配 1-3 人与唯一职责
串行生成前一位回复传给后一位
质量门重写、跳过或展示
为什么串行调用？
早期单次调用生成多人回复会导致角色口吻趋同、模型像“编剧”而不是“角色”。串行调用让每个角色拿到自己的人设提示词，并能看到前面角色的发言。
如何避免多人复读？
讨论编排器为每位角色分配本轮唯一职责；质量门再检查重复、空泛和跑题，必要时重写一次。
如何控制幻觉？
提示词层要求无证据不编造；后端对项目历史、进度、天气、新闻、价格等无证据问题做硬拦截，直接返回缺少资料。
群聊调度方案演进
快乐星球最核心的难点不是“让人工智能回答”，而是让不同角色在合适时机说不同内容，像真实评审群一样形成互补。
已废弃
单次生成多角色
一个提示词让模型写出多人发言。问题是角色口吻趋同，模型像编剧，容易出现角色名前缀和脏文本。
基础版
规则选人
用关键词、点名、意图权重、冷却时间初筛角色。优点是快，缺点是只能决定“谁可能适合”。
增强版
任务路由 + 回复策略
先判断用户是在拆想法、评风险、做最小版本、定执行计划还是表达困惑，再决定回复结构和必要视角。
当前方案
讨论编排器最终编排
最终决定 1-3 位角色、发言顺序和每个人的唯一职责；角色串行生成，后一位能看见前一位。
模块
负责什么
解决的问题
输入
输出
对话事件分类器
判断这句话是什么事件
避免把点名、纠错、困惑、星宝召唤都当普通问题
用户当前输入 + 最近上下文
业务问题 / 点名角色 / 困惑 / 换话题等
任务路由器
识别任务类型
避免“剧本杀应用”这类业务问题被误判为剧情创作
用户输入 + 事件类型
早期想法 / 风险评审 / 最小版本设计 / 执行计划等
回复策略
决定怎么答
避免所有问题都套固定结构
任务类型 + 对话强度
自然短答 / 轻结构 / 强结构 + 必需角度
讨论编排器
决定谁说、先后顺序和唯一职责
减少多人复读，让每个角色承担不同视角
候选角色 + 策略 + 历史发言
1-3 位角色的发言计划
人数为什么自适应？
闲聊和简单确认不需要多人；复杂产品评审才需要 2-3 个视角。这样减少等待、减少噪音，也更像真实工作群。
为什么保留规则引擎？
规则引擎负责低成本初筛，速度快、可控；人工智能只在需要语义判断和编排时介入，降低延迟和成本。
为什么需要唯一职责？
同一轮里每个角色只负责一个角度，例如商业假设、用户路径、技术边界或风险反证，避免三个人都讲同一套建议。
记忆与上下文方案
当前记忆面板分成“用户长期记忆、群聊长期沉淀、最近长期记忆事件”。它们都来自同一个长期记忆状态，只是在界面上按用途拆开展示。
用户长期记忆
- 偏好：例如“回答要直接”“少讲空话”。
- 风格：例如“大白话”“详细解释”“中文表达”。
- 项目：例如当前产品名称、目标用户、已确定方向。
- 来源：用户明确表达偏好或项目事实时写入。
群聊长期沉淀
- 沉淀摘要：当前关注、最近共识、待解决问题。
- 决策：例如“首版先做 A，不做 B”。
- 长期问题：例如“目标用户还没确定”。
- 项目焦点：当前讨论正在围绕什么推进。
最近长期记忆事件
- 记录最近一次被吸收进长期记忆的内容。
- 显示范围：用户、群聊、私聊。
- 显示类型：偏好、项目事实、决策、问题、摘要等。
- 作用：方便检查系统最近到底记住了什么。
界面栏目
代码字段
Supabase 存储
读取策略
用途
用户长期记忆
userMemory.preferences / communicationStyle / projectFacts
memories 表；完整快照在 client_id = memory-state-snapshot 的 metadata.snapshot 中
按当前问题相关性筛选项目事实和偏好；沟通风格少量全局注入
让角色记住用户偏好和项目事实
群聊长期沉淀
groupMemory.summary / decisions / openQuestions / currentFocus
同一份完整快照；同时展开 decision / question 等索引行
只召回与当前问题相关的决策和开放问题
让项目讨论跨轮连续，不重复推翻已确定内容
最近长期记忆事件
memoryEvents
展开为 source = memory_event 的索引行
不直接全量注入模型，主要用于展示和追踪
解释最近哪些内容被系统记住
私聊记忆
privateMemories[角色]
完整快照；有摘要时展开 private-summary 索引行
私聊或点名相关角色时按相关性召回
保留与单个角色的私聊摘要和未完成话题
早期问题
只存不读 / 读得太粗
私聊记忆和群聊总结存在本地，但召回不稳定，或者整段总结进入提示词，影响新话题。
第一次修正
打通读写路径
补齐私聊角色标识、是否包含私聊记忆等路径，让私聊和群聊记忆都能进入上下文。
第二次修正
相关性过滤
按当前问题筛选用户偏好、项目事实、决策和开放问题，不再无脑注入所有历史。
当前方案
快照为准 + 索引用于展示
读取时以完整快照为准，保存时再展开索引行。这样既能稳定恢复完整记忆，也便于在后台查看具体记忆条目。
当前策略：长期记忆不是把所有历史都塞进模型。每轮回复前会根据当前问题筛选相关项目事实、用户偏好、群聊决策和开放问题；如果缺少可参考资料，后端会直接提示缺少证据，不让模型编造项目进展。
数据闭环与权限
这部分说明：是不是只能本地演示、有没有账号体系、人工智能调用成本怎么控制。
对象
认证
聊天
记忆
配置
额度
登录用户
账号服务邮箱登录，刷新后恢复登录状态
会话表 / 消息表写入账号数据库
记忆按用户编号隔离
配置版本表保存版本快照
数据持久化，登录态隔离，支持历史回溯
本机演示
本机演示登录状态，无需注册
浏览器本地存储隔离
本机记忆，不进入真实数据库
本地运行时覆盖
适合现场快速演示和本机试用
管理员
邮箱白名单显示调试入口
复制聊天、清空当前对话
查看记忆与召回效果
模型测试、配置测试、版本对比
查看模型调用反馈与调试信息
迭代优化与效果
这里按“问题 -> 改动 -> 效果”讲，能体现工程判断和产品决策。
阶段 1-3
从能聊到可配置
先打通核心群聊链路，再把规则、角色行为、生成参数、记忆规则外置到 config.json。
效果
减少硬编码，后续调整提示词和规则不用每次改业务代码。
阶段 4-6
状态机 + 防幻觉
加入跨轮次语义状态提取，记录用户拒绝方向、当前关注点；后端加入无证据硬拦截。
效果
角色不会反复推荐用户刚否定的方向，也不会编造项目进展或实时天气价格。
阶段 7-9
星宝与产品体验重构
星宝从自动打断改为主动召唤；新增首轮任务入口、自适应发言人数、相关性记忆召回。
效果
降低信息负担；工作问题更像真实评审，不再固定三人套话，也减少旧记忆污染。
阶段 10-11
场景可视化与产品叙事
实现 6 个角色工位静态图层、状态气泡、星宝悬浮层，并明确“多角色人工智能产品评审群”定位。
效果
用户第一眼能理解这不是普通聊天框，而是一个有角色分工的评审空间。
阶段 12-14
账号、数据闭环、权限化调试
接入账号登录、核心数据表、数据仓库层、管理员面板和历史中断恢复。
效果
从纯本地演示进入可运营雏形：有账号隔离、持久化、调试入口。
个人贡献：从想法到可上线产品
体现的不是"会用 AI 写代码"，而是能把产品判断、系统拆解、工程交付和迭代验证串起来的能力。
从模糊想法到产品定义
把“AI 群聊”重新定义成“多角色 AI 产品评审群”，明确目标用户、核心场景、角色分工和 MVP 边界。
从 Prompt Demo 到可维护系统
没有停留在一个大 Prompt，而是拆成配置层、人格引擎、对话事件、任务路由、讨论编排、质量门、记忆和后端代理。
从本地玩具到线上可用
补齐 Supabase 登录、数据持久化、管理员调试入口、Vercel Function 生产入口和真实模型调用链路。
从能跑到能解释
把每次关键迭代沉淀成文档和页面，清晰展示每次改动的背景、解决的问题和当前风险。
体现的产品能力
问题定义、用户场景抽象、MVP 边界、功能优先级、体验取舍、产品叙事能力。
体现的 AI 产品能力
多 Agent 编排思路、提示词边界、角色差异、质量控制、记忆召回、防幻觉策略。
体现的工程能力
前后端集成、认证与数据闭环、生产部署、成本控制、调试后台、文档同步和可维护架构。
关键取舍与风险
这里说明产品当前的关键取舍、仍未完成的部分，以及后续为什么要这么排优先级。
星宝不自动跳出
早期自动总结会打断讨论并增加信息负担。当前版本改为用户主动召唤，先验证用户是否真的需要收束。
静态场景优先
先用静态工位图层建立产品识别度，暂不做复杂动画，避免把工程重心从对话质量转移到视觉特效。
真实模型固化
移除模拟人工智能切换，让演示和开发都面对真实模型表现，问题更早暴露在提示词、编排和质量门上。
角色仍可能套话
下一步要把角色输出从“视角差异”升级为可复用判断资产，例如商业假设、用户路径、技术边界和验证指标。
Cloudflare 尚未适配
Vercel 生产链路已经跑通；如果后续部署到 Cloudflare，需要把后端入口改成 Worker 的 fetch/request/env 风格。
通知提示会互相覆盖
保存成功、登录失败、额度用完这类短提示目前只显示最新一条；如果短时间连续触发，前一条会被顶掉，后续应改为通知队列。
长期规划
路线图围绕一个目标：从“能评审”升级为“能持续推进一个产品项目”。
近期高优先级
- 通知提示队列
- 模型测试面板完善
- Cloudflare 部署适配
- 构建包体积优化
产品体验
- 轮后操作条：补齐视角 / 收成结论 / 变行动项
- 角色输出资产化：假设、指标、风险、行动标准
- 更细的任务模板和行业模板
人工智能能力
- 更稳定的角色差异与反驳机制
- 质量门可观测化与自动评测集
- 更精准的长期记忆召回和遗忘策略
商业化
- 套餐管理与用量控制
- 团队空间与项目档案
- 评审报告导出与协作分享
常见问题
下面这些问题覆盖产品、工程、人工智能、数据、风险和规划，适合快速理解整个项目。
1. 这个产品的最小可行版本到底验证什么？
最小可行版本验证的是：当用户有一个产品想法或业务问题时，多角色人工智能评审是否比单一助手更能暴露盲区，并帮助用户形成下一步行动。当前版本已覆盖登录、真实模型调用、多角色编排、质量控制、记忆、星宝收束和数据持久化。
2. 项目做过哪些关键优化？
- 把单次多角色生成改成每角色独立串行生成，解决口吻趋同和脏前缀。
- 加入讨论编排器，为每个角色分配唯一职责，减少多人复读。
- 加入后端无证据硬拦截，避免编造历史进展、天气、价格等事实。
- 把星宝从自动打断改成主动召唤，降低用户信息负担。
- 把记忆召回改成相关性过滤，减少旧话题污染当前回答。
3. 为什么不用一个大提示词直接生成全部角色？
试过但废弃了。单次生成会让模型站在“导演/编剧”视角写群戏，角色口吻变得相似，还容易出现角色名前缀污染。现在每个角色独立调用，只拿自己的人设提示词，并接收前面角色的回复，因此更接近真实多人讨论。
4. 数据安全和账号隔离怎么做？
前端只使用公开的账号数据库地址和公开密钥。后端高权限密钥只放服务端环境变量。登录用户的数据按用户编号隔离；演示模式只写当前浏览器本地存储。
5. 目前最大不足是什么？
第一是 Cloudflare 还没有做单独适配；第二是角色输出还需要从“有不同视角”进化为“可复用判断资产”；第三是通知、模型测试面板和包体积还有工程优化空间。
6. 长期会做成什么？
长期目标不是只做一个有趣聊天页，而是做一个持续推进产品项目的人工智能工作空间：它能记录项目上下文、组织多角色评审、沉淀决策资产、生成行动项，并支持团队空间、评审报告和项目档案。