在安全的小幅迭代中使用“不要更改”提示模式

为什么小改动常常影响别处

所谓“一个小改动”很少真的只是小改动。你要求微调一个按钮标签，结果页面布局移动、表单不再校验，或结账步骤行为发生变化也并不罕见。应用是相互连接的系统：UI、逻辑、数据和集成都相互依赖。

常见原因之一是边界不清。如果一个请求写着“让注册更简单”，构建者（人或 AI）就不得不去猜“更简单”指什么。猜测会导致额外改动：删字段、改步骤、调整文案或重写校验。另一个原因是隐藏的依赖关系：一个微小的 UI 改动可能复用了出现在五个页面的组件。

一次安全的迭代意味着你得到了预期的改进，同时其他一切保持实质上不变。对非技术团队来说，这意味着用户感知的工作流程仍然相同，支持脚本仍然匹配产品，报表依然有效。对技术团队来说，这意味着路由、数据结构、API 合约或边界行为没有意外改变。

要做到这一点，你必须冻结那些绝对不能动的东西。实际上，这通常包括关键流程（用户完成操作的精确步骤）、UI/UX 细节（布局、间距、交互行为）、业务规则（定价、权限、校验）、数据行为（何时存储、存什么）和集成（分析事件、邮件、支付、外部 API）。

这个“不要更改”提示模式通过消除猜测并把改动范围限定下来，从而降低风险。它不是万无一失的：如果原有行为定义不清、改动触及共享组件，或你没有验证结果，依然会发生漂移。目标是减少意外并加快审批。

什么是“不要更改”提示模式

“不要更改”提示模式是一个简单的方法，用来在明确锁定其他部分的前提下请求一个具体改动。你指出你想要的单一改动，然后写一份简短的冻结清单，列出更新后必须保持完全一致的部分。

之所以重要，是因为模型常常会出于“帮忙改善”的目的去重构、重命名、重新组织文件或“清理”逻辑。即便输出仍然可用，那些额外改动也可能引入 bug、改变行为，或让审查变得更难。

对比下面两种请求：

“把设置页做得更好。” 这会邀请设计变更、新文案、布局改动和逻辑调整。

“把标签从 ‘Phone’ 改为 ‘Mobile phone’。不要更改布局、校验或保存行为。” 这个请求范围窄、可测试，也更安全。

一个合适的冻结清单通常覆盖三大类：

• 流程（用户旅程）： 用户采取的步骤以及出现的屏幕。
• UI 与 UX 细节： 布局、间距、字段顺序、按钮位置和交互。
• 业务规则与数据行为： 校验规则、定价计算、权限、数据库写入和 API 返回。

在像 Koder.ai 这样的基于聊天的构建工具中使用这个模式时，迭代通常更快，因为模型会聚焦于单一编辑，而不是做出你并未要求的广泛“改进”。

可复用的基本模板

这个模式在你的请求像一份微型合同时效果最好：一个明确目标、一份必须保持一致的冻结清单，以及若干验证方法。

复制并填写下面的模板，保持简短但具体。

Goal (one sentence):
- Change: [describe the one small change you want]

Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]

DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]

Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines

Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]

Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing

举例：如果你想改结账按钮颜色，目标可以写成“将主要结账按钮颜色更新为 #1A73E8”。你的 DO NOT CHANGE 应当冻结完整结账流程、按钮文本以及定价计算。

如果在 Koder.ai 中使用，这种格式也能让审查更快：你可以把验收检查和预览对照，然后在批准前查看变更摘要。

如何在不含糊的前提下冻结关键流程

当你请求一个小改动时，不要只说“别破坏任何东西”。列出必须保持一致的具体用户旅程，从第一次点击到最终结果。你不是冻结整个应用，而是冻结那些回归会造成损失的关键部分。

先用自然语言列出关键流程：登录（含重置密码）、入门、结账、设置。对每个流程说明“完成”应是什么样子。例如：“用户可以用邮箱+密码登录，登录后进入仪表盘，并在刷新后仍保持登录状态。”

然后锁定那些常被忘记的边界情况。后退按钮行为是常见漂移来源：“从结账页面后退回购物车（不是回首页），购物车项保持不变。” 明确错误状态（“密码错误显示相同的信息”）、空状态（“无项目显示相同的空状态文案”）和加载状态（“200ms 内出现 loading spinner，且无布局跳动”）。

如果性能与安全也重要，也要冻结这些预期。如果你不提及，模型可能会“改进”实现方式，例如增加额外请求、新的日志或改变认证检查。

一种紧凑的写法：

• 需要冻结的流程： 登录、注册、结账、设置（无新增步骤、无重排屏幕）
• 需要冻结的边缘情况： 后退按钮行为、错误信息、空状态、刷新行为
• 需要冻结的数据行为： 何时保存，保存什么，重载后如何显示
• 需要冻结的安全项： 权限、认证检查、速率限制，不新增公开接口
• 需要冻结的性能项： 在这些流程中不得增加额外 API 调用，响应时间不应变差

用一句话描述数据流。例如：“仅在按下保存时保存地址，存入用户档案记录，并在登出/登录后保持。” 这种细节能防止意外的自动保存、新字段或时序改动影响用户。

如何冻结 UI 与 UX 细节

UI 漂移通常来自模型“帮忙清理”样式或组件结构。解决办法与业务逻辑相同：明确列出不能改变的地方，并指出唯一允许变动的项。

固定可见结构。指出布局（列/行，页眉页脚位置）、间距规则（padding、gap、对齐）和组件行为（hover、disabled、loading、错误信息）。若某个组件有特定手感，请直接说明：“按钮的大小、圆角和颜色必须完全相同。”

响应式行为也需明确。如果你不提移动端规则，工具可能会“改进”它。写出关心的断点以及每个断点应有的行为：堆叠顺序、隐藏元素、固定栏与点击目标大小。

同时冻结文字内容。告诉模型除了你要改的那一条，其余所有文案、标签、占位和帮助文本必须保持不变。这可避免悄悄改写文字造成意义或布局变化。

一个可以粘进变更请求的精短清单：

• 保持一致：路由/屏幕、导航顺序和后退行为
• 保持一致：布局网格、间距、字体、颜色和组件状态
• 保持一致：所有文案和标签，除非是： “<the one string>”
• 移动规则：在 <breakpoints> 保持当前行为，不要重新流动其他部分
• 输出：描述你做的每一处 UI 变化，并列出触及的文件/组件

如果可能的话，要求前后屏幕截图；若无截图，要求简短的“UI 差异”描述（移动了什么、缩放了什么、变了什么颜色），以便你有把握批准。

如何冻结业务规则与数据行为

业务规则是小改动最容易造成静默回归的地方。一个标签更新可能无意中改变计算、状态转移或可见权限。把规则与数据行为当作契约来冻结。

从列出最可能损坏的规则开始。像写测试一样：输入、输出、谁可以做什么。

把必须保持不变的规则写清楚

与其写“保持定价不变”，不如明确：

• 定价：精确公式、四舍五入规则（向上/向下）、货币、税/VAT 行为以及折扣何时适用
• 权限：哪些角色可以创建、编辑、删除、批准、退款、导出或查看敏感字段
• 状态：允许的状态和有效转移（以及触发条件）
• 计算：总额、佣金、积分、限额及任何上限或下限
• 数据写入：哪些表/记录被创建或更新，哪些字段必须保持不可变

加入一个数值示例以消除解释空间。例如：“订单小计 $120，折扣 10%（在税前），税率 8.25% 作用于折后金额。期望总额 = (120 - 12) * 1.0825 = $116.91。仅在最终总额处保留两位小数。”

还要明确基于角色的可见性，而不仅是动作。例如：“支持人员可以查看订单状态和客户邮箱，但不得看到完整卡信息。只有管理员可发起退款。”

如果校验很重要，要把触发条件和用户可见的提示文字冻结：“若开始日期晚于结束日期，阻止保存并显示：‘结束日期必须在开始日期之后。’ 不要更改这段文字。”

别忘了应用外的副作用。如果你发送邮件、webhook 或调用第三方 API，也要冻结必须保持不变的项：事件名、载荷字段、时序（立即或延迟）以及幂等行为（重试时不重复发送）。

逐步：如何提出一个安全的小改动请求

把一次小更新当作微型合同处理。该模式在改动狭窄且其他一切被显式冻结时效果最佳。

1. 把改动写成一句可测试的陈述。“在设置页添加一个用于启用暗色模式的切换开关”是可测试的。写成“改进设置 UI”就不行。如果你无法在 30 秒内测试它，那它仍然太宽泛。

2. 为会造成损害的部分写一份冻结清单：用户流程、关键 UI 元素、业务规则、数据行为，以及必须保持不变的任何 API 或数据库表。

3. 添加验收检查和简短测试计划。这能防止“我这边可用”的意外。包括像：新开关出现、现有设置仍能保存、页面其他部分无位移等检查项。

4. 在开始编辑前，让助手复述你的约束。让它确认将改变什么、必须保持一致的是什么。如果摘要有偏差，先修正提示再允许改动。

5. 要求尽可能小的实现：不做重构、不改名、不做整体格式化，修改仅限受影响的行。你只买一个改动，不是一次大改造。

一个简短的审查清单：

• 仅请求的行为被修改
• 冻结的流程和屏幕仍保持一致
• 业务规则与数据写入未改动
• 按照说明测试通过（或手动步骤通过）
• 没有混入“清理”类提交

在 Koder.ai 中这个流程尤其有效：把冻结清单粘到 Planning Mode，让助手回读约束，然后生成最小补丁。

常见错误及其导致漂移的原因

大多数“小”改动出问题是因为请求保护了目标，但没保护行为。模型可能通过另一种实现方式实现目标，却悄悄改变了屏幕、逻辑或数据。

常见陷阱包括：

• 抽象化：你保护了目的，但没有逐步保护点击流程和预期结果。
• 忽略边界情况：空状态、加载状态、校验错误、权限拒绝、离线行为等。
• 捆绑改动：一次请求包含两三项改动，会增加权衡与回归风险。
• 未定义“相同”：未明确说明是相同的 UI 布局、相同的 API 调用、相同的数据写入、相同的邮件/通知、相同的分析事件。
• 凭感觉批准：看起来“还好”但没有验证关键路径。

举个小例子：你要求“让按钮更显眼”，并冻结了颜色，但忘记冻结禁用态。实现可能会把按钮始终设为可用，这会改变行为而你可能不会立刻注意到。

有助于减少问题的方法是把不能动的点写清。在接受改动前做一个快速回归：

• 运行主流程端到端（你冻结的那个流程）。
• 触发至少一个错误状态和一个空状态。
• 检查权限（管理员 vs 普通用户）。
• 确认副作用：记录是否被创建/更新、通知是否已发出、日志/指标是否未改动。

如果任何一项不同，那只是说明你的请求缺少某个冻结细节，而不是“坏代码”。

示例：在不改变工作流的前提下做小幅 UI 调整

常见的安全迭代是做小的 UI 打磨，同时工作流不能改变。

场景：一个简单的注册页面，表单字段少（姓名、邮箱、公司规模），主按钮提交表单后跳转到仪表盘。

明确的改动请求（一句）：“把主按钮从 'Create account' 改为 'Continue'，并把‘Company size’字段从自由文本改为下拉框。”

按模式应用冻结清单：

• 流程冻结：提交仍然创建账号，显示相同的校验信息，并把用户导向相同的下一个屏幕。
• UI 冻结：页面布局、间距、颜色和按钮位置保持不变。
• 数据冻结：后端请求负载的键与类型不变；存储的公司规模值保持和以前相同的格式。
• 业务规则冻结：必填字段仍是必填，表单在校验通过前按钮保持禁用。
• 分析冻结：提交和校验错误时触发相同的跟踪事件。

几项能在几分钟内完成的验收检查：

• 按钮文案处处显示“Continue”（默认、加载、禁用状态）。
• 公司规模为下拉框，默认值与之前一致。
• 提交后仍然跳转到仪表盘并创建账号。
• 现有用户编辑资料时仍能正确看到已保存的公司规模。
• 注册相关的测试或警告不新增失败项。

一个好的助手回复应当复述冻结项，确认任何模糊点（例如：下拉选项的精确列表以及存储值是什么），然后只做最小的代码/UI 改动并说明它没有触碰的部分（路由、校验逻辑、载荷结构）。

在批准前的快速检查清单

在你接受“小改动”前，做一个快速检查以发现静默漂移。目标不是做完整 QA，而是确认你标注为“不要更改”的地方确实没变，除了那个你要改的点。

5 项快速检查（10 分钟）

按相同顺序跑这些检查能让审查稳定并更容易发现回归。

• 关键流程端到端仍能完成： 从真实用户的入口点（登录、着陆页、仪表盘）开始并完成主要任务。
• UI 除目标改动外看上去相同： 打开你冻结的关键屏，扫描布局、按钮文案、间距和导航。
• 业务规则仍然吻合预期： 抽查 2-3 个常见出问题的场景，如折扣计算、角色权限或状态转移。
• 数据结构未变： 确认没有新字段、重命名字段、删除字段或不必要的迁移。
• 集成未被触碰： 确认没有端点变更且载荷字段未变（字段名、必需字段、状态码）。

何时回退并重新发起请求

如果任何冻结项被修改，即便应用“还能用”，也应回退。标签改动、新字段或细微规则改变都意味着模型越权了。

重新发起请求时把约束写得更紧：用一句话重申单一改动，按屏幕名称列出冻结的流程和屏幕，并加上“无架构更改、无端点更改、除 X 外不改变其他行为”。在 Koder.ai 中，变更前做快照能让回退变得极其简单。

下一步：在 Koder.ai 中应用以实现更安全的迭代

在 Koder.ai 中，这个“不要更改”提示模式作为习惯最有效：每次只做一处小改动，其他一切锁定，如果有漂移能快速回退。

先进行一次简短的规划

在请求改动前切换到 Planning Mode，让助手用普通语言复述你的范围。让它重复两点： (1) 精确变更是什么，(2) 清晰的冻结清单（流程、UI 细节和必须不变的业务规则）。

一个好用的规划提示例子： “复述我的请求。然后列出必须不变的项。如果有不清楚的地方，在修改前提问。”

用快照保护每次迭代

把每个变更请求当作一个检查点。变更前做快照，验证后再做一次快照。如果有问题，回退比补丁更快。

例如你可能要调整 React 页面中的按钮标签。改动看着很小，但仍可能影响间距、触发重渲染或破坏自动化测试。快照让你能对比行为并迅速回退。

一个简单工作流：

• 做快照："Before - change button label only"
• 运行规划并确认冻结清单
• 请求单一改动并要求简短的差异式总结
• 用清单验证（UI、流程、规则、数据）
• 做快照："After - verified"

在整个栈上复用相同模式

Koder.ai 可以生成 Web（React）、后端（Go + PostgreSQL）和移动（Flutter）。尽管代码各异，但模式相同：冻结定义行为的部分，而不限于文件名。

如果你改后端端点，冻结请求/响应形状、校验规则和数据写入。如果你改移动端屏幕，冻结导航顺序、字段默认值和错误信息。如果你改数据库逻辑，冻结现有行的含义并保证迁移安全。

复制模板，把它当成习惯：每次只改一处，用清单锁其余，按验收检查确认再批准。