3000 条话术与提示词工程：电脑版把需求说清楚的技巧

很多人第一次打开安卓修改大师电脑版，会觉得这件事很简单：把 APK 拖进去，在详情页打一句话，点“立刻修改”，等进度走完，装到手机上看效果。真正上手后才发现，卡住人的从来不是工具，而是那句话本身。“帮我把界面弄好看一点”“开屏广告太烦了，去掉”“名字改成我们公司的”，这些话在同事听来毫无障碍，交给 AI 却处处是歧义。

原因不复杂。人与人沟通时，双方共享大量没有说出口的背景：这是哪个项目、给谁用、上一版长什么样、哪些地方不能碰、做完谁来验。AI 工作区没有这些背景，它只有你写下的文字，以及 APK 反编译后展开的工程。你写得越省，它猜得越多；它猜得越多，返工越贵。

一、会说话不等于会写可执行需求

更麻烦的是，APK 不是一个平面文件，而是好几层结构叠在一起。资源层放图标、文案、颜色、布局；代码层放业务逻辑；清单层声明应用名、包名、权限、启动组件；资产层放网页、配置、字体；最外面还有签名。同一句“改名字”，落在不同层，结果完全不同。

你说的话	AI 可能理解成	改错后的表现
“改个名字”	桌面显示名、包名、关于页文案、版本名	桌面没变、安装冲突、关于页还是旧名
“换图标”	最高密度图标、自适应前景、圆形图标、通知小图标	桌面变了、设置里还是旧图、部分机型被裁切
“去掉开屏”	删广告控件、删整个启动页、跳过倒计时、换启动图	白屏、登录路由丢失、首帧闪烁
“改网址”	首页 WebView、关于页链接、接口地址、分享链接	只改一处、正式环境仍连测试、外链打不开
“美化一下”	换主题色、调间距、换字体、重排布局	改到别的页面、品牌色不一致、文字被截断

表格里没有一项是 AI 故意改错，全部是“信息不足时的合理猜测”。它选了最常见的路径，却没有机会知道你心里的那条路径。需求写得含糊，执行就会变成抽签；抽中了是运气，抽不中是常态。

所以，在这个工具里，“提示词工程”不是背几句咒语，而是把脑中的画面翻译成一份可执行、可检查的合同。合同至少要回答四件事：改哪里、改成什么、不能动什么、做完怎么算通过。后文把这四件事称为“四要素”。

新手常见三个误区。第一，把愿望当指令：“高级感”“流畅”“大气”都是审美判断，不是工程参数。第二，把实现当需求：一上来指定某个文件、某一行、某种写法，反编译后的工程结构与想象不一致时，需求直接失效。第三，把十件事塞进一段话：图标、名字、广告、接口、文案一起改，任何一项出问题，都很难判断是哪一句造成的。

这三种误区的代价也不同。愿望式需求带来“改错层”，实现式需求带来“改不动”，倾倒式需求带来“改坏了也说不清”。而返工的成本，不只是再点一次“立刻修改”，还包括重新安装、重新走验收、重新确认签名与版本，以及团队里其他人对这次改动失去信心。

把话说清楚，本质上是把“我觉得”换成“可观察”。可观察的东西不依赖心情：图标出现在桌面第几屏、应用名显示在设置里的哪一行、冷启动后第一帧是什么、日志里有没有异常、签名证书是不是自己那把。只要这些能写出来，AI 就有了明确的落点，你也有了明确的裁判标准。

还有一点需要提前说明：说清楚不等于写长。一份好的需求可以只有三句话，但三句话里必须同时有对象、结果、边界和验收。反过来，一份堆了五百字形容词的需求，可能连“改哪个图标”都没说。长度不是标准，信息密度才是。

当你开始用“对象、效果、边界、验收”去审视自己的表达，会发现很多原本以为很清楚的话，其实只是情绪。情绪可以留在第一稿，用来记录你想解决什么问题；但送进 AI 工作区的，必须是去掉情绪之后仍然成立的那一版。这个转换过程，就是本文要讲的“把需求说清楚”。

二、3000 条话术库：6 大类×500 条，先学“名词”再学“句式”

安卓修改大师电脑版的详情页提供了 3000 条话术，按 6 大类组织，每类 500 条：界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。它们不是“点一下自动完成”的按钮，而是可点选填入输入框的句式模板。点选之后，你仍然要把它改成自己的对象、补上边界和验收。

为什么是 6 类、每类 500 条？因为真实需求的长尾很长。同样是换图标，有人要换自适应图标，有人只换某个密度目录，有人还要同步通知栏小图标；同样是加弹窗，有人要首次启动弹一次，有人要每天最多一次，有人要带“不再提示”。500 条覆盖的是表达方式与场景组合，不是 500 个功能按钮。

类别	它解决什么	典型诉求	写的时候必须补什么	验收看什么
界面美化	让外观贴近品牌	图标、应用名、启动页、主题色、文案、间距	资源位置、尺寸或色值、影响范围	桌面、设置、启动首帧、目标页面
弹窗引流	在自有应用内增加提示与入口	公告弹窗、更新提示、活动入口、引导页	触发时机、频率上限、关闭方式、跳转目标	首次启动、二次启动、关闭后是否再弹
去除限制	调整自有应用的内部限制	内测白名单、调试开关、重复校验、冗余拦截	仅限自有应用、保留安全校验、回退方案	目标限制消失、其他校验仍在
常规修改	改配置与基础信息	版本名与版本号、接口地址、WebView 网址、文案	旧值与新值、出现位置、环境归属	关于页、接口请求、页面加载
混淆去毒	自有应用二次开发前的清理与审计	冗余代码、异常权限、可疑网络调用、重复壳层	审计范围、保留清单、改动记录	权限列表、启动日志、核心功能
插件添加	给自有应用加小模块	分享入口、公告栏、日志面板、外链页面	入口位置、权限、失败降级	入口可见、点击可用、异常不崩

这张表最重要的不是“功能清单”，而是最后一列。话术库负责让你把话说得像行话，验收列负责让你把话说完。只点话术、不看验收，等于只写了上半句。上半句决定 AI 往哪走，下半句决定你能否判断它走对了没有。

话术库对新手最大的价值，其实是补名词。没做过改包的人，不知道“应用名”和“包名”是两回事，不知道“启动页”和“开屏广告”经常住在同一个启动组件里，不知道图标还分自适应前景、背景和圆形图标，也不知道版本名是给用户看的、版本号是给系统比较的。名词不清楚，句子一定写不准。

你嘴里的说法	工程里的对象	建议写法
“名字”	应用显示名、包名、版本名	“只改桌面与设置里显示的应用名，包名保持不动”
“图标”	各密度 mipmap、自适应图标、圆形图标	“替换最高密度桌面图标，并同步圆形图标”
“开屏”	启动页、广告倒计时、引导页	“移除自家开屏广告倒计时，保留登录路由”
“网址”	WebView 首页、接口域名、分享链接	“只改首页 WebView 的初始网址，接口域名不动”
“版本”	versionName、versionCode	“版本名改为 2.3.0 内测，版本号加一”

有了名词，再学句式。话术库里的句子大多遵循“动作 + 对象 + 结果”的骨架，例如“将【对象】替换为【附件一】，保持【约束】不变”。你要做的是替换方括号里的内容。直接把模板原样发出去，AI 只能按模板里的占位描述猜；把方括号填满，模板才变成需求。

正确用法可以收敛为五步。第一步，在 6 类里找最接近的场景，而不是找最长的句子。第二步，把模板里的通用名词替换成你项目里的真实对象，最好带上页面名或资源名。第三步，补四要素，尤其是“不要动什么”。第四步，有图、有文案、有对照稿就挂附件，并在正文里用“附件一、附件二”指代。第五步，一次只推进一类改动，改完验收，再做下一类。

错误用法也很集中。有人连点十条话术，让它们一起填进输入框，结果十条需求互相覆盖；有人把“去除限制”理解成万能钥匙，却忘了它只适用于自有应用的内部限制；有人把话术当许愿池，只写一句“按这个模板做”，既没有对象也没有验收。话术库降低的是起步难度，不替你承担定义需求的责任。

还有一个容易被忽略的细节：话术库是“检索式学习”的好材料。你不必从第一条读到第五百条，而是带着问题去搜：想改启动图，就搜“启动页”；想加公告，就搜“弹窗”；想统一品牌，就搜“文案”。找到三条相近的，比较它们的差异，你很快就能看出哪些信息是必须写的，哪些是可选的。这个比较过程，比背模板有用得多。

最后提醒一句：话术库里的分类名称本身也是提示。界面美化提醒你“改的是可见层”，弹窗引流提醒你“要定义触发与频率”，去除限制提醒你“先确认权限边界”，常规修改提醒你“旧值与新值都要写”，混淆去毒提醒你“先审计再动手”，插件添加提醒你“入口、权限、降级三件事”。把这六个提醒记住，即使不点开任何一条话术，你也能写出及格的需求。

三、一条可执行需求的四要素：目标、效果、边界、验收

判断一条需求能不能被执行，有个很朴素的办法：把它交给一个不了解你项目的人，看对方能否在不追问的情况下动手，并且做完之后你能明确说“对”或“不对”。如果对方必须追问三个以上问题，或者你只能说“感觉不对”，这条需求就还没写完。

四要素就是为这个判断服务的。目标回答“改哪里”，效果回答“改成什么”，边界回答“不能碰什么”，验收回答“怎么算完成”。它们不是公文格式，而是四个必须被消除的歧义源。下面逐项拆开，每一项都给出反例和可执行写法。

1. 目标：改哪个对象，它现在在哪

目标要唯一。说“改图标”不唯一，因为一个应用可能同时存在自适应图标、多个密度的 PNG、圆形图标、通知栏小图标；说“替换桌面图标，优先最高密度，并同步圆形图标”才唯一。目标还要带位置线索：页面名、资源名、字符串内容、组件名都行，不必精确到行号，但必须让人能找到。

位置线索最好用“现在长什么样”来描述，而不是只给一个抽象名称。例如“设置页顶部那张蓝色横幅，文字是‘立即升级’”比“设置页 banner”更容易定位；“启动后第一屏，底部有跳过按钮的那个页面”比“开屏”更明确。对 AI 来说，现状描述是锚点；对你来说，现状描述也是验收时的对照物。

如果一次要改多个对象，列清单并编号。不要写“图标和名字都换一下”，而要写“本轮改两个对象：一是桌面图标，二是应用显示名；两项互不依赖，若只能完成一项，先完成图标”。编号让 AI 知道范围，也让失败时的沟通有抓手。

目标的反例：“把应用弄成我们品牌的样子。”
可执行写法：“改三个对象：桌面图标、启动页背景、设置页顶部横幅；其余页面不动。”

2. 效果：改成什么，用什么能看出来

效果要可观察。文案要逐字给出，包括全角半角、空格、标点；颜色给色值；尺寸给单位；位置说清相对关系；行为说清触发时机、持续时长、次数上限、跳转目标。凡是不能用眼睛、手指或日志确认的描述，都应该被替换掉。

“好看”不是不能写，而是要翻译。比如“主色改为深蓝 #0F172A，卡片圆角 16dp，标题字号保持 20sp，页面左右留白比现在多，入口数量不变”，这段话仍然包含审美判断，但大部分已经变成可对照的参数。再附一张参考截图，剩下的主观部分也有了锚点。

行为类效果尤其要写时机。公告弹窗是“首次启动弹一次”，还是“每天首次启动弹一次”，还是“每次冷启动都弹”？关闭方式是点“我知道了”还是点遮罩？关闭后本轮不再弹，还是永久不再弹？这些不写，AI 只能选一个默认值，而这个默认值大概率不是你想要的。

效果的反例：“弹窗做得友好一点。”
可执行写法：“首次启动弹出公告，标题‘服务时间调整’，正文三行以内，按钮‘我知道了’；点击按钮或遮罩关闭，同一版本内不再弹出。”

3. 边界：哪些不能动，冲突时听谁的

边界是四要素里最容易被省略、也最影响结果的一项。AI 在工程里做局部修改时，会沿着引用关系找相关文件；如果不给否定清单，它可能顺手统一了文案、调整了布局、替换了同名资源。多数时候它不是越权，而是“既然改了，就一起改干净”的合理推断。

边界要写成否定句和保留清单：包名不动、签名材料不动、权限不动、最低系统版本不动、其他语言不动、登录与支付流程不动、接口域名不动。哪些必须保留，也直接说：保留启动页的登录路由，保留版本检查，保留原有返回逻辑。否定句比肯定句更能约束范围。

还要写冲突时的优先级。资源替换经常遇到“改了 PNG 但自适应图标仍指向旧前景”的情况；启动页替换经常遇到“新图比例与屏幕不一致”的情况。提前写一句“若图标与自适应图标冲突，以桌面显示正常为优先；若启动图比例不符，保持铺满不拉伸并裁切边缘”，AI 就有决策依据，不必停下来猜。

最后写回退。不是每个需求都能一次成功，边界里应该包含失败时的动作：“若移除广告导致启动白屏，回退原启动流程，保留其他修改，并在结果里说明原因。”这句话的价值在于限制损失范围：失败时你拿到的是一份可用的旧版本加一份说明，而不是一个半坏的新包。

边界的反例：只写“改启动页”，不写保留什么。
可执行写法：“只换启动页背景图；启动路由、登录状态检查、版本检查、包名、签名、权限全部保持原样；若新图导致拉伸，按铺满裁切处理；失败则回退原启动流程。”

4. 验收：在哪台设备、看哪几步、什么算通过

验收要写成别人可以照做的步骤。设备写清型号与系统版本，安装方式写清是覆盖安装还是先卸载，检查步骤按顺序列出来，通过标准写成“看到什么算对”。验收不是“我看看”，而是“我按这五步看，五步都对才算过”。

验收项要覆盖四层：包层看签名与对齐，安装层看能否装上与拉起，视觉层看图标、名称、启动页、目标页面，行为层看登录、跳转、返回、二次启动。只验视觉不验行为，容易漏掉启动路由；只验行为不验包层，容易在分发时才发现签名不对。

证据也要提前约定。截图留存哪几屏，日志看哪几个文件，签名用哪条命令核对，前台应用怎么确认。把这些写进需求，AI 完成后的结果才有可比对的对象；否则每次验收都靠记忆，换个人就说不清。

验收的反例：“改完发我看看。”
可执行写法：“在 Android 14 真机上先卸载旧版再安装；冷启动三次，确认桌面图标清晰、设置里应用名正确、首帧为启动图、能进入登录页；保留三张截图与安装日志。”

要素	一句话提问	常见反例	可执行写法
目标	改哪个对象的哪一处？	“改图标”	“替换桌面自适应图标与最高密度 PNG”
效果	改成什么，肉眼或日志怎么确认？	“弄好看点”	“应用名改为 XX 助手 内测版，逐字一致”
边界	哪些不能动，冲突时优先谁？	不写	“包名、签名、权限、登录路由不动”
验收	在哪台设备看哪几步？	“改完我看看”	“真机冷启动三次，图标、名称、首帧、登录均正确”

把四要素拼起来，可以得到一个通用模板。它不是让你每次都写满，而是提醒你别漏。熟练之后，模板会压缩成三句话；但在新手阶段，写满比省略安全。

通用模板

【目标】在______（对象或页面）上，把现在的______改成______。

【效果】完成后应看到______；文案逐字为______；颜色或尺寸为______；触发时机为______。

【边界】不要改动______、______、______；若与______冲突，以______优先；失败时______。

【验收】在______设备上，按______步骤检查；通过标准是______；证据保留______。

填个例子，感受一下信息密度的变化：“【目标】把自家记账 App 的桌面图标换成附件一，应用显示名改为‘XX 助手 内测版’。【效果】桌面图标清晰无白边，设置里应用信息与最近任务显示新名称。【边界】包名、版本号、签名、权限、记账页面不动，关于页公司名不改。【验收】Android 14 真机卸载重装，冷启动两次，查看桌面、设置、最近任务三处，签名证书为自有证书。”

这段需求不到两百字，但每一个分句都能被检查。它没有规定 AI 用哪个工具、改哪个文件、按什么顺序做，却把结果和边界钉死了。这就是“结果写死、实现放开”的写法，也是后文反复要用的基准。

还有一个顺序建议：先写验收，再写目标与效果。因为验收逼你回答“我到底要看什么”，很多模糊词在这一步就会暴露。比如你写“界面更清爽”，一到验收就发现无法判断；改成“首页只保留三个入口，其余入口收进更多菜单”，验收立刻具体，目标也随之清晰。验收不是最后一步，它经常是最好的起点。

四、同一需求三种写法：从“许愿”到“可执行合同”

理论讲完，最有用的还是对照。下面挑三个改包时最常见的需求：换图标加改内测名、去自家开屏广告加换启动页、把 WebView 首页换成自家站点。每个需求给出三种写法，分别代表许愿、半成品和可执行合同，并说明 AI 大概率会怎么处理。

场景一：换图标 + 改内测名

写法 A（许愿）：“帮我换个图标，名字改成内测版。”这句话只有两个模糊对象，没有附件、没有精确名称、没有边界。AI 大概率会找一个它能定位的图标资源替换，改一处应用显示名，然后结束。结果可能是：高分辨率屏幕上图标发虚，因为只换了低密度；圆形图标还是旧的；应用名变成“内测版”三个字，而不是“XX 助手 内测版”；包名没变，但关于页仍是旧品牌。你不能说它没做，只能说它没按你想的做。

写法 B（半成品）：“把桌面图标换成附件里的 logo，应用名改成‘XX 助手 内测版’，不要改包名。”比 A 好很多：有附件、有精确文案、有一条边界。但它仍然没说什么叫“桌面图标”（自适应、圆形、各密度怎么处理），也没说名称要在哪些位置生效，更没写验收。AI 可能只替换一个 mipmap，部分启动器仍显示旧图；设置里的名称变了，最近任务却还是旧名。边界只写了包名，其他资源仍可能被顺手统一。

写法 C（合同）：“【目标】替换自家记账 App 的桌面图标与应用显示名。图标用附件一（1024×1024 PNG，透明背景），同时覆盖自适应图标前景与圆形图标；应用名改为‘XX 助手 内测版’，逐字一致。【效果】桌面、设置里的应用信息、最近任务三处都显示新图标与新名称，图标无白边、无裁切。【边界】包名、版本号、签名、权限、登录与记账页面均不改；关于页里的公司名不改；若自适应图标与 PNG 冲突，以桌面显示正常为优先。【验收】Android 14 真机先卸载旧版再安装，冷启动两次，检查上述三处；签名证书为自有证书，打包日志四步完整。”

维度	写法 A	写法 B	写法 C
目标	模糊	基本明确	唯一且带位置
效果	无	文案明确，视觉未定义	三处可见结果
边界	无	只保包名	保留清单加冲突优先级
验收	无	无	设备、步骤、证据齐全
预计结果	多轮返工	小修后可用	一轮可验收

场景二：去自家开屏广告 + 换启动页

写法 A（许愿）：“开屏广告去掉。”这句话最危险的地方不是模糊，而是它可能被理解成“删掉整个启动页”。启动页往往同时承担广告展示、登录状态检查、路由分发三件事。删掉广告控件是安全的，删掉整个页面就可能白屏，或者绕过登录检查直接进首页。AI 不一定知道你的启动页里还有什么，你也没告诉它。

写法 B（半成品）：“开屏广告不要显示，直接进首页，启动图换成附件。”比 A 明确，但“首页”可能要求登录，“直接”没有说首帧怎么处理，“启动图”没有说比例和裁切。AI 可能把广告倒计时去掉却留下空白页，也可能跳过登录检查。启动图比例不对时，它可能拉伸，也可能留黑边，两种都不一定是你想要的。

写法 C（合同）：“【目标】移除自家内部工具启动时的自家开屏广告，包括倒计时与跳过按钮；启动页背景替换为附件二。【效果】冷启动后首帧为附件二，竖屏铺满、不拉伸；广告不再出现；随后进入登录页，已登录用户直接进入工作台。【边界】保留登录状态检查、版本检查与崩溃日志；不改包名、签名、权限；若广告组件被其他页面引用，保留引用但不再展示；若替换导致白屏，回退原启动流程并说明。【验收】Android 13 与 Android 14 各冷启动三次，首帧正确、无白屏、无跳过按钮、登录可用；运行日志无未处理异常；打包日志四步完整。”

三种写法的差别，不在字数，而在“可失败性”。A 和 B 失败时，你很难判断是哪一步错了；C 失败时，边界和验收会告诉你损失范围：是图标没换全，是启动图比例不对，还是启动路由被破坏。可失败性越高，修起来越快。

场景三：把 WebView 首页换成自家站点

写法 A（许愿）：“把网址换成我们的。”一个应用里可能有三类网址：WebView 首页、接口域名、分享链接。AI 不知道“我们的”是哪个域名，也不知道是测试环境还是正式环境。更常见的情况是：它改了首页，却没改重定向；首页打开是新的，点进详情又跳回旧站；或者它把接口域名一起改了，登录直接失败。

写法 B（半成品）：“首页 WebView 打开 https://m.example.com/activity，别改接口。”方向对了，但还缺几件事：协议是否必须 HTTPS、是否需要允许混合内容、旧地址出现多次时是否全部替换、离线或加载失败时显示什么、返回键是否留在应用内。这些细节不写，AI 会按常规处理，常规处理不一定符合你的站点策略。

写法 C（合同）：“【目标】只改自家展示 App 首页 WebView 的初始地址，改为 https://m.example.com/activity；接口域名、分享链接、关于页链接不动。【效果】冷启动后首页加载新地址；页面内跳转仍在新站；加载失败显示应用内错误页，不弹系统浏览器；返回键先回上一页，到首页后再退出。【边界】不改网络权限、不改 WebView 其他配置（缓存、缩放、用户代理）；若旧地址在代码中出现多处，只替换首页初始化那一处；遇到混合内容拦截时优先保持 HTTPS，不回退 HTTP。【验收】真机冷启动两次，确认首页地址、站内跳转、失败提示、返回行为；抓包或日志确认接口仍走原域名。”

这三个场景可以总结出一条通用规律：写法 A 是“我想要”，写法 B 是“我知道要改什么”，写法 C 是“我知道改成什么、不能碰什么、怎么算完成”。从 A 到 C 不是把句子变长，而是把隐含信息逐层显式化。你甚至可以先用 A 记录想法，再用 B 找到对象，最后用 C 补边界和验收。

一句话记住三种写法：A 让 AI 猜，B 让 AI 做，C 让 AI 交作业。猜的结果看运气，做的结果看经验，交作业的结果才能验收。

需要说明的是，写法 C 并不是越细越好。它细在“可观察的结果”和“不可触碰的边界”，而不是细在“你必须先改哪个文件、再改哪一行”。前者是需求，后者是施工方案。施工方案应该留给执行方，尤其是在反编译工程里，资源名、类名、行号都可能与源码不同。

如果你只能记住一个改写动作，那就是把“帮我改一下 X”改写成“把 X 从 A 改成 B，别动 C，做完我看 D”。这个句式几乎适用于所有改包需求：图标、名称、启动页、文案、颜色、接口、弹窗、入口。它不优雅，但足够可执行。

还有一个实战技巧：把写法 C 拆成“发送版”和“验收版”。发送版给 AI 看，重点是目标、效果、边界；验收版给自己看，重点是步骤、证据、通过标准。两份可以完全一样，也可以验收版更细。分开之后，你不会因为验收步骤太长而把发送版也写得啰嗦，也不会因为发送版太简略而在验收时临时想标准。

五、附件与历史：把上下文一次说清

四要素解决“话怎么写”，附件和历史解决“背景怎么带”。改包需求很少只靠文字完成：图标要原图，启动页要新图，公告要正文，配置要对照。把这些东西挂在需求里，AI 才能看到你看到的；把每次原话留下来，你才能在下一轮少走弯路。

附件不是“顺手带上”，而是需求的一部分

安卓修改大师电脑版允许一次选择多个附件，每个附件都要写用途，用途不少于 10 个字。发送前会校验文件是否存在、不是目录、不是 0 字节、可读取；校验通过后，附件会按“序号 + 路径 + 说明”的形式拼进需求，一起发给 AI。这个设计看起来只是防呆，实际上解决的是改包里最常见的一类返工：附件在，但 AI 不知道它该用在哪。

为什么是 10 个字？因为文件名几乎不携带用途信息。“logo.png”可能要做桌面图标，也可能要做启动页、关于页、通知栏小图标；“文案.txt”可能是公告、按钮、隐私条款、更新说明。10 个字逼你写出“是什么、用在哪、有什么限制”，这三件事凑一凑，基本就超过 10 个字了。少于 10 个字，通常不是你不会写，而是你还没想清楚这个文件要干什么。

附件名	不及格的说明	合格的说明
logo.png	“图标”	“桌面图标原图，1024×1024，透明背景，用于替换最高密度”
notice.txt	“文案”	“公告弹窗正文，三行以内，保留换行，标点不要改”
splash.jpg	“启动图”	“竖屏启动页背景，1080×1920，铺满不拉伸，边缘可裁切”
config.json	“配置”	“内网接口配置，只改 baseUrl，其余键保持原值”

附件说明最好写成“用途 + 目标位置 + 限制”的三段式。用途回答“它是什么”，目标位置回答“用在哪”，限制回答“不能怎么用”。三段齐全，AI 不需要猜，你验收时也有对照。比如“启动页背景，用于替换第一屏，1080×1920，铺满不拉伸”，既是说明，也是验收标准的一部分。

多个附件要编号，并在正文里用编号指代。附件顺序变了，映射就会错；正文写“附件二用于公告”，附件区却把公告排在第一，AI 可能把公告正文塞进启动页。发送前扫一眼顺序，比事后返工便宜得多。附件说明里也不要把多个用途混在一句话里：一个附件只承担一个明确用途，复杂的改动用多个附件表达。

校验规则的意义也值得说清楚。文件不存在，AI 拿到的是一个空路径；文件是目录，读取会失败；文件是 0 字节，等于没有内容；文件不可读，执行到一半才报错。这四种情况如果等到 AI 工作区才发现，浪费的是一整轮反编译与回编。发送前校验，等于把错误挡在成本最低的地方。

附件里不要放敏感信息。签名口令走环境变量，不要写进需求正文，也不要塞进文本附件；包含个人信息的通讯录、订单、后台截图，先脱敏再挂；与本次需求无关的大文件不要挂，附件越多，AI 分辨用途的成本越高。附件是上下文，不是仓库。

history.ini 为什么只留原话

点“立刻修改”时，安卓修改大师电脑版会把需求原文和日期写进项目的 history.ini，然后把需求送进右侧 AI 工作区执行。注意，它只留用户原话，不留 AI 改写后的版本，也不留执行过程中的中间描述。这个选择看起来保守，实际上非常关键。

如果历史里存的是 AI 改写后的长提示，下一次回填就会在改写的基础上再改写，几轮之后，需求会越来越长、越来越偏，最后连你自己都说不清最初想改什么。只留原话，回填出来的就是当时那句原话，语义不会漂移。你可以改一个字再发，也可以原样重跑，差异永远可比较。

只留原话还带来两个好处。第一，可审计：出了问题，回看历史就知道当时怎么说的，不必猜 AI 有没有“加戏”。第二，可对比：同一版应用、两套文案，分别用两句原话改，装出来对比截图，哪套更好一目了然。如果历史里混入了执行细节，对比就不再是需求对比，而是提示词长度对比。

历史在详情页里最新在上，保留完整原文，右侧有“选择”可以回填到输入框。项目列表里也能查看历史、删除项目，删除只允许针对 Project 直接子目录。这个限制是有意的：项目目录里同时放着源包、反编译工程、构建产物和日志，误删的代价很高。删除前确认项目名，重要版本先另存备份。

历史不包含 AI 的输出、截图和日志，所以验收证据要另外留。比较稳妥的做法是：每轮改完，把需求原文、安装截图、关键日志放在同一个命名规则下，例如“日期-项目-需求关键词”。下次回填历史时，你能同时找回当时的话和当时的结果，而不是只找回半条线索。

历史回填的四种用法

第一种，复用。每月发内测版，流程几乎一样：改版本名、改版本号、换一张启动图、重新签名。回填上个月的原话，只改版本号和附件，其他边界与验收照旧。这样既不会漏掉“包名不动”的边界，也不用每次重新组织语言。

第二种，对比。同一版应用做两套首页文案，A 套强调活动，B 套强调功能。复制项目，分别回填两句话，改完各装一台测试机，按同一套验收步骤截图对比。历史保证两句话都是原话，差异只来自文案本身，不受提示词长度干扰。

第三种，回滚。新需求改坏了，回填上一轮成功的原话，重新执行，先恢复到可用状态，再分析新需求哪里写错。回滚不是失败，而是把损失限制在一轮之内。配合项目里保留的 source.apk，你始终有一条回到起点的路。

第四种，沉淀模板。某条需求一次通过，把它的结构抽出来，去掉项目专有名词，变成自己的模板：目标句式、边界清单、验收步骤。下次遇到同类需求，先套模板再改名词。积累十几条模板之后，你写需求的速度会明显快于翻话术库。

回填的正确姿势是“只改差异”。回填后先把整段读一遍，确认对象、附件编号、版本号、设备名都还是这次的值，再动笔。历史里最危险的不是旧需求，而是旧需求里的专有名词：上一个项目的应用名、上一台设备的型号、上一版附件编号，任何一个没改，都会把 AI 带偏。

一条实用规则：历史回填只复用“结构与边界”，不复用“对象与附件”。结构越稳定越好，对象越具体越好。把这两类信息分开看，回填就不会变成复制粘贴事故。

六、太虚与太细：两种失败，以及一张自检清单

需求写不好，通常不是“不够努力”，而是掉进了两个相反的坑：太虚和太细。太虚让 AI 自由发挥，太细让 AI 走进死胡同。两种失败的表象不同，根因相同：把“我关心的事”和“执行需要的信息”混在了一起。

太虚：把形容词当需求

典型句式是“好看一点”“高级一点”“流畅一点”“简洁一点”“你看着办”。这些词不是没有信息，而是信息无法落地：好看是相对谁好看，高级是参考哪个品牌，流畅是启动快还是滑动稳，简洁是减少入口还是减少颜色。AI 只能按常见做法选一个，选完你大概率不满意，因为你心里的参照物从来没说出来。

太虚的需求还有一个隐蔽问题：它会诱发过度修改。你只说“美化首页”，AI 可能改颜色、改间距、改字号、改图标风格，甚至重排布局。改得越多，回归风险越大。最后你面对一个“确实变了但说不上哪里不对”的版本，既不敢发，也不知道从哪改回去。

解法是把形容词翻译成参数或参照物。颜色给色值，尺寸给单位，位置给相对关系，风格给参考截图，范围给页面清单。翻译不完的部分，明确写“保持现状”。比如“只改主色和按钮圆角，布局、字号、入口数量、页面结构全部保持现状”，这句话本身就挡住了大部分过度修改。

太细：把实现当需求

另一个极端是把需求写成施工图纸：指定某个布局文件第几行、某个 smali 方法的哪一条指令、某个资源 ID 必须换成另一个。反编译工程与源码工程不完全一样，资源名可能被混淆，行号会随版本变化，类名可能被拆分或合并。你写得越具体到实现，越容易在第一步就卡住。

太细还会制造冲突。比如同时要求“图标必须用附件原图，不能压缩”和“安装包体积不能增加”，这两个条件在某种格式下可能互相打架；又比如要求“启动页必须瞬间显示”和“启动时完成登录检查”，时机上也需要权衡。条件越多，冲突概率越高，AI 只能挑一个执行，剩下的被你当成“没听懂”。

解法是约束结果，不约束实现。你可以要求“桌面图标清晰、无白边、圆形与方形都正常”，但不必规定 AI 用哪个工具、改哪个目录、按什么顺序压缩。你可以要求“冷启动首帧为启动图，不出现白屏”，但不必规定它删哪一行代码。结果是你的责任，实现是执行方的责任。

甜点区：结果写死，实现放开

太虚和太细之间，有一个很窄但很稳定的区间：结果写死，实现放开。具体表现为五条原则。一次只推进一个主题；效果用可观察的事实描述；边界用否定句列清楚；验收先写、步骤可照做；附件只放必要材料并写明用途。做到这五条，需求不一定漂亮，但大概率能执行。

为什么“一次一个主题”重要？因为改包是多步骤链路：反编译、改资源或代码、回编、对齐、签名、安装。多个主题混在一轮，任何一步失败都难以定位；分开之后，每一轮都有独立的成功标准，失败也能单独回退。图标和启动页可以分两轮，文案和弹窗可以分两轮，接口和视觉永远不要放同一轮。

为什么“验收先写”重要？因为验收是唯一能逼你把“感觉”变成“事实”的环节。你先写“冷启动三次，首帧为启动图，无白屏，登录可用”，再回头写目标，很多模糊表述会自动被淘汰。验收写得出来，需求就写得好；验收写不出来，说明你还没想清楚要什么。

自检问题	如果答案是“否”
1. 我写清楚要改的对象了吗？	补页面名、资源名或现状描述
2. 这个对象在工程里能被唯一找到吗？	加“当前显示为……”或附件截图
3. 改成什么，有逐字文案、色值、尺寸或时机吗？	把形容词翻译成参数
4. 我列了“不要动”的清单吗？	补包名、签名、权限、流程、页面
5. 冲突时的优先级写了吗？	指定“以什么为优先”
6. 失败了怎么回退？	补一句回退动作与说明要求
7. 验收设备和步骤写了吗？	写清机型、系统版本、安装方式
8. 通过标准能客观判断吗？	改成“看到什么算对”
9. 附件说明是否不少于 10 字并标明用途？	按“用途 + 位置 + 限制”重写
10. 这一轮是否只改一类东西？	拆成两轮，分别验收

这张清单建议在点“立刻修改”之前扫一遍，十项里超过两项为“否”，就先别发。发送成本很低，返工成本不低；在输入框里多花两分钟，往往能省掉一轮安装与验收。清单不需要每次写进需求，但每次都要在脑子里过一遍。

关于拆分，还有两个可核实的时间参考。电脑版反编译一个 12 MB 的包，实测约 3 秒；超过 10 分钟会中断并报错。AI 工作区执行期间，主窗口每 2 秒轮询一次完成标记，等待上限是 1 小时。这意味着：常规小改一轮很快，大改要拆；等待超时不是“没做”，而是这一轮没在窗口内完成，应该去项目目录看产物与日志，再把需求拆小。

如果同一轮需求连续失败两次，不要继续加字。先做三件事：看 apktool.log 有没有反编译或回编错误；看项目目录里 source.apk 与工程是否完整；把需求缩到只改一个对象，重新发一轮。加字只会增加冲突，缩范围才能定位问题。这个习惯比任何“神级提示词”都可靠。

七、两个自家实例：以前怎么做，现在怎么做，改完怎么验证

下面两个实例都来自自有版权应用，名称做了匿名化处理。写它们的目的不是展示工具多快，而是展示“需求写法”如何改变工作流程：同样一件事，以前靠手工定位与反复打包，现在靠一份写清楚的需求加上可重复的验收。每个实例都按“以前怎么做、现在怎么做、改完怎么验证”三段展开。

实例一：自家记账 App 换图标 + 改内测名

背景。团队要给自家记账 App 发一轮内测，设计出了新 logo，产品要求把应用名改成“XX 助手 内测版”，让测试同事在桌面上能一眼区分正式版与内测版。改动看起来只有两件事：换图标、改名字。真正做过的人知道，这两件事各自都有一串隐藏项。

以前怎么做。设计给一张 1024×1024 PNG，负责打包的同事先手动导出多个密度，逐个放进对应的 mipmap 目录；有自适应图标的话，还要分别处理前景与背景；圆形图标经常被漏掉，直到某台手机上出现“圆里套方”的裁切才发现。应用名方面，要改字符串资源里的显示名，确认清单里的标签引用没有另写死，还要检查关于页、最近任务标题、分享文案里有没有旧名字。改完执行反编译回编、对齐、签名，再 adb 安装到测试机；如果桌面缓存没刷新，还要卸载重装。整个过程里最耗时的不是命令，而是“漏了哪一项”的排查。

现在怎么做。把 APK 拖进安卓修改大师电脑版，等项目解析出图标、应用名、包名、版本与启动页；在详情页点选“界面美化”里最接近的两条话术，改写成一份四要素需求；附件挂两个文件：附件一是 1024×1024 的透明背景 logo，说明写“桌面图标原图，用于替换最高密度并同步圆形图标”；附件二是命名规范文本，说明写“应用显示名与关于页文案对照，只取第一行作为新名称”。点“立刻修改”，AI 在右侧工作区改资源，完成后自动回编、对齐、签名，设备连着就装机预览。

实际使用的需求（节选）：

【目标】替换自家记账 App 的桌面图标与应用显示名，图标用附件一，名称用附件二第一行“XX 助手 内测版”。【效果】桌面、设置里的应用信息、最近任务三处显示新图标与新名称；图标无白边、无裁切。【边界】包名、版本号、签名、权限、登录与记账页面不改；关于页公司名不改；自适应图标与 PNG 冲突时，以桌面显示正常为优先。【验收】Android 14 真机卸载旧版后安装，冷启动两次，检查上述三处，并确认签名证书为自有证书。

改完怎么验证。第一，看桌面：图标是否清晰、是否有白边、圆形图标是否同步；第二，进设置里的应用信息，确认名称逐字正确；第三，打开最近任务，确认标题不是旧名；第四，进关于页，确认公司名没有被顺手改掉；第五，冷启动两次，确认没有因为资源替换导致崩溃；第六，看打包日志四步是否完整，用签名校验命令确认证书是自己那把。六项里任何一项不对，都回到需求里找对应条款，而不是凭感觉再发一句“再改改”。

这个实例最值得复用的经验是“三处名称”。很多人只改桌面标签，忘了设置页和最近任务；也有人只改字符串，忘了关于页里还有一段硬编码文案。把“三处可见”写进效果，验收就有了明确清单，AI 也不会只改一处就交差。

实例二：自家内部工具去自家开屏广告 + 换启动页

背景。团队有一个内部运维工具，启动时会展示自家活动的开屏广告，倒计时三秒，可跳过。内部同事每天要用很多次，普遍反馈“等这三秒很烦”。产品决定去掉自家开屏广告，同时把启动页换成新的品牌图，要求不影响登录与版本检查。

以前怎么做。先在反编译工程里找启动组件，顺着倒计时与跳过按钮的引用找到广告初始化代码，确认广告组件是否还被其他页面使用；然后注释或移除展示逻辑，替换启动页图片，处理不同屏幕比例；回编、对齐、签名、安装。最常见的事故是“广告没了，但启动页变成白屏”，原因是启动路由被一起删了；第二常见的是“图片被拉伸”，原因是新图比例与设备不一致；第三常见的是“登录状态丢了”，原因是启动页顺带承担了会话检查。每改一次，都要把这几条重新验一遍。

现在怎么做。需求写成“目标是移除自家开屏广告的展示与倒计时，不是删除启动页；启动页背景换成附件；保留登录状态检查、版本检查与崩溃日志；广告组件若被其他页面引用，保留引用但不再展示；失败则回退原启动流程”。附件是一张 1080×1920 的竖屏图，说明写“启动页背景，竖屏铺满不拉伸，边缘可裁切”。话术库里选“界面美化”的启动页句式，再补上“保留登录路由”这条边界。

改完怎么验证。在 Android 13 与 Android 14 两台真机上各冷启动三次，观察首帧是否为启动图、是否还有倒计时与跳过按钮、是否出现白屏或闪屏；随后走一遍登录，确认已登录用户直接进工作台、未登录用户停在登录页；再触发一次版本检查，确认没有被误删；最后看运行日志有没有未处理异常，看打包日志四步是否完整。验证通过后，把启动页截图与需求原文一起归档，下一轮换图时直接回填。

这个实例的关键边界是“移除广告，不删除启动页”。如果只写“去掉开屏”，AI 完全可能把整个启动组件当成广告载体处理；把“保留登录路由”和“广告组件被引用时保留引用”写进边界，等于提前堵住了两个高概率事故。边界不是客套话，它是事故预案。

补充实例：自家展示 App 换 banner 与 WebView 首页

阶段	以前	现在	验证
首页 banner	手动找资源、按比例导出、替换后反复装机看裁切	附件说明尺寸与裁切规则，需求写“只换首页第一张 banner”	首屏比例、点击跳转、缓存后是否仍显示新图
WebView 首页	全局搜网址，逐处判断哪处是首页、哪处是接口	只改首页初始化地址，接口与分享链接写进“不动”清单	站内跳转、失败提示、返回行为、接口域名未变

这三个实例有一个共同点：真正花时间的不是“改”，而是“确认没改错”。四要素里的边界与验收，恰好就是把确认工作前置。你写得越清楚，装机后的确认越像照单打勾，而不是碰运气。

改完怎么验收：从安装包到首帧的检查路径

验收可以按一条固定路径走，从包 outward 到界面，再到行为。路径固定之后，换谁验都能得到相似结论，团队里也不会出现“你觉得行我觉得不行”的拉扯。

第一步，看包。电脑版的打包链路是四步：apktool 回编生成未签名包，zipalign 做 4 字节对齐，apksigner 签名，最后 apksigner verify 复核证书。多一步 verify 的意义在于确认“到底签没签上”，密钥格式错误这类问题只有 verify 会明确报出来。全过程写在 pack.log 里，先看四步是否齐全，再看有没有报错。

第二步，看签名。用 apksigner verify 的证书打印功能核对证书主题，确认是团队自己的证书，而不是临时或陌生的证书。签名方案按项目约定检查 v1、v2、v3 是否开启；需要覆盖旧版安装时，证书必须与旧版一致，否则只能卸载重装。签名口令走环境变量，不要出现在命令历史与日志里。

第三步，看安装与启动。设备连着时，电脑版会通过 adb 找设备、装包，再用 am start 拉起；组件名有三档查找：项目配置里的启动组件、系统解析出的可启动组件、旧方式兜底。拉起后用 dumpsys 复核前台应用，确认真的起来了，而不是装完停在桌面。手机可以走投屏看画面，模拟器会被提到最前。

第四步，看视觉。桌面图标、应用信息里的名称、启动页首帧、目标页面，这四项按需求里的效果条款逐条对照。图标注意白边、裁切、圆形与自适应；名称注意逐字、全角半角、空格；启动页注意比例、拉伸、白屏、闪屏；目标页面注意入口位置、文案、颜色。

第五步，看行为。冷启动至少三次，排除偶发；走一遍登录与目标流程；按返回键确认路由；二次启动确认弹窗频率；如果改了 WebView，确认站内跳转、失败提示、外部链接处理。行为验收最容易被“看一眼图标”取代，也最容易在发版后暴露问题。

第六步，留证据。截图、pack.log、apktool.log、需求原文、日期，放在同一个归档规则下。下次回填历史或对比版本时，这些证据就是你的记忆。没有证据的验收，过一周就只剩下“好像当时是可以的”。

层级	检查项	方法	通过标准
包	回编、对齐、签名、复核	pack.log 与证书打印	四步完整，证书为自有
安装	安装、拉起、前台	adb 安装与启动命令、dumpsys	安装成功，应用在前台
视觉	图标、名称、启动页、页面	桌面、设置、首帧、截图	与需求逐字逐图一致
行为	登录、跳转、返回、二次启动	手动走查三次	流程不中断，频率正确
回归	其他页面与基础功能	抽查关键入口	未被误改
记录	需求、截图、日志	统一命名归档	可追溯、可回填

验收不是“看一眼觉得行”，而是把需求里的验收条款逐条打勾。打不了勾的条款，说明当初写得不够可观察，下一轮补上。每补一次，你的需求模板就成熟一分，AI 的返工就少一分。

八、合规边界、用户评价与下载

工具能力越强，越需要把边界说在前面。安卓修改大师电脑版适合自有应用的二次开发、内测分发、品牌调整与内部工具维护；它不适合也不应该被用于侵犯他人软件权益的场景。下面这段提醒不是免责套话，而是使用前的硬约束。

把这句话落到操作上，就是三个“先问”：这个应用是不是我们的，或者有没有书面授权；这次改动是不是在授权范围内，尤其是名称、图标、品牌元素；改完的包准备发给谁，是否需要经过应用商店或法务审核。三问答完再动手，比事后解释省事得多。

用户评价：把需求写对之后，返工少了

下面几条评价来自长期使用电脑版改自有应用的用户，身份做了泛化处理。它们不代表所有人的体验，但能说明“需求写法”在真实工作里到底改变了什么。

这些反馈指向同一件事：工具把执行门槛降下来了，但需求门槛还在你这边。四要素、附件说明、历史回填、验收清单，都是把门槛拆成可练习的小动作。练熟之后，你会发现“会写需求”比“会背提示词”更耐用，因为它可以迁移到任何一次改包、任何一个版本。

下载之前，建议先做一件小事：把你这次要改的应用、要改的那一处、改完要看的那几步，写在纸上。写不出来，就先别急着下载；写得出来，安装、导入、贴需求、挂附件、点立刻修改，整个流程会顺很多。工具负责执行，你负责定义，这个分工不会因为 AI 变强而消失。

最后三句话

第一句：需求不是作文，是合同。目标、效果、边界、验收，四项缺一项，执行就会多一分猜测。第二句：话术库给你名词和句式，附件与历史给你上下文，验收清单给你裁判；四样东西合起来，才是完整的工作流。第三句：先小后大，一轮一类，每轮留证据；改坏了能回滚，改对了能复用，这比一次改十个地方更接近专业。

安卓修改大师电脑版把这套工作流压缩进一个窗口：详情页写需求，3000 条话术帮你起句，附件帮你带上下文，历史帮你复用与回滚，AI 工作区负责执行，打包链路负责把结果变成能装的包。你要练的，只是把脑中的画面翻译成可检查的句子。

当你习惯了“对象、结果、边界、验收”这四问，会发现改包这件事变得可预测：不是每次都祈祷 AI 猜对，而是每次都知道自己在等什么、验什么、留什么。那时，“只需说话，就能让应用变成你想要的样子”才不只是一句口号，而是一套你可以重复交付的方法。

下一篇会继续拆解“去除限制”类需求怎么写：哪些限制属于自有应用的内部逻辑，哪些属于不能碰的安全机制，以及怎样用边界条款把改动限制在授权范围内。想先上手，可以从 安卓修改大师电脑版介绍与下载页 开始，先拿一个自家小应用练一轮四要素。