Post-Training Chinese LLMs: Advances in Coding Agents, 3D Script Generation, and Financial Reasoning

1. The Engineering Value of Post-Training

Recent enhanced releases from Chinese LLM providers have pushed “post-training” back into the spotlight. Post-training refers to improving a fully pre-trained base model through supervised fine-tuning, preference alignment, reinforcement learning, and domain data injection, with the goal of boosting performance on targeted tasks. Compared with training from scratch, it offers controllable costs, short iteration cycles, and the ability to deepen capability in vertical domains such as code, 3D modeling, and financial analysis—without degrading general abilities.

From an engineering perspective, a successful post-training iteration typically involves:

1. Data mix design: determine the ratio of general instructions, domain corpora, and synthetic data to avoid catastrophic forgetting;
2. Reward modeling: build verifiable reward signals along dimensions such as code executability, geometric validity, and numerical consistency;
3. Reinforcement learning strategy: follow the RLVR (reinforcement learning with verifiable rewards) approach so the model receives feedback in real execution environments;
4. Safety and hallucination suppression: use stress-test suites and abstention policies to drive factual error rates down.

Run this pipeline well, and the model shows significant jumps across multiple benchmarks—which gives us something concrete to discuss.

2. Coding Capability: Terminal Tasks and Cost Control

For coding agents, the real test of whether a model can “do the work” is no longer single-function completion, but whether it can complete multi-step tasks in a terminal environment—reading error messages, editing files, running commands, and verifying results. The terminal-style benchmarks commonly used in the industry are designed around exactly this chain.

Public evaluation data shows that enhanced Chinese models now score in the top tier on terminal-based coding tasks, with the gap to leading international frontier models narrowed to single-digit percentage points. What deserves even more attention is cost: at comparable task completion rates, the inference cost per task (token consumption × unit price) has become the deciding metric for enterprise adoption. Some lightweight versions have lower unit prices, but their completion rates on complex tasks are low enough that they actually raise the “cost per successful task.”

Takeaways for developers:

• Don’t look at unit price alone: calculate the “average cost per completed task” rather than the price per million tokens;
• Segment by task difficulty: use lightweight models for simple script generation, and stronger models for multi-step debugging and long-context refactoring;
• Add caching and batching: for repetitive code review and formatting tasks, cache hits can cut overhead.

A schematic cost-per-success calculation looks like this:

def cost_per_success(model, tasks):
    total_cost = 0
    success = 0
    for t in tasks:
        tokens = model.run(t)          # returns tokens consumed
        ok = model.verify(t)           # executable verification
        total_cost += tokens * model.price
        success += int(ok)
    return total_cost / max(success, 1)

Only when “success rate” and “cost” enter the same formula does model selection become a meaningful engineering decision.

3. 3D Modeling: From MCP Dependencies to Direct Script Writing

3D content creation has long suffered from a structural mismatch: general-purpose LLMs don’t understand geometric semantics, while professional tools depend on complex plugin protocols. Early solutions exposed modeling software capabilities to the model through middleware layers such as the Model Context Protocol (MCP), but those pipelines were long, hard to debug, and slow.

The new approach is to let the model write modeling scripts directly. Mainstream 3D tools expose Python script interfaces, so a model only needs to generate code that conforms to the API conventions to handle asset assembly, material assignment, geometry adjustments, and layout. The advantages of this “direct script writing” mode:

• Reproducible: a script is an asset, and it can be version-controlled;
• Parametric: generation is parameterized—change one variable to batch-produce variants;
• Verifiable: whether a script executes successfully is a natural verifiable reward signal.

Public demonstrations show these capabilities covering tasks such as interior scene assembly, mechanical structure modeling, and lamp industrial design. The technical crux is the model’s understanding of spatial coordinates, boolean operations, and hierarchical transforms—which requires injecting large amounts of execution-feedback script data during post-training.

A typical parametric modeling script looks like this:

import bpy
def build_lamp(height=0.4, shade_radius=0.15):
    bpy.ops.mesh.primitive_cylinder_add(radius=0.02, depth=height)
    base = bpy.context.object
    bpy.ops.mesh.primitive_cone_add(radius1=shade_radius, depth=0.2)
    shade = bpy.context.object
    shade.location.z = height / 2 + 0.1
    return base, shade

To generate usable scripts, the model must understand concepts like location, radius, and parent-child hierarchies. This is why spatial reasoning has become a key dimension in 3D modeling evaluations.

For teams that want to validate 3D ideas quickly, general-purpose cloud compute and object storage can be used to manage generated model files and preview videos in one place, with online preview supporting collaborative review—closing the loop from generation to preview, export, and printing.

4. Financial Document Reasoning: Retrieval, Cross-Checking, and Multi-Step Calculation

Financial scenarios demand something very different from creative ones: not divergence, but accuracy, traceability, and verifiability. Typical tasks include extracting key metrics from financial report PDFs, reconciling definitions across multiple documents, and performing multi-step numerical reasoning that follows an investment logic.

Three difficulties stand out:

1. Complex layouts: tables spanning pages, nested footnotes, inconsistent units;
2. Definitional variance: the same metric is defined differently in different documents;
3. Multi-step dependency: each calculation step depends on previous extraction results, so errors accumulate.

Benchmarks for this capability therefore cover the full chain of “retrieval—cross-document checking—multi-step numerical reasoning.” Top-performing models tend to have strong long-context localization and numerical consistency constraints. Hallucination suppression is also a headline metric: in internal stress tests, cutting error rates from above 20% to below 10% means the model prefers to abstain or flag uncertainty rather than fabricate numbers.

Engineering recommendations:

• Mandatory citations: require the model to output the source page or paragraph for every number;
• Cross-validation: extract key metrics twice with two independent prompts and compare the results;
• Numerical sandbox: hand computation steps to deterministic code execution; the model only extracts and orchestrates.

5. Security and Hallucination Governance

Expanded capability comes with an expanded risk surface. Code execution, script generation, and terminal operation can all be abused if left unchecked, so post-training must strengthen safety alignment in parallel:

• Dangerous command detection: intercept or require confirmation for destructive, privilege-escalating, or outbound-network operations;
• Script sandboxing: run all generated scripts in isolated environments with restricted file system and network access;
• Hallucination governance: monitor error rates continuously with stress-test suites, and track abstention rate and accuracy on the same dashboard.

Hallucination governance is not a one-off project but an ongoing operation. Build an internal evaluation set covering factual QA, numerical computation, and code executability, and run regression tests after every model iteration so that capability gains don’t come with an error-rate rebound.

6. Summary and Selection Advice

Overall, Chinese LLMs have reached production-ready usability in coding agents, 3D script generation, and financial document reasoning through the post-training route, with some metrics in the top tier and standout cost control. For developers and enterprise users:

1. Select models by task tier: use strong models for high-complexity tasks and lightweight models for bulk simple ones;
2. Make “cost per successful task” the core metric: don’t be misled by unit price;
3. Prefer scriptable, verifiable capabilities: direct script writing is easier to debug and reproduce than middleware protocols;
4. Build security and hallucination governance into your workflow: sandboxed execution, mandatory citations, and regression testing are all essential;
5. Leverage general-purpose cloud services: object storage, container sandboxes, and logging/monitoring can significantly reduce integration costs.

The technology curve keeps accelerating. Real competitive advantage lies not in chasing a specific version number, but in embedding model capabilities reliably into your own engineering pipeline.