用 Claude 先理清配置器规则，再写三维代码

3D 产品配置器最显眼的是模型旋转、材质切换，但作者认为，更容易出错的是藏在目录和报价表里的业务规则：某个选项只能搭配特定框架，某种组合到底该加多少钱。他用 Claude 先整理这些规则，再动手写 Three.js。

这套做法值得看的地方，是把 AI 的任务收窄到需求建模：整理选项、提取约束、拆解计价，并找出资料没讲清的地方。它提供了一种让客户更早参与确认的项目启动方式，但原文没有给出效率或准确率的对照数据。

配置器容易出错的地方，在产品资料里

作者接到的输入通常是一份 PDF 宣传册、一张价格电子表格，以及几封补充说明邮件。资料涉及 4 条产品线、几十个选项，搭配限制则散落在文字中。

这些内容要变成程序，至少要回答三类问题：用户能选什么，哪些选项能一起选，选完之后如何计价。难点是三者会互相影响。选项本身存在，并不代表它适用于所有产品；某项收费有说明，也不代表所有组合下的计价方式都已明确。

作者说，手工整理很慢，而且自己总会漏掉规则。这是他的项目经验，原文没有提供遗漏次数或故障案例。但问题很具体：如果规则没确认，前端就无法准确限制选择，后端也缺少明确的计价依据。

先把业务规则写清楚，渲染和报价才有共同依据。

Claude 要交付四份结构，而不是应用代码

作者把原始资料交给 Claude，要求它输出四类结果。

第一份是选项模型，覆盖每个产品、选项组和可选值，并整理成可放进数据库的 schema，也就是描述数据结构的约定。原文没有展示具体字段，不能把它理解成一份已经验证过的通用数据库设计。

第二份是合法组合矩阵，把文字中的「可以搭配」「不适用于」整理成明确约束。遇到含糊之处，要标成向客户提出的问题，不能自行补全。

第三份是计价骨架，用伪代码写出基础价格、附加费用和按单位计算的规则。作者先看清计算结构，再写 PHP。这里交付的是待确认的计价逻辑，还不是可直接执行的报价实现。

第四份是待确认问题。作者认为，这是最有用的输出。例如，宣传册分别解释了两个选项，却没说它们同时被选中时怎么办，这个缺口就应该回到制造商那里确认。

没有说明的规则，应当变成问题，不能悄悄变成默认行为。

客户认可选项模型和规则之后，作者才进入 Three.js 与 Laravel 的实现：场景加载模型，界面选项映射到已定义的数据结构，服务端实现已经写明的计价规则。按他的描述，主要思考提前发生在自然语言阶段，修改成本也更低。

我的判断

我赞同把「待确认问题」当成正式交付物。配置器是否正确，取决于它有没有准确表达制造商的限制。画面可以正常运行，业务结果却仍然可能出错。

但 Claude 能整理资料，不代表它能保证规则完整。原文没有交代提示词、输入材料规模、结果复核方式，也没有展示矩阵和 schema 的样例。模型能找出一些缺口，同时仍可能漏掉另一些。作者关于「更适合用语言模型处理这类工作」的判断，目前属于经验之谈。

相比直接让 AI 生成配置页面，这套流程多了一次业务确认，产物也更容易让客户讨论。相比人工梳理，它有望减少初步整理的负担，但原文没有给出节省时间或减少错误的数据，不能据此承诺收益。

它还有一个前提：客户能参与确认，而且有权解释产品规则。资料互相冲突、制造商内部也没达成一致时，Claude 最多帮助暴露矛盾，最终规则仍需要业务方决定。

能拿来做什么

• 接到产品配置需求时，可以先让 Claude 分别输出选项模型、合法组合矩阵、计价伪代码和待确认问题，再安排页面与接口实现。
• 做 Three.js 配置界面前，先让客户确认哪些值可以选择、哪些组合受限，给控件状态和场景变化建立明确依据。
• 实现服务端报价前，先逐条核对基础价格、附加费用和按单位计算的规则；使用 Node 的团队也可以沿用这一步，但原文的后端实践是 PHP 与 Laravel。
• 把已确认规则和未解决问题记录进仓库，供后续开发查阅。作者提到自己会在每个仓库记录这套工作方式，但没有展开具体文档格式。