最近很火的OpenClaw依赖的Pi框架的作者Mario Zechner写了一篇Thoughts on slowing the fuck down ，结合我最近这个月的工作体验，深以为然。上篇提到我一个月前转组之后有了时间探索将LLM应用在工作中，又两周过去了，我又有了新的感悟（废话）想说，也算是对这篇的一个reaction。
就产出而言，我这个月做的事情如果没有LLM，从工作的角度来讲会更好，因为我已经足够熟悉且手速快，但是因为Claude老师的参与，我从根本上改变了自己的工作习惯，比如我几乎没有再手搓SQL，也没有怎么手动操作难用的内部数据平台，这两天甚至搞定了一部分采购的看板平台的操作，这么继续下去，我工作中动手的部分真的就快都消灭了，而这在一个月前还仅仅存在于我给自己画的饼里。“工欲善其事必先利其器”和“慢一点比较快”两句话在我人生里第一次真真切切的具像化了。因为给自己糊出来了好用的工具，工作体验提升到连本冤种打工人也觉得舒适的程度，前期的花的这些时间和精力也将助力我之后丝滑产出。虽然离大规模应用还远得很，甚至我都没想好怎么给亲老板描述这个事，但是hey，在改变世界之前，我先改变了自己。进一步说，对于管理者而言，牺牲短期产出来获得长期变革，在这个年代是一种很重要但又很稀缺的技能，我的亲老板未必有这个觉悟（毕竟他是一个憨憨），但对我而言已经实质上有这个效果，I will be forever grateful。
对于数据工程而言，一个意外的发现是，除了降低数据平台的使用门槛以外，似乎还出碰到一个更深层的问题：资源调度削峰填谷。因为内部平台限制，最近回刷数据都是让Claude Code以一周为单位提交任务，结束一天就再提交一天，因为它可以自己一直跑，我就不用像之前一样，一次性提交平台允许的最大数量，然后等待完成。如果换成平台的视角，如果所有的任务都是少量且稳定的进入队列，是不是就可以降低对调度这件事情的依赖？或者说，调度这件事被前置和分散了，从对所提交任务的操作，转换成了任务提交这一步的控制。可惜我过往的经验并不涉及数据平台，无法判断这个变化会造成多大的影响。
但拓展开来，这种变化会不会可以拓展到所有调度系统，特别是有人参与的那种，比如人员排班、工单分配？削峰填谷其实一直是个老大难问题，解决不好会直接带崩上下游，上述的调度前置这种做法，是否可以带来更大的想象空间？To be continued..