This site runs best with JavaScript enabled.

💬 闲着说

没那么多精力天天写文章，需要有一个地方想啥说啥，像是自己的微博~

💬

💬 闲着说

人生海海，山山而川，不过尔尔。有努力和收获，有意外和突如其来，有幸运和快乐。专注自己对工作的忙碌，保持自己对生活的热情。明白了人生的起起伏伏，懂得了跌倒也要爬起，最后仍然折腾！发疯！热血！勇往直前！

💡 概念和产品的鸿沟

2025-11-29 19:13:00
“概念”也并不是天马行空，也能落到地上，只是概念更多表达是一种“可以用这个东西做什么事”，在成为真正“产品”之前，还需要真的有人去用，真的成为很多人工作生活的一部分。
“我的某个 idea 很好，是一个什么什么概念”。我并不是在吐槽各种天马行空，而是在强调概念并不是一切，还需要额外的落地、细节验证、迭代改进等等不确定的东西，才能成为产品。

🎯 把过程当作了目的

2025-11-15 12:13:00
需求拆分的时候，用户目标可能变成了偏离的任务目标。从诉求的起点，拆解成任务的终点过程中。可能损失了很多有效信息，导致任务完成之后，并不能解决诉求。
接到用户的反馈或建议之后，我们自然的想等价于一个可以度量衡的标准需求，可以直白的告诉每个项目成员要做什么的需求任务。理想情况下，每个人完成任务之后，这个反馈或建议就能够被解决，但是很多情况下，都是事与愿违，变成了开发组的自说自话，也就是在需求拆解的过程中，把过程当作了目的。

🥗 生活技巧常年践行

2025-11-10 12:43:00
  1. 做点脏活累活：愿意做一些简单却繁复的脏活累活，能更好的推进各种事（比如生活中的刷碗、和工作中的各种衔接）。
  2. 积极反馈：把不想动，换成我还没累到不想动。
  3. 传播幸福：更愿意去传播美好，同时放下对细节和不公的执念。
你做这些可以减少80%的争吵。如果你觉得不公平，那么可以用这80%的争吵来换？我觉得为了减少争吵，这些值得去践行。

🥪 有用 !=== 有价值

2025-10-20 12:43:00
产品开发的过程中，涉及到很多功能点的设计，有些是产品规划的版本里程碑、有些是用户需求驱动、有些是领导想法驱动，大部分在需求评审立项的时候，都要各种需求分析、成本预估，之后再是预研、排期，稍大的项目更是要跨部门协作。
在各种眼花缭乱的需求评审的时候，吵架频繁到“累了”“算了”的时候很容易会忘了一件事，那就是要做的这个东西好像有用，但是有价值吗？
协作环节上的每个做没用功能的傻子早都被开了，所以决定要做的产品功能都是“有用的”，但是有没有价值这个就值得说道说道了，因为从后续数据来看，并不是每个“有用的”功能，都是“有价值的”。大把的时间浪费在了好像有用，但是花了人效后没任何可见的业务增长。
解决方法呢，就是理性分析（不自以为是）+beta验证（不眼高手低）。

🐴 AI 时代的敏捷开发

2025-10-12 12:36:10
产品越来越复杂，核心MVP功能跑了出来，基础功能稳固无需大规模的开发量，业务关注点逐步从功能细节到业务方向转变，大部分的开发工作从核心转移到边缘补充、到体验提升，主力开发也大部分开始尝试新业务，敏捷开发的逐步放缓。
AI时代没有标准清晰的产品路线，严格产品规划和稳定开发流程意味着守旧和落后。这个时代基础架构、云原生都是太成熟的东西了，产品关注点更强调的是快速验证和试错。
手段：
  1. 完成远大于完美：
    1. 产品只提供给核心用户，不需要千万级别的系统架构涉及
    2. 云原生，架构的事情让专业的人做，用适当的【预算】换产品验证的【时间】。
  2. 渐进式开发：
    1. 小团队密集开发：不划分大功能，拆解为产品+开发的小团队，AI 提效。
    2. 面向实验版发布：beta版本推进，提前在开发阶段收集产品反馈数据。
    3. 不追求集体共识：不表决功能，产品负责制，快速决策+快速验证。
  3. 追求人效：
    1. 每个人都要快速行动起来，AI 辅助，超级个体。
    2. 沟通流动起来，多人协作，沟通机制。
基于这些敏捷开发，产品的推进速度能快很多倍，意味着用更少的机会成本更高效的追求时代的机遇。

👨‍💻 招实习生的一点想法

2025-9-30 11:53:30
又是一年开学时，很多大三、大四的实习生涌入市场，也是我们历年来招人的大头，因为北京高校众多，海淀更是遍地都是，优秀的实习生真的很棒很好招收得到，虽然我们的竞争力很低，导致最终留下来的不多，但是从成本和产出的角度来说，能够招一些实习生感觉很棒。
  1. 实习生虽然良莠不齐，但是学习能力很强，在花费一点时间培训后比很多社招人员要好用的多。虽然代码质量或者经验上确实有短板，这些也都是培训重点。
  2. 培训的过程，也是情绪或者节奏上对老人的一种工作调节。我们的工作强度不高，每天花费时间给实习生培训，对很多老人来说是个有趣的事情，毕竟大部分都好为人师。涉及到的一些经验的事情，更能让一些老人有种技术满足感。
  3. 很多实习生在学校并没有学到那么多成体系的东西，所以在协作过程中，哪怕开会听一听都会有很多收获，所以强烈建议学生鼓起勇气尽早走出校园。不一定要去大厂，我们这种小公司也有很多，工作时间安排也更灵活好沟通。
也分享一下招人的标准：
  1. 好学校的确会更卷，学生能力明显更强，所以院校档次初筛真的很大影响。
  2. Demo 可以比院校档次更有用，所以简历里面一定要show出来你做过什么。
  3. 性格很重要，保持沟通是一个团队协作的最最基本能力，所以不卑不亢的与人沟通也是我们筛选的重要参考。
  4. 用人单位招到一个人的成本比你想象的要高，公司人力给个HC很不容易、招聘网站每次约人要钱、约工程师准备、约会议室占用时间成本、沟通时间安排和任务排期也很复杂，所以认真对待每次面试时最基本的礼貌，有啥说啥不浪费彼此时间，不卑不亢真的需要再次强调下。

📑 会议提效

2024-11-16 12:33:36
平时的会议时间占据工作时间比例太长，所以一直觉得是个需要提效的地方。
  1. 会议事项增加会前准备会后整理流程，事项清单和人员清单，纪要和待办；
  2. 开小会解决问题，开大会同步；
  3. 云文档代替PPT，尽量不用纯 markdown，方便插入结构图或原型图；

✅ 更直观的解决问题

2024-10-05 14:40:39
有些时候开发调研或者解决一个东西的时候，甚至大部分的生活琐事，混混沌沌的不好理解，大部分可以理解为没办法比较，不够直观。这个时候你需要一个核心可视化的东西帮你直观的解决这个问题。比如：
流程问题： 1. 假期安排（每日行程、注意事项、预定餐厅酒店、备用方案等制成两页纸） 2. 发版事项清单（每次发版相关的一套流程沉淀成一个表格） 3. 排期关键点管理等（维护一个进度图，把节点对齐） 4. 红白事流程（老家的结婚流程、喜酒流程，用心留意几个身边人的经验，就能总结出来）
主题相关的琐事： 4. 离家检查单（断水断电的阀门和门窗，要带的衣物和生活品，车子检查等事项） 5. 汽车相关（车子的保养维护表、关键参数、保险节点等等事项） 6. 孩子相关（孩子的证件、附近儿童医院和停车情况、疫苗和体检时间表等） 7. 家庭相关（家庭的水电气网、车贷房贷信息、物业和取暖信息、社区相关等） 8. 亲戚相关（总有那么一群老家的亲戚邻居你喊不出名字，可以分主题整理，甚至配上照片，能让i人的你不再为与人寒暄还要鼓足勇气了）
带有权重的表格比较法： 9. 买车表格（搜罗全部意向车型，把关心的数据量化到表格列中，量化评分排序） 10. 客户表格（意向客户的数据，把消费意愿用权重算出来排序） 11. 选型表格（找的源头工厂、调研的技术栈，用同样的方法量化梳理，评分排序）
你会发现散落在脑子里的繁杂事项，能在一个文档里面被梳理整齐，让你解决问题的方向更加直观。

🤖 AI Mentor

2024-07-13 09:07:44
正常新实习生进场之后会有一个落地流程，之前团队管理的时候说过。之前会给每个人配一个 Mentor，帮助解决基本业务问题，基本工作流程。现在我们把AI环节作为了一个必选项辅助解决编程问题，无论是 ChatGPT还是国内的大模型都可以，出现非业务问题第一寻求对象改成了AI，然后培训流程里面增加了如何提问、Promote的一些东西。
后续会搭一个通用的大模型代理，把优秀模型的使用成本和基础Promote固定下来。这应该会很好的提升提问、简单问题的处理效率。

🚗 相同的话，不同的效果

2024-06-23 21:07:44
不能随便用，可能有风险 排除风险的情况下可以用

🍞 很在乎的用户体验，并不是很重要

2024-06-12 18:07:44
很多产品都是刚发布就很好用，但是越来越难用，为什么呢？难道那些开发者和产品都是傻的吗？哪个好用自己不知道？用户体验不知道最重要吗？随便找两个用户一问就知道用户需要什么啊？？？
作为在产品决策层参与过很多讨论的人，只能说用户体验很重要，但是有些事情比用户体验更重要。
  1. 阶段不同：产品初期一般是验证需求，把基本需求做到极致，吸引更多的人来用能够验证产品，后期完成了需求验证，那么紧接着就有商业需求介入了。
  2. 商业价值：很多产品可以为高级会员做更好用的功能，这是正向的逻辑。但是实话说大部分的用户不接受会员机制，但仍然发出很大的声量要求极致的用户体验。这笔账产品和老板都是会算的，极致的用户体验但是不挣钱意义不大。
  3. 成本和效益：一大堆开发并不是坐在那里随便两分钟就把你这些需求做出来的，每个需求都是需要被评估、排期、开发最后上线。每个人每个小时工作量都是有成本的，所以都被安排了效益最大化的工作上了。
  4. 政策和法规：比如论坛、群聊、可以定义的头像简介等功能，每年政策要求公司必须额外付出更多成本，所以有一些功能技术不复杂但是有隐形成本。
  5. 甲之砒霜，乙之蜜糖：一个产品的用户并不只有一类人，对你不好用的功能，对于另一个人恰到好处，没有满足你，这种情况下只是你没有另一群人价值高。

📒 Markdown 并不是一个好的文档格式

2024-06-02 12:07:44
很多人包括我，都对md有一种情有独钟的偏好，纯文本的一中文字格式化方案，在各种项目中不可或缺，存储和管理都十分方便。
但是md是一个很有限的文字格式，平时的文档需求很多事没办法实现的。
  1. 排版能力差：没办法做稍微复杂些的排版
  2. 依赖外部：渲染、归档、查询等
  3. 资源文件分离存储：图片视频需要额外心智管理，引用方法不统一
  4. 兼容性与通用性：最基础的MD能力优先，扩展语法可能又不通用
结论是：做技术说明类够用，但是千万不能作为知识库。如果你要搭建团队知识库，markdown 是个很不值得推荐的东西。好在 markdown 是个纯文本格式，做迁移还来得及。

🧠 工作中有些思维差异

2024-05-25 12:07:44
Q: 你这个代码会崩溃？！ A: 我看下...哦，返回数据必须是4的整数倍，否则没办法解析。 Q: 然后呢？改呀 A: 什么然后？原因是数据和我的代码有冲突，数据的问题 Q: 数据要固定条数？ A: 就是数据读取的时候循环取值下标越界了。 Q: =.= 要么你现在改了，然后提代码测试上线。要么你拉个会议找对接人规定数据文档。
我要的不是你解释怎么会崩溃，而是解决方案。确定好的数据文档没有告诉你的异常错误，都是你要处理的 CornerCase。你需要上游配合你的逻辑，都是应该你主动发起的对齐。

🛬 精心设计，但是落地要简单

2024-05-22 12:07:44
设计和实现各种类型的功能，是产品和研发的家常便饭，每天每周每月可能开会过各种各样的需求和实现。见得多了，做的多了，到现在的阶段，好像突然意识到很多不同的东西。
  • 你作为产品、运营、开发、Boss，都并不是真是的用户，所以对产品的观感大有不同。
  • 你需求调研的用户画像，并不是一成不变的，你永远不知道用户是有多么复杂多样。
  • 真实的需求路径不是你精心设计安排的那样，是很复杂多变的。
  • 你按照自己逻辑推断的功能，能不能行，不是单单这个功能做没做好决定的。
  • 有些时候是拿着产品和功能去找需求。
  • 有时候随手做的看不上的东西数据挺好，但是精心做的东西就是拉跨跑不起来。
体验这个东西，不是你找个人写篇优化策略文档照着改就行，需要你做的时候就要花时间和精力去扣，需要你根据用户需求和实际使用不断完善。

🌭 不空想，不眼高手低，不自以为是

2024-05-16 18:07:44
一个人靠不靠谱需要很长一段时间才能看出来，但是能不能担起事负起责能从一些性格或者风格看出来。
  • 敢为人先：不是在那等安排，而是从各个角度争取深度参与。
  • 敢表达，不怕尴尬：靠已有的经验能表达自己的意见，即使意见不成熟。
  • 记性好，成长快：不是靠性格来发表意见，靠逻辑和经验来参与。
  • 有逻辑的大局观：大的业务环节追求环环相扣，不拘泥于一个个的小细节。
  • 不空想，不眼高手低，不自以为是：对待任何需求都不会用空想，用想当然代替前期的调研。
这些特点，能让人信服，而不是靠着嗓门和否定别人来让自己显得正确。

🚦 以实际需求为出发点

2024-04-26 13:07:44
产品开发并不是做学框架、做Demo，都是有实际需求的，需要去被用、需要解决某个问题、需要支撑起业务。
工作时间的20~30%可以用来跨部门或者非业务性的开发，但是仍然需要落地，而不是徒有其表的假大空。
大厂因为组织架构严密，业务发展快，需要并且可以组织一部分人去做效率提升，去做工程化，做一些普适性的支持工作，其中有些可以被公开分享。你作为外人看，感觉大厂好像基本就是做这些事情的，于是心里想着追求实现，仿佛只要实现了这样一个东西，自己也是大厂级别的人了。想在自己的业务中实现一个大而全的组件库，想要实现一个通用脚手架，想要实现一个知识库，想要实现一个低代码平台。
能做吗？当然可以，但是请以实际需求为出发点，一个60+的组件库用不了，后台管理用成熟框架就行，通用脚手架没有维护和业务量支持用不了几次。

🏃‍♂️ 目标和对手

2024-04-13 15:07:44
追赶别人是轻松的，被追赶是最累的。当你的视野缺少对手的时候，往往会稍有松懈。
你知道自己想要成为什么样的人的时候，你会拼命追赶，当你有了对手的时候，你会拼命努力。但是当你觉得能解决遇到的全部问题的时候，你没有了目标，觉得可以分心做点别的事情。
并不是，比你努力的人还在奋斗，你只是没有看到，你只是忘了怎么追赶了。
继续加油！！！！

♻ 管理的核心是可量化的确定性

2024-04-06 10:13:25
作为产品负责人或者Boss，最想要的就是确定性，不惜每天会议拉齐。
  • 排期：你这个东西多久能做完，xxx前保证产品上线
  • 更关心结果：我要xxx，不管你怎么实现。
  • 可行性：我知道不可行，但是你要想办法让它可行。
  • 不确定的保证：虽然xxx不能确定，但是你要给我保证。
  • OKR：可以有明确的达成和汇报目标
所以互联网行业的管理层，一般都太好当了，不需要多么精明的管理技能，比如合理的任务排期和规划能力。只需要给量化目标，然后压榨就行，明天就要，一周完成，两周上线...做不到？加班！封闭开发！挂钩绩效，最后弄出来了，就唯结果论，“我的英明管理xxxxx”，实际上这并不是能力，这是无法持续的无能狂奔。
软件行业的开发能力，被编排成了粒度唯小时分钟计的生产工具，在各种高效的排期软件中流转，与绩效挂钩的OKR驱使你去无脑执行，再加上一套PUA技巧。上下游不关心你的思考，只需要关心能够被量化的各种数字。
外卖行业，骑手送餐、商家出餐都是不确定的，但是平台必须要一个可量化的“送餐时间”、“出餐时间”，所以能给出这种保证的商家和骑手，被量化成了包含确定性的优质资源，编排进一个大系统中。

🐸 产品运营就是养青蛙

2024-03-29 12:14:45
产品给人打标签，可以理解成给一群小青蛙分群组，标签就是一个个的井。在这个标签体系中，没有青蛙是全知全能的，都是井底之蛙，在每个井里面只关心这个井。
一个个的单独内容不重要，重要的是这个内容提供了什么标签，那么这个内容就是投喂到井底的饲料。让每个井的青蛙方便的找到这些饲料，和另一个青蛙快乐的讨论关于饲料的一切，迅速的达成欣欣向荣的共识。
偶尔让两个水火不容的井联动，一起抢食或者分食，发生碰撞和摩擦，产生可控的喧闹效果，之后再分开，让整个蛙群呱呱呱的热闹起来。

🤓 不要被事情推着走

2024-03-18 14:08:15
被事情推着走时一种理想的工作流。
不被事情推着走我认为是一种更好的状态。
不要被事情填满你的时间，要有足够弹性的时间，让自己去【真正的思考】。

🧘‍♀️ 安心坐下来思考的能力

2024-03-07 13:02:47
作为任何工作者，如果没办法有那么个两小时，安心的坐在那不跳跃不胡思乱想，无论是用脑袋空想、用文档输出、用纸笔画画、用键盘敲敲、或者重构了几次把一个需求捋明白了，那这压根没有任何思考能力。
你能够拿到一个需求，端坐着思考思考，有了自己的理解，有了自己的主观性的观点和结论，以你的经验来判断这个事情的周边延伸，那么你算作认真思考。

🎊 龙年大吉

2024-02-17 21:06:38
过年回家待了两周，感觉与工作的分离有点让人有点恍惚。从工作一个个的发版推进和需求讨论忙的不可开交，转变为了人情社会的世故。
今年春节收获颇多，近门亲戚也多认识了些，自己以前排斥的人情世故也想多接触了下，兼顾技术和管理的经验来看，感觉自己也整理了一方法。
  1. 心理上不要排斥任何事情：越做不好越不想做，越不想做越做不好，相反做好了的话就不会排斥了，不可能一直在自己的舒适区。别怕尴尬，别怕负反馈。
  2. 面对不想做的事情，一定更要做好功课，自己不去用心自然不会做好。
  3. 提前做功课的方法
  4. 目标对象：近门和亲戚
  5. 获取名单：找到你家最近的礼单
  6. 工具整理：用 Notion、Obsidian、语雀或者思维导图
  7. 整理方法：虽然你认识大部分人，但是仍然和父母一起从叔辈、爷辈，从父系到母系每个人都记下来，如果有头像最好，记录住的位置就更细了
  8. 最后你会得到一个比较齐全的文档，包含亲戚近门的名单和称呼，这个熟悉可以分享给你比较小的弟妹。
  9. 当面怎么说话
  10. 见面叫人递烟准没错
  11. 找共同语言：知道对方大学生就问大学生活，高中生问高中生活，生娃了问孩子，工作地问景点，行业熟悉问行业。长辈不用担心，他们自然会找些话题问你，不用特别找话。
  12. 记一些打哈哈的话：过年什么时候回来的？年后啥时候走？
  13. 酒桌文化
  14. 一定找熟悉的人坐一起，不至于吃饭过程中没话说
  15. 打圈：按顺序从左到右或从右到左，或者随便每个人都敬个酒，长辈站起来，酒杯低一些，平辈无所谓。
  16. 红包文化
  17. 抱着吃亏的心理发红包收红包，不然会难受
  18. 可以慢半拍，等别人给你家娃发红包，你再根据对应金额返给他家。
  19. 对方孩子更多，或者对方家娃比较大，或者其他情况都需要根据情况
这些都是自然而然接触多了就会知道的事情，二十多岁就应当明白的理论。但是常年在大城市办公室，这些东西一窍不通，还每年不得不面对，所以也只能这样了。

📈 人生不能太拧巴

2024-01-23 08:48:42
把时间花在提升不完美的自己，而不是期待完美的别人。人的价值在于自己而不是别人，挫折更能让你认清自己，认清世界。抛弃幻想，努力做事，表演人生。沉迷在完美的自己和世界里只会让自己被碾压。想去改变就去做，去解构世界和社会，去准备面对风雨，去试试挫折，去看看更美好的事情，去百折不挠，去越挫越勇，去屡败屡战，去拼。能有什么呢，大不了摔一跤，大不了不要了，大不了回家，应该都比阿 q 和鸵鸟要好。
三十而立，人生不理性才是对的，不对自己要求太拧巴。
“挣钱不纠结，健康不纠结，学习不纠结，开心不纠结。” 目前只有学习不纠结，其他要努力。

🎯 偶然还是必然

2024-01-02 13:39:19
团队管理中，方法论、流程、复盘，都是在把业务的成功进行总结归纳出一个成功模式，期望按照相同的模式能获得批量的成功。
实际层面远比理论复杂，因为世界是混沌的，不可能存在像是编程中的纯函数一样的东西，有太多的 effect 存在，很难对于一个复杂的事情归纳出通用的模式。
所以，有些你以为的方法和流程并不能都永远导向成功。一个是因为这些方法在之前的案例能够导向成功，但是有可能还因为平台的推荐、流量的倾斜、一次偶然的营销事件等等，成功因素缺一不可。所以大概率就算你做相同的事情，缺少一个因素导致无法复刻成功。
这是不是意味着方法论和流程不重要了呢？并不是。

🤖 Gen-AI Start

2023-12-21 17:00:17
把大模型当做你工作流程中的某一个成员或角色
自从 ChatGPT 横空出世之后，一致在使用，也经常思考这个东西能怎么辅助个人或团队的工作流程，之前也花了很多时间接触这些能力。
有创造性的人或者专业公司或者大厂，会创造出眼花缭乱的工具和玩法，Text/Image/Design to Image/Video/Code/App、AIPilot等等，这属于发掘新的业务领域。
有一些人或者专业公司，专注于 LLMOps，属于科技公司的套路，把周边工具做好，这属于旁路赛道。
另一个是考虑实实在在的落地的话，尤其是个人或者小团队，小公司，更多的可能也就是 WrapChatGpt，在工作流程中引入 ChatGpt 辅助工作，在此基础上降低生产成本，做的好的能够辅助打开新的机遇。
对于团队，也分享了很多方法论，关于大模型这类东西：
  1. 了解并学习 GPT 模型
  2. 原理和大概机制
  3. 能力边界：能做什么，不能做什么
  4. 事实性验证
  5. 了解并学习 promote 的理论和实践
  6. 怎么才能更好的获取自己想要的答案
  7. 通过最佳化你需要的答案范围和边界
  8. 总结出一套切实可行的 promote 规则，并持续应用改进
  9. 以前只能开发人员才能搭建的一些自动化流程，可以借助 GPT 来灵活又快速的满足需求了
实际工作：
  1. 集成到工作流中，把繁复的工作减轻甚至取代
  2. 多语言和本地化：通过预设上下文、背景和偏好，加上微调，可以大批量快速翻译，然后人工校对，实测比各种翻译机更好更稳定
  3. 单元测试：对关键的业务输出一个初步的测试逻辑，然后人工完善
  4. 简单任务：简单需求可以直接输出一个还算靠谱的逻辑，然后调整直至完成任务
  5. 进行项目调研和预研，将本来应该翻阅的大量的琐碎知识，用 AI 提前压缩
  6. 一些技术原理和概念，让实习生或者初学者交接更加方便
  7. 调研新技术的时候，让预研工作更好推进，以前调研一周的东西，现在一天能完成大概
  8. 啃一些论文或者理论的时候，你要翻阅查看，外文期刊更是困难，现在不在话下
  9. copilot 之类的辅助编程
上面提到的都是最基本的，每个人都能做到的事情，你如果想要拉开技能或者认知的差距，需要 Open Your Mind.

⛓ 什么是标准和流程

2023-12-11 12:21:40
在工程化中会涉及到很多工作梳理过程，比如最简单的开发到发版的整个过程梳理，梳理的结果就是流程。
但是流程不仅仅强调流程本身，而是流程固定和不断优化，还包括多流程交叉参与，最后更是让每个参与者都能明白上下游和工作推进方法。
在每个流程的节点，工作的发起、承接、交付，都需要一个点，这个点可以是个会议、可以是个提交、可以是个审批、可以是一句话。这些节点就是标准。
标准并不是简单的要求、测试或审批，而是固定下来的一个流程节点，通过这些节点把事情上下流转。比如需求评审标准：标准需求评审表、跟相关方进行预讨论、组织评审会议、输出评审结果（分工、排期、节点）、归档推进。
而标准和流程等于效率、稳定，不过标准和流程属于工具和方法，不是银弹，实际过程有非常多突发意外导致流程中断，需要灵活使用。

👌 不要试着一句话归纳问题或结论

2023-11-29 12:05:13
有这样一群人，无论什么问题或事件，从国家大事到邻里纠纷，从现实问题到思维层面，总能以一种看破本质的神情和语气用一句话给出貌似直击核心的一句话结论。
这是一种无敌的存在，无论这一句话结论多么荒唐和自我矛盾，能让你无论怎么辩驳也都能用一种特殊的逻辑闭环解释过去。
这种人连家长里短甚至都理不明白，怎么能做到无需调查和研究就能得出结论的呢？
结论：
  1. 不了解就尝试归纳和总结的结论，肯定是不靠谱的
  2. 除了理论的数理界有标准公理和答案，世界其他问题都有复杂的内在
  3. 所以不要试着一句话归纳问题或结论
  4. 本质上不要抱着任何问题都不放在眼里的态度做事
  5. 这和见过世面、身经百战、饱经世事都没关系，这是傲慢、显摆、想当然

🎇 AI-Promote

2023-10-21 19:10:17
LLM 用的多了之后，发现提示词的使用挺有趣，就像是教一个非常聪明的小孩完成任务一样，有些描述有用，有些描述没啥效果，其中还是有些技巧的。
因为训练语聊很多就是大量自然语言，所以不需要用类似搜索词、程序指令、关键词的提示词，直接拟人化即可
  1. “对学校的学生信息按照年级和成绩的属性进行排序，尽可能优化排序的算法性能”，比“学生信息排序 年级和成绩 快速排序”更好
让 ChatGPT 慢下来能获取更高质量的结果。让GPT输出目标和过程能显著增强推理能力。
  1. 多次对话法：第一次先完成任务，第二次优化结果，中间可以让GPT自己提出改进方向和注意事项。在翻译、代码输出等场景非常有用。
  2. 多遍输出法：让GPT直接输出两遍不同要求的结果，第一个结果后面增加自我检查和要求后再输出第二遍。
  3. 引导思考：“逐步思考”、“仔细考虑”、“慎重输出”
添加示例能更好的控制输出。
  1. 即使一个小示例也能让输出结果变得好，多给几个实例更好。
  2. 对于专有名词进行解释。
  3. 对有一定推理的例子使用推理词进行描述，能帮助思考。
使用限定词来控制输出范围和场景
  1. 需要、做、在xx的条件下
  2. 不确定背景和目标或者需要更多信息的情况下请确认或询问
  3. 请按照 json 格式输出结果列表

🤐 做建设者，不仅仅做批判者

2023-10-04 15:53:06
  1. 如果你负责一件事情，或者重视这件事情，那么就要充分参与，不要态度上重视，行动上什么都不管，至少关键节点和逻辑一定要对齐确认。
  2. 在你发现问题的时候，第一时间不是质疑和批判，而是调查和分析为什么，因为你不一定是对的。
  3. 提出批判的时候，考虑解决或改进方案。批判再激烈，对于事情和问题没有更好的帮助。
  4. 不要从感性上找确定感，没人能打包票有绝对正收益，你只能从理性上找最大概率。

🍔 思维定式

2023-10-02 11:45:15
每个人的人生经验，在面对一个事情的时候，思维方式是不同的。
在大城市或者公司待时间长的小白领，面对事情可能第一反应是事情本身，遇到问题解决问题，想不到那么多弯弯绕绕，想着任何事情都是流程问题。
但是在小县城待过的父母，深知各种潜在规则，在遇到事情的第一反应是背后有什么深意，遇到问题先揣摩对方的心理和想法，一句话都想要分析出说话人的想法，最后引申出这个人的性格和对自己的看法。累吗？累，但是人情往来比较多的地方过惯了这种小心翼翼的生活，这就是第一规则了。

🎢 门槛增熵

2023-09-26 11:45:15
  1. 以前饭馆随便开，现在你需要有资质，还需要有洗碗间、冷食间、生食间、饮料区、现包饺面点间、杀鱼间、粗加工间、热加工间。
  2. 以前网站App随便开发上线，现在你需要符合严格的个人信息保护法、信息安全技术个人信息安全规范、信息安全技术 互联网交互式服务安全保护要求 ga1277、具有舆论属性或社会动员能力的互联网信息服务安全评估规定等等，之后还需要交钱来请第三方评估做等保，最后需要网安备案、网站备案、App备案，这其中一旦任何一个环节卡住，整个产品的开发和运营就全部泡汤。
法律法规的发展当然是越来越完善，能够保证不会出现问题，但是这些标准和规定同时也是系统庞大繁杂的限制，所以导致在无序中发展起来的，都享受到了红利，然后后来的人就需要面对很高的行业门槛和成本，导致发展不起来了。

☢ 专有名词

2023-09-11 18:53:21
最近发现稍微跨一点专业或者脱离一个固有环境就有好多专有名词不懂
比如实习生对很多专有名词不懂，大公司来的同事很多缩写或者词语也是听着一脸懵。
CR 在领导那代表降本 Cost Reduce，在人事这代表平均薪酬比较率 Comparative Rate，我这明明是认为叫code review才对啊，微博上饭圈用来标明原创 create from
dao 去中心化组织，DAO(DataAccessObject)数据访问对象，
所以跨专业、跨行业、跨公司都可能会出现语言不通问题，必须要花点时间适应才行。

🔮 AI BaaS

2023-08-23 14:15:49
LLM 的 GPT 类在一段时间的发展之后，已经成为了一条赛道，无数的人想要在这个基础上搭建东西，这些东西究竟在做什么。
LLM（包括ChatGPT和其他的模型）说白了就是带有上下文历史记录的文字输入输出的黑盒。要想完成你的目标任务，需要设定背景、提示、格式化输入、设定输出格式和解析等等东西，在无数人尝试用来完成无数任务的过程中，这些东西就逐渐的被抽象并提炼出概念或者辅助工具，这个过程是就是 LLMOps。就像云一样，有些人把提供尽可能贴心强大的周边辅助作为能力甚至生意。
  1. 通用内核：现在的大模型基本上 API 算是大同小异，提供上下文、输入、输出，多点的提供一些预设的参数。
  2. 基本能力：接入大模型的API+Key、管理上下文、提供输入输出展示和格式化、存储使用Prompt等
  3. 知识库：提供一个基本的小型语料库，能够进行模型微调，对某些方向的内容更专业
  4. Prompt Engineering：微调、编排诸如提示词、上下文、参数来让大模型理解输入，输出预期的调试过程。
  5. 多模态输入：可以输入word、pdf、图片（OCR）、视频（字幕）等格式资源的能力
  6. Agent：额外信息获取渠道，比如实时搜索、网址查询、API查询等获取到额外的信息能力
  7. 上下文压缩：对于超大的上下文，进行压缩处理（舍弃不重要的词、转为同样含义更少内容的过程？）
以上的每个点都存在门槛，而 LLMOps 平台都是在解决这些问题。

💡 AI 启动和爆发

2023-02-21 17:00:17
自从 ChatGPT 横空出世之后，真的是 Mind Blowing 💥，第一时间就想办法注册试用了。
  1. 那些混沌的非标准数据，可以被一个程序理解后相对格式化输出。
  2. AI 可能不明白，但是他能给你还算靠谱的答案
  3. 不要用简单传统问答机器人来理解大模型这个东西，far beyond chatbot
这个节点能够让你的眼界跃层，抓住这个机会，别等待被时代抛弃。例：
  1. 辅助编程，提高效率。别人一周的工作了，你可以用 AI 辅助两天完成。
  2. 跨界。感兴趣的东西，以前需要花1个月准备，现在用 AI 快速调研、实现出成果。
  3. 阅读。以前一天一篇文章也费劲，现在让AI辅助翻译和总结。
  4. 梳理每个流程，让AI替代或者辅助流程中的环节。

💩 愿意干点脏活

2022-11-21 16:48:41
很多人愿意做那种很有价值的工作，包括我自己，比如实现一个非常优雅的方案，类似的事情会觉得真有意思，非常愿意花时间在这些事情上面。
但是工作嘛，并不是只有想做的事情，还有很多脏活在那。这个如果不是抱着这个目的来的，很难愿意在这些事情上花时间，“我又不是干这个的，为啥让我做？我就不！我发脾气~我不好好做”。
对于这种情况，我个人的理解是：愿意去偶尔干点脏活，这并不会让你损失什么，但是对于推进整个团队工作是大有裨益。
这是你个人的能力，从做好自己的事情，到解决大事情，再到负责大事情。不把自己禁锢在仅仅是某个大事情的一个环节。
比如在互联网公司里，测试、推广、内容方案整理等等，都是属于一些脏活累活，作为开发或者产品，基本上都是不愿意做这些事，找个实习生干的又快又漂亮。但是如果没有人手，或者紧急情况，我认为当下压低你的骄傲和埋怨，撸起袖子跳进泥浆里面，把这个事情解决掉才是第一要务。

🏃 如果你想进步

2022-10-11 16:38:22
  1. 把每天的事情都记录下来
  2. 定计划
  3. 自己的事情自己负责

🥲 保持专业

2022-09-18 10:58:53
你可以不热情、可以不喜欢、可以不开心，也不知道更不感兴趣你的工资水平，但是对于这份工作，一旦你在我工作的上下游，我只想请你保持专业。
  1. 一定要思考
  2. 一定要认真
  3. 一定要有产出
  4. 一定要保持开放
  5. 一定要会沟通
请你不要：
  1. 觉得只要按时交付就完事大吉
  2. 觉得花心思和不花心思差不多
  3. 觉得只干自己的活，其他人的问题和你都无关，不参与、不改动
  4. 觉得自己的观点、自己的习惯、自己的态度无法改变
  5. 觉得只要干好活，其他和自己无关
以完成产品和需求为目的：
  1. 你的专业并不包含个人情绪和习惯，可以有，但是不要太大。
  2. 你的工作并不只是你的环节，还包括协作他人一起完成任务。

😵 人能有多啰嗦

2022-09-12 23:41:46
想说的是，很多时候会很啰嗦，是因为害怕被否定、害怕抬杠、抓不住重点、没有统一的共识、没有分清场合。
1. 担心被否定和抬杠，为了逻辑完备，结果很啰嗦
做决定的人性格不同，有些追求程序正义和流程严谨，落到文字或者会议上的时候，需要你从头到尾、从背景到论证和假设，最后得出他想要的效果。
你一旦中间跳过了某个步骤，或者描述的不准确，就会被追问：
论述：中国人愿意拿隐私换便利。 追问：我就不愿意！任何隐私？能有多便利？ 啰嗦：一些中国人，会被APP设法骗到，用基本的身份信息，换取相关度较高的商品推荐。
被质疑的多了，或者经常遇到抬杠的讨论环境，就会很自然的在说话的时候添加上很多的限定词之类的，以求自己说话的准确性。
相反的在一个开放的讨论环境中，除非涉及到严重的逻辑漏洞，不要因为一个表述不准确而全盘否定别人的论述。会让别人很难表述，最终的结果就是不愿意表述。
2. 追求广泛受众的共识，结果很啰嗦
组会、调研报告、分享会等等与人面对面沟通时候，你面对的受众是很明确的，你明白这些人对你所叙述的东西的适用背景。
你一旦对错误的人使用了错误的语言，那就会被认为很啰嗦。
物理老师：现在讲新内容，一个木块被按压到斜坡的受力分析。 战五渣：哇！老师在讲什么？什么摩擦力？什么重力？什么力的分解？好有趣啊~ 课代表：老师也太啰嗦了！5分钟的东西讲了两节课了还讲，太啰嗦！
所以作为个人面对某个人的语言、面对组会的语言、面对拉齐会议的语言，都应该考虑从对应的共识部分开始讲起。你的结论推导过程也不是扩写，而应该是有针对的逻辑论述。
面对有共识的组内同事，你只需要用最专业的一句话描述。面对有产品的会议，简单说下实现过程。面对有市场和老板的会议，多用比喻和短句，又长又臭的专有名词解释可能并不是好的论述。

😲 面对不熟悉的大事，你会以什么心情去面对

2022-08-27 13:32:20
紧张？心慌？坦然？逃避？期待？
无论在什么情况下，都要主动准备迎接变化，逃避解决不了问题，问题都是解决的。

🍭 能力大不同

2022-08-14 17:11:50
产品方向、工程方向和开发方向都是每个人的不同选择。
解决问题的方案调研、审查和落地的能力也都是每个人能力的侧重点。
我的建议是均衡发展，不然可能会“偏科”，导致“技术挺好，就是体验不行。”、“产品化的不错，但是开发能力太差。”、“开发能力不错，但是效率太低。”。
最简单的一些路径：
  1. 产品方向：多了解下其他竞品、市面上的热点应用，了解功能 what and why，不至于闷头开发感动自己。
  2. 工程方向：通过工具、流程、甚至简单约定等方式来提升开发效率，提炼出可行的高效方案，不断地和协作人一起追求高效。
  3. 开发方向：就是实际的规划功能然后实现功能，广度上的思维和深度上的钻研。
  4. 方案的调研：问题的拆解、分析、调研、最后融合自己的想法提出解决的方案。
  5. 方案的审查：对于一个方案，能够快速大致了解背景、问题、方法、目的，最后心里有工作量、风险点、更好的想法之类的东西。
  6. 方案的落地：接到一个方案，能够拆解并配合别人协作实现。
如果开发能力强，就是开发专家。如果分析问题能力强，就是产品或者主程。工程能力强，那就架构师或主程。

✍️ 研发流程上的测试驱动

2022-07-22 23:19:04
很多时候分配任务之后验收环节，发现交付过来的功能与预期不符，还要反复拉扯。
原因可能有很多，因为文档不清晰、没有会议拉齐、理解错误等等。
可以考虑借鉴测试驱动开发的机制，在做文档的时候，将最后要实现的产品功能先声明完备。
这样的话，大家理解上的偏差就会提早对齐了，就算中间有理解偏差，结果至少能对得上。

🦩“问题”无解可能是“问题”的问题

2022-06-30 16:23:04
产品的分析中，会遇到“问题”，总是为了解决这些“问题”提出很多的解决方案，这是开发、产品、老板的日常。举个例子：
  • 当前现状：用户流水太小。
  • 提出问题：充值和消费体验不流畅。（找到了一个不是核心问题的问题）
  • 初步解决：大力气、高成本改进了一整套的充值消费体系，结果提升有限，得不偿失。
  • 本质问题：商业逻辑本身有问题。（分析的时候没有涉及到这块）
但是这种“问题”的解决方案并不总是很容易提出来的，因为“问题”有可能不是问题，只是一层表象，真正的“问题”没有被解决，甚至完全相反的恶化了“问题”。
所以哪里不对的时候，提出的这个问题看似有道理，也确实有关联，但可能并不是主要问题。你需要采集统计、实际调研、上手体验等等分析之后，可能才会看到问题本质。

🌟 灵感的来源

2022-6-21 11:53:11
  1. 保持热爱：因为喜欢，所以才能花时间琢磨，生活是有很多烦恼，但是除了烦恼之外一定要永远保持热爱。
  2. 多去摄入：多看看世界和其他人，那么多了不起的人都在做什么。
  3. 多去问问题：为什么这么做，因果和演绎的法则。
  4. 印象深刻：令人印象深刻的事情总是会打破你的思维惯性，所以让自己多去做一些自己觉得了不起的事情。

🪵认真的工作态度

2022-06-12 23:06:35
不会因为外界条件而省略什么事情，就是瞄着目标，按照逻辑步骤充分准备、充分讨论。
  1. 抱着说服别人的目的，那么就从共同的观点开始推断，使用事实和证据而不仅仅罗列观点。
  2. 讨论问题，可以有观点，但是不要预设立场，更不能无理由坚守立场。
  3. 哪怕一件事重复无数次，也不使用推断或者演绎来跳过什么。
  4. 头脑风暴，充分表达，尊重决定。

🍁 核心目标

2022-05-22 23:14:41
优雅的实现是程序员的强迫症，但是你的目标和存在意义不是为了写代码，而是解决问题实现需求。
如果追求一个优雅的实现、一个完美的方案让你浪费太多时间，得不偿失。
很多人（就是我）在自己实现项目的时候，或者调研开源代码，甚至写文章文档的时候，可能会太过于纠结于细枝末节。
很多时候是因为想要完美，或者觉得追求一个优雅的实现很重要，或者某个模块很有意思，不停地冒出很多有意思的想法，结果就一直深入了下去。最后忘了本来想干啥来着...
本质上还是没有条理，或者没有提前规划能力。
先规划要实现什么功能，要写什么大纲，要满足什么需求。无论什么时候，完成一个小目标的时候，回头看下整个项目进度，再决定把接下来的精力和时间花费在哪里。

🗨 有效输入的积累

2022-5-15 11:53:11
工作中遇到的事情，如何能很快给出多个解决方案，或者至少给出一个靠谱的建议，这是一个人能力的体现。
而这种反应很大程度上依赖的是你的知识模型，日积月累的知识训练的结果，让你能够针对每一个输入场景，输出一个分数不错的结果。
所以不同人的模型差异也就是他能力的参差，有人对遇到的任何事情都游刃有余，因为他经验丰富。有人对任何事情都没有概念，说明他没有深刻理解。
怎么提高自己的模型质量呢？要么用更好的模型，但是对于人来说没办法推倒重来，从一出生建立起来的学习机制，社会的环境等都让你对知识的提炼形成了路径依赖，很难改变。
所以提高自己能力的一个另一个方法就是增加有效输入的积累：多看、多听、多总结。
机器学习理论中，样本或者训练集量越大、多样性越多，训练出的效果就越好，而且需要做好数据标记才能提炼出更好的数据特征。对应于人：
  1. 主动去搜寻更加多样且量大的知识，想要强化的方面的重点养成阅读和思考的习惯；
  2. 做好数据标记，将知识的特征和重点标记留存，方便自己关联记忆；
  3. 最重要的是找到乐趣或者最起码的兴趣，不然的话以上都是很痛苦且不能坚持的。

👾 技术上的强迫症

2022-04-25 11:04:32
  1. 一定不要什么都亲力亲为：
    1. 不用每个产品、模块、依赖都自己实现一遍，你可以使用别人的东西，更可以借用开源社区的实现（当然不要忘了致谢环节）
    2. 你的目标是实现预期，只要能然你节省精力的东西，都可以拿来用。
  2. 一定不要什么都尽善尽美
    1. 代码是一个迭代的艺术，更是一种妥协的艺术。
    2. 你很难做到完美无 bug，尽力完成预期的80%，然后尽量迭代到90%，做到100%就足够好了。
    3. 不要把所有的精力和预算都花费到了某个细节上，除非这个细节关乎成败。
  3. 一定不要什么都无边无际
    1. 你的计划越大，那么你烂尾的概率也越大
    2. 做程序员之前，先把自己当做一个 PM 写好 Readme
    3. 你的计划一定要能够收敛，能明确做完而不是越做越多
  4. 一定不要什么都自高自大
    1. 你能够模仿几个界面，真的不代表你能做出好的样式和交互
    2. 你能够做出几个小应用，真的不代表你就是业内无敌
    3. 天外有天、人外有人，一定要保持学习，保持相关资讯的输入。
    4. 知道你的能力边界和整个社区在解决什么问题。
那几个 ABAC 的成语真的是凑巧想说的 😂

❓ 要有被质疑的承受力

2022-03-14 13:26:10
大部分人在面对陌生人、非权威的时候，是不愿意被否认的。
当确实存在问题的时候，也会用增加特殊情形：“当时我的意思是...”，“因为当时...”等补充，来让自己显得没有那么“错误”。
要有被质疑的承受力，当别人说你之前说的 xxx 不太多，要能说：“你是对的|当时我理解错了|当时我想错了|原来这样”。
而反过来面对别人的错误，不要去试图得意洋洋地吹嘘自己的正确优越感，让别人必须承认自己犯了“错误”才罢休，更重要的是事情本身，而不是你的虚荣心，陷入情绪怪圈。

🐺 工作执行风格

2022-02-19 19:08:10
有创造力
没有创造力
对有创造力和愿意创造的人，要求少（我告诉你我想要的，你知道怎么做）
对不愿创造、没有方向、理解不清晰的人，要求尽可能细致（我需要告诉你怎么做才能给我想要的）

🚼 年少不经事

2022-1-26 09:49:19
  1. 年少的时候以为世界上好人多；现在明白就是有人没来由的歧视、取笑、压榨你，对你的外观、言行、性格产生优越攀比感。
  2. 年少的时候以为只要你认真做事一定能做好；现在明白，真的很多事情不是你遵循规则、认真做事就能成功，很多 under the book 的规则是真的存在的。
  3. 年少的时候以为科技的发展是好事，造成失业也是能够接受的，机器人取代人类更是美好的向往。 现在发现科技是巨头的垄断，社会效率的极致追求很难顾得上那些无阶级者，无人工厂很美好，但是更意味着利润的集中，直到某一天机器只为有能力购买服务的人服务。 集市越来越卖不出去东西，小集镇逐渐消失，饭馆越来越少，被大公司管理的外卖员和快递员越来越多，效率更高了；卖电器的小老板越来越少，电器装配员越来越多；卖衣服的小店越来越少，网上倾家荡产也争不过巨头流量的店主越来越多。 但是感觉这样的社会进步并没有那么美好。 我知道社会会这么发展，也没有别的路，就是感觉有点悲伤。
  4. 年少的时候以为知之为知之。 现在发现很多大人们人微言轻，阴谋论、小道消息、谣言等，只要能让别人关注他，变成人群焦点，说的什么不重要，只需要显得自己比别人强，无论你是村里的穷苦人，还是城里的有钱人。对错不重要，有人听，有人捧是最重要的。对方一旦流露出比自己强的信号，马上不自主的吹起了牛，想要证明自己眼界更广，知道的更多。承认自己错了很难吗？对于“体面人”很难！承认别人比自己厉害很难吗？对于“体面人”接受不了！面子很重要吗？对于“体面人”很重要！！
  5. 年少的时候以为简单的道理，怎么有人不懂呢？长大后发现，道理的对错、观点的对立、言语的冲突是这个世界上混沌的基本，除非数学公式的推导，任何说的、写的都有不同的理解，就像是一个个大大小小的辩论会，不可能有大统一。

🌏 世界观是每个人的认知边界

2021-12-28 22:26:10
以前我觉得世界观是一个很深奥的词，我知道但是没有体会，因为当时的我以为我看到的一切就是世界的一切。
现在我知道一个人的正确可能是另一个人的错误。
一个面朝黄土农村的农民，看过再多的抖音视频也许还不理解为什么牛排不能八分熟； 一个西装革履海归的博士，知道再多的知识论文可能也不懂得为什么田间地头那么忙。
每次你想鄙夷、批评、无法理解一个人的时候，你应该知道你看到的世界和他不同，你从小到大接触的事情、你认为正确错误的决定、你生活中遇到的每一个人都和他不同。
别人的思维和认知，可能是你无法理解的事情，所以遇到任何事情不要以自己的认知来理解，大家都是不同认知的普通人。
所以你认为的唯一答案在别人看来可能并不是，争吵一个问题的时候从多个角度思考，而不是依靠着自己的视角决定一切，没有人是全知全能的。
你要看得多、听得多、学的多，不要那么多自以为是，不要让情绪和反应控制你的认知。

🚸 摆脱情绪漩涡，向前看

2021-12-15 22:16:10
别让改变不了的事情一次又一次的影响你的情绪，你应该关注的事情是可以做什么而不是深陷情绪中。
充满希望，努力奔跑。

💤 早睡早起

2021-12-08 08:36:10
【早睡早起】可能是老人们只是出于自身的生活，推荐给年轻人的经验。
为什么非要“早”呢？可能是因为休息节奏让年龄大的人起得早、睡得早，这个经验适合年轻人吗？
整个人没精神是症状，不是问题，问题是睡眠不足。
解决的方案不是早睡早起，而是保证睡眠，规律作息才对。

😷 症状不是问题

2021-12-06 19:36:10
出现了问题，解决问题是一个程序员的下意识反应。
  • 你最大的问题是太胖了。
  • 胖是症状，不是问题，只是结果。
  • 问题是：吃的太多、运动太少，工作没有忙到吃不上饭，压力也没有大到没胃口，社交圈也没有让我有减肥的驱动，久而久之就胖起来了。
  • 解决问题：让自己忙起来，别在舒适区待太久，让自己有点压力，别把注意力都放到吃什么上。

🔨 亲历亲为

2021-12-06 21:09:10
如果你对很多事情的评估决定是“亲历亲为”的去做才能更好。
  1. 潜意识上你认为交给别人不如自己做，因为别人不如自己做的好，自己不放心。
  2. 出发点可能是效率更高，在救火、在保进度、保质量。
  3. 长期来讲这样是不利于团队合作的，因为你本质上不信任别人。
  4. 从小到大的把事情交给别人，各司其职的安排分配工作，才能最大化效益，才能让自己不紧绷着。

🤔 反思的步骤

2021-12-04 19:52:10
觉得最近工作好像出现了问题，明明自己想要做好、很认真在做的事情，结果却很曲折不符合预期。想要反思下自己，却不知道怎么下手。
思考了一下，想到了一个诊断调试法。
  1. 让你想反思的最大驱动
  2. 反思的必要性（让自己面对而不是回避）
  3. 稍微细化下最大的那个问题（从情绪到现实）
  4. 如果给自己找个借口，问题和解释（平息情绪的影响）
  5. 这些问题为什么解决不了（抽离出问题和方案）
  6. 你可以做点什么解决这些问题
最终结论：
一定不要眼高手低，实现优雅方案是最简单的结果，过程要考虑细致充分才是困难的地方，测试驱动、充分测试、考虑周全，集中注意力只是你想做好，不代表你真的认真了。

🤬 推进项目

2021-11-22 13:02:10
如果你没有经验，也不是权威的话，讨论问题的时候一直重复肯定、一定、必须、只能、这就是核心问题、相信我、方法论、没用、都不用试、就这个就行，这些话只能让你显得很无能。遇到到一件事，在没有详细分析和深入思考的情形下，不要天马行空地发表意见，除非是头脑风暴的环节。
每个人的生活阅历，经历的事情，看问题的分析结论不同，所以对一件事的解决方案不同，对某些方案的能不能真的解决问题的判断更可能大相径庭，你如果靠着上面的态度来做参与讨论，或者来说服对方，那你对不熟悉的新问题的解决能力是值得怀疑的。
{/正确的做法是详细听完别人方案的说明，从出发点到解决方案的全流程，如果你不是负责人，请顺着别人的思路来思考，而不是拿着自己的一个思考来否定别人的整个方案，反例来证明自己的某一个论点。 /}

➡ 细节

2021-11-21 12:52:10
如果一个产品中，没什么特别的原因的情况下，用大于号 > 代替了右导航图标，我会觉得敲出这个大于号的人做产品非常不用心。

❓ 否定

2021-08-05 20:22:10
在经历了很多团队合作或者团队管理之后，尤其是重视讨论和意见的职场环境下，意识到一个小 tip:
不要轻易否定别人，除非你有建设性意见。
找出一个方案中的薄弱点、理想化的地方、有瑕疵的推断之类的观点很简单，你很容易从你的专业角度、权利位置否定这个点，从而否定整个方案。
但是你不能靠着否定别人来证明自己，反而会让别人也陷入互相否定的怪圈。
下意识的否定之前，先把信任，建设性的思路前置，会让整个协作更容易。（别人的否定如果确实存在第一时间承认并提出改进，我的思想如果不能确保正确也不坚决坚持，也因此在合作中讨论任何事情都更顺利。这不是没有自主，只是多人协作方案的推进法宝。）
这个问题的点可能是因为每个人都觉得自己的“视角”是【对】【正确】【核心】【关键】的，“想要证明自己对”和“不想被否定”的两个观念冲突。

💥 震惊和意外其实总是这么突如其来

2021-06-15 23:22:10
昨天搬家的时候，媳妇突然收到一条消息，说高中的班主任走了，布置中考考场的时候走的。
媳妇说，没有特别亲近，但是以前朝夕相处，现在经常在朋友圈和群里交流，高中的时候承蒙他不少照顾，听到这个消息的时候想怎么可能，前两天还在群里闲聊呢。媳妇整个一天都有点恍惚，闲下来就会不自觉地想这个事，今天联系到之前的老同学，准备无论怎么样都要回去看一眼、送一程。
可能这就是感觉在你毫无防备的时候，突如其来一个大事，哐当砸你身上。有人相信征兆，说前几天眼睛老是跳，总感觉有什么事。也有人说，就说前几天心神不宁的呢。总想为这么大的心理震惊找个什么铺垫，让自己更容易接受点。要我说，这样的震惊其实总是这么突如其来。

🐎 做一个塞翁

2021-01-21 17:19:20
塞翁失马，焉知非福
一件事情看起来可能不是好事情，但是换个角度来说可能并不值得你难过。
住的好好的房子，突然房东收回了
  • 感觉难过、寄人篱下、看人脸色、无家可归、被赶出去？
  • NoNoNooooo，要这么想：还好房东收回，蟑螂那么多，离公司那么远，室友也不太卫生，违约金到手换个干净屋子岂不快哉，一定要放首音乐 Happy 先。
努力工作还是被公司劝退
  • 感觉好难过啊，怎么会发生在我身上？我可怎么办啊？
  • NoNoNo，这么想：终于解脱了，终于离开了职场PUA，终于不用加班了，终于不用战战兢兢的讨好谁了，终于可以换个环境了，拿到补偿金，休完攒的假，可得好好放松放松~~

🌎 你的价值和经验体现在

2020-12-13 20:42:10
工作一段时间之后，工作的激情、项目实现的动力、技术的追求等都不同程度的到了一个阶段，很容易开始思考自己价值了，相比新人你独特的地方在哪里？
假设你在面试两个人，一个新人一个老手，怎么看出他们的差别呢？他们可能都会对组件库、工程化、各个技术栈侃侃而谈，但是稍微聊聊就能明显区分不同的思考路径了。
比如一个组件库的项目，新人会对实现的效果浓墨重彩，做了多少个组件，里面包含了很多的交互细节等，但是你如果问怎么解决样式继承、TS 提示怎么更灵活，他们无法说的太明白，甚至没有考虑到，因为他的经验里面涉及到的比较少。但是有经验的人会知道实现组件和交互都是线性工作量，只是时间和设计的问题。而协作、新增组件、升级组件等抽象部分才是工作量的大头，这部分会花更多时间，所以在设计的时候尤其要提前考虑，工程化思想、抽象粒度、组件拆分、多态的实现等上的思考才是价值所在。
所以新手和老手做同样的项目，价值的体现在于经验上讲通过实践沉淀出自己的思考，从而能在下次遇到这类问题的时候更容易解决。
类似的还有项目经历、工程化实践、仿制 App 等问题上，重点不在于 show cases，而是 show thinking，不过有时候只有先 show cases，才能 show thinking...

🏆 工作多年之后

2020-12-12 20:53:10
工作了三年之后，你应该表现出来的:
  1. 对技术的精通、业务的熟悉、沟通能力、任务拆解能力、全局思考能力
  2. 任何需求都能准确评估并按计划实现，一个优秀的参与者。
  3. 能够对项目提供坚强的支持，无论是技术、意见和兜底都能有足够的参与度和靠谱度。
  4. 能够熟悉整个大项目的关键点和和技术架构，自己负责的部分能够深入且有质量和工程化。
五年之后:
  1. 独立负责项目: 独当一面、逻辑推理、业务梳理、功能实现能力等，而不是仅仅完成别人布置任务。
  2. 整体的思路很清晰，能够对别人的问询应付自如，能够简练的给别人讲清楚整个项目。
  3. 对别人提出的需求和假设，能够当场给出靠谱的解决方案、业务评估。（这些是被项目和需求大量训练出来的下意识思考，同时涉猎过大量的项目和技术范围。）
  4. 竞争力，能做别人做不到的事情。

😳 红海/蓝海

2020-12-07 23:02:10
进入到别人深耕多年的领域，就不能按照别人刚开始的玩法，或者相信自己刚开始的认知了，需要不断地学习才能恍然大悟。
比如做应用和游戏的，多年前游戏只要上架就能挣钱，推广也很简单，但是现在满大街的游戏，花钱让别人玩都很难增长。
又比如做网店，多年前只需要把店开起来就有订单，但是现在还在相信自然流量的已经死了很多波了，你需要各种投入和引流才能勉强存活，成本大了很多。
再比如开实体店，多年前做生意只要靠谱都能成，现在都被资本和房租压缩到了极致，如果不拼尽全力很容易就被淘汰了。
再再比如做互联网，多年前隐私保护、不正当竞争没那么完善，做大挣钱之后补上就行。但是现在隐私保护、专利保护、牌照资源、商用限制等东西如果你刚开始不投入资源，刚上架就会被找麻烦。
这些已知的领域对新人/新公司很不友好，因为你能想到的方法都是多年前别人试过的，做成的在提高效率做竞争门槛，而新人必须要不断学习才能知道现在的一线玩法。

😳 react-jsx

2020-11-26 21:23:10
刚创建的项目，在确认已经引入了 React 之后 tsx 文件飘红，看了下 tsconfig.json，发现一个不认识的选项 jsx: "react-jsx"，简单看了下挺有意思~~
项目用的最新的 React 17 版本，里面涉及到一个重要的改动就是 JSX 的编译。
老版本里面一直习惯的必须在 jsx 语法文件中引入 React，不然会报错，因为语法转换: 
// 转换前
const App = () => <h1>Hello World</h1>
// 转换后，里面包含了 React，必须要手动引入
const App = () => React.createElement('h1', null, 'Hello world')
17.0 修改了这个机制，上层使用的时候不变，但是编译过程修改了: 
// 转换后，不依赖于显式的 React，编译期自动引入 jsx 运行时
import {jsx as _jsx} from 'react/jsx-runtime';
function App() {
  return _jsx('h1', { children: 'Hello world' });
}
编辑器检查 ts 语法是依据 Tsdk，Tsdk 依据项目里的 tsconfig.json 配置，这个配置只有 ts 4.1 版本才有，Tsdk 是谁指定的呢？
  1. 如果命令行执行 eslint，那么可以用全局安装的文件，或者在 nodejs 中引入不同的位置
  2. 如果是编辑器的语法检查或者插件，需要配置，默认是编辑器自带，可以手动指定
所以如果 tsconfig.json 中配置 jsx: "react-jsx"，但是 Tsdk 版本小于 4.1 ，不认识这个选项，那么就都报错了。所以使用 React 17 版本的话，可以把配置改成了 react 、指定项目内的 ts、升级编辑器。

💡 方法论

2020-11-11 21:56:10
任何事情都是有方法论的，怎么解决问题、怎么沟通、怎么实现目标、怎么提效，很多东西都是能够总结出来、或者去学习得到的。就像是机器学习，就算你随机的实践，结果好作为激励，那么每次做的好的路径都是不停改进的方法论。
编程中:
  1. 每次对接项目都会花很多时间联调，为什么不去找提前对接的方法呢？
  2. 每次产品提测都是很痛苦的过程，回归测试每次都出问题，为什么不完善代码规范、考虑自动测试等方法呢？
  3. 产品清单、运行清单、测试清单
  4. 抽象、规范、流程、标准化、工程化
生活中也是一样:
  1. 做事不靠谱？那就提高能力、多实践、从而更准确的项目评估，遇到哪些问题然后下次预先考虑。
  2. 不善沟通？那就多沟通，把负面的心理惩罚降低，让自己更愿意去沟通，从而根据反馈调整自己的应答机制。
  3. 效率低？那就列出提效清单一个个实践。
遇到问题，那么就封装出一个解决问题的方法，下次遇到就直接调用。要有活跃的反馈和思考，像是一个有返回值的函数，好在哪？不够好在哪？下次怎么能做的更好？像是一个活跃的神经元，接受刺激，反馈信号。 最怕的是你关闭了学习的途径，变得像个老人一样，依靠老的习惯，不愿意找方法。
// 防杠: 方法论的输入不可能考虑全部的参数，所以也就导致方法论也并不是万能的。就像你的孩子从小和你做了完全一样的每个决定，大环境和运气的成分也可能让你们变得完全不同。

😲 猝不及防

2020-11-06 20:51:10
猝不及防，在你毫无准备的时候突然宣布一个让你严肃起来的消息，打乱你原本计划的一切。所以可以的话，让自己提前准备好，拥抱变化 😂，或者主动寻求变化。

💾 Web 编辑器内容防丢失机制

2020-11-01 20:42:10
  1. 文章变动立即存储内容和时间到本地，以一分钟粒度创建历史记录，随时可恢复
  2. 闲置无操作 2s 后再次检查本地存储是否一致无误，以免内容未持久化
  3. 有未保存到云端的内容时，关闭网页会触发提示组织关闭窗口
  4. 有未保存内容时强制关闭页面，下次进入能够提示恢复
  5. 本地内容比服务器内容更新时会主动提示恢复
  6. 每次保存操作后，会拉取刚保存云端内容，检查本地内容保存是否确认无误
  7. 删除操作提供标记废纸篓，而不是删除记录，删除操作可以云端恢复
以上内容如果出现错误将会提示用户，除非系统故障、浏览器错误导致本地存储失效，以上的备份机制还是能够做到防丢失的目的。

💒 结婚啦！！！

2020-10-01 23:58:10
非常开心自己的婚礼能有一场盛大的仪式来纪念这个难忘的日子。我一直觉得时间是证明一段感性真挚的方式，而我们用了 6 年的时间来证明了我们的感情，此时此刻我也能够在你的眼睛里看到这份真挚。今天我在此立下誓言，在我们的第 7 年、第 8 年、...第 100 年，我也能看着你的眼睛说 “我爱你”。
此外感谢为了我们两个的婚事忙前忙后、亲力亲为的大家庭的所有人，真的特别完美的一个婚礼，此生难忘。中秋/国庆双节同庆的日子，感谢所有人。
我们结婚啦
我们结婚啦

🤔 为什么没有人注意页面的音效了呢？

2020-8-09 20:16:10
现在的按钮、组件之类的，都没有了声音好像，音效的播放如果是点击、滑动等用户操作触发的，也不会被浏览器拦截，恰到好处的安排也不会很突兀。
很久之前 flash 页面很多的时候，带有音效的各种操作反馈挺有意思的，后来可能多媒体的支持没跟上、打扰到用户、没需求等，很少看到普通的应用中添加音效了。
客户端应用，比如 MACOS 或者 Windows 系统中包含了很多的操作音效反馈，这确实能够提升更强烈的感官丰富度。
所以: 不能被这种约定、大家都不做限制了想象，有时间给组件库加上音效主题，一定很有意思。

🆗 你见到过整个鳄鱼，就不会奇怪为什么水面上有两个眼睛了

2020-7-22 19:48:10
能够看到的很多技术、方案、规范、实现等，都有本质上的原理，初学者可以靠记性记住很多东西，但是原理如果明白了那么久能够融会贯通了。
比如: 很多实习生 弄不清楚 Headers、跨域、返回数据解析、API 版本、HTTP 报文等。本质是浏览器和服务器定义的请求响应数据结构的问题。
  • 浏览器和服务器的接口沟通走的时候 HTTP，浏览器发什么、服务器返回什么，在遵循 HTTP 规范的前提下都是很自由的。比如浏览器会根据服务器设置的 CORS 头来控制跨域的处理，但是如果不是浏览器来做 HTTP 请求，这个 CORS 头客户端就可能不去遵循。所以说白了这些 Headers 都是参数，其中有浏览器或者业界统一遵循的头规范，也可以自己定义、改写这些参数，然后达到自己的控制目的。
  • 从这个角度来看，http 请求的发送，添加 application/json 头，服务器就知道应该返回 JSON 格式数据，如果协商说客户端添加 accept: text/xml 的头参数，服务器只要能控制，也能决定返回 JSON 格式数据，这个不是写死的，而是代码里的约定俗成而已。请求中手动添加 v:2 的参数，服务器也能知道返回高版本的数据响应。
  • 再说很多的后端框架，比如 PHP 的 YII/ThinkPHP、JAVA 的 Tomcat 等框架，本身内置了很多的 HTTP 解析模块，能够将约定俗成的头参数进行解析，比如返回数据能够根据 accept 来自动的决定返回 JSON 还是 XML，这个行为是框架封装的，也是代码决定的。
再比如: 线程和进程、Docker 的 CPU限制、单线程模型。本质是 CPU 时间的问题。
  • 正常一台机器，多任务的处理方案都是 CPU 运行一段时间后切换给其他任务，所以多任务的本质是 CPU 把自己的计算时间给谁的问题，MACOS 的活动监视器中能够看到每个进程所用的 CPU 时间总和。
  • docker 或者虚拟机能控制某一个容器或机器最多用多少内存，但是没办法控制最多用多少 CPU，因为 CPU 的计量单位是时间和核，只能控制用几个核心用多久。
  • 本质上也是计算送到 CPU，计算完毕之后返回，这个计算时间跟计算量和 CPU 的频率有关，多个容器在一台机器上，机器能分配的是每个容器的优先级和时间分配。
  • 单个线程算一个计算，多线程就是将多个计算列队让一个进程循环处理，避免这一个进程出现空闲 CPU 时间，无论再快也是一个个计算，只是避免 CPU 等 IO 的情况，如果多线程全都是 CPU 计算的话，多线程的效率比单线程还要低，因为本质这个进程的 CPU 时间都是跑满的。（相当于三个队排队窗口打饭，如果每个人都要思考吃什么，师傅先给另一个队列打饭就行，整个队列会更快。但是如果每个人不思考上来就能打饭，那么排 100 个队伍打饭师傅也不可能比一个队更快）
  • 多进程是利用多核 CPU 核心，每个进程中都能安排计算，每个进程同时有 CPU 时间给这些计算。（相当于窗口有 2 个打饭师傅，无论怎么打饭也比 1 个师傅更快）
  • JS 这种单进程的执行逻辑一般都是用的 Event Loop，宏任务和微任务之类的执行逻辑，宏任务中的回调挂起，成功后被放到微任务中，宏任务完毕之后检查微任务，如果宏任务中有密集型的计算任务占据了 CPU 时间，那么用户操作的反馈在微任务中无法被调用响应，那么就会造成了卡顿。
有时间写个计算机通识与业务关系。
  1. CPU数、核心和线程 · 进程、线程和并发 · Java并发配置、web server 并发配置
  2. 网络层的一层层包装和协议，从 IP 到HTTP，再到 HTTP/2 的概念问题，到 server 和 browser 的概念，再到 RPC 等进程通信相关，聊聊数据怎么传的问题

🛅 数据层

2020-6-12 22:52:10
数据层和视图层的关系，在现在 React 类框架中没有很复杂的实现，甚至无意去着重实现。目前与 View 相关的数据层已经很多了，而基本上这些数据层也仅仅与视图层相关，没办法承载更复杂的东西。
业务本身如果足够复杂的时候，其也本应该有自己的核心数据层，比如很多的前端应用级别的实现，这些实现不可能依赖于业内有一个足够强大、适用、灵活的数据层来普适性的满足，更不能寄希望于 React 这些本身定位是视图层的框架来负责。
这些复杂的业务强相关的数据层是需要业务开发自己实现的，无论是基于目前的方案还是自己手动去撸。
对于数据层的实现和业务关联，目前我在 Novus 中，定义数据模型、动作、副作用，虽然与视图层强相关，重点在数据的聚合、变动和响应，这也足够满足一般意义上的前端业务，甚至涉及到编辑器类的应用级也能够应付大部分情况。而且进一步说，业务的数据层包含复杂输入输出、包含复杂的计算甚至前端侧的 CRUD 等需求，比如游戏等复杂交互和渲染的需求，这个真的跟传统视图层无关，需要有专门的数据层来支持这些模型和交互。

📠 客户端代理

2020-5-23 18:52:10
测试或者个人 demo 用来跳过 CORS:
https://cors-anywhere.herokuapp.com/
https://cors-anywhere.azm.workers.dev/
源码:
https://github.com/Rob--W/cors-anywhere/

🔃 React 组件的泛型定义

2020-5-16 13:02:10
React.ComponentType
// 组件的泛型 props
type CommonFormProps<T> = {
  name: string
  value: T
}
// 带有泛型的函数组件
function CommonForm<T>(props: CommonFormProps<T>) => JSX.Element
// 添加一个 memo 包裹，可以透传
const NewForm = React.memo(NewFormComponent)
// ===> 
// 在使用的时候用 ComponentType + as 来实现泛型的限制
const NewString = NewForm as React.ComponentType<CommonFormProps<string>>
const NewNumber = NewForm as React.ComponentType<CommonFormProps<number>>

😄 LOL hahaha...

2020-4-29 12:32:10
IT Crowd
IT Crowd

😲 预期、不符预期、焦虑、忙起来

2020-04-06 19:52:10
  1. 一个人基于自己的判断决定做某件事
  2. 这个人对这件事有自己的预期
  3. 但是事情的发展不符合自己的预期
  4. 焦虑和严肃随之而来
  5. way 1
    1. 顿悟、理智
    2. 找到明确的方法，坚持下去 / 说服自己跳出框架 / 变更思路
    3. 逐渐解决问题
  6. way 2
    1. 没有有效的解决办法
    2. 尝试各种办法 keep busy，缓解自己内心的焦虑
    3. 接受现实
最近看到太多这个心里路径了

🕥 github.githistory.xyz

2020-3-22 23:14:10
只需要把 github.com 换成 github.githistory.xyz 就可以浏览源代码文件以及它的历史变更，对于看源码怎么一步步的实现的非常友好

🗿 npm mirrors

2020-2-12 20:37:10
node 的 npm 包安装众所周知的慢，但是在 cnpm 镜像下快很多，或者 yarn 都能解决大部分的网络问题。但是很多 node 模块，比如 node-gyp 等还是依旧的慢，因为其中很多涉及到二进制的 node 文件。这里记录下这个地址: https://npm.taobao.org/mirrors，可以使用 mirror-config-china/binary-mirror-config 自动创建 npmrc 配置这些模块的镜像地址，能节省很多人生时间。

👰 她在 24 岁打怪兽

2020-2-08 07:32:10
从前有一个城堡，里面的居民每天都要打怪兽才能照顾好自己的生活。我爱的人，她叫小豆芽，很喜欢笑，剑法很不错，每天都能斗志昂扬的去打小怪兽，三两下就能放到的时候，还嫌生活太过平淡。后来她就去挑战了大怪兽了，不过好像有点不太能搞得定，在我的帮助下都被打得经常受伤，一天天的去挑战，偶尔打败了一个，但更多的是受伤，还被别人说打得太慢了，不认输的她都变得怀疑自己，斗志从积极到疲惫，看着特别心疼。早晨太阳升起，我迷迷糊糊的还没睡醒，她红着眼睛小声的跟我说: “我可不可以休息一天，我不喜欢去打怪兽了。”，心疼的紧紧抱住她，我能做的不多，帮她研究剑法，帮她疗伤，逗她开心，她还记得曾经的愿望和梦想，想好了在这个大怪兽身上锻炼出绝世剑法，陪我一起仗剑走天涯，过上自由的生活。大好青春年华，别皱着眉红着眼，享受自己春天的年纪，我来保护你。

🔨 辅助工具

2020-1-8 19:52:10
  • 录屏使用开源免费的 kap，能导出 mp4 效果比 gif 好很多，可控而且文件更小；
  • 原型图之类的使用 Sketch 画图，无论是产品设计还是基本的图表绘图都很不错，导出 svg 直接作为图片引用，不好的地方是文字空格会合并，不过少量文字可以轮廓化，图表比截图展示好很多。
  • 字符图使用 asciiflow 不用导出图片，直接使用字符画，简单图形来说更方便些

🌿 编程中常见的 Effect

2019-12-12 23:02:10
我们在 React 里面看到了 useEffect 的 Hook，在 Redux 里面看到了 Effects，第一次见可能会一头雾水，这些被称为副作用。其实根据函数式编程，所谓"副作用"（side effect），指的是函数内部与外部互动（最典型的情况，就是修改全局变量的值），产生运算以外的其他结果。计算以外的操作都属于 Effect，典型的就是 I/O 操作、网络请求、数据库读写等，算作除了标准输入之外的输入，可能会影响函数式的状态。

🛴 JSX <-> React

2019-12-10 22:22:10
JSX 语法和 React 并不是绑定在一起的东西，既可以只使用 JSX 不使用 React，也可以只用 React 不用 JSX。 JSX 作为一个类 XML 的语法，作为组件和 HTML 的抽象是非常合适的。单独使用 JSX 的时候只需要安装 @babel/plugin-syntax-jsx 让 babel 识别 jsx 语法，再配合其他转换插件，比如 @babel/plugin-transform-react-jsx 或者 vue-jsx，即可转译为普通的 js 语法了，也可以简单的使用 babel-plugin-transform-jsx 语法: 
let box = <div />;
=>
var box = {
  elementName: "div",
  attributes: {},
  children: null
};

👻 内心强大的混蛋

2019-9-29 20:32:10
构建自己的意识壁，和普通人不一样，不轻易否认自己，积极向上，懂得争取些什么

💭 Hooks 需要不一样的思想

2019-08-01 19:12:10
hooks 的思想是开发者不再需要去理清每一个生命周期函数的触发时机，以及在里面处理逻辑会有哪些影响。而是更关注去思考哪些是状态，哪些是副作用，哪些是需要缓存的复杂计算和不必要的渲染。

🐞 关于

有时间就会分享一些技术文章、专业内容、经典问题、系列功能等。

｛⛔ 未标注内容均为原创，请勿转载 ©️｝
Ubug