01｜围绕不可言说知识构造知识过程

工作场景：服务端提供一个「短信登录」的接口 显式知识：输入手机号码 -> 发送短信验证码 -> 输入短信验证码 -> 登录 不可言说知识： 1. 是否要支持国外手机号码？如果支持，支持哪些国家？怎么发送国外短信？ 2. 手机号码输入框的格式校验是什么？如果格式不正确，怎么处理？ 3. 短信验证码有效期是多久？如果超过有效期，怎么处理？ 4. 短信验证码格式是什么？纯数字？4位、6位？ 5. 发送短信需要按第三方要求填写短信模板，短信模板更新需要第三方审核通过后才能使用。 6. 短信发送频率限制是多久？如果超过频率限制，怎么处理？ 传递方式： 1. 运营部门分确定只发送国内短信「1」 2. 用户、运营部门、测试部门发现问题后，通知开发部门解决方案「2、3、4、5」 3. 遭遇黑客攻击，一夜间短信服务花费了 3W+ 费用，随后短信服务因欠费无法使用。紧接着所有开发与测试都被电话唤醒，紧急排查 Bug。最后大家记住了这次教训「6」

看评论区发现，原来这是一门哲学课😄

说实话，我也不知道隐形知识和不可言说知识的有没有理解对。按照老师的说法，隐形知识只要记录下来，就可以转换为显性知识，而不可言说的知识是一种经验和最佳实践，只能通过训练方法加以传递。 如果不可言说的知识和隐形知识最大的区别在于能否被记录，那么所有你能写下来的，都不是不可言说的知识，很有可能是是对复杂场景的简化甚至谬误，而产生的一种简化规则，就像编程规范，其中有一个是不要对方法参数在方法体内进行赋值，类似如下代码。 ``` int doSomething(String arg) { arg = "abc"; ... } ``` 其实我过去一直不理解为什么又这个规范，因为有的时候我们可能会对入参进行判空，判空后可能会赋一个默认值。这时这条规范就很麻烦，难道我又要重新定义一个变量吗？后来我才理解到，有些人会搞混形参和实参，分不清方法内赋值后，在调用时会有什么影响，索性就定这么一个规范。 但这就是合理的吗？文字是知识的尸体，知识的背后包含大量的上下文信息，一旦脱离这个背景条件，所谓的”显性知识“很有可能是谬误。

不可言说知识从经验的角度，偏向实践行动 有一种纸上得来终觉浅，绝知此事要躬行的味道 他人获取这种知识，无非是作者分享这种经验(通过书，课程等)不同的方式。而我们通过训练不断深入这种经验。 另一种部落知识则有一种行业领域黑话的赶脚。 那从软件开发到交付来理解文中的不可言说知识， 我理解是每个人理解层次不同，传递这种知识，每个角色是否理解清楚功能的产出物，这里的不可言说是说每个角色理解的差异(经验)，是这么回事吗

突然想到之前听一个读书分享会上说 人在挑书，书也在挑人。一个人和一本书有缘。对那个人来说书就是一本好书。事实情况就是如此，人有所经历才突然看懂了书的某些话。也是不可言说的知识在起作用。

不可言说的知识想想看应该可以替换成：能力，不是知识本身。

图片生成得好好啊

AI时代软件工程变成了知识工程这个提法真是精辟，照这么说，感觉领域驱动设计之类的技术可能还是会继续有用的？

课程有点水，而且 看评论有点托的感觉，估计这个评论也不会出现在评论区，没有意思的水课

作为中医爱好者，谈一点脉象这个不可言说知识。 关于脉诊的著作《濒湖脉学》分为两大部分，论述了浮、沉、迟、数、滑、涩、虚、实、长、短、洪、微、紧、缓、芤、弦、革、牢、濡、弱、散、细、伏、动、促、结、代，共27种脉象。 这些不同的脉象，如果没有师傅手把手指导，很难理解和体会这些脉象的含义。