第三阶段
一个网站、一个看板，以及驱动这一切的机制
书面描述变成三个真实的界面：castomUI 上的网站、dash-b 中的运营看板，以及执行实际工作的 castomFLOW 工作流。不是它们之间的模型——而是三个可以打开、编辑和关闭的产品。
这三个产品由同一份文档构建，并行进行，由三个被设计为放在同一架子上的系统完成。这比听起来更重要：看板上的标签与网站上的措辞一致，因为两者都由同一段落生成，而不是因为有人记得让它们保持同步。
之后，下面的一切都在各自的编辑器中打开。castoMIND 组装第一版；它不拥有它、不锁定它，也不要求你必须通过 castoMIND 才能修改一个标题。
三个界面
构建什么，由家族的哪个部分构建
网站——castomUI
页面、文案、品牌，发布在一个地址上。文案根据描述撰写，因此网站论证的是文档所论证的观点，而不是模板所假设的观点。
看板——dash-b
运营产品所依据的看板，第一天就布局完成。dash-b 是一个实时看板设计器，支持 86 种语言，并从底层平台自动填充内容。
工作流——castomFLOW
实际运行它的步骤：变成发票的订单、第三天的提醒、每夜的对账。在需要确定性之处保持确定性，在真正需要判断之处使用 AI。
文件夹就是在这里不再空着的。
看板在第一个客户出现之前就已存在
这是不寻常之处，而且是刻意的。大多数新产品在大约四个月后才建立度量，那时终于有人问复购率是多少，却没人能回答。到那时，最初四个月已无法挽回——数据从未被收集，因为没有任何地方在收集它。
第一天就把看板立起来只花几分钟，却能让第一个月就有数据。而恰恰是这个月的数据，决定有没有第二个月。
一个小小的异端观点：在第一周，看板比网站更有用。网站是给你还没有的客户看的；看板则是让你弄清楚为什么还没有他们。
- 1网站结构根据描述所暗示的内容选定页面。有价格，就有价格页。
- 2文案已写好基于已写好的方案，用品牌的语气，用你要求的语言。
- 3图片免版税，来自平台媒体库，许可和署名信息附在文件上。
- 4看板已布局这类产品生死攸关的四五个数字。不是四十个。
- 5工作流已搭建描述中暗示本来需要有人手工完成的每一步。
- ·然后由你打开它们三个编辑器，三个普通产品。没有任何东西是生成后即冻结的。
一份描述，支撑全部三个之后一切皆可编辑
工作流实际覆盖的内容
描述说明产品做什么，而产品做的事大多是重复性工作，本来需要有人在早上九点手工完成。这些就变成工作流：一张订单变成一张发票；一个注册用户在第三天收到欢迎和跟进；一张供应商订单被拆分、发送并催收；一份月度报告在每月一号自动生成。
castomFLOW 刻意不在每一步都放一个模型，castoMIND 继承了这份克制。一次对账不需要判断力，它需要的是每次都以同样的方式发生同样的事。真正需要判断力的步骤——给这条消息分类、起草那封回复、在三个选项中做选择——才会用到模型，而且只对这些收费。
结果是一套你读得懂的机器。当第二个月出了问题，会有一条运行日志，记录它走了哪个分支、哪些值决定了走向，而不是耸耸肩加一个听起来合理的猜测。
三者共同的底层
三者都构建在 castomAPI 之上，这就是为什么它们都不需要外购任何东西。网站的图片来自一个可搜索十一家供应商的免版税图库，并保留许可信息。地址和国家字段对照 3480 万行真实参考数据进行校验。工作流可以发送电子邮件、短信或推送、收款、提供预约时段或生成短链接，全部使用最初登录的同一个账户。
这些都不是需要任何人搭建的集成，也没有需要轮换的密钥。它是整个家族立足的地基。