十五年，专注同一个问题

2011 年——一个等待上架的店铺

当时我有一个 PrestaShop 店铺，只有一周时间把它填满。要创建两百款产品，其中大部分都有多种颜色和多个尺码。每个款式都必须成为一个独立的产品页，有自己的货号、图片和描述。

两天之后，账算得很清楚：照这个速度，我需要一个月。于是我停止手动录入，写了一个工具来替我完成。它简陋、难看，几乎谈不上有界面——但它能生成产品页并发送到店铺。一周就够了。

第一个工具教会我的事

问题不在于录入本身，而在于重复：同一款产品因为十二种颜色要录十二遍，每多一个销售店铺还要再录一遍。这种毫无附加价值的工作，吞噬了本该用来销售的时间。

现有工具没有抓住重点。CMS 自带的 CSV 导入能很好地处理大批量的结构化数据，但前提是文件已经存在且干净整洁。它们无法帮您创建款式、把一个产品页扩展成十二个，或同时为两个店铺供货。

真正的难点不在于构思，而在于每个 CMS 的细节。产品放进了子分类，却因为没有关联父分类而在哪里都看不到；税率在店铺中不存在，导致产品不含税就上线了；保存了的修改却始终没有同步到线上。每一个这样的坑，都让我耗费了数小时。

2026 年——ListoMax

ListoMax 就是 2011 年那个想法的完整实现。系列功能正是它的直系后代：填写一张表单，就能得到与所输入款式数量相同的完整产品页。

其余所有功能都围绕它构建，并根据真实店铺的需求不断打磨。父分类必须关联，产品才能出现在导航中；税率必须从店铺读取，而不是靠猜；重新发布时变体不能出错；图片必须真正上传；历史记录必须保留，以便随时回退。

每项功能在发布前都会在真实店铺上验证：PrestaShop 8、PrestaShop 9、WooCommerce。每次发布后，软件都会从店铺回读产品页，检查它是否收到了所发送的内容。这样开发更花时间，但这是确认它真正可用的唯一方法。

驱动开发的原则

绝无静默失败，永远如此。

使用 ListoMax 的客户不可能打开开发者控制台去弄清发生了什么。如果出现失败，他们必须在屏幕上看到，并知道是哪个产品受影响、原因是什么。看得见的错误可以修复；静默的错误会在无人察觉的情况下丢失数据。

这一原则带来了实实在在的影响。无法保存的修改必须明确告知；找不到的税率必须阻止发布，而不是让产品以错误的税率上线；未能上传的图片必须出现在错误列表中，而不是凭空消失。

这类细节在销售页面上从来看不到。但正是它们，决定了一个工具是被长期使用，还是三周后就被弃用。

一个独立项目

ListoMax 并非出自一家同时销售十几款软件的公司。它是一个独立项目，由同一个人开发和维护。当您写信给技术支持时，回复您的就是他本人。

这对您意味着：您的反馈会直接影响接下来的开发方向。多位用户提出的功能会被排到清单最前面。报告的 bug 会在下一个版本中修复，而不是两年以后。

这同样意味着：开发进度取决于一个人。我们宁愿事先坦诚相告，也不愿您日后才发现。