Build one tongue diagnosis software system
The tongue is the sprout of the heart, code is the hand of medicine
Recently, I've been debugging hardware integration, dealing with all sorts of bizarre issues that give me headaches. Stealing some time from the busy schedule, I did something I enjoy: spent a day building a self-service diagnostic system. Here's a record of the entire development process.
Original Motivation
I communicated with an experienced TCM (Traditional Chinese Medicine) tongue diagnosis practitioner about the possibility of moving tongue diagnosis online. Unlike other diagnostic methods that require pulse-taking or lab tests, tongue diagnosis can be done completely remotely without face-to-face consultation. Patients only need to provide photos of their tongue and describe their symptoms, then the physician can prescribe a treatment plan based on these two types of input.
Analyzing this process, tongue diagnosis can be fully digitized. The benefits are numerous:
- Solves the long appointment waiting times for medical care both domestically and internationally. When patients feel unwell, they can send their tongue photos and symptom descriptions anytime and receive diagnostic results quickly.
- Frees up physicians' energy and time, allowing them to practice flexibly based on patient input.
- Amplifies physicians' capabilities. Currently, they can only see 6-8 patients face-to-face per day, but with remote methods, they can diagnose many more people based on their available energy.
Of course, there are far more benefits than these, which I won't list exhaustively.
Building Process
Since remote diagnosis is feasible, in the current AI era, is it possible for patients to upload their symptoms and have backend AI replace the physician to provide instant results? The answer is yes, because I spent one day building such a system based on Claude Code. The overall architecture looks like this:
Patients mainly input tongue images and symptoms through the frontend, then the backend service integrated with Claude Code SDK calls Claude Code, which has learned the physician's professional knowledge base, completes the analysis, and provides results.
The professional knowledge base is managed in the claude.md file under the project, generally in an index-style format. Below is a sample:
Later, email and Feishu can be integrated for users and physicians to input remotely, allowing Claude Code to execute different operations accordingly.
Best Practice
After completing this, my child happened to have a cough. I originally planned to go to the hospital, which would definitely involve blood tests, ultrasounds, and everything else, then come back with a pile of medicine. But this time, I used this system to directly output diagnostic results:
I input my child's tongue photo and symptoms, and got diagnostic results within minutes:
Then I had a physician friend review this prescription. She said it could score 85 points and could beat over 90% of TCM practitioners. She made slight modifications to the prescription, and we went to a nearby hospital to get the medicine.
The entire diagnostic process was complete.
This is a very successful case of offline-to-online transformation. I plan to refine this system for use by relatives and friends. For upgrades, I mainly need to update the knowledge base content and selectively update the claude.md file.
Next Step - 24-Hour Employee
I previously heard in an interview program that one guest said a single email could make Claude work continuously through the night. At that time, I wanted to build such a system. Similar to the tongue diagnosis system above, I only need to keep the email integration path. Currently, I've got the Gmail workflow running.
The construction of this system signals the completion of the foundational capabilities for a one-person company, where the time-folding work effect is starting to take hold.
Next, I need to upgrade Claude's membership to Max. The current Pro membership's token quota simply cannot support a person full of creative ideas.
Recently, I've been debugging hardware in a large factory building. Apart from large equipment, there are only 2 people—a workplace with low population density, which is quite rare.
