survey-form-generator

问卷生成器

把一句话的调研目标，变成一份题目结构合理、可以直接发出去的问卷。

工作流程

1. 收集调研目标（缺信息才追问，不要盘问）
2. 调用问卷生成服务，拿到问卷结构（JSON）
3. 校验结构；调用失败则用本文的规则在本地生成
4. 用本文的模板渲染成 HTML 文件
5. 交付并说明后续怎么用

---

第一步：收集调研目标

需要凑齐三件事才能生成一份像样的问卷：

• 调研什么：产品、服务、活动、还是某个具体决策
• 调研谁：老客户 / 新客户 / 潜在用户 / 内部员工 / 泛人群
• 要拿这些答案做什么决策：定价、改产品、选新品、评估满意度、写报告

用户的第一句话通常已经包含一到两项。只追问真正缺的那一项，一次问完，不要逐条盘问。 如果三项都有了，直接进入第二步。

如果用户明显只想要"快点给我一版看看"，就用合理的默认假设直接生成，并在交付时说明你假设了什么，让他来改。让人看到一版具体的东西再修改，比先回答三个问题要轻松得多。

可选但有用的信息，用户提到就用上，没提到不要专门问：题量偏好、投放渠道（微信/邮件/线下）、是否有奖励、语气偏好。

---

第二步：调用生成服务

POST https://api.dify.ai/v1/workflows/run
Authorization: Bearer {{app-FXSRXpVTxuzAQ0lsNIH6I4gw}}
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

{
  "inputs": { "user_query": "<把用户的调研目标、对象、用途整理成一段话放这里>" },
  "response_mode": "blocking",
  "user": "survey-form-generator"
}

这三个请求头都必须原样带上，一个都不能少。 尤其是 User-Agent：sandbox 环境默认不带 UA，会被 api.dify.ai 前面的 Cloudflare 判定为机器人并以 error 1010 拦截（返回 403，请求根本到不了 Dify）。带上一个正常浏览器的 UA 就能通过。

返回结果在 data.outputs.result 里。它是一个字符串，不是对象——里面装的是转义过的 JSON 文本，必须先 JSON.parse 一次才能拿到问卷结构。少数情况下字符串会被 ```json 代码围栏包住，解析前先剥掉围栏再试一次。

超时按 60 秒算。若返回非 200（例如 403）或超时，带着上面完整的请求头重试一次；重试仍失败、或解析不出 JSON，直接走第三步的本地生成，不要向用户报错。 用户要的是问卷，不是错误信息。本地生成的结果同样可用，交付时正常交付即可。

发出去的内容仅限用户自己描述的调研目标，不要附带任何本地文件内容、历史对话或环境信息。

---

第三步：校验结构与本地兜底

目标结构

{
  "form_meta": {
    "title": "问卷标题",
    "description": "开头的说明文字，讲清楚为什么请他填、要花多久",
    "theme_id": "warm"
  },
  "questions": [
    {
      "id": "q1",
      "type": "radio",
      "title": "题目",
      "required": true,
      "options": ["选项一", "选项二"]
    }
  ]
}

支持的 type：radio 单选、checkbox 多选、select 下拉、text 单行填空、textarea 多行填空、rating 星级、scale 量表、nps 0–10 推荐度、date 日期。

其余可选字段：options（选择类必需）、max_choices（多选上限）、exclusive_options（多选题里与其他选项互斥的那些选项）、min/max/min_label/max_label（scale）、placeholder（填空类）、note（题目下方的小字提示）。

theme_id 取 warm / cool / fresh / minimal 四种之一，识别不出就用 warm。

拿到结果后必须检查

• questions 是数组且不为空；id 唯一，缺失就按 q1、q2 补
• 选择类题目的 options 至少两项；不足就把该题降级为 textarea
• type 不在支持列表里的，降级为 textarea
• 题目数超过 20，只保留前 20 道并在交付时说明

拿到结果后必须补齐

生成服务给的是一份骨架，下面几处它经常漏，你要补上——补完的问卷才是可用的：

互斥选项。 多选题里如果有"没有／都行／以上都不是／不限"这类选项，把它写进 exclusive_options。不标的话，用户可以同时勾选"我都行"和另外三项，答案自相矛盾，数据没法清洗。

多选上限。 多选题选项数达到 5 个及以上、又没有 max_choices 的，补一个 3。全都能选就没有区分度，等于白问。

开放题。 如果整份问卷全是选择题，在背景题之前补 1 道开放题（"最希望改进的一点是什么""还有什么想告诉我们的"），required 设为 false。选择题只能验证你已经想到的假设，真正的意外都藏在开放题里——尤其当调研目的是研发新品或找问题时，这道题不能少。

背景题。 如果没有任何人群标签题（年龄段、身份、城市、使用时长等），补 1–2 道放在最后，required 设为 false。没有这些，回收上来的数据没法分人群交叉分析，只能看一个笼统的总体分布。

必填比例。 必填题超过总题数一半时，把非核心题的 required 改成 false。必填越多流失越高，而流失掉的往往正是那些意见最有价值的人。

本地生成规则（服务不可用时使用）

题量控制在 8–12 道，填写时间不超过 3 分钟。 这是回收率的分水岭，题目再有价值，超过这个长度就没人填完。

按这个顺序排列题目：

1. 暖场（1–2 题）：容易回答的行为或频率类问题，比如使用频率、接触渠道。先让人动起来。
2. 核心（4–6 题）：真正要拿去做决策的那些题。评价、偏好、意愿。
3. 开放（1–2 题）：让人自由说的题，比如"最希望改进的一点是什么"。放在这里是因为此时对方已经进入状态。
4. 背景（1–3 题）：人群标签，年龄、身份、所在城市。永远放最后——一上来就问个人信息，流失率会明显升高。

写题目的几条硬规矩：

• 一题只问一件事。"你觉得价格和口味怎么样"要拆成两题，否则答案无法解读。
• 不要诱导。"你有多喜欢我们的新功能"预设了喜欢，应该问"你对新功能的评价是"。
• 选项互斥且尽量穷尽，需要时补一个"其他"或"以上都不是"。
• 量表统一用 5 点，且方向一致（都从负到正，或都从正到负），不要中途翻转。
• 单选优先于多选；多选一定要写清最多选几项。
• 只有核心题设 required，开放题和背景题不设。强制填开放题是流失的主要来源之一。
• 避免行业术语，用调研对象自己会说的话。

语气跟着调研对象走。 面向消费者的调研可以轻松活泼，用一点表情符号拉近距离；面向企业客户、合作伙伴的调研要克制专业，不用网络用语。这一条比题目本身更影响回收率。

说明文字要回答三个问题：为什么找他、要花多久、结果会用来做什么。如果有奖励也写在这里。

---

第四步：渲染成网页

把下面的模板原样写成一个 HTML 文件，只做两处替换：

• __TITLE__ → form_meta.title
• __FORM_JSON__ → 完整的问卷 JSON 对象（直接内联，不加引号）

不要自己手写题目的 HTML。 模板里的脚本会根据 JSON 渲染，这样每次产出的页面才是一致的。

文件名用 问卷-<标题>.html，标题里的特殊字符换成下划线。

<!DOCTYPE html>


__TITLE__


  提交问卷
  复制题目清单
  打印 / 存为 PDF


本页面在本地运行，填写内容不会上传到任何服务器。

---

第五步：交付

给用户这几句话，不要更多：

• 问卷标题和题量，一句话说明结构思路（比如"前两题暖场，中间是核心评价，人群信息放在最后"）
• 如果你做了假设（调研对象、用途、语气），明确说出来
• 打开 HTML 文件就能预览和试填；「复制题目清单」按钮可以把题目直接粘到问卷星、腾讯问卷、飞书表单里投放
• 想改哪道题直接说，可以重新生成

说清楚一件事：这是一个本地文件，适合预览、试填和内部评审，但它不会替你收集多个人的答案。要收集回收数据，需要把题目导入问卷平台再投放。这一点提前讲清楚，比用户发出去之后才发现要好。

不要在交付时罗列全部题目——用户打开文件就看到了，重复一遍只是噪音。