在我看来，API 就像一座桥，连接着产品经理与开发者。桥梁若不按双方的思维方式搭建，走上去就会感到不合拍、踩到坑。于是，设计 API 时，函数命名与参数结构就像桥面上的铺路砖，必须与开发者的心智模型保持一致。

心智模型本质是人们对世界运作方式的内部表征。心理学家 Daniel Kahneman 在《思考，快与慢》中指出，开发者在调用 API 时往往依据已有的认知框架做出决策。若 API 的名字与参数与他们的框架冲突，即使功能再强大，也会被忽略。

拿 Stripe 的支付 API 例子，几乎所有终端都遵循统一的动词命名：createCharge、retrieveCharge、refundCharge。这与开发者在处理 CRUD（创建、读取、更新、删除）时的思维完全吻合，减少了学习成本。相反，如果把同一功能命名为 makePayment、getPaymentInfo、cancelPayment，虽然也能工作，却打破了开发者的“支付-状态-动作”思维链。

参数结构同样要遵循心智模型。GitHub 的 REST API 在查询参数上采用了“filter”“sort”“per_page”等直观命名，开发者在构造 URL 时能马上想到“按标签过滤、按时间排序、每页显示多少”。而如果使用无意义的缩写，如 q=repo:js&sort=desc&pp=30，就会让人摸不着头脑。这里的成功经验告诉我们：可读性即是心智模型的外在表现。

作为产品经理，我常用的检查清单是：1）函数名是否与常用业务动词相匹配；2）参数名称是否符合开发者的行业术语；3）是否有统一的错误码体系，让错误处理与已有错误处理流程保持一致。若一次性满足上述三条，API 的使用率往往会在上线后 30 天内突破 70%。

Google Maps 的坐标 API 也是一个典型案例。它用 lat、lng、zoom 这些显而易见的英文缩写，既简短又与地图学的基本概念相符。开发者在一次查询后，就能立刻识别出纬度、经度、缩放级别的含义。若改成 latitude、longitude、scaleLevel，虽然也可以，但会显得冗长，降低开发效率。

综上所述，API 设计的心智模型是桥梁的基础设计原则。它要求我们在命名与参数结构上与开发者的认知框架保持同步，才能让产品在实际使用中真正落地。未来的 API 设计，或许还需要更深层次的用户画像分析，让心智模型从“产品经理的假设”升级为“开发者的真实预期”。你在设计下一代 API 时，是否也考虑过这层“心智对齐”呢？