From Prompt to WeChat Dev Build in One Day: Tests and Evidence Boundaries

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.

Product scope

The mechanic is compact: rotate path segments to connect a light source to a destination.

The build includes:

• ten puzzle levels
• level selection and unlocking
• undo and restart
• one free hint per level
• local progress persistence
• an original looping background track
• a music toggle with stored preference

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.

The working loop

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.

Architecture

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, pauses in the background or during interruptions, and stores the user's preference. Audio failure does not block gameplay.

Testing and readback

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.

The four-state model

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.

What AI was good at

AI was especially effective at keeping related changes synchronized:

• updating implementation and tests together
• aligning the product name across the UI, project metadata, and review copy
• generating repeatable checks instead of relying only on manual inspection
• documenting the current state after each meaningful transition

The speed came from many small verified loops, not from a single giant prompt.

What still required human judgment

The hardest decisions were not syntax decisions. They were questions such as:

• Is the mechanic understandable without explanation?
• Is a level difficult for the right reason?
• Does the visual and audio mood support the product idea?
• What evidence is strong enough for the next claim?
• Which platform step changes the truthful status of the project?

AI reduced implementation cost. It did not remove product judgment or release responsibility.

Takeaway

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.