设计也能改包：电脑版把视觉需求变成可安装成品

一、视觉稿到安装包，中间隔着的不只是“导出”

做设计的人大概都遇到过这种场面：品牌升级的方案已经定稿，标志的圆角半径讨论了三轮，主色从去年的橘调换成了更克制的墨绿，启动页的构图也在评审会上顺利通过。可当有人问“手机上什么时候能看到”，话题立刻转向排期、工具链和“谁来打包”。设计师手里握着最完整的视觉资产，却离最终那块屏幕最远。

原因不复杂：一个 APK 里的视觉资产并不集中。桌面图标在多个密度目录里各有一份，启动页可能同时存在普通位图与九宫格拉伸图，主题色牵动状态栏、按钮、选中态和悬浮控件，文案则散落在字符串资源里。任何一处漏改，装到手机上就是“看着有点怪”，但很难用一句话指出问题到底出在哪。更麻烦的是，这些问题往往要等到装包之后才暴露，改一轮、等一轮，节奏就被拖散了。

过去要在设计评审后看到真机效果，通常有两条路。第一条是把切图、色值、文案整理成清单发给开发，等一个版本窗口；第二条是自己装一套反编译工具链，学目录结构、学命令行、学签名。前者牺牲节奏，后者牺牲精力。对独立设计师、两三个人的小团队、以及同时维护多个品牌包的乙方来说，这两条路都不便宜，而且都很容易在“最后一公里”反复返工。

这篇文章想说的不是“设计师不用懂开发”，而是“视觉层面的重复劳动，可以换一种交付方式”。业务逻辑、性能、架构、数据安全，仍然应该由开发负责，这一点没什么可争议的；但改一个图标、换一张启动图、调一组品牌色、统一一次应用名，本来就不该占用一个完整的开发排期。把这类需求从排期里拿出来，交给能听懂人话的工具，开发也能把时间花在更值得的地方。

设计稿是提案，安装包才是交付。能让提案自己走到手机上，节奏就回到了设计师手里。

需要说明的是，“把改包交给工具”并不等于把设计判断也交出去。工具能替你完成目录替换、资源重编、签名打包这些确定性工作，但一张启动图该在什么位置收住、品牌色在深色底上要不要降饱和、图标缩到 48 像素还认不认得出，这些仍然只能由做视觉的人判断。工具降低的是操作门槛，不是审美门槛；它让判断更快得到验证，而不是替你判断。想清楚这一点，后面的流程才不会跑偏。

二、智能修改电脑版：把改包变成一段可以复述的话

智能修改电脑版是安卓修改大师智改工坊面向 Windows 的改包工具，支持 Windows 10/11 64 位系统，需要 .NET Framework 4.6.2 及以上，安装包约 6.86 MB。它的工作方式很直接：把一个 APK 拖进窗口，在详情页写下需求，右侧的 AI 工作区开始执行，改完自动回编、对齐、签名，再把成品装到手机或模拟器上。整个过程不需要打开 Android Studio，也不需要手写构建脚本。

导入格式覆盖 APK、JAR、APKS、XAPK、APKM 与 CLASS。设计师日常用得最多的是单个 APK；如果拿到的是应用市场下载的分包，APKS 或 XAPK 也能直接导入，工具会按包结构处理。对品牌换肤这种需求来说，单个 APK 最省事，因为它的资源都在一个文件里，改完就是最终成品，不存在再合并分包的步骤。

详情页内置了 3000 条话术，分 6 类、每类 500 条：界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。设计师最常用的是“界面美化”这一类，点一下就把一句结构完整的话填进输入框，再按自己的项目改尺寸、色值和边界。话术库的价值不是替你思考，而是给你一个不会漏项的句式骨架，尤其适合第一次写改包需求的人。

主窗口和 AI 工作区默认左右并排，两窗高度一致；AI 工作区的宽度按屏幕工作区宽乘以占比，再减去间隙和主窗宽计算。拖动时以 5 毫秒轮询，静止超过设定的吸附延迟才算用户操作，被拖走约 260 毫秒会自动吸回。对设计师的实际意义很朴素：左边可以放参考图、素材清单或验收标准，右边看 AI 一条条执行，视线不用在两个窗口之间来回切。

举个具体的使用场景：左边主窗口停在详情页，放素材清单和验收表；右边工作区看执行进度。磁吸会自动把两窗对齐、高度保持一致，被拖走二百多毫秒就吸回去。这个细节听起来像锦上添花，用起来却会明显减少“窗口挡住参考图、切回来、再切过去”的来回。设计工作很依赖对照，能同时看到“我要的”和“正在改的”，判断会快很多，也不容易漏掉需求里写过的某一项。

工具本身还提供了 10 套界面配色：极夜蓝、深海蓝、紫罗兰、樱花粉、烈焰红、落日橙、古铜金、青柠绿、薄荷绿、石墨灰，可以在参数设置里切换。它换的是工作台的颜色，不会影响你正在改的应用。长时间对着屏幕做像素级对照，选一个不刺眼的深色主题，眼睛会舒服一些；这不是功能，但对每天要坐几个小时的人来说，算是一个体贴的细节。

每个项目会在工作目录下建一个 8 位随机名的目录，写入 config.ini 与 history.ini，并把原始安装包复制成 source.apk。反编译结果放在 apktool 子目录，日志写在 apktool.log。source.apk 的存在意味着你随时可以回到原始包，改坏了不用重新找文件，也不必担心把唯一一份素材弄丢。

三、拖入 APK 的第一秒：aapt 已经在读你的图标

APK 拖进窗口后，第一件事不是改，而是读。工具调用 aapt 解析安装包，读出应用图标、应用名、包名、版本号、目标 SDK 和启动页对应的 Activity。这些信息会显示在详情页，也是后面写需求时的坐标。对设计师来说，这一屏信息很值得多看两眼：应用名是不是你预期的那个、启动页有没有指到你想要的那一页、图标当前取的是哪一档，都会影响后面的结果。

图标这一项有个容易被忽略的细节：一个包里往往同时存在 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 多份图标，aapt 会取最高密度的原图来展示和替换。判断“最高密度”不能简单按目录名或者数值大小排序，因为 aapt 里的 65534 是“任意密度”的哨兵值，它不是最高档，而是“不限定密度”。如果机械地按数值排序，会把这个哨兵当成最高密度，结果拿到的可能是一张矢量描述或占位图，换上去自然不对。

密度档位	目录名	桌面图标建议像素	常见设备
mdpi	mipmap-mdpi	48×48	老旧低分屏，现已少见
hdpi	mipmap-hdpi	72×72	早期 720p 设备
xhdpi	mipmap-xhdpi	96×96	1080p 主流机型
xxhdpi	mipmap-xxhdpi	144×144	高刷旗舰、折叠屏外屏
xxxhdpi	mipmap-xxxhdpi	192×192	2K 屏、平板

这张表的作用不是让你去背像素值，而是让你在交素材时有一个明确的下限。最稳妥的做法是准备一张 1024×1024 的透明底源图，让工具按目标包的实际密度去缩放；如果源图本身只有 48 像素，放大到 192 只会更糊，边缘的锯齿和渐变断层一上真机就藏不住。品牌升级时尤其要注意，新标志的细节（比如极细的描边、很小的负空间）在 48 像素下会糊成一团，必要时应该单独做一版简化图标。

反编译的速度比想象中快。12 MB 左右的包实测约 3 秒；如果超过 10 分钟还没有结果，工具会中断并报错，不会让你对着进度条干等。这个上限对设计师其实是个提醒：体积特别大、加固特别重的包，可能不适合直接在工作流里反复试改，先确认包的来源和结构，再决定要不要在这个包上做视觉迭代。

如果详情页读出来的应用名或启动页跟你预期不一致，先别急着改。常见原因是包里存在多个入口 Activity，或者应用名走了多语言资源，当前系统语言下显示的是另一套文案。这时候正确的做法是在需求里指明“以中文简体资源为准”，而不是笼统地说“改应用名”。读得准，后面才改得准；读错了就改，等于在错误的地基上刷墙。真遇到拿不准的入口，可以先在手机上打开应用，看看实际是从哪个页面进来的，再回去对照详情页的信息。

四、需求四要素：对象、尺寸、风格、边界

很多人第一次用 AI 改包，写的第一句话是“把界面做得高级一点”。这句话对人来说都很难执行，对工具更不可能。AI 不是读心术，它只能根据你给出的对象、尺寸、风格和边界去推断，信息越模糊，结果越接近“平均值”，而“平均值”通常不是设计师想要的东西。写需求这件事，本质上是把脑子里的验收标准翻译成可执行的描述。

我把设计师常用的需求拆成四个要素，缺一个都容易返工：对象是改哪里，尺寸是做多大、适配到哪，风格是色值、圆角、留白和字体，边界是哪些东西不能动。四样写齐，一段话就够了；四样缺两样，后面就得靠一轮轮试。

要素	要写清什么	常见反例	推荐写法
对象	改哪个页面、哪个资源	“界面弄好看点”	只改桌面图标、启动页、主题色，登录页和业务逻辑不动
尺寸	目标尺寸与适配范围	“按图做就行”	图标五档全换，启动图 1080×1920 居中，允许上下裁切
风格	色值、圆角、留白、字重	“高级一点、简洁一点”	主色 #0E5A46，浅底 #E9F3EE，圆角 22dp，标题加粗
边界	不动的部分与验收口径	“随便改，好看就行”	不改包名、版本号、权限；保留深色模式；启动流程不换

把四要素串起来，一段需求就会长成这样：

这次只做品牌视觉替换，不改任何业务逻辑和权限。桌面图标换成附件 1，五档密度都要换，主体居中、四周留 10% 安全边；启动页换成附件 2，1080×1920，上下可裁切；主题色按附件 3 的色板，主色 #0E5A46、强调色 #C9A227；应用名改为“青屿手作 内测版”；应用内标题字号保持原样，不要加阴影和描边。改完请保留深色模式下的可读性。

—— 这段可以直接粘进详情页，再按实际素材编号调整

写完不用急着点执行。详情页右侧的 AI 工作区会显示当前任务，点“立刻修改”后，需求原文和日期会写进 history.ini，文本被送进工作区执行。AI 完成后会在项目目录留一个完成标记，主窗口每 2 秒轮询一次，读到就把标记删掉，等待上限是 1 小时。这个机制的好处是你能清楚地知道“改完了没有”，而不是靠猜。

如果不想从零组织语言，可以先用 3000 条话术里的句子打底。点选之后文字会填进输入框，你再把“界面”“图标”这类泛称替换成具体的资源名、把笼统的“好看”替换成色值和尺寸。话术是脚手架，不是模板答案；真正决定成品质量的，还是四要素写得够不够具体。

历史记录也值得用起来。详情页的历史按时间倒序排列，保留完整原文，右侧有“选择”按钮可以一键回填。做系列改版时，这套历史相当于你的需求版本库：上一版写了什么、这一版改了哪个色值、客户第几轮提了什么意见，翻一翻就能对上，不用再去聊天记录里找。

还有一个实用建议：一次只改一类东西。图标、启动页、主题色、文案全塞进一段需求，看似高效，实际一旦结果不对，很难判断是哪一句引起的。更稳的节奏是先改图标和应用名，装机确认；再改启动页和主题色，再确认。每轮都短，回退成本低，历史记录也更清楚。改包不是考试，不需要一次交卷；把变化拆小，反而更容易拿到想要的结果。

五、附件不是“顺手拖几张图”，每张都要有一句说明

做品牌项目的人有个共同习惯：素材整理好，一股脑发过去就完事。在改包这件事上，这个习惯要改一改。附件系统并不是简单的文件传输，它要求每个文件都配一句用途说明，因为工具需要知道这张图是桌面图标、启动页背景，还是给 AI 参考的风格板。没有说明的图片，对执行方来说就是一张没有坐标的图，放到哪里都可能是错的。

具体的规则是这样的：附件可以一次多选，但每个文件都必须写用途，且不少于 10 个字；提交时会校验文件是否存在、是不是目录、是不是 0 字节、能不能读取。校验通过后，附件会按“序号 + 路径 + 说明”的格式拼进需求里，一起发给 AI。注意，历史记录里只保留用户自己写的原话，附件的路径和说明不会混进历史文本，这一点对后续复用需求很友好。

素材	建议规格	说明至少写清	示例
桌面图标	1024×1024 PNG，透明底，主体留 10% 安全边	用途、位置、是否含文字	新版品牌图标，用于桌面和设置页，已去掉外描边
启动页	1080×1920 或 1242×2688，主体居中	裁切方式、深色版本、对应页面	冷启动第一屏背景，主体居中，上下允许裁切
色板	PNG 色卡 + 文字 HEX 值	每个颜色对应什么角色	#0E5A46 主色，#E9F3EE 浅底，#C9A227 强调
字体	字体文件或授权说明	授权范围、使用位置	仅用于自家应用内标题，已购商用授权，不随包分发

命名也值得花两分钟。把文件叫“icon_brand_v3_1024.png”“splash_home_1080x1920.png”“palette_brand_v3.png”，比“未命名-3.png”“截图 2026-10-21.png”强太多。理由很现实：附件是按序号拼进需求的，当一屏里出现四个“微信图片”，你自己也分不清哪张是给 AI 的参考、哪张是最终素材。命名清楚，说明就能写短，写短了反而不容易漏信息。

色值尽量不要只放在图片里。色卡图片对人是直观的，对执行方来说却需要再从像素里取色，中间可能因为色彩配置、压缩、抗锯齿产生偏差。最稳的做法是图片照给，同时在需求文字里列出 HEX 值，并写清每个颜色用在哪：主色用于标题和主要按钮，浅底用于卡片背景，强调色用于价格和徽标。颜色一旦带上角色，执行时就不容易张冠李戴。

字体是另一个需要提前想清楚的素材。很多品牌字体只授权了平面物料，并没有授权嵌入应用；把字体文件直接打进 APK 之前，先确认授权范围。如果授权不允许，就退一步，用系统自带字体加字重、字距来接近视觉效果，或者只把品牌字体用在启动页这类图片化的位置。这不是技术问题，是合规问题，越早确认越省事。

附件数量建议控制在一次四到六个。太少，需求描述会变得很长；太多，主次容易乱。一个典型的品牌换肤需求，四个附件就够：图标源图、启动页、色板、应用名文案截图。如果还要换引导页插画，再加一到两张，并在说明里写清顺序和使用场景。附件不是越多越好，清晰比齐全重要。

还要区分“参考图”和“最终素材”。参考图是给执行方理解风格的，比如一张竞品截图、一张情绪板；最终素材是要真的放进包里的文件。两者混在一起，很容易出现“把参考图当成图标换上去”的事故。建议在说明里明确写“以下为最终素材，请直接替换”或“以下仅作风格参考，不要放入应用”，一句话就能把边界划清。

附件校验失败通常有三个原因：路径里有异常空格导致读取失败、选中的是文件夹而不是文件、图片是 0 字节的占位文件。前两个改一下选择方式就好，第三个往往是从聊天软件里“另存为”时没下载完。遇到提示不要反复重试，先回到文件夹里确认文件大小和能不能正常打开，再重新添加。这个习惯能省掉很多“明明选了却没生效”的困惑，也能避免把时间浪费在无意义的重复提交上。

六、实例一：自家 App 品牌换肤，从半天到一杯咖啡

说一个具体的。我们自己的品牌展示类应用“青屿手作”，原本用的是旧标志：圆角方形底、橘色渐变、中间一个手写体的“青”字。品牌升级后，新标志改成了墨绿底、留白更大的印章造型，主色从 #E86A33 换成 #0E5A46，强调色是 #C9A227。应用本身是自家的，代码和素材都在手里，这次要做的只是视觉替换：换图标、换应用名、换主题色、换启动页。业务逻辑不动，权限不动，包名不动。

以前：一条命令一条命令地走

以前的做法是先反编译，进 res 目录翻 mipmap-mdpi 到 mipmap-xxxhdpi 五个文件夹，把 icon.png 一张张替换掉；再去 values 里找颜色定义，改主色和强调色；应用名在字符串资源里，得找到对应的键再改；启动页要看它是普通位图还是九宫格，九宫格还要保留拉伸边距。改完重新打包，对齐，签名，装到测试机上，一台一台看。整个过程顺利的话四十分钟，遇到九宫格拉伸错位、或者某个界面写死了颜色，就得再来一轮。

最耗神的不是操作，而是“确认有没有漏”。五个密度目录、几个颜色键、两处应用名（桌面显示名和应用内标题）、启动页的深色版本，任何一处忘了，装到手机上就是半新半旧。设计师自己动手，常常要在命令行和设计软件之间来回切换；交给开发，又要等排期。品牌换肤这种“看起来只是换皮”的活，实际沟通成本并不低。

现在：四个附件、一段话、一次等待

换成智能修改电脑版之后，流程压缩成了几步。第一步，把自家应用的 APK 拖进窗口，等 aapt 读完信息，确认包名、版本、启动页都对。第二步，在详情页写需求，把四要素写齐：对象是图标、启动页、主题色、应用名；尺寸是图标五档全换、启动图 1080×1920；风格是墨绿主色加金色强调、圆角 22dp；边界是不动包名、版本号、权限和业务逻辑。第三步，把四个附件拖进去，每个写一句不少于 10 字的用途说明。第四步，点“立刻修改”，等右侧工作区跑完，主窗口读到完成标记后自动进入回编、对齐、签名，再把成品装到手机上。

这次从拖入到手机亮起新图标，一共二十多分钟，其中大部分时间是在等打包和安装，人不用盯着。第二轮客户提了一个小意见：图标在深色桌面上边缘偏暗，希望加一圈极细的浅色描边。只改了一个附件和一句说明，再跑一次，几分钟就出了新包。以前这种“一句话的微调”，往往要重新走一遍完整流程，现在它真的只是一句话的事。

有个现象要提前知道：换完图标后，部分启动器会缓存旧图标，装完短时间内桌面还是旧的。这不是没改成功，清理启动器缓存或者重启一次桌面就会刷新。验收时最好先强制停止应用、再回桌面看，必要时换一个启动器交叉确认。把这条写进验收说明，能避免很多“改了但没变”的误会；对不太熟悉安卓机制的设计师来说，这也是一个值得记住的小知识。

验证：六个位置逐一对照

• 桌面图标：默认启动器和第三方启动器各看一次，确认没有被自动加白底或裁成圆形。
• 应用名：桌面、最近任务、设置里的应用信息三处一致，后缀“内测版”没有丢。
• 启动页：冷启动第一屏完整显示，主体没有被状态栏遮住，上下裁切后构图仍然成立。
• 主题色：标题、主按钮、选中态、悬浮按钮四处颜色统一，没有残留旧橘色。
• 深色模式：切到深色后文字对比度足够，卡片没有出现“深底深字”。
• 签名：用 apksigner verify --print-certs 复核证书，确认装上去的确实是这次签的包。

还有一个容易被忽略的验证动作：装完之后用 dumpsys 看一眼当前前台应用，确认拉起来的是新包而不是系统缓存里的旧版本。有时候图标已经变了，点开却还是旧界面，多半是安装没有真正覆盖，或者启动的是另一个入口。把这一步加进验收清单，能省掉很多“明明改了却没生效”的争执。

品牌换肤的难点从来不是“会不会改”，而是“改完有没有漏、漏了能不能马上发现”。把验证清单固定下来，返工次数会肉眼可见地下降。

七、实例二：自家活动页启动图，三天换五版

第二个例子更贴近日常。自家电商应用每逢节点要做活动，活动页是自家站点，启动图也要跟着换：今天是预热，明天是开场，后天是返场，每版的主视觉、文案、色调都不一样。以前这种需求最尴尬，改动量只有一张图，但流程一点不少。找开发排期不现实，自己动手又得把整套工具链再走一遍，三天换五版几乎是奢望。

以前：一张图也要走完整条流水线

原来的做法是：先从活动主视觉里导出 1080×1920 的启动图，确认主体在安全区内；然后反编译自家 APK，找到启动页对应的图片资源，替换；接着重新打包、对齐、签名；最后 adb 安装到测试机，冷启动看效果。如果启动图同时存在普通版和夜间版，还要各替换一次。一版下来二十到三十分钟，五版就是小半天，而且每版都要重复同样的机械动作，出错概率随着次数上升。

更麻烦的是版本管理。五版图、五个安装包、五条聊天记录，最后自己也分不清手机上装的是哪一版。命名稍微随意一点，就会出现“我以为装的是返场版，其实还是预热版”的乌龙，验收时对着截图争论半天。

现在：只改一张图，其余明确不动

用智能修改电脑版之后，这类需求的写法反而要更克制。需求里第一句就写“只替换启动页背景图，其他资源、文案、逻辑一律不动”，然后给附件：活动启动图 1080×1920，说明写清“冷启动第一屏背景，主体居中，上下允许裁切，深色模式使用同一张”。点执行，等完成标记，自动回编签名装机，冷启动看一眼，收工。

第二版、第三版依此类推，只需要换附件、改一句日期和活动名，历史记录里点“选择”回填，再改两个字就行。五版下来，真正花在操作上的时间不到一小时，剩下的时间都用在设计本身：构图、文案层级、色调和活动氛围的匹配。对设计师来说，这才是时间应该花的地方。

版本多的时候，命名比记忆可靠。建议把安装包按“日期_活动名_版本号”保存，附件也照同样的规则命名，需求里写清这一版对应哪个活动节点。智能修改电脑版的项目目录本身会保留 source.apk 和日志，配合 history.ini 里的需求原文，基本能做到每一版都能还原。真出问题时，不用靠聊天记录回忆当时写了什么，翻一下项目目录就知道。

边界也要写死在需求里。“只替换启动页背景”这句话不够，最好补一句“不改启动流程、不改活动页地址、不改权限、不改版本号”。视觉需求最怕顺手改逻辑，尤其是 AI 执行时如果发现旁边还有可以“优化”的地方，边界不清就容易越界。你把不能动的部分列出来，执行范围就收窄了，验收也更有依据。

验证：冷启动、热启动和裁切

启动图的验收有自己的门道。第一，要区分冷启动和热启动：冷启动才会完整走启动页，热启动通常直接回到原页面，拿热启动判断启动图有没有换，很容易误判。第二，Android 12 及以上系统有自己的启动画面机制，应用图标和背景色会参与系统层的展示，如果只换了应用内的启动图，系统那一层可能还是旧背景，验收时要把两个阶段分开看。第三，不同比例的屏幕裁切结果不同，18:9、19.5:9、20:9 各看一台，确认主体没有被切掉。

还有两个细节值得写进清单：启动耗时有没有明显变化（可以用 am start -W 看总耗时），以及启动图之后的第一屏是不是原来的活动页。前者关系到体验，后者关系到“只改视觉”的边界有没有被破坏。五版跑下来，最直观的感受不是快，而是每一版都可追溯：哪个附件、哪句需求、哪次打包，日志里都能对上。

八、深色模式与多分辨率：验收时最容易漏的两处

视觉替换做得漂漂亮亮，一切到深色模式就露馅，这是设计师改包时最常见的翻车现场。原因往往不是执行出错，而是需求里根本没提深色。很多 APK 里同时存在浅色和深色两套资源，夜间版本放在带 -night 限定符的目录里；你只给了浅色色板，执行方只能按浅色改，切到深色自然还是旧配色。更隐蔽的情况是，某些界面把颜色写死在布局里，资源改了也不生效，这类地方必须靠真机逐屏检查才能发现。

深色模式不是把浅色反过来。纯黑背景配高饱和品牌色，在 OLED 屏幕上会显得刺眼，长时间阅读也累；比较稳妥的做法是用深灰做底（比如 #121212 一类的深色面），品牌色适当降饱和、提亮度，让它在深底上仍然可辨。正文和背景的对比度建议不低于 4.5:1，大字号标题可以放宽到 3:1。状态栏图标的明暗也要跟着切换，否则深色界面顶着一排黑图标，看起来就像没做完。

桌面图标还要单独看一眼深色壁纸。浅色底的图标在深色壁纸上容易丢掉边缘，尤其是那种主体颜色接近背景的极简标志。解决办法通常不是加白底，而是给主体加一圈极细的浅色描边，或者在图标底板和主体之间留出足够的明度差。这个细节在电脑上看不出来，必须装到手机上、换一张深色壁纸才能判断。

分辨率的问题更琐碎，但同样致命。Android 的布局单位是 dp，不是像素，同一个界面在 320dp、360dp、411dp 宽度的设备上，留白和换行都不一样；启动图按 1080×1920 做，到了 20:9 的屏幕上就要裁掉一截，主体偏上或偏下都会出问题。九宫格拉伸图还要注意拉伸区域，四角不能被拉变形。折叠屏展开态、平板横屏，也都是需要单独看一眼的场景。

验收项	检查方法	通过标准
深色模式整体	系统切深色，逐屏翻一遍	无深底深字，无残留浅色卡片
正文对比度	取色工具读前景与背景	不低于 4.5:1，大字不低于 3:1
图标深色壁纸	换深色壁纸看桌面	边缘清楚、不被系统加白底
小屏 720p	老设备或模拟器实装	按钮不重叠，文字不溢出
长屏 20:9	冷启动看启动图裁切	主体完整，上下留白均衡
折叠屏 / 平板	展开态与横屏各看一次	内容居中，没有大片空洞

把这张表存下来，每次改包按行打勾，比凭记忆靠谱。需要强调的是，表格里的“通过标准”应该由设计师来定，而不是交给执行方猜。你在需求里写“深色模式保持可读”，执行方只能做到“看起来能读”；你写“正文对比度不低于 4.5:1，深色底用 #121212，品牌色降饱和约 10%”，结果才可控。模糊的验收标准，最后往往会变成来回拉扯。

平板和折叠屏值得单独说一句。同一个应用在手机上看起来留白刚好，展开到平板就可能出现内容挤在顶部、两侧大片空白；折叠屏内外屏切换时，启动图的比例也会变。验收时不用覆盖所有机型，挑三台有代表性的：一台小屏、一台主流长屏、一台平板或折叠屏展开态，基本能覆盖大多数布局问题。剩下的靠需求里的边界描述兜住，比如写清“启动图主体始终居中，允许上下裁切，不允许左右裁切”。

九、回编、对齐、签名：能装、能验、能追溯

AI 改完资源不等于交付完成。一个 APK 要能装到手机上，还得经过四步：回编、对齐、签名、校验。智能修改电脑版把这四步串成自动流程，每一步都有对应的日志，出了问题能定位到具体环节。对设计师来说，不需要记住命令，但知道这四步在做什么，验收时心里会踏实很多。

apktool b -f -o build\unsigned.apk
zipalign -f -p 4 build\unsigned.apk build\aligned.apk
apksigner sign --ks release.jks --out build\signed.apk build\aligned.apk
apksigner verify --print-certs build\signed.apk

第一步把 apktool 工程重新编译成未签名的 APK；第二步做 4 字节对齐，让安装包内的资源按页对齐，减少运行时的读取开销；第三步用证书签名；第四步校验签名并打印证书信息。多出来的这一步校验很关键，因为“签了”和“签上了”是两件事。密钥格式不对、别名写错、口令不对，前面几步都可能看起来正常，只有 verify 会明确告诉你证书到底有没有写进去。

签名方式有四种可选：默认签名、JKS 或 keystore 证书、PEM 加 PK8、随机签名。签名版本支持 v1、v2、v3、v4，默认启用 v1+v2+v3，兼顾新旧系统。证书口令通过环境变量传入，不拼进命令行，也不会写进日志。这一点对团队协作很重要：交付用的证书不应该出现在任何可复制粘贴的文本里，否则等于把钥匙挂在门上。

打包失败最常见的原因有三类：资源引用缺失（删了图但布局还在引用）、九宫格图片的拉伸区域不合法、签名配置与证书不匹配。前两类会在回编阶段报错，日志里通常能直接看到是哪个资源；第三类往往要等到 verify 才暴露。遇到失败先看 pack.log 的最后一段，再决定是改素材还是换证书，不要一上来就重装工具链。多数问题其实是素材层面的，不是环境层面的。

打包完成后，工具会自动找设备、装包、拉起应用。找设备走 adb；拉起用 am start -W -n 包名/Activity，并等待启动结果；组件名有三档查找顺序，先读 config.ini 里的启动 Activity，找不到就用 cmd package resolve-activity --brief 查询，再不行走旧方式兜底。装完还会用 dumpsys 复核前台应用，确认真的拉起来了。手机连着的话可以走 scrcpy 投屏，模拟器窗口会被提到最前，设计师不用低头找手机。

三档查找看起来是技术细节，实际解决的是“不同应用写法不一样”的问题。有的应用启动入口写在配置里，有的需要现场解析，有的只能按旧规则猜。对设计师来说，你只需要知道：拉不起来时先看详情页的启动页信息对不对，再看手机上是不是装了两个同包名的版本，最后再怀疑包本身。把排查顺序固定下来，比凭感觉反复重装有效得多。

整个过程写进 pack.log，反编译输出在 apktool.log，窗口吸附和布局在 dock.log，未处理异常在 error.log。项目等 AI 完成的上限是 1 小时，超过就结束等待，不会无限挂起。这些日志平时不用看，但一旦出现“装不上”“图标没变”“启动就闪退”，它们就是最直接的线索。把日志位置告诉开发，沟通成本会低很多。

十、交付清单、用户评价与合规提醒

把前面的内容收拢成一张交付清单，改包这件事就变得可复制了。每次接需求，先对照清单确认素材和边界；改完，再对照清单逐项验收；交付时，把清单和安装包一起发出去。对设计师来说，这张清单既是工作方法，也是和客户、开发沟通的共同语言。

交付项	验收方法	通过标准
图标	两种启动器 + 深色壁纸	清晰、不裁切、无异常白边
启动页	冷启动 + 三种屏幕比例	主体完整，无拉伸变形
应用名	桌面、最近任务、设置页	三处一致，不截断
主题色	浅色与深色各翻一遍	无旧色残留，对比度达标
签名	apksigner verify --print-certs	证书信息与预期一致
可追溯	查 pack.log 与历史需求	每版都有据可查

说到底，这套流程解决的不是“设计师要不要学编程”的问题，而是“视觉决策能不能由做视觉的人快速验证”的问题。工具把反编译、回编、对齐、签名、装机这些机械环节接过去，设计师仍然要负责判断：这个圆角对不对、这张启动图在 20:9 的屏幕上是否成立、深色模式下的品牌色有没有失去识别度。判断力没有被替代，只是不必再被工具链消耗。

交付时建议把三样东西一起发：安装包、这一版的需求原文、验收清单的勾选结果。客户或开发拿到之后，不需要再问“这版改了什么”“怎么验证”，沟通成本会低很多。如果对方要自己复现，把 source.apk 和附件也一并留档，下一次迭代就能从同一个起点开始。这套习惯一旦建立，改包就从“一次性手艺”变成了“可复用的流程”，团队里换人接手也不至于从头摸索，项目交接会顺利很多。

对个人设计师来说，这套流程还带来一个隐性好处：你可以把精力放回品牌本身。以前一次改版要花半天在工具链上，现在同样的时间可以多打磨两版视觉、多测几种屏幕比例、多准备一套深色配色。客户看到的成品更完整，你收到的返工更少，下一次报价和排期也更有底气。工具不替你创作，但它把创作之外的路障挪开了。

用户评价：他们怎么把改包放进日常工作

“以前改一版图标要等开发排期，现在把四张图拖进去、写清楚哪张放哪，午休回来就能在手机上点开看。最有用的是附件说明，逼着我把‘这张图到底用在哪’想明白。”

—— 林一诺 · UI 设计师

“品牌手册里的色值终于能原样落到应用上。我把主色、浅底、强调色写成三行文字，再配一张色卡，出来的效果和打样几乎没有色差。”

—— 周子昂 · 品牌设计

“课程作业要交一个可安装的成品，我不会写代码，就用自家的练习应用改图标和启动页。最深色的那版在模拟器上看不出问题，装到真机上才发现启动图主体被裁了，后来按清单加了三种比例才过。”

—— 陈可 · 设计专业学生

“自由职业最怕客户一句‘再改一版’。现在历史记录里点一下就能回填上次的需求，改个色值和日期再跑，交付节奏稳了很多，也敢接小预算的品牌换肤了。”

—— 苏晚 · 自由职业视觉设计师

“团队里设计和开发各忙各的，视觉微调常常卡在中间。现在设计师自己跑完，把安装包和日志一起发过来，我只需要看签名和日志，不用再从零复现一遍环境。”

—— 何遇 · 小团队设计负责人

写到这里，回到最开始那个问题：设计师离最终屏幕到底有多远？以前隔着的是一整套工具链、一次次排期、一轮轮“改完再装”。现在这段距离可以被压缩到一次拖入、一段需求、几个附件、一次等待。你依然要判断尺寸、判断风格、判断边界，但这些判断能立刻在真机上得到回应，而不是停在设计稿里。