一位做供应链系统售前支持的朋友讲过一件事。客户验收时，仓库主管在系统里试录了十条入库单，用了不到五分钟就合上电脑说："这系统我用不了。"原因很朴素：物料名称那一列，老员工在 Excel 里输入时会弹出联想候选，敲两三个字母就能选中完整名称；而在新系统里，每一行都要从头到尾打全称——几百个物料，名字里全是"高强度""耐腐蚀"这类相似的前缀，打错一个字就是一条脏数据。
这位主管不是抗拒新系统，他是抗拒每天几千次的重复劳动被系统放大了。录入效率这种事，单次只差几秒钟，乘上使用频次，就是完全不同的产品命运。
为什么 Web 表格常常输给一张 Excel
企业软件团队经常遇到一个尴尬的对比：用户一边喊着要上线新系统，一边继续用 Excel 维护着同一份数据。追问下去，理由往往不是功能缺失，而是那些说不出口的顺手细节。
自动完成就是其中之一。Excel 用户对它太熟悉了：在同一列输入过"华东大区"，下一行刚敲出"华"，编辑栏就浮出提示，回车即达。这个机制同时干了两件事——把录入速度提上去，把取值范围收拢住。用户打得快是因为不用打全，数据干净是因为候选本来就来自历史值或字典表。
而许多自研系统的前端表格，恰恰在这一环上是空白。要么只有纯文本输入，要么提供一个几百项的原始下拉框——选项多到需要滚动条翻半天，比手打还慢。于是用户心里有杆秤：Excel 三秒一条，系统十秒一条还容易错。迁移阻力就是这样一点点积累起来的。
有意思的是，这些团队的系统里并不缺"下拉框"这个控件——普通的表单页面到处都是。缺的是它在表格里的那种形态：嵌在单元格中，跟随行与列的节奏，支持键盘连续操作。数据维护的主战场是表格，不是一张张孤立的表单；输入辅助只有长在表格的单元格里，才谈得上承接 Excel 的工作流。
值得强调的是，这不是"锦上添花"级别的体验差异。对高频录入岗位——仓库、客服、财务共享中心、医院挂号站——录入速度直接等于人力成本，错误率直接等于下游返工成本。一个输入框的行为方式，决定了这些岗位愿不愿意用这套系统。
算一笔简单的账就能看清分量。假设一个录入员每天处理三百条记录，每条记录上有五个这类枚举字段；自动完成让每个字段平均省下五秒，一天就是两个多小时。一个五十人的团队，一年下来是几千个工时——而实现这个功能的开发量，通常以天计。企业软件的投入产出分析里，很少有机会遇到杠杆这么明显的细节。
更隐蔽的是信任成本。用户在前十分钟里连续打错三次物料名称、被系统退回三次之后，他对整个系统的评价就已经形成了，后面再多的功能演示都很难扭转。第一印象往往诞生在最普通的输入框里，而不是在领导汇报的驾驶舱大屏上。
SpreadJS 的解法：单元格也能接上成熟的输入组件
SpreadJS 是一款纯前端的 JavaScript 电子表格控件，目标是让浏览器里的表格具备接近 Excel 的交互能力。面对自动完成这类需求，它的思路不是重新发明一套联想算法，而是开放了自定义单元格类型的扩展点：开发者可以接管某个单元格进入编辑状态时的那块输入区域，把业界现成的自动完成组件装进去。
落到体验上就是：双击物料编码列的任意一行，开始输入，候选面板随之浮现，上下键选择、回车确认，与用户在其他成熟软件里的肌肉记忆完全一致。整列统一配置一次即可，不需要逐个单元格设置。
更重要的是配套的约束机制。纯提示挡不住所有越界操作——总有人复制粘贴一个不在字典里的值进来。SpreadJS 的事件体系允许开发者在提交和粘贴这些关键节点上加校验：提交时发现输入不在候选范围内可以拒收；粘贴完成后可以逐格检查并清掉非法值。这样"打得快"和"存得对"是同时成立的，不会为了效率牺牲口径。
工程上还有一层务实的考虑：当字典规模很大时，可以设定触发联想的最小字符数，让用户敲够两三个字母才开始检索匹配，避免一进编辑就生成上千个候选项拖慢页面。这套参数都是可配置的，小字典场景下则可以完全放开，让用户一点开就看到全部选项。
对不同角色意味着什么
对业务负责人，这是迁移账本上一个容易被忽略的减分项：如果新系统的录入效率不如老 Excel，推广成本会远超预算，因为抵触情绪来自每天几千次的真实摩擦。把这类细节补齐，迁移才谈得上平滑。
对产品经理，这是需求清单上应该主动出现的一行。用户很少会提"我要自动完成"，他们只会说"不好用"。识别出哪些列是高频枚举字段、字典有多大、要不要限制自由输入，然后为它们配上合适的输入辅助，这是产品设计的基本功。
对技术决策者，价值在于风险可控：这类能力建立在控件开放的扩展点上，用的是业界通用的组件生态，而不是黑盒定制。团队评估工作量时可以明确知道边界在哪里，不会被"改个输入框"变成三个月排期。
对业务负责人，这是迁移账本上一个容易被忽略的减分项：如果新系统的录入效率不如老 Excel，推广成本会远超预算，因为抵触情绪来自每天几千次的真实摩擦。把这类细节补齐，迁移才谈得上平滑。反过来，一线用户在验收会上说出"这个比 Excel 还顺手"的那一刻，往往就是项目真正落地的时刻。
对产品经理，这是需求清单上应该主动出现的一行。用户很少会提"我要自动完成"，他们只会说"不好用"。识别出哪些列是高频枚举字段、字典有多大、要不要限制自由输入，然后为它们配上合适的输入辅助，这是产品设计的基本功。这类需求不会出现在竞品的功能对比表里，却真实地决定着日常使用体验。
对技术决策者，价值在于风险可控：这类能力建立在控件开放的扩展点上，用的是业界通用的组件生态，而不是黑盒定制。团队评估工作量时可以明确知道边界在哪里，不会被"改个输入框"变成三个月排期。已有的前端投入也能延续——成熟的输入组件生态可以直接复用，不必为表格场景另起炉灶。
当然也有诚实的边界：自动完成适合"范围有限但数量较多"的字段。真正的自由文本（备注、描述）不必套这层壳，而只有三五七个固定取值的字段，普通下拉反而更简单。选对工具的前提还是先看清字段的业务属性。
写在最后
企业系统与 Excel 之间几十年的习惯差距，从来不是靠一份红头文件弥合的，而是靠一个个让老用户点头认可的细节。自动完成只是其中之一，但它恰好站在效率与规范两条线的交点上——做好了，录入的人省力，看报表的人放心。
如果你的项目里也有一张让人想退回 Excel 的录入表，不妨从这样的单元格细节查起。
