玩键盘配列这件事聊再多都不如直接打开 Keyboard Layout Editor键盘布局编辑器圈内昵称 KLE拉一张图来得清楚。它是我做DIY键盘时用得最勤的一个网页工具不用安装、完全免费浏览器打开就能编辑三十秒内就能把脑子里那套古怪配列摆出来还能把结果导出成结构化数据给固件配置、键帽定制、PCB开发当下游依据。很多入坑的朋友把KLE当成“画键盘图的软件”其实它更像一个配列数据编辑器画图只是交互方式真正值钱的是它输出的那份布局文件。这篇文章我会按自己长期使用的路径拆一遍——从坐标规则、核心操作、容易翻车的点到一个完整实例最后聊聊布局文件怎么在项目里落地。无论你是刚接触配列的小白还是准备自己画PCB的老手这份经验都适用。1. 画配列只是表象真正的产出是一份“带属性的JSON数据”1.1 键盘DIY链条里布局编辑器卡在哪一环键盘DIY的完整链条大致是想法 → 配列图 → 开关矩阵 → PCB/固件 → 外壳 → 键帽。每一步之间都需要一份大家都能读懂的“中间文档”而配列图就是这张文档。我在社区里见过太多失败案例有人用Excel格子画配列有人用辅助线对不齐的绘图软件手动画还有人直接在群里发一张拍糊的白板草图。这些东西当讨论草稿没问题一旦要做固件配置或键帽定制就全都不够用了——因为对方需要知道的不是“大概有这几个按键”而是每个开关的中心坐标、每个键帽的有效宽度、每段旋转的具体角度。这些信息用文字和普通图片都说不清偏偏又属于那种“错一个数就全盘返工”的高精度信息。KLE正好卡在“想法”和“工程化”之间。它的核心价值不是让你画出一张好看的键盘图而是让你用一套可复现的规则把配列的物理属性完整表达出来。按键的宽度、高度、横向偏移、纵向偏移、旋转角度、键帽颜色、开关类型全都能写进同一个文件里。这也是为什么很多键盘项目的开源仓库里除了固件源码和PCB工程文件还会特意保留一份KLE导出的json或raw data——它就是配列设计的源文件。1.2 “一个能看的图”和“一份能用的数据”之间的差距普通画图软件和KLE的本质区别在于“能看”和“能用”。你在任意绘图软件里画一个2U空格别人看到的是一张图但固件开发者需要知道的是“这个空格在矩阵里的第几行第几列、它跨越几个开关位、宽度是19.05mm的几倍”。这些信息在KLE里是结构化存在的导出JSON后可以直接被程序解析或人工读校。数据链条大概是这样的KLE JSON → 行列映射表 → 固件里的layout宏或keymap配置KLE JSON → 键帽点位图 → 键帽厂的开模/染色/印刷参考。还有一部分人会拿KLE输出做PCB的初版坐标参考虽然最终肯定要去EDA里重新标注但前期方案阶段的沟通效率会高很多。我用一个生活类比解释KLE就像装修前的户型图墙怎么砌、插座装在哪、家具尺寸多少先标清楚水电工、木工、油漆工才各干各的不会打架。你不画这张图后面每一步都在拍脑袋返工是迟早的事。2. 半小时上手用KLE画一张基础配列要过哪些关2.1 先弄懂画布上的坐标规则打开KLE就是一张浅色网格画布左上角附近是原点所有单位都以“1U”为基础。1U就是标准一元按键的宽度行业惯例约等于19.05mm。不管是字母键、空格、回车尺寸都能用U的倍率表示比如2U就是两倍宽度0.5U就是半格宽度。KLE里最反直觉的一点是坐标系统的偏移量是“相对前一个键”的而不是绝对坐标。你在某一行里写了{x: 0.5}意思是“在刚刚那个键之后再多留半格”而不是“把下一个键放到画布的某个绝对位置”。这个设计在逐行录入时很顺手但也直接导致了很多新手把方向理解反——以为x是绝对值结果键全叠在画布左上角。还有一个容易误解的点KLE里的网格间距默认是紧贴的键与键之间没有额外的物理间隙。你在图上看到的“缝隙”更多是视觉上的边界线。真正做PCB时开关中心距通常是19.05mm的整数倍所以用KLE的U值去推PCB坐标时乘法关系非常直觉1U19.05mm2U38.1mm以此类推。2.2 实际操作的六个动作KLE的操作并不复杂真正要花时间的是那套“文本化”的编辑习惯。鼠标拖拽当然可以但在精确配列面前我更推荐直接操作属性行。以下六个动作是我认为最核心的动作做法关键点添加按键在当前行数组末尾继续写键名每个字符串就是一个按键添加新行新起一个数组数组和数组之间默认向下排列调整键帽宽度/高度在某键前插入带w/h的对象{w:2}表示这个键横跨2U水平/垂直偏移在键前插入带x/y的对象偏移量作用于下一个及后续键整行旋转在行首写r、rx、ryr是角度rx/ry是旋转中心修改配色与标签直接改键帽颜色、文字颜色便于区分功能区举个例子标准一行中想放一个2U左Shift你不需要“画”一个长条只要在Shift这个键之前写上{w:2}然后继续写后面的键名即可。同理想让某行整体往右缩进半格就在该行开头写{x:0.5}。我第一次用KLE时花了很久才意识到“每行是一个数组数组里每个对象只影响后面所有键”这个规则。一旦理解了几乎所有配列都能用这六个动作拼出来。2.3 配色与标签让图纸一眼可读配色不是花架子它至少有三种实际用途。第一是区分功能区比如字母区用一种颜色、拇指键用另一种颜色、旋钮和层切换键再标第三种颜色这样别人扫一眼就能看懂你的设计意图第二是给键帽厂做定制色确认很多键帽厂家会直接按KLE的色卡参考来沟通省去口头描述“大概是一种蓝”的麻烦第三是给自己做设计评审不同的配色方案摆在一起整体观感远比单独看每颗键帽更直观。标签方面我会给每个按键写入它实际的功能名而不是只写位置号。比如Esc、Spc、Fn这些标签导出后会跟着JSON走。虽然最终固件里的键值定义还是在代码里改但KLE阶段把标签写清楚能让矩阵映射表变得非常容易校对。3. 配列设计里的经典雷区以及我踩过坑后的排查思路3.1 旋转键的“圆心”陷阱我第一次做小指列旋转时把7度角度加到整行上结果整排按键哗啦一下飞出画布点哪里都找不回来。我以为是角度数值填错了反复试了5度、10度、15度结果一样按键要么原地癫狂地转要么整体偏移得离谱。排查到最后才发现KLE的旋转是绕某个中心点进行的默认中心点在画布左上角根本不是这一行键自己的中心。角度参数没错错的是圆心。这就是我踩过最深的KLE坑之一而且它几乎不提示任何错误只会默默给你一张“看起来疯了”的图。正确做法是在旋转行里显式声明rx和ry。我会把旋转中心放在这一行第一个键的左上角附近或者放在按键群的中心区域然后再给一个x/y补偿把旋转后的键组拉回预期位置。每次旋转完我会先做一次“整体位置检查”旋转后的键是否还在画布可视区最左边和最下边的按键是否和相邻行对齐如果对不齐优先查中心点而不是继续改角度。3.2 阶梯Caps Lock、ISO回车这类“非标准键”标准配列里最让新手头疼的就是两类非标准键阶梯Caps Lock和ISO回车。阶梯Caps Lock在物理上是一个左低右高、带角度的键帽键帽本身在垂直方向有高低差。但在KLE的二维平面图里它通常被表达成“略微旋转过的1.75U或1.5U键”。问题来了如果只给它一个旋转角度而不提供旋转中心这个键经常会和旁边的Tab、A键叠在一起或者互相打架。我一般的做法是先按标准宽度放好键帽位置再加上轻微角度最后拿x/y微调直到键帽边界看起来不再“咬”到邻键。ISO回车更麻烦。它是一个倒L形的键帽横跨两行KLE没有那种真正的“整块异形键帽”建模能力最接近的表达是用一个键同时设置w和h让它占据2行高度再在它旁边用偏移让下一行的键绕开。这样生成的数据能表达“这里有一个大回车、位置关系如何”但键帽本身真正的轮廓曲线需要靠键帽高度表和实物照片来补充。所以在发图给键帽厂时我会额外注明“ISO Enter物理形态以XX键帽厂数据为准”避免对方直接按平面尺寸开模。3.3 物理间距与视觉间距混为一谈很多人第一次接触KLE都会问x0.5是几毫米答案不是2.5mm而是半个按键单位也就是大约9.5mm。如果你把“两个键之间留0.5mm缝隙”的日常直觉直接代入输入一个x0.5那你得到的不是缝隙而是半个键位宽的间隔视觉上直接空出一个手指位。还有一个我见过很多次的镜像问题。做左右分体键盘时左手小指列旋转了7度右手想镜像成负7度结果两边完全不匹配——因为只改了角度没改旋转中心和偏移方向。正确做法是把旋转中心、x补偿、y补偿全部按镜像关系重新计算而不是简单把角度取反。这里有一条排查链路可以复用先确认是否用了旋转若有先查中心点再看偏移方向是否和旋转方向匹配最后把键帽轮廓和网格线对齐关系调整清楚。顺序错了很容易白费力气。4. 导出数据怎么用从JSON到固件矩阵和键帽定制图4.1 先看懂KLE导出JSON的结构不管你在KLE里画得多么花哨最终能被下游工具使用的核心其实是那一份JSON。KLE导出的JSON结构并不复杂我一般直接看三个部分元信息、每一行的键序列、行内的属性对象。下面这段是我某次做模拟项目X时留下的简化示例格式和KLE的常规导出结构一致[ { name: Left 40 sample, backcolor: #EEEEEE, switchmount: cherry, pcb: false, tags: layout, notes: left hand 40 with encoder }, [Esc, Q, W, E, R, T, {x: 0.5}, Rotary], [ {y: 0.2}, Tab, A, S, D, F, G, {x: 0.5}, P1 ], [ {x: 0.5}, Sft, Z, X, C, V, B, {x: 0.5}, P2 ], [ {x: 0.5, w: 1.25}, Spc, {w: 1.25}, Fn, {w: 1}, Ent ] ]规则其实就两条数组里的字符串代表一个按键数组里的对象代表“从这里开始后面的按键开始采用这些属性”。你不需要背所有字段只要能看出x、y、w、h、r这五个核心属性就已经能读懂绝大多数配列。4.2 把JSON翻译成固件矩阵固件开发里我们真正需要的往往是“矩阵坐标”也就是每个按键在行列扫描网络里的位置而不是它在屏幕上的视觉坐标。KLE画出来的是视觉配列和固件矩阵完全是两回事一个键在视觉上处于第3行第5列不代表它在MCU的扫描矩阵里就一定是第3行第5列。最常用的流程是先把KLE JSON里的每一个键按“视觉行号-视觉列号”编号再根据实际PCB走线重新排布成矩阵坐标。这个映射关系通常用一张表格记录在固件仓库里比如“Esc → 矩阵(0, 0)”、“Q → 矩阵(0, 1)”。如果你用的是QMK、ZMK或KMK这类固件它们都支持以“layout宏”的方式把视觉行映射到物理矩阵行这个宏的生成依据就是你在KLE里确定的视觉顺序。关于“一键转换”我得泼点冷水KLE本身并不直接输出目标固件的矩阵宏网上虽然有些辅助脚本但配列一复杂脚本生成的矩阵往往需要手动修正。我自己的习惯是宁可手工维护映射表也不要贪图一键生成。因为矩阵映射表一旦出错闪固件上去的按键就会“张冠李戴”排查起来比手工维护那几十行映射痛苦得多。4.3 交给键帽厂/渲染者的姿势和键帽厂、渲染师或团队伙伴对接时最好的交付物是“分享链接”或“raw data文本”而不是一张截图。截图丢分辨率而且对方拿不到底层数据没法继续编辑。KLE支持把整个配列编码进一个分享链接里对方打开就能原样看到配列和属性还可以继续拖拽修改。这个特性在社区评审阶段尤其好用别人给你提意见时可以直接在链接上动手改改完再发回来沟通效率极高。如果对方只需要一张图我一般会让浏览器把画布放大到合适尺寸再截图或者直接导出SVG后再转到矢量图。但任何一个做过键帽定制的人都会告诉你最终确认时别只依赖平面图。键帽高度OEM、Cherry、SA、XDA和键帽壁厚都会影响视觉效果这些信息务必在交付时一并标注清楚。5. 完整实例一块左手40%编码器的小配列5.1 先写需求和关键参数光讲原理太抽象这里我用模拟项目X做例子完整走一遍配列设计流程。需求很明确做一块左手半区的小键盘4行字母区右下角放3个拇指键最外侧加一个旋转编码器小指列整体倾斜7度。目标是用它配合右手鼠标工作处理快捷键和数字输入。关键参数我列成了表格区域说明核心参数字母区4行每行5到6列键宽1U为主小指列最左侧一列向掌心方向倾斜旋转角7度拇指区右侧下方3个键1.25U、1.25U、1U旋转编码器最上方右侧独立位置预留1U空间带按键功能行偏移第二、三、四行逐行下移/缩进y方向递增约0.2U之所以这样设计是因为左手半区不需要右侧的标点大键区但拇指区一定要宽裕否则长时间用下来拇指会很累。旋转编码器放在右上角比放在拇指区好用——右手挪过去拧音量时不需要移动整个手掌。5.2 分步搭建过程第一步先搭字母区骨架。我按4行开始写每行先用标准宽度放好Esc、Q、W、E、R、T再往下是Tab、A、S、D、F、G依此类推。这个阶段不需要管旋转和拇指区先把主干立起来。第二步处理小指列旋转。我在第一行最左侧前面插入一个带r的对象并把旋转中心定在这一块键组的中心附近。实际操作中我会先用rx标定旋转中心再通过x补偿把旋转后的键组拉回原位最后反复看网格线确认没有和相邻键重叠。第三步加拇指区。在第四行末尾用x偏移出一段距离然后依次放三个键宽度分别设成1.25U、1.25U和1U。这个组合能保证拇指在下压时不会蹩住也不会误触到旁边的字母键。第四步放编码器。我在第一行最右侧额外留了1U空间用一个单独的键位表示。KLE没法真正画出一个旋钮的物理凸起但我会在标签里写Enc并标明“带按压开关”这样后面做固件时就不会忘记它还有一个按键功能。第五步统一配色和标签。字母区用中性色拇指区用亮色编码器用深色然后逐个检查标签是否清晰。到这一步版面通常已经可以交给别人评审了。5.3 实际调参中的三个小问题这个流程走下来我实际踩到过三个问题。第一个是旋转中心选点不对。刚开始我把rx设在行首结果整行旋转后末尾的编码器位置飞出去老远。后来我把旋转中心挪到小指列的中部再手动补偿x整组键才回到合适位置。第二个问题是编码器占位的视觉误导。KLE上画一个1U的旋钮和旁边1U的字母键看起来一样大但实际旋钮可能会凸出上壳、也可能需要更大的内径。所以我后来会在数据文件和笔记里特别注明这个键不是普通MX开关是编码器孔径按旋钮规格处理别让PCB画板和外壳设计的人看错。第三个问题是坐标换算。KLE的单位网格转PCB毫米坐标时直接乘以19.05还不够因为PCB上的板边、定位孔、螺丝柱都有各自的参考原点。我的习惯是先在KLE里把配列中心点对准画布原点附近的整数位置再到EDA里重新确定板框原点两次换算各做一遍而不是指望一次乘算搞定所有事。6. 编辑器之外的一些经验备份、命名和大步跳到EDA6.1 什么时候不该用它KLE虽然好用但它的边界也很清楚。到了PCB设计阶段我会彻底离开KLE去EDA工具里画封装、摆开关、走线。KLE给出的坐标只能作为初版参考因为PCB上需要的还有不断变化的板框尺寸、螺丝孔位、定位柱、编码器孔径等等这些不是KLE的任务。同样的如果要做外壳3D模型我更推荐直接基于PCB的DXF文件去设计而不是把KLE的截图拖进建模软件。KLE的视觉比例只能用于概念沟通到了结构设计必须用真实尺寸。还有一点如果你只是要在几个配列方案之间做对比列表或表格比图更清晰。图适合单方案精修表格适合多方案横向比较别用错了工具。6.2 布局数据的备份与版本管理我见过很多人辛辛苦苦在KLE里调好一个配列然后直接复制代码发到群里本地什么都不存。下次想改一个键位发现链接过期了或者自己都找不到原文件只能从头再画。我的做法是每一次配列调整都把raw data或JSON存成文本文件文件名用“配列名_日期”的格式例如left40_20240513.json。如果项目进了版本管理系统那就更理想了——JSON是纯文本diff起来非常清楚改了什么键、动了哪个偏移一查便知。这套习惯在团队协作里尤其重要。某次我和A同学协作做分体键盘我们两个人都编辑同一个配列文件如果没有版本管理很容易出现我改了拇指区、他改了旋转角度最后互相覆盖的情况。用了版本管理之后每次合并都能看清双方改动冲突也只在很局部的位置出现。6.3 我的个人习惯做了不少配列之后我现在维护一套配列至少会保证“三个文件”齐全KLE JSON负责视觉配列矩阵映射表负责固件扫描顺序键帽高度表负责说明每个位置用什么高度的键帽。三份文件互相印证缺一份都会在某个环节卡住。最后再分享一个小技巧交付配列前花两分钟把KLE画布里的无名按键全部清一遍顺手把颜色统一到公开色卡值。这个习惯帮我省掉了无数“你那个绿色到底什么绿”的追问。配列设计这事细节都在看不见的地方把源头数据收拾干净后面所有环节都会顺畅得多。