为什么 Maker 不让 AI 去写代码。
应用生成器让语言模型即兴写代码。结果时而惊艳，却往往脆弱 —— 每一次修正都可能引发另一处崩坏。Maker 依赖一种不同的分工方式。
AI 做它最擅长的事：理解你的需求。构建器做机器最擅长的事：执行计划，每次都分毫不差。
分工 —— Maker 的根基为结构化管理型业务而生。
凡有实体、流程、状态和指标之处，Maker 都能制定计划：工单、订单、库存、排班、客户跟进。
这对你意味着什么。 Maker 生成的应用不是即兴之作：它执行的是一份经你确认的计划。当你调整需求时，计划随之改变 —— 构建也随之跟进，不产生副作用。
设计系统不是可选项。 每个应用都由一套专业组件系统组装而成 —— 与构建本网站的是同一套。
归属不容商量。 生成的代码从一开始就归你所有。ZIP 导出、推送到 GitHub、任意托管。Maker 是建造者，不是房东。
the making
Two ways to build an application. Only one holds up over time.
Every generator impresses on the first try. What sets them apart shows up during the making — then later, when something has to change. Here, one and the same request, followed end to end.
first movement — the making
From your idea to the first version.
Same starting request: “a tool to track my technicians' work orders, with a 4-hour deadline to meet”.
a generator that asks the ai to write the code
One sentence, in plain language.
Screens, data, rules: all produced in one shot. You don't see what was decided along the way.
maker — the ai draws up the plan
The same sentence, in your own words.
It lists what it understood: your technicians, your work orders, your 4-hour deadline. Nothing is built yet.
In plain language, not in code. The deadline is 6 hours, not 4? You fix it here, in one line — before a single line of code exists.
this is where the unpredictable stops
no correction loop
The builders apply proven rules: the code holds because it is assembled, not improvised.
They apply fixed rules, replayed identically on every generation. The code holds because it is assembled, not improvised — there is no correction loop.
At its dedicated URL. And the plan you validated stays readable — it's the reference.
second movement — the drift
What the fixes do to your original request.
When the AI re-reads and rewrites its own code several times over, it doesn't replay your request — it replays its last attempt. What you asked for drifts away, with nothing to flag it.
no written reference
The rule changed, and no one saw it. There is no document to compare against: the only trace of your request is the sentence you typed, and the code no longer resembles it.
the plan is the reference
The code can be rebuilt as many times as needed, the rule doesn't move. It isn't in the code: it's in the plan you approved.
third movement — the change
Later, you want to add a status “overdue ”.
This is where the gap shows most.
back to the loop
It re-reads code it has already rewritten several times, and never designed as such.
The code thickens, fixes pile up, and the loop lengthens as the application ages.
back to the plan
The one you validated. It's still there, still readable.
Status “overdue”: when the 4-hour deadline is passed. You re-read, you validate.
the rest of the plan hasn't moved
What didn't change in the plan doesn't change in the application. A late change takes the same effort as an early one.
what this changes for you
| criterion | the ai writes the code | blueprint maker |
|---|---|---|
| Role of the AI | the ai writes the code — Writes and rewrites the code | maker — Draws up the plan, never the code |
| Before delivery | the ai writes the code — Correction rounds, billed | maker — No correction round |
| What you validate | the ai writes the code — Nothing — you discover the result | maker — The plan, in plain language, before making |
| Your original request | the ai writes the code — Drifts with each fix | maker — Stays written, stays the reference |
| A change | the ai writes the code — Restarts the loop on the whole project | maker — Changes one line of the plan |
| Over time | the ai writes the code — Each fix calls for another | maker — The cost of a change doesn't spiral |
| Your code | the ai writes the code — Often kept on the platform | maker — ZIP export, GitHub push, self-hosting |
我们的理念
是什么把 Blueprint 与一个普通的应用生成器区分开来。
几乎所有人都忽视的那个问题
由人工智能驱动的应用生成器会写代码。当模型出错时，它出错时的自信与它正确时别无二致 —— 而在产出的代码中，没有任何东西能把两者区分开来。
我们在拒绝这种妥协的基础上构建了 Blueprint。以下这些原则支配着我们的系统做什么，尤其是它拒绝做什么。
我们所坚守的
我们不随意生成代码
Blueprint 不会让模型逐行写你的应用。它首先产出一份规格 —— 对应用应有形态的结构化、可核验的描述 —— 然后依据这份规格，以确定性的方式生成代码。
结果很简单：同一份规格两次，就会产出同一个应用两次。Blueprint 的可靠性是可证明的，而非或然的。
错误无害之处，模型自由；错误有害之处，模型受限
并非所有错误都等值。表单排布上的一处笨拙，转瞬即可修正。一条错误的业务规则，会悄然渗入每一个依赖它的计算。
在风险局部且可修复之处，我们赋予人工智能自由；在错误将无形且持久之处，我们对它严加约束。模型的回旋余地，与可能过失的严重程度相称。
我们的可靠性不取决于当下的模型
模型进步飞快；它们在变化。Blueprint 不把可靠性押在某个特定模型的才能上。保证你应用正确性的业务知识，存在于一份由专家策展的知识库中供模型查阅 —— 而非存在于模型本身。
更好的模型让 Blueprint 更好。没有任何模型会让 Blueprint 出错。
当系统不知道时，它会告诉你
这是我们最重要的承诺，与生成式 AI 的默认行为恰恰相反。面对无法确定的情形，Blueprint 宁可存疑，也不臆测。一处标明的空白是健康的状态；一处貌似合理的臆造，则是过失 —— 因为你无法把它与事实区分开来。
每一次推断都带着它的确定程度
当 Blueprint 解读你的需求时，它绝不会把一个猜测当作既定事实那样自信地呈现。可信程度会一路随信息传递到你手中。你始终知道什么是确定的，什么需要你亲自过目。
我们的方向
在今日所保证的之外，有两条要求指引着我们的工作：
- 产出与你业务真实高度相称的应用 —— 不是勉强「能用」的最小结构，而是你的业务应得的深度。
- 忠实于你所描述的领域，绝不为图省事而滑向一个通用方案。
这些是我们正逐步落实的方向，在尚未实现之前，我们拒绝把它们宣称为既成。这也是一种信守承诺的方式。
Blueprint —— 先有规格，后有应用。绝不随意。