把改包接进团队流程：工单字段、目录约定与版本对应关系维护（附流转图）

先说清楚我们在讲什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把「改 APK」这件事压缩成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

一个人改包，最省事的办法是什么记录都不做：改完、打包、装机、看一眼，包发出去就完事。一群人改包，这套打法会在三个地方翻车。第一，「这个包是谁改的」说不清 —— 群里传了四五轮之后，没人能保证手上那个包是最新的那一版。第二，「到底改了哪几条」说不清 —— 需求散在聊天记录里，翻半小时能翻出七条，第九条不知道去哪儿了。第三，「下个版本从哪一份开始改」说不清 —— 手边只有成品包，没有基线，下一个人只能凭感觉往上叠。

这篇不讲工具怎么点，讲怎么把它接进团队流程：需求登记写什么、改动执行时哪些东西会被自动记到文件里、验收归档留什么、版本对应关系怎么维护。中间会给一份可以直接抄的「改包工单」字段模板、一张流转图，以及两个团队场景实例。

一、先说机制：一个项目一个目录，目录里每一件东西都有团队含义

团队协作能不能成立，取决于「信息有没有固定的落点」。这套工具的落点设计得非常直白：每个项目就是一个文件夹，文件夹里放着一份项目从哪来、改过什么、变成什么样的全部痕迹。 程序启动时会自动挑一个工作盘（依次尝试 D、E、F、G 盘，取第一个能读写且剩余空间不少于 1GB 的盘，都不行才退回 C 盘），在盘下拼出一个固定的工作目录，里面分成两半：一个放工具链，一个放所有项目。下面是每个项目目录里你会看到的东西，以及它在团队语境里意味着什么：

目录里的东西	是什么	在团队里意味着什么
目录名（8 位随机字符串）	不会和别人撞名，适合统一放在一台机器或一块移动硬盘上
config.ini	项目的「身份证」，可以手工编辑，改完在项目列表点刷新即可
history.ini	团队的「变更清单」，删掉某一节＝删掉那一条记录
source.apk	基线。任何时候都能从它重新开一次项目、重来一遍
apktool 目录 + apktool.log	AI 真正动手改的地方；改不动、环境不对时翻日志
build 目录（三份中间件）	对外只认最后那份；中间件留着方便排查
pack.log	出包这件事的「凭证」，出问题直接定位卡在哪一环
icon 图标文件	项目在列表里的辨识度，多人多项目时靠它一眼认出来

这里有一个专门为「拷贝/交接」做的设计，团队协作时很实用：图标写在项目目录里时，配置里存的是文件名（相对路径）而不是完整路径 —— 所以整个项目目录拷到另一台机器上，图标照样找得到；项目的实际工作目录也是按它当前所在的目录算出来的，不是写死在配置里的。换句话说，你可以把一整个项目目录打包发给同事，他放到自己的工作目录下、在项目列表刷新一下，就能接着往下改。 只有「原始文件来源」那一栏可能还指着老机器上的路径，那只是备注性质的信息，不影响改包。

最后提醒一个需要团队先对齐的点：工作盘是程序自动挑的（D、E、F、G、C 的顺序，取第一个可用且空间足够的）。这台机器挑到 D 盘，那台机器可能挑到 F 盘，路径不完全一样。这不影响协作（因为项目目录内部结构是自洽的），但有两件事建议统一：一是大家统一在做完之后确认一次工作目录（参数设置页能看到），二是交接时不要只发一个路径，要连目录本身一起交接。

二、需求登记：工单字段模板，以及三个「必须写」

把改包接进流程，第一步是把口头需求变成工单。工单不需要复杂，但有几个字段是硬性的 —— 它们的共同标准是：能直接对应到文件里的某一处，或者能直接被验证。 下面这份模板可以直接抄进你们现有的工单系统（表里的「落到哪里」一列，就是它在项目目录里的归宿）：

工单字段	填写要求	落到哪里
工单号 / 提出人 / 日期	你们现有的编号规则即可	工单系统；同时对应项目目录
项目名	建议「应用名 + 基线版本」，一眼能对上库里是哪个项目	config.ini 的项目名（可手工改，改完点刷新）
应用与包名	导入后自动解析出来的那两项，直接抄	config.ini；打包时还会进「打包标记」
基线版本	这一版从哪个包改起（版本名 + 版本号）	source.apk ＋ config.ini 里的版本字段
改动点（本次要改的原话）	写成能直接粘进需求输入框的那一段话，一条一条列	history.ini 里逐条记录（只留原话）
附件与用途	每个文件一句话（说明不少于 10 个字），并写明文件存在哪	随需求发出（不进 history.ini），文件建议归档到工单附件区
验收标准	写成可复现的动作：「点哪里、看到什么、不该出现什么」	工单里保留，验收时逐条对
执行人 / 执行时间	谁点的「立刻修改」	history.ini 的记录时间 ＋ 打包时的标记
产物路径与签名校验	最终包在哪、校验签名得到的那一行证书信息	build 目录的最终包 ＋ pack.log
归档位置	发布包统一改名后的存放位置	包按「应用名_版本号_signed.apk」命名（程序给的默认名就是它）

十个字段里有三个是「必须写」，其余可以按你们的习惯精简：

三、改动执行：一句话跑完流水线，痕迹自动落到文件上

登记完之后，执行侧的动作其实非常简单：把改动点粘进需求框（如果用了话术库，也可以直接从话术页「选择」过来），点「立刻修改」。从这个动作开始，团队需要的信息就不再靠人记录了，而是被流水线自动写进文件：

• 需求原话进 history.ini：连同修改日期一起追加成一条记录，按记录1、记录2 递增。谁在什么时候提的什么需求，历史里逐条都在。
• 等待与打包的过程进 pack.log：需求发出去之后，AI 改完会在项目目录里留一个标志文件，主窗口每 2 秒读一次，读到就自动弹出打包窗口；回编、对齐、签名、校验四步命令与输出，全程写进项目目录下的打包日志。
• 「谁在哪台机器上打的」进打包标记：每次出包前，程序会往工程的资源里写入一个名为 info 的样式，内容是把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名拼起来编码后的标记。多人共用一台打包机时，这一个标记就能把「这个包是谁打的」说清楚。
• 产物进 build 目录：未签名、已对齐、最终签名三份中间件依次产生，加上上面那份日志，整个执行过程是可回溯的。

执行侧还有两条团队纪律值得写进规范。第一，改包这件事不要求同一个人从头做到尾，但要求「开工前先看 history」：接手别人的项目时，先把详情页下方的修改历史从上到下扫一遍，确认自己这次要加的那条没有和之前的改动冲突 —— 尤其是入口、权限、主题色这类容易被互相覆盖的改动。历史里每条记录右侧都有一个「选择」，一点就把当时那条原话填回输入框，这是团队里复用需求最快的方式。

第二，不要把「打包」这件事交给 AI 顺手做。程序在发给 AI 的环境说明里明确写了「不需要自动打包」：打包统一由主程序执行（回编、对齐、签名、校验四步都是同一套命令），这样出包口径永远一致。如果有人绕过主程序自己打了个包发出去，那个包既没有进 build 目录、也没有对应的 pack.log 与打包标记 —— 在团队语境里，这等于一条查不到源头的记录。

第三，等 AI 改完的那段时间，不需要有人守着。等候窗口会显示在等哪个项目、已经等了多久、在等哪个标志文件；临时走开就把窗口收到后台，顶部状态栏留着入口，回来点开还能看到进度；等不下去时点「取消修改」，会连同右侧 AI 的生成一起停掉，这次自动修改就此结束。对团队来说，这条设计减少了一种很常见的隐性消耗：一个人被「等」这件事绑在工位上。协作时更推荐的做法是登记好工单之后由当值的人集中跑一轮，而不是每个人都各自守着自己那条需求。

四、验收与归档：只认最终包，基线永不删

验收这一步，团队要做的是「把工单里的验收标准逐条对一遍」，工具这边已经把证据准备齐了：签名校验读出来的证书信息证明这个包确实签上了，装机之后的复核证明它确实跑起来了，打包日志证明整个过程没有跳步。这里有三条归档纪律：

第一，对外只发最终签名包。 build 目录里那三份中间件，只有最后一份走完四步流程。把未签名或未对齐的包发出去，等于把流水线的最后两道保险拆掉了 —— 装不上去还算幸运，最怕的是能装但有问题。

第二，发布包统一命名。 程序在保存产物时给的默认文件名就是「应用名_版本号_signed.apk」，团队直接沿用这个格式最省事：谁拿到包都能从文件名读出它是哪个应用、哪个版本、是最终签名包。归档时把工单号挂在同一目录或同一命名前缀上，工单与产物就对上了。

第三，source.apk 不删。 它是这个项目唯一的基线。改坏了、想重来、想对比「改前改后」的差异，靠的都是它。项目目录里的其他东西（反编译工程、build 中间件）都可以重新生成，基线不行 —— 删了就只能重新找原始安装包。

另外提醒一个容易误操作的点：history.ini 是「只追加」的文件，记录是按序号组织的，删掉某一节就等于删掉那一条记录。团队场景下不要手工去改它的序号或内容 —— 想标注「这条已发布」「这条作废」，写在工单或你们的变更表里，别动这个文件。至于 config.ini，它是可以手工编辑的（顶部注释里就写着程序自动生成、可手动编辑、改完在项目列表点刷新），用它来补项目名、备注版本，都是正常用法。

五、版本对应关系：三段关系，两种策略

团队改包最容易乱的就是版本。我们把这件事说成一句最短的话：每一次改动，都是「从某个基线出发、按若干条需求、产出某个成品包」。 这三段在项目目录里各自有明确的载体：

落到日常操作上，有两个常见策略，各有取舍，选哪个取决于你们发版的节奏：

策略	怎么做	适合 / 注意
一版本一项目	每拿到一份新的来源包就建一个新项目，改动都发生在这个项目里	适合对外发版；项目数会变多，靠项目名带版本号来区分
一项目多轮改动	同一个项目里连续多轮小改，历史逐条累积	适合内部试用与内部工具的持续微调；要养成读历史的习惯
想重来一次	拿 source.apk 重新建一个项目，从基线重做	这是「撤销一切」最干净的方式，也是基线存在的意义

说到「撤销」，还有一个现实里很有用的兜底：如果某次改动改坏了、而且改动之前忘了留备份，最稳的补救不是往回删代码，而是用项目目录里的基线包重新开一个项目、把历史里那些仍然需要的原话逐条再改一遍。历史里每条右侧的「选择」会把原话填回输入框，所以重做的成本主要是等待 AI 的时间，而不是重新组织需求的时间。

流转图：一张图说清四个动作

这张图里最容易被跳过的是①和④：大家天然喜欢③（一句话改完很爽），也天然容易忽略①（需求没登记）和④（归档没命名）。但团队的秩序恰恰全在这两头 ——①决定了别人能不能接手，④决定了三个月后还找不找得到。

六、两个团队实例：流程怎么落在真实场景里

下面两个例子都来自我们自己团队和身边小组的日常，用的是自家应用、自家素材。

实例一：三人小组维护内部「工单助手」App，每两周出一个内测版。

以前的做法：包在群里传来传去，谁改了什么全靠聊天记录；出现「这版比上版少了三个入口」这种问题时，三个人一起往上翻记录，翻到最后往往各说各话。发版那天最紧张，因为没人能确认手上那个包是不是最新的一份。

现在的做法：每两周的改动先过一遍工单，改动点写成可以直接粘的原话 —— 例如这一期的一条是「隐藏首页已下线的活动入口，保留页面类本身，避免其它引用报错；其余入口点击都正常。」 验收标准写成三条可复现的动作；然后由当值的同学在同一个项目里逐条执行（把原话填进需求框、点「立刻修改」、等标志文件、打包、装机），每一条都会在 history.ini 里留下时间与原文。发版时统一从 build 目录取最终签名包，按「应用名_版本号_signed.apk」命名归档。

改完怎么验证？除了逐条对验收标准，我们多做了一件事：把这一版的历史条目数与工单上的改动点条目数对一遍。两个数字对不上，说明有人改完了没登记、或者登记了没改，当场就能发现；对上了，再看一眼签名校验读出来的证书行，确认这个包确实出自我们的测试密钥。三分钟能做完，但省掉了以前整整一晚上的扯皮。

实例二：新人接手一个半年前改过的包，直接被要求「加两条改动」。

以前的做法：找不到源码、找不到改动记录，只能把现有的成品包当基线重新来一遍 —— 但成品包是别人改过的，它的「改前」是什么样、里面有哪些非官方的改动，谁也说不清。于是新人做得很小心，也很慢。

现在的做法：从交接的目录里直接把整个项目目录接过来，在项目列表里刷新一下就能看到这个项目；详情页下方列着历次修改的完整原话（最新的在最上面，完整显示不截断），config.ini 里写着应用名、包名、版本与启动页，source.apk 就是当初的基线。新人先从头读一遍历史（五分钟就能读完一个半年的项目），确认这次要加的两条和之前的改动没有冲突，然后把新需求写进输入框执行。改完把新增的两条与工单核对，产物同样按统一命名归档。

这两个实例想说明的是同一件事：工具本身已经把这些信息落到文件上了，团队要做的只是「不要绕过它们」 —— 需求从工单进来、执行在项目里发生、产物从 build 目录出去、历史不要手改。流程不需要多复杂，难的是别在赶时间的时候把①和④省掉。

七、还有几件值得写进团队规范的细节

• 统一先做一次工具链体检。 参数设置页里有一次体检，会把反编译与打包需要的几个组件逐个检查一遍并给出完整路径。新人第一天先跑它，比出问题再排查快得多 —— 「我改了包但打不出来」这类问题，一半以上能在这一页看出原因。
• 知道日志在哪。 诊断日志放在本机用户目录下的固定位置，吸附与布局自检、异常、打包、反编译各有各的日志文件。团队里约定一句「出问题先看日志」，比截图问人快。
• 交接要交目录，不要交路径。 项目目录内部是自洽的（图标存相对路径、工作目录按实际位置重新算），整个目录拷给同事即可；只发一个绝对路径，换台机器就失效了。
• 删除项目有防呆，但仍然要谨慎。 程序只允许删除项目目录的直接子目录 —— 就算配置文件里的路径被人改坏了，也不可能把目录外面删掉。反过来说，删项目＝删掉这个包的全部历史与基线，团队里这个权限建议只留给一个人。
• 共用一台打包机时，靠标记区分到人。 打包标记里同时包含程序的登录账号与系统用户名，还带机器名、机器码与时间 —— 两个人用同一个 Windows 账号轮流登录，也能从标记里区分出是哪一次出包。
• 把常用改法沉淀成话术。 团队里反复出现的改法，攒进话术库自己的分类里，新人不用读文档，打开话术页点一下分类就知道标准动作是什么。

八、用户评价：他们团队怎么落这套流程

九、结语：让流程活在文件里

把这篇收成一张清单：需求登记要写三样（项目名、能直接粘的改动原话、可复现的验收标准）；改动执行不用额外记录（原话进历史、过程进打包日志、身份进打包标记、产物进 build 目录）；验收归档守三条（只发最终签名包、产物统一命名、source.apk 永不删）；版本对应记三段（基线是 source.apk、过程是 history.ini、产物是 build 里的最终包）。

这套流程最舒服的地方是：它对人的要求集中在一头一尾，中间那段最花时间的活儿（发需求、等 AI、打包、装机）交给流水线。所以团队要维持的纪律其实很轻 —— 登记时认真写两句，归档时认真看两眼，中间不要绕过工具自己发挥。

于是你打开安卓修改大师智改工坊时看到的，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 而在团队里，这句话背后还多了一层意思：说过的每一句话，都能在文件里找到。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。