用大模型API构建心理测试结果生成服务，从后端到提示词

心理测试：我最吸引人的特质是什么？我选 DC。看到这种题，大多数人第一反应是直接翻到答案页，看看 D 和 C 分别意味着什么。但如果是做技术开发的人，大概率会多想一步：这个答案到底是人工编写的静态文案，还是根据选项动态生成的？一套问卷从点选到出结果，后端到底做了什么？更进一步，如果我想给自己团队、公众号或者个人站点做一个类似的轻量互动测试，用大模型 API 能不能快速落地？

这篇文章不打算给某个特定心理测试模板做“标准答案解读”，而是直接从工程视角拆解一个可运行的方案：前端给用户展示若干选择题，用户按直觉选择 D/C，后端接收选项后调用大模型接口，自动生成一段“最吸引人的特质”分析文案。文中会覆盖接口设计、提示词模板、本地 mock 测试、批量任务、调用成本与合规边界。如果你最近想把“互动测试 + 大模型生成”这个小玩法做成一个真实可用的服务，这篇文章可以直接当参考。

1. 先看这类测试工具的核心能力范围

不管是“我最吸引人的特质”还是其他娱乐型心理测试，产品侧需求大体是一致的：用户点选项，页面给出个性化结果，结果不能千篇一律，体验要快，内容要正面且没有冒犯性。从技术侧看，这类工具可以拆成三块：

从材料视角看，这里的 D 和 C 并没有一组公认的心理学映射关系。大多数娱乐型测试使用的是自制标签库，例如 D 对应“果断/直接/行动力强”，C 对应“细腻/重视关系/善于倾听”，再由模型生成完整文案。真要接入一个工具，必须先有这一层映射配置。

需要提醒的是，这类基于少数选项得出的结论缺少心理测量学意义上的效度和信度，不能用于人格评估、职业规划或心理状况判断。它更适合当体验工具，而不是诊断工具。

2. 系统结构：一个选项组合如何变成一段分析文案

整体链路很简洁：浏览器或小程序端提交用户选项 → 后端把它映射成若干人物特质关键词 → 后端组装提示词并发送给大模型 → 大模型返回一段自然语言分析 → 后端做基本安全检查和缓存 → 浏览器展示结果。

这个流程和常见的聊天机器人不太一样。聊天机器人是多轮对话，情绪状态是开放的；这类测试则是单次请求，输出范围相对固定。因此后端除了调模型，还要做几件额外的事：保持问卷题目和选项的配置化、结果文案的长度控制、避免模型生成确定性过强的判断语气、在异常情况下提供兜底输出。

题目的数据结构可以设计成 JSON。用配置而非写死代码，后续加题目、改选项、调结果风格会方便很多：

{ "quiz_id": "attractive_trait_001", "quiz_title": "我最吸引人的特质是什么？", "questions": [ { "id": 1, "text": "在陌生人聚会中，你更倾向于怎么表现？", "options": [ { "code": "A", "text": "主动组织话题，让大家快速熟起来" }, { "code": "B", "text": "先观察环境，等到自己熟悉的领域再开口" }, { "code": "C", "text": "一对一聊天，真诚倾听对方的故事" }, { "code": "D", "text": "用行动带动气氛，比如提议玩游戏或走位分享" } ] } ], "trait_map": { "A": "热情开朗、表达能力强", "B": "观察敏锐、思考深入", "C": "共情力强、让人感到安心", "D": "执行力强、能推动事情往前走" } }

用户选完所有题目后，前端把答案数组提交给后端。后端只需要统计每个选项出现的位置，再通过trait_map生成一段简短的关键词序列。比如答案组合里有较多 C 和 D，那系统可以给模型输入“用户特质倾向：共情力强、让人感到安心；执行力强、能推动事情往前走”，让模型基于这些词生成正式文案。

前端页面不是这篇文章的重点，但可以做得非常简单：一个静态 HTML 加几十行 JavaScript 就能完成交互。由于不是完整的大型系统，不需要引入重型状态管理库。调用接口时，把答案格式统一成数组，方便后端解析。

3. 本地开发环境准备

如果这个测试服务要走“云端大模型 API + 本地后端”的路线，对硬件要求很低。普通办公电脑、云服务器、树莓派都可以跑后端，因为推理发生在模型服务端。这里给出一个通用环境清单：

• 操作系统：Windows 10/11、macOS、Linux 均可。
• 运行环境：Python 3.9 或更高版本。
• Web 框架：FastAPI 或 Flask，建议 FastAPI，自带接口文档。
• 依赖库：requests、uvicorn、pydantic。
• 模型能力：准备一个大模型 API Key，或者本地服务地址。
• 磁盘空间：项目本身几十 MB 就够，不下载大模型的情况下没有额外压力。
• 网络条件：后端需要能访问模型 API 的公网地址，若模型部署在局域网则不需要。

用 pip 安装依赖：

pip install fastapi uvicorn requests pydantic

如果你完全没有模型 API，也可以先把服务做成“mock 模式”：固定返回几套模板文案，等拿到 API Key 后再切换真实模型。这样可以把前端联调和后端逻辑拆开，是最稳妥的开发方式。

4. 后端接口设计与提示词模板

后端暴露一个接口，例如POST /api/analysis。请求体包含用户标识、题目 ID 和答案数组，返回体包含结果文案和一个状态字段。用 FastAPI 写一个最小实现思路如下：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List import requests import time app = FastAPI() class AnalysisRequest(BaseModel): quiz_id: str answers: List[str] # 例如 ["D", "C"] class AnalysisResponse(BaseModel): code: int message: str data: dict TRAIT_MAP = { "A": "热情开朗、表达能力强", "B": "观察敏锐、思考深入", "C": "共情力强、让人感到安心", "D": "执行力强、能推动事情往前走" } def build_prompt(combined_traits: str) -> str: return f""" 你是一个轻松的社交互动文案助手。请根据用户测试得到的特质关键词，生成一段关于“最吸引人的特质”的分析。 用户特质关键词：{combined_traits} 要求： 1. 语气正面、真诚，不要过度吹捧。 2. 避免使用“你一定”“你就是”这种确定性过强的判断。 3. 可以适当给出一些小场景举例。 4. 最后一句话给出一个可执行的社交小建议。 5. 不要涉及心理治疗、诊断或医学建议。 6. 全文控制在 200 字以内。 """ def call_llm(prompt: str) -> str: # 这里需要替换成你自己的模型 API 地址、Key 和参数格式 url = "https://your-llm-endpoint/v1/chat/completions" headers = { "Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/json" } payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个安全的、温和的社交文案助手。"}, {"role": "user", "content": prompt} ], "temperature": 0.7, "max_tokens": 500 } resp = requests.post(url, headers=headers, json=payload, timeout=30) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"].strip() @app.post("/api/analysis", response_model=AnalysisResponse) def analysis(req: AnalysisRequest): # 简单校验 if not req.answers: raise HTTPException(status_code=400, detail="答案不能为空") traits = [] for code in req.answers: if code in TRAIT_MAP: traits.append(TRAIT_MAP[code]) if not traits: raise HTTPException(status_code=400, detail="无法识别答案选项") combined = "、".join(traits) # mock 模式：可以直接返回模板 if MOCK_MODE: generated_text = f"你的特质倾向是{combined}。这说明你在人际关系里经常给人留下一种可靠又主动的印象。" else: prompt = build_prompt(combined) try: generated_text = call_llm(prompt) except Exception as e: generated_text = f"当前模型服务暂不可用，请稍后再试。技术原因：{e}" return AnalysisResponse( code=0, message="success", data={"result": generated_text, "traits": traits} ) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="127.0.0.1", port=8000)

这段代码里面有几个明显占位符：YOUR_API_KEY、your-llm-endpoint、your-model-name。不同模型服务的请求地址和返回字段可能存在差异，需要按实际服务商文档替换。

提示词模板是整个服务风格的关键。心理测试和通用问答不太一样，用户心理预期是“被看见、被认可”，所以提示词里不要出现过于负面的标签。下面是一个推荐提示词策略：

• 角色设定为“轻松的社交互动文案助手”，不叫“心理医生”或“人格专家”。
• 让模型以“可能性”而非“确定性”来描述特质。
• 要求最后补一个小建议，让用户感觉测试有实际参考价值。
• 不允许模型渲染诸如“你是一个内向者/外向者”这种标签化结论，更不允许给出人生建议。

如果接的是国内模型或开源模型，温度参数建议 0.7 到 0.9 之间。温度太低容易输出重复模板，太高则可能跑题。max_tokens控制在 500 上下比较合适，结果太长测试页不好排版，太短又显得文案单薄。

5. 前端页面接入：从 HTML 提交到展示结果

前端不需要做成复杂项目。最省事的方式是写一个静态页面，内置题目和选项，点击按钮后用fetch请求后端接口。下面是一个实现思路：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>心理测试 - 我最吸引人的特质是什么</title> </head> <body> <div id="app"> <h2>我最吸引人的特质是什么？</h2> <div id="question-list"></div> <button id="submit-btn">查看结果</button> <div id="result-box" style="margin-top:20px;white-space:pre-wrap;"></div> </div> <script> const quizData = [ { id: 1, text: "在陌生人聚会中，你更倾向于怎么表现？", options: [ { code: "A", text: "主动组织话题，让大家快速熟起来" }, { code: "B", text: "先观察环境，等到自己熟悉的领域再开口" }, { code: "C", text: "一对一聊天，真诚倾听对方的故事" }, { code: "D", text: "用行动带动气氛，比如提议玩游戏或走位分享" } ] } ]; const answers = {}; function renderQuestions() { const container = document.getElementById("question-list"); container.innerHTML = ""; quizData.forEach(q => { const box = document.createElement("div"); box.style.marginBottom = "20px"; box.innerHTML = `<p>${q.id}. ${q.text}</p>`; q.options.forEach(opt => { const label = document.createElement("label"); label.style.display = "block"; label.innerHTML = ` <input type="radio" name="q${q.id}" value="${opt.code}" /> ${opt.code}. ${opt.text} `; label.querySelector("input").addEventListener("change", function () { answers[q.id] = this.value; }); box.appendChild(label); }); container.appendChild(box); }); } async function submit() { const answerCodes = Object.keys(answers).map(id => answers[id]); const btn = document.getElementById("submit-btn"); btn.disabled = true; btn.textContent = "生成中..."; try { const resp = await fetch("http://127.0.0.1:8000/api/analysis", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ quiz_id: "attractive_trait_001", answers: answerCodes }) }); const data = await resp.json(); document.getElementById("result-box").textContent = data.data ? data.data.result : "接口返回数据异常"; } catch (err) { document.getElementById("result-box").textContent = "请求失败：" + err; } finally { btn.disabled = false; btn.textContent = "查看结果"; } } document.getElementById("submit-btn").addEventListener("click", submit); renderQuestions(); </script> </body> </html>

这里我在代码中硬编码了一个题目，实际使用可以把题目放到后端下发，前端动态渲染。如果有多个题目，可以选择全部答完再提交，也可以一题一题滑动进入。单页应用即可，不需要引入外部 UI 库。

启动后端服务：

uvicorn main:app --host 127.0.0.1 --port 8000

再在浏览器打开静态 HTML 文件，点选一个或多个答案，点击“查看结果”。如果后端返回成功，页面上会出现基于选项组合生成的文案。

6. 用“我选 DC”跑一次完整链路

现在把标题里的“我选 DC”当作用户实际提交数据，走一遍接口链路。先准备一份不含真实 API Key 的请求示例，方便你理解数据结构。

打开终端，用 curl 直接测试后端：

curl -X POST http://127.0.0.1:8000/api/analysis \ -H "Content-Type: application/json" \ -d '{"quiz_id": "attractive_trait_001", "answers": ["D", "C"]}'

后端收到请求后，先遍历TRAIT_MAP，把 D 映射为“执行力强、能推动事情往前走”，C 映射为“共情力强、让人感到安心”。组合后得到：

执行力强、能推动事情往前走、共情力强、让人感到安心

接下来提示词会告诉模型：用户具有这种组合特质，请生成文案。最终返回的 JSON 结构类似：

{ "code": 0, "message": "success", "data": { "result": "你身上最容易被注意到的，是你面对事情时那种说做就做的冲劲。你不喜欢让气氛一直悬着，往往会先给一个方向。与此同时，你并不是只顾闷头往前冲的人，你对别人的情绪有很强的感知力。这两点组合在一起，让你在朋友圈里既像一个可靠的行动者，又像一个能接住情绪的人。在某些需要推动协作的场景，你常常会成为大家默认的发起人。", "traits": [ "共情力强、让人感到安心", "执行力强、能推动事情往前走" ] } }

注意编码顺序。如果 answers 数组是["D", "C"]，先插入的是 D 映射，后面 C 映射追加；不同测试页可能希望输出时把“最核心的特质”放前面，那需要在trait_map之外再维护一套排序规则。

在还没接入真实模型 API 之前，可以把MOCK_MODE设置为 True，此时后端不会发起 external call，而是返回模板文案。这样可以先把前端页面、接口结构、错误处理全部调通，再切换成真实模型。开发时利用 mock 模式有一个明显好处：接口测试不花钱，也不受模型服务网络波动影响。

要判断这次链路是否成功，不需要盯着模型文案质量，只需要确认几点：

• curl 返回 HTTP 200。
• 返回 JSON 中code字段为 0。
• data.result非空，且能看到选项映射出的关键词出现在文案附近。
• 重复提交同一组答案，只要打开 mock 模式，返回结果应该一致。
• 关闭 mock 模式后，同一组答案可能每次略有差异，这是模型采样导致的正常现象。

如果在真实模型调用时出现超时，可以在代码里把请求超时从 30 秒再降或调高。娱乐测试场景最好把超时控制在 10 秒之内，避免用户等待过久。一旦超时，直接用兜底文案返回，不要等下一次重试，否则结果页体验会很差。

7. 批量任务：同时分析几十个“选项组合”怎么办

如果只是自己测试一个链接，串行请求没什么问题。但如果要做推广活动，一份问卷在短时间内可能收到大量用户提交，模型接口并发能力就成了瓶颈。这个环节需要有批量任务设计。

批处理场景可以简单理解成：从数据库、Excel 或 CSV 里读取一批用户的答案，逐个调用后端接口，把结果写回文件。在没有现成数据的情况下，可以先用一个小脚本模拟：

import csv import time import requests input_file = "answers.csv" output_file = "outputs.csv" headers = { "Content-Type": "application/json" } with open(input_file, "r", encoding="utf-8") as f: reader = csv.DictReader(f) rows = list(reader) with open(output_file, "w", encoding="utf-8", newline="") as f: writer = csv.writer(f) writer.writerow(["user_id", "answers", "result", "status"]) for row in rows: user_id = row["user_id"] answers_str = row["answers"] # 例如 "D,C" answer_codes = [x.strip() for x in answers_str.split(",") if x.strip()] try: resp = requests.post( "http://127.0.0.1:8000/api/analysis", headers=headers, json={"quiz_id": "attractive_trait_001", "answers": answer_codes}, timeout=15 ) data = resp.json() if data.get("code") == 0: writer.writerow([user_id, answers_str, data["data"]["result"], "success"]) else: writer.writerow([user_id, answers_str, "", data.get("message", "unknown")]) except Exception as e: writer.writerow([user_id, answers_str, "", str(e)]) time.sleep(0.2)

这段代码是线性串行，适合几十条到几百条的小批量。如果数量达到几千，建议用并发或消息队列。简单的并发方案是用ThreadPoolExecutor，例如每次控制 3 到 5 个请求并发，避免把本地服务或模型 API 打爆：

from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(row): # 调用 /api/analysis，返回 row + result pass with ThreadPoolExecutor(max_workers=5) as executor: futures = {executor.submit(process_one, row): row for row in rows} for future in as_completed(futures): result = future.result() # 写入 CSV 或数据库

批量任务真正要处理的不是“并发”本身，而是失败恢复。建议每个请求都记录请求参数和返回报文。某一行失败时，不要直接丢弃，写到failed.csv，全部跑完后单独重试。

批量场景还有一个隐藏问题：同质内容刷屏。如果一个测试题只有两三个维度，大量用户的答案组合可能只有几十种。前端显示看似千人千面，但模型输出很多内容高度相似。缓存策略在这种情况下很有价值：把"D,C"这种组合作为 key，第一次生成后存到 Redis 或文件缓存里，后续同样组合直接返回缓存，能省下不少调用成本。

8. 资源占用与调用成本观察

因为这是一个偏业务应用的技术方案，资源消耗和模型推理性能需要分开看。

• 后端服务器本身的 CPU、内存占用通常很低，因为没有做重计算。
• 如果接入云端大模型 API，瓶颈在外部服务响应时间，而不是本地资源。
• 如果模型公司服务不稳定，需要设计超时和降级文案。
• 如果改为本地部署开源模型，才需要关注显存。显存占用与模型参数量、量化位数、并发数有直接关系，不能简单给一个固定数字。

性能观察重点是请求日志。每次调用应当记录：

• 请求进入时间与响应完成时间。
• 答案组合编码。
• 模型返回内容长度。
• 是否走了缓存。
• 是否触发了异常。
• 如果使用了多模型路由，还要记录命中了哪个模型。

以一天 1000 次请求为例，如果每个请求消耗约 300 到 500 token，很多时候 prompt 是固定的，输出文本占大头。先通过日志统计平均 token 消耗，再估算成本，这样才不会在活动结束后收到账单才发现超支。

对于低成本运行，有几个实用建议：

• 常用答案组合的结果做缓存，缓存时间可以设置 24 小时以上。
• 前端先展示“基础关键词组合”，模型生成文案延迟返回，避免接口阻塞太久。
• 对长文生成场景，控制max_tokens，例如只要 200 字左右就设置 300，避免模型多写浪费 token。
• 如果目标用户只是内部体验，直接减小并发数，没必要上大规模部署。

9. 常见问题与排查方法

这类工具上线后，问题往往集中在接口调用、模型输出质量和前端展示三层。

比较容易被忽略的是端口占用。本地起多个服务时，如果 8000 被占，换 8001 启动即可。但前端页面里的地址也要同步修改，否则会误以为后端挂了。FastAPI 自带/docs页面，是排查接口最好的入口，建议前端联调前先在/docs里手动提交一次请求。

10. 使用边界与合规提醒

心理测试类内容天然跟“人格标签”“自我认知”相关，做技术实现时不能只追求生成效果，还要注意使用边界。

第一，不要使用过度肯定的话术。模型输出中如果出现“你一定是个受欢迎的人”“你天生具有领导力”，虽然看起来很积极，但实际上相当于给用户贴了一个极其简化的标签。娱乐测试可以夸赞，但不能武断。更好的表达方式是：“在有些场景下，别人可能注意到你……”把结论限定在场景里，而不是全称判断。

第二，不能把这类测试结果用于心理诊断、招聘筛选、婚恋匹配等严肃场景。这类测试没有经过信度和效度检验，用途一旦扩展到关键决策，容易造成误导。

第三，涉及用户隐私。问卷可能采集用户的选项、昵称、设备信息。如果选项答案具有极强的个人倾向，在数据库中就属于敏感行为数据。建议不要设计“最近是否有抑郁情绪”“是否有过自伤想法”等敏感问题。即便要收集，也要明确告知用途并获得授权。本示例只展示社交场景下的轻松选择题，不涉及敏感维度。

第四，大模型生成内容可能存在事实性错误、偏见或价值观偏差。即使提示词约束得很严格，也不能保证每一条输出都稳妥。上线前宜准备一个关键词过滤列表，并定期抽检生成文案。若接入内容安全接口，可在模型返回后做二次过滤。

第五，如果有未成年人参与测试，更需要注意文案的引导性。娱乐测试不该给未成年人强加“吸引人特质”的成人化描述。产品页面最好加一行“本测试仅供娱乐，不构成任何专业建议”。

11. 总结与下一步

这个“心理测试：我最吸引人的特质是什么？我选 DC”的小项目，最值得尝试的点在于用非常轻量的方式验证了一条完整链路：前端交互 → 后端选项映射 → 大模型提示词生成 → 结果展示。你不一定需要复杂的推荐系统，也不一定需要本地部署超大参数模型，普通服务器加大模型 API 就能跑起来。

先实现 mock 模式接口，跑通页面和curl测试；再接入真实模型，根据输出调整提示词；最后加缓存和批量任务，观察接口成功率与成本。最容易踩的坑是提示词写得太宽，模型输出不可控；其次是并发量上来后没有做失败重试，导致批量任务断掉。

下一步可以继续扩展的方向有三个：一是把题目和选项做成后台配置，运营人员无需改代码就能换题；二是接向量数据库，让测试结果能关联到更细粒度的建议内容；三是加入用户反馈按钮，让用户对结果点“准”或“不准”，用真实的点击数据反过来调提示词模板。这套玩法不仅限于心理测试，换成“职业优势测试”“MBTI 风格轻测”“好友默契挑战”，技术结构都一样。最关键的是先跑通一个最小版本，看看真实用户对模型生成文案的反馈，再做优化。