有一段时间，我一直在想，桌面消息转发是不是可以做得更“干净”一点。既然联系人、会话和消息都已经在本地数据里，为什么还要打开界面、确认窗口，甚至保留截图和文字识别？如果这些步骤都能去掉，自动化速度会更快，流程也会更像一条稳定的流水线。
这次实际把消息转发流程往前推进时，我先比较了转发给1个人和转发给2个人的耗时，又继续追问不同联系人、好友申请，以及当前窗口到底能不能被数据层代替。问题慢慢从“怎样更快”变成了“哪些事情本来就不属于数据库”。
后来我形成了一个不太激进、但更可靠的判断：数据库适合提供稳定事实，界面负责当前窗口和真实账号，最后的写入动作还要回到能被看见、能被确认的地方。安全自动化不是在数据库和界面之间二选一，而是让每一层只承担自己真正知道的事情。
先从一个看似简单的转发说起
当时的场景很普通：要把桌面消息转给指定联系人。第一反应当然是先查本地数据，看看联系人是否存在、消息内容是什么、会话是否可定位。数据层的优势很明显，查询快，结果稳定，也不需要把整个窗口搬到前台去处理。
这让流程的前半段变得很顺。联系人可以先被定位，消息事实可以先被核对，候选对象也可以先被缩小。用户比较了转发给1人和转发给2人的耗时，继续问还能不能优化，本质上是在问：既然已经知道目标是谁，后面是不是只剩下一个无意义的点击？
这个问题不能用“能”或“不能”一口回答。因为“知道联系人”与“正在给这个联系人发送”不是一回事。前者是历史事实，后者是当前状态。数据库可以告诉我某个会话曾经存在，却不能单独证明当前窗口里登录的是哪个账号，也不能证明界面现在选中了哪个目标。
这件事表面上是一次转发提速，实际上是在划分自动化的责任边界。边界不清楚，优化越多，误写的机会反而越大。
数据库知道过去，界面确认现在
数据库最适合回答的是“已经发生过什么”和“系统保存了什么”。例如，联系人记录、会话标识、消息时间和消息内容，都可以作为稳定事实。它们适合用来做候选定位、去重和事前核对，也适合在动作完成后做结果回读。
但桌面应用并不是一张静态表。账号可能切换，窗口可能被别的操作覆盖，当前焦点可能落在另一个会话里，联系人也可能从未真正建立过可发送关系。好友申请更明显：数据库里有一个联系人候选，不代表界面上已经完成申请，也不代表对方关系状态允许下一步动作。
我后来把问题拆成了3层。第一层是数据层，负责稳定事实和候选定位；第二层是界面层，负责当前账号、当前窗口、当前选中对象；第三层是写入层，负责发送、申请和其他会改变状态的动作。这样一拆，很多争论就不再是“要不要截图”，而是“这一项事实究竟由谁能确认”。
数据层可以替代大量重复读取，但不能替代对当前账号、当前窗口和最终写入对象的确认。
如果不处理这个区别，后果不是偶尔慢一点，而是可能把消息写进错误的会话，向错误的对象发出好友申请，或者在窗口状态已经变化后仍然盲目执行。自动化最危险的地方，往往不是它完全失败，而是它看起来执行成功，结果却写错了位置。
最容易误判的错误捷径
最容易误判的错误捷径是：看到数据库里有联系人或消息，就假设发送、加好友和当前窗口也可以完全脱离界面完成。这个想法很有吸引力，因为它把所有问题都压成一条查询和一条写入，看起来既快又简单。
但“查得到”只说明数据存在，不说明写入条件成立。数据库里保存的联系人可能是旧关系，消息记录可能来自另一个账号，窗口里也可能仍停留在上一次操作的对象。即使写入接口返回了成功，如果没有对当前窗口和结果做确认，也很难知道成功的到底是什么。
另一个捷径是完全依赖截图和 OCR，把每一步都拍下来、识别文字，再根据识别结果点击。它确实能提供可见证据，但全程截图也会带来新的问题：速度慢，隐私暴露面变大，识别错误还可能把一个相似名字当成另一个名字。为了避免盲写而把所有过程都视觉化，同样不是成熟方案。
我没有选择这两个极端，是因为它们分别把所有信任压给了数据，或把所有信任压给了视觉。前者忽略当前状态，后者忽略稳定事实。真正需要的不是更多信息，而是让每个信息出现在它最有用的环节。
我选择保留最小的界面验收
我的选择是：能由数据层确认的，尽量读库；涉及账号、窗口和写动作的地方，保留最小视觉核对；动作结束后，再回到数据层做结果回读。
这不是为了让流程看起来更谨慎，而是因为界面掌握着数据库没有的“现在”。当前账号是谁、窗口是否在前台、目标是否真正被选中、按钮是否处在可执行状态，这些都属于瞬时状态。它们不一定适合长期保存，却决定了这一次动作能不能安全发生。
在实践里，可以先用数据层把目标缩小到一个候选，再用界面确认当前账号和窗口。确认通过后，只执行一个最小写动作，不把不必要的页面操作串在一起。写入完成后，读取结果验证消息或关系状态是否真的变化。如果界面核对失败，就停止，而不是用旧数据继续猜。
最小视觉核对的价值，不是记录每一个像素，而是在不可替代的状态边界上阻止盲写。
这也回答了“能不能不依赖 OCR”的问题。能不用的地方就不用。联系人候选、消息事实、历史状态可以优先从数据层读取；只有在文字识别确实承担了确认作用时，才保留它。即使需要视觉，也不必全程截图，可以采用一次定位、一次动作、一次结果确认的短链路。
把方法写成能力矩阵
这次真正留下来的，不是一条更快的命令，而是一张能力矩阵。以后遇到类似的桌面自动化，我会先把动作写成“事实、状态、写入”3列，再逐项判断来源。
事实类问题包括联系人是否存在、消息是否存在、历史记录是什么。这一列优先读数据库，因为数据库在这里更快、更稳定，也更适合做去重和事前检查。状态类问题包括当前登录账号、当前窗口、当前焦点和当前选中对象。这一列必须回到界面或等价的当前状态入口，不能由历史记录代替。写入类问题包括发送、好友申请和其他会改变关系或内容的动作。这一列要采用最小操作，并且必须有结果验收。
具体流程可以压缩成4步。先读库，得到事实和候选；再核对界面，确认账号、窗口和目标；然后执行单一写动作，避免把多个不可逆操作混在一起；最后回读结果，确认状态发生了预期变化。任何一步证据不足，都不把下一步当成已经成立。
这套方法也适合跨电脑、跨账号复用。可迁移的是数据字段、候选定位规则和验收逻辑；不能直接复制的是当前登录态、当前窗口和设备上的即时状态。换电脑时，如果把前者和后者混在一起，流程就会误以为“技能已经复制”意味着“动作可以直接执行”。真正可复用的应该是判断链，而不是某一次窗口位置或某一份登录环境。
速度优化的边界在哪里
用户比较1人和2人的耗时，其实给了我一个很重要的提醒：速度优化要优先减少重复确认，而不是直接删除所有确认。可以缓存联系人候选，可以提前读消息，可以把不会改变状态的查询并行化，也可以让每次界面操作只处理当前必要的一步。
但账号核对、目标核对和结果回读不能因为“看起来重复”就全部删掉。它们承担的是风险控制，不是单纯的性能成本。少一次截图可能节省时间，少一次关键确认却可能让错误消息直接落地。效率应该建立在边界清楚之后，而不是用更快的速度掩盖边界不清。
这件事让我重新意识到，一个流程成熟的标志，不是它能在理想状态下跑得多快，而是它在状态变化、关系不完整和目标不确定时，知道在哪里停下来。真正难的不是把动作自动执行，而是判断哪些地方可以放心自动化，哪些地方必须把决定权留给当前界面。
下次我会怎么做
下次再做桌面消息转发，我会先画一张简单的能力矩阵，不从“能不能彻底免界面”开始，而从“这一步的事实由谁确认”开始。联系人和消息先读库，账号和窗口回到界面，写动作坚持最小化，完成后再回读结果。
如果要优化速度，我会先统计每一步到底在重复确认什么，再删除不产生新证据的重复操作。对于会改变状态的动作，宁可保留一次短而明确的核对，也不把它交给旧记录或模糊匹配。遇到好友申请这类关系变化更大的动作，还要把“候选存在”和“关系已建立”严格分开。
如果需要换电脑或换账号，我会把可复用部分写成流程：读事实、找候选、确认当前状态、执行单一动作、回读结果。设备、账号和窗口只作为运行条件，不把它们伪装成技能本身。
一个流程真正值得沉淀的，不是它能否完全离开界面，而是它能否在数据事实与当前状态之间建立一条可验证的安全链路。
这条链路看起来没有“全自动”那么漂亮，却更接近真实工作。数据库让自动化少走弯路，界面让它知道此刻正在面对谁，结果回读则让“执行过”与“做对了”不再混为一谈。工具真正改变的不是速度本身，而是我们能不能把判断留下来，让下一次少依赖临场猜测。