你只写了一句话，它送出去一段长文：需求文本的三层结构

先说一个可能让你意外的事实：你在输入框里打的那句话，并不是最终被送出去的那段话。——真正送进右边那个 AI 工作区的文本，比你在输入框里写的要长——长出来的部分，你一个字都没打过。

这不是程序在"替你添油加醋"，更不是在偷偷加什么隐藏指令。——它加的那部分，是一段固定的操作说明：告诉对方去哪儿改、改到什么程度算完、改完别自己打包。——而这段说明，每一次都一模一样——所以它不该由你每次手打，也不该混进你的修改历史里。

这件事在这个工具里叫「需求文本分层」。——「安卓修改大师智改工坊」把它拆成三层：你写的原话、附件的说明、以及那段固定环境说明。——三层各管一件事，各有各的去处——而其中只有一层会被记进历史。——如果你只记住一句话，那就记这句：你写的是"要什么"，程序补的是"在哪儿、怎么算完"。

为什么这件事值得单独写一篇文章？——因为绝大多数"它没改对"的困惑，根子都在这里：你以为自己说了全部，其实你只说了目标，而没说边界；你以为它没听见你后半句，其实是你的后半句和环境说明撞在了一起。——一旦你知道那三层各自长什么样，很多"玄学问题"就变成了可解释的问题。

只需说话，就能让应用变成你想要的样子。而这句话要真正成立，前提是"说话"和"听话"之间那段没人看见的约定要说清——这正是本文要讲的东西。想先看看这套东西长什么样，可以从 https://www.apkeditor.cn/ai-version.aspx 进来，随便导入一个自己的应用，点一次「立刻修改」，再看一眼项目目录里的 history.ini——你就能亲眼看到"写进去的"和"发出去的"是两份东西。

一、先看三份东西：输入框、history.ini、真正发出去的文本

要理解分层，最直接的办法是把三份文本摆在一起看。

第一份：你在输入框里写的那句话。——比如「把启动页的欢迎语换成我们品牌的新口号，字号大一点，居中对齐」。——这就是你的原话，一共二十几个字。

第二份：history.ini 里那一条记录。——这个文件在项目目录下面，一条一条记着你每次提的需求。——而它里面存的，就是上面那二十几个字——原样，不增不减。

第三份：真正送进右边工作区的那段文本。——它由三段拼成：你的原话、附件说明（如果你加了附件）、以及一段固定的环境说明。——中间用空行隔开，顺序是死的：原话在最前，附件说明紧跟其后，环境说明压在最后。

为什么顺序是这个顺序，而不是把环境说明放最前面？——因为这三段的性质不同。——原话和附件说明属于"这次要改什么"，是一件事的两半，必须挨在一起；而环境说明是"操作约定"，它描述的是做事的方式，不是做事的对象。——约定压在最后，对方读完"要改什么"，紧接着读到"怎么改、改完怎么交"——这个顺序符合人读任务描述的习惯。

还有一个细节值得注意：原话为空的时候，整段就不发出去了。——也就是说，如果你只加了附件、没写一句话，程序不会替你发一段"请看看这些附件"——它按"需求是空的"处理。——这条设计其实是在提醒你一件事：附件是补充，不是需求本身。你至少得说一句"用这个附件干什么"。

顺便说清一个容易混的点：这三层不是"三个输入框"。——界面上你只看到一个需求输入框和一个「选择附件」按钮，环境说明根本没有界面——它是程序按当前项目的情况现拼的。——你看不见它，但它每次都在——而这也正是很多人"不知道自己说过什么"的原因。

二、为什么要分层：三个理由，一个比一个实际

如果只是"多发一段话"，看起来没必要专门设计。之所以值得分三层，是因为不分层会同时坏三件事。

第一个理由：历史会被刷屏。——假设环境说明也写进 history.ini。——那你打开「修改历史」，每一条记录都是先看到你写的那二十几个字，然后跟着一大段一模一样的操作说明。——五条记录之后，你就再也扫不出"我上次到底改了什么"——因为真正有信息量的那部分，被重复内容埋掉了。

这件事的分量，比听起来重。——修改历史是这个工具里少数几个"会一直陪着你"的东西：项目做得越久，历史越长，它越有用。——而它唯一的用处，就是让你在两秒钟内回忆起"这一版和上一版差在哪"。——一旦它变成三段拼盘的堆叠，这个用处就没了——你会开始用文件名记事："最终版2"、"最终版2改"。

第二个理由：约定不该由人来承担。——环境说明里那些话——切到哪个目录、改完留什么文件、不要自己打包——每一次都完全一样。——如果让你每次手打，会有三种结果：一种是忘了打，一种是打错字，还有一种是"这次懒得打，反正上次也没事"。——而这三种结果的代价都不小：忘了切目录，AI 可能在别的地方改；忘了留标志文件，主窗口会一直等下去，等到一小时上限。

凡是"每次都一样"的东西，都不该由人重复执行。——这是自动化里最朴素的一条原则，而这个工具把它用在了"说话"上：你说变的，程序说不变的。

第三个理由：约定要能随项目变，而你的原话不该跟着变。——环境说明里有一处是动态的：工作目录。——同一个应用，你可能做过三个项目：一个改图标、一个改文案、一个做渠道专供版。——三个项目的工作目录不同，但你要说的话可能差不多。——如果工作目录也要你手写进需求里，那你每换一个项目就得改一次需求——而那是不必要的工作量，也是很容易出错的地方（改漏一次，AI 就去改上一个项目的文件了）。

所以这个设计可以概括成一句话：把"每次都要说的"和"每次都不一样的"分开——不一样的留给你，一样的交给程序。——而分开的好处不止是省事：它还让"历史"这件东西保持了它该有的纯度。

这里还有一个隐含的好处，很多人没意识到：分层让"重发"成为可能。——当 AI 会话的上下文快满时，程序需要换一个新会话，然后把同一段需求重新发一遍。——如果需求是三层拼出来的，那"重发"就是把同一段拼好的文本再送一次——工作目录、标志文件约定全都在里面，不会漏。——而如果需求是你手打的一段话，那"重发"就意味着你得再打一遍——而这一次你很可能会漏掉点什么。

再补一个反直觉的点：分层不是为了"让 AI 看到更多"。——恰恰相反，它的目的是让 AI 看到的每一条信息都有明确归属——哪句是你的意图，哪句是环境约束。——信息不是越多越好，是越"有归属"越好。——一堆混在一起的话，容易让人（也容易让模型）把约束当成需求，把需求当成建议。

最后要说清这套设计的一个代价，因为它会影响你排查问题的思路：你没法在界面上"完整地看到"发出去的那段话。——输入框里只有你的原话，环境说明在背后拼——所以当结果不对时，你手上能对照的只有一层。——而这个代价是可以自己补上的：真遇到想不通的情况，去项目目录看一眼工作路径对不对、看一眼有没有残留的标志文件——这两件事一查，就等于把那两层也看到了。——换句话说，分层让"日常使用"变轻了，但把"深挖"这件事挪到了文件系统里——知道去哪儿看，就够了。

三、环境说明里到底写了什么：四句话，各有各的活

这段说明不长，但每一句都不是随手写的。把它拆成四句来看，你会更容易理解"为什么它必须由程序来说"。

第一句：身份和语言。——"你是一位专业的中文助手，无论用户使用什么语言提问，请始终使用简体中文回答和思考"。——这句话看起来像客套，其实是硬约束：它保证不管你的需求里夹了多少英文术语、或者你习惯性地写了几句英文，对方的回复和它的思考过程都保持在中文。——为什么要在技术场景里强调这个？因为改包这件事牵扯大量英文标识符——包名、资源名、类名、参数名——如果对方把这些"解释成中文"，你反而看不懂它在说什么。

第二句：去哪儿改。——"请将工作目录切换到{workdir}下面进行修改"。——这里的 {workdir} 是个占位符，发出去之前会被换成当前项目真实的工作目录——就是详情页那一栏显示的那个路径。——为什么用占位符而不是直接把路径拼进固定文本？因为这段说明是"一次写好、处处使用"的：项目换了，路径变了，只要替换一个占位符，整段话就跟着变。

这里有个很细的处理，值得单独讲：拿不到工作目录时，"切换到某目录"那半句会被整句去掉，而不是留下一个空括号。——因为留着会变成"请将工作目录切换到下面进行修改"这种病句——而病句在提示词里的伤害，比少一句话大得多：它会让人读到一半卡住，然后开始猜。——正常流程里这种情况不会发生（拿不到项目目录时会退回工作目录根目录），但这个兜底分支存在，说明写这段代码的人是真的把"话要通顺"当成一件事。

第三句：怎么算完。——这句是全段里最重要的：要求对方在"确认全部改完"之后，在项目工作目录下生成一个名为 ai_done.flag 的标志文件；主窗口会轮询读这个文件，读到就认为改完了，然后把它删掉；所以这个文件只能在整个修改真正结束之后再生成，中途不要生成。

为什么用"文件"当信号，而不是等对方回一句"改好了"？——因为程序读不到"一句话"。——右边那个工作区是一个独立的界面，它说了什么、什么时候说完，主窗口没法可靠地知道。——而磁盘是双方都能碰的地方：那边写一个文件，这边盯着看——这个通道又简单又稳，不依赖任何界面状态。

"中途不要生成"这半句，是整句里最容易被忽略、也最容易出问题的地方。——因为它的反面就是"改了一半就报告完成"。——而主窗口一旦读到这个文件，会立刻做三件事：删掉它、认为这一轮结束、然后重新打包。——如果这时候其实只改了三个文件里的一个，那打出来的包就是一个半成品——而你还以为改完了。

第四句：不要自己打包。——"按照上面的需求修改完毕后……不需要自动打包。"——这句话是整个分层设计里最"反直觉"的一句：为什么不让对方顺手把包打了？——因为打包这一步，在这个工具里是一件有严格流程的事，不能交给别人随意执行。

顺便说清一件事：除了这四句，发出去的文本末尾还会跟一小段"会话上下文快满时怎么办"的约定。——它要求对方在上下文接近上限时，先把手头的修改收尾到能回编的安全状态，然后留一个 talk_reset.flag 通知主窗口换新会话。——这段也属于环境说明的一部分——它同样是"每次都一样"的约定，同样不进历史。下一章会专门讲它为什么必须存在。

四、为什么"打包"这一句必须写进环境说明

这一句值得单独一章，因为它是"环境说明"里唯一一句在管"边界"的话——前面三句在说做什么，这一句在说"到这儿为止，剩下的别碰"。

先看这个工具自己打包时做了什么。它不是一个命令，是四步：——先用 apktool 回编出 unsigned.apk；再用 zipalign 做四字节对齐；然后用内置签名把包签出来；最后用 apksigner verify 校验一遍，并打印证书指纹。——四步走完，目录里会留下三个文件——unsigned、aligned、signed——而只有最后那个 signed 是能装到手机上的。

这四步里，最容易漏的是对齐和校验。——对齐漏了，包在很多机型上装不上或者起不来；校验漏了，你可能拿着一个签名失败的包去安装，看到"解析包时出现问题"，然后开始怀疑是改坏了。——而这两步都不是"顺手就会做"的事——它们需要工具、需要参数、需要知道做没做对。

更关键的是签名。——如果打包这件事交给 AI 随手做，它大概率会用某个默认的调试签名，或者自己生成一个。——而这会导致一个非常难受的后果：新包和手机上已装的那个包签名不一致，覆盖安装直接失败。——而唯一的解决办法是先卸载——卸载会清掉应用数据。——也就是说，"顺手打个包"这一个动作，可能让你丢掉测试机上积累了两周的登录状态和草稿。

所以"打包统一由主程序完成"这条约定的真正含义是：签名必须唯一。——每一次打包都用项目配置里那一份签名，签出来的包指纹永远一致，于是每一次都能覆盖安装，永远不需要卸载。——这一条把"改包"这件事从"每次都提心吊胆"变成了"每次都是例行公事"。

还有一层好处，是事后才看得见的：日志。——主程序打包时，全过程写进 pack.log——回编输出、对齐结果、签名结果、证书指纹，一条不落。——而如果打包是"别人顺手做的"，那这一步发生了什么，就只存在于那个界面的对话记录里——而对话记录会随会话重置而消失。

这里可以插一个自家应用的例子，因为它把这个道理讲得特别清楚。——我们内部有一个用于展厅演示的应用，改过很多轮：换过启动图、调过按钮圆角、加过一个"演示模式"入口。——早期的做法是：让 AI 改完顺手打个包，我们拿那个包装到展厅的平板上试。——试了三次，两次装不上——一次是对齐问题，一次是签名不一致（那次还不得不卸载，把平板上配好的展厅账号全丢了，重新配了半小时）。

现在的做法是：一句话描述改动，改完由主程序打包，只拿 signed 那个包装机。——从那以后，同一台平板上再也没有卸载过一次——每次都是覆盖安装，数据全在。——验证方式也很朴素：装完打开，看那个"演示模式"入口在不在、启动图是不是新的；如果这两处对，就说明这一轮改动落地了。

所以这一句约定，本质上是给"改"和"发"划了一条线：改造留在工程里，发布回到主程序。——而这条线划清之后，你会发现自己对"改包"这件事的心态变了——以前每次点打包都有一点点赌的成分，现在它就是一个动作。

五、完成标志的两个细节：为什么先清一遍，为什么只等一小时

环境说明里那句"留一个 ai_done.flag"，看起来简单，但围绕它有三处设计，每一处都在防一种具体的坑。

第一处：开始等之前，先清一遍同名残留。——主窗口每两秒轮询一次这个文件，读到就删、就认为改完了。——那么如果上一轮结束时这个文件因为某种原因没被删掉（比如上一轮你手动关掉了右边的程序、比如磁盘上还留着上一轮写的空文件），这一轮一开始就会立刻读到它——于是程序瞬间认为"改完了"，然后拿一个根本没改的工程去打包。

这种坑的特征是"看起来一切正常"：没有报错、打包成功、包也装上了——只有你打开应用，发现改动根本没生效。——而你会开始怀疑是 AI 没听懂，或者怀疑是打包没打进去——很难想到是"信号文件本来就躺在那里"。——所以那一句"开始等待前先清一次"看起来像一行防御代码，实际上是在保住你排查问题的时间。

第二处：两秒一次，不是半秒一次。——轮询间隔是个需要权衡的数：太密，白耗 CPU（而这个程序已经有一个 5 毫秒的窗口轮询在跑）；太疏，改完之后你要干等一下才看到反应。——两秒是个很实际的折中——一轮修改通常是几十秒到几分钟，两秒的延迟你基本感觉不到；而它带来的开销可以忽略。

第三处：等一小时就停。——这个上限的意义不是"怕你等太久"，而是"怕它永远等下去"。——如果右边那边出了状况——比如它崩了、比如它把你的需求理解成了别的事、比如它改到一半停在那儿——那标志文件永远不会出现。——没有上限的话，主窗口会一直显示"正在等待"，而你不知道该继续等还是该重来。——一小时后自动结束，至少给了你一个明确的、可行动的状态：它没回来，我们换个说法再来一次。

顺带说一个很容易被忽略的机制：这一轮结束之后，主窗口还会再盯二十秒。——为什么？因为对方可能先写完成标志、再写会话重置标志——这两件事有时隔了几秒。——如果主窗口一读到完成标志就收工，那随后出现的那句"我上下文满了，请换会话"就被漏掉了——于是下一轮你继续在这个快满的会话里改，改到一半它就撑不住了。

这就引出了第二段约定：talk_reset.flag。——为什么需要它？因为上下文是客户端控制的，AI 自己没法重置自己的会话。——它能做的只有一件事：留个文件，告诉主窗口"我这边快满了，请你换一个新的，然后把同一段需求再发给我"。——而主窗口读到这个文件，会立刻删掉它、在工作台里新建一个空白会话、再把之前存下的那段完整文本重发一遍。

注意这里"重发"的是什么：是拼好的整段文本，不是你的原话。——这就是第二章说的那个隐含好处——工作目录、完成标志约定、不要自己打包，全都跟着一起过去了。——对方换了新会话，但它拿到的任务描述和上一轮一字不差——所以它能接着干，不会因为"换了个人"就从头猜。

而"重发只用一次"这个细节，也很讲究。——如果同一个需求被反复重发，就会陷入"改一半→重置→重发→再改一半"的死循环——你会看到进度条永远在开头。——所以程序只重发一次：第二次再遇到会话满，它会停下来告诉你，让你决定是拆小一点重说，还是换个思路。——这条设计背后的判断很清醒：自动重试能救一次意外，救不了"这段需求本来就太大"。

六、中间那层：附件说明为什么算"需求"而不算"环境"

三层里的中间一层，位置很容易被误解。它被拼在原话后面、环境说明前面——这个位置本身就是一句声明：它属于"这次要改什么"，不属于"怎么改"。

它长什么样？开头是一句总说明：下面这些文件已经放在磁盘上了，请按各自的说明使用，路径是本地绝对路径，需要放进应用里的，请自己决定放到工程的哪个位置。——然后一条一条列：序号、路径、一段用途说明，中间用破折号连起来。

三个细节值得留意。——第一，路径是绝对路径：不是"附件里的那张图"，而是从盘符开始的完整路径。——第二，"需要放进哪里"这件事被明确交给了对方——因为只有它看得到工程结构，你只负责说这个文件是干什么的。——第三，每条都带说明：没有说明的附件，在对方眼里就是一个来路不明的文件。

它同样不进历史，理由和环境说明一样，但动机略有不同。——环境说明不进历史，是因为它每次都一样，会刷屏；附件说明不进历史，是因为它描述的是"这一轮用的材料"，而材料会过期——你回头看三个月前的历史，看到一串早已删掉的路径，除了困惑没有别的用处。——而"我当时到底想改什么"这句话，永远只由你的原话回答。

这里有一个很实际的推论：如果你某一轮只写了"按附件改"，然后把材料全放进附件——那这一轮的历史记录就只有"按附件改"四个字。——三个月后你看到这条记录，完全想不起来改了什么。——所以一个好的习惯是：原话里把"改什么"写清，附件只承担"用什么改"——两句话各就各位，历史才留得下来。

七、两个自家应用的实例：三层文本各自起了什么作用

道理说完了，看两个我们自己做过的例子——都是内部应用，都在自己手里。

实例一：内部排班应用，换启动页那句欢迎语。

以前怎么做：——反编译、在 res 里翻 strings.xml、找到那句中文、改掉、回编、对齐、签名、装机。——麻烦的不是改，是"找"——那个应用里中文文案几百条，你得先确认哪一条是启动页用的；如果文案是写在布局里的，还得再去 layout 里找一遍。——而每换一次说法（领导改口径是常事），这一整套就要重来一遍。

现在一句话怎么做：——原话只写一句："把启动页那句欢迎语改成『今天也辛苦了』，字号和位置都不动。"——没有附件（不需要材料），环境说明自动补上工作目录和完成标志。——改完主程序打包，覆盖安装到那台测试机上。

改完怎么验证：——三步——打开应用看启动页那一句变了没有；进"关于"页确认版本号是我们这一轮设的那个；再随手点两个功能页，确认没有因为改文案把布局挤坏（文案变长会把按钮挤下去，这是最常见的连带问题）。

实例二：内部库存盘点应用，一次换十八个功能图标。

以前怎么做：——十八个图标，先按密度档归好（同一张图要准备多个尺寸），再一个个对名字——"这个是人形图标还是工具箱图标"，光靠文件名分不出来，得打开看。——最耗的是核对：换完之后十八个入口得逐个点一遍，看有没有哪个图标张冠李戴。

现在一句话怎么做：——原话写："把功能入口的图标换成附件里这套新图标，图形风格统一了，但位置和顺序不要变。"——附件那一层有十八条，每条一句用途——"序号 3，盘点任务列表入口"、"序号 7，扫码入口"……——而"位置和顺序不要变"这半句，是原话里最值钱的六个字：它替你说了边界。

改完怎么验证：——打包装机，进首页，从左上到右下按顺序扫一遍入口——顺序对了、图形对了，就基本没问题；再单独点开两个"最容易混"的入口（我们那次是"盘点"和"查询"，两个图标原来都是表格样式），确认进的是对的页面。

这两个例子放在一起看，能看出三层各自的分工：——实例一里只有两层——原话和环境说明，因为不需要材料；实例二里三层齐全——但我猜你注意到了一件事：实例二真正决定成败的不是那十八条附件，而是原话里"位置和顺序不要变"这半句。——附件负责"换成什么"，原话负责"别动什么"——而后者往往是新手最容易漏的那一半。

八、原话该怎么写：六条能直接照做的建议

既然环境和附件都是程序或界面在处理，那真正需要你动脑的只有第一层。以下六条，都是踩过坑之后总结出来的。

第一条：说目标，不说步骤。——差的写法："先打开 strings.xml，找 welcome，改成今天也辛苦了，然后保存。"——好的写法："把启动页那句欢迎语改成『今天也辛苦了』。"——为什么不要给步骤？因为它比你看得清工程结构：你猜的那个文件名可能是错的，你猜的位置可能有三处同名。——你给它目标，它自己找路——这条路走错了它会换一条；而你给的步骤走错了，它只会照着错的路走到黑。

第二条：一条需求只干一件事。——把"换图标、改文案、加个入口"写在一段里，是新手最常犯的错。——不是说它一定做不完，而是做完之后你没法验收：三个改动搅在一起，出了问题你不知道是哪一处引起的；而想退半步（只保留两个）也做不到——历史里只有一条记录。——拆成三条的好处，在这一刻体现得非常具体：每一条都能单独打包、单独装机、单独确认。

第三条：一定要说"别动什么"。——这是六条里最容易被跳过的一条，也是收益最高的一条。——"位置和顺序不要变"、"其它页面不要动"、"字号保持现在这个"——这些话在语法上都是废话（不说也不会有人主动去改），但在实践里它们划出了边界。——因为"改一处"和"改一类"之间，边界是模糊的：你说"把按钮圆角改小一点"，它可能把所有按钮的圆角都改了——包括你不想动的那个登录按钮。

第四条：能量化就量化。——"大一点"、"明显一点"、"稍微"——这些词你和我能靠上下文对齐，但对方只能猜。——而"字号从现在的 18 调到 22"、"圆角从 8 改成 4"、"间距缩小一半"——这是可以被执行的。——如果你不确定具体数值，还有个更实用的写法："先按 XX 改，改完我看看效果。"——把量化推迟到第二轮，也比含糊着一次改歪强。

第五条：一句话里只用一个指代。——"把这个改成那样"是灾难句：这个指哪儿？那样是什么样？——在人和人之间，这类指代靠手势和上下文补齐；在文本里，它是纯粹的噪音。——而这个问题在改包场景里特别突出——因为屏幕上同时存在两个东西：左边的项目详情、右边的工作区。你说"这个页面"，到底指哪个？

第六条：把你已经排除的方案说一句。——"不要用弹窗"、"不要新增页面"、"不要换字体"——这些话看起来是在限制它，实际上是在帮你省一轮返工。——因为对方不知道你的偏好、不知道你们产品的规矩、不知道上个版本刚把一个弹窗改成了内嵌提示。——你说一句"别用弹窗"，它就少了一个错误选项——而错误选项少一个，正确结果的概率就高一点。

九、什么时候该把一条需求拆成两条

"一条需求一件事"说起来简单，但实际工作中总有"这两件事本来就是一回事"的情况。以下三个信号，出现任何一个就说明该拆了。

信号一：验收方式不一样。——"换图标"的验收是"看首页十八个入口"；"改启动流程"的验收是"从冷启动开始走一遍"。——两套验收方式意味着两次装机、两次确认——那就该是两条需求。——反过来，如果两处改动的验收动作是同一个（比如都在同一个页面上、看一眼就知道），那合成一条反而更省事。

信号二：失败之后要不要退。——有一条改动是"试试看，不行就撤"，另一条是"必须成"——这两条不该混。——混在一起，那一轮失败之后你就得两条一起重来；而分开的话，"必须成"的那条已经落地了，试的那条单独失败，损失可控。

信号三：你自己还没想清。——这条最实在：如果你写需求的时候写到一半开始犹豫"这里到底要不要改"，那就先写那个想清了的。——把没想清的部分塞进同一段话，结果通常是——它按某种理解改了，而你看到结果才发现自己原来不是这个意思。——而这时你已经在一条混着两件事的历史记录里，退也退不干净。

十、一个五分钟的自检清单

点「立刻修改」之前，花五分钟过一遍下面这张表。它查的不是你的表达能力，是"这段话有没有留下歧义空间"。

检查项	不合格的样子	合格的样子
目标清不清楚	"优化一下这个页面"	"把列表项之间的间距从 12 调到 16"
有没有给边界	只说改哪儿，不说别动哪儿	"其它页面不要动，标题栏保持原样"
指代是否唯一	"这个"、"那个"、"上面那个"	"首页顶部那个轮播图"
是不是只干一件事	换图标＋改文案＋加入口	只换图标，其它下一轮
附件说明是否齐全	只放文件，不写用途	每条一句"这是干什么用的"
验收动作想好了吗	"装上去看看"	"打开首页，看第二行第三个入口的图标"

这张表里，最后一行是最容易被跳过的，而它其实是前五行的验收标准。——如果你在写需求的时候还说不清"改完我怎么确认它对"，那说明这一条需求本身还模糊——因为一个清晰的改动，天然自带一个清晰的验收动作。

顺带说一句：这六条不只对改包有用。——你把这套写法用在给同事提需求、给外包写需求、给自己写待办上，效果是一样的——因为"说清一件事"的能力不依赖工具。——而工具的价值在于：它逼你把这件事练出来，因为它不会像同事那样"猜你想说什么"。——而当你习惯了先说目标、再说边界，你会发现同事回你的消息也变短了——他们不再需要反问三遍才敢动手。

十一、这套分层真正教会你的一件事

写到这里，可以退一步看看这件事的全貌。它的价值不止"少打几行字"。

它把一次"改包"拆成了三个责任区：你要什么、材料是什么、规矩是什么。——而这三个区各有各的主：第一个只有你能填，第二个你准备，第三个程序提供。——责任一分开，"出问题该找谁"就变清楚了。

举个很具体的对照。——改完发现改动没生效——这该找谁？——先看历史里那条原话：如果你写的是"把欢迎语改成今天也辛苦了"，那需求是清楚的，问题不在第一层。——再看完成标志是不是提前出现了（第五章那个坑），问题可能在第二层的等待机制。——最后看 pack.log：如果里面写着用的是哪份签名、打了哪个目录，问题可能在第三层。——三个区看一遍，你大概就知道是"我没说清"还是"它没做到"还是"包没装对"。

而在没有分层的情况下，这三件事是混在一起的。——你会陷入一种很消耗的状态：反复重述同一句话，每次加一点细节，每次结果都差不多——因为你不知道缺的到底是描述、是材料、还是流程。——这种状态下人很容易得出一个错误结论："这东西不靠谱"。而真相可能只是：你一直在第一层加字，而问题在第三层。

第二件它教会你的事，是"可复现"。——因为拼好的那段文本会被存下来，用于会话重置后的重发——这意味着同一段需求可以被完整地、一字不差地再执行一次。——这件事在团队里特别有用：你把项目目录连同 history.ini 一起交给同事，他能看到你每一轮说过什么；如果某一轮的效果特别好，他可以照着那条原话再走一遍。

而"可复现"的反面，是那种只存在于聊天记录里的口头需求。——"上次那个效果，你把那个改一下"——这句话在三个月后无法被执行，因为它没有落到任何能留存的地方。——history.ini 只留原话这条设计，本质上是在保一件事：让"你当时想要什么"这句话，成为项目的一部分，而不是你脑子的一部分。

还有一个更微妙的收益，是关于"你还愿不愿意翻历史"的。——一个人愿不愿意用一个功能，往往取决于它第一次打开时的样子：如果「修改历史」里每一条都是干净的一两句人话，你会愿意翻；如果每一条都要在一大段固定话术里挑出那点新意思，翻两次你就不翻了。——而不翻的后果不是"少看一个功能"，是"上一个版本为什么那么改"这件事彻底丢了——等到下一个人接手，或者三个月后的你自己回来，就只剩下一句"当时好像是调过什么"。

所以回到开头那句话：真正送出去的，比你在输入框里写的长。——而长出来的那部分，不是噪音，是这个工具替你说出的"常识"——去哪个目录、怎么算完、别自己打包、上下文满了怎么办。——这些常识原本要靠你每一次重新交代，现在它们被固定在同一个位置，每一次都完整地出现在同一段话的末尾。——你要做的，只是把第一层说清楚——而那本来就是一件只有你能做的事。

十二、用过的人怎么说

这五条里，有两条讲的是同一件事，只是方向相反：一个人学会了"不多写"（不再自己加'改完打个包'），另一个人学会了"写清楚"（不再写'那个'）。————而这两件事其实是同一件事的两面：知道哪一层归你，你才知道该在哪里用力。

还有一个人提到"翻历史想不起来'那个'是什么"——这个细节很值得记住。————历史的价值不在于"记录发生过什么"，而在于"三个月后还看得懂"。而看得懂与看不懂之间，往往就差那一次把'那个'换成具体名字。

---

只需说话，就能让应用变成你想要的样子。——而"说话"这件事，从你把第一层说清楚开始：安卓修改大师智改工坊把剩下两层替你说完，你只管说清你要什么。