知识管理的Git化与工作流重构哲学
作者:ERROZER | 发布时间: | 更新时间:
引言
现在各行各业都受到AI的冲击,但是社会评价体系总是要滞后于社会生产力的变化的,现在学习除了满足自己的精神需求外,最大的意义就是能托举你到下一个平台。首先纯“数据库性”的知识伴身意义已经没有之前那么大了,让大脑作为存储介质而言专用小参数模型都够呛能干得过。其次当前社会评价体系的本质还是一种“静态资产评估”,还在用高考、证书、工龄来估算你的知识储量。所以当前形势下,功利性学习(注意一定是功利性的)应该注重的是借助所有手头的工具去完成项目或者目标的 workflow,大脑的记忆应该主要起缓存的作用,所谓的 Git 化就是要借助各种工具,先计划最小达成目标所需的只是框架(一个 MVP),然后再不断 commit 去完善和迭代。完成之后这个流程不仅是可被他人参照的,也是能让自己在下一个 project 中优化流程中很有用的一步。
之前 CBL 和 PBL 流行过一段时间,其实这个是很适合现在的学习流程的,之前是为了去做什么事情去学习某套知识体系,现在我觉得更合适的应该是对某个高度的目标的追求通过从零或者基于已有的只是框架去「填充」步骤。
思路
怎么去把这个哲学应用到实际中去呢?
重新定义“知识MVP”
按照传统学习的方式,我们会把学会当成重点,但我们应该把可运行的最小闭环当作 MVP,这个 MVP 不仅是“掌握前三章”这种东西,而是产出一个虽然粗糙但是相对完整的项目结果。
怎么构建:拿到目标后,第一步不是看书,而是反向拆解执行路径。去问自己如果只有一定量的时间,我要输出什么?这个项目才算跑通?
大脑在这里的角色:大脑在这个阶段只负责路径桂花和关键节点的逻辑校验,不负责存储细节。所有的语法、公式、案例全都扔给外挂的工具(大模型等等)
Commit必须遵循原子化的原则
Git 的核心价值就在于可回滚或者说是可追溯的。每一次的commit不应该是“我学了一个小时”这种东西,而是应该是我修复了某个具体的报错或者新增了某个功能模块。
Commit 的规范:不要写“学习 python”,应该写“增加了断点续传/数据清洗新的逻辑”。这种记录方式在结合当前的信息化笔记系统是可以直接服务于未来的工作流的优化的,下次做类似的项目,直接就能调取当时发现的坑和解法。
大脑的缓存作用:大脑着重思考的应该该是 diff,一旦 commit 完成并推送多高代码库或者笔记,就暂时清空缓存,把自己脑子那点算力交给下一个阻塞点
引入分支branch策略去应对评价体系
主分支main应该是严格应对社会评价体系的,只合并已经完成并经过验证的项目成果(拿得出手的作品集、论文、产品)
Feature 则用于探索,在完成 main 的过程中总有自己的奇思妙想,如果有想探索的就单列一个分支出来。
从问题导向转向依赖导向
我们所有要做的东西不要是为了学而做,而是消除所有目标路径点上的阻塞点而做
把最终目标当成一个依赖树。不需要从头构建树根,而是检测到当前报错提示丢了哪个依赖包(缺哪块知识),就精准install
凡是和当前目标路径无关、且不会阻塞下一步执行的知识,即使再经典,也暂不纳入本次的冲刺。在大模型时代,这类知识是可以随时调取的,不必预加载。
总结
我个人认为随着时代发展,个人评价体系一定会发生变化,个人简历很有可能不再是“掌握多少知识或者有多少证书”,而是公开提交的日志,我认为在当前时代,个人最大的护城河已经不再是知识量,而是定义MVP 边界的直觉和合并冲突的应变力。