TechXueXi: a Selenium-driven study-points automator for XueXi QiangGuo, packaged as a Docker service

What TechXueXi automates, and who it is written for

TechXueXi is a Python tool that drives a browser session against XueXi QiangGuo and performs the daily tasks that award study points. The README states the target plainly: "TechXueXi 是一款使用python语言编写的学 xi 工具。可达 45 分/天" (a study tool written in Python, reaching 45 points per day). The repository topics include auto-xxqg, xuexiqiangguo and xxqg, and the description calls it an open source web helper for the platform that supports answering questions and Docker.

The audience is narrow and explicit. The README says the maintainers are IT workers who kept rewriting the same scripts individually and decided to maintain one shared codebase instead: "许多IT人员本终日埋头写代码，确实有需求，与其各人重复修改编写浪费生产力不如团队合作维护". The project describes itself as maintained by an organisation called 科技强国, built on an earlier project that has since stopped, and it asks users to file issues here rather than disturb the original author. If you are not a XueXi QiangGuo user, there is nothing here for you; the whole codebase exists to satisfy one platform's point rules.

How the automation actually runs: Selenium, Chrome, and a scheduled entrypoint

The mechanism is browser automation, not an API client. requirements.txt lists selenium==3.141.0, beautifulsoup4, lxml, pyzbar, Pillow, Flask, Flask_SQLAlchemy and pyTelegramBotAPI. That mix tells you what happens at runtime: Selenium drives a real Chrome binary, BeautifulSoup and lxml parse pages, pyzbar and Pillow handle QR-code login images, and Flask serves the local web interface.

The Dockerfile makes the dependency chain concrete. It starts FROM python:3.7-slim, installs wget, unzip, libzbar0, git, cron and supervisor, then downloads google-chrome-stable_92.0.4515.159-1_amd64.deb and chromedriver_linux64_92.0.4515.107.zip, unzips the driver, chmod 755 on it, and verifies it with ./chromedriver --version. The image sets TZ=Asia/Shanghai and defaults such as Pushmode=1, Nohead=True, islooplogin=False and CRONTIME="30 9 * * *". It then clones the source into /xuexi/code, copies SourcePackages into /xuexi, exposes port 80 and runs start.sh. Scheduling is cron inside the container, with supervisor managing the processes, which is why the compose file sets CRONTIME rather than asking you to write a crontab.

That pinning is the design's biggest constraint. Chrome 92 and chromedriver 92.0.4515.107 are fixed in the image, so a change on the platform side that breaks that pair cannot be fixed by upgrading Chrome alone: you would need a rebuilt image or a changed Dockerfile argument. The README does not document what happens when the bundled driver stops matching the site's expectations.

Installing TechXueXi with Docker Compose and running the first cycle

The repository ships a docker-compose.yaml that uses the published image techxuexi/techxuexi-amd64, so you do not build anything. Create the compose file with the service definition below, or clone the repository and use the file as it is. The volume maps ./xuexi on the host to /xuexi/user in the container, which is where account state and configuration live, so keep that directory between upgrades.

services:
  techxuexi:
    image: techxuexi/techxuexi-amd64
    container_name: techxuexi
    restart: unless-stopped
    volumes:
      - ./xuexi:/xuexi/user
    ports:
      - 9980:80
    shm_size: 2gb
    environment:
      - CRONTIME=5 */6 * * *
      - Pushmode=6
      - ZhuanXiang=True

The shm_size of 2gb is not decorative: Chrome needs shared memory, and the default 64 MB often makes the browser crash inside a container. Start it with the usual compose command.

docker compose up -d

The compose file's own comment says what to do next: "运行之后打开IP:9980即可" (after it runs, open IP:9980). The web UI is served on container port 80, published as host port 9980, so you log in there rather than at the command line. The first cycle then runs on the cron schedule you set through CRONTIME; the compose example uses 5 */6 * * *, meaning every six hours at five minutes past the hour. Pushmode selects how results are reported, and the Dockerfile default is 1 while the compose example sets 6; the README does not enumerate the modes, so check the wiki before changing it. ZhuanXiang=True is likewise set in the example and not explained in the README.

Where TechXueXi breaks, and when it is the wrong choice

The most serious limitation is announced by the maintainers themselves. The README carries the notice "我们随时删库跑路，请加交流群防失联" (we may delete the repository and run at any time, so join the chat group to avoid losing contact), and it tells readers to watch the repository and to follow the announcement channels on Telegram or the Cloudflare Workers notice page. A tool whose own authors advertise an exit plan is not something to build a workflow on without a mirror or a fork you control.

The second limitation is version drift. The project sits on Python 3.7 and Selenium 3.141.0, and the image pins Chrome 92 with chromedriver 92.0.4515.107. Selenium 4 changed the driver-management model, and Chrome has moved far past 92, so the container is a frozen snapshot rather than a maintained stack. If the site's front end changes in a way that the bundled driver cannot handle, the failure appears as a Selenium exception or a stalled login, and the README does not describe a recovery path beyond reading the issues and the wiki.

The third is that this is the wrong tool for anyone who wants an auditable record of their own study activity. It automates a browser session against an account; it does not produce a report of what was studied, and the point total is whatever the platform awards. If your goal is a local log of reading and answers, TechXueXi does not provide one.

How TechXueXi differs from writing your own requests-based script

The obvious alternative is a small script that calls the platform's HTTP endpoints directly with requests, which requirements.txt already includes at version 2.26.0. That approach is lighter: no Chrome, no chromedriver, no 2 GB of shared memory, no supervisor or cron inside a container. It also breaks more often, because you have to reproduce whatever signing, headers and session handling the web client uses, and you have to notice when the endpoints change.

TechXueXi takes the opposite position. It pays the weight of a full browser and a 2 GB shm allocation so that the automation behaves like a person clicking through pages, and it wraps that in Flask so you can log in through a web page instead of pasting cookies into a script. The trade is resource cost and image size for a smaller surface of platform-specific reverse engineering. Neither approach is documented here as more reliable; the repository only states the 45 points per day target and the Docker packaging. If you already maintain a requests-based script that works, TechXueXi is not an upgrade, it is a different maintenance burden.

Maintenance, licensing and the upgrade path you inherit

The default branch is developing, and the last push was on 2026-03-27, so the repository is not archived and work is still landing. The release history is stale by comparison: the newest release is v20220126, published on 2022-02-03, preceded by v20211221 on 2022-01-14 and v20211103 on 2021-11-08. Anyone pinning to a release tag is pinning to a build from early 2022, while the branch and the Docker image move separately. That mismatch is the practical upgrade cost: you either track the image tag and accept the branch's state, or you build from the Dockerfile yourself, in which case the ARG usesource and ARG usebranche values decide what gets cloned, and the defaults point at a mirror host and the dev branch.

The licence is LGPL-3.0, and the repository includes a LICENSE file. The README adds its own terms on top: it describes the project as "开源非营利项目" for exchange between programmers, forbids commercial use and any profit-making activity, and disclaims responsibility for consequences of illegal use. Those extra restrictions are the maintainers' own statement, not the licence text, so read both the LICENSE file and the README's disclaimer section before you decide how you may use the code. This is a description of what the documents say, not legal advice.

Operationally, the upgrade path is the volume. Because ./xuexi maps to /xuexi/user, replacing the container image does not wipe account state; the Dockerfile even contains a commented-out line that would remove /xuexi/config. Keep the host directory, pull a new image, and the cron schedule and push settings come back from the environment variables in your compose file.

Editorial conclusion

Adopt TechXueXi if you want a self-hosted Docker service that drives a real Chrome session against XueXi QiangGuo and you accept that the repository's own README warns it may delete itself at any time. Do not adopt it if you need a stable, versioned dependency you can pin: the newest release is v20220126 from 2022-02-03, the Dockerfile pins Chrome 92 and chromedriver 92.0.4515.107, and the README points to an external wiki for anything beyond the basics. Before you commit, read the wiki, DOCKER.md and 使用方法-更新方法-下载方式.md, then confirm the CRONTIME, Pushmode and ZhuanXiang environment variables in docker-compose.yaml match your schedule and your push channel.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. TechXueXi/TechXueXi on GitHub