企业官网建设流程全解析

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

📉 一、 那令人“头秃”的 6 次失败

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

1. 前 5 次的挣扎：Qoder 像一个经验丰富的 Web 前端工程师，本能地使用了flex-shrink、env(safe-area-inset-top)和constant()。它在 CSS 的世界里反复横跳，试图通过微调样式来解决问题。
2. 第 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 在正确的道路上，跑得更快、更稳。