你有没有经历过这种时刻一份四五十题的问卷选项麻烦不说还得按设定好的目标比例填出上百份样本——性别男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 为什么不用按键精灵也不用油猴脚本在决定方案之前我先把市面上几种「自动化填问卷」的路线都过了一遍实际上手验证过才确定最终技术栈。这个环节值得写出来因为选型直接决定了后面会不会踩坑。方案优点核心问题我的结论按键精灵等鼠标模拟器上手快像录宏一样坐标写死页面一有偏移就全崩问卷星选项位置不一定固定放弃浏览器油猴脚本轻量随开随用需要手写 DOM 选择器跨域逻辑绕比例配置还是得走代码部分场景可用但不够通用Python Selenium生态成熟资料多需要自己管理浏览器驱动等待策略不够智能经常要写一堆显式等待可以用来兜底Python Playwright自动等待、API 友好、自带浏览器管理相对新一些但会用了之后真的很顺手最终选择先说按键精灵。它本质上录的是屏幕坐标问卷星这类页面的选项结构在不同分辨率、不同缩放下位置完全不一样而且页面偶尔还有异步加载延迟坐标点过去可能根本没点到选项。我试过一次在笔记本上录好的脚本换到台式机就跑偏了直接放弃。油猴脚本Tampermonkey的思路好一些它运行在页面内部可以通过 DOM 操作点击选项也不受跨域限制。但它的问题是「配置从哪来」。油猴脚本里想要可视化调整比例要么做个页面内嵌面板要么改脚本里的常量再刷新页面。对于一次性的小任务够用但我要面对的是多道题、多选项、频繁调比例的复杂场景油猴的配置体验还是太糙了而且出错时不好调试。2.2 Playwright 对比 Selenium我选它的理由说到浏览器自动化Selenium 是老牌选手但真正实际用过一遍后我更推荐 Playwright尤其是做问卷这类「需要花式等待页面元素」的任务。首先是等待机制。问卷星的题目是异步加载的翻页、提交都有延迟。Selenium 里我得写一堆WebDriverWaitexpected_conditions代码看着很啰嗦Playwright 默认用locator.click()就会自动等待元素出现和可点击省掉至少三成样板代码。其次是浏览器管理。Selenium 需要自己下载对应版本的 ChromeDriverChrome 一更新驱动就崩Playwright 一条命令就能安装浏览器并锁定版本开发者电脑上基本不会再遇到「驱动不匹配」的恼人问题。第三是调试体验。Playwright 执行时可以通过page.screenshot()随时截图还可以录制执行录屏出问题我能立刻看到脚本在哪一步翻了车。它对 iframe 的处理也干净直接frame_locator().locator()就能钻进问卷嵌着的内层页面这些都是问卷星这类复杂结构页面很需要的特性。2.3 配置面板和执行模块的分工整个项目我拆成了两个独立模块各管一件事可视化配置面板用 Flask 起一个本地 Web 服务页面里用滑块和数字输入框展示每道题的选项比例实时校验总和等于 100%。调好之后点「开始运行」面板把配置打包成 JSON 发给执行模块。问卷执行器用 Playwright 控制浏览器打开问卷地址按配置逐题作答做完随机延时后提交如此循环配置好的次数。为什么要拆开而不是塞在一个脚本里因为配置是给人看的执行是给机器跑的。你把两者混在一起每次调整比例就得去翻执行代码代码和配置的耦合会让维护成本几何级上升。拆开之后面板可以单独启动执行器也可以单独用手写 JSON 跑一遍排查问题的时候非常清楚是配置的问题还是执行的问题。这里有个重要的经验执行模块要用子进程或者线程来跑别直接在 Flask 的处理函数里跑填卷循环。我最早犯过这个错点击「开始运行」后请求一直卡住页面上的「停止」按钮完全不响应。后来改成把配置丢给后台线程面板立刻就会返回「任务已启动」再通过一个简单的日志文件或内存队列把执行进度回传显示体验就正常了。3. 核心算法比例配置背后的动态分配逻辑可视化比例配置看起来只是把数字传到后台真正有价值的是后台怎么把「比例数字」翻译成「每一份问卷到底选哪个选项」。这部分我试过两种算法各有适用场景建议先理解再选。3.1 预分配加洗牌最简单也够用的方案假设性别题目标比例是男 40%、女 60%总份数是 50 份。最直白的做法是生成一个选择列表男出现 20 次女出现 30 次用随机洗牌把列表顺序打乱每一份问卷按顺序弹出下一个选项。这个方案的好处是极端简单只要总份数确定最终比例就是精确的 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 chromiumpython -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 headmeta charsetutf-8title问卷辅助脚本控制面板/title/head body div idapp h2问卷辅助脚本控制面板/h2 label问卷地址/label input idurl size50 value label填答份数/label input idcount typenumber value50 div idquestions/div button idrun开始运行/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(fdiv:has-text({keyword})).first option_locator question_block.locator(ftext{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(headlessFalse) 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()这里有两个细节想重点说明。第一个是headlessFalse。我刻意让浏览器窗口显示出来而不是用无头模式。原因是可调试性大于一切脚本跑起来你能直观看到它每一步点到了哪里出了问题也能马上发现。等你想批量跑一百份以上时再改成无头模式不迟。第二个是随机延时 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 拉下来看发现问卷星的单选题结构和我预想完全不一样不是标准的labelinput typeradio男/label而是自定义组件div classui-control-radio span男/span /div纯文本text男按说应该能匹配到span但我忽略了性别题旁边可能还有「年龄段」题目里也含文字。于是我把定位方式改得更收敛先定位包含题干关键词的上级题目区块再在区块内部查找选项文本。question_block page.locator(fdiv:has-text({keyword})).first option_locator question_block.locator(ftext{option_text}).first改成这个写法之后匹配精度大大提高再也没有出现「点错题目」的情况。如果你想让定位更稳也可以直接用 XPath 写//div[contains(text(), 男)]原理一样。5.2 第二道坎页面藏在iframe里另一个让我排查了一晚上的坑是 iframe。有份问卷是嵌入在某个第三方活动页里的浏览器地址栏能看到问卷星的完整 URL可 Playwright 用主页面选择器怎么都定位不到题目元素。这其实就是经典的「iframe 场景」问卷内容在一个内联框架里主页面只是一个壳。Selenium 老手知道要先switch_to.framePlaywright 的做法更直接frame page.frame_locator(iframe) option_locator frame.locator(ftext{option_text}).first我后来总结遇到定位不到元素时第一件事先看元素的ownerDocument是不是主文档用 Playwright 的探查功能一眼就能确认页面结构。确认是 iframe 后就用frame_locator去接管不要在主文档里死磕。5.3 第三道坎智能验证与半自动兜底问卷星现在会在提交环节插入智能验证最常见的是「拖动滑块到最右边」或者「请点击图中包含某物的区域」。全自动脚本在这里是过不去的必须想别的办法。我先尝试过模拟拖拽滑块Playwright 的mouse.down()mouse.move()可以做出拖拽动作但问卷星前端会收集鼠标轨迹、拖拽速度等多维信息机械式的拖动经常被识别并无限弹出新验证。你越折腾它越觉得你是机器人。最终我把方案改成半自动兜底脚本照常填完所有题目提交前检测页面是否出现验证元素如果出现浏览器窗口保持打开同时弹一个提示音人工把滑块拖一下脚本检测到验证消失后自动继续提交。这个方案牺牲了一点「全自动」但换来整个流程的稳定。我认为这是可以接受的妥协——问卷设置的边际防线就是为了挡住无差别自动化顺势而为才是最优解。你可以试试把验证部分也接入人工验证码平台但成本高、稳定性差个人项目完全没必要。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这样换一份问卷基本不用改代码日志要完整。每填一份记录好时间戳、选项选择、当前进度出错时能快速定位是第几份、哪道题出了问题尽量半自动。遇到验证码时保留人工介入的入口凡是让你头疼的自动化博弈停下来找到协同方案往往比硬刚更省事。最后再分享一个实际的体会做这个项目最意外的收获不是脚本本身而是它逼着我去理解一份问卷的完整生命周期——设计、校验逻辑、数据质量、平台规则。等你亲自把这一整套流程跑顺了你会比任何人都清楚真正的问卷调研有多依赖「真实」二字。把自动化放在它该在的位置上它就是生产力放错了位置它就只是给自己添乱的玩具。
你有没有经历过这种时刻一份四五十题的问卷选项麻烦不说还得按设定好的目标比例填出上百份样本——性别男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 为什么不用按键精灵也不用油猴脚本在决定方案之前我先把市面上几种「自动化填问卷」的路线都过了一遍实际上手验证过才确定最终技术栈。这个环节值得写出来因为选型直接决定了后面会不会踩坑。方案优点核心问题我的结论按键精灵等鼠标模拟器上手快像录宏一样坐标写死页面一有偏移就全崩问卷星选项位置不一定固定放弃浏览器油猴脚本轻量随开随用需要手写 DOM 选择器跨域逻辑绕比例配置还是得走代码部分场景可用但不够通用Python Selenium生态成熟资料多需要自己管理浏览器驱动等待策略不够智能经常要写一堆显式等待可以用来兜底Python Playwright自动等待、API 友好、自带浏览器管理相对新一些但会用了之后真的很顺手最终选择先说按键精灵。它本质上录的是屏幕坐标问卷星这类页面的选项结构在不同分辨率、不同缩放下位置完全不一样而且页面偶尔还有异步加载延迟坐标点过去可能根本没点到选项。我试过一次在笔记本上录好的脚本换到台式机就跑偏了直接放弃。油猴脚本Tampermonkey的思路好一些它运行在页面内部可以通过 DOM 操作点击选项也不受跨域限制。但它的问题是「配置从哪来」。油猴脚本里想要可视化调整比例要么做个页面内嵌面板要么改脚本里的常量再刷新页面。对于一次性的小任务够用但我要面对的是多道题、多选项、频繁调比例的复杂场景油猴的配置体验还是太糙了而且出错时不好调试。2.2 Playwright 对比 Selenium我选它的理由说到浏览器自动化Selenium 是老牌选手但真正实际用过一遍后我更推荐 Playwright尤其是做问卷这类「需要花式等待页面元素」的任务。首先是等待机制。问卷星的题目是异步加载的翻页、提交都有延迟。Selenium 里我得写一堆WebDriverWaitexpected_conditions代码看着很啰嗦Playwright 默认用locator.click()就会自动等待元素出现和可点击省掉至少三成样板代码。其次是浏览器管理。Selenium 需要自己下载对应版本的 ChromeDriverChrome 一更新驱动就崩Playwright 一条命令就能安装浏览器并锁定版本开发者电脑上基本不会再遇到「驱动不匹配」的恼人问题。第三是调试体验。Playwright 执行时可以通过page.screenshot()随时截图还可以录制执行录屏出问题我能立刻看到脚本在哪一步翻了车。它对 iframe 的处理也干净直接frame_locator().locator()就能钻进问卷嵌着的内层页面这些都是问卷星这类复杂结构页面很需要的特性。2.3 配置面板和执行模块的分工整个项目我拆成了两个独立模块各管一件事可视化配置面板用 Flask 起一个本地 Web 服务页面里用滑块和数字输入框展示每道题的选项比例实时校验总和等于 100%。调好之后点「开始运行」面板把配置打包成 JSON 发给执行模块。问卷执行器用 Playwright 控制浏览器打开问卷地址按配置逐题作答做完随机延时后提交如此循环配置好的次数。为什么要拆开而不是塞在一个脚本里因为配置是给人看的执行是给机器跑的。你把两者混在一起每次调整比例就得去翻执行代码代码和配置的耦合会让维护成本几何级上升。拆开之后面板可以单独启动执行器也可以单独用手写 JSON 跑一遍排查问题的时候非常清楚是配置的问题还是执行的问题。这里有个重要的经验执行模块要用子进程或者线程来跑别直接在 Flask 的处理函数里跑填卷循环。我最早犯过这个错点击「开始运行」后请求一直卡住页面上的「停止」按钮完全不响应。后来改成把配置丢给后台线程面板立刻就会返回「任务已启动」再通过一个简单的日志文件或内存队列把执行进度回传显示体验就正常了。3. 核心算法比例配置背后的动态分配逻辑可视化比例配置看起来只是把数字传到后台真正有价值的是后台怎么把「比例数字」翻译成「每一份问卷到底选哪个选项」。这部分我试过两种算法各有适用场景建议先理解再选。3.1 预分配加洗牌最简单也够用的方案假设性别题目标比例是男 40%、女 60%总份数是 50 份。最直白的做法是生成一个选择列表男出现 20 次女出现 30 次用随机洗牌把列表顺序打乱每一份问卷按顺序弹出下一个选项。这个方案的好处是极端简单只要总份数确定最终比例就是精确的 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 chromiumpython -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 headmeta charsetutf-8title问卷辅助脚本控制面板/title/head body div idapp h2问卷辅助脚本控制面板/h2 label问卷地址/label input idurl size50 value label填答份数/label input idcount typenumber value50 div idquestions/div button idrun开始运行/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(fdiv:has-text({keyword})).first option_locator question_block.locator(ftext{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(headlessFalse) 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()这里有两个细节想重点说明。第一个是headlessFalse。我刻意让浏览器窗口显示出来而不是用无头模式。原因是可调试性大于一切脚本跑起来你能直观看到它每一步点到了哪里出了问题也能马上发现。等你想批量跑一百份以上时再改成无头模式不迟。第二个是随机延时 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 拉下来看发现问卷星的单选题结构和我预想完全不一样不是标准的labelinput typeradio男/label而是自定义组件div classui-control-radio span男/span /div纯文本text男按说应该能匹配到span但我忽略了性别题旁边可能还有「年龄段」题目里也含文字。于是我把定位方式改得更收敛先定位包含题干关键词的上级题目区块再在区块内部查找选项文本。question_block page.locator(fdiv:has-text({keyword})).first option_locator question_block.locator(ftext{option_text}).first改成这个写法之后匹配精度大大提高再也没有出现「点错题目」的情况。如果你想让定位更稳也可以直接用 XPath 写//div[contains(text(), 男)]原理一样。5.2 第二道坎页面藏在iframe里另一个让我排查了一晚上的坑是 iframe。有份问卷是嵌入在某个第三方活动页里的浏览器地址栏能看到问卷星的完整 URL可 Playwright 用主页面选择器怎么都定位不到题目元素。这其实就是经典的「iframe 场景」问卷内容在一个内联框架里主页面只是一个壳。Selenium 老手知道要先switch_to.framePlaywright 的做法更直接frame page.frame_locator(iframe) option_locator frame.locator(ftext{option_text}).first我后来总结遇到定位不到元素时第一件事先看元素的ownerDocument是不是主文档用 Playwright 的探查功能一眼就能确认页面结构。确认是 iframe 后就用frame_locator去接管不要在主文档里死磕。5.3 第三道坎智能验证与半自动兜底问卷星现在会在提交环节插入智能验证最常见的是「拖动滑块到最右边」或者「请点击图中包含某物的区域」。全自动脚本在这里是过不去的必须想别的办法。我先尝试过模拟拖拽滑块Playwright 的mouse.down()mouse.move()可以做出拖拽动作但问卷星前端会收集鼠标轨迹、拖拽速度等多维信息机械式的拖动经常被识别并无限弹出新验证。你越折腾它越觉得你是机器人。最终我把方案改成半自动兜底脚本照常填完所有题目提交前检测页面是否出现验证元素如果出现浏览器窗口保持打开同时弹一个提示音人工把滑块拖一下脚本检测到验证消失后自动继续提交。这个方案牺牲了一点「全自动」但换来整个流程的稳定。我认为这是可以接受的妥协——问卷设置的边际防线就是为了挡住无差别自动化顺势而为才是最优解。你可以试试把验证部分也接入人工验证码平台但成本高、稳定性差个人项目完全没必要。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这样换一份问卷基本不用改代码日志要完整。每填一份记录好时间戳、选项选择、当前进度出错时能快速定位是第几份、哪道题出了问题尽量半自动。遇到验证码时保留人工介入的入口凡是让你头疼的自动化博弈停下来找到协同方案往往比硬刚更省事。最后再分享一个实际的体会做这个项目最意外的收获不是脚本本身而是它逼着我去理解一份问卷的完整生命周期——设计、校验逻辑、数据质量、平台规则。等你亲自把这一整套流程跑顺了你会比任何人都清楚真正的问卷调研有多依赖「真实」二字。把自动化放在它该在的位置上它就是生产力放错了位置它就只是给自己添乱的玩具。
