优秀软件工程师日常开发流程SOP

前言

技术SOP讲的是怎么写代码、怎么测试、怎么部署，但一个优秀的软件工程师和普通工程师的差距，往往不在技术操作上，而在日常开发的工作流程和习惯上。

这篇文章总结的是”一天的工作应该怎么过”，是开发流程层面的SOP，而非技术层面的SOP。

为什么一定要有SOP

我个人的经历是：刚工作的时候，做事情全靠”感觉”。拿到一个任务就开始写代码，遇到问题就到处查，做完了也不总结。看起来每天都很忙，但效率并不高，而且同样的错误会反复犯。

后来我发现，身边那些真正高效的工程师，做事情都有一套自己的流程。他们不一定会把它叫做”SOP”，但他们处理任务的方式是有章法的——什么时候该读文档，什么时候该问人，什么时候该写代码，什么时候该停下来想一想，都有一个相对固定的节奏。

SOP的价值在于：

1. 减少决策疲劳。每天面对的事情很多，如果每件事都要从零开始想”我该怎么做”，大脑会很快疲劳。有了SOP，常规操作不用思考，把精力省下来给真正需要创造力的问题。

2. 避免重复犯错。人在忙的时候容易忘事，容易走捷径。SOP就是一个检查清单，保证关键步骤不会被跳过。我自己就有过好几次因为跳过了”先和队友对齐方案”这一步，结果代码写完了被推翻重来的经历。

3. 让成长可积累。没有SOP的时候，每次做事都是一次性的经验。有了SOP，每一次的教训都可以变成流程的改进，这样能力是在不断叠加的，而不是原地踏步。

4. 提升团队协作效率。当团队成员都有相似的工作流程时，协作的摩擦会大大减少。你知道队友什么时候会提PR，什么时候会做review，沟通的预期是一致的。

简单来说，SOP不是让你变成机器人，而是把那些不需要创造力的事情标准化，让你有更多的精力去做真正有价值的事情。

我自己解决工作任务的SOP大致如下：

第一步：用AI理解需求。 拿到一个任务后，我会先把需求文档、ticket描述、相关的设计文档喂给Claude或者ChatGPT，让AI帮我梳理需求的核心要点、可能的边界情况、以及我需要确认的问题。AI在理解和总结文本方面非常高效，比自己反复读文档要快得多。特别是面对一个不熟悉的业务领域或者一个很长的需求文档时，AI可以帮你快速抓住重点，列出关键问题。在这一步中，还要让AI把理解到的需求拆解成具体的task列表，方便后续追踪进度。比如让Claude创建一组task：哪些是前置调研、哪些是核心开发、哪些是测试验证，每个task标注状态（未开始、进行中、已完成）。这样做的好处是，整个任务的全貌在一开始就被梳理清楚了，后续执行的时候不容易遗漏步骤，也方便向队友或者manager同步进展。当然，AI的理解不能替代你自己的判断，但它是一个很好的起点。

第二步：查看是否有已经解决过的相同或类似问题。 很多时候你遇到的问题，团队里早就有人解决过了。所以在动手之前，先去搜一搜：查Slack历史消息、搜项目的ticket和文档、翻git log和代码里的相关模块，看看有没有类似的实现可以参考。如果有，直接复用或者在已有方案的基础上改进，效率会高很多。如果没有找到，至少你也对现有代码和系统的上下文有了更深的了解，后面写方案和代码的时候会更有方向感。不要重复造轮子，站在前人的肩膀上是最聪明的做法。

第三步：还是不会，立刻求助，不要拖。 经过前两步，如果你对这个任务仍然没有清晰的思路，不要一个人卡在那里死磕，更不要因为”不好意思”或者”怕被觉得能力不行”就拖着不说。正确的做法是第一时间向上级或者同事发消息求助。你可以说”我看了需求和相关代码，目前卡在某个点上，我的理解是……想确认一下方向对不对”。这样的求助是专业的，不是示弱。真正不专业的做法是：卡了一天什么产出都没有，到了deadline才说自己不会。及时汇报问题是一种责任感的体现——团队需要知道任务的真实状态，才能做出正确的调度。记住，拖延和沉默才是最大的风险。

第四步：总结和准备，为下一次开会做好功课。 在任务推进过程中，随时整理好四个清单：（1）已经完成了什么；（2）接下来要做什么；（3）哪些地方自己不会或者有疑问；（4）针对疑问，自己预备的可能方案是什么。这四个清单就是你在standup、1on1或者任何同步会议上要汇报的内容。不要等到开会的时候才临时组织语言，提前准备好，开会的时候三分钟就能把事情讲清楚。而且，带着预备的解决方案去提问，和空手去说”我不会”，给人的印象和获得的帮助是完全不同的——前者是在推动问题解决，后者是在把问题甩出去。

正文

一、开始工作前：明确今天要做什么

1. 查看自己的任务列表（Jira、Linear或其他项目管理工具），确认今天的优先级

不要一上来就打开IDE写代码。先花5到10分钟搞清楚今天最重要的一件事是什么。

判断优先级的原则：

一个常见的陷阱是：把大量时间花在P2的事情上（因为它们”紧急”，会不断弹消息提醒你），而P1的核心任务一直没有推进。每天开始工作时，先确认自己今天的P0和P1是什么，把它们排在最前面。

还有一个非常重要的原则：优先选择领导和客户都能看得见的任务。 比如Live issue、客户直接反馈的bug、影响业务指标的问题，这些任务的优先级天然就高，因为它们直接影响到团队和公司的信誉。你花一天修一个Live issue，比花三天做一个内部优化，在组织里产生的价值和可见度完全不同。

而且，优先级越高的任务，越要在可见的地方进行日更。 P0和P1的任务，每天必须在ticket、Slack频道或者邮件中更新进展，让上级和相关方随时能看到当前状态。不要觉得”我在做就行了，做完再说”——对于高优先级任务，过程的透明度和结果一样重要。领导和客户关心的不只是”最终有没有解决”，而是”现在什么情况、什么时候能解决”。主动日更进展，既是对上级负责，也是保护自己——万一方向有偏差，别人能及时帮你纠正。

1. 检查是否有阻塞项

例如：是否在等别人的Code Review？是否有依赖的服务还没准备好？如果有阻塞，第一时间推动，不要被动等待。

1. 检查消息和邮件

快速浏览Slack、邮件，只回复紧急的。非紧急的标记稍后处理，不要让消息打断你的规划。

二、接到一个新任务：先理解再动手

1. 读清楚需求

不要拿到任务就写代码。先把需求文档、设计文档、相关的ticket全部读一遍。

如果需求不清楚，立刻找PM或者提需求的人确认，不要自己猜。猜错了返工的成本远大于问一个问题的成本。

1. 评估工作量和影响范围

这个改动涉及哪些文件、哪些服务？有没有上下游依赖？需不需要数据库迁移？

在心里或者笔记里列出大致的步骤，预估时间。如果超过预期，及时和团队沟通。

1. 和队友对齐方案

对于非trivial的改动，在写代码之前先把方案说一下，可以是简短的Slack消息，也可以是一个简单的设计文档。

这一步很多人跳过，结果写完了发现方向不对，浪费了大量时间。

三、写代码：小步快走

1. 从最小可验证的改动开始

不要试图一次性完成所有功能。先写最核心的部分，跑通一个最小的路径，确认方向是对的。

1. 频繁保存和提交

每完成一个小的逻辑单元，就做一次git commit。提交信息要有意义，不要写”fix”或者”update”。

好的提交历史是给未来的自己和队友的礼物。

1. 边写边测试

不要等所有代码写完再测试。写一部分就测一部分，发现问题可以立刻修，不用回头从一大堆改动中找bug。

1. 善用AI工具

Copilot、Claude等AI工具可以加速开发。但要注意：AI生成的代码一定要自己读一遍、理解一遍，不能盲目接受。

四、提交Code Review：让reviewer的工作变轻松

1. PR要小而专注

一个PR只做一件事。如果一个任务很大，拆成多个PR。大PR没人愿意review，小PR能更快合并。

1. 写好PR描述

说明这个PR做了什么、为什么要这么做、怎么测试的。如果有UI变化，附上截图。

1. 自己先review一遍

提交PR之前，先自己在GitHub上看一遍diff。你会惊讶于自己能发现多少问题：多余的调试代码、忘记删除的注释、不一致的命名。

1. 主动推动review

提交后在Slack或者团队频道通知一下reviewer。不要提交了就等着，如果超过半天没人review，主动去催。

五、Code Review别人的代码：认真对待

1. 理解上下文

先读PR描述和关联的ticket，理解这个改动的目的。不要上来就逐行看代码。

1. 关注设计而非风格

代码风格应该交给linter和formatter。Review的重点是：逻辑对不对？边界条件有没有处理？有没有更简单的实现方式？

1. 给出建设性的反馈

不要只说”这里不对”，要说”这里可能有问题，因为……建议改成……”。好的review是一次技术交流，不是挑毛病。

1. 及时完成review

别人在等你的review才能合并代码。尽量在一天内完成review，最好在几小时内。

六、遇到问题：有策略地求助

1. 紧急事务：可用性大于一致性，先稳住人再解决问题

遇到紧急的临时事务——客户报了一个严重bug、线上出了故障、上级突然问进展——第一件事不是埋头去解决问题，而是用明确的语言和态度先稳住对方。 无论你自己当时能不能解决，都要立刻回复，表达三层意思：（1）我已经收到了；（2）我正在处理；（3）预计什么时候给下一步反馈。

这就像分布式系统里的CAP定理：在紧急时刻，可用性（Availability）大于一致性（Consistency）。你不需要等到有了完整的答案再回复，先给一个及时的响应，让客户和上级知道事情有人在管，心里有底。沉默是最糟糕的回应——对方不知道你是在处理还是根本没看到，焦虑会迅速升级。

即使你完全不知道怎么解决，也可以说”我正在排查，十分钟后给您更新”。这句话本身就能极大地降低对方的焦虑。之后再去调查、求助、解决，但稳住人永远是第一步。

1. 非紧急问题：先自己调查15到30分钟

看报错信息、查日志、搜文档、读源码。大部分问题在这个阶段就能解决。

1. 如果解决不了，整理清楚再提问

向别人求助的时候，说明：

• 你要做什么
• 你遇到了什么问题
• 你已经尝试了什么
• 你目前的猜测是什么

不要只说”这个不工作了”。整理问题的过程本身往往就能帮你找到答案。

1. 选择合适的求助方式

简单问题发Slack消息，复杂问题约个简短的meeting或者pair programming。不要用一长串Slack消息讨论复杂的技术问题。

七、遇到问题：尽量全自己做

一个核心原则：若非必要，绝不交给别人做。 遇到问题，不管是bug、技术难题还是流程上的阻碍，第一反应永远是自己动手解决。不要习惯性地说”这个问题我不太熟，让某某来看看吧”——这种心态一旦养成，你的能力就永远停留在舒适区里。每一次自己硬啃下来的问题，都是实打实的成长。

自己做的好处是显而易见的：你对系统的理解会越来越深，解决问题的速度会越来越快，在团队中的信任和影响力也会越来越大。而把问题甩给别人，短期看省了时间，长期看你失去了学习的机会，别人也会觉得你缺乏ownership。

只有在真正确认自己没有能力解决（比如涉及完全不同的技术栈或者需要特殊权限）的时候，才考虑请别人帮忙。即便如此，也要全程跟进，把别人的解决过程当作一次学习，保证下次遇到同样的问题自己能独立处理。

如果当前确实没有时间处理，那么至少要做一件事：在项目管理工具中创建一张card，放到backlog里。 card里写清楚问题是什么、你观察到的现象、可能的影响范围。保证问题可见，不会被遗忘。

还有一点：永远不要卡壳。 如果你在一个问题上卡住了，不要干坐着发呆或者反复尝试同样的思路。卡住了，说明你在这个点上的基本功有缺失——可能是对某个概念理解不到位，可能是对某个工具不熟悉，可能是对系统的某个模块缺乏认知。这个时候，第一时间打开Claude或者ChatGPT，把你卡住的问题描述清楚，让AI帮你梳理相关的基础知识。AI最擅长的就是快速把一个知识点从零讲清楚。把基础补上了，原来卡住的问题往往就迎刃而解了。不要把”卡壳”当成正常状态来忍受，它是一个信号，告诉你这里有一个知识盲区需要填补。

八、主动让老板看到你的成果

很多工程师有一个误区：觉得自己把活干好了，老板自然会看到。现实是，老板非常忙，根本没有精力关注每个人在做什么。 他可能同时管着好几个项目、十几个人，每天被各种会议和决策填满。你做了一个很漂亮的优化，如果你不说，他大概率不知道。

所以正确的做法是：你来push老板，而不是等老板来关注你。

• 完成了一个重要任务或者解决了一个棘手的问题，主动在standup、1on1或者Slack里简要汇报
• 汇报的重点不是”我做了什么”，而是”这件事产生了什么价值”——比如”修复了这个Live issue，影响了多少用户，响应时间从多少降到了多少”
• 抓住合适的时机，不要等季度review的时候才想起来整理自己的成果，那时候很多细节已经记不清了
• 周报、月报不要写流水账，要突出亮点和影响

这不是在邀功，这是在帮老板了解团队的真实产出。老板需要这些信息来做决策、争取资源、向上汇报。你主动提供这些信息，对双方都有好处。埋头苦干不说话，最后吃亏的一定是自己。

九、结束工作前：收尾和准备

1. 更新任务状态

在项目管理工具中更新今天完成的任务状态。如果有阻塞或者延期，写清楚原因。

1. 总结今天的进展

花2到3分钟想一下：今天完成了什么？明天要做什么？有没有需要别人帮助的？

这个习惯看起来微不足道，但长期坚持下来，对自己的工作节奏感和掌控感提升很大。

1. 清理工作环境

关闭不需要的浏览器标签页，整理桌面，推送未提交的代码到远程分支。

保证第二天打开电脑的时候，能在一个干净的状态下开始工作。

八、跨团队沟通：主动而透明

1. 进度同步不要等别人问

如果你的任务和其他团队有关联，主动同步进度。特别是遇到延期或者方案变更的时候，越早通知越好。

1. 会议之前准备好要说的内容

Standup、weekly sync等例行会议，提前想好要说什么。会议不是想到哪说到哪的地方，高效的会议来自充分的准备。

1. 文档记录重要决定

口头讨论的结论，事后写到文档或者ticket里。人的记忆不可靠，文档才是单一事实来源。

1. 不要以为同事”懂了”就是真的懂了

这是沟通中最大的坑之一。你讲完一个方案，同事点头说”嗯嗯，了解了”，你就以为对齐了。结果一周后发现，两个人理解的完全是两回事。

避免这个问题有两个方法，而且两个都要定期反复做：

第一，画图。 不管是系统架构、数据流向还是业务逻辑，用图说话永远比用嘴说清楚。一张图能消除90%的歧义。不需要多精美，白板上随手画、或者用工具快速出一个示意图就够了。关键是让双方看到的是同一个东西，而不是各自脑海中想象的不同画面。

第二，问feedback。 讲完之后不要问”你听懂了吗”（大部分人会条件反射地说”懂了”），而是问”你觉得这个方案有什么问题？”或者”你能复述一下你的理解吗？”。让对方主动输出，你才能判断他是否真的理解了。

这两件事不是做一次就够了。项目推进过程中，每到一个关键节点，都要重新对齐一次。人的理解会随着时间和新信息不断变化，上周对齐的东西，这周可能已经偏了。

1. 在公共平台发言：果断、犀利、成熟

在Slack、GitHub、邮件等公共平台上发言，你的文字就是你的形象。不要用模棱两可的语言，不要一次抛出一堆问题。 这样做会让老板、同事甚至AI工具（比如用AI做绩效分析的公司）认为你思路不清晰、缺乏独立判断的能力。

反面例子：”这个地方是不是应该改一下？还是说不用改？我不太确定这样做对不对，要不要再讨论一下？”——这种表达传递的信号是”我没有想法，你来帮我决定”。

正面例子：”这里应该改成X方案，原因是……如果有不同意见我们可以讨论。”——这种表达传递的信号是”我有判断、有依据，同时开放讨论”。

表达观点要果断，给出结论要有依据。你可以有不确定的地方，但要把不确定的范围缩到最小，而不是把整个问题都抛出去。在公共平台上的每一条发言，都在塑造别人对你专业能力的认知。

九、复盘和反思：让每一次经历都变成能力

复盘不是走形式，而是把经验从”经历过”变成”学到了”的关键步骤。不复盘的人，工作十年可能只是把第一年的经验重复了十次。

1. 每个任务完成后：小复盘（5分钟）

任务做完、PR合并之后，花5分钟问自己三个问题：

• 什么做得好？ 这次有没有什么方法或习惯帮了大忙？记住它，下次继续用。
• 什么做得不好？ 有没有走弯路、返工、或者浪费时间的地方？原因是什么？
• 下次遇到类似的任务，我会怎么做？ 如果有更好的方式，更新到自己的SOP里。

2. 每周回顾：中复盘（15分钟）

每周五或者周末，回顾整个星期的工作：

• 这周完成了哪些任务？和预期比，是快了还是慢了？
• 有没有重复犯的错误？如果有，说明流程有漏洞，需要补上。
• 时间花在了什么地方？是P1的核心任务，还是被P2的琐事占据了？
• 这周学到了什么新东西？不管大小，记下来。

可以用一个简单的模板：

本周完成：
- ...
本周遇到的问题：
- ...（原因：...）
下周改进：
- ...

3. 每个项目或迭代结束后：大复盘

项目上线或者一个大的迭代结束后，做一次正式的复盘，最好和团队一起：

• 时间线回顾：从需求到上线，每个阶段花了多少时间？哪个阶段超出预期？为什么？
• 技术决策回顾：当初的技术方案合理吗？有没有更好的选择？踩了哪些坑？
• 协作回顾：和PM、设计、其他团队的沟通顺畅吗？有没有因为信息不对称导致的返工？
• 三个清单：应该继续做什么？应该停止做什么？应该开始做什么？

4. 把复盘结论沉淀下来

复盘最怕的就是”当时想明白了，过两天就忘了”。所以一定要把结论写下来：

• 个人层面：更新自己的SOP、写到笔记或者博客里
• 团队层面：写到团队的wiki或者知识库里，让后来的人少走弯路
• 如果发现了一个好的实践或者一个常见的坑，在团队内部分享一次，教别人是最好的巩固方式

5. 两个人给了相同的建议，一定要重视

如果有两个不同的人在不同的场合给了你相同的反馈或建议，那么这件事大概率是真的，不要再找借口或者觉得是别人的偏见。把这个建议用笔记认真记下来，然后设定一个可观测的改进目标。比如有两个同事都说你”沟通的时候缺少上下文”，那就在笔记里写下来，接下来每次发消息或者开会之前，刻意检查自己有没有提供足够的背景信息。每隔一两周回顾一下，看看自己在这个点上有没有进步。真正的成长往往就藏在这些反复被提起的反馈里——它们是别人帮你发现的盲区。

6. 持续学习

复盘让你从过去学习，但也要保持向外学习的习惯：

• 每周花一些时间读技术文章、看技术演讲、研究新工具
• 不需要很多，但不能停，保持对技术趋势的感知
• 关注的重点不是”什么最新”，而是”什么能解决我当前遇到的问题”

• Previous
  系统设计知识（一）