微信 AI 助手
No one would deny that when you run into a difficult problem or finish a project, you can ask on an LLM page or solve it with a Coding Agent. But what about a small question that suddenly pops into your head while you are simply chatting? Switching apps, typing the question, and waiting for the result—the cumbersome process itself wears away our curiosity and wastes a potentially interesting spark of inspiration.
So I wanted to make something more direct:
What if AI itself were one of my WeChat contacts?
There would be no extra software to open and no need to change how I already chat. I could message it directly or mention it in a group; it would understand the question, invoke the models and tools it needed, then send the answer back to WeChat.
微信 AI 助手 is the personal Windows WeChat AI assistant that grew from that idea.
What It Is
微信 AI 助手 runs alongside the Windows WeChat client and watches for new messages through desktop UI Automation.
It currently supports two main triggers:
- a direct message to the bot account
- an explicit
@mention of the bot in a group chat
When an eligible message arrives, the program first checks message identity and safety, then chooses a model and decides whether external tools are needed according to the question type.
The final answer is written back into the WeChat input field and sent.
From the user’s perspective, it is not very different from an ordinary WeChat contact:
Send a message → wait a few seconds → receive an AI reply.
Model calls, tool retrieval, and WeChat interaction all happen in the background.
Why It Is Not Just One Model API
The project gradually developed into a two-model collaboration architecture.
Instead of sending every question to one fixed model, it routes requests automatically according to their type.
OpenAI ChatGPT 5.6 Luna
OpenAI ChatGPT 5.6 Luna is the default model and mainly handles:
- general conversation
- work and study
- writing and translation
- programming
- general professional questions
- weather, news, and information from the Web
DeepSeek V4 Pro Thinking
Questions that need deeper reasoning or specialist judgment are routed automatically to DeepSeek V4 Pro Thinking. The main categories are currently:
- finance
- medicine and health
- fitness, nutrition, and exercise
- other fields that require detailed advice
Ordinary conversation goes directly to Luna, for example, while stock analysis switches automatically to DeepSeek Pro.
WeChat users actively choose which model should answer a question, and the program automatically selects the corresponding model based on the question.
Tools
The models are not limited to answering from their existing knowledge.
I also built a unified Skill / Tool layer.
- real-time market quotes
- historical candlestick data
- fundamental data
- Web Search
When someone asks about the recent movement of a stock in WeChat, the system can identify the ticker, obtain real market data, and let DeepSeek analyze that data.
User question → Agent decides what data is needed → tool call → result retrieval → model analysis → WeChat reply
It is more than simply forwarding a sentence to a model.
WeChat Desktop Automation
The difficult part of this project was not really the models. It was WeChat itself.
I use the ordinary Windows WeChat client, not a message interface designed for bots.
The program therefore has to work with the real desktop UI:
Recognition
- identify the current WeChat conversation
- distinguish new messages from message history
- recognize
@SELFin group chats - prevent the bot from replying to its own messages
Locate and write
- switch to the correct conversation
- find the input area
- write the answer
Send and verify
- find the Send button
- perform the send action
- confirm that the message was actually sent
During development, I even encountered a textbook UI Automation problem:
A text child control inside WeChat’s Send button covered the button’s original hit target. The answer could be generated and written into the input field, yet the program still could not safely establish the button’s actual clickable surface.
I eventually redesigned the Send button hit-test and transaction mechanism to complete the entire real sending path.
Problems like this are what distinguish the project from an ordinary ‘call an LLM API once’ demo.
SEND_VERIFIED
The program does not assume success just because it pressed Send once.
Every send is managed as an independent transaction.
If success can be confirmed, the state becomes:
SEND_VERIFIED
The transaction ends.
If the system knows that no send action was performed, it can fail safely and continue to the next request.
But if one real UI send action has already occurred and the system cannot determine whether WeChat accepted it, the transaction enters:
SEND_AMBIGUOUS
The system does not retry automatically in this state.
Missing one message is usually more acceptable than sending the same message twice.
When the outcome is uncertain, I prefer the program to stop and wait for human confirmation instead of risking another WeChat action.
Single-Flight Mode
The project is not designed to process large numbers of users at once.
Because its final output depends on a real Windows UI, stability matters more than concurrent throughput.
I therefore added a global BUSY single-flight mechanism.
When idle, the bot accepts only the first eligible new request.
Once processing begins, the state becomes:
BUSY
Even if other users continue to send direct messages or mention it in other groups, the program still observes those messages and advances its cursor, but it does not add them to a queue.
Those messages are discarded and are not revisited after the current answer finishes.
When the current request ends:
BUSY → IDLE
The bot resumes from the next new message that appears after that point.
This sacrifices some concurrency, but greatly reduces the risks of queues, wrong conversations, delayed replies to old messages, and changing UI state in a desktop-automation environment.
Safety Boundaries
Because the program can operate a real WeChat client, I kept strict boundaries around the send path.
Trigger Boundary
- group chats must explicitly
@the bot itself - messages already present before startup are not answered again
- group chats must explicitly
Deduplication and Echo Isolation
- the same message is not materialized twice
- messages sent by the bot do not trigger it again
Conversation and UI Control
- UI actions remain serial
- the target conversation is rechecked before sending
Send Transaction Protection
- uncertain sends are never retried blindly
- an unresolved transaction blocks new hazardous send actions
These mechanisms sacrifice some of the convenience of ‘reply whenever possible,’ but for a program that controls a real WeChat account, I care more that it:
does not message the wrong person, does not send duplicates, and does not lose control when the UI changes.
Current Status
The complete path has now been verified in a real WeChat environment.
The tested scenarios include:
General conversation
WeChat → Luna → answer generation → WeChat send
Finance questions
WeChat → DeepSeek V4 Pro Thinking → market-data Skills → analysis → WeChat send
Fitness / nutrition questions
WeChat → DeepSeek V4 Pro Thinking → WeChat send
I have also verified:
Message Entry and Protection
- group-chat
@SELF - automatic direct-message replies
- message deduplication
- historical-message protection
- group-chat
Models and Tools
- automatic model routing
- Tool Calling
- Web Search
- market-data calls
Sending and Concurrency
- send transactions
SEND_VERIFIED- unresolved transaction protection
- global BUSY single-flight processing
Still to Solve
Skills Expansion
The existing Skill / Tool system already covers some common capabilities. I would like to add more Skills over time so that WeChat can handle a broader range of tasks instead of stopping at question answering alone.
Relative Dates
When a question uses a relative date such as “today” or “tomorrow” instead of a specific date, the assistant occasionally fails to answer normally. Current investigation has not found a corresponding fault in the local program, but it remains unclear whether the cause lies in DeepSeek API scheduling, the model’s handling of temporal context, or another external factor. The root cause still needs further investigation.
Complex Compound Instructions
When a single message contains too many interrelated requirements, the assistant may also fail to answer normally; splitting the same task into several steps usually allows it to complete successfully. This issue has likewise not been precisely located, and further investigation is needed to determine whether it arises in the model, API scheduling, or a more complex combination of context and tool calls.
微信 AI 助手 is no longer a demo that exists only in test code. It is a personal AI Agent that can run beside the Windows WeChat client, receive questions, and complete real replies.