A Failed Restart

An indie developer friend of mine took on a gig: building an online document template system for a small legal consulting studio. The users' needs were simple—pick a "labor contract" or "lease agreement" template, fill in a few key pieces of information (Party A and Party B, salary, term), and have the system automatically generate a well-structured, internally consistent document.

His first version worked like this: take a general-purpose large model, stuff the entire template into the prompt, and let the model "fill in and polish." One week after launch, problems erupted:

• The model arbitrarily altered the wording of established legal clauses in the template, and the law firm rejected it during review;
• For the same field, the model sometimes filled in "人民币 8,000 元" and sometimes "捌仟元整"—completely inconsistent formatting;
• Some templates ran dozens of pages long; with lengthy text, the model missed fields, or even put "Party B" into the "Party A" slot;
• To improve results, he switched to a stronger model—and had to rewrite the API format, authentication method, and field names, burning an entire afternoon.

This wasn't the model failing; the approach was wrong. Here is the correct path after the post-mortem.

First, Clarify the Business Pain Points

The hard part of intelligent fill-in-the-blank for legal documents isn't "generation"—it's "constraint":

1. Templates must not be tampered with: The clauses have been approved by the law firm; AI can only fill in blanks, not rewrite the body text;
2. Fields have format specifications: Amounts, dates, and terms must conform to legal writing conventions;
3. Fields are interdependent: Contract term, probation caps, and social insurance clauses have statutory linkage relationships;
4. Many types of templates: Labor contracts, leases, NDAs, powers of attorney—each category has different rules.

The brute-force approach of general-purpose generation is inherently at odds with these constraints.

The Correct Architecture: The Template Is the Skeleton, AI Is Just the Fill-in Clerk

The refactored architecture has four layers:

┌─────────────────────────────────────┐
│  模板层：文书模板 + 字段占位符定义      │
│  （{{party_a}} {{salary}} {{term}}）  │
├─────────────────────────────────────┤
│  抽取层：对话式收集用户信息             │
│  （多轮问答，逐个补齐字段）             │
├─────────────────────────────────────┤
│  推理层：AI 只负责字段值的生成与校验     │
│  （结构化输出，不碰模板正文）            │
├─────────────────────────────────────┤
│  渲染层：纯代码做字符串替换 + 规则校验   │
└─────────────────────────────────────┘

The core principle in one sentence: AI only produces structured field values; template rendering is handed off to deterministic code. This way, the clauses approved by the law firm are never touched by the model, and the probability of problems drops from "could go wrong on every generation" to "occasional fields need human confirmation."

Key Implementation Steps

Step 1: Structure the templates. Break each document into "fixed body text + field list." The field list is defined with JSON Schema, including types, formats, validation rules, and inter-field constraints:

{
  "template_id": "labor_contract_v3",
  "fields": [
    {"name": "salary", "type": "currency", "format": "人民币{amount}元/月"},
    {"name": "term_months", "type": "int", "min": 1, "max": 36},
    {"name": "probation_months", "type": "int",
     "constraint": "term_months<=12 ? probation_months<=1 : probation_months<=6"}
  ]
}

Step 2: Conversational collection. Instead of making users fill out a thirty-item form, have AI ask guided questions—"What is the full registered name of Party A's company?" "What is the employee's monthly salary?"—asking only 2-3 related fields per round, and stopping once all missing information is collected.

Step 3: Structured generation + double validation. Require the model to return field values as JSON, then run a second-pass validation at the code layer with a rules engine (amount formats, probation caps, etc.). Model output accounts for only a small segment of the pipeline, so the blast radius of errors is tightly contained.

Step 4: Render and keep records. Generate the final document via string replacement, while also producing a "field filling notes" report that flags which values came from user input and which were inferred by AI (e.g., automatically filling in "handled by the Beijing municipal social insurance agency" based on "work location: Beijing"), making it easy for the law firm to review quickly.

Why a Unified AI API Gateway Reduces Maintenance Costs

The fourth pitfall my friend stepped in at the beginning—switching models means rewriting the integration—is actually the long-term cost indie developers most easily underestimate. After integrating a unified AI API gateway, the value shows up in three places:

1. Unified protocol: The extraction, conversation, and validation stages may use different models (cheap models for Q&A collection, stronger models for complex field reasoning). The gateway normalizes different vendors' APIs into a single calling format—switching models means changing one model parameter, without touching business code;
2. Key consolidation: No need to scatter various vendors' API Keys across multiple services; key rotation and leak handling happen in one place only;
3. Centralized cost and monitoring: Token consumption per document type and per stage is visible at a glance. Billing anomalies on long templates can be caught the same day, rather than discovering at month-end that some prompt blew up.

For a one- or two-person team, this means squeezing out zero-value work like "adapting to each vendor's model API" and spending all your energy on the business rules themselves.

Wrapping Up

The legal document scenario, at its core, tests not prompting skills but your judgment about the boundary of "what AI can and cannot do": hand the determinism of templates to code, hand the ambiguity of understanding and reasoning to the model—keep each in its proper place, and the product can pass the law firm's review gate.

If you're about to build a similar AI application and don't want to repeatedly adapt among multiple model APIs, you can start by registering a unified gateway account at https://api.thistoken.ai/register, sort out the model integration layer once and for all, and then come back to polish your field rules—get the order right, and you're halfway done.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.