本文探讨了理解事物的三种层次：实现、接口和流程。作者认为，人们在解释如何使用事物时，对这三个层次的划分存在差异，导致混淆。通过区分实现（底层运作）、接口（功能定义）和流程（常用操作），可以更清晰地理解和使用事物。这三个层次的划分有助于解决沟通中的误解，尤其是在遇到超出常规情况的问题时。尽管这种区分并非完美适用于所有情况，但仍然提供了一个有用的框架。

⚙️**实现：**指的是事物内部的运作方式，通常无需关注，除非遇到问题、需要修改或出于学习目的。它位于抽象之下，揭示了事物“幕后”的工作原理。

💡**接口：**描述事物的功能，而非实现方式，是一种抽象。它定义了事物在各种情况下的预期行为。接口关注的是“是什么”，而不是“怎么做”。

🔄**流程：**指的是人们通常使用事物的方式，即在日常操作中的响应。它关注的是事物在常见情况下的行为，而非在特殊情况下的表现。

🤔**应用场景：**这种区分在人工制品（如软件、工具）中效果更好，但在自然事物（如烹饪）中可能不够清晰。即使不完全匹配现实，这种框架也能提供有用的术语和理解方式。

Published on March 27, 2025 7:38 AM GMT

(Found this old draft that was more or less complete; figured I should publish it.)

It's commonly appreciated that when explaining how to use something, there's a distinction between the high-level usage instructions and the low-level details. But what I've noticed is that different people draw the line a bit differently, and this leads to some confusion. A more useful, less ambiguous distinction, I find, is to break things into three levels, which I'm calling "implementation", "interface", and "workflow".

Implementation is what it sounds like -- how the thing works under the hood, ignoring all abstractions you might use to paper it over. You normally shouldn't have to worry about this unless something breaks, or you want to modify it, or maybe you just want to learn how it works so you can do something new, or whatever. It's what's below the abstraction.

Interface is what the thing does and not how it does it; this is necessarily an abstraction and won't always work, but it's at least what the thing is supposed to do in every case.

Workflow is how you normally use the thing -- not everything it does, just how it will respond when you do the things you normally do with it, not how it's going to respond in weird edge cases.

Note that these distinctions will only really work for artificial things -- something like, say, cooking, doesn't have a clean separation between implementation and interface, and even for something artificial this may not quite work if it's not sufficiently complete or well-implemented -- but this can still be a useful separation to draw even when that separation may not match the territory cleanly.

Now this may sound fairly obvious, but I bother pointing it out because apparently it's not so obvious! I can think of multiple conversations I've had where (in effect) I was given workflow information, found it insufficient, asked about the interface, and was asked, why do you need to know about such internals? Except, I wasn't asking about internals (implementation), I was asking about interface; I didn't want to know how the thing worked interally, just what it would do in cases outside the usual ones. So I think this three-level breakdown, even if it doesn't always map cleanly onto reality, still provides some useful terminology.

Discuss