项目目录导读与手工维护：8 位随机目录里装了什么、哪些能改、盘符怎么挑

先交代主角。安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

「用一句话改包」的工具会删掉你目录管理的安全感 —— 很多人第一次用完，心里都会有个小问号：我的包到底被放到哪了？它改了什么？万一我想自己动手，会不会把工具搞坏？ 这是个好问题，因为改包这件事最怕的从来不是改错，而是不知道自己手上这个包是从哪来的、被谁动过。

这篇文章就是一份目录导读：先讲清工具把东西放在哪、盘符是怎么挑的；再把一个新建项目目录拆到文件一级，说清每个文件是谁写的、干什么用；然后给你两张清单 —— 哪些文件可以放心手改、哪些千万别动，以及手改 config.ini 之后会发生什么；最后配两个自家应用的实例。读完你会有一种很踏实的掌控感：盘上的每一个文件，你都知道它的来历。

一、文件都放在哪：工作目录是怎么挑出来的

工具启动时会自动挑一个盘，规则是：按 D → E → F → G 的顺序找，取第一个「能用」的盘，拼成一个固定的工作目录；四个都不行才退回 C 盘。 这个目录名是固定的，所以每台机器上的布局都是一句话能说清的：

「能用」这两个字是三道判定的合称，每一道都在挡一种具体的失败：

为什么 C 盘放最后？ 因为系统盘的权限限制最多：UAC、受控文件夹、杀软规则，都更容易让「写文件」这种小事失败。把 C 当兜底而不是首选，就是让绝大多数机器把工地放在数据盘上。四个优先盘都被否掉时会退回 C；就算 C 也没通过读写检测，程序也会照常给出这个路径 —— 至少界面和日志里能告诉你它落在哪，而不是让你对着一个不存在的路径猜。

选中之后，这个目录下面只有两个子目录，分工非常清楚：

• tools：工具链（java、aapt、apktool、7z、zipalign、apksigner 等）。它是自动递归搜索的 —— 按约定位置找（tools 下的 tools / bin / env / adrc 等），再带一次有上限的递归遍历；所以工具包是「解压成什么层级它都能找到」，不需要你登记路径。
• Project：项目。每个项目一个子目录，也就是这篇文章后半部分的主角。

另外还有两处「不在这里但值得知道」的落点：服务端工具包下过一次就留在工作目录的 download 子目录里，不会重复下载；apktool 的框架缓存放在系统的本机目录下（%LocalAppData%\apktool\framework），所以再解同类包会明显快一些。这些缓存都不是项目数据，删掉只会让下一次慢一点，不会影响你的包。

使用技巧：工作目录是「每次启动自己挑」的，所以换台机器、或者插拔过移动硬盘之后，它可能落到另一个盘上。如果你希望它固定在某个盘，到「参数设置」页把工作目录保存一次 —— 保存之后这份路径就记进配置（配置里的「自动挑盘」开关会自动关掉），以后不再随着机器环境漂移。这一页里还有一次工具链体检，会把 aapt / java / apktool / zipalign / apksigner 逐个检查并给出完整路径，排查「改了包但打不出来」时先看它，比翻日志快。

配置也是分层的：给人改的和给程序记的分开住

顺便把配置文件的家也说清楚，因为它和你后面要做的「手工维护」直接相关。程序和项目相关的配置分成两类：

文件	放哪	装什么
settings.ini	程序目录（exe 旁边）	给人改的：窗口尺寸、两窗占屏比例、间隙、轮询间隔、各种开关、主题
local.ini	%LocalAppData%\ApkGallary\	给程序自己记的：登录缓存、头像地址、机器码、上次的登录方式
config.ini / history.ini	每个项目目录里	这个项目的基本信息与修改历史（后面两章逐项讲）

分层的好处很实在：你手改写坏了 settings.ini，顶多是布局不好看；登录状态、机器码这类程序内部数据放在另一个文件里，不会被一起弄丢。反过来，程序自己写状态时也不会顺手覆盖掉你手写的注释 —— 「参数设置」页改一项，只更新配置里对应的那一行。

二、一次新建项目，磁盘上多出来的东西

新建一个项目（拖入包 → 起个名字 → 点创建）之后，Project 目录下会多出一个8 位随机字符串命名的子目录（小写字母加数字）。为什么用随机名而不是「应用名」？三个理由：不会重名、不依赖中文路径、而且项目名随便改都不影响目录 —— 名字只是给你看的标签，目录才是实际身份。

一个项目目录长这样（文件名都是固定约定）：

按「谁写的」把这些文件分三类，你对它们的处置方式就清楚了：

• 程序写的（config.ini / icon / source.apk / apktool.log / 日志类）：它们是事实记录，可以看、可以备份，改之前的价值在于「它记的是真的」；
• AI 写的（apktool 目录里的东西 / 中途的 ai_done.flag）：这是工地，随时在变；
• 你写的（history.ini 里的需求原话、附件指向的文件）：这是你的账本，值得维护。

创建过程本身也值得说一句，因为它解释了「为什么反编译失败不影响我用」：建项目的动作顺序是先建目录 → 拷一份原始包 → 存图标 → 写 config.ini → 再反编译。反编译是最后一步、而且是独立的：它失败的时候，前面那些已经落地的东西一个都不会少 —— 你照样能进详情页看到应用名、包名、版本号，只是多一条说明失败原因的提示（详细的完整输出在 apktool.log 里）。这不是宽容，而是把「项目」和「反编译结果」两件事分开了：前者是账，后者是工地。

三、config.ini 逐键导读：哪些是「记录」，哪些是「依据」

config.ini 是这个项目最重要的一份文件（没有它，这个目录根本不会出现在项目列表里）。它分成两节，内容都是明文的键值对。下面把常用的键逐个说清：改它会发生什么、程序读它还是只写它。

键	写的是什么	手工改了会怎样
ProjectName	项目名	列表与详情页显示的名会变；目录名不动（安全）
CreateDate	创建时间	改的是显示的时间；删空会退回用目录的创建时间
WorkDir	这个项目的完整路径	只是「记录」：读取时用的是目录本身的位置，改这一行不会让项目搬家
IconFile	图标文件名（相对项目目录）	可以指到你自己放进来的图；指到不存在的文件时退回「自动找 icon.\*」或文字头像
SourceApk	原始包副本的文件名	记录行：拷贝成功才会有值，没成功就是空的（不会撒谎）
ApktoolDir	反编译产物目录名	记录行：回编时实际使用的是固定位置，别指望改它来「换工地」
AppName / PackageName	应用名与包名	显示会变；包名还会影响「打包后自动运行」的目标与签名冲突时的卸载提示
LaunchableActivity	启动页组件名	它是「拉起应用」三档查找的第一档：改错了会拉不起来，但不会损坏包
版本 / SDK 几个键	版本名、版本号、最低与目标 SDK	属于「从包里读出来的档案」，改了只影响界面显示与记录，不会真的改进包里

这张表里最重要的一行是 WorkDir。很多人的直觉是「那我把这一行改掉，项目就搬到新位置了」—— 不会。 程序读取一个项目时，用的是「它找到 config.ini 的那个目录」当工作目录，文件里这一行只是写给你看的记录。这个设计其实更安全：如果这一行能当开关，那么手误改错一行，就可能让程序去别的地方找产物、甚至按错误的路径去删除项目。 把「记录」和「依据」分开，正是为了避免这种事故。

还有三件事和手工维护直接相关：

• config.ini 是「整文件重写」的：创建项目时程序会写它两次（建好之后写一次；反编译成功之后再把产物目录补写进去）。重写不会保留你在文件里手工加的注释，所以别把重要信息写成文件里的注释 —— 想留备注，写在项目名或者单独一个文本文件里；
• 手改完不需要重启程序：回到项目列表点一下「刷新」就会按新的内容重读（项目列表本来就是直接读磁盘上的 Project 目录的）；
• 项目目录整体是可以搬的：图标存的是相对文件名，所以把整个随机目录拷到别的盘、别的机器，图标也能找到；别人拷给你的项目目录，放进 Project 下再刷新一下就能看到。

四、另外三个角色：台账、工地与流水线

项目目录里除了配置，还有三处你要能分清楚的位置：一份台账（history.ini）、一个工地（apktool\）、一条流水线（build\）。它们各自的态度完全不同。

history.ini：你的改动台账，也是最好的交接单

history.ini 的结构简单到不需要解释：每条记录一个节，名字是「记录1、记录2……」递增，节里两个键 —— 时间（Date）和你写的需求原文（Demand）。详情页的「修改历史」直接读它（最新在最上、完整显示不截断），每条右边的「选择」能把那条原话填回输入框。

手工维护它有两条实用规则：

1. 删掉某一节，就等于删掉那条记录。 「记录1、记录3、记录4」这种编号不连续的状态完全正常，程序按现存的最大编号往下递增，不会乱；
2. 别把 Demand 清空：没有需求原文的记录在加载时会被跳过（界面上不显示），留着空壳只会让你以后困惑「这里怎么少了记录2」。

为什么值得你花心思维护它？ 因为它同时是三样东西：台账（这个包被改过什么、什么时候改的）、回放器（把某条原话填回去，补两句再发，就是「照上次那条再改一遍」，而且不会覆盖旧记录）、以及交接单（把项目目录整个拷给同事时，history.ini 就是最准确的说明书 —— 比口头描述可靠得多）。

顺带回答一个常见疑问：「我发了那么多条需求，历史里会不会被那段发给 AI 的固定说明刷屏？」不会。 历史里只留你写的原话；真正发出去的文本虽然还带着附件说明和一段环境说明（把工作目录切到本项目、改完留标志文件、不需要自动打包），但那两段都不写进历史。这是有意为之：历史是给你回看的，不是机器日志。

apktool\ 与 build\：工地和流水线

剩下两个目录一个是 AI 干活的地方，一个是打包产出的地方，它们的分工不能混。

apktool\ 是工地。 反编译之后，这里装着 apktool.yml、AndroidManifest.xml、smali（代码）、res（资源）、assets、lib 等等 —— AI 改的就是这些文件。要知道两件事：第一，这个目录名是固定约定，回编时用的就是「项目目录\apktool」这个位置，你把它改名，打包会直接失败（提示「项目里没有反编译出来的 apktool 目录，没法回编」）；第二，重新反编译会把旧目录整个清掉再解一遍，所以别在这里存放你唯一的副本 —— 想留什么东西，复制到项目目录外面去。反编译本身的完整输出在 apktool.log，解不开包的时候先看它最后几行，通常一眼就能看出是哪个文件不认。

build\ 是流水线。 每次打包会依次产出三个中间/最终文件：unsigned.apk（回编出来的，没签名）→ aligned.apk（已对齐）→ signed.apk（已签名，这个才是给用户的）。想区分版本别去改文件名 —— 用「保存 APK」另存到外面，默认文件名是「应用名_版本号_signed.apk」，本身就是带版本号的。全过程（包括每一步的命令行、以及打包标记那一行）都写进 pack.log。

五、两张清单：哪些能放心改、哪些千万别动

可以放心手工改的

改什么	怎么改
项目显示名、应用名	改 config.ini 里的 ProjectName / AppName，回项目列表点「刷新」生效
项目列表里显示的图标	目录根下那个 icon 文件是「给界面看的原图」；换掉它只换界面头像，不影响包里真正的图标（那个要走需求 + 打包）
图标显示不出来（webp 缺解码器）	放一张 png 进项目目录，把 IconFile 指到它，界面就能显示
修改历史	history.ini 删掉某一节就是删掉那条记录
界面尺寸、比例、间隙、开关、主题	settings.ini（带注释），或直接在「参数设置」页里点（只更新对应那一行）
话术库内容	改程序目录下 Resources\话术库.xml，回话术页点刷新重新读
搬项目 / 拷给同事	整个随机目录一起拷；放进 Project 下刷新即可看到

千万别动的

别动什么	为什么
程序正在跑（反编译 / 打包 / 等 AI）时别动目录里的文件	命令正在读写这些位置，此刻改动会变成一次莫名其妙的失败
别给 apktool 目录改名	回编用的是固定位置，改名后打包直接报「找不到 apktool 目录」
别删 config.ini	没有它的目录不会出现在项目列表里（等于项目「消失」了）
别改 WorkDir / ApktoolDir / SourceApk 这几行去「控制行为」	它们是记录不是开关，改了只会误导你自己
别动 source.apk 里的内容	它是「回到原点」的那张底牌，保持原样才有意义（要备份就复制出去）
别手改 local.ini	登录缓存、机器码在那里；想退出登录，把里面记录登录信息的那一行删掉就够了
别把 unsigned / aligned 当成成品发出去	它们没签名，装不上；最终产物是 build\signed.apk
删项目别用「手工删一半」的方式	用列表里的「删除」（带防呆：只允许删 Project 的直接子目录，路径被改坏也会被拒绝）；手工删就把整个目录一起删

再补一个排查用的小工具：用户中心里有一组统计 —— 项目数量、修改总次数、占用空间、以及所在磁盘剩余。想知道「这些项目到底吃了多少地方」「盘还够不够」，看这一页比一层层翻目录快得多（它是后台算完再回填的，所以刚进去数字可能会慢一拍，点一下刷新即可）。

六、两个自家改包实例：目录维护在真实场景里的用法

下面两个例子都来自自家与内部团队的日常，讲的不是「怎么改」，而是目录这一层怎么维护。

实例一：内部「巡检打卡」，把项目整个拷给同事接手

以前的做法。 接手一个改过的包，靠的是一个压缩包加一段聊天记录：「这版改过启动页、去过广告、接口地址也调过，具体你自己看一下。」接手的人第一件事是重新反编译、自己找改动点，经常改了半小时才发现「原来这里已经被改过了」。

现在怎么做。 直接把这个项目的随机目录整个拷过去 —— 它自带三样东西：source.apk（原始包，接手的人随时能回到原点对照）、history.ini（改过哪几条、原话是什么，一目了然）、以及现成的 apktool 工程与 build 产物。对方放进自己的 Project 目录下，在项目列表点一下「刷新」就能看到这个项目（列表本来就是直接读磁盘的），继续改还是重新打包都行。

改完怎么验证。 接手的人可以先对着 history.ini 把功能点逐一过一遍（每读一条原话，都能对应到一个看得见的现象：启动页、广告、某个页面），再打包一次做比对。「这台机器上的目录结构」和「同事手上的目录结构」完全一致，是这次交接最省心的地方 —— 不用先花半小时搞清楚这个包的来龙去脉。

实例二：自家「考勤助手」，手工改名 + 清历史台账

以前的做法。 一个项目改到一半，想换个更好认的名字、或者把中途试错那几条需求清掉，只能重新建项目、重导包、重来一遍 —— 只为了改两个字。

现在怎么做。 名字直接在 config.ini 里改（ProjectName=考勤助手 2.0 内测），回列表点「刷新」，显示名就换了，目录名和已经改好的 apktool 工程完全不动；试错留下的历史，在 history.ini 里把对应那一节删掉就行 —— 比如「记录2 / 记录3」是两次没改成的尝试，删掉之后台账里只留改成功的那几条，交接给别人时对方看到的是一份干净的记录。

改完怎么验证。 刷新列表看名字、打开「修改历史」看条数 —— 两处都对上就说明手改生效了。这类维护的好处是零风险：改的全是「显示」和「台账」，包本身、反编译产物、打包产物一个字节都没动，随时可以退回去。

一句话总结手工维护的原则：改「给你看的」，别改「给它用的」。 项目名、历史、图标这类是给你看的，随便改；产物目录名、记录行的路径、程序自己写的那份状态，是给它用的，别碰。

七、用户评价：把目录看明白之后，心里踏实了

八、结语：盘上的每个文件都说得清来路

把这篇收成三句话：工作目录按 D→E→F→G→C 挑一个能读写的盘，拼成固定的 <盘符>:\AiApkEditor，里面只有 tools 与 Project 两个子目录；每个项目是一个 8 位随机目录，里面有配置、历史、原始包、反编译产物与打包产物；config.ini 里分清「记录」与「依据」，history.ini 就是你的台账，能改的都改「给你看的」，别改「给它用的」。

目录这件事看起来琐碎，但它决定你能不能放心大胆地试：知道底牌在哪（source.apk）、知道账本在哪（history.ini）、知道工地和流水线在哪（apktool\ 与 build\），改包就从「碰运气」变成了「有据可查」。

于是你打开安卓修改大师智改工坊时的体验，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 你只管说要改什么，文件放在哪、按什么顺序落地、产物留在哪，工具已经替你把目录安排明白。

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