返回首页
最新
你知道有什么库或工具可以用来检测运动模糊的照片吗？
我花了几个月时间开发一个应用程序，却意识到我没有任何分发渠道。为了解决这个问题，我手动筛选了40多位影响者（覆盖人数可达16万），专门用于SaaS推广。
该平台已在 ShipShared.link 上线。我们正在为2月9日的试点项目挑选我们的“创始10家”初创公司。
商业模式：
• 无月度订阅：您无需支付月费即可访问平台。
• 固定活动费用：创始人支付固定费用以启动活动，从而提供可预测的覆盖率。
• 认证影响者：我们负责筛选，您无需“发布后祈祷”。
我非常欢迎您对该模型或网站提供任何反馈。
大家好，
我在一个志愿者足球委员会工作，其中一个业余俱乐部常常面临的挑战是评估球队的可行性。
每个赛季，确实会有一些球队能够招到足够的队员，但当俱乐部想要扩大影响力（例如进入新的年龄组或新的联赛）时，判断是否值得开放注册并承担风险就变得困难。
许多俱乐部使用的注册工具并不提供表达兴趣的功能，而是只提供正式注册，包括提前的信用卡付款，因此球员必须支付费用才能表示兴趣。有人可能会认为这意味着球员确实感兴趣，但这也是一个巨大的进入障碍，尤其是当球队可能无法成立时。
这导致俱乐部可能需要提供退款，并告诉球员他们无法在该年组建球队。这会造成不良的公关，并且对志愿者财务主管来说，账务处理也会变得复杂。
Squadsure 通过提供发布你考虑组建的球队（包括最低人数）的功能来填补这一空白。它的使用门槛很低，潜在球员只需提供姓名和电子邮件，以便及时了解球队是否能够成立。
它为俱乐部提供了自定义页面，列出表达兴趣的球队，俱乐部可以轻松地在社交网站、电子邮件、WhatsApp 等平台上分享。
球员还可以看到球队离目标的距离，而后台的管理员可以导出数据，以便在球队可行时轻松联系这些球员。
我之所以开发这个工具，是因为我们在自己的俱乐部也遇到了同样的问题，我也在其他俱乐部和运动中看到了类似的情况。
这个工具的设计旨在易于使用、低摩擦并节省时间。志愿者委员会非常渴望这样的工具，因为这并不是他们的日常工作。
请看看这个工具，告诉我你的想法。我开发这个工具并不是为了成为亿万富翁或百万富翁，而是为了填补我认为在体育注册软件中显而易见的一个空白。
<a href="https://www.tiktok.com/@recursecenter/video/7597943894319369502" rel="nofollow">https://www.tiktok.com/@recursecenter/video/7597943894319369...</a>
我很好奇这里的人们对此有什么看法。
许多应用程序最初是通过一次性购买的方式来运营。交易非常明确：你一次性付款，就拥有了所有功能。
但在某个时候，商业模式发生了变化：开始引入订阅服务，而用户已经支付过的功能则消失了，或者被锁在新的付费墙后。
我理解为什么会有订阅模式。经常性收入使得产品更容易维持。
但从用户的角度来看，这感觉就像是在事后改变规则。这不是对新用户的价格上涨，而是对现有用户的追溯性改变。
我最近在我参与的一个项目中添加了GPX导入功能，特别是为了避免数据锁定。这个想法很简单：即使有人停止使用这个应用，他们的数据也应该能够在其他地方使用。
这让我提出了一个更广泛的问题：
• 改变现有用户的交易条款是否可以接受？
• 可持续的盈利与破坏信任之间的界限在哪里？
• 对于你曾经支付过的软件，你如何看待“所有权”？
我真心希望听到创始人和用户的看法。
嗨，HN，我是Tony。
我创建了Grov（[https://grov.dev](https://grov.dev)），因为我在现有的AI编码助手上遇到了瓶颈：它们是“单人游戏”。当我关闭一个终端窗口或结束一个聊天会话时，在该会话期间生成的高层次推理和架构决策就会丢失。如果一个队友在一个小时后接触到相同的代码，他们的助手必须从头重新推导一切，或者阅读许多文档文件，以了解实现的任何功能或修复的错误。
我希望停止为所有内容撰写大量文档，仅仅是为了给我的助手提供上下文，或者不得不重新向我的助手解释我的队友做了什么以及为什么这么做。
Grov是一个开源的上下文层，有效地为你团队的AI助手提供了共享的、持久的记忆。
以下是技术方案：
1. 决策粒度的记忆，而非文档存储：当你同步记忆时，Grov在决策层面构建知识。我们捕捉特定的方面（例如，“认证策略”）、所做的选择（“JWT”）和推理过程（“无状态以便于扩展”）。重要的是，当你的代码库演变时，我们不会覆盖记忆，而是将旧的决策标记为被取代，并将其链接到新的选择。这为你的团队提供了架构演变的审计轨迹，而不仅仅是当前的快照。
2. 类似Git的记忆分支：团队在不同方法上进行实验时，可以创建记忆分支。功能分支上的记忆保持隔离，直到你准备好合并。访问控制与Git类似：主分支是团队范围的，而功能分支则保持噪音隔离。当你合并分支时，累积的见解会立即对每个人的助手可用。
3. 两阶段注入（令牌优化）：共享记忆的昂贵部分不是存储，而是上下文窗口。加载10个无关的记忆会浪费令牌并混淆模型。Grov采用“预览→扩展”策略：
- 预览：混合语义/关键词搜索返回轻量级记忆摘要（约100个令牌）。
- 扩展：只有在代理明确请求更多细节时，才会注入完整的推理轨迹（约500-1000个令牌）。与原始上下文转储相比，这通常会导致每次会话减少50-70%的令牌消耗。
结果是：你的队友的助手不会浪费5分钟重新探讨你为什么选择Postgres而不是Redis，或者重新阅读认证中间件。它只需知道，因为你的助手已经找到了答案并分享了它。
Github: [https://github.com/TonyStef/Grov](https://github.com/TonyStef/Grov)