Post-Training Evolution in Chinese LLMs: From Code Agents to 3D Content Generation

In recent years, LLM capability growth has shifted from a “pre-training scale race” toward “post-training refinement.” Two demanding task categories offer a useful lens for observing this shift: code intelligence and 3D content generation. The former tests a model’s reasoning chains, tool orchestration, and engineering reliability. The latter tests spatial understanding, geometric operations, and the ability to generate scripts for professional software. This article traces this evolution from a technical perspective, discussing how post-training enhances capabilities, what evaluation dimensions actually mean, and how script-based 3D creation may reshape the boundaries of content production.

Why Post-Training Has Become the Critical Stage for Capability Gains

Pre-training gives a model its general language and knowledge foundation. Post-training determines whether that model is actually “usable” on specific task distributions. For professional scenarios such as coding and 3D modeling, post-training typically involves several layers:

1. Task alignment: Converging general capabilities into clear input-output paradigms. For example, given a terminal environment and a goal, the model must plan command sequences, read feedback, and correct errors autonomously.
2. Trajectory learning: Using high-quality expert operation trajectories to teach the model “multi-step decision-making” rather than single-turn Q&A. This is critical for stability on long-horizon tasks.
3. Tool calling and script generation: The model must understand not only “what to do” but also “how to do it” — whether to call an existing tool API or write an executable script directly.
4. Cost and efficiency constraints: In real-world engineering, token consumption and turn count per task directly determine usability. Post-training therefore also incorporates optimization for inference efficiency.

These layers explain why the same base model can show significant differences on specific benchmarks after targeted post-training. Improved benchmark scores ultimately reflect progress in the compound capability of “multi-step reasoning + environment interaction + self-correction.”

Code Agents: Evaluating Capability and Cost on Terminal Tasks

Terminal-based tasks, such as those in terminal benchmarks, serve as a practical test for code agent engineering ability. They require a model to complete multi-step operations in a real or simulated command-line environment, including file system operations, dependency management, compilation and builds, test execution, and error diagnosis. Compared with traditional function-level code completion, these tasks are much closer to a developer’s actual workflow.

When evaluating this type of capability, three dimensions deserve attention:

• Task completion rate: Can the model reach the target state within a limited number of turns, rather than giving up midway or getting stuck in a loop?
• Process reliability: Are the commands reproducible and idempotent? Can the model adjust its strategy based on error messages after a failure?
• Per-task cost: How many calls and tokens are required to complete the same task? A model with strong cost control tends to plan more “compactly” and reduces unproductive trial and error.

From an engineering perspective, cost is often underestimated. A model that scores slightly higher on a benchmark but consumes several times more resources is not economical for large-scale automation. The combined evaluation of “performance and cost” therefore reflects real-world value better than a single score. The continued optimization of Chinese models on this dimension suggests that post-training objectives have shifted from chasing leaderboard scores to building practical usability.

A simplified agent loop structure looks like this:

# Pseudocode: basic loop for a terminal task agent
state = init_env(task)
for step in range(max_steps):
    action = model.plan(state, history)
    observation = env.execute(action)
    history.append((action, observation))
    if env.is_goal_reached(state):
        break
    state = model.reflect(state, observation)

The key part of this structure is the reflect step: the model must self-correct based on environmental feedback. The quality of post-training largely determines whether this reflection step actually works.

3D Content Generation: From Tool Calling to Direct Script Writing

3D modeling is another capability-intensive scenario. Traditionally, models generate 3D content through two paths: calling encapsulated modeling APIs, commonly seen in tool-calling protocols, or outputting structured scene descriptions that a rendering engine then parses. The former is limited by API coverage, while the latter is constrained by expressiveness.

Writing scripts directly for professional modeling software is a more generalizable path. In a typical 3D creation workflow, a model can generate scripts to perform the following operations:

• Asset setup: Create base geometry through scripts, adjust topology and subdivision.
• Materials and appearance: Configure shader parameters, texture paths, and node connections.
• Layout and transformation: Batch-set object positions, rotations, scales, and hierarchical relationships.
• Refinement and modification: Generate variants based on parametric logic, or make batch adjustments to existing scenes.

The advantage of this approach is that scripts are readable, versionable, and reusable assets. What the model produces can directly enter a production pipeline, rather than remaining at a “demo-level” output. It also reduces dependence on specific tool-calling protocols — as long as the target software supports a scripting interface, the model can interact with it through code.

This path also introduces new challenges:

1. API knowledge accuracy: Scripts must conform to the target software’s interface specifications. Errors in parameter names or call order will cause immediate execution failures.
2. Verifiability of spatial reasoning: The correctness of geometry and layout is difficult to judge automatically through text alone. It often requires rendering feedback or structured validation.
3. Stability of long scripts: The longer the script, the higher the probability of accumulated local errors. Models need the ability to generate in segments and perform self-checks.

Evaluating 3D script generation therefore typically requires both “tool-assisted” and “pure script” settings. The former measures the model’s upper bound in an assisted environment, while the latter measures its ability to complete complex orchestration independently. From an industry perspective, progress in open-source models on this front is narrowing the gap with closed-source frontier solutions — a positive signal for the creative tools ecosystem.

Practical Implications for Creators and Developers

If script-based 3D creation continues to mature, it may bring several changes:

• Reduced repetitive work: Tasks such as batch layout, parametric variants, and scene migration can be automated through scripts, allowing creators to focus on creative decisions.
• Improved pipeline automation: Model-generated scripts can be embedded into build processes and connected with asset management and rendering orchestration.
• Shifting skill requirements: The ability to “describe requirements and validate results” becomes more important, while reliance on purely manual operations decreases.

For developers, the more practical takeaway is this: when evaluating such models, build your own small-scale task set covering typical long-horizon scenarios, and track completion rates and costs instead of relying solely on public leaderboards. Leaderboards reflect capability under a specific distribution, while engineering deployment requires alignment with your own business distribution.

Conclusion

From terminal task performance in code agents to direct script writing for 3D content, post-training is pushing large language models from “knowing how to answer” toward “knowing how to operate.” The joint optimization of performance and cost, and the complementarity between tool calling and script generation, form the main technical threads of this stage. For enterprises and developers, understanding the evaluation logic and engineering constraints behind these capabilities offers more long-term value than chasing scores from any single release.