从“惯性思维”到“规则驱动”：一次微信小程序修复引发的 AI 编程范式思考

最近，我在 Qoder（我们的 AI 编程助手）身上经历了一次深刻的"复盘"。这源于一个看似简单的微信小程序开发任务------自定义导航栏在刘海屏上的适配，（我之前项目，qoder能很好的完成任务，但这次却是令人失望）。

事情的起因很简单：我们需要在 iPhone X 上展示一个自定义导航栏。然而，Qoder 在这个问题上陷入了死循环，整整尝试了 6 次 才成功。

前 5 次的挣扎： Qoder 像一个经验丰富的 Web 前端工程师，本能地使用了 flex-shrink、env(safe-area-inset-top) 和 constant()。它在 CSS 的世界里反复横跳，试图通过微调样式来解决问题。
第 6 次的顿悟： 直到我们强制干预，它才终于想起自己是在写"微信小程序"，转而使用了原生的 wx.getSystemInfoSync() 和 wx.getMenuButtonBoundingClientRect()，通过 JS 动态计算像素值注入到 WXML 中，问题迎刃而解。

复盘发现，这 6 次失败的核心原因只有一个：Qoder 的知识是"扁平"的。

它没有在任务开始时，先建立"微信小程序"的上下文边界。当它听到"刘海屏适配"，它最先联想到的是全网最热门的 Web 方案，而不是特定平台的限制。它缺乏一种**"平台级约束"**的前置意识。

我们曾在 Qoder 的记忆库中存入了大量以"微信小程序"为标题的经验总结：

但为什么这些记忆没能阻止那 5 次错误？

因为我们发现，Qoder 的记忆系统存在一个致命缺陷：它是"被动检索"的，而不是"主动过滤"的。

旧模式（日记本）： 记忆像是一本本散落的日记。"上次修过一个 CSS env 的 bug..." ------ 只有在报错发生后，AI 才会去翻翻日记。
新模式（规则书）： 我们需要的是一本"操作手册"。"❗在微信小程序中，禁止使用 env，必须用 JS API" ------ 这必须在代码生成前就成为不可触犯的红线。

为了解决这个问题，我们不再满足于让 AI "记住"经验，而是强制它"遵守"规则。

我们编写了一份名为 《微信小程序平台约束规则》 的文档，并强制要求 Qoder 在识别到 .wxml、.wxss 或 app.json 时，必须前置加载这套规则。

这份规则的核心，就是将之前的失败教训转化为不可动摇的"铁律"：

1. 核心原则：先识别，再限定

"先识别平台，再限定知识范围。禁止将父集平台（Web）的方案直接套用到子集平台（小程序）。"

2. 禁止项（❌ 绝对红线）

严禁混用 Web 知识： 一旦识别为小程序，立刻屏蔽 CSS var()、env()、document.getElementById 等 Web 特性。
严禁盲目迁移： 禁止直接将 Web 的安全区域适配方案迁移到 WXSS 中。

3. 必须项（✅ 强制执行）

刘海屏适配唯一解： 必须使用 wx.getSystemInfoSync() 获取状态栏高度，配合 wx.getMenuButtonBoundingClientRect() 计算胶囊位置，通过内联 style 动态注入。
隐私接口声明： 涉及位置功能时，必须在 app.json 中声明 requiredPrivateInfos。

当我们将这份 Rule 设定为"全局生效"后，Qoder 的行为模式发生了质的飞跃。

以前： 遇到导航栏问题 -> 尝试 CSS env() -> 失败 -> 报错 -> 检索记忆 -> 尝试 JS API。
现在： 识别项目为小程序 -> 加载 Rule -> 检测到"安全区域"需求 -> Rule 显示"禁止 CSS，强制 JS" -> 直接生成 wx.getSystemInfoSync 代码。

我们不再需要经历那 5 次无效的"试错"。AI 直接跳过了所有弯路，给出了第 6 次才找到的正确答案。

这次从"6次修复"到"规则驱动"的转变，是我们对 AICoding 工具使用方法论的一次重大升级。

我们意识到，仅靠"记忆"是不够的，必须建立"规则"。

规则（Rule）是 AI 通往可靠性的护栏。它帮助 AI 克服了知识的惯性，让通用的大模型在特定的业务场景下，能够精准地输出符合平台约束的高质量代码。未来，我们将继续构建更多这样的"约束清单"，让 AI 在正确的道路上，跑得更快、更稳。