开发日志251127,28

date
Nov 28, 2025
slug
开发日志251127,28
status
Published
tags
计算机
AI
summary
这两天修改了日志对象 导致了意外bug 内存溢出 最后来喜app会崩溃 我原以为是软件限制什么的 查了大半天的错 结果是日志的问题 日志优先级又很高 难怪直接死掉🥲
type
Post
这两天修改了日志对象 导致了意外bug 内存溢出 最后来喜app会崩溃
我原以为是软件限制什么的 查了大半天的错 结果是日志的问题 日志优先级又很高 难怪直接死掉🥲
今天尽量完善了刷视频脚本的基础流程 为以后各类脚本打基础 整体代码流程如下:
flowchart TD
    A[开始运行脚本] --> B[初始化环境]
    B --> C[启动抖音应用]
    C --> D[模拟上滑操作]
    D --> E[获取当前视频信息]
    
    E --> F{判断视频类型}
    F -->|直播间| G[记录直播间状态]
    F -->|普通视频| H[获取作者信息]
    
    G --> I[操作完成]
    H --> J{随机点赞判断<br>4%概率}
    
    J -->|执行点赞| K[查找点赞按钮]
    J -->|不点赞| L[跳过点赞]
    
    K --> M{点赞按钮<br>是否在屏幕上}
    M -->|| N[点击点赞按钮]
    M -->|| O[点赞失败]
    
    N --> P[验证点赞结果]
    P --> I
    O --> I
    L --> I
    
    I --> Q[随机休眠5-30]
    Q --> R[上报运行结果]
    R --> S[结束脚本]
    
    subgraph 初始化环境
        B1[设置屏幕尺寸] --> B2[显示控制台] --> B3[初始化变量]
    end
    
    subgraph 启动抖音应用
        C1{检查是否在前台} -->|| C2[已在抖音]
        C1 -->|| C3[返回桌面] --> C4[启动抖音]
    end
    

    subgraph 点赞流程
        K1[查找未点赞按钮] --> K2[过滤屏幕内元素] --> K3[提取点赞数] --> K4[执行点击]
    end
    
        subgraph 获取作者信息
		    D1[查找&commat;开头元素] --> D2[过滤屏幕内元素] --> D3[提取作者文本]
    end
    
notion image
这段脚本在执行刷视频这方面应该没什么问题
但是需要注意几个问题
  1. 目前没有加入关键词,目前将 点赞功能 写入了 刷视频 的流程.以后应该要根据 关键词 提高点赞概率;此外在评论时也需要根据 关键词 确定是否需要评论. 关键词应该是需要跟 主机 交换信息获取 考虑用 node.js fetch 方式获取 然后在主机本地储存
  1. 现在的脚本判断下一次任务的功能只会返回所需的脚本地址 暂时没做处理文件上传等的功能 后面看怎么处理
  1. 日志本地保存 的功能暂时没写 因为现在还处于 开发阶段 , 暂时没有 生成报表 等的需求 所以暂时搁置 反正目前可以通过 控制台 看到本次运行的日志
  1. 需要在以后支持 日志分级输出 的功能 防止被大量dev日志污染
  1. 现在会有碰到广告和各类弹窗的问题 暂未处理
明天要开始处理 抖音发评论 功能 现在许多功能已经实现了 希望写起来能更轻松一些 另外也要同时解决上面的一些问题
我的想法是前面的代码不动 从随机点赞模块开始修改 直接点进评论按钮进行评论
乍一看很简单 但是在这一部分我主要需要克服几个 问题 :
  1. 现在评论不能 无脑评论 ,暂时应该没有办法 根据视频内容 进行评论.但是可以根据视频下的 其他评论内容 进行评论.这里要写一个接口,先发送请求到主机,请求获取本次评论所需的内容,然后返回到手机;主机上也需要写一个接口方便以后接入到 AI 工具(留空)
流程如下
graph TD
  A[手机] --发送内容请求--> B[主机] --发送AI生成请求-->C[AI生成端]
  C--返回AI生成结果-->B --返回评论内容--> A
notion image
  1. 需要针对设备的关键词判断是否增大进入的概率 流程同上
  1. 可能需要处理 遇到其他群控账号 发布的视频针对性评论的问题

后续在抖音单平台还需要的一些功能:
  1. 发布视频
  1. 评中评 这个可能涉及到AI分析

以后要加强的地方:
  1. 以后尽量勤commit 尽量做到 修改一个功能就提交一次 否则起不到GitHub仓库维护的灵活性 这样可以 更灵活 的处理问题 当某个功能 出现BUG 时可以针对性退回commit 防止像这两天出现的 修改了大量功能而无从查错退回 的情况

再接再厉


© Dominic Hodpel 2022 - 2025