https://cybersecurityerial.github.io/echo_blog/tags/%E6%97%B6%E9%97%B4%E7%AE%A1%E7%90%86/Recent content in 时间管理 on 我的技术博客Hugozh-cnThu, 07 May 2026 08:34:39 +0800https://cybersecurityerial.github.io/echo_blog/posts/time-management-from-memory-management/Thu, 07 May 2026 08:34:39 +0800https://cybersecurityerial.github.io/echo_blog/posts/time-management-from-memory-management/<p>碎片化时间管理是一个老生常谈的话题。和其他open又普遍存在的问题一样，这种问题的解决办法听人讲经验永远是那么几句，毫无新意。人们于是倾向于自己实操的时候总结自己的策略，做完以后会觉得自己的策略比别人的要高明一点点，但是如果真的拿来对比，发现大家的insight好像都差不多。</p> <p>懂了，原来这就是“造轮子”的冲动。所以今天不从头造轮子，而是给已有的一套体系（虽然也不知道这个体系究竟在哪，就默认大家已经形成了一些共识吧）提几个commit，关注一些重要的点。依旧从第一性原理出发。</p> <p>人脑的上下文切换开销通常被忽视，并且实际上不能忽视。非规整的碎片化时间，带来的问题是人脑不得不进行非规整频率的上下文切换。那怎么办最好？修车的老师傅，总是带着一大包不同尺寸的螺丝。对修车师傅而言，每天要处理k个故障问题，而修理车辆所需的螺丝尺寸同样是一个非规整的请求。这就导向了一个很自然而然的设计：我们只要把不同“尺度”（scale）的任务归类在不同的队列里面，那么针对不同size的时间碎片，只需要alloc不同的任务进去就行了。</p> <p>上面的solutions看起来很make sense，但是还需要解决一个小问题：任务的优先级。任务有先后，有的着急有的不着急。那么在每个scale task queue的内部还需要一个维度对任务的轻重缓急进行排序。也就是说最终决定任务调度行为的meta data至少包含两个维度：{任务优先级level，任务尺度scale}。那么理应需要一个至少二维的矩阵去管理任务。单纯人脑是很难保存这样巨大且复杂的表格的。</p> <p>所以offload到外部存储就好了，这也是非常合理也水到渠成想到的。这也就是任务管理软件的重要性所在。实际上这种软件的本质是在offload memory之上搭建了一个子系统，让我们更方便的读写这部分被offload的任务表单。</p> <p>上述情况似乎尽善尽美了，但还有一个问题：我们如何准确地比较两次上下文切换发生的时间间隔与任务耗费的总时间呢？显然是无法做到精密比对的，只能做量级上的近似。那如果一段空闲时间片内做完了还好，没做完该怎么办。还是从第一性原理出发，突发的上下文切换影响了时间利用的效率。那么具体是怎么影响效率的呢？在实践中笔者发现这部分带来的开销主要是人脑在任务切换时冷启动的时间过长，因此需要一个比较完备的checkpoint/镜像机制记录每次任务的上下文，同时任务执行者还需要有一个从checkpoint/镜像恢复工作进度的好习惯（Harness），二者结合方可实现高效的冷启动。因此笔者觉得，工作期间最需要倾注精力的其实是对工作context的把控。</p> <p>问题解决到这里，基本上已经完成90%了，那么剩下的最后10%问题是什么呢？在笔者的实践与观察中发现，大多数人没有记录context的习惯，因此在将context记录融入到工作流时，难免显著影响效率。那么最关键的问题是如何尽可能低成本的维护context。需要注意的一点是，context的维护难免要消耗更多的精力，因为这里实际上在做的事情是“用工作时的时间轴连续认知资源去置换下次上下文切换时工作冷启动所需要的一次性资源”。no free lunch因此代价无可避免。所做的就是如何降低这种代价。笔者这里提供一点实践思路：</p> <p>对于工作用的agent，要有一个固定的harness使其保存工作的context，乃是“工作留痕”这一职场规则的升级版。哪怕你不喜欢用ai agent帮助自己改善工作流，也最好最少开通一个这样的工具帮助你管理上下文。在每次工作被迫中断时对已经产生的镜像/checkpoint进行review，并且和context tracker ai agent共同创造出一个可以让你下次快速启动工作进程的context文件。如果工作流固化，那么也可以进一步把context创建的流程本身做一个固化。</p> <p>同时，如果你的工作需要和很多人进行协作，最好尽量向他们提供信息，分布式保存工作中所遇到的信息，也就是减少协作体之间的信息差（或者说信息分布的方差）。这个降低方差的操作也适用于多agent协作场景。</p> <p>最后需要尽可能集中信息源之间的联系。这话听起来抽象，其实做起来很简单。信息源乃是工作进度的直接来源，比如说你写了一段代码，并且测试了一部分还没测完，commit了一部分但还没全部commit，那么这个时候信息源就包含很多部分：你已经提交的commit，你还未提交的commit，你已经测试的模块生成的log文件1，log文件2，相关的资料和文档&hellip;&hellip;当你再次开始一段工作的时候，可以把上述这些信息都保存在一个文件，然后工作在冷启动的时候可以把这些页面都一键启动，能瞬间抹平信息差，而不是要重新想自己上次做到哪里，还剩什么没测，log文件重新跑一遍&hellip;不仅浪费时间而且消耗精力。把这些工作所需文件/页面集中到context，就是本段所说的集中信息源之间的联系。</p> <p>顺带一提，写完以后感觉自己的说话方式越来越像AI了，亦或是AI越来越像人了。所以就想起来《BALDR SKY Dive》里面超级AI伊芙的一句台词：我们都在互相学习，渴望与你们相互理解。</p>