0809 | Basedash 订阅、Toolport MCP 网关、Hexis 与 GTM Co-Founder 速览

林岚: 欢迎收听 Bri 的《ProductHunt 产品分享》，我是林岚。

陈序: 我是陈序。这期我们聊到几样东西，有的是帮你管理自家技能的，有的是把整个太阳系搬到屏幕上的。

林岚: 还有一款让开发工具创始人订阅并管理自家产品数据的功能，和一个全新的本地工具连接方案。

陈序: 另外还有一件面向独立开发者工具创业者的开源作品。咱们这就开始。

陈序: 先讲一个新上线的东西，叫 Basedash Subscriptions。它是一个能帮你把仪表板数据按计划自动送到邮箱或 Slack 的功能。创始人说，做这个的出发点很日常：每个团队总有那么一个人，要记得在开会前打开仪表板截图、再把图贴到某个地方。这个功能想做的就是把这个差事去掉。它在八月八号正式发布，官方说今天对所有用户开放。

林岚: 所以它就是把截图这种手动事务自动化了对吧。那设置起来麻烦吗？

陈序: 官方说很简单，点一下创建订阅就算完成，没有第三步。你在任意一个仪表板或图表上选订阅，然后用自然语言写日程，比如每周一早上九点，它支持每天、工作日、每周某一天，甚至季度这样更长的节奏。同一个仪表板还能叠加多个订阅。

林岚: 听起来它设想的就是固定的汇报仪式，比如周一复盘、季度董事会材料那种。

陈序: 没错。官方举了一个很具体的例子：一个收入仪表板可以同时配三个订阅——给高管团队邮箱发每日摘要，周一早上把一条东西发到指标频道，再给董事会发一份月度快照。三个订阅、三个日程、三个受众，中间不用任何手动操作。投递方式上，Slack 里每个图表直接以图片嵌入，团队不用点链接或登录就能看到数字；邮件里除了内联图表，还有一个跳回实时仪表板的按钮。

林岚: 那发出去的数字是旧的还是当时的？

陈序: 官方声称图表是在投递那一刻从实时数据渲染的，所以不会发过期报告。而且它是有意保持简单，只发送仪表板现有的样子；如果你想要它按计划做分析、总结一周或者标记异常，那属于另一个叫 Automations 的功能。创始人还提到，他们团队自己已经在内部用：周一的收入复盘和每日的关键指标摘要，会在站会前出现在 Slack 里，之后没有人再手动发过仪表板截图。

林岚: 我想知道它调度的时候是按谁的时间区来算的。我在社区里看到有用户问了这个问题，但现有资料里没有回答。要提醒的是，这些功能描述、效果和内部使用情况都来自厂商的博客和社区帖子，属于厂商自己说的话，不是独立验证过的结果。

林岚: 接下来聊一个开源工具，叫 Toolport。它是一个完全本地运行的 MCP 网关，一句话说就是，每个工具一个端口，让所有 AI 代理共用同一套 MCP 配置。做这个的开发者 Tyler 说，起因是他反复为各种客户端各自维护配置文件，同一批 API 密钥得一次次明文粘贴，维护起来很烦。

陈序: 那它解决的第二件事是什么？我记得提到过，接入服务器之后还会有别的麻烦。

林岚: 对，第二个麻烦是上下文被占满。每个 MCP 服务器都会把完整的工具列表塞进对话里，开发者实测，三个服务器在还没问任何问题之前，光工具定义就消耗了大约两万四千个 token。Toolport 的做法是在代理和服务器之间插一层网关，只暴露少量的元工具，让代理真正需要的时候再按需去搜工具，而不是一次把几百个定义全部载入。

陈序: 那这些数据都是他自己测出来的吧？

林岚: 是的，这些数字都是厂商自报、没有独立验证的。比如在一个前沿模型上，相同任务成功率下总 token 最多能减少百分之九十一；在一个几百个工具的真实目录上，定义的开销降了百分之九十九点多。

陈序: 除了省 token，它还有别的动作？

林岚: 有。它支持最新的 MCP 规范，旧客户端和旧服务器不受影响。还有一个代码模式，能让代理把一整串工具运行成一个服务端脚本，避免每一步调用都经过模型往返。安全这块做得比较细：密钥存在操作系统钥匙串里，运行时注入，不落进配置文件，也不上云；还给每个工具做指纹，用来标记那种批准之后定义被改动的行为，以及工具描述里藏了指令的投毒。疑似注入的工具输出会被当数据处理而不是当指令处理，破坏性的调用可以暂停下来等人工批准，还能一键隐藏所有破坏性工具。

林岚: 它支持哪些客户端和服务环境？

陈序: 客户端方面最多支持三十三个应用，包括常用的那几个；另外有一个不依赖桌面的无头 Docker 网关版本。支持 Windows、macOS 和 Linux，不用注册账户，也没有云依赖，代码是 MIT 许可，流量不经过开发者的服务器。还给团队做了个版本，让团队共享一批受治理的服务器，但密钥各自留在自己机器上，最多五个人免费。

林岚: 不过社区里有个挺重要的未决问题：有人已经在别的客户端里用延迟加载的方式来绕开同样的痛点，他提出一个没人量化过的权衡——如果一次对话最后真的需要调用八九个不同的工具，那搜索调用本身会不会变成额外的开销，省下来的 token 还成不成立。这确实是个值得继续看的问题。开发者那边则请用户提名希望下一步支持的客户端或服务器，说这个清单会直接决定他们的路线图。

林岚: 先看一个刚在 Product Hunt 上线的项目，叫 Hexis。它给自己的定位是“给 AI 代理用的技能、工具和上下文”，说白了，它是一个叫 Bevel 平台的开源代码核心，想把一家公司的 AI 技能、工具和知识集中起来，做统一的管理、审查和访问控制，然后通过一个叫 MCP 的通用接口，让任何 AI 代理都能调用。团队自己说，之所以做这个东西，是因为大家以前习惯把技能和上下文塞进 GitHub 仓库，但那些不懂代码的人就不得不去学一整条 Git 工作流，而且 GitHub、GitLab 这类平台又没法做基于文件的访问权限管理。Hexis 就是在 Git 之上套了一层非开发者友好的界面，底下仍然保留版本控制和合并请求机制，只是改由管理员来批准变更，并决定每个人、每个团队、甚至每个代理能访问哪些上下文、工具和技能。

陈序: 所以对一家公司来说，员工只要一次性连接，把工作区加进 Claude Code、ChatGPT、Cursor 或者任何支持 MCP 的代理，就能按角色去用技能和知识，不用在每一个代理里单独配项目，也不用来回传递各种工具的凭据。底层其实是用户自己拥有的 Git 仓库，可以放在 GitHub、GitLab、Bitbucket、Azure DevOps 或者自己托管的环境里；技能以文件夹形式保存，工具手册用另一种格式编码，还带加密的密钥库，并且内置了分支、变更请求加所有者审批、基于角色的访问，以及一个远程 MCP 服务器。官方宣传里特意强调它跟代理厂商完全解耦——你可以按价格、按性能随便换代理，甚至不同任务混着用，都不必重建代理的知识；而且每条变更都有作者和回退路径，规则对人和代理一视同仁。

林岚: 社区里有些人分享了一手的体验，但证据不多。有位评论者说，切换代理、为各种任务创建后台代理变得非常容易，还建议想用的人先去那个公共演示站点测一测，再考虑自托管。不过也有人抛出两个到现在都没被回答的治理问题：如果一个技能名同时出现在团队级技能和项目级的本地覆盖这两个层级上，Hexis 是自动选更具体的那份，还是得靠管理员手动解决冲突；再有就是两个团队提交了同一个技能的竞争版本，到底走的是标准的合并请求审查，还是有单独的治理步骤。这两个问题直接影响它作为一层技能治理的可信度，但目前都还是开放问题。

陈序: 想自己部署的话，官方声称五分钟用 Docker 就能起一个，需要 Docker Compose，再加一个任意主机上的空 Git 仓库来放知识库，首次运行会自动播种一套启动模板。公共演示用 Google 账户就能登录，里面内置了一家虚构公司的知识、技能和工具，整体以共享和只读为主，访问者可以提议改动，由所有者来批准；也有托管实例的选项，官方说包含托管、升级、备份和单点登录。代码仓库采用 Apache 二点零许可，现在页面显示大概三百多次提交。不过要强调的是，以上这些能力基本都来自官方自述或者个别评论者的经验，并没有作为验证结果呈现，也谈不上有共识。

林岚: 而且像 Hexis 这类产品，真正的考验其实是等它被更多真实团队用起来之后，前面那两个治理问题有没有一个明确答案——因为对一家想把公司级技能管起来的组织来说，冲突怎么裁决，往往才是敢不敢上的关键。

陈序: 这一批简报里另一款产品叫 The GTM Co-Founder，是给独立技术开发者工具创始人做的一套开源的“市场进入”技能。它要解决的问题，按创始人的说法，是大多数 AI 给做开发者工具的创始人提供的，都是泛泛的销售和营销建议。它的做法是：先访谈你一次，了解你真实的产品和市场，然后一步步给出排好优先级的市场进入路线图，覆盖目标用户、定位、前五十个用户、发布和定价这些环节。

林岚: 产品官网写得更直白——回答五个问题，就能拿到一份排好优先级的路线图。它是免费的，MIT 许可，运行在你已经在里面编码的那个代理里，页面展示的是 Claude Code 环境，通过一条命令就能装，需要 Node.js。它的方法论据称建立在两个业内实战手册的基础上，再加上创建者本人做过创始 AE 和 GTM 顾问的经历。不过这些目前都属于制造者自述，不是经过独立验证的结果。

陈序: 社区评论给了几个经验性的信号。有位评论者说，他在自己的 beta 产品上试过，拿到的是“非常出色且详细的分析”，并表示以后会经常用。也有其他人调侃网站设计“粗暴”、README“读起来像独处技术创始人的治疗”，但确实欣赏它把市场进入看作一组可复用的技能，而不是又一个通用的 AI 聊天。

林岚: 与此同时，评论者也提出了一些还没得到回应的开放问题：怎么长期保持定位、定价、发布之间的上下文一致，避免建议随时间互相矛盾；怎么处理知识漂移；能不能接入 ChatGPT；而且把产品的影响力跟某个具体的 AI 技能生态绑在一起，是否存在依赖风险；还有一点，它的路线图是不是主要停留在发布前的定位，能不能真正覆盖从“没人链接泛泛内容”到“值得被链接”这个具体差距。这几点都悬而未决。

陈序: 所以这份简报里就这两款开源产品，都是帮开发者代理变得更“会干你的活”的思路——Hexis 管的是组织层面的技能治理，而这个 GTM Co-Founder 管的是创始人个人那一套市场进入路线。它们的共同点也很明显：价值信号大多来自制造者自述和个别评论者的使用反馈，共识性的验证还很缺，那些没被回答的治理和一致性问题，恰恰是它们接下来最值得关注的观察点。

林岚: 有个叫 AstraPixels 的项目，把太阳系做成了像素画地图，而且它有个很明确的主张：上面所有天体都显示在真实的当前位置。也就是说，位置不是随手画的，也不是从现成列表抄的，而是用 astronomy-engine 这个库、按已发布的轨道要素算出来的。用户可以放大缩小，从太阳一路看到柯伊伯带，还能打开一百七十一个已编目天体，看每条带来源的事实。此外它还能看未来六个月的天象——合、冲日、流星雨、日食月食都在里面。

陈序: 更特别的是它允许时间推进，也可以切到所谓的“真实比例”。制作者说，一旦切到真实比例，就好比把地图真正摊开看，它到底有多大程度“在对你撒谎”，一下就看出来了——因为平时为了好看，比例其实是严重失真的。

林岚: 商业设计上这套玩法也很直白。每颗小行星定价五美元，一次性买断、永久保留，然后可以随意命名；月亮要四十九美元。而太阳、八颗行星的皮肤和彗星，是只租不卖的。主带那三千颗小行星是程序生成的岩石，制作者说这样能保证五美元的底价库存永远不会卖完。

陈序: 不过得说清楚，这个命名只显示在 AstraPixels 这个网站里面，不是国际天文学联合会 IAU 的正式命名，也不会提交给任何机构，所以天文台不会承认。官方的小行星命名只能由 IAU 分配，而且不可购买——这段披露会出现在每一个显示自定义名称的页面上。连账户系统都很随意：没有注册流程，Stripe 要个邮箱，就算是整个账户了。

林岚: 还有个挺有趣的维护细节。地图上的链接每个月检查一次，如果连续三次失败，这颗岩石就会变成可见的“衰败废弃精灵”，库存也会被回收。制作者说参考的是当年百万美元首页那种模式，那里大概百分之二十二的链接在十年内就失效了。网站落款是 astrapixels 点 com，标着 2026 年，由 @nicklaunches 制作。

陈序: 制作者自己说最没底的一件事，就是这张地图到底会被当成玩具还是仪器。社区反馈也正好分成两派：有用户说第一眼是玩具感，但用了时间轴和真实比例之后觉得更像工具，天象页很实用，只是移动端缩放有时不稳；有人已经认领了 Juliet 这颗小行星，还夸放大之后的视觉效果；但也有批评者觉得图形太弱，就没再深入了解；还有人找不到地球绕太阳的椭圆轨道。

林岚: 另外有个开放式问题目前没看到答复：认领命名后的自定义名称，其他访客能不能看到，还是只在自己会话里可见。其实这个问题挺关键的，因为它直接决定了花五美元买一颗石头,到底是“买给别人看的地图地标”，还是纯粹买给自己的一份私人乐趣。

林岚: 好，今天的简报到这里就接近尾声了。我们聊了 Basedash 让开发者可以订阅任意应用的版本，聊了 Toolport 这样把 AI 代理的 MCP 配置集中起来、一种配置到处用的开源工具，还有 Hexis 想把公司的 AI 技能、工具和知识统一管理的思路。

陈序: 再加上 GTM Co-Founder 那套给独立开发者工具创始人的市场进入技能，以及一张按天体实时位置绘制的像素太阳系地图。今天的这几条，大多集中在让 AI 工具更好用、更好管、更好落地上面，也很能看出这个生态正在往更务实的方向走。

林岚: 下一期简报我们继续，到时见。