用AI写文章。用AI翻译。用AI修链接。用AI统计访问量。问AI“这里是不是不太好懂？”，然后再用AI去改。
走到这一步，通常会冒出一个问题。
所有人都对这个网站太熟悉了。
做网站的人知道每个按钮是什么意思。AI读了需求文档，也能明白“这个按钮是相关文章”。运营者看过无数遍，就算有点奇怪，脑子也会自动帮忙补全。
但第一次来的人不一样。
“这是什么？” “该点哪儿？” “为什么只有这里是英文？” “我退不回去了。” “文字能看懂，但就是觉得别扭。”
我想要的，就是这个“就是觉得”。
于是最后冒出来的点子，挺有意思的。
我终于要把调试这道工序外包给真人了。
而且每提一条意见，给1日元。每人最多1000日元。
人类抢AI饭碗的时代来了。负责的业务是“违和感”。
1. 想外包的不是代码审查，而是“第一次看到时的那个卡点”
这次我想要的，不是专家做的大规模审计。
- 看不懂按钮是什么意思
- 不知道下一步该去哪儿
- 标题怪怪的
- 在手机上不好点
- 点进去的链接是另一种语言
- 点了一下，页面变成一片空白
- 句子本身说得通，但人读起来就是别扭
- 觉得这里要是有个什么功能会更方便
大概就是这类东西。
美国政府的网站指南Digital.gov把可用性测试描述为：观察真实用户如何使用产品或服务的方法。[1] 英国政府的GOV.UK也说，看着真实用户操作，就能发现语言、版面等具体问题。[2]
也就是说，“让真人上手用一次”，并不是AI时代突然冒出来的什么神秘仪式。
只是老早就有的可用性测试，回到了一个能用AI批量生产、批量修改的网站身上而已。
2. 有时候，运营者本人反而最没法好好测试
每天认真检查自己的网站。
说起来容易。可文章变多、语言变多、功能变多之后，根本做不到。
而且“做的人自己来看”还有另一个问题。
他知道搜索框在哪儿。 他知道相关文章会出现在哪儿。 他也知道语言切换是怎么设计的。 就算有点不对劲，也会当成“本来就是这样”放过去。
最重要的是，看起来太麻烦了。
这一点出乎意料地关键。
如果靠意志力硬扛麻烦，定个“每天检查100个页面”的目标，这种做法撑不了多久。那就干脆把这道麻烦的工序单独拆出去。
运营者不必是什么都要看一遍的人，
而是决定该看什么，并搭好机制去修复收集上来的问题的人。
3. 一条1日元买的不是“点子”，而是一双新鲜的眼睛
光看“一条1日元”这个数字，便宜得离谱。
但这里我想买的，并不是一份像模像样的咨询报告。
而是**“有一双第一次看的眼睛，在这里卡住了一次”这个事实**。
一个人提出1000条，就是1000日元。 但如果只是把同一件事换个说法，就只算1条。 每人的报酬上限也是1000日元。
这个上限相当重要。
一旦说出“希望大家多提”，世界立刻就会朝着“那让AI列一万条改进点，不就能拿一万日元了吗？”的方向狂奔。
所以，在按条数给报酬的同时，还要配上这些条件：
- 真的看过这个网站
- 写的是真实存在的位置和真实发生的现象
- 不拿同一个问题换说法来凑数
- 设定上限
另外说明一下，一条1日元只是这次实验的设计，并不是通用的合理报酬。如果要请人长时间工作，或做专业评估，就得换成与时间和难度相称的条件。
4. 最大的敌人是“我用AI生成了一万条改进建议”
没必要禁止使用AI。
问题在于，从没看过网站就写出来的改进建议。
“一般来说，网站的导航应该更清晰。” “让我们改善无障碍体验。” “让我们优化响应式适配。”
全都没错。
但全都不是这次想要的。
我想要的是这样的观察：
“这个页面上的这个按钮，点了会发生什么，我看不出来。” “这个标题后面，话题突然跳了。” “只有这个语言版本，相关文章跳到了另一种语言。”
AI可以用来把这些观察整理得简短一些，或者合并重复的内容。
人发现，AI整理。
别把顺序弄反，这一点很重要。
5. 要是一条一条用聊天发过来，发起人会先累死
想让反馈数量变多，提交方式也得设计好。
最要命的是这种：
“第1条。” “第2条。” “对了，还有第3条。” “再补充第4条。”
聊天记录会没完没了地一直往下拉。
这样一来，明明把调试外包出去了，却冒出了回收反馈这项新的手工活。
所以统一一次性提交。
- Excel
- 在线表格
- txt
- 带编号的列表
- 可以直接复制粘贴的文字
什么都行。
截图原则上也不需要。图片看起来方便，但之后要检索、去重、交给AI处理时，阻力很大。
GOV.UK的用户研究指南也提到，打字记录的笔记便于日后保存和分析，把一个观察拆成一个条目，也更方便排序和分析。[3]
格式简单就好。
位置 / 现在是什么样 / 怎么改比较好
如果是bug，就写：
位置 / 做了什么 / 发生了什么
光是这些，后面的AI就能干不少活了。
6. 在多语言网站上，“翻译出来了”和“真人读得懂”是两回事
多语言网站就更有意思了。
从机器的角度看，12种语言全部生成成功。 构建成功。 HTTP 200。 链接也都存在。
可真人一看，照样会觉得别扭。
- 有一部分还留着原文的语言
- 只有按钮的翻译很怪
- 句子意思说得通，但母语者读起来不自然
- 文字变长，版面乱了
- 切换语言后，只有相关文章变回了原来的语言
- 明明是同一篇文章，却缺了一部分
这个只需要看得懂那种语言的人去看就行。
看得懂英语的人看英语。 看得懂韩语的人看韩语。 中文、西班牙语、葡萄牙语、印度尼西亚语、泰语、越南语、法语、德语也一样。
不需要让每个人把所有语言都看一遍。
机器确认“生成出来了”，真人确认“这个正常读得通吗”。
分工不同。
7. 重复的反馈，按报酬算是1条，但对分析来说极其重要
同一个人如果写了
“按钮不好懂” “按钮的意思不明白” “这个按钮是什么？”
三次，算1条就行。
但如果是三个不同的人，各自独立地在同一个按钮上卡住了，情况就不一样了。
这就不是单纯的重复，而是可以复现的摩擦。
所以统计的时候要分开处理：
- 同一个人的不同说法 → 合并
- 不同的人独立提出的同一个问题 → 作为频次保留
“三个人在同一个地方迷路了”，比运营者的个人喜好有分量得多。
GOV.UK也把“经常向真实或预期的用户确认可用性，并在反映用户行为的各种设备上测试”写进了服务标准。[4]
增加人数的意义不是“用意见投票”，而是看同样的摩擦会不会在别人身上也发生。
8. 最终形态是 AI → 真人 → AI，真人成为传感器
最终的流程相当漂亮。
- AI生成文章
- AI翻译
- AI检查链接、结构和显示
- AI修复已知问题
- 真人实际去读、去点、去迷路
- 真人把“总觉得哪里怪”写成文字交上来
- AI合并重复项
- AI按严重程度、可复现性和修复成本分类
- AI生成修复方案
- 修复后，再回到机器检查和真人确认
终于，连人也成了流水线上的一道工序。
不过，留给人的不是单纯的体力活。
而是察觉只有人才会感受到的摩擦。
这反而更像是一次升职。
让机器去看“链接是不是404”，让真人去看“不是404，但不明白为什么被带到了这里”。
让机器去看“翻译的字符串有没有”，让真人去看“有是有，可正常人不会这么说”。
这样分工才自然。
9. 测试的人一看，浏览量也会涨。但别把它当目的
当然，让人看上几十个页面，浏览量就会增加。
如果是有广告的网站，随着正常的浏览，广告也可能会被展示出来。
不过这完全是副产品。
让人去点广告，或者把增加广告展示量定为工作条件，那就是另一回事了。
我买的不是浏览量。
而是真人看过页面之后留下的观察。
顺带访问量涨了一点的话，就当作“做用户测试的时候，收银机也顺便响了两声”，这样想正合适。
10. 自动化的终点，并不是“零人工”
一开始用AI，总忍不住想“能把人去掉到什么程度”。
可是真把自动化推下去，有时会得出相反的结论。
不需要把人全部去掉。
只要把人挪到只有人才能创造价值的地方就行。
文章初稿。 翻译。 整理重复项。 检查链接。 分类。 统计。 修复方案。
这些都交给机器。
然后到最后，
“第一次看，不知道是什么意思” “这里我不喜欢” “总觉得哪里怪” “这个挺方便”
只向真人买这些。
一条1日元买的，不是一行文字。
而是我自己和AI都没有的、另一个人一瞬间的违和感。
把自动化做到极致之后，人又回来了。
而且负责的部门是“总觉得哪里怪怪的”。
太有人味儿了。
出处
参考资料（4条）
- Digital.gov, “Usability testing digital.gov
- GOV.UK Service Manual, “Using moderated usability testing gov.uk
- GOV.UK Service Manual, “Taking notes and recording user research sessions gov.uk
- GOV.UK Service Manual, “4. Make the service simple to use gov.uk
