11. 交给一个真实的人使用

到目前为止，所有裁决都在作者自己手里完成。这里有个盲区：作者太熟悉这个工具了。用什么格式的输入、按什么顺序操作、遇到不对劲会怎么绕开，作者心里都有数，于是一大批假设从来没有被真正触碰过。把工具交给一个真实使用者，这些假设才会一个个冒出来。

作者是最差的测试者

作者测自己的工具，会不自觉地避开它的弱点：用早就准备好的干净数据，按设计时想的顺序点按钮，出了错也知道是哪里的问题、顺手就绕过去了。这些动作让工具「在作者手里」总是好用的。

真实使用者没有这些默契。他不知道输入该用英文逗号，不知道该先粘文本再点按钮，出错时也不知道问题出在哪。他会用作者没预料的方式使用它，而那些方式，恰恰是工具真正会遇到的方式。

一次观察的规矩

找一名真实使用者，把报价整理器交给他，然后守住一条规矩：作者只观察和记录，不中途替工具解释，也不代他操作。

使用者卡在某一步时，作者一句「哦这里得先粘文本」就能让他继续，可这句话同时盖掉了一条最重要的信息：工具本身没把这一步说清楚。作者插一次嘴，就少发现一个真实存在的问题。把「他卡在哪、愣了多久、试了什么」原样记下来，这些才是这一章要的东西。

会自然冒出来的问题

一次真实使用，通常会暴露这几类作者自测照不到的问题：

• 输入校验：使用者把带表头的整段文本粘了进来，第一行「品名 单位 含税价」被当成了一条报价。
• 错误提示：格式不对时，工具要么没反应，要么弹出一句使用者看不懂的报错，没告诉他下一步该怎么办。
• 字段命名：「含税价」这个列名，使用者不确定该填含税的还是不含税的，停下来问。
• 文件选择与导入：使用者想直接导入一个文件，找不到入口，只能手动复制粘贴。
• 恢复路径：点错了一步，不知道怎么退回上一状态，干脆整个刷新重来。

这些问题在作者手里一个都不会出现，因为作者早就知道该怎么避开。

数据边界

真实使用会很自然地想用真实数据，这里要先划一条线。练习优先使用脱敏过的文件，也就是把真实的公司名、金额、个人信息替换成假数据的版本。真实业务数据能不能进入这个工具，不由「这样最方便」决定，由数据的所有者和所在组织的规则决定。这条边界在任何「拿真实数据试一下」的冲动之前就要立好。

把一条观察变成一次修订

把观察到的问题挑一条最典型的，走一遍第二幕的闭环。比如「粘进带表头的文本，表头被当成一条报价」这个问题，转成一条新的验收条件：

以「品名」开头的表头行，应当被跳过，不计入报价。

再把它写成一条测试。这条测试对着现在的实现是红的，因为现在没有跳过表头这回事：

parse-quotes.test.js

// 新增验收条件：表头行不计入报价
test('表头行被跳过', () => {
  const text = '品名,单位,含税价\nM6 螺母,个,0.18';
  const rows = parseQuotes(text);
  assert.equal(rows.length, 1);
});

然后交给 AI，让它在这条测试的判定下把实现改绿，改完照第 10 章看一遍 Diff。这一章的产物由此凑齐三样：一次使用记录、一条从真实使用里长出来的新验收条件、一次由它驱动的修订。

真实的人会暴露作者想不到的输入。下一章换一个方向问同样的问题：测试自己够不够严。方法是反过来，故意把实现改坏，看测试抓不抓得住。