用结构化输出为 AI 生成财务模型：先定 Schema，再谈电子表格

Generating a financial model with an LLM is not primarily a spreadsheet-generation problem. It is a data-contract problem. When an LLM is asked to create a financial model directly in Excel, several important decisions can become implicit. What is an input? Which numbers are assumptions? Which values came from external evidence? Which numbers are calculated? What units are being used? Which fields are mandatory?

A spreadsheet can represent all of these things, but it is not necessarily the best place to define the contract between an LLM and a financial-modeling system. A more reliable approach is to first represent the model as structured data, validate that structure, perform deterministic calculations, and only then render the result into a spreadsheet.

Why the spreadsheet should not be the first output

Consider a simple development model with inputs such as gross floor area, saleable area, selling price, construction cost, professional fees, financing assumptions, and development timing.

A prompt such as:
Create an Excel development feasibility model from these assumptions. may produce a workbook that looks reasonable. That does not mean the model is correct.

For example, construction cost might be calculated using gross floor area:

construction_cost = GFA × construction_cost_per_sqm

But another implementation could use saleable area:
construction_cost = saleable_area × construction_cost_per_sqm
Both can result in valid Excel formulas.

The difference is a modelling decision, not a spreadsheet-formatting decision. The same problem occurs with percentages, currencies, time periods, unit conversions, missing assumptions, and the distinction between user inputs and derived values.
The system needs to represent those decisions explicitly before Excel becomes involved.

Start with a structured model specification

A useful intermediate representation can describe the financial model without depending on a particular spreadsheet.
For example:
{
"model": {
"name": "development_feasibility",
"currency": "USD",
"period": "monthly"
},
"inputs": [
{
"id": "gfa",
"value": 25000,
"unit": "sqm",
"source_type": "user_input"
},
{
"id": "construction_cost",
"value": 1800,
"unit": "USD/sqm",
"source_type": "assumption"
}
],
"calculations": [
{
"id": "construction_cost_total",
"formula": "gfa * construction_cost",
"unit": "USD"
}
]
}
The representation is deliberately simple. The important part is that the model's meaning exists independently of the workbook. The application can validate the structure before any spreadsheet is generated. It can also determine whether a calculation references a known input and whether the units and expected data types are consistent.

What a schema actually gives you

JSON Schema is useful because it defines the expected structure of the data. A schema can require that value is a number, that unit is a string, and that source_type belongs to an approved set of values.

For example:
{
"type": "object",
"properties": {
"id": {
"type": "string"
},
"value": {
"type": "number"
},
"unit": {
"type": "string"
},
"source_type": {
"type": "string",
"enum": [
"user_input",
"assumption",
"verified_evidence"
]
}
},
"required": [
"id",
"value",
"unit",
"source_type"
],
"additionalProperties": false
}

This prevents the model from returning something structurally invalid, such as a text description where a numeric value is required. Modern structured-output APIs can use JSON Schema to constrain model responses. OpenAI's current documentation also distinguishes schema-constrained structured outputs from simply requesting valid JSON. But schema validation has a clear limit.

It can establish that:
{
"construction_cost": 1800
}

contains a number. It cannot establish that 1800 is the correct construction-cost assumption for a particular project. That requires evidence or professional judgement. This distinction is important when designing systems for financial modelling.

Separate structural validation from model validation

There should be more than one validation layer. The first layer checks the structure of the response. It can validate required fields, data types, enumerations, object structure, and permitted properties.
The second layer checks whether the proposed model makes sense. It can check units, dependencies, calculation references, period consistency, missing assumptions, sign conventions, and other modelling rules.

A response can pass the first layer and still fail the second. For example, this is structurally valid:
{
"gfa": 25000,
"construction_cost": 1800,
"currency": "USD"
}

But if the calculation engine expects construction cost in USD per square foot, the model has a semantic problem even though every field has the correct basic data type. A schema therefore should not be treated as a financial-model validator. It is one part of the validation system.

Keep deterministic calculations deterministic

LLMs are useful for interpreting natural-language instructions and converting them into structured representations. They are less appropriate as the final authority for calculations that can be expressed deterministically.

Suppose the model specification contains:
gfa = 25,000 sqm
construction_cost = 1,800 USD/sqm
The calculation:
25,000 × 1,800
does not need probabilistic reasoning.

The calculation engine should perform it. This separation makes the system easier to test because the calculation can be evaluated independently of the language model. It also makes changes easier to trace. If the construction-cost assumption changes, the system can identify the affected calculation rather than relying on the LLM to regenerate an entire workbook.

Excel becomes the presentation layer

Excel remains useful because financial professionals can inspect formulas, modify assumptions, test scenarios, and work with a familiar interface. The important design decision is not to remove Excel. It is to avoid making Excel the only representation of the model.
The Excel JavaScript API provides ranges for reading and writing values and formulas. Microsoft's documentation describes Range as the basic object for working with cells and contiguous blocks, with separate values and formulas properties. That means a validated model specification can be translated into a workbook in a controlled way.

For example, the renderer might write an input value to a specific range and write a formula to another range.
const inputRange = worksheet.getRange("B5");
inputRange.values = [[25000]];

const outputRange = worksheet.getRange("B10");
outputRange.formulas = [["=B5*B6"]];

The important point is that the formula is being generated from an already validated model definition. The LLM is not deciding what every spreadsheet cell should contain during workbook construction.

Provenance should be part of the data

Financial models contain different kinds of numbers. A user-provided input is not the same thing as an external market observation. An assumption is not the same thing as a calculated output. Those distinctions should remain visible in the structured representation.

For example:
{
"id": "sale_price",
"value": 4200,
"unit": "USD/sqm",
"source_type": "verified_evidence",
"source_id": "market_source_017"
}
is materially different from:
{
"id": "sale_price",
"value": 4200,
"unit": "USD/sqm",
"source_type": "assumption"
}
The numeric value is identical. The provenance is not. A system should also avoid allowing the LLM to invent source identifiers. If a source identifier represents external evidence, it should come from the evidence layer or from an explicitly supplied source. Otherwise the system can create the appearance of provenance without actually having verifiable provenance.

Do not make the schema a second spreadsheet

There is a temptation to put everything into the schema.
Every cell.
Every formula.
Every formatting property.
Every Excel address.
Every chart.
That creates another problem.
The schema should represent the meaning of the financial model rather than reproduce the entire workbook.
This is useful:
revenue = units × price_per_unit
This is implementation detail:
cell = H47
formula = "=SUM(H31:H46)"
font = "Calibri"
font_size = 11

The first describes model logic. The second describes spreadsheet presentation. Keeping those concerns separate makes the system easier to maintain.

Schema changes should be treated like API changes

The model schema will evolve.
A first version might contain:
gfa
construction_cost
selling_price
A later version might introduce:
gfa
saleable_area
construction_cost
selling_price
phasing
If older model specifications cannot be identified or interpreted after a schema change, reproducibility becomes difficult.
A simple version field can help:
{
"schema_version": "1.2"
}

Schema changes can then be tested in the same way that API changes are tested. Maintain representative model fixtures and validate them whenever the schema or calculation engine changes. This is particularly important when an LLM is involved because the model may produce different structures as prompts, schemas, or model versions change.

What structured outputs do not solve

Structured outputs do not make the underlying financial assumptions correct.

• They do not verify market evidence.
• They do not determine whether a comparable is appropriate.
• They do not establish that a construction-cost assumption is realistic.
• They do not replace review of development logic.
• They do not make an LLM a financial analyst.
• Their value is more specific.
• They create a stronger boundary between probabilistic language generation and deterministic software.

That boundary makes the system easier to validate, test, debug, and audit.

The practical rule

For AI-generated financial models, the useful principle is simple. Let the LLM interpret the request and propose a structured representation. Validate that representation before using it. Keep material calculations deterministic. Preserve the provenance of important inputs. Use Excel to expose the resulting model to the professional user. The interesting engineering question is therefore not whether an LLM can create an Excel file.

It can.

The more important question is whether the system can explain what each material number represents, where the number came from, how it was calculated, and which assumptions affect it. That is why structured outputs should come before spreadsheets. AI-Assisted. Human technical review required before publication.