掘金专栏可能会更新不及时，欢迎大家移步道德经：程序之路
不尚贤，使民不争；不贵难得之货，使民不为盗；不见可欲，使民心不乱。是以圣人之治，虚其心，实其腹；弱其志，强其骨。
常使民无知无欲。使夫知者不敢为也。
为无为，则无不治。
《道德经》第三章，是非常容易被误解的一章。
有人一看到"不尚贤"，就以为老子反对人才；看到"无知无欲"，就以为这是在讲愚民；看到"弱其志"，就觉得这是不是在压制人的上进心。
如果只按字面读，这一章确实很刺耳。
但放到今天的技术团队、产品团队和组织管理里看，它真正关心的不是"要不要人才"，而是一个更现实的问题：
你把什么东西放到台面上奖励，大家就会围绕什么东西竞争；你把什么东西包装成稀缺资源，组织就会围绕它产生争夺；你不断刺激人的欲望，团队的心就很难安定下来。
这句话对程序员和产品经理都很重要。
因为我们每天做的事，本质上都在设计系统。
写代码，是设计软件系统。
做产品，是设计用户行为系统。
做管理，是设计团队协作系统。
系统一旦设计出来，人的行为就会被它塑造。
你奖励什么，大家就追什么。
你展示什么，大家就比较什么。
你稀缺什么，大家就争什么。
你反复强调什么，大家就焦虑什么。
第三章讲的，就是这个。
一、不尚贤，不是不尊重优秀的人
"不尚贤，使民不争。"
这句话最容易被误读。
老子不是说不要贤能的人，也不是说优秀的人不重要。
一个团队当然需要优秀的人。没有强工程师，复杂系统撑不住；没有好产品经理，需求会变成一堆功能堆砌；没有靠谱的负责人，项目很容易在混乱里消耗掉。
问题不在"贤"，而在"尚"。
"尚"，是把某种人、某种能力、某种标签高高举起来，让所有人都围绕它崇拜、攀比、争夺。
比如一个团队里，如果天天强调"谁是技术大牛""谁是核心人才""谁是明星员工"，短期看好像是在激励大家变强，长期看却可能制造出几种副作用：
- 普通成员觉得自己不重要，只等大牛拍板
- 技术骨干习惯被依赖，不愿意沉淀知识
- 大家开始争抢曝光度，而不是解决真实问题
- 难而脏的活没人愿意做，因为"不够亮眼"
- 团队评价从"事情是否做好"，变成"谁看起来更厉害"
这就是"不尚贤，使民不争"的现代含义。
不是不要优秀，而是不要把优秀做成一套让所有人互相争夺的身份系统。
真正健康的团队，应该尊重能力，但不要崇拜人设；应该看见贡献，但不要制造神坛；应该培养高手，但不要让团队依赖英雄。
二、技术团队最怕的，不是没有高手，而是只有高手能干活
很多技术团队都有一个熟悉的场景：
线上出问题了，大家第一反应不是看监控、查文档、走预案，而是问：
某某在不在？
核心模块要改，大家第一反应不是看设计文档，而是问：
这个以前是谁写的？
新需求要评估，大家第一反应不是拆链路，而是问：
这块是不是得让某某来？
这当然说明某个人能力强。
但从系统角度看，这也说明团队有风险。
如果一个系统只有某个人能维护，它就不是一个真正健康的系统。
如果一个问题只有某个人能解释，它就不是团队知识，而是个人记忆。
如果一个项目只有某个人能推动，它就不是组织能力，而是个人能力在硬扛。
短期依赖高手，效率很高。长期依赖高手，组织会变脆。
这就像代码里有一个超级大的工具类，什么都能干，哪里都调用它。刚开始很方便，后来所有逻辑都绕不开它，任何改动都怕影响全局。
团队里的"超级英雄"也是一样。
一个真正成熟的技术负责人，不是让所有人都离不开自己，而是逐渐让更多事情不再依赖自己。
他会把经验写成文档，把排障路径变成 SOP，把核心模块拆出边界，把新人带到关键项目里，把隐性知识变成团队资产。
这才是"不尚贤"的工程版本：
不要把能力供在一个人身上，而要把能力沉到系统里。
三、"不贵难得之货"：越稀缺的东西，越容易引发争夺
"不贵难得之货，使民不为盗。"
这句话也不是说珍贵的东西没有价值。
它说的是：当一个社会把某些稀缺物品看得过重，人就容易围绕这些东西产生争夺，甚至不择手段。
放在公司里，"难得之货"不一定是珠宝黄金，它可能是：
- 核心项目
- 晋升名额
- 绩效等级
- 年终奖包
- 老板关注
- 关键客户
- 资源预算
- 技术话语权
- 对外分享机会
这些东西都很现实，也都很重要。
问题是，如果组织把它们包装得过于稀缺、神秘、刺激，团队行为就会发生变化。
大家会开始问：
哪个项目更容易出成绩？
哪个需求老板更关注？
哪个坑位更容易晋升？
哪个指标最容易被看见？
哪件事虽然重要，但不值得我做？
于是，真正有价值但不显眼的事情，没人愿意碰。
比如：
- 补文档
- 清理历史债务
- 优化报警噪音
- 改善测试稳定性
- 梳理权限模型
- 修复边缘场景
- 帮新人熟悉系统
- 维护内部工具
这些事很重要，但不一定"难得"，也不一定容易被包装成亮点。
如果团队只贵"难得之货"，大家就会追逐稀缺标签，而不是建设真实能力。
所以管理者要特别小心：
当你把某种资源设计得越稀缺，它就越容易从激励变成争夺。
四、产品经理也要懂：稀缺感不是万能药
"不贵难得之货"放到产品里，也非常直接。
很多产品喜欢制造稀缺感：
- 限时抢购
- 限量名额
- 内测资格
- 稀有徽章
- 排名榜单
- 会员专属
- 连续打卡奖励
- 错过就没有
这些玩法有没有用？当然有。
它们能提高转化，能刺激行动，能制造传播，能让用户更快做决策。
但如果一个产品长期依赖稀缺和焦虑驱动，用户心智会慢慢变化。
用户不再因为产品本身有价值而留下，而是因为害怕错过。
用户不再自然使用，而是被提醒、倒计时、红点和排名推着走。
用户不再信任产品，而是开始怀疑自己是不是又被套路了。
短期增长可能很好看，长期关系可能会被消耗。
比如一个学习产品，如果天天用排行榜刺激用户，一开始会让人更积极。但时间久了，排名靠前的人越来越上瘾，排名靠后的人越来越挫败，中间的人慢慢麻木。
最后产品收获了活跃，却未必收获了真正的学习。
再比如一个工具产品，如果不停用"会员专享""限时解锁""立即升级"打断用户，收入可能会上升，但用户对工具的信任感会下降。
产品设计不是不能用欲望，而是要知道欲望有副作用。
好的产品不只是让用户点击，更要让用户使用后不后悔。
五、"不见可欲"：别把团队的心搅乱
"不见可欲，使民心不乱。"
这句话在今天尤其有现实感。
我们生活和工作里，有太多"可欲"的东西。
社交媒体上，是别人的升职、跳槽、创业、融资、影响力。
技术社区里，是别人的开源项目、演讲、证书、收入、履历。
公司内部，是别人的评级、奖金、项目、曝光、老板认可。
这些东西不一定是假的，也不一定不好。
但如果一个人长期被这些东西刺激，心很容易乱。
程序员会开始怀疑：
我是不是太慢了？
我是不是技术不够新？
我是不是应该赶紧学下一个框架？
我是不是还不够有影响力？
产品经理会开始焦虑：
别人的增长怎么这么快？
别人的功能怎么这么会包装？
别人的项目怎么总能拿资源？
我是不是也得做点更大的概念？
团队也会被这种欲望带偏。
本来应该认真修一个基础体验问题，结果大家去追热点。
本来应该沉下心来解决稳定性，结果大家去包装创新项目。
本来应该为用户做一个朴素但有用的功能，结果大家去做更容易汇报的"大版本"。
这就是"民心乱"。
心一乱，判断就乱；判断一乱，系统就乱。
所以，一个好的团队环境，不应该天天刺激比较、焦虑和欲望。
不是让大家没有追求，而是别让追求被外部信号牵着跑。
六、"虚其心，实其腹"：少一点噪音，多一点真实支持
"是以圣人之治，虚其心，实其腹。"
这句话也容易被误读。
"虚其心"不是让人没有思想，而是减少杂念、噪音和无谓的焦虑。
"实其腹"不是只管吃饱，而是让基本需求得到真实满足。
放到团队管理里，就是：
少讲空话，多给支持。
少制造焦虑，多解决问题。
少喊口号，多补资源。
少让大家猜，多把信息讲清楚。
有些团队很喜欢开大会讲方向、讲愿景、讲挑战、讲危机感。
讲一次有用，讲多了就会变成噪音。
如果团队真正缺的是测试环境，你讲再多长期主义也没用。
如果研发真正缺的是需求澄清，你讲再多效率也没用。
如果产品真正缺的是用户反馈，你讲再多增长也没用。
如果大家真正缺的是明确优先级，你讲再多使命感也没用。
"实其腹"就是解决这些具体问题。
比如：
- 给清楚的目标
- 给稳定的排期
- 给必要的人力
- 给真实的用户反馈
- 给可用的工具链
- 给足够的测试时间
- 给能落地的决策机制
团队不是靠鸡血跑起来的。
真正能让人安心工作的，是目标清楚、资源匹配、边界明确、反馈真实。
七、"弱其志，强其骨"：削弱虚荣心，增强基本功
"弱其志，强其骨。"
这里的"志"，不能简单理解成志向。
如果理解成"压制人的志向"，那就太粗糙了。
放在这一章的语境里，它更像是那些被外部刺激出来的争胜心、炫耀心、占有心和不安分的欲望。
"强其骨"，则是把真正支撑系统的骨架建起来。
对程序员来说，"骨"是什么？
是清晰的模块边界。
是稳定的测试。
是可靠的监控。
是能读懂的文档。
是可回滚的发布。
是可追踪的问题链路。
是团队都能理解的工程规范。
对产品经理来说，"骨"是什么？
是对用户场景的真实理解。
是对业务目标的清楚拆解。
是对优先级的判断能力。
是对边界条件的敏感。
是对数据的合理使用。
是对长期体验的负责。
很多团队的问题，不是没有志向，而是骨头太弱。
目标喊得很大，但基础链路不稳。
版本规划很漂亮，但需求反复变。
技术方案很先进，但线上监控缺失。
产品概念很宏大，但用户基本路径都走不顺。
这时候继续强化"志"，只会让团队更焦虑。
真正应该做的是"强其骨"。
把基本盘打牢，把流程理顺，把系统稳住，把关键问题一个个解决掉。
人只有站得稳，才谈得上走得远。
八、"常使民无知无欲"：不是让人无知，而是减少无效刺激
"常使民无知无欲。"
这句最危险，也最需要现代解释。
如果把它理解成让人愚昧、让人没有判断力，那当然不值得接受。
但如果放回前文，它更像是在说：不要让人被过多的机巧、欲望和争夺牵着走。
在一个团队里，"知"有两种。
一种是做事所需要的知识：业务背景、技术方案、用户反馈、系统风险、决策逻辑。这个当然越透明越好。
另一种是会制造内耗的信息：谁和老板关系更近、谁可能晋升、哪个项目更容易露脸、哪个资源可以争、谁在背后评价谁。
前一种知识，要让团队充分知道。
后一种噪音，要尽量少制造。
"无欲"也不是没有目标，而是少一点被外部刺激牵动的欲望。
一个好的团队，不应该让大家天天想着：
我怎么赢过同事？
我怎么抢到更亮的项目？
我怎么把功劳归到自己名下？
我怎么让别人看起来不如我？
它应该让大家更容易把注意力放回事情本身：
用户的问题是什么？
系统的风险在哪里？
这个版本最重要的目标是什么？
我们怎样让协作更顺畅？
这才是"无知无欲"比较健康的现代理解。
不是减少人的思考，而是减少让人走偏的刺激。
九、"使夫知者不敢为"：别让聪明人钻系统空子
"使夫知者不敢为也。"
这里的"知者"，可以理解为很聪明、很会算计、很懂规则漏洞的人。
任何组织里都有聪明人。
聪明本身当然是好事。问题是，如果系统规则设计得不好，聪明人就会把能力用在钻空子上。
比如：
- 绩效只看代码行数，就有人写更多无意义代码
- 绩效只看需求数量，就有人拆很多小需求刷存在感
- 绩效只看上线速度，就有人牺牲测试和质量
- 绩效只看故障次数，就有人减少发布、掩盖问题
- 绩效只看用户增长，就有人过度打扰用户
- 绩效只看成本下降，就有人把成本转移给其他团队
这不是人的问题，是系统在邀请人这样做。
一个指标一旦成为唯一目标，就会被聪明人优化到变形。
所以好的治理，不是天天要求大家"要有主人翁精神"，而是把规则设计得更不容易被利用。
比如：
- 评价研发，不只看产出，也看质量、协作和长期维护
- 评价产品，不只看增长，也看留存、体验和用户信任
- 评价团队，不只看短期结果，也看风险、债务和组织能力
- 评价管理者，不只看项目成功，也看团队是否变得更强
当规则足够清楚，边界足够稳定，反馈足够真实，聪明人就不容易把聪明用偏。
这就是"使夫知者不敢为"的现代意义：
不是压制聪明人，而是不要让系统奖励投机。
十、"为无为"：最好的管理，是让系统自己变顺
"为无为，则无不治。"
又回到了老子最重要的词：无为。
无为不是不做事。
在第三章里，它更像是一种治理方式：
少制造欲望，少制造争夺，少制造噪音，少制造让人投机的规则。
你不需要天天喊大家不要内卷，如果你的评价体系天天制造排名，大家自然会内卷。
你不需要天天喊大家要协作，如果你的激励只奖励个人英雄，大家自然会各自为战。
你不需要天天喊大家重视质量，如果你的排期永远压缩测试，大家自然会牺牲质量。
你不需要天天喊大家关注用户，如果你的汇报只看漂亮数据，大家自然会包装数据。
很多管理问题，不是靠多开会解决的，而是靠重新设计系统解决的。
这和写代码很像。
如果一个函数总是被误用，你不能只在群里提醒大家"不要误用"。你要考虑是不是命名不清楚、参数设计不合理、默认行为太危险、缺少类型约束、没有测试保护。
如果一个流程总是出错，你不能只要求大家"更仔细"。你要考虑是不是步骤太多、责任不清、反馈太慢、工具太差、异常路径没人兜底。
真正的"为无为"，不是管理者什么都不做，而是做那些能让系统自然变好的事。
少一点临时干预，多一点机制建设。
少一点情绪推动，多一点规则清晰。
少一点英雄救火，多一点系统兜底。
少一点口号激励，多一点真实支持。
当系统顺了，很多问题不需要反复管。
十一、总结
不要低估激励系统对人的塑造。
程序员写代码时，要知道接口、默认值、权限、错误提示，都会塑造使用者的行为。
产品经理做功能时，要知道红点、排行榜、会员权益、限时活动，都会塑造用户的欲望。
管理者带团队时，要知道绩效、晋升、资源、曝光机会，都会塑造成员的注意力。
你设计什么，人就会围绕什么行动。
所以，不要轻易制造稀缺，不要随便刺激攀比，不要把少数英雄捧成团队唯一的解法，不要让聪明人通过钻规则漏洞获得收益。
真正好的系统，不是把人逼得更努力，而是让人更容易把力气用在正确的地方。
真正好的团队，不是每个人都在争着证明自己，而是大家能稳定地把事情做好。
真正好的产品，不是不断刺激用户想要更多，而是让用户在使用中获得更少的焦虑和更多的确定感。
第三章最后落到一句话：
少制造欲望，多建设骨架；少崇拜英雄，多沉淀系统；少用刺激驱动人，多用清晰、稳定和真实支持让事情自然变好。
这就是"为无为，则无不治"在技术世界里的意思。