I recently used AI as the primary development interface for a small WeChat mini game called Weiguang Xinyu.
The one-day result was a working ten-level Canvas2D puzzle, an original background track, a passing local test suite, and a successfully uploaded development build. The public release followed later.
This post focuses on the technical workflow and the evidence boundary between those two stages.
The mechanic is compact: rotate path segments to connect a light source to a destination.
The build includes:
The first version did not depend on a cloud environment, external server, personal-data API, advertising, or payments. That kept the test surface controlled enough for a one-day experiment.
I used voice as the primary interface and treated AI as a coordinated implementation system rather than a one-shot code generator.
requirement
-> implementation
-> local test
-> visual inspection
-> packaging check
-> development upload
-> remote source readback
Each loop ended with an observable artifact. A plausible answer in a chat window did not count as completion.
The game uses Canvas2D for rendering and separates the core puzzle state from platform-specific behavior.
game state + level data
|
+-- input and rotation logic
+-- path connectivity checks
+-- progress persistence
+-- renderer
+-- audio controller
|
+-- browser adapter
+-- WeChat adapter
This separation mattered because local browser previews and the WeChat runtime do not expose identical audio APIs or lifecycle behavior.
The music starts only after the first user interaction, loops when enabled, s in the background or during interruptions, and stores the user's preference. Audio failure does not block gameplay.
The final local suite reported 13/13 tests passing. The checks covered the original puzzle behavior together with the music controller and platform adapters.
The upload alone was not treated as proof that the intended source had reached the platform. After the official development-build upload succeeded, the remote source map was read back. Thirteen remote source files matched the local source files.
That is useful evidence, but it has limits. It does not replace real-device testing, prove every binary asset is byte-identical, or mean the build is already public at that moment.
| State | Evidence |
|---|---|
| Local prototype | The project runs locally and the core interaction works |
| Tested build | Defined tests pass and the relevant UI is inspected |
| Uploaded development build | The platform accepts the build and the result is read back where possible |
| Public release | Review is approved and ordinary users can access the production version |
The process screenshot captured the tested-and-uploaded stage. The project later reached public release.
AI was especially effective at keeping related changes synchronized:
The speed came from many small verified loops, not from a single giant prompt.
The hardest decisions were not syntax decisions. They were questions such as:
AI reduced implementation cost. It did not remove product judgment or release responsibility.
Yes, AI can help one person build a small game in a day.
The more useful claim is narrower: AI can compress the path from idea to a tested, uploaded development build when the scope is controlled and every stage ends with evidence. The release can then follow through its own verified steps.
That is already a major change. Just do not call the development upload a launch before the later launch is actually complete.