问卷星、腾讯问卷、考试系统都有自己的适用场景，而且这些平台都做得很成熟。普通调研、满意度收集、报名表、简单测评，用它们效率非常高。腾讯问卷有自定义逻辑 / DSL 相关能力，问卷星也支持常见的题目逻辑、API、量表和计分配置。真要只是发一份问卷、收一批答案、导出 Excel，我肯定不会自己造轮子。

我这里说的“问卷考试系统”，更类似是心理量表 + 考试流程 + 报告引擎 + 内部系统集成揉在一起的东西。它不是一个单纯的问卷，也不是一个单纯的考试。踩坑之后我发现，问题不在于现成平台有没有某个功能，而在于这些功能是不是能按我们的方式组合、审计、复用和长期维护。

现成问卷平台的边界

问卷星、腾讯问卷这类 SaaS 平台适合快速搭建和运营，优势很明显：

• 题型丰富，跳题、显示逻辑、配额、回收渠道都比较完善
• 常规计分、基础报告、数据导出基本够用
• 高级版/企业版通常还会提供 API、团队协作、品牌定制、更多逻辑能力
• 对非研发团队很友好，产品、运营、老师自己就能配置

但到心理量表和内部业务系统结合时，边界就开始出现了。

第一，算法可控性不够。 SCL-90 有 9 个因子分，CES-D 有正性情感题需要反向计分，MMPI 又有 L/F/K 等效度量表。平台可能支持“维度计分”或者“反向题”，但我们还会遇到更细的规则：题目版本修订、常模分层、测谎阈值、T 分/Z 分转换、异常答题判定、人工复核标记。只要规则需要被代码审计、被测试用例覆盖、被历史版本追溯，单靠页面配置就会吃力。

第二，报告不是简单的结果页。 心理测评的报告往往不是“你得了 78 分”这么简单。它要解释每个维度的含义，要有雷达图、柱状图、风险提示、建议话术，还要能输出 PDF、归档、推送到业务系统。模板一多，报告本身就变成了一个小型内容系统。

第三，数据合规和私有化要求绕不开。 有些答卷数据涉及个人状态、组织内部评估、学校或企业的敏感信息。即使平台本身安全可靠，业务上也可能要求数据留在自己的库里，权限走自己的组织架构，审计走自己的日志链路。

第四，长期成本和集成成本要算总账。 SaaS 平台按版本、账号、回收量、API 能力收费，短期省事，长期不一定便宜。更麻烦的是集成：用户体系、组织架构、权限、报告归档、消息通知、数据看板都要打通，越往后越类似在平台外面再套一层系统。

所以我末尾的判断是：现成平台并非不能用，重点是如果核心价值在“量表算法和报告自动化”上，自建会更可控。

考试系统模型哪里不贴合

考试系统当然也能改。它的流程很完整：题库、试卷、答题、交卷、评分、成绩统计，和我们要做的东西确实很类似。

问题在于考试系统默认有一套很强的假设：答案有对错，题目有标准答案，分数代表掌握程度。心理测评不是这个模型。“近段时间一周你感到情绪低落的频率”这种题，选“没有”和选“经常”只是反映状态，不存在谁更正确。反向题也并非为了“迷惑考生”，重点是为了修正量表方向和控制作答质量。

再比如考试系统常见的防作弊逻辑是切屏检测、人脸识别、随机抽题；心理量表更关心直线作答、过快作答、矛盾回答、测谎题异常。看起来都是“质量控制”，实际关注点完全不同。

什么时候值得自建

我的经验是，不要一上来就自建。先用这个清单判断：

如果只是普通问卷，用成熟平台更省心；如果要做成企业内部长期运行的测评能力，那就需要一套更工程化的系统。

上一篇聊了整体架构和数据模型，这篇讲整个系统核心的部分：怎么用一套统一的 JSON 结构，把单选、多选、量表、矩阵、排序、填空……所有题型都描述清楚。然后让引擎把这些 JSON 跑起来，条件跳题、题目分组、随机排序，这些才是让问卷从"能编辑"变成"能填写"的关键。

为什么用 JSON 而不是多张表

传统建模的麻烦

直观的做法，每种题型一张表：

CREATE TABLE question_single_choice (
    id BIGINT PRIMARY KEY, stem TEXT,
    option_a TEXT, option_b TEXT, option_c TEXT, option_d TEXT,
    correct_answer VARCHAR(10)
);
CREATE TABLE question_likert (
    id BIGINT PRIMARY KEY, stem TEXT,
    scale_type VARCHAR(20), is_reverse BOOLEAN
);
-- 10 种题型 10 张表……

问题很明显：

评分引擎是整个系统里容易出错、也需要优先可审计的部分。心理量表和普通考试上限的差异也在这里：不能只把考试系统那套 sum() 逻辑搬过来，很多规则要单独设计。

心理量表评分 vs 普通考试

两者的差异很大。

普通考试的计分模型很直白:答对得 1 分,答错得 0 分,加起来就是总分。题目按章节组织,分数按章节汇总,出个柱状图就完事了。

到心理量表这里，逻辑就不一样了。题目常用 Likert 等级量表–“从不”到“总是”、“非常不同意”到“非常同意”，每个选项对应一个分值，没有对错之分，只有程度差异。量表按心理学维度组织，比如焦虑、抑郁、躯体化，每道题在设计阶段就归属到某个维度了。

更关键的差异:

• 反向计分题:防止被试不动脑子全选同一个选项。正常题"我觉得工作很有成就感"选"总是"得 5 分,反向题"我觉得工作毫无意义"选"总是"得 1 分。考试没有这种概念。
• 测谎题:检测被试是否在刻意美化自己。考试也不需要这个。
• 维度分析:心理量表的核心价值是维度分–焦虑多少分、抑郁多少分、躯体化多少分,分别对应什么严重程度。光给一个总分没有意义。
• 常模参照:原始分需要转换成标准分(T 分/Z 分),然后和常模比较才能得出有意义的结论。这是心理量表和考试上限的区别,后面会详细讲。

维度模型设计

维度和题目不要做成简单多对多，还要记录反向题、测谎题和父子维度聚合规则：

维度与题目的关联

每个量表由若干维度组成,每道题归属于一个维度。维度之间可以有层级关系–比如职业兴趣测评里先有"人际/事务/研究"这类一级维度,下面再拆更细的子维度。类似 SCL-90 这种经典量表则是相对扁平的 9 个因子,不要硬套层级。

问卷收上来一堆答案，怎么判断哪些是认真填的、哪些是随便糊弄的？另外，在出卷阶段，怎么保证组出来的试卷在分数分布上是合理的？这两个问题分别对应答题后质量检测和出卷时约束验证。

三道防线：测谎题检测被试是否在刻意美化，Z3 约束求解器在组卷阶段验证分数区间无冲突，异常模式检测抓全选、极端值、过快作答等刷卷行为。

质量控制分成卷前验证和卷后检测，两条链路末尾汇总成答卷可信度：

第一道防线：测谎题，检测"装好人"

设计原理

测谎题的逻辑很简单：大多数人不太可能在所有测谎题上都选“完美”的那一端。

MMPI 的 L（Lie）效度量表是经典案例。它会放一些社会称许性很强、但现实中很难完全做到的题目，例如：

• “我从来没有说过谎”，大多数人都说过谎，全选“是”反而可疑
• “我从不背后说人坏话”，太完美了，不真实
• “我从来不会迟到”，现实里很难完全做到

这些题目不计入心理维度的分数，唯一的用途就是检测被试的作答态度。

评分逻辑

每道测谎题都有一个或多个"可疑答案"。被试选中了可疑答案，就记 1 分；否则记 0 分。末尾把所有测谎题的可疑分加起来，和阈值做比较。

阈值不要写死，更稳妥按量表手册和人群配置。下面只是工程示例：

• VALID（有效）：可疑比例 ≤ 50%
• SUSPICIOUS（可疑）：50% < 可疑比例 ≤ 80%
• INVALID（无效）：可疑比例 > 80%

实现

public LieScaleResult calculate(List<Question> lieScaleQuestions,
                                 Map<String, Answer> answers) {
    int totalLieScore = 0;
    for (Question q : lieScaleQuestions) {
        Answer answer = answers.get(q.getId());
        if (answer == null) continue;

        int value = answer.getSelectedValue();
        if (q.getLieAnswerValues().contains(value)) {
            totalLieScore++;
        }
    }

    double lieRatio = (double) totalLieScore / lieScaleQuestions.size();
    String verdict;
    if (lieRatio > 0.8) verdict = "INVALID";
    else if (lieRatio > 0.5) verdict = "SUSPICIOUS";
    else verdict = "VALID";

    return new LieScaleResult(totalLieScore, lieScaleQuestions.size(),
                               lieRatio, verdict);
}

注意：测谎题的可疑答案不一定总是更高分。有些题是"选低分才可疑"，有些还可能有多个可疑选项。稳妥做法是在题目配置里显式声明 lieAnswerValues。

]]>https://oldletter.cn/posts/qnr-05-frontend/Mon, 20 Apr 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/qnr-05-frontend/上一篇：问卷考试系统设计（四）：质量控制

后端写好了，接口也通了。前端要解决四个问题：怎么把后端返回的 JSON 渲染成可交互的答题界面、状态怎么管、考试场景怎么防作弊、手机上表格挤成一团怎么办。

前端答题状态要围绕一份本地快照流转，草稿和提交使用同一套校验结果：

stateDiagram-v2 [*] --> LoadingDsl LoadingDsl --> InitStore: 加载问卷 DSL InitStore --> Answering: 初始化 Pinia Answering --> RecomputeLogic: 选项变化 RecomputeLogic --> Answering: 更新跳题结果 Answering --> SavingDraft: 定时或失焦 SavingDraft --> Answering: 保存成功 Answering --> SubmitCheck: 点击提交 SubmitCheck --> Answering: 校验失败 SubmitCheck --> SubmitAnswer: 校验通过 SubmitAnswer --> SubmitSecurity: 附带质量与防作弊数据 SubmitSecurity --> Done Done --> [*]

---

一、注册表模式：一套 DSL 驱动所有题型渲染

硬编码的坑

直观的写法是 if-else：

<SingleChoice v-if="q.type === 'single_choice'" :question="q" />
<MultipleChoice v-else-if="q.type === 'multiple_choice'" :question="q" />
<LikertScale v-else-if="q.type === 'likert'" :question="q" />

每加一种题型，渲染层、校验层、状态层都得改。后面会越来越难维护。

]]>https://oldletter.cn/posts/qnr-06-report-ai/Sat, 25 Apr 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/qnr-06-report-ai/上一篇：问卷考试系统设计（五）：前端引擎

数据收集、评分计算都做完了，业务方更关心的是末尾一步：拿到一份类似样的报告。报告生成的完整链路：模板定结构、规则填数据、AI 写解读、图表画可视化、末尾拼成 PDF。

报告生成适合异步化，前端只订阅任务进度，不直接等待 PDF 渲染完成：

sequenceDiagram participant API as 报告 API participant Queue as 异步任务 participant Rule as 规则解读 participant AI as AI 文案 participant Chart as 图表渲染 participant PDF as PDF 导出 participant SSE as SSE 进度 API->>Queue: 提交评分结果 Queue->>SSE: 10% 已接收 Queue->>Rule: 生成规则解读 Queue->>AI: 生成辅助文案 Queue->>Chart: 渲染图表 PNG Queue->>PDF: 拼 HTML 并导出 PDF Queue->>SSE: 100% 报告可下载

---

报告生成的几种模式

模板填充适合格式固定的报告，模板写好，变量一填就完事。

规则引擎解决条件判断问题。焦虑得分 0-4 分是"无焦虑"，5-9 分是"轻度焦虑"，这种区间映射用硬编码也能写，但规则多了维护起来是噩梦。

AI 生成处理自然语言解读。数字摆在那里，但用户要的是一段"读得懂"的文字。

实际项目中三者结合：模板定骨架，规则引擎填确定性结论，AI 只负责把结论写得更类似人话。先保证可复现，再谈润色。

]]>https://oldletter.cn/posts/qnr-07-statistics/Fri, 01 May 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/qnr-07-statistics/上一篇：问卷考试系统设计（六）：报告生成

数据采集只是起点。问卷系统真正产生价值的时刻，是数据沉淀之后，研究者打开统计面板，看到分组差异、趋势变化和数据质量。这篇聚焦数据统计分析、多格式导出、隐私脱敏、大屏可视化，以及常模的建立过程。

统计分析要区分离线口径和实时看板，避免把探索性分析塞进在线请求：

flowchart LR A["答卷清洗"] --> B["维度分汇总"] B --> C["描述统计"] C --> D["显著性检验"] D --> E["常模构建"] E --> F["离线导出"] B --> G["实时指标聚合"] G --> H["WebSocket 推送"] H --> I["大屏看板"] E --> J["常模版本"] J --> K["评分引擎读取"]

---

一、描述性统计

拿到一批量表分数，第一件事是看整体面貌：

public DescriptiveStats descriptive(List<Double> scores) {
    DoubleSummaryStatistics stats = scores.stream()
        .mapToDouble(Double::doubleValue)
        .summaryStatistics();

    double mean = stats.getAverage();
    double std = Math.sqrt(
        scores.stream()
            .mapToDouble(v -> Math.pow(v - mean, 2))
            .average().orElse(0.0)
    );
    List<Double> sorted = scores.stream().sorted().collect(Collectors.toList());
    double median = sorted.size() % 2 == 0
        ? (sorted.get(sorted.size() / 2 - 1) + sorted.get(sorted.size() / 2)) / 2.0
        : sorted.get(sorted.size() / 2);

    return new DescriptiveStats(mean, std, median, stats.getMin(), stats.getMax(),
        stats.getCount());
}

均值、标准差、中位数、极值，这几个数字能快速告诉研究者数据有没有异常、分布偏不偏。对于问卷系统这个体量的数据（通常几万条以内），纯 Java Stream 基本够用。

]]>