一张家庭工单看板：从反馈墙看 KK 词典的迭代节奏

很多大厂天天喊"以用户为中心"，开几百次需求评审会、画几十页交互图，都不如这张反馈墙真实。

一、先说这张看板长什么样

KK 词典的后台，有一面反馈墙。

上面贴着四条留言。没有工单号，没有优先级标签，没有指派人——只有孩子的手写文字，和一个默默改代码的父亲。

【反馈墙 · 四条留言】  
  
① 能不能在每个单词上面搞个插图 -kenny  
② 字母 g 有点像字母 Q，勾太短了。  
③ 打开反馈墙的时候下面的东西在滑动，反馈墙自己没动。  
④ 背景不够漂亮，优化一下。

如果只看文字，这是一面普通的用户反馈墙。

但如果翻开源码，会发现——这四条留言，每一条都已经被改进了。

这不是一面反馈墙，这是一张"家庭工单看板"。

二、Kenny 的工号签名

最打动我的是第一条：

能不能在每个单词上面搞个插图 -kenny

注意末尾那个 -kenny。

一个孩子提需求，还在末尾工工整整签上了自己的名字。

这个动作很小，但信息量很大：

他不是在"留言"，是在"提单"
他不是"请求"，是"我在用这个东西，我有权利要求它更好"
他把自己当成这个系统的需求方，而不是被动的接受者

成年人提需求往往带着试探（"能不能加个……"），而 Kenny 是直接提——因为他知道墙后面的人会听。

署名这件事，本身就说明：他已经把自己当成了"这个系统的一部分"。

三、儿童视角独有的"像素级 Bug"

第二条：

字母 g 有点像字母 Q，勾太短了。

这个反馈绝了。

成年工程师测字体、测排版，往往只看视觉逼格、衬线、字重、行高——根本没人会去抠单个字母。

但一个正在学写英文的小孩，会死死盯着那个小写 g。

如果衬线字体（比如 Georgia 或特定英文字体）的弯钩收得太紧、或者笔画偏圆——他写字的时候就会困惑："这到底是 g 还是反过来的 q 还是大写 Q？"

这不是"挑刺"，是"孩子真的在写它"。

这种反馈，只有真实在学英文的孩子才能提出来。任何成年人做用户测试，都测不到这一层——因为你已经"会写"了，你的眼睛会自动补全。

这条反馈的价值，不在于"改一个字"，在于它证明了：这个产品真的在被一个孩子"用着、学着、写着"。

四、代码里已经偷偷修复的"父爱补丁"

如果说前两条是"需求"，那后两条就是**"Bug 报告"**。

而且——父亲已经在代码库里，默默把它们修了。

补丁一：反馈墙的"滚动穿透"

反馈：

打开反馈墙的时候下面的东西在滑动，反馈墙自己没动。

这是一个经典的 "弹窗滚动穿透（Scroll Chaining）" 问题。

翻开源码 src/js/31-feedback.js 第 69-70 行：

function fbOpen() {  
    ...  
    mask.style.display = 'flex';  
    document.documentElement.style.overflow = 'hidden'; // 锁定背景！  
    document.body.style.overflow = 'hidden';            // 锁定背景！  
    ...  
}

父亲在收到这条吐槽后，立刻就给 html 和 body 加上了 overflow: hidden。

弹窗打开时，页面背景再也不会乱滑了。

这就是传说中的"当天提单，当天解决"。

补丁二：从"背景不够漂亮"到一整个新模块

反馈：

背景不够漂亮，优化一下。

然后代码库里就多了一个 32-background.js。

不是改个颜色，不是换个渐变——是新增了一整个模块：

粒子星空——动态的、会流动的背景
自定义背景图片上传——让孩子自己挑图
图片压缩——自动把最长边压到 1920px
自动蒙层——在浅色/深色模式下自动加不同透明度的蒙层，防止看不清字

"背景不够漂亮"这句话，在孩子嘴里可能只有 6 个字；但父亲的回应，是一整个工程模块。

补丁三：一个真实的边缘测试用例

反馈：

文章学习有文字和图片的时候没有带上文字。

这是一个扎扎实实的 边缘测试用例（Edge Case）。

说明孩子不仅在查单词，还在真正拿它来拍照识别英语报纸、做文章精读。

在同时输入文本和图片时，代码优先走了图片模式，而忽略了文本框。

这不是用户"瞎用"，是"真实场景"——真实场景就是图文混着来的。

而成年人设计时，往往会想当然地分"模式 A（纯文本）"和"模式 B（纯图片）"，忘了第三种情况。

是孩子帮他把这个边界补上的。

五、从"反馈墙"看迭代节奏

把四条反馈和四个补丁放在一起，会发现一种极其罕见的迭代节奏：

反馈	类型	修复动作	响应速度
每个词配插图	新功能需求	（待做）	已列入高优先级
`g` 像 `Q`	字体细节	字体优化	当天
滚动穿透	Bug	`31-feedback.js` 加 `overflow: hidden`	当天
背景不够漂亮	体验优化	新增 `32-background.js` 模块	当天
图文混发丢文字	边缘 Bug	修复优先级判断	当天

四条反馈，四条都在动。

而且这里有一个特别值得注意的细节：

反馈墙本身，就是代码库里的一个模块（31-feedback.js）——也就是说，反馈、记录、修复、发布，全都在同一个系统里闭环。

这个系统不仅能"听"，还能"记"，还能"改"。

六、最动人的产品研发闭环

很多大厂天天喊"以用户为中心"，开几百次需求评审会、画几十页交互图——都不如这张反馈墙真实。

因为这张墙上有三样东西，是大厂流程里最稀缺的：

1. 真实的用户

不是"用户画像"，不是"目标人群"——是两个直言不讳、对界面颜值和易用性极其挑剔的小男孩。

2. 最短的反馈链路

用户 → 反馈墙 → 开发者。没有产品经理转译，没有需求文档过滤，没有版本规划延迟。

孩子今天说"背景不够漂亮"，父亲今天晚上就打开终端。

3. 明确的身份

甲方：两个小男孩（Kenny 还认真留下了工号签名）
乙方：一个下班后默默打开终端的父亲

没有 KPI，没有虚伪的汇报，只有"提"和"改"，两个动作在墙上循环。

这哪是一个词典的后台啊——

这是一家人在数字世界里，共同经营一间属于他们自己的奇迹工坊。

七、一个可以延伸的判断

如果把这件事拉远看，会发现它其实回答了一个更根本的问题：

一个软件，怎么才能真正"被使用"？

大厂的答案是：投放、推广、增长、留存。

而这张反馈墙给出的答案是：让用户成为"共同维护者"。

Kenny 署名的那一刻，他就不再是"用户"了——他是这个系统的共建者。

而一个"共建者"提的需求，和"用户"提的需求，质量完全不同：

用户提的是"我希望它更好"
共建者提的是"它这里不对"

前者是愿望，后者是诊断。

这就是为什么这张墙上的四条反馈，每一条都那么准。

八、结语

一张反馈墙，四条留言。

看起来很小。

但它是一个父亲给儿子造的系统，一个孩子给父亲提的需求，两条线在一个数字空间里交汇的地方。

技术会长存，但比技术更长存的——

是这面墙上，那些被认真对待的、歪歪扭扭的、带着签名的字。

（本文基于 KK 词典反馈墙的实际留言与对应代码改动整理。Kenny 是系统的真实用户之一。）