可视化比例配置的问卷星全自动填答脚本：Python+Playwright+Flask实战

你有没有经历过这种时刻：一份四五十题的问卷，选项麻烦不说，还得按设定好的目标比例填出上百份样本——性别男35%女65%，年龄段再各占不同百分比。手动填的话，每份平均四五十秒，一百份就是两小时起步，而且你得全程保持清醒，否则统计起来比例早就偏到姥姥家了。

我之前帮朋友做课程问卷的答题逻辑测试就卡在这事上。后来写了个带可视化比例配置的问卷星全自动填答脚本，彻底把这件事变成了「拖一下滑块、点一下开始、喝口水回来数据已经按比例填好」。整套方案完全免费，只用 Python 加两个开源库就能跑。今天这篇文章，就把这个脚本的完整设计思路、核心算法、踩坑记录和使用边界一次性讲清楚，想自己搭一套的可以直接照着做，想了解原理的也能看懂每一步为什么这么设计。

1. 为什么需要"可视化比例配置"这类问卷辅助脚本

1.1 帮我填到崩溃的实测场景

把时间拨回我做这个脚本之前。当时的需求是这样的：问卷平台是问卷星，里面有一道性别题、一道年龄段题、几道态度量表题，我需要在这份问卷里生成 120 份测试数据，比例要求是男 35%、女 65%，年龄段则按 25% / 30% / 45% 分布。

听起来不复杂对吧？实际填起来完全是另一回事。问卷星的量表题一页有五个矩阵行，每行五个选项，光点完一道题就要 20 次点击。填到第 30 份的时候我已经开始数错选项，后面为了核对比例，每填 10 份还得手动拉一下已填问卷的数量统计。整个过程又累又容易出错，你花了大把时间，产出的却是一批比例可能不合格的数据，这才最让人崩溃。

所以我当时的核心诉求其实很朴素：能不能有一个工具，我只要定好「每道题每个选项占多少百分比」，它就能自动按比例把问卷填完，并且在填的过程中还能可视化调整这些比例，不用我改一行代码。这就是「可视化比例配置」这个需求的最初来源。

1.2 可视化比例配置解决了什么核心问题

市面上的自动填问卷脚本并不少，但大多数是写死脚本：某个选项点击固定次数，或者按固定顺序轮流点。这种方案应对「比例要求」时非常笨拙——你想让 A 选项占 40%、B 占 60%，脚本就得算出循环的步长，比例一变又要改代码重新跑。

可视化比例配置把这个过程变成了配置驱动。你在本地网页面板上拖滑块：

• 性别题：男 35%，女 65%
• 年龄段：25% / 30% / 45%

滑块一拖，脚本执行时就会根据这套配置去动态决定每一份问卷该选哪个选项。比例调整不再需要动代码，这对于「先跑 50 份看看分布，再把某档比例调高 10% 再跑」这种迭代场景特别友好。我后来统计结果，配置准确的情况下，实际生成的样本分布和目标比例误差能控制在 ±2% 以内。

1.3 它适合谁，不适合谁

先说实话，这个脚本不适合用来刷真实调研问卷。问卷平台有专门的异常检测机制，高频率重复提交的数据会被直接标记为无效，你拿到手里的是一堆「看似完美但完全没用」的垃圾数据。这个话题我在文章最后会展开，这里先额外提一句我把自己的脚本定位成测试与演练工具。

它真正适合的是这几类人：

• 问卷设计者，需要快速验证跳转逻辑、必填校验、量表信度是否合理；
• 做演示和教学的人，需要一批比例合适的示例数据来展示数据分析流程；
• 做表单性能测试的人，需要批量提交来观察平台响应和限流逻辑；
• 想学习 Python 自动化 + Web 控制的学生，这套代码本身就是一个结构清晰的小项目。

不适合的人也很明显：想靠它批量刷有奖问卷、伪造调研报告的人。原因很简单，平台的风控不是摆设，你刷出来的数据要么被废掉，要么给引用它的人带来完全错误的结论，最后坑的是你自己。

2. 技术选型：Python + Playwright + Flask搭建免费方案

2.1 为什么不用按键精灵，也不用油猴脚本

在决定方案之前，我先把市面上几种「自动化填问卷」的路线都过了一遍，实际上手验证过才确定最终技术栈。这个环节值得写出来，因为选型直接决定了后面会不会踩坑。

先说按键精灵。它本质上录的是屏幕坐标，问卷星这类页面的选项结构在不同分辨率、不同缩放下位置完全不一样，而且页面偶尔还有异步加载延迟，坐标点过去可能根本没点到选项。我试过一次在笔记本上录好的脚本，换到台式机就跑偏了，直接放弃。

油猴脚本（Tampermonkey）的思路好一些，它运行在页面内部，可以通过 DOM 操作点击选项，也不受跨域限制。但它的问题是「配置从哪来」。油猴脚本里想要可视化调整比例，要么做个页面内嵌面板，要么改脚本里的常量再刷新页面。对于一次性的小任务够用，但我要面对的是多道题、多选项、频繁调比例的复杂场景，油猴的配置体验还是太糙了，而且出错时不好调试。

2.2 Playwright 对比 Selenium：我选它的理由

说到浏览器自动化，Selenium 是老牌选手，但真正实际用过一遍后，我更推荐 Playwright，尤其是做问卷这类「需要花式等待页面元素」的任务。

首先是等待机制。问卷星的题目是异步加载的，翻页、提交都有延迟。Selenium 里我得写一堆WebDriverWait+expected_conditions，代码看着很啰嗦；Playwright 默认用locator.click()就会自动等待元素出现和可点击，省掉至少三成样板代码。

其次是浏览器管理。Selenium 需要自己下载对应版本的 ChromeDriver，Chrome 一更新驱动就崩；Playwright 一条命令就能安装浏览器并锁定版本，开发者电脑上基本不会再遇到「驱动不匹配」的恼人问题。

第三是调试体验。Playwright 执行时可以通过page.screenshot()随时截图，还可以录制执行录屏，出问题我能立刻看到脚本在哪一步翻了车。它对 iframe 的处理也干净，直接frame_locator().locator()就能钻进问卷嵌着的内层页面，这些都是问卷星这类复杂结构页面很需要的特性。

2.3 配置面板和执行模块的分工

整个项目我拆成了两个独立模块，各管一件事：

可视化配置面板：用 Flask 起一个本地 Web 服务，页面里用滑块和数字输入框展示每道题的选项比例，实时校验总和等于 100%。调好之后点「开始运行」，面板把配置打包成 JSON 发给执行模块。

问卷执行器：用 Playwright 控制浏览器，打开问卷地址，按配置逐题作答，做完随机延时后提交，如此循环配置好的次数。

为什么要拆开而不是塞在一个脚本里？因为配置是给人看的，执行是给机器跑的。你把两者混在一起，每次调整比例就得去翻执行代码，代码和配置的耦合会让维护成本几何级上升。拆开之后，面板可以单独启动，执行器也可以单独用手写 JSON 跑一遍，排查问题的时候非常清楚是配置的问题还是执行的问题。

这里有个重要的经验：执行模块要用子进程或者线程来跑，别直接在 Flask 的处理函数里跑填卷循环。我最早犯过这个错，点击「开始运行」后请求一直卡住，页面上的「停止」按钮完全不响应。后来改成把配置丢给后台线程，面板立刻就会返回「任务已启动」，再通过一个简单的日志文件或内存队列把执行进度回传显示，体验就正常了。

3. 核心算法：比例配置背后的动态分配逻辑

可视化比例配置看起来只是把数字传到后台，真正有价值的是后台怎么把「比例数字」翻译成「每一份问卷到底选哪个选项」。这部分我试过两种算法，各有适用场景，建议先理解再选。

3.1 预分配加洗牌：最简单也够用的方案

假设性别题目标比例是男 40%、女 60%，总份数是 50 份。最直白的做法是：

1. 生成一个选择列表：男出现 20 次，女出现 30 次；
2. 用随机洗牌把列表顺序打乱；
3. 每一份问卷按顺序弹出下一个选项。

这个方案的好处是极端简单，只要总份数确定，最终比例就是精确的 40/60。缺点是必须「跑满额定份数」。如果任务刚跑到一半，发现某选项比例偏差太大想提前停止，最终数据就会停在某个中途状态，不一定贴合目标比例。

适合场景：批量一次跑够，不打算中途停。如果你只是快速造一批固定数量的测试数据，这个方案足够。

3.2 动态贪心逼近：填到一半也能接近目标比例

为了解决「中途可能停止」的问题，我改用了动态贪心逼近方案。它的核心思想是每次填问卷之前，先统计当前已完成问卷里各选项已经出现了多少票，然后计算每个选项当前比例与目标比例的差距，优先补差距最大的那个选项。

拿男 40% / 女 60% 举例。已经完成了 10 份，其中男 3 份、女 7 份，当前比例是男 30%、女 70%。此时对比目标比例：

• 男的差距：30% - 40% = -10%，需要多选；
• 女的差距：70% - 60% = +10%，已经超了。

于是第 11 份自动选男。填完第 11 份后，男 4/11 ≈ 36.4%，差距变成约 -3.6%；女 7/11 ≈ 63.6%，差距约 +3.6%，两边又接近了，继续随机或继续补另一边。这个策略在任务量不是特别小的情况下，可以让任何中途时间点的实际比例都大体贴合目标，不会出现「只跑了三分之一、某一项完全偏到一边」的尴尬局面。

动态贪心的计算成本几乎为零，所以我的脚本最终用的就是它。代码里每填完一份，就更新一个计数字典，然后各题重新计算偏差，下一份按偏差排序来决定选项。

3.3 通用的题目配置结构

不管是哪种算法，后台都需要一份结构清晰的配置。我设计的 JSON 结构大概长这样：

{ "问卷地址": "https://www.wjx.cn/vm/xxxxx.aspx", "填答份数": 50, "题目": [ { "题干关键词": "性别", "选项比例": { "男": 40, "女": 60 } }, { "题干关键词": "年龄段", "选项比例": { "18-25岁": 25, "26-35岁": 30, "36-45岁": 45 } } ] }

你可能会问，「题干关键词」是干嘛的？这是为了在页面上定位题目。问卷星的题目结构并不提供稳定的 ID，我实测下来最可靠的方式就是按题干文本去匹配。填答时脚本遍历配置里的每道题，在当前页面找包含「题干关键词」的题目区块，再在该区块里点对应的选项文本。这种方式能兼容大部分单选题和多选题，字段命名也直白，面板上的滑块值直接映射到这个 JSON 里。

3.4 分配器核心代码

下面给出动态贪心分配器的精简实现，这部分是整个脚本的数学核心，值得单独把代码贴出来。为了便于理解，我略去了浏览器交互部分，只保留「选哪个选项」的决定逻辑：

import random from collections import defaultdict class RatioAllocator: def __init__(self, config): self.config = config # 记录每道题已选各选项的次数 self.counter = { idx: defaultdict(int) for idx in range(len(config["题目"])) } self.total = {idx: 0 for idx in range(len(config["题目"]))} def decide(self, question_idx): """ 根据当前各选项实际占比和目标占比， 返回本份问卷该选的选项文本。 """ question = self.config["题目"][question_idx] target = question["选项比例"] current_all = self.total[question_idx] best_option = None best_gap = float("inf") for option, target_ratio in target.items(): current_count = self.counter[question_idx].get(option, 0) # 当前实际比例 current_ratio = (current_count / current_all) if current_all else 0 # 目标比例是 0-100 的整数，统一换成 0-1 target_ratio_decimal = target_ratio / 100.0 gap = target_ratio_decimal - current_ratio # gap 越大说明欠得越多，优先补 if gap > best_gap: best_gap = gap best_option = option # 如果全是非正差（所有选项都已超标），随机选一个即可 if best_option is None: best_option = random.choice(list(target.keys())) # 更新计数 self.counter[question_idx][best_option] += 1 self.total[question_idx] += 1 return best_option

这段代码核心就是那几句求差额、取最大的逻辑。注意我在每一份问卷循环时，每道题都会调用一次decide，完成一次选择后立刻更新计数，下份问卷的选择就基于最新的历史数据，这就是「动态」二字的含义。

当你需要批量跑且精确控制最后结果时，可以把这段替换成预分配加洗牌；当你需要随时中止且希望已有数据比例不偏时，保留这个动态贪心即可。实测下来我在 120 份样本里提前到 100 份停止，最终性别比例是 36% / 64%，距离目标 35% / 65% 已经很接近了。

4. 从零跑通：环境准备与最小演示

4.1 环境准备：Python、Playwright、Flask

动手之前先把环境弄干净。我默认你已经装好了 Python 3.10 以上版本（Python 官网直接下就行），然后安装两个核心库：

pip install playwright flask python -m playwright install chromium

python -m playwright install chromium这一步容易漏，它会下载对应的 Chromium 浏览器内核，没有它脚本跑不起来。顺带说一句，Windows 用户如果在 PowerShell 里遇到playwright命令提示不被识别，通常是 Python 的 Scripts 目录没有加入 PATH，或者新开一个终端窗口让环境变量刷新一下，和 npm 那类「安装成功但命令找不到」的问题本质一样。

检查装没装好，跑一句：

python -c "from playwright.sync_api import sync_playwright; print('ok')"

能看到ok就说明导入正常。Flask 不需要单独验证，后面起服务时自然知道成果。

4.2 可视化面板：滑块配置界面

配置面板我用 Flask 起一个本地页面，端口默认 5000。界面的核心交互是滑块：每题一个滑块区，每个选项一行「名称 + 滑块 + 百分比数字」，滑块拖动时数字实时刷新，底部自动算总和，总和不是 100 时给红色提示，等于 100 时才能点「开始运行」。

可能是这种风格的页面：

from flask import Flask, request, jsonify, render_template_string app = Flask(__name__) INIT_CONFIG = { "问卷地址": "https://www.wjx.cn/vm/xxxxx.aspx", "填答份数": 50, "题目": [ { "题干关键词": "性别", "选项比例": {"男": 40, "女": 60} } ] } HTML = """ <!DOCTYPE html> <html> <head><meta charset="utf-8"><title>问卷辅助脚本控制面板</title></head> <body> <div id="app"> <h2>问卷辅助脚本控制面板</h2> <label>问卷地址</label> <input id="url" size="50" value=""> <label>填答份数</label> <input id="count" type="number" value="50"> <div id="questions"></div> <button id="run">开始运行</button> </div> <script> // 页面初始化时从后端读取配置并渲染滑块 // 每个滑块通过 input 事件更新对应百分比数字 // 点击「开始运行」后把当前配置 POST 到 /run 接口 </script> </body> </html> """ @app.route("/") def index(): return render_template_string(HTML) @app.route("/run", methods=["POST"]) def run(): config = request.get_json() # 实际项目中在这里把 config 传给后台线程执行 return jsonify({"status": "started", "config": config})

这只是最小可运行版，真实页面的滑块和校验逻辑会增加一些 JS，但核心思路就是：前端把滑块值写进一个 JSON，点开始后发给/run接口。

提到一个我踩过的坑：滑块数值不能直接允许 0~100 自由给，否则用户把三个选项拖成 40/40/30，总和不是 100，后台还会按错误比例跑。我在面板上做了「自动归一到 100」的逻辑——任意滑块变化后，把差值平均分摊到其他滑块上，保证总和恒为 100。虽然描述起来有点绕，但实际操作时体验非常顺滑。

4.3 执行模块：定位、延时、提交

执行模块我单独写成一个runner.py，它接收配置 JSON，用 Playwright 打开浏览器逐份填答。核心循环大致是：

import time import random from playwright.sync_api import sync_playwright def run_one_page(page, config, allocator, question_idx): question = config["题目"][question_idx] option_text = allocator.decide(question_idx) keyword = question["题干关键词"] question_block = page.locator(f"div:has-text('{keyword}')").first option_locator = question_block.locator(f"text='{option_text}'").first option_locator.click() page.wait_for_timeout(random.randint(200, 500)) def run_survey(config): with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() for i in range(config["填答份数"]): page.goto(config["问卷地址"]) for q_idx in range(len(config["题目"])): run_one_page(page, config, allocator, q_idx) # 随机延时 8-15 秒，模拟人手工填答的节奏 page.wait_for_timeout(random.randint(8000, 15000)) submit_btn = page.locator("#submit, button:has-text('提交')").first submit_btn.click() page.wait_for_timeout(random.randint(3000, 6000)) browser.close()

这里有两个细节想重点说明。

第一个是headless=False。我刻意让浏览器窗口显示出来，而不是用无头模式。原因是可调试性大于一切：脚本跑起来你能直观看到它每一步点到了哪里，出了问题也能马上发现。等你想批量跑一百份以上时，再改成无头模式不迟。

第二个是随机延时 8-15 秒。这不是营销话术，而是问卷平台判断「真人作答」的重要指标——如果一份 40 题的问卷 3 秒就提交，前端埋点会记录下这个异常时间。为了模拟真实节奏，我在每题之间也加了 200-500 毫秒随机停顿，整体耗时拉长到正常人能接受的范围。你甚至可以再放宽一点，延时 15-20 秒，代价只是总时长变长。

4.4 跑通后怎么验证比例

脚本跑完了，怎么知道比例到底准不准？我在驱动模块里加了一个统计回调，每完成一份就打印当前的累计选择情况：

[进度] 第 12/50 份 性别题：男 5 份 (41.7%)，女 7 份 (58.3%) 目标比例：男 40%，女 60%

最后一份跑完时会输出总统计表，和配置目标逐项对比。我自己验证时的做法更严格一点：把问卷星后台导出 CSV，拿 Python 的collections.Counter重新数一遍每道题的选择分布，确保脚本日志和平台导出结果一致。如果你用的是动态贪心方案，在跑完 50 份且随机种子正常的情况下，实际误差控制到 1-2 个百分点以内没有问题。

这里也想提醒各位：验证环节绝对不能省。脚本点击「成功」不代表问卷星记录成功，遇到过选项没点上、页面弹窗遮住了提交按钮等情况，最后平台侧根本没有任何提交记录，只有导出的统计能告诉你真相。

5. 在真实问卷里踩过的坑与排查思路

5.1 第一道坎：选项定位失败

第一次跑脚本，预期顺利，结果一上来就翻车：text='男'这个选择器死活点不到选项。

排查过程是这样的。我先用 Playwright 的page.content()把整页 HTML 拉下来看，发现问卷星的单选题结构和我预想完全不一样，不是标准的<label><input type="radio">男</label>，而是自定义组件：

<div class="ui-control-radio"> <span>男</span> </div>

纯文本text='男'按说应该能匹配到<span>，但我忽略了性别题旁边可能还有「年龄段」题目里也含文字。于是我把定位方式改得更收敛：先定位包含题干关键词的上级题目区块，再在区块内部查找选项文本。

question_block = page.locator(f"div:has-text('{keyword}')").first option_locator = question_block.locator(f"text='{option_text}'").first

改成这个写法之后，匹配精度大大提高，再也没有出现「点错题目」的情况。如果你想让定位更稳，也可以直接用 XPath 写//div[contains(text(), "男")]，原理一样。

5.2 第二道坎：页面藏在iframe里

另一个让我排查了一晚上的坑是 iframe。有份问卷是嵌入在某个第三方活动页里的，浏览器地址栏能看到问卷星的完整 URL，可 Playwright 用主页面选择器怎么都定位不到题目元素。

这其实就是经典的「iframe 场景」：问卷内容在一个内联框架里，主页面只是一个壳。Selenium 老手知道要先switch_to.frame，Playwright 的做法更直接：

frame = page.frame_locator("iframe") option_locator = frame.locator(f"text='{option_text}'").first

我后来总结：遇到定位不到元素时，第一件事先看元素的ownerDocument是不是主文档，用 Playwright 的探查功能一眼就能确认页面结构。确认是 iframe 后就用frame_locator去接管，不要在主文档里死磕。

5.3 第三道坎：智能验证与半自动兜底

问卷星现在会在提交环节插入智能验证，最常见的是「拖动滑块到最右边」或者「请点击图中包含某物的区域」。全自动脚本在这里是过不去的，必须想别的办法。

我先尝试过模拟拖拽滑块，Playwright 的mouse.down()+mouse.move()可以做出拖拽动作，但问卷星前端会收集鼠标轨迹、拖拽速度等多维信息，机械式的拖动经常被识别并无限弹出新验证。你越折腾，它越觉得你是机器人。

最终我把方案改成半自动兜底：

1. 脚本照常填完所有题目；
2. 提交前检测页面是否出现验证元素；
3. 如果出现，浏览器窗口保持打开，同时弹一个提示音；
4. 人工把滑块拖一下，脚本检测到验证消失后自动继续提交。

这个方案牺牲了一点「全自动」，但换来整个流程的稳定。我认为这是可以接受的妥协——问卷设置的边际防线就是为了挡住无差别自动化，顺势而为才是最优解。你可以试试把验证部分也接入人工验证码平台，但成本高、稳定性差，个人项目完全没必要。

5.4 第四道坎：隐蔽的必填项与提交按钮

有一次跑完 50 份，去后台一看只有 42 条记录。逐条排查后发现，问卷里有一道「请输入您的姓氏」的必填开放题，脚本没填，问卷星静默拦截了提交——不是报错，是点了提交之后没有真正提交。

这印证了一件事：跑正式问卷之前，必须先手动完整填一遍。操作是：用脚本打开问卷，手动答题提交一份，观察有没有脚本覆盖不到的必填项；如果有，把它们写进配置的「固定答案」字段里，脚本每次执行时额外填写这些字段，再走提交逻辑。

另外，提交按钮的选择器写死为#submit也很脆弱，不同模板的问卷按钮 ID 不一样，有的叫btn_submit，有的是<a>标签。我现在会写成一组候选选择器，挨个尝试，哪个有效用哪个：

submit_candidates = [ "#submit", "#btn_submit", "button:has-text('提交')", ".submit-btn", ]

这个配置化的处理方式极大地提高了脚本在不同问卷模板之间的复用率。

6. 合规边界与使用建议：自动化不是刷数据的借口

到了说点「不太好听但必须说」的部分。

6.1 我把它用在哪儿

这个脚本在我手里的定位一直很清晰：测试辅助工具。具体场景包括：

• 问卷设计完了，想快速验证多选题的跳转逻辑、必填校验是否生效；
• 讲师上课需要演示数据，按比例生成几十份高仿真的练习样本；
• 团队内部做数据分析培训，需要给学员一份「比例漂亮」的教学数据集；
• 表单性能验证，确认问卷在高并发提交下不会出现错乱。

以上这些场景里，填答者实际上是「模拟数据生成器」，不涉及欺骗真实用户，也不影响真实的调研结论，脚本的价值是正向的。

6.2 问卷星会怎么识别异常数据

如果你动了「用它刷真实调研问卷」的念头，先把下面这些机制看清楚。

问卷平台的风控大致分三层。第一层是提交频率检测：同 IP 短时间提交大量问卷，或者提交间隔过于规律，会被直接标记为嫌疑；第二层是作答时长与轨迹检测：一份需要 5 分钟答完的问卷，你 30 秒交卷，鼠标轨迹又是直线移动，大概率被丢进无效池；第三层是数据一致性校验：同一用户的选项分布长期高度吻合目标比例，在统计上本身就是异常信号。

换句话说，你可能最后拿到一份「比例超级完美」的答卷数据，但这份数据很可能已经被平台锁死为无效或低质量样本。用这样的数据做分析，结论本身就是错的，还不如不做。所以我的建议放在最后：脚本是双刃剑，用对地方是工具，用错地方是给自己挖坑。

6.3 几条实打实的建议

基于我自己的实践，最后给想动手做一套同类工具的朋友几条建议：

• 先定位为「本地测试工具」，不要一上来就搞分布式、多账号。个人项目优先保证稳定和可控，复杂化只会增加风控风险和维护成本；
• 配置驱动优先于代码写死。把问卷地址、选项比例、填答份数、固定答案全部放进 JSON，这样换一份问卷基本不用改代码；
• 日志要完整。每填一份记录好时间戳、选项选择、当前进度，出错时能快速定位是第几份、哪道题出了问题；
• 尽量半自动。遇到验证码时保留人工介入的入口，凡是让你头疼的自动化博弈，停下来找到协同方案往往比硬刚更省事。

最后再分享一个实际的体会：做这个项目最意外的收获不是脚本本身，而是它逼着我去理解一份问卷的完整生命周期——设计、校验逻辑、数据质量、平台规则。等你亲自把这一整套流程跑顺了，你会比任何人都清楚，真正的问卷调研有多依赖「真实」二字。把自动化放在它该在的位置上，它就是生产力；放错了位置，它就只是给自己添乱的玩具。