前面已经对 “做好，而不是做完” 的问题进行了分析并提供了解决方案。

现在，我们来分析和总结 “项目月末统计及时完成率，出现人人达标的情况” 这一问题，希望能梳理出有价值的见解。

那就从源头开始，最开始，我们计划通过 “任务及时达成率” 来反映项目成员的工作情况，期望从中能发现一些问题并起到督促的作用。

打算通过一定的约束力、紧迫感，促使大家及时完成手头上的工作，为此制定的规则是：

1. 每个月未及时达标的任务不可超过 2 条，超过则需赞助部门经费 50 元。
2. 项目总负责人也不例外，同样需要赞助 50 元。

之所以这样设计，是因为能让项目总负责人与项目成员站在同一战线上，有助于避免形成对立，降低工作开展的阻力。

然而，历经一年有余，除了最开始有一两个项目成员未达标并缴纳了赞助费用外，此后很长时间都是人人达标的状态。

这从正态分布上来说，就显得不切实际。因为，很少有人能保证所有任务都及时完成。而且，月月如此。

为什么会出现这种情况呢？后来我分析了一下，原因是，我们对任务变更没有进行有效管控，插入需求的频率过高。为什么插入需求的频率会过高呢？因为项目业务需要根据客户反馈及时调整，第一时间响应客户需求。例如：

1. 突然有客户反馈紧急需求，希望快速响应；
2. 当前线上存在之前疏忽的功能细节，需要及时完善和补充；
3. 有客户询盘并表达合作意向，但对某个功能不太满意，需要及时给出优化方案以推进合作。

这些情况都会破坏之前制定好的项目计划和正在执行的任务。此时，无论是项目总负责人还是项目负责人，往往没有深究是否应该变更，而是默认允许变更。

只要产品、后端、前端、运维等任何一方出现需求问题或任务执行未及时达成，影响后续关联任务，就会出现任务变更的情况。

此时，很多人要么不具备分辨能力，要么贪图省事，不愿花心思去辨别是否真的应该允许变更，而是一概通过变更申请。

要解决这个问题，首先应从减少插入需求入手。但对于研发工作而言，如果完全不允许插入需求和任务变更，就显得过于僵硬和死板。市场在实时变化，响应时间的早晚可能导致截然不同的结果。因此，对于紧急、关键的需求，肯定要及时响应。

然而，如果总是允许插入需求，项目计划就容易失控。久而久之，项目成员会产生一种心态，反正最后都要变更计划，今天做完还是明天做完有什么区别呢？ 这种思想一旦萌生就很难消除，必须从根源上、从制度上解决。

项目负责人要引导项目成员主动思考是否可以通过其他方式解决延期风险，而不是通过变更影响后续任务。例如，可以提高事情优先级、提升工作效率、适当加班等。这样才能以目标为导向，锻炼应对不利情况的能力。

当然，如果插入的需求需要较长的开发周期，自然需要变更任务计划，并同步更新。这一观点我在之前的文章《项目需求变更时如何处理》中也提到过。坦白讲，就是要在 “插入需求” 和 “任务变更” 之间取得一个平衡点。

这实际上，还是回到了项目计划和里程碑的目的。**正如我在之前多篇文章中提到的，项目计划的目的是提供一个方向和时间节点，就像大海中的灯塔，引导大家朝着同一个方向前进。**如果张三往东走，李四往西走，王五往南走，工作就无法有效开展。

其次，项目负责人和项目成员在面对任务变更和各种突发事件时，应该充分发挥自己的智慧，制定有效的策略，就像行军打仗、摆兵布阵一样，明确先做什么、后做什么，如何争取资源，如何与其他成员和上级领导协调沟通，以确保在规定时间内达成目标。

如果某个项目成员反馈任务需要变更（例如前端因为后端接口问题导致任务受阻，申请延长任务时间），项目负责人需要了解事情的前因后果，而不是仅凭这个项目成员的一面之词。这就需要把相关项目成员（如后端）叫来一起沟通，了解问题所在及解决方案，可能出现的情况包括：

1. 后端接口没有问题，只是两人对需求的理解有误，这种情况不需要变更；
2. 后端接口有问题，但前端可以先开发界面，最后一两天再联调，这种情况不一定需要变更；
3. 后端接口真的有问题，但前端对延长时间的理解有误，可能存在故意拉长时间的情况；
4. 后端接口真的有问题，追溯起来是因为对需求的理解不一致，这种情况可以总结经验，下次在需求层面多做分解和沟通；
5. 后端接口真的有问题，前端提出的延长时间合理，符合常规理解，可以同意变更。

可以看到，有些任务只是看起来需要变更，有些任务只是看起来需要延长时间，实际上不一定如此。

归根结底，就是项目负责人在执行上出现了问题，为什么没有做到位呢？换位思考，我在带一个项目，里面有关系好的，关系不好的，关系好的呢，肯定是适当通融，关系不好的呢，不想得罪对方，这是人之常情。

每个人的角色不一样，所掌握的话语权和资源也不尽相同，面对同样的一个人或者一件事，在你看来，很容易处理，但其他人就会觉得很难，不同的立场，面对的阻力就会发生变化。

所以，要为项目负责人的执行背书，从源头梳理，制定《项目管理规章制度》，特别是任务变更的规定，然后，组织项目负责人讨论会议，对这份《项目管理规章制度》里的每一条规定，都反复讨论和敲定，有什么问题，当场提出来，现场就解决对方的顾虑和疑惑，能够达成共识。

只有达成共识，项目负责人执行起来就会从被动变为主动。 然后，再把这个《项目管理规章制度》在部门里发布和告知。

之后，项目负责人在执行的时候，就照着规定行事，不用顾及对方的感受，直接按规矩办事，实事求是，如果对方反应很激烈，那也不用项目负责人去解决，只需要把这种对立情绪向上反馈，由项目总负责人、部门去解决，不用有心理负担。

说到底，就是要给项目负责人做这个事情的正当性，而不是把压力完全由项目负责人承担，从源头贯彻理念，而不是处于模棱两可的状态，规定个12345，有问题解决问题，直到大家都没有异议，那么执行起来，就不会有那么多阻力。

谁没做到位，直接提出来，到底是什么原因，是制度的不完善，还是人的问题，制度不完善，继续完善制度，人的问题，就解决人的问题。

最后，要提的一点是，任务变更固然是一个问题，但这都是基于 “目标如期达成存在很大风险” 这个主要矛盾延伸的，先明白了这一点，再去抓任务变更这个事情，才不会舍本逐末。

前言

近期，在项目管理过程中，发现了两个值得深思的问题：

1. 有的同事任务做完了，但是暴露出很多显而易见的问题；
2. 项目月末统计及时完成率，出现人人达标的情况。

这两个问题，都在一定程度上反映出任务执行过程中、项目管理方面存在一些方法不对，或者制度漏洞，导致没有达成预期的效果。

现在，就基于这两个问题，好好分析以及给出对应的解决方案。

任务要做好，而不是做完

在会议室验收功能的时候，有个同事开发的功能模块，比如设备列表，暴露出很多问题。而且，还是一些很明显的问题：

1. 列表只是展示 10 条数据，没有滚动条，没有分页，导致后面的数据都看不到；
2. 点击删除按钮的时候，没有二次弹窗让用户确认，而是直接删除了，删除之后列表也没有更新。

这些虽然是小问题，但是表面风平浪静，实则暗流涌动，从中可以窥见在水面下的深层问题：

第一个就是没有用心在开发这个功能，这些都是很明显的问题，一些细节都是约定俗成，并不需要别人反复和你强调。

第二个就是换位思考，假设你是用户，在使用自己开发的功能，难道就没觉得有问题吗？

任务要做好，而不是做完，做完只是机械地执行，做好就需要动脑思考。

任务执行过程中，到底有没有对这个任务的方方面面了解清楚呢？

任务的背景是什么？为什么要做这个功能？什么人在用？到底会关注哪些细节？这个功能定好的实现方案，是否有更好的？现在遇到的这些问题，不解决的话，会留下什么隐患？

经过这样反复思考，如果觉得有问题，就应该及时反馈、暴露出来、及时沟通和处理。

而不要觉得，多一事不如少一事，差不多就行了，要是反馈的话，搞不好还增加工作量，我才不傻呢。

大部分人都会这样想，并没有什么问题，还是那句话，人之常情。

只是，要算一笔账的话，就会知道，很划不来。

因为，如果后面功能验收出了问题，除了影响你在工作上的口碑，还有可能会返工，那还是要增加工作量的啊。

那还不如，从一开始就做到位了。

当然，有人会说，要是每做一个事情，就经常反馈、提建议，让人觉得自己很难沟通，怎么办？

确实，有时候，要的就是执行命令，而不是习惯性抬杠。

但，我想说的是，要看从集体利益，还是个人利益的角度出发了，如果是集体利益，而不是私心，只要说的有道理，都是应该听取的。

凡事都可以商量着来。

完成比完美更重要

在 2024 年 8 月，3A 大作《黑神话：悟空》上线以来，全网一片好评，很多人评价，包括我，都说是划时代的作品，会在游戏的历史长河中，被铭记于丰碑之上。

但是，美中不足的是，后面两章，明显没有前面几章那么精细，赶工痕迹特别明显，特别是第六章，整一个大石敢当，实属无语，感觉有点敷衍了。

如果好好打磨，会更上一层楼。只是没有办法了，没那么多时间了，所以，就像主创冯骥说的：

“完成比完美更重要。”

在现实生活中，同样也是如此，很多坚持打卡的事情，早睡早起啊、坚持跑步啊、坚持控制饮食啊、坚持看书学习啊等等。

有一些人，比如我，会陷入完美主义的陷阱，比如要在草稿纸上写一段话，如果第一个字感觉没写好，就会撕掉重写，这个现在看来，是有问题的。

就好像人生，就好像打牌，不可能每一次开局都那么完美，只能是基于现有的牌，来不断调整策略、方法，然后能打赢。

之所以写一个字，没写好，就可以撕掉重写，无非就是撕掉一张纸的成本过低罢了，没有伤筋动骨，当然不会觉得有什么。

但是，无形之中，会养成这种较真的、不切实际的完美主义的思想，对于做好一些事情，是有害处的。

而这种思维，和上面提的 “做好，而不是做完” 的区别在于，是有先后顺序的，不同的阶段，不同的思维，不应一概而论。

最后

总之，不管是工作还是生活，我的结论是：

首先要有 “做好，而不是做完” 这个意识，等这个意识在你脑海中生根发芽，这是第一步。

很多事情，你确定自己是真的倾尽全力了，只能做到这一步了，再怎么责备你也没办法了，就算拿把刀架你脖子上，也不会更进一步了。

然后，这个时候，才可以说，完成比完美更重要，这是第二步。

这是一个递进的思维意识，而不是像二极管一样，非黑即白，本身就是要辩证地看待。

只是大部分人，没有第一步的意识，就妄想直接跳到第二步，来为自己的懈怠开脱。

所以最终还是要回到项目的完整的生命周期，对每一个环节，都要深入分析和研究，确保自己是真的做到位了。

下一篇，就说明一下完整的项目生命周期有哪些。

前言

在软件开发过程中，我们经常会遇到一些探索型的功能开发任务，就是那些没有做过、没有参考案例、甚至整个部门都没人有经验的功能开发。

这种任务往往充满了不确定性，也最容易出现问题。

书接上回

还记得之前张三和李四因为临时方案爆发的争论吗？

李四最近的开发工作一直都差强人意。

每次功能做完在会议上演示，总是会被挑出很多问题：功能实现丢三落四、界面样式不够美观、逻辑处理不够完善等等。

问题表现

这个问题到底出在哪里呢？是李四做事情不够用心吗？

经过一段时间的观察，我发现问题主要出在两个方面：

问题一：需求沟通不到位

首先是需求沟通的问题，很多时候，需求给出来的时候就存在可协商的空间，什么意思呢？就是需求描述不够明确，没有达到可量化的程度。

比如只说 “界面主题色是蓝色”，但没有给出具体的十六进制值。对于开发人员来说，蓝色可以是天蓝色、浅蓝色、粉蓝色，甚至深蓝色。

结果等开发完成了，你又不满意了，说想要的是深蓝色。这个时候功能都实现完了，找谁说理去？

问题二：探索型任务的特殊性

第二个原因是，李四的开发任务是探索型的任务，这类功能没有做过，甚至整个部门就他一个人开始做。

对于这种类型的任务，最容易出现的问题就是口头沟通的局限性，两个人在座位上你一句我一句地讨论功能实现、技术预研、技术框架、设计方案、函数封装等，都是口头沟通。

因为没有参考案例，沟通双方很容易出现 “我觉得我说清楚了，你觉得你听明白了” 的情况。

结果呢？

等功能开发出来，李四觉得自己已经做到位了，张三一看，觉得和之前沟通的完全不是一回事儿。

解决方案

面对这些问题，我们应该怎么办呢？

对策一：需求量化是基础

首先，需求必须可量化、可验证，这是解决问题的第一步。

颜色要给出具体的十六进制值，尺寸要给出具体的像素或百分比，功能要明确输入输出，性能要给出具体的指标要求。

所以说，模糊的需求必然导致模糊的结果。

对策二：方案文档不可少

其次，对于探索型任务，方案文档是关键。

李四应该在开始敲代码前，先在脑子里过一遍整个开发流程，找出可能存在的技术难点和争议点，针对每个难点提供 1-2 个解决方案，然后形成方案文档，文档应包括：做什么、为什么、怎么做、有什么问题、怎么解决、结论。

一来可以把思路梳理清楚，二来可以提前预知可能出现的问题，把风险在开发前就排除掉。

对策三：多人讨论是保障

最后，一个人拍脑袋决定的方案往往存在隐患，正确的做法是召集项目负责人、相关同事等一起过一遍方案文档，大家从不同角度提出意见和建议，明确解决方案和实现方式。

为什么要这么做？

因为每个人掌握的信息不同，多人讨论可以避免信息盲区，可以发现个人思考中忽略的问题，最重要的是，集体决策可以分摊责任，如果最后方案还是不太理想，也怪不到某一个人头上。

总结

说实话，探索性功能开发确实充满挑战，很多人会觉得这类型的任务，最大的难点是在技术层面的攻关，但实际上，只要做事情的方式不对，同样得不到自己满意的结果。

所以说，探索不代表可以随意，创新也需要规范。按照正确的流程和方法去做，你会发现，很多看似复杂的问题其实都有章可循。

前言

说实话，这个事情真的太常见了。在项目开发过程中，时间紧、任务重，大家都想赶紧把功能做出来，这种时候往往就容易出现一些临时方案。

但是呢，临时方案这个东西，用好了是救急，用不好就是埋雷。

今天就给大家分享一个真实发生的案例，看看在项目紧急情况下，我们到底应该怎么处理。

事情是这样的

李四最近在赶一个项目的进度。说实话，时间真的太紧了，按照正常的开发流程，根本来不及完成所有功能。于是呢，李四就动了个心思，用了一些临时的解决方案。

比如说，有些条件判断、有些循环逻辑，本来应该是根据接口返回的数值来动态设置的，但是为了赶时间，李四直接把这些值硬编码写死了。这样做的好处是，功能马上就能跑起来，测试也能顺利通过。

但是呢，这种做法在功能、代码规范上面肯定是有问题的。就像你盖房子，本来应该用钢筋混凝土浇筑的柱子，你用了几根木头临时支撑一下，虽然看起来也能立起来，但是，随着楼面东西越来越多，顶不住是时间问题。

矛盾爆发

项目负责人张三在重构代码的时候，就发现了这个问题。说实话，张三当时就火了，在项目进度例会上直接就和李四争论起来了。

从张三的角度来说，这种低级错误真的无法理解。代码规范这种约定俗成的东西，难道还需要一遍一遍地强调吗？如果每个人都这样随意修改代码，那项目质量怎么保证？

从李四的角度来说，他觉得很委屈。当时项目时间那么紧张，我想出了临时方案，至少保证了功能按时上线，自己不但没被表扬，反而被批评，心里真的很不好受。

双方都觉得自己有道理，看起来这个问题真的很无解。

张三的问题

说实话，张三作为项目负责人，也有他的责任。

首先，代码审核没有做到位。这种明显的硬编码问题，应该在第一时间就发现，而不是等到项目上线后才提出来。

其次，在李四解释了原因之后，张三不应该过多指责，而是应该给出建设性的建议，帮助李四改进工作方式，避免下次再出现类似的问题。

李四的问题

李四的临时方案本身并没有太大问题，毕竟在紧急情况下，有时候确实需要一些特殊手段。

但是呢，他的处理方式有问题。在使用临时方案之后，他应该有更好的选择：

方案一：主动告知

在群里或者邮件中告知团队成员，说明自己使用了临时方案，并且承诺在时间节点过后会进行完善。这样既能保证项目进度，又能让团队成员了解情况。

方案二：默默完善

如果不想让太多人知道，至少在时间节点过后，自己要记得把这些临时方案替换成正式的解决方案。

但是很遗憾，李四两个选择都没有做。所以才导致了后来的争执。

总结

说实话，这个案例虽然看起来很简单，但背后反映的是项目管理中的一个普遍问题。

在项目开发中，我们经常会遇到各种紧急情况，这时候就需要我们有灵活的应变能力。

但是，灵活不等于随意，我们需要在保证项目进度的同时，也要保证项目质量。

最重要的是，遇到问题不要互相指责，而是要互相理解，共同寻找解决方案。

只有这样，才能让团队变得更强大，项目变得更成功。

记住，临时方案可以用，但一定要使用正确的方法，想出一个好点子，并不等于就解决了问题，要在执行层面也做到位，那才是真正的解决了问题，而不是出现新的问题。

在多项目管理过程中，会遇到这样一个问题：有的项目人比较多，有的项目人比较少。

比如 A 项目有张三、李四、王五等 4 个人，B 项目则只有赵六、王七 2 个人。

这种情况下，通常会考虑从 A 项目调一个人去支持 B 项目。

不过在做这个事情之前，得先想明白几个问题：我们为什么要调一个人去支持 B 项目？调谁合适？为什么是他？做这个事情的根本目的又是什么？

如果不加深究，很容易得出答案：因为 A 项目人多，B 项目人少，适当匀一下，显得更为合理。

但实际上，人员调配的真正目的是优化资源结构，把钱花在刀刃上，实现利益最大化。

从这个角度出发，你会发现事实可能和之前预想的不一样：

A 项目有 4 个人，B 项目有 2 个人，虽然 B 项目的事情好像更多更杂，表面看更应该加人。

但结合项目对部门业绩发展的重要性来评估资源投入就会清楚，A 项目是行业项目，B 项目只是对内的、满足公司自身需求的项目。

显然，这两个项目对部门发展的重要性是不一样的，A 项目很明显更重要。

所以，即便 A 项目人多，B 项目人少又事情多，也不应该从 A 项目调离人员。

正确的做法是加快 A 项目的功能迭代，同时对 B 项目的功能进行筛选，先做高优先级的，低优先级的就推迟开发。

除此之外，是否调离人员，还需要评估人员的重要性。

结合实际情况，核心成员就该投入到重要性高的项目，再结合对他的发展期望，调整到利于他发展的项目中。这样一来，他的能力能得到提升，也容易做出更好的业绩，从而激励到自身。

还有一点，要尽量不过多变动当前人员负责的业务，不让他们掺杂过多业务，一来精力太分散，容易变得低效；二来人员掺杂过多业务，会加大管理难度，影响多项目推进。

所以在我看来，多项目管理中的人员调配，可以通过这几个来判断：

1. 根据项目对部门业务发展的重要性，评估投入资源。重要性高的项目人多，重要性低的项目人少。重要性低的项目事情多，就适当慢下来，按优先级处理。
2. 依据成员的重要性进行调配，核心成员投入到重要性高的项目，利于其发展、做出业绩，实现自我激励。
3. 避免人员参与过多业务，以最小力度调整人员，保持业务的稳定性。

在之前的文章《37-AI 时代，代码评审方式究竟怎样优化？关键要点有哪些？》中已经提到，AI 代码评审基于 Code-Review-GPT-Gitlab 进行使用，因为这个开源库包含评分机制、问题反馈、修改建议和修正后的代码等部分，比较符合我的预期。

在使用了一段时间之后，考虑到要基于流程规范来操作，项目成员提交代码后，最好能看到 AI 代码评审报告，然后根据反馈的问题修改后再提交代码。

但怎样才算修改好了呢？这就需要制定一个标准，比如将 90 分作为评分标准，每个分支提交到仓库时，都需要达到 90 分以上，代码才能入库。

然而，以 90 分作为标准执行一段时间后，有同事反馈这个标准可能不太合理。因为通过 AI 代码评审，出现了一些幻觉问题，这会导致评分不准确，使得 90 分的要求难以达成。

幻觉问题一直是当下 AI 面临的较大难题，在我看来，这并非完全是由于私有化部署时使用的模型小、性能不够强大所致，很多市面上很强大的 AI 工具，同样存在这个问题。

加上，其实提交的代码只是变更部分，AI 代码评审时，只会对 diff 部分进行检查，这就会存在对业务认知不完整的问题，因为项目中一个完整的业务功能，并不一定就在一个文件里完整呈现的。

因此，流程调整为采用 “AI 预评审 + 人工复核” 的方式，依旧按照 90 分的评分要求，具体问题具体分析。如果出现幻觉问题，则灵活处理，而非因噎废食。

关于幻觉问题，一方面可以考虑升级配置，比如购买性能更好的显卡；另一方面只能等待行业发展，以有效解决 AI 幻觉问题。

在《当 99% 可靠性是及格线，我们如何为大模型装上工程 “安全带”？》这篇文章中，提到了对幻觉问题的探索和解决，后续发展情况仍需持续关注：

在 2025 世界人工智能大会（WAIC）上，蚂蚁集团旗下蚂蚁密算宣布对外开源高阶程序（High-Order Program）大模型可信应用技术框架，通过外部化控制与核验，为构建可信、可控、可维护的大模型应用提供了务实的参考标准。

除此之外，项目成员在提交代码之前，需要在 VSCode 中使用豆包 AI 插件，对所有改动的文件进行检查。

这样至少能在提交代码、进行分支合并之前，在本地提前暴露问题，无需等到提交代码后再用 AI 进行代码评审，从而简化大量工作。

不过，在本地使用豆包 AI 插件检查改动的代码时，无需过度检查。因为我发现，每次提问都会得到问题反馈，即便复制它建议的代码去询问，仍然会收到很多建议，这会让人感觉没完没了。

毕竟代码的写法、规范并非只有一套，功能的实现细节也千差万别，并非绝对统一。所以，只需检查一次，把特别明显的问题改掉即可，若是吹毛求疵，只会陷入无尽的循环。

至此，我之前认为代码评审完全可以由 AI 来完成并让整个流程顺畅运转的想法，显然有些激进了。

以当前情况来看，无论 AI 代码评审能达到何种程度，即便幻觉问题能得到有效解决，也不应该完全由 AI 来承担这项工作。

采用 “本地 AI 插件检查 + AI 预评审 + 人工复核” 这三个步骤，或许更为合理。

一般而言，项目的任务计划都是由项目负责人制定的，其中需要明确每一条任务的优先级、开发周期和开发负责人。

但是，有些项目负责人的技术背景是前端，有的是后端，还有的是终端。

这就会遇到一个问题：他们怎么去制定其他技术栈成员的任务并进行验收？

在此之前，我们默认都是由项目负责人完成这些工作的。比如，项目负责人张三是前端出身，现在他要给后端的李四制定开发任务。

通常的做法是，张三会和李四沟通要开发的功能，然后由李四给出功能开发所需的时间，接着张三填写任务时间，任务安排便完成了。

这里就存在可操作的空间，因为李四给出的时间没有第二人进行审核。而张三是前端出身，并不具备审核后端任务时间的能力。如此一来，任务安排就完全取决于李四是否厚道了。

我们一直反复强调人性，可依赖人性做事情，迟早会出问题。

今天李四心情好，可能就凭良心给出合理时间；哪天他心情不好，或许就会把任务时间拉长，好趁机摸鱼。

写到这里，我想起 2020 年的几场培训，培训老师说过的一句话让我印象深刻：

“如果你不想吃亏的话，要以最坏的情况去判断你的员工。”

即便李四为人厚道、兢兢业业，不会偷奸耍滑，那你能保证王五、赵六也不会这样吗？

你真的有时间和精力去仔细分析每个人，或者持续观察他们的一言一行吗？

那样的话，你自己就不用干活了。

所以，还是要回归到流程规范上来，不回避任何问题，把它暴露在阳光下，通过望闻问切，仔细分析原因和我们的诉求。

接着就是大家沟通达成共识，用规定来约束，用流程从源头解决问题。

那接下来，如何从流程规范入手解决这个问题呢？

这要从我们的目的出发，我们的目的是对任务进行有效制定、跟进和验收，而不是流于形式。

既然要 “有效”，就要实事求是，杜绝虚假。而规避虚假的办法，就是专业的事情交给专业的人。

现实情况是，项目负责人并非全能全知，所以可以把这部分工作交给对应的同事来执行，引入技术端负责人的角色。

各项目可根据实际情况，设立前端负责人、后端负责人和终端负责人。他们的职责是协助项目负责人明确对应技术端任务的开发所需时间，跟进任务进展，并负责验收。

整个项目的人员架构就变成：项目成员 - 技术端负责人 - 项目负责人。

那么，项目成员的任务申请时间变更，由谁来审核呢？

本来我觉得，项目的全部任务本应由项目负责人审核，而技术端负责人已经对开发周期（即天数）进行了把关，项目负责人依据这一点判断即可。

但技术端负责人需要覆盖三个关键环节：制定、跟进和验收。变更属于跟进部分，如果这一环节改由项目负责人执行，整个任务的生命周期就无法形成闭环了。

在项目管理系统中，曾经的设计思路是：项目成员的任务时间变更，审核人都是项目负责人。

如果现在引入端负责人的角色，那么技术端成员的任务时间变更就应由对应的技术端负责人审核，而技术端负责人的任务变更则由项目负责人审核。

至此，我认为可以解决项目负责人如何制定、跟进和验收不同技术栈成员任务的问题。

在这篇文章《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中，已经讲明了当前项目过进度的方式：要求各项目成员到前面的座位来，把上两周以及下两周要做的工作情况汇报一下。

但是，在执行大半年的时间里，发现有的项目成员在会议上汇报自己任务情况时，只是简单说明内容，两三句话就说完了。

怎么引导项目成员更多地反馈工作中的情况，而不是让会议变成形式化、流水账式的无意义会议呢？

我反复思考了一下，项目成员为什么不想说那么多呢？这个点其实在《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中也有过分析，这里就不再过多赘述了，无外乎就是多一事不如少一事 —— 只要我说得越少，问题也就越少。

不过，我也能想到其他的可能，比如 “就是线上修复了几个 Bug，没有什么可说的”“就是正常的功能开发，没什么可说的”“我做的是其他项目的，跟其他人关系不大，没什么可说的”。

关键点就在于 “没有什么可说的”。

为什么没有什么可说的呢？

难道每个人在开发的过程中，真的一点问题都没有吗？

每一条任务的制定，都包含需求、方案、研发、技术笔记和验收等多个环节。

这几个环节中，总该有可以说的点吧？

但是，为什么没有什么可说的呢？原因就是没有做好相关的工作。

很多需求只是一句话，或者口头说一下；很多方案也只是当面沟通一下，沟通好就完事了，没有整理成方案文档记录下来。

至于研发过程中遇到的问题，有些 Bug 在没解决之前是 Bug，解决之后恍然大悟，就会觉得问题不值一提 “原来如此，我居然会犯这个低级错误？” 所以，也就觉得没有什么值得总结和记录的了。

还有技术笔记，写这个是要花时间的，完全看每个人是否自觉去做，那真的太难了，大多数人的想法是，还不如省下这些时间去做下一条任务。

甚至，有些人会觉得，这种知识点还要写技术笔记，会不会让人觉得自己技术很菜、水平很低，还不如不写。

任何问题都要透过表象抓住本质，一般这种问题，只是从人身上入手，效果不会很理想的，你可以口头要求对方一次两次，过段时间，只要你稍微疏忽了，对方也就松懈了，所以，还是要从源头去解决，也就是要从流程入手、从规章制度入手，经过沟通讨论，定下一些规定，让大家一起遵守就好。

比如，项目负责人在制定任务的时候，需要把任务要求写清楚，任务要先整理详细的需求文档、解决方案和技术笔记。

之前可能只是 1 条 “支持 10 万台设备接入”的开发任务，里面涵盖着想让成员写各种文档的期望，现在这个事情直接挑明了，拆分成 3 条任务：

1. 支持 10 万台设备接入需求文档
2. 支持 10 万台设备接入解决方案
3. XXX 框架基本使用、疑难问题解决等技术笔记

这样，就把之前依赖项目成员自觉的工作，变成硬性要求，以任务形式下达，让工作从无序变成有序，从无条理变为有章法。

在这个基础上，项目进度会议中项目成员汇报进度时，就可以把这些资料都过一遍，然后再进行验收，应该能有效解决会议流水账的问题。

背景

在项目开发过程中，代码评审还是很重要的，主要是为了解决代码规范、功能开发方式、相互学习等问题，代码是否符合规范，关系到项目成员协作的问题。

如果写出来的代码风格五花八门，那么，在沟通交流上面，就额外增加了难度，而这是完全没有必要的。

除此之外，上面说到的功能开发方式问题，意思就是，每个人都有可能是孤岛，一个人的想法可能会有缺陷，如果多个人沟通以及探讨，相互学习，有可能会从不同视角发现潜在的问题。

人工代码评审

一直以来，我们要做项目代码评审，通常都是有这几种方式，比如项目组成员交叉验收各自的功能代码，然后把问题整理到文档，再一起组织代码评审会议，把问题都过一遍，然后安排任务去调整。一方面解决了代码存在的问题，另一方面通过深入交流，大家相互学习。

还有，就是在 GitLab 代码合并阶段，项目成员发起功能分支合并至主分支，由项目负责人去审查项目成员提交的代码分支。

如果没有问题，则合并到主分支；如果有问题，则反馈给项目成员。待项目成员修复完成再次发起分支代码合并，然后，项目负责人确认之后，合并到主分支。这个应该就是常规的代码评审流程。

但是，随着团队的发展以及对降本增效的要求，开始着手去研究，团队中哪些工作是有可优化的空间？

项目负责人承担的工作事务越来越多，怎么去有效简化无意义的工作，成为了当前亟需解决的问题。

SonarQube

基于上面降本增效的目的，我之前调研了 SonarQube 代码检测工具。

它基本支持了市面上的 Java、Go、JavaScript、TypeScript 等十多种语言，并提供几千条代码规则，用于代码规范检查、代码优化提示等代码质量问题。

支持结合 GitLab 的 CI/CD 做流水线事件中断，方便代码提交人员，自行去查看反馈的问题。

并且，提供 SonarLint 这个 IDE 插件，在代码编写时，就反馈存在的问题，并给出修改建议。

后来为了减少项目负责人的代码评审工作，整个部门的项目，就都接入了 SonarQube 来实现代码问题检查工作。

在使用 SonarQube 的过程中，给我印象深刻的主要有以下几点：

如果一个历史项目要接入使用 SonarQube 工具去检查代码，这个时候，势必会有很多问题反馈，比如可能 2000 个问题，这个时候，是否要立马安排时间去解决呢？

立马安排的话，就需要比较多的时间了，如果不立马安排解决的话，这些问题应该什么时候去解决呢？

SonarQube 提出了一个 “新代码” 的概念了，意思就是，可以不立即就把这 2000 个问题修复掉，而是在项目功能迭代的过程中，逐步把有问题的代码修复掉。

因为项目功能有迭代，意味着，这部分代码就需要去改动，趁此机会，刚好同步解决掉遗留的代码问题，慢慢地，遗留的 2000 个问题就会以这种方式解决掉。

至于哪些没有迭代的，说明功能已经很稳定了，或者功能不重要，那优先级也相对更低了。

SonarQube 官网文档的这篇说明 《Clean as You Code》 提出的这个方法论，我觉得理念还是很不错的：

SonarQube 旨在通过帮助您（开发人员）确保您提交到项目中的每个代码更改都没有问题，从而确保高代码质量和安全性。通过始终提交干净的代码，您可以逐步提高项目的整体质量。我们称这种方法为“Clean as You Code”。

Clean as You Code 的核心思想是将注意力和精力集中在新代码上。在您进行功能和改进时，SonarQube 会在每次新提交时分析您的代码，并在任何代码质量问题和安全问题上提醒您。然后，您可以立即解决这些问题，并确保添加到项目中的所有新代码始终是干净的。

传统的代码质量方法通常强调在每个开发周期结束时有一个单独的审查阶段，在这个阶段发现并解决质量问题。在这个过程中有一个单独的阶段，通常由不同的团队进行，可能会导致问题，因为积累的技术债务量可能变得难以管理，而责任的划分意味着质量问题可能会从裂缝中消失。

Clean as You Code 避免了这些陷阱。它阐明了代码质量和代码安全性是您作为开发人员的责任。它还通过使其成为日常工作节奏的一部分，使代码质量的维护保持可控。

另一个让我印象深刻的是 SonarQube 代码检测结合 CI/CD 阻断流水线事件的功能，真正去应用了，才真正感受到这个功能的好处在哪里，比如前端项目，要合并分支并自动化发布到线上，这个时候，如果 SonarQube 检测到代码问题，就会中断发布流程，需要解决掉反馈的代码问题，才可以正常发布到线上，从而简化了项目负责人的代码评审工作。

但是，SonarQube 只是静态的代码检查，固定好规则，然后它就去检查，只是一个相对 “死板” 的检查方式，无法结合代码上下文，去提出更为深层次的问题，比如功能的实现方式，代码性能优化的写法建议等等，还是要人工去做这部分的工作。

AI 代码评审

随着 AI 大模型的爆发，我之前设想的通过 AI 去做代码评审的事情，开始可以去落实。

早在选定 SonarQube 作为代码评审检查工具，从而减少项目负责人的工作之时，我就设想能否通过 ChatGPT 来完成这个事情，这个是之前写的结论。

借助 ChatGPT，利用 GitLab 获取到合并请求内容并发送到 ChatGPT 完成代码审查, 并将审查结果提交评论至修改行。当前环境下，该做法可能有点激进，存在法律和安全方面的风险。时机未成熟。

当时是没想明白，怎么解决掉代码安全的问题，因为我们项目的代码，总不能接入公网吧，而且，GhatGPT 还是外网，还要翻墙，还要购买服务等等问题，就此作罢了。

可现在完全不同了，AI 大模型发展迅速，日新月变，全面开花。在这样的背景下，我知道时机应该成熟了。

我的想法是，能够通过 AI 把项目成员自己提交的代码分支，做一次代码评审，然后将代码中存在的问题反馈给项目成员，项目成员自行根据建议修复之后，再次推送分支，这一个过程完全不需要项目负责人参与。

项目负责人只需要在最后一步，合并分支代码的时候，看下 AI 代码评审报告，确定各方面评价满足预期，则合并分支代码，从而简化项目负责人的工作。

后来通过多次调研，发现 Code-Review-GPT-Gitlab 这个项目比较符合预期，有评分、代码亮点、代码问题、修改建议、修改后的版本等等，就开始着手验证和执行。

不过，当前还有一个点要解决，因为这个评论是需要合并分支代码之后，才可以检查 diff 部分的代码，然后结合上下文，给出代码检查报告的，那么就没有做到阻断事件的效果了。

之前，总认为把这个约束放到人身上，大家自行去看合并后的分支报告就行了，不做强制要求。

但是，这种事情，是没办法去考验人性的，要大家自觉去做，可能一开始还行，时间久了，有什么突发事情、工作进度受阻、准备下班了等等原因，就开始趋利避害了。这个是正常的，所以，只能从源头去解决，那就是完善这个阻断事件的功能。

总结

上面就是代码评审的方式以及演变过程，不过，在实际应用中，AI 代码评审也不是万能的，除非你能把它喂到覆盖你需求的程度，但是，现阶段还是比较难的。

所以，最好还是结合代码评审会议去完善代码评审这个事情，比如一个季度开一次，都看看项目的代码，兴许可以发现一些 AI 代码评审覆盖不到的、团队特有的代码规范、功能实现方式可优化等问题。

在当下降本增效的浪潮之下，强调团队的产出，基于这个目的，各个工作环节，都要深入去分析，是否存在可以优化的要点，通过结合实际情况的分析与论证，比如，先以一个项目作为试点，看看大家的反馈如何，没有什么问题，再全面推进，再加以实施，更能做成一件事情，避免弄得载声怨道，事与愿违。

对于程序员来说，技术网站还是很多的，我可以列举出来很多个，比如 CSDN，简书，掘金，博客园，开源中国，力扣，InfoQ、思否等。

早些年我是逛开源中国的，后来，发现了 CSDN，就迁移到 CSDN 了，但是，CSDN 广告真的太恐怖了，不到万不得已，我是绝对不想打开的，因为真的受不了这个广告，

简书出来之后，就转到简书了，继续写一些技术文章，内容主要是遇到的问题分析、积累的一些解决方案等，但是，后来简书真的吃相越来越难看了。

满屏的广告不说，文章最后本来应该就是评论区的，硬是要在这个小地方塞进去了十几篇推荐的文章，每次看到最后，想看下评论区，都要把窗口拖下去很久才行。

文章左侧还有一个 APP 二维码，一直闪烁，我都不清楚简书的产品经理脑袋里装的都是什么，完全没有脑子，阅读文章内容时，注意力老是被这个二维码的动效干扰，人都变得很烦躁，猜测这个功能的目的，是为了推流下载简书 APP，但是，在实现这个目的过程中，采用了简答粗暴的方式，真的一点脑子都没有。

再加上文章详情页，右侧推荐的文章都是那种 “庞太师与我娘亲二三事” 之类的文章，我当时就觉得受够了，简书死不足惜。

再加上 2017 年饱醉豚无端抹黑程序员事件，彻底激了众怒了，所以，就转到博客园了。

博客园的优点其实很多的，比如整个网站没什么广告，然后个人博客风格还可以自定义，编辑器也过得去，但是不知道什么原因，没有继续在上面发发技术文章，或者平时逛逛，基本上得很少用，只能是我自己的选择问题了。

最后，就迁移到极客时间推出的 InfoQ 网站了，在上面写了几篇技术文章，感觉这个网站没那么多广告，这点还是很不错的，然后不管是编辑器、个人主页都很清爽，但说实话人气确实不咋地。而且，很多文章都是太资讯、行业化了？一看就不是程序员平时写的东西。

后面，迁移到掘金了，在掘金应该是比较久的了，之前一直也是不错的，但是，最近感觉掘金的广告也变多了起来，可能是有 KPI 绩效的要求，每次打开，都要顶部撑开一个大位置，用来放广告，然后再收缩起来，不知道这个动画效果是不是没有处理好的原因，每次都感觉卡顿，然后莫名其妙的。

这一点也是很烦的。以致有人写了文章吐槽这个，有意思的是，这篇文章还上掘金热搜榜了，也不知道掘金小编是怎么审核通过的，还是有格局的，亦或是早就看不惯了，迫于上级要求，只能通过这个方式表达不满了。

然后我现在发文，是掘金和公众号一起，先是在公众号发完，然后同步到掘金，然后再同步到个人博客。这一流程基本沿用至今。

上面就是一些使用技术网站的背景，从上面的描述中，可以看到，其实，自己是疯狂吐槽简书的，挑的问题也最多，那是因为很喜欢简书的，至少一开始真的很惊艳，干干净净，简简单单的，但是现在已经全都变了。

但是，任何事情都要结合实际情况来分析，从不同的角度去看，每个人都有不一样的难处。

用户觉得广告太多，阅读体验差，网站觉得我要运营，要买服务器，要花钱的，不搞点收益，怎么活下去，你们白嫖了还到处抱怨？

要解决这个问题，还是在于用不用。

如果不用那就眼不见为净，没有任何烦恼，如果要用，单纯去指责网站意义不大，愤怒、指责、抱怨只是短暂发泄下负面的情绪，没办法彻底解决掉这个问题。因为赚钱嘛，不寒碜。

同时，如果技术网站，要推行类似 Medium 的付费模式。我估计死得更快，我赏脸在你这个破网站上发表文章，没找你要稿费都不错了，我看点别人的文章还要收费？

毕竟，我们没有这个付费的传统习惯，从最初的音乐、电影、单机游戏和办公软件之类的，能用盗版用盗版，这个怎么说呢，不去评判好坏了。

我也有理由说的！现在的视频网站，都什么操作？开通会员还得看广告，这不是坑人吗？会员等级还分三六九等，VIP分成了好几个档次，简直是要把用户的钱包榨干！更夸张的是，同一份资源，换个设备看还要多花钱，这也太离谱了吧！还有那些限制分辨率、限制投屏的操作，这不是欺负人吗？我可是乖乖交了会员费的好人，怎么就要被这样对待？好人就该被枪指着是吧！你们既然这样，那别怪我去找盗版了！脸都不要了！

很多人都有过上面的经历，所以，才没办法单纯评判好坏。我们不是没有这个付费的传统习惯，我们只会为值得的东西买单。

再加上 Windows 之前之所以能在中国打开市场，并且，占据大部分市场份额，就是因为它默许了 Windows 盗版横行。而且，在开源这一块也是一样，要想让我们付费和打赏，还是太难了，我看尤雨溪入驻国内 “爱发电” 平台，想要扩宽国内的 Vue 赞助渠道，不会有几个钢镚的。

所以，回归正传，怎么解决这个技术网站的阅读体验问题呢？

只能是折中的手段，那就是通过安装广告拦截插件来解决了。甚至定位并拦截哪些广告区域，通过这个方式，后面再浏览各大技术网站时，已经干净很多了。

至此，现在看技术博文，就是在掘金比较多了，偶尔看下 InfoQ 上的文章，因为有一些资讯或者访谈类的文章，其实还是不错的。

然后，因为之前的 ARTS 打卡活动，也经常要看下力扣的，现在这个打卡活动结束了，时不时也去看下日常的讨论，还有就是思否，这种问答式的模式其实还是很不错的，只是感觉有些时候，感兴趣的话题不是很多。

现在，基本不会怎么改变这个习惯了吧。

2020 年 7 月，因为第一次使用 Flutter 来开发项目，所以研究后发现，如果要使用 iPhone 真机调试，需要在 XCode 上运行。但当时苹果手机系统版本是 13.6，而 XCode 是 11.3.1，所以运行时出现如下提示：

This iPhone 11 is running iOS 13.6 (17G68), which may not be supported by this version of Xcode. An updated version of Xcode may be found on the App Store or at developer.apple.com.

也就是说，当前 XCode 版本过低，不支持当前手机的版本。然而，App Store 没有 XCode 升级提示，我便以为 XCode 还没有新版本发布。那么，要解决这个问题，当下就是想办法让其支持 13.6 版本的手机。

于是我在百度上搜索，发现 CSDN 有很多 iOS 13.6 真机调试包可以下载，但需要积分。由于 CSDN 广告太多，我早已反感，之前攒的积分也花光了，所以没办法下载。

当时我就想，为什么别人能弄到这个 13.6 真机调试包，总不可能都是自己做出来的吧。反正我看到 CSDN 上面到处都是，都标着很高的积分，心里暗自吐槽，这尼玛是不是都你抄我、我抄你的啊。好多东西无非就是信息差，提前知道了，或者在外网看了相关讯息，拿到别人的东西，就拿到国内来卖。

如果是自己辛辛苦苦弄出来的，也认了，毕竟是自己的劳动成果。但如果是拿别人的东西来唬人，那性质就不是一样的了。

反正很长一段时间里，我使用百度搜索一些问题的解决方案，不下五六篇都是一模一样的，我都不知道谁才是原创。或者本来答案就是 Stack Overflow 上面的，只不过翻译了一下而已，也不给个链接或者标注下，真是糟糕透了。

基于这个原因，我用必应搜索，搜索到的结果很干净，没有那么多杂七杂八的东西（比如满屏的广告）干扰定位问题答案。

比如搜索 XCode 13.6 相关内容，我慢慢找，就发现了这个问题：Xcode 11.5 doesn’t support iOS 13.6?，没错，Stack Overflow 上面就有答案。

Stack Overflow 除了访问很慢，其它没什么问题。而且在这个问答里，我找到了 13.6 真机调试包下载的地方，也就是 Github 上面的iPhoneOSDeviceSupport。我看了这个项目，是好几年前的了，甚至 14.0 的真机调试包都有提供。所以我严重怀疑 CSDN 上面那些就是抄的这里的，从这里下载后，自己标上积分供人下载。

所以，求知要到知识的源头去。也正因如此，我现在都用必应搜索，或者到 Stack Overflow 找问题解决方案。现在国内的这个环境，真是无力吐槽。

但是，说回到现在 2025 年，因为 AI 的爆发，搜索引擎受到了很大冲击。我感觉 Stack Overflow 基本快没什么人用了，因为遇到问题，第一个想法肯定是先问 AI，最多对不确定的信息再三确认下。毕竟，AI 给的答案不一定都对，需要进一步甄别。但相比之前传统查找解决问题的方式，效率各方面都不可同日而语。

DeepSeek 过年时爆火，现在全球整个 AI 市场，各大模型感觉都不知道升级了多少代，速度真的太快了。比如，最近 360 纳米 AI 又搞出一个超级智能体，也是在进一步探索可能性。

在这样的时代背景下，上面存在的问题，将进一步被其他方式解决，比如使用 AI 来查找问题答案。那么不管各大技术网站、博文质量如何，你都不用操心这些了，最终能去伪存真、化繁为简，直接给你答案。

总之，还是那句话，拥抱变化，淘汰人的不是 AI，而是使用 AI 的人。这句话跟《浪客剑心》的那句台词有异曲同工之处：

“创造时代的并不是刀，而是使用刀的人。”

1. 精力就是做事情的能力。包括体能、情感、思维、意志四个方面。
2. 今天我们要分析一条革命性的理论——管理精力，而非时间，才是是高效表现的基础。
3. 我们与运动员合作成功的秘诀并非在于技巧或战略。人们通常认为，才华横溢的人面对挑战时只要配备足够技能，就能够发挥出最好的水平。从我们的经验来看却并非如此。精力才是完全点燃才华和技能的正解。
4. 人们极少考虑我们消耗了多少精力储备，总是想当然地认为它能够随用随取。事实上，不断增长的需求逐步耗尽了我们的精力储备——尤其由于我们不对随着年龄出现的能力减退做任何补救。通过全方位的训练，我们可以极大地减缓身体和思维的衰退，并切实地深化情感和精神的能力，直至生命的尽头。
5. 如果某件事你每次做之前都需要思考，你很可能不会长久坚持这件事。
6. 通过运动和休息交替进行可以最大限度提高表现，这条理论最初由斐洛斯特拉图斯提出，他是古希腊运动员训练手册的编撰者。随着训练强度增大、对运动员要求提高，能力的恢复和补偿程度也必然相应增加，否则，运动员的表现将会逐渐下降。
7. 持续健身能带来身心改善，但若停止一周，曾经的改善就会大幅退步，只要停止4周，这种改善就会完全消失。
8. 自然本身存在规律的脉动，在活跃和休息之间有节奏、波浪形地交替。涨潮退潮，四季更替，日升日落，不胜枚举。同理，所有有机体都遵从恒久的节奏——鸟类迁徙，熊类冬眠，松鼠收集坚果，鱼儿产卵，生物的活动都有一定的间歇。
9. 张弛有度是全情投入、维持机能和保持健康的关键。相反，单线化运动最终会导致机能障碍和死亡。想象一幅健康的脑电图或心电图是如何起伏波动的，再想象它的反面，是不是一条直线？
10. 我拥有在任何情况下高度集中的能力，摒弃那些让我分心的事物。然而，我无法在打完18洞的过程里始终集中精力，即便可以，我怀疑我的思维也会过度损耗，思维变得混沌，最终还是无法推杆入洞。因而我制订了一套步骤，帮助我完成从高度集中到惬意放松的过渡，反之亦然。
11. 从最实用的角度看，全情投入的能力取决于周期性休息的能力。
12. 科技的进步永不止息。它本该帮我们更好地感知周围的事物，然而却成为现实中导致我们无法全情投入的祸因。
13. 《心流》的作者、心理学家米哈里·契克森米哈写道，“最佳时刻，往往发生在一个人的身心为了达成艰难目标或完成有意义的事情，而自愿达到极限的时候。”
14. 我们还发现，喝水或许是最常被人忽略的体能再生方式。口渴不会像饥饿一样散发出明显的信号，等我们感到口渴的时候，身体或许已经缺水很久了。一家研究机构称，每天至少饮用1.8公斤水对维持体能有诸多好处。
15. 睡眠需求随年龄、性别、基因体能而异，但普遍的科学共识是：人体每晚需要7至8小时的睡眠才可以运转良好。还有数项研究发现，即使将人们隔绝自然光或钟表，他们还是会每24小时睡眠7至8个小时。
16. 小憩就是一种精力恢复手段。斯坦皮发现，小睡片刻的工人即便不能长时间睡眠，仍可以保持超过24小时的惊人高效和敏锐。唯一需要注意的地方就是小憩需要定时，以免受试者陷入更深的睡眠中。如果小憩超出30或40分钟，许多受试者会感到眩晕无力，甚至比不睡更加疲倦。
17. 即便适度锻炼有诸多益处，大多数美国人还是几乎不锻炼。原因很简单，提升力量与耐力需要我们踏出舒适区，体验不适的感觉，并且需要持续一定时间才能见效。但大多数人在看到明显的效果之前就放弃了。
18. 对需要坐在办公桌前工作的大批白领来说，日常锻炼的缺乏阻碍了机体的自然增强，导致年龄增长后，大多数人应对挑战和压力的能力都逐渐下降。
19. 定期锻炼可以缓解他的紧张感，帮助他更好地控制情感。
20. 身体锻炼是思维和情感精力的极佳源泉。
21. 盖洛普公司发现，保持优秀表现的诀窍之一是在工作环境中至少交一位好朋友。一段稳固的关系包括付出与回报、倾诉与倾听、珍视他人和被人同等珍视。如果一段关系中总是付出而得不到相应的回馈，不免会感到空虚和失落。以自我为中心的关系，也称不上真正的情感关系。
22. 当愤怒逐渐累积时，保罗会选择用腹部做深呼吸，放松肩膀和面部肌肉，掐断自己一触即发的情绪。当情绪逐渐平复下来，他会想办法将沮丧的感觉用一种大家更容易接受的方式表现出来——通常是自嘲的方式。如果保罗认为有必要提出批评的意见，他会采用 “三明治”技巧。首先真诚地对该员工的良好表现给出正面评价，然后以讨论而非宣讲的形式提出批评意见——因为自己的看法或许并非完全准确，最后以鼓励结尾。用“三明治”的方式提出意见不仅让他看起来充满善意和关怀，而且更容易让员工听取他的建议，不会产生逆反心理。
23. 只有接受那些看似相反的品质，不逼自己在其间二选一，才有可能获得最深刻最丰富的情感能力。情感层面的全情投入需要遵循斯多葛派哲学家的“破格文体”——美德的共同存在性。从这一角度看来，没有一种美德是不依赖其他品质而成为美德的。所有的美德都有条件。例如，毫不留情的诚实只是残酷而已。
24. 越来越多证据表明，大脑的运作方式也类似肌肉——积极使用能够提升能力，使用不足就会萎缩。
25. 尼采有句名言 ：“知晓生命的意义，方能忍耐一切。”任何能够点燃人类精神的事物都有助于全情投入、促进最佳表现。意志精力的关键动力在于性格品质——一个人如果有自己的人生目标，他的勇气和信念，即使面对艰难困苦和个人牺牲也会在所不惜。意志精力由激情、奉献、正直与诚实支持着。
26. 弗兰克尔是纳粹集中营中幸存的心理学家，他创作了《活出生命的意义》这本经典巨著。书中他引用了尼采的名言：“知晓生命的意义，方能忍耐一切。”弗兰克尔也描述了在不断有人死去的环境中，这个认知如何挽救了他的生命：生而没有意义的人是痛苦的，没有目标、没有目的、无需继续忍受。他很快就会迷失。我们的人生态度需要从根本上转变。我们既要自己学着转变，也要向绝望之人伸出援手，告诉他我们对生活的期待其实并不重要，重要的是生活于我们有何期望。我们要停止追问生命的意义所在，每时每刻提醒自己接受生命的检视。我们的回应不仅体现在言语和冥想中，还要贯穿我们的行为举止。生命的终极意义是担起责任，找寻难题的答案，并且完成生命为每个人设定的任务。
27. 每个人都拥有许多未知的潜力，只能在困境中才会激发它们。
28. 当目标感从消极流向积极、从外部流向内部、从自己流向他人，它就成为生活中最强大也最持久的精力源。
29. 设想一下，如果你坐在一艘行驶在海上的小船里，船底突然开始漏水，你的目的肯定是阻止小船沉下去。但如果你一直忙着舀水，肯定无暇顾及小船的航向。生活也是如此。当我们忙着填补漏洞，不让自己沉底，就没有多余精力探寻更深层的意义了。
30. 出于对内心深处软弱无力的恐惧，恃强的人会蛮横粗暴地对待他人。因为不愿承认内心的不足，成功的领导者永远都在吹嘘自己的成就，炫耀自己认识多少大人物。
31. “邪恶的本质缺陷并非是罪恶本身，而是自我否认。”《少有人走的路》的作者斯科特·派克写道，“邪恶攻击他人，而不承认自己的失败……因为必须否认自己是坏人，所以只能把别人当作坏人。”
32. 若困在狭隘的自我视角中，我们也不会注意到或有意培养自己的能力。我们或许可以尽力压制自己令人反感的一面，但同时也很难认可自己的优秀品质。
33. 使用许多手段否认生活中的不如意或逃避为此承担责任。责怪他人并将自己看作受害者是一种常见的方式。
34. 所有表现卓越的人都依靠积极的仪式习惯管理精力和规范行为。如果你一直久坐不动，打算开始锻炼身体，你可以最开始每周3次、每次步行15分钟，然后逐周增加步行时间或加快步伐。
35. 不管面对什么样的事情，他要么全情投入，要么有策略地离开。
36. 人类行为只有5%是受自我意识支配的。我们是习惯的造物，因而我们的行为有95%都是自动反应或对于某种需求或紧急情况的应激反应。
37. 在任何表现至上的领域，压力与恢复的平衡都至关重要。我们越能高效恢复精力，越能尽快储备资源以备调用。

1. 言语上的指责、嘲讽、否定、说教以及任意打断、拒不回应、随意出口的评价和结论给我们带来的情感和精神上的创伤，甚至比肉体的伤害更加令人痛苦。这些无心或有意的语言暴力让人与人变得冷漠、隔膜、敌视。
2. 我很希望这本书能帮助更多的人安静下来。使用暴力的人其实是因为他们内心的宁静遭到了破坏，所以他们才会用暴力的方式维护或寻求心灵的和平。
3. 非暴力沟通提醒我们人性是相通的——虽然每个人的价值观和生活方式或许不同，但作为人却有着共同的感受和需要。这样，在发生矛盾和冲突的时候，运用非暴力沟通，我们将能专注于彼此的感受和需要，从而促进倾听、理解以及由衷的互助。
4. 人们常说：“爱能使心灵的创伤痊愈。”
5. 作为有色人种，生活在执行种族隔离政策的南非并不是很有意思的事情。在那里，肤色随时都可能给你招来无情的刺激。十岁那年，白人打了我，他们认为我太黑了；接着，黑人又打了我，他们认为我太白了。这样的耻辱也许会让任何人想报复社会。
6. 非暴力生活的一个关键就是：感激生活的赐予，而不贪心。
7. 我意识到什么是真正的非暴力以及认识自身暴力的重要性。由于缺乏了解，我们常常认识不到自身的暴力。我们认为，只有打人、鞭挞、杀人以及战争等才算是暴力，而这类事与我们无关。
8. 因为恐惧无法带来和平。
9. 让尊重、理解、欣赏、感激、慈悲和友情，而非自私自利、贪婪、憎恨、偏见、怀疑和敌意，来主导生活。人们常说：这是一个弱肉强食的世界，为了生存，我们必须不择手段。这个观点，请恕我无法同意。
10. 我相信，人天生热爱生命，乐于互助。可是，究竟是什么，使我们难以体会到心中的爱，以致互相伤害？又是什么，让有些人即使在充满敌意的环境中，也能心存爱意？
11. 也许我们并不认为自己的谈话方式是“暴力”的，但我们的语言确实常常引发自己和他人的痛苦。
12. 当我们真诚助人时，我们丰富他人生命的愿望得到了满足。我们的行为，是出于由衷的喜悦。
13. 非暴力沟通的四个要素：1．观察 2．感受 3．需要 4．请求
14. 首先，留意发生的事情。我们此刻观察到什么？不管是否喜欢，只是说出人们所做的事情。要点是，清楚地表达观察结果，而不判断或评估。接着，表达感受，例如受伤、害怕、喜悦、开心、气愤等等。然后，说出哪些需要导致那样的感受。
15. 非暴力沟通提醒我们专注于彼此的观察、感受、需要和请求。它鼓励倾听，培育尊重与爱，使我们情意相通，乐于互助。有些人用非暴力沟通理解自己，有些人用它改善人际关系，还有人借助它改进工作。在世界各地，非暴力沟通被用来协调各个层面的争论和冲突。
16. 对他人的评价实际上反映了我们的需要和价值观。
17. 分类和评判提倡的是暴力。
18. 暴力的根源在于人们忽视彼此的感受与需要，而将冲突归咎于对方——至少大部分暴力的根源都是如此。
19. 美国领导人把前苏联看作是致力于摧毁美国生活方式的“邪恶帝国”；前苏联领导人将美国人看作是试图征服他们的“帝国主义压迫者”。双方都没有承认内心的恐惧。
20. 如果真的想过上悲惨生活，就去与他人做比较。
21. 比较也是一种评判。
22. 我们对自己的思想、情感和行动负有责任。可是，人们广泛使用“不得不”这一短语。例如：“不管你是否喜欢，有些事你不得不做。”显然，这种表达方式淡化了个人责任。“你让我”是人们常用的另一短语，例如：“你让我伤透了心。”此时，我们的表达方式忽视了我们情感的内在根源。
23. 我们可以用负责任的语言代替回避责任的语言。
24. 一旦意识不到我们是自己的主人，我们就成了危险人物。
25. 我们无法强迫他人按我们的期待生活。
26. 认为“某人应当受到惩罚”使我们难以体会到心中的爱。
27. 我们大多数的人使用的语言倾向于评判、比较、命令和指责，而不是鼓励我们倾听彼此的感受和需要。
28. 对于国王、沙皇、贵族来说，将臣民训练得具有奴隶般的精神状态符合他们的利益。“不应该”、“应该”和“不得不”这些表达方式特别适合这个目的：人们越是习惯于评定是非，他们也就越倾向于追随权威，来获得正确和错误的标准。一旦专注于自身的感受和需要，我们就不再是好奴隶和好属下。
29. 人天生热爱生命，乐于互助。可是，异化的沟通方式使我们难以体会到心中的爱。道德评判就是其中的一种，它将不符合我们价值观的人看作是不道德的或邪恶的。进行比较也是一种评判，它会蒙蔽对人对己的爱意。异化的沟通方式还淡化了我们对自己的思想、情感和行为的责任意识。此外，强人所难也会造成心灵的隔阂。
30. 不区分观察和评论，人们将倾向于听到批评。
31. 非暴力沟通的第一个要素是观察。我们仔细观察正在发生的事情，并清楚地说出观察结果。非暴力沟通并不要求我们保持完全的客观而不作任何评论。它只是强调区分观察和评论的重要性。将观察和评论混为一谈，人们将倾向于听到批评，甚至会产生逆反心理。
32. 不带评论的观察是人类智力的最高形式。
33. 对于大多数的人来说，观察他人及其行为，而不评判、指责或以其他方式进行分析，是难以做到的。
34. 非暴力沟通的第一个要素是观察。将观察和评论混为一谈，别人就会倾向于听到批评，并反驳我们。非暴力沟通是动态的语言，不主张绝对化的结论。它提倡在特定的时间和情境中进行观察，并清楚地描述观察结果。例如，它会说“欧文在过去的5场比赛中没有进一个球”，而不是说“欧文是个差劲的前锋”。
35. 只是描述观察结果而不含任何评论。
36. 非暴力沟通的第二个要素是感受。心理学家罗洛·梅（Rollo May）认为：“成熟的人十分敏锐，就像听交响乐的不同乐章，不论是热情奔放，还是柔和舒缓，他都能体察到细微的起伏。”
37. 当我们说“我觉得”，我们常常并不是在表达感受，而是在表达想法。
38. 非暴力沟通的第二个要素是感受。通过建立表达感受的词汇表，我们可以更清楚地表达感受，从而使沟通更为顺畅。在表达感受时，示弱有助于解决冲突。此外，非暴力沟通还对表达具体感受的词语与陈述想法、评论以及观点的词语作了区分。
39. 非暴力沟通强调，感受的根源在于我们自身。我们的需要和期待，以及对他人言行的看法，导致了我们的感受。
40. 听到不中听的话的四种选择： 1．责备自己 2．指责他人 3．体会自己的感受和需要 4．体会他人的感受和需要
41. 批评往往暗含着期待。对他人的批评实际上间接表达了我们尚未满足的需要。如果一个人说“你从不理解我”，他实际上是渴望得到理解。如果太太说“这个星期你每天都工作到很晚，你喜欢工作，不喜欢我”，那反映了她看重亲密关系。
42. 如果我们通过批评来提出主张，人们的反应常常是申辩或反击。反之，如果我们直接说出需要，其他人就较有可能作出积极的回应。
43. 双方都习惯于指责对方。
44. 如果我们不看重自己的需要，别人可能也不会。实际上，如果直接说出需要，获得积极回应的可能性就会增加。
45. 对于大多数人来说，个人成长一般会经历三个阶段：（1）“情感的奴隶”——我们认为自己有义务使他人快乐；（2）“面目可憎”时期——此时，我们拒绝考虑他人的感受和需要；（3）“生活的主人”——我们意识到，虽然我们对自己的意愿、感受和行动负有完全的责任，但无法为他人负责。与此同时，我们还认识到，我们无法牺牲他人来满足自己的需要。
46. 首先，清楚地告诉对方，我们希望他们做什么。如果我们请求他人不做什么，对方也许会感到困惑，不知道我们到底想要什么。而且，这样的请求还容易引起别人的反感。
47. 我们提出的请求越具体越好。如果我们的意思含糊不清，别人就难以了解我们到底想要什么。
48. 抽象的语言无助于深化自我认识。
49. 许多来向我求助的人后来发现，他们感到沮丧或灰心，很大程度上是因为他们不清楚自己对他人究竟有什么样的期待。
50. 如果我们只是表达自己的感受，别人可能就不清楚我们想要什么。
51. 像“你没有听明白”“这不是我的意思”“你听错了”这样的表达，很可能会让托尼觉得老师在批评他。
52. 参加集体讨论时，说清楚我们希望得到怎样的反馈，是至关重要的。如果不清楚发言的目的，我们的讨论也许只是在浪费时间，而无法满足任何人的需要。
53. 如何区分命令和请求：请求没有得到满足时，提出请求的人如果批评和指责，那就是命令；如果想利用对方的内疚来达到目的，也是命令。
54. 我们越是将他人的不顺从看作是对我们的排斥，我们所表达的愿望就越有可能被看作是命令。
55. 在生活中，如果我们不想勉强人，那么，清楚地表明这一点是重要的——这有助于人们相信我们提出的是请求而非命令。
56. 在人们无法满足我们的愿望时，我们是否尊重他们的感受和需要最能体现我们提出的是请求还是命令。如果我们愿意去体会是什么使他们无法说“是”，那么，根据我的定义，我们提出的就是请求而非命令。选择通过请求而非命令来表达愿望，并不意味着，一旦人们说“不”，我们就不再去满足自己的需要。但它意味着，除非已经充分体会是什么妨碍了他人说“是”，我们就不会试图说服他们。
57. 如果我们只是想改变别人，以使他们的行动符合我们的利益，那么非暴力沟通并不是适当的工具。非暴力沟通是用来帮助我们在诚实和倾听的基础上与人联系。使用非暴力沟通时，我们希望人们的改变和行动是出于对生命的爱。一旦人们相信我们看重彼此的感情，并能兼顾双方的需要，那么，他们也就会相信我们所表达的愿望是请求而非命令。
58. 我要会见的学生有四十位。在学校中，他们被看作是“品行不端”的学生。我认为，像“品行不端”这样的标签会带来很消极的影响。如果一个学生被贴上这样的标签，那岂不是说他不遵守学校规矩是正常的吗？这样的标签将鼓励学生做我们不希望他们做的事，然后，他们的行为似乎又进一步证实了我们的判断。
59. “在印象中，如果我没照你说的去做，你就不会尊重我。如果我知道你并不想使唤我，在你叫我时，我会乐于回应你。如果你高高在上，像个盛气凌人的老板，你将会发现，你一头撞在了墙上。当你反复提醒我，你为我做的各种事情，你最好准备再次碰壁！你可以大声抱怨、责骂，但我仍不会去倒垃圾。即使你现在改变方式，我也需要时间忘记不快。”
60. 一旦人们认为不答应我们就会受到责罚，他们就会把我们的请求看作是命令。如果我们清楚地表达我们无意强人所难，人们一般会相信，我们提出的是请求而非命令。非暴力沟通的目的不是为了改变他人来迎合我们。相反，非暴力沟通重视每个人的需要，它的目的是帮助我们在诚实和倾听的基础上与人联系。
61. 在前四章中，我们介绍了如何通过非暴力沟通的四个要素来表达自己。本章我们将探讨如何倾听他人，了解他们的观察、感受、需要和请求，并给予反馈。
62. 尽管有种种相似之处，生活的每时每刻就像一个刚出生的婴儿，一张新的面孔，我们从未见过，也不可能再次见到。我们无法停留在过去，也无法预见我们的反应。我们需要不带成见地感受变化。我们需要用全身心去倾听。
63. 在安慰他人或提建议前，先看看那是否是他们想要的。
64. ·建议：“我想你应该……” ·比较：“这算不了什么。你听听我的经历……” ·说教：“如果你这样做……你将会得到很大的好处。” ·安慰：“这不是你的错；你已经尽最大努力了。” ·回忆：“这让我想起……” ·否定：“高兴一点。不要这么难过。” ·同情：“哦，你这可怜的人……” ·询问：“这种情况是什么时候开始的？” ·辩解：“我原想早点打电话给你，但昨晚……” ·纠正：“事情的经过不是那样的。”
65. 说了什么，并考虑他的情况符合哪种理论，我们是在诊断人——我们并没有倾听他们。在非暴力沟通中，倾听他人意味着，放下已有的想法和判断，一心一意地体会他人。倾听的这种品质体现了它与理解以及同情之间的区别。
66. 分析妨碍了倾听。
67. 不论别人说什么，我们只听到他们此时此刻的（a）观察，（b）感受，（c）需要 和（d）请求。
68. 在倾听他人的观察、感受、需要和请求之后，我们可以主动表达我们的理解。如果我们已经准确领会了他们的意思，我们的反馈将帮助他们意识到这一点。反之，如果我们的理解还不到位，他们也就有机会来纠正我们。此外，这样做还有助于人们体会自己的状况，从而深入了解自己。
69. 一般来说，如果一个人在说话时有明显的情绪，他一般会期待得到他人的反馈。如果我们自己是说话的那个人，我们不妨清楚地表明我们是否期待反馈。
70. 一个人在听别人谈自己的感受和需要时，将会留意其中是否暗含着批评或嘲讽。如果我们的语气很肯定，仿佛是在宣布他们的内心世界，那么，通常不会有好的反应。然而，一旦别人通过我们的语气意识到我们是在体会，而非下结论，他们一般就不会产生反感。
71. 有时，我们认为自己受到了指责，实际上，那些话是他人表达需要和请求的方式。如果意识到这一点，我们就不会认为自己的人格受到了伤害。反之，如果一心分析自己或对方的过错，我们就会认为自己被贬低了。
72. 作家约瑟夫·坎伯（Joseph Campbell）说道：“为了幸福，必须把‘别人怎么看我’这个问题放在一边。”
73. 如果人们常常怀疑我们的诚意，那么，我们就需要好好审视自己的动机。也许，我们只是在机械地运用非暴力沟通，而忘记其目的。这时，我们就可以问自己，我们关心的是加深与人的联系，还是以“标准的”非暴力沟通方式来说话。或者，虽然我们是以非暴力沟通的方式来表达自己，我们在乎的也许只是改变他人来迎合我们的需要。
74. 一旦一个人意识到自己得到了理解和接纳，一般来说，他会觉得很惬意。
75. 怎样判断对方的感受是否已经充分表达呢？首先，如果一个人觉得别人已经完全明白他的意思，他就会变得轻松。这时，我们也会感到放松。另一个更为明显的标志是，他停止了谈话。如果无法确定对方是否还有话要说，就不妨问一句：“你还有什么话要告诉我吗？”
76. 我们无法给别人我们自己都没有的东西。有时，我们会发现自己没有心情去关心别人。一般来说，这反映了我们也需要得到关心。如果告诉他人我们正处于痛苦中，我们无法顾及他们的感受和需要，别人很可能就会伸出援手。
77. 联合国前秘书长汉马斯克德（Dag Hammarskjold）曾经说道：“你越是留意自己内心的声音，就越能够听到别人的声音。”一旦我们能够敏锐地察觉并照顾自己的感受和需要，我们就有能力迅速调整好状态，来倾听他人。
78. 我大声地提出请求，是为了提醒他们注意我此时此刻的痛苦和需要。
79. 当他人遭遇不幸时，我们常常急于提建议，安慰，或表达我们的态度和感受。为了倾听他人，我们需要先放下已有的想法和判断，全心全意地体会对方。倾听他人有助于对他人的理解和接纳。
80. 如果有人倾听你，不对你评头论足，不替你担惊受怕，也不想改变你，这多美好啊……每当我得到人们的倾听和理解，我就可以用新的眼光看世界，并继续前进……这真神奇啊！一旦有人倾听，看起来无法解决的问题就有了解决办法，千头万绪的思路也会变得清晰起来。
81. 非暴力沟通鼓励我们表达自己最深的感受和需要，因此，我们有时也许会发现运用非暴力沟通是富有挑战性的。然而，通过倾听，我们将意识到他人的人性以及彼此的共通之处，这会使自我表达变得容易些。我们越是倾听他人语言背后的感受和需要，就越不怕与他们坦诚地沟通。我们最不愿意示弱的时候往往是因为担心失去控制想显得强硬的时候。
82. “你和我们说，在一个生气的人面前，永远不要用‘不过’‘可是’‘但是’之类的词语。一开始，我很想为自己辩护，我想和他说，‘可是，我们真的没房间’。幸好，在那时，我想起了那句话。我一直记得这句话，是因为在一周前，妈妈在和我争吵时说，‘如果我说什么，你都说‘但是’，小心我杀了你’。想一想，我妈妈生气时听到‘但是’都想杀了我，何况那个男人呢？如果我在他愤怒时说，‘可是，我们真的没房间’，我想我早就没命了。”
83. 当别人说“不”的时候，我们常常会认为他们是在拒绝我们。有时，我们甚至还会觉得自己受到了伤害。然而，如果我们能够体会他人的感受和需要，我们也许就会发现是什么使他们无法答应我们的请求。
84. 有的时候，谈话的气氛很沉闷。我们体会不到说话的人有怎样的感受和需要，也不知道他对我们有什么期待。这样的谈话是很累人的。它只是在浪费我们的时间，而无法帮助我们与他人加深联系。这种局面的出现往往是因为说话的人并不清楚自己的感受、需要和请求。
85. 人们常常没有意识到，他们需要的是别人的理解和接纳。他们也没有意识到，直接表达自己的感受和需要，与讲故事相比，更容易得到他们所期待的联系。
86. 说的人更希望对方打断，而不是假装在听。
87. 所有的人都希望自己的话对人有益，而不想被人当作负担。
88. 有的时候，我们说了心里话，很想知道对方的反应，却发现对方一句话也不说。这时，我们也许会很不安，容易把事情往坏处想。在别人保持沉默时，我们一般会觉得有些别扭，而很难静下心来体会对方的感受和需要。
89. 倾听使我们勇于面对自己的弱点。它还可以帮助我们预防潜在的暴力，使谈话生动有趣，并了解“不！”和沉默所反映的感受和需要。一次又一次，我见证了，倾听帮助人们治愈心灵的创伤。
90. 非暴力沟通最重要的应用也许是培养对自己的爱。
91. 如何培养对自己的爱呢？转变自我评价的方式是一个重要方面。既然希望自己所做的任何事情都是有益的，那么，自我评价的方式就要有助于学习，使我们的选择符合生命的需要。然而，不幸的是，我们的自我评价方式往往导致自我憎恨，而无助于学习。
92. 失误揭示我们的局限性，并引导我们的成长。
93. 我希望，我们的改变是出于对生命的爱，而不是出于羞愧或内疚这些具有负面影响的心理。
94. 羞愧是自我憎恨的一种形式，出于羞愧的行为不是自由而快乐的行为。即使我们试图更加友善和体贴，一旦人们意识到我们行为背后的羞愧或内疚，他们对这些行为的欣赏也就比不上那些只是出于爱的行为。在我们的语言中，有一个词极易引起羞愧和内疚。我们经常使用它来打击自己。它在我们的意识中是如此根深蒂固，以致许多人无法想象，没有它生活将如何继续。这个词就是“应该”，也就是“我应该早点知道”或“我不应该做那件事情”中的“应该”。如果我们认为自己“应该”怎么样，在大多数的情况下，我们也就封闭了自我。因为“应该”意味着我们别无选择。这使我们感到无奈和沮丧。同时，又心有不甘，不愿屈服。
95. 自责是尚未满足的需要的可悲表达。
96. 经常责备自己、强迫自己将使我们“更像椅子而不像人”。非暴力沟通认为，对他人的指责反映了我们遇到了挫折——他人的行为不符合我们的需要。如果我们指责的那个人恰好是我们自己，那么，言下之意是：“我的行为不符合我的需要。”我相信，如果我们专注于需要是否得到满足以及得到怎样的满足，我们就更有可能从自我评价中获益。
97. 如果发现我们痛骂自己：“你看你，又把事情搞砸了！”我们马上就可以问：“我什么样的需要没有得到满足？”一旦意识到自己尚未满足的需要——很可能是多个层面的需要，我们的身心状态就会发生明显的变化。我们不再感到羞愧、内疚和沮丧，而开始体会到别的情感。不论它们是忧愁、失望、恐惧、悲伤、挫折感或别的——其目的都是推动我们去满足需要和追逐梦想。
98. 非暴力沟通鼓励我们直面人生的苦难：在遇到挫折时，充分体会人生的悲哀和内心的渴望。是的，感到遗憾是难免的。但它能帮助我们从经历中学习，而无须责备自己。我们意识到过去的行为违背了自己的需要及价值观，并允许这种觉察引发的情感充分流淌。一旦专注于尚未满足的需要，我们就会考虑如何满足它。反之，如果用苛刻的语言指责自己，我们不仅难以找到解决办法，而且容易陷于自我惩罚的痛苦中。
99. 非暴力沟通自我宽恕：感到遗憾时，我们试图了解过去的行为所要满足的需要。
100. 人的行为总是服务于自身的需要及价值观。
101. 当我们拥抱自己的各个方面，并理解它们所反映的需要及价值观，我们活在对自己深深的爱之中。
102. 我深信，出于对生命纯洁的爱，而不是出于恐惧、内疚、羞愧、职责或义务来选择生活，是爱惜自己的重要体现。
103. 不论你选择做什么，了解自己为什么要那样做。
104. 我们知道，如果不做某些事情，我们就会责备自己。我们认为不做那些事情是不对的、愚蠢的。可是，如果为了体面而循规蹈矩，我们最终难免会感到厌烦。
105. 最危险的行为也许是“因为别人的要求”我们不得不做。
106. 我相信，我们越是投入服务生命的乐趣中——服务生命是唯一的目的，我们也就越爱自己。
107. 非暴力沟通最重要的应用也许在于培育对自己的爱。当我们的表现不完美时，我们可以通过体会忧伤和自我宽恕，来看清个人成长的方向，以及避免自我惩罚。评价自己的行为时，我们专注于尚未满足的需要；这样，我们就不再依赖羞愧、内疚、恼怒或沮丧的心理来寻求改变，而让爱主导我们的学习和成长。
108. 充分表达愤怒的第一步是我们不再归咎于他人。如果我们认为“他让我很生气”，那么，我们难免就会指责他人。然而，实际情况是，我们心情并不取决于他人的行为。
109. 生气的原因在于我们的想法——对他人的评判和指责。
110. 如果在一个社会中，内疚被运用来控制人；那么，指责他人就容易成为一种习惯。同时，为了使这种手段奏效，我们可能就会认为一个人可以主导另一个人的情绪。
111. 听到不中听的话时，我们有四种选择：1．责备自己；2．指责他人；3．体会自己的感受和需要；4．体会他人的感受和需要。
112. 希望他人因为内疚发生改变，就是将刺激和原因混为一谈。
113. 假定我们约了个人，时间到了，她却没来。如果彼此的关系处于比较微妙的时期，我们可能会忧心忡忡。如果我们看重的是诚实守信，我们也许会觉得不耐烦。反之，如果我们想休息一会儿，我们可能就不会介意她来晚了。因此，同一件事情，不同的需要导致不同的感受。一旦意识到自己的需要——不论是友谊、诚信还是休息，我们就可以更加体贴自己。我们可能会有强烈的情绪，但不再生气。可是，如果意识不到自己尚未满足的需要，一心考虑别人的过错，我们难免就会生气。除了专注于自身的感受和需要，我们还可以选择去体会对方的感受和需要。此时，我们也不会感到生气。我们无须压抑愤怒，只要我们专注于他人的感受和需要，愤怒也就不再存在。
114. 在我看来，愤怒是我们的思维方式造成的。它的核心是尚未满足的需要。如果我们能够借助它来提醒自己——我们有需要没有得到满足，而我们的思维方式正使它难以得到满足，那愤怒就是有价值的。
115. 愤怒驱使我们去惩罚他人，而不是去满足需要。
116. 我们将会有意识地用“我生气是因为我需要……”来取代“我生气是因为他们……”。
117. 我生气的原因不在于别人做了什么，而在于我怎么看待对方及其行为。
118. 当我们意识到自己的需要，愤怒就转变为服务需要的情感。
119. 如果人们认为自己的痛苦是由其他人造成的，并认为那些人应该受到谴责或惩罚，那么，就像这位年轻的囚犯那样，他们播下了暴力的种子。
120. 指责一个人，往往使我们的愿望更难得到满足。
121. 指责他人有时可以使我们达到目的——出于害怕、内疚或惭愧，他们改变了自己的行为。
122. 批评和指责使人倾向于自我保护并变得更有攻击性。
123. 我们只是静静地体会自己。接着，想一想是什么想法使我们生气了。
124. 越是能够倾听他人，也越有机会被倾听。
125. 在大多数的情况下，在表达自己之前，我们需要先倾听他人。如果对方还处于某种情绪中，他们就很难静下心来体会我们的感受和需要。一旦我们用心倾听他们，并表达我们的理解，在得到倾听和理解之后，他们一般也就会开始留意我们的感受和需要。
126. 一旦意识到他人的感受和需要，我们就会发现彼此相同的人性。
127. 留意头脑中出现的暴力想法，而不评判它们。
128. 那位先生一直诉说着他的忧虑和不满。不经意间，他已经从犹太人谈到了黑人。看起来，他渴望有人了解他的痛苦。我静静地听着，大概十分钟后，他停了下来。他觉得我已经理解了他。
129. 人们常常觉得自己受到了指责，有时他们自己也同意，并开始恨自己——但这并不意味着他们会改变自己的行为。
130. 我们需要有足够的耐心来学习和运用非暴力沟通。在与人交往的过程中，我们的第一反应常常是习惯性的反应，因此，运用非暴力沟通有时是很别扭的事。然而，如果我们想要实现自己的人生选择，我们就要给自己充分的时间。
131. 练习把每一个指责都转化为尚未满足的需要。
132. 如果你希望自己在生气的时候也能运用非暴力沟通，我建议你做以下的练习。在前面，我们已经提到，我们生气是因为我们的想法——我们认为人们“应该”或“不应该”做什么，我们还给人贴上各种标签，并说长论短。请留意我们头脑中“我不喜欢抽烟的人……”之类的想法。然后，问自己：“我不喜欢他们……，是因为我什么样的需要没有得到满足？”通过这样的方式，我们就把注意力放在了尚未得到满足的需要，而不是考虑他人有什么过错。
133. 在生气时，批评和指责他人都无法真正传达我们的心声。如果想充分表达愤怒，我们就不能归咎于他人，而把注意力放在自己的感受和需要上。与批评和指责他人相比，直接说出我们的需要更有可能使我们的愿望得到满足。
134. 表达愤怒的四个步骤是：（1）停下来，除了呼吸，什么都别做；（2）想一想是什么想法使我们生气了；（3）体会自己的需要；（4）表达感受和尚未满足的需要。有时，在第3步和第4步之间，我们需要先倾听他人。在得到倾听和理解之后，他们也就可以静下心来体会我们的感受和需要。
135. 非暴力沟通认为，如果一个人做的事情会伤害到自己或他人，那是因为他不够成熟。为此，他需要得到帮助。如果我们不够成熟，我们可能会有以下的表现：（1）我们意识不到自己行为的后果；（2）我们认识不到，我们并不需要通过惩罚他人来满足自己的需要；（3）我们相信，我们有“权利”去惩罚或伤害他人，因为他们是罪有应得；（4）我们产生了幻觉，例如，听到“某种声音”叫我们去杀人。
136. 使用防卫性的强制力，是为了保护自己或他人，而不是为了惩罚、羞辱或谴责他人。
137. 我们希望痛苦能让他们：（1）意识到自己的过错；（2）感到懊悔；（3）改变行为。然而，在实际生活中，惩罚往往加强了对方的敌意和抵触心理，使双方的关系更加疏远。
138. 有的时候孩子拒绝做一件对他们有益的事情，只是因为他们不想在父母的压力面前屈服。其次，即使体罚能带来立竿见影的效果，这也并不意味着，其他方法无法达到同样的效果。最后，我还担心，体罚孩子会造成不良的社会影响。如果我们把暴力作为解决问题的办法，虽然孩子可能会去做我们要求的事，但这样做难道不是在鼓励孩子用暴力来解决冲突吗？
139. 当我们为了回避惩罚去做事情时，我们可能会忽视事情本身的价值，而陷于对失败的忧虑。如果员工的表现只是在服从管理层的命令，士气就会受到影响；或迟或早，工作效率就会降低。
140. 我希望他基于怎样的原因去做我想要他做的事情？
141. 了解别人基于什么样的原因来满足我们的愿望是至关重要的。
142. 在有些情形中，我们没有机会和他人交流，这时，我们也许需要使用强制力来保护自己和他人。我们这样做，是为了避免伤害，而不是为了惩罚他人。如果我们威胁他人或实施惩罚，人们常常会产生敌意和抵触心理。这样，彼此的关系将会疏远。同时，惩罚还可能使人忽视事情本身的意义，而把注意力放在不服从的后果上。如果我们试图通过惩罚来使人们认识自己的需要，那么，我们很可能适得其反。
143. 然而，对于大多数人来说，倾听和表达自己的需要并不容易。一般来说，我们的文化倾向于把个人需要看作是消极的、具有破坏性的。如果一个人公开表达自己的需要，就很可能被看作是自私的。
144. 专注于我们想要做的，而不是追究错在哪里。
145. 我感到惊讶的是，只要我不再批评和指责他人，而把注意力放在自己的感受和需要，我的心情就放松了许多。
146. 在情绪低落的时候，我们也许会怨天尤人。然而，如果我们以苛刻的态度对人对己，我们的心情也好不到哪里去。通过运用非暴力沟通，我们不再试图分析自己或他人有什么毛病，而是用心去了解我们的需要，这样，我们的内心将逐渐变得平和。一旦我们发现自己心底深处的愿望，并采取积极的行动，我们将会重获生活的热情。
147. 优雅地接受别人的感激。
148. 在别人表达感激时，人们通常有两种截然不同的反应。一种是自我膨胀，相信我们比别人优越；另一种是假谦虚，否定别人的欣赏，耸耸肩说：“哦，这没什么。”纳菲滋帮助我看到了，我们有别的方式来听取感激。如果我意识到我的能力是生命赋予我的，我就能够同时避免自我膨胀和假谦虚。
149. 虽然人们在听到感激时会不太自在，但绝大多数的人渴望得到他人的肯定和感激。
150. 我刚刚结束一个有100多人参加的研讨班，除了一个人，其他人都高度评价这次的研讨班。然而，我牢记的却是那个人的不满。
151. 约翰·鲍威尔（John Powell）在他的《爱的秘密》一书中讲到，对于没有在父亲活着的时候表达自己的感激，他十分伤心。这激起了我的强烈共鸣。如果无法向那些对我们的一生有极为重要影响的人表达感激，我们会感到多么悲哀啊！
152. 在赞扬他人时，我们很少揭示内心活动，而把自己放在了裁判的位置。赞扬也常常被人用来实现个人目的。非暴力沟通鼓励我们充分表达感激。在表达感激时，我们说出：（1）对我们有益的行为；（2）我们的哪些需要得到了满足；（3）我们的需要得到满足后，我们是什么样的心情。

1. 马克思以前的唯物论，离开人的社会性，离开人的历史发展，去观察认识问题，因此不能了解认识对社会实践的依赖关系，即认识对生产和阶级斗争的依赖关系。

2. 人的社会实践，不限于生产活动一种形式，还有多种其他的形式，阶级斗争，政治生活，科学和艺术的活动，总之社会实际生活的一切领域都是社会的人所参加的。因此，人的认识，在物质生活以外，还从政治生活文化生活中（与物质生活密切联系），在各种不同程度上，知道人和人的各种关系。

3. 马克思主义者认为人类社会的生产活动，是一步又一步地由低级向高级发展，因此，人们的认识，不论对于自然界方面，对于社会方面，也都是一步又一步地由低级向高级发展，即由浅入深，由片面到更多的方面。

4. 人们要想得到工作的胜利即得到预想的结果，一定要使自己的思想合于客观外界的规律性，如果不合，就会在实践中失败。人们经过失败之后，也就从失败取得教训，改正自己的思想使之适合于外界的规律性，人们就能变失败为胜利，所谓“失败者成功之母”，“吃一堑长一智”，就是这个道理。

5. 然而人的认识究竟怎样从实践发生，而又服务于实践呢？这只要看一看认识的发展过程就会明了的。原来人在实践过程中，开始只是看到过程中各个事物的现象方面，看到各个事物的片面，看到各个事物之间的外部联系。

6. 社会实践的继续，使人们在实践中引起感觉和印象的东西反复了多次，于是在人们的脑子里生起了一个认识过程中的突变（即飞跃），产生了概念。概念这种东西已经不是事物的现象，不是事物的各个片面，不是它们的外部联系，而是抓着了事物的本质，事物的全体，事物的内部联系了。概念同感觉，不但是数量上的差别，而且有了性质上的差别。

7. 认识的真正任务在于经过感觉而到达于思维，到达于逐步了解客观事物的内部矛盾，了解它的规律性，了解这一过程和那一过程间的内部联系，即到达于论理的认识。

8. 这种基于实践的由浅入深的辩证唯物论的关于认识发展过程的理论，在马克思主义以前，是没有一个人这样解决过的。

9. 指出了社会的人在他们的生产和阶级斗争的复杂的、经常反复的实践中，由感性认识到论理认识的推移的运动。

10. 感觉只解决现象问题，理论才解决本质问题。

11. 马克思、恩格斯、列宁、斯大林之所以能够作出他们的理论，除了他们的天才条件之外，主要地是他们亲自参加了当时的阶级斗争和科学实验的实践，没有这后一个条件，任何天才也是不能成功的。

12. 如果要直接地认识某种或某些事物，便只有亲身参加于变革现实、变革某种或某些事物的实践的斗争中，才能触到那种或那些事物的现象，也只有在亲身参加变革现实的实践的斗争中，才能暴露那种或那些事物的本质而理解它们。

13. 一切真知都是从直接经验发源的。

14. 就知识的总体说来，无论何种知识都是不能离开直接经验的。任何知识的来源，在于人的肉体感官对客观外界的感觉，否认了这个感觉，否认了直接经验，否认亲自参加变革现实的实践，他就不是唯物论者。

15. 中国人有一句老话：“不入虎穴，焉得虎子。”这句话对于人们的实践是真理，对于认识论也是真理。离开实践的认识是不可能的。

16. 中国人民对于帝国主义的认识也是这样。第一阶段是表面的感性的认识阶段，表现在太平天国运动和义和团运动等笼统的排外主义的斗争上。第二阶段才进到理性的认识阶段，看出了帝国主义内部和外部的各种矛盾，并看出了帝国主义联合中国买办阶级和封建阶级以压榨中国人民大众的实质，这种认识是从一九一九年五四运动前后才开始的。

17. 那个具体战争的规律性，懂得了战略和战术，因而能够有把握地去指导战争。此时，如果改换一个无经验的人去指导，又会要在吃了一些败仗之后（有了经验之后）才能理会战争的正确的规律。

18. 如果这个人在这项工作中经过了一个时期，他有了这项工作的经验了，而他又是一个肯虚心体察情况的人，不是一个主观地、片面地、表面地看问题的人，他就能够自己做出应该怎样进行工作的结论，他的工作勇气也就可以大大地提高了。只有那些主观地、片面地和表面地看问题的人，跑到一个地方，不问环境的情况，不看事情的全体（事情的历史和全部现状），也不触到事情的本质（事情的性质及此一事情和其他事情的内部联系），就自以为是地发号施令起来，这样的人是没有不跌交子的。

19. 认识的过程，第一步，是开始接触外界事情，属于感觉的阶段。第二步，是综合感觉的材料加以整理和改造，属于概念、判断和推理的阶段。只有感觉的材料十分丰富（不是零碎不全）和合于实际（不是错觉），才能根据这样的材料造出正确的概念和论理来。

20. 第二是认识有待于深化，认识的感性阶段有待于发展到理性阶段——这就是认识论的辩证法。如果以为认识可以停顿在低级的感性阶段，以为只有感性认识可靠，而理性认识是靠不住的，这便是重复了历史上的“经验论”的错误。

21. 庸俗的事务主义家不是这样，他们尊重经验而看轻理论，因而不能通观客观过程的全体，缺乏明确的方针，没有远大的前途，沾沾自喜于一得之功和一孔之见。这种人如果指导革命，就会引导革命走上碰壁的地步。

22. 理性认识依赖于感性认识，感性认识有待于发展到理性认识，这就是辩证唯物论的认识论。

23. 认识从实践始，经过实践得到了理论的认识，还须再回到实践去。

24. 人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。

25. 斯大林说得好：“理论若不和革命实践联系起来，就会变成无对象的理论，同样，实践若不以革命理论为指南，就会变成盲目的实践。”

26. 许多时候须反复失败过多次，才能纠正错误的认识，才能到达于和客观过程的规律性相符合，因而才能够变主观的东西为客观的东西，即在实践中得到预想的结果。

27. 革命时期情况的变化是很急速的，如果革命党人的认识不能随之而急速变化，就不能引导革命走向胜利。

28. 我们反对革命队伍中的顽固派，他们的思想不能随变化了的客观情况而前进，在历史上表现为右倾机会主义。这些人看不出矛盾的斗争已将客观过程推向前进了，而他们的认识仍然停止在旧阶段。一切顽固党的思想都有这样的特征。他们的思想离开了社会的实践，他们不能站在社会车轮的前头充任向导的工作，他们只知跟在车子后面怨恨车子走得太快了，企图把它向后拉，开倒车。

29. 我们也反对“左”翼空谈主义。他们的思想超过客观过程的一定发展阶段，有些把幻想看作真理，有些则把仅在将来有现实可能性的理想，勉强地放在现时来做，离开了当前大多数人的实践，离开了当前的现实性，在行动上表现为冒险主义。

30. 马克思主义者承认，在绝对的总的宇宙发展过程中，各个具体过程的发展都是相对的，因而在绝对真理的长河中，人们对于在各个一定发展阶段上的具体过程的认识只具有相对的真理性。无数相对的真理之总和，就是绝对的真理。客观过程的发展是充满着矛盾和斗争的发展，人的认识运动的发展也是充满着矛盾和斗争的发展。

31. 社会的发展到了今天的时代，正确地认识世界和改造世界的责任，已经历史地落在无产阶级及其政党的肩上。这种根据科学认识而定下来的改造世界的实践过程，在世界、在中国均已到达了一个历史的时节——自有历史以来未曾有过的重大时节，这就是整个儿地推翻世界和中国的黑暗面，把它们转变过来成为前所未有的光明世界。

32. 世界到了全人类都自觉地改造自己和改造世界的时候，那就是世界的共产主义时代。

33. 通过实践而发现真理，又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识，又从理性认识而能动地指导革命实践，改造主观世界和客观世界。实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。

1. 丹尼尔・平克在《驱动力 3.0》一书中有说：“服从让我们撑过白天，而投入才能让我们撑过夜晚。” 这告诉了我们一个很简单的事实：外驱让我们可以做好本职工作，而内驱才能让我们成就卓越。
2. 驱动力 2.0 的核心价值观是 “顺从”；而驱动力 3.0 的核心价值观是 “自主”。
3. 我们做管理工作的目标，归根结底，不就是 “群策群力打胜仗” 吗？“群策群力” 就是如何带好团队，“打胜仗” 就是如何取得好的业绩，“带人”+“做事”，齐了。
4. 想被提拔为一个管理者最好的方式，就是你首先成为一个实际上的管理者，我们常常把这样的晋升理念叫 “既定事实”，而这种理念在互联网行业里被广泛认同。
5. 无论你走哪条路上，你都会发现有些能力是共通的，比如规划、带人、沟通、执行等管理能力覆盖了全部 8 个方向。
6. 对于工程师思维特别重的管理者来说，他们尤其倚重技术；对于不懂技术的管理者来说，他们又特别迷信技术。
7. 做工程师的时候，技术是用来做事情的，掌握好技术的目的就是为了做好实施，看待技术是从如何运用的角度出发。而对于管理者来说，技术是达成目标的手段之一，所以看待技术是从如何评估的角度出发，评估该项技术是否是最合理的手段，以及如何选择才合理，并据此做出决策，因此常常被称为技术判断力。我们的老领导经常会告诫我们，即使做了管理，技术判断力不能丢，就是指这种能力。
8. 首先，把技术提到更高视角来看待。做技术的时候，把技术做好就是最大的目标；而做了管理之后，你会把技术作为一个手段来看待，看它究竟能为目标带来什么。但这并不意味着你就不再关心技术，只是关心的层次不同了，你开始需要借助每个人的技术能力去做更大的事情了。这很像在学习组装电脑，即便已经不需要关心主板、内存、CPU 的内部运行逻辑，但你还是要很清楚它们的功能是什么，接口什么样，以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏，也得清楚在整台电脑中，哪个部件可能会是短板，等等。所以，技术转管理并不意味着不关心技术，只是更关心更大的目标和整体结果了。
9. 其次，换一种学习方式来掌握技术。你要深刻地认识到，亲自写代码固然是很好的学习技术的方式，但是作为 leader，你需要快速掌握更多的技术，并且快速判断该如何搭配使用，所以你一定得有更高效的学习方式才行。这里我介绍三个行之有效的做法：建立你的学习机制。你可以想想在团队内建立什么样的学习机制，可以帮助你借助团队的力量来提升技术判断力，并结合自己的情况来创建。请教专家。在了解某一个领域的情况时，借助你的平台，找你能找到的最厉害的专家高手进行请教，他们之所以成为高手，一般都能给出高屋建瓴、醍醐灌顶的认知。在这个知识型工作者的时代，和自己埋头思考相比，共创成果往往会出乎你想象，特别能增长见识，你可以看看在团队中如何建立共创机制。
10. 别忘了，自从你带团队的那一天起，你就已经不是一个人在战斗。所以，你可以依靠团队和更广的人脉，去拓展技术视野和技术判断力。常见的几个方式如下：建立技术学习机制。盘点你负责的业务，需要哪些方面的技术，成立一个或几个核心的技术小组，让团队对各个方向的技术保持敏感，要求小组定期做交流和分享，这样你就可以保持技术的敏感度。专项技术调研项目化。如果某项技术对团队的业务有重要的价值，可以专门立项做技术调研，并要求项目负责人做调研汇报。和技术大牛交流。越是厉害的技术人，越能深入浅出地把技术讲明白，所以针对某项技术找大牛取经，也是学习的好途径。你看，虽然实际操刀的时间少了，但是你和技术大牛的交流机会多了，一方面因为你有更大的影响力了，另一方面，你和大牛有了共同的诉求，就是把技术 “变现”，让技术产生价值。听取工作汇报。因为你带的是技术团队，大部分工作都和技术相关，在读员工的周报、季度汇报时，相互探讨，也是一种切磋和学习。总之，你会发现，技术管理人的技术水准的提升和保持，主要看能从周围人的身上汲取到多少信息和知识，而不再只是靠自学。
11. 站在工程师视角上，追求工作的极致品质，恰恰是一种良好的工匠精神。但是站在管理者视角上，就需要评估一段时间内的产出效率了。衡量一项工作 “到底需要花 5 天做到 70 分，还是 10 天做到 90 分”，是管理者的日常工作。90 分方案未必就比 70 分方案好，此时，就需要优秀工程师出身的你放弃一些执念了。一旦放松这个念头，你就会发现，完成一项工作，原来还有很多的手段可以选择。
12. 分工不是为了高效，而是为了能容纳更多的人来一起干更大、更复杂的事情，做简单的小事情，是不需要分工的。
13. 凝聚力即是团队协作的基础，又是团队协作的目标。强大的凝聚力，是战斗力强大的团队的重要特征之一。
14. 如果能够带出一个良好的团队，持续不断地把一件又一件的事情做好，才算是一个好的团队管理者。所以，团队产出是否可持续，是考量管理者价值的一个很重要的维度，它体现了这个团队是否健康，是否有耐力和韧劲。其中，耐力让团队走得远，韧劲让团队走得稳。
15. 提升一个团队的耐力和韧劲，有两个要素：梯队培养和团队文化。
16. 一个团队的文化价值观，主要来源于团队负责人或核心管理者。你是什么样的作风和价值观，你团队就会是什么样的，也就是说，你的团队文化和你喜欢什么样的文化关系不大，而和你是什么样的人关系很大。
17. 面对问题，如果你总是抱怨，那么和团队强调积极文化是不会成功的； 面对合作，如果你总是对抗，那么和团队强调紧密协作是不会成功的； 面对工作，如果你总是被动等待，那么和团队强调积极主动是不会成功的； 面对下属，如果你总是漠不关心，那么和团队强调温暖有爱也是不会成功的。
18. 你想打造什么样的团队文化，核心是从你身上的优秀品质中提炼，从而把你优秀的特质放大到整个团队。若你身上没有的特质，那就不适合作为团队的文化价值观去培育。
19. 很多管理者为了激发培养对象的成长动力，常用句式是，“如果你干得好，将会如何如何……” 我的建议是，只明确培养的意向和计划就足够了，最好不要作出成长之外的承诺。
20. 如果你团队有不少资历比你老的员工，或者有一些技术能力比你强的员工，那么我得首先恭喜你。因为这至少说明两个问题：第一，你真的是非常优秀，以至于你能被公司赏识来负责这样一个团队；第二，因为这些老资格和高能力员工的存在，你有机会做出更好的业绩。
21. 既然你被任命为这个团队的负责人，你就是此次时刻带领这个团队最合适的人。
22. 我曾经的上级传授给我一句话，非常有效，相信对于此时的你也一定会有帮助，她对我说：“你也许不是那个最强的人，但是你得相信，你是此时此刻做这事儿最合适的人。”
23. 对于提升员工个人能力来说，最关键的往往不是学习的方法，而是学习的意愿。
24. 主动学习的员工总会是少数派，不只是公司的员工如此，社会生活中的人们亦是如此，所以有人说，“学习是反人性的事情！”
25. 往往因为某个要素不具备就否定所有的可能性。
26. 给员工信心和耐心，允许他们犯错、走弯路。因为很多经验都是踩坑儿踩出来的，所以不能一出问题就劈头盖脸一顿批，甚至是剥夺其做事的机会。
27. 善用威者不轻怒，善用恩者不妄施。
28. 你要做的，不是和团队成员竞争、比较，也不是比团队每个人都强，而是要考虑如何让大家把自己的才智都发挥出来，去达成一个共同的团队目标。总之，你要做的不是管束和控制大家，而是引导和支持大家。
29. 你可能满足不了某员工所期望的工作内容，但是还有行为模式和思维模式方面可以考虑，比如某些人特别爱和人沟通协调，那就让他用沟通讨论的方式去工作；如果有人特别善于独立思考和筹划，那就发挥他的思维优势；有的人行动特别迅速，那就让他去快速启动一项工作。总之，千万别简单认为发挥员工优势，就是鼓励员工 “挑活”；优势是多层次的，所以让员工发挥优势这件事并不困难。
30. 这里我提供一个简单实用的方法，即尽量避免用 “任务性” 的语言，而多使用 “成果性” 的语言。比如你安排一项工作给员工，常见的说法是：“把项目 A 抓紧做一下吧，下周要发布。” 这在员工看起来，他收到了一项任务。但换成 “成果性” 的说法是：“项目 A 会帮我们验证一个结论，决定我们是否在这个方向上持续投入，下周就要做出决策，所以，你看下周能否搞定？” 显然，成果性的说法会让员工更清楚自己工作的价值，完成之后也会很有成就感。
31. 作为管理者，只有言行一致，保持承诺一致性，才能赢得团队的信任。
32. 每一个激励方案都需要去思考和设计，把外驱和内驱结合起来，把长期和短期结合起来，把业务推进和职业幸福集合起来，把个人工作和团队使命结合起来。
33. 大多管理者都能够想到这一点，就是在工作进展过程中要了解进度、评估风险，而不是任务交代完了就撒手不管了。
34. 既然是授权，事中最好不要干涉太多，只做约定好的 check 和支持就好。
35. 一线员工是用工作量来评估价值的，他们只要做出了自己该做的，就是有价值的；而管理者是用团队业绩来评估价值的，即便不是管理者个人的原因，只要结果是团队不出业绩，那么管理者的价值就很难体现。
36. 管理者分配工作的方式是直接交代要做什么，并不会和员工去分享和探讨这项工作的价值，以及对团队和公司意味着什么，所以起不到激励效果。
37. 作为管理者你可以亲身感受得到，总会有一批人因为工作没有价值而离职。他们不是矫情，而是真的需要看到自己给公司和社会带来什么价值。所以，管理者的一项重要修炼，就是去梳理团队的使命和项目的意义。
38. 对于新管理者，你在绩效评估和沟通之前，先审视一下自己的角色：你是这个团队的管理者，是这个团队的负责人，你是有责任来评价团队每个员工的工作表现和业绩的。你是站在团队的视角来看待这个问题，而不是站在任何一个成员的对立面来特别针对他。即便他做的也还不错，但是你如果还是把低绩效的名额给了他，那么你一定是有自己的依据的，所以这个绩效也的确是他应得的，你并不欠他什么。你有管理者的职业素养，有管理者的工作视角，也有令人信服的评价依据，你做出来的就是最公平和最恰当的决策。所以，你需要考虑的事情是，如何和他达成共识，期待并支持他也可以像其他同事一样，变得更加出色。 所以，你的角色不仅仅是一个评判者和告知者，还更是一个辅导者和支持者。
39. 希望我和初级管理者们澄清一个事情，那就是：“上级默认是需要管理者们主动向上沟通和反馈的，而非默认不需要。”
40. 相信你也听过这样一个说法：看似是两个人之间的沟通，其实至少是 “四个人” 之间的对话，哪 “四个人” 呢？也就是：你想表达的、你实际表达的、对方听到的和对方对于听到内容的理解，这其中每一步传递都会造成失真，所以很难领会到对方的真实意图也就情理之中了。
41. 向上沟通、向下沟通和横向沟通构成了管理沟通的主体，所以我把它们称为管理沟通的三大典型场景。
42. 管理者要做出好的业绩，就需要站高一层，站在自己上级的视角来和各个团队协同，以收获共同期待的成果。并且大部分时候，帮合作团队一起做好工作，也是为了自己的业绩，你并不会吃亏。
43. 工作中最好还是以做事为主，少考虑一些个人感受。如果就事论事地去沟通问题，反而会赢得更多合作者的尊重。
44. 不能默认对方一定能收到，而且不能默认对方理解的和你想的是一致的。
45. 对于你关心的问题，一定要去确认清楚，跟进到底，形成沟通闭环。
46. 影响力，是一种不使用强制性力量却能改变别人的看法和行为的能力。一般又分为职权影响力和非职权影响力。
47. 要想提升自己在这个因素上的影响力，不妨去盘点一下别人经常用什么正向的词来形容你，并进一步地把它们打磨得更加鲜明。一旦对方认同你的人品，就有了很好的信任基础。
48. 一旦违背了如下三个批评的原则，“促其改变” 的效果就很难达到： 人是 OK 的原则。即，对事不对人。批评事，不要打击人，更不能给人贴标签。 具体性原则。指出具体哪里做的不好，让对方容易认同。 面向未来的原则。体现负面的暂时性和过去时，并提供改变的 “出口”。
49. 我采取的策略是问自己这两个问题： 如果做，收益是否很大？收益越大，这个事情就越重要。 如果不做，损失是否很大？损失越大，这个事情就越紧急。
50. 可以靠经常能关注到的一个随身物件来提示。比如你的手环、戒指，甚至是手上的一个伤疤，只要你能时不时关注到，就可以。一旦看到这个物件，你就问一下自己 “我是不是在发怒”，这也是一种觉察。 每天写觉察日记，反思自己在情绪管理方面是否有所失误。我身边就有伙伴用这种方式并取得了比较好的效果。 可以和伙伴约定，请他帮忙提醒。一旦他发觉你情绪不对，都可以当场或事后提醒你，来加强觉察。 用你的重要关切来提醒。比如，你可以和你的上级约定，把这个季度的情绪化频次作为一项 KPI 纳入自己的《绩效计划》，从而让你心里总是悬着一根弦来不断提醒自己要注意情绪。细心的你一定发现了，这个方法显然也可以用于帮自己的下级来提升情绪管理的能力。事实上，我就用过，并且取得了很好的效果。
51. 作为管理者我们需要清楚一点，的确会有很多事情是我们掌控之外的，其中不乏不合理或不完善的。对于这样的情况，发泄抱怨则意味着我们内心深处已经对此无能无力了。而实际上，我们也许并不需要完美地解决这个问题，而只需要把一个 40 分的状态改善到 60 分就行了，或者即便没有改善到 60 分，我们也把事情往好的方向上推进了一点点，这也是我们的价值。而抱怨除了把负面情绪感染给团队之外，收获不到任何正向的价值。
52. “这个规定太不合理了，没法遵守！”—— 那么，怎么样就合理了？ “我们在指定日期肯定做不完，没戏！”—— 那么，什么条件满足之后，就能做完呢？或者，认为什么时候能做完？ “这个设计很不合理，完全不考虑用户体验！”—— 那么，怎么样会合理一些呢？ “团队的氛围太差了，郁闷！”—— 那么，怎么做氛围会变好一点点呢？
53. 我会问自己的初心：“你到底想要的是什么？你能为上级、下级和公司带来哪些价值呢？” 通过问自己这个问题，我会秉持一种帮助公司、帮助 CEO 和下属的初衷，把我们的利益全部统一起来，以至于从一开始就不担心上级不信任、下级不服气以及同级排挤的问题。因为，每个人都不会拒绝你给他带来支持和帮助的。
54. 遇到冲突时，跳出自己的角色来判断是非对错，通过审视初心来做决策，很容易让自己充满力量。
55. 不要指望按照头衔去筹划自己的工作，就可以满足上级和公司的期待。
56. 如果你不主动去争取你想要的，你就不得不接受一些你不想要的。
57. 其实，我们对于一个人的评价，从来都是有双重标准的，一个标准是 “及格”，另外一个标准是 “优秀”。所谓 “及格”，就是只要胜任工作的要求就好了；而 “优秀”，除了胜任工作要求，还需要脱颖而出，超出团队普通表现，成为整个团队的核心人物。
58. 罗伯特・迪尔茨的 “NLP 逻辑层次图”，一个人的行为、能力、价值观，都源于一个最根本的认知，就是自我角色的设定。
59. “7-2-1” 法则，即：10% 靠听课和看书自学，20% 靠相互交流和讨论，70% 靠工作实践。
60. 模仿，是人们学习新技能非常重要和常用的方式。当你尝试做管理的时候，也可能在不断模仿那些你认为 “最优秀” 的管理者，并希望像他们一样 “成功”。
61. 对于管理者来说，最大的客户就是上级，因此，价值最大化的核心就是去匹配上级和公司的期待。
62. 这是一种面向客户的视角，即，围绕客户的需要去发挥和提升自己的能力和价值。
63. 这个视角在 “求生存” 的时候特别好用，其逻辑是通过满足别人的期待，来获得自己生存的资源，因此也叫 “生存视角”。
64. 最核心的就是要厘清上级的期待并努力去兑现它，这对于在新的环境中 “生存” 下来是非常有效的，即是这个道理。
65. 职位头衔已经不再体现职责要求，我们需要从固化的职位要求中跳脱出来，从实际的工作需求去定义自己的职责和角色。
66. 我想说的是，无论是主动也好，被动也罢；无论是出于使命、兴趣也好，抑或是欲望、压力也罢，只要是在职场中，就有一个基本法则在发挥作用，那就是 “价值兑现”，即，你能收获多少回馈，取决于你能输出多少价值。这里的回馈不仅是指物质回馈，还包括成长感、成就感、幸福感等精神回馈。所以，无论是什么初衷，以及选择了什么样的职业道路，最终都会落在一个问题上：“我能否最大化地输出自己的价值？”
67. 即便如此，在最后的最后，我还是有两句话要交代：请耐心地给自己成长的时间。这个时代的快节奏带给我们很多的焦虑和不安，仿佛一不小心就会错过什么。其实，职业生涯就像一场 “马拉松”，很漫长，5 年或 10 年可以发生很多事，而你的生涯可能是 20 年、30 年，甚至可以像我一样，贯穿整个余生。在这么漫长的岁月中，肯定有人 “先胖”，有人 “后胖”，不用着急。成功其实很容易，因为所有的失败都不叫 “失败”，都只是 “尚未成功” 而已；只要有一次 “成功” 可以让你足慰平生，你就是个 “成功者”。互联网拉平了世界，你随时都有时间和机会去赢得自己的成功，或早或晚。用自己最擅长的姿势，开创属于自己的发展之路。不是前人走过的路才叫路，也没有什么规定好的 “管理之路” 是你必须要走的。因此，也就不存在所谓的 “弯路”，所有你走过的路都是你的成长之路，这条路是你自己开创的。事实上，所有的路上都有一条法则是奏效的，那就是 “价值兑换”，所以，做技术不重要，做管理也不重要，把技术和管理当成你职业的两条腿，在职场中输出自己最大的价值，才是最好的，才真正属于你。切记，不要被别人的路限制住，也不要被某个职位限制住，没有哪个职位可以定义你的职业发展。

如何提升项目管理能力？这个问题覆盖面很广，其实，很多时候方法都是通用的，这方面和学一门技术所运用的技巧是一样的，可以先实践后学习，以终为始，先解决当前遇到的问题，解决了之后再总结，久而久之就像涂鸦一样，慢慢这一块那一块也会涂完，而不是一开始就按顺序涂完整幅画。

在做事情的时候，有些知识不是立马就会用到的，学了之后没有应用，很快就会忘记，而且没有立马实践意味着没有产出，你没看到有什么显著的成果，就会打击积极性，便不利于你后续的学习。

其实，这个思路无形之中刚好契合了毛泽东《实践论》所说的，“通过实践而发现真理，又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识，又从理性认识而能动地指导革命实践，改造主观世界和客观世界。实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。”

所以，这也是我们项目计划为什么需要有复盘会议的原因，实践、认识、再实践、再认识，如此反复，不断地向真理靠近。

市面上相关项目管理的书籍很多，但是大部分都是一些方法技巧，我始终认为方法固然很重要，但是意识才是最核心的那部分，只有不断修炼意识层面，哪怕方法暂时掌握不到位，日积月累，终有一日也会有所成就。

所以，项目管理的书籍，我就只推荐一本，来自刘建国的《知行：技术人的管理之路》，主要内容就是程序员如何走上管理、为什么要做管理、怎么做好管理，全方位剖析会遇到的问题怎么解决等等，我觉得是很实用的一本书。

其他的，就是一些看起来好像和项目管理一点关系都没有，实际上关联密切的书籍，首先就是《实践论》，它是如此的重要，以致我不得不多次提及，除了这本书之外，还推荐《非暴力沟通》和《精力管理》，附录会有一些摘要，可以简单看一下，基本上可以总结为四个方面，覆盖项目管理所需的各项能力：方法、意识、沟通、身体。

其中，身体其实才是最重要的，它是一座高楼的地基。地基的好坏，直接影响到上层的建设。在项目管理上也是如此，它会关系到你能成长到哪一个阶段。

因为对于项目负责人而言，无论是手头上的开发任务，还是面对与多个部门的沟通协作，以及处理诸多繁琐事务，外加达成目标的压力，无不耗费巨大的精力和心力。

“身体是革命的本钱”，这句话大家都听过，所言非虚，在此就不再赘述了。

至此，从 2022 年 8 月开始编写这些内容，从开发人员到项目负责人再到项目总负责人，对遇到的各类项目问题都进行了梳理，并以个人浅见提供了一些解决方案，总结为一句话就是：结果导向，修己安人。

这个系列，基本上就告一段落了，如果后面有一些心得还是会持续更新的。

1. 前言

部门项目文档是使用 ShowDoc 进行管理的，为了技术文档的整洁以及易于阅读，根据当前实际情况，整理了一些文档编写规范。

标准的文档应包括 TOC 标题目录、说明栏、标题、子标题（如果需要）、内容，如下所示：

2. 标题

标题总共有 3 种样式，可以选择任意一种，视具体情况而定，但是最好不要混用。

# 一、样式1
# 1、样式2
# 1. 样式3

预览效果，如下所示：

如果只有一级标题，3 种样式都可以使用，如果有子标题，建议使用样式3。

# 1. 这是一级标题
## 1.1 这是二级标题
### 1.1.1 这是三级标题
### 1.1.2 这是三级标题
## 1.2 这是二级标题
## 1.3 这是二级标题
# 2. 这是一级标题

文档内容中显示的效果，如下所示：

文档大纲显示的目录样式，如下所示：

3. 代码块

Markdown 语法支持代码格式化，在文档中显示更为美观，方式是除了操作栏上面的快捷按钮 ，也可以头尾加上```实现，我们通常使用这个功能主要是为了在文档中贴上代码，但也会在其他情况下使用，比如一些命令或者很长的 Bug 报错信息。

1. 代码

const CounterApp = {
  data() {
    return {
      counter: 0
    }
  },
  mounted() {
    setInterval(() => {
      this.counter++
    }, 1000)
  }
}

2. 命令

npm install
npm run dev

3. Bug 报错信息

Uncaught TypeError: Cannot read property 'toggleRowSelection' of undefined

4. 文本高亮

文本高亮通常在输入英文单词时使用，一来为了强调重点，二来是为了界面美观。

1. 实现方式

我们创建了一份完整的构建 `Vue` 服务端渲染应用的指南。这份指南非常深入，适合已经熟悉 `Vue` 、 `webpack` 和 `Node.js` 开发的开发者阅读。请移步 `ssr.vuejs.org` 。

2. 实现效果

我们创建了一份完整的构建 Vue 服务端渲染应用的指南。这份指南非常深入，适合已经熟悉 Vue 、 webpack 和 Node.js 开发的开发者阅读。请移步 ssr.vuejs.org 。

5. 超链接

超链接的使用方式，方括号里是超链接显示的文本内容，圆括号是超链接具体的网址。

1. 实现方式

[ECMAScript 6](https://es6.ruanyifeng.com/)

2. 实现效果

ECMAScript 6

6. 插入图片

插入图片的使用方式和超链接方式很相似，只是在前面多个一个感叹号 ! 而已。但这种不是最便捷的，如果是在 ShowDoc 上面使用，直接复制图片，在文档中粘贴即可，会自动上传并回显图片的路径。

7. 应用模板

1. 解决方案文档，可以参照《Web应用实现在手机端访问和使用方案》
2. 技术笔记文档，可以参照《Sentry的基本使用》、《Linux与Windows跨平台文件共享实现》

在前面《25 - 项目需求如何有效梳理》文章中，已经说明过项目需求应如何依据实际情况进行梳理。不过，那是针对单个项目的情况。

倘若项目负责人负责多个项目，且这些项目之间存在一定关联，例如同属某个具体行业，此时，项目需求梳理就会面临问题。

该项目负责人所在团队有 10 人，负责项目 A、B 两个项目，这就需要两份需求文档、两个项目计划以及两个版本发布时间。

1. 项目 A 的需求文档和项目计划

2. 项目 B 的需求文档和项目计划

按理来说，这种安排并没有什么问题。然而，由于这两个项目均由这 10 个人负责，存在人员复用的情况，项目 A 的需求和计划一旦发生变化，就会对项目 B 的需求和计划制定产生影响。

对于项目负责人而言，项目管理的难度显著增加。一方面，需要在不同的项目文档里整理需求；另一方面，还需在不同项目中修改计划。

此外，还有两个版本发布时间，原本 10 个人负责的工作，却出现两个目标时间节点，无论是目标导向还是上下级沟通，都变得很复杂。

如何解决这一问题呢？

一方面要简化项目负责人对多个项目的管理工作，另一方面要让这 10 个项目成员更具目标感和凝聚力，设定唯一目标，即 10 个人要在规定的时间节点前完成安排的任务。

鉴于项目 A 和项目 B 同属一个行业，可以把它们转为子项目，重新创建一个总项目，下设子项目 A 和子项目 B，如此一来，就只需一份需求文档、一个项目计划和一个版本发布时间。

但这里存在一个问题，总项目的版本号只是用来做需求规划的，项目 A、项目 B 都有各自独立的版本号，并没有办法沿用总项目的版本号。那么，如何将它们与需求文档关联起来，以便追溯呢？

例如，项目 A 线上出现了 Bug，需要查看这个版本更新了哪些内容，才能判断 Bug 的影响范围。

假设总项目需求文档是 V1.0，而项目 A 当前版本是 V2.1，怎么在需求文档中查看项目 A 的 V2.1 迭代了哪些功能呢？

我能想到的是，只需要在总项目每个版本的需求文档里，在项目 A 旁标记当前版本号，并评估这些迭代功能是否需要升版本号即可。

如果要在该文档系统中列出项目 A 某个版本的全部需求（比如 V2.1 ），可以在搜索框使用【项目 A `2.1`】进行搜索，这样相关内容就能全部罗列出来。

最近，我发现有些事情安排下去后，如果我这边没有跟进到位，过一段时间，这件事情可能就突然没了下文。

起因是之前我和项目负责人沟通一件事，有个项目的原型和已有项目基本没什么差别，于是探讨如何复用和设计，以实现前端组件复用，减少工作量。

当时，我们在座位上沟通，也说好方案大概完成的时间。然而，过了一两周，我看项目需求文档时，发现上面压根没记录这件事。和他沟通后，他才又想起来好像有这么回事。

乍听之下，肯定觉得这是项目负责人的问题。但深入思考后，我才意识到，很可能我这边才是最大的问题。

为什么这么说呢？

因为我习惯在滴答清单上列出每天要做的任务，每做完一条就勾选掉。这本身没什么问题，问题在于对于安排型任务，我也是如此处理。

通常我会和项目负责人在座位上沟通，把事情的背景、要做什么、为什么这样做以及要达成什么结果都说明清楚，然后给出大概的完成时间。

之后，我就在滴答清单上把这条任务勾掉，觉得事情已经安排下去，就算做完了。

但这个事情进入下一个环节，会出现哪些情况呢？

如果项目负责人本身具备及时反馈的意识，那还好说。但要是项目负责人不重视，或者被其他事情干扰、疏忽了，而我这边又没有及时跟进，过了一两周甚至更久，才突然想起好像有这么一件事，那时可就晚了。

这个时候，我能去问责项目负责人吗？

其实也不是不行，但对方也有理由，这一两周也没闲着，只是事情太多太杂，忘记了而已。

通常都是这类理由，所以问责也于事无补，反正也改变不了现在这个结果。因此，没必要问责，还是要从最本质的问题出发，找到最根本的原因，再通过一些策略彻底解决这个问题。

首先，从我自身角度来说，就是要跟进到位。那怎么解决任务跟进的问题呢？

我想到一个方案，就是在企业微信上创建一个任务清单表格，把需求提出方、提出时间、任务内容、安排时间、计划完成时间、验收情况、进度情况都填写清楚，并实时更新。

每周都要梳理一遍上面的任务情况，再结合每两周一次的项目进度会议，及时更新任务进度。

如果出现任何问题，比如事情被遗忘、遇到困难、无法推进等等，及时沟通解决。等事情验收完成后，再在任务清单上标记已完成。我觉得这样就能解决上述问题。

总的来说，安排任务时，不能只是把任务分配下去就高枕无忧了。虽然每一条任务的发布和验收形成闭环是很理想的状态，但在这个过程中，及时跟进也至关重要。

1. 前言

项目总负责人究竟应该在什么时候介入项目呢？

这个问题的本质其实是在深入探讨，何时需要项目总负责人直接替代项目负责人做出关键决策，或者直接介入并解决项目推进过程中遇到的具体问题。

下面以项目负责人为张三、项目总负责人为王七的实际案例进行详细说明。

2. 事情起因

曾经有一次，客户在项目沟通群里反馈了一个问题，明确提到平台的地图功能没有正常显示出来。

当时正值周六，按照常规工作安排，大家都没有在公司上班，因此项目负责人张三可能没有及时留意到沟通群里的消息，也就没有在第一时间回复客户。

后来，有看到消息的同事将客户反馈的问题转发到了部门群，这样整个部门的人员都能看到客户的反馈内容了。

可即便如此，张三仍然没有在部门群里对客户的问题进行回复。

3. 张三为什么没有及时回复

事后了解到，他认为地图功能并不是由自己负责的项目团队开发的，而是属于其他项目团队的功能，自己负责的项目仅仅是在使用这个功能模块而已。

也就是说，他在内心将自己定位为功能使用方，所以觉得不应该由自己来回复客户，而应该由负责开发地图功能的相关人员来处理。

4. 王七为什么没有及时回复

事实上，项目总负责人王七在周六当天也看到了客户在沟通群里反馈的消息，但他同样没有及时回复客户，就这样任由问题持续发酵。

王七当时的想法是等着张三去处理这个问题 —— 因为在他看来，这是项目负责人职责范围内的事情。如果王七事事都介入处理，就相当于虽然已经对张三进行了授权，自己却又在一旁指手画脚，这样的做法显得有些奇怪。

不过事后回头来看，王七在这件事情上确实存在考虑不周全的问题，没有全面深入地看到问题的核心本质。

5. 从客户的视角看问题

换位思考，假设你自己就是那位客户，在沟通群里反馈问题之后过了很长时间都没有人回复，会作何感想呢？

而且需要注意的是，这次反馈问题的渠道不是工单渠道，而是群内的实时交流渠道，在这种情况下，客户即便不生气，心里也会十分不爽吧。

毕竟，客户在使用功能时遇到了问题，急需解决以便正常使用，而我们却没有给予足够的重视。

6. 张三的问题与改进

张三的做法乍一看似乎有一定的合理性，但他根本没有想明白关键问题所在 —— 对外和对内处理问题的方式是截然不同的。

在公司或者部门内部，上面提到的那种想法虽然存在一定问题，但还不是特别严重。

因为无论对外还是对内，项目负责人的职责本来就包括对项目整体的管理，一旦出现问题，第一责任人肯定还是要找到项目负责人，怎么会有出现问题先去找具体功能负责人的道理呢？

正确的处理流程应该是：客户的反馈先到达张三这里，然后由张三再去找对应的同事沟通并解决问题。在对外沟通时，个人所代表的不再是自己，而是整个公司。

因此，每一句话、每一个行为都需要用公司的标准来严格要求自己。

就算明知道问题属于其他项目组甚至其他部门，如果该部门的相关人员不在这个沟通群里，也应该先回复客户，比如可以说 “我先了解一下具体是什么问题”。

然后再去寻找对应的同事，不管是部门内部的还是其他部门的，都要积极去协商协调，最终把问题解决掉。

客户不会去关注你是哪个部门的，他们只知道你是这家公司的员工。

不管在公司内部具体是由谁负责这件事情，客户只需要你帮忙解决他们遇到的问题，仅此而已。

7. 王七的问题与改进

当客户反馈问题之后，已经过去了五六个小时，张三还是没有回复客户。

这个时候，王七可能觉得这是张三的职责所在，认为张三需要经历这样的事情，而这也正是导致王七没有直接介入沟通的原因，差不多就是想让张三通过这次犯错来积累工作经验。

不过，王七也犯了同样的错误：从想法本身来看没有问题，把全部职责交给张三，张三就应该承担起相应的责任。

但关键在于**要弄清楚是什么事情，不可能什么事情都能用来攒经验的。**就拿上面这件事情来说，客诉问题，一直是重中之重的事情，不可掉以轻心。

正如前面所提到的，客户不会去关心你公司内部的分工情况，他们只知道你是这家公司的员工，你在客户面前的任何表现，都直接关系到客户对这家公司的整体印象。

所以在这种情况下，当张三没有回复客户时，如果过了一两个小时，张三仍然没有回复，那么王七自己就需要直接介入，回复客户，并跟进这个事情，弄清楚到底是什么原因导致了这个问题，确保问题能有效解决。

至于要问责或弄清楚张三为什么没有及时回复客户等事情，可以等事情解决了之后再说，现在首要解决的是客户遇到的问题，一切以客户为先。

在项目管理中，我们常会制定一些规章制度用以约束行为，从而有效推进项目。但现实中，无论是开会沟通通知还是口头传达的要求，往往只能坚持一段时间，过后便会恢复原状。

正如那句话说的：“你无法要求别人做什么，除非他自己愿意去做。”

工作中亦是如此，即便强调过每天下班前要在项目任务系统填写当天日志，对方也只能坚持一阵子，时间一长便又故态复萌。

同理，项目计划需要实时更新，以避免信息同步不及时影响后续功能开发或决策制定，但很多人依旧未能遵守，大多是坚持一段时间后便打回原形。

这种现象很难单纯用对错来评判。回归本质，我们的核心目的在于：将所有问题公开化，通过即时沟通制定规章制度，确保各项目有效推进，避免延期，最终达成项目目标。

那么，该如何解决这些问题呢？发脾气或许能起到一定作用，但也要看对象，而且大多数情况下并不推荐。更合适的做法是找个会议室私下沟通清楚，避免当众批评，以免引发逆反心理，得不偿失。

因此，我们需要探寻有效的解决方法。就以任务日志缺填这一问题为例（实际情况中存在的问题远不止于此，此处仅作举例说明），可以采取以下措施：

首先，将规章制度以严谨的文字梳理成文档，并建立惩罚机制。例如，约定任务日志缺填每月不得超过 3 次，否则需赞助50 块钱到部门经费 ，同时，项目总负责人自己也需赞助 50 块钱。

这样做的目的在于：一方面，项目总负责人作为全部项目首要责任人，理应对项目中出现的任务问题负责；另一方面，避免将自己置于项目成员的对立面，减少摩擦，让大家感受到你与他们是站在同一阵线，制定这些规定只是为了更好地进行项目管理，而不是针对谁。

在落实过程中，月底统计时如果发现有人当月缺填超过 3 次，就需要当面沟通了解情况，探究缺填的原因。

沟通时要因人而异，大多数情况下，只要解释合理（无论真假），都按真实情况处理，并明确告知此次可以通融，但下个月如果再出现类似情况，将直接收取 50 块钱，不再给予额外机会。

因为，我们的目的并不是为了这 50 块钱，所以，给对方一次改正的机会，让对方感受到被尊重，后续会更愿意、自觉地遵守这些规章制度。

但凡事也有例外的，虽然应该不多。如果下个月对方依旧出现，任务日志缺填超过 3 次以上的情况，该如何处理？

这需要根据具体原因来判断：如果理由充分、合情合理，可暂时不收取费用；如果理由并不充分，则直接收取费用，并与对方一同扫码将费用赞助至部门经费，同时在部门群内公开，以消除大家对项目总负责人是否也一起赞助 50 块钱了的疑虑。

如果下个月仍然出现缺填且理由不充分，在要求对方赞助 50 块时态度还很恶劣，那么，就需要明确告诉对方：制定项目规章制度的目的是什么？任务日志的作用是什么 —— 让项目负责人能够实时了解每个人的工作情况、任务进度，以及是否存在影响项目推进的问题，以便及时采取其他方案。

如果对方依旧不服从，就需要强硬处理，因为规章制度刚落实时如果不及时拔除这根钉子，后续将难以服众。

总的来说，项目总负责人应以身作则，制定合理的规章制度，并通过实际沟通和客观判断，赢得大家的信任，促使大家养成良好习惯。

实际上，设置 50 块钱赞助部门经费的规定，重点并非在于金额多少，而是形成一种无形的约束。

理想状态下，一年可能就收个两三次，大概就 300 块钱左右。毕竟，钱好像不是很多，但是要让大家白白支出这笔钱，肯定觉得太亏了。相信这样应该能有效解决一些项目管理中遇到的问题。

所以前面 10 篇都没有群发记录，基本是偷偷在写 —— 主要想验证自己能否坚持下来，万一失败了，反正也不会有人知道。

但当时心里一直想着：要做就做好，要么就不做。没有不清不楚、不黑不白、不上不下的中间地带。

这个打卡活动，我从 2020 年 4 月底购买陈皓《左耳听风》课程时就知道了，起初打算试试看，后来不知怎么就不了了之。这次重拾起来主要有三个目的：

1. 平时上班敲代码的机会变少，想通过刷算法题保持对代码的感觉。
2. 我有一份问题清单，记录着工作中遇到的问题、技术点和小技巧，但一直没整理，打算通过 Tip 模块倒逼自己梳理。
3. 老生常谈的英语学习。

前期坚持的效果还不错，印象中没补几次卡，应该就是过年放假时间长了点，其他时候都还好。

起初计划每周阅读 Medium 上的文章，说实话，上面的文章质量真不错，而且这个网站没有广告，阅读体验特别好。

我做 Review 这件事的流程基本是：自己先看一遍，看不懂的用欧路翻译插件一键自动记录到生词本，了解大概内容后自己翻译，再用有道翻译原文，对比两者的差异。

这个模式坚持了一段时间后，我觉得 Medium 上的文章有时太长，自行翻译太费时间，加上需要翻墙，在公司看文章很不方便，于是换成在 Breaking News English 网站翻译新闻短文，一方面文章篇幅短，另一方面不用翻墙，还能了解新闻资讯。

在这个网站坚持一段时间后，有一天我突然觉得自己看英文文章不发怵了，不管多长都能硬着头皮看下去，总觉得自己马上就能看懂了。但这种感觉没持续多久，就又回归正常状态了。

说真的，我很讨厌英语，为什么要学这个东西呢？但后来我想明白了，“师夷长技以制夷” 的前提是你得懂对方在说什么。当然也可以用翻译软件，但学习一门语言就是在学习一种文化，只有了解了文化和风俗习惯，应对问题，才能游刃有余。这是翻译软件无法替代的。

坚持这个打卡活动到某个时间点时，我突然觉得差不多了，就是已经不需要证明什么了。当时计划在 2024 年 10 月 22 日结束这个打卡活动。

但刚好《黑神话：悟空》8 月底开售，我想自己都等了 4 年了，Windows 电脑和游戏手柄都有，装备齐全，没理由不去玩，一玩才发现，这质量也太高了吧，远远超出预期。

9 月初通关《黑神话：悟空》后，我真正对魂类游戏产生了兴趣，想起 2017 年买的《黑暗之魂 3》，每次玩都因为不知道怎么玩，也不看攻略，再加上都是骷髅有点吓人，玩了几次，实在玩不下去，就作罢了。

这次趁热打铁，我把老贼的《黑暗之魂 3》通关了，通关后才感叹这真是艺术品啊。它在我 Steam 游戏库里吃灰快 8 年，直到现在，我才真正体验到这部作品为什么是史诗级别的。接着我又通关了老贼的《艾尔登法环》，这部年度游戏也是神作，就不多说了。

前前后后花了很多时间在游戏上，ARTS 打卡活动就经常断掉，只能攒起来恶补，每周一次的打卡规定也形同虚设。

但我一点都不慌，也不觉得心虚，因为我已经不需要这些来证明自己能坚持这个打卡活动了。

我坚信，即使是现在，我依然可以按严格的每周一更频率坚持打卡，只是已经没有这个必要了。

从 2023 年 5 月 13 日陈皓过世到现在已经 2 年了，时间过得真快。

我在《关于陈皓，二三事》这篇文章里介绍过一些交集，虽然我们从未沟通过，但我还是很感恩。

陈皓文章中体现的一些东西一直激励着我，虽说他是后端，我是前端，那个课程大部分内容是后端、大数据、Go 语言、各种服务器知识等，和我关联不大，但他在做人做事、职业规划、工作学习上的建议，让我醍醐灌顶，很是受用。

现在真的要结束了，想起过去快两年在电脑前码字的时光，不管是艳阳高照的白天，还是灯火通明的深夜，我都是开心的，也觉得很值得。

我相信 “日拱一卒，功不唐捐”。

我想起之前看《铁齿铜牙纪晓岚 4》时，有这样一段剧情：乾隆打算在凌烟阁挂上二十四幅功臣图，众人就谁排第一产生争执。乾隆使计让杜小月说出，若让纪晓岚进入军机部，也能像和珅一样出色，所以不同意和珅比纪晓岚厉害。乾隆顺水推舟，安排了角色互换的游戏，让纪晓岚去军机部，和珅去修四库全书。结果两人在处理不同部门事务时，因为缺乏经验，导致处处受阻，只能私下碰头商讨对策。

剧中，纪晓岚说皇上让自己查张廷玉的几块银两用在何处，觉得这点小事不必斤斤计较。和珅则表示，皇上安排的事情，最怕的不是大事，因为大事有章法可循，按章办理即可；最怕的是小事，没有先例，只能琢磨心思、见招拆招，所以对皇上安排的小事，要特别小心。

还有曾仕强先生在一期节目中说道：“如果老板让我去死，我到底去不去呢？” 他给出的回答是，先应承 “好的，老板”，然后自己不去就行了嘛。

从上述事例中，我们能得到什么启发呢？一方面要明白领导的用意，另一方面是不要直接拒绝领导。关键在于不要直接拒绝，而非完全不能拒绝。

其实核心还是 “先肯定后否决” 的策略，这和我们平时常用的标准反驳句式如出一辙 ——“你说的确实有道理，但是……”

如果是我，我会先一口答应下来，尤其是在多人场合。如果只有自己和领导两人沟通，拒绝的影响相对小一些；然而在多人场合直接拒绝，领导可能会觉得没面子。要是领导心眼小、心胸狭窄，日后难免会给你穿小鞋。所以，先痛快地答应 “好的”，然后过半小时左右去找领导，解释目前手头上的任务太多，若新任务时间紧迫，是否可以将其他任务暂缓？如果不能暂缓，多项任务同时推进实在难以完成，恐怕最后会顾此失彼。

这样做既能表明自己有积极完成任务的态度，又能说明客观条件不允许。领导的回应通常有两种：要么让你先暂缓其他任务，要么让你推迟新任务的完成时间，问题往往就能迎刃而解。当然，如果领导听不进建议，仍然一意孤行，直接干他就是了（哈哈哈，你敢信，我就敢说）。

由此可以延伸思考，领导安排任务时，必然有自己的考量。一般有两种情况：一是从当时的实际情况出发，认为由你负责更为合适；二是借此进行测试。培养一个人并非突然委以重任或提拔，而是通过日常工作中的突然考验，时不时来这么一下，看你瞬间的反应，从多个维度综合评估你是否值得信任、能否为我所用。

可能有人会说，公司的组织架构、管理方式和领导的性格等各方面情况都不一样，但我觉得核心逻辑是一样的 —— 先肯定后否决，只是在执行方式上，需根据实际情况调整。比如公司是扁平化管理，上下级没有明显的严格层级划分，而你对自己负责的项目情况又特别清楚，领导安排新的任务时，你完全可以直接当面解释目前的情况，说明加上新任务可能会导致的问题，而不必非要一口答应，等到半个小时之后才去找领导解释，那样做事就太死板了。

不过话说回来，工作和生活本就是一体的，但又不尽相同，人在上面的行事风格差异很大。工作上的这种测试是可以接受的，毕竟只是工作。但生活中类似的测试，真的不能接受，因为很没意思。

本周的算法题为 598. 区间加法 II

给你一个 m x n 的矩阵 M 和一个操作数组 op 。矩阵初始化时所有的单元格都为 0 。ops[i] = [ai, bi] 意味着当所有的 0 <= x < ai 和 0 <= y < bi 时， M[x][y] 应该加 1。

在 执行完所有操作后 ，计算并返回 矩阵中最大整数的个数 。

示例 1:

输入: m = 3, n = 3，ops = [[2,2],[3,3]]
输出: 4
解释: M 中最大的整数是 2, 而且 M 中有4个值为2的元素。因此返回 4。

实现代码如下：

const maxCount = function(m, n, ops) {
    // 如果操作组为空，则表示都是0，直接返回m*n
    if (ops.length === 0) {
        return m * n;
    }
    // 找到最小的m和n
    let minM = m;
    let minN = n;
    for (let i = 0; i < ops.length; i++) {
        minM = Math.min(minM,ops[i][0])
        minN = Math.min(minN,ops[i][1])
    }
    // 返回最小的m和n的个数相乘
    return minM * minN;
};

解题思路：

这道题其实还是很简单的，只是一开始会有点绕，不太清楚要讲什么，但是仔细观察就会发现，突破点就是这个 “矩阵中最大整数的个数”。因为所有的格子都要 + 1，所以，最大的整数只会出现在操作组a1、b1值最小的那个上面。所以，我们要做的工作，就是找出最小值的那个操作组。

Review

Carlo Ancelotti leaves Real Madrid to coach Brazil - Breaking News English Lesson

65 岁的传奇足球教练卡洛・安切洛蒂已决定离开西班牙豪门皇家马德里，出任巴西国家队主教练。他执教皇马的最后一场比赛将于 5 月 25 日举行，次日他将正式走马上任巴西国家队主教练一职。安切洛蒂对记者表示：“从 26 日起，我将成为巴西队主帅，这是一项重大挑战。现在，我仍是皇马主帅，我希望能圆满完成这最后一段征程，为这段美妙的冒险画上句号。” 执教巴西队将是安切洛蒂首次担任国家队主教练一职。安切洛蒂是有史以来最成功的足球教练之一，他是唯一一位赢得过欧洲五大顶级联赛冠军的教练，还创纪录地五次捧起欧洲冠军联赛奖杯。

巴西队是世界上战绩最为辉煌的国家队，也是唯一一个五次夺得国际足联世界杯冠军的国家，但上一次夺冠还是在 2002 年，自那以后，巴西队再未闯入过世界杯决赛。2014 年，巴西队在半决赛中 1 比 7 惨败给德国队。巴西足球联合会主席埃德纳尔多・罗德里格斯希望安切洛蒂能扭转巴西队的命运。罗德里格斯先生说：“安切洛蒂是历史上最伟大的教练，如今他执掌着世界上最伟大的国家队。我们将携手为巴西足球书写新的辉煌篇章。” 安切洛蒂将率领巴西队出战下个月对阵巴拉圭和厄瓜多尔的世界杯预选赛。

Tip

之前一直用 DeepSeek 来检查文章、公司文档的错别字和标点符号，结果它总是输出莫名其妙的东西。后来我换成 Kimi，虽然效果好了很多，但还是不尽如人意，很多语句都有问题。这次换成豆包 AI，好像是好一些，但也就那样吧。

所以说，想用 AI 写文，实际上搞不好反而会降低效率。当然，这还是得看使用的人，如果没什么底线，觉得输出的东西无所谓，那效率确实高得很。

Share

“醉后不知天在水，满船清梦压星河。”

这真的是人能写出来的么？

好像没有什么问题？其实，真正的产品需求文档，也就是俗称的 PRD 文档，是很规范的，就不说什么形式上的问题，比如文档信息、版本更新历史、名词解释等等。就光内容的要求，就很精细。就拿 APP 的 PRD 文档来说，是需要把原型的图片贴到文档里的，然后要对每个功能和交互进行说明，比如点击这个按钮，会出现什么弹窗，弹窗的布局是什么样子的，内容是什么，文本是什么颜色的，是使用什么字体的等等。比如，XiaoPiu 的官方示例：

这样详细的好处是，在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述，那就是避免需求边界不清晰，导致后续的返工。

但是，对于我们现阶段而言，项目的需求应该怎么梳理呢？这个怎么说呢？如果是在大公司，分工比较明确，那么这样做无可厚非，精益求精未尝不可，但是，如果是中小型公司，或者只是一个部门，要自负盈亏，考虑到实际工作中的产出，或者说性价比，那么就感觉有点过度精细了，说好听点，是追求极致与差不多这个度怎么把控的问题，说直白点，是怎么利益最大化的问题。

所以，从实际情况出发，虽然 PRD 文档规范化，有诸多好处，但是投入产出比显然很低的，因为没有那么多人手把这个需求做到这么精细的程度，加上平时沟通也很及时，有什么问题及时沟通处理就行，而且，PRD 文档规范化还有一个重要的目的是，为了和其他部门或其他公司进行沟通交流使用的。

可是，只是我们部门内部使用的需求文档，就没必要这么精细了，只要能做好这件事情就行。但是，虽然是一句话需求，但还是有优化空间的，我们做不到整个文档规范化，但对这一句话的需求，可以规范化。

上面说的是 PRD 文档的规范问题，但其实，对于需求的整理，可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程（XP）的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写，帮助团队更高效地管理需求，确保故事的可交付性和价值性。

INVEST 原则主要用于优化用户故事的描述，使其满足以下特性：

1. 独立性（Independent）：故事之间减少依赖，便于单独开发和测试。

2. 可协商性（Negotiable）：避免过早锁定细节，鼓励通过沟通逐步完善需求。

3. 有价值（Valuable）：每个故事必须为用户或客户提供明确价值，避免资源浪费。

4. 可估算（Estimable）：团队能评估工作量以制定迭代计划。

5. 短小（Small） ：单个故事工作量控制在几天内，以降低风险。

6. 可测试（Testable）：明确验收标准，确保功能可验证。

结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？

这里就以设备管理功能，写一个示例参考：

深圳客户希望能看到自己有多少台设备，方便统计和日常维护。

1. 是谁：深圳客户
2. 要做什么：看到自己有多少台设备
3. 为什么：方便统计和日常维护

通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。

项目发起测试时，首先要在 OA 填写软件测试申请单。填好之后，由项目负责人准备当前版本的测试用例，交给测试部门，同时沟通确定测试周期，之后才正式开始项目功能测试。

2. 线上版本出现明显的问题

最近有个线上平台，客户反馈说平台里有个列表的按钮怎么点都没反应，而且弹窗的样式也错乱了。可这个版本明明是测试通过才上线的，这就说明测试环节肯定出问题了。

3. 问题产生的原因分析

为什么会出现这种情况呢？

主要还是测试流程有漏洞。因为项目负责人提供给测试部门的测试用例，只包含了当前迭代的需求。所以测试的时候，测试人员就只测了新增加的功能，而出问题的那个功能是旧功能，因为不在迭代的需求范围内，所以压根就没测。

按理说，这个旧功能没做任何改动，怎么会出问题呢？

后来发现，在开发当前迭代需求的时候，有可能开发人员不小心动到了这个功能的代码，或者是在修复其他小问题的时候影响到了它。

还有可能是当前迭代需求其实和这个功能是有关联的，但我们只关注了迭代功能有没有完成，根本没管那些关联功能，这才导致问题在实际使用的时候暴露出来。

4. 测试流程改进办法

为了解决测试覆盖不全，又不想每一轮都全部测一遍浪费时间的问题，我们优化了测试流程：

项目负责人这边要提供完整的测试用例，还要标注清楚当前版本里哪些功能必须测试，哪些不用测试。

测试人员分三轮进行测试：

第一轮，不管标注的是不是必须测试，把平台所有功能的测试用例都过一遍；

第二轮，专门验证已经修复的 Bug，同时再把那些必须测的功能测一遍；

第三轮，等所有 Bug 都修好了，确定没什么大问题了，再把平台全部功能的测试用例再过一遍。

这样一来，既能保证测试全面，又不会做太多无用功。

项目当前版本（假设为1.0）开发完成之后，会提交给测试组进行测试，然后，开始进行下一个版本（假设为2.0）的研发工作。

但是，测试组测试周期可能要一两个月，期间会不断的反馈 Bug 到系统里，等项目当前版本（1.0） Bug 修复完成之后，再进行下一轮的测试。

这时，项目新的版本（2.0）功能开发进行中，每个人都已经有自己的开发任务了，时间也排好了，应该怎么安排？

还有，在 A 功能模块上修复 Bug，而同时又在 A 功能模块上开发新的功能，代码合并可能会冲突等等问题怎么处理？

2. 权衡任务调整的利弊

因为测试反馈 Bug 数量不是一个可控的事情，有时第一轮测试完成，都没几个 Bug，有时第一轮测试就反馈好几十个 Bug，完全可以衍生新的任务，评估个两三天去处理。

所以，如果你打算，暂停或推迟当前版本（2.0）的开发任务，而去执行修复上个版本（1.0）的 Bug 的任务，很有可能收益不大，因为可能都没有几个 Bug 让你修复。

但是，如果你完全对第一轮反馈的 Bug 不管不顾，又会影响到测试组的测试进度。

3. 基于测试周期的任务调整

上面说的，虽然测试反馈 Bug 的个数是不可控的，但庆幸的是，测试周期是明确的，比如第一轮具体是什么时间段，第二轮又是什么时间段，这些都是前期沟通好的，虽然偶有变数，但是大体上问题不大。

在这个基础之下，项目负责人就要根据测试轮次结束的时间，对当前反馈的 Bug 情况，进行任务上面的调整，比如第一轮测试反馈了 50 个 Bug，然后按功能模块划分清楚，以及哪些功能模块对应的负责人是谁，修复这些 Bug 需要多少工作量，新增一条修复 Bug 的任务在项目当前版本（2.0）计划中。

4. 测试环节的漏洞

但是，如果 Bug 特别多，花费了大量的时间，甚至影响到了当前版本（2.0）的开发进度怎么办？

这个时候，是否需要延长修复 Bug 的任务呢？

缩短开发的任务时间呢？

加加班？

这些方式可以解决这个问题，但是，治标不治本。

因为在这个功能到测试组介入参与测试时，其实，已经有过三个环节，对功能进行测试了。

一个是功能开发人员自测，编写测试用例，然后对开发的功能点一一测试。

另一个是功能开发任务验收，这个验收的工作就是根据功能开发人员提供的测试用例，验收人自行跑一下这个测试用例，看下有没有什么问题。

最后一个是项目负责人内测，就是项目当前版本（1.0）结束，要给测试组提测之前，把全部功能都测试一遍。

上面这三个环节，为什么不能发现和解决掉一些很明显的 Bug，而一定要测试组测试时才发现？

5. 优化测试流程

理想状态下，每一轮测试都不应反馈那么多 Bug 的，然后需要排两三天的时间去处理的，通过一两天差不多了，甚至在开发当前功能时抽个一天的时间解决掉就行。

所以，回答项目开发中应什么时候去修复测试反馈的 Bug 这个问题，那就是做好下面的流程：

1. 功能开发人员自测
2. 功能开发任务验收
3. 项目负责人内测

然后，等测试哪一天测试完成之后，评估一下反馈的 Bug 数量，补充一条修复 Bug 任务，同时，变更当前的开发任务时间。

理论上来说，这条修复 Bug 的任务时间也就一天左右，最多也就两天了，除非出现突发的不可控因素。

如果反馈的 Bug 特别多，需要的修复时间也很长，意味着上面三个环节压根没有做到位。

6. 代码合并问题的处理

这个问题，其实可以等版本 1.0 的测试全部通过，发布至线上环境之后，再把 1.0 的代码合并到 2.0 的分支（即当前的 `Dev 分支），解决掉冲突就可以了。

7. 整体流程

测试人员反馈的 Bug 一般都记录在 Bug 系统里进行管理，所以问题不大。发在沟通群里的，多个人看到了之后，会给功能负责人带来一定的约束力，通常问题也不大。

最大的问题是那种私底下一对一沟通反馈的 Bug。比如，项目负责人张三给项目成员李四发消息，反馈了一个功能上面的 Bug ，李四说记下来了。

如果李四解决了并反馈给张三，那还好；但如果李四不反馈，张三就不知道这个 Bug 的状态了。除非张三主动去问，否则谁也不知道这个 Bug 是否已经解决。

写到这里，我不由得感叹，要做好一件事情，各方面的协作都要到位。**任何一个流程没有有效执行，都会导致后续的环节发生变化，并需及时提供相应的对策，从而使简单的问题复杂化。**所以，制定清晰的流程并传达到位，是多么的重要。

首先，在推动从流程入手解决这个问题之前，要先分析一下：

为什么反馈 Bug 时要私底下一对一沟通呢？

为什么不直接发到沟通群里呢？

原因很简单，大家都是同事，低头不见抬头见。发现对方开发的功能出现了 Bug，虽然不是什么大事，毕竟，谁都不能保证自己开发的功能，一个 Bug 都没有。只是，发到项目沟通群里，当众指出别人的问题，不管对方心胸多么宽广，总会不高兴的，自然而然，都会觉得没必要做这种不讨好的事情，反正能解决掉这个 Bug 就行，是否是私底下一对一沟通反馈，没有那么重要。

我觉得换位思考，上面这样的原因是可以接受的，但是完全依赖人，而不是依赖流程，是不能彻底解决掉问题的。

所以，我们可以这样规定：

在 Bug 系统上进行管理，为项目创建一个对应的版本。在这个版本的开发时间段内，遇到的所有问题，以及别人反馈的 Bug，都记录在这个上面，而不是私下沟通。这样虽然是公开的，但是不去看就不会知道，不像在项目沟通群里，当众处刑。

因为 Bug 系统是和邮件关联的。比如你是项目负责人张三，在验收李四开发的一个功能时，发现了问题123，那么就在 Bug 系统记录，并分配给李四。

等李四解决掉 Bug 之后，就修改这个 Bug 的状态为 “已解决”，张三就知道 Bug 已经解决了，然后再去跟进，这样就形成了闭环。

那如果张三还是不把 Bug 记录到 Bug 系统，或者李四解决了 Bug 但没有在 Bug 系统上修改状态呢？

那就需要及时介入沟通了，不能听之任之。抓而不紧，等于不抓，出现问题要第一时间解决，表明你对这件事情很重视。

否则，大家都觉得可有可无，慢慢就变成做做样子应付了事，那通过流程化解决对 Bug 进行有效管理的初衷就无法达成了。

复盘会议通常是在项目某个版本完成开发并正式上线之后才召开的，但复盘工作其实并不是等到最后才开始的。项目负责人应该在项目前期就开始着手准备，在项目推进的过程中，持续记录各种各样的问题，这样在会议上就能有更充分的内容来进行讨论和总结经验。

当项目负责人要召开项目复盘会议的时候，需要把项目相关人员都通知到位，比如产品、后端、前端和测试等等。然后预订一个会议室，在群里发布会议通知，到时候按计划如期进行。

这个复盘会议对于项目负责人来说，一方面能够吸取项目管理方面的经验，另一方面也有助于提升项目团队的凝聚力。

在会议上，把项目开发过程中哪些是做得好的，哪些是做得不好的，依次都列出来，让大家一起讨论一下，有一个总结与反思的过程，也是一个一起分享成果的过程。

对于做得好的地方，那肯定是要表扬的；对于做得不好的地方，大家就再接再厉。

复盘会议上讨论的内容，基本上涵盖了项目版本周期的方方面面，目前主要总结了以下几点。

2. 任务完成情况

这个版本的项目任务计划制定得是否合理？哪些任务有多次变更的？已过期的任务具体原因又是什么？

3. 测试反馈BUG问题

把这个版本测试提出的 Bug 整理和归纳一下，分析一下具体的情况。哪些 Bug 是完全可以通过提前规划来避免的呢？比如输入框的校验，基本都没有，功能开发的时候，只是保证能用就行了，功能的边界完全没有自测。类似这种问题，就可以在会上进行讨论，然后达成共识，加入到开发规范里，后续就可以规避类似的问题了。

4. 会议记录

我们每次开会都有会议记录文档，然后会把反馈的问题都记录下来。这些文档在复盘的时候就会起到作用，可以从中吸取经验。看看有哪些问题是第一次出现的，那有没有对策可以避免再次出现呢？这些都是可以在复盘阶段解决的。

5. 技术笔记

技术笔记是开发过程中对功能难点进行总结的文档。遇到哪些功能解决不了的？后来又是怎么解决的？都可以在复盘会议上进行分享。

6. 群内反馈的问题

群里反馈的问题可不止是项目讨论群里的，还有其他客户群里的。客户反馈了哪些问题，又提出了哪些需求？后续我们的工作要怎么规划？

7. 总结

复盘的目的不是对过去的问责，而是对过去的反思和总结，并着眼于未来如何改善。

项目这个版本的功能已经完成了，事已至此，没必要深究谁没做好，然后让对方有心理负担。我们的目的一向是解决问题，这次没做好，下次做好不就行了，谁都有没做好的时候。

更重要的是，今天比昨天做好一点。更重要的是，着眼于未来，这个项目下一个版本能不能比上个版本做得更好一点？

我们统一每周周二开项目进度会议，每个项目的情况都不一样，有些问题就是需要讨论很久，所以时间是无法评估的。

我们不可能要求什么时间内一定要开完项目进度会议，只能说项目负责人需要知道项目进度会议的流程，并且逐渐按照流程执行。

一般情况下，每周开一次项目进度会议，任务通常不会太多，通常一次会议所需时间应该不会太长，但是我们把项目会议流程梳理之后就会发现，时间是大大超出我们预期的，如下所示：

• 项目进度情况（20 分钟）
• 问题反馈讨论（20 分钟）
• 任务验收
  • 功能演示（20 分钟）
  • 代码抽查（20 分钟）
  • 文档查看（10 分钟）
  • Bug 修复情况（10 分钟）
• 后续工作安排
  • 任务安排（20 分钟）
  • 加班情况（10 分钟）

项目人较多时，就需要 2 个小时左右；项目人较少时，也需要 1 个小时左右。我觉得项目会议时间在 1 - 2 个小时之内是可以接受的，但是开到 3 个小时以上就有点问题了。

要解决问题，最终还是要回到问题本身。项目进度会议时间过长，你的诉求到底是什么？最要解决的本质问题是什么？难道真的是项目时间过长吗？

那我直接规定每次开会不能超过某个时长就好了，没必要在这里纠结那么多。

所以说，本质的问题不在项目会议时间过长，而在于这个项目进度会议的时间是否产生了价值，是否有必要。

那我们要清楚，到底是哪些问题，容易导致项目进度会议时间拉长呢？

我想了一下，可能是这三种情况。

2. 没有在会前准备解决方案

有些问题没有在会前自己捋一遍，然后根据自己研究的结果，给出多个解决方案，并整理到文档中，然后发到项目讨论群里，而是自己闷头在研究，简单在脑里想了下，觉得想明白了，等到项目进度会议上再深入沟通。

在项目进度会议上，没有什么文档，大家就一起参与讨论了，只是口头沟通，然后七嘴八舌的，说什么都有，这样行不行，那样行不行？

讨论没有任何依据，只是凭感觉，反正你一句我一句，再加上一些闲话，最终浪费了很多时间。

正确的做法应该是，在会前要把自己研究或者想到的解决方案，整理到文档中，要列举至少两三个方案，并把每个方案的优说明缺点清楚，最后在总结一栏，把自己推荐的方案标明清楚，并说明你选择该方案的原因。

当然你可能会说，有些难题是在会上反馈出来的，哪有时间去准备解决方案文档，很多都是靠沟通交流得出的。

如果是这种情况，那么可以简单沟通一下，然后回去整理好解决方案文档，发到项目讨论群里，然后叫上相关人员在座位上过一下，然后把最终结论补上文档即可。

3. 无关话题太多以及范围过大

有时在项目进度例会上，很多时候沟通是没有依据的，也就是没有围绕项目当前的情况进行，总是一连串旁枝末节的话题，一个接一个没完没了。

你说这些话题有必要讨论吗？

当然有的，但是要看当前项目的情况和时机。比如有些规划是大半年以后的，有些甚至是几年后都不一定要做的，这些话题进行深入沟通可以增长个人的知识面，但是在当前没有什么意义，完全可以在私底下去了解。

如果觉得很有用处，可以在了解之后，叫上几个人在座位上探讨一番，而不是在项目进度会议上。

比如讨论 App 的功能，说着说着，又说到 Flutter 最近好像不太平，Flutter 组又裁员了，然后还在 GitHub 上面搞了一个社区的分支，单独维护，然后说不计划合并到 Google 的主分支上了，然后又讨论 Flutter 是不是要完蛋了？那我们后续开发 App 要换不要技术方案？那老项目要怎么维护？Android、iOS、鸿蒙、微信小程序这些跨平台要怎么解决等等。

完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。

正确的做法应该是，紧跟当前项目核心问题进行讨论。比如上面的例子，App 的某个功能，在使用或实现上是否出现了问题，以及怎么解决这些问题？不要把话题扩散太广，避免违背了这个会议的初衷。

这个会议的目的是要解决项目当前的问题，不是新闻热点讨论会议。

4. 会议主持人没有做好把控

上面的问题，虽然源头都是会议前没有准备问题的解决方案文档、无关话题太多以及范围过大，但是，真正可以解决掉这个问题的，当然还是要回归到项目负责人对会议开展的把控上。

一看到有任何苗头，就可以立马打断，把话题拉回项目自身，而不是放任不管，浪费白白太多时间。

项目进度例会，我们担心有些人不说，但又怕有些人说太多，所以还是要灵活把控这个尺度，鼓励少说的多说，控制说多的少说，但目的是一致的，为了能及时暴露项目当前存在的问题，以及讨论出解决这些问题的方案。

至于无关紧要之事，可以会后私下里沟通。

5. 总结

项目进度会议时间过长的问题，最终还是要回归到这个问题的诉求上，也就是说，如果我们能够做到会议前准备好要讨论的问题的解决方案文档、减少无关话题、项目负责人做好会议进行的把控工作，那么应该是可以解决这个问题的。

第一步，项目负责人把当前项目情况进行汇报，然后重点问题说一下。

第二步，每个项目成员在自己的座位上，说一下上周做的事情，下周计划做什么，遇到什么问题。

第三步，散会。

但是，不同的阶段关注的重点不一样。

在项目进度例会中，对当前所做的工作进行验收，是很重要的一环，这些也在《16-项目的任务质量如何保证》中，把前因后果也说明清楚了。

本篇主要是探讨让项目负责人把全部功能进行演示和让项目成员依次汇报任务进度和演示，这两种方式不同之处在哪里？

首先，我们要知道，参加会议的人，什么样的心态都有。有的人现在遇到了很多问题，亟需在会议上反馈出来，然后帮助他解决这些问题；有的人觉得我现在忙得很，又天天开会，真烦，能不能少开一点、少说一点，让我赶紧忙完，要不然就得加班了；有的人觉得真好啊，最好开一整天，又可以摸鱼了，等等。在这些心态之下，各人的反应也会不一样。但更深层的一点是，多一事不如少一事，你要让他主动去说，那太难了，你问了才会说，不问就不说，甚至你问了，也可能因为性格等各方面的原因，都不太愿意说太多。加上大部分人都在会上刷手机，不会有心思听那么多的。

在这样的情况之下，让项目负责人把全部任务进度进行汇报并演示可验收的功能，很难覆盖到其他项目成员。他们本身不会觉得和这个会议有什么太大的关系，反正就是听一听，看一看手机，到了时间散会就完事儿。也许有些人可能有问题要反馈，但是他不会主动去提。

所以，项目进度例会的整体流程就要进行调整：

第一步，项目负责人要对项目当前的情况进行汇报，比如延期风险高不高？有什么重点问题？说一下，同步下信息，以及后续要注意哪些方面，等等。

第二步，就是要项目成员依次到前面来，而不是在自己座位上。把自己上周完成了哪些任务说一下，哪些任务进度怎么样也说一下，然后是演示一下自己开发的功能或者一些技术文档，最后就是遇到了哪些问题？需要现在就讨论和解决，然后就是下周计划做什么？把这些信息都记录在会议记录文档上面。

一方面可以减少项目负责人需要全面深入细节的工作；另一方面，可以侧面给项目成员一点压力。因为每次项目进度例会都要说一下工作内容，你如果上周完全都不用心，那么工作自然没什么产出，这样你总不能胡编乱造吧。

冥冥之中，不需要谁整天盯着你工作，你自己清楚，无形之中，就会有约束力，也减少了项目负责人的管理工作。

第三步，项目负责人把项目成员过进度中反馈的待解决问题，都记录到会议记录文档里面。下次项目进度例会，会看下待解决的问题是否已经解决。

第四步，项目负责人要根据当前项目进度情况，再次强调要重点关注的点，然后评估下是否需要加班。如有需要，进行加班安排。

第五步，散会。

相信按上面这个流程，可以有效解决项目成员在会议上没有深入参与的问题，并且能起到日常工作的一些约束，加强自我管理的意识，达成期望的工作目标。

本周的算法题为 3280. 将日期转换为二进制表示

给你一个字符串 date，它的格式为 yyyy-mm-dd，表示一个公历日期。

date 可以重写为二进制表示，只需要将年、月、日分别转换为对应的二进制表示（不带前导零）并遵循 year-month-day 的格式。

返回 date 的 二进制 表示。

示例 1：
输入： date = "2080-02-29"
输出： "100000100000-10-11101"
解释：
100000100000, 10 和 11101 分别是 2080, 02 和 29 的二进制表示。

实现代码如下：

const convertDateToBinary = function(date) {
    const [year, month, day] = date.split('-')
    const yearBinary = parseInt(year).toString(2)
    const monthBinary = parseInt(month).toString(2)
    const dayBinary = parseInt(day).toString(2)
    return `${yearBinary}-${monthBinary}-${dayBinary}`
};

解题思路：

1. 将日期格式的字符串拆分为年、月、日三个部分。
2. 利用 Number.prototype.toString() 方法中基数的特性，将数字转换为二进制字符串。

Review

Scientists discover new water purification microbes - Breaking News English Lesson

科学家们在我们脚下的地球中发现了一种以前未知的微生物。密歇根州立大学的研究人员一直在探索地球表面下方和上方的一个区域，称为临界区。这个区域对于提供维持生命的条件至关重要。研究人员将这些微生物称为 CSP1-3。微生物可能是净化水过程的关键部分。微生物学家 James Tiedje 说，虽然土壤层负责雨水的大部分过滤，但 CSP1-3 也是必不可少的。他说：“CSP1-3 是清理土壤表层的清道夫。他们的工作是净化我们的饮用水。

Tiedje 博士和他的团队专注于生活在我们脚下 200 米深处土壤中的微生物。他说，CSP1-3 微生物可以去除供水中的有害污染物和碎屑。他现在想在他的实验室中培养 CSP1-3，以了解更多关于它们的特性。他认为它们可以用来清理土壤中的污染。他说：“我们不知道它们代谢顽固污染物的能力，如果我们能了解这一点，我们就可以帮助解决地球上最紧迫的问题之一。scitechdaily.com 网站称：“了解这个新发现的群体可以促进保护工作并帮助应对气候变化。

Tip

在平时写邮件和使用 typora 软件写日记的时候，特别苦恼怎么能快速插入日期，比如写日记，每次都要复制昨天的日记文档，然后修改时间，很是繁琐，所以就研究了一下，结果发现使用搜狗输入法就很快实现了。

使用搜狗输入法，在中文模式下，输入 rq ，则会自动显示日期格式 年月日 ，如下所示：

如果输入 sj ，则会显示年月日时分秒，如下所示：

这样就可以快速插入日期了。

Share

一文读懂：PMF（product market fit）与产品管理

“一些初创企业，花很多的时间专注于他的新技术、新功能、新创意，不做用户访谈，花极少的时间验证市场需求、用户付费意愿，最后用一个产品去解决一个不存在的问题或者市场，拿着锤子找钉子，这样的结果大概率也是失败的。”

然而，深入分析后不难发现，这种做法存在一些潜在问题。首先，项目负责人可能对其他同事开发的功能并不熟悉；其次，项目负责人作为整个项目的负责人，在进行项目整体汇报时，若将主要演示职责交给开发人员，会导致职责划分不清晰，这不仅不利于项目负责人的个人成长，也不利于项目的顺利开展。

因此，项目功能演示环节最好由项目负责人全程主导，开发人员可适时进行补充。这样做的好处有三点：一是避免职责不清；二是增强项目负责人的责任感；三是促使项目负责人更深入地了解项目需求，因为只有真正理解项目需求，才能顺利进行演示，这也有助于后续的功能验收环节，其影响是多方面的。

归根结底，问题的根源在于项目需求与方案环节。项目负责人需要确保对项目需求有清晰、透彻的理解，虽然不一定亲自编写代码，但可以在脑海中模拟开发过程，至少要清楚功能的具体形态和使用方式。基于此，项目负责人可以在每周一提前浏览本周的任务，鉴于项目进度会议每周举行一次，本周需要实现的功能数量相对有限，亲自操作演示也不会花费过多时间，从而确保在周二的项目进度会议上能够清晰、准确地进行汇报。

对于那些能够在会议前完成合并的分支，其代码已成功合并至开发环境平台，此时仅需进行功能验收即可。然而，功能分支的代码需经过项目负责人的评审，但往往功能开发任务在当天刚刚完成，而项目负责人本身还承担着其他功能的开发任务，因此难以及时完成代码评审及合并工作。在这种情况下，该如何妥善处理呢？

一种可行的方案是Clone功能分支代码至本地，在本地环境中运行并进行验收。但这一流程存在诸多不便：需要Clone分支代码、安装依赖，且可能面临与本地环境不兼容的问题，还需进行微调才能成功运行，整个过程较为繁琐。在会议中花费大量时间进行此类操作显然毫无意义，那么如何简化这一流程呢？

一方面，可以在会议前与相关人员进行沟通，提前了解哪些任务已完成且已合并至Dev分支，哪些功能的代码尚未完成评审并合并至Dev分支。对于尚未合并的功能分支，可提前将其Clone至本地电脑，安装好依赖并成功运行，待开会时通过远程连接至本地电脑即可进行演示。

另一种方案是直接打开代码仓库GitLab，查看项目分支的代码，让负责功能开发的同事详细介绍该功能的实现方式以及代码的设计思路，这样既能解决上述问题，也能达到功能演示的目的。

此外，还可以考虑在现有的Dev、TEST、Staging、Master 四个环境之外，额外设立一个Preview环境。项目的各个功能分支，无论处于何种状态，均可立即合并至Preview环境。功能开发完成后，项目负责人可直接将该功能分支合并至Preview分支，解决合并冲突后通过CI/CD流水线自动部署至Preview环境，从而方便地进行功能演示。Preview环境主要用于功能演示，最终的代码合并仍需以Dev、TEST、Staging、Master 四个分支为主，项目负责人在完成代码评审后，需将功能分支代码合并至Dev分支。

通过以上提供的三种解决方案，包括项目负责人在会前做好准备工作、通过GitLab查看功能分支代码进行验收、提供Preview环境以便直接合并功能分支进行验收，相信可以解决会议上因代码没有合并，从而无法进行功能演示的问题。

项目的任务质量如何保证？在我看来，主要取决于以下这几个环节：需求要明确、任务开发时间要合理评估、任务需提供测试用例、在项目进度会议上进行功能演示。产品质量是生产出来的，不是检验出来的，不可能全都依赖于验收环节，毕竟那时已经晚了。验收环节只是为任务的质量加了一层防护，应从源头开始，就要不断地关注和解决存在的问题。

需求要明确

需求要明确，这一点在前面几篇文章中都反复提到过，这里就不再赘述了。简而言之，就是产品的需求要具体到可量化的程度。比如我要买苹果，应该是我要买10斤XXX牌子的苹果。

任务开发时间合理评估

在评估任务开发时间的时候，要根据实际情况，不能过于宽松。比如一个设备列表的功能排个两三天就差不多了，硬是排了一周多，这显然是有问题的。但也不能太严格，比如就给一天的时间，这就存心为难他人了，大可不必，实事求是就好了。

有人觉得开发任务只要时间够长，那么交付的功能质量一定就更好，实际上并非如此。人性本就如此，很少有人会提前完成任务，大部分人都会压到最后一刻才说做完了，不过，这也没什么可指摘的，人之常情。

所以，任务开发所需的时间，通常以一个“跳一跳能够够得到”的要求去评估即可。

**我们不会要求一个只能跑10公里的人去跑马拉松，我们只会要求他不断地跑到10公里、11公里和9公里，而不是他每次都只跑了5公里。**道理是一样的，没有什么是十全十美的，只希望每个人都能在自身能力范围内做到最好，仅此而已。

任务需提供测试用例

我们开发人员在开发完成之后，就匆忙提交任务进度为100%，意味着任务已经完成了。但是在验收人去验收的时候，还是经常发现这样或那样的问题。

为了解决这个问题，就需要把全部的问题都放到明面上，而不是藏着掖着，让大家都能清楚地知道，哪些功能确实是真的验收了。

这就需要开发人员在开发完成这个功能之后，提供一个自测报告，也就是在AgileTC测试用例管理平台编写这个功能的测试用例（在《AgileTC测试用例管理平台的基本使用》这篇文章中有介绍过如何使用），把全部功能要测试的点依次列出。

这样验收人在验收功能时，就可以根据这个测试用例，把全部功能都过一遍，有规范有依据，不会像之前那样混乱，到底哪些功能是没问题的，哪些功能是有问题的，一目了然，沟通效率也会更高。

以微信读书PC端的功能为例，图一为微信读书PC端的页面，图二为根据功能编写的测试用例，如下所示：

什么时候编写测试用例

上面提到的是在任务开发完成之后再编写测试用例，但如果在需求阶段就编写测试用例会不会有什么问题呢？

在需求阶段就编写测试用例，这种开发模式就是常说的TDD（测试驱动开发）模式。这个方式当然是可行的，但存在一个问题，就是最终交付的功能和最初的需求可能会有出入，导致之前编写的测试用例不能用了，需要重新编写。

首先，开发人员在需求阶段就编写测试用例，相当于在对需求进行分解，同时对需求也会更加了解，能和产品明确，达成共识，避免接下来出现返工的情况。

总体而言，测试用例等同于列出需求点，后续需求有变更，也不是全部测试用例都不能用了，很大概率只是个别测试用例进行微调而已。

所以，不管是在需求阶段还是开发完功能之后再编写，在我看来都可以的。

说到底，测试用例最终还是要围绕需求来编写，从需求中提炼出的测试要点才是真实有效的。所以，**对被测对象业务的熟悉程度，也决定了能否设计出高质量的测试用例。**毕竟，各功能点之间往往都是有关联的，会隐藏很多被我们忽略掉或者是想不到的测试用例。

在项目进度会议上进行功能演示

我们发现只有在项目进度会议上进行功能演示才会发现问题。开发人员通常口头上说“已经做完了”，这很有可能是片面的，并非开发人员存心欺瞒，只是每个人对需求的理解，有可能一开始就有差异，这种差异即便功能已经开发完成，还是可能会存在。

在项目进度会议上进行功能演示，整个项目团队的人员都可以看到，并且可以随时提出问题，虽然这样会增加会议的时间，但我相信这是值得的。

这其实也就是在敏捷开发模式中提到的Sprint Review环节，简单来说，就是解决颗粒度对齐的问题（笑），能让项目团队中的相关人员，包括但不限于产品、研发、测试和需求提出方等参与验收当前开发的功能，确认是否有需求理解偏差或潜在的需求调整，能够及时反馈和沟通，有助于项目下一步的功能优化和工作安排。

之前项目负责人去验收，实际上是不知道任务进度情况的，只有问了项目开发的同事才知道负责的任务完成了没有，项目负责人完全不知道有多少任务需要验收，完全是随机的状态，相应的其他事情的计划就又要变更了。那我们何不反过来，使用观察者模式，等开发同事完成任务后，给项目负责人发一下邮件或者企业微信的消息，一来形成闭环，二来强化开发同事任务是需要验收的这个意识。项目负责人这个时候立马去验收也可以，但不推荐，因为挨个去验收，精力就会分散，建议把可验收的任务整理记到下周一当天工作计划里，统一验收。后续等我们在线项目管理系统上线，里面就提供一个功能：如果开发同事任务完成，需提交技术文档（如有需要），然后把任务状态变更为待验收，这个时候，系统就会给项目负责人发一条可验收的邮件，相信可以有效解决这个问题。

召开项目进度会议的方式应依据部门的具体情况灵活安排。尽管一些部门的职能结构通常为项目总负责人、项目负责人，再到具体项目及其成员，但在实际召开项目进度会议时，通常有以下两种设计思路：一种是项目总负责人深度参与并引导会议；另一种则是授权项目负责人自行组织会议，而项目总负责人则另设专门的项目负责人会议。

项目负责人主导型会议

项目负责人主导项目进度会议的全过程。他们负责申请会议室、准备设备、在项目群中发布通知并召集相关人员参会，项目总负责人也会参与其中。会议中，无论是项目进度汇报、问题反馈、任务验收还是后续工作安排，均由项目负责人主导提出、讨论并解决问题，项目总负责人则主要扮演补充角色，例如指出潜在问题等。这种模式能够有效增强项目负责人的责任感，使其将项目视为自己的责任。换言之，项目负责人应明确，在项目事务中，他们行使的是权力而非义务。**权力是主动争取并愿意承担的事情，而义务则是他人强加的要求，二者意义截然不同。**许多项目负责人虽然参与了许多工作，但心态上仍与项目脱节，认为项目是上级安排的任务，只是机械地执行上级指令，而未意识到自己需要对项目的各个方面负责。

分层汇报机制会议

在这种会议模式下，项目负责人负责组织项目进度会议，而项目总负责人则主导召开项目负责人会议，用于听取各项目负责人的项目整体情况汇报。这种方式通常适用于规模较大的团队，且对项目负责人和项目总负责人的能力要求较高，实施起来并非易事。

为何项目会频繁出现加班的情况呢？究其根源究竟在哪里呢？从项目管理的角度出发，我认为项目负责人可能在以下几个关键环节存在不足之处，从而引发了加班现象的产生。

需求不够清晰明确

项目需求是否已经足够明确呢？例如，当我要开发设备列表这一功能时，上级给出的需求仅仅是一句“实现对设备的管理”，而没有细化到该功能的具体要求，比如页面默认应显示10条数据、需支持分页功能且分页选项为10、20、30、50和100条，还要支持按设备名称和设备ID进行搜索，列表要展示的表头包括设备名称、设备ID、设备型号等。

在需求沟通阶段，若未能明确需求的范围，就会使要做的工作存在过多不确定因素。就好比我要提一个需求，即“用一张纸剪一个圆”，如果只是简单地告诉对方“我要剪一个圈”，而对方仅凭感觉去剪，剪好后我却觉得不满意，要求剪得小一点，但又没有明确具体要多小，对方只能凭借自己的感觉不断尝试，直至剪出令我满意的结果为止。在这个过程中，对方其实一直在进行返工，这无疑就变相导致了加班的情况出现。

正确的做法应当是，在告知对方要剪一个圆时，直接将圆画在纸上，待双方沟通确认之后，对方只需剪一次即可，从而避免出现反复返工的问题。

项目缺乏充分的预研工作

在项目的预研阶段，项目负责人需要在脑海中对项目从无到有的整个过程进行全面且深入的分析，将可能出现的问题逐一梳理，并且提供相应的解决方案，而不是仅仅依据需求阶段沟通好的需求，就仓促地开始着手实施。

需求阶段的工作做到位只是基础的第一步，接下来的第二步就是要以终为始，从最终结果开始倒推，思考可能会遇到哪些问题呢？这个功能采用何种技术来实现呢？这个饼图应该使用哪个插件来制作呢？这个3D动画效果是选用哪个第三方库来实现，还是自行开发呢？天气数据又该使用哪个平台呢？客户提出的这个需求是否真的能够实现呢？类似这样的一系列问题都需要项目负责人提前想清楚，并且做到心中有数，甚至对于一些功能难点，还需要制作一个Demo来进行验证。

倘若在这一阶段没有做到位，仅根据需求评估项目的开发计划，并且向客户承诺交付的时间，那么在项目推进过程中，一旦发现存在无法解决的问题，或者某个环节比预期花费了更多时间，为了应对这种阻碍项目推进的突发状况，项目负责人往往只能被迫安排加班，否则就无法按照预期完成项目。简而言之，就是前期预研工作没有做到位，从而意外地遇到了隐藏的暗礁。

临时插入需求导致的问题

其实关于项目推进过程中出现紧急需求插入的情况，已经在《10-项目需求变更时如何处理》这篇文章中有所提及，当遇到这种情况时，应该如何妥善解决呢？这里就不再重复阐述了，只是想说明一下为何这种情况下会出现加班的情况。原因就在于项目负责人没有充分按照《10-项目需求变更时如何处理》中提到的方案去操作，而是盲目地接下来，完全不进行沟通，只要上级提出任务，就理所当然地认为上级是知晓当前项目情况的，如果自己有不同意见，可能会给上级留下不好的印象，会被认为是身为项目负责人，稍微增加一点工作量就开始抱怨。于是，就硬着头皮接受了任务，但此时已经有正在进行的工作了，新增的任务必然需要额外的人力和时间去完成，那么在这种情况下，只能安排加班，否则还能怎么办呢？最终项目没有如期达成，被上级批评，而项目负责人自己却感到非常委屈，明明项目团队天天都在加班，只是差了一点点就完成了，却还要被批评，心里十分不爽。这就是典型的吃力不讨好，没有及时与上级进行沟通。很多人总是错误地认为上级是全能全知的，上级的决策一定都是正确的，既然上级安排了临时任务，那一定是有其原因的，也一定知道我正在忙很多事情。这种想法是不可取的。类似这种情况，由于项目需求变更、临时插入紧急任务，一定要及时向上级反馈，不能等到事情搞砸了，再去找各种理由，即便理由再充分，但项目没有按照预期交付，这个结果就是工作没有做好。

关于加班的合理时机

说实话，其实我是很反对加班的。虽然我加班还挺多的，但并不是因为我加班多才反对的，主要是加班要加得有意义，加班本身不应成为目的。然而，许多人却将加班视为勤奋的象征。例如，有人会说：“我一个月加班近50个小时，这难道还不算努力吗？”我见过太多人在正常工作时间内拖沓，却把事情留到加班时间去完成，这种行为毫无意义。

加班应该是应对突发情况的手段，而不是常态。比如，当服务器突然宕机，或者线上平台的关键功能无法使用，严重影响用户体验时，这种紧急情况需要立即解决，加班是必要的。这种加班才是有意义的，因为它解决了实际问题，避免了更大的损失。

许多硬性安排的加班往往只是形式主义，大多数人只是在“摸鱼”，不会关注“今天把事情做完”的重要性，不会追求提高工作效率，只是在凑时长而已。

甚至有些人认为“我做得越快，不就是做得越多吗？”这种想法有一定道理，但关键在于如何利用时间。如果你担心完成任务太快会被认为无所事事，那么可以利用剩余时间学习新技术、阅读专业文章，提升自己，这才是更有意义的做法。

如果遇到问题，无法解决，应该怎么处理？其实，这个问题要从两个不同的视角来探讨：一个是项目成员的角度，另一个是项目负责人的角度。假设项目成员是李四、王五，项目负责人是张三。

及时反馈

比如项目成员李四，有一条功能开发的任务，工期为5天。在开发过程中，他遇到一个无法解决的问题，一个人琢磨了一两天，但始终无法突破，就这样卡在了这个点上。他的心路历程可能是这样的：一方面，他担心自己的技术能力不足，觉得这个问题在别人看来可能很简单，自己居然解决不了；另一方面，他想死磕到底，觉得遇到这样的技术难题，如果不解决就太不甘心了。这些想法本身没有问题，毕竟谁都不想被别人说技术菜，而死磕难题正是极客精神的体现，值得鼓励。

但问题在于，这种心态放在项目团队中可能会带来隐患。项目最终看的是产出和结果，而不是个人的技术表现。只要项目能够完成，其他因素都是次要的。从这个角度看，担心被人说技术菜、死磕技术难点，都变得毫无意义。因为解决问题的方式并不唯一，不一定非要从技术入手。比如，李四可以把问题及时反馈给项目负责人张三，由张三组织项目团队讨论，甚至与客户沟通，看看是否可以通过微调需求来解决问题。也许客户的需求，用另一种呈现方式同样可以满足，而无需纠结于技术实现本身。

有人可能会问，如果讨论后发现确实只能通过技术手段解决呢？如果项目负责人张三已经召集项目团队进行讨论，仍然没有解决方案，那又有什么可害怕的？大家绞尽脑汁都没能解决，怎么能说明李四技术很菜呢？如果有人质疑，他完全可以回怼：“你那么厉害，那你来试试看。”

所以，项目成员遇到问题，如果已经使出浑身解数，还是没能解决，要及时反馈给项目负责人，要从项目全局角度考虑问题，而不只是个人的维度。你及时反馈，虽然是别人给你的解决思路，但最终执行的是你，这条任务还是你来完成的，而你如期完成了这条任务。

小心“猴子”

上面是项目成员李四的角度，那么从项目负责人张三的角度来看呢？

如果项目成员不是像李四那样闷头死磕问题，而是遇到问题就立即反馈，比如王五，张三应该如何应对？

有些项目负责人可能会及时介入，觉得自己项目同事遇到了问题，自己当仁不让，当然要身先士卒，冲到最前面了。这个本来是很好的行为，出发点也是好的，但这样做的结果是，原本属于王五的开发任务可能完全变成了张三的工作。这就是我们常说的**“小心下属的猴子跳到上级身上”**的问题。王五可能因此变得依赖，而张三则疲于奔命，吃力不讨好。这种情况本质上取决于项目成员的性格和工作态度。如果是这种倾向明显的同事，张三首先要做的不是直接介入，而是反问王五“有好好研究过了吗？”，如果王五支支吾吾，那就先让他自己研究一下，不要遇到点小问题就退缩，如果王五说已经研究过了，那张三就需要及时调整王五任务的优先级，让王五先做其他事情，避免他无所事事，自己再介入。

意思就是说，对于项目成员反馈的问题，张三可以介入协助，但最好只提供解决问题的思路和建议，比如分享自己调研到的可行方案，然后交给王五去验证。张三的角色主要是引导作用，而不是直接接手去解决问题。他需要激发项目成员的主动性，让他们在遇到问题时真正动脑思考，而不是轻易放弃。如果最终仍然没有解决方案，张三可以召集相关同事讨论，甚至向上级反馈，让更高层来做决策。

所以，项目负责人在处理项目成员反馈的问题时，应避免替团队成员承担过多责任，而是通过引导和协调，激发他们的主观能动性。一来项目成员可以得到锻炼，二来项目负责人可以投入精力在更重要的事情上，这对于项目团队而言，是大有裨益的。

有人提议是否可以申请一些设备常驻我们部门，让项目相关人员在开发过程中能够随时试用设备，真实感受应用场景，同时遇到问题时可以立即用设备重现和排查。这个想法确实有一定道理，但仔细想想，设备本身也在不断迭代，如果设备长期放在我们部门，可能只能停留在某个版本，后续更新无法跟上，反而会限制我们的开发思路。此外，设备的使用频率主要集中在开发阶段，项目上线后很少再被关注，长期占用硬件资源可能造成浪费。

其实，我们的核心问题并不是设备是否常驻，而是如何让开发人员在开发阶段有机会试用设备，从而增强对业务的理解和对设备功能的熟悉。与其申请设备常驻，不如在开发阶段短期借用设备，确保开发人员在关键阶段能够充分接触和使用设备，同时避免资源的长期占用。这样既能满足开发需求，又能兼顾资源的合理利用。

项目遇到需求变更，通常都是新增需求，很少是减少需求的变更。简而言之，就是增加了工作量。而项目负责人面临的难题在于：如何在不影响整体计划的前提下，高效应对这种变化。需求变更的规模有大有小，不可一概而论。如果是小的变更，那无伤大雅，适当微调即可。但倘若是很大的变更，比如新增的功能开发需要一两周甚至更长时间，那么整个项目计划可能就需要推倒重做，这无可厚非。

我们要探讨的是介于这大小之间的需求变更——那些有机会在当前计划里解决掉的需求，比如增加了一周的工作量。你有信心能按当前制定的计划如期交付吗？现在的情况是，我们可能只是将需求变更分为大小两个情况：小的微调，大的立刻调整项目计划，然后项目上线时间就会变更。久而久之，这种处理方式可能会让人觉得理所当然。

事实上，大部分项目开发工作是有协商空间的，并未被完全限定死。遇到突发情况，比如客户需求变更，但交付时间没有任何商量余地时，项目负责人该怎么办？有人可能会说加班，但有时加班未必能解决问题。

也许现在我们可以慢慢培养这方面的意识和能力，在平时多积累这方面的经验，避免真正遇到事情时手忙脚乱、无从下手。也就是说，我们可以将需求变更分为三种情况：小的变更，微调即可；大的变更，比如需要增加两周工作量，那就变更项目计划；中等变更，比如需要增加一周工作量，我们先不急于调整计划 ，而是先想一想：有没有什么办法可以在不变更计划的情况下解决这个问题？然后将各种可能的解决方案列出来（1、2、3……），召集项目其他成员一起讨论。也许经过多轮讨论，我们就能找到解决方案。如果讨论后仍无法解决，再根据实际情况变更项目计划。

举个例子，设备管理模块的开发需要张三负责后端，李四负责前端。如果将他们的任务写在一起，当前进度显示为60%，我们无法直接了解具体情况。这个60%可能意味着后端已完成，只是前端还在开发；也可能是后端和前端都还未完成。这样一来，项目负责人就不得不去沟通询问，才能知道真实情况，这无疑降低了工作效率。

因此，项目开发计划里的任务最好是一人一条，拆分清晰。这样做的好处有两个：一是可以明确职责，避免出现责任不清的情况；二是任务状态会更加透明，项目负责人能够一目了然地掌握每个环节的进展，从而减少管理难度。

如下图所示，当任务拆分清晰后，我们可以立刻知道设备管理功能模块的后端开发进度为100%，已经完成，而前端开发进度为20%。这样一来，项目负责人就能根据这些信息及时调整计划，合理安排后续工作，确保项目顺利推进。

之前有APP项目就是这样的情况，本来APP功能已经开发好了，然后测试阶段，设备经常出现问题，可以用但是又不稳定，经常测到一半就测不下去了，然后反馈给到设备那边，改了好几次，觉得可以了，又继续测试了，后来还是不行。反复多次我才醒悟苗头不对，不能再这样下去了，立马中止项目测试，和设备那边沟通，设备需要确保完全没有问题，再继续这个项目的工作，可以说是血的教训。

这个问题之所以会造成那么大的影响，是因为我们在和他人协作的时候，没有和对方明确一个具体的时间节点，而是很含糊地回答道：“等某某完成了我才可以对接”，然后再问一句：“那他什么时候可以做完呢？过几天吧”，到底是几天？哪一天的？不知道呢。这样是有隐患的，因为这些模糊的信息，负责对接的开发同事完全就是看天吃饭了，任何结果完全是随机的。过几天，可能是一天，也可能是两天，甚至是一周或者更多，再者，项目负责人调整项目任务的时间也会变得很困难。

我们需要和对方明确一个具体的时间节点，比如前端同事需要问下后端的同事，接口是哪一天可以提供使用，而这个使用的意思，基本上是自测过的，不说一个Bug都没有，至少是相对稳定的。我们知道这个具体的时间节点之后，就可以先安排其他事情了，项目开发工作的开展就会很清晰，而不是完全混乱的。

项目负责人的开发任务应比项目成员提前3天左右时间结束，这个时候项目的其他功能还在继续开发，项目负责人可以借机着手准备下个阶段的任务（之所以是下个阶段，而不是下个版本，是因为有可能不是迭代这个项目了），将需求进行梳理分析，编写方案设计和制定开发计划，等到其他项目成员开发任务完成之后，就接着下个阶段的任务进行，项目负责人这时再回到当前项目，去做内部验收和提交测试申请，整个衔接是很清晰顺畅，不至于那么被动，捉襟见肘。

可能会造成项目延期，在上一篇文章《05-项目为什么总是延期》中已经分析过了，这里就不再赘述了，我们现在要探讨的是，如何制定一个项目计划呢？

在开始项目计划制定之前，可以先了解一下开发模式的相关知识，这部分主要是《【清华大学】项目管理的逻辑（全6讲）》里面的内容，有兴趣的可以去看一下，还是很不错的。

1. 瀑布式开发

预测型开发，在还没有开始着手编写代码前，就可以提前预知结果如何，之所以叫瀑布式，是因为整个开发流程都是有序的，就像水从上往下流，每一步做很到位就到下一阶段。

2. 迭代式开发

迭代式开发，顾名思义，就是一个版本接着一个版本进行迭代，先将项目整体框架搭建好，然后基础布局全部铺开，就好像画人物肖像一样，先勾勒草图，画出人物整体轮廓，然后才依次画出脑袋、眉毛、眼睛、鼻子、嘴巴等等，全部画出来之后，才是着色。

3. 增量式开发

增量式开发，咋听之下，与迭代式开发的意思一样，实际上是不一样的，增量式开发的意思是，每次只构建一点，每个阶段就交付一部分，然后组合在一起，还是用画人物肖像来举例子，一开始先画头发，画完之后上色，然后接着是眉毛，画好之后着色，以此类推，全部画好一个地方再接着画另一个地方，如下图所示：

4. 敏捷式开发

适应型开发，灵活性很高，需求可以随时提，然后放到需求池里，可能两周一个周期发一个版本。因为能干的活儿很有限，就像坐地铁一样，人很多，挤不上去那就下一趟，所以敏捷开发的思路就是，未必做得到，所以下个版本实现需求，可以有节奏地持续开发。

以上就是常用的开发模式，但是我们在实际应用中，应该怎么选择哪一种开发模式呢？为此有一个STACEY矩阵图可以作一些参考，如下所示：

从上图中可以知道，选择哪种开发模式，是基于需求和技术两个维度去评估的，所以项目负责人在编写项目需求与方案文档的时候，可能就可以做出判断了。说回我们自身，开发模式毕竟只是项目管理中的一种技巧，要深刻认识到它并不是万能的，如果掉入盲目迷信权威的陷阱，那么就太死板了，真正应用的时候，还是要考虑实际情况，在遵循基本原则的基础上，要明白事物变化的重要性，在变化的世界里使用不变的方法是不现实的，没有任何一种开发模式能够适用全部的项目。

现在部门按照项目来管理，每个人都比较清楚自己要做的事情，也没有那么多交叉的任务，所以变更理应很少才对，在制定项目计划的时候，我们可以把项目开发的周期全部列出，虽然项目计划通常都会有变更，但项目计划最好能够做到有始有终，把全部任务时间明确一下，然后项目交付时间基本就确定了，其中的任意环节有变更，很有可能是不会影响到项目交付时间的。我们可以把项目计划分为11个环节，如下所示：

1. 需求分析
2. 原型设计
3. 方案设计
4. 开发计划
5. 开发阶段
6. 下版计划（下一阶段任务计划）
7. 内部验收
8. 产品验收
9. 测试阶段
10. 模拟升级
11. 正式发布
12. 复盘会议

如下图所示，就是根据这11个环节制定的项目开发计划，虽然实际情况会有所出入，但是可以知道这个项目12月底基本上就可以交付了，有这样很清晰的时间节点，对于接下来的开发工作，会更有目标和方向感，其中经常出现任务变更，大多是在开发阶段，但是并不代表做好这个环节就没事了，接下来的环节如果遇到问题，也是会影响到项目交付的，所以怎么能管理好一个项目，是需要多方面去思考和解决问题的，并不是只做好开发任务环节就行了。

之所以会这样，是因为在项目推进过程中，我们聚焦的一直是解决项目当前遇到的难题，为了解决这个难题，不断地调整项目任务计划时间，明天后天下周下个月等等。也许我们可以转换一下思路：项目推进过程中，以终为始，以最终结果为导向，聚焦项目上线发布这个目标。为了达成这个目标，我们要采取不同的做事情方式，也就是多维度思考如何解决问题。

导致项目进度受阻的问题有大有小，如果是不可抗力的情况（比如有的项目需要用到设备，结果设备完全用不了），那当然没有办法，但这种情况相对来说还是比较少的。其他的那些问题就要想一下，是不是当下一定要解决，或者说一定要从技术层面解决才行呢？那当然不是，我们的需求只是解决问题，问题解决了就行，并不关心用了什么方式。就好像要从广州到北京，需求只是要去到北京，并不在乎你怎么过去，是要坐飞机、坐动车、自己开车或者打车什么都可以，只要能到北京就行。

在项目推进过程中，项目负责人遇到问题时，以前可能是这样思考的：“这个问题解决起来很困难，可能需要5天的时间，我要问一下，项目计划能不能变更，调整一下上线的时间？“现在的话，如果是以终为始，可能就需要这样思考了：“这个问题解决起来很困难，可能需要5天时间，这个版本计划11月15日上线，时间有点紧张——这个功能是不是必须的？一定是这个版本要加的么？能不能下个版本？为什么需要5天的时间，有没有其他更好的解决方案？5天的时间里，我是不是可以先做其他事情？测试阶段、发版阶段还有没有什么潜在的问题？第三方编译走通过了么？时间有点赶，问题有点多，可能要动员一下，让大家知道现在时间有点紧张，加加班才行了，宁愿赶在前面，也不要后面遇到问题了没时间解决。”

我们倾向于哪怕只是一点点可能性，也要挣扎一下，不要那么容易就缴械投降。还是要回到小平同志说的那句话：“不管黑猫白猫，能捉老鼠的就是好猫。”

这种状况容易导致项目管理出现诸多问题，表面上看似平静，实则处于一种失控状态，主要体现在以下几个方面：

1. 任务时间评估不到位：项目负责人由于对整体功能和需求缺乏深入了解，导致在评估任务所需时间时不够准确，经常需要变更任务计划，影响项目进度的稳定性。

2. 风险意识不足：由于对业务不够熟悉，项目负责人无法提前识别潜在的延期风险因素，也无法有效判断是否需要安排加班来应对可能出现的问题，从而增加了项目按时完成的不确定性。

3. 任务验收困难：在验收功能时，由于项目负责人对业务和需求不够了解，只能依赖开发同事的回答来判断功能是否实现以及是否与需求一致。这种情况下，验收工作往往流于形式，难以深入和全面地评估功能质量，导致验收工作的积极性和效果都不理想。

为了解决这些问题，项目负责人需要自行梳理一份详细的项目需求与功能实现文档。比如下图所示的文档格式。在文档中，将每个功能按照“是什么”、“为什么”、“怎么做”这三个问题进行清晰的梳理和记录。在项目推进过程中，一旦出现需求变更，应及时更新文档，确保项目负责人对项目的整体情况有清晰的把握和了解。

1. 开发能力

项目里自己负责开发的功能高质量完成，基本可以认为是可以直接给客户演示的标准：功能没有特别重大的Bug（例如不会突然崩溃或无法使用）；功能边界定义清晰（例如手机号输入有格式限制，且包含正确提示和异常处理）；界面交互流畅，避免出现逻辑混乱的页面跳转；视觉细节完善，连一个像素的偏差都会调整到位。

2. 方法论沉淀

项目里自己开发的模块业务非常熟悉，但其他人负责的部分了解不足；能够独立完成需求理解、方案设计、开发计划制定、内部验收、测试提交和项目上线全流程，对分配到的模块有完整把控力。

3. 产品化思维

对项目中所有业务需求的关联性和实现路径一清二楚；熟练使用项目涉及的硬件设备及相关配套产品；如果由你主导，能够完成产品需求文档和原型设计，并对需求合理性提出专业建议。

4. 技术全局观

突破单一技术栈限制，例如前端出身的负责人掌握后端核心技术逻辑，后端负责人熟悉前端核心实现原理，能够主导跨技术栈的方案设计与协作。

5. 市场价值洞察

从技术执行转向产品驱动，深入理解产品的市场定位与核心价值（例如清楚产品解决什么痛点、目标用户是谁）；关注产品的市场推广策略与用户增长，推动技术方案适配市场需求。

对于项目负责人而言，他需要明白项目管理的意义。根据我个人的一些经验，总结了以下三点，分别涉及一个项目完整的周期，即开始、过程和结束。

一致性

目标一致、步伐一致，项目中的全体成员都需要知道，我们的目标是什么？并将全部精力投入到达成目标的要事上面。在这个过程中，间接实现了项目降本增效，还有提高团队的凝聚力。

及时性

项目进行过程中，无时无刻都在发生变化，不管是项目制定的计划，还是遇到了业务或技术难点，及时了解到当下的情况，尽快解决问题，可以避免项目进度受阻。

高质性

项目完成并不意味着没有问题，质量如何保证，就需要项目负责人进行项目的验收，不然怎么知道已经完善了呢？

以上这三点都是对于项目而言，那么对于项目负责人来说，意义又在哪里呢？

那就是一个人的成功（做好事情）固然值得肯定，但如果他能将这种成功因地制宜地在团队其他人身上应验，那将意义深远。一方面，团队里的成员能力有所提升，对项目上面的工作肯定是有帮助的；另一方面，我们都知道每个人都有自己对世界的一套认知，怎么做事情，都有自己的方式，我们只是一直在摸索那条规律，不断应验和调整。如果其他人也适用，那至少说明，你的一整套理论是有可取之处的，越来越靠近那条规律；如果不适用，那也可以借机进行反思和完善，对你而言是大有裨益的。这也是教员《实践论》里提到的观点：“人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。”

这些内容是我在2022年8月编写的，当时在部门内部进行了分享，主要涉及项目管理知识和个人工作经验总结。最开始我是计划以写书的方式系统整理这些内容，但因种种原因一直搁置。现在我觉得，事情还是越早开始越好，因为不同阶段的工作重心会有变化。若一味拖延，可能错失深入处理细节的机会，而且时间越久，当初的感受和体会也会淡去，相应的观点也可能会有出入。因此，现在就开始着手整理吧。

你可能是项目中的开发能手，最佳情况也只是能保证自己负责开发的功能没有问题，其他的你是无法保证的。哪怕你承担了项目中全部的开发工作，测试阶段、验收阶段和发布阶段也是需要其他人协助的。假设这些你都可以自己完成，而且也做得很到位，但要是需要该项目在很短的时间内交付，想必你就没有办法了。一个人的能力不管多高，人的精力终究是有限的，任何事情能够得到一个比较满意的结果，都离不开众人的努力，对于项目而言也是如此。

在推进多项目管理过程中，反馈出来不少问题，我针对这些问题进行了分析，并且提供了一些相应的解决方案。不过这些方案不一定全对，只是我个人的一些反思总结和心得分享。我计划把内容分为意识、能力、方法、提升和附录这几个部分。意识主要是项目管理意识方面的探讨，意识是这一切的基础，意识没有到位，后面的其他方面做得再好，也是有局限性的，就像一棵大树，树根没有长好，枝干树叶的成长也是有限的。因为意识很重要，所以把它放在前面。能力主要是探讨项目管理应该具备哪些能力。方法主要是项目管理方法上面的探讨。至于附录，是一些有助于提升项目管理能力的书籍摘要。

本周的算法题为 2351. 第一个出现两次的字母

给你一个由小写英文字母组成的字符串 s ，请你找出并返回第一个出现 两次 的字母。

注意：

• 如果 a 的 第二次 出现比 b 的 第二次 出现在字符串中的位置更靠前，则认为字母 a 在字母 b 之前出现两次。
• s 包含至少一个出现两次的字母。

示例 1：

输入：s = "abccbaacz"
输出："c"
解释：
字母 'a' 在下标 0 、5 和 6 处出现。
字母 'b' 在下标 1 和 4 处出现。
字母 'c' 在下标 2 、3 和 7 处出现。
字母 'z' 在下标 8 处出现。
字母 'c' 是第一个出现两次的字母，因为在所有字母中，'c' 第二次出现的下标是最小的。

实现代码如下：

const repeatedCharacter = function (str) {
    let earliestRepeatIndex = Infinity;
    for (let i = 0; i < str.length; i++) {
        // 如果出现了第一次和最后一次的位置不相等，则表示有2个以上存在
        if (str.indexOf(str[i]) !== str.lastIndexOf(str[i])) {
            // 第一个出现两次的字母，则关键点就在第二次出现的位置，谁最靠前（indexOf越小），那么该位置的字母就是所求的值。
            const secondOccurrenceIndex = str.indexOf(str[i], str.indexOf(str[i]) + 1);
            earliestRepeatIndex = Math.min(earliestRepeatIndex, secondOccurrenceIndex);
        }
    }
    return str[earliestRepeatIndex];
}

解题思路：

1. 如果出现了第一次和最后一次的位置不相等，则表示有2个以上存在
2. 第一个出现两次的字母，则关键点就在第二次出现的位置，谁最靠前（indexOf越小），那么该位置的字母就是所求的值。

Review

Fog harvesting could provide water for dry cities - Breaking News English Lesson

全球许多地区降雨稀少，人们每日获取饮用水都面临巨大挑战。科学家发现了一项可能帮助世界最干旱城镇的新技术——从雾中收集水分，这项技术有望为数百万人口提供饮用水。智利研究人员正在探索"捕雾取水"技术的应用潜力。这项技术原理简单：在立柱之间悬挂巨型网状幕帘，当云雾穿行其间，水滴附着在网格表面，最终汇聚成水流通过下方管道导入储水罐。这种低成本、易操作的集水方式为干旱地区提供了新选择。

来自首都圣地亚哥私立大学马约尔大学的研究团队，在年均降雨量不足5毫米的沙漠小镇阿尔托奥斯特西奥开展实地测试。当地居民日常饮用水主要依赖卡车运输。研究负责人弗吉尼亚·卡特·甘贝里尼博士指出，这项技术将开启"新时代"，其研究"标志着雾水资源利用认知的重大转变——从局限于农村地区的小型解决方案，升级为适用于城市的实用水源"。她补充道：“云雾中的水资源既能提升城市应对气候变化的能力，又能改善清洁水源的获取条件。”

Tip

在 Windows 中，端口被占用，怎么解决？

在 Windows 下检查端口 503 是否被占用，以管理员身份运行 “命令提示符” 窗口，使用命令检查当前端口使用的进程：

netstat -ano | findstr :503

然后记下状态为 LISTENING 的数字（例如 39880），然后使用以下命令，终止进程：

 taskkill /PID 39880 /F

Share

《大才非学不成》 [明·郑晓]

胆欲大，心欲小；智欲圆，行欲方。大志非才不就，大才非学不成。学非记诵云尔，当究事所以然，融于心目，如身亲履之。南阳一出即相，淮阴一出即将，果盖世雄才，皆是平时所学。志士读书当知此。不然，世之能读书能文章不善做官做人者最多也。

​

本周的算法题为 1566. 重复至少 K 次且长度为 M 的模式

给你一个正整数数组arr，请你找出一个长度为m且在数组中至少重复k次的模式。

模式是由一个或多个值组成的子数组（连续的子序列），连续重复多次但不重叠。模式由其长度和重复次数定义。

如果数组中存在至少重复k次且长度为m的模式，则返回true，否则返回false。

示例 1：

输入：arr = [1,2,4,4,4,4], m = 1, k = 3
输出：true
解释：模式 (4) 的长度为 1 ，且连续重复 4 次。注意，模式可以重复 k 次或更多次，但不能少于 k 次。

实现代码如下：

const containsPattern = function(arr, m, k) {
    const n = arr.length;
    if (n < m * k) return false;

    for (let i = 0; i <= n - m * k; i++) {
        let valid = true;
        for (let j = 1; j < k; j++) {
            for (let pos = 0; pos < m; pos++) {
                const currentPos = i + j * m + pos;
                const patternPos = i + pos;
                if (arr[currentPos] !== arr[patternPos]) {
                    valid = false;
                    break;
                }
            }
            if (!valid) break;
        }
        if (valid) return true;
    }

    return false;
};

解题思路：

1. 首先检查数组的长度是否至少为 m * k。如果不足，则直接返回 false。
2. 遍历所有可能的模式起始位置 i，确保这些位置可以容纳至少 k 个连续的模式（即 i 的范围是 0 到 arr.length - m * k）。
3. 对于每个起始位置 i，检查从该位置开始的连续 k 个模式的元素是否完全一致。直接通过数组索引比较元素。

Review

New Zealand relaxes visa rules for ‘digital nomads’ - Breaking News English Lesson

对有意在新西兰工作的人来说，这是一个好消息。该国放宽了签证政策，希望吸引"数字游民"在当地居住和工作长达九个月。数字游民指能基于远程在线工作方式在任何地方生活的人群。新西兰推出新签证，允许境外雇主员工在该国远程工作三个月，并可延长至九个月——但停留满九个月者可能需要缴税。经济增长部长尼古拉·威利斯表示，新政策旨在"让更多富裕且极具才华的人通过入境口来到新西兰"，以促进经济发展。

近年来该国经济面临多重挑战：新冠疫情重创的旅游业尚未恢复至疫情前水平，青年人才流失问题加剧——当前二十余岁年轻人赴海外工作数量创历史新高。移民部长埃丽卡·斯坦福预计，新签证持有者在境内停留时间延长将刺激消费，“更重要的是希望他们能爱上这个地方”。

Tip

DeepSeek满血版使用

年前使用DeepSeek还挺顺畅的，没想到过年期间突然爆火，导致流量暴涨。再加上美帝“亡我之心不死”，天天攻击，服务器经常繁忙，有时候重复提问20多次都没反应，实在忍不了了，只能研究其他渠道来使用深度思考（R1）功能。

经过一番查找，发现可以使用硅基流动（SiliconFlow）提供的服务。硅基流动与华为云联合推出了基于昇腾云的DeepSeek R1 & V3推理服务。使用邀请码注册：https://cloud.siliconflow.cn/i/wDEipqNd，可以赠送14块钱，足够用很久了。不过，由于这是API调用的方式，历史问答的内容无法保留，因此需要结合Cherry Studio客户端软件来使用。

当然，如果觉得麻烦，也可以考虑使用360的纳米AI搜索的慢思考模式，或者kimi的k1.5长思考模式。不过，就推理方面来说，还是觉得DeepSeek更有意思一些。

Share

哈哈哈，实属蚌埠住了。

本周的算法题为 1156. 单字符重复子串的最大长度

如果字符串中的所有字符都相同，那么这个字符串是单字符重复的字符串。

给你一个字符串 text，你只能交换其中两个字符一次或者什么都不做，然后得到一些单字符重复的子串。返回其中最长的子串的长度。

示例 1：
输入：text = "ababa"
输出：3

实现代码如下：

const maxRepOpt1 = function (text) {
    const count = {};
    for (const char of text) {
        if (!count[char]) {
            count[char] = 0;
        }
        count[char]++;
    }

    let max_length = 0;
    const n = text.length;

    for (let i = 0; i < n; i++) {
        const char = text[i];
        let length = 1; 
        let j = i + 1;
        while (j < n && text[j] === char) {
            length++;
            j++;
        }
        if (length < count[char]) {
            if (j < n && text[j] !== char && j + 1 < n && text[j + 1] === char) {
                let k = j + 1;
                while (k < n && text[k] === char) {
                    length++;
                    k++;
                }
                if (length < count[char]) {
                    length++;
                }
            } else {
                length++;
            }
        }
        max_length = Math.max(max_length, length);
    }
    return max_length;
}

解题思路：

1. 使用一个对象 count 来统计每个字符的出现次数。遍历字符串，将每个字符的出现次数记录在 count 中。
2. 使用一个外层循环，从每个字符开始，向右扩展，找到当前字符的最长连续重复子串。
3. 如果当前子串长度小于该字符的总出现次数，尝试检查子串两端是否有相同字符，或者中间是否有不同字符可以交换。
4. 每次找到一个更长的子串时，更新 max_length。

Review

Lunar New Year sees record migration in China - Breaking News English Lesson

春节是中国最重要的节日。数亿人会返回家乡庆祝这一传统佳节，今年也不例外。机场、火车站和汽车站挤满了踏上年度返乡之旅的旅客。今年对应中国十二生肖中的蛇年。庆祝活动从1月29日开始，持续长达16天，其中前七天是国家法定假日。路透社报道称今年出境游尤其受欢迎，援引某旅行社数据称"平台出境航班和度假套餐预订量较去年翻倍"，最热门目的地集中在亚洲地区。

美联社将中国春节称为"全球最大规模的年度人口迁徙"。随着中国现代化高速交通网络的发展，春运流动人数呈几何级增长。新华社预计今年出行人次将"创历史新高"。3500年前春节雏形初现时，离乡者寥寥无几。但随着中国经济腾飞，数十亿人因工作、求学或追求更好的生活在全国各地迁徙。这场年度迁徙潮成为经济助推器，旅游、酒店和零售行业在此期间迎来利润增长。

Tip

通过TeamViewer传输exe文件过大的问题

使用Electron开发的一个PC软件，包大小为400MB，有可能是TeamViewer传输大小有限制，每次传到200MB就自动中断了，导致无法把.exe文件从A电脑传输到无网络的B电脑上，又不想使用U盘进行传输，因为B电脑主机环境在机房，操作起来非常不方便。为了解决这个问题，可以通过压缩分卷的方式，把400MB大小的软件包分成两个200MB即可。以VSCode软件为例，将100MB软件包压缩分卷为两个50MB的文件。

Share

《2025 年，我的第一个建议是别当程序员了！但如果非要当，这些办法可以教会你如何提升自己》

1. 我在做事时，倾向于不轻易说“给你 10 个人去做”。因为一旦给团队说 10 个人去做，团队就不思考了。

2. 优秀的程序员通过自己的思考，产生的影响是非线性的，一定要用好这种能力。

3. 很多创新都是在资源受限的情况下被迫发生的。

4. 我是个实用主义者，我所学的所有技术都是因为别人付钱让我去做项目。我从不免费学习知识或做项目。所以，我的判断完全不是从美感或品位出发的，在我看来，品位就是用最低的成本赚最多的钱。如果一个设计不能让我后续用最低成本维护、用最少时间达到效果并赚到钱，那它就不是好设计。

5. 如果只注重表面的美观而忽视了实用性，那么这种所谓的“美”只是主观的，并不符合业界的实际需求和标准。

6. 我认为所谓品味，你应该问自己：解决这个问题该用什么方法最优雅？这包括几方面考虑：一是你面临的脑力负担，需不需要了解全貌才能解决；二是你要承担多大风险，作为工程师，首先要考虑的是项目会不会因你的选择而失败；三是收益。

7. 我自己在做重大决定时，第一个倾向是能不做就不做，能晚点做就晚点做，保持系统的简洁，也就是所谓的品味。作为古典程序员流派，我更倾向于以简单为美。

8. 程序员并没有绝对的优秀与否之分，评价标准并非线性。写代码比我快一秒钟，或者接口设计比我好一点点，都不能简单判定谁更出色。不存在这样一个明确的标准，每个人都可以从他人身上学到东西。如果真有值得学习之处，交流其实更为重要，而不是纠结于谁更优秀。这涉及到自我认知的问题，我建议就是放弃所有这种自我优越感，每个人都能从对方身上学到东西。

9. 我觉得程序员这个职业和传统职业最大的不同在于，我们不需要做前人做过的工作。一个人把别人做过的事再做一遍，这没什么了不起，甚至在这个行业是可耻的。看看世界上需要什么，有什么问题需要解决，把问题解决好，你就厉害了。你不需要和任何人比较，你就是最厉害的。

10. 不喜欢一定是有原因的，要么违反你的人性，要么违反你的道德。不做自己不感兴趣的事本身就是一个加分项，你会更有意愿去钻研，不会觉得累。比如我过去三四年，每天工作十四五个小时很常见，虽然赚钱也不多，但核心是开心，因为做了自己感兴趣的事，就不会觉得累。

11. 抬杠的过程有助于去魅，并且强迫自己找证据、了解真相。敢于抬杠是一个挑战权威的过程，并且强迫自己学习。年轻人要想办法做和别人不一样的那个人，无论是做人还是做事。别人都做得那么好了，你还有什么希望？你要做点自己感兴趣，觉得还没人好好做的事。

12. 如果不会英语，那就去学。现在全球化是大趋势，英语不仅是语言，更是一种思维方式，尤其是技术领域，它已经成为了全球交流的通用语言。如果你想进步，就必须克服语言障碍，融入全球化的交流中。中国年轻开发者确实需要提升眼界。有一个简单的方法就是多看像 Hacker News 这样的国际知名技术社区，并积极参与其中的讨论。

13. 只要有效就 OK，关键是无效。所以，无效才是原罪。

14. 对我们所有创业者来说，创业者首先是个产品经理，产品到底给谁用，为什么用户要用，这才是关键。

本周的算法题为 1475. 商品折扣后的最终价格

给你一个数组 prices ，其中 prices[i] 是商店里第 i 件商品的价格。

商店里正在进行促销活动，如果你要买第 i 件商品，那么你可以得到与 prices[j] 相等的折扣，其中 j 是满足 j > i 且 prices[j] <= prices[i] 的 最小下标 ，如果没有满足条件的 j ，你将没有任何折扣。

请你返回一个数组，数组中第 i 个元素是折扣后你购买商品 i 最终需要支付的价格。

示例 1：

输入：prices = [8,4,6,2,3]
输出：[4,2,4,2,3]
解释：
商品 0 的价格为 price[0]=8 ，你将得到 prices[1]=4 的折扣，所以最终价格为 8 - 4 = 4 。
商品 1 的价格为 price[1]=4 ，你将得到 prices[3]=2 的折扣，所以最终价格为 4 - 2 = 2 。
商品 2 的价格为 price[2]=6 ，你将得到 prices[3]=2 的折扣，所以最终价格为 6 - 2 = 4 。
商品 3 和 4 都没有折扣。

实现代码如下：

const finalPrices = function (prices) {
    let priceDifferences = []
    prices.forEach((currentPrice, currentIndex) => {
        let lowerPriceIndexes = []
        let priceDifference = 0
        prices.forEach((comparePrice, compareIndex) => {
            if (compareIndex > currentIndex && comparePrice <= currentPrice) {
                lowerPriceIndexes.push(compareIndex);
            }
        })
        if (lowerPriceIndexes.length === 0) {
            priceDifference = currentPrice
        } else {
            let minIndex = Math.min(...lowerPriceIndexes)
            priceDifference = currentPrice - prices[minIndex]
        }
        priceDifferences.push(priceDifference)
    })
    return priceDifferences
}

解题思路：

1. 先遍历查询满足条件的下标，然后获取最小下标。
2. 如果没有符合条件的折扣，则使用当前价格。

Review

Mystery drones in USA causing alarm - Breaking News English Lesson

美国各地已经有数百起神秘无人机的目击事件。上个月，人们首次开始向警方讲述无人机的情况。从那以后，越来越多的人报告看到了他们。大多数目击事件发生在新泽西州。那里的居民很担心，因为无人机一直在军事基地上空飞行。在新泽西州唐纳德·特朗普的高尔夫球场附近发现了一架无人机。由于“可疑”无人机活动，纽约州斯图尔特机场上周关闭了一个小时。美国当局表示，他们不确定无人机来自哪里。一位发言人表示，不明飞行物（UFO）对公众没有危险。

由于无人机目击事件，许多阴谋论在网上开始出现。社交媒体上的一些人说俄罗斯和中国正在利用这些物体监视美国。一名新泽西州共和党众议员表示，这些无人机来自大西洋的一艘“伊朗母舰”。美国国土安全部部长告诉美国广播公司新闻，他知道“没有外国参与这些目击事件”。他补充说：“如果我们发现任何外国参与或犯罪活动，我们将与美国公众沟通。”联邦调查局调查人员表示，大多数无人机目击事件都是“认错人”的情况，人们对新闻报道“反应过度”。

Tip

Element Plus组件库的Table表格组件，在设置el-table-column的type为selection，align为center时，出现只有表头居中了，但是内容没有居中，排查了一下原因，是因为在自行封装的Table组件中，设置了show-overflow-tooltip，虽然已经过滤了type为custom的情况，但是缺少了过滤selection的情况，所以勾选框多了一个el-tooltip的样式，导致center不生效。

Share

因为在《铁齿铜牙纪晓岚》中知道“皎皎者易污”，然后把李固的《遗黄琼书》书信内容也看了一下，不得不说，写的真好，发人深省：

1. 盖君子谓：“伯夷隘，柳下惠不恭。”
2. 常闻语曰：“峣峣者易缺，皎皎者易污。”《阳春》之曲，和者必寡；盛名之下，其实难副。

本周的算法题为 557. 反转字符串中的单词 III

给定一个字符串 s ，你需要反转字符串中每个单词的字符顺序，同时仍保留空格和单词的初始顺序。

示例 1：

输入：s = "Let's take LeetCode contest"
输出："s'teL ekat edoCteeL tsetnoc"

实现代码如下：

const reverseWords = function (s) {
    let result = '';
    s.match(/\S+/g).forEach(word => {
        result += word.split('').reverse().join('') + ' ';
    });
    return result.trimEnd();
}

解题思路：

String.prototype.match() 方法检索字符串与正则表达式进行匹配的结果。比如以上示例，s.match(/\S+/g)的结果为 [ "Let's", 'take', 'LeetCode', 'contest' ]。

Review

Record number of people in space - Breaking News English Lesson

太空变得越来越拥挤了。目前，太空中创纪录地有19人。这一记录是在俄罗斯联盟号宇宙飞船的三名乘员与国际空间站（ISS）对接后打破的。最近的任务包括NASA宇航员Don Pettit和俄罗斯宇航员Alexey Ovchinin以及Ivan Vagner。他们将国际空间站的居民人数增加到了12人。中国的宇航员也是这一记录的一部分。他们在天宫空间站有三名“太空人”在工作。剩下的四名太空旅行者是SpaceX的极光黎明任务的一部分。该项目在上周四见证了历史上第一次全平民太空行走。

关于最近的记录有一点争议，那就是关于外太空起点的定义。NASA和美国军方将地球大气层和外太空的边界视为海拔80公里。按照这种解释，人类在太空中的记录是20人，在2023年5月和今年1月创下。然而，外太空边缘的传统定义被称为卡门线。国际航空联合会将这条线定为海拔100公里。新的记录使用了这个定义。卡门线用于法律目的，以区分飞机和宇宙飞船。

Tip

在给项目配置Sentry时，要将sourcemaps通过sentry-wizard自动上传至Sentry，但是却提示以下报错信息：

Loading Wizard failed. Did you provide the right URL?

再三确认URL是没有问题，所以，就很奇怪这是什么问题？

使用curl命令是没有问题的，但是，返回了Sentry网站没有证书的信息。

查看Github上面的Issues，发现有类似的问题，如下所示：

Loading Wizard failed for NextJs #416

提供的解决方案是，使用命令 set NODE_TLS_REJECT_UNAUTHORIZED=0 ，因为在Node.js 中，NODE_TLS_REJECT_UNAUTHORIZED 是一个环境变量，用于控制Node.js在执行HTTPS请求时是否应该拒绝未经授权的SSL证书。

然后，可以使用命令npx @sentry/wizard@latest -i sourcemaps可以正常执行了，只是在运行npm run build进行打包的时候，还是报错了，提示证书异常：

error: API request failed
  caused by: [60] SSL peer certificate or SSH remote key was not OK (schannel: SEC_E_UNTRUSTED_ROOT (0x80090325))

所以，还是没办法解决，后来，Sentry更新了证书就好了。

Share

“套用98年乔丹对斯科特·伯勒尔的一段话：‘你肯定想再来一局，你想告诉你的外孙们，你打败了乔丹，那我和我外孙们说点什么？说我打败了斯科特·伯勒尔吗？’这才是真正的杀人诛心！他们赢了乔丹可以使劲吹。乔丹赢了他们有意思吗？”

本周的算法题为 1822. 数组元素积的符号

已知函数 signFunc(x) 将会根据 x 的正负返回特定值：

• 如果 x 是正数，返回 1 。
• 如果 x 是负数，返回 -1 。
• 如果 x 是等于 0 ，返回 0 。

给你一个整数数组 nums 。令 product 为数组 nums 中所有元素值的乘积。

返回 signFunc(product) 。

示例 1：

输入：nums = [-1,-2,-3,-4,3,2,1]
输出：1
解释：数组中所有值的乘积是 144 ，且 signFunc(144) = 1

实现代码如下：

let arraySign = function (nums) {
    let product = 1
    nums.forEach(n => {
        if (n === 0) {
            product = 0
            return
        }
        product = product * n

    });
    return signFunc(product)

    function signFunc(p) {
        if (p > 0) {
            return 1
        } else if (p < 0) {
            return -1
        } else {
            return 0
        }
    }
}

解题思路：

题目很简单。

Review

Nature can reduce anxiety and boost mental health - Breaking News English Lesson

我们都知道，置身于大自然中对我们有好处。新的研究表明，在自然界中仅 10 分钟就有助于我们的心理健康。该研究还表示，在自然环境中与他人共度时光有助于建立人际关系。即使在城市公园和园艺中也可以有所作为。香港城市大学的一项研究发现，大自然增加了我们将他人视为“完全的人”的方式。研究人员表示，这使我们更多地帮助和合作他人。我们变得更善于交际。这让我们对自己感觉更好。我们感觉更积极，因此我们的心理健康得到了改善。帮助他人也可以减轻我们的压力和焦虑。

心理健康是一个在世界范围内日益增长的问题。越来越多的人患有焦虑、抑郁和其他心理障碍。美国全国精神疾病联盟报告称，五分之一的美国人有心理健康问题。该研究包含关于大自然如何帮助解决这些问题的好建议。它说，在树上或田野里度过的时间与更好的睡眠和注意力的提高有关。日本千叶大学的一项研究发现，即使是鲜花也对心理健康有积极影响。研究人员发现，办公桌上放着一瓶玫瑰的员工在短短四分钟后就变得更加平静，压力也减轻了。

Tip

在维护部门内部的API库时，出现执行命令报错，如下所示：

node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^
Error: Command failed with ENOENT: npm run clean
spawn npm run clean ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:478:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn npm run clean',
  path: 'npm run clean',
  spawnargs: [],
  originalMessage: 'spawn npm run clean ENOENT',
  shortMessage: 'Command failed with ENOENT: npm run clean\nspawn npm run clean ENOENT',
  command: 'npm run clean',
  exitCode: undefined,
  signal: undefined,
  signalDescription: undefined,
  stdout: '',
  stderr: '',
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}

从报错信息可知，代码在执行到npm run clean命令时报错了，提示找不到这个命令，但是我复制命令在终端运行是成功的，在windows10系统是没问题的，但我在mac系统上运行就报错了，执行代码如下所示：

await execa('npm run clean')

初步猜测，可能execa用法在mac环境中不生效。将其注释，没有提示报错，所以，接着就要研究如何在mac环境中使用execa了。只需将

execa('npm run clean') 

改写为

execa('npm', ['run', 'clean'], { shell: true })

即可，这时，我们就会想知道这两种用法有什么区别呢？

execa是一个用于执行shell命令的Node.js模块，它可以将命令作为参数传递给它，并返回一个Promise，以便在命令执行完成之后处理。根据报错提示没有找到npm命令，很有可能是execa模块无法正确识别到环境变量。

所以将npm run clean拆分为npm和run clean两个参数，并将 shell 选项设置为true，以便在子进程中运行命令的时候使用默认的shell，这样可以正确找到npm命令并且识别环境变量，找到npm命令。

Share

“上兵伐谋，其次伐交，其次伐兵，其下攻城。”

本周的算法题为 2283. 判断一个数的数字计数是否等于数位的值

给你一个下标从 0 开始长度为 n 的字符串 num ，它只包含数字。

如果对于 每个 0 <= i < n 的下标 i ，都满足数位 i 在 num 中出现了 num[i]次，那么请你返回 true ，否则返回 false 。

示例 1：

解释：
num[0] = '1' 。数字 0 在 num 中出现了一次。
num[1] = '2' 。数字 1 在 num 中出现了两次。
num[2] = '1' 。数字 2 在 num 中出现了一次。
num[3] = '0' 。数字 3 在 num 中出现了零次。
"1210" 满足题目要求条件，所以返回 true 。

实现代码如下：

const digitCount = function (num) {
    for (let i = 0; i < num.length; i++) {
        const n = num[i];
        console.log({ i, n });
        if (Number(n) !== getCount(i, num)) {
            return false
        }
    }
    return true

    function getCount(char, s) {
        let count = 0
        let postion = s.indexOf(char)
        while (postion !==-1) {
            count++
            postion = s.indexOf(char, postion + 1)
        }
        return count
    }
};

解题思路：

只需求得下标字符i在字符串中出现的次数与num[i]相等即可。

Review

Marmoset monkeys call each other by name - Breaking News English Lesson

研究人员表示，狨猴会叫出对方的名字，类似于人类识别彼此的方式。这种 20 厘米长的灵长类动物原产于南美洲。耶路撒冷希伯来大学的科学家研究了 10 只狨猴的社会互动。研究小组发现，这些动物对他们组中的其他猴子使用了独特的叫声。该研究的合著者大卫·奥马尔博士说，狨猴是已知的第一批使用名字的非人类灵长类动物。研究人员将狨猴分为各种配对。然后，他们使用人工智能分析了 50,000 多只猴子的叫声。这使科学家们能够确定这些动物彼此都有名字。

Omer 博士认为，这些发现可以揭示人类语言是如何进化的。他说：“直到最近，人们还认为人类语言是一个无中生有的奇异现象。我们开始看到证据表明情况并非如此。Omer 假设了狨猴是如何发展出一种叫名系统的。他说：“狨猴生活在一夫一妻制的小家庭群体中，就像人类一样一起照顾它们的幼崽。这些相似性表明，他们面临着与我们早期前语言祖先相当的进化社会挑战。其他已知能通过名字识别同类生物的生物是海豚和大象。

Tip

在Windows系统中，要删除多层级的文件夹，比如项目依赖包node_module，它的目录可能包含有成千上万的文件和子目录，因为系统删除时会将这些文件逐一检查，读取文件大小、权限验证等，会额外增加删除所需的时间，如果电脑配置不太行，真的让人受不了。

基于博文《Windows下快速删除上万个文件和子目录(快速删除文件) 命令行cmd快速删除文件夹》提供的解决方案如下：

在D:\tools\FASTDEL中新建一个fastdel.bat文件，然后复制下面的代码：

@ECHO OFF
ECHO Delete Folder: %CD%
PAUSE
SET FOLDER=%CD%
CD ..
DEL /F/Q/S "%FOLDER%\*" > NUL
RMDIR /Q/S "%FOLDER%"
EXIT

保存之后，打开系统环境变量配置页面，在Path路径加上D:\tools\FASTDEL，如下所示：

之后，在你要删除的文件目录下，打开Windows PowerShell命令窗口，然后输入命令FASTDEL进行删除即可，如下所示：

Share

本周的算法题为 438. 找到字符串中所有字母异位词

给定两个字符串 s 和 p，找到 s 中所有 p 的 异位词的子串，返回这些子串的起始索引。不考虑答案输出的顺序。

示例 1:

输入: s = "cbaebabacd", p = "abc"
输出: [0,6]
解释:
起始索引等于 0 的子串是 "cba", 它是 "abc" 的异位词。
起始索引等于 6 的子串是 "bac", 它是 "abc" 的异位词。

实现代码如下：

const findAnagrams = function (s, p) {
    if (p.length > s.length) {
        return [];
    }

    let pCount = new Array(26).fill(0); 
    let sCount = new Array(26).fill(0);
    let result = [];

    for (let char of p) {
        pCount[char.charCodeAt(0) - 'a'.charCodeAt(0)] += 1;
    }
    for (let i = 0; i < p.length; i++) {
        sCount[s.charCodeAt(i) - 'a'.charCodeAt(0)] += 1;
    }

    if (isEqual(pCount, sCount)) {
        result.push(0);
    }
    for (let i = p.length; i < s.length; i++) {
        sCount[s.charCodeAt(i - p.length) - 'a'.charCodeAt(0)] -= 1;
        sCount[s.charCodeAt(i) - 'a'.charCodeAt(0)] += 1;
        if (isEqual(pCount, sCount)) {
            result.push(i - p.length + 1);
        }
    }

    function isEqual(count1, count2) {
        for (let i = 0; i < 26; i++) {
            if (count1[i] !== count2[i]) {
                return false;
            }
        }
        return true;
    }

    return result;

};

解题思路：

创建pCount和sCount字母表，通过一个字母的Unicode编码减去字母a的Unicode编码，得到其在字母表中的位置，并且将其计数，通过滑动窗口，左减右加，最后通过对比相同位置计数是否相等，来确定是否是字母异位词。

Review

Eye colour change is riskiest cosmetic surgery - Breaking News English Lesson

全世界越来越多的人选择整容手术来提升他们的容貌。潜在患者可能不知道的是，改变眼睛颜色的手术是风险最大的。在线眼镜店 Overnight Glasses 进行的研究断言，眼部颜色手术有92%的可能性出现并发症。眼睛颜色变化在研究人员最危险的整容手术名单中名列前茅。此类手术包括虹膜植入物和激光色素去除。还有一个称为角膜色素沉着的程序。这是一种永久性的眼睛颜色变化，其中使用精密激光技术将特殊的着色剂插入眼睛中。

今年早些时候，美国眼科学会发布了对眼睛变色手术的警告。Ashley Brissette 博士强调了可能出错的事情。这些包括染料泄漏、过敏反应、感染、对光敏感、可能导致混浊或视力丧失的角膜损伤，以及最终失明。她说：“我们用眼睛做的任何事情，都必须非常非常小心。研究人员表示，恢复时间可能长达两个月，手术的平均费用为 12,000 美元。眼科医生 Nicole Bajic 建议戴彩色隐形眼镜，而不是动刀。她说，“可以给你你想要的外观，而不会危及你的眼睛健康”。

Tip

在使用npm i命令给项目安装依赖时，出现卡住的情况，等了好久，也没见成功或者中断，这就无法入手去解决问题。使用命令npm install --verbose可以看到安装的更多信息，便于排查问题。

Share

“珍惜现在，就是穿越时空。”

本周的算法题为 189. 轮转数组

给定一个整数数组 nums，将数组中的元素向右轮转 k 个位置，其中 k 是非负数。

示例 1:

输入: nums = [1,2,3,4,5,6,7], k = 3
输出: [5,6,7,1,2,3,4]
解释:
向右轮转 1 步: [7,1,2,3,4,5,6]
向右轮转 2 步: [6,7,1,2,3,4,5]
向右轮转 3 步: [5,6,7,1,2,3,4]

实现代码如下：

const rotate = function (nums, k) {
    let count = 0;
    if (k <= nums.length) {
        count = k;
    } else {
        count = k % nums.length;
    }
    const middlePart = nums.splice(nums.length - count, count);
    nums.unshift(...middlePart);
    return nums;
}

解题思路：

通过示例1，可以找到规律，元素向右轮转了k个位置，相当于从 nums.length - count 位置截取然后再添加到数组的开头位置。如果k的值等于数组长度，那么，经过向右轮转之后，各元素还是原位。因此，使用 k % nums.length 取余，处理当k大于数组长度的情况。

Review

1Scientists fear people will fall in love with AI voices - Breaking News English Lesson

拥有 ChatGPT 的公司 OpenAI 担心人们可能会在情感上依赖人工智能的声音。该公司上周向用户发布了一种新的“高级语音模式”。聊天机器人配备了一系列栩栩如生的声音，这些声音与人声几乎没有区别。他们可以实时进行真实的对话，在适当的时间大笑，用“嗯”、“啊”和“嗯”插话，他们可以适应被打断。OpenAI 的一份报告指出，新发布的、听起来像人的声音可能会导致人们依赖 AI 来陪伴，甚至浪漫和爱情。它警告说：“用户可能会与 AI 建立社交关系，从而减少他们对人类互动的需求。

OpenAI 报告警告说，未来的聊天机器人可能会从根本上改变社会。它们将重塑我们与家人、朋友和同事的互动方式。他们甚至可能篡夺人类之间的交流。该报告指出了新工具的好处。这些包括给孤独的人带来安慰和友谊，给那些缺乏自信的人信心。报告称，人们可能会获得足够的信心来开始在现实世界中约会。另一方面，聊天机器人可能会导致人们变得更粗鲁、更不耐烦和更自私。Wired.com 写道，新的聊天机器人包括“潜在的……放大社会偏见，传播虚假信息，并帮助开发化学或生物武器”。

Tip

在运行electron-vue项目时，打算把node_modules删除了再重新安装，却提示node_modules/electron文件夹正在被使用，删除失败。然后，把相关窗口都关闭了还是不行，猜测是有关联的进程没有关闭，所以，就看下怎么处理。步骤如下：

打开任务管理器 ➔ 性能 ➔ CPU ➔ 打开资源监视器 ➔ 关联的句柄 ➔ 搜索句柄electron ➔ 右键结束进程。

Share

查理·芒格的“大猩猩理论”：一个聪明人进入一个有大猩猩的房间，解释他的想法是什么，而那个大猩猩只是坐在那里吃它的香蕉。结束这段谈话后，那个解释的人出来时一定变得更聪明了。

本周的算法题为 1346. 检查整数及其两倍数是否存在

给你一个整数数组 arr，请你检查是否存在两个整数 N 和 M，满足 N 是 M 的两倍（即，N = 2 * M）。

更正式地，检查是否存在两个下标 i 和 j 满足：

• i != j
• 0 <= i, j < arr.length
• arr[i] == 2 * arr[j]

示例 1：

输入：arr = [10,2,5,3]
输出：true
解释：N = 10 是 M = 5 的两倍，即 10 = 2 * 5 。

实现代码如下：

const checkIfExist = function (arr) {
  const result = arr.map((m, i) => {
    const index = arr.indexOf(m * 2)
    return index != -1 && index != i
  })
  return result.includes(true)
};

解题思路：

把整数数组中的每个整数都乘以2，然后验证其值是否和数组中油相等的存在，如果存在，并且它的下标并不相等（为了排除0*2=0的情况），则证明整数及其两倍数存在。

Review

18-km wide diamond layer on Mercury, says study

美国著名影星玛丽莲·梦露曾唱过一首著名的歌:“钻石是女孩最好的朋友”。比利时列日大学的科学家们相信，他们已经发掘出了数量巨大的这种宝石。在水星的地壳下可能有一个18公里宽的宝石层。离我们最近的行星邻居很可能是天上的一颗宝石。研究人员测试了大约45亿年前水星是如何形成的。这颗行星是从宇宙尘埃和气体云的旋转中演化而来的。经过数百万年的时间，尘埃被压缩成石墨，石墨的化学性质与钻石相同。两者都是碳元素的固体形式。水星上的钻石不太可能被开采出来，因为它们在地表以下约500公里处。

研究人员使用一种被称为砧压机的机器来模拟水星形成的条件。这台印刷机是用来制造人造钻石的。研究人员在石墨胶囊内混合了各种元素。其中包括硅、镁和铝。太空舱承受的压力是地球上的7万倍。它被加热到2000摄氏度的温度。首席研究员推测水星上的钻石。他说:“钻石只由碳构成，所以它们应该与我们在地球上所知道的相似……它们会像纯钻石。”科学家们相信在地球表面下有一千万亿吨钻石。专家表示，这些隐藏的宝石的价值几乎无法估量。

Tip

使用Chrome访问HTTP网站时，因为浏览器自动转为HTTPS导致访问失败，查了下网上的解决方案，如下所示：

1. 在Chrome浏览器地址栏输入chrome://net-internals/#hsts并回车。
2. 找到页面中的Delete domain security policies部分。
3. 输入导致问题的网站域名。
4. 点击Delete按钮删除该域名的安全策略。

Share

前些天，早上过来公司，打开菜鸟教程网站，看了下正则表达式的内容，然后看了“关于我们”一栏，里面有句话说得蛮好的：“我们坚持一件事情，并不是因为这样做了会有效果，而是坚信，这样做是对的。”

本周的算法题为 2432. 处理用时最长的那个任务的员工

共有 n 位员工，每位员工都有一个从 0 到 n - 1 的唯一 id 。

给你一个二维整数数组 logs ，其中 logs[i] = [idi, leaveTimei] ：

• idi 是处理第 i 个任务的员工的 id ，且
• leaveTimei 是员工完成第 i 个任务的时刻。所有 leaveTimei 的值都是 唯一 的。

注意，第 i 个任务在第 (i - 1) 个任务结束后立即开始，且第 0 个任务从时刻 0 开始。

返回处理用时最长的那个任务的员工的 id 。如果存在两个或多个员工同时满足，则返回几人中 最小 的 id 。

示例 1：

输入：n = 10, logs = [[0,3],[2,5],[0,9],[1,15]]
输出：1
解释：
任务 0 于时刻 0 开始，且在时刻 3 结束，共计 3 个单位时间。
任务 1 于时刻 3 开始，且在时刻 5 结束，共计 2 个单位时间。
任务 2 于时刻 5 开始，且在时刻 9 结束，共计 4 个单位时间。
任务 3 于时刻 9 开始，且在时刻 15 结束，共计 6 个单位时间。
时间最长的任务是任务 3 ，而 id 为 1 的员工是处理此任务的员工，所以返回 1 。

实现代码如下：

const hardestWorker = function (n, logs) {
    let longestDuration = logs[0][1];
    let employeeDurationDifferences = [[logs[0][0], logs[0][1]]];

    logs.forEach((log, index) => {
        if (index >= logs.length - 1) {
            return;
        }
        const currentTimeDiff = logs[index + 1][1] - logs[index][1];
        employeeDurationDifferences.push([logs[index + 1][0], currentTimeDiff]);
        longestDuration = Math.max(longestDuration, currentTimeDiff);
    });

    const longestDurationEmployees = employeeDurationDifferences.filter(diff => diff[1] === longestDuration);

    // 如果只存在一个员工是这个任务时长，则直接返回该员工的ID
    if (longestDurationEmployees.length == 1) {
        return longestDurationEmployees[0][0]
    }

    let longestDurationEmployeeIds = [];
    longestDurationEmployees.forEach(record => {
        longestDurationEmployeeIds.push(record[0]);
    });
    return Math.min(...longestDurationEmployeeIds);
}

解题思路：

首先，通过logs二维数组，获取到每个员工的ID以及对应的任务时长，同时，使用Math.max()函数求得任务时长最大值，然后，筛选任务时长最大值的员工ID，如果只有一个员工，则直接返回结果，否则，通过遍历获取全部的员工ID，再使用Math.min()函数，求得最小值。

Review

Violence against women and girls at ’epidemic’ levels

英国警方发布了一份报告，强调针对妇女和女孩的暴力事件急剧增加。报告指出，厌女症和针对妇女的犯罪行为达到了创纪录的水平。据报道，一年内有100多万起此类犯罪。这可能只是冰山一角。将会有大量的暴力事件没有被报道。伦敦大都会警察局撰文描述了这一问题的严重性。报告称:“针对妇女和女孩的暴力是地方性的、系统性的，对社会的威胁与恐怖主义一样严重。”它补充说，针对妇女的犯罪占所有记录犯罪的20%。它说:“我们必须采取行动，改变妇女和女孩无法接受的现实。”

该报告由英国国家警察局长委员会和警务学院发布。副警长麦琪·布莱斯称这些数据“令人震惊”。她说:“对妇女和女孩的暴力行为是国家的紧急情况。作为一个社会，我们需要向前迈进，做出改变，不再认为针对妇女和女孩的暴力是不可避免的。”警方表示:“每12名女性中就有1人会成为暴力的受害者。每六起谋杀案中就有一起是家庭暴力造成的。每20个人中就有1个人——其中超过200万人——在他们的生活中会对妇女和女孩施暴。”报告称，基于性别的暴力犯罪包括骚扰、谋杀、网络性虐待、强奸和跟踪。

Tip

markdown 文档如何自动加上标题编号？

因为我那个记录问题的markdown文档，需要时不时更新一下内容，所以，标题的编号也要同步更新，这个文档内容那么多，改起来工作量很大，只能研究一下，怎么在markdown文档里自动加上标题编号。

在VSCode里有插件能够实现这个需求，自己也使用了一段时间，感觉还是很方便的，只是因为电脑更新系统，不小心卸载了这个插件，不太记得插件名字了，只能使用另一个———— Markdown Header。可使用这个插件增加标题编号时，发现它并不是基于现有的标题编号进行更新，而是额外增加了标题编号，比如1.1 1.1，加上要清空标题编号没有生效，只能看下，怎么把当前文档里的标题编号全都清空，然后，再使用这个插件自动生成标题编号，解决思路是，在VSCode中使用正则表达式搜索，匹配到# 1.2.3类似的格式，一个#加一个空格，然后是标题编号，全部替换成#即可。

(#\s+)(\b\d+(\.\d+)*\b)

接着，使用Ctrl+Shift+P，选择Markdown generate header number，一键生成标题编号。

Share

“若不披上这件衣裳，众生又怎知我尘缘已断、金海尽干？”

本周的算法题为 1232. 缀点成线

给定一个数组 coordinates ，其中 coordinates[i] = [x, y] ， [x, y] 表示横坐标为 x、纵坐标为 y 的点。请你来判断，这些点是否在该坐标系中属于同一条直线上。

示例 1:

输入：coordinates = [[1,2],[2,3],[3,4],[4,5],[5,6],[6,7]]
输出：true

实现代码如下：

const checkStraightLine = function (coordinates) {
  // 两点确定一条直线
  if (coordinates.length < 2) {
    return false;
  }
  // 同一个X轴
  const allEqualX = coordinates.every((item) => item[0] === coordinates[0][0]);
  if (allEqualX) {
    return true;
  }
  // 同一个Y轴
  const allEqualY = coordinates.every((item) => item[1] === coordinates[0][1]);
  if (allEqualY) {
    return true;
  }
  // 对角线
  const [x0, y0] = coordinates[0];
  const [x1, y1] = coordinates[1];
  // 斜率
  const slope = (y1 - y0) / (x1 - x0);
  // 遍历剩余的坐标点，检查斜率是否一致
  for (let i = 2; i < coordinates.length; i++) {
    const [xi, yi] = coordinates[i];
    // 避免除以零，并且使用交叉乘积来比较斜率
    if ((yi - y0) * (x1 - x0) !== (y1 - y0) * (xi - x0)) {
      return false;
    }
  }
  return true;
};

解题思路：

首先，我们明确需求，即判断一组点是否都在同一直线上。这包括三种情况：所有点的X轴坐标相同、所有点的Y轴坐标相同，或者是这些点构成一条斜线。我们可以使用every方法遍历数组中的点，对比它们的X轴或Y轴坐标是否相同。

接下来，对于斜线的判断，我们需要验证这些点的斜率是否一致。如果直接计算斜率 (yi - y0) / (xi - x0) 并与另一个斜率 (y2 - y1) / (x2 - x1) 进行比较，而 x2 - x1 为0时，会遇到除零错误或浮点数精度问题。为了避免这些问题，我们可以使用交叉乘积的方法，即两边同时乘以 (xi - x0) * (x2 - x1)，从而得到 (yi - y0) * (x1 - x0) == (y1 - y0) * (xi - x0) 作为斜率是否相等的判断条件。

Review

Spanish residents take to streets against mass tourism - Breaking News English Lesson

西班牙成千上万的人正在抗议大众旅游。在巴塞罗那，居民们用水枪向餐馆里的游客喷射。在马略卡岛上，一万人走上街头，手举横幅，上面写着：“够了！”和“马略卡不出售！”马略卡岛的人们对他们的租金上涨感到愤怒。由于旅游业的发展，当地人几乎无法购买房屋。由于公司正在购买房产以租给游客，房价飙升。Airbnb的一位发言人说：“旅游业从业者无法在自己所在的城市负担得起租金。”她补充说：“我们认为将经济……建立在……旅游业之上是不可持续的，必须改变。” 旅游区的居民有很多抱怨。他们说旅游对他们的生活产生了负面影响。许多人再也找不到住的地方了。一些人不得不搬出家园，因为房东正在提高租金。日常生活也成了问题。公交车和火车上挤满了背包客和拉着行李箱的游客。由于垃圾不断增加，城镇很难保持街道清洁。当地人也抱怨说，由于游客，他们无法在自己喜欢的餐馆吃饭。西班牙并不是唯一一个旅游业成为问题的国家。日本、奥地利和墨西哥已经采取行动，寻求在帮助当地人和可持续旅游业之间找到平衡。

Tip

<img> 动态修改图片颜色

在实现el-menu动态配置菜单图标的时候，因为从字体图标替换成在线获取的.svg图片，所以需要研究下如何实现动态配置颜色，好解决后续各项目不同主题的需求。

transform: translateX(-80px);
filter: drop-shadow(#a80f0f 80px 0);

Share

独家专访亚马逊 CTO Werner Vogels | InfoQ

1. 各种商业机构和教育平台都能帮我们快速掌握新的编程语言，所以到底选择哪种语言本身已经不那么重要了。
2. 由于技术发展太过迅速，高等教育、大学课程根本就跟不上变化。问问那些刚刚走出校园的学生就知道了，他们对区块链、生成式 AI 等新技术的了解肯定不如我们这些从业者。而且随着技术的采用周期越来越短，产品的上市速度也会远超以往。也就是说，学校里传授的知识不再具有先进性。所以除了编程语言之外，我们在学校中的最大收获就是学习能力，这种学习能力决定我们能否成为技术专家、保持终身钻研。
3. 我认为任何接受过良好基础教育的人都有能力掌握计算机技术，即便专业不同。因为具体学了什么专业并不重要，重要的是教育经历让你掌握了学习能力、知道要如何设立更宏大的目标、如何汇总信息、记在脑子里、进行批判性思考，如此往复。
4. 在实际工作中，我强调“协作”是日常工作的核心。
5. 对于招聘，我更关心候选人是否具备在大学里培养的学习能力，而不仅仅是特定的语言或技术。
6. 技术的变化一刻不停，永远别指望自己毕业之后头一年学到的东西够用一辈子。
7. 但保守并不代表守旧，研究人员还是在努力把成果整合起来，打造出能让消费者们眼前一亮的产品。就像那个有趣的比喻，如果你看到一只熊在跳舞，那最重要的就是它能跳舞，而不是它跳得好不好。希望大家能用类似的心态看待前沿技术，尽量宽容一点。
8. AI 可以接管一些繁琐的任务，这使得开发者可以更专注于他们真正擅长的工作，如获取和整合信息、做出决策和规划。
9. 人需要肩负起监管的职责。请记住，AI 只是辅助、是帮助我们的工具。它们是在帮我们做预测，而不是替我们做预测，责任永远要由人来承担。

本周的算法题为 1528. 重新排列字符串

给你一个字符串 s 和一个 长度相同 的整数数组 indices 。

请你重新排列字符串 s ，其中第 i 个字符需要移动到 indices[i] 指示的位置。

返回重新排列后的字符串。

示例 1：
输入：s = "codeleet", indices = [4,5,6,7,0,2,1,3]
输出："leetcode"
解释：如上图所示，"codeleet" 重新排列后变为 "leetcode" 。

实现代码如下：

const restoreString = function (s, indices) {
  let result = "";
  for (let i = 0; i < indices.length; i++) {
    result += s[indices.indexOf(i)];
  }
  return result;
};

解题思路：

题目很简单，只需要遍历indices数组，对于每个遍历到的索引i，我们取出indices[i]的值，这个值直接对应了字符串s中某个字符的索引。然后，我们根据这个索引从s中取出相应的字符，并将这些字符按照indices数组的顺序依次拼接起来，形成新的字符串。

Review

Chimpanzees use medicinal plants when sick - Breaking News English Lesson

人类自史前时代起便开始使用药用植物，至今全球各地仍在使用传统草药。科学家首次发现黑猩猩也会寻找森林中的果实来为自己治病。英国牛津大学的研究人员在乌干达的布东戈中央森林保护区对黑猩猩的行为进行了研究。研究人员跟踪了一只手部受伤的黑猩猩，发现它在寻找一种蕨类植物的叶子。这种蕨类植物可能具有减轻黑猩猩手部肿胀的功效。另一只患有寄生虫感染的黑猩猩则寻找猫棘树的树皮，这有助于缓解它的病情。

研究团队表示，黑猩猩的疾病和受伤情况与它们所食用的植物的药用特性之间存在很强的相关性。研究人员测试了不属于黑猩猩正常饮食的植物提取物，发现88%的提取物具有抗菌特性，33%的提取物具有抗炎特性。研究员兼人类学家艾洛蒂·弗雷曼博士表示：“药理学研究结果表明，布东戈的黑猩猩会食用多种具有强大药用特性的植物。”她说，她的团队对灵长类动物行为的研究可能为我们在生活中更广泛地使用自然疗法铺平道路。

Tip

在Vue Next项目开发过程中，我们需要调试一些鼠标悬停才会出现的元素，比如Element Plus 里的 <el-dropdown> 组件，如要修改它下拉菜单的背景色，可使用鼠标悬停显示下拉框，然后按下快捷键 Ctrl + Shift + C 触发视图查看，再点击下拉框即可获取Class名称进行修改，如下所示：

Share

每个人所要追求的东西并不一样，没必要强人所难，说过一两次就够了，平常心对待，说到底，只不过一份工作而已，承载不了太多的东西。

本周的算法题为 3114. 替换字符可以得到的最晚时间

给你一个字符串 s，表示一个 12 小时制的时间格式，其中一些数字（可能没有）被 "?" 替换。

12 小时制时间格式为 "HH:MM" ，其中 HH 的取值范围为 00 至 11，MM 的取值范围为 00 至 59。最早的时间为 00:00，最晚的时间为 11:59。

你需要将 s 中的 所有 "?" 字符替换为数字，使得结果字符串代表的时间是一个 有效 的 12 小时制时间，并且是可能的 最晚 时间。

返回结果字符串。

示例 1：

输入： s = "1?:?4"
输出： "11:54"
解释： 通过替换 "?" 字符，可以得到的最晚12小时制时间是 "11:54"。

实现代码如下：

const findLatestTime = function (timeString) {
  let result = "";
  let replacementDigits = ["1", "9", "0", "5", "9"];
  for (let i = 0; i < timeString.length; i++) {
    let char = timeString[i];
    if (char === "?") {
      char = replacementDigits[i];
    }
    result += char;
  }
  let sub = result.substring(0, 2);
  let replacementString = "";
  if (timeString[0] === "?" && Number(sub) > 11) {
    replacementString = "0" + timeString[1];
  }
  if (timeString[1] === "?" && Number(sub) > 11) {
    replacementString = "11";
  }
  if (replacementString) {
    result = result.replace(sub, replacementString);
  }
  return result;
};

解题思路：

首先，将"HH:MM"的每个时分最大取值明确，然后如果是?就替换成对应索引的数值，这样可以满足通用的情况下 ，在这个基础上，对特殊情况进行处理，然后得出想要的结果。

Review

Top US doctor wants social media health warnings - Breaking News English Lesson

社交媒体已经改变了世界。它既有好的一面，也有坏的一面。其中一个不好的地方是，它可能导致心理健康问题。这是美国顶级医生想要解决的问题。美国卫生与公共服务部部长维韦克·穆尔西希望社交媒体公司在其平台上发布有关心理健康的警告。他尤其担心这些平台对年轻人的伤害。他说算法导致年轻人接触到极端色情和暴力内容。穆尔西博士说：“现在是时候要求在社交媒体平台上贴上卫生与公共服务部长的警告标签了，指出社交媒体与青少年心理健康的严重损害有关。”他还表示，需要法律来保护年轻人在网络上的安全。

多年来，穆尔西博士一直在为加强对社交媒体的管控而奔走呼吁。2023年，他警告说，社交媒体对儿童和青少年的心理健康和福祉构成“严重的伤害风险”。他最近的警告发表在《纽约时报》的一篇客座文章中。他写道：“年轻人面临的心理健康危机是一场紧急事件。社交媒体已成为一个重要的促成因素。”他担心年轻人花在网络上的时间太长。他说“每天花费三个多小时在社交媒体上的年轻人面临焦虑和抑郁症状的风险是其他人的两倍。”穆尔西认为，就像香烟上的警告一样，在线警告也会有所帮助。

Tip

Cookie Banner是指网站上出现的一种通知条，用于告知用户该网站使用Cookie等技术来收集、存储和处理用户数据，并且需要用户同意这些数据的使用。通常，Cookie Banner会包含一个简要的说明，告知用户使用Cookie的目的和类型，以及提供一个同意或拒绝的选项。此外，还可能包含一个链接，指向更详细的隐私政策或Cookie策略页面。

Cookie政策是网站提供给用户的一份声明，解释了网站如何使用Cookie（一种小型文本文件），以及与Cookie相关的数据收集和隐私保护措施。Cookie是一种存储在用户计算机上的文本文件，它包含有关用户访问网站的信息。许多网站使用Cookie来跟踪用户行为，例如记住用户首选项、购物车信息、广告和其他内容。Cookie政策通常包括以下信息：

1. 网站使用Cookie的目的和类型。
2. 与Cookie相关的数据如何收集、存储和使用。
3. 用户如何控制Cookie的使用和删除Cookie。
4. 如何保护用户数据隐私。
5. Cookie政策的更新和变更如何通知用户。

Share

既要，又要，还要。

不可能“我全都要的”，只能有所取舍，有失才有得。

本周的算法题为 2455. 可被三整除的偶数的平均值

给你一个由正整数组成的整数数组 nums ，返回其中可被 3 整除的所有偶数的平均值。

注意：n 个元素的平均值等于 n 个元素 求和 再除以 n ，结果 向下取整 到最接近的整数。

示例 1：
输入：nums = [1,3,6,10,12,15]
输出：9
解释：6 和 12 是可以被 3 整除的偶数。(6 + 12) / 2 = 9 。

实现代码如下：

const averageValue = function (nums) {
  let total = 0;
  let count = 0;
  for (let i = 0; i < nums.length; i++) {
    if (nums[i] % 6 === 0) {
      total += nums[i];
      count++;
    }
  }
  return count > 0 ? Math.floor(total / count) : 0;
};

解题思路：

因为可被3整除的判断条件为nums[i] % 3 === 0，偶数的判断条件为nums[i] % 2 === 0，所以可以合起来为nums[i] % 6 === 0，然后，再使用total来记录求和值，count来记录次数，相除即可得到想要的平均值。

Review

Australia to allow foreign citizens into its army - Breaking News English Lesson

澳大利亚很快将允许非澳大利亚人参军。来自英国、加拿大和新西兰等国家的人可以申请加入澳大利亚国防军(ADF)。澳大利亚在招人参军方面遇到了问题。政府希望向其他国家的人开放军队以解决征兵问题。ADF目前缺少约4400名工人。从7月起，在澳大利亚永久居住的新西兰人可以申请加入。明年，来自英国、美国和加拿大的学生将有机会。澳大利亚国防部长理查德·马尔斯(Richard Marles)表示，未来可能会有更多国家的人加入。

马勒斯表示，出于安全考虑，法国正在改变征兵政策。他说:“澳大利亚政府选择发展澳大利亚国防军，因为这对于应对未来十年乃至更长时间内的国家安全挑战至关重要。”国防部发言人说:“为了发展国防军，我们采取了大胆的行动。从更广泛的人群中招募人才将有助于确保(ADF)反映澳大利亚的全面多样性，并能够吸引(所有)澳大利亚社会的人才。”反对党外交部长西蒙·伯明翰不同意这项政策。他说，这显示了政府的失败。他说:“我们应该看到更多的澳大利亚人有信心报名参加。”

Tip

Math.floor() 、Math.ceil() 和 Math.round()

1. Math.floor()，向下取整，Math.floor(5.96) = 5。
2. Math.ceil()，向上取整，Math.ceil(5.96) = 6。
3. Math.round()，四舍五入，取其值的绝对值进行四舍五入，如果原数是负数，结果保持为负。比如Math.round(5.96) = 6；Math.round(-5.0001) = -5。

Share

第二名就是头号输家。

本周的算法题为 3151. 特殊数组 I

如果数组的每一对相邻元素都是两个奇偶性不同的数字，则该数组被认为是一个 特殊数组 。

Aging 有一个整数数组 nums。如果 nums 是一个 特殊数组 ，返回 true，否则返回 false。

示例 1

输入：nums = [2,1,4]
输出：true
解释：
只有两对相邻元素： (2,1) 和 (1,4)，它们都包含了奇偶性不同的数字，因此答案为 true。

实现代码如下：

const isArraySpecial = function (nums) {
    for (let i = 0; i < nums.length; i++) {
        if (i !== nums.length - 1 && nums[i] % 2 === nums[i + 1] % 2) {
            return false
        }
    }
    return true
};

解题思路：

一开始想到的方案是：

1. 如果nums[0] 为偶数时，只要遍历偶数索引，其值如果出现奇数，则返回false
2. 如果nums[0] 为奇数时，只要遍历偶数索引，其值如果出现偶数，则返回false
3. 否则，返回true

但是，出现相邻为奇数或偶数时，是不满足条件的，因为两个条件分开判断的，所以，还是把问题想复杂化了，其实处理起来很简单，只需要判断相邻的两个数，只要出现一次奇偶性相同，则为false，否则为true。

但这里，也引申出了一个问题，检查数组边界和和不检查数组边界，哪个效率更高一点？

// 检查数组边界
if (i !== nums.length - 1 && nums[i] % 2 === nums[i + 1] % 2) {
   return false
}

// 不检查数组边界
if (nums[i] % 2 === nums[i + 1] % 2) {
   return false
}

一般来说，前者因为有一个比较的操作，所以，会影响到实际代码执行效率，但是，避免了潜在的数组越界错误；后者，没有这个比较操作，但是会有潜在数据越界错误。从健壮性和避免潜在错误的角度考虑，第一个方式是更推荐的写法。

Review

Panama evacuates islanders due to rising sea levels - Breaking News English Lesson

上升的海平面导致巴拿马撤离了其中一个岛屿的居民。位于巴拿马加勒比海岸的小岛加尔迪·苏格杜布的居民正在被重新安置到内陆。然而，一名巴拿马政府官员表示，一些人拒绝撤离他们的祖居。他们将一直留到最后一刻。巴拿马政府表示，加尔迪·苏格杜布是即将发生的事情的一个迹象，因为更多的低洼岛屿正面临被海水吞没的威胁。巴拿马环境部门最近的一项研究估计，该国将失去2.01%的沿海领土。该研究还指出，将有大约38,000人需要搬迁，成本约为12亿美元。

加尔迪·苏格杜布一直是世代居住的古纳族人的家园。这个拥挤的岛屿只有366米长和137米宽，却曾经是将近300个家庭的家园。他们依靠捕鱼和旅游业谋生。24岁的岛民纳丁·莫拉莱斯说：“我们有点难过……但海水一点一点地淹没了这个岛屿。”她补充道：“最近，我发现气候变化产生了重大影响……潮汐的水位比以前更高，而且酷热难当。”莫拉莱斯女士表示，她希望她的社区在新的地点能够繁荣。她的新家将位于距离船只前往加尔迪·苏格杜布的港口两公里处，这是一项价值1200万美元的政府开发项目。

Tip

git 切换分支

1. git branch 查看当前分支
2. git branch -r 查看远程仓库的分支列表
3. git checkout 切换到已存在的分支
4. git checkout -b 创建并切换到新分支

在切换分支前，确保你的工作目录是干净的（没有未提交的更改）。如果有未提交的更改，可以使用git stash命令将其暂存起来，然后再切换分支。

Share

布利斯定理：用较多的时间为一次工作事前计划，做这项工作所用的总时间就会减少。

1. 启示1：事前先思考，事后少烦恼。
2. 启示2：事先做计划，成功概率大。
3. 启示3：拆分大目标，再各个击破。

凡事预则立，不立则废，好计划是成功的开始。

本周的算法题为 1512. 好数对的数目

给你一个整数数组 nums 。

如果一组数字 (i,j) 满足 nums[i] == nums[j] 且 i < j ，就可以认为这是一组 好数对 。

返回好数对的数目。

示例 1：

输入：nums = [1,2,3,1,1,3]
输出：4
解释：有 4 组好数对，分别是 (0,3), (0,4), (3,4), (2,5) ，下标从 0 开始

实现代码如下：

const numIdenticalPairs = function (nums) {
    let count = 0
    for (let i = 0; i < nums.length; i++) {
        for (let j = 0; j < nums.length; j++) {
            if (nums[i] == nums[j] && i < j) {
                count += 1
            }
        }

    }
    return count
};

解题思路：

题目相对简单，使用for遍历两次，加上条件判断，累计出现好书对次数即可。

Review

UK leader wants national service for 18-year-olds - Breaking News English Lesson

英国首相里希·苏纳克计划为18岁年轻人引入国民服役制度，如果他所在的党派在7月4日的英国大选中获胜，他将推行强制国民服役。根据他的计划，年轻人满18岁时将有两个选择：一是花一年时间在陆军、海军或空军服役，政府预计约有3万人会选择这一选项；二是每月一个周末从事志愿工作，比如为英国的国民卫生服务体系、急救服务、消防服务或地方社区提供服务。苏纳克表示，这将帮助年轻人获得宝贵技能，并有助于“建设更强大的国家文化”。

然而，苏纳克的计划遭到了许多人的批评。各种专家表示，该计划成本过高，且英国没有足够的人员来培训3万名军队志愿者。许多国防专家认为这一想法不切实际。前海军司令艾伦·韦斯特表示，虽然他对更多年轻人意识到国防的重要性感到高兴，但这一想法是“荒谬的”。他认为政府需要增加国防开支，而国民服役制度将“榨取”国防资金。许多年轻人也不同意这一计划，认为它剥夺了他们的自由。然而，一名17岁的年轻人表示，这将给许多年轻人带来目标，并指出国民服役制度在数十个国家都运作良好。

Tip

升级 package.json 中全部依赖包到最新版本

在 Vue 项目 package.json 中，要将全部依赖包升级至最新版本，可以使用工具 npm-check-updates 实现，如下所示：

全局安装

npm install -g npm-check-updates

或者，npx安装

npx npm-check-updates

检查并显示最新版本

ncu -u

重新安装

npm install

至此，完成。

Share

第一次知道技术胖，是在2018年，当时看他的博客学了一下Weex，然后是Flutter，后来没怎么关注了，没想到现在退休回老家当保安了，财富自由就是可以任性，不过，生活才是最重要的。最近，看了他新发布的这篇文章。

给年轻程序员的三点启示 | 程序软技能-01 - 掘金 (juejin.cn)

“我从06年开始进入编程领域，做过Java、Python、PHP，前端，现在已经回到自己的家乡，和母亲生活再一起，过着梦寐以求的田园生活。在编程领域摸爬滚打了16年，通过这个文章，我希望能给小伙伴一些启发。现在我已经退出职场，也不准备作培训和卖课，所以分享文章的目的很简单，就是想我在程序领域走过的弯路和踩过的坑，小伙伴不要再走一遍或者再踩坑了。”

“启示一：尽早作自己喜欢的事。”

“启示二：抛开代码与人沟通。”

“启示三：慢慢建立个人权威。”

第一次知道陈皓这个名字，是在极客时间上面，因为购买了《左耳听风》课程，所以知道这个人。这个课程基本涵盖了陈皓个人网站上面的精华博文，因为很多涉及后端方面的内容，所以我并没有全部看完，只是看了技术基础、程序员练级攻略、程序员面试攻略、高效学习、高效沟通这几块内容，可以说干货满满，很受启发。并且，每次重温，都会有不同的体会。

当时购买课程之后，可以加群的，即陈皓发起的ARTS活动，自己也申请入群，不知道为什么，没有入群成功，也就没太在意。想要打卡这个活动，又觉得有点难，很怕自己坚持不下来，所以就不了了之了。

后来，听说他要和我所在的部门合作一些项目，觉得很巧，很有意思。

只是去年他过来开会，沟通项目的业务，当时他就在一楼，本来想着去见一面，能请教一下问题，但是因为是后端相关的会议，加上觉得这样不太合适，所以就没下去。

没想到过了两个多月他就因为心梗突然过世了，真是人生无常。当时看到百度热搜里那条过世的消息，心里蛮不是滋味的。

陈皓自己个人网站，酷壳上面好几篇博文都很不错，也是上面课程的内容：

1. 《谈谈我的“三观”》 - 第一步要努力实现自我价值，第二步要全力照顾好家人，第三步要尽可能帮助善良的人，第四步为族群发声，第五步为国家争荣誉。事实上作为男人，前两步成功，人生已算得上圆满，做到第三步堪称伟大，而随意颠倒次序的那些人，一般不值得信任。修身齐家治国平天下。穷则独善其身，达则兼济天下。

2. 《程序员技术练级攻略》 - 有时候我们需要更多的是抬起头来看看技术以外的事情，或者是说我们在作技术的时候不去思考为什么会有这个技术，为什么不是别的，问题不在于技术，问题在于我们死读书，读死书，成了技术的书呆子。

3. 《如何超过大多数人》 - 要超过别人其实还是比较简单的，尤其在今天的中国，更是简单。因为，你只看看中国的互联网，你就会发现，他们基本上全部都是在消费大众，让大众变得更为地愚蠢和傻瓜。所以，在今天的中国，你基本上不用做什么，只需要不使用中国互联网，你就很自然地超过大多数人了。

4. 《技术人员的发展之路》 - 能够去规划自己的个人发展的人，通常都是有很多机会和可能性的人；有很多机会和可能性的人，通常都是有Leadership，喜欢冒险的人；有Leadership喜欢冒险的人，通常都是学习能力强，思维活跃，喜欢折腾，懂得“投资”的人；学习能力强思维活跃的人，通常来说，都是喜欢看书，喜欢实践和新鲜事物，不怕艰难和挑战，用智力而不是使蛮力的人；懂得“投资”的人，通常来说，他们更多的关注的是未来和长远的成长，而不是当下的KPI、奖金和晋升。

5. 《程序员如何把控自己的职业》- 如果你想更好的把握时代，提升自己，你需要知道这个时代的趋势是什么，需要什么样的人，这些人需要什么样的能力，这些能力是怎么获得的，投入到基础知识的学习就像“基建”一样，如果基础不好，不能长高，学习能力也是需要适应这个快速时代的重要的基础能力，没有好的学习能力，很快就会掉队被淘汰。

从去年10月份开始，我突然萌生要打卡这个ARTS活动的想法，起初只是觉得我应该做这个事情，因为上班能敲代码的时间基本都没有了，只能下班回来找一点事情做，不让自己脱离代码太久了。我也并没有打算，能从ARTS打卡活动中，一定有所收获，但正是这种很坦然的心态，反而促使我坚持到了现在，而且在这过程之中，我从未有任何心理压力。

说句题外话，陈皓老师真的看起来有点虚胖，健康状态真的不是很好。所以我们还是要多注意身体，不要熬夜，坚持运动，饮食有度，毕竟身体是革命的本钱，是好几个0前面的1，没有1，后面再多的0都是徒然。我也是一样，每天要去健身房，然后，不要熬夜了。但一直以来都太忙了，其他都能坚持下来，就是熬夜总是戒不掉，争取再努力，调整回来吧。最后以陈皓老师的座右铭结尾吧，与诸君共勉：

“芝兰生于深谷，不以无人而不芳，君子修身养德，不以穷困而改志。”

本周的算法题为 1805. 字符串中不同整数的数目

给你一个字符串 word ，该字符串由数字和小写英文字母组成。

请你用空格替换每个不是数字的字符。例如，"a123bc34d8ef34" 将会变成 " 123 34 8 34" 。注意，剩下的这些整数为（相邻彼此至少有一个空格隔开）："123"、"34"、"8" 和 "34" 。

返回对 word 完成替换后形成的 不同 整数的数目。

只有当两个整数的 不含前导零 的十进制表示不同， 才认为这两个整数也不同。

示例 1：

输入：word = "a123bc34d8ef34"
输出：3
解释：不同的整数有 "123"、"34" 和 "8" 。注意，"34" 只计数一次。

实现代码如下：

const numDifferentIntegers = function (word) {
    // 1. 匹配所有的数字，返回一个数组，每个元素是一个数字字符串
    const nums = word.match(/\d+/g);
    // 2. 如果没有匹配到数字，返回0
    if (nums === null) {
        return 0;
    }
    // 3. 去掉前导0，返回一个新的数组，每个元素是一个数字字符串
    nums.forEach((n, i) => {
        nums[i] = n.replace(/^0+/, '');
    });
    // 4. 用Set去重
    const set = new Set(nums); // 去重
    // 5. 返回Set的大小
    return set.size;
};

解题思路：

1. 匹配所有的数字，返回一个数组，每个元素是一个数字字符串。
2. 如果没有匹配到数字，返回0。
3. 去掉前导0，返回一个新的数组，每个元素是一个数字字符串。
4. 用Set去重。
5. 使用 set.size 返回大小，即为所求的值。

Review

Scientists find why most ginger cats are male - Breaking News English Lesson

科学家们揭开了一个关于猫科动物的长期谜团。日本九州大学的遗传学家发现，为什么十只橘猫中有八只是雄性。佐佐木博之博士发现，X 染色体上的一个突变导致了一种此前未知的“橘色基因”。佐佐木博士说：“找到这个基因一直是我的梦想，所以终于破解了这个谜团，我感到非常高兴。”这种基因负责动物皮肤的色素沉着。雄性哺乳动物有一条 X 染色体和一条 Y 染色体。如果雄性猫的 X 染色体上有这种基因，它就会是橘色的。由于雌性猫有两条 X 染色体，所以两条染色体上都需要有这种基因，猫才会是橘色的。这种情况发生的可能性较小。

佐佐木博士及其同事的研究成果已发表在《当代生物学》杂志上。在这项研究中，研究人员分析了 18 只猫的 DNA。其中 10 只猫的毛色为橘色。研究人员发现，所有橘色猫都有一种名为 ARHGAP36 的基因突变，而非橘色猫则没有这种突变。佐佐木博士表示，猫主人通常会将毛色与性格特征联系起来。他写道：“许多猫主人坚信不同毛色和花纹与不同性格有关。目前尚无科学证据支持这一观点，但这确实是个有趣的想法，我很想进一步探究。”他还表示，橘色猫可能具有某些共同的行为特征，因为它们大多是雄性。

Tip

腾讯 ARC 图片修复工具，挺好用的。https://arc.tencent.com/zh/ai-demos/faceRestoration

Share

本周的算法题为 1556. 千位分隔数

给你一个整数 n，请你每隔三位添加点（即 “.” 符号）作为千位分隔符，并将结果以字符串格式返回。

示例 1：

输入：n = 123456789
输出："123.456.789"