前一阵，我们内部为一个问题争了好几轮：那套管理会计系统，到底是该做成一个界面，还是干脆用一堆 markdown 文档把内容摊开？
主张做界面的人说，界面直观，能下钻，能预警；主张写文档的人说，文档轻，改起来快，不用每次都重新构建。两边都有道理，所以谁也说服不了谁。
现在回头看，这场争论之所以没有出口，是因为我们一直在争"哪个更好看"。那是个审美问题，而审美问题没有标准答案。
真正让争论停下来的是换了个问法。我不再问"哪个更好"，而是问一句：这东西，是给谁读的？
答案一下就清楚了。给人用眼睛在屏幕上扫的，做成界面；给人一行行读进去的，写成文档；给机器去取的，走接口。三种读者，三种形态，各归各位，没有高下，也不需要投票。
我们把这三条压成一句话：指标进 UI，结论出 md，机器走 API。
不过，这句话如果只停在这里，它就只是一句顺口的话。它真正站得住，是因为背后还连着另一件事。
我们做系统做久了，有一个反复在用的框架：结构、关系、系统。会计科目是结构，KPI 是关系，OKR 的目标是系统。我们一直拿它来理解一个组织、一套账、一门生意——先看骨架是什么，再看骨架之间怎么连，最后看它朝什么目标走。这是一套用来认识一个东西的框架。
后来我发现，前面那句话和这套框架，其实是同一件事的两面。
结构、关系、系统，是一个东西的体——它由什么构成。
指标、结论、接口，是同一个东西的用——它怎样被使用。
体是向内看的，用是向外看的。但它们不是两样东西，是同一件东西的两面。这就是老话讲的，体用不二。
这个提法听起来像在咬文嚼字，但它立刻变成了一条能用的判据。去掉所有修饰，只剩六个字：
用必出于体；无体之用，必退化。
还是拿自己开刀。我们那套系统的知识库，早期是直接写死在页面代码里的——每一篇内容都硬编码在前端文件里。表面上看，它有"用"：页面上确实能翻、能搜、能点开。可它的体是空的——内容自己没有结构，没有独立于页面之外的存在。
结果不出所料：每加一篇内容，都要改前端、重新构建一次；改过十来次之后，那个文件又长又脆，谁都不敢碰。这就是无体之用的典型下场。它不是不能用，而是每用一次都要更费劲一点，直到某一次彻底推不动。
反过来看：如果内容本身就是有结构的——一篇一篇独立的文档，各自带着标题、分类、摘要——那么用就只是把它们呈现出来而已。加一篇内容，就是加一个文件，别的地方什么都不用动。
用是体长出来的，所以它轻。
我把这套东西讲给团队听时，有一句效果最好：争论的双方往往都没错，错的是他们争的那个问题。很多争论之所以无解，不是因为没有答案，而是因为问题被问成了审美的样子。一旦把问题换成"谁读它""它由什么构成"，答案自己就浮上来了。
这也是我最近越来越信的一件事：一个好判据的价值，不在于它多正确，而在于它能把一场没有出口的争论，变成一次可以验收的选择。前者消耗的是人的耐心，后者节约的是组织的成本。
到这里，我想说的其实已经超出了界面和文档。做企业服务的人，客户最常问的一类问题是"我到底该上这个还是那个"——该上大屏还是该上报表，该做定制还是该用标准品，该自建还是该买。这类问题如果按"哪个好"来答，永远答不完；但如果先问一句"它是给谁用的、它由什么构成"，往往当场就收敛了。
所以对我们自己，这句话的落点有三条。凡是"要展示什么内容"，先问谁读，再定形态——指标进 UI，结论出 md，机器走 API，不再为一段文字去写一个页面。凡是设计一件新东西，先看它有没有体，再谈它怎么用——没有体的用，早晚要还债。凡是遇到僵住的争论，先回头看一眼：我们争的到底是不是那个真正的问题。
这条判据不限于我们自己用。做企业服务的人都知道，客户最常卡在"该上哪个"的争论里——大屏还是报表，定制还是标准品，自建还是外购。市面上给框架的人多，给判据的人少。"谁读它""它由什么构成"这两个问题，十分钟就能把一场争论收成一个可验收的选择。这条路走得通，就是售前里最轻的那把刀——不卖方法论，卖一次收敛。
一切皆如