在公司呆了好多年，你可能也经历过这样的时刻：又一个项目上线了，代码review了，bug修了，又开始下一个项目。日子一年一年过，你写了几十个项目，参加了无数次会议，修复了成千上万个bug。但有一天你停下来想，为什么感觉自己没在进步？为什么每个项目都像在重复昨天的工作？
这不是你变懒了，而是你发现了一个很多人都会遇到的问题：你在被一个不属于你的工作流所驱动。
那个工作流是什么？是公司的项目管理制度、是sprint的节奏、是code review的流程、是上线前的那一套检查清单。这些东西本身没有问题，问题是，当你完全被动地跟随这个流程时，你没有机会去思考和优化属于自己的东西。
直到某一天，你发现了一个更深层的真相：最优秀的工程师不是那些最努力完成任务的人，而是那些设计了自己工作流的人。他们的流程让他们能更快地学习，更准确地决策，更少地犯重复错误。而你现在意识到，你需要为自己设计一套工作流。
为什么需要自己的工作流
让我换个角度来解释这个问题。如果你把工程师的工作看作是一个系统，这个系统的输入是需求和信息，输出是高质量的代码和解决方案，那么中间那个黑盒就是你的工作流。
公司给你的工作流是通用的、平衡的、低风险的。它能保证一个普通员工不会犯太大的错误，但它也保证了你的天花板。而当你为自己设计工作流时，你可以根据自己的优势来优化。你可能特别擅长快速阅读代码，那就设计流程让你更多地掌握全局；你可能特别讨厌重复工作，那就把自动化作为工作流的核心。
更重要的是，自己的工作流是可以进化的。公司的工作流变化很慢，需要无数次的论证和试点。但你的工作流可以每个月、甚至每个礼拜迭代一次。这种快速反馈就是为什么优秀工程师进步那么快------他们不只是在做项目，他们在不断地优化做项目的方式。
工作流的三个层次
现在我们要回答一个实际的问题：怎样才能设计一个属于自己的工作流？
来看看Claude Code这样的顶级系统是怎样设计的。它们采用了一个分层的思路，把整个系统分成三个层次来优化。你也可以用同样的思路来设计自己的工作流。
第一层：你说什么（Prompt）
这是关于你如何清晰地表达意图。当你开始一个工作任务时，你对问题的理解清晰度，直接影响了后面所有工作的质量。很多人的问题不在于执行力弱，而在于一开始就理解错了问题。
根据Prompt框架，清晰的表达需要遵循两个核心原则。第一是明确和具体，不是说"优化一下这个页面"，而是"这个页面的首屏加载时间需要从3秒降到1秒，使用什么工具测量，成功的标准是什么"。第二是给自己充足的思考时间，不要急着开始敲代码，先把整个问题的各个维度想清楚。
你可以为自己建立一个简单的习惯：每个任务开始时，写下五句话：这是什么问题，为什么要解决它，怎样才算解决好了，有哪些约束条件，我已经知道哪些信息。这五句话本身就是一个自我清晰化的过程。
第二层：你看什么（Context）
即使你一开始理解得很清楚，如果你在解决问题的过程中掌握的信息不对，也会走偏。这就是Context Engineering讲的东西。
想象你在修一个复杂的bug。现在的问题是，你的大脑每时每刻都在处理有限的信息。当你在代码、日志、ticket和Slack之间来回切换时，你实际上在浪费认知资源。顶级的系统会非常智能地为你筛选、压缩、优化信息，只把你最需要的放在眼前。
你可以对自己做同样的事。当你处理一个项目时，建立一个项目笔记，把核心信息都记在那里。不是把整个文档都拷过来，而是用你自己的话总结关键点。架构是什么，关键文件在哪，常见的bug模式，之前的失败教训。这样当你再次需要这些信息时，不用再从零开始挖掘。
进一步，你可以根据自己的工作状态来动态调整信息。比如在深度debug的时候，你只需要代码和日志，其他的信息都是噪音。当你在设计阶段，你需要更多的背景和历史信息。为自己建立这样的上下文切换机制，可以显著降低你的认知负荷。
第三层：你被允许做什么（Harness）
这一层听起来像是限制，但其实是保护。Harness Engineering的核心思想是，通过明确的边界和约束，反而能让你更自由地工作。
具体是什么意思呢？当你知道哪些事情不能做（比如不能绕过code review，不能在生产环境直接修改），你就不用在脑子里维护"我该不该这样做"的疑问。你的精力就能完全用来解决问题。
对自己的工作流也是一样。给自己建立一套规则。比如，我写代码之前一定要写单元测试；我提交任何代码改动之前一定要自己走一遍测试场景；我的任何架构设计都要能用一张图表清楚地说明。这些看起来是约束，但实际上它们是你对自己的承诺。它们保证了你的代码质量，也保证了你不会因为赶时间而做蠢事。
更高级的是，当这些规则变成你的习惯时，你不再需要有意识地去遵守它们。它们就像你的第二本能。你会发现，比起完全自由但容易出错，受到明确约束反而让你的工作更顺畅、更快。
从三层到循环
现在你有了三层的优化框架。但还有一个更高层的东西，那就是Loop Engineering讲的------怎样让你的工作流自动运行。
这个听起来有点深奥，但其实很简单。想象你现在每做完一个功能，都要经过一个固定的流程：自测、写文档、代码review、上线前检查、上线、线上监控。如果这个流程每次都要你手动做一遍，你就在浪费时间重复同样的操作。
顶级的团队会把这个流程自动化。通过CI/CD，很多检查自动运行。通过自动化测试，你不用手动测那么多场景。通过清单制系统，关键步骤不会被遗漏。
你可以对自己做同样的事。建立一套个人的工作流自动化。你可以用什么工具呢？
如果你用Claude Code或类似的AI编码工具，你可以设置定期的任务------比如每周的项目总结、每个月的回顾分析，由系统帮你自动生成初稿。你可以建立自动化的脚本来生成报告、整理知识库、提醒你该复习什么。关键是，你把那些重复性的工作流程化，然后让工具来执行。
更进一步，你可以建立一个个人的知识库系统，像你现在用Obsidian一样。每个项目完成后，自动把关键的代码片段、架构决策、lessons learned存储进去。下次碰到类似问题，你就不用从零思考。这本质上就是在建立一个持续进化的工作流。
实战：从今天开始
这些想法听起来都很美好，但怎样真的开始呢？
第一步很简单：选一个你最常做的重复工作。不要试图一次性优化你所有的工作，那太累了。选一个最容易优化、收益也最高的地方开始。
比如你可能每周都要花一两小时整理bug list和优先级。或者你经常要从多个地方copy代码来实现类似的功能。或者每次接新项目，你都要花半天时间理解架构。选择其中之一。
第二步：记录这个流程的每一步。不是大脑里面的流程，而是真的写下来。你是怎样开始的，中间有哪些决策点，最后怎样完成的。这个过程本身就会让你看到很多改进的机会。有的步骤其实不必要，有的步骤可以并行做，有的步骤可以工具化。
第三步：识别三个优化机会。在Prompt、Context、Harness这三个层面，各选一个可以改进的地方。可能是，你的起始理解不够清晰（Prompt层），你工作时查资料太低效（Context层），你的工作流程没有清晰的标准（Harness层）。
第四步：做一个小的优化实验。不要等到一切都计划好了才开始。选其中最简单的一个改进，这周就试试。比如为自己的工作建一个简单的checklist；或者为常见的代码模式建一个snippet库；或者试试每次工作开始时先写下三个要点。
关键是这个实验要很小，但要有明确的反馈。这周用了新的checklist，我是不是犯的错更少了？用了snippet库，我写代码是不是更快了？记录这个反馈，然后迭代。
为什么这样设计有效
也许你会问，这和普通的效率优化有什么区别？为什么要这么复杂地分成三层？
原因是，当你把工作流分解成这几个层次时，你就能系统性地思考。大多数人的效率问题根本上是这三层中的某一层出了问题。有的人是因为一开始理解不清，导致做了一堆无用功。有的人是因为信息管理混乱，在各种工具之间浪费时间。有的人是因为没有明确的标准，每次都要重新决策。
我们能看到一个有趣的现象：那些优秀的系统之所以能保证高质量，不是靠什么神奇的算法，而是靠明确的约束和清晰的标准。在你自己的工作流中也是一样。你的进步不会来自于"更努力"，而来自于"更聪明地约束自己"。
长期的收益
当你坚持优化自己的工作流半年、一年之后，你会发现一些很有趣的变化。
首先，你处理新问题的速度会变快。因为你有了一套系统化的思考框架，无论什么问题来了，你都能快速套用Prompt-Context-Harness的三层模式来分析。你不再是凭经验，而是凭方法。
其次，你犯的错会变少。因为你的harness层建立了防线。即使偶尔有不清晰的理解或者遗漏的信息，你的checklist和规范会catch住大部分问题。
再次，你会变得可复制。这很重要。你的工作流不再只是存在你的脑子里，而是变成了文档、工具、脚本。这意味着如果需要的话，其他人可以快速学到你的方法。在团队中，这让你的价值放大了好多倍。
最后，也是最重要的，你变成了一个自进化的系统。你不只是在做工作，你在同时优化做工作的方式。每个项目都是一个反馈循环。上一个项目暴露的问题，变成了下个项目优化的目标。一年两年下来，你的工作流已经和两年前完全不一样了，但你的进步是连续的、有记录的、可量化的。
这就是为什么我说自己设计工作流这么重要。它不是一个一次性的项目，而是一个持续的、指数级增长的过程。
最后的话
你可能还会问，我真的有时间来优化工作流吗？我的项目已经堆得很满了。
答案是，优化工作流本身就会给你省出时间。一个好的工作流不是额外的负担，而是在你现有的工作中嵌入优化。比如，给项目写一个清晰的README，这是工作的一部分，但同时也在建立你的Context layer。给自己写一个checklist，这花不了多长时间，但能防止你后续的很多重复工作。
关键是转变思维。从"我在做项目"变成"我在同时做项目和优化做项目的方式"。这个思维转变本身，可能就是那些在公司呆了多年却仍在进步的人，和那些在原地踏步的人之间最大的区别。
你在公司呆了很久，写了很多项目。这不是你停滞的原因，而是你优化工作流的最好起点。因为你已经有了足够的项目经验来识别哪里需要改进。而从今天开始，给自己设计工作流，就是在为你的下一个十年做准备。