Sibo's Blog

Agents, Skills, and Models: Reflections from Alibaba AI Night School

Tue, 18 Aug 2026 15:29:47 GMT

1. Preface

I recently attended AI Night School training organized by Taotian’s business technology organization. As I have been working on Agent-related development lately, I enrolled in the two-month course. Last Thursday’s first overview session was excellent, and I want to combine my recent experience building Agent applications with some thoughts on Agents, Skills, and models.

This article has been declassified and contains no commercial secrets. It is highly personal in its thinking. Some sections assume readers understand the basic concepts of LLMs and Agents; without that experience, they may be a little demanding to read.

2. Can Agents replace everything?

From Agents emerging in 2024, to their concentrated explosion in 2025, to xxClaw triggering “everyone raising shrimp” in 2026, LLM-powered AI appears able to do anything. Quite a few AI bloggers even make the bold claim: “In the future there will be no software, only AI.”

Reality is not that tidy. Many people have never used office Agents such as WorkBuddy, Manus, or QwenWork, and their understanding of AI remains at the level of chatting with Doubao. Even if monthly active users of office Agents truly grow from millions to hundreds of millions, can AI replace all SaaS software?

From a software-engineering perspective, I think that conclusion is overly optimistic.

An LLM can be roughly understood as an enormous “idiom-chain game” system. Even top algorithm researchers currently struggle to clearly attribute every output. When calling an LLM, even with temperature set to 0, multiple responses may not be entirely identical. Difficulty of attribution and uncertain output are unavoidable characteristics of models. Model capability alone has difficulty directly taking on highly sensitive, high-risk business operations.

The real change LLMs bring is the ability to handle unstructured data. After training on massive data and parameters, they seemingly understand almost every kind of natural-language expression and give reasonable feedback. This happens to be what traditional structured programs are not good at. Workflows that once required users to repeatedly operate across multiple interfaces can be turned into more natural conversational interaction through an LLM, but that does not mean existing software will be completely replaced.

In production applications, AI and programs are more like complementary roles. Models understand fuzzy intent and handle unstructured information; programs perform deterministic and structured operations. A simple example is that production environments commonly equip LLMs with a calculator tool to calculate directly. Models can calculate too, but calculator results are more stable, cheaper, and easier to verify.

Cost is also very real. Context and Tokens are not cheap. Assigning a deterministic task to a normal program may consume little CPU and memory; giving every step to an LLM significantly increases resource cost and response time.

Of course, one can think more aggressively: if deterministic programs themselves are written by AI and then called directly by AI after being written, does that mean AI can ultimately take over the whole digital world? In one sense, it can be understood this way, but the process will be very long. Complex software architecture and continually emerging incremental requirements remain difficult to automate completely.

3. What is the essence of an Agent?

While browsing the Jike community previously, I saw many bloggers with “xx_AI” in their names evaluating new models such as DeepSeek, MiniMax, and GLM. Some even judged whether a base model was capable by “how many Subagents it starts” or “whether it can generate attractive videos.” The latter at least corresponds to multimodal capability; the former is strange: starting multiple Subagents is an engineering implementation, not a base-model capability.

So what is an Agent? Where is the difference between an Agent and a Model?

For models, refer to my introductory LLM article from last year. Put simply, the core of a model still resembles an “idiom-chain game”: based on enormous parameters, it uses vector and matrix operations, takes Prompt Tokens as input, and progressively generates output. Multimodal models work similarly, except their inputs and outputs become specially encoded image, audio, or video Tokens.

Anyone who has read the source code of open-source Agent tools such as Codex and OpenCode will find that an Agent is essentially an engineering wrapper around calls to a model API. It assembles user input, descriptions of tools and Skills, system information, and other content into context and sends it to the model API; the model then returns Thinking Delta, Text Delta, and the tool name and input parameters to execute, token by token.

An Agent’s value lies in uniformly managing the runtime for LLM API calls and providing invocation patterns such as ReAct and Handoff externally. Developers mainly focus on an Agent’s Prompt, Tool Config, and Skill, without repeatedly adapting to protocols and parameters of downstream model interfaces.

One layer outward, the boundaries of today’s large Agent platforms have gone beyond a single Agent and are closer to a Harness suite. Beyond model invocation and context assembly, they handle memory extraction and storage, state restoration, tool execution, and even self-iterative optimization. These are all parts of Harness engineering.

Developers need not obey the Agent abstraction in every scenario, however. Sometimes we only want to customize one model-interface parameter; having to create a whole Agent Prompt, Tool, and Skill is somewhat like using a cannon to kill a mosquito. Abstraction should resolve complexity, not create it in reverse.

Many base models emphasize their Agentic capabilities. An important reason is that during training they encountered massive amounts of data in formats such as Function Call, Thinking Delta, JSON Schema, and System Prompt. Thus, once in an Agent environment, they more easily generate tool-call information that meets conventions. Such models are usually called Agentic Models. Tool-orchestration approaches, the number of Subagents, and runtime recovery capabilities still belong to engineering systems outside the model.

4. Thoughts on Skills

At the beginning of this year, after Anthropic proposed and popularized the concept of Skills, many friends—especially those who do not develop software—felt that everything could be solved by writing a Skill.

When talking with product colleagues, I often hear: “Quickly abstract this into a Skill, then I will not need to ask you again.” There is a correct part to that statement, but also an obvious boundary. Skills can indeed accumulate experience, but many problems will not resolve themselves simply because a Skill has been written.

Anyone familiar with Agent development knows that a Skill is essentially a working SOP. To prevent model context from becoming overloaded, Skill content is usually loaded progressively. A Skill can therefore be viewed as a larger, more structured Prompt. In essence it is no different from instructions typed into a Doubao input box; the principal difference is that its full text is not inserted into context at the beginning. Instead, it is progressively loaded based on the task, saving context and reducing interference with reasoning.

Since a Skill describes an SOP, can everything be made into a Skill? Theoretically yes; in practice, there is no need.

We should not repackage every existing SOP and Workflow as a Skill just for AI. On the one hand, programmatic Workflows cost little to execute and are more stable. On the other, the same Skill in different Agents is affected by context style, base-model capability, and recovery mechanisms, making results hard to make as precise as program flows. Skill text is deterministic, but execution results still carry model uncertainty. The market also currently lacks sufficiently mature, unified tools to evaluate and optimize Skills. The road to precisely using Skills at scale is still long.

Another easily missed issue is that an Agent can read a Skill in full. Opening a Skill is, to some extent, exposing all accumulated experience within it. This risk cannot be ignored when sensitive experience or internal knowledge is involved.

Therefore, for most deterministic tasks, replacing programs with Skills is often merely “AI for AI’s sake.” For example, uploading an image to GitHub can call the GitHub interface directly through a script, or use a Skill to have a model operate a page through Browser Use. Clearly, the script is faster, more stable, and more trouble-free.

Skills are better suited to business processes that cannot be fully programmed but whose operational experience can be summarized. They can combine MCP and tools for overall orchestration. For example, in a handover scenario, a colleague about to leave can organize an operating manual as a Skill, and the incoming colleague can then use AI to complete tasks that previously required repeated questions. The value here is making tacit experience executable; deterministic steps still go to programs.

There is another, more technical question: what exactly is the difference between Subagents and Skills? For nontechnical colleagues who directly use Agent tools such as WorkBuddy, this may sound odd—Subagent is an Agent, Skill is an Agent’s SOP, so why compare them?

From an engineering implementation perspective, Agents and Skills both ultimately become sets of context passed to the model interface. Thus actual development often faces the same choice: should a task be placed as a Skill in the primary Agent, or assigned separately to a Subagent?

My judgment is that Subagents suit tasks that can be completed independently, need independent context, or can run in parallel. A primary Agent plus Skill suits general flows requiring continuous shared context. When using Subagents, pay special attention to how intermediate artifacts are handed off; otherwise the benefits of isolated context may become information loss.

5. Common business scenarios for Agents

The discussion so far shows that Agents can hardly replace software for all work; having Agents also does not mean business revenue and profit will grow naturally.

Agents are first and foremost efficiency tools. They can help programmers with end-to-end development from requirement understanding to code implementation, and help nontechnical colleagues investigate tickets, process Excel, and write weekly reports. More importantly, many of these tasks can run in parallel. Work that is highly standardized but complex to process can go to Agents, leaving people’s energy for the parts requiring judgment and creativity.

Because they can handle large amounts of unstructured data, Agents are also naturally suitable for customer service, sales, and QA. New-hire landing and work handovers are common scenarios as well. I saw at WAIC that financial systems are nearly all experimenting with Agent-based Q&A customer service. These practices still sound early-stage, but the direction is straightforward: first connect scattered knowledge and operational processes, then progressively raise task-completion rates.

Learning is also very suitable for Agents. An Agent does not lose patience due to repeated questions, can adjust explanations to learners’ understanding levels, and has broad enough knowledge coverage. Knowledge accuracy and teaching pace still need evaluation, however, especially in specialized domains where fluent answers cannot simply be assumed correct.

Moving further toward algorithms, LLM reasoning can be used to understand user needs more finely, supplementing information traditional structured features struggle to express. This can form more detailed user profiles and then serve search and recommendation scenarios.

At present, the more certain value of most Agent scenarios is still efficiency improvement. Teams hoping AI will directly relieve all business pressure may need first to re-examine their business model: does the problem come from repetitive work, information processing, or the product itself? Placing every expectation on AI makes it easy to miss the problem that should actually be solved.

6. Agent-development choices and considerations

For technical colleagues, many specific business needs cannot be completed directly through general desktop Agents such as WorkBuddy and QwenWork. It is often still necessary to call model-vendor interfaces and manage context independently. In this situation, several matters need to be thought through first.

First is whether the Agent runs locally for the user or in the cloud. With local operation, message disconnection and service recovery are relatively simple. If it runs in the cloud, exceptions such as message disconnection, server restarts, system outages, context storage, and scenario memory must be handled. The cloud also has obvious advantages: it can centrally collect user data and run business 24×7. Many vendors have recognized this; Alibaba’s earlier MuleRun and Qoder Agent Cloud are products that package Agents in the cloud for users to call through APIs.

Second is the choice between ReAct and Workflow. Nearly all current general Agents show traces of ReAct, and implementations such as Codex (OpenAI also open-sourced a framework with the same name), DeepSeek Harness, and AgentScope have appeared. ReAct lets a model autonomously call tools through “thought—action—observation,” making it suitable for open problems. But ReAct alone is often insufficient, and developers still need to provide more deterministic Workflows.

The advantage of Workflow is high determinism, more controllable cost, and faster execution. A common approach is to have ReAct first generate a Dynamic Workflow, letting AI decide the flow, then handing execution to a program. The common Plan pattern can also be seen as a variant of this form. During actual selection, clearly separate “what the model decides” from “what the program guarantees.”

When truly writing an Agent, context management, memory, and caching are also important. How should user and system messages be positioned and inserted? When should user memories be extracted? Where are memories stored and how are they retrieved? How should context be assembled to make better use of Model Cache? How should tool inputs and outputs be compressed? How should every session be managed? These questions are difficult to solve completely with one unified framework, and usually must be designed one by one with the product form in mind. I only list the questions here; I may expand on particular solutions later.

Finally, do not become constrained by Chat when developing Agent applications. Using a chat box does not mean a product is more intelligent. Agents truly excel at handling unstructured information and understanding fuzzy intent; interaction should still begin from the product perspective: when a button clearly solves something, why force the user to type a paragraph?

7. How to evaluate Agents

In traditional software engineering, development and testing are both important stages; Agent development likewise cannot do without evaluation. Verifying that an Agent can complete basic functions is only the first step. The harder questions are whether it is actually useful in unstructured scenarios, can be used stably, is worth using, how Bad Cases can be found, and how problems can be quickly located and optimized after they appear.

I think Agent evaluation must solve at least three problems:

Basic functions: ensure the Agent’s product functions meet business requirements.
Stability: cover different inputs, different times, and every kind of Bad Case, checking whether output consistently meets expectations. LLM output is probabilistic, so evaluation cannot rely only on one manual experience; Agent evaluation needs to be as automated as possible.
Optimization suggestions: beyond showing whether an Agent meets expectations, evaluation results should locate places to optimize in the execution chain, such as Prompt, Cache hit rate, Skill, or tool description. It is best to evaluate the cost of each execution too, to determine whether real ROI meets business expectations.

To accomplish this, an evaluation system also needs several foundational capabilities:

First, collect runtime metrics such as cache hit rate, TTFT, token cost, and time cost. Without them, it is difficult to judge whether an optimization improved results or merely increased cost.

Second, design evaluation criteria around business expectations. Agent output is difficult to measure with a single universal score; evaluation items must answer whether it completed a specific business goal.

Third, identify and locate Bad Cases. After finding results that fail to meet expectations, continue determining whether the problem lies in Prompt, Skill, tool, context assembly, or the model itself.

Fourth, retain historical evaluation results so every change can be traced and associated with previous versions. Otherwise, after adjusting a Prompt or Skill, it is easy to fix the current Case while bringing old problems back.

For now, this section is more a summary of problems and directions. This article does not yet expand on concrete evaluation implementation. Once later practice is more complete, I will write a separate article.

Building a Codex Plugin for Multichannel Publishing from Yuque

Sun, 02 Aug 2026 09:28:50 GMT

I usually finish writing an article in Yuque first.

But after the final sentence, the work is not over: a blog, WeChat Official Account, and RedNote each have their own content format. I still need to reformat, illustrate, split, and check it, which takes roughly another two hours.

Recently, I made this workflow into a Codex Plugin. It reads the Yuque original, lets AI polish it, create images, and adapt it for platforms, then uses scripts for uploading, validation, persistence, resume support, and pre-publication checks. This article is its first complete test. I want to record how it was made and clarify what can truly be automated and what still needs a person to confirm on each platform page.

1. Why make content distribution a plugin?

I have always kept a blog, and usually put everyday writing in Yuque first. Once an article is finished, I publish it on my website, then prepare WeChat Official Account and RedNote versions. All three backends appear to accept pasted Markdown, but in practice each brings a pile of work.

A blog needs complete structure, code blocks, and Hexo front matter. A WeChat article cares more about mobile reading and needs a separate 2.35:1 cover. RedNote needs the long article reorganized into a short note and a set of vertical cards. Images cannot simply be reused either: a lead image, section image, WeChat cover, and RedNote card each have different jobs.

At first I gradually wrote several Skills under .agents/skills/ in the repository: fetching Yuque, migrating images, uploading them to image hosting, and polishing Markdown. Each worked alone, but managing them together became increasingly difficult.

For example, the Yuque Skill knew only how to download an article locally, not where it should ultimately go. The polishing Skill could learn a voice, but did not know how much blog content WeChat should retain. The image-upload Skill certainly could not tell whether an image truly explained a section. Each run forced AI to reassemble those capabilities, and directories, parameters, and context were easily omitted. Copying the repository to someone else could also leave out an .agents/skills dependency.

The chain is long too. Yuque reading, polishing, image generation, upload, three-platform adaptation, and publishing can all be interrupted by a network or page problem. If progress exists only in the current session, the next run must reconstruct everything.

These issues convinced me that the whole workflow needed one Plugin. It should carry its own instructions, scripts, references, tests, and artifact contract, while keeping personal credentials and task progress in the workspace. Copying the plugin then does not copy tokens, and resuming a task does not require guessing where it stopped.

2. How I built the plugin

The plugin and this article were built entirely with Codex. Here is the general approach.

2.1. First define the boundary between AI and scripts

Voice judgment, content additions, image concepts, and platform adaptation need context, so I gave them to AI. AI also performs the final review, checking factual boundaries, heading numbering, image semantics, and platform differences.

Downloading files, uploading images, checking image ratios, comparing WeChat and blog bodies, creating directories, and recording state all have definite results, so scripts handle them. Scripts judge only whether files exist, ratios are correct, and fields are complete; they never secretly rewrite an author’s body text.

This boundary became the plugin’s core: AI can create, but must leave inspectable artifacts; scripts remain stable without reducing creative work to string replacement.

2.2. Bring scattered Skills into one Plugin

The old Yuque fetcher, image uploader, and voice cache became internal plugin components. Only one main Skill remains public, describing the full workflow and quality requirements. AI no longer finds multiple Skills temporarily or depends on the target repository’s .agents/ directory.

Yuque reading prefers an already logged-in browser session. This handles private documents, non-member pages, and API-policy changes. When Markdown can be copied from the page, formatting is retained directly; when it cannot, visible structure restores headings, lists, quotations, code, and images. Original images are reuploaded to the user’s own image host.

2.3. Build an author-voice baseline from 86 earlier articles

I did not want each polish to reread historical articles, so AI first read the blog’s 86 existing posts and compiled author-voice.md. This personal profile lives in .codex/yuque-multichannel-publisher/style-profiles/ in the workspace and is not packaged into the Plugin.

After others install the plugin, their first run follows the same learning process, reading only historical posts in their own workspace. If no usable samples exist, the plugin explicitly uses a restrained general voice until enough articles exist to build a personal profile. The process creates only a voice reference, never keys. Image-host tokens must be supplied by environment variables or workspace configuration; WeChat and RedNote use the user’s existing logged-in sessions.

The reference records a first-person engineer viewpoint, common openings, sentence and paragraph rhythm, technical reasoning patterns, ending habits, and expressions to avoid. Later polish reads only this compact baseline. If old posts change, update the corpus fingerprint; if a category genuinely differs, add a small category profile.

Voice protection has two passes. First preserve facts, adding only background, causality, examples, and boundaries needed to understand the article. Only then reorganize sentences and paragraphs according to the voice profile, retaining my first-person judgments, technical reasoning, hesitation, and natural transitions. This avoids inventing experiences merely to “sound like me.”

Then perform a de-AI review, targeting template openings, empty buzzwords, neat parallelism, universal summaries, and frequent negative-contrast phrasing. The project records the voice-profile path, corpus fingerprint, checks, and review notes. Scripts verify that evidence exists and scan high-risk language; AI still makes the final language judgment.

2.4. Give images content before style

The first section images had correct proportions and looked technological, but said little about their sections. I therefore split generation into three steps: write a visual brief, generate the image, and review it.

The brief states the section’s core claim, required objects and relationships, appropriate information type, and elements to avoid. Processes and architecture prefer editorial infographics; real screenshots come first when material exists; personal experiences fit narrative illustration. Afterwards, inspect text, relationships, and thumbnail readability, redrawing if content does not match.

The body lead image retains a warm hand-drawn animation feel. Generate the WeChat cover separately at exactly 2.35:1 with a short title in the safe area. For RedNote, organize a card narrative first—each card advances one information point—then make 3:4 images.

2.5. Use checkpoints for long tasks

Every content project stores state.json and event records under content-projects/<slug>/.codex/. They contain the current stage, completed artifacts, hashes, and final target directory.

The plugin divides work into initialization, fetching, polishing, image creation, review, and persistence. After interruption, resume directly shows where it stopped. Only after the reviewed checkpoint is recorded may materialize write drafts into formal directories.

Finally, I added contract tests to the pipeline. They check heading numbering, image ratios and briefs, author-voice fingerprints, WeChat/blog body similarity, RedNote card counts, cross-round references, final directories, and whether platforms were mistakenly recorded with the same publishing status. After this test article ran, draft validation, materialization validation, and the Hexo build all passed.

3. Plugin structure, artifacts, and benefits

The plugin has one public Skill and roughly this directory structure:

yuque-multichannel-publisher/
├── .codex-plugin/
│   └── plugin.json
├── README.md
└── skills/
    └── yuque-multichannel-publisher/
        ├── SKILL.md
        ├── assets/
        │   └── config.example.json
        ├── references/
        │   ├── voice-profile.md
        │   ├── editorial-guide.md
        │   ├── visual-direction.md
        │   ├── artifact-contract.md
        │   ├── style-profile-cache.md
        │   └── publishing.md
        ├── scripts/
        │   ├── pipeline.py
        │   ├── workspace.py
        │   ├── yuque_fetcher.py
        │   ├── image_uploader.py
        │   └── style_profiles.py
        └── tests/
            └── test_pipeline.py

plugin.json defines plugin identity, version, and Codex display information. SKILL.md tells AI how to complete the workflow. references/ holds general standards for voice learning, editing, images, artifacts, and publishing. scripts/ performs deterministic work, and tests/ prevents directory and validation rules from silently breaking after updates.

Personal data lives separately in the workspace:

<workspace>/.codex/yuque-multichannel-publisher/
├── config.json
├── browser-data/
└── style-profiles/
    ├── author-voice.md
    ├── profile-index.json
    └── style-*.json

At runtime, personal voice, login state, image-host tokens, category cache, and task state are not written to the plugin directory. They live in .codex/yuque-multichannel-publisher/ in the workspace or in a concrete content project. The plugin only checks whether credentials are configured; it does not generate keys or read browser passwords. The plugin can be updated or copied without overwriting personal configuration.

3.1. How the three platforms are persisted

The blog retains full argument, code, citations, and table-of-contents structure, finally writing to:

source/_posts/<slug>.md

WeChat uses the same body as the blog with only light paragraph adaptation, generating both Markdown and HTML with inline styles:

wechat/<slug>/article.md
wechat/<slug>/article.html

RedNote first determines how many independent notes the original supports. Every round must reintroduce its subject and core claim, then generate its body and card plan:

rednote/<slug>/series-plan.json
rednote/<slug>/round1/post.md
rednote/<slug>/round1/cards.json

This article ultimately creates only one round. Its motivation, production process, plugin structure, and benefits are one topic; splitting it into three rounds would leave the latter two without necessary context.

3.2. How RedNote decides the number of rounds

RedNote splitting considers themes first, then sections. AI extracts the article’s subject, target reader, core judgment, actionable information, and real material, then judges whether each candidate theme remains complete when separated.

A round must answer three questions: what it discusses, why it is worth reading, and what readers can do. It also needs its own context, benefit, and visual material. A mere step in the long article, or content requiring “the previous round” to understand, remains in the same note.

After deciding the count, each round writes its context in series-plan.json before writing cards.json. The first card states the topic and target reader; each middle card advances one point; the last closes the conclusion or asks a concrete question. Images prioritize real screenshots and materials, then redraws, text-and-image cards, and AI scenes. Finally, read each round’s body and cards separately as a “stranger-reader test.”

This article includes motivation, process, plugin structure, and benefits, but all answer “How was this plugin made?” Separating them would remove the structure and benefits from their product context, so one round remains.

3.3. Inspect first, then decide how to deliver drafts

Following md2wechat and XiaohongshuSkills, I separated “generate publication packages” from “operate external platforms.” The pipeline first produces a machine-readable readiness report:

python3 pipeline.py inspect --project <slug> --probe

It lists body character count, heading count, remote images, summary length, AI-cliché risk, missing artifacts on all three channels, and adapter status. Subsequent actions trust only blockers in this report rather than guessing publishability from “the file was generated.”

WeChat can connect to a separately installed md2wechat. The plugin calls inspect to check account configuration, cover, and target status, then writes the draft. AppID, Secret, and API Key remain in the external tool’s own configuration; the plugin saves only an executable path and account alias.

python3 pipeline.py send-draft \
  --project <slug> \
  --channel wechat \
  --confirm

RedNote is handled more conservatively. The reference project operates its creator backend through Chrome DevTools Protocol and can upload images and fill title and body, but automation is affected by page changes, login checks, and account risk control. The plugin therefore always calls its --preview mode: it fills only the editor, never clicks Publish, and never records “the page was filled” as “the platform draft was saved.”

python3 pipeline.py send-draft \
  --project <slug> \
  --channel rednote \
  --round round1 \
  --confirm

Only after RedNote explicitly reports a successful save does it record draft_saved. WeChat, RedNote, and every RedNote round each have their own status; filled_for_review, draft_saved, and published are also completely separate. Thus, a failed round does not roll back content stages already finished on other platforms.

Neither external project is packaged directly into the plugin. md2wechat‘s license has extra requirements for commercial use and redistribution, while XiaohongshuSkills browser selectors must follow platform updates. Keeping an adapter layer means the plugin maintains only content contracts, capability probing, and state records; external tools can be installed and upgraded independently.

3.4. What I think is most valuable now

First, the plugin is self-contained: copying the directory carries the main Skill, internal scripts, references, and tests, without reassembling multiple repository Skills.

Second, AI’s creative ability and scripts’ stability have clear places. AI still creates articles, images, and channel adaptations, while scripts check directories, ratios, state, and similarity. When a problem appears, it is easier to know whether to change the prompt, reference, or code.

Third, long tasks are resumable. If image generation or browser automation stops, originals, drafts, images, and checkpoints remain locally and the next session can continue from the valid stage.

Fourth, the three channels share facts and a long-form draft but have independent artifact forms. WeChat does not become a summary, and RedNote is not mechanically split by first-level headings.

Fifth, quality requirements leave evidence. The project files show which voice reference was used, what a section image should express, whether the WeChat-cover title was checked, and why RedNote has its current number of rounds.

It still has boundaries. A WeChat draft box can be written through an external adapter, but credentials, IP allowlists, and account permissions still require user configuration. RedNote automation can reliably fill the editor, but whether a draft was actually saved must be confirmed from platform feedback. The blog repository also has its own Git rules. Before real publication, account, title, time, and visibility still need confirmation.

Plugin source and instructions are in wxxlamp/ai-coding-config, under plugins/yuque-multichannel-publisher/.

For me, the plugin has put the most tiresome transport work into a repeatable flow. After writing an article, I can keep my attention on the content, wait for local publication-package checks to pass, and then decide when to open each platform.

Designing an AI Operations Platform with AgentScope

Sun, 19 Jul 2026 15:58:00 GMT

When many people begin agent development, their first instinct is to make the agent loop run: the model calls a tool, gets a result, and enters the next round. But once you make an operations-oriented AI platform genuinely usable, you find that the loop is only the starting point. Based on AgentScope, this article discusses the things we encountered and considered while building an AI operations platform beyond the loop: how prompts and skills divide work, how to guide long flows, and how to ensure parameter correctness across multiple downstream APIs. (Internal platform URLs, system names, and concrete business data have been removed; only reusable engineering practices remain.)

I. Core problems and solutions

Three core problems are unavoidable in this type of operations agent; the approaches we ultimately adopted are listed alongside them.

Core problems

How can strategy defined by algorithms be effectively recognized by the model?
- Split agents by domains such as audience selection, outreach, and benefits; each domain agent maintains its own context and skill.
- Use AgentScope to implement the agent loop and basic skill and MCP management.
How can long operational flows be guided correctly without taking arbitrary actions?
- workflow + frontend flow rendering
- ask user question cards
How can multiple downstream systems be connected while ensuring parameter correctness?
- Connect marketing-delivery platforms, outreach platforms, data warehouses, low-code platforms, collaboration documents, and other tools and MCPs.
- For tools such as coupon delivery and outreach, extract and parse core parameters from context rather than letting the model fill them in itself.

Architecture and solution

The following is a sanitized overview of the architecture; you can compare it with each module discussed below:

II. Prompts, skills, and conversations

Thinking about the division of work between prompts and skills

When you are starting out, you will probably do as we did: keep the main agent’s prompt simple and put routing and workflow management in skills. Soon, however, you discover that the model sometimes does not load the relevant skill at all. It instead improvises from the system prompt, weakening the result. Two recommendations follow:

Skills are disclosed and loaded progressively. If data is important and used in every round, put it directly in the system prompt. Do not put it in skills merely to save tokens, or the effect will suffer badly.
Although system prompts are often recommended to stay within roughly 500 lines, do not be constrained by that at the start. Write a broad, comprehensive system prompt first; once results stabilize, optimize its length through references.

Dynamic prompts prevent Lost in the Middle

For Transformer-based LLMs, attention tends to spread toward both ends and information in the middle may be “forgotten.” Compression can also remove tool results from an agent. Remember one principle: do not leave truly important information for the model to manage by itself; intervene manually.

Using AgentScope middleware, at the beginning of every turn we abstract important information from memory and forcibly append it to the system prompt with <Context-Reminder></Context-Reminder> tags. This ensures the model gives critical information “absolute attention.”

Context-Reminder normally includes:

Basic campaign information (campaign name, user ID, and so on), campaign stage and flow control, audience information, IDs from external APIs, and so on

How to optimize prompts

Our prompt-optimization rhythm has three steps:

step1: Write the initial prompt according to the agent’s role and function.
step2: Keep adding prompt content and get the effect working first.
step3: Once the effect meets expectations, store parts of the prompt in references and load them progressively.

Two cautions:

Prompts do not need to concern themselves with tool input parameters.
Do not compress prompts blindly just because of context length.

Context compression

Overlong context both slows model reasoning and affects reasoning quality. AgentScope’s default compression strategies currently include compressing thinking, tools, and model replies. You can understand their progression this way:

With AgentScope, the model’s thinking process and tool-call results are compressed by default, retaining only the user’s and model’s Q&A in each round.
A more advanced compression strategy retains some tool results while removing invalid conversations.

III. State machines and the Plan tool

An operations campaign is often complex and long-running: it must answer user questions flexibly while guiding the user through the process. We therefore dynamically inject a state machine into the system prompt, which guides the user at the highest priority. One key detail: do not write state-machine rules into the prompt. Instead, use hard code to determine the model’s current step and what it must do next. Its overall form is:

{
  "currentStage": "阶段标识",
  "currentStep": "当前步骤标识",
  "nextStep": "下一步骤标识",
  "actionType": "independentThinking | callSkill | callAgent"
}

Along with the current step, explicitly tell the model whether completing it requires independent thinking, calling a skill, or calling an agent.

To let steps advance dynamically, we customized a plan tool. The model calls it after completing each step to update progress. The system detects memory-data changes and, in the next loop, feeds the latest step back to the model through middleware.

Because these steps are persisted in a database, operators can see the workflow progress directly in the frontend, greatly improving the experience.

IV. Parent and child agents

When should you use a child agent?

First dispel a misconception: an agent is essentially a contextual wrapper around a model API, and the model cannot actually recognize a “child agent” (to it, that agent is merely a tool). Compared with a skill, however, a child agent has an independent context and can execute concurrently. Decide whether to split out a child agent using these three criteria:

Is the subtask independent?
Can the subtask execute in parallel?
Does the subtask require too many iterations?

Division of work also brings an easily overlooked organizational benefit. When several algorithm engineers participate, splitting child agents by domain lets everyone own the quality of their own agent. Clear domain boundaries make integration smoother and provide better assurance for the whole project.

Communication and collaboration between parent and child agents

Three practical lessons:

Dynamically inject the “child agent currently to be called” into the parent agent’s system prompt. This prevents the parent agent from taking over before the child task is finished and significantly improves the parent’s recognition accuracy.
Require child agents to return JSON and add an isCompleted=true field to indicate completion. (Some models can enable structured JSON output by parameter.)
After a child agent finishes, persist its returned result through middleware. Because the JSON format is fixed, the data can directly become inputs to subsequent tools.

Optimizing excessive reasoning time

During initial tests, agents can take too long to reason. Do not simply disable thinking: that severely harms results. With LLMs, we took several measures to reduce reasoning time:

Context compression: remove child-agent skill preloading and lower the main agent’s thinking-token limit.
Thinking budget: some LLMs expose a thinking-budget parameter to control thinking duration.
Adjust top-p and temperature.

We are continuing to explore several directions:

Parallel agent invocation.
Asynchronous agent invocation, with the main agent returning results to the business early.
Splitting agent responsibilities more finely and matching different models and parameters to different responsibilities.

V. Tools and MCP

How to ensure API-parameter correctness

When integrating APIs such as marketing-delivery and outreach platforms, the greatest concern is that the model will not understand parameter meanings and therefore pass incorrect parameters, such as channel ID, validity period, or start time.

Experience confirmed this concern. In early integration testing, the model regularly passed wrong fields; audience SQL was a typical case. Even if field definitions are clear, when many audience-selection SQL statements exist in context, the model may randomly choose the wrong one—for example, pass a production table instead of an offline table, or use a benefits SQL statement for outreach SQL.

We adopted three measures:

Add a “parameter definition” API on the delivery-platform side to strictly constrain input enumerations and make definitions as rich as possible.
On the operations-platform side, wrap the delivery platform’s MCP as tools, then use middleware to hard-code extraction of key parameters—audience SQL, start time, validity period, campaign type, and so on. Code passes these parameters directly; the model does not need to infer them.
Add monitoring: persist both the “model-inferred parameters” and the parameters ultimately passed to the delivery platform, making later audits and tracing possible.

Pitfalls in concurrent tool calls

Calling tools concurrently can reduce model loop count and improve results, but be careful: concurrent modifications to database fields may overwrite data and break consistency. Evaluate this before designing a concurrency plan.

VI. Integration and validation

After changing a prompt or skill, validating the corresponding feature is often time-consuming, and it is difficult to know whether the change affected other areas.

Our solution is a custom script. It uses a coding agent to call the platform’s chat API, converse with the platform through a model, and intelligently judge whether the platform’s reply meets expectations under agreed constraints. The validation uses these artifacts:

An e2e script that converses with the platform through a coding agent.
Output from platform conversations.
Platform runtime logs.
The platform model’s context (only the final two arrays).

Feed those artifacts to the coding agent and ask it to analyze whether platform behavior meets the standard in light of the feature optimized this time.

Frankly, this approach is still early. We have automated the conversations, but because agents in different roles are all specialized, algorithm engineers still need to combine the logs for final analysis after the conversation ends.

VII. User-experience measures

KeepAlive mechanism

When a user does not provide input for a long time, an SSE stream can easily disconnect. We added a server-side keepalive mechanism to prevent conversation interruption. If your product also uses SSE for streaming output, this is almost essential.

Resume-and-retry mechanism

Network jitter, such as backend-service deployment, can break chat. We therefore added resume-and-retry support in the frontend: it automatically retries a chat session three times, minimizing user awareness.

Ask User Question cards

Using AgentScope, we optimized ask user question cards. After the model calls this tool, users can choose options directly, fill blanks, and complete dates, yielding a smoother interaction.

VIII. Future development and plans

Finally, here are several directions we are advancing; discussion is welcome:

An auto copilot for multiple products and campaigns.
An automatic correction mechanism for different campaign types derived from user sessions: use scheduled tasks to scan user conversations, capture what users question, and automatically optimize skills and prompts.
Invoke different agents concurrently to improve system response speed.

Reflections on Writing 10,000 Lines of Code with Qoder

Sun, 07 Jun 2026 08:00:00 GMT

Introduction

I previously used Claude Code, but recently could not use the Opus-series models for various reasons. With company promotion as well, I began using Qoder as its substitute.

In April I developed nearly 10,000 lines of effective business code. Human intervention during development was below 10%, although integration and test-submission required more human work because of infrastructure.

Through two key projects, this article discusses how much coding agents can improve R&D efficiency and what remains worth caring about in an era of organization-wide AI coding. The practical material is long; readers in a hurry can jump directly to the reflections.

I briefly record practices and thoughts from the coding stage. These lessons are not limited to Qoder; I hope to extract reusable strategies for other coding agents.

Practice

[Practice 1] Using Qoder to integrate a gateway payment flow with an external channel

Under an existing mature architecture, this practice used the channel’s mature API documentation to integrate five payment APIs and two webhooks.

Development preparation

The PRD was not AI-native—it was not written in a structured form AI can understand. Feeding it directly to AI would produce a mess even with complete skills, MCPs, and rules. Before development, I therefore did the following:

Clarified channel APIs: understood call flows and timing, and special cases such as retries and idempotency; prepared complete API documentation for Qoder.
Clarified the business solution: after PRD review, many points remained undecided or conflicted with existing business, so people had to align the overall requirements with PD and the business team.
Clarified the technical solution: AI can write a design, but Qoder did not know the infrastructure’s design preferences and priorities for channel integration. Letting it design directly from the PRD and documentation would cause much correction and rework. It was cheaper for developers to write the technical document’s skeleton and cautions, then let Qoder complete it.
Reviewed existing code: channel integration is a mature gateway capability. Besides the design, PRD, and APIs, Qoder needed existing channel-integration code, including task-scheduling and API-rendering strategies. Do not expect it to understand code by grepping without context; that inevitably misses things.

AI Coding stage

Before coding, I created a new-channel integration skill from prior experience. Combining it with SPEC completed design clarification, implementation, testing, and compilation.

Qoder fetched Yuque links, channel API documents, and related repository code from the technical document. Because the design was clear, its reasoning and output were highly accurate. It then asked about ambiguous points:

After clarification, Qoder generated a detailed SPEC. I spent about an hour reviewing it, correcting incorrect design, and asking Qoder to optimize it again:

Once the SPEC was clear, Qoder could plan, implement, compile, and self-test autonomously.

Although Qoder’s design needed continuous clarification, it considered things that are hard to foresee during technical-document design. For example, its questions revealed that the original design for refreshing a new channel’s token was wrong, enabling optimization.

Code Review stage

Even after repeated SPEC reviews, AI-generated code needs a code-level CR. I used both an independent-context CR agent with the technical document and manual visual checking, taking about two hours. Problems included:

Qoder’s habits did not match my own, changing some style. For example, it wrapped every request and response in a json object; AI can understand this, but future maintenance may be difficult.
Its architectural understanding of the application was insufficient, so some architecture-related foundational code was not handled well.
The application used much Diamond and database configuration, yet Qoder could not accurately obtain or add configuration, creating many configuration-handling problems.
Repeatedly prompting AI to fix these issues can pollute context and make Qoder fix things ever more incorrectly, eventually requiring human intervention.

In theory, a better harness can improve AI understanding of these issues. For item 4, subagents can reduce hallucinations caused by context consumption.

Self-test and fixes

After CR came self-testing. This could theoretically use MCPs for browser, HSF, database, and SLS configuration, but our infrastructure was incomplete, so testing remained manual.

Despite standardized documentation, the gateway did not correctly parse channel inputs and outputs. For a data.response.result response, Qoder omitted the middle response and parsed data.result, making channel data unavailable.
Channel error codes and idempotent retry mechanisms also need attention. Qoder handled error returns from the documentation but did not consider retries after errors or recovery cases.

These fixes were difficult to request in the old context. Many integration bugs require repeated alignment with the channel before a solution emerges. In this stage, manual modification often proved much faster than AI Coding.

[Practice 2] Using Qoder for a fund-settlement integration in unfamiliar code

This practice used Qoder and SPEC to write code for an application the developer did not know well. AI wrote 100% of the code, and delivery took about one week.

Development preparation

As in Practice 1, although I did not know the application’s architecture, I wrote a technical document from my own context and supplied it to Qoder+SPEC for design and coding. The document both let Qoder match the developer’s thinking more accurately and helped me become familiar with the system. If the developer does not understand the system, 100% AI Coding is clearly extremely difficult today.

AI Coding stage

I completed the core technical document manually:

During SPEC, Qoder revealed a major design problem:

Tax data had to be added. Under the existing business-code identity logic, the model needed two fields: tax amount and tax currency.
Because I did not know the code well, Qoder also identified the inflow and outflow direction of the tax fund flow during SPEC, avoiding many pitfalls.

Code Review stage

After Qoder independently wrote the code and unit tests, I started a new agent for CR. It found country-validation issues: only Mexico may calculate tax; non-Mexico traffic should alert and be blocked. Since the codebase was small, around 500 lines, the new agent independently performed CR and fixes using the technical document.

Self-test and fixes

End-to-end testing then found data inconsistencies through order processing.

CASE 1: Persisting data during order settlement failed because code fields differed from newly added database fields. Manual configuration changes differed from Qoder’s understanding, causing database insert failure.

CASE 2: After partial order refunds, recalculating tax produced a settlement-total discrepancy that prevented settlement. Investigation showed that recalculating settlement after a refund did not handle the new tax fields. This was a knowledge-base and model issue, so Qoder had to be prompted to add the missing code:

These problems show that insufficient context and reasoning information can skew Qoder’s technical design. Human intervention and alignment are still necessary for non-code issues, or its coding will also go wrong.

Reflections

Use SPEC well

Qoder’s SPEC mode is powerful: enable SPEC in the conversation and Qoder uses planning and subagents with existing MCPs and skills for Q&A before generating a spec document. Users should focus on reviewing and repeatedly revising that document through conversation to improve accuracy and delivery quality.

SPEC plus careful code review is at least twice as effective and efficient as simple conversational coding. SPEC consumes context quickly and it is unclear whether repeated compression will reduce quality, but Qoder’s current compression is good and accuracy has not visibly decayed.

Context determines everything

Modern coding agents compress context, but we still cannot complete unlimited requirements in one session. Claude Code’s official documentation says to conserve context: results below 50% context usage are much better than those above 70%.

Context is always precious. Conserve it by:

Using subagents: a subagent has context independent of the main agent, which only needs its result, not its process. Careful inspection shows Qoder sometimes spontaneously uses subagents itself.
Using skills rather than MCPs: both consume context, but MCP only tells the model that a tool exists, while a skill’s SOP is much more precise.
Disabling unnecessary skills and MCPs: do not load all system and personal MCPs and skills in every conversation; this consumes context and burdens the model with choices.

Use Qoder’s repowiki to keep the system architecture current, and rules and hooks to update rules and handling. Repowiki and rules enter the model context in every session; only continuously updating them and maintaining the harness makes Qoder increasingly useful.

Non-code configuration affects AI Coding efficiency

In the era of manual programming, everyone used non-code configuration to improve R&D efficiency. When a boss asks how efficiency improved, many answer, “What previously required code can now be done by configuration.”

Deployment and release are also extremely complex, and configuration helps changes go online quickly. But in an AI Coding era, when AI can write code almost instantly, do configurations scattered through Diamond, switches, and databases still improve efficiency?

They also create obstacles to AI understanding. Current infrastructure lets AI quickly read all code, but it is lost when configuration is involved: it cannot directly read configuration and therefore writes strange code. Without configuration permissions, developers also spend much time handling it themselves.

Human participation is unavoidable

Many people reconsider the roles of humans and AI from architecture and top-level design. Extreme designs even imagine no people: AI handles requirements, coding, tests, and releases. It is a beautiful wish, but frontline practice in large commercial systems shows that end-to-end AI still needs time. AI Coding still requires expert experience and human intervention.

Simple class-level changes can unquestionably be fully given to AI. But people cannot fully state requirements during requirement design—not only PD, but developers too. Requirement creators cannot state every delivery need at once; therefore AI cannot be expected to directly write highly faithful, robust code. Today AI coding can join each atomic R&D stage and iterate code through Vibe Coding, but humans must still connect the entire software lifecycle.

Collaboration is another familiar issue. People say most R&D time is spent in meetings, not coding; similarly, much software-development time is spent in integration rather than coding. In the two deep Qoder practices, it wrote nearly 85% of code in the first SPEC stage, but the 15% needing integration fixes required people; Qoder could not handle it.

For channel integration, Qoder omitted defensive programming such as idempotency, retries, transactions, and consistency. These must be customized for different architectures, and developers must participate deeply for Qoder to produce expected code. This is not unsolvable: continuously improving project-specific coding habits and rules through the harness will reduce such intervention.

Finally, if human participation is unavoidable, developers must still understand overall requirements, solution design, and code details. Would you dare deploy code you do not understand to serve users or operate funds?

Where are programmers’ capability boundaries?

If the obstacles to full-lifecycle AI coding discussed above—model capability, context, and infrastructure—are solved, will programmers’ job model change?

Certainly.

Programmers will no longer be constrained by languages: Java today, Python tomorrow. Once they understand a language’s core ideas, models can supply syntax and ecosystem. Nor must programmers be constrained by specialties: frontend, backend, and big data can all theoretically be completed with AI assistance.

Does that mean programmers can do everything, and AI lowers requirements? I believe the opposite. AI frees programmers from rote interview knowledge and syntax so they can focus on transferable capabilities: learning, innovation, and rapid migration. They must understand more, make decisions, judgments, and guidance for AI in core domains rather than merely implement—because AI will certainly do implementation.

In the near future, programmers must master coding-agent tools as they master computing fundamentals, give code development to AI, expand their ability boundary upward, and engage deeply with business requirements and product capability. That is the most certain trend.

So if your present work never requires professional judgment and you only keep your head down coding, it is time to look up and reassess yourself.

A Practical Guide to Claude Code Commands

Mon, 13 Apr 2026 14:00:00 GMT

Work agents were the undisputed stars of 2025, with Claude Code standing out most. Claude Code has remained at the forefront of coding agents, introducing concepts such as skills and subagents that have become de facto standards.

Subsequently, a series of coding agents—including Qoder, Gemini CLI, Qwen CLI, and CodeX—have followed CC’s main design. Once one understands the principles of one agent, that understanding can transfer to the others.

Meanwhile, concepts such as commands, skills, rules, and subagents exist in nearly every work agent. Once these assets are accumulated, they can be smoothly reused by other agents.

So, based on Claude Code’s official documentation plus my own understanding, I have organized these slash-command-related concepts to help with later vibe coding.

This is the first article in the Claude Code series. It introduces foundational concepts and operations. I expect two more articles: one on common context-optimization techniques in CC, and another on my personal thoughts about assisting programming with CC.

Basic concepts

Command

A command is the most direct user prompt for driving an agent. Entering instructions directly in the CLI or GUI input box triggers CC to respond.

If an instruction is too long or reusable, it can be made into a file and placed in the .cluade/commands/ directory. The next time it is needed, enter slash + command directly in the CLI, as shown below:

Skill

For related material, see: https://code.claude.com/docs/en/skills

A Skill can be understood as a large command that turns complex or standard work into an SOP. The biggest difference between a skill and a command is that skills can be invoked proactively, while during vibe coding Claude Code can also analyze context and decide whether to invoke a skill automatically. So how do we write a skill?

Writing a skill manually is certainly good, but in the AI era we can also ask CC to write it. Claude Code’s official skill guide and skill instruction can help us create one.

Once we have a skill for creating skills, we can converse with Claude Code to make other skills. For example, I wanted a skill that retrieves a document from yuque.com, with the following prompt:

Help me create a skill that retrieves documents from yuque.com. Specifically, I give you a Yuque document link (I can access it normally in Chrome because I am logged into my own Yuque account there, and the link is to my own Yuque document). Please read the document from the Yuque link, download it locally, and save it in Markdown format.

Claude Code can automatically discover the skill-create skill we just wrote, as follows:

I have uploaded the generated skill to GitHub; interested readers can click here to obtain it.

Next, using the yuque-fetcher skill generated by skill-create to save a Yuque document locally, Claude Code traverses all available skills and invokes the yuque-doc-downloader skill by default to download the article.

The result is excellent too. Although the images did not display successfully, the basic content was all there.

One question is how to discover whether a skill has been called. Check ~/.claude.json for the number of times a skill has been invoked in the background:

Rule

For related material, see: https://code.claude.com/docs/zh-CN/memory

The essence of a rule is also a kind of memory. CC supplies the complete rule to the LLM in every model request. We can inspect it with /memory:

The most common use of a rule is constraining Claude’s behavior. For example, code conventions can be written as rules for CC to use as reference. Project-level rules are located as follows:

your-project/
├── .claude/
│   ├── CLAUDE.md           # 主项目指令
│   └── rules/
│       ├── code-style.md   # 代码样式指南
│       ├── testing.md      # 测试约定
│       └── security.md     # 安全要求

Note that the paths property can choose which files a rule applies to, as follows:

---
paths:
  - "src/api/**/*.ts"
---

# API 开发规则

- 所有 API 端点必须包括输入验证
- 使用标准错误响应格式
- 包括 OpenAPI 文档注释

Hooks

For related material, see: https://code.claude.com/docs/en/hooks-guide

The Hook mechanism gives users more precise control over Claude Code’s behavior. We can run various commands before and after sessions, and before and after scripts execute.

According to CC’s official documentation, common hook phases are as follows:

A classic hook use case is context compression. For a project, we can have Claude compress context into local storage every time a Claude session closes, then automatically read it on the next launch.

Refer to Claude Code’s official example: whenever human intervention is needed, show a prompt so the task does not keep holding.

MCP

For related material, see: https://code.claude.com/docs/en/mcp

When Claude receives instructions, it lists not only all skills and rules, but all MCPs as well. Claude Code chooses the most appropriate MCP based on the user’s instruction.

Note, however, that MCP locations differ from those of skills and similar assets. Both user-level and project-level MCP configuration are in ~/.claude.json. Common MCPs include:

Name	Purpose	Main capabilities
sequential-thinking	Sequential reasoning for complex problems. When solving multi-step problems, performing logical analysis, or planning complex work, this server helps build a chain of reasoning step by step.	Multi-step logical analysis, task planning, step-by-step derivation of conclusions
jetbrains	Integrates with JetBrains IDEs, such as IntelliJ IDEA, PyCharm, and WebStorm.	Lets AI read code directly, refactor, run tests, access project structure, and perform other IDE-level operations
browsermcp	Browser automation that lets AI control browser behavior.	Navigate pages, click elements, fill forms, take screenshots; suitable for web testing, data collection, and application debugging
puppeteer	Browser automation based on Puppeteer, with capabilities similar to browsermcp.	Page control, element operations, JavaScript execution, PDF/screenshot generation; lower-level and more programmable
context7	Real-time access to current programming documentation and code examples, beyond the timeliness limits of AI training data.	Query API usage, obtain current library documentation, retrieve code examples, and support lookup of version updates

Note: browsermcp and puppeteer overlap in function, but browsermcp is a general browser-MCP interface, while puppeteer usually refers specifically to an implementation based on Chromium and Node.js automation.

Of course, MCP can also be configured at project level; use this command:

claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic

Subagents

For related material, see: https://code.claude.com/docs/en/sub-agents

Different agents can use different skills and MCPs, permissions, models, and context. In my view, the most important feature of a subagent is context isolation: different tasks can be isolated in separate contexts. This saves many tokens and makes model responses more precise.

Because a subagent is still an agent, its capabilities are almost the same as those of the primary agent. A subagent also has independent memory for maintaining long-term context; when creating one, we can explicitly enable memory storage.

How do we activate a subagent? There are two approaches. One is natural language in the CLI, such as Use code reviewer to help me complete a code review; the other is @ to explicitly require Claude Code to use an agent, such as Use @‘code reviewer(agent)’ to help me complete a code review.

After creating a subagent, its storage location is the same as skills and commands. At project level, it is stored in project/.claude/agents/.

For example, we can create a code-reviewer subagent to review code independently of the primary context.

As shown, the system can select the appropriate subagent based on natural language. But if the system can automatically find subagents to use, they also occupy a place in memory. In other words, more subagents are not always better; too many can, like MCPs, exhaust the context-token budget.

Plugins

For related material, see: https://code.claude.com/docs/en/plugins

A Plugin, as the name suggests, is a plugin. It is a collection of commands, skills, subagents, and so on. A Plugin is a solution for addressing one kind of work.

This article will not elaborate on it for now. Later I will create a plugin that pulls blog posts from the Yuque website and automatically publishes them to a WeChat Official Account, a personal website, and Xiaohongshu, then demonstrate its packaging capability.

My 2025: An Annual Review

Sun, 05 Apr 2026 09:13:00 GMT

Lunar New Year arrived rather late this year, indirectly delaying my 2025 review.

Sitting at my desk with a mixture of anxiety, regret, and confusion, I worked through last year’s diary and tried to recover its memories. I discovered far too many mistaken decisions.

Overall, 2025 fell somewhat short of expectations:

Although I graduated successfully with a Hong Kong master’s degree, failing to extract its full value was an absolute strategic mistake. On the positive side, it did broaden my perspective, including a deeper understanding of LLM fundamentals and blockchain, though I failed to convert that knowledge into concrete outcomes.
At work, I thought more deeply about the global-sales business, the connection between myself and the business, technology-driven progress, and AI enablement. I can feel that my understanding of work has advanced again compared with three years ago.
Regarding the future, I now understand my abilities more clearly. I used to want to chase every trend: self-media, videos, selling courses, and everything else. After flailing around for a long time, I realized that my skill tree simply does not point in that direction, so I have finally let it go. Concentrating on writing suits me better.

As usual, I will begin with a detailed review of 2025.

Progress on My 2025 Goals

At work, organize the full business chain and knowledge of cross-border transactions and fund fulfillment, and write one or two documents. Essentially complete. I spent substantial time documenting transaction flows, fund accounting, and other business logic. This should become a meaningful asset for my future.
In development, complete my approach to hot-spot systems under high concurrency and write two to four documents. 20%. At the end of 2025, I did read many relevant articles, including material on consistency and performance in concurrent scenarios, but I never turned the learning into documents.
Technically, master the foundations from ML through DL, NLP, and LLMs; build a mature product with Spring AI or LangChain; and write one or two documents. 40%. I produced one document on LLM fundamentals but did not create a mature product.
In education, earn my Hong Kong master’s degree. 100%. I graduated on October 15. A year of master’s study, IELTS preparation, and applications now feels like a dream.
Professionally, reach the next level, measured through performance. With no other major distraction, go all in at work. Basically complete. My S1 result was good, and my annual rating should be at least 3.5+.
In personal finance, average a 3% annual return, specifically by converting part of my funds into US dollars for fixed-term deposits. I was cautious about the unknown. The renminbi depreciated in the second half, while most of my principal remained in the bank, leaving a miserable return below 2%.
In mindset, focus on one or two important things and stop scattering my attention. Put concrete plans into action immediately. Looking back, this goal was too vague to have much value.
In routine, sleep at 12:30 a.m. and wake at 8:30 a.m. A complete 0%. My schedule was terrible and even affected my energy during the day.
In exercise, run 700 km during the year. 90%. I ran 650 km; the target was slightly misjudged.

Reviewing 2025

There were only two main missions in 2025: graduate successfully from UST and produce better results at work.

2025 was the Year of the Snake. On New Year’s Day, I hiked Hong Kong’s Snake Hill with Brother Ji. I no longer remember exactly where it was, but we had a good time. January always has the highest forgetting coefficient, so I recall only being surrounded by chores: buying New Year supplies, arranging a Hong Kong bank card, and worrying about my younger brother’s affairs. A business trip to Hangzhou at the end of the month at least gave me a few quiet days before the holiday.

Then I went home for New Year. The 2025 Spring Festival was hardly relaxing: as soon as I arrived, every kind of matter began revolving around me, and many things I had planned for the holiday went unfinished. At first, I was deeply frustrated by my failure to follow the plan, but gradually I became numb and silently permitted myself not to finish it—which is not a good outcome. During the holiday, I thought: I often attribute flaws in my personality to family education, but after thirty that may no longer be a good excuse. By then, I will have spent half my life away from home and must bear the cost of every outcome myself. The middle and latter parts of February were extremely difficult, chiefly because of the Batan PayPal project. Going from a beginner to launching the entire chain—from merchant onboarding and payment through settlement and accounting—nearly overwhelmed me. Yet I also gained a great deal from it.

In March, I reconsidered my direction and hoped to shift the center of my work toward AI while keeping up self-media operations. I did little concrete work, however. Looking back from 2026, I give the decision itself full marks, but my execution after March lagged badly. Other than bringing my WeChat public account close to one thousand followers, neither initiative produced substantial progress, especially AI.

March and April brought not only work but weekly travel between Hong Kong and Shenzhen for classes. The large-model and NLP courses nearly broke me. As a beginner who could not even configure a Python environment, I suddenly had to run LLM inference in Python. During early assignments, almost half my time went into learning prerequisites and configuring the environment. Worse, I ran the code on a Thunderobot laptop bought in 2017. Its fan mixed with the hot cicadas outside and repeatedly made me restless. Fortunately, I could use the company’s GPU resources for free. Thanks to Alibaba and Bailian, I obtained a 32-core GPU on weekends to finish the assignments. In the process, I learned how to perform SFT on a model and about model classification. The gains were substantial.

May was filled with deadlines for projects across all my courses. I spent almost every day on assignments and, for the first time, felt that I might not withstand the load. Staying up late every night made it impossible to focus all my energy on work. When the assignments ended in late May, I fell back into indecision: what was my career plan? Should I take advantage of studying in Hong Kong to remain there for work, or go to Singapore?

From June through September, I shifted my attention back to work. Several major events occurred:

The department’s collaboration model changed. Our group brought in many outsourced employees, and I had to coordinate with and train two or three of them while completing my own work. During this period, I worked intensely from 9:50 a.m. to 10:30 p.m. almost every day and felt physically drained. Rather than passively enduring it, I proactively asked my manager to clarify how many person-days belonged to outsourced work and loosen the allocation for my own business. This gave me room to breathe and let me train the outsourced colleagues more effectively to accept requirements.
My business scope also changed. Because another colleague planned to leave, I additionally took over fund-related requirements covering payments and settlement. It was challenging, but the new scenarios taught me more business knowledge. This was one important reason I earned a good S1 rating.
I began formally mentoring someone for the first time, four years after graduation. The intern was only a year younger than me but carried the unmistakably dazed air of a student. I believe I guided him attentively, and he successfully passed his conversion defense in September.
I used company travel funding for a business trip to South Korea, my first trip abroad. Shenzhen is a remarkable place. Since moving there in 2024, I have visited Hong Kong and South Korea and encountered different lifestyles and working cultures. The world feels full of possibilities.
I organized a team self-driving trip for the first time. The intern, outsourced colleagues, other teammates, and I drove Guangdong’s Route 318—an amazing journey.
I wrote several popular articles. How Programmers Should Configure a MacBook Pro produced more than 30,000 views on my WeChat public account for the first time, a small breakthrough. I followed it with articles on blockchain and the digital renminbi, which also performed well.

October brought graduation, finally closing my year as a Hong Kong master’s student. I even received the school’s Top Student Reward scholarship. At work, I entered the S1 review and received a decent result. I had wanted to use that momentum to keep charging ahead, but at the end of the month I learned that our business had been assigned to another manager, who brought several trusted lieutenants with him. The situation instantly felt complicated.

I spent the remaining time preparing again for the early-November professional software exam. The result shocked me: I passed comprehensive knowledge and case analysis, but failed the essay section I had considered certain. I was upset for a long time. It felt as if my effort had brought no return, and I even formed the illusion that no amount of work would let me succeed. My confidence took a real blow. Must everyone pass through such a stage in life? I remembered a sentence by Wang Xiaobo and the person I was on my twentieth birthday. Back then, I wanted to become a cloud in the sky. Now I seemed to have been slowly hammered flat.

I should have studied AI seriously and prepared paid courses on agent development. Curiosity distracted me instead: in late November and early December, I served as a teaching assistant for UST’s blockchain lecturer. He was Indian and had a strong accent, making communication difficult. The experience also led me to revisit blockchain and Ethereum, and overall I learned something. In hindsight, though, the path had drifted. I should have gone all in on agents then and at least completed the goal I set in 2024.

To summarize simply, 2025 had too many branching paths. I departed from my 2024 goals and seriously lost touch with AI agents, though I understood LLM fundamentals reasonably well. This affected a series of decisions in 2026.

Goals for 2026

At work, find a new direction and land it successfully, integrating AI coding and AI-assisted work fully into my job.
Technically, discover and resolve latent transaction-consistency problems in the system.
In AI, master the internals of one agent framework, such as Spring AI, LangChain, or Eino, and understand how coding agents work.
In writing, force myself to collaborate and publish two WeChat public-account articles each month. This is the most important goal.
In education, obtain the professional software certificate.
In personal finance, allocate 10% of my assets to US stocks and target a 3% return.
In exercise, run 700 km.
In health, undergo gastroscopy and colonoscopy and establish a 12:30 a.m.–8:30 a.m. sleep schedule. Stop sitting for long periods and reduce the fat around my lower abdomen.
In focus, keep phone use below two hours on more than twenty working days.

How Large Models and Agents Are Democratizing Technology

Sat, 10 Jan 2026 07:42:00 GMT

I really do not know Git very well.

During campus-recruitment interviews, I could talk circles around interviewers and casually reel off commands such as merge and revert over the phone. But honestly, I had barely used them.

After more than four years of work, I still knew only the five basic moves: pull, add, commit, checkout, and push. I rarely encountered complex Git commands or collaboration workflows in daily work, so I had little motivation to study them carefully.

But if you often walk beside the river, eventually your shoes get wet.

At around 10 p.m. last night, a teammate, Xiao A, committed and pushed the code for his feature branch as usual. After pushing to the test branch, he predictably encountered conflicts: with year-end approaching, no fewer than five feature branches had been merged into the test branch while awaiting deployment to the test environment.

This situation is common. Xiao A pulled the remote test branch, intending to merge his feature branch into it. Instead, with one slip, he merged hundreds of commits from the test branch into his own feature branch.

He did not yet realize how serious the situation was—or even that there was a problem—and continued committing code locally on his feature branch.

After several rounds of local commits, once he was satisfied that the code worked and prepared to push it to the remote test branch, he suddenly discovered that the test branch had contaminated his branch. His feature was due for testing and release the next day; he could hardly deploy everyone else’s test code along with it.

Xiao A began to panic.

Like me, he did not know Git particularly well. After struggling for an hour, he still could not remove the unwanted commits from his local feature branch.

With no better option, he created a new branch and cherry-picked his earlier commits onto it. By the time he finished, it was already past midnight. Exhausted, he took a taxi home under the moonlight.

The incident caused no major damage, but I was sure there had to be a way to remove the junk commit history from the original branch. The next morning, I opened GPT.

As I typed, “Branch A accidentally merged branch B. How can I remove multiple commits from B?” and prepared to press Enter, a thought occurred to me: “Could I just ask Claude to operate on it directly?”

That led to the following conversation with Claude.

Me:

My Git branch accidentally merged another branch. Please roll it back to the latest commit whose committer is Xiao A.

CLAUDE:

Understood. I first need to find Xiao A’s latest commit hash and inspect the current working-tree state.
The target commit is commit_hash_A. I also found that an interactive rebase is currently in progress and has merge conflicts. To roll back safely, I need to abort the current rebase and then perform a hard reset.

Me:

Roll me back to this commit: a3a8f43dfa8eac801e804f76cf2c36450c717479.

CLAUDE:

No problem. I will reset HEAD directly to that commit.

Me:

Can you force-push my local branch to the remote repository?

CLAUDE:

Yes. I have confirmed that the current branch is feature_1. Because we just rolled it back, the local branch is behind the remote and requires a force push.

Me:

The remote repository still contains the earlier merge commits and differs from my local branch. How do I remove them?

CLAUDE:

Let me compare the commit-history differences between the local feature_1 and the remote branch.

The analysis shows that although the local pointer is correct, the remote history contains many nonlinear merge commits automatically produced by the build system. We need to clean up the timeline.

Please confirm your cleanup strategy:

Completely discard every commit after the target?

Or retain normal code commits after the target while removing only the merge commits?

Me:

I want to retain the normal commits after a3a8f43dfa and remove only the merge commits—the commits not made by Xiao A.

CLAUDE:

Understood. This is a complex “rebase cleanup” task. Strategy: create a temporary branch from the clean commit, “pick out” (cherry-pick) Xiao A’s valid commits from the old branch, append them to the new branch, and finally replace the original branch.

Create a backup and temporary branch

Select and migrate Xiao A’s commits

Replace the main branch and push

From asking Claude the first question to its completing the entire job took less than ten minutes. It was fast and effective. At that moment, I truly felt that technology had been democratized.

Our use of large models should not stop at conversation. With capabilities such as MCP and RAG integrated into agents, a well-written prompt can enable them to complete a great many tasks for us.

Inside the company, we have also used large models and coding agents to generate code autonomously. Many teams are actively exploring autonomous ticket diagnosis, integration testing, and other capabilities based on large models and agents.

Individuals should likewise use agents to automate routine chores. Our working model may eventually change: learning how to talk with an agent and supervise it may become an important subject.

The foundational capabilities of large models—what we usually call pre-training—matter greatly. Some people say post-training matters too, and I do not disagree. In the consumer market, however, agent capability will be the decisive factor for many AI products.

I believe that helps explain why Meta spent a billion dollars acquiring a company that did no model training and focused only on agents. It also helps explain why Alibaba’s Qwen, despite becoming the leading open-source model worldwide, still cannot outperform Doubao in the consumer market.

Finally, returning to today’s topic: how can you quickly remove a branch that was merged into your Git history? See the image below.

Note: the images in this article were generated with Gemini Nano Banana Pro.

How Cross-Border E-Commerce Transactions Work

Sun, 04 Jan 2026 06:16:00 GMT

As someone who spends time surfing the Internet, I use online shopping platforms such as Taobao, JD, and Pinduoduo for everyday purchases.

Since changing roles in August 2024, I have been responsible for online-shopping business similar to Taobao and JD, but with two differences. First, Taobao and JD are B2C shopping platforms for ordinary consumers, while the code I write serves B2B trade platforms. Second, Taobao and JD serve domestic merchants and consumers, whereas I work with overseas merchants and overseas consumers every day.

Over the past year, the code I developed has covered merchant onboarding, transactions, orders, safeguards, payments, settlement, liquidity, accounting, gateways, and other domains. As my first article of 2026, this is a summary of roughly the past year of work. It also explains the complete cross-border transaction-fulfillment flow.

What buyers and sellers do on e-commerce platforms

The essence of online transactions on e-commerce platforms is managing the flow of information, funds, and logistics: 1) transactions carry the information agreed by buyers and sellers; 2) funds legally and compliantly transfer buyers’ payment to sellers’ cards; and 3) logistics safely transports sellers’ goods to the locations buyers specify.

Below is a brief summary from buyer-seller and platform perspectives.

Buyer and seller perspective — the transaction lifecycle

The end-to-end view from buyers’ and sellers’ perspective is as follows:

The preceding diagram shows a release of funds action after the buyer completes payment. Payment cannot go directly into the seller’s account because we cannot guarantee that the seller will fulfill normally afterward. If you have noticed, when you confirm receipt on Taobao, you are asked to enter your payment password (or complete Alipay facial verification). That is because for Taobao, your money is truly paid to the merchant only when you confirm receipt.

From buyer and seller perspectives, the following are the main action points:

Platform perspective — the platform’s role in a transaction

From the platform’s perspective, the key is to connect the flows in different business domains across transaction and fund stages. A simplified flowchart is as follows:

E-commerce participants and profit models

Participants — many pairs of eyes behind a transaction

For ordinary consumers, this is simply a transaction completed by buyer and seller on a platform. From the platform’s perspective, though, transaction participants include not only the platform and buyer and seller, but also various intermediary funding channels.

Taking a basic cross-border online trading platform as an example: if the platform is not licensed to handle buyers’ funds, then in addition to buyers, sellers, and the platform, an extra funding center is needed. The arrangement is as follows:

Once a platform has the license to hold funds, it often has the acquiring institution settle funds to the platform to strengthen its control over funds; the platform then settles those funds to sellers worldwide through a payout institution.

Every participant should be bound by an agreement with the others.

Buyers need an agreement with the platform to purchase goods and pay for them; merchants need an agreement with the platform to trade goods and withdraw funds; Adyen, as the acquiring channel, also needs a corresponding acquiring agreement with the platform; Payout, as the payout channel, needs corresponding payment-service agreements with both the platform and merchants. If there is an FX institution (used to exchange foreign currencies into USD), that institution must also sign an agreement with the platform.

Profit models — how platforms make money

From a consumer perspective, online transactions can charge merchants a transaction service fee on every transaction. In cross-border scenarios, however, platforms have many ways to profit:

Transaction dimension
1. Transaction service fee: roughly a 3% technical service fee is charged to merchants for each transaction. This revenue belongs entirely to the platform; accordingly, the platform must issue an invoice to the merchant.
Payment dimension
1. Payment processing fee: each payment charges the payer (buyer) a 3% fee (depending on the payment instrument). Unlike domestic payments, overseas payment instruments generally charge the payer a percentage on every payment (credit cards are basically 2%, for example). The platform shares revenue with the payment institution under a fixed rule.
Withdrawal dimension
1. Withdrawal fee: every time a merchant withdraws funds from its platform balance account to a bank card, it is charged a fee at a fixed rate or amount. The platform generally collects it on behalf of the provider, then shares it with the payout institution. This applies both domestically and internationally: merchants pay fees whenever they withdraw. For example, Alipay and WeChat both charge a 0.1% withdrawal fee.
Value-added services
1. Insurance premium: the platform can help merchants insure goods and share premiums with the insurance company.
2. Loan interest: mature platforms partner with banks to offer loans to merchants, splitting loan interest with the channel.
3. Collection service fee: by providing factoring institutions, platforms help merchants collect funds rapidly, sharing the service fee with the institution.
4. Deposit: merchants often pay the platform a deposit when opening a store, used for deductions in subsequent after-sales disputes.
Merchant dimension
1. Merchants joining Alibaba International Station as members need to pay a membership fee.
2. Merchants can purchase many kinds of services to increase the exposure of their stores and themselves, thereby improving conversion. This is the profit core of virtually every online platform, such as Taobao’s Alimama and Douyin’s Ocean Engine.
Logistics dimension
1. Merchants pay the platform a logistics fee when shipping; the fee is shared with logistics companies.

Cross-border fund clearing and settlement

Transactions represent information flow; another important part is fund flow. At the lowest level, fund flow is the movement of money among financial institutions, accompanied by debit-credit relationships among accounts. Fund transfers and accounting give rise upstream to business scenarios such as merchant onboarding, payment, settlement, withdrawal, transfers, and foreign exchange.

Fund flow — how your money reaches the merchant’s pocket

For a cross-border platform in its early construction phase, an acquiring platform can provide USD settlement capability to get the site running quickly, so there is no need to introduce an FX institution. Note that because this is a cross-border platform, under the current system of U.S.-dollar dominance, USD is the default preferred settlement currency.

The fund flow is shown below:

Phase one: After placing orders, buyers around the world enter the payment process. They pay the acquiring institution (for example, Adyen) through CREDIT CARD, GOOGLE PAY, APPLY PAY, PAYPAL, and other local payment methods. Adyen then performs internal currency conversion and settles the funds to the platform entity at T+1.

Phase two: Through a T+1 transfer, the platform moves money settled to it by the acquiring institution into the account it opened with the payout institution, in fixed amounts according to merchants’ withdrawal amounts. Merchants can then withdraw money from their platform balance accounts directly into their own accounts. To ensure merchants can withdraw quickly, the project uses prefunding: before the project operates, funds are advanced to the payout institution through a treasury account.

After the platform develops and matures, it will certainly add multiple acquiring institutions to introduce more payment instruments. When an acquirer does not support USD settlement, the platform needs an FX institution to convert other currencies to USD and settle them to the platform. The fund flow then becomes:

As the diagram shows, the platform must now recognize the user’s payment currency and complete its own rate lock and conversion from LCY to USD.

Accounting capabilities — how a platform records money

Since money must move and be transferred N times from buyers to merchants, how do we ensure that it is recorded correctly? This requires understanding a platform’s accounting capability, namely how it records money. The platform creates N virtual accounts internally to represent flows among different accounts. Internet companies generally use double-entry bookkeeping; interested readers can explore it further. Here are several classic account types:

Pending-association account: after a buyer pays, funds are recorded in the pending-association account.
Escrow account: after the system associates the funds with an order, the merchandise-payment portion moves from the pending-association account to the escrow account.
Revenue account: the system moves the platform’s receivable portion (transaction service fees, processing fees, and so on) to the revenue account.
Tax account: the system moves taxes withheld and remitted for merchants (such as EPR and GST) to the tax account and reports them to the corresponding authorities on schedule.
Merchant balance account: after a merchant fulfills, money moves from the escrow account to the merchant balance account.
Dedicated withdrawal account: after a merchant initiates a withdrawal, money in the balance account moves to the dedicated withdrawal account.
Refund transit account: after a buyer requests a refund, funds are gathered into the refund transit account through fund preparation and paid to the payment channel.

Here is a classic flowchart (including forward and reverse flows) for a more detailed view:

Machine Learning for Backend Developers in the Age of Large Models

Wed, 24 Dec 2025 13:50:00 GMT

Preface

From the emergence of the Transformer architecture in 2017 to the arrival of GPT in 2022, people have increasingly recognized the importance of large models, to the point that every year seems to be proclaimed the inaugural year of LLMs. As we gradually enter the AI era, I feel both deeply anxious, worried that large models might replace me, and excited by the prospect of doing more with LMs.

But what can I do with LLMs? And what do I need to understand?

Before the age of large models, backend developers could generally start building software once they had mastered a programming language such as Java, Go, or JavaScript, along with architectural knowledge of MySQL and Redis. In the AI era—or, more precisely, the age of large models—knowing only conventional programming languages is clearly no longer enough.

LLM engineering can be summed up in one sentence: using all kinds of prompts to call LLMs, accompanied by engineering capabilities such as MCP and RAG. If you want to quickly embed LM capabilities into a business scenario, it is essentially the same as being a CRUD developer in the old days: simply call the open APIs provided by large-model vendors.

Yet merely calling a model’s API is like looking at the moon reflected in water or flowers reflected in a mirror: you never truly see the essence or the whole system. In my view, for backend developers who want to become part of the AI era, the first step should not be calling LLM-related APIs. It should be understanding the concepts and principles behind traditional artificial intelligence and machine learning. What exactly is the relationship between ML and DL? How did architectures such as CNNs, RNNs, and Transformers evolve? Without this basic knowledge, it is like programming without understanding operating systems or computer networks—you can complete basic development tasks, but cannot go further and glimpse the wonders of the computing world.

So I spent some time organizing my understanding of artificial intelligence and machine learning around a number of common questions.

Your AI and My AI Seem to Be Different

In recent years, with the rise of large models, everything has become AI. In the narrow sense, AI means artificial intelligence, and the people primarily responsible for implementing it are called “algorithm engineers” (often jokingly called parameter tuners). In the age of large models, many people use large models as a synonym for AI. Luo Yonghao, for example, has consistently argued that the true AI era did not arrive until 2023. So what are the relationships and differences among artificial intelligence, machine learning, deep learning, and large models?

According to Hung-yi Lee’s framework, we generally regard Artificial Intelligence (AI) as the ultimate goal and Machine Learning (ML) as the primary means of achieving it. Computer Vision (CV), Natural Language Processing (NLP), and similar fields are specific applications.

From a layperson’s perspective, ML is an umbrella term whose core logic is to “train models with data so that computers learn patterns independently and complete specific tasks.” Among the technical branches of ML, Deep Learning (DL) is currently the most central and mainstream direction. Deep learning uses “deep neural networks” as its core architecture, with multiple layers containing many neurons that learn. In increasing order of complexity, neural networks include basic Feedforward Neural Networks (FNNs), Recurrent Neural Networks (RNNs) for sequential data, and Convolutional Neural Networks (CNNs) for spatial data. Google’s Transformer architecture restructured the sequential processing principles used by RNNs and CNNs. By adopting a Self-Attention mechanism, it addressed sequence dependency problems, allowing a model both to perceive relationships among tokens and to train in parallel.

As for Large Models (LMs), “large” refers not only to their number of parameters but also to the volume of data required for training. It was the Transformer that made scaling models to this size possible. One of the earliest branches of large models was the Large Language Model (LLM), which originated in NLP and is suited to conventional NLP tasks such as text generation. With the development of multimodal LMs, however, large models are no longer confined to NLP; in pursuit of the broader goal of AI, they have reached into every kind of application.

What Can Machine Learning Do?

At the application level, ML-based LLMs can generate text from text, images from text, text from images, and more. At their root, however, all application tasks ultimately return to two categories: “regression” and “classification.”

Regression is similar to y=kx+b: different inputs produce different values. Regression tasks are commonly used for prediction, such as weather forecasts, house prices, and stock trends. Classification builds on regression and uses an activation or classification function to divide results into categories, such as positive and negative. Classification tasks are commonly used for labeling.

The recommendation component in search, recommendation, and advertising systems is a classification task. As is widely known, although a large model generates text according to predicted probabilities, it is essentially predicting the next word (Token) from a vocabulary of, say, 50,000 words. Large models therefore perform classification tasks.

What Exactly Is a Model?

With the widespread adoption of large models, almost everyone has heard the word “model.” But what exactly is one?

At a high level, a model is a black box. You provide input to the model, computations take place inside it, and it ultimately returns an output.

Looking at the open-source model repository on Hugging Face, a model looks like this:

Inside a model is a collection of parameters (weights). What we call the model’s thinking process is essentially a series of vector operations—mainly matrix multiplication—performed together with the input tokens. In the age of large models, we can narrow our focus and think of the model as a neural network composed of many neurons. So what exactly is a neuron?

Neurons and Neural Networks

Neurons

A neuron can be understood simply as a computational unit. Given an input x, the neuron might compute wx+b, and its calculated output can be y. The difference is that x is not a single variable of the kind encountered in high-school mathematics, but a one-dimensional vector made up of n variables related to the input:

$y = \sigma(w_1 x_1 + w_2 x_2 + b)$ , that is:

$y = \sigma([w_1, w_2] \cdot \begin{bmatrix} x_1 \\ x_2 \end{bmatrix} + b)$

In the expression above, $$x_1$$ and $$x_2$$ are input features. For example, in a weather forecasting model, $$x_1$$ might be humidity and $$x_2$$ might be temperature. $$w_1$$ and $$w_2$$ are the variables’ weights, also known as “parameters.” Training means continually adjusting the values of $$w$$ (and other parameters) so that the output $$y$$ approaches the true value and the loss becomes lower. $$b$$ is the bias—or, in simpler terms, the intercept—which can increase or decrease the computed value. The symbol outside the parentheses is sigma ( $\sigma$ ), representing the activation function. Common activation functions include Sigmoid ( $\sigma(x) \in (0,1)$ ) and ReLU ( $$relu(x) = max(0,x)$$ ). Activation functions control the output and make the result nonlinear.

A visual representation of a neuron is shown below:

A simple neuron can be expressed in Python as follows:

import torch

def simple_neuron_torch(x, w, b, activation=torch.sigmoid):
    z = torch.dot(x, w) + b  # 点积是标量
    return activation(z) # 通过sigmoid激活

x = torch.tensor([28.0, 75.0])  # 今天：温度28°C，湿度75%
w = torch.tensor([0.5, 0.5])   # 权重：高温抑制下雨(-0.5)，高湿度促进下雨(+0.8)
b = torch.tensor(-15.0)         # 偏置：基准阈值

output = simple_neuron_torch(x, w, b)  # 得到最后的下雨概率（0.9999）

Suppose the trained parameters are $$w_1=0.5, w_2=0.5, b=-40$$ , giving $y = \sigma(0.5 x_1 + 0.5 x_2 - 40)$ . We obtain the prediction trend shown below:

From the diagram, we would conclude that higher temperature and higher humidity make rain more likely. Let us examine the cases:

Case A (sauna-like weather): $0.9 \times 0.5 + 0.9 \times 0.5 = 0.9$ (predicts rain, correct ✅)
Case B (desert): $0.9 \times 0.5 + 0.0 \times 0.5 = 0.45$ (predicts no rain, correct ✅)
Case C (extreme heat and dryness): suppose the temperature is exceptionally high, $x_1=2.0$:
- $2.0 \times 0.5 + 0.0 \times 0.5 = 1.0$ (predicts rain, incorrect ❌)

We find that even if the trained w and b are optimal, the result is necessarily linear. Weather forecasting, however, is not a linear prediction problem. We therefore need to try other tools to solve it.

Fully Connected Neural Networks

As we can see, a simple neuron can only perform linear regression. The real world is complex, so we need to connect multiple neurons together to perform more complex tasks.

The weather forecasting example tells us that forecasting weather is not a linear prediction problem. The weather features are related, yet a single neuron cannot capture those relationships. From an engineering perspective, when in doubt, add an intermediate layer. Since temperature and humidity are related, we can associate them to form multiple intermediate features, then use those intermediate features to produce the final result, as shown below:

Converted into simple mathematical formulas, this becomes:

h_1 = \sigma(w_{11} x_1 + w_{12} x_2 + b_1) \\ h_2 = \sigma(w_{21} x_1 + w_{22} x_2 + b_2) \\ h_3 = \sigma(w_{31} x_1 + w_{32} x_2 + b_3) \\ y_{final} = \sigma(v_1 h_1 + v_{2} h_2 + v_3 h_3 + b_4)

Because the formulas above connect $$x_1, x_2$$ as completely as possible, we call this network a Fully Connected Network (FCN), which forms the foundation of modern deep learning. Applying this FCN to our humidity and temperature example, let $$h_1$$ represent sauna-like conditions, $$h_2$$ cold and humid conditions, and $$h_3$$ hot and dry conditions. Suppose training produces the following result:

h_1 = \sigma(x_1 + x_2 -1.2) \\ h_2 = \sigma(-x_1 + x_2 -0.5) \\ h_3 = \sigma(x_1 - x_2 - 1.0) \\ y_{final} = \sigma(2 h_1 + 0.5 h_2 - h_3 -1)

We obtain the prediction diagram below. As you can see, after adding the intermediate layer, the model no longer predicts rain under “hot and dry” conditions.

Returning to the mathematical formulas, if there are many features and multiple layers of neurons, the preceding notation becomes far too complicated. Using the spatial transformation properties of matrix multiplication—rotation, scaling, and distortion—we can rewrite the hidden layer as follows:

h = \begin{bmatrix} h_1 \\ h_2 \\ h_3 \end{bmatrix} = \begin{bmatrix} \sigma(w_{1,1}x_1 + w_{1,2}x_2 + b_1) \\ \sigma(w_{2,1}x_1 + w_{2,2}x_2 + b_2) \\ \sigma(w_{3,1}x_1 + w_{3,2}x_2 + b_3) \end{bmatrix} = \sigma(\begin{bmatrix} w_{1,1} & w_{1,2} \\ w_{2,1} & w_{2,2} \\ w_{3,1} & w_{3,2} \end{bmatrix} \cdot \begin{bmatrix} x_1 \\ x_2 \end{bmatrix} + \begin{bmatrix} b_1 \\ b_2 \\ b_3 \end{bmatrix}) = \sigma(Wx + b)

The final output is therefore:

$y_{final} = \sigma( \underbrace{\begin{bmatrix} v_1 & v_2 & v_3 \end{bmatrix}}_{W_2} \cdot \underbrace{\begin{bmatrix} h_1 \\ h_2 \\ h_3 \end{bmatrix}}_{h} + b_4 )$ .

When training in code, however, we want to parallelize as much of the work as possible, which introduces the concept of batching. Instead of calculating one feature sample at a time, we group samples into a batch and calculate several at once, using the following formula:

\begin{bmatrix} h_{1,1} & h_{1,2} & h_{1,3} \\ h_{2,1} & h_{2,2} & h_{2,3} \\ h_{3,1} & h_{3,2} & h_{3,3} \\ h_{4,1} & h_{4,2} & h_{4,3} \\ h_{5,1} & h_{5,2} & h_{5,3} \end{bmatrix} = \begin{bmatrix} x_{1,1} & x_{1,2} \\ x_{2,1} & x_{2,2} \\ x_{3,1} & x_{3,2} \\ x_{4,1} & x_{4,2} \\ x_{5,1} & x_{5,2} \end{bmatrix}_{\text{Data (5 days)}} \cdot \begin{bmatrix} w_{1,1} & w_{2,1} & w_{3,1} \\ w_{1,2} & w_{2,2} & w_{3,2} \end{bmatrix}_{W^T} + \begin{bmatrix} b_1 & b_2 & b_3 \end{bmatrix}_{\text{Bias}}

That is:

$h_{\text{单层输出}} = xW^T + b$

In code:

class SimpleFCN(nn.Module):
    def __init__(self):
        super(SimpleFCN, self).__init__()
        self.fc1 = nn.Linear(2, 3)
        self.fc2 = nn.Linear(3, 1)

    def forward(self, x):
        x = torch.sigmoid(self.fc1(x))
        x = torch.sigmoid(self.fc2(x))
        return x

CNNs and RNNs

With FCNs, we can theoretically use enough data to train for any result we want. But because FCNs are fully connected, they have three major drawbacks:

Parameter redundancy and high computational cost: By default, every neuron connects to every neuron in the previous layer, causing the number of parameters to rise sharply. When the input dimensionality is high, as in high-resolution images, or the network has many layers, this can cause a parameter explosion that exhausts the computer’s memory.
Local features are ignored: Because every FCN computation must consider all inputs, it has no concept of “spatial locality.” It cannot behave like the human eye, first focusing on local features such as lines and textures and then combining them into a whole. Instead, it processes all information in one undifferentiated gulp.
No awareness of “order”: In an FCN, all input features are parallel, so the network cannot perceive which came “before” and which came “after.” For example, when we feed a Sentence into an FCN as Input, the FCN cannot effectively capture temporal dependencies among Tokens, making it difficult to understand contextual meaning.

CNN

A CNN, or Convolutional Neural Network, centers on a convolutional layer. Unlike an FCN, this layer does not connect every neuron to all parameters; it connects them “selectively.”

Suppose we have a 33-pixel image. If we use an FCN to recognize it, we must flatten the 33 pixels into nine parameters and perform fully connected linear operations on them. A single neuron can be expressed mathematically as follows:

\begin{bmatrix} x_1 & x_2 & x_3 \\ x_4 & x_5 & x_6 \\ x_7 & x_8 & x_9 \end{bmatrix} \xrightarrow{\text{Flatten}} [x_1, x_2, x_3, x_4, x_5, x_6, x_7, x_8, x_9]

$h = \sigma(w_{1} x_1 + w_{2} x_2 + ... + w_n x_n + ... + w_9 x_9 + b) \\$

Flattening almost completely removes positional and spatial information from the parameters. Using an FCN therefore causes not only a parameter explosion, but also a reduction in recognition accuracy.

For images, preserving positional information means we cannot flatten the input pixels. We must consider the relationships among pixel values. At the same time, to avoid computing every pixel each time, we need a window so that each neuron calculates only the values inside that window. If the window is 2x2, it can be represented as follows:

\text{Kernel} = \begin{bmatrix} w_{1,1} & w_{1,2} \\ w_{2,1} & w_{2,2} \end{bmatrix}

This Kernel is the convolution kernel. The neuron can now be expressed as:

$h = \sigma(w_{1,1} x_1 + w_{1,2} x_2 + w_{2,1} x_4 + w_{2,2} x_5 + b) \\$

As we can see, a convolution-kernel neuron has two characteristics: first, it does not process all parameters; second, it can precisely perceive position-related information.

The essence of a convolution kernel is that it focuses on local features instead of all features. We can think of a convolution kernel as a local feature detector. Suppose $$K_h$$ has 22 parameters and is specifically responsible for recognizing “vertical lines.” $$K_h$$ slides up, down, left, and right through every 22 block of pixels to find blocks that might contain a “vertical line.”

An image has more than one feature, so we use multiple convolution kernels ( $$K_1,..., K_n$$ ), each representing a different feature. Some kernels may recognize lines, others colors, and so on.

A simple CNN is shown below:

import torch
import torch.nn as nn

class CNN_Model(nn.Module):
    def __init__(self):
        super().__init__()

        # 1. 卷积层 (眼睛)
        # in_channels=1: 因为是黑白图，只有1层深
        # out_channels=32: 我们用 32 个不同的卷积核(手电筒)去扫描，提取32种不同的特征
        # kernel_size=3: 卷积核大小是 3x3
        self.conv1 = nn.Conv2d(in_channels=1, out_channels=32, kernel_size=3)

        # 2. 激活函数 (当然还要用 ReLU)
        self.relu = nn.ReLU()

        # 3. 池化层 (压缩)
        # 2x2 的窗口，把图片长宽各缩小一半
        self.pool = nn.MaxPool2d(kernel_size=2)

        # 4. 全连接层 (大脑)
        # 经过上面的卷积和池化，图片变小了，但在深度上变厚了(32层)
        # 这里需要算一下剩下的特征数量，连接到分类器
        self.fc = nn.Linear(in_features=32 * 13 * 13, out_features=10)

    def forward(self, x):
        # 保持图片的 2D 结构进行处理
        x = self.conv1(x)  # 扫描
        x = self.relu(x)   # 激活
        x = self.pool(x)   # 压缩

        # 展平，交给全连接层做最后决定
        x = x.view(x.size(0), -1)
        x = self.fc(x)
        return x

model = CNN_Model()
print(model)

RNN

FCNs transform user-provided features into more general features, while CNNs go further by handling certain relationships among features. Neither FCNs nor CNNs, however, address relationships among features across time. Consider this scenario:

While performing machine translation, we try to translate “Book a hotel” and “I like book” into Chinese.

If we directly train an FCN on the sentences above, each token in “Book a hotel” must be used as a training parameter. That is certainly feasible, but once the sentence to translate changes to “I like book,” the original FCN becomes completely unusable because its input parameters have a fixed shape. An FCN alone is therefore wholly inadequate when the input varies.

Since training the complete sentence is impractical, we must split it into words and train on them separately. In other words, the input cannot be fed all at once as it is in an FCN; it must be fed incrementally. Yet because “book” has different meanings in different sentences, when we input the current word we must also retain some preceding words and provide them to the model as input.

Can we therefore design a network that 1) dynamically perceives input tokens and 2) perceives not only the current token but previous tokens as well? That is precisely an RNN (Recurrent Neural Network).

At its core, an RNN adds a recurrent mechanism to an FCN, enabling it to perceive the preceding output. Its mathematical expression is:

h_{t-1} = \sigma(W_{xh} \cdot x_{t-1} + b )\\ h_t = \sigma(\underbrace{W_{xh} \cdot x_t}_{\text{处理当前输入}} + \underbrace{W_{hh} \cdot h_{t-1}}_{\text{处理过去记忆}} + b)

The formula shows that the essence of an RNN is to feed the result calculated from the previous input into the next computation as another input. The Python code is as follows:

import torch
import torch.nn as nn

# --- 设定参数 ---
input_size = 10   # 输入特征维度 (比如今天的10个财经指标)
hidden_size = 20  # 记忆容量 (隐藏层神经元数量)

# --- 定义权重 (这就是 RNN 模型本体) ---
# 1. 处理输入的权重 (对应 x_t)
W_xh = nn.Linear(input_size, hidden_size)

# 2. 处理记忆的权重 (对应 h_t-1) <--- RNN 独有的！
W_hh = nn.Linear(hidden_size, hidden_size)

# --- 模拟时间序列数据 (Sequence) ---
# 假设有 5 天的数据 (Time steps = 5)
inputs = [torch.randn(1, input_size) for _ in range(5)]

# --- 初始化记忆 (h_0) ---
# 一开始脑子是空的
h_t = torch.zeros(1, hidden_size)

print("开始时间循环...\n")

# --- RNN 的核心循环 ---
for i, x_t in enumerate(inputs):
    # 公式: h_t = tanh( W_xh * x + W_hh * h_prev )

    # 1. 现在的输入产生的反应
    current_input_effect = W_xh(x_t)

    # 2. 过去的记忆产生的反应
    past_memory_effect = W_hh(h_t) # 注意这里用的是上一轮的 h_t

    # 3. 融合 (相加) 并 激活
    # Tanh 是 RNN 最常用的激活函数，因为它输出在 -1 到 1 之间，能防止数值爆炸
    h_t = torch.tanh(current_input_effect + past_memory_effect)

    print(f"第 {i+1} 天: 更新了隐藏状态 (记忆)。部分数值: {h_t[0][:3].detach().numpy()}...")

print("\n循环结束。最终的 h_t 包含了过去 5 天的所有累积信息。")

There is one important detail: if the weight is 0.9, then as the number of propagation layers grows, $0.9^{n}$ approaches 0. This means an RNN cannot remember very long inputs; overly long inputs cause it to “forget,” a phenomenon known as the vanishing-gradient problem. This led to the development of LSTM, which uses an Input Gate, Output Gate, and Forget Gate to decide when to store memories and to control the model’s forgetting more precisely.

What Exactly Are a Model’s Parameters?

From the FCN, CNN, and RNN models above, we can see that a model is essentially $y = \sigma(kx+b)$ . Its so-called parameters are therefore $$k$$ (the weight, or w) and b (the bias). A real model simply has n$ values of x and m values of y. As n and m (as well as the neurons in the intermediate hidden layers) increase, there are more weights and biases, and the trained model becomes more “intelligent.” This is the popular industry understanding of the “large” in “large model.”

Training a model means using various mathematical methods to calculate the most effective weights and biases. Take GPT-3 as an example: it has 175B (175 billion) parameters, meaning that the w and b values across all its neurons add up to 175 billion.

TODO-Hyperparameters.

How Does a Model Understand Natural Language?

So far, we have learned how a model performs inference: given an input x, where x is a tensor, it applies a series of formula-based operations and produces an output. This raises a question. Whether we use an FCN, RNN, or CNN, the model can only perform floating-point operations, so its input must be a group of numbers. That works well enough for ordinary mathematical predictions. But for today’s flourishing field of natural language processing, how do we turn natural language into numbers that a model can understand?

One-Hot

The simplest approach is to use a Boolean-array mapping. Given a Boolean array of fixed length, we identify different tokens by marking different indexes as true. Suppose your vocabulary contains only five words: ["我", "爱", "学习", "AI", "猫"]. The word “学习” is represented as [0, 0, 1, 0, 0].

One-hot encoding has two fatal problems that prevent it from being used in LLMs:

Sparsity and the curse of dimensionality: A real vocabulary contains tens or even hundreds of thousands of words. Each word becomes a vector of length 50,000 containing 49,999 zeros. This wastes enormous computational resources.
Lack of semantic relationships (Semantic Meaning): In One-Hot space, the distance between every pair of words is identical. The distance between “cat” and “dog” is the same as the distance between “cat” and “refrigerator.” The model cannot know that “cat” and “dog” are similar.

Embedding

Embedding lets us compress one-hot’s high-dimensional sparse vectors into low-dimensional dense vectors. For example, we can map “cat” to a 512-dimensional vector:

$\text{Embedding(cat)} = [0.21, -0.54, 0.03, ..., 0.99]$

In this new vector space, words with similar meanings are closer together geometrically. For example, we can approximately say:

$"国王" - "男人" + "女人" \approx "女王"$

How do we obtain a set of dense vectors capable of retaining relationships among words? The method is straightforward: perform unsupervised training and transformation with an FCN. Here is an example:

Calculate the five-dimensional one-hot vectors for “机器学习改变了世界” and convert them into three-dimensional dense vectors.

Define one-hot vectors for the five tokens. For example, the one-hot vector for 学习 is $$x = [0, 1, 0, 0, 0]$$ .
Define a linear regression network in which W has a 5x3 structure, then substitute the x for “学习” as follows:

h = x \cdot W_{in} = [0, 1, 0, 0, 0] \cdot \begin{bmatrix} w_{0,0} & w_{0,1} & w_{0,2} \\ \mathbf{w_{1,0}} & \mathbf{w_{1,1}} & \mathbf{w_{1,2}} \\ w_{2,0} & w_{2,1} & w_{2,2} \\ \vdots & \vdots & \vdots \\ w_{4,0} & w_{4,1} & w_{4,2} \end{bmatrix}_{w初始为随机浮点数}

Next, calculate the dot product of $$h$$ and another transposed matrix, $W_{out}$ :

$z = \sigma(h \cdot W_{out} = h \cdot [u_0, u_1, u_2, u_3, u_4])$

This gives the probabilities relating “学习” to each token in the original sentence. Suppose the calculated dot-product result is:

$\hat{z} = [0.05, \quad 0.02, \quad \mathbf{0.80}, \quad 0.01, \quad 0.12]$

This means there is an 80% probability that “改变” follows “学习,” but we want that probability to be 100%. We therefore need to update the values in W through backpropagation. After multiple rounds of training, $W_{input}$ becomes our final embedding vectors.

How Does a Machine Learn?

We have repeatedly emphasized that we need to train models so they can learn independently. How, then, does a model learn?

Before examining the learning process in depth, we need to understand two terms: Forward Propagation and Backpropagation.

Forward Propagation

Forward propagation is quite simple to explain. The FCN, CNN, and RNN computations described above are all forward propagation, expressed as:

$y_{pred} = \text{Model}(x)$

During forward propagation, the parameters (Weight and bias) are known and given. In fact, when we use GPT or Gemini, the process by which the model produces an answer is forward propagation.

Backpropagation

Backpropagation is the reverse of forward propagation. Given $y_{pred},y_{true},LearningRate$ , it is the process of calculating the parameters $$Weight, Bais$$ .

To define exactly how far apart $y_{pred}$ and $y_{true}$ are, we generally use a Loss Function. This is the Loss commonly discussed when training models: the larger the Loss, the worse the model’s result. A common loss function is Mean Squared Error:

$Loss = (y_{pred} - y_{true})^2$

To reduce Loss, we use backpropagation together with the Gradient Descent algorithm, calculating new weights through differentiation according to this formula:

$W_{new} = W_{old} - \text{learning\_rate} \times \text{Gradient}$

Learning_rate is the step size, which determines how much the weights change in each training iteration. You can search for details on how the Gradient is calculated; I will not cover them here. An example of backpropagation follows:

import torch
import torch.nn as nn
import torch.optim as optim
import matplotlib.pyplot as plt

# --- 1. 准备数据 (真值) ---
# 假设真实规律是: y = x * 0.5 + 0.2
# 我们生成 100 个数据点
X = torch.rand(100, 1)  # 随机生成 0~1 之间的温度
y_true = X * 0.5 + 0.2  # 这是我们要逼近的"靶心"

# --- 2. 搭建模型 (射手) ---
# 一个最简单的线性层: y = w * x + b
# 初始时，w 和 b 都是随机生成的，它根本不知道 0.5 和 0.2 是什么
model = nn.Linear(1, 1)

print(f"初始随机权重 w: {model.weight.item():.4f}, 偏置 b: {model.bias.item():.4f}")

# --- 3. 定义工具 ---
# Loss Function (裁判): 均方误差
criterion = nn.MSELoss()
# Optimizer (教练): 随机梯度下降 (SGD)，学习率 lr=0.1
optimizer = optim.SGD(model.parameters(), lr=0.1)

# --- 4. 开始训练循环 (练习射箭 100 次) ---
loss_history = []

for epoch in range(100):
    # A. 前向传播 (射出一箭)
    y_pred = model(X)

    # B. 计算 Loss (测量差距)
    loss = criterion(y_pred, y_true)
    loss_history.append(loss.item())

    # C. 反向传播 (寻找原因)
    # 这行代码会自动计算所有权重的梯度
    optimizer.zero_grad() # 清空上一次的梯度
    loss.backward()       # <--- 核心！反向传播发生在这里

    # D. 更新权重 (纠正姿势)
    optimizer.step()

# --- 5. 结果展示 ---
print(f"训练后学到的权重 w: {model.weight.item():.4f} (真实值是 0.5)")
print(f"训练后学到的偏置 b: {model.bias.item():.4f} (真实值是 0.2)")

# 画图：Loss 是如何下降的
plt.figure(figsize=(8, 4))
plt.plot(loss_history, color='red')
plt.title('Loss Curve: Error drops as the model learns')
plt.xlabel('Training Iterations (Epochs)')
plt.ylabel('Loss (Error)')
plt.grid(True)
plt.show()

Why Do GPUs Rule the World?

Before exploring this question, let us distinguish CPUs from GPUs:

CPU: A CPU has a small number of powerful cores—our typical servers, for example, may have eight cores. It handles complex computations and logical branches, adding caches, control units, and other components to its computational units.
GPU: A GPU has many simpler cores—even an ordinary one may have 4,096. Each core has limited capabilities and can perform only simple arithmetic rather than complex logic.

From model inference and training, we know that both forward propagation and backpropagation involve vast numbers of vector-product operations and differentiations. At heart, these are simple floating-point operations. Such operations basically do not interfere with one another, so they are naturally suited to “parallel” computation, making them an excellent fit for GPU architecture.

For example, multiplying two 1000x1000 matrices requires roughly one billion multiply-add operations. Even with eight parallel threads, an eight-thread CPU will take a long time to process them. A GPU has many more cores, so it is naturally much faster.

References

Hung-yi Lee’s materials: YouTube (in Chinese), Bilibili (in Chinese)
Gemini
Datawhale: https://github.com/datawhalechina

Why So Many Students Choose to Study in Hong Kong

Tue, 07 Oct 2025 02:36:00 GMT

Preface

Time flies. It has been a full year since I went to Hong Kong for a master’s degree in September 2024. Although I have not spent that much time in Hong Kong during the year—perhaps only several dozen days in total—the city’s distinctive character has deeply impressed me.

I am a typical small-town test taker. I never left the county town for study in junior or senior high school. As I recall, my first visit to the provincial capital was for a special-admission examination at a Project 985 university after the college entrance examination. I first left the province only after entering university, on a trip to Shanghai with classmates during the summer of my freshman year at age eighteen. As for going abroad or outside the mainland, embarrassingly, I had never done it before working and then studying for a master’s degree.

So, taking this first anniversary of study as an opportunity, I would like to talk about my year of overseas study from the perspective of a worker who returned to education after working. This is the first article in a series. It mainly introduces differences between Hong Kong—especially its education—and mainland China. Friends interested in studying in Hong Kong are also welcome to message me for details.

Where do Hong Kong and mainland China differ?

This section will not focus on simple differences in daily life, such as language and transport. Its focus is on the different positioning of Hong Kong and the background of “one country, two systems.”

Hong Kong through “one country, two systems”

After I went to Hong Kong for the start of term last year, I was initially just curious about a different environment—for example, signage everywhere is in traditional Chinese and English, and I never saw Mandarin or Pinyin. Later I found that Hong Kong’s institutions are indeed fundamentally different from those on the mainland.

Under “one country, two systems,” Hong Kong’s foreign affairs, sovereignty, and military are managed centrally, while other systems—such as legislation, justice, prosecution, speech, and finance—are decided by the Hong Kong government itself. After entering Hong Kong, one finds that speech controls and ideology are completely different from the mainland. As I recall, Luo Yonghao and Zhou Hongyi both had experiences of being summoned by mainland police and fleeing to Hong Kong, because Hong Kong’s judicial independence prevents mainland police from enforcing law across the border. Hong Kong’s financial system is also closer to Western systems; its payment habits are nearly identical to Europe and the United States. Similarity in financial systems is one reason there are more foreigners in Hong Kong. A Hong Kong identity is also more readily recognized by other countries and regions, so many classmates find applications for Japanese, European, and American visas especially easy using a Hong Kong identity card.

High-school textbooks tell us that we are a socialist country with Chinese characteristics, whereas after 1997 Hong Kong continued the capitalist system from the period of British colonial rule. In government elections, people from all sectors of society who meet legal qualifications—who comply with the Basic Law—can participate according to law. I often saw candidates posting “pick me”-style advertisements on the minibus to and from school. Hong Kong residents can also express views on government measures through various channels, provided they do not violate the Basic Law: “what the law does not prohibit may be done.” As a capitalist region, many Hong Kong matters operate through capital. Employees’ Mandatory Provident Fund, for example, is managed by qualified private MPF trustees, fundamentally unlike mainland state-owned enterprises and direct government management. Even the Hong Kong dollar is issued by three private banks authorized by the government and pegged to the U.S. dollar: banks remit U.S. dollars to the Hong Kong government, receive permission, and issue Hong Kong dollars at a fixed exchange rate. This is fundamentally different from the mainland’s unified issuance of RMB by the central bank.

Why Hong Kong is the Pearl of the Orient

Hong Kong is known as the “Pearl of the Orient” and is a financial center for exchange between the mainland and the outside world. Because of its previous British colonization, combined with intentional government promotion in recent years, Hong Kong has become a top-tier Asian financial center. Nearly all major global financial institutions establish their Asian headquarters there. Of course, in recent years some institutions have moved headquarters to Singapore for various reasons; Singapore is challenging Hong Kong and establishing a new financial order.

Every year, a continuous stream of foreign-exchange reserves is delivered to the mainland through Hong Kong, while much RMB is exchanged for U.S. dollars through Hong Kong’s financial center. Nearly all internationalized mainland companies—including familiar Internet companies—open Hong Kong branches, using its international settlement network and multi-currency financing channels to conduct business. Most transaction-settlement funds circulate through Hong Kong’s banking system. In recent years, many companies have sought to go overseas. One could even say that Hong Kong is necessarily the first stop for mainland companies going global—not to sell goods in Hong Kong, but to use the absence of foreign-exchange controls to allocate cross-border funds or convert them into Hong Kong dollars, U.S. dollars, and other currencies for international settlement and asset allocation.

Consequently, Hong Kong’s financial industry is extremely developed. Many large mainland companies establish finance, investment, and legal departments there. I once heard from a friend of a friend inside Tencent that he goes to Hong Kong every year to report investments to Pony; that also demonstrates Hong Kong’s financial position. But for the IT work I do, Hong Kong is much weaker: old technology stacks and low salaries characterize Hong Kong IT. Only bank technology departments or quantitative technology are a way forward in Hong Kong IT, and how much does getting into such firms actually have to do with technical skill?

Benefiting from Hong Kong’s position as a financial center, Shenzhen has developed increasingly fast because it faces Hong Kong across the sea. A quick look at the job market shows an enormous number of Shenzhen cross-border trade and cross-border payment companies. Because Hong Kong has no foreign-exchange controls and customs clearance with Shenzhen is convenient, many Shenzhen colleagues experienced in stock trading exchange a certain amount of RMB for Hong Kong dollars or U.S. dollars to further optimize asset allocation.

Working and living in Hong Kong

After visiting Hong Kong many times, one finds that its social welfare and facilities for an aging society do differ from the mainland’s.

For example, it provides Old Age Allowance and Old Age Living Allowance to elderly people. Taxes paid by workers are relatively low—progressive taxation, with a maximum of 17%—and beyond tax, only a 5% Mandatory Provident Fund contribution is needed. The MPF system is similar to the mainland pension system. What impressed me most is that Hong Kong’s infrastructure is very friendly to older people and people with disabilities. Buses have wheelchair boarding ramps; when a wheelchair user is waiting at a stop, the driver immediately gets out to open the dedicated ramp. Hong Kong’s tactile paving is also comprehensive. On my way to and from school I saw blind people walking with canes more than once. Consideration for aging is not merely infrastructure; it has entered ordinary people’s minds, and many would rather stand than occupy priority seats on the metro or bus.

What astonished me was Hong Kong people’s strong awareness of rules. Even when lifts are crowded, people queue on the right and leave the left passage for people in a hurry, except in extremely crowded cases. I remember once queuing for a toilet stall: people in Hong Kong began queuing at the entrance, ensuring that whoever arrived first used a stall first, rather than everyone standing at the doors of separate stalls. When everyone follows one set of rules, ordinary people enjoy basic services more fairly and society operates more efficiently.

But no place is perfect. Many people know average salaries in Hong Kong are very high; even restaurant waiters seen everywhere earn roughly HKD 15,000–25,000 per month. Yet consumption is extremely expensive. Leaving housing aside, even a simple three-dish meal at my school cafeteria costs around HKD 40–50. At a modest restaurant outside, ordering a few dishes can start at HKD 200 per person, unaffordable for ordinary people. At times, a taxi from school back to Shenzhen—a trip of about 50 km—costs HKD 400. That said, Hong Kong’s public transport is very developed, and basic travel can largely be completed by metro and bus.

Some mainland people may have experienced discrimination from Hong Kong people. Once, on a minibus home, I misheard Cantonese spoken by the driver and he said contemptuously, “This is Hong Kong, not the mainland.” I cannot say I was not angry in that moment, but I also knew it was only the driver’s impotent rage. Friends who know Hong Kong told me that with faster implementation of one country, two systems and a continuous inflow of high-end talent, many older blue-collar workers still have hostility toward mainland people. In their minds, the mainland remains the mainland of twenty years ago. Little do they realize that times change unpredictably and China is becoming stronger than ever.

Still, it must be admitted objectively that there are obvious gaps between the mainland and Hong Kong in some respects. I believe behind these gaps is the difference between 1.4 billion people and 7 million people: as population differs, the difficulty of management rises exponentially. Times are developing; the Party’s strong leadership and the superiority of the socialist system will both become engines for the Eastern dragon’s development. Our motherland will certainly become better!

Does university education in Hong Kong differ from the mainland?

Although I graduated from undergraduate study three years ago, returning to Hong Kong to study still lets me feel huge differences between the two education systems.

Mainland education emphasizes universal access more. The government’s first goal is enabling every child, no matter how poor, to afford university, and it also devotes considerable effort to making up for educational shortcomings for people with disabilities. But mainland China has too many students, and because it has developed so quickly, the teacher-student ratio is relatively low. Hong Kong performs a little better on this ratio and, as is well known, its education is more “elite-oriented,” allowing students more diverse development.

Below, from my own experience, I briefly compare educational systems at mainland Project 211 universities and Hong Kong’s top-three universities.

University information systems

During my whole undergraduate career, whether notices from the university or school, events, or course assignments, everything was communicated through QQ group chats—perhaps WeChat now. But because Hong Kong study and work are more Western-oriented, many matters are notified by email: post-holiday shuttle-bus arrangements, holiday periods, professors’ lectures, maintenance information, and every other detail. It is normal for students to receive dozens of relevant emails a day.

Whether group notices or email are better is a matter of opinion, but Hong Kong classrooms are much more digitalized than mainland ones. Teachers’ contacts, course information, and assigned work—including deadlines—are all available on websites or Canvas. Students upload completed electronic assignments directly through Canvas. This made a particularly deep impression on me. In undergraduate study, almost every assignment—calculation problems, coding, and so on—was written on paper and handed to the class study representative to submit. If one missed the representative’s collection time, one had to submit it directly to the teacher; students sometimes missed deadlines because they could not find the representative. As I recall, undergraduate grades and rankings were sent to the class monitor, who posted them directly as group announcements, causing students who performed poorly to publicly lose face. When studying for my master’s in Hong Kong, teachers put grades, rankings, and the class’s top and bottom quarter score lines only on each student’s own Canvas, protecting everyone’s privacy.

Besides notices and classes, Hong Kong university websites are especially well digitalized. Any information can be found on the intranet, including course results, employment information, tuition payments, and graduation information. Because I am not often in Hong Kong during term, what I find most convenient is being able to check my elective credits at any time and directly check my graduation progress through the website.

Teaching quality

Because my Hong Kong degree is an MSc, mainly taught courses, I also made a simple comparison of classroom quality in the mainland and Hong Kong.

In Hong Kong I took easy courses I had already studied, such as Computer Networks and Software Engineering, as well as comparatively cutting-edge courses such as Blockchain, LLM, and NLP. What impressed me most was how current the teachers’ ideas were. In all these computing-related courses, professors mentioned large models, and each course specifically spent one or two classes explaining the relationship between LLMs and the course, as well as current LLM development. Another discovery was that many knowledge points came with links to relevant papers for students to explore. I never had that experience as a mainland undergraduate. I never knew what a paper was in undergraduate classes; only after studying in Hong Kong did I discover how close research was to me. I once spoke with an associate professor from my undergraduate university, who candidly said he had not learned for a long time and, being older now, basically did not read papers in related fields. Hong Kong instructors are generally at the research frontier, so students can better grasp the idea of “papers.”

In addition, I found many part-time teachers while studying in Hong Kong. They do not hold university “establishment” positions and only undertake teaching duties. They generally have PhDs and other jobs in society. For example, my first-semester Blockchain teacher and second-semester FinTech teacher both worked outside the university and taught on weekends as part-timers. We did have corporate-practice courses as undergraduates, but because they carried no or very few credits and were extremely superficial, I think everyone understands the overall quality. I think this Hong Kong arrangement is an especially good innovation. Compared with the possible separation from practical reality among some mainland teachers who remain in ivory towers, learning from it could very likely ease the current disconnect between mainland schools and social needs.

Perhaps because the Hong Kong government and universities have money, learning facilities are exceptionally good: the library even has many free 4K monitors for students. Students can also reserve school study rooms online for group discussion. Thinking back to undergraduate group discussions, we either met in an open-air cafeteria or found an empty classroom, which is a little bittersweet.

Admission difficulty and career development

It is well known that because mainland China has so many students, the college entrance examination is particularly competitive. So many mainland parents send children to Hong Kong for high school so they can apply directly to Hong Kong universities for undergraduate education. This is indeed one option. But the money and effort involved are absolutely beyond what an ordinary family can bear. I do not know much about this area, so I will not discuss it in detail.

Perhaps because I am at HKUST, the entrepreneurial atmosphere is especially strong. Many students’ labels are “serial entrepreneur”; at such young ages, they have started businesses several times and even received angel rounds, which truly astonished me. At university I also learned about some Hong Kong PhD situations. People basically pursue PhDs with full scholarships, receiving roughly HKD 20,000 per month, which feels like a substantial income during doctoral study.

Many people are interested in MSc employment and PhD progression. Since this article is already lengthy, I will discuss these in detail in the next one.

Why the Digital Renminbi Matters in an Online Payment Economy

Wed, 17 Sep 2025 02:36:00 GMT

Preface

I have recently been developing cross-border payment and fund-related features. Cross-border fund movement is truly expensive and slow, although domestic consumers hardly feel those drawbacks. That led me to study China’s online-payment network, as well as the digital renminbi and stablecoins.

Some readers probably have a digital-renminbi bank account. Yet most people ask the same question when using it: paying with the digital renminbi feels almost identical to Alipay. Since we already have online payment as convenient as Alipay, why is the country promoting it?

Some guess it is redundant and merely creates jobs. Others think the state wants to take control of electronic payments back from Alipay and WeChat. Some even think it is only a blockchain gimmick for capital markets.

In fact, its strategic value goes far beyond what most people imagine. The digital renminbi has been digital from its creation, which is very different from traditional paper RMB supported by the Internet.

From a user’s perspective, the digital renminbi and Alipay are both quick and convenient online payments. But in areas such as large-value transactions, which ordinary consumers rarely encounter, conventional RMB online payment still has many pain points.

This article begins with online payments, discusses the difference between conventional RMB and the digital renminbi, and finally considers the opportunity for stablecoins in mainland China.

The nature of conventional online payments

Conventional online payments complete transactions through digitized banknotes. Underneath, RMB still needs to move among banks.

Information flow and fund flow

Before online transactions became widespread, everyone transacted offline directly with RMB. When we hand cash to a merchant, the delivery of funds and goods is completed simultaneously. This is the familiar idea of “payment and goods settled together”; the transaction’s information flow and fund flow also finish together.

Keeping cash on hand is inconvenient, so most money is held in banks. Withdrawing it to buy goods offline is troublesome. Naturally, we want to pay directly online through banks, as shown below.

But is the solution really that simple? What if Li Si’s account is at another bank?

Bank A must actually transfer Zhang San’s 10 yuan to Bank B; this is called fund delivery. Delivery cannot be completed by a simple instruction, so interbank transfers are slow. Can they be made faster?

Yes. Bank A can open an account at Bank B and deposit a reserve. When Zhang San asks Bank A to transfer 10 yuan to Bank B, Bank A only sends the instruction and Bank B debits A’s account. This is clearly much more efficient.

This approach still leaves at least two issues unresolved:

The obstacle of transfers among many banks: China has hundreds of commercial banks. Must every bank deposit funds with every other? A bank failure or disappearance could cause a major incident, which the state does not want.
Lack of supervision and restraints: without effective supervision, commercial banks may face moral hazard, such as transferring Li Si’s funds to Zhang San without authorization.

Therefore, a highly trusted intermediary is needed. This role is performed by the People’s Bank of China (PBOC). The PBOC requires online payments and transfers to go through UnionPay (interbank transactions) or NetsUnion (transactions involving payment institutions); those systems settle the funds. Commercial banks and payment institutions must also maintain reserve accounts at the PBOC, which completes final fund delivery.

Modern online payments can therefore be roughly divided into two steps:

Information flow: payment institutions or banks make internal book entries and freeze the funds, completing preliminary processing.
Fund flow: funds are actually moved through the central-bank clearing system; only then does ownership truly transfer.

This is the information flow and fund flow often mentioned in payments. Online payment is much more complex than it looks. Can such a complex process finish in seconds?

Clearly it cannot. Every transaction must be handled by the central bank. If it updated every bank’s reserve account in real time for each transaction, its system would quickly collapse. The PBOC instead uses T+1 batch processing and netting for daily transactions between banks and payment institutions. The information flow can finish quickly, but the fund flow through the PBOC may take a day to become final.

Why then does an Alipay transfer feel instantaneous to consumers? Alipay provides credit backing and advances funds. Because it has reserve accounts at partner banks, it can notify relevant banks to pre-debit funds during the information-flow stage. In general, when users see a transaction succeed in real time, only the information flow has succeeded; the fund flow still needs central-bank settlement.

Transactions, clearing, settlement, and delivery

To understand what happens behind a payment, we need to clarify transaction, clearing, settlement, and delivery.

Transaction: here this does not mean buying and selling goods, but theinitiation of a payment instruction. It specifies sender, recipient, amount, and other information, and starts the fund process. Clicking “Confirm payment” in Alipay initiates afund-transfer instruction.From the user’s view, “Success” means the instruction has been received, not that fund transfer is over. Participants include theuser initiating it and the payment institution or bank receiving it.
Clearing: thecentralized handling of many transactions over a period. It verifies transaction information, calculates each party’s receivables and payables, and establishes the claims and obligations between payment institutions and banks (the net amount). In short, it calculates who owes whom how much; an obligation is established but funds have not moved. Participants are mainlyclearing institutions such as NetsUnion and UnionPay, banks, and payment institutions.
Settlement: the process offinal confirmation of clearing results and creation of irrevocable transfer instructions. It makes obligations final. Clearing and settlement are often jointly called “clearing,” normally comprising “calculate the accounts” and “pay the money.” Participants extend to thecentral bank payment system.
Delivery (Settlement finality): when settlement is complete and transfer is irrevocable, delivery has been reached. It is thefinal stage, achievingsettlement finality. The central bank adjusts the balances of the relevantcommercial banks in theirreserve accounts. Only then have funds fully transferred in law. A payment institution’scentralized customer-reserve custody account is adjusted correspondingly, ultimately affecting its custodian bank’s reserve account.

Typical processing times:

Stage	Time window
Transaction	24/7 (users may initiate payment instructions at any time)
Clearing	Real-time clearing (D0) or scheduled clearing (such as early morning T+1, chosen by the payment institution)
Settlement	24/7 (small-value / third-party payments) or weekdays 8:30–17:00 (large-value system, traditional mode)
Delivery	Real-time after settlement (account balances update immediately)

Fund movement in online payments

Suppose user A transfers 100 yuan from a China Merchants Bank account to user B’s Alipay balance. Each stage is:

Transaction: A clicks pay in Alipay, which sends an instruction to China Merchants Bank, and the bank freezes A’s amount. A sees payment succeed and B receives money, but Alipay has only made internal entries; funds have not truly moved.
Clearing: Alipay packages transactions from a period and sends them to NetsUnion, which calculates how much Alipay should receive from CMB and pay other banks (netting).
Settlement: NetsUnion turns the calculated net result (for example, Alipay receives a net 100 yuan from CMB) into a formal settlement list and sends it to the PBOC payment system.
Delivery: The PBOC’s large-value payment system completes the transferfinally and irrevocably on its ledger: it debits 100 yuan from CMB’s reserve account and credits Alipay’s reserve account. Only then has A’s 100 yuan actually left CMB and entered Alipay’s pool.

The flowchart makes the full fund movement easier to see:

Drawbacks of online payments

Conventional RMB is essentially cash; online payments merely digitize it. Ordinary people cannot digitize cash and trade online by themselves, so they deposit money in banks and use banks or payment institutions as intermediaries.

Intermediaries create these drawbacks:

Poor timeliness: Although small transfers seem instant to both parties, that only completes the transaction stage; the fund flow has not finished. Large-value transfers still need T+1 (withdrawals commonly arrive T+1). If domestic large-value transfers take T+1, international transfers take even longer; USD-to-PKR may take a week.

High fees: Alipay and WeChat charge withdrawal fees (0.1%). Cross-border transfers can involve more intermediary banks and average around 7% in fees.

Difficult account opening: Offline, cash is enough. Online, an account must be opened at a bank or payment institution, with identity registration and review. This is unfriendly to overseas travelers and visitors from elsewhere.

Network dependence: Current online payments rely on the Internet. Without it, online transactions are impossible.

Institutional risk: Online payments rely on banks and payment institutions. If they disappear or fail, users’ funds may change hands.

The digital renminbi emerged to address these drawbacks.

The underlying logic of the digital renminbi

Its nature

Unlike conventional RMB, which is still essentially physical cash, the digital renminbi uses blockchain capabilities and is digital from inception. In theory, its online transactions need no intermediary bank or payment institution.

For example, Zhang San can transfer 10 yuan of digital RMB directly to Li Si through their electronic wallets, just as handing over 10 yuan in cash. The record is written directly to a blockchain operated by the PBOC; no payment institution or bank participates.

In one sentence: conventional RMB online transactions, such as online banking and Alipay, separate a first-completed information flow from a later-completed fund flow. Digital-RMB online transactions, like conventional RMB offline transactions, unify both flows and complete them simultaneously.

Blockchain and smart contracts

The digital renminbi is based on blockchain technology. What is a blockchain?

Think of it as a special linked list. Unlike an ordinary linked list, changing information in any blockchain node requires changing every following node to produce a valid chain again. Because such changes are extremely costly (almost impossible), a blockchain is essentially an immutable database.

For an article on blockchain, see:

A 10,000-word introduction to blockchain and Bitcoin · Yuque (in Chinese)

Because it cannot be modified, once user transaction data is stored on a blockchain, we can trust the authenticity of account balances derived from it.

A smart contract can be understood as a contract running on a blockchain. It is tightly bound to the currency on that blockchain. Code can specify when it automatically transfers money to someone. Once published, it cannot change; when a specified condition is triggered, it transfers money to a specified account.

Digital RMB and Bitcoin

Based on blockchain and cryptographic algorithms, both digital RMB and Bitcoin are cryptographic digital currencies, but they differ fundamentally.

The central difference is thatBitcoin is completely decentralized: any participant can operate a node, and transaction information is fully public. By contrast,digital RMB uses a centralized architecture whose blockchain nodes are entirely controlled by the PBOC, protecting transaction records and account balances.

In terms of value,Bitcoin fluctuates sharply: from the original 1,250 BTC for a pizza to as much as US$110,000 per coin, its price is highly uncertain.Digital RMB is stable: as central-bank digital currency, it is backed by national credit, exchanged at par with paper RMB, and has unlimited legal-tender status.

As to issuance,Bitcoin supply is fixed at 21 million from inception and is controlled by no institution.Digital RMB issuance is flexible: like conventional RMB, it is macro-regulated by the PBOC according to economic need.

Thus, despite both using cryptography, digital RMB is legal tender representing national credit; Bitcoin is decentralized crypto currency with more of an investment character. This is their most fundamental difference.

Digital-RMB applications

Returning to the original question: what does digital RMB have to do with ordinary people? After much thought, regrettably, not much. Competition from Alipay and similar institutions pushed banks to optimize online payments—small transfers are free and arrive in seconds—so consumers already have an excellent, fee-free experience.

In special circumstances, however, ordinary users can benefit. Without a network, online payments stop working. An electronic wallet on a physical device can pay digital RMB offline because balance information is local, then synchronize settlement with the PBOC once online. That means tourists in mountainous areas need not carry cash.

But the country would obviously not invest this effort merely for offline payment. The core is direct transactions between counterparties through the central-bank system, without intermediaries. Together with smart contracts, which can enforce transfers automatically under contractual terms, this creates different application scenarios.

Cross-border use

Friends who trade US or Hong Kong stocks may know that domestic-to-foreign-bank transfers use SWIFT. Funds need clearing through the relevant central banks for USD, EUR, or RMB and through several intermediary banks. Each bank holds the funds and charges a percentage or fixed clearing fee.

International interbank transfers typically take at least T+1 and fees are often around 5%. Excluding risk-control review, digital RMB could arrive in real time and at very low cost because there are no intermediary banks. This would be a major benefit for cross-border trade, one of the three engines of growth.

The country is also promoting digital RMB in Belt and Road settings to reduce dependence on the US-centered SWIFT system. If countries across Asia and Africa accept it, cross-border trade—especially fund movement—could happen anytime and anywhere.

B2B

For merchants, consumer payment in digital RMB transfers directly through the PBOC blockchain into the merchant’s digital-RMB wallet. There are no payment institutions or intermediary banks, and thus no “withdrawal,” withdrawal fee, or slow arrival.

Smart contracts also bind contracts to fund flows automatically, making payment default less likely. For example, suppose Company A and Company B sign a procurement contract: when B receives A’s product, B pays A RMB 1 million. Traditionally, the contract creates legal obligations; if B does not pay, A must use judicial procedures.

With digital RMB this could differ. A and B can create a coded smart-contract agreement. When a logistics company sends delivery information to the contract, it automatically transfers B’s RMB 1 million to A’s account, preventing non-payment.

Business is complex, however. Not every acceptance criterion can be digitized. If Party A delays acceptance, the system cannot trigger the contract and the digital RMB in A’s account still cannot settle to Party B. Technology alone cannot solve this.

G2B

Smart-contract rules can direct government digital-RMB fiscal allocations more precisely, preventing misuse and untraceability of conventional funds. For example, a poverty-alleviation program is intended for fertilizer and seeds. The government creates a subsidy smart contract and funds it. It specifies: 1) only designated farmers may use the subsidy, each with an allowance; 2) it lasts one year and unused subsidy returns automatically to the government; and 3) recipients must be agricultural merchants registered with the government.

After a farmer buys fertilizer and seed from a designated merchant, they enter the merchant information registered with the government. This notifies the smart contract to use the farmer’s allowance, and it transfers the digital RMB to the merchant wallet.

If the farmer buys a Mac rather than agricultural goods, the contract has no Apple information, so funds cannot be sent to Apple.

Smart contracts therefore enable targeted subsidy use. This strengthens government control of subsidy funds and uses taxpayer money more efficiently.

Digital RMB and stablecoins

With the US GENIUS Act enacted in recent months and Hong Kong’s Stablecoins Ordinance formally taking effect, stablecoins have again created a market wave.

A stablecoin is essentially Bitcoin tied to fiat currency. For an article on Bitcoin, see:

Seven images that explain what Bitcoin looks like (in Chinese)

As crypto assets, stablecoins inherit some key Bitcoin characteristics:

Anonymity: an account is a hash value and all transactions use hashes. Even if transactions are traceable on-chain, the real owner of a hash account cannot be known.
Timeliness: transfers can complete in minutes, operate 24/7, and break traditional finance’s time and geographic barriers without waiting days for clearing.

Stablecoins are also pegged one-to-one to fiat money such as USD and HKD: when someone buys one yuan’s worth, one stablecoin is created on-chain. Compliant issuers must hold equivalent fiat reserves to ensure solvency.

Their relatively stable market value plus decentralization, anonymity, and real-time settlement have made them popular.

Globally, stablecoins have become a new arena of geopolitical finance:

For the United States, the GENIUS Act regulates stablecoins redeemable one-to-one for dollars, meaning the US has begun recognizing them. Dollar stablecoin volume may grow explosively. Their anonymity allows even countries previously sanctioned by the US, such as Russia, to trade again with other countries using dollar-based stablecoins, further strengthening dollar hegemony.
For Hong Kong, they are an outlet for China’s fund flows. Mainland trade funds, whether imports or exports, generally pass through Hong Kong. Its recognition of stablecoins further consolidates its role as a port city. HKD stablecoins can greatly increase cross-border trade-fund liquidity and lower costs.
For mainland China, digital RMB already has many stablecoin functions, such as real-time settlement, and adds programmability and central-bank backing. Mainland China is therefore unlikely to promote stablecoins. Its foreign-exchange controls also do not permit anonymous USD or HKD stablecoins to circulate domestically.

In one sentence, stablecoins are an opportunity—but across the ocean. In mainland China, it is worth watching the digital renminbi more closely.

Understanding Bitcoin and Blockchain from First Principles

Sun, 07 Sep 2025 02:36:00 GMT

Written for both technical readers and complete beginners, this article moves from decentralization and blockchain to the principles behind Bitcoin. Through explanations and questions, it aims to help everyone understand the essence and technical foundations of decentralized money.

Centralization and Decentralization

Conceptually, centralization and decentralization represent two ways of storing data and executing logic. With centralization, data such as asset records is stored in one place or institution, and logic such as transactions is executed independently by a single system. With decentralization, also called a distributed model, data such as asset information is stored across multiple peer nodes, and logic such as transactions is valid only when recognized by all nodes.

Advantages and Disadvantages of Centralized Money

Before blockchain appeared, almost every system was centralized. Note that distributed systems did exist, but they were generally controlled by a single organization and could not be extended freely to any organization or individual. A distributed database such as OceanBase is therefore still centralized.

A typical centralized application is centralized money. Backed by national credit, it is issued by each country’s central bank as a measure of wealth and a medium of exchange, and it has unlimited legal tender status. Centralized money has two advantages:

Stability. Take the US dollar issued by the Federal Reserve as an example. The Fed regulates its value, making that value relatively stable and preventing large fluctuations. When people transact in dollars, the value of goods remains within a stable range. Centralized money is also backed by national credit: as long as the country remains stable, its currency can circulate.
Risk resistance. If money is stolen through an accidental or fraudulent transaction, centralized money backed by national credit can help users recover the lost amount through tracing, recovery proceedings, and other means.

Centralization has a major weakness, however: it is vulnerable to a single point of failure. If the central bank at that single point collapses, the centralized money supported by its national credit becomes water without a source. Holders’ money may be reduced directly to zero, and the wealth it represents disappears as well. Centralized money also has the following disadvantages:

Single-point control. Because money is controlled by a centralized central bank, the money people hold can potentially be frozen by that central bank at any time. After the United States sanctioned Russia, for example, US dollars held by Russian companies in the United States and affiliated countries were frozen indefinitely without justification.
Loss of central-bank credibility. A central bank independently decides how much money to issue. If it is incompetent and makes a bad decision that results in overissuance, the ensuing inflation can drastically erode people’s wealth. The now-abandoned Zimbabwean dollar, for example, ceased to function as money because of overissuance.
Poor privacy. When centralized money is used for transactions, every payment record except small cash transactions is recorded by the central bank. This means payment data that users consider private is visible to centralized institutions. If you buy a steamed bun through Alipay in the morning, for example, the central bank can associate that transaction with your ID whenever it wishes.
Low cross-border efficiency. Centralized money is especially inefficient in cross-border transactions conducted through the SWIFT system. Different countries have different central banks, each issuing its own currency. When centralized currencies issued by different entities are exchanged, settlement passes through multiple multinational banks. More participants make cross-border remittances extremely slow and expensive.

Opportunities and Challenges of Decentralized Money

In countries whose governments enjoy very high public trust, centralized money meets the needs of 99% of people. But there will always be another 1% who are dissatisfied with the status quo and hope to address its flaws through decentralization.

With decentralized money, issuance and transactions are not dictated by one entity; they are decided collectively by all nodes that use the currency. There is no central bank, yet everyone is a central bank. If issuance and transactions require approval from a majority of community nodes, at least the following problems are addressed:

The currency can operate on nodes around the world. The failure of any single node does not affect its basic operation.
Issuance is no longer controlled by one institution or organization, reducing the risk that a single party will issue money recklessly. The amount issued must be approved by a majority of community nodes, and everyone has the right to participate.
Transactions are no longer controlled by one institution. Without agreement from a majority of community nodes, no transaction can be rejected or frozen.
Transactions run on nodes around the world. Domestic and international transactions are fundamentally the same, so cross-border payments can be more efficient than the current SWIFT system. Note that centralized money remains more efficient for domestic payments.

Judging from these problems, decentralized monetary transactions may seem far too “free” for most people. No sovereign state can accept a currency it cannot control through its central bank. An inability to control issuance means that, during a major economic crisis, the state cannot adjust the economy by increasing or reducing the money supply, as happened during the 2008 financial crisis. An inability to control transactions also allows far more illicit and underground transactions to flourish.

Furthermore, decentralization means that every full node in the community must store all transaction data. As the number of transactions grows, so does the data volume, continually increasing the storage and computing requirements imposed on community members.

What Is Blockchain?

Blockchain is one way to implement decentralized money. Combined with cryptographic techniques such as asymmetric encryption, it can implement decentralized cryptocurrency. Several misconceptions need clarification: cryptocurrency is not necessarily decentralized, and decentralized money is not necessarily cryptocurrency. Gold, for example, is a classic decentralized, non-cryptographic currency. With modern digital money, however, a lack of encryption could let A impersonate B. Bitcoin and Trump-themed meme coins, among others, are therefore both cryptocurrencies and decentralized currencies.

A blockchain consists of individual blocks. Each block has two parts: a block header containing basic information and a block body primarily containing transaction data. There are two kinds of transaction. A coinbase transaction issues currency out of thin air and transfers it to an account. A regular transfer transaction moves money from account A to account B. Every full node in the community maintains the complete blockchain.

A High-Level View of Blockchain

Technically, a blockchain is essentially a linked list. In a conventional linked list, the preceding block generally points to the next one, as shown below:

What makes a blockchain special is that the next block points back to the previous block. Instead of using a conventional memory-address pointer, it uses a hash pointer.

A hash pointer is essentially a hash value. Anyone with a computer science background knows that a hash algorithm maps a value X to another value Y through an irreversible process. A common algorithm such as SHA-256 maps an X of any size to a new, fixed-length 256-bit value Y.

When the next block b points to the preceding block a, block b is essentially recording the hash value of block a, as shown below:

One advantage is that if the contents of block a change, its hash value recorded in block b also changes. Block b then regards block a as invalid, breaking the chain. To keep the chain intact, a node storing it must alter block a and recalculate the hashes of every subsequent block, because each block’s hash depends on the preceding block. This consumes enormous computing power—for example, under PoW, the node must redo the mining validation. The technical cost is extremely high. More significantly, even after completing the changes, the node must control over 51% of the entire network’s computing power under PoW, or staked assets under PoS, to force other nodes to abandon the original valid chain and accept the altered version. The cost of such a 51% attack far exceeds any benefit from the alteration, making tampering virtually impossible.

This property of blockchain ensures that every block on the chain is tamper-resistant. That is really all there is to blockchain; nothing about it is inherently complicated. In one sentence, a blockchain is an immutable database maintained jointly by decentralized nodes (this “immutability” is not absolute; in theory, unlimited computing power could alter it, but in practice it is enough to ensure the authenticity and security of on-chain transaction records).

Why Does Decentralized Money Need Blockchain?

Before discussing blockchain further, consider why decentralized money needs it. Since one of blockchain’s major properties is immutability, the question becomes: why must decentralized money be immutable?

Trust in centralized money comes from the central bank’s backing. People believe that a central bank will honor its debts and that banks will accurately record deposits. Even if banking-system data is altered, the central bank can use its authority to trace and correct it.
Decentralized money has no central authority, and every node has equal power. Its “trust” can come only from the technical “authenticity of data.” If transaction records in a block could be altered at will—if A could secretly return a transferred 100 yuan to their own account, for example, or fabricate a transaction that takes B’s money—the entire currency system’s anchor of value would collapse instantly.

If decentralized transactions are technically immutable, then the data stored in their blocks can be trusted completely. Note that this trust is not the trust placed in a central bank under centralized money, but trust based on technical resistance to alteration.

The Relationship Among Bitcoin, Blockchain, and Ethereum

Most people have heard something about Bitcoin, blockchain, and Ethereum, but how exactly do they differ?

Simply put, Bitcoin and Ethereum are both built on blockchain and both possess the characteristics of decentralized money. Although Ethereum can store and exchange value like a currency, its more important property is support for Smart Contracts.

Ethereum makes Smart Contract-based Apps distributed. A DApp’s core logic, including transaction rules and asset ownership, can be packaged into blocks through Smart Contracts and then flooding-synced to every Ethereum node worldwide, while frontend resources may still be deployed on centralized machines. As a result, the application no longer exists on a single institution’s server under the absolute control of an App vendor, as it did in the Web2 era. It exists across all node machines, and immutable Smart Contracts prevent even the App vendor from changing rules or manipulating data midway through execution. This is Web3.

Bitcoin Based on a Blockchain Ledger

Blockchain guarantees that data cannot be tampered with. Building on that property, nodes running Bitcoin must also be capable of issuing currency, supporting valid transactions, and rejecting invalid ones—for example, when A has only 10 yuan but tries to transfer 100 yuan to B.

There are tens of thousands of Bitcoin nodes worldwide, all with equal authority. This section explores how Bitcoin uses blockchain and other specialized data structures to ensure that transactions and blocks are valid.

Asymmetric Cryptography

As mentioned earlier, Bitcoin is a cryptocurrency. We will therefore begin with some of the cryptographic algorithms involved in Bitcoin. We have already briefly discussed hash algorithms, so this section provides a short introduction to asymmetric cryptography.

Each blockchain block records a certain number of transfers. Suppose one transaction in a block transfers 10 BTC from Alice to Bob. From a cryptographic perspective, what encryption work must be done?

Consider Alice transferring money to Bob through Alipay. Before scanning the code to pay, Alice must enter a password to prove that the current Alipay account is really hers. This involves two steps: first, she sets a password in the centralized Alipay system before making the transfer; second, during the transfer, she enters that password and centralized Alipay verifies it.

Likewise, the initiator of a blockchain transaction must prove that she is Alice. First, Alice should set a password for this transaction. In blockchain, this act is called signing, just as a credit-card receipt may require a signature. When the transaction is about to be packaged into a block, the block performs the second step: verifying the signature’s authenticity.

Because Bitcoin is decentralized, individual nodes cannot store account passwords; if nodes stored those passwords, every account password would be exposed. Asymmetric cryptography makes it possible to sign and verify without revealing a password, thereby authenticating the user.

Asymmetric cryptography uses public and private keys. Readers with computer-related backgrounds likely know that HTTPS is based on asymmetric cryptography. Its simplified process is: 1) the client uses the server’s public key as the key to asymmetrically encrypt content, then transmits it to the server; 2) the server asymmetrically decrypts the content with its own private key.

From the HTTPS process, we can see that the essence of asymmetric cryptography is the one-to-one relationship between a public key, which is disclosed, and a private key, which remains secret. It has two primary scenarios: 1. Encryption: a public key encrypts data, and only the private key can decrypt it, as in HTTPS transmission; 2. Signing: the private key encrypts data such as transaction information to produce a “signature,” and anyone can use the public key to decrypt the signature and verify that the data came from the private-key holder. Together, these scenarios support Bitcoin’s transaction security.

Bitcoin Accounts

Based on these properties of asymmetric cryptography, when Alice transfers money to Bob, Alice must 1) write the transaction information; 2) sign her transaction with her private key; and 3) include her public-key information so nodes can verify the transaction signature when packaging it into a block.

We can therefore easily determine how a Bitcoin account is uniquely identified: its account credentials, analogous to a bank-account number and password, are a public-private key pair conforming to asymmetric cryptography. The public key is disclosed for receiving funds and representing the owner’s identity. The private key is kept by the user and used to sign transactions. If someone steals your private key, they can easily transfer the money from your account. Because the system is decentralized, no institution can recover the money even after someone else transfers it away.

This raises a question: how do we determine the balance of a Bitcoin account?

In a centralized banking system, a relational database such as Oracle or MySQL can store mappings between accounts and balances. When a user makes a transaction, the centralized system need only run a simple update statement. But in a decentralized system, how can we ensure that every node updates every account affected by transactions in a block? How can we ensure that account data is consistent across nodes?

This is extremely difficult. We also know that blockchain data cannot be updated once inserted because of its immutable design. An account balance therefore cannot be updated on the Bitcoin blockchain. How can it be represented?

As shown above, it can be calculated from a transaction ledger. The blockchain records every transaction, including the sender and recipient of BTC. Adding up the transaction records gives the account’s balance. This explains this section’s title: Bitcoin is a cryptocurrency based on a blockchain ledger. Ethereum is account-based and has a more complex MPT design, which is outside this article’s scope.

Blockchains, Nodes, and Accounts

The preceding section introduced Bitcoin accounts. Beginners may be confused about whether an account that initiates transactions is equivalent to a node, and whether every node must maintain a blockchain.

One point must be made clear: accounts and nodes have no necessary relationship. A node is a machine that runs the blockchain. Every node is equivalent and runs the same blockchain. Blocks in the blockchain package information about transactions between accounts. A person without any account can still run a blockchain node, although there is no reward and therefore no reason to do so.

For example, Alice has an account containing the public key PublicA and private key PrivateA. She owns a machine containing the complete blockchain. That machine is a Bitcoin node.

There is a problem: as the number of transactions grows, the complete chain requires more storage. If every node stores all information in the chain, every node needs a machine with enormous storage capacity, making Bitcoin prohibitively difficult to use. To allow even a phone to act as a blockchain node and make the system accessible to everyone, the Bitcoin protocol divides nodes into full nodes and lightweight nodes.

A full node stores all blockchain information and validates every transaction and block. Some full nodes participate in packaging blocks, or mining; these are called “miners.” A lightweight node does not store transaction details, only the header of each blockchain block. It can synchronize valid blocks from full nodes but does not write transactions.

Bitcoin’s Data Structures

The Structure of a Single Block

We now know that lightweight nodes store only blockchain block heads, while full nodes store both block heads containing metadata and block bodies containing all transaction information, as shown below. For the exact contents of a recent real block, visit OKLink:

Several details deserve emphasis. The hash pointer discussed earlier is not a hash of all the data in the preceding block. Suppose block b follows block a. Block b obtains block a’s hash through this process:

When block a is generated, all its transactions are first processed through a Merkle Tree, discussed below, to calculate the final Hash of all transactions, the Merkle root, which is written into its block header.
Block a then calculates a Hash of its complete header, including the transaction hash and the preceding block’s Hash, producing “block a’s block-header Hash.”
When block b is generated, “block a’s block-header Hash” is written directly into block b’s header, forming the chain relationship.

The Data Structure of Transactions in a Block

Besides blockchain itself, does Bitcoin use other specialized data structures?

It does. Suppose Alice transfers 10 BTC to Bob. How does Bob know that the money has reached his account? With centralized money, Bob can ask a bank. In Bitcoin’s decentralized setting, if Bob owns a full node, it can traverse all nodes to check whether a transaction says “Alice transferred 10 BTC to Bob.” But what if Bob has a lightweight node, which holds only each block’s head and no transaction information?

Bob’s lightweight node can only ask an arbitrary full node on the P2P network whether an “Alice transferred 10 BTC to Bob” transaction exists. But because Bitcoin is decentralized, no node is theoretically trustworthy. Suppose Bob’s lightweight node happens to query Alice’s full node and Alice’s node replies that the transaction exists when it actually does not. Bob has effectively been deceived.

How can this be solved? By using a Merkle Tree to maintain the structure of all transactions.

Merkle Tree

A Merkle Tree is constructed by hashing transactions in pairs, hashing the resulting hashes in pairs, and continuing recursively until a single root hash, called the Merkle root, remains. All transactions and all hashes generated during this process form a Merkle Tree, as shown below:

The diagram shows that changing a transaction’s hash propagates upward and changes the Merkle root. Because the Merkle root is included in the block header, changing it alters the block header’s hash pointer, which in turn affects every successor block. Accomplishing this is virtually impossible.

A Merkle Tree has a useful property: given some hash values, namely a Merkle path, one can verify whether a particular transaction exists. In the diagram above, if a lightweight node wants to verify that transaction TX1 exists, the full node need only provide the hash values for TX2, H(2), and H(34). The lightweight node can calculate the Merkle root and compare it with the hash in its own block header. If they match, transaction TX1 really exists.

In practice, if Bob’s lightweight node wants to verify that transaction TX has been packaged into a block by a full node, the process is:

Bob’s lightweight node asks an arbitrary full node on the P2P network to verify transaction TX. Then
That node returns the Merkle path for transaction TX to Bob. Then
Bob’s lightweight node independently calculates the “Merkle root” from “TX’s Hash + the Merkle path” and compares it with the Merkle root stored in its own block header. If they match, TX truly exists in the block; if they differ, the path returned by the full node is invalid.

Lightweight nodes omit transaction information, but still store every block header in the blockchain, and each header contains a Merkle root. Their validation process essentially compares the correct Merkle root in their own block with the root calculated from the transaction and Merkle path.

Overview of Bitcoin’s Data Structures

What exactly does each Bitcoin full node look like? How does it organize its blocks? Where is the Merkle Tree stored?

The following diagram reveals the data structures inside each full node:

(Note that the block data in every full node’s blockchain is identical.)

Bitcoin’s Consensus Mechanism

Before analyzing the details of Bitcoin transactions, we must consider how Bitcoin, the original decentralized currency, 1) enables every node to reach consensus and ensures that every node has consistent blockchain data, and 2) prevents malicious nodes from spreading invalid transactions to normal nodes.

These technical problems are solved using transaction pointers, UTXO, and a multi-node consensus protocol.

Proof of Work (PoW)

Because Bitcoin is decentralized, every node maintains a blockchain. As noted earlier, every node’s blockchain should contain identical blocks and transaction data. Yet every node is independent, so Bitcoin needs a mechanism through which every node recognizes the block data produced by one node. When node A forms its next block, all other nodes must follow that decision, abandon the blocks they were packaging themselves, and use node A’s block as the next block in their own blockchains.

When transaction volume is high, node A may package transactions a, b, and c into its block while node B packages b, d, and f into its own. Which of those two blocks should the other nodes follow? In Bitcoin, Proof of Work solves the problem of making every other node recognize a newly packaged block from one node.

When a Bitcoin node’s software generates a new block, it sets a difficulty value X. To package the block, each node must calculate the hash of its “block header,” which contains the preceding block’s hash, Merkle root, timestamp, difficulty target, nonce, and other data. The resulting hash value Y must meet the specific requirement imposed by difficulty X. Because a hash value is unpredictable, a node can only keep changing the nonce and repeatedly calculating until it obtains a value Y that meets X. Only then is the new block considered valid and eligible to be accepted by other nodes after broadcast. This process of trying different nonce values until Y satisfies X is called Proof of Work (PoW).

Every 2,016 blocks, the Bitcoin system dynamically adjusts difficulty X according to the total computing power of all nodes, keeping the average block-packaging time near ten minutes. A transaction therefore takes about ten minutes to be published to the blockchain, while confirmation requires waiting for six subsequent blocks, or roughly an hour. This cannot begin to compare with Alipay’s routinely hundreds of thousands of TPS. The process in which nodes calculate Y to package a block is called mining, and the nodes that do it are called miners.

Why Use PoW?

Some may ask why every miner should compete for the right to publish blocks through PoW’s seemingly pointless computation. It simply wastes computing power and electricity; even after the Yarlung Tsangpo dam is completed, it might not withstand consumption on this scale.

Why not use time? Why not simply follow whoever publishes a block first?

That does not work, for two reasons:

Each node can be regarded as an independent computer. When relying only on local clocks, times can differ across machines, and a node could even deliberately set its local clock ahead. Different nodes would then disagree about the latest time.
If blocks were packaged based on time, large numbers of different blocks would be published to the network during the same period, creating many forks. Yet only the longest chain can be treated as valid. Many published blocks would consequently be useless, wasting computing power and harming the Bitcoin community.

As the blockchain community has developed, Ethereum has introduced a voting mechanism that does not waste computing power, Proof of Stake (PoS). This article focuses on Bitcoin, so PoS will not be discussed further.

Why Do Miners Mine?

Why would miners waste vast amounts of computing power on mining? Are they simply overflowing with geek spirit and volunteering to package every community transaction into a block? Clearly not. To sustain a thriving community, when miners package transactions into blocks, the system rewards the first miner to calculate a nonce that meets the difficulty requirement. Besides allowing that miner to package and publish the block, it grants the miner a BTC reward.

Unlike a transfer, this reward has no input; it generates new Bitcoin “out of thin air”. This is what we commonly call a coinbase transaction. Through such transactions, Bitcoin acquires the ability to issue currency.

Bitcoin distributes a block reward about every 10 minutes, and the reward halves every 4 years, or 210,000 blocks. The current reward is 3.125 BTC per block. At Bitcoin’s current price of USD 110,000 per coin, publishing one block earns a miner USD 360,000—more than an ordinary person may earn in a lifetime.

Valid Transactions

We noted earlier that if Alice transfers 10 BTC to Bob, she must sign the transaction with her private key. Other nodes use Alice’s public key to verify it, and the transaction is valid only if verification produces the expected result.

Because Bitcoin is ledger-based and has no account concept, however, asymmetric cryptography verifies the transaction initiator’s identity but not whether the initiator has sufficient funds. Two situations require attention:

Suppose Alice previously earned a 10 BTC block reward from mining and tries to transfer 20 BTC to Bob. How does a block reject the transaction?
Suppose Alice previously earned a 10 BTC block reward from mining, already transferred 10 BTC to Bob, and later attempts to transfer another 10 BTC to Bob. How does a block reject it?

Transaction Pointers

The solution is simple. When publishing a transaction, Bitcoin requires the sender to use a hash pointer to point that transaction to the earlier transaction through which the sender obtained the Bitcoin, as shown below:

The node packaging the transaction can then easily use the hash pointer to find the transaction through which Alice obtained her BTC and validate it. “Alice transfers 20 BTC to Bob, but Alice previously received only 10 BTC” is invalid, so validation fails. This solves the first problem.

The second problem remains. Suppose Alice creates TX2 immediately after TX1 and transfers another 10 BTC to Bob, as shown below. A transaction pointer alone cannot detect this “double-spend transaction.” Nodes therefore need to maintain state recording whether the BTC output from each transaction has already been spent.

UTXO

The data structure that records whether transaction outputs have been spent is called Unspent Transaction Output (UTXO).

UTXO can be understood as a map keyed by transaction and recipient, whose value records whether another transaction has spent the current transaction’s output. In the diagram above, TX0 gives Alice a 10 BTC block reward, so the UTXO for the block containing TX0 is {'TX0:Alice': false}, indicating that TX0’s output has not been spent. Once TX1 is packaged into a block, the UTXO for the block containing TX0 becomes {'TX0:Alice': true}, indicating that TX0’s output has been spent. If TX2 later points to TX0, validation finds that TX0’s output has already been spent and classifies TX2 as invalid, so it is not packaged into a block.

Unlike the immutable blockchain, this UTXO can change. It is not part of the blockchain and does not participate in hash calculations. Nodes do not synchronize their block’s UTXO state to other nodes over the network. Instead, each node locally constructs UTXO whenever it updates its blocks. As new blocks are added, UTXO changes dynamically according to the transactions in the blockchain.

UTXO exists to help nodes validate transactions more quickly. Without it, a node trying to prevent a “double-spend transaction” would have to traverse every transaction in every block from newest to oldest. With about 910,000 blocks today, even a single traversal would impose considerable computational cost.

Valid Blocks

Transaction pointers and UTXO let a node accurately determine whether transactions are valid while packaging a block. Only valid transactions are packaged. If an abnormal node packages an invalid transaction into its block, the other nodes on the network will not recognize that block.

But if every transaction in a block is valid, will the other network nodes necessarily accept it? No. Valid transactions are only a necessary condition for a valid block. Validating a block also requires the PoW described earlier.

How to Validate a Block

After a node publishes a block to the network, other nodes verify its PoW by calculating the hash from the block header’s nonce, pre hash, Merkle root, and other fields and checking whether it meets the mining difficulty. If the Proof of Work is valid, they then validate each transaction using transaction pointers and UTXO. Only when every transaction in the block is valid do the other nodes recognize the block as valid.

Yet a valid block is not necessarily accepted by the other nodes.

Consider a node that produces a valid new block A whose transactions are also valid, but whose pre hash points to a block from several years ago, as shown below. Will other nodes accept it?

They will not. A Bitcoin blockchain may have multiple forks, and because transactions can differ across forks, multiple branches cannot all be valid. Bitcoin recognizes only one blockchain as valid: the longest one, meaning the one with the greatest accumulated work. When block A pointing to a very old block is published to the network, other nodes compare the work difficulty of block A’s chain with the accumulated work difficulty of their own local chain. If A’s chain has less work, block A is discarded without mercy. Its transactions do not achieve consensus on the Bitcoin network, and the node that produced A mined for nothing.

To avoid this, whenever a miner discovers a blockchain longer than its own on the network, it must immediately update the pre hash of the block it is packaging and recalculate the nonce and other parameters to complete PoW again.

What If Valid Blocks Are Produced Simultaneously?

Because mining is nondeterministic, two nodes may produce valid blocks with equal work at the same time, as shown below:

Other nodes will initially accept both blocks A and B because they contain the same amount of work. Due to network uncertainty, however, some nodes will mine from BLOCK A while others mine from BLOCK B. If a new block is mined after BLOCK A first, the other nodes regard the chain containing BLOCK A as the longest valid chain and discard BLOCK B. Once BLOCK B is discarded, its coinbase transaction awarding currency to the corresponding account also becomes invalid.

To prevent uncertainty over which node’s transactions to follow when two nodes produce blocks simultaneously, Bitcoin’s real-world payment rule considers transactions in BLOCK A valid only after six additional blocks have been added behind it.

Thus, Bitcoin is a consensus game decided by every node in the community, rather than a sovereignty game decided by a central institution. That may be the appeal of decentralization.

The Lifecycle of a Bitcoin Transaction

Using the consensus mechanism and Bitcoin data structures described in this article, let us reconstruct how every node in the Bitcoin network changes when “Alice transfers 10 BTC to Bob”:

A MacBook Pro Setup Guide for Developers

Fri, 15 Aug 2025 04:05:00 GMT

In the blink of an eye, I had been at the company for four years, and it replaced my old machine with a 14-inch MacBook Pro as my new master.

When I first encountered a Mac four years ago, I installed everything by clicking Next. That occasionally produced baffling environment problems: mvn could not be found, Python versions differed, and so on. With the old 13-inch MBP officially retiring, this was a good opportunity to understand macOS properly.

I also did not know where the data from all those installations was stored. I therefore used the opportunity to organize and study basic macOS concepts and operations systematically.

Readers interested only in practical setup can jump directly to the second part.

The Mac Directory Structure

Unix-like systems do not require Windows-style disk partitions, so there is no concern that excessive junk on drive C will impair the OS. When downloading on a Mac, we need not decide which disk should hold the file, reducing decision cost. Beginners should nevertheless understand the directory structure roughly.

1.1 System Directories

Ordinary use rarely touches system directories. Common examples include:

/Applications, where applications shared by all users are installed. Homebrew installs applications there by default.

The following table lists common system directories. The first four are most relevant to daily development and use.

Directory	Main purpose	Characteristics	Permissions	Common use
/Applications	System-wide applications	Shared by all users	Administrator required	Applications for every user
/bin	Basic system commands	Core executables	System protected	Basic commands such as ls, cp, mv
/Volumes	Mount points	External devices	System managed	USB and network-drive access
/opt	Third-party packages	Optional software	Administrator required	Package managers such as Homebrew
/System	Core macOS files	Protected and read-only	System protected	⚠️ Required by the OS; do not modify
/Library	System-wide libraries and configuration	Shared resources	Administrator required	Frameworks, plugins, fonts
/Users	User home directories	Contains every user’s folder	System managed	Root of user-data storage
/sbin	Administration commands	Administrator utilities	Root required	System maintenance and configuration
/usr	User programs and libraries	User-level system programs	Some actions require administrator	Programming tools and libraries
/etc	System configuration	Global configuration	Administrator required	Services and network settings
/var	Variable data	Dynamically changing files	Mixed permissions	Logs, caches, mail queues
/tmp	Temporary files	Cleared after restart	Writable by all users	Temporary storage
/dev	Device files	Hardware interfaces	System managed	Hardware-device access
/private	Private system files	Internal files	System protected	⚠️ Internal use; do not modify
/home	User-directory symbolic link	Points to /Users	System managed	Unix compatibility
/cores	Core dumps	Crash information	System generated	Debugging crashed programs

1.2 User Directories

Daily work happens mainly under /Users/$user/, so most ordinary reads and writes occur there. Like Windows, macOS recommends standard locations for user data:

Directory	Main purpose	Characteristics	Recommended use
~/Applications	Personal applications	Current user only	✅ Best location for personal applications
~/Documents	Personal documents	Main workspace	✅ Documents, projects, and code
~/Downloads	Downloads	Browser default	✅ Default downloaded-file location
~/Desktop	Desktop files	Visible on desktop	Shortcuts and temporary files
~/Library	User configuration and data	Application configuration	✅ Developer configuration files
~/Pictures	Images and photographs	Media management	Photos, screenshots, image assets
~/Movies	Video files	Video library	Personal videos
~/Music	Audio files	Music library	Music and audio

1.3 Common Configuration Files

The user home also contains important configuration files loaded when terminal sessions initialize. Nonsystem commands such as Java, Maven, and Node are commonly added to the environment through these files.

Before macOS Catalina, Bash used .bash_profile and .bashrc. They remain for compatibility, while Catalina and later recommend .zprofile and .zshrc for Zsh.

When Terminal.app opens, the system executes the login profile scripts. The detailed sequence is:

login → /etc/zshenv → ~/.zshenv → /etc/zprofile → ~/.zprofile → /etc/zshrc → ~/.zshrc → /etc/zlogin → ~/.zlogin

Broadly, .zprofile runs at login, while .zshrc runs for each new interactive terminal, including one opened inside VS Code. Put login initialization in .zprofile, and functions and aliases in .zshrc. Avoid repeatedly appending PATH or JAVA_HOME there in ways that produce a duplicated, extremely long path and slow which. GUI applications may also read .zprofile.

File	Shell	When loaded	Main purpose	Status
.zprofile	Zsh	Once at login	Login initialization and GUI environment	🟢 Recommended
.zshrc	Zsh	Every new terminal session	Interactive Zsh configuration	🟢 Main configuration file
.bash_profile	Bash	Once at login	Bash environment configuration	🟡 Retained for compatibility

To apply updated shell configuration, run:

source ~/.zshrc

1.4 Hidden Folders

The Mac user home contains many configuration folders beginning with ., generally storing settings for programs such as pyenv, Git, nvm, and VS Code:

Downloading Common Tools

As on Windows, Mac software can be installed through the App Store or packages downloaded in a browser. As a Unix-like system, macOS also offers more efficient methods.

Common Download Tools

A development Mac needs many programs without GUIs, for which browser downloads are inconvenient. Homebrew and curl are common choices. I recommend Homebrew, a Mac package manager that installs, removes, and upgrades software consistently and avoids incomplete later removal. Note that Homebrew is not designed to manage several versions of one tool simultaneously. For Python 2 and Python 3 side by side, use a specialized version manager such as pyenv, discussed below.

Scenario	Recommended tool	Reason	Storage location
Ordinary downloads	Safari/Chrome	Simple, safe, reliable	~/Downloads/, Chrome application-support and app folders
Batch or automated downloads	curl	Scriptable and customizable	Chosen with `-o`
GUI installation	App Store	Official integration	App Store support and ~/Applications
Command-line tools	Homebrew	Unified package management like apt	/opt/homebrew/

Common Homebrew Commands

# 查看Homebrew安装路径
brew --prefix

# 查看某个包的安装位置
brew --prefix <package-name>

# 清理缓存
brew cleanup

# 查看Homebrew占用空间
du -sh $(brew --prefix)

#删除缓存文件
rm -rf "$(brew --cache)"

#重新安装损坏的软件
brew reinstall git

# 查看安装的软件及版本
brew list --versions

#每日维护例程
brew update && brew upgrade && brew cleanup

#搜索并安装软件
brew search python
brew info python@3.11
brew install python@3.11

# 服务管理
brew install mysql
brew services start mysql
brew services list

When using Homebrew in mainland China, configure a domestic mirror.

Common Mac Applications

Here are useful applications and ways to install them.

Daily Use

Application	Purpose	Installation	Notes
Chrome	Primary browser	brew, browser, App Store	Main browser
Firefox	Backup browser	brew, browser, App Store	A second browser for special cases
Sogou Input	Familiar input method	brew, browser, App Store	Better memory than Apple’s, but consider privacy
WeChat	Communication	brew, browser, App Store	Two instances can run on Mac
Maccy	Clipboard	brew, GitHub	Keeps roughly fifty clipboard entries
Scroll Reverser	Mouse scrolling	Browser	Makes an external mouse scroll like Windows

Productivity Tools

Application	Purpose	Installation	Notes
iTerm2	Terminal	brew, browser	More capable than Terminal.app
Oh My Zsh	Zsh customization	GitHub	Themes, highlighting, completion, fast directory jumps
IntelliJ IDEA	Java development	Browser, JetBrains Toolbox	JetBrains JVM suite; Rainbow plugin
PyCharm	Python development	Browser, JetBrains Toolbox	JetBrains Python IDE
WebStorm	JavaScript development	Browser, JetBrains Toolbox	JetBrains web IDE
VS Code	Text editing	brew, browser	Python/JS; convenient `code xx` command
LightProxy	Proxy tool	GitHub	Development traffic monitoring
ClashX	Proxy	GitHub	Network proxy
Docker	Virtualization	brew	Both cask and CLI are available

Oh My Zsh is best used with several plugins:

Switch to the Spaceship theme; install zsh-syntax-highlighting to highlight commands; install zsh-autosuggestions for history completion; and install autojump for fast directory navigation.

Development Environment

Git with Multiple Repositories

Use SSH tools to generate two private/public key pairs and copy the public keys into the corresponding repository settings.

ssh-keygen -t rsa -b 4096 -C "wxxlamp@foxmail.com" -f ~/.ssh/id_rsa_person
ssh-keygen -t rsa -b 4096 -C "wxxlamp@work.com" -f ~/.ssh/id_rsa_work

Configure the keys in GitHub and the GitLab repository, then configure .ssh/config:

# GitHub
Host github.com
    HostName github.com
    User wxx

# 对应工作仓库
Host gitlab.work.com
    HostName gitlab.work.com
    User work
    IdentityFile ~/.ssh/id_rsa_work

Test connectivity with ssh -T@github.com.

Java and Maven Runtimes

Because Homebrew does not manage multiple versions of one application conveniently, Java, Python, and Node need specialized tools.

For the JVM ecosystem, SDKMAN can manage Java and Maven versions globally:

# 1. 安装 SDKMAN
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"

# 2. 查询并安装 Java 21
sdk list java
sdk install java 21.0.4-tem

# 3. 设为默认
sdk default java 21.0.4-tem

# 4. 安装 Maven 最新版
sdk install maven

# 5. 查看结果
sdk current

Common SDKMAN commands:

Command	Purpose	Example or note
List candidates	Supported languages and tools	`sdk list`
List versions	Versions of one candidate	`sdk list java`
Install a version	Install OpenJDK 17	`sdk install java 17.0.12`
Install latest stable	Omit the version	`sdk install maven`
Use an installed version	Current shell only	`sdk use java 21.0.4-tem`
Set default version	Global default	`sdk default java 21.0.4-tem`
Show current versions	All candidates	`sdk current`
Show one current version	Java only	`sdk current java`
Uninstall a version	Remove local copy	`sdk uninstall java 11.0.25`
Show installation path	Useful in scripts	`sdk home java 17.0.12-tem`

Python Runtime

Python has an overwhelming number of managers. macOS also ships a Python runtime at /usr/bin/python3, which is sufficient if you are not developing Python projects. Many programs require particular Python versions, however, so third-party tools manage versions and packages.

Tool	Core purpose	Scope	Typical use
venv	Lightweight virtual environments	Dependency isolation only	Simple projects; built into Python 3.3+
virtualenv	Enhanced virtual environments	Dependency isolation only	Multiple projects; Python 2/3
pyenv	Python version management	Interpreter versions only	Several Python versions side by side
conda	Environment management beyond Python	Versions, environments, packages	Data science and cross-language projects

Put simply, pyenv switches Python versions, virtualenv provides isolated dependency environments, and conda extends environment management to non-Python scientific packages.

I recommend pyenv for global Python versions and pyenv-virtualenv for virtual environments. Conda can itself be installed as a pyenv-managed environment; switch to it when a project requires non-Python packages.

These tools implement environments differently.

Pyenv first ensures that PATH points to pyenv. Setting a global version writes it to ~/.pyenv/version. Setting a local version applies only inside one folder by creating .python-version at the project root.

Activating virtualenv creates a venv directory that stores the environment’s dependencies. It uses the Python version selected by pyenv rather than copying another interpreter. A new shell must reactivate the environment.

Activating conda creates an environment directory beneath the conda installation, copies a Python interpreter there, and stores later dependencies in that directory. A new shell must reactivate it.

Common commands:

# 确认当前python的路径
which python3

#======= pyenv command
# List all installed Python versions in pyenv
pyenv versions

# Install a specific Python version (if not already installed):
pyenv install 3.11.4

# set the python system or current versions
pyenv global 3.11.4  

cd /path/to/your/project
pyenv local 3.10.8  # Creates a .python-version file in the project

#======= conda command
# 通过pyenv管理conda环境
pyenv install miniconda3-latest

# shell级别切换python版本
pyenv shell miniconda3-latest

# List all conda environments:
conda env list

# Create a new environment with a specific Python version
conda create --name myenv python=3.9 

# Activate an environment 
conda activate myenv

# 查看当前pip安装的依赖地址
pip show pip | grep Location

Node Runtime

Use nvm to manage Node versions. Installing nvm directly with curl is recommended.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
nvm install --lts     # 安装最新的 LTS 版本
nvm install 20.12.2   # 安装指定版本
nvm use 20.12.2       # 切换到指定版本
nvm current
nvm list

My 2024: Promotion, a Half Marathon, and Studying Across Hong Kong and Shenzhen

Fri, 07 Mar 2025 12:19:00 GMT

I am rather embarrassed that I write my annual review later every year. Time may be like water in a sponge—you can always squeeze some out if you try—but deadlines remain the greatest source of productivity. I did not even begin this year’s review until the end of March 2025.

The past cannot be changed, but the future can still be pursued. I hope my 2025 review will not be delayed as badly as this one.

Overall, 2024 felt fresh, fulfilling, and confusing. I entered new environments, and both my way of working and my way of learning changed. I was admitted to HKUST’s MSc program, transferred to a position in Shenzhen, and began commuting between Hong Kong and Shenzhen. Leaving behind my stable relationships and work environment in Hangzhou inevitably made the adjustment somewhat bumpy, yet I also felt eager to try what lay ahead.

Progress on My 2024 Goals

In previous years I always reviewed milestones. This year I will use a different approach with two parts: first, reviewing my progress on the goals I set for 2024, and second, listing what I actually did.

Maintain a regular schedule: get up at 8:30 a.m. and go to sleep at midnight. Spend at least one and a half hours studying and writing on weekdays, and at least six hours on weekends, unless something unusual happens. ===> 40%. Because I began studying in the second half of the year, I usually got up at 9:30 a.m. and went to bed at 2:30 a.m. Reality was completely different from the plan, so this goal fell apart. I generally did preserve the planned study and writing time on weekdays and weekends, although my actual output also fell somewhat short of expectations.
Keep exercising: six sessions of pull-ups and crunches per week, with two or three sets each time; have at least four visible abdominal muscles by year-end; and run 800 km during the year. ===> 70%. I mostly kept up the crunches and pull-ups. I had achieved the four-pack by midyear, although it disappeared again by year-end. I ran 764 km in total, slightly short of the goal.
Complete a systematic approach for handling hot spots in high-concurrency scenarios; write twelve technical blog posts. ===> 0%. I truly had wanted to organize this material because it inevitably comes up in interviews. To be honest, by the time I wrote this article, I had forgotten that I had even set this goal.
Learn iOS and Vision Pro development (tentative). ===> 0%. At the beginning of last year, Vision Pro was incredibly popular, much like DeepSeek is now. A few months later, however, it had almost vanished from view, so this goal quietly came to nothing as well.
Gain a basic understanding of China’s financial system. ===> 90%. After transferring to the global team, I became responsible for the entire transaction and fund-fulfillment chain. As a result, I passively absorbed a great deal of knowledge about finance, economics, and payments during the second half of 2024.
Read two novels (tentative). ===> 100%. I nearly finished Ming Dynasty in 1566. While reading, I even noticed some familiar historical figures and wanted to build a website showing their relationships. I had too many ideas and too little action, however, so that never happened. I also read Chen Xingjia’s At the Bend of the Jianghu and The Alleyway Families. Both were well written and resonated with me. The Alleyway Families was especially immersive in its portrayal of interpersonal conflict and family tensions, and it offered some approaches that might prove useful in resolving them.
Learn the foundations of AI and become able to use large models for basic data modeling. ===> 10%. LLMs were extremely popular, but perhaps because I was too busy, I only received knowledge about them passively and never studied them actively.
For my side project, establish a self-media presence based on knowledge creation and personal reflection, reaching 1,000 followers across all platforms this year. ===> 50%. I reached a combined total of 500 followers. The basic media matrix is now in place; the next step is to update it consistently and thoughtfully.

As you can see, I completed less than half of my 2024 goals. On one hand, this reflects my poor execution. On the other, circumstances changed so quickly that plans simply could not keep up. In the new year, I therefore need stronger feedback mechanisms so that I can adjust goals and correct course sooner.

Besides following the map laid out by my goals for 2024, I also did the following during the year:

Enrolled at HKUST and became half a university student again.
Transferred to Shenzhen, where I became responsible for global transaction and fund-fulfillment services for merchants in Europe, Asia, and the Americas.
Took the senior software engineer examination and missed passing by only a few points.

Reviewing 2024

As with last year, I can barely remember the first half of the year. Fortunately, I keep a diary and can revisit what happened. There are too many entries, though, and they are too fragmented. In the new year, besides keeping my diary, I plan to write a monthly review that records each month’s events, lets me reflect and consolidate what I learned, and gives me timely feedback for making corrections.

Perhaps because I have always worked in southern China, I have gradually learned about southern Lunar New Year customs. Celebrating the New Year in the south differs from where I grew up. Back home, we had neither a New Year’s Eve dinner nor all kinds of holiday trips and activities. For as long as I can remember, the New Year began with winter vacation: buying toy guns, ammunition, and fireworks, then running wild outdoors every day. On New Year’s Eve we would begin putting up Spring Festival couplets, and the first day of the lunar year marked the formal start of the celebration.

I mainly did two things in January 2024: applied to graduate programs at NTU and NUS, and celebrated the Spring Festival. The main thread of the holiday was much the same as before. I visited relatives to exchange New Year greetings on the first day, then spent days two through five visiting my mother’s and grandmother’s siblings and their families. In previous years I could still rest for a few days on the sixth, seventh, and eighth days. This year was different because of my younger brother. I spent those three days trying every possible connection to move him into a stronger class, but ultimately failed. And with that, January was over.

After returning to the company in February, there was essentially one major task: writing my review in preparation for the approaching performance season. I was not particularly worried because I knew I would be promoted that year. My responsibilities also expanded. I did some work involving transactions and contracts and gained a basic understanding of B2B cross-border trade.

In March I received the promotion as expected and also registered for the software qualification examination. Most significantly, I ran the first half marathon of my life and set a personal best of 1 hour and 46 minutes. I also considered how to expand my side project. I decided to begin by posting my IELTS notes on RedNote, but unsurprisingly they made little impact.

April was mainly a month of internal friction because I used my free time so inefficiently. On a weekend day, I could devote only about three hours wholeheartedly to studying or writing. I could not get up in the morning and did not want to get up in the afternoon; after exercising for a while and looking at my phone, it would already be time to go back to sleep. Alibaba generally pays its year-end bonus in April. When I checked mine, the increase was modest. It seems the Internet industry can indeed no longer be associated with rapid growth.

I began preparing for the software qualification examination in May, but ultimately fell ten points short and missed the senior software architect certificate. The second major matter was the system migration at work, which had nearly reached its closing stage. I felt that I had put real care into it. The final event determined the turning point of my entire 2024: I received an offer from HKUST. The offer arrived so late that I had originally decided not to go. After careful thought, I realized that I still dreamed of earning a master’s degree, so I decided to resign and study. The decision-making process lasted nearly a month. I asked many people and received all kinds of advice. The whole experience was genuinely painful, and I could accomplish almost nothing useful each day.

June was largely about telling friends around me that I would soon leave Alibaba to study in Hong Kong. I made all kinds of plans for going there: build a side business, learn English, find a job in Hong Kong, and so on.

July brought another turn of events. While preparing to enroll, I suddenly realized that I might be able to transfer to Shenzhen. With help from my manager and HR, I successfully rebased to the global sales team there, producing what appeared to be a win-win outcome: I could keep working and attend school at the same time. In any case, avoiding resignation was a good thing, and I began familiarizing myself with the Shenzhen team’s business. I also revived the campus-recruitment edition of my interview study guide and reorganized backend interview questions suitable for new graduates, which felt quite rewarding. Finally, I did something that shaped my entire Hong Kong–Shenzhen commuting plan: I completed the edX courses, allowing me to take three fewer courses at HKUST. That decision later proved to be a lifesaver.

After continuing July’s work and completing my edX certification, I formally rebased to Shenzhen on August 16 and began what might become a year-long stay there. The second half of August was mainly about learning how the Shenzhen office operated, renting an apartment, and visiting Hong Kong to become familiar with the university. Everything felt new.

In September I formally began commuting between Hong Kong and Shenzhen. Until the semester ended in November, I had to travel from Shenzhen to Hong Kong three times each week. Between assignments, classes, and a full-time job, I was unbelievably busy and barely wrote anything in my diary. Many interesting firsts happened during this period: my first visit to Hong Kong, my first credit card and Hong Kong bank card, my first Hong Kong identity card, and my first time looking up at residential buildings nearly one hundred stories tall. At school I learned about blockchain, but the instructor did not go very deeply and the material was not oriented toward practical applications. In addition, I found the Indian instructor’s spoken English extremely difficult to understand, so I did not pursue the subject further. Compared with my undergraduate education, I found that universities outside mainland China truly have strengths in education. First, they offer rich educational resources; even 4K displays in the library are free to use. Second, the teaching content is strong: instructors directly use perspectives from research papers as classroom material. Third, administration differs enormously from that in mainland China. Slides, recordings, and assignments are all exchanged through Canvas, and university matters are communicated by email, instead of documents flying around countless QQ groups as they do on the mainland. Because I was frequently in Hong Kong, I also passively absorbed a great deal of financial knowledge, including foreign exchange, investment, and payments. I kept around RMB 20,000 on my Hong Kong card as well. I still have one regret: classes were taught entirely in English and there were many international students, but I was too shy to express myself. My spoken English and listening ability barely improved, and even everyday communication still felt difficult.

December brought three examinations in succession. I stayed up through several nights, but in the end I earned three A grades, so graduation should not be a problem. In late December I traveled to Beijing for a team-building trip. Traveling without the pressure of examinations was wonderful.

2025 Goals

Studying in Hong Kong meant that the course of my entire 2024 did not follow the plan I had expected, but the broad outline of 2025 is still set. I hope I can complete this year’s tasks properly.

At work, organize the complete business processes and knowledge for cross-border transactions and fund fulfillment, and write one or two documents.
In development, complete a systematic approach for handling hot spots in high-concurrency scenarios, and write two to four documents.
Technically, master the foundations from ML through DL, NLP, and LLMs; use Spring AI or LangChain to build a mature product; and write one or two documents.
In education, earn my Hong Kong master’s degree.
In my career, strive to advance another level, measured specifically through performance results. With no other matters getting in the way, I need to go all in at work.
In personal finance, achieve an average annual return of 3%. More specifically, accomplish this by converting part of my funds into US dollars and placing them in fixed-term deposits.
In mindset, focus on one or two important things and stop spreading my attention. Put concrete plans into action immediately.
In daily routine, go to sleep at 12:30 a.m. and get up at 8:30 a.m.
In exercise, run 700 km this year.

Three Years at Alibaba: Personal Reflections Beyond Technology

Sun, 16 Feb 2025 12:19:00 GMT

On July 9, 2021, I joined Alibaba as a campus hire and began a journey there that has been both fascinating and meaningful.

Over these three years, I moved from the Corporate Finance Technology Department to ICBU Technology, with a stint seconded to 1688 Technology in between. Apart from the now-defunct LST business, I seem to have experienced nearly every line of business in the Binjiang campus.

I went through five managers and changed teams countless times. There were plenty of good and bad moments, and all sorts of frustrating, maddening situations. Fortunately, the experts around me helped me patiently and taught me tirelessly. They let me feel the warmth of Alibaba people, and I gained friendship, growth, and moving memories here.

There is a saying at Alibaba: “three years to become an adult.” At this point, I would like to offer a small summary. Criticism is welcome~

Working on Business and Doing Technology

“You build rockets in interviews, then tighten screws after joining.”

In today’s increasingly competitive environment, interviews have become harder and harder. HR screens résumés first: no non-985 candidates, no candidates without projects. During interviews, most Alibaba interviewers begin with a few standard theory questions, assess your ability through the projects on your résumé, and finish with some high-concurrency questions. After taking that combination punch, candidates really believe their future work will be closely tied to high concurrency and high availability. They imagine taking on tens of millions of concurrent requests and billions of users, thrilled at the thought that transaction after transaction would be completed through code in their hands.

But after joining, they discover that all the high-performance and high-availability tricks they wielded so easily in interviews have no place to be used. Instead, they get pushed around by PDs and grind through CURD. Every day, they guess at ancient business details buried in mountains of legacy code written years ago. One mistake can earn them a P-level incident, followed by a group chat and a full postmortem. A major blunder can mean an N+1 package and a direct trip back to society.

Many people join business teams and then find that the code they work with daily—perhaps under pressure from rapid business iteration, perhaps constrained by flaws in a predecessor’s design—has almost no “technical” design to speak of. Adding machines or upgrading configurations at the first sign of trouble is the most common, and perhaps the only, way to deal with so-called high concurrency.

As for high availability, the middleware platforms are already mature enough that the extreme problems mentioned in interviews are unlikely to occur. Even if they do, they fall outside the scope of business scenarios: the data volume is too small, and offline reconciliation and correction is often the usual solution.

So after joining a business technology team, I believe most campus hires, after developing business requirements for a while, either start questioning the company and sigh, “Is this all Alibaba is?”, then numb themselves and let requirements push them forward; or suffer a deeper collapse of conviction, begin doubting their original dreams, and eventually either get pushed out or leave for another field.

I belonged to the first group when I had just joined. Watching classmates around me blast through CURD tasks, I could not help feeling lost and questioning the meaning of the three years I had spent studying technology at school. I often wondered: could doing CURD every day really solve problems?

Pure CRUD certainly cannot solve problems. As I went deeper into the work, I found that things were far less simple than I had imagined. Although it is still create, read, update, and delete, the prerequisite for writing it is a substantial understanding of the business. Only by abstracting and modeling real business through technology can we write highly extensible code. As we take on more and larger requirements, the business knowledge we gain gradually becomes our own moat. Along the way, we write code that is more robust, readable, and extensible. The business knowledge we master, along with the performance and stability targets the business currently needs, all become valuable professional assets.

The biggest difference between business technology teams and pure technology teams is that they solve different problems. Business teams solve real-world business problems, while pure technology teams solve technical problems. To some extent, computer science students with formal training are more easily influenced by geek culture: they believe that after graduation they will certainly do a great deal of technology-related work. Combined with the hard-core questions asked in interviews, this raises expectations and creates a large sense of disconnect once people start working.

In a business team, a major taboo for technologists is showing off technical muscle for its own sake. Everyone wants to try new technologies and harder challenges. But if low concurrency can solve the business problem, why invite pain by tackling all the problems of high concurrency? Especially in today’s environment of operating responsibility, technology’s job is to serve the business and solve business problems at the lowest cost.

Still, knowledge is everywhere if you pay attention. Although many hard-core technologies are not useful in day-to-day business scenarios, there are plenty of opportunities to learn after joining Alibaba if you truly enjoy studying technology: read middleware source code, apply middleware design patterns, solve the strange problems you encounter every day (Maven dependency conflicts, class loading), respond to and handle production incidents, and so on. As long as you make time, even if you are tightening screws on a business team, the chance to build a rocket for the business may come if you prepare a little more.

The Courage to Borrow Arrows with a Straw Boat

While writing this article, I searched with GPT and found that introverts may account for 60% or more of programmers. This personality trait can certainly help people focus more during development, but it often also makes developers less proactive in communicating with others.

When many people first join, whether they are learning the business or developing a requirement, they feel embarrassed to ask senior colleagues when they run into problems. Some even mumble that a project is nearly done when a senior asks for progress, only for joint debugging to reveal that their code differs considerably from what the business expected.

Therefore, for campus hires, asking senior colleagues, managers, and business partners questions at appropriate times is essential to maintaining the pace of growth. Yet people often lack the courage to ask. Based on my own experience and examples around me, the usual reasons are roughly these:

They have never interacted with the person they want to consult and do not know how to start;
They worry the question is too simple and fear being laughed at or looked down on;
Everyone is busy, and they worry about disrupting the other person’s work.

Another example left a deep impression on me. A few years ago, a newly joined campus hire in the team next to ours was still working at his desk at 11 p.m. I was also dealing with a few things, and since he had not left, I went over and chatted with him. I learned that he was dealing with a very classic Spring startup issue, so I helped him solve it. Later I found out that he had already been looking at it for almost three hours. If he had found a chance to ask other classmates for help, he could have been in bed launching Genshin Impact at 11 that night.

It is not only about asking other people. Alibaba has so many technical assets. When you hit a problem, searching Yuque or ATA often gives you a 50% chance of solving it. Learning to use tools is also part of growth.

Unlike ancient times, when a household could nearly complete the entire chain from production to consumption through farming and weaving, modern society is founded on specialization and cooperation. So dealing with other people is unavoidable. Very often, our own work can only be completed by actively or passively relying on others’ help.

When new colleagues first enter the workplace, they should draw more on the strength of senior colleagues and peers. During the beginner-protection period, people are more tolerant of the things you do not know. So while you are at your most inexperienced, gain as much knowledge as you can.

When a project gets stuck, draw more on your manager’s strength. Is the business side under a tight deadline? Is a partner uncooperative? Whenever higher-level communication is involved, report to your manager and let them help drive execution from a broader perspective. But before going to your manager, do not merely throw the problem at them; offer possible solutions and an expected timeline. That way, when it comes time to fight for resources or negotiate, your manager will not be so passive.

For business development, business knowledge is one of the foundations developers must master. When you encounter business problems, draw more on the business side’s strength. Ask them about the background, possible approaches, and reasons behind an issue. Communicating more with the business side not only helps you master more business knowledge, but, from a utilitarian perspective, also lets them get to know you. As everyone becomes more familiar, gaps in later collaboration shrink and work becomes smoother.

Borrowing arrows with a straw boat requires not only courage but also wisdom. Prepare the boat before talking, and pay attention to the time and setting. Expressing gratitude afterwards is indispensable too. Whether it is a simple “thanks,” a coffee, or a meal is up to you~~~

Expectations and Project Management

Whether writing code or managing technical projects as a PM, the core is ensuring that things are delivered on time. There will always be things we do not understand along the way, so balancing unknown pitfalls and fixed delivery dates has been one of the most painful parts of being a technical PM since I joined.

If more than 30% of a project is unfamiliar to you, I recommend leaving yourself more buffer. There are two reasons. With unknown pitfalls, good luck may let you skip right over them; with bad luck, you may fall into one and be unable to get out for a week. No matter the project’s size, as its owner, we cannot let delivery time fluctuate with luck. That would leave us passive, affect the project’s external communication, and also affect frontline operations.

Leaving buffer is not only about giving yourself more time to encounter pitfalls; it also gives you more room to discuss schedules with the business side. If you begin by agreeing on a very tight deadline that can barely be met with overtime, the project will very likely be delayed. That will hurt your reputation with partners. Uncle Lu Xun once said: “Chinese people always like reconciliation and compromise. For example, if you say this room is too dark and a skylight must be opened, everyone will surely refuse; but if you advocate tearing off the roof, they will come to compromise and agree to open a window.” So if you estimate a schedule with buffer at the outset, you have plenty of room later to decide whether to tear off the roof or open a skylight.

But sometimes the schedule is not something small-P employees like us can decide. There are piles of projects that must go live before 9/30 or 3/30; every one is labeled P0 or the Nth growth curve and declared mandatory. There is no room for buffer. What should we do then?

Past experience tells me that throughout a project of continually discovering and resolving risks, any risk that is hard to solve must be synchronized with your manager. Let your manager understand the project’s progress in time and appropriately manage stakeholders’ expectations. That way, you will not give all the experts a SURPISE at every project milestone.

I remember writing a newcomer post about being a technical PM about half a year after joining. Interested readers are welcome to criticize it: Lessons from My First Technical Project Management Role

Shared Joy Is Better Than Solitary Joy

During my three years at Alibaba, I met many outstanding senior colleagues. Most of them gave me very important help during my time at Alibaba. When I asked why they would still make time to answer my questions despite being so busy, their answers were strikingly similar:

“Because I was once soaked by the rain myself, I know how painful these tedious things can be.”

“Once you understand these conceptual things, you take many fewer detours. There is no need for you to waste time on things with no value.”

I was deeply moved. To me, this is the best expression of Alibaba’s senior-junior culture. From my internship through campus recruitment, every senior colleague and manager I worked with did their best to help me land on my feet: teaching me technical principles, showing me how to learn and grow, how to manage projects, and how to control risks. I am grateful for every moment spent with them over these three years. Those days are among the most valuable treasures of my life (one of them, hahaha).

So if you have time, help new friends a little more. Before they have grown up, offer less PUA and more help within your ability. It makes you happy and everyone else happy, and little by little the team atmosphere improves and Alibaba’s culture is passed on.

And when we help them grow, is that not a form of growth for ourselves too?

Is Everything Worth Competing Over?

I joined Alibaba as an intern in 2020 and was one of the lucky undergraduate students who converted to a full-time role through campus recruitment. Internet companies expanded campus hiring heavily in 2020, 2021, and 2022. From today’s perspective, under current hiring standards, there is no way an ordinary undergraduate like me would have been hired. Campus hires in my department now start with master’s degrees and have 985 universities as a baseline. In the competition over academic credentials, I had already lost at the starting line as a developer.

If I cannot compete on academic credentials, what else can I compete on? Overtime hours? Lines of code? Or logged hours in Aone?

I think all of these are process metrics. Competing over them may comfort or ease managers’ anxiety, but it is difficult for them to solve any other problem in a meaningful way, and they do nothing to help our own growth or improvement.

Top internet companies are reservoirs of talent, and excellent people are everywhere around us: technically capable, business-savvy, and often equipped with their own ways of dealing with people and situations. As newcomers to the workplace, we should work hard on our own skills, learn from the experts around us, improve technically, learn the business, and then put what we learn into practice. We should move from imitation to surpassing it and form a loop of learning, understanding, practice, and improvement.

After gaining foundational technical and business ability, business developers should not focus only on their own small technical domain. Gradually start competing on business understanding: learn the background, development, and plans of the business you build for, and practice considering problems from a broader view. Alibaba is still tolerant of newcomers making mistakes. Campus hires can experiment quickly, keep growing, wait for opportunities, and take on greater responsibility. I once came across a good talk by Zhang Yiming:张一鸣演讲整理 (in Chinese)

Slow down a little. Give yourself some time to find one or two things you truly want to do in work and in life, then keep doing them. Do not compete over meaningless metrics. Campus hires: begin by competing with yourself.

You Hit a Pitfall—Then What?

As newcomers, when we first join there are always many things we do not understand. Some people may not even have used the development language commonly used in their department before. This is entirely normal. In the first year after joining, everyone falls into all kinds of pitfalls. I remember hitting many myself:

Batch calls from a DTS task triggered downstream alerts
An Aochuang deployment went live but did not take effect
Missing configuration for certain tenants caused an NPE, and so on

Some even caused P5 incidents. During the postmortems, my manager and senior colleagues helped me summarize the lessons, and I gained a great deal. Many people treat these as dark marks on their work record and do not want to face them. But for campus hires, the opposite is true: as long as the issue is not too serious, they are excellent chances to correct mistakes. As the saying goes, the best memory is worse than the palest ink. Like keeping a notebook of wrong answers in high school, record the pitfalls you have encountered. One day, when you encounter a similar problem for a second time, the scene of the first failure will suddenly come to mind. You can open the record, successfully avoid the pitfall, and keep moving forward.

People have a high tolerance for campus hires’ mistakes, so new colleagues must use this period to experiment and learn. When I was interning, a senior colleague gave me some suggestions during a code review, but I did not take them seriously and did not correct them. He sternly pointed out the problem with how I responded to comments and patiently taught me: “When someone helps you by pointing out mistakes in a CR, you must respond, discuss, or fix them. It shows that you value the reviewer. If you do not reply, it will be hard to get high-quality comments when you ask the same people for CR in the future.” That advice has served me well. After I formally joined, whenever a senior organized a broad CR and I received high-quality feedback, I would immediately submit a patch to fix it. The earlier a fix is made, the lower the risk of release.

At the same time, after hitting a pitfall, remember not only to avoid it yourself. If you can turn the lesson into public documentation or a knowledge base to keep others from hitting it, or fix the pitfall along the way, that is even more meritorious. (Of course, how to let others know you fixed it is an art //v//)

Understand Clearly, Explain Clearly

As programmers, we deal more with machines in day-to-day development, but communication with people is unavoidable in project management. Information entropy inevitably causes loss during transmission. So in communication, we need to use every possible way to make sure information is conveyed as correctly and completely as possible.

Communication is a skill that requires long-term practice. Two especially important points are patience and attentiveness. When listening, give your partner enough room to express themselves. Under normal circumstances, do not rush to deny or interrupt them—just as you would not want to be interrupted when speaking. What we need to do is listen carefully, note and digest the points the other person wants to express one by one. Before answering, we can also restate what the other person has just said in a few sentences to reduce the GAP between the two people as much as possible.

Likewise, when expressing your own views, try to organize them point by point. Like writing an essay, use a general-specific-general structure: state the key point at the beginning and end, with the middle explaining it in organized points. Also be sure to provide context and background. Otherwise, it is easy to confuse the recipient and create an awkward situation in which the two sides are talking past each other. This is especially true when consulting someone about a problem: if you ask only about one specific detail, they may find it hard to grasp the meaning immediately; if you explain the background clearly, communication may be much smoother.

But after all, every technique is only decoration. When your own influence is strong enough, many things resolve themselves.

Embrace Change

Embracing change is one of the New Six Veins, and no colleague is unfamiliar with it. At the company, embracing change is not merely a slogan; it is vividly reflected in action. Many people answer the organization’s call to “embrace change” every fiscal year, or even every half fiscal year, switching businesses, teams, and managers. Under organizational moves, they meet new people and take on new challenges.

As a campus hire, I initially did not feel the meaning of the word “change” very deeply. The first time I felt it was five months after I joined, when the whole group was notified that we would move to another BU. Since only the organizational relationship changed and the colleagues and manager I worked with did not, I had only an intuitive understanding of this change. The second time was in 2022, when the manager who had led me since my internship graduated from Alibaba and the entire team fell into a vortex. That time made me think. The third time was my own choice: choosing a different environment in which to continue working.

These changes left me with several thoughts:

First, many campus hires may have a misconception when they enter work: they think they must do something closely related to their major, study technology intensely, and write code. But after entering the workplace, I think this student mindset needs to shift slightly. Of course we should keep improving technically, but the core should be to focus on needs and organizational needs, and apply our technology or ability to those needs. The essence of an intermediary making money is matching supply and demand; sometimes making reports or thinking about the business is also growth.

Second, change has two sides. It means leaving your original comfort zone, but it also means facing a new environment and perhaps greater opportunities. After moving from one organization to another, discomfort and unfamiliarity are challenges we must face while first integrating. Some people may think when facing change, “Why change them instead of me?” Personally, I feel we should not assume too much malice from the organization. Perhaps we have not noticed that being moved from our original place may mean that our development there has already become constrained. So it is better to embrace this change with a more positive attitude and start again in a new field.

Third, a loss may turn out to be a blessing. Some changes may seem to cost us in the short term, but who can say what will happen in the long run? In only three years, I have seen many examples: changes that initially seemed good but later developed away from what people expected; and changes that began in utter disaster but later opened into a bright future. So when facing change, do your work well with a positive mindset, stay grounded while finding creative opportunities, and wait quietly for flowers to bloom.

We must acknowledge one fact: a business can keep running without any particular person. Most developers do not have technical ability so exceptional that it leaves everyone else in the dust. At first I naively thought, “This expert understands this technology so well—what will happen if their business changes?” After working longer, I gradually found that only when people change can things change. There is no requirement that cannot be solved by adding code, adding person-days, or doing a refactor. Though the so-called refactor may simply implement the previous feature again—you tell me, does it work or not? Hahaha.

The ability to learn is very important. When facing change, we must learn to integrate into a new environment quickly. Learn to understand the business quickly, take over unfamiliar code logic quickly, and develop your own methodology. Remember: we will never again have the happy time of a campus hire getting two full months just to familiarize ourselves with the code. The ability to deliver business requirements in unfamiliar code without creating risks, while even maintaining architectural consistency, is the foundational ability for a programmer to embrace change in the environment of our company.

In change, we must know this: no matter how the people and things around us change, the constant is always ourselves. Improving our abilities and cultivating ourselves through events is the enduring foundation amid change.

High P and Low P

I have met many P9s at work. Their basic abilities are strong, and communicating with them feels like a spring breeze. But you cannot talk deeply with them for too long: before long, you find that many like to make sweeping pronouncements about fields they do not understand well. One HR person believed that graduate students from Tsinghua and Peking University in technical roles were inferior to master’s graduates from UCL and KCL; another sales leader made many basic factual mistakes while harshly reviewing DeepSeek. So as a campus hire, do not automatically put a flattering filter on high-P people. As the saying goes: “When you are out in the world, your identity is bestowed by the company.” It is hard to say how much real ability they have. At the very least, in the field you know best, they may truly know less than you.

What I also want to say is that many high-P people today rose during the internet boom years, and their knowledge base and learning ability may no longer keep pace with the times. Many campus hires still want to copy the old path: they arrive and want a promotion, imagining P6 in two years, P7 in two years, P8 in three years, and perhaps P9 after a lucky break. Frankly, the odds are small. No matter how hard you strive, the final result may still differ greatly from your expectations, because promotion is not only about ability; luck matters a great deal too. Here are a few external factors: whether you frequently change teams, whether you meet a good manager, whether there is an opening for promotion, whether the business is growing, whether your age is appropriate, and so on.

Although a soldier who does not want to become a general is not a good soldier, organizational problems arrive once a company grows large. You may even get caught in the crossfire for no reason because of senior management policies. So sometimes, even if you work very hard, you may not get the result you want. That is entirely normal. I have seen many people with very strong business and technical abilities who did not get promoted because of various factors. As the saying goes, a grain of ash from an era becomes a mountain when it falls on a person. Keep an even mindset, let go of titles, and treat every person at the company for who they are.

Catch Rainwater and Repair the Roof

Although not everything is worth competing over, in today’s intensely competitive environment we often cannot avoid getting drawn into internal competition and numbly doing the same things over and over. The passion and courage we had when first entering work can gradually be worn away by an environment of constantly taking on passive requirements.

Sometimes, we may agonize every day over colleagues’ negative opinions; lose sleep over a small oversight at work; or become gloomy and shut ourselves off because a project is unfinished. “Hell is other people.” After working for a long time, we often fall into the evaluation system around us, becoming slaves to others’ words instead of masters of ourselves. At such times, seeking outward may be one solution.

The company’s halo and an individual’s ability are different things. Alongside internal company evaluation standards, try to use external evaluation to position yourself more accurately. In your free time, catch more rainwater and prepare for a rainy day; only then can you stay independent when the downpour comes. Looking back on the great layoffs of 2022 still makes my legs tremble with fear.

Preparing for a rainy day and repairing the roof while the weather is clear are equally necessary. When there are fewer requirements, relax physically but stay mentally alert. Learn more about competitors’ products and movements, and reflect on your strengths and weaknesses at work. Keep track of industry trends in your field, and feed them back into your business and technology. Build a more comprehensive evaluation system for yourself with a positive attitude, position yourself clearly, and improve accordingly. As an aside, large models are so popular now that every department hopes to use them to ease immediate problems, tell a new story, and paint a grand vision. If we ordinary soldiers do not understand these things and only keep doing curd, we may seem to be in a comfort zone but are actually pushing ourselves into an abyss. When an avalanche occurs, no snowflake is innocent.

The sea is wide enough for fish to leap; the sky is high enough for birds to fly.

Whatever happens, this is only a job. Becoming depressed because of work is simply not worth it. Cherish every friend around you, try to reconcile with yourself, accept what you cannot do, strive for what you can gain, face the results calmly, and be a friend to life.

When mountains and rivers seem to leave no road, beyond dark willows and bright flowers lies another village.

A New Beginning

I originally wanted to publish this article on my third anniversary, but a series of events happened in between, and the delay stretched to half a year. Still, despite procrastinating for so long, I am glad it is finally published:)

It so happens that I will attend the company’s three-year anniversary event on February 17. “What is past cannot be undone; what lies ahead can still be pursued.” With this, I commemorate my third anniversary at Alibaba and welcome new challenges here ^_^

Building and Testing a Distributed Lock

Sat, 15 Jun 2024 10:39:00 GMT

Building a Lock

Points to consider when implementing a distributed lock:

Support retries and renewal, and ensure consistency between lock acquisition and release.
What should happen if Redis cannot be reached? What should happen if a thread fails to acquire the lock?

Business Logic Around Lock Acquisition

Include business-required retries and handling for Redis connection failures and unsuccessful lock acquisition.

public static <T, R> R runWithLock(Function<T, R> function, T req, Class<? extends AssuranceSyncHandler<T,R>> clazz,
                                       int expiredSec, String... factors) {
    AssuranceSyncHandler<T, R> zedSynchronizedHandler = getSyncHandlerFromClazz(clazz);
    ZedBody zedBody = buildBody(req, expiredSec, factors);
    // 尝试加锁
    boolean lockSuc = tryLock(zedBody, zedSynchronizedHandler);
    // 如果没加锁成功，则按照配置策略进行重试
    if (!lockSuc && !retryLock(zedBody, zedSynchronizedHandler)) {
        LOGGER.info("thread can not get lock, retry times is {}", zedSynchronizedHandler.getRetryTimes());
        // 如果缓存不可用，则直接执行业务逻辑
        if (SmartZedThreadLocal.isSynchronizedLockInvalid()) {
            LOGGER.error("lock failed because of the system error, so func apply directly");
            SmartZedThreadLocal.clear(zedBody.getRowKey());
            return function.apply(req);
        }
        // 如果缓存可用，则执行自定义锁策略
        return zedSynchronizedHandler.strategyWhenSync(req);
    }

    R result;
    try {
        result = function.apply(req);
    } catch (Exception ex) {
        LOGGER.error("AssuranceLockUtils.runWithLock error when apply func", ex);
        throw ex;
    } finally {
        tryUnLock(zedBody);
    }
    return result;
}

@SuppressWarnings("unchecked")
private static <T, R> AssuranceSyncHandler<T, R> getSyncHandlerFromClazz(Class<? extends AssuranceSyncHandler<T,R>> clazz) {
    return Optional.ofNullable(clazz)
            .map(ApplicationContextUtil::getBean)
            // 此处加map是为了把子类转成父类
            .map(e -> (AssuranceSyncHandler<T, R>)e)
            .orElse((AssuranceSyncHandler<T, R>)defaultHandler);
}

private static boolean retryLock(ZedBody zedBody, AssuranceSyncHandler<?,?> handler) {
    int retryTimes = 0;
    boolean lockSuc = false;
    while(!lockSuc && handler.getRetryTimes() > retryTimes++) {
        lockSuc = tryLock(zedBody, handler);
    }
    return lockSuc;
}

Internal Lock Acquisition

Control the granularity of the internal lock, and consider what happens if releasing either of the two locks fails.
An internal lock may not be necessary. With low contention, each call can acquire the Redis lock anyway, so adding a local lock reduces performance. Consider an internal lock when contention on a single machine is high.

 private static boolean tryLock(ZedBody zedBody, AssuranceSyncHandler<?,?> zedSynchronizedHandler) {
    boolean ans = false;
    boolean innerTryLock = false;
    try {
        innerTryLock = LocalLockHolder.tryLock(zedBody.getRowKey(), zedSynchronizedHandler.getRetryInterval());
        if (innerTryLock) {
            ans = assuranceSyncService.lock(zedBody);
        }
    } catch (Throwable e) {
        LOGGER.error("AssuranceLockUtils.runWithLock error", e);
    } finally {
        // 如果外部锁没加成功，则释放内部锁
        if (!ans && innerTryLock) {
            LocalLockHolder.unlock(zedBody.getRowKey());
        }
    }
    return ans;
}

private static void tryUnLock(ZedBody zedBody) {
    try {
        LocalLockHolder.unlock(zedBody.getRowKey());
        assuranceSyncService.unLock(zedBody);
    } catch (Throwable e) {
        LOGGER.error("AssuranceLockUtils.runWithUnLock error", e);
    }
}

private static class LocalLockHolder {
    private static final Map<String, Lock> LOCK_MAP = new ConcurrentHashMap<>();

    public static boolean tryLock(String key, long timeout) throws InterruptedException {
        Lock lock = LOCK_MAP.computeIfAbsent(key, k -> new ReentrantLock());
        return lock.tryLock(timeout, TimeUnit.MILLISECONDS);
    }

    public static void unlock(String key) {
        Lock lock = LOCK_MAP.get(key);
        if (lock != null) {
            lock.unlock();
        }
        LOCK_MAP.remove(key);
    }
}

Core Locking Logic

Include support for reentrant locking.

public Boolean lock(ZedBody zedBody) {
    // 1. 竞争锁
    boolean suc = syncService.set(zedBody.getRowKey(), getValue(), zedBody.getTimeout(), () -> {
        // 如果redis没有连接上，则不加锁
        SmartZedThreadLocal.markSynchronizedLockInvalid(true);
        return null;
    });
    if (suc || isOwnLock(zedBody)) {
        // 增加引用次数
        int count = increaseCount(zedBody.getRowKey());
        LOGGER.info("lock suc key:{},threadId:{}, count {}", zedBody.getRowKey(), Thread.currentThread().getId(), count);
        return true;
    }
    return false;
}

@Override
public Boolean unLock(ZedBody zedBody) {
    int lockCount = threadLocal.get().getByKeyWithDefault(zedBody.getRowKey()).count.get();
    LOGGER.info("un lock start key:{},threadId:{},count:{}", zedBody.getRowKey(),
            Thread.currentThread().getId(), lockCount);
    // 1. 如果引用计数已经小于0，则失效缓存
    if (decreaseCount(zedBody.getRowKey()) <= 0) {
        return syncService.del(zedBody.getRowKey());
    }
    return true;
}

private int increaseCount(String key) {
    LockCounterHolder counterHolder = threadLocal.get();
    return counterHolder.increaseWithKey(key);
}

private int decreaseCount(String key) {
    LockCounterHolder counterHolder = threadLocal.get();
    return counterHolder.decreaseWithKey(key);
}

private boolean isOwnLock(ZedBody zedBody) {
    String s = syncService.get(zedBody.getRowKey());
    return StringUtils.equals(s, getValue());
}

private String getValue() {
    return LOCAL_HOSTNAME + ":" + Thread.currentThread().getId();
}

private static String getHostname() {
    try {
        return InetAddress.getLocalHost().getHostName();
    } catch (UnknownHostException e) {
        LOGGER.warn("Failed to get hostname", e);
        return "[unknown]";
    }
}

private static class LockCounterHolder {

    private final Map<String, LockCounter> counters = new HashMap<>();

    public LockCounter getByKeyWithDefault(String key) {
        return counters.computeIfAbsent(key, e -> new LockCounter());
    }

    public int increaseWithKey(String key) {
        LockCounter counter = getByKeyWithDefault(key);
        return counter.count.incrementAndGet();
    }

    public int decreaseWithKey(String key) {
        LockCounter counter = counters.get(key);
        // 防止非持有锁的线程释放锁
        if (counter == null) {
            throw new ZedSynchronizedException("key is not found when release. key=" + key);
        }
        int count = counter.count.decrementAndGet();

        if (count <= 0) {
            //如果count 小于0，删除key，避免内存泄漏
            counters.remove(key);
        }
        return count;
    }
}

private static class LockCounter {

    private final AtomicInteger count;

    public LockCounter() {
        this.count = new AtomicInteger(0);
    }
}

Redis Connection Logic

Include retries when a Redis connection cannot be established.

public boolean set(String key, String value, int expireTimeSec) {
    int connectTime = 0;
    String v = null;
    SetParams setParams = new SetParams().nx().ex(expireTimeSec);
    while (Objects.isNull(v)) {
        try (Jedis jedis = jedisPool.getResource()) {
            v = jedis.set(PREFIX + key, value, setParams);
            return StringUtils.equals(SUCCESS, v);
        } catch (Exception e) {
            LOGGER.error("rdb3 setNx error key:{} value:{}", key, value, e);
            if (connectTime++ >= RECONNECT_TIMES) {
                LOGGER.error("rdb3 retry {} times setNx error key:{} value:{}", RECONNECT_TIMES, key, value, e);
                throw e;
            }
        }
    }
    return StringUtils.equals(SUCCESS, v);
}

Testing the Lock

Given the distributed lock above, how should I write unit tests on one machine to verify its correctness?

First Version

My first test looked like this:

@Test
public void testLockSync() throws InterruptedException {
    // 1. 第一个线程抢占到锁，睡眠
    new Thread(() -> {
        String res = AssuranceLockUtils.runWithLock((req) -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "test";
        }, null, 10, "test");
        Assert.assertEqual("test", res);
    }).start();
    // 2. 第二个线程尝试抢占锁，应该失败
    new Thread(() -> {
        try {
            AssuranceLockUtils.runWithLock((req) -> "test", null, 10, "test");
        } catch (Exception exception) {
            Assert.assertTrue(exception instanceOf ZedSynchronizedException);
        }
    }).start();
}

Sharp-eyed readers may immediately spot the problem: the main thread cannot observe the test results. Two things are necessary to fix this. First, pass the worker threads’ results to the main thread. Second, ensure the main thread checks them after the worker threads have finished. Common approaches include CountDownLatch, BlockingQueue, and shared memory.

Second Version

I therefore tried this second version:

@Test
public void testLockSync() throws InterruptedException {
    CountDownLatch latch = new CountDownLatch(2);
    AtomicReference<String> firstThreadAns = new AtomicReference<>();
    AtomicReference<Exception> secondThreadAns = new AtomicReference<>();
    // 1. 第一个线程抢占到锁，睡眠
    new Thread(() -> {
        firstThreadAns.set(AssuranceLockUtils.runWithLock((req) -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                latch.countDown();
            }
            return "test";
        }, null, 10, "test"));
    }).start();
    // 2. 第二个线程尝试抢占锁，应该失败
    new Thread(() -> {
        try {
            AssuranceLockUtils.runWithLock((req) -> "test", null, 10, "test");
        } catch (Exception exception) {
            secondThreadAns.set(exception);
        } finally {
            latch.countDown();
        }
    }).start();
    // 3. 主线程check结果
    latch.await();
    Assert.assertEquals("test", firstThreadAns.get());
    Assert.assertTrue(secondThreadAns.get() instanceof ZedSynchronizedException);
}

Running this test exposes several failure cases:

The assertion on line 31 fails because firstThreadAns.get() == null. The worker calls latch.countDown() prematurely on line 14. The main thread starts checking before the worker has passed its result back.
The main thread waits forever, preventing the program from finishing. The second thread runs first, so the first thread fails to acquire the lock and throws an exception without calling latch.countDown(). The main thread remains pending. The solution is straightforward: ensure the first test thread reaches the required point before the second. A Semaphore, CountDownLatch, or lock can do this, but note that Thread.join() is unsuitable here.

Third Version

@Test
public void testLockSync() throws InterruptedException {
    CountDownLatch latch = new CountDownLatch(2);
    Semaphore semaphore = new Semaphore(0);
    AtomicReference<String> firstThreadAns = new AtomicReference<>();
    AtomicReference<Exception> secondThreadAns = new AtomicReference<>();
    // 1. 第一个线程抢占到锁，睡眠
    new Thread(() -> {
        firstThreadAns.set(AssuranceLockUtils.runWithLock((req) -> {
            req.release();
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "test";
        }, semaphore, 10, "test"));
        latch.countDown();
    }).start();
    // 2. 第二个线程尝试抢占锁，应该失败
    new Thread(() -> {
        try {
            semaphore.acquire();
            AssuranceLockUtils.runWithLock((req) -> "test", null, 10, "test");
        } catch (Exception exception) {
            secondThreadAns.set(exception);
        } finally {
            latch.countDown();
        }
    }).start();
    // 3. 主线程check结果
    latch.await();
    Assert.assertEquals("test", firstThreadAns.get());
    Assert.assertTrue(secondThreadAns.get() instanceof ZedSynchronizedException);
}

Perfect.

Handling Hot Reads and Writes

Sun, 09 Jul 2023 02:36:00 GMT

We will use a flash-sale scenario throughout: skuId, skuContent, and skuStore.

Hot Reads

Hot reads mean that skuContent must be displayed for a skuId. Since the database IO connection pool is fixed, the amount of data the database can handle is limited, so hot data needs to be synchronized to Redis.

Cache Consistency

Deletion is preferable to updating, because updating is not an atomic operation.
If the cache is deleted first, then the database is updated and the cache is written back, inconsistency can occur during the write.
Therefore, use a delayed double-deletion strategy.

Handling Hot Caches

The basic approach is to warm hot data in advance so requests do not hit the database directly. If traffic is so large that even Redis cannot handle it, consider these measures:

Shard large keys. For example, hash skuId into different keys using a consistent-hash algorithm and store them in Redis.
Use multi-level caches: keep one copy in the browser, CDN, local cache, and Redis.
Make requests in stages. For example, request the relevant hot data as soon as the user starts loading, so there is no need to request it again when the page is actually entered.

Hot Writes

When a skuId becomes hot, database updates become a major problem too. Updating the database directly may produce a very high RT, because under the RC isolation level the row for that skuId is locked. The following approaches can be considered:

Distribute SKUs across different databases and decrement inventory there.
Decrement inventory in Redis, then send a message through Redis to the database for the decrement.
Write transaction details directly, then update inventory asynchronously from those details (the update must query the sum of the details).
Apply rate limiting at the application layer by skuId to prevent requests from reaching the database.
Create a hot-data database and move hot products into it.

Note: use optimistic locking to ensure consistency when deducting inventory.

Handling Message Idempotency in Queue Consumers

Sun, 07 May 2023 02:36:00 GMT

Recently, while integrating with another business, I found a problem:

When consuming messages from an upstream business, an unusual upstream situation caused multiple messages to be sent at the same time (status-change messages, with the status changing several times in one moment). Since the consumer had no idempotency protection, it consumed the messages repeatedly. In this case, that resulted in two rows being inserted.

How do we solve it? It is actually simple: lock the conflicting resource. There are several approaches.

Approach 1: Distributed lock

Add a distributed lock to the current consumption logic by user.
If it has already been consumed, do not consume it again.
If it has not been consumed, consume it.

The pseudocode is:

public void consume(Message msg) {
	String id = msg.getId();
	RedisLock.acquire(id, msg -> {
        Record record = db.query(msg);
        if(record != null) {
            return;
        }
        process(msg);
    });
}

Approach 2: Database unique index

Most current Web services are deployed as clusters, so a lock must be distributed. Although databases may use sharding, for the same shard key a record from one consumption will always land in one physical database and one physical table.
We can therefore use a unique index on the single physical database and let the database provide the lock. If insertion fails, simply catch an exception such as Duplicate entry.

Approach 3: Special SQL statements

These essentially also depend on a unique index.

insert ignore

insert ignore ignores data already present in the database (determined by the primary key or unique index). If no data exists, it inserts a new row; if data exists, it skips the row.

 insert ignore into sc (name,class,score) values ('张三','三年二班',90)

Running the statement produces no error, but the primary key still auto-increments.

replace into

replace into first attempts to insert data into the table. If the row already exists (determined by the primary key or unique index), it first deletes the row and then inserts a new one; otherwise it inserts a new row directly.

replace into sc (name,class,score) values ('张三','三年二班',90);

insert on duplicate key update

If on duplicate key update is specified at the end of an insert into statement and inserting the row would create a duplicate value in a UNIQUE index or PRIMARY KEY, the duplicate row is updated. If there is no duplicate, a new row is inserted as with an ordinary insert into.
If a new row is inserted, the affected-row count is 1; if an existing row is updated, it is 2; if the value is unchanged before and after the update, it is 0.

insert into sc (name,class,score) values ('张三','三年二班',90) on duplicate key update score=100;

Approach 4: Transaction + exclusive lock

InnoDB reads use MVCC, so an ordinary select does not block. We can use a database transaction to lock during the query. Other queries are then blocked, and we insert if nothing is found. The SQL is:

select * from c where name = '张三' for update;

Approach 4 resembles approach 1, except approach 1 locks at the service level while this approach uses a database lock. The following examples use the RR isolation level.

The relationship between indexes and locks

Primary-key index

Start a transaction with an indexed where condition:

begin;
select * from article where id = 3 for update ;

The lock state is:

Both the table and row are locked: the table has an intention-exclusive lock, and the row has a standard exclusive lock (only the record, not the gap). Therefore, another transaction attempting an exclusive-lock SQL statement will fail:

select * from article where id = 3 for update ;
update article set name='ck' where id = 3;

PS, the purpose of an intention lock:
Without an intention lock, obtaining an exclusive table lock would require traversing every record to check whether any record had an exclusive lock, which would be slow.
With an intention lock, an intention-exclusive table lock is added before an exclusive record lock. When obtaining an exclusive table lock, we can simply check whether the table has an intention-exclusive lock. If it does, records in the table already have exclusive locks, so there is no need to traverse them.
Therefore, the purpose of an intention lock is to quickly determine whether any record in a table is locked.

No index

Start a transaction with the following condition:

begin;
select * from article where author_id = 1 for update ;

The lock state is:

We can see that the table also has an intention-exclusive lock. However, every record receives a fully exclusive lock (locking both the row and the gap), effectively locking the entire table. This is dangerous because other transactions cannot perform locking operations on the table.

Locking when there is no match

For a case without an index, the locking logic is the same as for a match. Here we look at how locking works when there is an index but no match.

begin;
select * from article where id = 3 for update ;

The lock state is:

The row receives a fully exclusive lock covering the range from 3 to positive infinity. Nothing can be inserted or updated between 3 and positive infinity.

primary key value(s) of the locked record if LOCK_TYPE=’RECORD’, otherwise NULL. This column contains the value(s) of the primary key column(s) in the locked row, formatted as a valid SQL string (ready to be copied to SQL commands). If there is no primary key then the InnoDB internal unique row ID number is used. If a gap lock is taken for key values or ranges above the largest value in the index, LOCK_DATA reports “supremum pseudo-record”. When the page containing the locked record is not in the buffer pool (in the case that it was paged out to disk while the lock was held), InnoDB does not fetch the page from disk, to avoid unnecessary disk operations. Instead, LOCK_DATA is set to NULL

References

Sperm Donation: The Process and Personal Reflections

Fri, 05 May 2023 02:36:00 GMT

Why Donate Sperm

The Standard Answer

As the environment worsens and people adopt increasingly unhealthy lifestyles, the number of families facing infertility is growing rapidly. Today, one in every eight couples of childbearing age in China has a fertility problem. Some men cannot produce qualified sperm, while others have genetic diseases that prevent them from having children. They need sperm from healthy men to help solve their fertility problems, creating a major demand for sperm donation. These families often suffer greatly because they cannot have children. In that sense, sperm donation is a noble humanitarian act, as honorable as donating blood or bone marrow!

The Real Answer

Pure curiosity; the possibility of storing sperm for future use; and the subsidy.

Requirements

The requirements are extremely strict. The basic requirements are:

But if those were the only requirements, sperm banks in China would not be short of sperm. There are further hidden requirements during screening:

Volume must exceed 2 ml.
Concentration must exceed 60 million/ml (below 15 million/ml is oligospermia).
Motility (straight-line movement, generally indicators a+b) must exceed 60% (below 30% is asthenospermia).
More than 30% must have normal morphology.

Procedure

Zhejiang Province is used as an example below. Information is available through the WeChat public account Zhejiang Human Sperm Bank.

Make an appointment on the website (in Chinese).

Go directly to the second floor of Zhejiang Maternal and Child Health Hospital to donate:

Subsidies

If unsuccessful

Blood type measurement
A 50-yuan subsidy

If successful

Free sperm storage for 30 years
Free blood tests for HIV, syphilis, and other diseases

PS: If someone referred you, the referrer also receives 100 yuan.

Reflections

One third of 2023 had already passed. More than 1,200 people had applied to donate at the Zhejiang sperm bank, but only 25% qualified. As far as I know, qualified programmers are even rarer.

Men’s sperm quality in China really is declining. A recent report (in Chinese) found a sharp decline: the average number of sperm per milliliter fell from around 130 million in 2005 to 67 million in 2015. The average percentage of progressively motile sperm fell from 56.5% to 51.6%. The report notes that sperm-bank donors are generally healthier than the general population, so these figures may still exceed the public average. Sperm concentration and motility are directly related to the probability of conception; fewer than 20 million sperm per milliliter is oligospermia, and progressive motility below 32% is asthenospermia. If the trend continues, the outlook is worrying.

Apart from objective factors such as radiation, the main influences I know of are staying up late, stress, prolonged sitting, drinking, and smoking. What a miserable list—these factors seem tailor-made for programmers.

To maintain good sperm quality:

Do moderate aerobic exercise. Scientists say at least three 30-minute aerobic sessions per week can increase sperm count, although the improvement is temporary and returns to its original state within a month after stopping. Excessively intense exercise can also damage sperm quality. Source: Reproduction.
Sleep seven to eight hours every night. Compared with eight hours, men sleeping under six or over nine hours have a 42% lower chance of conception in any given month. Source: Boston University School of Public Health.
Eat healthily. Eat foods rich in vitamins D and C, zinc, selenium, and folate, such as nuts, tomatoes, oranges, eggs, fish, poultry, milk, leafy vegetables, beans, blueberries, pomegranates, and dark chocolate.
Drink fewer soft and energy drinks. Men who drink at least one soft drink daily are 33% less likely to successfully conceive with their partners. Source: Epidemiology.
Do not keep your phone in your trouser pocket. Compared with a control group, men who often do so had 8% lower sperm survival and progressive motility. Source: Environment International.
Wear boxer briefs. Harvard research found that men who regularly wear boxer briefs have higher sperm concentration and total sperm counts than men who do not. Avoiding overly tight trousers follows the same principle.

Finally, according to the study Effects of Seasonal Factors on Semen Quality among Sperm Donors in Beijing, spring is the best season for sperm donation.

Troubleshooting a MetaQ Consumer Backlog

Tue, 25 Apr 2023 13:36:00 GMT

Note: MetaQ is an internal Alibaba product whose open-source version is called RocketMQ.

Symptoms

For special reasons, one application in the business I owned needed its messaging configuration changed from Spring Cloud Stream to native MetaQ. The configurations before and after the change were:

spring.cloud.stream.bindings.consumerA.group=CID_CONSUMER_A
spring.cloud.stream.bindings.consumerA.contentType=text/plain
spring.cloud.stream.bindings.consumerA.destination=CONSUMER_A_TOPIC
spring.cloud.stream.metaq.bindings.consumerA.consumer.tags=CONSUMER_A_TOPIC_TAG

spring.cloud.stream.bindings.consumerB.group=CID_CONSUMER_A
spring.cloud.stream.bindings.consumerB.contentType=text/plain
spring.cloud.stream.bindings.consumerB.destination=CONSUMER_B_TOPIC
spring.cloud.stream.metaq.bindings.consumerB.consumer.tags=CONSUMER_B_TOPIC_TAG

spring.cloud.stream.bindings.consumerC.group=CID_CONSUMER_A
spring.cloud.stream.bindings.consumerC.contentType=text/plain
spring.cloud.stream.bindings.consumerC.destination=CONSUMER_C_TOPIC
spring.cloud.stream.metaq.bindings.consumerC.consumer.tags=CONSUMER_C_TOPIC_TAG

spring.metaq.consumers[0].consumer-group=CID_CONSUMER_A
spring.metaq.consumers[0].topic=CONSUMER_A_TOPIC
spring.metaq.consumers[0].sub-expression=CONSUMER_A_TOPIC_TAG
spring.metaq.consumers[0].message-listener-ref=consumerAListener

spring.cloud.stream.bindings.consumerB.group=CID_CONSUMER_A
spring.cloud.stream.bindings.consumerB.contentType=text/plain
spring.cloud.stream.bindings.consumerB.destination=CONSUMER_B_TOPIC
spring.cloud.stream.metaq.bindings.consumerB.consumer.tags=CONSUMER_B_TOPIC_TAG

spring.cloud.stream.bindings.consumerC.group=CID_CONSUMER_A
spring.cloud.stream.bindings.consumerC.contentType=text/plain
spring.cloud.stream.bindings.consumerC.destination=CONSUMER_C_TOPIC
spring.cloud.stream.metaq.bindings.consumerC.consumer.tags=CONSUMER_C_TOPIC_TAG

When half the machines had been deployed and we began observing the canary rollout, messages started accumulating:

Cause

Inconsistent Message Subscriptions

Based on past experience, I suspected that machines in the consumer group had inconsistent subscription relationships. Some subscribed to A and others to B, so MetaQ could not determine whether to consume the messages and left them accumulating on the broker. The MetaQ console confirmed that inconsistent subscriptions had caused the backlog.

The subscription on the deployed machine was:

The undeployed machine had the following subscriptions, clearly more than the deployed machine:

Spring Cloud Stream and Native MetaQ

This raised another question: why did the subscriptions for the same ConsumerId change after replacing Spring Cloud Stream with native MetaQ?

More simply, when MetaQ and Spring Cloud Stream used the same ConsumerId, why did MetaQ’s subscriptions overwrite Spring Cloud Stream’s subscriptions?

Note: one consumerId can subscribe to multiple topics.

The only way to answer this was to inspect the startup source code of Spring Cloud Stream and MetaQ.

MetaQ

The MetaQ client’s class diagram is shown below:

MQConsumerInner records how the current consumerGroup interacts with the server and maps topics to tags. Its default implementation is DefaultMQPushConsumerImpl, with a one-to-one relationship to consumerGroup.
MQClientInstance centrally manages reusable objects such as network connections. A map maintains the relationship between ConsumerGroupId and MQConsumerInner. Put simply, one ConsumerGroup can correspond to only one MQConsumerInner, as shown below:

Spring Cloud Stream

Spring Cloud Stream is a glue layer between Spring and middleware. When it starts, it also registers a ConsumerGroup, as shown below:

Root Cause

At this point, the cause is clear. During startup, Spring Cloud Stream creates its own MetaPushConsumer, which is effectively a new MQConsumerInner. One ConsumerGroup therefore has two MQConsumerInner instances, violating MetaQ’s required one-to-one mapping. By default, MetaQ replaces the old mapping with the new one. The native MetaQ consumer consequently replaces Spring Cloud Stream’s consumer.

That is why, for ConsumerA on deployed machines, only the native MetaQ subscription remained.

Solution

Change the consumer ID:

spring.metaq.consumers[0].consumer-group=CID_CONSUMER_A
spring.metaq.consumers[0].topic=CONSUMER_A_TOPIC
spring.metaq.consumers[0].sub-expression=CONSUMER_A_TOPIC_TAG
spring.metaq.consumers[0].message-listener-ref=consumerAListener

spring.cloud.stream.bindings.consumerB.group=CID_CONSUMER_B
spring.cloud.stream.bindings.consumerB.contentType=text/plain
spring.cloud.stream.bindings.consumerB.destination=CONSUMER_B_TOPIC
spring.cloud.stream.metaq.bindings.consumerB.consumer.tags=CONSUMER_B_TOPIC_TAG

spring.cloud.stream.bindings.consumerC.group=CID_CONSUMER_B
spring.cloud.stream.bindings.consumerC.contentType=text/plain
spring.cloud.stream.bindings.consumerC.destination=CONSUMER_C_TOPIC
spring.cloud.stream.metaq.bindings.consumerC.consumer.tags=CONSUMER_C_TOPIC_TAG

Reflections and Summary

The cause was not complicated, but many people might stop at the first layer—an inconsistent subscription relationship caused the backlog. We still need the curiosity to investigate more deeply.
Avoid maintaining two sets of configuration in production wherever possible, because doing so adds cognitive overhead.