旧稿：
在修改生产资源之前，先向我确认。
很多人的 system prompt 第二行就挂着它。坏就坏在【先】这个字。
"先"是时间词，不是条件词。模型读到"先确认"，读到的是一个流程步骤：确认，然后执行。流程走完一遍就作数了。会话跑到第 90 分钟，这个账号里它已经改过七八个资源，那条"先"在它账上早划掉了——不是被无视，是被满足了。
它不是不听话。是它认定这个条件的有效期已经过了。
这一点决定你改哪儿。要是认定模型"越到后面越不守规矩"，修法就会往加重语气的方向走：一定、务必、任何情况下都必须。没用。要改的不是它的态度，是这句话的可满足性。
改到第二版：
每次调用会修改生产资源的工具之前，停下来把变更摘要发给我，等我回复确认再执行。
动了三处。【每次都】把一次性条件变成每轮成立；【停下来】把流程改成关卡；【等我回复】把"确认"从模型的动作改成我的动作——它没资格自己宣布自己确认过了。十七个字变成四十一个字。
V2 带出了新毛病。模型开始把"停下来"当成一种姿态来展示：我想看一眼成本报告它问，读一个文件它也问。它不是守规矩，是在表演守规矩。这是我常犯的毛病，把客气当成检查点。留白留错了地方，就是含糊。
改到第三版，补上边界：
只对会写状态的操作触发以下流程（创建、修改、删除，含 terraform apply 和带 --force 的命令）：先把变更摘要发我，等我回复确认再执行。只读操作不用问。
六十七个字，比 V1 多出三倍。多出来的不是客套字，是边界。"会写状态"钉死了哪些工具该触发，"只读不用问"堵住了表演的入口。短从来不是目的，贴合才是。
这套"什么时候才作数"的毛病，不只在 guardrail 上。
一个 EKS 的 Terraform 项目，会话里已经堆了 VPC 私有子网、集群、托管节点组、服务账号 IAM 角色、安全组、CoreDNS 和 kube-proxy 插件。半小时前刚配好 OIDC provider，ARN 也拿到了。这时候要一份 aws-load-balancer-controller 的 trust policy，模型给的是一份通用模板，集群名和 OIDC ARN 一个字没提。
清掉会话，把集群名、区域、OIDC ARN 重新贴一遍。二十秒，对的 policy 出来了。
从这件事里学到"上下文满了要清"，我觉得这个结论偷懒了。真正发生的是：那条 ARN 上一分钟还站在末尾，这一分钟被几十轮工具输出推到了中间。清空之所以有效，不是因为它腾出了空间，是因为它把那条 ARN 重新挪回了末尾。而新会话的末尾，就是那条消息本身。
U 型注意力的事做这行的都清楚，中间那截天生吃亏，不重复。只说一个常被漏掉的后续：那个效应在窗口填到一半左右时最猛，再往后首因偏差减弱、近因偏差增强，模型越来越只看最近几分钟说过什么。
这一条把百分比那套框架捅了个洞。
那篇文章给过一张很干净的表：40% 以下放心用，40 到 60 收着点，70% 以上开始退化。表没错，我自己也差不多按这个来。
但它量的是空间。你缺的常常是位置。
同一个模型，60% 的窗口，只要那条 ARN 在你最后一条消息里，它答得比 30%、但 ARN 埋在第十五轮的时候还准。百分比是代理指标。代理久了，你会以为自己缺的是容量，于是去换更大的窗口。可窗口再大，中间还是中间，那截不会因为长度变长而变亮。
真该盯的，可能不是"用了多少"，是"我上一句关键的话是什么时候说的，中间隔了多少东西"。
那条 40% 的线我照旧会瞟一眼。只是现在它更像一个提醒我去看位置的路标，不是用来决定要不要开新会话的阈值。