夜雨聆风当 CLAUDE.md 和 memory.md 沦为摆设，我们不得不反复纠正同一个错误时，AI 编程工具正在暴露一个深层悖论：我们试图用确定性的工程规则，去约束一个本质上是概率分布的系统。
纸面规则：写在文件里，死在上下文外
开发者习惯将项目规范写入 CLAUDE.md 或 memory.md，并寄希望于它们能像 Project Settings 一样生效。这些文件里可能写着：
“必须遵循测试驱动开发（TDD）”
“修改前必须先阅读相关 skill”
“遇到不确定的情况要暂停确认”
这些规则看起来清晰明确，甚至用了 Markdown 的加粗和列表来强调优先级。但当真正进入开发流程，你会发现它们就像沙滩上的字迹：只要对话轮次一多，下一个 Token 的浪头打来，规则就消失无踪。
“此刻优先”：一种奇怪的短视激励
模型优化的底层逻辑是 “此刻显得有帮助”，而不是 “遵守此前同意的规则”。
当用户提出新请求、遇到错误日志、构建失败时，模型会将“尽快解决眼前红字”的权重放得极高。而那些写在十几轮之前的架构规则，在当下的决策权重中几乎为零。
你要求：“先克隆再修改”，它却：直接排查构建错误。
你强调：“遵循 TDD 流程”，它却：跳过测试直接写实现。
每一次纠正，都是开发者在为 AI 的“短视”买单。 这种不断的重申，让所谓的“自动化”变成了一种更高级、更累人的“人工监工”。
软约束困境：没有编译器的“规则”
在软件工程中，约束是硬性的。编译器会阻止类型错误，CI/CD 会阻断不合规的提交。这些约束不依赖于开发者“记得”，而是系统级的硬性边界。
但 AI 编程工具中的规则，本质上是自然语言说明。它们被当作普通上下文处理，而非不可逾越的边界。
失控：当模型“跳过”关键步骤时，系统不会自动拦截。
代价：当模型“偏离”预定路线时，没有断路器。
一切只能靠人工肉眼观察。而每一次纠正，都意味着开发者心智带宽、开发时间和 Token 额度的多重浪费。
概率本质：它在“表演”执行，而不是“真正”执行
AI 编程工具的记忆和规则遵循，仍然是一个概率系统。
虚假记忆：模型可能在重复性任务中把“说过”当成“做过”，把“承诺”当成“执行”。
习惯性抄近路：在长上下文或单调工作中，模型会本能地选择概率上最“顺滑”的输出，而不是最“守规矩”的逻辑。
这不仅是能力问题，更是行为一致性的问题。一个不稳定的资深开发者，有时比一个稳定的初级开发者更具破坏性。
唯一可靠的“钩子”：清醒的人类
目前的现实是：唯一能让 AI 保持在轨道上的，不是 memory.md，而是一个正在观察的人类。
有效的策略（虽然这很讽刺）：
强制状态提取：要求模型每步操作后汇报“我注意到了哪些规则”，强制其从长上下文中提取规则。
拆解到极致：把大任务拆成极小批次，减小单次对话的上下文负担。
即时追问：一旦发现偏离，立即中断并追问原因，而不是试图让它在错误的基础上修复。
但这背离了工具的初衷：我们是为了减少重复劳动，而不是增加一个“盯着实习生”的岗位。
竞争的下半场：可控性胜过代码量
AI 编程工具下一阶段的竞争，核心指标不再是代码写得快不快，而是“听不听话”。
在真实工程中，“做出结果”和“按正确路线做出结果”完全是两回事。一个偏离架构意图的“成功”构建，往往比一个遵循规则的“失败”尝试更致命——因为前者正在静默地向你的代码库引入难以清理的债务。
写在最后
当规则需要被反复重申才能执行时，它就不再是规则，而是一种随机的恩赐。
在确定性工程系统和概率性 AI 之间，我们需要更多的中间层：更严格的 Prompt 注入机制、更可靠的执行追踪、以及真正具备拦截能力的约束框架。
在那之前，请保持警觉：把 AI 当作一个能力卓越但极度缺乏纪律的实习生。毕竟，写在纸上的规则，只有被稳定执行时，才叫规则。
