所有的代码规范、接口设计以及各种规定，都是为了在团队内部形成共识，防止个人习惯差异引起的混乱。 GitHub 当中有不少有用的功能，本文将介绍 Issues、Pull Requests、Discussions、Projects 等功能。 Issues Use GitHub Issues to track ideas, feedback, tasks, or bugs for work on GitHub. 根据官方文档的说法，Issues 可用于追踪想法、反馈、任务以及 Bug。 在新建 Issue 时，还可以设置 Assignees、 Labels、Projects、Milestone 等属性。 属性 用途 Assignees 指定这个 Issue 的负责人。 Labels 指定这个 Issue 的标签，表示该 Issue 的类型，例如 bug、enhancement、question、help wanted 等。 Projects 指定这个 Issue 的所属项目。 Milestone 指定这个 Issue 关联的里程碑，通常用来表示项目的一个阶段。Issue 不能设置截止时间，但是 Milestone 可以。 在实际使用的时候，每当有新的需求时，建议先创建新的 Issue，再创建对应的功能分支，功能分支的名称可以以 Issue 的编号开头。在任何时候，针对一个 Issue 只能存在一个分支，但一个分支可以解决一个或多个 Issue。 在描写一个 Issue 标题的时候，使用 “As an administrator, I want to remove users without receiving an error” 会比 “Administrators can’t remove users.” 更好。 在 Commit Message 中提到 #n（其中 n 为 Issue 编号，下同）即可将该 commit 与相关 Issue 关联上。更进一步，只要 Commit Message 中出现 close、closes、closed、fix、fixes、fixed、resolve、resolves、resolved 等官方文档中出现的关键词加上 #n，就可以关闭对应 Issue。 Pull requests Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. Pull Request 本质上是一种沟通机制。 当你需要反馈的时候，你可以不指定 Reviewers，并在标题中写上 [Draft]、Draft:、(Draft) 等关键词，告知大家这是一个 Draft Pull Request，防止被不小心合并了。 当你需要将合并代码的时候，指定 Reviewers。 在分支开发完成后，大概率会有不少的 Commit 记录，但是在合并到主分支的时候，往往只希望较少的 Commit 记录，方便追溯以及管理。如果该分支由你一个人开发，且该分支没有和主分支合并过，应该把多个 Commit 记录合并成一个（或两三个）。 Discussions Use discussions to ask and answer questions, share information, make announcements, and conduct or participate in a conversation about a project on GitHub. GitHub 终于把 Issues 和 Discussions 这功能划分得更加明确了。 在 Discussions 功能出现之前，开发者只能把交流放到 Issues 列表当中，时间久了之后整个 Issues 会变得非常混乱。Discussions 更像是个社区论坛，可以在上面进行提问、发布公告以及分享信息。 Projects Projects are a customizable, flexible tool for planning and tracking work on GitHub. Projects 功能简单说就是提供项目看板，可以将 Issues、Pull Requests 更系统化地追踪，且可以自定义 Workflow。关于 Projects 的最佳实践请参照官网。

所有的代码规范、接口设计以及各种规定，都是为了在团队内部形成共识，防止个人习惯差异引起的混乱。 当只有你自己一个人在 Git 仓库中的时候，你一般不需要考虑如何协作的问题。 但当你需要与多人一起协作的时候，混乱就诞生了。 对于不同规模的团队，不同的协作模式效率也不一样。本文将介绍不同的 Git 协作流程，以适应不同的团队。同时，带着以下的先验知识阅读文章会对你更有帮助： 工作流程需要简单，并且工作流程确实能够提高团队的生产力 没有适用于任何情况的万能工作流程 业务上的需求会倒逼出更适合团队的工作流程 关于 Git 的操作可以参照《程序员的时间机器 —— Git 与 GitHub 的使用》。 Git Flow Workflow Git Flow 适用于有预定发布周期的项目，但不太适用于持续发布的项目。 Git Flow 提出了五种不同的分支，分别是 master、develop、hotfix、release、feature。 其中，master 和 develop 分支是长期存在的，而 hotfix、release、feature 在被合并进 master 或 develop 分支后，这些分支都会被删掉，因此也是短期分支。 Git Flow 主要为不同的分支分配了非常具体的作用，以及定义了它们之间应该如何以及何时产生互动。 分支名称 分支属性 分支作用 master 长期分支 主要用来存放稳定、随时可以上线的版本，开发者不会直接 commit 到此分支上。因为是稳定版本，通常会在 master 分支上的 commit 贴上版本标签。 develop 长期分支 作为主要开发的分支，是所有短期分支的基础分支。当要发布时，在 master 分支上对 develop 分支进行合并。 hotfix 短期分支 从 master 分支创建进行修复，当修复完成后合并回 master 分支，也同时合并回 develop 分支。 release 短期分支 在 develop 分支发布正式版本到 master 分支之前可以进行预发布进行测试。 feature 短期分支 从 develop 分支创建，用来新增功能的分支，完成开发后再合并回 develop 分支。 在 macOS 上只需要使用 brew install git-flow 即可安装 git-flow 的命令行工具。安装完 git-flow 后，就可以通过 git flow init 来使用。git-flow 本质上是对 Git 的一个封装，git flow init 命令就是默认的 git init 命令的扩展，除了为你创建分支外，并不改变仓库中的任何东西。git-flow 的常见命令如下： git flow init # 初始化 git flow feature start feature-a # 创建 feature git flow feature finish feature-a # 完成 feature git flow release start .. # 创建 release git flow release finish .. # 完成 release git flow hotfix start bug-a # 创建 hotfix git flow hotfix finish bug-a # 完成 hotfix 因此，使用 git flow 的大致流程是这样的： develop 分支由 master 分支创建而来 feature 分支由 develop 分支创建而来 当一个 feature 分支完成了之后，需要将它合并到 develop 分支中 release 分支由 develop 分支创建而来 当一个 release 分支完成了之后，需要将它合并到 develop 和 master 分支中 hotfix 分支由 master 分支创建而来 当一个 release 分支完成了之后，需要将它合并到 develop 和 master 分支中 总体来说，虽然 git flow 分支的作用清晰，但是较为复杂： 需要同时维护 master 与 develop 两个长期分支，且大多数工具都会将 master 分支作为默认分支，开发者会需要高频切换，过于繁杂。 hotfix 和 release 分支带来的复杂性对于大多数团队来说都是过犹不及的，例如有开发者只把修改合并到 master 分支而不合并到 develop 分支，有些项目不需要做热修复等等。 Forking Workflow Forking Workflow 一般适用于开源项目的贡献同时也适用于私有工作流程。Forking Workflow 一般会与 Git 托管平台结合使用。 以实际的例子举例，使用 Forking Workflow 的流程大致如下： 你想对托管在 GitHub 的开源项目 VXenomac/DS_Store_Cleaner 贡献 在该仓库页面，使用 GitHub 的 Fork 功能 将在自己账号下的该仓库 clone 到本地 在本地创建新的 feature 分支 开发完成并提交 commit 将该 feature 分支 push 到自己账号下的该仓库 使用 GitHub 的 Pull Request 功能申请将 feature 分支与原始仓库进行合并 由原始仓库的 maintainer 进行判断是否合并 GitHub flow Workflow The GitHub flow is useful for everyone, not just developers. 官方文档中提到 GitHub flow 使用起来非常简单，你只需要有一个 GitHub 的账号以及一个 Git 仓库即可。 对于持续发布的产品来说，GitHub flow 是最合适的流程。 使用 GitHub flow 的大致流程如下： 从 mater 分支创建新的分支，不区分 feature 还是 hotfix 分支 在新建的分支上开始开发，理想情况下，每次 commit 都包含一个独立（isolated）且完整（complete）的修改 当你准备好合并之后或者需要讨论的时候，就发起一个 Pull Request 负责代码审核的人可以对该 Pull Request 进行提问、建议、点评等 当 Pull Request 被审批通过之后，这部分变动会被合并到 master 分支上 当分支被合并之后，需要删除之前创建的分支 GitHub flow 看上去整体确实非常简单、高效，但是是基于 master 分支就是当前线上代码的假设，而有时候业务较为复杂的时候，发布到 master 分支的代码并不是立刻就发布的，例如需要等待到特定时间才能发布等，这会导致线上版本落后于 master 分支的版本，因此这种情况下你不得不创建其他分支来跟踪线上版本，例如 production 分支。 GitLab Flow Workflow Frequently, the reaction to this problem is to adopt a standardized pattern such as Git flow and GitHub flow. We think there is still room for improvement. In this document, we describe a set of practices we call GitLab flow. 官方文档中提到 GitLab Flow 结合了 Git Flow 和 GitHub flow 的优势。 GitLab Flow 主要提出了几个新的提议： 针对 GitHub flow 存在的假设问题：master 代码是立即发布的，GitLab Flow 中提出用 Production branch 来解决问题，即创建一个反映线上代码部署情况的分支，将 master 分支部署到 Production branch 来部署新版本（不知道为啥官方文档图中用的是 development 分支）。 针对实际的部署环境，GitLab Flow 提出用 Environment branches 来控制部署环境。GitLab Flow Workflow 要求变更只向下游流动，以确保所有变更在所有环境中都经过测试。假设你有一个 staging 环境、一个 pre-production 和 production 环境，则一个完整的上线流程是： 使用 staging 分支部署到 staging 环境 将 staging 分支合并到 pre-prod 分支以部署到 pre-production 环境 将 pre-prod 分支合并到 production 分支以部署到 production 环境 GitLab Flow 提出用 Release branches 来对外发布版本，每一个稳定版本都从 master 分支创建。只有在修补严重的 BUG 才允许将代码合并到这些分支上，在此过程遵循上游优先（upstream first）策略，即先合并到 master 分支再 cherry-pick 到 对应 release 分支。 一些技巧 不同的 Workflow 都是为了提高协作之间的效率以及减少冲突的发生，我们在使用 Git 过程本身中，也更应该遵循一些原则来减少冲突的发生： 逢新必创：每次开发新功能，都应该新建一个单独的分支 逢切必拉：每当切换到共有分支，先拉去最新的代码 小步快走：每开发完一个小功能就先提交 合多为一：如果某一分支由你单独开发且没有和 master 分支合并过，则发起 Pull Request 前，应该把多个 Commit 合并成一个以方便阅读或 cherry-pick

所有的代码规范、接口设计以及各种规定，都是为了在团队内部形成共识，防止个人习惯差异引起的混乱。 你是否也受够了自己所有的 Git Commit 记录都是亘古不变的 Update，某一天回查的时候啥也查不到。 写好 Commit Message 不仅有助于 Code Review，还可以便捷有效地输出 CHANGELOG。 本文将介绍 angular 团队的 Git Commit 规范格式以及方便标准提交 Git Commit 的工具。 关于 Git 的操作可以参照之前写的《程序员的时间机器 —— Git 与 GitHub 的使用》。 Commit Message 格式 参照 angular 的 Commit Message Guidelines，angular 团队对 Git Commit 的格式有着非常精确的规定，在他们的规范中，每条 Commit Message 由 header、body 、footer 组成。header 会有特殊的格式，包括type、scope、subject。其中： type 是 commit 的类型 scope 是 commit 的影响范围 subject 是 commit 的概述 body 是 commit 的具体内容 footer 是 commit 的一些备注 <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> 在 angular 团队的规范中，type 只能是以下的： build: 影响构建系统或外部依赖的变换 ci: 改变了 CI 的配置及脚本 docs: 更新了文档 feat: 增加了新功能 fix: 修复了 BUG perf: 提高了代码的性能 refactor: 重构了代码，没有修复 BUG，也没有新增功能 style: 代码格式上的调整，不影响代码的含义 test: 新增缺失的测试或修正现有的测试 angular 官网的一些 Commit Message 的例子如下： docs(changelog): update changelog to beta. fix(release): need to depend on latest rxjs and zone.js The version in our package.json gets copied to the one we publish, and users need the latest of these. 一些注意事项如下： header 是必须的，scope 则是可选的。 Commit Message 中的任何一行都不能超过 个字符。 如果 commit 回滚了，Commit Message 则应该以 revert 开头，后面跟上被回滚的 commit 的 header，在 body 中应该提到这是对 <hash> 的回滚，其中 <hash> 指的是被回滚的 commit 的 SHA。 （这条非 angular 规范，但比较重要）理想情况下，每个 commit 都包含独立（isolated）且完整（complete）的修改。 Commitizen 工具 上面说了那么多的规范，到现在基本都差不多忘了吧？既然写好 Commit Message 是刚需，那社区自然少不了好用的工具。对于懒人来说，借助工具就可以把 Commit Message 写得规范，同时还能一步解决 Commit Message 和版本发布的事情。 首先介绍一个工具 commitizen/cz-cli，使用它提供的 git cz 就可以帮助我们生成符合规范的 Commit Message。此外，我们还需要 为它指定一个 Adapter（例如 commitizen/cz-conventional-changelog 是一个符合 Angular 的预设），使得 commitizen 可以按照我们指定的规范生成 Commit Message。 我觉得此类工具还是全局安装比较方便，以下为安装命令： npm i -g commitizen cz-conventional-changelog npm i -g commitizen cz-conventional-changelog --registry=http://registry.npm.taobao.org # 如果第一条命令比较慢可以使用淘宝镜像源进行安装 echo '&#; "path": "cz-conventional-changelog" &#;' > ~/.czrc 安装完成后，在 Git Repo 中要进行 Commit Message 时使用 git cz 命令即可： 自定义 Adapter angular 的规范总归是其他团队的规范，如果需要指定一套符合自己团队的规范，也可以通过指定自定义 Adapter 来实现。 npm i -g cz-customizable npm install -g cz-customizable --registry=http://registry.npm.taobao.org # 如果第一条命令比较慢可以使用淘宝镜像源进行安装 之后修改 .czrc 中的内容为： &#; "path": "cz-customizable" &#; 同时在 ~/ 目录下创建 .cz-config.js，维护你想要的格式，一个参考格式如下： 'use strict'; module.exports = &#; types: [&#; value: 'WIP', name: '💪 WIP: Work in progress' &#;, &#; value: 'feat', name: '✨ feat: A new feature' &#;, &#; value: 'fix', name: '🐞 fix: A bug fix' &#;, &#; value: 'refactor', name: '🛠 refactor: A code change that neither fixes a bug nor adds a feature' &#;, &#; value: 'docs', name: '📚 docs: Documentation only changes' &#;, &#; value: 'test', name: '🏁 test: Add missing tests or correcting existing tests' &#;, &#; value: 'chore', name: '🗯 chore: Changes that don\'t modify src or test files. Such as updating build tasks, package manager' &#;, &#; value: 'style', name: '💅 style: Code Style, Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)' &#;, &#; value: 'revert', name: '⏪ revert: Revert to a commit' &#; ], scopes: [], allowCustomScopes: true, allowBreakingChanges: ["feat", "fix"] &#;; 自动生成 CHANGELOG 工具除了可以帮助我们规范化进行 Commit Message，在规范提交 Commit 信息的情况下，还可以使用 conventional-changelog/standard-version 工具帮助我们自动生成 CHANGELOG。 npm i -g standard-version npm i -g standard-version --registry=http://registry.npm.taobao.org # 如果第一条命令比较慢可以使用淘宝镜像源进行安装 standard-version --first-release # 使用 standard-version 生成第一个发布版本的 CHANGELOG 关于 standard-version 更多的使用方法可以参考官方 Repo 的使用说明。

所有的代码规范、接口设计以及各种规定，都是为了在团队内部形成共识，防止个人习惯差异引起的混乱。 你可能会在代码注释中见过以下的内容： # TODO: implement the algorithm here ... # FIXME: late at night, I need some sleep 使用这些注释标签可以很方便地搜索到代码可以被改进的地方，大多数 IDE 都会有一个专门的视图来呈现这些内容。Python 中也有 PEP 介绍这些 Codetags，尽管这个 PEP 被拒了，但还是有非常多有意思的点。 常见的注释标签 我根据对代码的影响程度大小将不同的注释标签分为了蓝色组、橙色组、红色组，影响程度依次加深。 蓝色组 蓝色组表示代码可以运行，但是需要更多的功能或更多的解释。 注释标签 用途 标签注释 PEP 解释 TODO 功能待实现 知道要实现什么功能，但还没开始写。 Informal tasks/features that are pending completion. NOTE 代码实现描述 描述代码的工作原理等 Sections where a code reviewer found something that needs discussion or further investigation. 橙色组 橙色组表示代码可以运行，但是不正确。 注释标签 用途 标签注释 PEP 解释 HACK 代码待优化 使用非正规的方法实现了功能，不应该进入生产环境。 Hacks: Temporary code to force inflexible functionality, or simply a test change, or workaround a known problem. FIXME 代码需修复 有问题或者不能运行的代码，需要修正。 Areas of problematic or ugly code needing refactoring or cleanup. BUG 代码有漏洞 有个 BUG。 Reported defects tracked in bug database. REVIEW 代码待评审 代码可能是正确的，但是需要评审一下。 XXX 代码待优化 虽然能用但是丑陋的代码，未来有空需要优化，需要更好的抽象性、可维护性以及性能等。 Areas of problematic or ugly code needing refactoring or cleanup. 红色组 红色组表示代码根本无法运行。 注释标签 用途 标签注释 ERROR 代码抛异常 代码出现了具体的、重复的错误，即可复现的异常。 BROKEN 代码坏了 代码坏了

每年年末，我的一大乐趣就是翻阅各大 APP 出品的个人年度数据报告。 一来是出于职业习惯，二来是认为这些数据姑且能算是我过去一年真实存在的证据。 但我总感觉差些什么，在今年我终于意识到了， 那就是微信这个几乎每天都占据最多使用时长榜首的应用，竟然没有一个使用数据分析报告。 本着好玩的想法，我尝试着自己完成了一个非官方版的微信好友聊天分析报告，代码目前已开源在 GitHub，具体使用方式请参照仓库的说明。 最终的效果如下，包含了一些聊天情况数据及聊天关键词的词云图等： {.gallery data-height=“”} 完整复现本文分析至少所需以下内容： 至少拥有一台 iOS / iPadOS 设备，如果只是安卓用户，本文暂未覆盖，阅读本文可能会浪费你的时间。 有耐心等待不确定的备份时间，一般在几个小时以上，并且有重来一次的决心。 流程 数据准备 数据分析脱离数据就无从谈起，整个过程中最耗时、最重要的就是获得与微信好友的聊天记录。 本文采用 WX Backup 这款工具来获取微信聊天记录，如何解密微信的本地数据库不在本篇的讨论范围内，有时（挖）间（坑）可以单独开一篇聊一聊。 iTunes 备份 据官网介绍，你需要做的就是将带有聊天记录的设备连接到电脑（Mac/PC）上，并使用 iTunes 进行一次完整备份。 从 年苹果宣布取消在 macOS 上的独立 iTunes APP 之后，iTunes 就被集成在 Finder 当中。请注意，在备份的时候不要选择「加密备份」。 完整备份一次需要非常久的时间（由设备使用容量所决定，但一般不低于两小时），因此如果你恰好有一些 iOS / iPadOS 设备，有个技巧比较适合： 将需要分析的用户的聊天记录迁移至另一台使用容量较小的设备，这样获取数据的耗时一般就会缩短不少。 不要忘记你的设备依然与你的 iTunes 保持着连接，不要因为一些习惯性动作（接电话、离开一会儿等）拔掉数据线。血的教训，但也只能再来一次。 导出聊天记录 当你备份完成之后，你可以使用 WX Backup 来导出你想要分析联系人的聊天记录（图来自于 WX Backup）： 选择一个联系人导出后会得到一个文件夹，本次分析所需要的数据就在 js 文件夹中的 messages.js 中。 将 JS 转换为 Excel 为方便后续处理，可以先将 messages.js 文件转换为熟悉的 Excel 文件，转换代码如下： import json import pandas as pd from pathlib import Path from datetime import datetime def jsexcel(path): with open(path, 'r') as f: load_dict = json.loads(f.read().replace('var data = ', '')) message = pd.DataFrame(load_dict['message']).rename(columns=&#;'m_nsFromUsr': '发送人', 'm_uiCreateTime': '发送时间', 'm_nsContent': '消息内容'&#;) message['发送时间'] = message['发送时间'].apply(lambda timestamp: datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %T')) ORDER = ['发送人', '发送时间', '消息内容'] message = message[ORDER] return message if __name__ == '__main__': folder = 'XXX' # 替换为导出联系人的文件夹名称 path = Path(folder) / 'js/message.js' message = jsexcel(path) message.to_excel('消息.xlsx', index=False) 在运行完脚本之后便可以获得一个包含了所有消息的 Excel 表格。 数据分析 本脚本当前支持以下分析： 计算成为好友的天数：根据本地聊天记录计算与目标用户第一次聊天迄今为止的天数。如果换过手机等原因造成聊天记录缺失等的情况会导致数据不准确。 计算聊天的天数：计算成为好友迄今为止当天至少发送过一条消息的天数。 计算聊天最频繁的日期：计算成为好友迄今为止当天发送消息数量最多的日期。 计算聊天最频繁的时间段：计算一天 小时内聊天最频繁的时间段。 计算聊天到最晚的日期及聊天内容：计算聊天至最晚（最接近凌晨 点）的日期及聊天内容。 计算发送与接受的消息量统计：计算成为好友迄今为止发送与接受的消息量统计。 计算聊天最频繁的关键词：统计关键词词频，可输入用户字典。 完整分析器代码如下： import re import pkuseg import pandas as pd from datetime import datetime from dateutil.parser import parse from collections import Counter class WeChatMessageAnalyser(object): def __init__(self, message): self.message = message def 计算成为好友的天数(self): # 根据本地聊天记录计算与目标用户第一次聊天迄今为止的天数。如果换过手机等原因造成聊天记录缺失等的情况会导致数据不准确 date = self.message.loc[, '发送时间'][:].split('-') date = f'&#;date[]&#;年&#;date[]&#;月&#;date[]&#;日' return &#; '成为好友的日期': date, '成为好友的天数': (datetime.now() - parse(self.message.loc[, '发送时间'])).days &#; def 计算聊天的情况(self): self.message['发送日期'] = self.message['发送时间'].apply(lambda x: x[:]) # 计算成为好友迄今为止当天至少发送过一条消息的天数 unique_day = list(set(self.message['发送日期'])) day_counter = Counter(day[:] for day in unique_day) result = &#;f'&#;k&#; 年聊天的天数': v for k, v in day_counter.items()&#; result['总计聊天的天数'] = len(unique_day) # 计算成为好友迄今为止当天发送消息数量最多的日期 message_day = self.message['发送日期'].to_list() frequent_day = Counter(message_day).most_common()[] result['聊天最频繁的日期'] = &#; '日期': frequent_day[], '消息数量': frequent_day[] &#; # 计算一天 小时内聊天最频繁的时间段 message_day_time = self.message['发送时间'].apply(lambda x: x[:]).to_list() frequent_day_time = Counter(message_day_time).most_common()[] result['聊天最频繁的时间'] = &#; '时间': frequent_day_time[], '消息数量': frequent_day_time[] &#; # 计算聊天至最晚（最接近凌晨 点）的日期及聊天内容 self.message['与 点相差的时间'] = self.message['发送时间'].apply(lambda x: (parse('::') - parse(x[:])).seconds / ) index = self.message['与 点相差的时间'].idxmin() result['聊天最晚的时间'] = &#; '日期': self.message.loc[index, '发送日期'], '发送时间': self.message.loc[index, '发送时间'][:], '发送内容': self.message.loc[index, '消息内容'] &#; return result def 计算消息量(self): # 计算成为好友迄今为止发送与接受的消息量统计 return &#; '总共消息': self.message.shape[], '收到消息': self.message[self.message['发送人'].notnull()].shape[], '发送消息': self.message[self.message['发送人'].isnull()].shape[] &#; def 计算关键词(self): # 统计关键词词频 content = '' for _, row in self.message.iterrows(): pattern = re.compile(r'[A-Za-z]', re.S) if res := re.findall(pattern, row['消息内容']): continue else: content = f'&#;content&#; &#;row["消息内容"]&#;' # 设置停用词 stop_words = [' ', '的', '了', '我', '是', '你', '好', '也', '就', '不', '吗', '个', '有', '还', '一', '都', '这', '在', '啊', '没', '要', '去', '太', '会', '那', '看', '哦', '说', '这个', '给', '很', '人', '天', '那个', '两', '他', '还是', '应该', '跟', '什么', ']', '她', '吧', '能', '对', '想', '然后', '[', '用', '做', '上', '时候', '！', '，', '得', '大', '但是', '自己', '下', '这样', '能', '着', '挺', '写', '一下', '？', '已经', '因为', '找', '小', '次', '和', '打', '呢', '好像', '可能', '呀', '感觉', '来', '没有', '嘛', '过', '行', '多', '啦', '把', '到', '再', '过', '柴]', '觉得', '这么', '先', '发'] # 设置用户字典 lexicon = ['笑死', '妹妹', '甜妹', '渣男', '预训练', '臭宝', '宝贝', '宝', '好滴', '牛蛙', '牛哇'] seg = pkuseg.pkuseg(user_dict=lexicon, model_name='web') seg_list = seg.cut(content) seg_list = [word for word in seg_list if word not in stop_words] counter = Counter(seg_list) return &#; '关键词': counter.most_common() &#; 高版本如果直接使用 pip install pkusge 失败的话，可以使用 GitHub 仓库来进行安装，具体原因参照相关 Issue。 pip install https:;;github.com;lancopku;pkuseg-python;archive;master.zip 未来升级方向 当前的分析脚本还有非常多不完善的地方，以及还有很多功能还没实现。 未来我会从以下方面来升级，但具体什么时候开始还不明确，先挖个坑。 一是增加分析的种类，例如分析最常用的表情包等。 二是增加分析的功能， 年年末美国德克萨斯大学"Language left behind on social media exposes the emotional and cognitive costs of a romantic breakup"的研究表明通过分析情侣的聊天记录，可以找到即将分手的证据。目前的分析脚本当中忽略了信息的时间连续性，为此现存的一个改进空间是通过分析连续的聊天记录，来计算聊天双方之间当前的“亲密度”，以此来预测追求成功的可能性，同样这个数值也会泛化为“健康度”，以修正双方之间的关系。 另外在选择分词工具的时候，我在 pkuseg、thulac、jieba 等之间纠结了很久。总结来看是目前缺乏一个比较好的方式可以快速评估各类分词工具的相关性能，我应该也会做下这方面的研究。

一般员工只有一个领导，而领导有非常多的下属、客户、平级等，要处理的消息体量也是员工的好多倍。因此与领导沟通的时候尽量要提高传达信息的准确性、高效性，降低领导消耗不必要的时间在猜测你发消息的真实意图上。 一般员工发给领导的消息类型有五类，大致如下： 消息类型 消息内容 可以附加的关键字 知悉 告诉领导：①你已经做了什么；②遇到了什么问题；③怎么解决的。让领导掌握进度，使之心里有数，这类消息一般不需要领导回复。 请知悉。 请示 关键问题需要请领导帮助判断和决策，必须等对方给明确指令才能继续。如果领导不能及时回复，可能是他实在太忙或者他需要时间考虑，这种情况下你需要自己有意识去推进工作的落地，而不能把锅甩给领导不及时回复。 请指示。 认可 当有事情需要判断的时候，你自觉有能力和权限做出判断，自行做了选择。告知领导是为了让领导对你的决定追加认可，如果领导有不同意见，会告知你立刻纠正。 如有其他意见，请告知。 提醒 当有事情你觉得领导可能忘记了或者非常重要的环节你觉得可能会出现问题，提醒领导，也是给自己降低风险。另外在参加会面或饭局上，领导和对方所达成的意见、做成的决定以及回去后要做的事情都可以整理一份活动备忘。 备忘 汇报 日常的日报、周报，阶段性工作成果交付。当领导发现里面的问题，会再让你修改调整。 以上内容交付，请审核。 ++因此只要不是决策和汇报结果的信息，在领导看来一般都是不重要的。++{.dot .warning} 另外，在传达消息的时候也需要注意一些方面： 给的信息没有明确目的，需要领导花很多时间在猜测你发消息的真实意图上 给领导发了一大堆的文字但最后没有说明白需要领导做什么，他会看不懂这是“请示”还是“汇报”。 因此除了内容简短，也需要一些关键词帮助领导快速理解消息类型。 缺乏关键内容，领导无法做决策 领导不知道详细的细节，缺乏核心的关键信息，领导无法做出决策。 请示的问题不符合应用的专业性 每个岗位都有自身的专业性，在专业领域可以自己完成判断，汇报中告诉领导理由和结果即可。 如果大事小事问个不停，除非领导非常耐心并且想培养你，否则大概率得不到回复。