38 lines
3.1 KiB
Markdown
38 lines
3.1 KiB
Markdown
# Process
|
|
|
|
## 2026-04-19
|
|
|
|
### 今日战利品
|
|
- 修复了 163 邮箱顶部“刷新”按钮的识别问题。
|
|
- 根因不是插件不知道顶部按钮在哪里,而是它用 DOM 文本做识别时,代码只认“刷新”,但 163 实际渲染出来可能是“刷 新”。
|
|
- 给 `163` 邮箱补上了回归测试,确保以后再次遇到这种带空格的按钮文案时,脚本仍然会优先点击顶部工具栏刷新,而不是误退回到“收件箱”。
|
|
- 额外补了更直白的刷新分支日志,后续排查时可以直接看出本次命中的是“顶部刷新”“左侧收信”还是“收件箱兜底”。
|
|
|
|
### 知识地图
|
|
- 这一块属于“自动化脚本稳定性”里的 DOM 识别层。
|
|
- 老板可以把它理解成:脚本不是靠“看见页面上方那个位置”去点按钮,而是靠“读页面结构里的标签文字和属性”去认目标。
|
|
- 所以这里学到的核心不是某一个按钮怎么点,而是“页面自动化里,视觉上像同一个按钮,DOM 文本却可能有空格、换行、图标包裹等变体”,识别逻辑必须做抗噪处理。
|
|
- 这部分在大神知识体系里,位置属于:前端页面结构理解 -> 浏览器自动化 -> 选择器与文本匹配鲁棒性。
|
|
|
|
### 下一步导航
|
|
- 可以继续把 163 的删除兜底逻辑也做一次同类检查,因为顶部“删 除”从 DOM 结构看也可能存在同样的空格拆字风险。
|
|
- 如果老板接下来还想继续提稳收信成功率,可以再查一层:163 顶部“刷新”点击之后,页面到底有没有真正触发新的列表请求,以及请求完成信号该监听什么。
|
|
- 如果要把这一块做成长期稳定方案,下一步适合补“刷新动作观测点”日志,比如记录刷新前后列表首封邮件 ID、请求时间、是否出现 loading。
|
|
|
|
|
|
## 2026-04-19 Step 2 纠偏补充
|
|
|
|
### 今日战利品
|
|
- 修复了中文按钮 继续使用电子邮件地址登录 无法被 Step 2 识别的问题。
|
|
- 修复了后台把 步骤 2:当前页面仍停留在手机号输入模式... 这类错误误判成 auth dd-phone 致命页的问题。
|
|
- 现在自动运行只会在真正命中认证流程的手机号页面时才按 fatal 停止,不会因为注册弹窗还停留在手机号输入态就整轮停机。
|
|
|
|
### 知识地图
|
|
- 这一块属于“错误分类系统”和“页面状态系统”的交叉地带。
|
|
- 老板可以把它理解成:同样都带“手机号”三个字,但“注册弹窗默认展示手机号输入框”和“认证流程真的跳进 add-phone 页面”在业务意义上完全不是一回事。
|
|
- 大神体系里,这属于自动化系统里很重要的一层:不仅要会识别页面,还要会给错误正确分级。
|
|
|
|
### 下一步导航
|
|
- 如果老板接下来还想继续提稳 Step 2,可以把“手机号态切邮箱”的点击前后 DOM 快照也打进日志里,这样下次能直接看出是“按钮没识别到”还是“按钮点了但页面没切”。
|
|
- 如果后面再遇到多语言 UI 变体,优先考虑把按钮识别继续升级成“关键语义词 + 排除词 + 结构位置”三段式判断,抗漂移会更强。
|