外包代做交付：源包分明、需求留痕、验收写清，一次验收通过

交付不扯皮：源包不动、需求有痕、产物可验

拖入包 → 中文写需求 → AI 改包 → 自动回编 · 对齐 · 签名 · 校验 → 一键装到设备，当着客户的面验收

外包与代做这一行，最贵的成本不是技术难度，而是解释成本：客户觉得交付的和说好的不一样，你觉得客户中途改了三回口。双方都不是故意为难对方，问题出在同一件事上——需求在聊天记录里飘着，过程没有留痕，验收没有标准，于是只能靠「印象」判断对错。

这篇讲的是用一款 Windows 桌面工具把交付这件事做扎实：安卓修改大师智改工坊，把「改 APK」从技术活变成一句话——拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。产品介绍页：https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。

下文按交付的时间顺序走：开工前怎么把源包管好，动手时怎么把需求留痕，交付时怎么把验收标准摆上桌。所有例子都来自自家团队做过的内部项目，写清以前怎么做、现在一句话怎么做、验收时怎么核对。

一、交付扯皮的三个经典场景，根因只有一个

• 场景一：「这不是我要的效果。」——但需求当初只在语音里说过，谁也没写下来。
• 场景二：「还是上一版好，改回去吧。」——上一版改了什么、怎么改的，没人记得。
• 场景三：「这包装不上，是不是改坏了？」——其实只是签名没对齐，或者客户拿错了文件。

三个场景根因是一个：过程没有留下痕迹。需求是一句话说完就没的，产物是一个压缩包发过去就没的，验收标准从来没人写过。智改工坊的思路正好相反——源包有副本、需求有记录、产物有名字、出包有日志。

二、源包与产物分明：项目目录就是你的交付台

交付现场最尴尬的一刻，是客户问「原始包还在吗」，而你手上只剩下一个改了三轮的产物。智改工坊从建项目那一刻起，就把这件事定死了。

• 每个项目一个独立目录：目录名是 8 位随机字符串，互不覆盖；建项目时自动写 config.ini，并拷一份 source.apk 放在项目里——它就是你交付时的「原始凭证」。
• 反编译输出单独放：所有解包内容进 apktool 目录，源包与解包产物物理分开，不会互相污染。
• 出包产物三件套：build 目录下依次留下 unsigned.apk / aligned.apk / signed.apk，哪一步出的问题，一眼能分清。
• 全过程日志：打包过程写进包目录下的 pack.log；项目列表读磁盘生成，带搜索与刷新，删项目还有防呆（只允许删 Project 的直接子目录）。

还有一点值得说：反编译失败并不影响项目本身——配置、图标、源包已经落地，程序会提示原因并给出日志路径。哪怕这次改动没成，客户的包也完整在位。

三、需求留痕：把口头要求变成可复现的条目

需求留痕这件事，智改工坊做得很朴素：每次点「立刻修改」，需求原文和修改日期就写进项目的 history.ini；详情页直接把历史列出来，最新的在最上面，每条显示「#序号 + 时间 + 需求原文」，而且原文完整显示、不做截断。历史按「记录1、记录2」递增，删某一节即删那条记录。

更实用的是每条右侧的「选择」按钮：点一下，那条需求原文就回到输入框里，「照上次那条再改一遍」是一秒钟的事。对交付来说，它解决的是最要命的一类返工——客户说「还是上一版好」，你不必凭记忆复原，只要把上一版那条需求点回来重新执行。

写需求的时候可以用话术库：它按 6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）收了 3000 条成型指令，每条都把「要做什么、细节要求、参数参考、范围、验收」写全。点「选择」直接填进输入框，点「复制」把正文复制走——复制出来的这段，转手发给客户确认就是一份需求确认单。

一句好的交付需求，应该让三方都能看懂：客户看得懂改了哪里，你执行时不会漏，验收时逐条能对照。

四、验收标准写清：把「四步打包」写进交付说明

验收扯皮的另一半原因，是双方对「包做好了」的定义不同：客户以为「能装能开」，你以为「代码改完」。智改工坊把出包固定成四步：回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + testkey）→ 校验（apksigner verify）。第四步最值得写进交付说明——前三步只看退出码，到底签没签上，要 verify 说了算。把这四步讲给客户听，他就明白「能装」是流程保证的。

• 交付前自己先装一遍：程序会用 adb 找到手机或模拟器，装上并拉起应用；拉起用的是 am start，安装结束后还会用 dumpsys 看一眼前台应用是不是它。
• 签名密钥可替换：默认用工作目录下的 testkey.pk8 / testkey.x509.pem；如果有正式的签名密钥，替换掉再出包，交付物就带上你自己的签名。
• 产物命名规范化：点「保存 APK」默认文件名是「应用名_版本号_signed.apk」，客户拿到手就知道这是哪一版、哪个应用。
• 出包标记可追溯：每次出包前程序会自动往 res/values/styles.xml 写入一个 name 为 info 的样式，内容是时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记；「这一版是谁在什么时候打的」有据可查。

五、两个交付实例：名字图标、启动页与品牌文案

实例一：自家团队给合作门店做的内部点单工具，交付前要换成客户的品牌形象。需求是两件事——应用名从内部代号改成「门店点单 连锁版」，图标换成客户的 logo。

• 以前：解包后在资源目录里找图标与字符串，多套密度逐个替换；改完回编、签名，把包装到手机上确认桌面名称有没有变、图标有没有糊；客户临时说「名字改回上一版」，只能再走一遍流程。
• 现在：把内部工具的包拖进智改工坊建项目，点「选择附件」把客户 logo 传进去，写明用途（不少于 10 个字，例如「客户品牌主 logo，用于桌面图标」）；输入框里写下改名与换图的需求，点「立刻修改」。AI 改完留一个标志文件，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口。
• 验收：打包跑完自动装到设备上；桌面上的应用名变成「门店点单 连锁版」，图标是客户 logo；客户如果想回退，直接在历史里点上一版需求右侧的「选择」，填回输入框再执行一次。

实例二：同一款点单工具，把启动页背景换成客户品牌主视觉，并把界面上默认的仓库名文案换掉。以前这类改动最碎也最容易漏：启动页图要翻资源目录逐套密度替换，仓库名文案散在多个界面里，改完还得挨个页面点一遍确认。现在一句话的做法是：附件里一次传两张图，每张写清用途；需求里把「启动页背景覆盖为满屏不留白」「默认仓库名文案替换为 XX 门店」写成一句话，范围限定在启动页与文案两处。改完装到设备上看启动页是否铺满、文案是否正确，其余页面顺一遍确认没被误伤。

这两件事在智改工坊里都有一个共同点：改动范围写在需求里，改动过程落在历史里，改动结果装在设备上。客户验收时不用听你复述，直接看设备、看历史、看产物，三样东西互相印证。

六、交付前的十分钟自检清单

1. 确认源包在位：项目目录里有 config.ini 与 source.apk，客户原始包未被改动。
2. 确认需求齐备：本次需求已执行，历史里能查到原文与时间。
3. 确认附件有效：客户素材已传入，每张图都带 10 个字以上的用途说明。
4. 确认四步跑完：回编、对齐、签名、校验全部通过，pack.log 里能看到过程。
5. 确认产物齐全：build 目录下 unsigned / aligned / signed 三个包都在。
6. 确认命名规范：保存的包名带应用名与版本号，和客户约定的版本对得上。
7. 确认装机正常：已装到约定机型并成功拉起，前台应用核对无误。
8. 确认回退方案：万一客户要求回到上一版，历史里那条需求可以直接回填重做。

两个容易忽略的细节：打包过程中窗口是不给关的，这不是卡住，而是避免误关把包做废；第一次在客户现场用之前，先在「参数设置」里做一次工具链体检，aapt / java / apktool / zipalign / apksigner 逐个报是否就绪，缺了直接点「立刻更新」自动下载工具包——现场环境不齐，比改不好更尴尬。

七、用过的人怎么说，以及一条合规提醒

外包与代做，本质上是把「信任」做成流程。需求写清楚、过程留得住、产物查得到，信任就不再依赖记忆和口才，而是依赖文件本身。这也是「交付不扯皮：源包不动、需求有痕、产物可验」这句话的由来——安卓修改大师智改工坊能帮你的，就是把这三件事变成默认动作。想看看它具体长什么样、怎么开始，从这里进：https://www.apkeditor.cn/ai-version.aspx。