一家之言，胡言乱语

软件架构之前后端分离的外行一知半解

Wed, 21 Jan 2026 15:51:57 +0800

作为一个产品经理，我正式在代码层面深入了解一个软件项目时，接手的就是一个前后端一体的WMS的项目。当时并不理解何为前后端一体或前后端分离，直到后来接手了前后端分离的项目，有了对比才有了理解。

我的WMS项目是基于 JSF(JavaServer Faces)/RichFaces 开发的，在 2018 年接手时，第一感觉就是信息密度大，响应快，但界面很丑，尤其默认字体使用的是衬线字体，控件类型或者控件支持的属性不够丰富。当时就想为什么 UI 设计不能像现在很多网站那样做的好看一些。后来接手的前后端分离 Vue/ViewUI 的项目，界面相对漂亮，但是响应速度慢，信息密度小，给人的感觉就是中看不中用。

另一点感知到的不同是根据前端定位后端逻辑上：JSF 架构的项目，前端控件绑定的是后端的某个 action 的某个方法，后端的 action 然后调用 service 层，service 层再调用 impl 层，impl 层再调用 dao 层， dao 层再调用数据库，或者是利用 hibernate 框架生成的 sql 操作数据库；而前后端分离的项目，前端无一例外都是通过 HTTP 请求调用后端 API，后端返回一个 JSON 实体。下面分别是两个例子：

<!-- 对比前后端一体 -->
<h:commandButton value ="确认-分拣框" styleClass="btnCla btn-m" action="#{reCheckAction.startCkeckBySortContainer}" id="startCkeckBySortContainerBtn" style="font-size: 16px;"/>

<!-- 对比前后端分离 -->
methods: {
            getQuotationProduct() {
                this.sceneList = [];
                this.sceneLoading = true;
                postAction(basePath + '/quotationScene/getQuotationProductByContractNo/' + this.contract.contractNo).then(res => {
                    this.sceneList = res.data;
                    this.setMergeCells();
                    setTimeout(()=>{this.$refs.vTable.$refs.xTable.setAllRowExpand(true)},500)
                }).catch(e => {
                    console.log(e);
                }).finally(f=>{
                    this.sceneLoading = false;
                })
            }
}

对于这些不同架构的项目，我之前始终有着这些困惑：

前后端是否分离的关键点在哪里？
为什么前后端一体的 UI 设计不能跟随时代审美变化更新成最新最好看的组件库？
我看上了某个组件库独有的控件，不能直接拿来用吗？
为什么 JSF 架构响应快，前后端分离的明显慢？
前后端分离的项目如果开发、产品也分离，需求文档怎么写，怎么沟通？怎么分工？

得益于和 Gemini 的对话，我这个外行对前后端是否分离有了下面这些理解。

关键区别点在于能否项目拆分，分别部署

前后端一体 (JSF/RichFaces):前端(.xhtml)与后端(.java)在同一个工程，因为前端的页面要直接调用后端 Java 对象方法，所以必须捆绑在一起才行。当然对应的开发势必是同一个人。如果要换前端框架，后端就要跟着一起重构。任何前端或后端的调整，整个项目都必须重新发布，用户感知会很明显。

前后端分离：前端(.html)与后端(.java)可以在不同的工程，对应的开发也可以分给不同的人合作，因为前端的页面通过 HTTP 请求调用后端 API，后端返回 JSON 数据，和两个独立系统之间通过接口通信没什么不同，所以可以独立开发、独立部署。前后端由于是分离的，只要二者间的接口定义未发生变化，任何一方都可以独立改动独立发布，用户感知不明显。

页面渲染方式不同

前者是通过 Java 服务器渲染目标 html 直接发送给浏览器，也就是 SSR(Server-Side Rendering)，后者从后端拿到的是 json 实体，页面则是通过前端 JavaScript 来完成的，也就是 CSR(Client-Side Rendering)。所以前者靠的是后端服务器的性能，后者靠的是客户端的性能，以及客户端具体浏览器对内存的优化能力。这也是为什么前后端分离项目更常让人感觉慢的原因：客户端硬件性能差、浏览器内存优化弱、功能样式丰富的组件库带来的庞大的资源开销。

前端组件库的背后是对应的渲染方式，基于 Java 还是 JavaScript，是和具体选择的架构绑定的，像 RichFaces, PrimeFaces 就是和 JSF 绑定的，ViewUI 就是和 Vue 绑定的。所以如果想换一个组件库，不换架构就只能在同架构的里面选，否则必须整体重构。

后端方法的复用

前者如果有其他客户端，后端方法 action 是无法重用的（action 往往也会有部分逻辑），只能在具体的实现层（service 或 impl 层）进行方法复用。而后者由于使用的是 http 接口，天然的适合多类型客户端复用后端。

B2B 系统的“现代化”陷阱：快 vs 美

这是我感触最深的一点。现在的 UI 库（如 View UI）做得非常漂亮，但在处理 B2B 复杂业务（如密集录入、多 Tab 操作）时，体验反而不如老旧的 JSF。

“假 Tab”带来的内存占用问题一个系统界面常常设计成多标签页（Tab），看起来像浏览器的标签，但关闭时往往因为只是隐藏或缓存机制或者内存泄漏而没有释放内存。不像浏览器的标签页，在任务管理器里可以看到一个标签对应一个进程，关闭时一定会释放内存。所以如果开发人员没有处理好垃圾回收，系统给人的感觉就是刚打开时还挺顺畅，但用久了，内存占用会极高，系统越来越卡。而 JSF 每次跳转都是页面刷新，天然地“重置”了内存环境。
大表格卡顿问题这就好比在 Excel 中，是选中一万个单元格批量设置格式，还是逐个给一万个单元格单独设置某个属性带来的表格文件大小变化一样，前者是压缩编码的信息，只需要记录范围和属性就可以，后者却要记录每个单元格的属性，所以文件大小会大。viewUI 有时候的表格就是后者，所以遇到表格展示十行还行，一旦选张展示一百条，就会感知到明显的卡顿问题，必须选用高性能的表格组件，或者至少采用“虚拟滚动”（显示多少，渲染多少，但页面搜索就废了）尽量规避。更要命的是在表格展示时同时要允许直接编辑的场景，嵌套输入框等更加要命。
B2B 系统其实对 UI 的要求只要做到像《写给大家看的设计书》里所说：对比、重复、对齐、亲密性四大原则即可。信息密度一定要大，响应要够快。然而现在 UI 库大多默认设定都是针对 2C 场景，大量使用留白，页面控件总是有很大间距，很多动画效果浪费时间，美丽而不够突出的提示……

前后端分离给分工带来了更高的要求

分工一定会带来沟通成本的增加，前后端是由接口文档串联起来的，两个角色必须先沟通清楚 API 定义，如果一个公司开发流程不合理，经常扯皮，或者把定义接口的事情交给不太擅长的 PM，可能是噩梦。虽然PM可能不直接定义API，但是必须负责定义API中的业务数据的输入输出。
PM 得注意一份文档两个人看，怎么处理文档结构方便不同角色的开发看的问题。
两个角色的开发周期不一致，必须依赖 Mock 解决进度不一致的独立开发问题。
开发可以分工，PM 可不行，难以想象一个函数的定义，一个人负责设计输入，另一个人负责设计过程和输出。

前后端分离隐含的无状态管理大坑

上面提到前后端分离时，前端和后端是通过 http 接口通信的，和平时不同系统间对接接口没什么差别。我们平时在系统对接时设计接口要考虑的并发、重试等场景，在前后端分离的接口设计时同样要考虑。设计者不仅要考虑前端的无状态管理（通过 token 认证、禁用按钮等方式防止重复提交），还要考虑后端作为最后一道防线如何防止重复提交，以及如何处理并发请求。缺少了 JSF 框架的隐形保护，稍不注意就可能导致数据异常。

不要因为好看一个原因选择一个组件库

选择组件库，背后是选择架构，选择的是渲染方式、性能、工作流程。在 2B 业态里，高效的完成工作应该是首要考量，选型应该在此基础上再考虑是否好看。选择Javascript 生态的前后端分离组件库时，应该考虑下自己的业态是否能够利用其特点：

多类型客户端
前端交互复杂度高
开发团队规模能够进行前后端分工
有能力管理对应的开发流程

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

我读

Fri, 01 Aug 2025 00:00:00 +0000

书名	作者	备注
常识	梁文道
常识	托马斯·潘恩
巨婴国	武志红
奴化的人：中国文化的深层结构	孙隆基
1984	乔治·奥威尔
动物农庄	乔治·奥威尔
政府论（下篇）	洛克
黑客与画家	保罗·格雷厄姆
附录与补遗	阿尔泰·叔本华
人月神话：软件项目管理之道	佛瑞德·布鲁克斯
世界观：现代人必须要懂的科学哲学和科学史	理查德·德威特
被劫持的私生活	肉唐僧
天朝的崩溃	茅海建
中国文明的反思	萧建生
极权的诱惑	许知远
局外人	阿贝尔·加缪
中国人的性格	史密斯
美妙的新世界	阿道斯·赫胥黎
我们	叶甫盖尼·扎米亚京
叫魂：1768年中国妖术大恐慌	孔飞力
政治学通识	包刚升
狂热分子：码头工人哲学家的沉思录	埃里克·霍弗
编码：隐匿在计算机硬件背后的语言	Charles Petzold
论自由	约翰·穆勒
野火集：三十周年纪念版	龙应台
到奴役之路	海耶克
学会提问：批判性思维指南	尼尔·布朗/ 斯图尔特·霍尔
费孝通作品精选	费孝通
全球科技通史	吴军

访问量统计：0

如何设计一个规则引擎

Sun, 30 Jun 2024 15:59:24 +0800

产品设计过程当中，经常会遇到需要制定各种规则的场景，例如如何选择承运商、如何匹配费用等等。这里记录下关于这种面向用户配置的规则引擎设计的思考。

本质

将 IF 或 CASE 的条件与结果可配置化，UI 化或结构化（使用 json\SQL）如下内容：

对象
比较运算符
值
逻辑运算符与或非
计算顺序
代码执行顺序
结果

对象

数据库字段、实体类属性在前台对应业务属性的映射。

通常需要决定那些实体类，哪些属性可以用于制定规则。如果将这个也变成自由定义，可能会过度增加复杂度。
可能会遇到多个对象进行数学计算过后再进行比较运算的情形，例如体积满足某个条件，但是数据库只单独记录了长、宽、高，在设计时需要额外注意。
前台设计时，应该使用下拉框，避免输入。

比较运算符

使用下拉框。
支持常见的数值型运算符和字符串运算符。
如果对象选择是数值型的属性，那么运算符应该候选项限定为数值运算符。
尽量不使用 isNull 之类的运算符，不太适合暴露给普通用户。

值

如果对象是数值型，在前台进行输入合法验证。

逻辑运算符与或非

AND OR NOT 且或非。
使用下拉框。

计算顺序

自然顺序，不需要设计。
自定义顺序，需要使用括号。
用户可能很容易理解括号，但是不一定能够记得其他运算符的先后顺序，可能的话，将用户配置的规则的计算顺序在前台展示出来。

代码执行顺序

可以将 CASE WHEN THEN ELSE 或 IF THEN ELSE 这样的关键字或对应的关键字中文描述暴露给用户，如果确定用户可以理解的话。
使用规则优先级数字，交由用户填写。
1. 应该提示给用户，数字大小与执行顺序的关系。
2. 规则应该按照执行顺序进行排序。
3. 如果 UI 设计上，不同条目的规则不可以拖拽进行优先级调整，那么优先级应该选择数值型，以便插入规则时不需要修改后续所有规则。
如果规则已经使用整数型作为数据类型，在配置时可以使用 100,200 这样的大间距整数，当需要插入新规则时，取前后规则的中间值即可，而不需要调整所有后续规则。
对优先级进行唯一性检查。
注意这些分支语句都应该有兜底。

结果

问题

新增一条规则后，怎么知道规则逻辑对不对？

可以在规则引擎的配置页面增加一个测试功能，允许用户使用某个历史数据验证匹配的具体规则来验证，也可以允许用户手动输入测试的各属性值的组合来验证。

新增一条规则后，可以验证该命中规则的命中了，怎么确保不该命中规则不命中呢？

每次规则被更新，都选择历史一段时期的数据重新匹配一次规则，并输出和之前匹配的目标结果不一致的数据，交给用户验证。

规则太多，管理困难，新增编辑规则时，完全不知道相关的规则有哪些，优先级应该如何制定

规则太多就 divide and conquer，看看规则是不是可以明显的进行分组，把最常用的区别大的因素作为规则头的判定对象，其他的作为明细的判定对象。如此一来只需要在组内的少数规则中判断如何设置优先级即可。
每次新增规则后，采取历史数据回归验证的方式检查正确性。

好的实践

记录命中规则的原因与结果。
使用缓存机制。如果规则长期稳定，使用缓存可以避免遍历规则。例如使用重量、体积范围决定承运商的规则，可以记录下来相同重量体积区间的记录，避免重复计算。
每条规则鼓励用户填写规则描述，用直白的语言便于事后理解与核对规则设定是否满足意图。
注意规则应用的场景是否经常有时间段限制，如果有，允许用户配置生效时间范围。对于时间要求高的场景，不能寄希望于用户在时间点到达那一刻再去配置规则，必须要提前配置。有时间段限制的规则，需要考虑规则延期或制定新规则的提前期，必须在提前期前提醒用户开始未来时间段规则的制定。
规则使用版本号，修改应该记录下修改前后的内容日志，用于事后溯源。
对生产环境影响很大而且破坏不可逆的规则，应该提前考虑如何在测试环境对线上的数据进行模拟。
对规则设定是否启用的开关，并且应该提供规则不生效时，如何达到原目标的替代方案。
一个规则可能会出于管理考虑需要人工选中规则输出结果，设计时需要考虑。例如：
1. 计费规则，使用去年的业务数据，运行一次今年的新报价计费规则对比
2. 同样的业务数据，分别使用不同供应商的规则，进行结果对比

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

产品经理如何写接口文档

Fri, 09 Feb 2024 10:10:35 +0800

系统间的接口交互本来是一个偏向开发领域的范畴，但却经常由产品经理负责。原因大概有开发无法提前参与到系统间需求对接过程中，或公司的职责安排本就如此等等原因。

此文是我站在一个产品经理的视角，阐述自己对系统间接口文档设计的见解。由于我只是对后端开发有所涉猎，并不具备丰富的开发领域的知识储备，可能会有事实性错误或理解偏差。

系统间的数据交互有很多种，但本文将局限于目前最常见的采用 HTTP 协议实现的接口。

我的定义

接口文档就是对如何使用 HTTP 协议传输信息的声明。这个声明构建了接口文档的核心元素，在此基础上再增加一些利于受众阅读、理解的辅助元素。

HTTP 协议结构

我并没有也不打算对 HTTP 协议本身做深入的研究，仅借助 Postman 这种可视化的 API 测试工具来找出接口实现必要的部分。需要注意的是，除了下述 Request Body 部分和业务逻辑高度耦合，产品经理可以主动负责以外，其他部分都应该以研发为准，如果有冲突，主动 step aside.

下面将根据图片中从左到右，从上到下的顺序描述。

请求方法 method

定义了每个资源路径支持的操作，例如 GET、POST、PUT、DELETE 等。目前来看遇到的场景基本上倾向于 RPC 风格，都使用 POST 方法，并不会按照 RESTful 风格进行各种抽象。

请求地址 URL

URL 实际上是由请求地址 + 请求参数两部分组成的。

请求地址

实际上这个小节是最令我难以下笔的地方，涉及到 URI、RESTful 风格、RPC 风格等诸多概念。又因为目前见到的不管是公司内部还是各大公司开放平台对如何实现都各不相同，导致我很难表达，甚至说可能还没有搞清楚。

首先我们向服务端请求，首先要确定服务端应用主机在网络上的地址。当使用 IP 地址时通常由 IP 地址和端口组成。这部分也常被称为 BaseURL，是伴随应用环境变化而变化的部分。

当应用 RESTful 风格（这种风格在表达利用 HTTP method 对服务端的特定资源进行操作）时，往往使用 URI 表达不同资源的路径，反映了业务层级和结构，使用 HTTP method 中的 POST、GET 等方法表达如何操作资源。由于 URI 表达的是服务端的一个资源，所以命名上往往是资源名词的复数形式，例如，/users 表示用户资源集合，使用 GET 方法获取。URI 上也会出现参数，例如 /users/{id} 则是表达请求特定 id 的用户。

当应用类似 RPC 风格（这种风格在表达调用服务端一个特定方法）时，以目前我常见到的两大类实现方式而言，要么在 URL 上直接表达一个远端方法，例如 /users/create，要么利用请求参数，使用一个参数表达具体方法名，例如 /prc?method=getUserById 。这种接口名（方法名）的命名要注意清晰而简洁，准确传达接口的用途。避免过于复杂或冗长的名字，使得开发者在一瞥之间能够理解接口的作用。考虑使用动词和名词：使用动词描述操作，使用名词描述资源。例如，getUserInfo 表示获取用户信息，createOrder 表示创建订单。

注意要保持接口命名的一致性，使用相似的命名规范，以便开发者更容易理解整个 API 的设计风格。

还有一点需要注意的是有关版本信息：如果采用版本控制，将版本信息包含在接口名中，例如 /v1/getUserInfo。RPC风格也可以考虑使用请求参数控制版本。

为了避免可能的大小写问题，最好统一成小写（基本不会有人主动改为驼峰，却极易发生全都小写的情况）。

请求参数 Query Params

请求参数位于 URL 的查询字符串中，通常跟在问号后面，使用键值对的形式传递，多个参数之间使用 & 分隔，形如 ?param1=value1&param2=value2。例如 /api/users?name=John&age=25。

在 GET方法中，通常用于过滤、分页、排序等场景。在用于 RPC 风格的接口统一使用 POST 方法时，常用来表达接口名、请求时间、身份等。

请求参数是公开可见的，因为它们出现在 URL 中，很显然要注意不应该将个人隐私信息等敏感类型的数据放在请求参数当中。

对于接口，应该明确描述请求体参数，包括参数名、类型、是否必须、用途要求等。

请求头 Headers

请求头一般情况下需要注意的是内容类型 Content-Type 的定义。当使用 JSON 作为请求体格式时，应该声明 application/json. 这个声明主要用于服务端正确的进行反序列化解析请求体。另外还应该注意由于我们使用汉字，需要声明字符集 charset=utf-8，以免出现乱码。

至于其他对 Headers 的使用场景，常见的是在此处放置签名，具体包含哪些内容与开发的实现方式有关，需要后续开发补充。

请求体 Request Body

如果请求的信息没有完全通过请求参数表达的话，那么就会用到请求体了。这个才是产品经理需要重点参与的与业务逻辑相关的部分。

请求体通常用于 POST、PUT、PATCH 等带有主体的请求方法，GET 方法是没有请求体的。

请求体中的数据通常不在 URL 中可见，因此更适合传递敏感信息。

请求体可以使用不同的格式，如 JSON、XML、表单（键值对）等。平时最常见的就是 JSON 格式了，本文也限于描述 JSON 格式的请求体。XML 限于历史原因积重难返的场景中还会继续使用，但全新的系统一般都默认采用更轻、更对人类阅读友好的 JSON 格式。

在继续之前，不得不先大概说下 JSON 格式。

JSON 有两种基本结构：对象和数组。
对象：是由大括号{}括起来的键值对的集合。
1. 键（Key）：是由双引号括起的字符串；
2. 值（Value）:可以是数值、字符串、布尔值、对象、数组，其中字符串型的值需要双引号括起，数值和布尔型的值不需要引号。
数组：是由方括号 [] 括起的元素( members )的集合，之间用逗号隔开，元素可以是数值、字符串、布尔值、对象、数组。
对象可以在键值对的值部分包含数组，数组又可以包含对象。

这是一个综合例子：

{
"class": "3-1",
"headMaster": "Jack Jones", 
"teachers": [
    "Jack Jones",
    "Jane Smith"
],
"students": [
    {
    "name": "Tom",
    "age": 12,  
    "hobby": [
        "piano",
        "football"   
    ]
    },
    {
    "name": "Jerry",
    "age": 12,  
    "hobby": [
        "swimming"
    ] 
    }
],
"location": {
    "District": "Ork Street",
    "campus": "No.1",
    "building": "Main1",-
    "floor": 2
},
"studentsLimits": 20,
"isNew": true  
}

上述例子对应的结构可视化之后就是这样：

对于产品经理而言，只能将 JSON 结构用于表达实体映射关系，设计出的结构通常是对象最少的一种结构。而研发往往还可能出于业务逻辑上的关联性、代码复用、数据处理的便利性、数据结构的清晰度等方面考量，会进行进一步对象的抽象。例如一张订单表，虽然收寄信息、打印信息、时间要求等都和订单本身是 1：1 的映射关系，但开发可能会将这三部分抽离出单独的 3 个对象处理。

字段名

清晰的字段名：
- 字段名应该尽量自解释，让开发者不需要额外的文档也能理解字段的含义、作用。避免使用过于晦涩的命名，使得开发者需要查阅文档才能理解字段的用途。
- 避免使用缩写或过于简短的字段名，除非是广泛认可的缩写。
- 如果你不精通专业术语英文，不要直接随意采用机器翻译结果。请至少将多个同义词的释义例句看一遍，选择最接近的那个。有一点羞耻心，不要被笑话。
一致性：
- 保持字段命名的一致性，使用相似的命名规范，例如采用驼峰命名法或下划线命名法。为什么程序员经常选择首字母小写的驼峰命名法？（最小成本分词）目标是为了将连在一起的多个单词区分开来，所以首词并不需要额外区分，也就少按一次shift，效率更高。很显然下划线的方式要多多按的是个组合键，更不经济，也增加了长度。
- 在整个 API 中使用相同的字段名，以减少开发者的学习适应成本。
避免特殊字符：
- 避免在字段名中使用特殊字符，以确保兼容性和易读性。
在字段名中体现数据类型，例如：
- qty\cnt 表达 Number
- is/has 表达 Boolean
- date 表达 String 格式是个日期
- datetime 表达 String 格式是个日期时间
合理的字段长度：这里的字段长度是指 Key 自身命名长度，应该合理，既能够满足实际需求，又不至于过长导致难以阅读。如果遇到过长问题，可以采取一些缩写方案，注意不同单词有不同的适合方式，关键是可读、一致。
- 约定俗成
- 首尾各取1个字母，中间使用数字代替
- 取首或尾的关键部分
- 使用类似发音的数字代替音节
- 取每个音节的第一个字母，基本等于去掉元音
- ……

字段数据类型

JSON的数据类型：

字符串（string）
数字（number）
布尔值（boolean）
对象（object）
数组（array）

注意不要滥用 String. 这会造成必须额外转换、不能直接验证、浪费计算机资源等问题。而且这种特征会让接口文档的受众失去文档质量的信心，造成信任危机。

是否（选择性）必须

可以从以下几点考虑是否限制：

业务逻辑要求：理解业务需求，确定哪些字段对于系统的正常运作是必不可少的。有时候，某些字段的值对于后续的计算、判断或决策是必需的。
安全性要求：一些安全性考虑可能需要某些字段的值是必填的，以确保系统能够正常进行身份验证或授权等操作。
客户端需要：客户端后续还要继续用于查询依据。
数据完整性：考虑数据的完整性要求。某些数据在系统中必须是完整的，缺失某些字段可能会导致数据的不一致性。
数据关系和约束：考虑数据之间的关系和约束。如果某个字段与其他字段存在关联或依赖关系，确保这些字段都被正确填充，以维护数据的一致性。例如一个度量类字段必填，则其表达单位的字段也势必必填。
历史记录和审计：如果需要跟踪历史记录或进行审计，确保关键字段是必填的，以便准确记录系统操作的细节。
第三方集成：考虑与其他系统的集成，其他系统要求必填，则也要考虑必填。

注释

为每个字段提供清晰注释，解释字段的业务含义、取值范围和使用规则等。

业务含义无需赘述。
对于 Number 类型的字段，要特别注意数值本身是否孤立时无法表达完整的含义，例如货币、长度、重量、时间等。若无单位对应的 Key 的定义，则务必在备注中声明。这类字段还往往要注明精确度的要求。
指定字段长度和范围：
1. 对于字符串类型的字段，可以指定其最大长度，以便客户端能够正确处理输入。
2. 对于数值类型，可以定义其取值范围，以避免不合理的数值输入。
3. 对于字段的长度实际上是由数据库采用的数据类型和长度限制的，往往对每一个字段定义长度是一个很无趣也大多数时候无用的过程。可以采取合理的业务推断判定其最大长度，数据库进行一定宽放。只对灵活无法预判的字段指明长度约束。
4. 接口定义的数据长度将给应用开发语言选择合适的数据类型以及数据库字段数据类型和长度选择提供参考，以节省内存或硬盘开销，提高应用的性能或查询性能。
处理日期和时间：如果接口涉及到日期和时间，明确约定使用的日期时间格式，以便各方正确解析。
处理枚举值：如果某个字段只能取特定的几个值，可以使用枚举类型或字符串常量表示。这样有助于避免非法数值的输入。最好同时提供对应的描述字段，这样下游如果只是展示，便不需要维护数据字典，可以直接取用现成的描述。
是否有缺省值：注意区分“缺省”和“默认”。“缺省”是服务端对未赋值字段缺失时的处理方式，而“默认”更容易被理解为诱导客户端：嘿，如果你不知道这个字段什么意思，就这样赋值吧。基于他人是不可靠的假设，我更倾向于对必要的且最常规的场景中，己方设计缺省。

响应 Response

错误处理和状态码：
- 明确错误处理机制，包括可能的错误状态码、错误消息的格式等。
  - 系统宕机 http 状态码自然会反映
  - 系统正常，但对报文解析出错或内部执行过程中发生了不可预见的系统错误例如数据库事务执行失败等异常
  - 系统正常，但业务验证报错
  - 提供常见错误场景的示例，以便开发者了解如何处理异常情况。

其他非结构性的必要元素

认证鉴权等安全性问题

安全认证和权限：
- 描述接口所需的认证方式和权限，如何获取访问令牌等。
- 提供示例认证流程。
- 请求数据里是否有敏感信息需要加密。
是否采用 IP 白名单方式
是否使用 HTTPS 协议
……

其他元素

确定明确目标和受众，然后根据不同的受众需要组织接口文档的组成部分。

清晰的概览和方便的跳转：
- 使用包含文档内超链接的目录。
- 提供接口的概览，包括主要功能、使用场景和核心概念。
- 提供时序图。
- 设计入口文档页面，使用户可以迅速找到他们感兴趣的信息。
及时更新和维护
- 及时更新文档以反映实际接口的变化。
- 记录包含日期、人员、改动内容概述的更新日志，方便定位最新的更新部分
提供示例
- 提供测试环境和测试数据，帮助开发者更好地理解接口的使用方式。
- 提供具有详细注释的示例请求和响应，以便开发者更好地理解如何使用接口。
- 考虑提供不同情况下的示例，例如成功响应、错误响应等。
- 提供的示例应尽量真实以便开发人员能够理解字段的预期格式和内容。但注意敏感数据的脱敏。
反馈和支持：
- 提供反馈渠道，让用户能够报告文档错误或提出疑问、建议。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

每天坐地铁见闻

Wed, 07 Feb 2024 17:07:14 +0800

分享一些平时坐地铁看到的现象和当时的想法。

安检员的“敬业”，与我对安检措施的无条件的厌恶

每天进地铁都必须安检，这种安检在这个国度早已成了众人习以为常的事情，但我永远不会从内心接受这种浪费所有人生命的低效做法。每次看到听到安检员不停的喊着那句“大包小包都要过机安检”，真为他们不得不做这样一份工作而感到可悲。他们大概率也是不愿意喊的，肯定有强压他们的权力存在，但何必那么“敬业”呢？

我很想问：

一丝枪口抬高一寸的可能都没有吗？
女孩子巴掌大的包真的能容纳多大杀伤力的东西吗？
如果真觉得不管多大的包都能容纳有杀伤力的武器，那么有心人不会随身携带吗？
当真认为风险高的可怕，不认真安检真的会引火烧身？

身边不乏安检的拥护者，提起理由不外乎是安全第一这种政治正确的口号，这时候好像多么看重生命似的。确定在我国生命真的无价吗？所有安检措施的成本都是纳税人的钱，说是安检，不如说是维稳。一直禁止提“纳税人”概念是很有效的，整个国家的人都认为自己的一切都是国家的恩赐。不管它做什么恶，都不乏大量的拥趸，而批评的声音早就被屏蔽。

普遍的缺乏不影响他人的意识

开着外放看视频、打游戏。

总有人在自动扶梯到头的时候呆若木鸡，不是旁若无人就是看手机，都不知道后面的人被扶梯惯性送出的时候会发生碰撞。

人流量大的车站上车的人总是把门堵的死死的。

不下车却坚定的要站在门口当钉子户。

结伴的人一横排占满道路，两个人并排站在扶梯上，拿着行李的人和行李并排站扶梯上。

在可以看见地铁到达的扶梯上，只有看到自己乘坐的方向车要来的时候，才会主动走，只要不是自己的方向的车来就霸占着两侧不动。经常看到可笑的现象：看到有车到达，赶紧动起来，定睛一看不是自己的方向，马上就停下，把快速通道堵的死死的。

同理心、共情这种容易消耗自己心力的能力在国人中多么的普遍缺乏，应该不至于遭到否认吧。

细节工作的不到位

公共厕所的小便池感应装置的面板上下颠倒。这个问题见到过应该有几十次了。

地铁站内部小地图指示牌装错位置，“你当前的位置”明显不是现在的位置。

难以克制的擦肩而过的负面情绪

今天在扶梯上，被前面拿行李并排站的人挡住了快速通道，扶梯到一半恰好看到地铁来了，我这时候便意识到自己克制不住的心跳加速了，肾上腺素应该也又分泌了些，一种不自觉的想跑的冲动。当不得不等前面慢悠悠的走出扶梯后，再小步快跑上车，刚好来不及上车，这时候内心又产生了一小股愤怒的情绪。

等下。我为什么急于上这班车？2分钟的发车间隔，错过这辆会造成迟到吗？并不会。为什么刚才要为这点事心跳加速，又为何因为错过而产生恼怒？并没有这种必要。

这让我想起大学时有些相似的事情。

这是大一时的事情了。一进学校就被告知过：专业第一名可以拿国家奖学金，班级前两名可以拿励志奖学金。我从来没当过回事，总觉得会跟自己有关吗，我是专业的佼佼者吗？每门考试都是像高中的时候一样的不刻意准备。体育课考试游泳，我看到自己已经游过水底代表及格的那条线以后就马上停止了，其实还可以再游一些距离。等最终成绩出来的时候，我发现我和励志奖学金擦肩而过的距离不过就是2分，仅仅需要体育课考试多坚持一下下。

越是看到触手可及的目标，感知到和目标擦肩而过越容易产生恼怒、悔恨等情绪，如果看不到反而心平气和。就此是不是就要凡事百分百努力呢？努力过后依然擦肩而过内心是不是更难接受现实呢？

我不知道答案，我只知道如果它是一个问题，意识到这种现象的存在，思考，就已经解决了一半了。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

只言片语

Thu, 01 Feb 2024 00:00:00 +0000

我们似乎长期习惯于饮鸩止渴，不管统治者还是个人，只看重解决眼前短期利益，不关心建立正反馈的机制。

我讨厌“卷”这个词，当用来形容自己时总令我读出有一种顾影自怜的感觉。用这个字形容别人的，心理又往往隐含一种虚假的恭维。很多人自我感动，完全意识不到自己是因为效率低的问题。不过这可能也是个悖论：正因为不得法，可能根本不知道更高效的办法存在。警惕那些工作狂，这种人往往不仅自己陷入恶性循环，还会拉团队下水，比一个什么都不做的人危害更大.

J. Richard 的 “60/30/10规则”：团队成功的60%取决于“团队中有哪些人?” 30%是你如何组织它的，最简单且关键的就是明确的分工。最多10%是领导力。

看剧本身就是用来同理人生、疗愈自己，以及看见跟自己不一样的世界。

地铁车门上写的：Please yield to alighting passengers. 这里竟然用“yield to”，想表达本来不该先下后上却不得不屈服吗？倒是和基本盘的道德水准不谋而合。不过不管翻译水平怎样都不重要了，以后可能是这样的翻译：Qing Xian Xia Hou Shang

今天是全民齐蹲文字狱的一天。

看到一篇介绍《The Science of Learning Physics 》这本书的文章，提到物理学家和初学者看待要解决的问题的三个关键不同点：

Experts see principles, while novices see surface features. Asked to categorize physics problems, experts organize them based on the fundamental principle involved. Novices, in contrast, focus on surface features, like whether the problem involves a ramp or a pulley. 高手看原理，新手看表面。当要求对物理问题进行分类时，专家们根据所涉及的基本原理对它们进行组织。相比之下，新手则关注表面特征，例如问题是否涉及坡道或滑轮。

Experts reason forward, while novices reason backward. Experts start from the “givens” of a problem and pick the right formulas to apply to get the intermediate quantities needed to solve a problem. Novices, in contrast, start with the goal and try to find equations to solve for the goal, working backward. This latter approach is more mentally demanding, which is one reason physics problems are so hard for beginners. 专家向前推理，新手向后推理。专家从问题的“给定条件”出发，选择正确的公式来应用以获得解决问题所需的中间量。相比之下，新手从目标开始，尝试找到方程来解决目标，然后逆向工作。后一种方法对智力的要求更高，这就是物理问题对初学者来说如此困难的原因之一。

Experts spend more time studying a problem, while novices rush to calculations right away. While experts generally solve problems faster than novices, proportionally, they spend more time trying to understand the problem before doing any computations. Novices, lacking the ability to categorize the problem by general principles, tend to rush to crunching numbers, hoping it will lead to a solution. 专家花更多时间研究问题，而新手则立即进行计算。虽然专家通常比新手解决问题的速度更快，但按比例来说，他们在进行任何计算之前会花费更多的时间来尝试理解问题。新手缺乏按照一般原则对问题进行分类的能力，往往会急于处理数字，希望能找到解决方案。在产品设计领域也可以观察到类似的现象。这种现象的起源往往源自需求的提出者提出了一个解决方案，而产品经理将其视为需求，并不会深究问题。拿到“需求”之后，就开始着手如何逐字实现。结果不仅思考过程极为痛苦，还导致将系统变得更加复杂和脆弱。

言论自由是中国目前问题解决方案的基石。

一切都是模糊的，直至你试图使其精确时，你才会发现，我们日常表达出来的精确与真正的精确相距甚远。以至于当我们说话时，你无法假设这就是对方真正的意思。 – 伯特兰·罗素（Bertrand Russel），英国哲学家

“官方”这个词深刻的反映了刻在国人骨子里的官本位思想。提起“官方”就默认了正确性、合法性、不可辩驳与无需辩驳。在英语里勉强对应的词是“official”，不要翻译直接看它的含义，不过是代表拥有正式授权的办公室有关的意味。

管理者应该主动把手弄脏，不要把“管理”想的那么高山流水。至少要把手下做的事情看一遍，做一遍，才知道他的工作性质、忙不忙、工作中最大的效率问题在哪里、做事有没有方法、你有没有更好的实践。只有这样才有实际的掌控能力。

打破恶性循环的关键在于“打破”，无法打破的理由不应该是因为处于恶性循环当中而没时间梳理。

绝大多数社畜的日常工作都没有什么创造性，总是可以套用程式思想去梳理：流程里的顺序、循环和判断，以及函数方法的输入与输出。这些东西管理者搞清楚以后，怕什么地球离了谁转不转呢？

一个公司衰亡的特征：流程和制度越来越多，做事情的制度性阻力越来越大；考勤越来越严格；沟通时的这总那总的称呼越来越多，具体指谁要靠猜；未完待续

逻辑学：一门关于思想和推理的艺术，逻辑能力的高低与误解产生的概率成反比。安布鲁斯·比尔斯这或许可以解释中国人为什么那么多婆媳之间的猜疑？

理想的工作是报酬、权力、责任、能力四者相匹配。

好的设计是没有存在感的设计，而现在大多数公司的 KPI 考核机制，恰恰需要有存在感。

容易紧张的本质是：把别人当神的同时，没把自己当人。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

和互联网失联了怎么办

Wed, 31 Jan 2024 16:34:21 +0800

与互联网连接的时候，总是难免遇到一个悖论：必须先爬墙，才能解决持续爬墙的问题。今天就聊聊目前可行的几种方式。

远程桌面

这种原理是提供一个类似于微软的远程桌面一样，通过对方无限制的网络环境临时解决问题。

Neverinstall

缺点：免费资源需要排队半小时才可能申请到资源。

远程浏览器

这一类的原理和远程桌面类似，但只提供了一个远程机器上的浏览器环境。

SquareX

选择第一项 Disposable Browsers，然后选择服务器地区，Start 即可。
可以使用微软账户联名登陆。
每次连接只有 10 min 时间。

Browserling

直接在文本框输入网址即可。
免费的只有 3 min. 可能仅够支付，耗时太长的操作还未完成就断开了。

通过给特定邮件地址发送任意内容邮件获取客户端

有些提供免费客户端的组织可以通过向其特定的邮件地址发送任意内容的邮件，即可自动回信附带最新的客户端。但注意这些免费的客户端是 GFW 的重点关注对象，长期处于猫鼠游戏当中，有些时期可能服务不稳定。以下是可以尝试的邮件(不要使用国内邮箱服务商，等于主动送人头)：

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

当我们谈论价值观的时候，我们在谈什么

Mon, 22 Jan 2024 12:46:02 +0800

价值观是一个经常用、经常听到的词，但说实话，长时间以来，我并不理解价值观的真正含义。当我们讲价值观不一样的时候，是否属于价值观的范畴可能都没搞清楚。

以前，我对价值观的粗浅理解是怎么衡量价值，这种理解是孤立的、绝对的，所以我遇到提及价值观的语境一直似懂非懂。直到最近一段时间我在读《学会提问，批判性思维指南》的时候才意识到为什么说不同的价值观决定了不同的行为。一个很关键的点在于“比较优先级” 。我们之所以这样做（想）而不那样做（想），就是因为相比这一件事而言，我认为另一件事更重要。理解这一点，再理解每个人的价值观不同之类的说法就简单多了。

每个人价值观都是不同的，出生时都在一个原点，然后逐渐受教育、文化、经历、反思、阅读、洗脑等等因素影响，向不同的方向发散。每个人的价值观形成轨迹，谁也不会和谁重合，至多是朝向一个大方向。完全相同价值观的两个人是不存在的。

想要通过讨论改变一个人的观点几乎是不可能的。

当我们对一个观点产生争议时，争论往往没有任何效果。要想取得好的效果，需要满足：

对方是基本有逻辑的。有的人只抛出观点，有些人的论据则和论点没有什么逻辑联系。识别到对方是逻辑错乱的人，最好马上停止讨论，免得浪费时间。
挖掘出隐含的价值观假设。大多数认为对方论据不足以支撑其结论的时候，是因为对方的论据背后还隐含了一个人的价值观假设。这个价值观假设往往才是对方论证的基石。当价值观被当成无可辩驳的论据存在时，每个人的价值观自然引导其得出了当下的结论。所以价值观方向相差太大的人是无法深入交流的，每个人都深陷在自己的价值观车辙里。想说服一个人，就要挖掘出对方的价值观假设，把假设推翻，但显然改变一个人某个价值观假设是非常困难的。
能够遇到一个能够心平气和的讨论问题的人。大多数人面对自己价值观的挑战，马上就会进入防御姿态，开始拒绝输入。

面对想要影响别人的冲动，只能循序渐进，通过提供给对方新的信息输入，促进个人的反思达成。欲速则不达。

人与人之间应该加强理解。

价值观的形成因素那么多，每个人形成过程不一样，谁也不是全能神，这就使得价值观非常主观，很难评价价值观的对错，只有法律限定的底线。

价值的优先级取向也不是固定的，总是依赖特定情境的。例如：我认为友情更重要，不应该告密，那么如果朋友即将要杀人，是不是就会有所调整了。面对一个社会热议的事件，在国内目前的言论环境下，你只能发出想让你发出的声音，你也只能看到想让你看到的内容。记者行业早已全线沦落为宣传工具，这让人很难获取全面的信息，了解当事人的两难处境。

虽然强调要加强理解，但理解并非等同于认可。理解是希望尽量还原一个人是如何形成如今的价值观的。如果他的价值观游走在犯罪的边缘，如何消除这种价值观形成的关键因素。如果你想改变他，又该从何入手。

个人应该主动增加输入的多样性。

一个人要承认自己价值观的局限性。只有不断的主动反思，放弃信息茧房里的奶头乐，多做些深度的阅读，扩大自己的经历，才能够逐渐打破局限性，调整自己的价值观。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

第一性原理在产品设计中的启示

Mon, 15 Jan 2024 17:41:08 +0800

第一性原理要回归问题本源，重新推导，得出最佳的解决方案。第一性原理的思想并不是新发明，而是马斯克以自己命名的方式，借助个人的影响力，使这种思想得到了广泛的讨论和传播。像企业业务流程再造的概念（BPR）就是要求对企业的业务流程（以及组织形式）作根本性的思考和彻底重建。

那么，这种思想为何重要？何时应该应用这种思想，又对工作生活有哪些启示呢？

一个结论（思想、最佳实践、规则、方法论等形式），往往是这样得出的：针对某某问题，在哪些特定条件下，基于这样那样的逻辑推导或实践总结，得到了如此的结论。结论总是可以得到广泛的传播，然而其得出机制往往少有人知晓。

首先要辨别的就是其针对的问题。对于工业生产领域的最佳实践而言，其对应要解决的问题往往是直观清晰的。但对于其他领域，一种思想、规则、解决方案等，很容易会产生理解的偏差。这些结论所对应的问题往往是被包装的，之所以会觉察到不合理、不理解，有时候就是因为没有搞清楚原来是想解决什么问题。

例如《三字经》，《弟子规》等古书里总是强调的忠孝，卧冰求鲤的故事想必大家都听过。重视孝道是为了成就更好的个体吗？不是，它的目标是家国一体，用三纲五常的伦理观洗脑被统治者，让人听话，因为国就是家，皇帝就是父，臣民就应该孝。那么到了今天又为什么还有很多家长乐于继续拿这种故事来主动教育自己的孩子呢？虽然可能不会被承认，这背后是不是因为这些故事解决了家长如何让孩子听话这样的问题呢？

例如现行的教育体制，最近很热的中考强制五五分流政策为什么会被制定呢。因为我国的教育制度制定从不是为了解决个人价值的实现，而是为了创造社会需要的螺丝钉。在这样的目标下，得以实现个人幸福的，只是“连带受益”而已。

例如我们的历史教科书和考试为什么总是逃脱不了这样的范式：祖上阔过，总被外人欺侮，现在得到如此的成就。什么是正确的历史观，利于统治的历史观就是正确的历史观。

再例如法律这个东西，在有些国家要解决的问题是如何平等的保护每一个人的利益，而在另一些国家要解决的问题是如何进行更好的统治。明白这一点，你可能更理解为什么禁止谈分权，为什么重大社会事件不公开庭审，为什么判决书不再公开，为什么不经讨论就可以快速的立法，为什么“寻衅滋事罪”始终没有被废弃……

那么，假如我们已经明确其对应的问题了，接下来看另外两个因素。假设前提与得出结论的过程。

世界是持续变化的，整体是发展的，得出结论的前提条件也是可能随之变化的。拿特斯拉的电池制作工艺来举例，原来的工艺基于当时的假设，可以说认定为最优解，但原材料价格已经变了，更有新的工艺被发明，当时的最佳实践的时效性就凸显出来了。

至于得出结论的过程，通常有两种常见的途径：通过一定的逻辑推导，或通过多次的实践总结。

通过逻辑得出结论的，逻辑链条是否足够严谨是一个需要考虑的问题。提起“逻辑”这个舶来词，可能接下来要有很多人玻璃心碎一地了。我国古代，乃至今天的国人大多数没有多少“逻辑”可言，缺乏逻辑训练。最常见的逻辑谬误怕就是“诉诸权威”了。我们是怎么得到结论的呢，往往是滥用比喻说理，大量的排比修辞强调，最后塞给你一个结论。在我看来，我们文化中相当比例的成语、歇后语、名言，只适用于给当前事态一个类似的说法来辅助理解，而不适用于当作论据。

那么通过实践总结的呢？实践总结其实已经假设了成本可控范围内得到的最优解。通过实践寻找最优解的代价是昂贵的，一个相当可以接受的可行解现实生活中可以作为“最优解”被接受。是否要重新实践总结，往往取决于前提条件的变化。

以上其实和编程随想强调的学习三个层次what why how相得益彰，甚至是受益于此，潜移默化有了今天的思考。直接采纳一个结论，是非常具备诱惑力的，因为不需要思考，也可以避免重复造轮子。但随之而来的代价是可能是随波逐流、缺乏创新、轻易被操弄。

说回本行产品设计领域。对于产品设计而言，从以下方面考虑是否适用第一性原理思考：

一般情况下我们面对的并不是行业最佳实践，大多数都不是SAP这种级别的产品，就应该假定第一性原理运用的空间还是比较广的。
通过“考古”，研究历史设计文档，研究代码判断当前系统的设计质量，也就是考察当初得出系统解决方案的过程质量高不高。
当时的假设前提也可能早已发生变化。

同时也启示我们：

写文档应该写清楚基于的假设前提，设计思路，
有哪些常见的思路为何最终被舍弃（实践过程）。

这样未来更方便重新检视流程是否需要重新设计。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

Just Get Things Done

Tue, 09 Jan 2024 14:15:30 +0800

大多数被骂没脑子的现象，多是一种 just get things done 的心态。这里的 get things done 可不是时间管理领域的 GTD，而是一种不负责任、缺乏主动意识的凑合心态。很可惜，这种心态的人在工作场所中是大多数，所以才有世界是草台班子搭成的说法。这种人内心里有一种救火心态，如果是消防员，这种人只“消”不“防”。

可惜，偏偏这种劣币常常驱逐良币。良币太“安静”了，本职工作做的越出色，越没有对比出的落差存在感。而劣币总是捅娄子，捅完就解决问题。由于往往没有完善的事故调查机制，导致常常反而造成一种劣币有能力的假象。

不要觉得自己当了领导不会让这种劣币驱逐良币的事情发生。大多数领导哪个承认自己会纵容发生，可还不是普遍现象。一方面劣币往往行事诡秘，而领导往往太偏管理向已经失去了对一线业务的敏感无法发现。再一方面，良币往往“不听话”。还有一方面是我们的思维惯性，导致难以自知。比如说，49年开始中国折腾30年，关起大门自己使劲儿折腾，折腾的统治危矣不得不搞改革开放，大家不也是歌功颂德，觉得是个良币么，但请问当年关门折腾的又是谁呢？

聊聊我在工作当中打交道的一些产品经理和研发工程师的例子。

产品经理：

传话筒。本来需求提出方就倾向于提方案而不是提需求，有些人乐于提出方提方案，越详细越好，乐享其成。
重形式不重内容。复制粘贴，完成需求文档的形式。形式完整即设计完成。
做功能不做设计，只解决当前需求，只要逐条满足对方提的方案就万事大吉。
救火心态。哪里走不通了就解决直接原因，从不溯源根本原因，导致简单的事情复杂化，系统最后臃肿不堪。

研发：

写完就提交，自己不做最基本的用例测试。
建表不考虑索引。线上卡一次加一次，而且只加当前问题的索引。
线上事故、bug不总结成 check list。永远不会吃一堑长一智，同样类型的错误下一次再犯。
产品写多少，做多少，只做功能，不做设计。字面意义上严格的按照设计文档做事情。更不会不关心第一人称的业务用例。-
改代码不看上下文，不检查改动关联点，提醒测试。
提交代码IDE对缩进处理和主干代码不一致，格式化导致覆盖掉了所有历史修改记录，却长时间无人关注提出。难道提交后无人能看见所有的提交备注都变成一个人的了吗

招聘不需要十分聪明的人，十分聪明的人本来就少数，可遇不可得。需要的是脑子一般好用，能够理解，能够学习积累，具备良好的工作习惯的人。只要能够吃一堑长一智，就像复利一样，此人必定是在不断的变优秀。怕的是今天犯的错，一年后还会继续犯同样的错误。

有人会说给多少钱干多少事，可是你至少要区分一下哪些也于己有利，考虑下是否有羽毛要爱护吧。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

离文明还有些距离

Tue, 02 Jan 2024 17:19:03 +0800

23年的最后一天去听了第一场音乐会。选择年底倒并非出于什么特殊意义，我这个人相当没有仪式感。仅仅是最近在看一部韩剧《弦上的真相》，此剧重新激起了我要看一场音乐会的想法，又因为是周末的时间也合适，票还比较便宜（只要58块钱），所以就随便选了一个。

晚上7点半开始，5点40就跟老婆从家出发了。到江汉路换乘的时候，我们被地铁站里的阵仗吓倒了：到处人挤人，各个内部的算不算得上交叉口的都设了路障。非常担心没法按时到达剧院，不停的看表。这时候焦虑源于不确定性，地铁站里那么多用于广告用的屏幕，有没有考虑过在特殊时期征用用于指引信息的显示，例如现在屏幕位置距离换乘预计还有多久，今天几点封站等等。虽然焦躁，但还是局部观察了一下地铁公司怎么控制人流的。

这种跨年夜的情况，地铁公司最关心什么：

零踩踏事故。踩踏事故一般只有零和很多两种情况。
加速周转。其实这一点算不得目标，应该说是零踩踏的实现方式。只有快速的把人流疏解到地面和驶离江汉路的地铁上才能实现零踩踏。只要站内人多，就永远处于高风险状态。

我猜地铁公司采取的策略是：

不同人流线路严格分隔成单行道，在关键入口设人管控，杜绝逆行带来的流速降低问题。
引导人群从就近的出口出站，放弃按照距离目的地最近的出口出站。一是想把人流压力快速疏解到地面。二是减少站内人流交叉。这一点实施起来很难，因为江汉路站是一个换乘站，每个节点的工作人员均无法区分人流的目的是换乘还是出站，所以只能依靠喇叭喊。关于这一点，交警遇到十字路口发生死锁（Grid Lock）的时候也常采用这种疏导策略，即“我不关心你原来的目的地是直行还是左拐，现在的最高目标也是唯一目标就是解锁，所以车辆听指挥，快速的离开当前的死锁区域。至于原目的地，绕行解决。”遇到死锁问题，一定要修正疏导目标，如果仍然将原行进方向当作约束的话，想解开死锁会非常耗时。常常会发现，刚刚解开一点，后续车辆又快速填充了被解开的位置。
同一流向的线路上利用原交叉口的设施分隔为多段，每一段都尽量保有自己的缓冲空间。当后方缓冲空间即将耗尽或者前段有较大的缓冲空间时向前方路段放行。这一点其实是 divide and conquer 思想的应用。把复杂场景分成多个小场景，通过多个缓冲区增加了柔性。试想一下万一出现踩踏事故，地铁里所有人流是一条几百米的长龙的话，踩踏只会快速恶化，而且工作人员无法快速进入事故区域进行干扰。但这一点上实施起来想要控制合适的缓冲大小和控制放行的时机并不容易把控，因为每一段的设定常常依赖原设施的柱子等隔断导致每一段的长度相差很大，有的路段还有窄长扶梯。空间大小和流速都不太一样，控制起来比较有挑战，需要多个路段的工作人员紧密协作。但这种时候人员很多，地铁公司即使从其他路段借调对讲机，也会对如何分配信道、同一信道太多人在里面的对讲机使用规则提出很高的要求。我反正是没听到地铁工作人员平时用对讲机有多讲究规则，还不如当年在仓库的时候讲规矩。关于对讲机的使用，想一想为什么总是在电影里听到 Roger that. Copy that. Over. Alpha,Beta…
防止踩踏。当各个路段有效控制自己的缓冲空间时，最容易发生踩踏的路段就是扶梯了。地铁公司应该对扶梯段也是高度紧张的，之前也有商场、地铁扶梯被挤坏的报道。其他路段的秩序维护人员都是地铁公司的工作人员，而扶梯段则是安排的辅警在盯着，并且不停的高声警告不许推搡、从侧面插队。

就这次体验来说，我对江汉路站里的疏导方案还是认可的，没有一眼看就吐槽的地方。可惜没有机会全面的观察江汉路的地铁疏导方案和地面人员疏导方案，由于在仓库久了，对于这种高压场景总是充满兴趣。

还好，最终换乘花费了20分钟，尚在这次出门准备的宽放范围内。上了2号线远离江汉路方向，车上人流量就恢复正常了。

七点前就到达了剧院，剧院大门紧闭，到门口也看不到任何告示，也不知道几点开门。观众在外面零零散散的站着。这种感觉很不好，服务的提供者应该减少被服务者对未知不确定性的恐慌，剧院其实只需要在门口张贴一张几点钟开门的告示，或者说在卖票的网页上声明自己接受观众入场的时间。

观察了一下剧院外候着的观众，只有极个别的刻意打扮而来。我跟老婆头一天还商量这音乐会外国人不是总是男的西装革履，女的晚礼服么，我们穿个羽绒服会不会太随意了显得对演奏者不够尊重。但阿Q一下，感觉在这方面我们整体跟人家还有相当的差距，穿的不扎眼应该就可以了，于是每人穿了一身黑。

七点剧院开了正门，人群涌入。左手边一排桌子有纸质的票，不少人凑了上去排了队才发现跟自己无关：猫眼渠道买的需要换实体票。我对剧院的好感继续降低，引导观众很难吗？

开门放人没几分钟后就开始检票入场了。这时候我才明白为什么大麦的小程序一直在强调票的二维码截屏无效。我还纳闷呢，你二维码又不是动态二维码，就算是动态二维码只要我截屏和扫码时间差足够短保持在失效范围内也没关系啊。结果二维码检票靠人看，只要看到是大麦，二维码的边在动就可以进场了。。。这个东西有点太容易伪造了吧，做个H5页面，手机发送到桌面伪装成全屏应用，哪里看得出差别。。。

进来以后，找自己座位，又要忍不住吐槽了。座椅的排数是在路边很容易定位的，可是每排的座位号确都在座位的背面。假如大厅座位排列是一个规则的矩阵也就算了，人们只需要看前一排的号码就可以确定自己的号码，偏偏这种大厅在设计时考虑到声波的反射，往往都是不规则形状的，每一排的座位数都可能不一样，甚至呈扇形分布，连对齐都不会对齐。每个人进到自己的那一排后，就难免要探头到后面去看号码。这在刚入场的时候还行得通，随着逐渐落座，这种做法会越来越不可行。所见却非所得，这种类似体验在各种影院、剧院都非常常见。是什么制作工艺上的难关无法克服吗，我想并不是。

坐下以后，舞台边侧门就开始排队了。这个队伍一直排到演出开始。一看性别都是女，那不用说，这门后肯定是卫生间。哪天看不到这种单一性别排队的现象了，那可真是文明的一大进步了。

演出到点儿开始了，好多手机屏幕也亮起来了，闪光灯闪起来了。我理解拍个照发个朋友圈的冲动，刚开始拍几张就拍几张吧，可是闪光灯的问题是习惯性的不把对别人的影响放在心里才会这么多闪光灯的吧。表演者上台，应该礼貌性的鼓掌欢迎吧，你们举着手机拍照哪有手鼓掌？最后，只听见稀稀拉拉局部的一些掌声。

指挥上台，没有主持人，指挥自己兼任，虽然我第一次来，还是觉得挺哭笑不得的，感觉像是过家家，剧院只是出租场地。

指挥开始前先说了一大段，还说什么“本来不让讲”。先解释了前段时间网络上说他们和武汉爱乐名字类似的冒名风波问题，然后表示团员们都心情不好备受打击，所以今天表演不好的话大家多见谅。言语中还强调，自己的乐团团员是“真正爱音乐，视音乐如声明的艺术家”，合着这意思是另一个在风波中的乐团不是呗。“本来不让讲”，不让讲就别讲呗。大家都是拿钱买票进来的，先做好本职。“真正爱音乐”，“艺术家”就应该用实力证明，而不是嘴皮子。指挥的解释在我心里没赢得多少好感，反而觉得没有受到尊重。

演出开始，咱也不懂音乐，也不敢点评，只是有几点感受：

首席小提琴真的很好分辨，很重要，难怪看韩剧里这个任命那么容易起争议。音乐里最凸显的声音就是首席小提琴发出的声音，就像一条大河，其他的小提琴声都是支流汇入。
看着谁就能分辨出谁。通过拉弓的动作可以很容易的辨识出来现在听到的音乐里哪个声音是当前这位演奏出来的。
单簧管给我的感觉像是漫布的背景声，总能感受到它的存在。

虽然咱不懂音乐，但是有些曲目还是能感觉到“乱”，看小提琴的动作也能感觉到大家不齐。中间还演奏了《权力的游戏》主题曲，演奏完直接观众席上听到有人骂”垃圾“。这首曲子年轻人都很熟，我也是感觉还不如看电视的时候听到的宏伟有力。

因为没有主持人，指挥每次演奏一曲结束后，都伴随着整理乐谱、拿话筒的动作，搞得下面都不知道该不该鼓掌了，甚是尴尬。更尴尬的是表演中途，又再次强调艺术家们压力大，让乐手又起身鞠躬要掌声。看着乐手一个个面如死灰，我也不知道他们怎么想的，自己一定也很尴尬。

演出中途后面一对母女总是在交谈：”这是你学过的曲子“，”妈妈，刚刚变拍子了“……。我想说，光掏钱送孩子学音乐了，怎么连音乐有关的礼仪都不学一下？因为学音乐是为了加分吗？肯定不是为了陶冶情操。我还闻到了汉堡薯条的味道，妈妈在一旁催：快吃！

前面几排总是又几个手机一会儿掏出来拍几张照片、录一段视频、挑一条刚拍的照片…… 这公德心不知道哪里去了。这可不是自由问题，自由不能以令他人受损为代价。

听到后半段，观众席上骂声变的频繁了。观众席上也发生了争执，大概是分成两派，一派是骂乐团水平太差对不起观众的，一派是别人在表演呢，你不要闹，你不愿意听我们还愿意听呢。两派差点打起来，不过不了了之。

这两派我倒都理解，自己呢属于骑墙。主要是因为我既不懂音乐，无法评判其水平和票价是否匹配，缺少点底气，又因为今天的票便宜没有强烈的落差，可不能跟前排全价买票进来的比。

等到表演结束到返场环节，我猜可能会尴尬，没想到真的尴尬了。这个返场环节我有点不能理解，为何会出现在节目单上。返场难道不是因为演出精彩，观众掌声不断强烈要求加演才形成的返场吗？如今已经演化成标准环节了？对自己的表演这么有自信？只见乐团指挥静静下场，无人鼓掌，观众当中一片寂静。过了一会儿，指挥重新上台。应该是”灰溜溜“的吧。直接就开始返场的第一个曲目，表演完又被观众骂了，这次是”退票“。这回指挥也实在没脸了，就要结束。下面观众里一部分不乐意了，你这节目单上不是还有个梁祝没表演吗，怎么就要走呢，就还是要听。于是指挥尴尬的笑笑，继续开始返场第二个曲目《梁祝》。这个曲子听到后段是首席小提琴独奏部分，就在这时候，今天的高潮来了。观众有人陆续开始离场，嘴上骂骂咧咧。坐在最中间的单簧管突然站了起来，卷起乐谱起身就走。紧随其后，其他管乐乐手也一起起身离开。接着除了正在演奏的首席小提琴之外的弦乐手也都收拾谱子转身离开。观众离场开始规模化，首席小提琴也拉不下去了，停止了演奏。整场演出就这样结束了。

诚然，直接中途离场的乐手表现得不够专业，不够尊重观众，但这个责任我觉得还是应该公司背负，指挥背负。为何要把乐团置于今天的境地？商业演出应该做好专业的准备不是吗？是欺负观众大多数欣赏不出来高下吗？

还想说，年轻人果然有性子。今天演出的乐手年龄应该都没超过30岁的，一个比一个年轻。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

关于

Thu, 31 Aug 2023 00:00:00 +0000

一个热爱自由，讨厌约束的人。

一个接受规则，但探究规则制定的本意而敢于打破规则的人。

一个喜欢折腾、爱学习，却又容易浅尝辄止、见好就收的人。

一个什么都懂一点，恰好适合当产品经理，在各种角色当中游走的人。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0

归档

Tue, 28 May 2019 00:00:00 +0000

搜索

Mon, 01 Jan 0001 00:00:00 +0000

一家之言，胡言乱语

软件架构之前后端分离的外行一知半解

关键区别点在于能否项目拆分，分别部署

页面渲染方式不同

后端方法的复用

B2B 系统的“现代化”陷阱：快 vs 美

前后端分离给分工带来了更高的要求

前后端分离隐含的无状态管理大坑

不要因为好看一个原因选择一个组件库

我读

如何设计一个规则引擎

本质

对象

比较运算符

值

逻辑运算符 与 或 非

计算顺序

代码执行顺序

结果

问题

新增一条规则后，怎么知道规则逻辑对不对？

新增一条规则后，可以验证该命中规则的命中了，怎么确保不该命中规则不命中呢？

规则太多，管理困难，新增编辑规则时，完全不知道相关的规则有哪些，优先级应该如何制定

好的实践

产品经理如何写接口文档

我的定义

HTTP 协议结构

请求方法 method

请求地址 URL

请求地址

请求参数 Query Params

请求头 Headers

请求体 Request Body

字段名

字段数据类型

是否（选择性）必须

注释

响应 Response

其他非结构性的必要元素

认证鉴权等安全性问题

其他元素

每天坐地铁见闻

安检员的“敬业”，与我对安检措施的无条件的厌恶

普遍的缺乏不影响他人的意识

细节工作的不到位

难以克制的擦肩而过的负面情绪

只言片语

和互联网失联了怎么办

远程桌面

Neverinstall

远程浏览器

SquareX

Browserling

通过给特定邮件地址发送任意内容邮件获取客户端

当我们谈论价值观的时候，我们在谈什么

第一性原理在产品设计中的启示

Just Get Things Done

离文明还有些距离

关于

归档

搜索

逻辑运算符与或非