为什么 Maker 不让 AI 去写代码。
应用生成器让语言模型即兴写代码。结果时而惊艳，却往往脆弱 —— 每一次修正都可能引发另一处崩坏。Maker 依赖一种不同的分工方式。
AI 做它最擅长的事：理解你的需求。构建器做机器最擅长的事：执行计划，每次都分毫不差。
分工 —— Maker 的根基为每一种结构化管理需求而生。
凡有实体、流程、状态和指标之处，Maker 都能制定计划：工单、订单、库存、排班、客户跟进。
工单
库存
客户跟进
你的需求
订单
排班
指标
这对你意味着什么。
Maker 生成的应用不是即兴之作：它执行的是一份经你确认的计划。当你调整需求时，计划随之改变 —— 构建也随之跟进，不产生副作用。
设计系统不是可选项。
每个应用都由一套专业组件系统组装而成 —— 与构建本网站的是同一套。
归属不容商量。
生成的代码从一开始就归你所有。ZIP 导出、推送到 GitHub、任意托管。Maker 是建造者，不是房东。
制造
构建一个应用有两种方式。 只有一种能经受时间。
每个生成器在第一次尝试时都令人惊艳。真正区分它们的，显现于制造过程之中––以及日后需要修改之时。这里，同一个需求，从头到尾被完整追踪。
第一幕：制造
从你的想法到第一个 版本。
同一个起始需求：「一个用来跟踪我的技师工单的工具，须遵守 4 小时的期限」。
一个让 ai 编写代码的生成器
一句话，用自然语言。
界面、数据、规则：一次性全部产出。你看不到途中做了哪些决定。
maker：ai 制定方案
同样一句话，用你自己的话。
它列出所理解的内容：你的技师、你的工单、你的 4 小时期限。此时尚未制造任何东西。
用自然语言，而非代码。期限是 6 小时而不是 4 小时？你在这里改，一行即可––在任何一行代码存在之前。
不可预测在此止步
没有修正循环
构建器应用久经检验的规则：代码之所以站得住，是因为它被组装而非即兴发挥。
它们应用固定规则，每次生成都被原样重放。代码之所以站得住，是因为它被组装而非即兴发挥––没有修正循环。
在其专属 URL 上。而你确认过的方案仍可查阅––它就是基准。
第二幕：偏移
这些修正对 你最初的需求做了什么。
当 AI 一次又一次地重读并重写自己的代码时，它重放的不是你的需求––而是它上一次的尝试。你所要求的会逐渐走样，却没有任何东西提醒你。
没有书面基准
规则变了，没人看见。 没有任何文档可供比对：你需求的唯一痕迹就是你敲下的那句话，而代码已不再与它相像。
方案就是基准
代码可以按需要重造任意多次，规则不会移动。 它不在代码里：它在你批准过的方案里。
第三幕：修改
日后，你想添加一个状态「逾期」。
正是在这里，差距最为明显。
又回到循环
它重读一段自己已经重写过多次、且并非如此设计的代码。
代码变厚，修正堆叠，随着应用老化，循环越拉越长。
回到方案
就是你确认过的那份。它还在，依然可读。
状态「逾期」：当 4 小时的期限被超过时。你重读，你确认。
方案的其余部分没有变动
方案中未改动的部分，在应用里也不会变。一次迟来的修改所需的功夫，和一次早期修改相同。
这对你意味着什么
| 标准 | ai 编写代码 | blueprint maker |
|---|---|---|
| AI 的角色 | ai 编写代码：编写并重写代码 | maker：制定方案；骨架是被编译的，而非写出来的 |
| 交付之前 | ai 编写代码：一轮轮修正，需付费 | maker：没有任何修正轮次 |
| 你确认的内容 | ai 编写代码：什么都没有––你直接看到结果 | maker：方案，用自然语言，在制造之前 |
| 你最初的需求 | ai 编写代码：每次修正都走样 | maker：保持书面，始终是基准 |
| 一次修改 | ai 编写代码：在整个项目上重启循环 | maker：更改方案中的一行 |
| 随着时间 | ai 编写代码：每次修正都引出下一次 | maker：修改的成本不会失控 |
| 你的代码 | ai 编写代码：常被留在平台上 | maker：ZIP 导出、GitHub 推送、自行托管 |
我们的理念
是什么把 Blueprint 与一个普通的应用生成器区分开来。
几乎所有人都忽视的那个问题
由人工智能驱动的应用生成器会写代码。当模型出错时，它出错时的自信与它正确时别无二致 —— 而在产出的代码中，没有任何东西能把两者区分开来。
我们在拒绝这种妥协的基础上构建了 Blueprint。以下这些原则支配着我们的系统做什么，尤其是它拒绝做什么。
我们所坚守的
我们不随意生成代码
Blueprint 不会让模型逐行写你的应用。它首先产出一份规格 —— 对应用应有形态的结构化、可核验的描述 —— 然后依据这份规格，以确定性的方式生成代码。
结果很简单：同一份规格两次，就会产出同一个应用两次。Blueprint 的可靠性是可证明的，而非或然的。
错误无害之处，模型自由；错误有害之处，模型受限
并非所有错误都等值。表单排布上的一处笨拙，转瞬即可修正。一条错误的业务规则，会悄然渗入每一个依赖它的计算。
在风险局部且可修复之处，我们赋予人工智能自由；在错误将无形且持久之处，我们对它严加约束。模型的回旋余地，与可能过失的严重程度相称。
我们的可靠性不取决于当下的模型
模型进步飞快；它们在变化。Blueprint 不把可靠性押在某个特定模型的才能上。保证你应用正确性的业务知识，存在于一份由专家策展的知识库中供模型查阅 —— 而非存在于模型本身。
更好的模型让 Blueprint 更好。没有任何模型会让 Blueprint 出错。
当系统不知道时，它会告诉你
这是我们最重要的承诺，与生成式 AI 的默认行为恰恰相反。面对无法确定的情形，Blueprint 宁可存疑，也不臆测。一处标明的空白是健康的状态；一处貌似合理的臆造，则是过失 —— 因为你无法把它与事实区分开来。
每一次推断都带着它的确定程度
当 Blueprint 解读你的需求时，它绝不会把一个猜测当作既定事实那样自信地呈现。可信程度会一路随信息传递到你手中。你始终知道什么是确定的，什么需要你亲自过目。
我们的方向
在今日所保证的之外，有两条要求指引着我们的工作：
- 产出与你业务真实高度相称的应用 —— 不是勉强「能用」的最小结构，而是你的业务应得的深度。
- 忠实于你所描述的领域，绝不为图省事而滑向一个通用方案。
这些是我们正逐步落实的方向，在尚未实现之前，我们拒绝把它们宣称为既成。这也是一种信守承诺的方式。
Blueprint —— 先有规格，后有应用。绝不随意。