我用奇门遁甲给自己的 SaaS 做了一场代码审计

大多数人听到"奇门遁甲"，第一反应是算命。

但在我手里，它是一套符号系统——九星、八门、八神、九宫，本质是把一个复杂系统的状态，映射成一组可观察的"象"。星代表能量属性，门代表通道状态，神代表环境变量。它不是预测未来，是给当下拍一张结构化的 X 光。

我做了一个叫"境明"的 AI 奇门产品（qimenseek）。它能排盘、能解读、能分场景取用神。但做产品的都知道一句话：自己写的代码，自己看不清。

于是我干了件有点疯的事——给这个项目排了一盘，用"项目用神"的视角看它到底有没有病：

• 开门 = 功能是否通畅
• 值符 = 系统核心层
• 日干 = 我自己（决策视角）
• 天芮 = 病灶 / 缺陷
• 庚 = 阻碍 / 技术债

盘的象很集中，三处把"项目还有哪些问题"点得明明白白：

1. 值符（核心）临天芮病星、带死门 —— 核心层绑着没清干净的边界缺陷。带病，但不等于坏；只是病在核心，迟早会露。
2. 日干宫压着玄武 —— 我有盲区。玄武主"数据不实、看不清的东西"。这象太准了：我之前一份审计报告严重过时，一度要对已经修好的东西做重复修复，根因就是盲区。
3. 乾宫庚格 + 空亡 + 马星 + 螣蛇 —— 有个悬在 backlog 里的技术债重构，想动没动成、反复纠缠。正是"空亡 + 马星 + 螣蛇"的象。

排盘是视角，不是结论。我转头做了真实的代码审计，结果和盘象一一对上：

第一，盲区是真的。 我以为语译库缺一堆格局、Prompt 路径断裂，逐行核对后发现，7 月那次更新早把这些修好了。原报告基于更早的版本，已经失效。这本身就是"玄武"的现实验证——靠人眼审，必有盲区。

第二，安全漏洞是真的。 用扣子改的前端，为了让网页能调通 API，把后端同一个 API Key 明文写进了浏览器 JS。而后端鉴权是开着的（ENABLE_AUTH=true）。等于把钥匙挂在门上，任何人开 DevTools 就能拿走你的密钥随意调接口。

第三，半截活是真的。 一个 checkAPIError 错误处理函数，定义了却没被任何地方调用。用户真遇到 401/429/504，代码会直接把错误体当正常结果解析，白屏或异常。写了等于没写。

第四，最隐蔽的雷是真的。 原文件里一行 replace(/\n/g 被真实换行截断成了两行，导致整个 script.js 语法非法、整页 JS 无法解析。单宫解读功能整个是废的——只是日常路径碰不到那条分支，没人发现。

这些我全修了：

• 删掉前端 7 处明文 Key，公开排盘接口改为免鉴权白名单，管理类端点保留校验——既消除了"钥匙挂门上"，又没废掉鉴权机制；
• 把 checkAPIError 接进全部 7 个 fetch，401/429/504 现在真能拦截；
• 合并那行被截断的正则，整页 JS 恢复解析；
• 部署后端到端验证全绿：前端 Key 计数 0、公开端点免 Key 返回 200、非公开端点带错 Key 返回 401。

但技术修好，不等于产品能跑通。我又用运营视角盘了一遍，结论很扎心：技术底座扎实，但"建好庙没人来上香"。

• 页面零私域入口，用户用完即走，零留存；
• 首屏 CTA 弱到只有一句文案"遇事不决，可问"，没有明确的行动按钮；
• 搜索引擎权威为零，GSC 没验证，结构化数据近乎空白。

于是又改了 index.html：首屏加「🌀 免费起一局」按钮、页脚加联系入口、补 GSC 元标签，顺手修了个把 og:url 写成错误旧域名的 bug。

有意思的是，运营盘象和技术盘象同源。开门寄坤、生门被庚辛白虎冲克——"获客和体验差一口气"，在真实的流量和转化数据里得到了验证。

最后说句实在话：奇门是决策辅助的视角，不是玄学兜底。项目有没有病，最终靠代码、靠测试、靠用户说话。但作为一套把"我看不清的东西"逼出来的框架，它确实比单纯拍脑袋强——至少它逼我去核对了那行被截断的正则，也逼我去查了那个被明文写在前端的 Key。

境明：不替你做决定，只帮你照见真相。包括你自己的代码。