被屏幕砍掉一截的时候：安卓修改大师电脑版的尺寸让位与降级顺序

界面这件事最尴尬的一种情况是：程序本身没有任何 bug，但用户打开它就发现"下面没了"。

按钮在屏幕外、提示条看不到、滚动条都没有。你去问他，他说"你的软件显示不全"；你去自己机器上看，一切正常。因为你们两台机器的屏幕不一样高。

这类问题在笔记本上特别常见。1366×768 的办公本、1920×1080 但缩放调到 150% 的设计本、外接投影仪时临时切到 1024×768 的会议室——每一种都会让"设计时看着正好"的窗口变得不合适。

难的地方不在于"缩小一点"，而在于缩小的顺序。窗口里有顶栏、有内容区、有提示条，还有一个必须和主窗口一样高的AI 改包窗口。屏幕不够高时，这些部分谁先让、谁后让、谁绝对不能让？这个顺序如果没想清楚，缩出来的结果就是"能显示但没法用"。

一、先分清三组数：物理像素、逻辑像素、工作区

"屏幕有多高"这个问题，在有缩放设置的 Windows 上其实有三个答案。分不清这三个，后面所有的算术都会错。

如果配置里写的是 2000，那这个 2000 是逻辑像素。而屏幕只给得出约 1344 逻辑像素的物理空间——2000 比 1344 大，多出来的 656 没有地方放。这就是整个问题的源头。

顺带解释一个很多人困惑的现象：为什么在 100% 缩放的机器上，同一个 2000 的配置可能看着还行？因为那块屏如果纵向是 2160 物理像素、缩放 100%，那 2000 逻辑像素就装得下。同一份配置，两块屏，两种结果——这跟程序好坏无关，纯粹是空间不够。

二、那一刀是谁砍的：不是程序，是系统

这里有个容易误解的地方需要点明：窗口被截短不是程序改的，是 Windows 不允许窗口高过屏幕。

你把一个窗口设成 2000 逻辑像素高，系统会把它压到屏幕能给的高度。这个行为是操作系统的规则，不是应用的选择。实测在 125% 缩放、1680 物理像素高的屏幕上，2000 会被截到约 1362 逻辑像素。

为什么是 1362 而不是上面算的 1344？因为系统允许窗口略高于工作区（可以把任务栏盖住一点），真正的上限比工作区稍高一些。这个差额不重要，重要的是理解它的性质：这是一个"系统说了算"的数，程序只能读，不能改。

所以程序能做的不多：读到实际值、想办法在内部分配这 1362、然后告诉用户发生了什么。这三步里，第二步最难，第三步最容易被省略。

三、一条不能破的硬约束：两窗高度必须相等

这是这件事真正的难点，也是这套工具最鲜明的设计选择之一。

主窗口负责"输入需求"和"看进度"，右侧的 AI 改包窗口负责"改包"。两个窗口并排站着，如果高度不一致，会出现什么？

• 上面或下面会有一截空白，视觉上明显"断了"；
• 用户在两个窗口之间来回看时，视线要上下跳，每次都要重新定位；
• 更实际的：两边内容区的起始位置不同，滚动起来完全对不上，你在这边看到第三段，那边显示的是第五段。

所以这套工具把"两窗高度严格相等"当成硬约束——不是尽量相等，是必须相等。实测在各种截短情况下都成立。

这条约束一旦确立，问题就变得很具体了：主窗口被系统压到 1362，那AI 改包窗口也必须是 1362，不管它自己"想"多高。而这就引出了一个反方向的连锁反应——如果AI 改包窗口自己有高度上限呢？它上不去 1362，那就只能让主窗口降下来陪它。

这就是整套让位逻辑的骨架：高度这条线上，两窗是一条绳，谁被限制，另一个跟着受限。理解这一点，后面所有的"为什么它变矮了"都能自己推出来。

四、让位的第一层不是界面，是那句话

界面被截短之后，绝大多数软件会做什么？什么都不做。它继续按原来的布局画，把底部的控件画在屏幕之外，用户看到的就是"下面没了"。而它自己完全不知道这件事发生了。

这套工具的选择是反过来：界面底部那条提示条不退场，反而先说话。它会告诉你实际高度是多少，然后给出两个解决办法。

这个顺序值得停一下想一想。通常的直觉是"先把界面缩好，缩不好再提示"。但这里的选择是先解释，再让位。为什么？因为"界面被截短"这件事对用户来说是完全无解的——他能看到的只是"你的软件少了东西"，他能想到的动作只有"反馈 bug"或者"卸载"。你不解释，他就永远不知道这是自己机器的高度问题。

而一旦解释了，问题立刻从"你的软件有问题"变成"我的屏幕不够高"，处理方式就出来了：调小、或者让它自动收缩。

第三行为什么更有效？因为它给的不是"可能有问题"这种模糊信息，而是一个可以验证的数字。用户看到"实际高度 1362"，再去自己机器上对一下，立刻就确认了。而"可能显示不全"这种话，用户是无法验证的，只能选择信或不信。

还有一个细节很聪明：说明完之后，提示条不是一直挂着，而是进入"使用技巧轮播"，每 12 秒随机换一条。

为什么这个细节重要？因为如果那条提示常驻，它会变成一个永久的疤痕——用户每次打开都看到"你的屏幕不够高"，看三天就烦了。而变成轮播之后，它只出现一次（有时长刚刚好，够读完），然后让位给别的信息。问题说清了就退场，这本身就是一种尊重。

五、两个办法，各自适合谁

提示条给的两个办法，其实是两种完全不同的思路。选错了会一直别扭，所以值得说清各自的适用场景。

办法一：把 MainHeight 调小

这是"手工适配"。你去 settings.ini 里把 MainHeight 改成一个屏幕装得下的值，比如 1200。

适合：屏幕固定的台式机、专门用来出包的机器。你只在这台机器上用，改一次就一直是那个值，而且你知道自己为什么改成 1200。

不适合：笔记本 + 外接显示器的组合。你在家用外接大屏，白天带回公司用小屏，同一份配置要适配两种高度——那就得每次改，或者每次看着它被截。

办法二：打开 FitToWorkArea

这是"自动适配"。把 FitToWorkArea 设成 true，程序在高度超出屏幕时会自动收缩到可视高度。配置里写的还是 2000，但实际会在需要时降下来。

适合：经常换屏幕的人、多台机器用同一份配置的人、给别人发配置的人（你不知道对方屏幕多高）。

代价：你不再能精确控制高度。如果某天你希望它固定在 1200，这个开关会让它随屏幕变化。

两面都说完，其实有个比较通用的建议：如果你只有一台固定机器，手工调；如果你不止一台，或者不确定将来会在哪台机器上跑，开自动。这个判断标准比"哪个更高级"有用得多——因为这两个选项没有优劣，只有匹配与否。

六、界面上那 1362 怎么分

拿到了实际高度，下一步是在内部把它分掉。这套工具的界面是三段式，每段的"性格"不一样。

这个分工里有一个隐含的判断：让位要让"可再生的"那部分。顶栏和提示条的高度是固定的几十像素，压它们省不下多少，却会造成功能缺失；内容区可以无限压（压到只剩一行也是能用的），而且它的信息本来就可以滚动着看。所以让位只能落在它身上。

这个原则可以推广成一句话：资源不够时，先牺牲"可以滚动查看的东西"，最后才动"必须一直在的东西"。你在做任何界面的时候都可以用这句话检查一遍自己排的优先级对不对。

还有一个隐性的好处：内容区先让，意味着在高度刚好够的临界点上，界面看起来仍然完整——顶栏在、提示条在、Tab 也在，只是中间那块矮了一点。用户不会觉得"缺了什么"，只会觉得"这窗口有点矮"。这是最不容易引起怀疑的失败方式。

七、反方向的连锁：对方窗口也会拉低主窗口

前面讲的是"屏幕压主窗口，主窗口压AI 改包窗口"。但这条链是会反过来的。

有些右侧的程序自带尺寸上限。最典型的是"字符映射表"这类固定布局的老程序——它的最大高度只有 800 物理像素，你让它变高它也不干。

此时那条硬约束就变成了一个难题：右边那个窗口最高只能到 800 物理像素，而主窗口"想"是 1362 逻辑像素。两者必须一样高，怎么办？

答案是主窗口降下来陪它。主窗口会缩到对方能接受的高度，以维持"高度必须一样"这条约束。这不是瑕疵，这是那条硬约束的必然结果。

我特别想强调第三条，因为它是一个典型的归因错误。用户看到的是"我这个窗口变矮了"，于是怀疑主程序有问题；而真正的原因在他没注意的那一侧。凡是"A 跟着 B 变"的设计，出问题时人的第一反应总是怀疑 A。

这条也解释了为什么"硬约束"这种东西必须写进文档。一个约束如果只体现在行为里、不体现在说明里，那它每次发作都会被当成 bug 报一次。而写清之后，它就变成了"我知道会有这个现象，而且我知道怎么办"。

八、为什么"两窗等高"值得当成硬约束

读到这里可能会有人问：既然等高会带来这么多麻烦（对方限制了就得跟着降、屏幕矮了就得跟着矮），为什么不放弃这条约束，让两个窗口各按自己的高度？

这个质疑很合理，值得正面回答。

因为这两个窗口不是"两个窗口"，是"一件事的两个半屏"。用户在左边写需求、在右边看改包过程，视线在两块之间来回移动的频率非常高——高到任何一次上下跳动都会变成负担。等高意味着两边的行是对齐的，眼睛不需要重新找位置。

而放弃等高之后，你会得到什么？右边窗口高一点、左边矮一点，下面是空的。视觉上明显不整齐，而且那个空洞没有任何用处——它不能放东西（因为不属于任何一个窗口），也不能点击。你付出了"视线跳动"的代价，换来一块废掉的区域。

所以这是一个清醒的取舍：宁可在极端情况下让主窗口变小，也不要在所有情况下让两块屏错位。前者是少数情况下的妥协，后者是每一天的磨损。

顺带说，这也是"设计约束"这个词的真实含义。约束不是"限制你自由的东西"，而是你为了某个更重要的性质，主动放弃一部分自由度。等高这条约束保护的是"两块屏是一个整体"这个感觉，它值得为之付出"偶尔变矮"的代价。

九、六条优先级，一条一条看

把前面讲的整理成一份可执行的顺序。这份顺序的意义是：当你遇到"窗口显示不正常"，按这个顺序查，一定能在六步之内找到原因。

这六条里，第一条和第二条是最常见的，加起来能覆盖大部分情况。第五条最容易被忽略——很多人一直以为是屏幕的问题，其实配置里就写了 2000，而他的屏幕从来没装得下过。

第三条听起来小，但真实存在：任务栏在底部还是侧边，会让可用高度差出几十像素。这几十像素有时候刚好就是"提示条看不看得到"的分界。所以"我昨天还好好的，今天就不行了"这类反馈，先问一句"你是不是把任务栏挪过位置"。

第六条值得单独展开，因为它涉及另一套坐标。

十、接两块屏的时候，坐标是谁的坐标

笔记本外接显示器是最常见的组合，也是最容易出坐标问题的地方。原因有两个：一是两块屏的缩放比例可能不同（笔记本 150%、外接屏 100% 是常见搭配），二是两块屏的物理高度也不同。

这套工具在这件事上的两个选择：

选择一：主窗口默认贴在主显示器的左上角。不去猜"用户希望出现在哪块屏上"，而是固定一个可预期的位置。用户如果想去副屏，自己拖过去就好——这个动作的成本很低，而猜错的成本很高（窗口出现在他看不到的那块屏上，等于"打不开"）。

选择二：跨屏时坐标按物理像素对齐。这一条是技术性的，但它的必要性可以用一个现象说明：如果按逻辑像素算，两块缩放不同的屏之间会出现"窗口跳到错误位置"的情况——你拖到副屏，它出现在偏离几十像素的地方；再拖回来，又偏一次。按物理像素对齐之后，窗口在两块屏之间移动时位置是连续的。

支撑这一切的是清单里声明的一行：Per-Monitor V2 DPI 感知。如果不声明这个，程序在缩放不同的两块屏之间移动时会被系统"虚拟化"——系统假装缩放是 100%，然后把它放大，结果是模糊的。声明之后，程序自己负责在每个 DPI 下重画，字就是清晰的。

顺带说一句 DPI 这件事对内容的影响。这套工具里所有界面元素都是矢量画的（图标也是），所以在任何 DPI 下都清晰，不用往程序里塞多套位图。这个选择在"屏幕截短"这个话题里也相关——因为如果用的是位图，一旦为了适配小屏而缩放，图就糊了；矢量的话，缩到多少都还是清楚的。

十一、三个自家场景

前面讲的都是机制。这一节换成实际发生的事，三个场景都是我们自己改包时遇到的，用的都是自家有版权、有权修改的应用。

场景一：在那台 1366×768 的办公本上，确认按钮永远点不到

我们要给一个内部用的小工具加一个"首次启动的引导页"，页面上有个「我知道了」按钮，点了之后不再显示。

以前的做法是自己写布局：几行说明、一张示意图、底部一个按钮。在自己机器上看着挺好，发给同事之后收到一句"点不到"——他那台是 1366×768 的办公本，说明文字换行多了两行，按钮被挤到了屏幕之外，而那个页面没有滚动条。

现在的做法是一句话："这个引导页在矮屏幕上要让按钮始终可见，说明文字放不下就滚动，按钮固定在底部不要跟着滚。"打包完装到设备上，把自己的窗口高度改到很小试一次，按钮还在，说明成了。

怎么验证。三步：正常高度看一次（确认排版没坏）、把窗口压到很矮看一次（确认按钮还在）、把字号调到最大看一次（确认文字不会撑破）。第二步是这次改动的核心——它验证的正是"矮屏幕上按钮不许消失"这条要求。如果第二步的表现是"按钮跟着滚下去了"，那这次改动只做对了一半。

这个场景的教训很具体："按钮必须一直可见"和"内容可以滚动"是两个不同的要求，它们必须分别说出来。你只说"适配小屏"，实现方可能理解成"整体缩小"，也可能理解成"加滚动条"——而这两种做法都不能保证按钮在。

场景二：外接屏拔掉之后，窗口跑到了看不见的地方

这个更常见：白天在公司用外接显示器，窗口放在副屏上；晚上拔掉显示器带回家，打开程序——窗口不在任何一块屏上。因为它记忆的坐标在副屏，而副屏已经不存在了。

以前的做法是靠记忆位置，于是每次拔显示器都要手动"召回"窗口（用任务栏右键、或者 Win+方向键）。现在的做法是让它默认贴主显示器左上角，不记忆跨屏位置。

这个选择的代价是"每次都要重新拖到副屏"，收益是"永远不会打开在看不见的地方"。在这个具体的取舍上，后者显然更重要——因为"打开就能用"是底线，"打开就在我习惯的位置"是优化。底线不能破。

这条也给了一个通用的判断方法：凡是涉及"记忆上一次状态"的功能，都要问一句"如果那个环境已经不在了，会怎样"。记忆窗口位置要问"屏幕变少了"，记忆工作目录要问"那个盘拔了"，记忆默认浏览器要问"它被卸载了"。这三件事的处理原则是一样的：记忆可以有，但必须有一个不依赖记忆的起点。

场景三：给同事发了一份配置，他那台机器上全乱了

我们内部统一过一份 settings.ini，里面 MainHeight 写的是 1300（因为我们的机器是 1440 高的）。发给一位用 1366×768 办公本的同事之后，他那边的窗口底部永远是缺的，而且他以为是软件装坏了。

修法很简单：把那份共享配置里的 FitToWorkArea 改成 true，然后 MainHeight 保留一个大值。这样高性能机器上按大值来，小屏机器上自动降。一份配置适配两种机器。

这件事的教训是：只要一份配置会被用在不止一台机器上，里面就不能有"只有我这儿成立"的值。高度、宽度、绝对路径、盘符——都属于这一类。判断方法很土但有效：闭上眼想一遍"这份文件如果发到一个我完全不了解的机器上，哪几个值会不成立"。

十二、一份可以抄走的适配清单

如果你自己在做界面（不管是用这套工具改包，还是在写别的程序），这六条值得过一遍。它们的共同点是：每一条都能在十分钟内验证，而漏掉任何一条都可能在别人机器上变成"你的软件有问题"。

六条里，第五条有个很实用的替代方案：你不需要真的有第二块屏。把窗口手动拖到很矮，效果和"小屏"几乎一样——因为所有这些问题最终都归结为"可用空间变少了"。而"空间变少"这件事，你在自己机器上随时可以模拟。

回头再看这六条，会发现它们几乎都不需要技术。压窗口、调缩放、把内容塞多、拖到很矮——全是两三下就能做的事。它们唯一的门槛是"想不想得到要做"。而这恰恰是这类问题最典型的特征：解决成本极低，发现成本极高。所以它值得被写成一张单子，贴在你看得见的地方。

还有一点：这六条不只适用于"你自己做的界面"。你交给别人的包，界面也是被别人看的——同一套检查照样适用，只是主体从"程序"变成了"包里的那套布局"。

十三、这套思路里能搬走的三件事

"尺寸让位"听起来是个很窄的工程话题，但它背后有三个东西跟改包这件事也直接相关。

第一件：约束要写出来，不要留在行为里。这套工具把"两窗必须等高"写进了文档，连"对方有高度上限时主窗口会跟着变小"这种细节都写了。为什么值得写？因为不写的话，每次发作都会被当成 bug 报一次。而写了之后，它变成了"已知现象 + 已知解法"。

这一条在你的需求里同样成立。"除了这几处，别的都不许动"这句话看着像废话，但它是把隐含约束写出来的唯一方式。你不写，实现方就按自己的理解扩展范围；你写了，超出范围的改动就是明确的问题。

第二件：让位要有顺序，不能"一起缩"。界面高度不够时，顶栏和提示条不让、内容区先让。这个顺序不是随意排的，它依据的是"这个部分可不可以被压缩"。

你在写需求的时候也可以用这个思路：当一句话里有多个要求，而它们可能冲突时，提前排好优先级。比如"字要大一点，但按钮别变宽"——这两件事在窄按钮上是冲突的，你不说清哪个优先，实现方只能猜，猜错就要返工一轮。

第三件：状态变了要说，不要静默适配。被截短的时候提示条会说明实际高度。这个动作的成本很低（一句话），但它决定了用户是"知道发生了什么"还是"觉得软件坏了"。

改包也一样。如果一个改动有副作用（比如某个页面变长了、某个按钮位置挪了），在交付的时候就该说一句。不说，对方会把它当成新出现的问题；说了，它就是"这次改动的已知影响"。

十三之二、为什么不是"全部加滚动条"就完了

有人会想到一个更简单的解法：既然高度不够，那就让整个窗口内容可以滚动，滚一滚就都能看到。为什么不做成这样？

因为窗口本身不能被滚动。窗口是操作系统管的，它的边框、顶栏、缩放柄都属于系统那一层，不是一个可以"滚上去"的容器。你能滚的只有窗口内部的内容区，而这个前提是窗口自己已经完整地站在屏幕上了。

换句话说："加滚动条"解决的是"内容太多"，不是"窗口太大"。这两件事看着像，其实是两个层面的问题。内容太多是应用自己可以处理的；窗口太大是系统和屏幕共同决定的，应用只能接受。

这也解释了为什么提示条要给的是"改配置"而不是"滚一下"。因为前者作用于窗口这一层，后者作用于内容这一层——而问题出在前者。

这个区分在别的地方也用得上：遇到"显示不下"的时候，先判断是哪一层不够。是容器不够（那就得改容器尺寸），还是内容太多（那就滚动或折叠）。判断错了层，做多少调整都不会有效——因为你在一个用不上的地方使劲。

顺带说，这也是这类"窄而高"的竖条窗口为什么不做最大化的原因之一。最大化能让窗口变宽，但高度还是屏幕那么高，问题一点没解决，反而把右侧本该留给AI 改包窗口的空间吃掉了。一个功能如果解决不了它声称要解决的问题，那它就不该存在。

十四、十一个提问

问一：我怎么知道自己的窗口被截短了？两个信号：一是底部有元素看不见（按钮、提示条），二是提示条上出现了实际高度的说明。如果两个都没有但你觉得不对，去 settings.ini 看 MainHeight 是不是比屏幕还大。

问二：为什么不能自动缩放到刚好装下？因为整体缩放会让字和点击区一起变小，在笔记本上反而更难用。现在的做法是"按原尺寸画、切掉超出的部分"，至少以上部分是清晰的。

问三：FitToWorkArea 打开之后，我设的 MainHeight 还有用吗？有用，它是"想要的高度"。屏幕装得下就按它来，装不下才降。相当于一个上限而不是一个定值。

问四：为什么我改了配置没生效？先确认改的是程序目录下那份 settings.ini，然后重启程序——这类配置是启动时读的，改完不重启不会生效。

问五：主窗口突然变矮了，是不是中病毒了？先看右边那个AI 改包窗口。如果它自己有高度上限，主窗口是被它拉下来的。换一个右侧的程序试一次就能确认。

问六：能不能只让主窗口高、右边矮？不能，这是设计上明确拒绝的。两块屏错位带来的视线跳动是每天都发生的磨损，而"偶尔变矮"是少数情况下的妥协。

问七：提示条上那条说明能关掉吗？它说明完就自动进入技巧轮播了，不会一直挂着。如果你觉得轮播也烦，那是另一个设置的事，但"被截短"这条说明只出现一次。

问八：我在 4K 屏上把缩放调到 200%，会怎样？逻辑像素会变成物理的一半，所以一个 2160 物理高的屏只剩约 1080 逻辑高。此时 2000 的配置一定会被截，建议直接开 FitToWorkArea。

问九：多显示器下窗口跑到副屏了，怎么弄回来？它默认贴主显示器左上角，所以正常情况下不会跑。如果是你手动拖过去的，拖回来就行；如果拔掉副屏后找不到了，用任务栏右键"移动"再用方向键拉回来。

问十：这些尺寸问题会影响改包结果吗？不会。打包用的是固定流程和固定参数，跟窗口多大无关。它影响的只是"你能不能舒服地操作"。但这一条也不能小看——看不见按钮就等于不能用。

问十一：为什么要把这些限制写进文档？因为一个约束如果只体现在行为里、不体现在说明里，它每次发作都会被当成 bug 报一次。写清之后，它就从"故障"变成了"已知现象"——这两者消耗的信任完全不是一个量级。

问十二：我把窗口拖大了，超过屏幕，会自动缩回来吗？系统会拦住它，不允许窗口高过屏幕。所以你拖到某个位置之后会发现"拖不动了"，那不是卡了，是到上限了。宽度没有这个限制，可以拖得比屏幕宽——但那就跑到屏幕外去了，需要自己拉回来。

问十三：为什么右侧窗口的高度必须和我这边一样，不能它自己定？因为两块屏是一个整体。高度不一样会在下方留出一块没有用的空白，而且两边的内容起点不同，视线来回时要重新定位。这条约束保护的是"读起来不费劲"，代价是"偶尔一起变矮"。

十三个问题问完，其实可以合成一句，而且这一句能覆盖上面全部：凡是"我的窗口怎么不对了"，先去找"哪个东西在限制它"。屏幕、缩放、任务栏、右边那个窗口、配置文件——五个候选里必有一个。找对了，改一个值就好；找错了，改十个值也没用。而"找对"的前提，是你知道这五个候选都存在——文档的价值就在这里，它把候选名单摊开给你看。

十五、他们被"下面没了"坑过

十六、写在最后：让位是一种诚实

"窗口被截短"这件事，本质上是一个无法解决的问题：用户的屏幕就是那么高，你不能变出空间来。

面对这种无解的问题，软件通常有三种态度：

第一种是装作没发生。照原样画，超出的部分画在屏幕外，用户自己承担后果。这是最常见的，因为最省事。

第二种是拼命适配。想尽办法把一切都缩进去——等比缩小、字号变小、间距压缩。结果是"能看了但不好用"，在笔记本上尤其糟。

第三种是承认限制、排好顺序、把话说清。哪些部分绝对不让、哪些先让、让了多少告诉你、你可以怎么改。

这套工具选的是第三种。它没有假装自己能适配所有屏幕，也没有为了让画面好看而牺牲可用性——它只是把"我做不到"这件事说得足够清楚，清楚到你还能继续用下去。

这种态度放到改包上也一样。你改完一个包交给别人，总有一些地方是你做不到的（某个界面结构太复杂、某个第三方库改不动、某台老设备就是不兼容）。把它们说清楚，比假装没有要值钱得多。因为说清楚了，对方能提前安排；不说，他就只能在踩到的时候回头找你——而那时候双方的心情都不会好。

只需说话，就能让应用变成你想要的样子。这句承诺的边界感其实很清楚：它管的是"把你的意思变成改动"，管不了"你的屏幕有多高"。但它至少会在屏幕不够高的时候，先告诉你一声。

安卓修改大师智改工坊的产品页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。它替你省掉的是查文件、改布局、重打包这些机械的事，留下的是"你想要什么"和"你怎么知道成了"——这两件事，从来没有人能替你做。

---