项目与文件命名的方法：8 位随机目录名、四要素与一套命名约定

这篇讲一件看起来最不像技术的事：给项目起名字。但在安卓修改大师智改工坊里，命名不是"顺手填一格"的动作，而是决定你能不能在半年前的项目堆里找回那一次改动的关键。它是一款 Windows 桌面工具：拖入安装包，用中文写一句需求，AI 改包，改完自动回编、对齐、签名、校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

为什么值得专门写一篇？因为这套工具在磁盘上给每个项目分的目录，是一串 8 位的随机字符。你打开工作目录下的 Project 文件夹，看到的是一排 a3f9k2mq、k7x2p0da 这样的目录 —— 光看目录名，谁也不知道里面装的是哪个应用、哪一版、干什么用的。你的名字写在哪、怎么写，就成了唯一的线索。

一、先把一个项目目录摊开看：每个项目一个目录，目录里有什么

要谈命名，先得知道名字落在一个什么样的结构里。工作目录是程序启动时自动挑的：按 D、E、F、G 的顺序找第一个能读写、剩余空间不少于 1GB 的盘，拼成 <盘符>:\AiApkEditor，实在都不行才退回 C 盘（系统盘权限限制多，所以放在最后）。这个目录下面有两个子目录：tools（java、aapt、apktool、7z、zipalign、apksigner 等工具，程序会自动递归搜索，不用登记）和 Project（项目）。

导入一个包、填好项目名、点创建之后，Project 下面会出现一个 8 位随机名的子目录，它的内容是这样的：

目录里的东西	是什么	谁写它
config.ini	项目名、创建日期、工作目录、图标文件、源包、工程目录；应用名、包名、版本、SDK、启动页	程序生成，可手工改
history.ini	修改历史：每次点「立刻修改」追加一条（时间 + 需求原文）	程序追加
source.apk	导入时那份原始包的副本（存档）	程序拷贝
icon.xxx	从包里取出的应用图标原图（扩展名跟随原格式）	程序提取
apktool\	反编译出来的工程（apktool.yml / smali / res …）	apktool
apktool.log	反编译的完整输出，失败时翻它	程序写
build\	打包产物：unsigned.apk / aligned.apk / signed.apk	打包流程
pack.log	打包全过程（回编 / 对齐 / 签名 / 校验逐条命令与输出）	打包流程
ai_done.flag	等 AI 改完的临时标志文件（读到即删，不长期存在）	AI 生成 / 程序删除

这张表本身就是本文的提纲：一个项目目录里同时住着四种性质完全不同的信息 —— 你的命名（config.ini 里的项目名）、程序解析出来的客观事实（包名、版本、SDK）、你的操作意图（history.ini 里的原话）、以及机器执行的过程证据（两个日志与 build 里的产物）。命名的方法论，本质上就是"想清楚哪类信息该落在哪一层"。

二、为什么目录名是 8 位随机串：三个理由与一个必须付的代价

很多人的第一反应是"为什么不用应用名当目录名？" 这个问题的答案不是"懒得做"，而是三个很实在的工程理由。

代价也很明确，而且必须由你的命名习惯来补：在资源管理器的视角里，项目目录是不可读的。你没法靠翻目录名找到那个项目，只能靠程序界面。所以这套设计对使用者提出的要求是 —— 名字要写得能被检索，因为它是界面上唯一一眼可见的身份。

这里还有一条很实用、但很少有人注意的细节：config.ini 里记录的图标是相对文件名（图标就放在项目目录里，配置里只写文件名），所以把整个项目目录拷到别处，图标照样能找到；而工作目录这一行记的是绝对路径，所以整个目录搬走之后，这一行要跟着改。这是"信息分层"在设计上的一个体现：能相对的就相对，必须绝对的才绝对 —— 你手工整理项目目录时，顺着这个思路改就不会漏。

另外提醒一句操作层面的取舍：不要试图去改那串随机目录名。 名字不属于目录，属于 config.ini；目录名一改，配置里的工作目录那一行、以及所有指向它的记录就全对不上了。要改名字，改的是 config.ini 里的项目名，然后回项目列表点一下刷新 —— 显示名会立刻变，目录名纹丝不动，这才是这套结构希望你做的事（删除也有对应的防呆：只允许删 Project 的直接子目录，就是为了防止配置里的路径被人改坏之后误删到别处）。

三、一个项目名里应该带上的四要素

既然是唯一的身份标识，那么名字里要装的信息就有讲究了。四要素：应用、用途、版本、日期。 每一样都对应一个具体的检索需求，缺一样就会在某个场景里卡住：

要素	它回答的问题	缺了会怎样
应用	这是哪个应用的项目？	十个项目长得一样，靠记忆赌运气
用途	给谁用、改了什么？	分不清"内测那版"和"演示那版"，装错包
版本	这是基于哪一版改的？	上游发新版时，不知道手上的改动对着谁
日期	什么时候做的这一批？	两个同名项目谁新谁旧，得逐个点进去看

有一个常见误解需要点破：日期写进名字，和项目里已经记录创建日期，不是重复劳动。 config.ini 里的创建日期是给程序排序用的 —— 项目列表就是按创建时间倒序排列的，最新做的项目永远在最上面；而名字里的日期是给人眼扫用的：当你在搜索框里打进"巡检打卡"，列出三五条结果时，名字里的日期让你不用逐条点开就能判断"我要找的是四月那一次"。一个服务排序，一个服务识别。

版本这一要素，建议直接用包里解析出来的版本号（详情页上就写着，形如版本名 + 版本号）。理由很实际：这个值不是你编的，是包的客观属性；写进名字之后，"这个名字"和"这个包"之间就有了双向可验证的关系 —— 拿到名字就知道该找哪个包，拿到包也能核对名字对不对。

还有一条边界要知道：项目名在写入配置前会被清洗一遍 —— 首尾空白去掉、文件名字符里的非法字符换成下划线、超过 80 个字符截断。四要素拼出来通常只有二三十个字，离上限很远；但如果你习惯把整段需求都塞进项目名，就会撞上这条线，而被截断的名字在列表里看起来几乎一样，反而更难分辨。所以名字要短：能一眼扫过去的长度，才是好名字的长度；剩下的细节留给 history.ini 里的需求原话。

用途怎么写才叫"可检索"

四要素里最容易写坏的是"用途"，因为它看起来最自由。经验是把它拆成两半："给谁用"用固定词表，"改了什么"用短词。"给谁用"推荐这几个固定词：内测、演示、评审、交付、灰度、基线。固定词表的价值在于它可被搜索、可被统计，也不会因为今天心情好写成"测试版"、明天写成"验证包"而散架。其中 基线 这个词特别值得保留：它指的是"改动之前的干净版本"，留一个基线项目，后面任何异常都有对照物 —— 这是很多团队做到第三轮才后悔没留的东西。

"改了什么"则用三到六个字的短词，例如 图标换新、启动页新图、配色对齐、去掉广告位。注意它不需要写技术细节（"替换 mipmap-xxxhdpi 下的 ic_launcher"这种话属于 history.ini 里的需求原话），名字里只需要"人一眼懂"的粒度。

四、命名如何决定可追溯性：搜索命中什么、历史记住什么

"可追溯"听起来抽象，落到这套工具里其实就是两件事：找得到，和看得懂当时想干什么。

找得到，靠的是项目列表的搜索。 搜索框会同时匹配四个字段：项目名、应用名、包名、项目所在目录。请注意这四个字段里有两个是你写的（项目名），两个是解析出来的（应用名、包名）。这意味着两件事：一是名字写得越具体，能被搜到的路径越多；二是即使你的项目名写得很随意，只要你还记得包名或应用名，往往也还能救回来 —— 但如果你连应用名都没印象了，那就真的只能翻。

这就解释了为什么"用途"要写进名字：应用名和包名是程序能给的，用途只有你能给。 搜索"记账助手"能列出这个应用的所有项目，而要在里面认出"哪一次是给运营做演示用的"，只能靠名字里的那两个字。

看得懂当时想干什么，靠的是修改历史。 项目详情页会直接列出修改历史（最新的在最上面），每条显示序号、时间和需求原文，原文完整显示、不截断；每条右侧还有一个「选择」，能把那一条需求原样填回输入框。这个按钮解决的是一个非常真实的场景：隔了两周要"照上次那条再改一遍"（比如上游版本更新了，要把同一套改动重做），你不需要重新组织语言，点一下、改几个字、发出去即可。

历史的一个关键设计是：history.ini 里只留你写的原话。 需求原文连修改日期一起按"记录1、记录2…"递增追加；而附件说明、以及发出去时那段固定的环境说明（切工作目录、留标志文件、不要自动打包）都不进历史。为什么这个取舍重要？因为历史是人的意图记录，不是机器日志。一条历史如果混进了"请在项目工作目录下生成 ai_done.flag"这种系统约定，翻十条记录你就不想再翻了 —— 而记录一旦没人看，可追溯性就是空的。顺带说，history.ini 的结构也让人工维护变得简单：删掉某一条对应的那一节，那条记录就没了。

把这两件事加起来，就得到一个团队协作里很具体的收益：交接时不需要口头传话。 接手的人打开项目列表、按应用名搜出全部相关项目、看名字就能区分用途与日期，点进任意一个就能看到当时的需求原话，需要复现就点「选择」把原话填回输入框。整个过程里，"名字"是入口，"历史"是内容，两者都不依赖"当时那个人还在不在群里"。

五、信息该落在哪：配置、历史、日志、产物四层分工

命名混乱的根源，往往是"什么都往名字里塞"。项目名只有一行，塞不下所有信息；正确的做法是让每一类信息落到它该去的地方。项目目录里其实已经有四层现成的容器：

这里面有两个容易被忽略但很能说明设计取舍的细节。第一，原始包是拷贝一份存档的：source.apk 就在项目目录里，改动做坏了随时可以对照原始包；而且程序在拷贝失败时宁可把这一行留空，也不写一句假的（"别让配置说文解字"）—— 所以如果你在 config.ini 里看到源包那一行是空的，说明拷贝当时确实没成功，而不是名字写错了。

第二，素材不进项目目录，是有意的。附件系统的说明里写得很清楚：这些文件放在磁盘上，让 AI 按路径读取、自己决定放进工程的哪个位置。这样做的结果是"输入素材"与"工程产物"不会混在一起 —— 你把新 logo 放在设计共享盘、把新宣传图放在本地下载目录都可以，项目目录始终保持干净：工程 + 存档 + 配置 + 历史 + 产物，各就各位。

顺带说一个"名字写到哪一层"的实操结论：凡是要长期靠人认的，写进 config.ini 的项目名；凡是要短期让 AI 知道的，写进附件说明；凡是机器自己要看的，交给日志。 附件说明之所以"不进历史"，正是因为它属于一次性的执行信息，而不是长期意图。

交付物的命名也顺手说一下：点「保存 APK」时默认名已经是应用名_版本号_signed.apk，这已经带了两要素，建议不要把它改成 demo、最终、新版这类词，也建议保留 signed 这个后缀 —— build 目录里同时躺着 unsigned.apk 与 aligned.apk，signed 是唯一能拿去装的那一个，名字里留着它，等于在文件名上写清"这个能用"。如果同一天要出两个用途的包，把用途词补在中间即可：记账助手_内测_2.0.0_signed.apk。项目名与出包文件名共用同一套词表，找的时候才不会两边对不上。

六、一套可以直接抄的命名约定

把四要素拼起来，最小集是四段：应用名 - 用途 - 版本 - 日期；如果同一个用途下同一天要区分多批改动，在用途后面再加一个短词，变成应用名 - 用途 - 改动主题 - 版本 - 日期。分隔符统一用半角连字符，不要用空格（搜索和口述时容易断）、不要用全角符号（输入法切换容易出错）、不要用括号（不同系统下的显示宽度不一样）。日期统一用 yyyyMMdd 八位，不用"4月12日"这种写法 —— 八位数字天然可排序、可搜索、无歧义。

建议这样写	它回答了什么
记账助手-内测-2.0.0-20260412	应用 + 给谁用 + 基于哪版 + 哪一天
记账助手-内测-图标换新-2.0.0-20260412	同一天同用途有两批改动时，加上改动主题
巡检打卡-演示-启动页新图-1.4.2-20260412	给外部演示用的那一版，和内部测试版分开
客户走访台账-评审-去掉广告位-1.9.0-20260412	评审用的中间态，明确是"还没定稿"的那一版
设备点检-基线-1.3.0-20260412	改动之前的干净对照，出问题时用来比对
门店助手-交付-配色对齐-3.1.0-20260412	这一版是要交出去的，名字里先声明用途

反过来，下面这些写法就是典型的"半年后找不回来"：

如果你所在的团队习惯用代号而不是应用名，把"应用名"这一格换成代号即可，但请统一：一个应用在项目列表里出现两种叫法（一会儿"记账助手"、一会儿"记账"），搜索时就只能搜两次 —— 命名约定最怕的不是"起得不好看"，而是"同一件事有两种写法"。

还有一类文件同样值得按这套规则起名：附件素材。附件拼给 AI 的文本是「序号. 文件路径 —— 用途说明」，路径里那个文件名会原样出现在发出去的文本里，也会出现在你自己的记忆里。logo.png、新建图片(1).png 这样的名字，在团队共享盘上一天能撞上十几份；而 记账助手_新logo_512_20260412.png 这种名字，即便有人漏看了用途说明，也能一眼认出它属于哪个应用。素材命名可以跟项目名同源：应用 + 内容 + 规格 + 日期，四个词就能把"这是谁的、是什么、多大、哪天的"讲完。

七、两个自家改包实例：名字怎么写，验证怎么做

下面两个例子都是我们自己团队里真实发生过的改包任务，涉及的都是自有应用与内部应用、自有素材。重点看三件事：以前怎么做、现在一句话怎么做、改完怎么验证 —— 以及名字在这三步里起了什么作用。

实例一：给自家「记账助手」换新图标，同时把显示名改成内测版。

以前怎么做：设计给来几档尺寸的 logo，命令行反编译，把图标按密度逐档替换进 mipmap（漏一档就会在某些机型上出现新旧混用），回编、对齐、签名，adb 装机看桌面。更麻烦的是那阵子里"记账助手"同时有好几个目录在改：一个在改图标、一个在试新配色、一个在给运营做演示包 —— 目录名全靠自己记，装错包是常有的事；出包文件名更是各写各的，出现过 记账助手_new.apk、记账助手_改过.apk 这种事后看不懂的名字。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，项目名填 记账助手-内测-图标换新-2.0.0-20260412，在需求框里写"把应用图标换成附件里的新 logo，各密度与自适应图标的前景与背景层一起换；同时把各语言显示名统一改成『记账助手 内测版』"，把新 logo 加为附件并写清用途，点「立刻修改」。

改完怎么验证：AI 改完留下标志文件，程序自动弹出打包窗口跑完回编、对齐、签名、校验四步，最后一步打印出签名证书信息（就是"确实签上了"的那行证据）；三件产物留在项目目录的 build 下，全过程写进 pack.log。点「保存 APK」，默认文件名就是 应用名_版本号_signed.apk —— 出包名天然带版本，不需要你再手动加上去；勾上"打包后自动运行"，程序装到设备并拉起，桌面上看到的图标与名字就是最终结果。半年后要找回这个项目，在项目列表里搜"记账助手"或直接搜包名都能列出来，名字里还写着它是"内测-图标换新-20260412"那一次。

实例二：给内部「巡检打卡」工具换启动页背景图，并且要区分内测与演示两条线。

以前怎么做：先确认背景图在资源里的文件名和目录（几百个文件名里翻），按原尺寸导出覆盖、回编、签名、装机。这里的痛点甚至不在"改"，而在分清装的是哪一个 —— 巡检工具当时有两套需求在跑：一套给内部同事试点，一套用来给上级做演示（演示版要多换一张宣传图）。两个项目目录、两份产物，名字都含糊，装错版本被领导当场看到"这是测试数据"，是很尴尬的一次事故。

现在一句话：两个项目分别起名 巡检打卡-内测-1.4.2-20260412 与 巡检打卡-演示-启动页新图-1.4.2-20260412；演示那一条的需求写成"把启动页背景图换成附件里这张新版宣传图，保持原来的显示比例，不要改其他图片和版权信息"，附件是那张新图、用途说明写清是"演示版启动页背景"。

改完怎么验证：打包完成后勾选"打包后自动运行"，程序用 adb 找手机或模拟器、装包、拉起应用（手机走 scrcpy 投屏到电脑，模拟器把窗口提到最前面），拉起之后还会复核前台应用是不是它 —— 启动页这种"一闪而过"的东西，靠这一条链路看一眼比反复重装十次都省事。要确认自己装的是哪一版，去看设备上应用的版本号，和名字里那段版本号对一下即可；出包默认名 巡检打卡_1.4.2_signed.apk 也带着版本，发给谁都不会串。

这两个例子里，命名带来的变化其实很朴素：它让"这是哪一个"这个问题，在打开项目之前就有答案。 而"改完怎么验证"这半边，靠的是工作流自带的证据链 —— 证书信息、三件产物、打包日志、设备前台复核，名字负责把这次改动和这些证据绑在一起。

顺便说一句：这类"看起来只是习惯"的东西，工具其实已经在很多地方替你铺好了路 —— 新建项目时项目名默认就用解析出来的应用名（省去从零想名字）、保存 APK 的默认名带应用名与版本号、项目列表按创建时间倒序、历史里每条需求都能一键填回输入框。你要做的只是在那一步上多花十秒，把用途和日期补上。

八、用户评价与结语

用户评价：他们是怎么起名的

下面几条来自内部试用与技术交流里的反馈整理，讲的都是习惯层面的真实变化。具体怎么定规矩，还是按你团队的情况来。

结语：名字是这套工作流的入口

把这篇收成一件事：在安卓修改大师智改工坊里，磁盘上的目录名刻意保持"不可读"，名字被交给 config.ini 与界面，所以你写下的那一行字承担了比平时更重的职责 —— 它决定了半年后的你、以及接手这件事的同事，能不能在几秒内找到它、看懂它、重做它。四要素（应用、用途、版本、日期）、固定的分隔符与日期格式、以及"信息各归各层"的习惯，就是把这件小事做对所需付出的全部成本。

于是这套流程可以这样收尾：项目名写清"是哪个应用、给谁用、基于哪版、哪天做的"，需求写成一句能进历史的人话，素材作为附件带着用途说明一起发出去，AI 改完自动回编、对齐、签名、校验，装到设备上看一眼 —— 只需说话，就能让应用变成你想要的样子，而说过的每一句话，都在项目里留下了能找回的位置。

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