NotionNext BLOG

SQLChat尝鲜记

Tue, 11 Apr 2023 00:00:00 GMT

作为一个经常利用Bytebase公号软文来给自己的知识体系打补丁的“九漏鱼” 🐶🤣，自己此前看到sqlchat发布文章时，就感叹原来今时IT行业的新鲜玩意儿并不是我们这一代人突然开了天眼洞察出的市场需求，反而大部分是对既往同类目的产品的一次次改造、迭代、升级，只不过现代人更擅长新造名词罢了。而对于ChatGPT这一当红辣子鸡，原本自己更多地觉得这是对信息检索的革新，但文章中提及的“这是交互方式从GUI演化到Chat”的观点确实很inspiring。毕竟，想想吃到从CLI到GUI变化红利的Microsoft和Apple，就更对这样交互方式变革背后的商业机会肃然起敬了。

在前不久参加Bytebase新手村任务时，自己就对Chat SQL的自动写SQL功能进行了试用，感叹这简直就是对SQL女工的革命性解放。于是，在新产品SQL Chat发布的第一时间，自己就进行了试用。趁此次新一期产品体验官活动，回头来再次使用对比并整理成文。

以下是本文目录，可根据实际需求食用：

1 sqlchat.ai基本情况 2 作为用户，感知到的AHA moment 2.1 响应快 2.2 chat+execute的丝滑 2.3 change data等写入操作不直接提供执行 3 作为好奇宝宝，探索发现的功能实现方式 3.1 聊天机器人 3.2 创建数据库连接 3.3 查询 4 作为找茬专业户，需要指出的问题 4.1 等待服务器响应时间频繁过长 4.2 新建数据库连接时 4.3 数据库连接密钥存储问题 4.4 连接数据库后，无法展示ER图 4.5 单次对话组中，chat接口返回内容没有联系上文（和此前的结果联动）5 总结 About Author

1 sqlchat.ai基本情况

URL：https://www.sqlchat.ai/，大概是03-20创建的

部署在Vercel，服务器位于US；刚发布时大中华局域网可直接访问（而且挂梯子的话机器人返回速度会慢3x），但目前好像还是得挂梯子才能访问；

若使用上述云服务，OPENAI API费用由Bytebase承担；若本地部署，需要用自己的API KEY，API费用由自己承担；

chat接口调用的是OPENAI的GPT-3.5-Turbo模型；

（跑个题，考虑到这个团队的未来前景，我是不是该先去把其他相关地址注册下，以方便以后好狠狠敲一笔🙊）

2 作为用户，感知到的AHA moment

2.1 响应快

如果说ChatGPT目前在用户体验方面有痛点的话，那这个痛点就是其返回内容的速度了。所以一开始和机器人聊天的时候，原本已经做好了响应速度会很慢的心理预期，但实际使用时却发现这响应速度简直惊人啊！试了很多次后发现content download前的waiting for server response时间基本都在1s内，网络不差、chat内容没那么那么复杂的时候可以在500ms内，这速度相较于ChatGPT简直逆天了。

当然，由于现在需要梯子，如果代理选择了香港的线路而不是美国的话，前面的等待速度就会长很多。

2.2 chat+execute的丝滑

在连好自己放在AWS RDS的employees数据库后，进行了chat👉query操作。由于此前已经尝试过Bytebase里面的Chat SQL功能，所以对于目前的SQL自动生成功能并没有那么惊讶（dbq，我飘了 😈）。但这里的交互明显比之前嵌在Bytebase里的ChatGPT+NotionAI合并式的交互方式要自然得多，就整个一丝滑流畅。

2.3 change data等写入操作不直接提供执行

考虑到Bytebase主产品在change data时审核的谨慎，自己在SQL Chat斗胆试了试drop table和update命令，发现会返回SQL语句，但不提供执行按钮。这么细节的考虑对一个MVP产品而言，也太难能可贵了吧！

3 作为好奇宝宝，探索发现的功能实现方式

3.1 聊天机器人

用户输入文本，点击【发送】图标或输入回车后，调用chat接口；

chat接口的入参中的message是用户在此次对话中所有历史内容；

chat接口返回内容即是调用openai api + 基于规则生成的内容；

3.2 创建数据库连接

点击save前，都是前端；

点击save后，先调用test接口；如果成功，则调用db接口；如果成功，则返回页面；

test接口：

请求方式POST，请求地址https://www.sqlchat.ai/api/connection/test
请求入参：用户输入的数据库连接信息

返回结果：（状态码）

db接口：

请求方式POST，请求地址https://www.sqlchat.ai/api/connection/db
请求入参：用户输入的数据库连接信息

返回结果：数据库名称

3.3 查询

用户输入文本，点击【发送】图标或输入回车后，先调用db_schema接口

再用db_schema接口返回的数据库schema信息/建表语句作为入参，调用chat接口

再用chat接口返回的sql语句作为入参，调用execute接口

step1：调用db_schema接口

db_schema接口：

请求方式：POST；请求URL：https://www.sqlchat.ai/api/connection/db_schema
请求入参是数据库连接信息

返回结果：该数据库的建表语句

step2：db_schema返回后，调chat接口。

chat接口：

请求方式：POST；请求URL：https://www.sqlchat.ai/api/chat
请求入参：一个消息队列，包括db_schema的返回结果、用户的输入内容

返回结果：SQL语句

step3：点击【执行】按钮后，调用execute接口。

execute接口：

请求方式：POST；请求地址：https://www.sqlchat.ai/api/connection/execute。
请求入参：用户此前输入的数据库连接信息+chat接口返回的SQL语句。

返回结果：sql执行结果

4 作为找茬专业户，需要指出的问题

4.1 等待服务器响应时间频繁过长

SQL Chat刚发布时，明显的是飞一般的速度，能体会到的延迟大多在1s内。但这次自己再用时，明显感觉响应速度降下来了。除了考虑到自己使用梯子带来延迟这一外部因素外，请求发送后，waiting for server response时间超过5s的情况也频频发生。

由于db_schema接口并没有调用OPENAI的API，不受其模型变慢的影响，所以应该还是SQL Chat这边负载均衡的问题。如果我之后真的要常用SQL Chat的话，这个速度确实会有点劝退。

🤣当然，也可能是我这边网络的问题，没有控制变量测过。

4.2 新建数据库连接时

缺少连接名称、密码隐藏、测试连接按钮等上一代SQL Client已经培养出的用户习惯的功能（不过这些都是细节小问题，不影响产品主干功能）。

看了下test接口和db接口的设计，目前都有tittle字段，猜测对应数据库连接名称。但目前为空，不知道之后前端会不会用上。

在SQL Chat刚发布时，本来还在吐槽数据库连接缺少SSL，但没想到这次再用时已经补上了这块儿功能，这迭代速度真心绝绝子👏👏👏。

但参考自己在使用SQLtron时只需勾选SSL、无需自己准备CA证书的使用经历，这里可能、也许、maybe做到SQL Chat的云服务中？（对CA证书的生成细节不太了解，不知道该想法是不是真的可行的）

4.3 数据库连接密钥存储问题

db_schema请求的入参，私钥完全明文，说明之前建立数据库连接时密钥也是明文存储的。虽然数据库连接信息是存储在浏览器缓存里的、网络连接时也可以通过SSL来做通信的加密，但感觉这里password在转存到浏览器前确实应该做一次加密，毕竟不是直接传用户填入的POST内容，至少不应该能通过F12直接看到password明文吧？（当然，实现是否可行、具体怎么实现我也不知道🐶）

尽管github上有写数据库连接存在本地浏览器、仅会把schema信息传给OpenAI（而不是table中一行行的实际数据）、我也并不在意schema信息传给OpenAI（毕竟我用的是MySQL和PGSQL的官方样例库），但密钥明文这一点确实让人有点不安心。

4.4 连接数据库后，无法展示ER图

无法展示ER图，用户连接后无法知道数据库结构，因此目前还无法替代dbeaver等工具；

4.5 单次对话组中，chat接口返回内容没有联系上文（和此前的结果联动）

前往发现chat接口的入参包括此次对话中的历史输入，但自动生成的SQL并没有把对话上下文考虑在内。这个要求可能有点吹毛求疵了，但从使用ChatGPT和NotionAI的经验来看，它们确实做了同一次对话、同一页联系上下文。

上述这些问题和发现的其他问题，自己之后也会找时间提到github issue的bug report和enhancement里。

5 总结

SQL Chat整体给我的惊喜远大过使用细节上的小缺憾，真的应得上产品发布推介文所述的是GUI到Chat的交互变革，希望早日能冲上Dev Tools 2.0 Portfolio！

About Author

a 2-year data platform PM at an indigenous tier-2 public cloud provider, focusing on privacy-preserving computing, data security, data opening, system security, product process optimization, product QA test, user experience, & etc.

have experiences in data mining projects, but no SWE/SRE/DBA work background

have experiences in using ubuntu, docker, aws rds, google bigquery, snowflake, databricks, fivetran, dbt, chatgpt, notion ai, web & data security products

familiar with sql, python, gitlab, jira, dbeaver

name:rachel, gender:female, age:27, contact:luorachel228@gmail.com

Bytebase产品试用体会

Tue, 21 Mar 2023 00:00:00 GMT

写在前面

作为数据领域的techPM，自己一直有关注data stack和一些工具类的产品。在一次PM线下见面会上机缘巧合知道了bytebase，之后就被他们的Logo、官网、文档、招聘流程、远程办公、成员背景吸引，好奇这样神奇的团队到底能做出什么样的早期产品出来 🧐。

一直想使用这个产品，但又一直没把这件事的优先级放得那么高。上周以会落选的心态（毕竟我只是个PM，不是这个产品的核心目标用户 🤣）报名了 Bytebase新手村任务，意外被通知入选了 😛（看来还是不能给自己设限hhh），这周末的P1事项就安排给了bytebase。

根据任务需求进行了产品体验，于是乎有了这篇文章。夸夸夸的部分集中在【2.1让人眼前一亮的功能点】和【3 summary】，其他部分主要讨论一些使用上的一些细节问题（毕竟还是要以帮助产品迭代为目的）。

以下是本文目录，可根据实际需求食用：

写在前面 1 个人背景 2 feature snapshots & thoughts 2.1 让人眼前一亮的功能点（a.k.a.我自己私心特别喜欢的）2.2 ChatSQL使用细节问题 2.2.1 OpenAI API key 私密性问题 2.2.2 ChatSQL block放置位置 2.2.3 结合insert需求使用ChatSQL，发现生成的SQL没把schema中要求的唯一性考虑在内 2.3 issue review使用细节问题 2.3.1 没有disapprove，虽然提供的cancle issue也能达到disapprove目的，但cancle的说法会让人误解成删除此条issue记录 2.3.2 报错后，retry按钮的置灰应该是和activity中的状态有联动 2.3.3 把issue重新assign给DBA后，DBA却没有approve权限 2.3.4 default issue name 2.4 alter schema 使用细节问题 2.4.1 弹窗跳转 2.4.2 rename table时的提示 2.5 RBAC 细节问题 2.6 system security细节问题 2.7 others 2.7.1 sign up时的交互提醒问题 2.7.2 subscription说明有点让人混淆 2.7.3 GitOps / SSO 让人充满好奇 3 summary

1 个人背景

a 2-year data platform PM at an indigenous tier-2 public cloud provider, focusing on privacy-preserving computing, data security, data opening, system security, product process optimization, product QA test, user experience, & etc.

have experiences in data mining projects, but no SWE/SRE/DBA work background

have experiences in using ubuntu, docker, aws rds, google bigquery, snowflake, databricks, fivetran, dbt, chatgpt, notion ai, web & data security products

familiar with sql, python, gitlab, jira, dbeaver

name:rachel, gender:female, age:27, contact:luorachel228@gmail.com

2 feature snapshots & thoughts

2.1 让人眼前一亮的功能点（a.k.a.我自己私心特别喜欢的）

💡

Quickstart

作为一个新用户，虽然之前零星看过bytebase的功能介绍、demo视频，但自己部署后面对左侧和顶部的一级菜单确实会一时搞不清楚逻辑，但我又不想浪费时间不分主次地逐个去点击。于是乎这里的Quickstart就能让对to-do-list有强划线习惯的我跟着这里的list去看到底都有些什么功能，这个交互真的太赞了。

💡

ChatSQL

作为一个没怎么写过ddl和select以外dml、以及一段时间不写select后再写时经常因为脑子记不住太细节的语法而被报错的人，有了ChatSQL后终于感觉自己终于不是拖油瓶了！！！依赖奇奇怪怪语法细节或者SQL方言的事情它可以直接帮我做，而我所需做的就是在报错后及时排错，这样太解放人类大脑了吧。发现它对中文的支持也不错后就更放心了。

💡

Alter schema时的及时交互

很喜欢这个schema diagram的可视化风格，比navicat和dbeavor的上世纪风格好看太多了。

看到点击删除、修改not null设置后，直接有了红色和黄色的醒目提醒，这个功能很喜欢。

这个upload和sync的功能也很喜欢。upload可以用在有别人写的/在其他地方写的sql脚本文件快速同步过来的（避免了手动复制粘贴）。sync可以检查刚刚在editor编辑的语句。

💡

drop table前的重命名

这个删表前需要重命名的功能，很喜欢，让人谨慎谨慎又谨慎。

2.2 ChatSQL使用细节问题

2.2.1 OpenAI API key 私密性问题

OpenAI的API key在产生后，便是遮挡显示，甚至没有设置可见的👁️按钮。

但是Bytebase的AI增强在输入key后，直接连，全部明文显示😲，连像密码中设置不可见👁️按钮都没有，让人有点不安心。

2.2.2 ChatSQL block放置位置

ChatSQL的交互是ChatGPT和NotionAI的结合体，但放置位置有点奇怪。

ChatGPT的对话框输入内容在底部，生成的对话内容在上面，这点没什么问题，因为对话内容就是返回结果，没有又一层执行sql后的返回结果。

Notion AI的对话框输入内容在上方，生成的对话内容在下方，这点也没有什么问题，因为可以直接把对话内容插入进文档中。

但这里ChatSQL放在中间，先在中间输入需求，然后自动在输入框上方生成对话，然后执行sql后再在输入框下方生成查询结果。虽然有点吹毛求疵，但这种交互确实有点奇怪。

另外，上方对话内容生成SQL语句后，有时会出现执行按钮错位的UIUX类的小问题。

2.2.3 结合insert需求使用ChatSQL，发现生成的SQL没把schema中要求的唯一性考虑在内

scenario

希望探索change data后的审核功能，模拟的场景是在department表中insert一条数据提交给tech lead审核。但我忘了具体的insert语句怎么写，于是想到了用chatsql帮我写。

summary

功能使用不方便之处：

💡

1）chatsql不仅可以用在select语句中，也可以应用在change data中自动生成insert/update/delete语句。但目前用户需要先到sql editor中生成带select的insert语句，不能直接在change data中的sql区直接生成，使用上很难受。 2）使用change data时，issue的creator在发现sql语句有错需要返回修改时，会被retry误导

发现了bug：

💡

1）schema editor里面的row count字段有错。 2）chatsql在生成insert语句时没有把名称唯一性要求考虑在内。

specific steps / how to reproduce

step1：忘了insert语句怎么写，让chatsql帮我写。看自动生成的sql语句也符合该表各字段的名称命名规范，决定在change data中去掉select后执行该insert语句。

step2：从change data进入，复制刚才的insert语句，create issue

step3：作为审核者，在看到run check都没warning的情况下，点击approve。可是结果却报错？？？

step4：发现error是名称唯一性约束导致的后，返回sql editor，查询department表中的数据。结果发现是有数据的（明明之前schema editor里面显示该表是没有行的）。这意味着：1）之前schema editor里面的row count字段是错的；2）chatsql在生成insert语句时也没有把名称唯一性要求考虑在内。

step5：找到错误原因后，想返回修改insert语句。直觉想法是在下面的sql区内直接修改，结果提示我这一块儿是只读的。于是以为需要retry后才能修改，可是点击上方的retry按钮后发现retry是重新执行dml语句，而不是返回到ddl语句修改。摸索一阵后才发现旁边小小的编辑按钮。

step6：重新编辑insert语句后终于成功。

2.3 issue review使用细节问题

2.3.1 没有disapprove，虽然提供的cancle issue也能达到disapprove目的，但cancle的说法会让人误解成删除此条issue记录

在审核schema变更issue时，当需要disapprove的时候，发现找不到入口。

虽然实验下来发现能直接通过cancle issue来拒绝变更，但如果没有拿一个sample issue来实验的话，还是不太敢直接点cancle。

2.3.2 报错后，retry按钮的置灰应该是和activity中的状态有联动

发现随机insert的内容违反命名规范后，想直接返回修改sql语句，但retry按钮和sql功能区都不能让我快速返回修改。

第一反应是点击retry返回修改sql，但发现retry是基于现有的sql尝试执行change data，会多一条报错。然后反应是在sql区修改，但提示这里是只读。第3次尝试点了旁边的编辑按钮后，才发现还是可以修改sql语句的，这才顺利修改。

为什么retry不是直接返回到修改sql的状态？为什么要让我进行前面2次试错？

考虑到实际生产环境中，issue的creator和reviewer应该是2个人，所以重新建了个DBA角色的用户作为creator，将这个issue分配给admin角色的用户，体验在retry时两个页面的区别。

果然，发现刚才的问题是因为creator和assignee是同一个人才造成的。creator创建issue后，由于没有retry按钮的干扰，在发现sql问题后，直接在sql区编辑被提醒后，根据人的直觉很容易点击旁边的编辑按钮进行重新编辑，就没有了刚才的问题。

但作为assignee的admin在approve后，发现因为名称唯一性问题sql执行报错，出现了retry按钮。但此时要修改错误的话，流程应该是先把issue返回creator修改sql，确认creator修改后再retry，而不是直接让admin直接retry。虽然也能根据activity来判断issue的creator是否有根据要求修改，但感觉retry按钮的置灰应该和issue的返回/或者下面activity的状态来调整。

2.3.3 把issue重新assign给DBA后，DBA却没有approve权限

为了体验admin/DBA/dev的角色权限差别，重新部署容器后，把默认的schema审核任务分配给DBA。但以DBA的身份登录后，却发现没有approve入口？？？

再做个小实验。

以developer的身份新建project后，分配给DBA。但以DBA的身份登录后，命名看到assign给自己了，点进去审核却发现还是没有approve按钮。

重新把assignee修改为admin后，以admin的身份登录，才发现有approve按钮。

既然只有admin角色的用户可以approve，那为什么assignee的下拉框要有DBA角色的用户呢？这个问题不知是否只是此次镜像的问题。

2.3.4 default issue name

默认的issue name是dbname+action+timestamp，但我作为用户，为了快，就懒得去修改默认名称。导致最后list里面一堆同名issue我不知道是啥，也没有显示description，就让我需要逐个点击进去看。

感觉可能默认名称修改为事件会好一些。

2.4 alter schema 使用细节问题

2.4.1 弹窗跳转

点击列表内容后，页面直接跳转，next按钮没什么用。

2.4.2 rename table时的提示

drop table前需要重命名表，这个功能非常喜欢。但这里【_del$】的正则表达式和【_del】的后缀会让人有点混淆到底要不要加【$】。比如此次重命名就先改为【_del$】后发现无法删除，才又返回改为【_del】

2.5 RBAC 细节问题

为了体会DBA&Developer&TechLead的工作协作，重新部署了重启拟分角色协作。

在admin创建member时没有设置密码，内心os：这里又没有自定义密码或者默认密码或者发邮件给用户让他新设置密码，那这些用户怎么登陆？

果然，登录的时候提示密码错误。点击forgot password也是要联系admin，可是我admin也没有reset password的权限啊；点击sign up也是提示用户已存在。无解。

只好新注册dev2和dba2用户，然后登录admin来修改他们的角色。

内心os：逻辑难道不应该是一开始admin在分配用户角色的时候就报错该用户不存在吗？为什么要让我分配后发现该用户无法登录，然后再新建用户，然后再重新分配用户角色？

不知这是不是镜像的问题，还是saas服务中也存在该问题。

2.6 system security细节问题

注册时密码没有格式及长度要求都可以注册好，密码位数不够，明显不安全。

在故意输错密码后连续20+次点击sign in，只是报错密码错误，没有出于安全问题进行账号冻结/锁定，这明显是不符合等保的基本要求的。

看到注册和登录的安全防范机制是这样的后，有点不太敢使用SSO等功能，怕因为bytebase这里有安全漏洞害我别的账户受牵连。

2.7 others

2.7.1 sign up时的交互提醒问题

2.7.2 subscription说明有点让人混淆

作为一个PM，自然会好奇Pricing方案。但看到我的subscription既是写的enterprise plan，但seat count又是team plan、subcribe也在team plan下时，内心OS：所以我这到底是什么plan？

2.7.3 GitOps / SSO 让人充满好奇

看到bytebase对自己的介绍是服务于GitOps工作流，想到日常和SRE+developer工作时他们的任务流的混乱，就特别想体验这个功能。

根据提示在Github完成了OAuth配置、拿到了ClientID和secret，却发现报错没有配置external url，回到新手指南配好它，结果却连github都无法访问了，还以为是配external url时候直接修改了我本机的网关。排查一通下来发现是因为我自己的梯子服务商出问题无法进行下一步，哎。SSO也是同样的梯子问题。

只有等梯子好了再重新试试。对这一块儿功能实在是太好奇了。

3 summary

💡

关于新手指南

get started文档写得非常清晰，从deploy到configure external url都没有遇到什么关键步骤是文档中没有提的，给文档工作点10086个赞👍。

此外，产品中的issue review/alter schema/change data/project/database/environment等功能也能够直接根据自己的认知+产品页面功能设计去一步步把流程往下推，不需要再依赖看其他文档/操作手册来进行下一步，这点非常难得，谢谢PM的良苦用心😀。

大致看了看gitbook中get started附近的其他文档和tutorial，应该会在之后使用saas产品时来逐一摸索。

💡

关于部署

虽然一开始会好奇既然镜像在docker hub，为什么没有docker pull就直接开始docker run，但实际操作后还是很顺利地就把bytebase的容器给拉起来了。初次部署上没遇到什么问题。

但后来想配置external url又担心影响现有的容器，就又新拉了一个容器，2个容器同时run。可能是共享了一些volumn的原因，新容器用了老容器的账户系统，但又在拼命报错，额。

于是就把2个容器删掉从头再新部署，愉快地重新开始玩耍。

但后续即使容器重新部署了，电脑关机后再重启容器，会在进入setup admin account时，页面下方疯狂报错invalid。

💡

关于SQL editor

自己之前用狗家的BigQuery时，就一直感叹这SQL editor做得也太好了吧。现在看到一款才做没多久的产品能够媲美当时用狗家产品时的体验，就很惊喜。

再加上现在接入OpenAI API后，直接解放sql女工！

之后探索其saas产品如果发现能完美契合自己的其他常用的数据库/RDS的话，之后的sql editor应该就选它了，navicat/dbeaver/sqltron这种单点工具应该也就放弃了。

💡

关于对Bytebase核心功能的探索

此次产品体验真的又应证了那句话：

要快速有实感地了解一个产品，最好的方法还是直接用。

虽然之前一直有关注bytebase，知道它大概在干什么、属于哪个范围的产品，但明确知道bytebase在干什么还是这次亲自上手用后。

此次对其issue review, alter schema, change data, sql editor, sql advisor, RBAC功能都有了实感，但对backup & restore，回滚，批量等功能还没有仔细体会，之后应该会用其saas产品来进一步了解。

💡

in-a-nutshell

aha moment：1）deploy的方便性；2）真正把用户当人去尊重的UIUX风格和文档清晰度；3）SQL workflow的整体流畅度

犹豫点：自己部署试用过程中发现了一些产品bug和安全性担忧，之后应该会通过探索saas产品来看看这些问题是否一直存在。如果自己的顾虑能打消的话，会把bytebase作为个人常用工具。如果个人使用一段时间后非常流畅的话，会把Bytebase推荐给团队的SRE/DBA/TechLead。

工作繁重，我们是否还应花时间阅读文学？

Sun, 01 Jan 2023 00:00:00 GMT

冯古内特，哦不，冯内古特的《五号屠场》和《囚鸟》已经躺在我的to-read-list好几年了，但至今都没找到合适的情绪状态去看。意识到自己是真的懒，于是找了个捷径——看采访，于是翻出了这本《冯内古特：最后的访谈》。

之前看这个系列的海明威那本时十分失望，因为能明显地感觉到海明威本人对吐露内心真实想法的抗拒，访谈内容也流于表面、拼拼凑凑。但冯内古特这本有点相反的意味，更像是冯内古特为了揭示一些观点而做的自我对话，毕竟第一篇的序言就是：

受访者（冯内古特）对自己的谈话记录感到无比担忧，于是对组合后的采访稿做了大量修改。实际上，以下可以看作一次他对自己的采访。

访谈中有许多提供不同视角的金句，譬如颇有欧洲艺术电影感的：

我觉得存在于生活中心最恐怖、最吓人或是最悲剧的伪善，就是那个无人敢碰的真相——人类不爱生命

可以让人削减用力过猛及其焦虑的：

拥有天赋不代表一定要利用它做什么，不要仅仅因为你有才华，而认为必须利用才华做出些什么

还有让人有世俗会心一笑的：

别人都写烂书，我为什么不写写

但私以为最能和当下人的工作生活产生碰撞回音的，是书中几处关于文学阅读及艺术投入的描述。

阅读不是必要的

这些年虽然很多人批判当代人不读书了，但就自己具有显著偏差的观察样本而言，有阅读习惯的人其实一直在阅读，只是投入时间精力的多与少、阅读的主题与介质会与自己的生活状态强相关罢了。

我很认同卡尔维诺所言的：

世界上存在着只有文学才能以其特殊的手段给予我们的感受

但我确实也愈发觉得其实对大多数非文学翻译编辑出版从业者的读者而言，文学阅读（尤其是小说阅读）的作用分为两类：

💡

1）获得一种情绪体验，延展为培养审美趣味； 2）附和所谓的经典或阳春白雪，描绘理想自我状态的「人格面具」。

所以当看到冯内古特在采访中谈到：

小说向来都是一种精英艺术，这是为少数人存在的艺术形式

内心一顿惊叹：

由一个靠写作谋生的人直言这是「为少数人存在」实在太难得了！（尤其是结合当下把书籍当商业产品做的现实后）

但可惜的是，冯内古特加上了优越限定词「精英艺术」，还补充了理由：

因为只有为数不多的人擅长阅读

说可惜，是因为正如张楚所唱的：

蚂蚁蚂蚁蚂蚁蚂蚁蚂蚁没问题

大多数人不适合看小说的原因不是配不上阳春白雪，而是「没有必要」。

用之前在少数派上看到的一个观点及其论据可以很好地解释：

读书是一件「应该去做」但「没有必要」人人去做的事情。没有必要的原因很简单： 1）每个人的时间有限，只能去做最重要的事。如果读书尚且不能让你生存下来还会大量占用你的时间，那么把时间花费在「求生存」上更为合理。 2）读书并非是获取知识的唯一渠道。我们所处的时代叫「数字时代」，能够获取知识的渠道并非只有文字，还有演讲、播客、视频等等。每种知识一定有它最适合的获取方式，读书也只是这些方式之一，大多数情况下并不是最适合的那种。 3）读书并非获得最佳情绪体验的唯一渠道。在小说阅读过程中，读者的情绪体验会非常明显，作者创作本身的部分目的也是如此。但在这个时代，「快餐文化」往往给人更大的冲击，让人获得情绪体验的方式也变得多元，「快节奏」的生活方式给人带来了快节奏的情绪体验。

就我个人而言，鉴于自己还没有游走于世界上最顶尖公司的生存能力，工作中还会出现眼高手低、insight不足、没有first-class作品等问题，我把2022年的阅读主题从2021年的文学类切换成了能够告诉我「how to do things right」的工作相关书籍，以求生存。当我把书架上那些历史留名、装帧精美但却又来不及看的文学艺术类书籍一本本收起来卖掉时，感觉自己的青春已死。

但是，这种「牺牲文学、换取现实」是值得的吗？

但牺牲阅读是不值得的

一开始，当我从我想读的「正经类书籍」中看到那些我想快速习得的经验法则时，暗自窃喜自己及时调整了车头。可当我试图将这些武功秘籍应用于实践时，却发现那些经抽象总结后的「DO」和「DON’T」原则在不同的问题背景下其实边界非常模糊。那些被批判的、被摈弃的，其实可以作为当下最高效的临时解决方案；那些被视作理想的处理方式、不重不漏的思维方法，其实在当下的资源限制下不太具备可行性。

经验的归纳者能在自己的示例中证明他们自己是对的，但其却无法证明所摈弃的方式在别的应用场景下是错的。正如Dr.House所道破的：

Just because he was right doesn't mean he was wrong

日常工作由无数的细节堆叠而成，业务成败受无数的变量影响，通过归纳法知晓的经验并不能直接通过演绎法来指导实践：

即使有一种成长的方法可以让你在三个月之内成长非常多，也是不可能的，只有经过足够多的实战案例的训练，才能让你成长得最快。每个人都会有自己解决问题的办法，没有永远正确的教条。一定是你自己理解到的，才是你自己的。

所以啊，工作类的书籍，别因为作者那令人羡慕的闪亮背景就将其奉为金科玉律。遇上好的，就得慢慢熬着看，通过实践不断去修正自己的理解。

牺牲掉文学阅读时间，试图去换取工作现实经验的醍醐灌顶，是行不通的。因为后者需要大量的时间投入去感受、去修正、去内化、去实践，大多数人仅凭文学阅读的那点时间精力，是远远不够的。这个时间要从其他被浪费掉的时间中去挤。

阅读不是killing time

那为什么花在文学阅读上的时间，又不算作被浪费掉的时间呢？为什么这个时间不应该被挤压呢？

冯内古特在访谈中对此类问题的回答是：

人们为了不寂寞会做任何事——就像窒息的人会拼命挣脱这种状态。这就是大型的美国通病，很容易被冷血者利用的疾病：寂寞，难以忍受的寂寞。如果这些人能感受到的寂寞不单单可以被宗教治愈，还可以被艺术、音乐、舞蹈、自由思想治愈的话，就是另一回事了。你从事艺术，是为了让灵魂生长，而不是以此谋生，让自己获得名声和财富。这是一种蜕变的过程，是长大成人的一种必需品，就像食物、体育锻炼一样。你从中发现了自我。有很多值得去做的事情是赚不了钱的。它们是让生活更愉快的愉快方式。赞美或是失败什么的，只是噪声。重要的是做的过程，蜕变的过程。剩下的真的无所谓。

💡

从事文学阅读、或者其他一种自己爱好的艺术，是让生活得以熬得过去的一种方式。其中的过程体验，是内啡肽、多巴胺、血清素、乙酰胆碱的集合，不仅有短时间的爽感和愉悦感，还有长期稳定的满足和归属感，而后者是短平快的「快餐文化」情绪体验所无法带来的。

这是不能牺牲文学阅读的原因。

💡

但对于非文学行业从业者而言，如果其所从事的工作不是可有可无的毫无意义的工作，那能让自己联结更多个体、堆高自己的人生高度的，更多地还是自己事业中的创造，是把时间线拉长到10年为单位、去坚决而又冷酷地执行后的幸福感，以及对世界施以影响的成就感。

这是不能主次不分、本末倒置的原因。

至于我。

我还是会在每年的待读书单中为纯文学作品预留几个席位，只是不会再那么紧迫地想尽快体验完这些人类瑰宝了。