一句需求怎么说 AI 才一次改对：给定位、给结果、给边界

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

用久了你会发现一个很真实的现象：决定一次改包成功率的，往往不是模型，而是你写的那句话。 同一款工具，有人写"把应用图标换成附件里的新 logo"就一次过；也有人写"优化一下界面"，然后盯着右边的窗口等一个不知道会不会来的结果。两者输入的都是中文，差距全在信息的密度与锚点上。

这篇不谈玄学，只谈语言学——准确地说，是"把一句人话翻译成一次可执行的修改"这件事的工程学。我们把它拆成五层：好描述的三件套（定位、期望结果、边界）、需求文本的三层结构（你写的原话 / 附件说明 / 环境说明）、附件闸门的设计用意（10 字门槛与去重到底在防什么）、验收标准怎么提前写进需求，最后落到两个自家应用的改包实例上。

一、好描述的三件套：定位、期望结果、边界

先立一个判断标准。一条"能被执行的"需求，至少要让对方知道三件事。缺任何一件，剩下的部分就只能靠猜——而猜出来的结果，正确与否全凭运气。这正是"同样一句中文，两次结果不一样"的根源：不是工具不稳定，而是那句话本身没有把答案固定下来。

把这三件套套进一句话里，你会发现它并不长："把应用图标换成附件里的新 logo（定位），装完后桌面和设置里都是新图标（期望结果），只改图标，应用名保持不动（边界）"——四十来个字，一次说清。真正费劲的不是写字，而是先想明白这三件事。写完再读一遍，如果这三问答得上来，这句话就是合格的。

写法	缺了什么	对方只能怎么处理
优化一下	三件全缺	只能自己挑一处"看起来该优化"的地方动手
界面好看点	三件全缺，且"好看"没有客观标准	大概率去改配色或圆角，改完你未必认
把图标换一下	缺期望结果与来源	得反问"换成什么"，或者自己造一个
把启动页改改	缺期望结果，边界也缺	"改改"可以是一百种改法，你收到的可能不是你想要的
只改应用名，别的不动	缺"改成什么"	边界很干净，但目标还是一个问号
把应用图标换成附件里的新 logo，只改图标	基本齐全	可以直接开工，结果可预期

这张表想说明一件事："优化一下""好看点"这类说法的问题不在于口语化，而在于没有锚点。 锚点是一个可以被指向的东西——一个文件、一个页面、一个你能看到的画面、一条明确的不许。有锚点的句子未必优雅，但可执行；没锚点的句子听起来更像需求，实际只是一句情绪。把情绪翻译成锚点，就是把话说清楚的全部工作。

定位的三种粒度：从"图标"到"详情页左上角那个方形图标"

同一个对象，可以用不同粒度去指。粒度越细，可搜索的范围越小，一次改对的概率越高。以图标为例，从粗到细至少有三种说法：粗——"图标"，包里可能对应几十个候选；中——"应用图标（桌面和设置里显示的那个）"，一句话就排除了通知栏图标、Tab 图标、按钮上的各种小图；细——"应用图标，就是详情页左上角那个方形图标"，连你指的是哪一类都已对齐。

你不需要每次都写到最细，粒度够用就好。判断"够不够用"的标准还是那一句：如果这句话里的对象在你脑子里是唯一的，那它对对方来说也基本是唯一的。 反过来，如果你自己念一遍都觉得"它可能会去改另一个地方"，那就再加半句限定条件——这半句的成本，远低于改错之后重来一轮的成本。

为什么"多写一点"几乎不亏，少写才亏

有个很朴素的规律值得记住：需求写得长一点，通常不会带来额外风险，反而把不确定性压低了。 原因在于需求是被"执行"的，不是被"评分"的——多写一句约束，等于多关掉一扇会走偏的门；少写一句，等于把那扇门一直开着。你不会因为多写了一句"其他保持不动"而被扣分，但很可能因为少写它而多等一轮。

唯一要避免的是自相矛盾：同一句话里既写"只改图标"，又写"顺便把应用名也改一下"，后者就把前者推翻了。写完念一遍，看看有没有两句在互相打架——这一遍花不了十秒，但能拦住相当一部分返工。

字符串类需求：把确切文本用引号圈出来

改应用名、改按钮文字、改弹窗标题这类属于"字符串类"需求，它的翻车点只有一个：你在句子里对这个文本的称呼，和你想要的最终文本不是一回事。 比如你希望桌面显示"巡检助手 内测版"（中间有一个空格），如果只写"改成巡检助手内测版"，那个空格就没有交代；写成"把名称改成『巡检助手 内测版』"——用引号把最终文本原样圈出来，就没有歧义了。

同类细节还有：全角与半角标点、括号用哪种、要不要保留版本号后缀（例如"v2.3"）、大小写。这些都不需要你懂技术，只需要把引号里的东西当成"要印刷出来的字"来对待。引号是需求里最便宜的精确工具。

二、你写的一句话，最后是怎么变成"一段话"的

明白了怎么写，再来看工具这一侧做了什么——这是这篇的技术核心，也是很多人用完一圈都没搞清的部分：你在输入框里写的那句话，和你点「立刻修改」之后真正送出去的那段文字，不是同一份内容。

实际的文本被分成了三层，每一层的归属和用途都不一样：

三层里最值得讲的是第三层，也就是"环境说明"。它是程序固定拼上去的一段操作约定，用户不需要写、也改不到。它交代的是这个工具链自己才关心的事：切到当前项目的工作目录去改（否则对方不知道在哪份工程上动手）、改完在项目目录里留下一个 ai_done.flag 标志文件（主窗口每 2 秒看一次，看到就自动弹打包窗口）、以及"不需要自动打包"（打包由本程序自己回编、对齐、签名，不需要对方代劳）。

这段说明里有一个占位符式的设计：工作目录不是写死的，而是每次发送时替换成当前项目的工作目录。所以你在 A 项目和 B 项目之间来回切换，送出去的那句"切换到……下面进行修改"永远指向对的目录——这也是为什么换项目之后不需要重新配置任何东西。顺带说一句，万一工作目录取不到，程序会把"请将工作目录切换到……"整句去掉，而不是留着拼出"请将工作目录切换到下面"这种病句。宁可少一句，不写半句。

为什么环境说明坚决不写进 history.ini

这是这套分层里最见功力的一处取舍。history.ini 是项目目录里那份"修改历史"，按 记录1、记录2 一节一节递增，界面上的「修改历史」列表读的就是它。它里面只留你写的原话。 如果把整段环境说明也一起存进去，会立刻出现两个后果：一是历史列表被大段固定文字刷屏，"这一条到底改了什么"再也一眼看不清；二是历史记录不再等于"你说过的话"，回填之后你没法判断这句话是不是你当时写的那一条。

换句话说，分层的价值不在省字符，而在于把"可读、可引用的人话"和"每次都要带的机器约定"分开存放。人话进历史，约定每次现拼——历史是给人看的，约定是给执行的人看的，两者的生命周期完全不同。同一节里还存着这条记录的时间（精确到秒），所以翻历史时不只能看到改了什么，还能看到是什么时候改的；一条记录对应一节配置，所谓"删掉某条历史"，落到底就是把那一节删掉，用记事本打开也能做，不需要为它专门做个功能。

还有一个容易被忽略的推论：历史里留的是原话，所以它是"可再次引用"的。 反过来，如果历史里存的是带路径、带环境说明的完整报文，那这句话就只能发一次——路径会变、项目会换，引用它等于引用一份过期的东西。这个设计选择在后面那篇讲"迭代与回看"的文章里还会再碰到一次，它是整套机制的基石。

三、工具怎么帮你把话说清楚：附件闸门与话术库

"给定位"这件事，用户往往缺的不是表达，而是素材。你想换的新 logo、新背景图、新的配置文本，都躺在你的磁盘上。点「选择附件」可以一次挑多个文件（图片、文本、配置文件都能选，也可以直接选"所有文件"），并且给每个文件写一句它是干什么用的。这句话最终会拼成"序号. 绝对路径 —— 用途说明"的格式，跟在需求原话后面一起发出去。

为什么必须逐个写用途？因为一个路径本身不含意图。"D:\素材\figure_03.png"这行字只告诉对方文件在哪，没有告诉它这是要整张替换的图标、还是要从里面抠一部分出来当背景、抑或只是拿来参考配色。附件说明这一栏存在的意义，就是把"路径"升级成"指令"——这也是这套机制里唯一一处强制你写够字数的地方。

这两道校验合起来解决同一类事故：发出去的附件是坏的、或含义不明的，于是整趟改包白跑。 改包不是点一下就出结果的事——要等对方改完、要回编、要对齐、要签名，一轮下来是几分钟到十几分钟。与其跑完一轮才发现路径指错了，不如在点「确定」的那一刻就把不合格的附件拦在门外。这就是"闸门放在上游"的思路：错误越早暴露，付出的代价越小。

也正因为校验发生在"确定"的那一刻，有一个使用要点值得单独提醒：附件不能"先在对话框里填好、过一会儿再点确定"——如果这期间文件被移动、改名、删掉，或者被某个程序独占占用，确定的时候就会被拦下并告诉你原因。这不是刁难，而是把"发过去之后对方读不到"这种更贵的失败，提前换成一句当场能看懂的提示。

另两个设计同样服务于"别让 AI 猜"：同一路径自动去重——同一个文件被选到两次时只保留一条（重复出现的文件会让"听哪条说明"变成一道选择题）；换项目即清空附件——附件是跟着"这一次要发的需求"走的，切换项目就清掉，免得把 A 项目的新 logo 顺手发到 B 项目的需求里。详情页上还会把已附加的文件列出来，显示成"文件名 —— 用途"，点「选择附件」可以改说明或再添几个，也可以一键「清空附件」。

还有一个细节值得知道：附件说明里并不会交代"这个文件该放进工程的哪个位置"——那个判断交给了对方（固定措辞就是"路径是本地绝对路径，需要放进应用里的，请自己决定放到 apktool 工程的哪个位置"）。所以附件的用途说明，才是你能控制的那一半：告诉它这是什么、要用来干什么、有什么约束（正方形、带透明通道、按比例完整显示……），剩下的放置与替换动作，交给它按工程结构去判断。你负责说清意图，它负责落实位置，这条分工线划得非常清楚。

话术库：不会写的时候，先用"填空模板"起步

如果"给定位、给结果、给边界"这套你一时写不顺，工具内置了一条捷径：详情页的「选择话术」会打开话术列表，里面按 6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）放着成型的指令模板，每一条都把要做什么、细节要求、参数参考、范围、验收这几件事写全。

用的时候注意两个按钮的区别，这是新手最容易点错的地方：「选择」是把正文填进需求输入框，你可以接着在它后面补充自己的话（输入框里已经有内容时是追加，不会覆盖掉你写了一半的东西）；「复制」只把正文拷到系统剪贴板，完全不动详情页——适合"这条我想存到别处用"的场景。

话术库的内容放在程序目录下的 Resources\话术库.xml 里，是可以手改的：把你们团队自己常改的那几条沉淀进去，改完点「刷新」重新读一次就生效。文件被删掉或者格式坏了也不会让程序起不来——会退回内置的少量示例话术，并把原因写进诊断日志。这个设计的潜台词很清楚：话术库不是官方的固定菜单，而是你自己的一条"常用需求"清单。

把话术当模板用，最有效的姿势是"挑一条最接近的，然后改三处"：把里面的对象换成你的（改成你的页面名、你的资源名），把范围收窄成你真正要动的那一块，把验收改成你待会儿要看的那个画面。三处改完，一条属于你自己的、带锚点的需求就成型了。这个过程第一次要花两分钟，第三次之后基本就是三十秒——因为它跟写代码不一样，不需要你去查任何文档，只需要你说清你要什么。

四、把"怎么算改对了"提前写进需求

这一节讲的是三件套里"期望结果"的延伸：验收标准也可以写进需求，而且越早写越省事。 要做到这一点，得先知道改完之后到底会发生什么——这条链路是自动的，值得完整讲一遍。

点「立刻修改」之后，需求先写进项目的 history.ini，然后被送进右侧那个被吸附的窗口并回车执行；从这一刻起，主窗口开始盯着项目目录里那个标志文件（每 2 秒看一次）。开始等之前，程序会先清一次同名的残留文件——不然上一轮留下的那个会让主窗口误以为"这一轮已经改完了"。等到标志文件出现，主窗口读到它就把它删掉，然后自动弹出打包窗口，四步走完：

最后那一步不是多余的：前三步看的都是退出码，而"到底签没签上"要 verify 说了算——密钥格式不对这类问题，只有这一步会明确报出来。产物依次落在项目目录的 build 下（unsigned.apk → aligned.apk → signed.apk），全过程写进打包日志。勾上"打包后自动运行"，包还会用 adb 装到手机或模拟器上并拉起应用，装上之后还会用系统命令复核一次前台应用是不是它——避免出现"装上了但没起来、以为改失败"的误判。

这条链路反过来教你怎么写需求：既然最后一定要在设备上看一眼，那就在需求里直接写下"我待会儿要看的那一眼"。 写"桌面图标变新"而不是"改图标"，写"启动页是新的宣传图、完整不裁切"而不是"改启动页"——你写下的那句话，同时就是你的验收清单。等打包装机跑完，看一眼桌面和启动页，验收就完成了，中间不需要任何技术判断。这就是"把验收标准提前写进需求"的全部价值：让最后那一眼有明确的答案可对。

顺带交代一个使用上的边界：等待标志文件这件事有上限（超过一小时就不再等，状态行会写明已停止等待），不会永远挂着"等待中"；等候窗口上可以选「后台等待」把窗口收起来继续等（顶栏会出现一个"AI 修改中"的入口随时叫回），也可以点「取消修改」连对方那边正在跑的生成一起停掉。这些开关的意义是：你随时可以中断，也随时可以接着来——改包这件事从来不是一次定生死的。

五、改写练习：五组句子怎么救活

下面这五组对照，都是从内部试用里真实出现过的说法提炼出来的（左侧保留原语气，右侧是改写）。注意右边的句子并没有变长多少，只是多带了锚点。

原始说法	补上锚点之后
把界面弄好看点	把首页顶部那张卡片改成圆角加浅阴影，其他页面不要动
图标换一下	把应用图标换成附件里的新 logo，桌面与设置里同步生效，其他不动
启动页改改	把启动页背景换成附件里的图，按原图比例完整显示，不要裁切
名字改一下	把应用显示名称改成"巡检助手 内测版"，桌面图标名称一起变
去掉点没用的东西	去掉自家应用启动时那张自家广告位，直接进首页，其余保持不变

最后一行值得单独说。所有"去掉 / 精简 / 优化"类需求，本质都是减法，而减法比加法更容易伤到别处——你删掉的东西可能被别的页面共用。所以这类需求尤其要把"范围"和"除此之外保持不变"写进句子里。这半句不是客套，它是一道明确的止损线。

这四问的顺序是有讲究的：从"定位"到"来源"到"边界"再到"验收"，正好是这条需求从模糊到具体的过程。多数写砸的需求不是不会写，而是从第一步就跳到了第三步——脑子里想的是"我要个新图标"，手下敲出来的是一个没有主语、没有素材、没有边界的动词。

六、两个自家改包实例：把话说清那一刻，活就干完了一半

下面两件事都来自我们自己和同事的日常工作，改的是自家开发的内部应用、用的是自家素材，主线都按"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"来写。

实例一：给自家内部「考勤打卡」工具换底部三个 Tab 的图标，并把应用名改成"考勤打卡 内测版"。

以前的做法：设计同学发来一套 PNG，每张要按密度分别铺到资源目录里；先在资源管理器里找到那几个 ic_tab_ 开头的文件，再对照密度目录逐个覆盖，然后 apktool 回编、手动对齐、手动签名、装到测试机上看底部三个图标。最烦的是漏档——某个密度目录下的图标忘了换，在这种密度的机器上就会看到新旧图标混用的画面，而且往往要等到别人手机上才暴露出来。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，附件里加上三张新图标（顺手再补一张新的应用图标），需求框里写——"把底部三个 Tab 的图标换成附件里的三张图（按文件名顺序对应首页、打卡、我的），同时把应用显示名称改成『考勤打卡 内测版』；只改这两处，页面布局和文字不要动"。附件那一栏给每张图各写一句用途，比如"首页 Tab 图标，选中态用这一张"。

为什么这句话能一次成？因为它把三件套给全了：定位（底部三个 Tab 的图标、分别对应哪一页）、期望结果（桌面名称与 Tab 图标都变）、边界（只改这两处）。附件说明又把"每张图给谁用"钉死了——这恰好绕开了"一个路径不含意图"的坑。改完怎么验证？标志文件出现后自动弹打包窗口，回编、对齐、签名、校验四步跑完；勾上"打包后自动运行"，包会装到手机或模拟器上并自动拉起，看一眼底部图标和桌面名称就够了。最后一步的签名校验会打印证书信息，用来确认"确实签上了"，而不是只看前几步的退出码。

实例二：给内部「门店巡检」应用换掉启动页背景图。

这是给巡检同事用的内部工具，启动页背景是上一版活动的旧图。以前要找背景图在资源里的位置，把新图按原尺寸导出覆盖，回编签名装机，再看启动页——启动页一瞬就过去，同事常要装三四次才确认换的是哪张。

现在一句话：写"把启动页背景图换成附件里这张新版宣传图，按原图比例完整显示，不要裁切也不要拉伸；只改启动页背景，其他页面和文案保持不动"，附上新图并写清用途。这里的边界句是关键——"不要裁切"这四个字，直接决定了这张图最后是完整出现还是被裁掉两边。 改完的验证链路和实例一相同：自动打包、自动装机拉起，看一眼启动页；启动页一闪而过看不清，就在设备上把应用关掉再打开一次。改的是哪张图、装的是哪个包，全程都在同一个项目目录里，不存在"我到底装的哪个版本"的疑问。打包产物在项目目录的 build 子目录依次留下未签名、已对齐、已签名三个中间件，全过程写进打包日志，哪一环出问题都查得到——万一这一版不满意，需求原话还在历史里，改两句再发一次就是了。

两件事做完回头再看，最省时间的其实不是"少打字"，而是少返工：一句带锚点的需求，省掉的是"改完发现不是我要的、再等一轮"的十几分钟。这就是这篇想传递的东西——把话说清楚不是额外成本，它本身就是最短的路径。

七、用户评价：他们是怎么把话说清楚的

八、结语：把话说到能验收，需求就写完了

把这篇收成三句话：好描述 = 定位 + 期望结果 + 边界；你写的原话进历史，附件说明跟着原话，环境说明永远压在最后；附件闸门放在上游，为的是不让一轮改包白跑。 这套东西没有一句要求你懂安卓，判断标准也很简单——如果这句话改完之后，你能明确说出"我看到什么才算成功"，那它就已经是一条合格的需求了。

这也是安卓修改大师智改工坊想做成的事：把"改包"从一串需要记得住的工具链动作，变成一次把话说清楚的沟通。左边写下需求，右边按这句话动手，改完自动回编、对齐、签名、校验，再一键装到设备上看结果——只需说话，就能让应用变成你想要的样子。

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