# AI 生成题目方案（对话式出题）

> 文档状态：方案讨论 / 待评审
> 创建日期：2026-06-16
> 背景：当前小程序与同类应用差异不明显，用户画像不够精准。探索引入 AI 能力——用户用自然语言描述需求，AI 将其翻译为对预置「技能（绘制方法）」的调用，并完成出题与绘制。

---

## 一、战略层面：先想清楚「为什么要做」

本方案在技术上完全可行，但要避免 AI 沦为「为差异化而加的功能」，而非「解决真实痛点的功能」。立项前需先回答：

- **用户的真实痛点是什么？** 是「找不到合适的题目」，还是「孩子不爱练」「不知道该练什么」？如果痛点不在出题，AI 出题器再酷也救不了留存。
- **家长真的会打字描述需求吗？** 「我想要培养数感的题目」这类话，家长未必说得出（多数人不知道「数感」是什么）。更真实的诉求往往是「我家娃 5 岁，给我今天该练的」。这意味着 AI 的价值可能不在「自然语言理解」，而在 **「帮不懂教育的家长做决策」**。
- **不用 AI 能否满足 80%？** 如果几个下拉框 + 模板就能满足，AI 的边际价值仅是「输入方式更自然」，通常撑不起差异化。

**结论 / 定位建议：** 把 AI 定位成 **「懂教育的助教」**（帮家长判断该练什么、循序渐进地推荐），而不是 **「自然语言转绘制指令的翻译器」**。前者是真差异，后者只是花哨的表单。

---

## 二、技术层面：经典的 Function Calling / Tool Use 架构

「把需求变成可调用的技能」在工程上的成熟范式叫 **工具调用（tool use / function calling）**：已有的「绘制方法」即工具，LLM 负责把人话翻译成「调用哪个工具 + 什么参数」。

### 2.1 整体数据流（小程序云开发）

```
用户输入(自然语言)
  → 小程序前端 (聊天式 UI)
  → 云函数 ai-orchestrator
  → 调用 LLM(带 tools 定义)
       ├─ 缺参数 → 返回追问("孩子几岁？")  ← 多轮
       └─ 参数齐全 → 返回结构化调用意图
  → 确认环节(用户点"确认生成")
  → 云函数 / 前端调用内置绘制方法
  → 生成题目数据 + 渲染(canvas/图片)
  → 返回前端展示 / 保存 / 下载
```

### 2.2 关键模块

**1）技能注册表（最核心）**
每个绘制方法描述成一个 tool schema，让 LLM 知道有哪些能力、各需要什么参数：

```json
{
  "name": "generate_number_sense",
  "description": "生成培养数感的练习题（比大小、数的分解、数数等）",
  "parameters": {
    "type": "object",
    "properties": {
      "age":        { "type": "integer", "description": "孩子年龄 3-8" },
      "sub_type":   { "type": "string", "enum": ["比大小", "数的分解", "按数取物"] },
      "count":      { "type": "integer", "description": "题目数量" },
      "number_range": { "type": "string", "enum": ["1-10", "1-20", "1-100"] }
    },
    "required": ["age", "sub_type", "count"]
  }
}
```

**2）LLM 选型（国内合规很重要）**
云函数可发 HTTP 请求，能接任意 LLM。国内备案合规、且支持 OpenAI 兼容 function calling 的可选：**通义千问、豆包(火山方舟)、DeepSeek、文心、混元**。微信云开发本身也有「AI 能力 / 微信对话开放平台」。建议挑一个支持 `tools` 参数的，编排逻辑几乎无需自写。

**3）多轮对话 + 槽位填充（slot filling）**
「缺年龄就追问年龄」的逻辑交给 LLM 判断，比手写 if-else 更强。需要做的只是：

- 每轮带上对话历史（存云数据库或前端回传）；
- 在 system prompt 里要求：「参数不全时先友好追问，不要瞎猜」。

**4）「决策」与「生成」必须分离 ⚠️（最重要的工程原则）**
让 LLM 决定「生成什么」（结构化参数），但题目实际内容由确定性代码生成：

- ❌ 不要让 LLM 直接吐出 20 道算术题——会算错、会重复、不可控。
- ✅ 让 LLM 输出 `{age:5, sub_type:"比大小", count:20, range:"1-10"}`，再由绘制方法按规则生成 + 渲染。

兼得 AI 的「听得懂人话」与传统代码的「100% 正确可控」。

**5）确认环节**
真正调用绘制方法前，把解析出的参数回显给用户确认（「将生成 20 道 1-10 比大小，确认？」）。既防误解，也是好体验。

### 2.3 小程序云开发的几个坑


| 坑              | 说明 / 对策                                                                               |
| -------------- | ------------------------------------------------------------------------------------- |
| **云函数超时**      | 默认 20s，LLM 调用可能慢。先做**非流式**（一次返回）；想要打字机效果，后期再用 WebSocket 或 HTTP 触发器 + SSE，复杂度高，别一开始就做。 |
| **内容安全（必须）**   | 微信强制要求。用户输入和 AI 输出都要过 `security.msgSecCheck`，否则可能被封。合规硬要求，非可选。                        |
| **API Key 保护** | LLM 的 key 只能放云函数环境变量，**绝不能进前端**。                                                      |
| **成本与频率**      | 每次对话烧 token。加缓存（相同需求复用）、限频，防刷。                                                        |
| **冷启动延迟**      | 云函数冷启动 + LLM 延迟叠加，首次可能 3-5s，UI 要有 loading 反馈。                                         |


---

## 三、要不要把绘制方法搬到服务端？

**短答：不需要把「绘制」搬到服务端。但要先把现有方法拆成两层——「出题数据」和「画图」——只有前者可能值得上服务端，后者留在小程序里。**

### 3.1 把「绘制方法」拆成三层

```
① 意图理解层   用户人话 → 结构化参数      ← 必须在服务端(云函数 + LLM)
② 出题数据层   参数 → 题目数据(JSON)       ← 可服务端、可客户端
③ 渲染绘制层   题目数据 → canvas 画出来     ← 留在小程序前端
```

现有「绘制方法」大概率是 ②③ 混在一起（一个函数既算题目又调 `wx.canvas` 画图）。做 AI **真正要做的不是「搬到服务端」，而是「把 ② 和 ③ 解耦」**。

### 3.2 为什么渲染层（③）不该搬服务端

- 小程序 canvas 是**客户端 API**，云函数（Node 环境）里没有 DOM、没有原生 canvas；要画图得引 `node-canvas` 之类，又重又易踩坑，得不偿失。
- 渲染留前端：性能好、可交互（手写、橡皮擦等）、省服务器成本。

→ ③ **保持现状，一行都不用动**。

### 3.3 ② 出题数据层：搬不搬都行

**方案 A — 什么都不搬（最快上线，推荐起步）**
云函数只做 ①，返回结构化参数给前端：

```js
// 云函数返回
{ skill: "number_sense", age: 5, sub_type: "比大小", count: 20, range: "1-10" }
```

前端拿到参数，调已有的出题 + 绘制方法，照常跑。AI 是「加在前面的一层翻译」，老代码完全复用。

**方案 B — 把出题逻辑(②)搬服务端**
云函数直接算好题目数据返回：

```js
{ problems: [ {left:7, right:3, op:">"}, {left:2, right:8, op:"<"}, ... ] }
```

前端只负责画。

什么时候才值得选 B：

- 出题逻辑要**保密/防作弊**（题库、难度算法不想暴露前端）；
- **多端复用**（以后有 H5、APP，出题逻辑只维护一份）；
- 出题需要**服务端资源**（查数据库题库、调别的接口）。

以上都没有，**先选 A**。

### 3.4 关键动作

唯一的关键动作：**确保出题逻辑是个「纯数据函数」（输入参数、输出 JSON、不碰 canvas）**。做到这点，搬不搬服务端都是后话，随时可切。

---

## 四、最小可行起步（MVP）

别一上来做全套对话系统，先做最小闭环验证：

1. **单个技能**：只挑「数感题目」一个绘制方法接进来。
2. **单轮或两轮对话**：用户说需求 → AI 解析参数（缺了追问一次）→ 确认 → 生成。
3. **跑通链路**：「人话 → 结构化参数 → 已有绘制方法」。

跑通后回答关键问题：**家长真的会用自然语言输入吗？还是更想点几下就出题？** 用真实数据决定是否继续往「对话式」投入，而非凭感觉。

---

## 五、待办 / 下一步

- [ ] 盘点现有「绘制方法」清单及调用方式，判断 ②③ 缠绕程度。
- [ ] 确定 LLM 供应商（合规 + 支持 function calling）。
- [ ] 抽离一个出题逻辑为纯数据函数（以「数感题目」为试点）。
- [ ] 搭建 `ai-orchestrator` 云函数骨架 + 技能注册表。
- [ ] 接入内容安全 `msgSecCheck`。
- [ ] MVP 灰度，观察家长真实输入行为与转化数据。