谷神不死，是谓玄牝。
玄牝之门，是谓天地根。
绵绵若存，用之不勤。
《道德经》第六章很短，短到只有几句话。
但它讲的东西很深。
老子没有继续讲规则、治理、争夺和系统边界，而是把视角放到了一个更底层的问题上：
一个系统真正持续生长的源头，是什么？
为什么有些程序员工作很多年，依然有好奇心，依然能学新东西，依然能写出有生命力的代码？
为什么有些产品做了很多版本，依然没有变成一堆功能的堆砌，反而越做越清楚？
为什么有些团队经历过业务变化、人员流动、线上事故，依然能恢复、沉淀、继续往前走？
为什么有些领导者看起来不怎么用力，却能让组织持续产出？
这就是第六章要谈的东西。
它不是在讲一种具体方法，而是在讲一种"源头能力"。
一个人、一个产品、一个技术系统、一个团队，如果只靠外部压力推动，很快就会累；如果只靠短期目标刺激，很快就会枯；如果只靠少数英雄硬扛，很快就会断。
真正长期的东西，背后一定有一个源头。
这个源头不一定热闹，不一定显眼，不一定每天被拿出来汇报。
但它像山谷一样，空着，却能不断容纳；像泉眼一样，安静，却能持续生出水来。
这就是"谷神不死"。
先解释原文：谷神不是神仙，而是生生不息的源头
"谷神不死。"
这里的"谷"，可以理解为山谷。
山谷有什么特点？
它低，它空，它不争高处。可是正因为它低，水会流向它；正因为它空，万物能在其中回响、生长、汇聚。
"神"不是迷信意义上的神仙，更像一种看不见但真实存在的生命力、生成力、运行力。
所以"谷神不死"可以理解为：
那个像山谷一样虚静、包容、能不断生成万物的源头，是不会枯竭的。
这和我们平时对"强"的理解很不一样。
我们常以为强是更高、更快、更满、更硬、更有控制力。
但老子说，真正持久的强，反而像谷。
低一点，空一点，柔一点，能接住东西，能让东西生长。
"是谓玄牝。"
"牝"是雌性，这里不是在做性别评价，而是借"母性"和"孕育"来比喻一种生成能力。
它不是向外攻击，而是向内孕育；不是一次性爆发，而是持续生长；不是靠强行推动，而是让东西从源头里自然出来。
"玄牝之门，是谓天地根。"
这个生成之门，就是天地万物的根。
用现代话说，就是：
真正重要的，不只是你已经做出了什么，而是你有没有持续生出新东西的能力。
"绵绵若存，用之不勤。"
它绵绵不断，好像存在，又不张扬；使用它，却不会轻易耗尽。
这句话特别适合今天的技术人。
因为我们太容易把自己、团队和系统用到枯竭。
程序员最怕的不是累，而是源头枯了
程序员的工作很容易累。
需求一个接一个。
Bug 一个接一个。
会议一个接一个。
版本一个接一个。
线上问题一个接一个。
累本身不可怕。
真正可怕的是，你慢慢发现自己不再想理解系统，只想把任务关掉；不再想写好代码，只想让它先跑；不再想学习新东西，只想别再来新东西。
这不是能力问题。
这是源头开始枯了。
一个程序员的长期能力，不只来自技术栈，也来自内在的"谷神"：
- 对问题的好奇心
- 对复杂系统的耐心
- 对代码质量的审美
- 对用户场景的尊重
- 对不确定性的容忍
- 对长期成长的信任
这些东西平时不一定写在简历上，但它们决定一个人能走多久。
很多人刚入行时，技术成长很快。
因为一切都是新的，学一个框架就能解决一类问题，写一个项目就能看到明显进步。
但几年后，真正的分化开始出现。
有人变成了只会交付需求的人。
有人变成了只会抱怨业务的人。
有人变成了只会追新框架的人。
也有人开始理解系统、理解团队、理解产品、理解复杂度。
差别不只是技术能力，而是源头不同。
如果一个程序员的动力只来自外部评价，比如晋升、薪资、头衔、KPI，他当然也能跑很快，但很容易被消耗。
因为外部评价永远不够稳定。
今天被认可，明天可能被忽略。
今年拿高绩效，明年可能换业务。
这个技术火，过两年可能过时。
这个项目重要，过一阵可能被砍。
如果你的源头只接在这些东西上，心就很容易乱。
更稳定的源头，是你真的愿意理解问题，真的愿意把事情做清楚，真的愿意让系统变好。
这不是鸡汤。
这是技术人的长期燃料。
团队的"谷神"：知识、信任和机制
一个团队也有"谷神"。
有些团队看起来很忙，但越忙越弱。
每个版本都赶。
每个问题都救火。
每个项目都靠少数人硬扛。
每次新人进来都要靠口口相传。
每次事故复盘都写得很认真，但下次还是同样的问题。
这种团队看起来一直在动，但源头不稳。
它没有把经验沉淀成机制，没有把问题沉淀成知识，没有把信任沉淀成协作方式。
所以它每次都像第一次遇到问题。
真正有生命力的团队，背后一定有几个源头：
- 知识源头：文档、案例、代码规范、排障经验、业务背景
- 信任源头：能说真话、能暴露问题、能承认不确定性
- 机制源头：复盘、监控、发布、测试、评审、决策流程
- 人才源头：新人能成长，老人能传承，骨干不被耗干
- 目标源头：大家知道什么重要，什么可以放下
这些东西不一定每天都直接产出需求。
但它们决定团队能不能持续产出。
比如文档。
很多人觉得写文档慢。
但一个关键模块如果没有文档，新人每次都要问老人；老人每次都要重复解释；解释多了就烦；新人怕打扰就自己猜；猜错了又返工。
最后省下的文档时间，会变成更多沟通成本。
再比如复盘。
如果复盘只是为了写报告，那确实浪费时间。
但如果复盘能把一次事故转化成监控改进、流程改进、工具改进和认知改进，那它就是团队的源头能力。
因为下一次，团队不再只是靠记性，而是靠系统。
这就是"谷神不死"在团队里的样子：
真正不死的，不是某个人的经验，而是团队持续生成能力的机制。
领导者的任务：保护源头，而不是榨干源头
第六章也很适合讲领导力。
很多领导者误以为自己的任务是推动产出。
当然，产出很重要。
但如果只盯产出，很容易把组织的源头用坏。
为了这个季度目标，把团队排期压满。
为了一个大客户，把核心骨干连续透支。
为了短期增长，把用户信任反复消耗。
为了汇报好看，把真实问题藏起来。
为了快速上线，把工程质量一再让步。
这些做法短期都有收益。
但它们在消耗源头。
领导者真正高级的任务，不只是让团队"这次交付"，而是让团队"交付之后还更有能力"。
这两个结果完全不同。
一个团队如果每做完一个项目，都多一点文档、多一点经验、多一点可复用能力、多一点人才成长、多一点流程改进，那么项目越多，团队越强。
但如果每做完一个项目，都多一点疲惫、多一点技术债、多一点怨气、多一点对人的依赖、多一点不敢说的问题，那么项目越多，团队越虚。
很多组织看起来增长了，其实只是把未来透支到了现在。
领导者要问的不是：
这件事能不能压出来？
而是：
压出来之后，系统会更强，还是更弱？
真正懂领导力的人，会保护几个源头：
- 保护团队的信任，让问题能被及时说出来
- 保护关键人才，不让高手长期处在无休止救火里
- 保护用户信任，不为了短期指标过度打扰和套路用户
- 保护工程质量，不让每次上线都变成新的债务
- 保护组织节奏，不让所有人长期处在紧绷状态
这不是心软。
这是长期经营。
源头被保护住，组织才有绵绵不断的产出。
"用之不勤"：不要过度使用你的核心资产
"用之不勤。"
这里的"勤"，可以理解为穷尽、过度、使其劳竭。
它不是说不用，而是说使用它，但不要把它用到枯竭。
这句话太适合今天的职场。
很多团队最常犯的错误，就是反复使用最可靠的人。
谁靠谱，谁就多接需求。
谁抗压，谁就多救火。
谁好说话，谁就多背锅。
谁能力强，谁就成为所有项目的默认兜底。
短期看，这是最有效率的资源分配。
长期看，这是在损耗组织最宝贵的源头。
一个技术骨干如果长期被当作救火工具，他会越来越没有时间做系统性建设。
一个优秀产品经理如果长期被塞满项目，他会越来越没有时间理解用户和打磨判断。
一个靠谱管理者如果长期被事务淹没，他会越来越没有时间培养人和设计机制。
最后，团队会发现：
最可靠的人越来越累。
最重要的系统越来越依赖少数人。
最需要沉淀的经验一直没时间沉淀。
最值得培养的新人一直没有机会接手。
这就是"不懂用之不勤"的后果。
真正好的管理，不是把能用的人用到极限，而是让能力在组织里再生。
比如：
- 核心模块不要永远只让一个人维护
- 线上排障经验要写成文档和预案
- 关键会议要让新人逐步参与
- 复杂项目要拆出可带教的部分
- 技术债要定期处理，而不是全靠高手救火
- 管理者要识别长期透支，而不是只奖励抗压
一个组织最愚蠢的事，就是把自己的泉眼当水桶用。
水桶可以反复提，泉眼需要保护。
个人成长也要"用之不勤"
第六章不只是讲团队，也讲个人。
很多技术人对自己也很狠。
白天写业务，晚上学新技术。
工作日开会写代码，周末补课程刷文章。
一边焦虑 AI，一边焦虑年龄，一边焦虑薪资，一边焦虑晋升。
努力当然重要。
但如果努力的方式一直是压榨自己，最后很容易从成长变成耗竭。
一个人长期成长，需要节奏。
你不能只输入，不消化。
不能只工作，不复盘。
不能只追热点，不建立自己的知识结构。
不能只解决别人派来的任务，不思考自己真正要积累什么能力。
"用之不勤"不是让你懒。
它是提醒你，不要把自己的注意力、好奇心、创造力和身体状态当成无限资源。
程序员最重要的资产，不只是时间。
还有注意力。
注意力被碎片化，你就很难做深问题。
好奇心被消耗掉，你就很难持续学习。
身体被透支掉，你就很难长期稳定。
判断力被焦虑占满，你就很难做出好选择。
所以个人也要保护自己的"谷神"。
给自己留一点阅读和思考的时间。
给自己留一点真正理解业务的时间。
给自己留一点整理经验的时间。
给自己留一点从噪音里退出来的时间。
长期主义不是每天打鸡血。
长期主义是让自己不要断流。
写在最后
程序员的好奇心、团队的信任、组织的知识传承，都不像项目结果那样醒目，却决定了下一次还能不能创造。领导者真正要保护的，正是这些不容易写进报表的东西。别把泉眼当成水桶反复提取，长期能力才不会在短期成功里枯掉。