产品实现规划：ReviewPilot

技术选型原则

三个硬约束指导全部技术决策：

单人可维护：整个代码库一个人能在半天内理解全貌
零运维优先：能不部署服务端的，一律放客户端
渐进式复杂度：V1用最简单方案，不为"未来可能需要"提前架设基础设施

技术栈

V1技术栈总表

层级	选型	选型理由
扩展框架	Vanilla JS + Chrome Extension Manifest V3	零框架依赖，Chrome审核快（JobPocket案例：<24小时过审）
UI组件	原生HTML/CSS + 少量Tailwind CSS CDN	不引入React/Vue，减少bundle体积和审核风险
认证	Supabase Auth（Email + Google OAuth）	免费层支持50K MAU，自带Row Level Security
数据库	Supabase PostgreSQL	免费层500MB，足够前10K用户
AI推理	OpenAI GPT-4o API（主）+ Claude API（备）	GPT-4o最低$0.003/回复；提供模型切换降本
支付	Stripe Checkout + Customer Portal	全球支付+自动税务处理（通过MoR）
邮件	Resend（免费层100封/天）	评论摘要邮件
短信	Twilio（V2引入）	评论邀请短信（V2功能）
Hosting	无服务端——Chrome扩展纯客户端	零hosting成本
Edge Functions	Supabase Edge Functions（付费按量）	仅在需要服务端逻辑时使用（AI API Key保护等）
监控	Sentry（错误追踪）+ Supabase自带分析	免费层均够用
分析	Plausible（隐私友好的页面统计）	或直接用Chrome Web Store自带统计

为何不用框架

Chrome扩展使用React/Vue会带来三个问题：

审核风险：混淆/打包后的JS代码增加Chrome Web Store审核时间（明文Vanilla JS过审在24小时内）
权限膨胀：框架的依赖链可能导致manifest权限超出实际需要
调试困难：Service Worker、Content Script、Popup Panel三个上下文中的框架状态同步是已知痛点

V1坚持零框架。V2若UI复杂度显著增加，再评估引入Preact（3KB替代React）。

项目结构

reviewpilot-extension/
├── manifest.json              # Chrome Extension Manifest V3
├── icons/                     # 扩展图标（16/48/128）
├── popup/                     # 弹出面板
│   ├── popup.html
│   ├── popup.css
│   └── popup.js
├── content/                   # 页面注入
│   ├── content.js             # 主content script
│   ├── platforms/             # 各平台识别器+处理器
│   │   ├── google.js          # Google Business Profile
│   │   ├── yelp.js            # Yelp
│   │   ├── facebook.js        # Facebook Page
│   │   └── trustpilot.js      # Trustpilot（V2）
│   └── ui/                    # 内嵌面板UI
│       ├── reply-panel.css
│       └── reply-panel.js
├── background/                # Service Worker
│   └── service-worker.js
├── sidepanel/                 # 侧边栏
│   ├── sidepanel.html
│   ├── sidepanel.css
│   └── sidepanel.js
├── options/                   # 设置页面
│   ├── options.html
│   ├── options.css
│   └── options.js
├── shared/                    # 共享模块
│   ├── supabase.js            # Supabase客户端
│   ├── ai.js                  # AI调用封装
│   ├── stripe.js              # Stripe支付
│   ├── storage.js             # Chrome Storage API封装
│   └── utils.js               # 通用工具
├── tests/                     # 测试
│   ├── unit/
│   └── integration/
└── scripts/                   # 构建脚本
    ├── build.sh               # 打包脚本
    └── publish.sh             # Chrome Web Store发布

关键设计决策：

shared/ai.js是唯一调用LLM API的地方，所有平台的回复生成走同一入口。这意味着如果要切换模型（GPT→Claude）、添加缓存、或做成本控制，只需改一个文件。
content/platforms/下每个平台一个文件，各文件实现同一个接口（detect(), getReviews(), postReply()）。新增平台只需新增一个文件，不影响其他。
所有Chrome Storage操作通过shared/storage.js代理，不直接调用chrome.storage.*。未来如果要迁移到IndexedDB或云端存储，改一处。

数据模型

Supabase表结构

-- 用户表（Supabase Auth内置，扩展profile）
CREATE TABLE profiles (
  id UUID REFERENCES auth.users PRIMARY KEY,
  email TEXT,
  business_name TEXT,
  business_type TEXT,       -- restaurant/clinic/salon/...
  brand_voice TEXT,         -- professional/friendly/humorous/formal/warm
  brand_details JSONB,      -- {tone_keywords: [], response_style: "", custom_rules: ""}
  plan TEXT DEFAULT 'free', -- free/basic/pro
  stripe_customer_id TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 平台连接
CREATE TABLE platform_connections (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES profiles(id) NOT NULL,
  platform TEXT NOT NULL,   -- google/yelp/facebook/trustpilot
  platform_business_id TEXT, -- GBP place_id / Yelp business_id
  business_url TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  UNIQUE(user_id, platform, platform_business_id)
);

-- AI回复记录（用于品牌语音学习，V2）
CREATE TABLE reply_history (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES profiles(id) NOT NULL,
  platform TEXT,
  review_text TEXT,
  review_rating INTEGER,    -- 1-5
  ai_suggestion TEXT,        -- AI生成的建议
  final_reply TEXT,          -- 用户修改后实际发出的回复
  approved BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 订阅（Stripe Webhook同步）
CREATE TABLE subscriptions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES profiles(id) NOT NULL,
  stripe_subscription_id TEXT UNIQUE,
  plan TEXT,
  status TEXT,              -- active/past_due/canceled
  current_period_end TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

设计原则：V1 MVP不建reply_history表——先用localStorage缓存（每条回复<1KB，Chrome存储限制10MB够用10K条）。V2当品牌语音学习功能上线时再迁移到Supabase。

核心流程设计

流程A：商家回复一条评论（主流程）

1. 用户在浏览器打开Google Business Profile评论页面
2. Content Script检测到页面类型 → 注入内嵌回复按钮
3. 用户点击"AI回复"按钮
4. Content Script提取：评论内容 + 评分 + 评论者名称
5. 调用 shared/ai.js → GPT-4o生成3条回复建议
   - Prompt包含：品牌语气 + 评论内容 + 评分 + 回复策略
6. 内嵌面板展示3条建议，用户选择一条
7. 用户可编辑后点击"发布"
8. Content Script通过DOM操作填入回复框并提交
9. 记录回复到localStorage（后续同步到Supabase）
10. 更新popup面板中的回复率统计

流程B：新评论监控（后台服务）

1. Service Worker每15分钟激活（chrome.alarms API）
2. 遍历用户已连接的平台
3. 对每个平台：通过Supabase Edge Function代理请求（避免API Key暴露）
4. 对比上次检查结果 → 发现新评论
5. 触发Chrome通知（chrome.notifications API）
6. 更新badge数字（扩展图标上的未读数）
7. 如果有新评论且用户24小时未回复 → 发送邮件提醒（Resend）

注意：Google Business Profile的评论数据在2026年仍然没有完整的公开API。获取方式有两种：

方案A（V1采用）：Content Script抓取GBP管理页面的DOM，用户需打开GBP页面。评论监控通过Supabase Edge Function调用Google My Business API（需用户OAuth授权）。
方案B（备选）：纯Content Script方案——用户打开GBP页面时自动抓取并缓存评论列表。无法做后台监控，但可以做到零服务端成本。

V1优先方案B（纯客户端），V2迁移到方案A（Edge Function + OAuth）。理由：先验证用户愿意付费，再投资服务端基础设施。

流程C：用户注册与付费

1. 用户安装扩展 → 进入Onboarding页面（Options Page）
2. 输入品牌名称 + 选择行业 + 选择品牌语气 → 注册Supabase账号
3. 获得Free层权限（1个Google平台 + 10条AI回复/月）
4. 用户用完10条免费额度 → popup提示升级
5. 点击升级 → Stripe Checkout弹出（新标签页）
6. 支付完成 → Stripe Webhook → Supabase Edge Function更新plan字段
7. 扩展内plan状态刷新 → 解锁Basic/Pro功能

MVP开发排期（4周）

第1周：骨架搭建

天	任务	交付物
1-2	Manifest V3配置 + popup/sidepanel/options HTML骨架 + icons	可安装的空白扩展
3-4	Supabase项目创建 + Auth集成（Email + Google OAuth）	用户可注册/登录
5	Chrome Storage封装 + 平台连接CRUD	数据层完成
6-7	Google平台Content Script（检测GBP页面 + 提取评论）	可识别GBP页面并读取评论

第2周：核心AI功能

天	任务	交付物
8-10	shared/ai.js（GPT-4o调用 + 5种品牌语气Prompt模板）	AI可生成回复
11-12	内嵌回复面板UI（评论下展示AI建议 + 编辑 + 发布）	单条评论AI回复闭环
13-14	免费额度管理（每月10条，计数器 + 重置逻辑）	用量控制

第3周：面板与支付

天	任务	交付物
15-16	Popup面板（评论聚合流 + 快速操作 + 回复率显示）	弹出面板可用
17-18	Stripe集成（Checkout + Webhook + Customer Portal）	支付闭环
19-20	Options页面完善（品牌配置 + 订阅管理 + 账号设置）	设置页可用
21	Yelp平台Content Script	第二平台覆盖

第4周：打磨与发布

天	任务	交付物
22-23	错误处理 + 边界情况（未登录/评论已删除/API限流等）	产品稳定
24	Chrome Web Store素材准备（截图/描述/宣传图）	上架材料
25-26	内部测试 + 修复Bug	稳定版本
27	Landing Page搭建（reviewpilot.io，Vercel免费层）	官网
28	Chrome Web Store提交审核	等待上架

关键实现细节

AI Prompt设计

品牌的5种语气预设对应的System Prompt片段：

专业（Professional）：

你是一家{行业}的客服代表。回复需要正式、礼貌、专注于解决问题。使用完整的句子，保持专业距离，绝不使用表情符号或网络用语。

友好（Friendly）：

你是一家{行业}的老板，性格热情、真诚。回复需要温暖、人性化，可以适当使用表情符号，让顾客感觉像在跟朋友聊天。

幽默（Humorous）：

你是一家{行业}的有趣老板，擅长用幽默化解尴尬。回复可以轻松、有趣，但不失尊重。适合美食、娱乐等行业，不适合医疗、法律等行业。

正式（Formal）：

你是一家{行业}的高级经理。回复需要简洁、高效、直奔主题。不寒暄，不拖沓，每句话都有信息量。

温暖（Warm）：

你是一家{行业}的创始人，非常关心每一位顾客的感受。回复需要真诚、有共鸣，让顾客感受到"这家店真的在乎我"。

每条评论的User Prompt结构：

评论内容：{review_text}
评分：{rating}/5
评论者：{reviewer_name}

请生成3条回复建议：
1. 如果评分≥4：表达感谢并邀请再次光临
2. 如果评分=3：感谢反馈，认可具体问题，提出改进措施
3. 如果评分≤2：道歉，表示重视，提供联系方式（不公开争论）

回复长度：50-150字

安全设计

AI API Key存储在Supabase Edge Function环境变量中（不暴露给客户端）
客户端通过Supabase认证后的RPC调用Edge Function来获取AI回复（Supabase Auth JWT验证）
Stripe Webhook签名验证在Supabase Edge Function中完成
Content Script只操作评论页面的DOM，不读取非相关数据

成本控制

GPT-4o Mini（$0.15/1M input tokens, $0.60/1M output tokens）对评论回复场景足够，仅在用户选择"高质量"模式时使用GPT-4o
在shared/ai.js中实现响应缓存：相同或相似评论（余弦相似度>0.9）直接返回缓存结果，节省API成本
免费层用户的AI请求使用GPT-4o Mini；Pro用户默认GPT-4o（可降级）

验证节点

在写代码前需要先验证的三个核心假设：

假设1：本地商家愿意付费 → Landing Page + Waitlist + Reddit验证，30天内收集100+邮箱即通过

假设2：品牌语音定制有需求 → 对10个种子用户做30分钟访谈，问"如果AI回复听起来不像你，你会用吗？"

假设3：Chrome扩展形态优于独立网页 → A/B测试：Landing Page上同时展示"扩展+网页版"两个选项，测点击率差异

三个假设全部通过后再进入4周开发。任一假设不通过，调整方向后重新验证。

AI多平台评论管理Chrome扩展