<antirez>9 hours agohttp://antirez.com/news/107作者花费数天时间反复设计新模块和Redis数据类型的API，强调为程序员设计的用户界面至关重要。程序员用户界面（API、库、命令行工具等）每天都被使用，并塑造了对系统的认知；简洁性至关重要。反复设计以找到简单的界面并非完美主义，而是对设计空间的探索，由感知引导而非严格规则。良好简洁的用户界面能够学习通用概念（微量营养素），而非过时的临时知识（垃圾食品）。作者主张在发布前完善设计，并确保临时部分简单甚至有趣易用。
Designing APIs for Agents15 days agohttps://www.freestyle.sh/blog/opinion/designing-apis-for-agents为人类设计的API优先考虑最少使用模式、良好默认值以及易于上手、无需大量文档阅读的SDK。为智能体设计的API优先考虑清晰和明确性，因为智能体可以阅读大量文档并快速生成大量代码。对智能体而言，默认值是不好的，因为它们可以根据文档明确填写所有字段，从而减少误解和错误。错误对智能体来说并非坏事；它们提供了澄清API行为的机会，这与人类相反，后者应尽量减少初次使用时的错误。不明确的API可能导致智能体产生幻觉；具体的字段名称（例如使用displayName而非name）和文档注释有助于防止误解。API对智能体的价值在于提供无法在内部复制的事实（例如账单已支付、消息已发送），而非实用功能函数。自由式虚拟机从使用SDK工具隐藏复杂性转向提供清晰指南，从而改善了智能体初始化和代码清晰度。智能体框架和沙盒API的质量参差不齐，例如Flue框架因语义简洁清晰而表现优异，而像Eve这样的框架则因庞大而受到批评。
Good APIs Age Slowly24 days agohttps://yusufaytas.com/good-apis-age-slowly最初令人印象深刻的 API 往往会导致后续维护困难；应信任持久性而非初始的优雅。API 的第一个版本常被高估，因为它在真实世界依赖关系出现前，只会在简单环境中被评判。关键的 API 设计问题涉及边界：尽早决定什么是公开的、什么是私有的，以避免意外的依赖。初始时尽可能少地暴露，因为以后添加比在他人依赖后移除更容易。API 的便利性可能隐藏假设，导致面对新用例时僵化；无聊、诚实的 API 往往更持久。避免围绕当前前端形态设计 API，以防止耦合到临时的 UI 决策。版本控制并不能为糟糕的 API 设计开脱；稳定的 API 能建立信任并减少协调成本。好的 API 会谨慎对待暴露的内容，尤其是在响应中，以防止意外的依赖。