Post-Training in a Domestic LLM: Breakthroughs in Visual Aesthetics and Coding

1. From Base Release to Post-Training Re-Production: A Compressed Evolutionary Timeline

Over the past year, the focus of competition among open-source LLMs has been shifting. Early contests centered on parameter scale and pretraining data volume, but trends from the past six months indicate that the key variable determining a model’s real productivity has shifted from “how large the base is” to “how deep the post-training goes.” A typical observation sample is a domestic flagship model family that completed two iterations within just over a hundred days: first establishing the scale ceiling of the open-source camp with a super-large parameter base, then—rather than continuing to stack parameters—investing nearly a hundred days in reinforcement learning post-training, delivering a “.1” version with comprehensive leaps in general intelligence, visual aesthetics, and coding benchmarks.

The timeline itself is worth reviewing, because it reveals a pragmatic engineering rhythm:

• Phase 1: Base breakthrough. Entering with a super-large open-source parameter base, the focus was on validating underlying capabilities such as compute scheduling, operator optimization, compilation, and inference efficiency, establishing technical credibility in geek-oriented scenarios. But the shortcomings of this phase were equally obvious—on terminal-type benchmarks that test real command-line fundamentals, the first-generation version showed a clear generational gap versus top closed-source models, indicating that “being able to write code” and “being able to complete tasks in a real environment” are two different capabilities.
• Phase 2: Toolchain outer-loop refinement. Beyond the model itself, the intelligent coding client and general-purpose workbench were iterated rapidly in parallel, continuously filling in capabilities such as sandbox execution, terminal access, browser toolchains, visual annotation, and long-horizon task planning. The significance of this step: model capabilities need to be “caught” by the toolchain, otherwise even the strongest reasoning cannot be converted into deliverable productivity.
• Phase 3: Post-training inner-loop re-production. Joint reinforcement learning covering over a hundred domains was conducted on the base, lasting 99 days. The output of this phase is not “a bigger model” but “a model that is better at doing things.”

The formula summarizing this evolution in one sentence: New-generation flagship = full-power base skeleton + multi-domain joint RL re-production + significantly lowered invocation cost. The third item deserves particular attention—capabilities improved while price actually dropped, which runs counter to the conventional business logic of “capabilities for premium pricing” and is closer to an engineering approach of “amortizing unit intelligence cost through post-training efficiency.”

2. Unpacking the Upgrade: Why the “.1” Version May Be a Generational Leap

Many vendors’ “.1” versions are merely routine fine-tuning, with changes concentrated in data mix ratios and a small amount of alignment. But the version tested here has a scorecard closer to a generational leap. This leap can be understood from three dimensions.

2.1 The Jump in the Composite Intelligence Index

In third-party blind-test composite intelligence evaluations, this version improved by approximately 11 points over the first generation, entering the global top tier. It should be emphasized that improvements in the composite intelligence index are not linear additions but exhibit a clear “threshold effect”: each point gained above the passing line often reflects synchronized improvement in multiple sub-capabilities such as reasoning chain stability, long-context consistency, and instruction-following robustness. An 11-point leap means the model’s “collapse rate” on complex multi-step reasoning tasks has dropped significantly—a prerequisite for whether Agent-type applications can be deployed.

2.2 Differentiated Advantage in Visual Aesthetics

The most surprising finding in testing was its performance on visual aesthetics-related tasks. In dimensions that lean “subjective”—3D scene generation, frontend page layout, color schemes, and typography—this version demonstrates noticeably better stability than competitors at the same price point. This deserves elaboration.

Traditionally, code generation capability and visual aesthetics capability have been viewed as two relatively independent abilities: the former relies on logic and syntax constraints, the latter on implicit modeling of design conventions. Frontend and 3D generation happen to be the intersection of the two—the model must not only write code that runs but write code that “looks right.” This requires the model to have been exposed to large amounts of real design mockups and corresponding implementation code during training, and to establish a mapping from visual intent to code structure. The introduction of visual feedback signals during post-training (for example, preference scoring of rendered results) is likely the source of this capability leap.

2.3 Substantive Surpassal on Coding Benchmarks

Surpassal on coding benchmarks needs to be viewed in layers. Metrics such as syntax correctness rate and unit test pass rate have long converged among leading models; what truly separates them is task completion rate in real engineering environments, such as multi-file refactoring, dependency management, error localization, and repair. The first-generation version’s low scores on terminal-type benchmarks exposed exactly this layer’s shortcomings. The post-training version’s improvement in this dimension indicates that interactive environment feedback introduced during the RL phase (execution results, error messages, tool-call success or failure) was effectively utilized, and the model began to learn the “trial—observe—revise” loop rather than single-shot generation.

3. Breaking Down Test Dimensions: Real Productivity Boundaries Across Three Task Types

To avoid broad generalities, the following breaks down test observations by task type and provides reusable evaluation methods.

3.1 3D and Frontend Visual Generation: From “Runs” to “Looks Right”

Task setup: Given a natural language description, generate a frontend page including layout, color scheme, and interaction states, plus an interactive 3D scene.

Observations:

• At the layout level, the model handles grid systems, spacing rhythm, and responsive breakpoints fairly stably, with fewer instances of element overlap or overflow.
• At the color level, the model can follow style constraints in the description (e.g., “low saturation, cool tones, high-contrast accent color”) and maintain consistent color semantics across multiple components.
• At the 3D scene level, the model’s default choices for common properties such as camera parameters, light direction, and material roughness are reasonable, and the generated results are noticeably better at “first-glance impression” than same-price solutions.

Code illustration (typical structure generated by the model, simplified):

// Scene initialization: the model tends to establish reasonable defaults for camera and lighting first
const scene = new Scene();
const camera = new PerspectiveCamera(45, aspect, 0.1, 1000);
camera.position.set(0, 2, 6);
const keyLight = new DirectionalLight(0xffffff, 1.2);
keyLight.position.set(5, 10, 7);
scene.add(keyLight);
// Material parameters: the model infers roughness and metalness from the description
const material = new MeshStandardMaterial({
  color: 0x3a6ea5,
  roughness: 0.65,
  metalness: 0.1
});

Boundary note: The visual aesthetics advantage is stable within “common design paradigms,” but on highly customized brand visuals or complex interaction animations, manual intervention is still needed. The model is better at “reasonable” than “stunningly original.”

3.2 Coding Tasks: Real Experience Beyond Benchmark Scores

Task setup: Three categories—single-file algorithm problems, multi-file small project refactoring, and dependency conflict troubleshooting.

Observations:

• Single-file tasks: high completion rate, fairly comprehensive boundary condition coverage, but the gap versus other leading models is not obvious.
• Multi-file refactoring: the model can maintain cross-file symbol consistency, with good control over the scope of changes and fewer cascading errors of “fix one place, break three others.”
• Dependency troubleshooting: the model can locate specific dependency version conflicts based on error messages and provide executable repair steps—this capability is directly related to the toolchain’s terminal access capability.

Methodology recommendation: When evaluating coding capability, prioritize constructing tasks with execution feedback rather than only looking at the static quality of generated code. The following evaluation framework can be referenced:

# Simplified task evaluation loop (illustrative)
def evaluate_task(model, task, sandbox):
    plan = model.plan(task)                 # Planning phase
    patch = model.generate_patch(plan)      # Generate changes
    result = sandbox.apply_and_test(patch)  # Real execution
    if not result.passed:
        feedback = result.error_log
        patch = model.revise(patch, feedback)  # Revise based on feedback
    return result

The key to this loop is “real execution,” which is closer to the production environment than any static benchmark.

3.3 Cost Structure: What One-Fifth the Price Means

Invocation cost reduced to roughly one-fifth of comparable-capability solutions means more than “cheap.” For developers, it directly changes the economic constraints of application design:

• More trial-and-error rounds affordable: Agent-type applications naturally require multi-turn interaction; lower per-round cost means retry strategies and self-correction counts can be relaxed.
• Longer contexts coverable: Long document processing, full repository understanding, and similar scenarios shift from “occasional” to “routine.”
• Deployable to more edge scenarios: High-frequency, low-value tasks such as batch code review and automated test generation become economically viable.

It should be objectively noted that low cost does not equal low latency or high throughput; actual selection should still be comprehensively evaluated in light of concurrency requirements and quota policies.

4. Engineering Deployment Recommendations: How to Make Good Use of a “Post-Training-Reinforced” Model

Based on test experience, four actionable practice recommendations are provided.

First, design the toolchain as part of the model’s capability. The closed-loop capabilities reinforced by post-training need to be supported by sandboxes, terminals, browsers, and other tools. If only plain-text invocation is used, the model’s “good at doing things” advantage cannot be unleashed.

Second, use execution feedback to drive prompt design. Rather than pursuing a one-shot perfect prompt, design a “generate—execute—revise” loop and explicitly tell the model in the prompt what verification means are available.

Third, establish a manual acceptance checklist for visual tasks. Models with strong aesthetics can easily cause people to relax acceptance standards; it is recommended to establish fixed check items for layout consistency, accessibility, and responsive behavior, to avoid “looks good” masking engineering defects.

Fourth, cost advantages should be converted into architectural elasticity. Where cost permits, multi-model parallel generation with voting, or a generate—review dual-role collaboration pattern, can be adopted to trade redundancy for stability—something difficult to achieve when per-round cost is high.

5. Conclusion: The Competitive Logic of the Post-Training Era

The core conclusions of this test can be summarized in three points: First, parameter scale is no longer the sole moat; the depth and quality of post-training are becoming the main engine of capability leaps; second, visual aesthetics and coding capability are not mutually exclusive—they combine in frontend and 3D scenarios to form a differentiated productivity advantage; third, cost structure optimization occurs simultaneously with capability improvement, indicating that unit intelligence cost still has considerable room to decline.

For developers, this means the selection approach needs adjustment: from “looking at leaderboard scores” to “looking at task closed-loop completion rate,” from “comparing parameters” to “comparing toolchain synergy.” For the industry, the real value of this round of post-training competition lies not in any single version’s ranking but in the fact that it validates a replicable engineering path—using reinforcement learning to convert base capabilities into deliverable productivity. The maturity of this path will determine whether LLMs can move from “impressive demos” to “reliable everyday use.”