Backend systems and AI workflows,
grounded in real business processes.

AIGC Signal

GitHub source

A dashboard tracks AIGC repository events in a rolling 30-day window and publishes a Markdown brief.

• Python standard-library collection stores raw responses with SHA-256 hashes for offline reconstruction.
• Selections bind to event IDs and source hashes; changed evidence invalidates dependent interpretations.
• Failed or partial refreshes preserve the previous published period.
• GitHub Actions schedules refreshes. Pages Functions trigger manual updates with cooldown and concurrency checks; the workflow deploys to Cloudflare Pages.

AI-assisted development; authorship and review status are documented in AI_USAGE.md. Runtime collection does not call an LLM. Editorial interpretations remain labelled AI drafts.

Job-search automation

Resume tailoring involves several dependent operations: parse the job description, match evidence, rewrite the document, check it and produce a PDF. I separated these steps into observable nodes rather than treating the task as one long model prompt.

• Python REST APIs connect n8n with Claude and Codex CLI execution; MySQL records jobs, document versions, applications and feedback.
• The first version used Ollama, Qwen, MiniMax and LaTeX. Model choice depends on task, cost and availability; selected personal data stays on local models.
• Match quality and logical consistency are checked with failed cases and regression samples. The workflow reduced tailoring from approximately 30 minutes to one minute.

My role: system design and full-stack development. Personal workflow under continued iteration.

Resume-matching service

I extracted the matching step into a standalone REST service. The service combines an external LLM API with persistent records and cached responses.

• Spring Boot Web and Data JPA handle the service and persistence; RestClient connects the LLM API.
• Redis keys use a resume/job fingerprint to avoid repeated model calls for the same input.
• Retry and fallback handle timeouts and malformed model responses, with cache-first retrieval and database backup.
• JUnit tests cover core logic; docker-compose starts the application, MySQL and Redis together.

My role: solo backend development.

Anime Pilgrimage Planner

A travel-planning application turns scattered Japanese and English location information into daily itineraries and cost comparisons. The structured dataset covers seven cities, 44 anime titles and 65 locations.

• Four Flask APIs serve city and anime data, generate itineraries and provide a health check.
• Geographic clustering groups locations into days; groups larger than five locations are split.
• Budget simulation combines admission, transport, food and accommodation, including city rail-pass comparisons.
• Chart.js shows the cost breakdown; the frontend uses responsive Tailwind CSS.

Project status: implemented full-stack MVP. This page is a technical case study, not a hosted instance of the planning API.

Zhixingli knowledge workbench

A knowledge-workbench concept organises fragmented inputs into topic boards, AI outputs and authorised next actions. I wrote a 410-line specification and built a runnable single-file HTML prototype.

• Defined six input types, board organisation, output modes and an action layer.
• Designed explicit per-action permissions. Sensitive fields such as payment information are disabled by default.
• Specified how generated outputs return to the knowledge base for later reuse.

Project status: product specification and interactive prototype. External integrations and live AI generation are proposed capabilities, not production features.

Education pre-sales Agent

I built a pre-sales workbench to organise customer context, product evidence, demonstrations and talk-tracks. The knowledge model covers 867 entries across 12 scenarios, with customer types and stakeholder roles represented as structured fields.

• Structured and embedded product documents, demonstration material and talk-tracks; combined metadata filtering with vector retrieval.
• Wrapped demo lookup, talk-track queries and document search as function-calling tools; role-based prompt templates adapt the response to the stakeholder.
• Implemented the FastAPI backend and Docker deployment on a private cloud instance; tested service calls and supported Shenzhen University demonstrations.
• Connected proposal work to implementation: five stakeholder groups, 10 AI/cloud proposals and approximately 20 meeting records.

My role: requirements analysis, knowledge modelling, Agent development, deployment and customer demonstrations. Product recommendations remain subject to human review.

AI competition launch review

Before a university brain-computer-interface model competition, I reviewed a 146-file package and identified four P0 and four P1 issues. The review covered code, dataset handling and evaluation assumptions.

• Found exposed long-lived object-storage credentials in the code package.
• Identified a loader attempting to read an approximately 145.5 GiB object into memory.
• Found channel-name mapping failures in 12 of 21 datasets and seed settings inconsistent with competition rules.
• Checked 320,014 training rows and 7,049 validation rows; delivered findings and a support matrix to a 15-person partner group.

I also configured the cloud AI-platform workflow from ingestion through supervised fine-tuning and evaluation, coordinating university, data and product teams.

My role: read-only technical review and platform workflow support. Review findings do not imply that I authored the competition code or trained a new model architecture.

AI Coding competition platform

I supported the platform launch for a Shenzhen University AI Coding competition: three tracks, approximately 200 teams planned and an RMB 100K partnership.

• Prepared the event page, two-to-three-person team registration, test links and QR-code entry points.
• Checked page behaviour, links, QR codes and registration data flows before public launch.
• Prepared launch handover and coordinated the platform setup with the project stakeholders.

The team count is a planning figure, not a confirmed participation result. This case focuses on my platform-side delivery.