最近我在 Qoder我们的 AI 编程助手身上经历了一次深刻的“复盘”。这源于一个看似简单的微信小程序开发任务——自定义导航栏在刘海屏上的适配我之前项目qoder能很好的完成任务但这次却是令人失望。 一、 那令人“头秃”的 6 次失败事情的起因很简单我们需要在 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 的记忆库中存入了大量以“微信小程序”为标题的经验总结“微信小程序 WXSS 不支持 CSS 变量”“微信小程序导航栏适配经验”“小程序刘海屏适配禁用 env”但为什么这些记忆没能阻止那 5 次错误因为我们发现Qoder 的记忆系统存在一个致命缺陷它是“被动检索”的而不是“主动过滤”的。旧模式日记本记忆像是一本本散落的日记。“上次修过一个 CSS env 的 bug…” —— 只有在报错发生后AI 才会去翻翻日记。新模式规则书我们需要的是一本“操作手册”。“❗在微信小程序中禁止使用 env必须用 JS API” —— 这必须在代码生成前就成为不可触犯的红线。️ 三、 制定“铁律”让规则全局生效为了解决这个问题我们不再满足于让 AI “记住”经验而是强制它“遵守”规则。我们编写了一份名为《微信小程序平台约束规则》的文档并强制要求 Qoder 在识别到.wxml、.wxss或app.json时必须前置加载这套规则。这份规则的核心就是将之前的失败教训转化为不可动摇的“铁律”1. 核心原则先识别再限定“先识别平台再限定知识范围。禁止将父集平台Web的方案直接套用到子集平台小程序。”2. 禁止项❌ 绝对红线严禁混用 Web 知识一旦识别为小程序立刻屏蔽 CSSvar()、env()、document.getElementById等 Web 特性。严禁盲目迁移禁止直接将 Web 的安全区域适配方案迁移到 WXSS 中。3. 必须项✅ 强制执行刘海屏适配唯一解必须使用wx.getSystemInfoSync()获取状态栏高度配合wx.getMenuButtonBoundingClientRect()计算胶囊位置通过内联style动态注入。隐私接口声明涉及位置功能时必须在app.json中声明requiredPrivateInfos。 四、 优化后的 AICoding 体验当我们将这份 Rule 设定为“全局生效”后Qoder 的行为模式发生了质的飞跃。以前遇到导航栏问题 - 尝试 CSSenv()- 失败 - 报错 - 检索记忆 - 尝试 JS API。现在识别项目为小程序 -加载 Rule- 检测到“安全区域”需求 - Rule 显示“禁止 CSS强制 JS” - 直接生成wx.getSystemInfoSync代码。我们不再需要经历那 5 次无效的“试错”。AI 直接跳过了所有弯路给出了第 6 次才找到的正确答案。 五、 结语规则是 AI 的“护栏”这次从“6次修复”到“规则驱动”的转变是我们对 AICoding 工具使用方法论的一次重大升级。我们意识到仅靠“记忆”是不够的必须建立“规则”。规则Rule是 AI 通往可靠性的护栏。它帮助 AI 克服了知识的惯性让通用的大模型在特定的业务场景下能够精准地输出符合平台约束的高质量代码。未来我们将继续构建更多这样的“约束清单”让 AI 在正确的道路上跑得更快、更稳。