为什么用区块，而不是 HTML
Why blocks, not HTML
客户编辑内容，AI 提出结构，站点保留设计权。本文说明这种分工在底层如何运作，以及生成一个页面的成本。
设计笔记
Most site builders hand the client a page-level HTML editor and hope. Two years later the home page and the inner pages look like two different websites, because every editor drifts the design a little. AIBlog takes the other road: the client edits content, the AI proposes structure, and the site owns the design.
What the client sees
- a box to paste text into, from a document, a chat export, or notes
- a place to drop photos
- a chat to ask for changes in plain language
The client never chooses a block type, a column, a widget or a font. They cannot, because nothing in the interface offers one.
What happens underneath
The composer receives the pasted material, the family's editorial policy and a numbered list of the photos with a one-line description of each. It returns the whole page as a typed object: apparatus fields in each locale, and a body of semantic blocks such as lead, paragraph, sub-head, list, quote, fact strip, table, figure and photo sheet. The server validates every field and every photo reference against the schema and the family's allow-list. Anything outside it is refused, and one automatic repair turn asks the model to try again. What survives is saved as a draft and rendered by the real page.
The client has editorial control, the AI has bounded compositional discretion, and the host site retains design authority.
Why this holds
The renderer emits structure and class hooks, never colours or widths. A theme is a plain stylesheet. A client cannot break the design by editing, because the editor only lets them change words and pictures inside blocks whose types are fixed. Structural changes go back to the composer, which can only emit blocks the theme already knows how to draw.
What it costs
A page from first paste to published usually costs well under a dollar in model usage, and the composer's prompt is cached so revision turns are cheap. Photo descriptions cost a fraction of a cent each.