Zero-Cost QQ Group Minesweeper Bot in 6 Minutes with DeepSeek

From "Writing Word Banks" to "Letting AI Write Scripts"

In the QQ group bot ecosystem, "word banks" (词库) used to be the most common way to drive interaction — mapping preset question-answer pairs to let a bot respond to specific content. Technically speaking, a word bank is a rule-based text matching system at its core: a mapping between predefined trigger keywords and response content. This design resembles a simplified Finite State Machine (FSM), where each rule is an independent state transition — input a keyword, output a fixed response.

For context, FSM is a classic mathematical model in computer science that describes system behavior using a finite set of states, transition conditions, and actions. As a simplified FSM variant, each word bank rule represents a memoryless, single-step transition — meaning the system retains no information about conversation history after responding. Modern dialogue systems typically introduce "Slot Filling" mechanisms or stateful dialogue managers to track multi-turn context, breaking past this limitation — but word banks were never designed with any such mechanism. Without persistent context memory or dynamic variable support, word banks fundamentally cannot handle scenarios that require "remembering what happened in the last step" — and that's their core bottleneck when faced with complex interactions.

As large language models have become mainstream, more people have started using AI to generate word banks directly. However, this path is far less smooth than it sounds.

As one Bilibili creator discovered in practice: many AI-generated word banks simply won't run. Even those that appear to "work" are often riddled with problems on closer inspection. Complex logic like randomized reward systems is nearly impossible to implement correctly within the word bank framework. A word bank is fundamentally a static, text-matching rule system — great for simple Q&A, but ill-suited for game logic like Minesweeper that requires state management, dynamic computation, and multi-step interaction.

This explains why the creator chose a different path: abandoning word banks entirely and letting AI write a complete Python bot script from scratch.

The OICQ Framework + DeepSeek Approach

The core of this experiment was using the OICQ bot framework together with the DeepSeek large language model to generate a runnable game script.

A bit of background on OICQ-type frameworks: frameworks like go-cqhttp and ecosystem components such as NoneBot are third-party bot development tools built by reverse-engineering QQ's communication protocol. They provide Python APIs for message sending/receiving, group management, event listening, and more. The underlying mechanism reconstructs Tencent's proprietary OICQ/TEA encrypted protocol through reverse engineering, simulating a standard QQ client's login and messaging behavior locally. The tech stack typically has three layers: the protocol layer (handling handshakes, encryption/decryption with Tencent's servers), an event bus (converting incoming messages into structured events), and a plugin system (where developers attach custom logic). Since the protocol isn't officially open to third parties, Tencent can change protocol details at any time and break these frameworks — which is the fundamental reason such tools have long existed in a "gray area." Despite this, their openness and flexibility have earned OICQ-type frameworks a vibrant community of users and rich documentation.

The overall approach breaks down into three steps:

Step 1: "Feed" the Official Docs to the AI

The key move here is simple: navigate to the framework's official website, copy the URL of its documentation, then hand that link to DeepSeek.

This touches on an important concept in AI code generation: large model hallucination. When generating code, LLMs sometimes "invent" function names, parameter signatures, or API interfaces that look plausible but don't actually exist — because the model's training objective is to generate linguistically coherent content, not to guarantee factual accuracy. In code generation, hallucination typically manifests as calling a method that never existed, or making incorrect assumptions about how a library works, causing the code to crash at runtime.

By providing the official documentation URL as context input to the AI, you're essentially giving the model a "factual anchor." This approach is rooted in the principle of Retrieval-Augmented Generation (RAG): RAG was originally designed to let language models reference external knowledge bases when answering questions, rather than relying solely on static knowledge compressed into model parameters during training. In code generation, the model accesses up-to-date documentation to obtain accurate API signatures, parameter types, and usage examples — treating these as "factual anchors" in the context window to constrain output within the range of real, existing interfaces. This dramatically reduces hallucination risk and improves the usability of generated code. As major model providers roll out versions with web browsing capabilities, this "read docs first, then write code" paradigm is becoming a standard workflow in AI-assisted programming.

The creator's prompt was straightforward: "Please read this website's documentation and help me write a Minesweeper game script in Python. The game should have a command menu, which can be rendered using HTML converted to an image."

Step 2: Iteratively Refine the Prompt

The first-pass output wasn't ideal because the prompt lacked precision. The creator quickly followed up with more specific requirements: "Please use the documentation to give me a complete Python script that can run on a third-party bot." This iteration directly targeted two core goals — "runnable" and "based on the docs" — and the output quality improved noticeably.

This illustrates an important lesson in AI-assisted programming: the precision of your prompt directly determines the quality of the output. Prompt engineering is an emerging technical discipline focused on how to effectively guide large language models through natural language instructions. The core insight is that LLMs are fundamentally predicting "the probability of the next token" — the wording, order, and constraints of your prompt directly shape the model's probability distribution over the desired output space. Effective strategies include role assignment, constraint injection, few-shot examples, and chain-of-thought guidance. Rather than expecting perfection on the first try, it's more productive to converge through multiple rounds of dialogue — each round constrains and calibrates the model's output space. Adding qualifiers like "runnable," "based on the docs," and "complete code" effectively communicates evaluation criteria to the model, progressively narrowing output variance and steering the model toward higher-quality solutions.

Deployment and Pitfalls: The Real-World Process

Generating code is just the first step. Actually getting the script running requires a series of configuration steps. The creator's hands-on process was refreshingly honest, complete with several "oops" moments.

The configuration flow went roughly like this: locate the OICQ folder, navigate to the code directory, create a new Minesweeper game file, paste the AI-generated code in and save. The main script was named main.py and saved the same way.

It wasn't all smooth sailing — the creator accidentally created the wrong folder at one point, and ran into a connection that froze up. The fix was delightfully simple: quit and restart. After rebooting, the connection came back and the script loaded successfully.

These seemingly minor hiccups actually paint an honest picture of AI-assisted development: code generation becomes incredibly efficient, but environment setup and file management still require human intervention. AI can write 90% of your code — the remaining 10% of deployment details still demands hands-on effort.

Live Results: A Minesweeper Game That Actually Works

After the script refreshed and loaded, the creator began testing. First, entering a command to pull up the menu — both 菜单 and help work as triggers — and the bot successfully returned the command list.

Next, testing the core gameplay: using board to view the grid and open to reveal cells.

It's worth noting that Minesweeper is algorithmically non-trivial — it's actually a fairly representative benchmark for testing AI code generation capabilities. The core mechanics involve multiple algorithmic challenges: the random mine-placement algorithm needs to distribute mines uniformly across a 2D array while ensuring the player doesn't hit a mine on their first click; revealing blank areas requires a recursive Flood Fill algorithm — borrowed from the "paint bucket" fill operation in computer graphics — which starts from the player's clicked cell and expands in all eight directions (up, down, left, right, and diagonals), recursively revealing each cell where the surrounding mine count is zero, until all adjacent safe cells are uncovered. Notably, on large boards, a naive recursive implementation risks call stack overflow; in practice, this is typically replaced with a queue-based BFS (Breadth-First Search) iterative approach. The game also needs to track multiple states per cell (unrevealed, revealed, flagged, mine, etc.). All of this logic intertwined makes Minesweeper far more complex than simple Q&A — and it's precisely why a word bank solution could never handle it.

Although the creator jokingly admitted to not being great at Minesweeper and hit a mine right at the start, that was actually proof of something important — the AI-generated Minesweeper logic is genuinely functional. Mine generation, reveal logic, and explosion detection all worked correctly. The creator even brought in a friend who actually knows how to play for a full run-through.

The Value and Limitations of This Approach

What's Worth Borrowing

Zero cost and high efficiency are the biggest highlights. The entire game went from concept to running in roughly 6 minutes. Compared to manually authoring word banks or writing bot code from scratch, the "feed docs + AI generate" model dramatically lowers the barrier to entry.

The practice of generating code based on official documentation is especially worth spreading. Having the AI read the docs before writing code effectively prevents hallucinated, non-existent APIs — a key technique for improving code usability. The underlying logic here applies the concept of Retrieval-Augmented Generation (RAG) to programming assistance: using an external knowledge source to constrain model output, preserving generative flexibility while anchoring factual accuracy within a controllable range.

Limitations to Keep in Mind

First, "6 minutes" represents the ideal scenario; real-world deployment issues like connection freezes and file management overhead will eat into that time. Second, while the AI-generated Minesweeper logic runs, its robustness under stress remains to be tested — edge cases like stack overflow risk from large-area recursive flood fills and flag marking functionality need further validation.

Finally, a word of caution: using third-party bot frameworks involves QQ account security risks and platform compliance concerns. "Third-party bots" carry a real risk of account banning — proceed carefully if you choose to experiment.

Conclusion

This case vividly illustrates the new normal of AI-assisted development: when we can have AI read documentation directly and generate runnable scripts for complex logic, inefficient legacy approaches like hand-written word banks are genuinely becoming obsolete. For everyday users, mastering the methodology of "feed docs + precise prompts + iterative refinement" enables you to build things at minimal cost that used to require professional programming expertise. AI won't replace the need for hands-on skills — but it's lowering the barrier to turning ideas into reality to an unprecedented degree.

Key Takeaways