原则就像是指引行动的“灯塔”，它将我们的价值观与行动相互连接。本文对十条精进原则进行了总结，希望能给大家带来启发，从而更好地指导我们的行动。

8 年前，我开始了人生中的第一份实习工作，是在某互联网公司的无线搜索部担任 C++工程师。那时的我满怀豪情，决心大干一番。然而，第一次上线时，我写下了人生中的第一个东西。因为对部署环境不了解，我错误地将 SVN 库里的配置文件发送到了线上，并且在上线后就去吃晚饭了。等我吃完饭回来，发现师傅正在焦急地回滚配置。那次故障使得一个核心服务有 20 分钟无法使用，这影响到了几百万的用户。 那次故障导致一个核心服务处于 20 分钟的不可用状态，几百万的用户受到了影响。 那次故障致使一个核心服务 20 分钟不能用，几百万的用户被波及。

这只是一个开端。在之后半年的时间当中，我几乎把所有职场新人有可能犯下的错误全都犯了一遍。架构师让我去调研一个抓取性能提升的方案，我埋头苦干了两周，却始终未能得出任何结论。原本安排好的开发计划，因为我临时需要回去写论文，让经理措手不及。在参加项目座谈会时，我全程都只是在“打酱油”。那段时间，我自己也感到十分苦恼，几乎每天晚上都要到 11 点多才能离开，虽然很累很辛苦，但依然无法获得想要的结果。

8 年已过，自己从初入职场的小白逐渐成长为一名技术人员。我察觉到团队里的许多同学在不断地重复犯下自己当年类似的错误。他们并非不努力，那到底是何处出现了问题呢？

我经过一段时间的观察与思考，认为自己找到了答案。答案是：我们大多数同学在工作时缺乏原则的指导。

原则，犹如指引行动的“灯塔”，它连接着我们的价值观与行动。

不久前，桥水基金的创始人雷·达里奥在《原则》这本书里所传达的那些理念，在朋友圈引发了爆炸式的传播。每个人都应当拥有属于自己的原则，当我们面临选择的时候，必须要以原则为核心并始终坚持。然而在现实的生活里，我们通常缺乏对原则的归纳总结，对于很多人而言，这就像是一门“只能用心去体会而无法用言语表达清楚”的玄学，是老司机所独有的秘密，其实这种看法是不正确的。

美团的价值观是“追求卓越”。作为技术人员，我们需要思考怎样去践行这一价值观呢？

本文总结出了十条精进原则，期望能给大家带来些许启发，从而更好地对我们的行动进行指导。

原则一：意识

“意识”主要体现在以下两个层面：其一，具备认真负责的态度；其二，拥有积极主动的精神。

1）认真负责是工作的底线

首先，要对交付的结果承担责任。在项目中，每一份设计文档都要认真完成，每一行代码也都要认真编写，要对它们的质量负责。倘若设计文档逻辑混乱，代码没有注释，在测试时发现诸多 Bug，那么影响的不只是 RD 的工程交付质量，还会给协同工作的 RD、QA、PM 等带来不良影响。时间一长，团队的整体交付质量会逐步下降，工作效率也会逐步下降。甚至还会让团队成员之间产生不信任感。

其次，我们需对开发的系统承担责任。系统的架构方面是否需要改进，接口文档是否完备，日志是否完整，数据库是否需要扩充容量，缓存空间是否足够等，这些都是需要付诸实践的事宜。作为系统，务必认真地去履行。

2）积极主动是“意识”更高一级的要求

RD 每天需面对众多工作，其中许多还不在计划之中，这就要求具备积极主动的精神。比如我们每天或许会遭遇大量的技术咨询，倘若客户提出的问题长时间未得到回复，就会导致不良的客户体验。

很多同学称因忙于工作而无暇处理；有同学认为此事不重要；还有很多同学看到了，但不知如何作答；更有同学看到后干脆装作没看见，这些都体现出缺乏意识。正确做法是积极主动地推动问题解决，若时间无法安排或不知如何解决，可直接将问题反馈给能解决的同学。

积极主动在更多方面有体现。例如：许多同学会自发地对负责服务的现状进行梳理，依据接口在性能方面暴露出的问题提出改进的意见，并且持续推动问题的解决；还有同学在跨团队沟通时主动担当主 R 的角色，积极地去发现问题、暴露问题，促使合作团队的进度得以推进，保障项目能够顺利进行。

这些同学都是团队的重要力量。因此，我们在做好本职工作的同时，要积极主动地参与到“份外”工作中。付出就会有收获，不要限制自己，努力让自己变得更优秀。

原则二：时间观念

大家都有时间观念，然而真正能将其执行到位的或许并不多。互联网属于快速发展的行业，研发部门（RD）的研发效率能重要体现一个公司的硬实力。项目按期交付是一项极为重要的执行能力，在很大程度上会决定领导和同事对自身靠谱程度的评价。

大家或许会问：项目的难度几乎是一样的，为什么有的同学时常能够按时上线，而有的同学每次都能做到按时上线呢？

一个重要原因在于，这些按时交付的同学通常具备以下两个特质：其一，做事有计划；其二，工作能分主次。

1）工作安排要有计划性

通常，RD 在设计评审结束后能够预估出准确的开发时间，接着便可合理地安排开发、联调、测试计划。若身为项目负责人，便会牵涉到协调 FE、QA、PM 等多个工种的同学一同完成工作。凡事预先做好规划就能成功，没有预先规划就会失败。在制定计划的过程中，要尽量将每一项拆分得细致一些（至少要达到 pd 的粒度）。事实表明，粒度细化后，计划会更精准，实际开发时间与计划之间的误差也会变小。

此外，要规定明确且可检查的产出，并且在计划中设置一些关键的时间点来进行核对。很多项目延期的事实告诉我们，很多时候是因为在一些关键交付点上双方存在分歧导致的。比如：后台 RD 的接口文档计划在周五提供，FE 认为是周五上午，RD 认为是周五下班前提交，这会给排期带来 1pd 的误差。所以，我们要做到计划粒度足够细，关键时间点要可检查。

2）工作安排要分清楚主次

我们每天需面对诸多事情，要懂得分辨这些工作的主次。能够尝试运用“艾森豪威尔法则”（四象限法则），将工作依据重要程度以及紧急程度划分成四个象限。

优先处理重要且紧急的事情；对于重要但不紧急的事情，可以先放一放，不过要持续推进；紧急但不重要的事情，可以根据情况委托给最适合的人去做；不重要也不紧急的事情，可以思考是否不做。

很多项目无法按期交付，原因在于执行人分不清主次。例如，在开发过程中需要使用 ES，一些不熟悉 ES 的同学，可能会想系统性地学习这方面的知识，于是就一头扎进 ES 的汪洋里。最后才发觉，原本一天就能完成的工作被严重拖延了。

在实际工作里，我们得避开这种“本末倒置”的工作方式。就拿本例来说，“系统性地学习 ES”属于重要却不紧急的事。要能够分辨出这些会产生干扰的工作项，以此确保重要紧急的事情能够按时完成交付。

原则三：以终为始

1）先想清楚目标，然后努力实现。

史蒂芬·柯维在《高效能人士的七个习惯》中提到了一个习惯，即“以终为始”。这个习惯是以所有事物都经过两次创造的原则为基础的，第一次是心智上的创造，第二次是实际的创造。

在工作里，很多研发人员（RD）常常只是专注于埋头做事，很少去抬头观察周围的情况。每当进行季度总结时，会罗列许多项目，也付出了大量的努力。然而，具体到这些项目究竟获得了哪些收益，对业务起到了哪些提升作用，却难以清晰地表述出来。这表明在工作过程中并未遵循“以终为始”这一重要原则。

很多同学在做需求时，对目标和收益关注不足。系统上线后，他们也没有持续跟进使用效果。这一情况在技术优化项目中表现得很明显。

在一个接口性能优化的项目里，RD努力进行优化后，系统的 TP99 被缩短了 60%，对 QPS 的支持提升了 2 倍。然而，系统究竟需要优化到何种程度呢？是不是缩短 60%且提升 2 倍就能满足需求呢？

2）根据问题设定目标，再进行优化

很多同学在优化之前常常会忘记去设置一个预设的目标，这个目标比如是 TP99 要小于多少，同时支持的 QPS 要大于多少。我们要清楚，进行优化是有原因的，像预期某节假日的流量会急剧增加，或者某接口的超时比例过高。如果不进行优化，系统就可能会有宕机的风险。而解决特定的问题才是技术优化的最终目的。

“以终为始”这一原则在我们的学习中也能发挥作用。许多同学看过大量的技术文章，然而却始终觉得自己一无所知。其中一个很重要的原因便是没有怀揣着目标去进行学习。

在这个信息爆炸的时代，倘若仅仅是碎片化地接收各个公众号推送而来的文章，那么其效果几乎是可以不予考虑的。在展开学习之前，我们务必要扪心自问，此次学习的目标究竟是什么？

想把持久化原理弄清楚，还是把主从同步机制弄明白，或者想学习整个架构体系呢？如果带着问题与目标去进行相关资料的搜集与学习，就会事半功倍。这种学习模式的效果比碎片化阅读好很多。

原则四：闭环思维

你是否曾遇到这样的场景：参与了一个设计（或需求）的评审。在评审过程中，大家兴致盎然地提出了许多合理的意见。然而，当再次进行评审时，却发现第一次提出的很多问题都没有得到改善。并且，许多之前讨论过的问题还需要重新开始讨论。这种情形就是一种典型的工作未形成闭环的情况。

之前看过一句话：

3. 事事都有回音。

闭环思维很重要。它强调的是即时反馈闭环。当别人给我们分配一个任务时，无论完成结果怎样，都必须在规定时间内给出明确反馈。

在跨部门的沟通会议里，各方达成了一致，并且会议发起者把最终的记录让大家都知道了。然而，到这一步并不能算是完成了真正的闭环，在落地执行的过程中很有可能还会有一些潜在的问题。

会议纪要是否经过了各方的仔细核对并予以确认呢？会议中明确的待办事项（To Do）的进展情况是怎样的？是否有关于完成结果的相关机制呢？

如果没有做到这些，就会陷入这样一种恶性循环：先是沟通，接着发现问题，然后再次沟通，之后又再次发现问题。

真正的闭环意味着我们要在工作中养成良好的思维习惯。对于工作中的事情，沟通必须要有结论，通知一定要有反馈，To Do 则需要有验收。

“闭环思维”还要求能够主动进行阶段性的反馈且要定期。刚参加工作时，我承接了一个工期两个月的项目，此项目需独自完成，我每天都按计划有条不紊地进行开发。大概过了两周，当询问项目进度时，尽管我已告知没问题，但他却告诉我，由于我每天对着电脑不说话，这让他心里很没底。

这时，我意识到一个重要问题，我与他之间存在信息不对称。从那之后，我会时不时向他汇报进度，即便只是简短的一句话，也能明显感觉到他对我的信心增加了许多。特别是在我做事之后，对这种闭环反馈的理解更加深刻了。从他的角度来看，其实只是想知道项目是否在正常推进，是否遇到需要他协助解决的问题。

原则五：保持敬畏

君子之心常存敬畏。保持敬畏之心，能使我们少犯错误。工作中有各种规范，像代码规范、设计规范、上线规范等。我们要明白，这些规范的制定是基于某些客观原因的，它们是历史上无数案例积累的经验。团队中的每一个成员都应学习并严格遵守，对于新人来说，这一点尤为重要。

当进入新团队时，首先要暂时忘却之前的习惯。接着要尽快学习团队已有的规范，使自己与团队保持一致。比如在编码风格方面，很多同学习惯了自己之前的代码写作风格，在做新公司的第一个项目时，会按照自己的习惯进行变量、包的命名等操作。然而，在代码过程中，会被提出很多修改意见，导致不得不返工重写，这是得不偿失的。

如果能怀有敬畏之心，并且提前去了解编码规范，那么这种问题是完全可以避免的。

类似的问题包含对上线流程不了解，对回滚操作不熟悉，对 SRE 线上变更过程不了解等情况。除了这些明显的规范外，还有一些约定俗成的规则。个人的建议是：若有事情不确定，可多向其他同事询问，不要仅凭自己的感觉行事。

保持敬畏之心并不意味着要“因循守旧”。当我们充分了解这些规范和约定后，如果觉得有不妥之处，能够与全组同学进行讨论，探讨是否采纳新的建议，接着及时进行更新迭代。实际上，让规范与约定与时俱进，这也是另一种形式的敬畏。

原则六：事不过二

“事不过二”是我们团队一直秉持的原则，这一原则可以被解读出两层含义。

一层含义是“所有的评审以及问题讨论，需控制在两次以内”。之所以有这样的要求，是因为我们察觉到，许多 RD 都将时间耗费在一些没有尽头的评审与问题讨论上，而真正投入到实际开发中的时间却很少。在实际的工作情形里，我们时常会碰到一些并非很成熟的需求评审。这些需求文档，有的背景与目标模糊不清晰，有的产品方案描述不够细致，还有的存在歧义。RD 与 PM 不得不反复开展讨论，我曾经历过一次需求评审，历经三次仍被打回。

同样的问题在设计评审中时常出现。方案需要经过反复讨论，然而若迟迟无法达成一致，就会浪费很多 RD 与 PM 的宝贵时间，这与提升研发效率的理念相违背，所以我们团队规定：所有的评审最多进行两次。

这种方式能促使利益相关方尽力做好需求与方案设计。在评审会议组织之前，试着与所有相关人员达成一致，询问他们的意见，然后进行有针对性的讨论，如此一来，评审会议的效率和质量能得到大大提升。若第一次评审未通过，仅有一次复审机会。若两次都未通过，就需要进行相关操作。

“事不过二”原则还有一层含义，即“同样的错误不能第二次犯”。每次出现故障后，都要进行深刻的总结复盘工作，针对故障原因进行 5Why 分析，并且给出明确且可执行的 To Do List。在每次的季度总结会上，大家要自我反省存在的问题，在下一个季度必须有所改进，不能再犯类似的错误。孔子说：“不要把怒气转移到别人身上，不要犯两次同样的错误。”在错误之中进行反思并且获得成长，这样才能够让我们成为更加优秀的人。

原则七：设计优先

“设计优先”这一原则相对更为具体。之所以将其单独列为一项，是因为架构设计具有极为重要的地位。

Bob曾说过：

软件架构的目标在于使构建和维护系统所需的人力资源达到最小化。

架构设计不仅与系统的质量相关，也关乎团队的效能。许多团队都有明确规定，对于开发周期在 3pd 及以上的项目必须有设计文档，对于开发周期在 5pd 及以上的项目必须进行设计评审。在实际执行过程中，因各种原因，设计常常无法达到预期效果。

究其原因，一部分是项目周期紧，导致来不及进行足够详细的设计。还有一部分是 RD 主观上觉得项目较为简单，所以设计得很草率，敷衍了事。

无数事实表明，前期设计被忽略，后续开发周期往往会大幅拉长，给项目带来很大风险。并且，最可怕的是，不当的设计会使项目后期维护成本巨大，我们不得不腾出时间专门对项目进行优化与重构。

因此，要记住“设计优先”这一原则。前期有良好的设计，磨刀就不会耽误砍柴。前期良好的设计，会给项目开发以及后期维护带来很大的收益。

“设计优先”这一原则要求所写的设计要让他人能够看懂。我们了解一个系统最为直接的方式就是将设计文档与代码结合起来。在实际的工作里，很多同学所撰写的设计文档让大家感到十分困惑，从头到尾看完后，都无法清晰地看出系统整体的设计思路。

设计的过程实际上是一种智力方面的创造。我们更期望它能够成为个人的智慧与集体的智慧相结合的结晶。

如何才能让我们的设计变得通俗易懂？

我认为设计应尽量运用合理逻辑，以此将设计中的一些点进行组织。例如：能够采用从抽象到具体、由总到分的结构来安排材料。在设计期间，需以需求作为起始点，借助合理的抽象把问题进行简化，阐明各个模块之间的关系，之后再详细地分述模块的实现细节。

做完设计之后，能够发给较为资深的 RD 或者 PM 进行审阅。接着，依据他们的反馈来进一步完善设计。优秀的设计，必然是逻辑清晰且易于理解，同时细节能够落地并可执行的。

原则八：P/PC平衡

“P/PC 平衡”原则，也就是产出与产能平衡的原则。伊索寓言里有个《生金蛋的鹅》的故事，产出就如同“金蛋”，产能就如同“会下金蛋的鹅”。那些“重蛋轻鹅”的人，到头来或许连产蛋的资产都无法保住；而那些“重鹅轻蛋”的人，最终很可能会被饿死。只有产出与产能保持平衡，才能够实现真正的高效能。

为了让大家更清晰的了解这一原则，本文举两个例子：

从系统角度而言，每一个系统都是依靠持续不断地叠加功能，以此来达成其产出。而系统的产能是由系统架构的可扩展性、稳定性等一系列特性所体现出来的。为了让产出与产能达到平衡，就需要在持续满足业务需求的过程中，不断地在技术架构层面进行优化。

如果只是一味地去做业务需求，随着时间的推移，系统的运行速度会逐渐变慢，并且最终会对业务的稳定性产生影响。相反，一个完全没有任何业务产出的系统，到最后是会消亡的。

从 RD 的角度来审视这个问题，RD 通过开展需求来为公司创造价值，以实现自身的产出。RD 的产能包含技术能力、软素质以及身体健康状况等方面，具备这些资本后，我们才能够持续地进行产出。在日常工作里，我察觉到许多 RD 常常仅仅注重产出。他们在做项目时非常努力，然而每个项目所采用的方法，依旧是沿袭自己之前一贯的思路。最终，不仅项目做得一般，还会抱怨自己得不到任何成长。

这体现了 P/PC 的不平衡。在做项目的过程中，通过学习总结，能够持续提升自己的技术能力和软素质，并且将这些提升应用于项目实施交付中，相信就一定会取得双赢的结果。

“P/PC 平衡”原则在很多其他领域也适用，像团队领域、家庭领域等。我本人对这一原则极为推崇。希望大家能把它当作自身的一项基本原则，去努力找到产出与产能之间的平衡点。

原则九：善于提问

“善于提问”，首先要保持提问的勤快。求知欲源自好奇心，这是人类的一种本能。在工作过程中，要逐渐养成经常提问的好习惯，遇到不懂的就及时询问，不能因为自身一时的懒散或者碍于面子等原因，就舍弃提问的时机。当碰到不同的观点时，也应当以礼貌的方式问出来。波克定理向我们表明，只有在进行争辩的时候，才有可能产生最好的主意和最恰当的决定。

在设计评审以及代码评审这类能够体现集体智慧的活动里，遇到存在问题的地方就必须要提出来。我时常能看到，许多同学在评审过程中一直都不说话，这无疑是在浪费大家的时间。设计评审的目的在于，让大家针对相关方案提出改进的意见并且达成一致，如果在整个过程中只是“敷衍了事”，那就丧失了评审的意义。我们鼓励大家多提问，将自己内心的疑惑表达出来。接着，通过交流这种方式去获得答案。

要善于提问，就必须懂得如何提问。在参加设计评审时，会出现这样的情况：有的同学能够提出很好的问题，然而有的同学却提不出任何问题，这是为什么呢？

除了在知识储备、专业技能以及经验等方面存在差异之外，还有一个很重要的方面，那就是批判性思维。

批判性思维提倡通过批判性思考来达成理性思维，也就是对事物本质的认知与把握。对于怎样进行批判性思维，大家能够参考一些经典的图书，像《批判性思维》《学会提问》等。在工作面临决策时，会有诸多意见呈现在你面前。因此，我们得学会运用批判性思维去分析，要考量每个人的论据是否可靠，论证是否合理，以及是否存在隐含的立场。

同样，在阅读一篇技术博客时，需运用批判性思维。要多问几个为什么，比如作者得出的结论是否合理，论据是否充分。

只有这样，才能不断地获取真正的知识。

原则十：空杯心态

“满招损，谦受益”，其中“空杯心态”是最后一项原则。我认为这是一个人能够持续成长的前提。做技术的人，骨子里一般带有一股傲气，并且会随着资历的增长、成绩的提升而不断增强。初入职场的新人，或许会十分谦虚，然而工作几年后，专业技能逐渐提升，或许还取得了一些小成果，人就会越发自信。

这时候，若不能一直保持“空杯心态”，那么这种自信就会渐渐演变成自满。自满的人，在工作中常把别人的建议视为批评，不接纳任何反对意见；在学习上，也缺少求知的动力，总是用自己的长处去和别人的短处进行比较。实际上，每个人或多或少都会有一些自满，而可怕的是既不知道也不愿意承认自己有自满。

保持“空杯心态”这一原则，要求我们时刻进行自我检视与反省。在工作中，我们可以多跟不同级别的同学聊一聊，也可以做一个 360 度评估，这样有助于我们更加客观地评价自己。在横向对比时，我们要多向那些优秀的同学看齐，学习他人的优点。

很多同学在设计评审或代码过程里，当别人提出问题与建议时，常常会采取一种对立的态度。他们错误地觉得别人是在挑毛病，是在针对自己。

诚然，在某些方面，我们或许确实比其他人思考得更为深入。然而，这并不意味着在所有方面我们都能考虑得十分周全。对于别人的建议，建议运用“善于提问”原则中所提到的批判性思维，对其进行仔细的分析，并且要以虚心的态度吸取那些有益的建议。

工作学习如同“练级打怪”，技能储备越多，就越易于走到最后。保持空杯心态，能让我们察觉到许多以往留意不到的新能力。我们要努力学习这些新能力，并将其转化为自身能力库的一部分。

总结

以上是我总结的工作与学习的十条基本原则。有的原则侧重于个人做事情的方法，像“意识”“时间观念”“以终为始”“闭环思维”；有的原则侧重于团队工作的标准规范，例如“保持敬畏”“事不过二”“设计优先”；有的原则侧重于团队或个人效能的提升，比如“P/PC 平衡”“善于提问”“空杯心态”。

这些原则是我在多年的工作与学习过程中，经过不断总结而获得的经验。希望在大家面临选择的时候，这些原则能够发挥一定的作用，给予帮助和指导。

以原则为中心地工作与生活，让自己与团队变得更加强大。

若有收获，就点个赞吧