Skip to content

implementation_plan.md

Latest commit

 

History

History
160 lines (117 loc) · 9.09 KB

implementation_plan.md

File metadata and controls

160 lines (117 loc) · 9.09 KB

PitchPerfect CN: 微信小程序 AI PPT 纯国产化合规实施方案

版本：v1.0.0 日期：2026-01-21 状态：评审中

1. 项目背景与目标

核心目标：将原 PitchPerfect AI（基于 Gemini）的“大脑+画师”双流工作流，完整移植到微信小程序云开发（TCB）架构中，并进行全链路国产化替换，以满足微信小程序的严格合规要求（算法备案、域名白名单）。

核心价值：为 B 端销售场景提供“输入客户名，一键生成定制化 PPT”的解决方案，解决销售人员写方案慢、不精准的痛点。

2. 技术架构方案 (Technical Architecture)

采用 "云端大脑 + 异步工坊 + 流式交付" 的架构，解决小程序端算力弱、网络限制严的问题。

2.1 核心模型选型 (Model Selection)

模块 原方案 (Gemini) 新方案 (国产合规) 选型理由
Planner (大脑) Gemini 1.5 Pro DeepSeek-R1 / V3 国内推理能力最强，非常适合逻辑性强的大纲生成任务。通过 TCB AI 网关调用，无需额外配置域名。
Artist (画师) Imagen 3 腾讯混元 (Hunyuan) 腾讯生态原生支持，无需跨域，国内合规备案齐全，不仅能生图，未来还能微调风格。
Assembler (合成) 前端 pdf-lib 后端 pdf-lib (云函数) 移至云端合成，避免小程序端内存溢出 (OOM) 风险，且网速更快。
Storage (存储) Firebase Storage 腾讯云 COS 云开发自带，内网传输极快，无流量费用。

2.2 数据流向图 (Data Flow)

graph TD
    User[用户 (小程序)] -->|1. 输入需求| CloudFunc[云函数 ai_ppt]
    
    subgraph "Phase 1: Planner (Brain)"
        CloudFunc -->|调用| DeepSeek[DeepSeek-R1]
        DeepSeek -->|返回 JSON 大纲| CloudFunc
        CloudFunc -->|Stream 返回| User
    end
    
    subgraph "Phase 2: Artist (Studio)"
        User -->|2. 确认生成| CloudFunc
        CloudFunc -->|并发请求| Hunyuan[腾讯混元文生图 API]
        Hunyuan -->|返回图片 URL| CloudFunc
        CloudFunc -->|Save| COS[云存储]
    end
    
    subgraph "Phase 3: Assembler (Delivery)"
        CloudFunc -->|图+文合成| PDFLib[pdf-lib]
        PDFLib -->|生成 PDF| COS
        COS -->|下载链接| User
    end
Loading

3. 详细实施细节

3.1 云函数规划 (ai_ppt)

将创建一个单体云函数 ai_ppt，内部通过 action 路由分发不同任务：

  • Action: generate_outline (生成大纲)

    • 输入: 客户名称、行业、痛点。
    • 逻辑: 构造 Prompt，调用 DeepSeek-R1。DeepSeek-R1 自带思维链 (CoT)，能更好地拆解客户痛点。
    • 输出: 结构化 JSON（包含 8-10 页 PPT 的标题、要点、画面描述）。

  • Action: generate_images (批量生图)

    • 输入: 大纲 JSON。
    • 逻辑:
      • 不仅是简单的循环，而是并发控制（例如 Promise.all 限制并发数 3-5）。
      • Prompt 优化: 在调用混元前，先用 DeepSeek 将中文画面描述翻译并优化为混元更易理解的英文/中文 Prompt 关键词。
    • 输出: 图片 URL 映射表 { 1: "cloud://.../p1.png", 2: "..." }。

  • Action: assemble_pdf (合成交付)

    • 输入: 大纲 JSON + 图片 MAP。
    • 逻辑: 加载标准底板（Logo、页码架构），将 AI 生成的图片作为层叠加，再绘制文字。
    • 输出: PDF 的 fileID。

3.2 混合渲染策略 (Hybrid Rendering)

为了平衡成本（混元 API 调用费）和速度，采用混合策略：

  • T1: 标准页 (Standard Slides)
    • 封面、目录、封底、公司简介：直接使用云存储中的高清静态图。
    • 优势：0等待，0成本。
  • T2: 定制页 (Custom Slides)
    • 痛点分析、解决方案、场景落地：调用混元实时生成。
    • 优势：千人千面，直击客户痛点。

4. 合规性与风险控制

  1. 内容安全 (Content Safety):
    • 云函数输出端集成腾讯云文本内容安全 (TMS) 接口，过滤敏感词。
    • 生图接口混元自带审核，但我们需处理“生成失败/违规”的 Fallback 逻辑（如显示默认占位图）。
  2. 标识规范:
    • 所有生成的 PDF 页脚强制添加水印：“本内容由人工智能生成，仅供参考”。
  3. 服务类目:
    • 小程序需确保补充“深度合成-AI问答/AI绘画”类目（视实际上线情况而定，Demo 阶段可暂缓，但正式版必须有）。

5. 专家评审意见模拟 (Expert Review)

以下模拟了三位不同背景专家的评审意见：

👨‍💻 专家 A：架构师 (专注于性能与稳定性)

意见: "架构整体合理，将重计算逻辑（生图、PDF合成）全部移至云端是明智的。但我有两个担忧：

  1. 云函数超时: 混元生图较慢，如果生成 10 张图，可能会超过云函数 60s/90s 的执行时限。建议把生图做成异步任务队列，由前端轮询状态，而不是一个长链接死等。
  2. PDF-Lib 字体: 在云端合成 PDF 渲染中文时，必须加载中文字体文件（如思源黑体），这文件很大（10MB+），每次云函数冷启动都加载会很慢。建议将字体文件放在层（Layer）中，或利用 CFS 挂载。"

⚖️ 专家 B：法务合规专家 (专注于风控)

意见: "方案在合规性上做了很大改进。特别提醒几点：

  1. DeepSeek 接入方式: 必须确认是通过腾讯云官方网关调用的，而不是直接调 DeepSeek 的公网 API，否则依然有域名白名单问题。
  2. 水印: 仅仅在 PDF 加水印不够，小程序预览界面每张 AI 生成的图上，最好也加上半透明的 'AI Generated' 标记。
  3. 用户协议: 在用户点击'生成'按钮前，必须有一个勾选框：'我已知晓内容由 AI 生成并同意《AI 服务免责协议》'。"

🎨 专家 C：产品体验专家 (专注于 UX)

意见: "流程上通顺，但体验可能不够‘性感’。

  1. 过程感: 生成大纲到生图中间可能有 30-60 秒的空白期。建议在前端做一个'伪终端'效果，滚动显示日志：'正在分析行业痛点...', '正在构思画面...', '混元画师正在绘图...'，缓解等待焦虑。
  2. 可干预性: 用户如果对 DeepSeek 生成的某条文案不满意，在生图之前一定要给修改机会。'生图'是最贵的步骤，一旦画出来再改就浪费了。确认环节至关重要。"

6. 最终修正决议 (Action Items)

基于专家评审，对方案做如下修正：

  1. 异步队列: 采纳专家 A 意见，前端采用轮询机制查生图进度，防止超时。
  2. 字体优化: 将字体文件打包进云函数代码包（或使用 CDN 链接缓冲），确保中文渲染正常。
  3. 增强 UX: 增加详细的 Loading 状态文案，并确保大纲生成后提供**“编辑/确认”**步骤。
  4. 合规补全: 确认使用 TCB AI 网关调用 DeepSeek；在 UI 上补充 AI 标识和免责协议。

7. 实施日志 (Implementation Log)

2026-01-22: 核心链路修复与稳定性优化

本此更新集中修复了支付链路和基础导航体验中的严重阻断性 Bug。

7.1 订单取消功能修复

  • 问题: 用户点击取消订单报错“订单不存在”或状态未更新。
  • 原因:
    • 环境不一致: 开发环境/真机调试的 OpenID 不一致，导致数据库查询不到对应订单。
    • 代码逻辑: 云函数中过于严格的 _openid 校验阻碍了对脏数据的清理。
  • 解决:
    • 后端: 重构 cancelOrder 云函数，临时放宽权限清理脏数据，随后恢复了严格的 OpenID 校验以保障安全。优化了错误日志输出。
    • 前端: 改进了 cancelOrder 的交互反馈（Loading/Toast），并确保操作成功后立即重载列表。

7.2 导航系统修复 (Double Back Issue)

  • 问题: 从“试用页”进入“确认订单页”后，点击顶部返回按钮直接退回“首页”，跳过了“试用页”。
  • 原因: t-navbar 组件自带返回逻辑，而页面代码中又绑定了 bind:go-back 并再次调用 navigateBack，导致触发了两次返回 (Double Back)。
  • 解决: 删除了 intent/confirm/index.js 中冗余的 goBack 函数及 WXML 绑定，遵循减法调试原则。

7.3 TabBar 状态同步

  • 问题: “我的”页面底部导航栏高亮错误（停留在“首页”）。
  • 原因: 自定义 TabBar 需要在每个 Tab 页面的 onShow 中手动更新选中态，pages/mine/index.js 缺失了这段逻辑。
  • 解决: 在所有 Tab 页面（包括 Mine, Index, Chat, Solution）的 onShow 中确保了 getTabBar().setData({ selected: index }) 的逻辑存在且正确。

7.4 流程优化

  • 建立了 《Antigravity 调试总纲》 (.agent/workflows/debug_protocol.md)，确立了“先诊断后编码”和“减法定位”的原则。