零依赖 AI 应用的设计取舍：以设计灵感助手为例

一个反直觉的选择

做一个 AI 应用，默认思路往往是先接大模型接口。但在实际交付场景里，这个选择未必最优。最近做了一款面向服装设计的灵感助手，最终把它做成了零依赖、可离线运行的形态，过程中做了几组取舍，值得记录。

取舍一：规则引擎还是大模型

大模型的优势是覆盖面广、表达自然；劣势是输出不稳定、依赖网络、成本随使用量增长。规则引擎的优势是结果可控、零成本、断网可用；劣势是覆盖面有限、需要人工整理知识。

在评审与演示场景里，「稳定可复现」的价值往往高于「无所不知」。因此默认走规则引擎，把大模型作为可选增强：配置了接口就调用，没配置就本地生成。这样既保证演示不会翻车，也保留了后续升级路径。

// 前端检测后端能力，自动降级
const res = await fetch('/api/generate', { method: 'POST', body });
if (!res.ok) {
  return localEngine(input);   // 回退本地规则引擎
}

取舍二：黑箱输出还是可解释输出

AI 应用容易陷入「给结果不给理由」的陷阱。但设计场景的沟通习惯是讲清楚为什么：为什么选这个配色、为什么推荐这种面料。没有理由的建议很难被采纳。

因此每条建议都附带一句解释，例如「精纺羊毛：垂坠挺括，适合利落的直筒廓形」。这些解释来自结构化的知识库，而非事后补写。做法是把知识拆成三个维度：

• 风格：极简、复古、街头、浪漫、轻运动、新中式
• 场合：日常、校园通勤、正式、舞台
• 季节：春夏秋冬，影响面料厚薄与配色明度

每个维度独立维护，组合时按规则拼装。好处是扩展新风格只需加一份数据，不改代码。

取舍三：功能堆砌还是聚焦主流程

早期版本想加很多功能：趋势抓取、面料比价、社群分享。后来砍到只剩一条主流程：输入四个维度，输出一份方案。理由是演示时间有限，用户记住的往往只有一条最顺的路径。

砍掉的功能并没有浪费——它们变成了 README 里的「后续规划」，反而让作品的边界更清晰。评审看的是核心功能是否扎实，而不是功能列表有多长。

技术上的几个具体决定

纯前端实现。不引入任何框架与构建工具，页面、样式、逻辑拆成三个文件。代价是没有组件复用，收益是双击即用、零安装、评审无需配环境。

数据结构先于界面。先把规则库的数据结构定好，再写渲染逻辑。这样后续替换为大模型时，只需让模型输出同样结构，前端无需改动。

本地存储做收藏。用 localStorage 保存灵感卡片，避免引入后端与账号体系。虽不能跨设备同步，但对演示足够，且降低了复杂度。

如何判断这些取舍是对的

验证方式很朴素：让非开发者按 README 操作一遍，看能否在三步内跑起来；再看生成的方案能否直接用于讨论。两点都成立，说明取舍站得住。

另一个信号是修改成本。当想新增一种风格时，如果只需改数据文件而不是改逻辑，说明抽象是合理的。

小结

零依赖不等于低能力，而是一种把「稳定」放在「炫技」之前的工程选择。规则引擎保证下限，大模型提供上限，可解释性保证沟通效率，聚焦主流程保证演示效果。这四条合在一起，构成了一个能在真实场景里跑起来的小作品。