2025年12月11日·1 分钟
在安全的小幅迭代中使用“不要更改”提示模式
学习“不要更改”提示模式：在只做一处小改动的同时冻结关键 UI 流程、业务规则和重要行为，避免其他部分发生漂移。
学习“不要更改”提示模式：在只做一处小改动的同时冻结关键 UI 流程、业务规则和重要行为，避免其他部分发生漂移。
所谓“一个小改动”很少真的只是小改动。你要求微调一个按钮标签，结果页面布局移动、表单不再校验，或结账步骤行为发生变化也并不罕见。应用是相互连接的系统：UI、逻辑、数据和集成都相互依赖。
常见原因之一是边界不清。如果一个请求写着“让注册更简单”，构建者（人或 AI）就不得不去猜“更简单”指什么。猜测会导致额外改动：删字段、改步骤、调整文案或重写校验。另一个原因是隐藏的依赖关系：一个微小的 UI 改动可能复用了出现在五个页面的组件。
一次安全的迭代意味着你得到了预期的改进，同时其他一切保持实质上不变。对非技术团队来说，这意味着用户感知的工作流程仍然相同，支持脚本仍然匹配产品，报表依然有效。对技术团队来说，这意味着路由、数据结构、API 合约或边界行为没有意外改变。
要做到这一点，你必须冻结那些绝对不能动的东西。实际上，这通常包括关键流程（用户完成操作的精确步骤）、UI/UX 细节（布局、间距、交互行为）、业务规则（定价、权限、校验）、数据行为（何时存储、存什么）和集成（分析事件、邮件、支付、外部 API）。
这个“不要更改”提示模式通过消除猜测并把改动范围限定下来，从而降低风险。它不是万无一失的：如果原有行为定义不清、改动触及共享组件，或你没有验证结果，依然会发生漂移。目标是减少意外并加快审批。
“不要更改”提示模式是一个简单的方法，用来在明确锁定其他部分的前提下请求一个具体改动。你指出你想要的单一改动，然后写一份简短的冻结清单，列出更新后必须保持完全一致的部分。
之所以重要，是因为模型常常会出于“帮忙改善”的目的去重构、重命名、重新组织文件或“清理”逻辑。即便输出仍然可用，那些额外改动也可能引入 bug、改变行为，或让审查变得更难。
对比下面两种请求：
“把设置页做得更好。” 这会邀请设计变更、新文案、布局改动和逻辑调整。
“把标签从 ‘Phone’ 改为 ‘Mobile phone’。不要更改布局、校验或保存行为。” 这个请求范围窄、可测试，也更安全。
一个合适的冻结清单通常覆盖三大类：
在像 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，且无布局跳动”）。
如果性能与安全也重要，也要冻结这些预期。如果你不提及，模型可能会“改进”实现方式，例如增加额外请求、新的日志或改变认证检查。
一种紧凑的写法：
用一句话描述数据流。例如：“仅在按下保存时保存地址，存入用户档案记录，并在登出/登录后保持。” 这种细节能防止意外的自动保存、新字段或时序改动影响用户。
UI 漂移通常来自模型“帮忙清理”样式或组件结构。解决办法与业务逻辑相同：明确列出不能改变的地方，并指出唯一允许变动的项。
固定可见结构。指出布局（列/行，页眉页脚位置）、间距规则（padding、gap、对齐）和组件行为（hover、disabled、loading、错误信息）。若某个组件有特定手感，请直接说明：“按钮的大小、圆角和颜色必须完全相同。”
响应式行为也需明确。如果你不提移动端规则，工具可能会“改进”它。写出关心的断点以及每个断点应有的行为：堆叠顺序、隐藏元素、固定栏与点击目标大小。
同时冻结文字内容。告诉模型除了你要改的那一条，其余所有文案、标签、占位和帮助文本必须保持不变。这可避免悄悄改写文字造成意义或布局变化。
一个可以粘进变更请求的精短清单：
如果可能的话，要求前后屏幕截图；若无截图，要求简短的“UI 差异”描述（移动了什么、缩放了什么、变了什么颜色），以便你有把握批准。
业务规则是小改动最容易造成静默回归的地方。一个标签更新可能无意中改变计算、状态转移或可见权限。把规则与数据行为当作契约来冻结。
从列出最可能损坏的规则开始。像写测试一样：输入、输出、谁可以做什么。
与其写“保持定价不变”，不如明确：
加入一个数值示例以消除解释空间。例如：“订单小计 $120，折扣 10%（在税前），税率 8.25% 作用于折后金额。期望总额 = (120 - 12) * 1.0825 = $116.91。仅在最终总额处保留两位小数。”
还要明确基于角色的可见性，而不仅是动作。例如：“支持人员可以查看订单状态和客户邮箱，但不得看到完整卡信息。只有管理员可发起退款。”
如果校验很重要，要把触发条件和用户可见的提示文字冻结：“若开始日期晚于结束日期，阻止保存并显示：‘结束日期必须在开始日期之后。’ 不要更改这段文字。”
别忘了应用外的副作用。如果你发送邮件、webhook 或调用第三方 API，也要冻结必须保持不变的项：事件名、载荷字段、时序（立即或延迟）以及幂等行为（重试时不重复发送）。
把一次小更新当作微型合同处理。该模式在改动狭窄且其他一切被显式冻结时效果最佳。
把改动写成一句可测试的陈述。“在设置页添加一个用于启用暗色模式的切换开关”是可测试的。写成“改进设置 UI”就不行。如果你无法在 30 秒内测试它，那它仍然太宽泛。
为会造成损害的部分写一份冻结清单：用户流程、关键 UI 元素、业务规则、数据行为，以及必须保持不变的任何 API 或数据库表。
添加验收检查和简短测试计划。这能防止“我这边可用”的意外。包括像：新开关出现、现有设置仍能保存、页面其他部分无位移等检查项。
在开始编辑前，让助手复述你的约束。让它确认将改变什么、必须保持一致的是什么。如果摘要有偏差，先修正提示再允许改动。
要求尽可能小的实现：不做重构、不改名、不做整体格式化，修改仅限受影响的行。你只买一个改动，不是一次大改造。
一个简短的审查清单：
在 Koder.ai 中这个流程尤其有效：把冻结清单粘到 Planning Mode，让助手回读约束，然后生成最小补丁。
大多数“小”改动出问题是因为请求保护了目标，但没保护行为。模型可能通过另一种实现方式实现目标，却悄悄改变了屏幕、逻辑或数据。
常见陷阱包括：
举个小例子：你要求“让按钮更显眼”，并冻结了颜色，但忘记冻结禁用态。实现可能会把按钮始终设为可用，这会改变行为而你可能不会立刻注意到。
有助于减少问题的方法是把不能动的点写清。在接受改动前做一个快速回归：
如果任何一项不同，那只是说明你的请求缺少某个冻结细节，而不是“坏代码”。
常见的安全迭代是做小的 UI 打磨，同时工作流不能改变。
场景：一个简单的注册页面，表单字段少（姓名、邮箱、公司规模），主按钮提交表单后跳转到仪表盘。
明确的改动请求（一句）：“把主按钮从 'Create account' 改为 'Continue'，并把‘Company size’字段从自由文本改为下拉框。”
按模式应用冻结清单：
几项能在几分钟内完成的验收检查：
一个好的助手回复应当复述冻结项，确认任何模糊点（例如：下拉选项的精确列表以及存储值是什么），然后只做最小的代码/UI 改动并说明它没有触碰的部分（路由、校验逻辑、载荷结构）。
在你接受“小改动”前，做一个快速检查以发现静默漂移。目标不是做完整 QA，而是确认你标注为“不要更改”的地方确实没变，除了那个你要改的点。
按相同顺序跑这些检查能让审查稳定并更容易发现回归。
如果任何冻结项被修改，即便应用“还能用”，也应回退。标签改动、新字段或细微规则改变都意味着模型越权了。
重新发起请求时把约束写得更紧：用一句话重申单一改动，按屏幕名称列出冻结的流程和屏幕，并加上“无架构更改、无端点更改、除 X 外不改变其他行为”。在 Koder.ai 中，变更前做快照能让回退变得极其简单。
在 Koder.ai 中，这个“不要更改”提示模式作为习惯最有效：每次只做一处小改动，其他一切锁定，如果有漂移能快速回退。
在请求改动前切换到 Planning Mode，让助手用普通语言复述你的范围。让它重复两点： (1) 精确变更是什么，(2) 清晰的冻结清单（流程、UI 细节和必须不变的业务规则）。
一个好用的规划提示例子： “复述我的请求。然后列出必须不变的项。如果有不清楚的地方，在修改前提问。”
把每个变更请求当作一个检查点。变更前做快照，验证后再做一次快照。如果有问题，回退比补丁更快。
例如你可能要调整 React 页面中的按钮标签。改动看着很小，但仍可能影响间距、触发重渲染或破坏自动化测试。快照让你能对比行为并迅速回退。
一个简单工作流：
Koder.ai 可以生成 Web（React）、后端（Go + PostgreSQL）和移动（Flutter）。尽管代码各异，但模式相同：冻结定义行为的部分，而不限于文件名。
如果你改后端端点，冻结请求/响应形状、校验规则和数据写入。如果你改移动端屏幕，冻结导航顺序、字段默认值和错误信息。如果你改数据库逻辑，冻结现有行的含义并保证迁移安全。
复制模板，把它当成习惯：每次只改一处，用清单锁其余，按验收检查确认再批准。
在你只需要一个明确改动且希望其他一切保持不变时使用。它对结账、认证、计费或任何小幅漂移会造成真实用户问题的流程尤其有用。
因为应用的各部分共用组件、数据和规则。一个细微的 UI 修改可能触及被复用的组件，从而改变别处的布局、校验逻辑或 API 负载，问题往往在后期才被发现。
写一个清晰的目标，然后列出在变更后必须保持不变的项。关键在于冻结行为（流程、规则、数据、集成）和可见的 UI 细节，而不是笼统地说“别弄坏”。
保持简短但具体：关键流程、必须不动的 UI/UX 细节、业务规则、数据行为和集成。如果你无法列出必须保持不变的内容，模型就会去猜，猜测会导致漂移。
把范围缩到既能保护你又不过分广泛为准。例如冻结结账流程及其共享组件，但如果你只修改某个屏幕上的标签，就不必冻结整个应用。
按步描述用户路径并定义“完成”是什么。再补上常见的边界情况：后退按钮行为、错误信息、空状态和刷新行为，这样在用户最在意的地方流程才能保持一致。
明确冻结布局结构、间距、组件状态（hover/disabled/loading）和所有文案，除了你要修改的那一条文字。否则模型可能会“清理”样式或重写文本，从而改变含义或布局。
冻结契约：请求/响应形状、校验规则、权限、计算方式以及什么时候存储数据。对于敏感规则（如定价），加入一个数值示例以避免实现时的歧义。
要求可快速执行的验收检查，并提供简短的差异式总结说明改动内容和位置。然后运行冻结流程的端到端检查，触发至少一个错误状态，并确认数据和集成未发生变化。
在变更前创建快照，进行规划阶段让助手复述范围和冻结清单，然后应用最小补丁。验证通过后再建一个快照，这样回滚只需一步。