今日“题目”复盘

一些思考（开篇）

在 AI 时代，如果只是掌握几个工具的使用方法、按照既定流程做事，确实很容易被淘汰。那什么样的能力更能让自己站稳脚跟呢？
我目前的思考是：

• 处理任务时清晰、缜密的思维
• 在有限信息条件下，快速找到问题关键点的能力
• 快速学习的能力

听起来有点空，但我也确实打算在这三方面好好成长。

正文

我尝试把每一个任务、每一个项目，都当成高中时代的一道题来分析。
这种思路更偏向个人成长，可读性不一定好，还请读者见谅。

今天遇到的问题大致是：
针对别人项目组的产品代码，写一个调试打印函数，打印特定消息在解密前后的密文、明文、密钥等信息。

协议底层传上来的数据本身就是密文，密钥也可以通过 getxxCipherKey 在解密函数前直接获取，打印不难。
真正让我花时间的，是找到明文。

下面是一个简要的过程概述，实际操作比这更琐碎一些：

1、先在 DeCrypt 函数后面，直接打印原本存放密文的结构体成员变量，发现还是密文，没有变化。

2、在函数前后翻找，尝试打印一个叫 DstBuf 的变量，发现也不是明文。

3、不再盲目尝试，去看 DeCrypt 的具体实现，发现它用的是公共组件。开始有点沉不住气。
在公司代码搜索平台搜这个函数的实现，搜到一个结果，但不确定版本是否适配。粗略看下来，里面没有实际解密的调用，应该不是本包真正使用的解密函数。
于是没了耐心，不再继续搜代码，又回到打印尝试的老路上。

4、打印 DeCrypt 函数传入的第一个参数（一个叫 pPPeBuf 的变量），这个变量名不太像是解密结果要存入的位置。再看结构体内部，也没有类似 plain_text 或 decoded_xxx 的成员。
打印出来的内容大多为空，唯一有点价值的 xxx_len 也是 0。不过这个变量类型是一个节点，明文也可能存在其他节点里。这一阶段主要是各种尝试，没有深入。

5、另一个结构体 secAlgo 包含密钥、算法等成员。注意到其中有一个成员，指定解密后的内容是覆盖原位置，还是存入指定地址。
打印该结构体后，发现配置是“覆盖原位置”，并不是存入指定地址（如果是后者，那指定地址就是明文存储位置）。

6、到这一步，我还没找到明文，于是找师父求助。
师父比我果断得多，直接在公司代码搜索平台搜 DeCryptxxx 这个函数。一开始也搜到了我遇到的那个函数（不含解密操作，我当时就停在这里了）。
他看到这个函数不含解密操作后，继续搜索，最终找到了真正包含解密操作的定义。

7、所以，结合我自己的打印调试和现在找到的公共函数实现，接下来的方向是：
在 DeCrypt 函数定义上继续深挖，找到明文真正存入了哪个成员。

关键点分析

1. 事后诸葛亮角度

错误的路径：
先后打印——

• 存有密文的成员
• DstBuf
• secAlgo 变量
• pPPeBuf 的每个成员

每次尝试都要重新编译并升级到设备上，耗时十几分钟。
先后分析、修改、验证，非常耗时。

正确的路径：
直接在公共代码平台搜索 DeCryptxx 的具体实现 → 读完第一个错误实现后，继续找到第二个正确实现。

2. 客观因素分析

1. 这是别的项目组的代码，没有文档。能摸到复盘起始的位置，已经花了不少时间和精力，后续耐心不足。
2. 自己的代码阅读能力可以进一步提升，这样阅读过程会更轻松一些。
3. 已知密文存储变量，又看到 DstBuf、pPPeBuf 是解密函数的第一个参数，很容易以为明文就存在它们里面。
4. 为什么没有一次把所有怀疑的变量都打印，而是一次次试？→ 因为每次都觉得“这次肯定对了”，结果错了才去找下一个。
5. 公司的公共代码搜索平台体验一般，不太爱用……

3. 如果我有上帝视角

那肯定就是：

• 直接去搜解密函数的定义 → 跳过第一个错误的 → 找第二个正确的。

4. 可以优化的步骤

• 进一步提升代码阅读能力，阅读能力提升后，自己“通过打印调试来验证猜想”的倾向会降低，理清代码的倾向会变高。
• 多熟悉公司代码搜索平台，目前用得少、不熟，所以浅尝辄止
• 函数名 xxxDecrypt(参数1, 参数2, 参数3)，按惯例，参数1 确实是密文输入和明文输出的位置
• 既然每次升级成本这么高，那第一次失败之后，应该先停一两分钟，缓解下脑力，然后应该先列出可能的明文存储位置，并确定每个可能位置的依据。不断试错成本有点高，沉没成本又引导着自己进一步投入时间。
• 现在 AI Agent 工具已经很强了，完全可以让我让 Agent 帮忙分析一下
• 探索路径有点随机，缺乏结构化
• 投入过多，产出不符合预期时会沉不住气，每当遇到这个时候，停下来重新分析一下，或者拉着不忙的同事喝咖啡并聊一聊。