The Evolution of LLM Post-Training and 3D Script Generation Practices

I. From Base Models to Post-Training: The Logic of Capability Leap

The iteration of large language model (LLM) capabilities has gradually shifted from a pre-training competition focused on scaling parameters and data to refining specific capabilities centered around post-training. Post-training refers to the process of applying supervised fine-tuning, preference alignment, reinforcement learning, and tool-calling trajectory distillation on top of a pre-trained base model to enhance its performance in specific task domains.

This approach has become mainstream for three primary reasons:

1. Higher Marginal Returns: The compute cost of pre-training scales exponentially, whereas targeted post-training can yield significant improvements in specific dimensions at a much lower cost.
2. Clear Task Orientation: Domains such as coding, mathematics, finance, and spatial reasoning each have distinct evaluation metrics. Post-training allows for directed optimization around these frameworks.
3. High Engineering Controllability: Data ratios, reward design, and evaluation loops during the post-training phase can be finely tuned, enabling rapid iteration.

A recent upgraded version released by a domestic LLM team is the product of large-scale post-training on a base model. The capability enhancements are not isolated breakthroughs but cover multiple dimensions, including coding, 3D modeling, financial analysis, hallucination suppression, and security research. This comprehensive elevation reflects the maturity of their post-training pipeline.

II. Coding Capabilities: Terminal Tasks and Cost Efficiency

In coding capability evaluations, Terminal Bench has gained significant attention in recent years. It does not merely test function completion; rather, it evaluates a model’s comprehensive ability to perform multi-step operations, read/write files, invoke tools, and troubleshoot errors within a real command-line environment. Because these tasks closely resemble a developer’s daily workflow, their reference value is exceptionally high.

According to public benchmark data, leading domestic models have entered the first tier in terminal coding tasks, trailing only a few top-tier closed-source models while surpassing some peer competitors. More noteworthy is cost efficiency: for equivalent tasks, the unit cost of this model ranks among the best in frontier models. For enterprise users, this means significantly lower inference costs in scenarios like batch code generation and automated script writing.

From an engineering perspective, benchmark scores are merely a reference. True deployment depends on three factors:

• Task Pass Rate: Whether it can generate runnable, syntax-error-free code in a single pass.
• Context Retention: Whether it remembers interface conventions and file structures across multi-turn interactions.
• Tool Synergy: Whether it can correctly invoke external commands, read/write files, and handle exceptions.

These three capabilities determine whether a model is a toy or a genuine productivity tool.

III. Direct 3D Modeling Script Generation: From MCP Dependency to Native Scripts

The most imaginative aspect of this capability upgrade is the direct script writing capability in the 3D modeling domain.

Traditionally, enabling an LLM to operate professional 3D modeling software requires intermediate protocols like MCP (Model Context Protocol). The modeling software’s capabilities are encapsulated into tool interfaces, which the model then calls. The issue with this approach is a long dependency chain, difficult debugging, and tight coupling with the modeling software’s version and plugin ecosystem.

The new generation model’s capability lies in bypassing intermediate protocols to directly write native scripts for modeling software. This handles asset setup, geometric detailing, layout adjustments, and material configuration. This is technically supported by the model’s deep mastery of modeling script languages (like Python script interfaces) and its spatial reasoning capabilities regarding 3D relationships.

Public demos show that these capabilities can already achieve:

• Forest vegetation modeling and spatial layout for interior scenes;
• Parametric modeling of mechanical structures (e.g., vortex engines);
• Modeling consumer-grade products like 3D-printable desk lamps.

In tool-dependent modeling benchmarks, this model’s scores approach those of top-tier closed-source models, making it one of the best-performing open-source models available.

3.1 Technical Key Points of Direct Script Writing

To ensure a model stably generates usable modeling scripts, several key issues must be resolved:

First, API Semantic Alignment. A modeling software’s script interface typically contains hundreds of functions and parameters. The model must understand the semantics, parameter types, return values, and calling sequence of each function. This requires the post-training data to contain a massive amount of “natural language description → script code” paired samples.

Second, Spatial Reasoning Capability. 3D modeling is not simple code concatenation; it requires understanding object position, rotation, scaling, boolean operations, and topological relationships. The model must maintain spatial consistency when generating scripts to avoid geometric intersections and flipped normals.

Third, Executability Validation. Generated scripts must actually run in the target software. Therefore, the post-training stage typically introduces an execution feedback loop: generate script → execute in sandbox → capture errors → correct code. This “execution-driven” training method is crucial for improving script usability.

Below is an illustrative modeling script structure (pseudo-code representing the logic):

# Illustration: Parametric modeling script structure
def build_scene(params):
    # 1. Initialize scene
    scene = init_scene(unit_scale=params.unit)
    # 2. Create base geometry
    base = create_primitive(
        type="cube",
        size=(params.length, params.width, params.height),
        location=(0, 0, 0)
    )
    # 3. Apply bevel and subdivision
    base = apply_bevel(base, width=params.bevel, segments=3)
    base = apply_subdivision(base, levels=2)
    # 4. Material and texture
    mat = create_material(
        base_color=params.color,
        roughness=params.roughness,
        metallic=params.metallic
    )
    assign_material(base, mat)
    # 5. Export and print check
    validate_mesh(base, min_thickness=0.8)
    export_mesh(base, path=params.output)

This pseudo-code illustrates that the model needs to understand the complete pipeline of “parameters → geometry → material → validation → export,” rather than generating isolated lines of code.

3.2 Engineering Value of Online Preview and Editing

The accompanying online 3D feature allows users to preview and edit models online, supporting exports for 3D printing or exporting videos and dynamic photos for sharing. The engineering value of this pipeline includes:

• Lowering the Barrier: Non-professional modelers can generate editable 3D assets via natural language;
• Shortening the Loop: The time from idea to a printable model is drastically compressed;
• Facilitating Collaboration: Model files can be shared directly, reducing format conversion costs.

For developers, this means 3D generation capabilities can be embedded into their own product workflows, such as e-commerce product display, educational courseware creation, and game prototype design.

IV. Financial Document Reasoning: Retrieval, Reconciliation, and Multi-step Numerical Calculation

The financial domain is the touchstone for testing a model’s “rigor.” Relevant evaluations typically assess three types of capabilities:

1. Complex Financial Data Analysis: Extracting key metrics from real financial reports and announcements;
2. Cross-document Reconciliation: Comparing data consistency across different files;
3. Multi-step Numerical Reasoning: Completing calculations and deriving conclusions based on extracted data.

On such benchmarks, this model achieved leading scores, proving the effectiveness of its post-training in long-document understanding, table parsing, and numerical calculation pipelines. In another evaluation assessing a complete investment workflow (from target screening to profitability analysis), the model showed significant improvement over its predecessor, ranking in the first tier.

For developers, deployment scenarios for these capabilities include intelligent investment research assistants, automated financial report summarization, and risk metric monitoring. The key is implementing citation tracing—every number provided by the model should correspond to its original location in the text, otherwise, it cannot be trusted in financial contexts.

V. Hallucination Suppression and Security Research: The Underlying Guarantee of Credibility

Hallucination is one of the biggest obstacles to LLM deployment. In internal stress tests, the model’s error rate dropped significantly from 23.4% in the previous generation to 8.3%, trailing only a few top-tier models. This indicates substantial work on factual consistency during the post-training phase.

Common hallucination suppression methods include:

• Retrieval Augmentation: Forcing the model to answer based on retrieved evidence;
• Refusal Training: Teaching the model to say “I don’t know” to uncertain questions;
• Consistency Validation: Multi-sampling the same question to detect answer conflicts;
• Citation Constraints: Requiring the model to output verifiable source snippets.

Regarding cybersecurity capabilities, official observations note that as post-training scales, the model’s vulnerability research capabilities continuously improve. This is a double-edged sword: it can be used for automated code auditing and vulnerability mining, but it also requires accompanying safety guardrails to prevent abuse. Developers integrating such capabilities should establish input/output auditing, privilege isolation, and rate-limiting mechanisms.

VI. Practical Recommendations for Developers

Based on the capability profile above, here are several deployment recommendations:

First, Select by Task Domain. Do not use one model for everything. Coding tasks, financial documents, and 3D modeling have vastly different requirements. It is recommended to conduct A/B testing by scenario and choose the solution with the highest pass rate per unit cost.

Second, Establish an Evaluation Loop. General benchmarks are only for initial screening. What truly determines success or failure is a proprietary evaluation set. It is recommended to collect real task samples and build automated regression tests.

Third, Emphasize Execution Feedback. For code and script generation, always execute in a sandbox and capture errors. Use the execution results as input for secondary correction, rather than blindly trusting the model output.

Fourth, Control Costs. In batch tasks, prioritize models with better cost efficiency; escalate to stronger models only for high-difficulty tasks, forming a tiered routing strategy.

Fifth, Ensure Security and Compliance. Establish strict permission and auditing mechanisms for scenarios involving vulnerability research, financial data, and user privacy.

VII. Conclusion

From the perspective of post-training technology, domestic LLMs are transitioning from “single-point catch-up” to “systematic capability building.” The simultaneous improvement in coding, direct 3D script writing, financial reasoning, and hallucination suppression reflects the overall maturity of data pipelines, reward design, and evaluation loops. For developers, the key is not chasing a specific benchmark score but understanding the technical principles behind these capabilities and translating them into deployable, verifiable, and cost-controllable engineering solutions. The emergence of direct 3D modeling script writing is particularly noteworthy—it could mark the starting point of the next efficiency leap in creative toolchains.