使用手册:我的构建，你的产品库—

上周二我在找一个构建项目，但想不起来给那次聊天取的名字了——大概是"落地页 v2"之类的，或者六周后已经完全没有意义的名字。这通常就是"我的构建"从可有可无变成你真正会用到的工具的时刻。生成第三、第四个应用之后，翻聊天记录列表去找你做过的东西，速度就会明显变慢，而这个库正是为了填补这个空缺而设计的。我一开始出于习惯在搜索栏里打了"admin"，然后放弃了，改用筛选器: 类型缩小范围到 Web 应用，类别再进一步区分内部工具和面向客户的工具，然后就找到了——第三张卡片，版本徽章显示 v3。我完全忘了自己又回去改过那次聊天两次。这个库显示的不是重复项，而是版本沿革。v1 和 v2 并没有消失，只是退出了默认视图，而这一点在大约十分钟后变得很关键，因为另一个项目上的客户不喜欢我作为 v4 发布的导航改动。我打开了旧的 v3 卡片，就地浏览了它的文件树，取出了两个关键文件，然后重新部署。不需要重新提示，也不需要翻聊天记录去还原之前的版式是什么样子。这就是卡片信息结构在你点开任何东西之前就已经发挥作用的地方:缩略图是验证通过后截取的真实截图，所以你看到的就是实际渲染效果，而不是一个技术上完成但加载时报错的构建。缩略图下方是类型和分类标签、版本号、相对时间戳。足够用来做初步筛选而不需要点击。而当你点击进去后，选项就很清晰地分成了两类——

预览会直接打开线上构建，无需下载，无需本地服务器。对于网站来说，这就是部署后的实际体验；对于桌面或移动端构建来说，这是不安装的情况下最接近实际运行效果的方式。
代码是可直接浏览的文件树。我经常用它做三十秒的快速检查——确认它确实用了我要求的库——然后再决定要不要下载。
操作菜单涵盖下载、发布、适用平台的原生安装包、符合条件时上架应用商店，以及另存为模板。

以上这些都不需要重新打开对话。我那天只回到原始聊天一次，是为了真正做一次修改，而这也是库唯一做不到的事情——修改需要上下文，而上下文存在于对话线程中。其他一切，库都能独立处理，与聊天并行运行，而不是作为回到聊天的快捷方式。在卡片上发布内容，下次打开那个对话线程时聊天会同步显示；在聊天里发布，卡片也会同步更新。同一个构建，两个入口。那天下午晚些时候，一位同事让我发一个我上周做的东西的链接，我发现自己没有把她引导进对话——我发的是卡片，说实话如果那时已经上线的话我会直接发布布上的 URL。没有人希望被丢进陌生人的聊天记录里去找一个文件。一旦团队里每人平均有超过一两个构建项目，这种分工就会很自然地形成:聊天保持为你的私人工作坊，库则成为其他人真正会用的东西。我那里还放着一个周末项目做的小游戏，这让我想起库并不是查看同一批数据的唯一视角。游戏和其他内容一样会出现在"我的构建"里，但它们也会出现在我的游戏中，按游玩模式和发布状态筛选，如果游戏是你主要的产出内容，那个视图会更适合日常使用。同样的逻辑也适用于 已发布，它显示任何拥有 URL 或处于商店排队状态的内容的当前上线情况，以及 已发布，用于追踪应用商店或扩展商店的审核状态。这些是针对同一批卡片提出的不同问题——"现在什么内容正在上线"和"我为某个主题构建过什么"——而不是拼凑起来的独立系统。有一件事第一次遇到时让我有点意外:发布一个构建并不会冻结它。我后来又回到那个管理面板的聊天里，要求了一处修改，得到了 v4——而已发布的线上版本继续提供 v3，直到我明确重新部署为止。想清楚之后其实很合理。如果对一个已上线的聊天随手一句提示就能破坏生产环境网站，那就没人敢再碰已发布的构建了。那周我做的另一件事，几乎是顺手为之，就是把那个管理面板另存为模板。这已经是我用基本相同的骨架做的第三个内部工具了——同样的布局、同样的身份验证脚手架、同样的表格组件，只是底层数据不同。另存为模板提取了结构和风格，而非具体内容，从它开始构建第四个项目，把原本要花二十分钟规划的对话缩短到了大约五分钟。问题在于模板会在你保存的那一刻被冻结——我的习惯做法后来有所变化，而旧模板并不知道这一点。作为一个你本来就打算在此基础上做出改动的起点，这没问题；但如果你想要的是能持续保持同步的复用方式，直接跨构建引用文件会比模板化更好。

没有任何内容会过期。六周前的那个 v1 版本，虽然位于版本历史中 v3 之下，仍然可以预览、下载、发布，和今天早上刚构建的东西一样容易获取。后台没有任何清理计时器在运行。这个库是一个可以随时用来发布的存档，而不是一个你要跟时间赛跑的历史记录页面。

手册

分享X LinkedIn Facebook Reddit Quora WhatsApp Telegram 邮箱

← 所有文章

手册:"我的构建",你的产品库

相关文章

BuildMidas 手册:平台全景地图

写出能构建出好东西的提示词

读懂计划(以及如何修改它)