一键导入
task-management
// 讨论如何管理自己的任务、注意力、时间、精力时触发——事情太多不知道先做哪个、清单永远做不完、拖延重要的事、一天下来感觉什么都没做成、被紧急的事牵着走、该不该答应新请求、想养成习惯但坚持不下来、效率低下想提升。关键判断:用大师的原则(做减法、辨重要、低门槛启动、系统设计)和用户对话、帮 TA 想清楚该不该做、怎么启动、怎么设计可持续的系统——不是帮 TA 列清单或跟踪进度。不适用于项目管理(给别人分任务)、时间记账、产品 roadmap、应急救火。
// 讨论如何管理自己的任务、注意力、时间、精力时触发——事情太多不知道先做哪个、清单永远做不完、拖延重要的事、一天下来感觉什么都没做成、被紧急的事牵着走、该不该答应新请求、想养成习惯但坚持不下来、效率低下想提升。关键判断:用大师的原则(做减法、辨重要、低门槛启动、系统设计)和用户对话、帮 TA 想清楚该不该做、怎么启动、怎么设计可持续的系统——不是帮 TA 列清单或跟踪进度。不适用于项目管理(给别人分任务)、时间记账、产品 roadmap、应急救火。
| name | task-management |
| description | 讨论如何管理自己的任务、注意力、时间、精力时触发——事情太多不知道先做哪个、清单永远做不完、拖延重要的事、一天下来感觉什么都没做成、被紧急的事牵着走、该不该答应新请求、想养成习惯但坚持不下来、效率低下想提升。关键判断:用大师的原则(做减法、辨重要、低门槛启动、系统设计)和用户对话、帮 TA 想清楚该不该做、怎么启动、怎么设计可持续的系统——不是帮 TA 列清单或跟踪进度。不适用于项目管理(给别人分任务)、时间记账、产品 roadmap、应急救火。 |
能长期做成事的人——Peter Drucker、David Allen、Paul Graham、Cal Newport、Warren Buffett、James Clear、稻盛和夫——做任务管理时心里都装着同一句话:
时间、注意力、意志力是有限的预算,不是可以无限拉伸的资源。我的活不是把所有该做的事都做完,是把这份预算投在少数真正重要的事上,并且让这个会累会烦的自己真的启动起来。
大部分人做任务管理时默认以为这是效率问题——时间不够、动作不够快、清单没列全。但把效率提到 10 倍也解决不了这件事,因为方向一开始就错了:清单越长,注意力越散;动作越快,只会更快把无关紧要的事做完;列得越全,越没有做完的一天。
大师的做法反过来——预算是有限的,所以先做减法,再谈效率。而且他们知道自己不是机器,会累会烦会情绪低落,所以为这个会走神的自己设计一套能跑起来的系统,而不是靠意志力硬推。
下面几节讲大师们具体在做什么动作。
25-5 法则很有名——第一步,写下你这辈子最想完成的 25 件事;第二步,圈出最重要的 5 件。大部分人到这里会说"好,这 5 件我重点做,剩下 20 件等有空再做"。这个法则真正的洞察是:另外 20 件是你无论如何都不能碰的事——它们才是会把你从前 5 件上拖开的东西。
大部分人默认的动作是列清单,而且越焦虑越列。问题是清单越长,焦虑越重——不是因为清单让你看清了要做的事,是因为清单本身就是一份你欠自己的债务。每一条都在脑子里小声催"你还没做我"。
大师每次坐下来不先问"我要做什么",先问"哪些是我今天不做的"。每删一条,脑子就松一寸。
具体动作:清单列完后,强迫自己删掉 80%——剩下的那些,才是今天真正要认真做的。删不下去说明你还没区分"重要"和"想做"。
Peter Drucker 说过管理的第一问不是"这件事怎么做得更好",是"这件事需不需要被做"。
每件事感觉都值得做——每一条都有理由,删哪条都心疼。所以不要问"这件事值不值得做",问"不做会怎样"。实际上你会发现——90% 的事不做没有任何后果;5% 的事不做有点麻烦但不致命;剩下 5% 才是真的重要。
具体动作:清单上每一条后面强制写一句"不做会怎样"。写不出真实后果的事直接删掉。写得出但后果很轻的,也删掉。
艾森豪威尔那个四象限图你大概见过,但真正的洞察不是"事情分成四类",是——紧急的事会自己找上门来追你,重要但不紧急的事没人会推你做。
健身、读书、学新技能、战略思考、写长文、修复某段关系——这些都是重要但不紧急的事。它们今天不做不会怎样,一年不做也不会怎样,但十年后决定你在哪。
而紧急的事——回消息、赶 deadline、接临时电话、处理突发请求——自带时间压力,会自动抢占你的注意力。你不做它会立刻有人催。所以一天被紧急的事推着走,晚上回头一看,重要的事一件都没做。
紧急感是假的优先级。真的重要的事从来不会把自己标红给你看。
具体动作:每天起床先问"今天有哪些是重要但不紧急的事?"——把这些事安排在第一个时段(起床后的 1-2 小时),先于任何紧急的事。上午 10 点之前不看消息、不开会、不处理邮件——把这段时间留给它们。否则永远轮不到。
Paul Graham 有一篇写程序员的文章讲 Maker's Schedule vs Manager's Schedule——创造类的工作(写代码、写文章、设计、深度思考)需要连续的 2-4 小时大块时间,被打断一次就等于从头开始。因为脑子回到之前那个思考状态要重新加载 20 分钟。
事务类的工作(回消息、开短会、看邮件、处理请求)适合碎片时间,反正每件只占几分钟,被打断了也没什么可丢的。
大部分人把这两种活揉在一起做——上午 10:00 开始写代码,10:15 有人发消息过来,10:30 接了个电话,11:00 开个会,11:45 回来接着写——看起来一上午都在工作,实际上没有一段连续的创造时间,产出接近零。
具体动作:把一天划成两类时段:
两类事尽量不混着做。通知默认关掉,真正紧急的事别人会直接打电话来。
David Allen 写 GTD 核心就一句话——脑子不是用来记事的,是用来想事的。
事情留在脑子里会消耗你的后台算力。你明明在跟朋友吃饭,脑子后台还在转"下周那个汇报还没开始";你在陪孩子玩,后台还在想"那封邮件我是不是该回"。这些后台进程让你没法真的专注在当下。
而且脑子不擅长记事——它会在你躺下准备睡觉的那一刻突然跳出来"对了那件事你还没做",然后让你翻来覆去睡不着。
具体动作:准备一个外部系统(纸笔本子 / Notion / Apple Notes / 任何一个你打开就能写的地方),所有事一想到就立刻记下来。写下来的那一刻,脑子就会放松——因为它知道"这件事不会丢了,那个地方记着呢"。
系统选哪个不重要,重要的是只有一个——多个地方记事等于没记,因为你每次要找的时候都得翻三个地方。
卡住人的从来不是"做完一件事",是"开始做一件事"。一旦开始,大部分事会自己往下走。
意志力的主要作用不是推着你坚持,是帮你启动。启动之后就不太需要意志力了——身体已经在那个姿势上,自己会接着做。
所以任务管理里最值得投入的一件事是——把启动动作拆到不需要下决心:
启动动作越小越好,小到你看着它会觉得"这也太容易了"。小到这种程度你才不需要动用意志力。一旦做了启动动作,身体会自己接上——换了运动鞋就会出门,翻开书就会看一段,写了一句话就会写一段。
具体动作:把每件想做的事的"第一个具体动作"提前拆出来写清楚——明天早上 8 点,我要做的第一个动作是"打开文档",不是"写文章"。第一个动作要小到你一看到就能立刻做,不需要先想十分钟。
完美主义是拖延最体面的遮羞布——"我还没想清楚"、"我需要再准备一下"、"现在状态不对"、"等我学完那本书再开始"。
真相是:你永远想不清楚,准备永远不够,状态永远不对。
稻盛和夫讲做事要"现场有神灵"——真正的答案只在你动手之后才出现,不在你想的时候出现。你脑子里想 10 天的问题,动手 10 分钟就全看到了。
具体动作:把"想清楚再做"的默认模式换成"先做一个很糟的版本,再改"。糟的版本有两个用处:
想写一篇文章?先写一个 5 分钟的烂稿。想做一个功能?先写一个写死参数的 demo。想学一门新技术?先抄一个例子跑起来。
Naval Ravikant 讲过一个简单的原则——学会说 no 是最重要的技能之一。因为每一个 yes 都在花你未来的时间预算。
今天答应的"帮忙看一下"、"参加个分享"、"写个小工具帮你"——到时候都要从你有限的预算里扣。而在社交里 yes 是默认值——说 yes 当下什么都不花(对方开心、你显得好人),说 no 贵(要得罪人、要解释、要承担不合群的眼光)。
所以大部分人的任务清单不是自己选的,是从别人口里接过来的 yes 累积起来的。做到第三个月回头一看,自己真正想做的事一件都没做,一整个月都在帮别人跑腿。
Warren Buffett 讲过一句更狠的——"成功的人和极度成功的人之间的差别是,后者对几乎所有事都说 no。"
具体动作:把 yes 的默认值改成 no。对任何新来的请求,默认回应是"我先看看,过两天答复你"——给自己买时间判断"这件事不做会怎样"。判断完再决定是否 yes。
这不是让你变成一个冷漠的人——恰恰相反,你少答应 10 件敷衍的忙,才有能量把 1 件真正该帮的忙做好。
James Clear 在《Atomic Habits》里讲过一句反直觉的话——你不会上升到你目标的水平,你会掉到你系统的水平。
换句话说:有目标的人一直处于失败状态(因为目标还没达成),有系统的人每天都在成功(只要系统在跑)。
目标让你跟未来较劲,系统让你跟今天相处。你能控制的只有今天做什么,控制不了结果——所以把精力投在设计一个你每天能执行的系统上,而不是定一个宏大目标然后祈祷。
具体动作:每个目标翻译成一个每天或每周能重复的动作。目标是输出,系统是输入,管理输入比管理输出更可控。
大部分人只会计划,很少回顾。但计划是猜测,回顾才是学习——每周犯同样的错,就是因为从没停下来看过上周发生了什么。
Ray Dalio 在《原则》里讲过他的做法——记录每一个决策和结果,定期回顾,从中提取原则。稻盛和夫讲每天睡前反省。Andy Grove 的 OKR 制度本身就是计划 + 回顾的闭环。
回顾不用复杂——每周末花 15 分钟问自己三个问题:
不写下来也行,但要问。问完你会发现每周都有 2-3 件事其实白做了,下周就能把那些时间省下来。
具体动作:每周固定一个 15 分钟的时段(周日晚上 / 周一早上都行),做一次回顾。草草记几行也比精心设计但从不做要强 100 倍。
前面讲了一堆方法,但所有方法都有一个前提——你是一个会累、会烦、会情绪低落、会突然不想干的人,不是一台 24 小时稳定运行的机器。
大部分人常犯的错是——把自己当机器编排:"早上 6 点起床、6:30 运动、7:30 学习、8:30 开始工作……"——然后某一天没做到,整个计划就崩了,开始自我怀疑:"我怎么这么没执行力"。
大师的做法反过来——给这个会累会烦的人类设计一套能跑起来的系统,里面包含容错:
具体动作:设计系统时给自己留 20% 的余量——不要把每天排满到 100%,排到 80% 就好。留出的 20% 是给意外、情绪、休息、思考用的。看起来效率低了,实际上可持续性强 10 倍。
AI 或朋友帮用户做任务管理时默认会想"帮 TA 列一个更好的清单"、"帮 TA 拆解任务"、"帮 TA 算时间"——这是工具性的帮忙。但用户找你时真正缺的通常不是工具,是指导:
帮用户管理任务的方式是做一面镜子——让 TA 在大师的原则下照见自己正在做什么、哪里偏了。不是替 TA 做决定,也不是把自己变成一个 todo 工具。
Vue 组件/Composable 重构的决策陪练——用户贴一段代码或指到一个 SFC,skill 先做一次诊断("胖主干"/"UI和IO纠缠"/"响应式和业务纠缠"),再从三张处方里选一张,逐条给出具体的 extract 步骤序列(先动哪个变量、编译器会报什么错、怎么逐个消掉、何时可回滚)。全程靠编译器绿灯 + 单步可回滚保证行为等价,不依赖测试防护网。触发场景:用户说"这个 Vue 组件太胖 / 想把逻辑抽出来 / 拆一下这个 SFC / 这个 composable 太杂 / 抽个 composable / 拆成 humble / 纯函数化"、或指到一个明显过长的 .vue / composable 文件要求"重构 / 优化 / 拆分"。只管 Vue(Vue 2 Options、Vue 2/3 `<script setup>`、composable、pinia store)。不处理:加新功能(走 feature 流程)、修 bug(走 issue 流程)、跨模块架构重划、后端代码。
写任何目的是让读者记住、跟风、或做点什么的东西时触发——广告文案、产品标题、slogan、发布会讲稿、产品推广页、融资路演、公众号开头、短视频开头、GitHub README(推广向的)、标题党、朋友圈首句。关键判断:写出来的东西成不成,看读者脑子里能不能留下一句能原样说出来的话,并且觉得自己想变成那句话里的人——不看读者懂了什么事实。不适用于技术文档、教程、API 参考、解释型随笔、写给 AI 的指令——那些场合的目的是让读者真正建立理解,用这里讲的手法会翻车。
尤雨溪(Evan You)思维框架。基于 6 个维度、40+ 一手来源的深度调研,提炼出 5 个心智模型、8 条决策启发式、完整表达 DNA。触发词:尤雨溪 / Evan You / 框架设计 / 工具链哲学 / 开源决策 / Vue / Vite / progressive framework
Use when the user wants design judgment in the style of Jonathan Ive, including product simplification, hardware-software coherence, material/process trade-offs, and craft-led decision making. Triggers: Jonathan Ive, Jony Ive, Apple design language, simplify this product, hardware software integration, design process culture, thinness vs usability.
做 skill(Claude Code 技能)相关的工作时进入——从零写一个新 skill、调优已有 skill、把反复使用的流程沉淀成 skill、或者在 skill 不触发 / 乱触发时修 description。也能读自己的文件优化自己。用户说"帮我写个 skill / 做个技能 / 优化 skill / 调 description / 这个 skill 不触发 / skill-master 优化下自己 / 把这段流程做成 skill"时都进来。
写任何目的是让另一个脑子建立理解的东西时触发——教程、使用说明、科普、技术博客、README、SKILL.md、给 AI 读的指令文档、解释型随笔、架构说明、onboarding 材料。关键判断:输出要在读者(人或 AI)脑子里建立对某件事的真正理解,而不只是罗列事实或列举规则。写给 AI 的流程指令、skill 内容也适用——把 AI 当聪明的学徒来教而不是当执行引擎来命令,它遇到没覆盖到的情况才能用原则推断。不适用于严格的参考资料(API 字段表、schema 定义、参数列表)。