Kitpilot

过去二十年的电商，解决的是同一件事：把商品搬到线上，让你更快找到它。搜索框、推荐流、比价工具，本质都建立在一个假设之上：用户已经知道自己要买什么，只是需要找到、找便宜。

但人真正的需求，很少是「一件商品」。是「下周末第一次去露营，别踩坑」，是「六千块配一台安静的白色游戏主机」，是「周末去市集，想出片但别太用力」。这些是任务，不是 SKU。

在 LLM 之前，把一个模糊任务翻译成一整套相互兼容、预算合理、不漏项的商品组合，成本太高，只能靠人来做：数码博主、买手、攻略帖。 LLM 第一次让「理解一个任务」变得便宜。

所以我的判断是：AI 给电商带来的不是「会聊天的导购」，而是入口本身的迁移：从商品中心到场景中心。用户不再输入关键词，而是描述场景；系统不再返回列表，而是生成一份可购买、可替换、可调整的 Kit。

“搜索框假设你已经知道要买什么。但很多时候，我们只知道自己要做什么，还不知道要买哪件。

Kitpilot 是我把这个判断做成的可交互原型。下面这台手机是真能点的，可以先玩，再看我怎么想。

Kitpilot 是一个 C 端 AI 场景电商策展产品。一句话：你告诉它「我要做什么」，它给你一整套可购买、可替换、可调整的方案。

它刻意避开两样东西：商品搜索和聊天机器人导购。

不是商品搜索。你不需要先知道自己要买什么，你只需要描述场景。

也不是聊天机器人导购。它的输出不是一段自然语言，而是一份有结构的清单：预算、关键指标、风险提示、按用途分组，每一行都可以点、可以换、可以调。

上面三个场景已经走过：露营是门面、装机是深度、穿搭是广度。它们共用同一套 Kit 模板，差异完全来自数据，不靠场景专属代码分支。后面会展开这套系统是怎么收敛成一套的。

今天打开任何一个电商 App，商品是过剩的，不是稀缺的。真正稀缺的是「把一堆商品组织成一个能直接照做的方案」这件事。而现状的两条路都不够：

• 搜索 / 推荐：给你一千个帐篷，却不告诉你这一千个里哪八件能凑成「你这次露营真正需要、互相不冲突、又在预算内」的一套。组织成本，全压在用户身上。
• 聊天机器人导购：能聊，但输出是一段自然语言。你没法点、没法替换，也看不到换一件之后预算和兼容性会怎么变。它把决策又退回成「读一段文字，然后自己去搜」。

Kitpilot 想补的，正是中间这层：从「商品」到「方案」之间的组织工作，交给系统来做。

“用户大多不缺选项，缺的是有人帮他把一堆选项收成一个能直接照做的决定。

有一个很容易踩的坑：三个场景，做三套页面。那样每加一个场景就是一次重写，而且根本证明不了「这是一个系统」。

所以我逼自己先想清楚一件事：三个场景里，什么是场景无关、能共用的，什么才是场景独有的。它落在两个层面：你看到的（渲染），和你操作的（交互）。这两层，我都想收敛成一套。

渲染：一份模板，三份数据

三个场景共用同一个 Kit 模板。场景之间的差异，包括指标（露营看重量、装机看电源、穿搭看复用）、风险提示、商品分组、模块名称，全部来自数据，不来自代码里的场景分支。

补充提问也是同一逻辑：不为每个场景做专属问卷，而是复用少量问题组件（单选、区间、已有物品、自由文本），靠数据装配。

想清楚这条边界之后，加第四个场景的成本就是「填一份数据」，而不是「写一个页面」。这既是产品判断，也是它能不能规模化到几十个场景的前提。

交互：从三套收敛成一套

渲染统一了，交互我却先做岔了。第一版我给每个场景的结果页底部堆了不同按钮：有的有替换、有的有调整，三个场景三个样。点起来不一致，也暴露出我其实还没想清楚它们是同一件事。

于是收敛成两条统一规则：

• 替换进列表：取消底部的「替换」大按钮。直接点商品行，弹出这件商品的替换页（同品类候选；装机场景里，每个候选旁边还会带一个兼容状态的小标记）。替换是「就地」发生的，符合直觉。
• 调整全场景通用：底部只留一个「调整方案」。点开是一个对话框（推荐方向 + 自由输入），用户说想怎么改，生成改动前后的对比，确认后回到主页替换对应商品。

状态上，我把它泛化成一个 overrides 映射（原商品 id → 替换 id）。预算、重量、件数、兼容状态，全部由 buildKit(场景, overrides) 实时重算。换一件，所有指标和风险即时更新。

收益很直接：三个场景的底部操作完全一致（调整方案 / 打包），交互模型只有一套，用户的心智负担降到最低。

“统一不是为了好看。当时我给三个场景做了三套交互，其实是因为我还没看出来：它们本来是一回事。

做这个产品，我想得最多的一个问题是：哪些事可以交给模型，哪些最好别交。

LLM 负责它擅长的：把模糊的自然语言场景翻译成结构化需求、补齐用户没说出口的隐含约束、为每件商品解释「为什么是它」。这些是语言和常识问题，模型做得好。

但有一类事我坚决不交给模型：硬约束。预算够不够、这套装机能不能点亮、有没有漏掉必需品、用户已有的东西要不要复用。这些是确定性问题，答案非黑即白，错了就是真的错了。让模型「猜」兼容性，等于把一件本来能算准的事，变成一件可能翻车的事。

所以架构是分层的：LLM 负责理解与解释，规则引擎负责裁决硬约束。模型可以建议一块显卡，但「这块卡配这个电源够不够」由规则说了算，不由模型的语气说了算。

“模型负责听懂你要什么，规则负责保证它不会给你一套点不亮的电脑。

装机是检验这套思路最好的场景，因为它的需求里全是不能商量的物理约束。我写了一个 deterministic 的规则引擎，读取每件商品的 specs，跑五条规则：

• CPU 与主板的插槽必须匹配
• 主板支持的内存类型（DDR）必须和内存条一致
• 显卡的推荐电源瓦数，不能超过电源的供给能力
• 机箱要放得下主板的尺寸规格
• 显卡长度不能超过机箱的显卡限长

引擎输出三态：兼容通过 / 需确认 / 不兼容，直接驱动 Kit 顶部的状态条。这里有个刻意的设计：不是「非通过即失败」的二元。中间留了一个「需确认」的黄色状态：比如换上一块 7800 XT，它的推荐 700W 超过了当前 650W 电源，系统不会粗暴判死，而是标黄提示「需确认电源」，把判断权和信息一起交还给用户。

替换商品时，每个候选项旁边会实时算出兼容 chip （电源足够 / 机箱可放 / 需确认电源），让用户在「换之前」就看到后果，而不是换完才发现冲突。上面那台手机切到装机场景、点任意一块显卡，就能看到这套规则在跑。

为什么我最看重这一段

它是整个产品最不像「AI 套壳」的地方。 Prompt 谁都能抄，但把一个领域里的硬约束，显式编码成可解释的规则，是产品判断，不是模型能力。这也是我做 Offerpilot 时就有的体会：真正花时间的地方，常常不在模型本身。

为什么第一版不做真实电商闭环

真实商品 API、支付、购物车，我都有意没做。这一版要证明的东西，不在那里。

真实电商闭环会立刻把精力吸进商品数据、价格库存、交易售后、平台对接，这些是运营和工程问题，不是产品判断问题。而这一版我想证明的恰恰是产品判断：场景中心的入口成不成立、LLM 与规则怎么分工、一套系统能不能迁移多个场景。 mock 数据足够把这些讲清楚。

这个 demo 证明了什么、没证明什么

证明了：形态成立。从场景输入到可操作 Kit 的闭环是顺的、可解释的、能迁移的；把硬约束交给规则引擎是对的。

没证明：真实场景下 LLM 的需求理解准确率、真实商品库的覆盖与价格、以及用户是否真的愿意用「场景」而不是「搜索」作为入口。这些要真实数据和用户测试才能回答，这一版还没有。诚实说，这就是它和一个真实产品之间的距离。

下一步

• 接一个真实 LLM 做需求理解（现在是 deterministic 的 demo flow），看它在「翻译模糊场景」上的真实表现。
• 把规则引擎从装机扩展出去（露营的季节与温区、穿搭的场合与天气），验证「硬约束可解释」这件事在更多品类成立。
• 找几个真实用户，看他们会不会自然地用「场景」开口。这是整个判断最该被证伪的地方。

如果电商真的会从商品中心走向场景中心，那最难的大概不是让 AI 多说几句话，而是让它给出一套你敢照着买下去的方案。 Kitpilot 是我朝这个方向走出的第一步。