安卓修改大师 · 智改工坊

复杂需求怎么写才可执行：以会员与授权校验为例

现象与入口 · 五要素 · 停手条款 · 真机验证

在智改工坊里，改一个应用名只要一句话，但"把会员到期提示的处理方式改成内测模式"这种需求， 写完往往自己都觉得心里没底：改哪儿？改到什么程度算完？问题不在工具，在于需求本身没有被写成可执行的样子。 这篇文章就专门讲这件事——复杂需求怎么写，才能让 AI 一次做对、也让你一次验得明白。

先说边界：本文讨论的会员 / 授权 / 校验类改动，全部限定在你自己拥有版权或已获授权的应用上—— 比如自有 App 在内测期临时放开会员校验、把自研产品的试用逻辑改成内测模式、调整自家授权提示的流程与文案。这不是"破解别人应用"的方法论，也请不要那样用。

一、为什么这类需求最容易写砸

先说结论：会员与授权类需求之所以难写，是因为它同时踩了三个坑——入口隐蔽、判定分散、结果不可观察。看三个典型写法：

三种写法的共同后果是一样的：AI 只能按自己的理解下手，你只能在装机后凭感觉验收。而复杂改动一旦改偏，返工成本远高于多写二十行需求。

二、把需求拆成五要素：从"能看懂"到"能执行"

工作目录里的话术库（Resources\话术库.xml）给了一个现成的骨架：每条指令都按要做什么 / 细节要求 / 参数参考 / 范围 / 验收五部分写全， 六大分类里就有专治这类场景的条目。照着它把自己的需求补齐，是最快的上手方式。下面这张表是同一件事的两种写法对比。

差别不在字数，而在每一句话都能被对照检查。当需求里出现了具体的页面、具体的动作、具体的不许项，AI 的每一步判断都有了依据，你的验收也有了标准。

三、先定位，再动手：把现象、入口、期望写清楚

会员与授权逻辑的特点是"看不见"：你不知道它写在哪一层、是本地判断还是联网校验。因此需求里第一件该说清的事，不是"怎么改"，而是你看到了什么。

1. 现象：在什么情况下看到什么——"启动 3 秒后弹出到期提示，点『我的』进会员中心显示已过期"；
2. 入口：你是怎么走到那一屏的——"首页右上角头像 → 我的 → 会员中心"；
3. 期望：改完后同样路径下应该看到什么——"提示不再弹，会员中心显示内测有效期"；
4. 不确定就交给它判断：如果你不知道判定是本地还是联网，就在需求里写"先定位判定位置并告诉我结论，再决定怎么改"。这一句能省掉大量来回。

把这几句写成一段完整需求，大概是这样（可以直接照着改字段）：

四、范围与边界：一定要写"停手条款"

复杂需求里，"不改什么"往往比"改什么"更重要。授权、会员这类逻辑通常和支付链路纠缠在一起，越界改动会带来两个后果：一是把能正常工作的功能改坏，二是出问题后没人说得清是哪一步引入的。

另外强烈建议拆步推进：先发一条小需求（比如只改提示文案）跑通整条链路，确认 AI 理解与打包都正常，再把主需求发出去。 每条需求都会以原文形式记进项目的 history.ini，在详情页按最新在上列出、完整显示不截断；哪一步走偏了，点「选择」把那一条填回输入框，补一句说明再发一次即可。

五、改完必须真机验证：五步验收清单

AI 改完会在项目目录留一个标志文件，主窗口每 2 秒轮询到就自动弹打包窗口，回编 → 对齐 → 签名 → 校验依次跑完，产物在项目目录的 build 下，全过程写进 pack.log。 前三步只看退出码，最后一步 verify 才是"签名到底签上没有"的判据——四步全过，才轮到真机这一关。

1. 装上去：勾上"打包后自动运行"，程序用 adb 找手机或模拟器，装上后自动拉起；
2. 认身份：装完用 dumpsys 看一眼前台应用，确认跑起来的确实是刚出的这个包；
3. 走路径：按需求里写的那条路径手点一遍——启动 → 我的 → 会员中心 → 受限功能，看行为是否与"期望"一致；
4. 反向验证：退出登录、换非目标账号、断网再各看一遍，确认没有把别的情况改坏；
5. 多设备复测：手机与模拟器各跑一次；连手机时 scrcpy 会把屏幕投到电脑上，模拟器则会被提到最前面，点起来都省事。

设备侧的小状况都不难处理：国内主流模拟器（雷电 / MuMu / 夜神等）装了但 adb 没连上会自动扫端口连上；模拟器装了没开，会搜出安装路径问你要不要帮你打开；手机没授权会提示你去点"允许 USB 调试"。顺便说一句，拉起应用用的是 am start 而非 monkey——新版安卓镜像里已经没有 monkey，且它失败时退出码还是 0，容易把失败当成功。

万一改动方向有问题也不必慌：建项目时自动留存的 source.apk 就是原始包备份；反编译失败不会影响项目本身（配置、图标、源包都已落地，修好环境重来即可，会提示原因并给 apktool.log 路径）；每次出包前还会往工程里写入一条带出包时间、账号与机器码的标记样式，几个包分不清来源时能一眼回溯。项目列表本身读磁盘、带搜索，每条可编辑 / 看历史 / 删除（删除带防呆，只允许删 Project 的直接子目录）。

六、用户评价

以下摘录来自做内测交付、测试与自研产品的使用者，已获授权并做脱敏处理。

七、合规提醒与上手清单

最后照例给一份可以直接照做的清单：

1. 建项目：拖入自有或已授权的包，等反编译完成；
2. 挑模板：到话术库挑一条最接近的条目，点「选择」填进输入框，再按自己的场景改字段；
3. 写现象与入口：把"在哪看到什么、怎么走到那一屏、期望变成什么"写进需求；
4. 补范围与停手条款：不许动支付、订单、包名；不能改的部位请保留原样并说明原因；
5. 参数与说明走附件：账号、配置、对照说明都可以当附件带上，每个文件写一句不少于 10 个字的用途；
6. 发出去：点「立刻修改」，需求原文进 history.ini，改完自动接打包四步；
7. 真机五步验收：装、认身份、走路径、反向验证、多设备复测；
8. 留痕：需求在历史里、原包在项目里、出包记录在打包标记里。

本文所述操作均针对自有版权或已获授权的应用；用户反馈已获授权并做脱敏处理。