aoe置顶2024-03-11 来自浙江工作场景：服务端提供一个「短信登录」的接口 显式知识：输入手机号码 -> 发送短信验证码 -> 输入短信验证码 -> 登录 不可言说知识： 1. 是否要支持国外手机号码？如果支持，支持哪些国家？怎么发送国外短信？ 2. 手机号码输入框的格式校验是什么？如果格式不正确，怎么处理？ 3. 短信验证码有效期是多久？如果超过有效期，怎么处理？ 4. 短信验证码格式是什么？纯数字？4位、6位？ 5. 发送短信需要按第三方要求填写短信模板，短信模板更新需要第三方审核通过后才能使用。 6. 短信发送频率限制是多久？如果超过频率限制，怎么处理？ 传递方式： 1. 运营部门分确定只发送国内短信「1」 2. 用户、运营部门、测试部门发现问题后，通知开发部门解决方案「2、3、4、5」 3. 遭遇黑客攻击，一夜间短信服务花费了 3W+ 费用，随后短信服务因欠费无法使用。紧接着所有开发与测试都被电话唤醒，紧急排查 Bug。最后大家记住了这次教训「6」共 2 条评论3
🐑2024-03-11 来自广东图片生成得好好啊编辑回复: 一个叫“锦书”的AI艺术字生成工具（可在线），有兴趣可以去试试～
1
新的一页
2024-03-12 来自广东另举一个例子，一般人都经历过失眠。 显示知识：解决失眠的办法是忘掉自己在失眠，空掉自己，自然就会睡着。 不可言说知识：忘掉自己在失眠，空掉自己，自然就会睡着。 传递方式： 失眠的时候脑袋里一直在想。 我还没睡着，不要想失眠，就会睡着。 我还没睡着，不要想失眠，就会睡着。 我还没睡着，不要想失眠，就会睡着。 几个小时过去了。 天亮了，我昨晚失眠了一晚上。只要失眠就痛苦面具一直带。 直到有一天，明白了，空掉自己，是空掉自己的念头，是空掉“空掉自己的念头”，自然就会睡着。- 新的一页2024-03-12 来自广东场景：多个人编辑相同业务时，合并代码，不按照时间线来，合并出现异常后，选择在生产分支修改代码，从而导致代码后续每次合并这个文件的时候及其容易出问题。由于时间原因，后续接手的人也不敢优化这个文件，业务也不支持优化，导致每次修改到这块业务，都要痛苦一次。 不可言说的知识：版本管理要规范化。 传递方式：痛苦面具。
公元前2024-03-12 来自北京个人感觉“设计模式、架构原则”属于不可言说知识。比如，我们很容易了解到各种设计模式的概念，但想要掌握只能通过在解决实际问题时思考，或者思考别人使用该设计模式时的考量。
娇娇2024-03-12 来自北京1. 代码风格：日常CR 2. 问题定位于排查：预案演练
术子米德2024-03-12 来自浙江🤔☕️🤔☕️🤔 【R】工作中的知识 = 显式知识（Explicit Knowledge）<know-what>+ 不可言说知识（Tacit Knowledge）<know-how>。 不可言说知识 > 隐形知识，后者能说而没说，前者想说也难说。 社会化活动（Socialization）是传递不可言说知识的不二法门 = 启动~反馈循环（kickoff-feedback cycle）。 【.I.】显=外挂，隐=内住。我们把能表达的部分知识，记录到各种媒介进行传播，实际上就是把经验做成外挂，传递给需要的人。对于遇到问题的我而言，都需要内住在我身体的知识，理解并运用这些知识，才能解决当下的问题，无论这些内住的知识，学习自外挂，还是自学于实践。如果手头现有的知识，无法解决遇到的问题，折腾出新的方法来解决，所谓的创造性就在此处，而由此创新同时会创造出新的知识，这些新知识首先具备内住的隐性，首先是我自己的经验，甚至是有意无意的肌肉性经验；其次我把它们总结分享出来，才可能变成外挂的显性知识，但也不得不承认，我不一定能表达的如此准确和完整，毕竟语言可能无法精确表达我的肌肉记忆。 【Q】悟性，是在表达不可言说知识的学习率嘛？ — by 术子米德@2024年3月12日展开共 1 条评论
木头人2024-03-11 来自浙江突然想到之前听一个读书分享会上说 人在挑书，书也在挑人。一个人和一本书有缘。对那个人来说书就是一本好书。事实情况就是如此，人有所经历才突然看懂了书的某些话。也是不可言说的知识在起作用。- 木头人2024-03-11 来自浙江不可言说的知识想想看应该可以替换成：能力，不是知识本身。
临风2024-03-11 来自广东说实话，我也不知道隐形知识和不可言说知识的有没有理解对。按照老师的说法，隐形知识只要记录下来，就可以转换为显性知识，而不可言说的知识是一种经验和最佳实践，只能通过训练方法加以传递。 如果不可言说的知识和隐形知识最大的区别在于能否被记录，那么所有你能写下来的，都不是不可言说的知识，很有可能是是对复杂场景的简化甚至谬误，而产生的一种简化规则，就像编程规范，其中有一个是不要对方法参数在方法体内进行赋值，类似如下代码。 ``` int doSomething(String arg) { arg = "abc"; ... } ``` 其实我过去一直不理解为什么又这个规范，因为有的时候我们可能会对入参进行判空，判空后可能会赋一个默认值。这时这条规范就很麻烦，难道我又要重新定义一个变量吗？后来我才理解到，有些人会搞混形参和实参，分不清方法内赋值后，在调用时会有什么影响，索性就定这么一个规范。 但这就是合理的吗？文字是知识的尸体，知识的背后包含大量的上下文信息，一旦脱离这个背景条件，所谓的”显性知识“很有可能是谬误。