论预设内容如何打断操作流#

1.1 一条顺畅的流#

先描述一条没有问题的流。

用户打开一个网页或一个应用，输入一段数据——比如一段搜索词、一个收件地址、一条快递单号、一份要粘贴的文本。系统把这份输入解析成一个待确认的视图：这里是要发往的地址，那里是订单摘要，右侧是合计金额。用户扫一遍，点下”提交”。三个步骤：输入、确认、输出。

这条流的成立有一个隐含前提：在这三个步骤之间，用户的注意力是单向的、连续的。他不需要重新读一遍自己刚才写了什么，也不需要为了说一件事而先撤销另一件他不想要的事。

1.2 断点出现在输入环节#

问题出在第一步。输入框不是空的。

在真实世界里，这个”不是空的”有几种不同的来历：系统上一次留下的历史记录；上一次使用的账号或地址；产品经理认为”多数人都想要”的默认值；浏览器密码管理器或自动填充塞进来的内容；还有一种情况，界面上用灰色文字提示了格式示例，但这段灰字在实现上是一个真实的初始值，用户一开始就要把它删掉。

无论来历是哪一种，只要这段内容对这位用户、这次意图是不成立的，操作流就在这里断开：用户的目标是”填 A”，而屏幕上呈现的是”已有 B，请先删掉 B”。系统把他放到了一个他本来不必去的地方。

1.3 为什么值得把它单列出来#

一个自然的反应是：这不就是”表单默认值没设好”嘛，归到表单设计的常见问题里就行了。

但把三件事并排放在一起看，会发现这个现象有自己的形状：

第一，它不是一个错误，而是一次成功的预填。系统确实预填了某些东西，代码没有 bug，测试用例通过了。问题只出现在”这次用户恰好不需要它”的那部分会话里，因此很容易在内部测试中消失——测试者就是那个恰好需要它的人。

第二，它的代价不在于难，而在于多余。一次删除动作不涉及任何认知困难，不涉及任何错误恢复。它只是让本来三步的流变成四步。而多出来的这一步落在最敏感的位置上：它是用户到达”确认”这一步之前的最后一道阻力。

第三，它的成本会随场景被放大。如果这个输入框出现十次，如果每次都预填了上次的内容，如果用户是在手机上、在公共场合、在只有单手能用鼠标的情况下操作，那么这个”多余的一步”就会从一个不便变成一道门槛。

Nielsen Norman Group 的 Katie Sherwin 在那篇讨论占位符的文章里，把这件事描述得非常直接：如果占位符文字以可编辑文本的形式留在字段里，“users are forced to manually select and delete it. This creates an unnecessary burden on users and increases the interaction cost of filling in the form.”——不必要的负担，以及填表交互成本的上升。注意她用的是 “unnecessary” 这个词：代价的核心不是难度，是多余。

2.1 占位提示（placeholder）#

灰色的一段提示文字，告诉用户这个字段应该填什么、是什么格式，比如”请输入 11 位手机号""搜索”。

它在语义上是提示，不是内容。用户不该认为它是数据，也不该把它当作真实值提交。它在 HTML 里的正式名字是 placeholder，WHATWG HTML Living Standard 对它的定义是：

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value.

关键短语是 “when the control has no value”——它只在字段为空时出现，一旦用户开始输入就消失。规范紧接着给了一条规范性要求：

The placeholder attribute should not be used as an alternative to a label.

这正是很多问题的源头：当 placeholder 被实现成”字段的初始值”而不是”字段为空时的提示”时，它就变成了一个用户必须先删掉的默认文本。Sherwin 观察到的”用户把占位符误认成系统自动填入的值”，正是这个 bug 的用户侧投影。

2.2 默认值（default value）#

字段里真实存在的初始内容，可以被提交、被确认、被当作这次操作的一部分。它的正当性完全取决于一件事：这份默认值对用户本次的意图是否成立。

搜索框里预填上你上次的搜索词，对”想重新搜同样的东西”的人成立，对”想搜点别的”的人不成立。收货地址里预填上默认地址，对”寄回家”的人可能成立，对”寄到公司”的人不成立。这两者都是合理的默认值设计，差别只在于命中率。

2.3 自动填充（autofill）#

由浏览器或密码管理器提供的、来自用户自己历史记录的内容。它和默认值的根本区别在于来源：默认值来自产品的猜测，autofill 来自用户自己的输入过的东西。

Chrome 团队在 2024 年 12 月公开的一组数据说明了这件事的分量。他们聚合了”users who consented to share that information”的表单数据，覆盖美国 Chrome 中数千个最常访问网站的地址与信用卡表单，结论是：使用自动填充的用户，表单放弃率显著更低、填表耗时显著更短——原文的两句分别是”users abandon forms 75% less frequently when they use autofill”与”time spent filling forms is approximately 35% lower with autofill”，媒体转述版本写作”The average website saw a 75% reduction in abandonment and, on the shoppers’ end, a 35% reduction in completion [time]”。

（该组数字出自 Chrome 官方博客《How Google Chrome’s autofill feature helps both shoppers and merchants》（blog.google，2024-12-20，Lokesh Khurana）与开发者版《Autofill in action: real-world insights》（Chrome for Developers，2024-12-17，Maud Nalpas）。两篇原文的 fetch 在本文写作时不稳定，故此处另经 enggtalks 的报道转引核对：https://news.enggtalks.com/how-chromes-autofill-can-drive-more-conversions-at-checkout/ ）

从 autofill 的角度看，本文讨论的现象几乎是同一个问题的另一面：自动填充之所以有效，是因为它填的是用户自己给过的、多半还想要的东西；而糟糕的默认值之所以糟糕，是因为它填的是别人猜的、未必是用户想要的。Sherwin 也提到过这个对称性：在没有可见标签时，浏览器的自动填充可能填错，用户只能”delete the text in each field one by one”去逐个核对纠错。

2.4 结转答案（carried-forward answers）#

GOV.UK Design System 在讲多页面表单时提出的一条做法：如果同一份信息在一次流程里需要多次提供，应通过”pre-populating the relevant fields”或”showing carried-forward responses as an option for the user to select”来复用，并且明确要求——

You should provide a ‘Change’ link next to each section on your check answers page so that users can add or change the information.

预填 + 修改入口，这是规范层面的标准配置。它说明：预填与”可低成本改掉”应当同时设计，而不是二选一。

2.5 一个反直觉的规范事实#

在动手写这篇文章之前，我先去查了 WCAG。结果是：WCAG 2.2 全文里没有出现过一次 “placeholder”。

这不是巧合，而是规范体系的真实状况：WCAG 关心的是结果（用户能否知道要输入什么、能否看清内容），不指定实现（必须用 label，还是可以用别的机制）。所以对占位符的约束，是从别的成功准则推出来的：

• SC 3.3.2 Labels or Instructions（Level A）：“Labels or instructions are provided when content requires user input.”其 Understanding 文档把 benefits 写得很具体：提供标签与说明”can prevent users from making incomplete or incorrect form submissions, which prevents users from having to navigate once more through a page/form in order to fix submission errors.”——注意这句话里的因果链：看不清标签 → 填错 → 提交失败 → 不得不重新走一遍流程。本文讨论的”多一步”，正是这条链子的起点。
• SC 1.4.3 Contrast (Minimum)：W3C 的 Understanding 文档明确写道，“The minimum contrast success criterion (1.4.3) applies to text in the page, and placeholder text is text in the page. If used, placeholder text needs to provide sufficient contrast.”

对占位符最直接、最不留情面的禁令其实来自两家政府设计系统：

• GOV.UK Design System（英国政府数字服务）列了一节 “Avoid placeholder text”，理由三条：用户一开始输入它就消失，会给有记忆障碍或在核对答案的用户造成问题；不是所有读屏软件都会朗读它；浏览器默认样式通常达不到 WCAG 2.2 SC 1.4.3 的对比度要求。
• USWDS（美国 Web 设计系统，GSA / 18F）在 Text input 组件下同样写着 “Avoid placeholder text”，理由是：占位符在用户点击字段后消失，用户想回头核对自己填了什么时就没有了；对认知或视觉障碍者还有额外障碍；且浏览器默认渲染的对比度”does not provide a high enough contrast ratio”。

W3C 自己的 WAI 教程《Form Instructions》也把话说得很死：

placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels.

以及那句”Be aware that this makes it very hard for users to review the form.”——让表单变得难以复核。这几乎就是本文主题的一句话版本。

同一份 WAI 教程的姊妹篇《Labeling Controls》还记下了用户对”没有可见标签”这件事的态度，语气比规范文本更直白：“Sometimes designers propose not including visual field labels. However, most users prefer or even need visible labels to understand the form.”——设计者常提议省掉可见标签，但多数用户需要它。它同时给了一条容易被忽略的实施细节：标签可以被视觉上隐藏（用于朗读与语音输入），但必须留在代码里。这为第二节开头那条”提示被当成数据”的对照提供了规范侧的解法：让标签不可见可以，让标签不存在不行。

W3C 内部对这条路径并非没有质疑。GitHub 上 WCAG 仓库的 issue #100 里，有人指出大量实现把某个技巧文档当成”只要有 aria 属性就算满足可见标签要求”的合规路径，并称”This is a major problem for mobile were everyone loves placeholders over labels.”

顺带说明一个流传很广但需要限定的事实：HTML 5.1 时代曾经有一段规范警告，里面有 “placeholder text may be mistaken for a pre-filled value” 这样的措辞。现行 WHATWG Living Standard 已经不再包含这段警告，它被压缩成上面那句 “should not be used as an alternative to a label”；而 W3C 低视力无障碍任务组的 wiki 页面（那只是 AGWG 参与者的协作笔记，页面自带”不代表共识、可能有错误信息”的免责声明）仍在转录旧版文本。引用时若要强调”被误认为预填值”，稳妥的出处是 NN/g 的用户测试结论，而不是旧版规范。

3.1 察觉机制：有内容的字段在视觉上退隐#

人的视线天然被空字段吸引。Sherwin 引用眼动研究的结论是：“Eyetracking studies show that users’ eyes are drawn to empty fields.”——空的地方是缺口，缺口引发填补动作；非空的地方不是缺口。

于是，一个已经被预填的字段在页面上是”更不显眼”的：它看起来已经处理好了，不需要再看。这本身在多数情况下是优点，但在两种情况下变成缺点——

• 当预填内容是错的或不需要的时候，用户找不到它，也就找不到”需要改”这个判断的触发点；
• 当一个字段已经非空，而另一个还空着时，用户的注意力全部压到后者身上，前者就这么被带进了提交。

Sherwin 在讨论”浮动标签”这种折中方案时，也承认它没有解决前两条危害：“fields with text in them are less noticeable, and users might think there is already a default value entered in the field.”

3.2 归因机制：把”提示”读成”数据”，把”数据”读成”事实”#

察觉之后是判断。用户要在极短时间内回答一个问题：这个框里的东西是什么？

有四种可能的答案：系统替我填好的默认值、我自己上次输入的东西、浏览器替我存的、或者只是一个示例。人脑在这几种之间做区分时，靠的主要是视觉线索——颜色、字体、以及一个很关键的语义线索：这个内容会不会随我点提交一起被送走。

占位符式的提示在这里被读成了数据。Sherwin 记录的观察是：

Users may mistake a placeholder for data that was automatically filled in. When there is already text in the field, people are less likely to realize that they can type there. Some users assume the placeholder text is a default value and skip the field completely.

这件事在实证层面也有对应研究。Breitmayer、Arnold、Winter 与 Reichert 在 Information Systems and e-Business Management（vol. 22, no. 1, pp. 171-207, 2024）上的 “Exploring user editing preferences in electronic forms: an empirical study”，用 162 名参与者做了一项关于电子表单（订单录入、纳税申报一类）的实验，研究的核心问题之一正是用户在不同场景下如何感知表单字段的先后顺序、什么样的顺序算”直观”。他们的结论之一是：不同字段组织方式之间的”直观性”差异显著，而用户对字段应该如何排列存在一种共同理解（例如需要上传文件的字段应当放在表单末尾）。

这项研究表面上谈的是顺序而不是预填，但它给本文提供了一个重要的旁证：用户在电子表单里并不只是被动接受者，他们会主动评价”这个界面要求我做的事是否顺理成章”，并且这种评价有系统性、可被测量。 本文讨论的打断之所以容易被容忍到最后一刻，正是因为大部分用户不会把”我得多删一次”说成”这里设计得不好”——他们只是默默删掉，然后继续。

最后半句值得停一下：有些用户干脆跳过整个字段。也就是说，察觉机制和归因机制叠加的结果，未必是”多一步删除”，也可能是”漏填一个字段然后提交失败”。失败之后按 SC 3.3.2 Understanding 文档里那条因果链，用户要”navigate once more through a page/form”——整个流程重走一遍。多一步删除是一秒钟的事，漏填一个必填项是几十秒甚至几分钟的事。

3.3 操作机制：多出来的那个动作值多少钱#

如果用户确实注意到了、也正确判断出了”这不是我要的”，那么他要付出一次删除动作。在认知科学里，这类成本有相对成熟的估算方法。

Hick–Hyman 定律（Hick & Hyman, 1954）说的是选择反应时间随备选项信息量对数增长；Keystroke-Level Model（Card, Moran & Newell, 1980）把一个交互任务拆成 K（击键）、P（指点）、H（眼动或心理操作）并按固定算子表加权求和。

用 KLM 的思路粗算一次”选中并删除一段预填文本”：把光标定位到文本起始处大约是一次指点（P，一次移动平均取 1.1 秒量级）；框选（通常一次拖拽或 Ctrl/Shift 加方向键组合）约 0.5 秒；按下 Delete 是一次击键（K，熟练用户 0.2 秒量级）。三步加起来，熟练用户大约在 1.5 到 2 秒之间，外加一次视觉确认。也就是说，一个熟练用户在一次”删除无用预填”上的开销，和一次普通点击处在同一个数量级。

这个数字之所以值得写出来，是因为它常常被两类人低估：一类是产品方（“就多一次点击而已”），另一类是用户自己（“我也知道该删”）。对一个在结账页做决策的人来说，一两秒未必致命；但把同样的动作乘上整页的预填字段数量、乘上”同一段内容在多处重复”、再乘上手机端与移动网络下反复往返的成本，它就会变成可观的一块。

3.4 校验机制：把不便升级成错误#

前三种机制都还能靠用户的主动性化解。第四种不行：用户并不知道自己漏了或错了，直到系统告诉他错了。

这里出现了一个结构性的不对称——错误的代价总是被低估，预设的收益总是被高估。预填在最好的情况下省一次输入，在最坏的情况下制造一次提交失败。系统在开发与测试阶段看到的是前一种情况，用户在生产环境里遇到的是后一种情况。

Sherwin 对这一点还有一个补充观察，与本文主题直接相关：在缺少可见标签的表单里，“Without labels, users cannot check their work before submitting a form.”——没有标签就无法在提交前自查。预填 + 无标签 + 提交失败，三者叠加，就是一次完整的、用户没有任何工具可以自行避免的失败。

这个机制还有一个更安静的版本，而且它已经被统计学家在真实数据上抓到了。Whittard、Ritchie、Phan、Bryson、Forth、Stokes 与 Singleton 在 Statistical Journal of the IAOS（vol. 39, no. 3, pp. 661-677, 2023）上的 “The perils of pre-filling: Lessons from the UK’s Annual Survey of Hours and Earning microdata”，研究的是英国官方统计机构 ASHE（Annual Survey of Hours and Earnings）的问卷流程。文章摘要里的问题陈述是：

We study whether the use of prefilled forms in ASHE may create inaccurate values in one of the key fields, workplace location, despite there being no direct evidence of it in the data supplied to researchers.

也就是说：预填把”工作地点”这个字段预先填上了一份，而受访者没有去纠正它；这种错误不会以任何形式出现在交付给研究者的数据里，研究者拿不到证据，也就不会去质疑它的可信度。研究者随后检验的假设是——在多工作地点雇主处工作的员工，更可能因为没有去修正这个变量而导致工作地点被错误记录。

这是本文讨论的现象里最值得警惕的一个变体。用户没有多点一次删除，代价不是他自己多花两秒钟，而是一个错误值从此进入了公共统计口径，并且带着”用户自己确认过”的外观向下游传播。系统收下了用户的沉默，并且当成了同意。

值得强调的是，这里头没有一处是恶意。最容易被忽略的伤害，恰恰来自那些”出发点是替用户省事”的设计。

还有一个更极端的变体：预填的内容被存到了用户根本没有预期的地方，于是”删掉它”这件事从一次交互变成了一项善后工作。仓库 brave/brave-browser 的 issue #24757，标题《Crypto wallet recovery codes can end up saved in autofill》，创建于 2022 年 8 月 17 日，状态至今仍是 open。问题是：用户在 NuFi 钱包扩展的网页端恢复助记词时，浏览器把这些词当成可自动填充的内容存了下来。修复由扩展方完成，而维护者在 issue 里给出的处置建议是——

we recommend clearing the autocomplete history to wipe the wallet’s seed phrase words stored by the browser’s autocomplete while the bug was there

“清空自动填充历史”——注意这不是”下次别再填”，而是”你之前填过的东西已经被记下来了，得自己去擦掉”。预填在这里制造的垃圾，用户自己不知道存在，也就无从自己删除。

4.1 单次交互尺度：那些被用户自己撞上的缺陷#

一个现象有多普遍，看它出现在多少个互不相干的真实产品里。下面四个 issue 都来自公开的仓库，都指向同一件事：预填了一段用户用不上的内容，而且没有廉价的清空方式。

GitHub。 仓库 dear-github/dear-github 的 issue #212，标题《Change issue default search prepend query form “is is” to just “is”》，创建于 2016 年 11 月 25 日，到本文写作时状态仍是 open。这份 issue 的正文几乎可以当作本文的英文摘要来读：

The search method for issues includes, by default, is:issue is:open to the query. This is biased and assumes that users are, by default, more likely to search for open issues. I don’t have data to prove what is the average user intent, however considering that this is a search field making it unbiased and with broader results seems correct behavior considering issue search.

At first this behavior might look handy, however what it actually does is hide correct and valuable responses from users. More importantly issues are already resolved, documented or fixed are not shown.

Also humans are inherently lazy, developers even more, so when searching for issues a particular project developers don’t perform an additional search for closed issues this often causes users inadvertedly duplicate closed or resolved issues

请注意这个 issue 的标题本身就是一次”删除”：作者的诉求是把默认预填的 is:issue is:open 改成 is:issue。而第三段则点出了一个比”多点一次”严重得多的后果——搜不到已关闭的 issue，就会重复提交一个已经被解决过的问题。 一个用不上的预填值，不只制造摩擦，它还会污染下游（重复 issue、重复工单、重复提问）。

Grafana。 仓库 grafana/grafana 的 issue #97618，标题《Explore: “line contains” field in logs search cannot be emptied once a value is set under latest Grafana Cloud version》，创建于 2024 年 12 月 9 日，现已关闭。场景是用户在 Grafana Cloud 的 Explore 里查日志：为了筛选 job 或 level，他填了几个条件，界面上同时存在一个名为 “Line contains” 的操作，这个操作会把搜索词预填进文本搜索框——而文本搜索跟他要做的事（按 job / level 过滤）并不是一回事。它预填了，用户没法清空，只能想办法绕过去。修复由 PR #97551 完成。

这是本文讨论的现象的一个极好的标本：预填不是凭空出现的，它是别的功能顺手把值填进来的；而”清空”这个本该存在的动作没有被一起交付。

WezTerm。 仓库 wezterm/wezterm 的 issue #1988，《Search: option to not use last search term》，创建于 2022 年 5 月 14 日，状态至今仍是 open。issue 正文：

In dc0fde7 the behaviour of the search was altered and it now defaults to using the last search term, if the pattern is empty. I’ve been using the empty pattern as default, though.

一次行为变更，把”空搜索词”默认改成了”沿用上一次搜索词”。报告者说得很直接：“I’ve been using the empty pattern as default, though.”——他就是要空着搜。至于为什么需要空着搜，issue 里没说；维护者回复得也很客气但没问出结果：“Can you share a bit more about the workflow in which you want it to be explicitly blank?”——这个反问本身就说明了问题的性质：要衡量一个默认值合不合适，得先知道它对谁不合适，而这正是默认值设计最难拿到反馈的地方。

incluud/accessible-astro-starter。 issue #190 的标题几乎就是本文的英文摘要：《Use directory question suggestion as placeholder/default, not pre-filled value》，创建于 2026 年 5 月 23 日，状态 open。正文：

The directory selection question currently comes with a value already filled in. This forces users to manually delete the suggestion if they want to enter a different directory. This behavior is unintuitive and unfriendly.

“forces users to manually delete”、“unintuitive and unfriendly”。四个互不相干的仓库、四个互不相干的团队，结论几乎一致。同一类缺陷在不同代码库里重复出现，通常说明它不是某个团队的水平问题，而是某种默认决策方式的问题。

4.2 流程尺度：转化与放弃#

单次交互的代价需要乘以频次才有意义。当这个输入字段处于下单、支付、注册、绑定的路径上时，它的代价就会被流程数据放大。

方向相反的证据同样清楚：Chrome 团队那组数据说明，当预填的内容是对的，用户愿意继续的比例显著更高——使用自动填充的表单，放弃率低约 75%，填表耗时低约 35%。Baymard Institute 长期跟踪的全球平均购物车放弃率则常年停在 70.19% 附近。这两个数字放在一起给出的信息是明确的：在结账路径上，替用户少做事能做到什么程度，以及反过来的代价有多大。

本文不宣称这两组数据之间存在因果关系——它们测的不是同一件事（一个是 autofill，一个是”默认值是否有用”）。但它们共同支持一个更朴素的判断：在转化路径上，输入环节的每一次多余摩擦都有价格，而预填是少数几种能同时往两个方向作用的杠杆。用错了，它是负债；用对了，它是最便宜的优化之一。

4.3 社会与合规尺度：预填一旦绑定商业选项，就不再是可用性问题#

前面两个尺度上，预填是设计问题。但存在一个临界点：当预填的内容不是数据，而是选项——尤其是需要用户付费的选项——同一个动作就换了性质。

这不是推测，是有明确法律定义的。欧盟《数字服务法》（Digital Services Act, (EU) 2022/2065）在 Recital (67) 里定义：

Dark patterns on online interfaces of online platforms are practices that materially distort or impair, either on purpose or in effect, the ability of recipients of the service to make autonomous and informed choices or decisions.

并在 Article 25 “Online interface design and organisation” 第 1 款设下禁令：

Providers of online platforms shall not design, organise or operate their online interfaces in a way that deceives or manipulates the recipients of their service or in a way that otherwise materially distorts or impairs the ability of the recipients of their service to make free and informed decisions.

第 3 款还专门列举了三类做法，作为委员会将来出台指引时的重点：(a) 在征求用户决定时给某些选项更多显著性；(b) 用户已经做过选择之后，反复要求其重新选择，“especially by presenting pop-ups that interfere with the user experience”；(c) 让终止服务的流程比订阅更难。这一组里 (a) 与 (b) 恰好是本文讨论的两种形态：把不合适的选项摆在显眼位置，以及让”改掉上一次的选择”变得麻烦。

这条禁令不是纸面上的。2023 年 1 月 30 日，欧盟委员会与 23 个成员国及挪威、冰岛的消费者保护机构发布联合新闻稿 IP/23/418，对 399 家零售网店做了统一检查，结果是 148 家至少含一种暗黑模式，其中 54 家通过视觉设计或措辞引导用户选择订阅、更贵的产品或配送选项，70 家隐藏了运费、成分、是否存在更便宜选项等重要信息，102 个被检查的 app 中有 27 个存在同类问题。负责的委员 Johannes Reynders 的话是，接近 40% 的购物网站依赖操纵性做法。

学术侧的测量给出了同向的结果，而且规模要大得多。Mathur、Narayanan 与 Thai 在 Proceedings of the ACM on Human-Computer Interaction（CSCW, vol. 3, 2019）的 “Dark Patterns at Scale” 里爬取了约 11,000 家购物网站、约 53,000 个商品页面，找出 1,818 处暗黑模式实例，归为 15 种类型、7 个大类，并发现其中 183 家网站确实在从事欺骗性做法。论文里还有一项发现，比上面那组数字更值得停下来看一眼：他们识别出 22 个第三方机构，把暗黑模式作为”交钥匙”方案在售卖。

“22 个第三方机构”这个数字值得多想一层。它说明暗黑模式在今天不是若干个作恶者的个人选择，而是一门有现成供应链的生意：模板、插件、咨询打包成服务，再卖给各个平台。这也解释了为什么第四节开头那种”替用户省事”的善意，会稳定地滑向伤害——当一种做法有现成的商业模板时，采用它不需要恶意，只需要一次采购决策。

在中国这边，形态从”强制默认勾选”转向了”视觉误导”，但机制没变。央广网中国之声 2026 年 1 月 8 日的报道《从强制”默认勾选”到”隐形诱导” 记者起底购票平台搭售套路》（记者周益帆）记录了几个细节：

• 2025 年 11 月，广西消费者王冉（化名）在某第三方购票小程序买柳州至杭州南的动车二等卧铺，页面显示票价 404 元并标注”免费选铺”，到支付页变成了 515 元。她的说法是：“付钱的页面和刚点进去的页面是不一样的……它写免费选座，按最低价写在上面，付钱的时候就是完全不一样。付钱的时候是五百多元，我也没有购买任何保险，为什么票价突然贵一百多元？”
• 2025 年 10 月，四川消费者刘莉（化名）遇到的是另一种：购票首页显示 50 元，弹出 72 元，她”立马点击返回键，但系统强制出票”，而此前已在不知情的情况下开通了免密支付。退款时她才发现多出来的是”无忧退票”等服务费，而”购票过程中，既没有勾选的弹窗提示也没有注意到有明确提示服务费的字样”。
• 记者实测的一套：某订票小程序搜上海到北京高铁二等座，价格 576 元，搜索页排名第一的选项写 574 元”已优惠两元”，点进订票页后左下角支付价变成 626 元，明细里含”便捷购票""退改补偿”等增值服务费用。

报道里中国政法大学知识产权中心特约研究员赵占领的分析，恰好点中了预填设计中最微妙的一种形态：排序本身成为暗示。

很多订票平台按照价格从低到高的顺序进行排列，最前面的一个是价格最低的，但是消费者却无法按照最低的价格购买车票或是机票。他必须购买其他的产品之后，才可以享受到这个所谓的最低价，这在价格排序规则上误导了消费者。

“他必须购买其他的产品之后，才可以享受到这个所谓的最低价”——这句话描述的仍然是我们熟悉的那个动作：为了让眼前这个预填的价格变成真的，用户必须额外付出一次修改（这里是删除增值服务）。只不过这一次修改被伪装成了优惠。

报道同时引述了相关规定：“购票平台的保险、加速包、会员等相关增值服务不得默认勾选；以直接捆绑或者提供多种可选项方式向消费者搭售商品或者服务的，应当以显著方式提醒消费者注意。“江苏省消保委的调查显示，超九成受访者使用过第三方购票平台，超半数认为隐性消费陷阱最突出。

把这三个尺度并排看，可以得到本文的核心判断之一：预填的伦理风险随”它是不是需要花钱的选择”而陡增。预填一个上次的搜索词，最坏结果是用户多按一次删除；预填一个付费选项，最坏结果是用户在毫不知情的情况下付了钱，并且因为”已经出了票”而放弃维权。同一种实现缺陷，在不同的激励结构下，制造的是完全不同的伤害。

5.1 无障碍规范要求的恰恰是预填#

WCAG 2.2 里与预填最直接相关的一条成功准则，是 SC 3.3.7 Redundant Entry（Level A）：

Information previously entered by or provided to the user that is required to be entered again in the same process is either: auto-populated, or available for the user to select.

而且它有三个例外：重新录入确有必要、该信息是保障内容安全所必需、此前录入的信息已不再有效。

它的 Understanding 文档把理由讲得很清楚：目标是”Make it easier for users to complete multi-step processes”，减少认知努力，也减少回忆负担；而”Information that is required to be remembered for input can pose a significant barrier to users with cognitive or memory difficulties”——让用户回忆自己刚才输过什么，本身就是一道障碍。对认知障碍用户而言，一个”必须先删掉再输入”的空字段，不比一个预填好的字段更友好。

GOV.UK 的 Question pages 模式讲得更直接：“Whenever possible, do not ask a user to re-enter information they’ve already provided.”，并把复用方式列为预填或”以选项形式呈现、供用户选择”。

同一份 GOV.UK Service Manual 在讲表单结构时给出的另一条原则，也能用来减轻本文讨论的负担：把长表单拆到多个页面上，每页只放一件事（“one piece of information you’re telling a user / one decision they have to make / one question they have to answer”），好处是”understand what you’re asking them to do / focus on the specific question and its answer / find their way through an unfamiliar process / use the service on a mobile device / recover easily from form errors”。

一页只放一件事，看上去和本文的论点无关，其实关系很直接：每页预填字段越少，需要用户删除的东西就越少，而删除总量是线性累加的。同时单页步骤少，填错之后的恢复成本也低——这一点恰好对应 3.4 节说的”校验机制把不便升级成错误”。把一次二十个字段的长表单拆成五个四字段的短页面，用户的每一次删除仍然存在，但它不会再叠加在一次高风险的提交上。

所以规范的态度不是”别预填”，而是**“该预填的必须预填，同时必须可改”**。GOV.UK 的 Check answers 模式把这条要求写成了操作规范：回到上一步时，之前填过的信息要被预填回来；每一节旁边都要有 Change 链接；可选项没填时要显示为 “Not provided” 而不是留白。

5.2 真正的分界线#

把上面两边放在一起，本文想主张的分界线是：

预填是否成立，取决于两个问题：这个内容对用户本次意图的成立概率有多大？以及当它不成立时，用户改掉它的成本有多低？

只有第一个问题的答案才是”预填是不是个好主意”；第二个问题的答案，决定了它是不是一个安全的预填。而当前大量出问题的实现，是只回答了第一个问题就上线了。

USWDS 在这一点上给过一个很实用的技术区分，适合抄作业：

Choose disabled or read-only behavior deliberately. A native disabled input cannot be edited or reached with the Tab key, and its value is not submitted with the form. A readonly text input remains focusable and its value is submitted. Use read-only behavior when users need to review or copy a value.

disabled 与 readonly 的差别不只是能不能改，还包括值会不会被提交。这正是”用户能否低成本改掉它”在工程上的落点：需要用户复核但不该改的字段，用 readonly 并配一个清晰的修改入口；不该被提交的，用 disabled。

5.3 这件事正在被专门研究#

预填的交互设计并不是靠拍脑袋。USWDS 在 2024 年 9 月 10 日发起过一个公开讨论，标题就叫《Pattern proposal: Help users to… Know when their information is prefilled》（discussion #6053）；配套的 uswds-proposals 仓库在 2024 年 10 月 31 日登记了 issue #39 “Component lifecycle: Pre-filled form pattern proposal”。

需要说明的是，这仍然是提案阶段的讨论，不是已发布的规范。USWDS 目前的组件库中没有名为 “Clear default text” 的组件，也没有名为 prefill 的 pattern——我抓取了其 components 与 patterns 两个索引页全文做检索，相关关键词零命中。所以这里能说的只是：这个问题已经被专业机构正式列为待解决议题，而不是被无视了。

美国退伍军人事务部则走得更远，公开了一份预填研究计划与报告（va.gov-team 仓库中 products/authenticated-patterns/Design-and-research/2024-07-Research-Initiative-One-Prefill/Prefill Research Report 09_2024.md），研究问题里明确包含”理解用户何时需要预填提示出现”与”理解用户期望预填数据如何展示”。这类机构要把预填做成受认证流程的一部分时，就必须先解决”用户怎么发现和纠正它”，因为在那种场景里，一个没被发现的错误预填可能直接导致申报材料出错。

学术侧对”预填该不该有”也有实证研究。Fochmann、Müller 与 Overesch 在 Journal of Economic Psychology（vol. 83, article 102365, 2021）上发表的 “Less cheating? The effects of prefilled forms on compliance behavior”，研究的正是”在作弊与说谎成为关切的场景中，人们遇到 prefilled forms 或 prefilled data entry masks 时会怎么做”；Ruffle 与 Morrison 的 “Insurable Losses, Pre-filled Claims Forms and Honesty in Reporting”（SSRN 3518766）则把问题放进了保险理赔场景。这两篇都指向同一个此前被忽略的角度：预填不只是便利问题，它还会改变人的诚实程度。一个被预填的字段，用户可能不去核对；而错误信息里”以为存在”的内容，比空白字段更容易被提交上去。

6.1 四个前置问题#

在决定是否预填一个字段之前，先回答四个问题。任何一条答不上来，就应该先别填。

问题一：这份内容的来源是”用户自己的历史”还是”产品的猜测”？

这是最关键的一条判据，因为它直接对应了前面引用的那组对照数据。Chrome 的 autofill 之所以能带来放弃率的大幅下降，是因为它填的是用户自己给过的东西；而糟糕的默认值之所以糟糕，是因为它填的是别人猜的东西。GOV.UK 把复用答案的做法限定在”用户本次流程里已经提供过的信息”上，WCAG 3.3.7 的措辞同样是 “Information previously entered by or provided to the user”——规范给的是”来自用户”这个限定，而不是一个无条件的预填许可。

问题二：这次预填对当前意图的成立概率是多少？有数据支撑吗？

“上一个搜索词”、“上一次的收货地址”这类默认值，成立概率因场景差异极大，而且通常没有人在测量它。GOV.UK Question pages 里那条”do not ask a user to re-enter information they’ve already provided”之所以是规范要求而不是建议，正是因为它在流程内部成立概率接近 1——用户几分钟前自己刚输过。而跨会话、跨场景的”上次”，没有这个保证。

如果一个默认值的成立概率只有一半，那么它带来的期望收益就已经很小了——因为另一半用户付出的是确定的代价。

问题三：用户改掉它的成本有多低？有没有一键清空？

这不只是”有没有 X 按钮”这么表面。一个真正低成本的可改，需要同时满足：

• 可发现：用户知道这个框里有东西可以被改，而不是以为它是提示或已经完成；
• 可定位：光标能一键落在这段文字的开头，或者整段能被直接选中；
• 可撤销：按一次就能删掉，而不是要按住退格键划掉一百个字符；
• 可恢复：删错了还能退回来（这正是浏览器原生 undo 的价值，用 value 属性硬改会把这个能力一起弄丢）。

Grafana 那个 issue 的问题恰好在第一条：不是不能改，是用户不知道能改、也找不到地方改。GitHub 那个 issue 则是四条里最极端的：它不是”改起来费事”，而是一旦不接受这个默认值，整个查询串都得重写——is:issue is:open 要变成 is:issue，用户还得自己想明白多出来的那半截是不是真的需要。

问题四：这个字段会参与计费、授权或法律声明吗？

如果会，它就不该由系统替用户做决定，而不只是”加个提示”。这一条跨越了可用性与合规的边界，第四节那两个案例说明，把它留在”可用性”的框架里讨论本身就会低估它。

6.2 一个可复用的分类#

综合前面几节，可以把”框里那段文字”按危险程度分成四类。这个分类的价值在于，前两类和后两类不该用同一套规则处理。

“伪装”这一类是最值得单独拎出来的，因为它在代码里非常隐蔽：placeholder 是一个合法的属性名，写成 <input placeholder="请输入手机号"> 是完全正确的写法；错误发生在有人为了让”提示看起来像输入过的内容”而把它写进了 value，或者用 CSS 把 ::placeholder 的样式做得像普通文本以至于用户分不清。前者是实现错误，后者是设计错误——后者更麻烦，因为它通常是刻意为之。

7.1 让”可改”成为默认交付项，而不是加分项#

上一节说预填的成立概率由第 6.1 节的第一个问题决定。第二个问题决定它是否安全。而安全的预填，必须和它的撤销路径一起发布。

具体到工程实现，最低成本的一条路是：给可能预填的字段配一个清空按钮（带可访问名称，比如 aria-label="清空搜索条件"），并且在有值时才显示。这条改动很小，但它把 Grafana 那类”清空入口缺失”的缺陷挡在了设计阶段。

对于文本较长的预填（例如带前缀的历史查询），更好的做法是让用户能从中间编辑而不是只能整体覆盖——最省事的实现是选中文本中间一段，让用户的下一次输入替换掉选区。

7.2 用 readonly 而不是 disabled#

USWDS 那段关于两者的区分值得单列一条，因为它是常被搞反的地方：disabled 的输入框无法编辑、无法 Tab 到、值也不会随表单提交；readonly 的输入框仍然可聚焦，值会被提交。

对”系统帮用户填好了某个确定值、用户只需要复核”的场景（比如从账户信息带出来的昵称、从订单带出来的商品名称），正确做法是 readonly 加一个清晰的”修改”入口，而不是 disabled。用 disabled 的后果是：用户看不到值、不确定发生了什么，甚至以为什么都没发生。

7.3 让预填在视觉上就自证身份#

第二节引用的 NN/g 结论是”有内容的字段在视觉上退隐”。这条是可改的：让”这是系统填的、可以改”这件事在视觉上成立，而不要指望用户靠猜。

具体手段包括：预填值用与用户输入值可区分的样式（比如略浅的颜色，但必须满足 1.4.3 对比度——不要为了区分而牺牲可读性）；清空入口固定出现在同一位置，避免”有值才出现”造成的布局跳动；在字段组标题上说明这些值的来源（“已填入你上次使用的地址”）。

USWDS 对错误提示也有一条相关的经验可以借鉴：“Wait to validate. Only show error validation messages or stylings after a user has interacted with a particular field.”——不要在用户还没动手时就告诉他这里有问题。预填的值同样是这种情况。

这条对策还有一个更老的名字。Nielsen 在 2006 年的《Progressive Disclosure》里讲的是同一件事的另一面：把不常用或高级的选项推迟到二级界面上，“Initially, show users only a few of the most important options. Offer a larger set of specialized options upon request.”。他还有一句观察值得记下来：在一个用渐进披露设计的系统里，“某样东西出现在首屏”这件事本身，就在告诉用户它重要。

把这个原则搬到预填上，得到一个反直觉但很实用的推论：预填不只是”填什么”的问题，还是”什么该出现在第一层”的问题。一个被预填上的字段，用户会默认它是重要的、是系统替他确认过的；这既让真正重要的默认值获得了它应得的分量，也让不重要的预填获得了它不该有的分量。控制”什么出现在首层”，有时候比逐个字段地做判断更省事。

7.4 让”清空”成为一个动作，而不是一段删除#

如果一定要靠删除，那么删除操作本身也应该被优化。对搜索类输入框，把”清空”做成一个独立的按钮或快捷键，好过让用户自己去数退格键；对数值与日期类字段，配合直接编辑与合理的输入归一化（接受 20260108 与 2026-01-08 两种写法）能省掉大量修改动作。

Belgacem、Li、Bianculli 与 Briand 在 ACM Transactions on Software Engineering and Methodology（vol. 32, issue 2, article 47, 2023，40 页）上提出过一个自动填充分类字段的方法 LAFF，用贝叶斯网络预测用户接下来最可能选的类别，报告的平均倒数排名（MRR）超过 0.73，每条建议的生成时间不超过 317 毫秒。这项工作本身是关于怎么推荐的，但它的评测指标很有启发：评价自动填充系统的质量，不应只问”命中率多少”，还应问”用户采纳一条建议需要几步”。采纳成本和推荐准确率是两个独立的指标，而现有工作几乎都只优化后者。

7.5 对涉及计费或授权的选项，交回选择权#

这一条与前六条不同：它不是可用性优化，而是合规底线。第四节引用的 DSA Article 25 第 1 款是直接禁令，GOV.UK 还补了一条容易忽略的执行细节——“Never mark mandatory fields with asterisks.”——意思是必填性要靠文案说明，不能靠一个默认勾上的框来暗示。

在中国，《中华人民共和国电子商务法》（2018 年 8 月 31 日通过，2019 年 1 月 1 日施行）第十九条给出的表述更短，也更直接：

电子商务经营者搭售商品或者服务，应当以显著方式提请消费者注意，不得将搭售商品或者服务作为默认同意的选项。

同法第十八条还有一句常被忽略的规定：“电子商务经营者根据消费者的兴趣爱好、消费习惯等特征向其提供商品或者服务的搜索结果的，应当同时向该消费者提供不针对其个人特征的选项。“——按个人特征排序的结果，必须同时提供一个不针对个人特征的选项。这条正好是 4.3 节开头那个”临界点”在中文立法里的对应物：算法猜出来的默认值可以存在，但猜出来的那个不能是唯一选项。

配套的还有《中华人民共和国消费者权益保护法实施条例》（国务院令第 778 号，2024 年 3 月 15 日公布，2024 年 7 月 1 日施行）第十一条：“经营者不得以暴力、胁迫、限制人身自由等方式或者利用技术手段，强制或者变相强制消费者购买商品或者接受服务，或者排除、限制消费者选择其他经营者提供的商品或者服务。经营者通过搭配、组合等方式提供商品或者服务的，应当以显著方式提请消费者注意。“央广网报道中江苏省消保委调查里那句”超半数受访者认为隐性消费陷阱最为突出”，说明这不是个别平台的问题。

7.6 建立一条回归检查项#

这类缺陷很难靠人工评审发现，因为它只在”特定用户 + 特定场景”的交叉点上出现。可以固化成一个检查问题：“这个界面上，有哪些字段对一位首次使用、且只想完成最小任务的用户来说，需要先删掉点什么？”

这个问题问的是”首次使用”和”最小任务”，因为它们恰好是默认值的命中率最低、而用户又最不愿意忍受打扰的两种情况。如果答案不是”没有”，那预填在这里就是负担。

顺带一提，这也是为什么这类缺陷普遍在测试里逃过：内部测试者往往就是那个”上次搜索词恰好还想再来一次”的人。

7.7 把这次交互纳入研究，而不是等用户投诉#

USWDS 的预填模式讨论（#6053）与退伍军人事务部的预填研究计划说明，专业机构处理这个问题的方式是先研究用户如何发现与纠正预填内容，再定模式。对资源有限的团队，一个更小的版本是：在可用性测试里加一个专项任务——给参与者一个明确目标（例如”给三个月没联系的人发一条消息”），观察他在到达”发送”之前做了哪些计划外的操作。这些操作就是打断的证据，比问卷里的”你觉得方便吗”可靠得多。