返回首页
最新
Vibe 为我的 Omarchy 设置编写了这个代码。希望分享并听听大家的想法。
我在过去几个月里一直在构建MCP服务器，发现为AI代理设计工具架构与为人类设计REST API有着惊人的不同。
以下是一些在生产中有效和无效的模式：
**无效的模式：**
1. 细粒度的CRUD端点。我最开始使用了显而易见的端点，如get_request、update_request_status、update_request_assignee、add_comment等。代理经常会调用错误的端点或以错误的顺序链式调用。过多相似的工具导致了混淆。
2. 泛化的参数名称。一个名为“id”的字段在没有上下文的情况下对代理毫无意义。它会产生虚假的ID或传递错误实体的ID。
3. 稀疏的错误信息。返回“404 Not Found”并没有给代理提供任何有用的信息。它会无限期地重试同样的错误调用。
**有效的模式：**
1. 更少、更宽泛的工具。与其使用8个CRUD端点，不如将它们合并为3个：search_requests、get_request_detail、update_request。使用更小的工具集，代理犯错的次数大大减少。
2. 带有示例的描述性架构。在JSON架构中添加“description”字段及示例值显著提高了准确性。架构本身就是提示。
3. 丰富的错误响应。与其返回“404”，不如返回“未找到ID为‘abc’的请求。您是否想先进行搜索？可用工具：search_requests”，这实际上促使代理自我纠正。
4. 读-写模式。在结构化工具时，让代理在进行更改之前自然地获取上下文，显著减少了破坏性错误。
5. 危险操作的确认字段。为删除或批量更新添加一个必需的“confirm: true”参数，起到了减速带的作用，使代理三思而后行。
**思维模型的转变：** 你不是在为阅读文档的开发者设计API，而是在为一个只看到架构和最后几条消息的推理引擎设计接口。每个字段名称、描述和错误信息都是一个提示。
我很好奇其他构建MCP服务器的人是否发现了类似的模式或不同的方法。
嗨，HN，我开发了Mission Plus，这是一款小型的原生macOS工具，可以在你打开多个窗口时使Mission Control更易于阅读。
Mission Control非常棒，但当多个窗口看起来相似时，快速识别每个窗口的内容就变得困难。Mission Plus在每个窗口上方叠加了大字号的文本标题和易于识别的应用图标，这样你就可以立即区分它们，而无需在缩略图中寻找。
该应用程序是原生实现的，专注于低开销和流畅的性能。它紧密跟随Mission Control的动画效果，并设计得像是内置的macOS功能，而不是第三方叠加工具。
主要功能：
- 窗口上方的大而清晰的文本标题
- 对大多数常见macOS应用的自动图标匹配
- 非常低的资源使用率和没有明显的延迟
- 直接下载DMG文件（无需注册，无需App Store）
你可以在这里下载并试用：
<a href="https://trystartup.com/" rel="nofollow">https://trystartup.com/</a>
这是一个早期版本，我非常希望能收到反馈，特别是来自macOS重度用户的意见。我会在评论区回答问题并讨论设计或实现细节。
开发了一种更快的单指输入方式（不考虑语音转文本），使用动态时间规整（DTW）算法来计算和比较路径。引擎使用Rust编写，并编译为WASM和FFI以支持Mac。
申请X26（截止日期是明天）。<p>我之所以开发这个工具，是因为我在W25（人工智能辅导员的想法）中被拒绝了，想要根据我能找到的经验指标来检查我未来的申请。<p>它的工作原理如下：
向量搜索：将你的想法与5000多个过去的YC公司（成功与失败）进行对比。
评分分析：根据从YC创业学校和保罗·格雷厄姆的文章中提取的标准评估创业机制。<p>我在一些朋友的项目上进行了测试。正确识别了一个VS Code文档扩展为可有可无/低紧迫性（失败）。对一个校园转租市场给予了通过，但正确标记了“鸡和蛋”供应风险。
WriteMore帮助写作者提高写作产量。它由写作者开发，将每日提示转化为一种共享的创作实践——每天写作、发布，并探索他人正在创作的内容。
我觉得关于这个话题的讨论很多都归结为冷漠或放弃。人们常说如果Steam真的关停，他们就会开始盗版自己所有的游戏库，但这听起来更像是一种本能反应，而不是一个实际的计划。要让Steam完全消失，必须有某种关键因素在全球范围内崩溃。要明确，这并不是一个现实的短期情景，但我只是想谈谈这个问题，看看其他人对此有什么看法。
即使你想要保存自己的游戏库，很多人的收藏已经超出了任何常见的消费者存储设备的容量。我们说的是需要多个TB，甚至十几个TB才能完全归档的游戏库。支撑这些数据的基础设施既不便宜也不简单。因此，当你考虑到实际的后勤问题时，“我就全部盗版”的回应开始显得空洞。
对我来说，这引发了一个令人不安的问题：当初积累这些游戏的意义是什么？有多少人的游戏库里堆满了Humble Bundle的额外内容、Steam促销时的冲动购买，以及那些他们发誓有一天会玩的但从未触碰过的游戏？顺便说一下，我也对此深有感触。
我花了很多钱建立了一个还算不错的游戏收藏，但其中很大一部分都在那儿积灰尘。
所以，当假设发生时，你的游戏库变得无法访问，你会如何合理化这一切？你真的会怀念那些游戏吗，还是会意识到你其实只关心其中的少数几款？
你会寻找一个新的平台开始购买游戏吗？
我现在的观点稍有转变，购买游戏却从未玩过，实际上相当于对维持Steam存在的30%捐赠，以及对开发者/发行商继续做他们所做事情的70%捐赠。
当你这样合理化时，感觉就没那么痛苦了，但我很好奇HN对这个话题的看法。