---
title: 聊天式改网站，又不会改坏
description: 用大白话提出修改，演示容易，做到安全却很难。一次修改如何变成对已验证定义的补丁，并进入一份供你审阅的草稿。
date: 2026-08-27
author: crea.site
tags: [product]
---

"把页眉调深一点，把评价挪到价格上面。"

演示这句话很容易。让它安全才是真正的工作，因为最大的风险不是颜色错了，而是模型重写了本来只让它微调的页面，还顺手悄悄丢掉了营业时间。

## 网站是数据，不是代码

这里的网站是一份经过验证的定义：页面、区块、内容和设计。只有渲染器会把它变成 HTML，别的都不会。所以一次修改从不触碰标记，它只改动定义，而定义在存储之前会先被检查。

检查的意思不只是"能解析"。跨字段规则会抓住模式无法表达的问题：一个页面上有两个首屏区块，一篇文章没有日期，一个页面嵌套在路由永远不会提供的位置，一个表格绑定了网站并未声明的集合。这些都会被直接拒绝，而不是发布之后才被发现。

## 一次修改就是一个补丁

我们不会要求模型返回一个全新的网站，而是要求它针对网站当前的样子，给出能完成这次修改的最小补丁。

这一个决定就消除了大部分风险：

- 修改中没有提到的内容不可能变化，因为它不在回答里。
- 小修改只需要小回答，所以修改又快又省。
- 补丁会被保存，所以历史记录的是_改了什么_，而不只是网站变成了什么样。

## 你说发布之前，什么都不会发布

每次修改都会进入草稿。编辑器显示的是草稿；在你发布之前，公开网站一直是上一个已发布的版本。每个版本都会保留，所以回退只需点一下，不必道歉。

还有一项检查值得一提，因为它抓到过一个真实的 bug。如果一次耗时较长的修改进行期间草稿发生了变化，比如你在另一个标签页里做了改动，结果会被拒绝而不是合并：

> 在这次修改进行期间，网站又保存了另一项更改。请查看当前草稿后重试。

丢掉一次修改只是让人烦。悄悄覆盖掉一次修改则糟糕得多。

## 我们不会做的事

我们不允许修改凭空捏造事实。添加一条无人写过的用户评价，或一项无人持有的认证，都不是功能，管理生成的规则同样管理修改。

我们也不会在没做到时假装做到了。如果一个请求无法表达为对定义的修改，系统会如实说明，而不是拿出一个相近的东西，指望蒙混过关。