The Evolution of LLM Vertical Capabilities: Terminal Coding, Direct 3D Scripting, and Financial Reasoning

Introduction

The main theme of the large model industry is shifting gears. Over the past two years, the competition was about “who answers more intelligently.” Now, it is about “who executes more thoroughly.” Models must not only provide conclusions in a dialog box but also run tasks in the terminal, produce usable assets in modeling software, and complete verification and calculations across piles of financial documents. Recently, a batch of models undergoing deep post-training has made simultaneous progress in these three directions. The gap between the open-source community and closed-source frontier models has significantly narrowed, and “capability parity” is becoming a perceivable reality rather than just a slogan.

This article is not a single product review. Instead, it abstracts these three major directions into general technical problems: what their capability forms look like, how to evaluate them scientifically, how to implement them in engineering, and where the pitfalls lie. Hopefully, after reading this, you can establish your own framework for model selection and integration.

1. Post-Training Determines Capability Depth

Base models provide “general knowledge,” while the leap in vertical capabilities mainly comes from the post-training phase. Supervised fine-tuning injects domain paradigms, and reinforcement learning based on human feedback and verifiable rewards teaches the model to “get things done.” This is especially true for tasks with clear verification signals, such as coding—whether compilation passes or tests pass serves as objective feedback. With clear reward signals, the return on investment for reinforcement learning is extremely high. This explains why recent model updates have shown significant progress in terminal tasks, parametric modeling, and numerical reasoning: it is not that the base model scale has increased dramatically, but rather that the training objectives are closer to “execution results” rather than “text similarity.”

The implication for developers is direct: when evaluating a new model, do not just look at general leaderboards. Look at the depth of post-training on your specific task forms (multi-step execution, tool calling, long context). The same base model with different post-training strategies can yield vastly different results in production.

2. Terminal Coding: From “Code Completion” to “Agent Execution”

2.1 Changes in Capability Form

The working loop of a terminal coding agent is: understand the task → search the repository → generate commands/code → execute → observe output → correct → deliver. This requires the model to possess four capabilities: environment awareness, command selection, error recovery, and context compression. Unlike code completion in an editor, the feedback for terminal tasks is “hard”: a command either succeeds or throws an error. Any failure in a multi-step chain is exposed, leaving no room to hide deficiencies.

2.2 Evaluation Dimensions

Terminal benchmarks examine the end-to-end task completion rate in real environments, rather than the correctness rate of static coding questions. During selection, focus on four metrics:

• Task Success Rate: The percentage of fully completed tasks.
• Average Interaction Turns: The number of round trips required to achieve the goal.
• Context Management: Whether the model “loses” early constraints during long tasks.
• Error Recovery Rate: Whether it can self-correct after an error instead of getting stuck in an infinite loop.

2.3 Calculate Costs by “Task”

Deep reasoning models have a high success rate on difficult tasks, but the token consumption for thinking is large. Lightweight models are cheap, but failed retries will drive up actual costs. For enterprise selection, it is recommended to measure the cost per unit task (total inference cost ÷ number of successful tasks) rather than the price per thousand tokens, and route tasks by difficulty: simple tasks go to lightweight models, while tough nuts are handed to deep reasoning models.

2.4 Engineering Best Practices

• Sandbox Execution: Commands generated by the agent must always run in a container or VM sandbox, with sensitive directories mounted as read-only.
• Least Privilege: Network access and file writing should be granted via a whitelist.
• Test Guardrails: Use “change → run tests → regression pass” as the completion standard, rather than “it looks fixed.”
• Full-Link Logging: Record every command and output at each step to facilitate replay auditing and problem attribution.

An illustrative agent task log snippet:

[task] Fix intermittent timeout in the login API
[step 1] Search and locate middleware -> Found connection pool has no upper limit set
[step 2] Modify configuration and run local stress test -> p99 latency reduced from 2.1s to 80ms
[step 3] Run regression tests -> All passed, generate patch and submit

3. Direct 3D Scripting: A New Paradigm in Generative Modeling

This is the direction with the most “mainstream breakout” potential in this evolution cycle. Instead of taking the detour of the “text-to-image → image-to-3D” reconstruction pipeline, the model directly outputs modeling scripts to be executed by mature modeling and CAD software.

3.1 Comparison of Three Technical Routes

• Image-to-3D: Fast, but the topology is uncontrollable and the wireframe is messy, making it difficult to enter serious industrial pipelines.
• Neural Implicit Representation: A research frontier with good rendering results, but the engineering pipeline for export, editing, and printing is not yet mature.
• Direct Scripting: The model generates parametric modeling scripts executed by the script interface of professional software. The output is naturally editable, reproducible, precision-controllable, and can directly interface with rendering and 3D printing.

Scripts are a good intermediate representation because they satisfy three conditions: composability (parameters, loops, functions freely assembled), verifiability (execution errors serve as feedback signals), and ecosystem maturity (almost all mainstream modeling and CAD software provide script interfaces). More importantly, it does not require external tool bridging protocols. The scripts directly produced by the model can complete asset building and detailing, and adjust layout, materials, geometry, and other elements.

3.2 Typical Workflow and Illustrative Code

Requirement description → Model generates script → Sandbox execution → Return preview or error → Model self-correction → Export model file for printing or rendering.

# Pseudo-code illustration, interface names depend on the target modeling software's script API
def build_lamp(base_r=90, pole_h=380, shade_r=120):
    base  = cylinder(radius=base_r, height=10)
    pole  = cylinder(radius=6, height=pole_h, pos=(0, 5 + pole_h/2, 0))
    shade = cone(r_top=50, r_bottom=shade_r, h=130,
                 pos=(0, 10 + pole_h + 65, 0))
    shade.material = "matte_plastic"
    return export("lamp.stl")   # Directly used for 3D printing

The core value of this approach lies in the restructuring of labor: aesthetics and intent belong to humans, software operation belongs to the model. A creator says “make the base thicker and change the lampshade to a matte material,” and the model simply changes two parameters, without the creator needing to study modeling software for three years first. Parametric vegetation placement in interior scenes, complex surface modeling for engine components, and directly printable consumer product designs all share a commonality: encapsulating “modeling knowledge” into the model while leaving “creative judgment” to humans. This is the key leverage point for breaking into the creative circle.

3.3 Engineering Essentials

• Scripts must be executed in a sandbox to prevent malicious or destructive code.
• Establish an asset library of materials and common components for the model to reference, avoiding generating everything from scratch each time.
• Automatically perform geometric validation (watertightness, normal direction, dimensional tolerances) after generation; if it fails, regenerate.
• Exported model files should be archived in object storage, rendering tasks should be sent to message queues for asynchronous processing, and the frontend should provide online preview and editing, supporting the export of print files or demo videos.

4. Financial Document Parsing: Retrieval, Reconciliation, and Multi-Step Reasoning

The difficulty in financial scenarios lies not in the breadth of knowledge, but in “rigor.” Real documents are full of tables, scanned copies, and cross-chapter references. A single misaligned number leads to a conclusive error. The complete task pipeline should be decomposed into four layers:

1. Document Parsing: Layout restoration, table structuring, and scanned document recognition.
2. Retrieval Augmentation: Locating paragraphs and report items relevant to the query.
3. Cross-Document Reconciliation: Consistency verification of the same metric across different reports and periods.
4. Multi-Step Numerical Reasoning: Chain calculations for growth rates, proportions, and accounting relationships.

Engineering recommendations: Always delegate numerical calculations to a code interpreter; prohibit the model from “doing math in its head.” Outputs must include citation tracing (filename + page number/cell coordinates); do not adopt answers without citations. Perform extraction validation first, then reasoning validation, and finally use a rules engine to cross-check accounting relationships. Build a private evaluation set using desensitized real business documents for continuous regression testing.

5. Hallucination Management: From “Capable of Answering” to “Trustworthy”

The most underestimated progress in this evolution cycle is the general decline in hallucination rates. Models that have undergone robust alignment have significantly reduced fabrication rates during stress testing. However, hallucination management is never a single-point technology; it is a combined approach:

• Training Side: Preference alignment explicitly penalizes “confidently fabricating” and rewards “admitting uncertainty.”
• Inference Side: Retrieval grounding (only answering with evidence) and self-verification of the evidence chain behind conclusions.
• Evaluation Side: Build a hallucination stress set specifically containing trap questions that “the model doesn’t know but tends to force an answer to,” serving as a regression gate before going live.

Enterprise implementation advice: Integrate hallucination testing into CI/CD. Run the stress set every time you switch models or adjust prompts. Set threshold alerts for error rates, and automatically block releases if exceeded, turning trustworthiness into a measurable engineering metric.

6. Enterprise Integration: One-Stop Cloud Deployment

For most enterprises, the challenge is not “which model to choose,” but how to embed the model into existing systems: inference services, vector retrieval, object storage, message queues, logging, and monitoring alerts. Cloud-based model services, such as Baidu AI Cloud, integrate these general capabilities into a unified foundation, allowing developers to focus on business orchestration rather than infrastructure assembly. It is recommended to proceed in four steps:

1. Selection & Evaluation: Build evaluation sets for terminal tasks, modeling, and document reasoning respectively, using cost per task and success rate as core metrics.
2. Sandbox Pilot: Run a closed loop in low-risk scenarios (internal tool script generation, marketing asset modeling).
3. Cost Observation: Implement full-link tracing to monitor token consumption and failure retry rates for each task type.
4. Gradual Rollout: Transition from assisted generation to automated execution, gradually increasing agent permissions while retaining manual checkpoints throughout.

Conclusion

To answer the question raised in the title: Will direct 3D scripting break into the creative circle? My judgment is—yes, and faster than many expect. The barrier to creation drops from “learning professional software” to “clearly stating what you want,” which will significantly amplify the supply of creations. The real bottleneck will shift to aesthetic judgment, requirement definition, and the maturity of the engineering pipeline for validation, export, and printing. The broader implication for developers is that the coordinate system of model competition has shifted from “general intelligence” to “vertical depth + engineering reliability.” A scientific methodology for selection, evaluation, and integration is far more important than chasing leaderboard scores.