掘金专栏可能会更新不及时，欢迎大家移步道德经：程序之路
天下皆知美之为美，斯恶已。
皆知善之为善，斯不善已。
故有无相生，难易相成，长短相形，高下相倾，音声相和，前后相随，恒也。
是以圣人处无为之事，行不言之教，万物作焉而不辞，生而不有，为而不恃，功成而弗居。
夫唯弗居，是以不去。
《道德经》第二章，讲的是一个很容易被忽略的问题：
当我们开始集体认定什么是“好”的时候，另一些东西也会被顺手定义成“不好”。
这句话放在技术世界里，特别有意思。
因为程序员和产品经理，都很喜欢讨论“什么是好的”。
什么是好代码？ 什么是好架构？ 什么是好产品？ 什么是好设计？ 什么是好流程？ 什么是好团队？
这些问题当然重要。没有标准，团队很难协作；没有审美，产品很难进步；没有工程规范，系统迟早会变成一团乱麻。
但老子在第二章里提醒我们：一旦某种“好”被绝对化，它就可能变成新的束缚。
很多时候，问题不是我们没有标准，而是我们太快相信了某个标准。
一、美和善，不是孤立存在的
“天下皆知美之为美，斯恶已。”
这句话不是说美不好，也不是说不要追求美。
它真正想说的是：当天下人都知道某个东西是“美”的时候，“丑”的概念也就同时被制造出来了。
比如大家都说极简设计好，于是复杂就变得可疑；大家都说微服务先进，于是单体架构就显得落后；大家都说代码要优雅，于是那些为了救火写出来的代码就容易被嘲笑。
但真实世界没有这么简单。
有些“复杂”，其实是在承载真实业务；有些“单体”，其实比过早拆分的微服务更稳；有些“不优雅”的代码，背后可能是一个团队在资源有限、时间紧张、线上压力巨大的情况下做出的现实选择。
“皆知善之为善，斯不善已。”
这句话也是一样。
当我们把某种做法定义成“善”，另一种做法就会被定义成“不善”。可问题是，工作里的很多选择不是善恶题，而是场景题。
加班是好还是坏？ 写单测是好还是坏？ 上微服务是好还是坏？ 做中台是好还是坏？ 需求要不要砍？ 代码要不要重构？
如果脱离场景，答案都很漂亮；一回到真实项目，答案马上变得没那么干净。
这就是第二章很锋利的地方：它不是反对标准，而是反对把标准当成真理。
二、技术人最容易迷信的东西：最佳实践
技术圈有一个很常见的词，叫“最佳实践”。
这个词本身没有问题。它是很多人踩坑之后总结出来的经验，能帮后来者少走弯路。
但如果使用不当，“最佳实践”很快会变成“最佳迷信”。
比如：
- 只要项目大一点，就必须上微服务
- 只要前端复杂一点，就必须上状态管理
- 只要接口多一点，就必须上网关
- 只要团队人多一点，就必须做中台
- 只要代码旧一点，就必须全面重构
- 只要有业务逻辑，就必须抽象成配置
这些做法有没有价值？当然有。
但它们都有前提。
微服务解决的是组织协作、独立部署、复杂系统边界的问题。可如果一个团队只有三五个人，业务还没跑通，过早拆微服务，很可能不是先进，而是给自己造出一堆网络调用、链路追踪、数据一致性、部署运维和排障成本。
状态管理解决的是复杂状态流转的问题。可如果页面只是几个表单和列表，硬上一套复杂状态模型，最后可能每改一个字段都要穿过三层概念。
中台解决的是复用和沉淀的问题。可如果业务模型还在剧烈变化，过早中台化，就容易把不稳定的东西固化，最后前台嫌它慢，后台嫌它乱，中台自己也很痛苦。
所以，一个成熟的技术判断，不是问：
这是不是最佳实践？
而是问：
在我们现在的团队、业务、规模、成本和风险下，这是不是合适的实践？
这就是“美之为美，斯恶已”在工程里的意思。
当你把某种架构认定为“美”，你可能就看不见它的代价；当你把某种代码风格认定为“善”，你可能就会误伤那些在特定场景下更朴素、更直接、更可靠的选择。
三、“有无相生”：功能和空白，是一起设计出来的
“故有无相生。”
有和无，不是互相独立的。一个东西被做出来，另一些东西就被留下了。
产品经理特别需要理解这句话。
很多人以为产品设计就是不断增加功能：用户要什么，我们就做什么；竞品有什么，我们也补什么；老板想到什么，就排进需求池。
但一个产品真正的质感，往往不只来自“做了什么”，也来自“没做什么”。
你做了一个导出功能，就要考虑用户会不会绕过系统在线协作，全部转到 Excel 里处理。
你做了一个手动配置入口，就要考虑运营会不会把本该由系统规则保障的事情，变成每天人工调参。
你做了一个强大的筛选器，就要考虑普通用户会不会被过多条件吓退。
你做了一个“跳过流程”的后门，就要考虑未来每个异常 case 都会不会来找你开后门。
功能不是越多越好。
每一个“有”，都会带来一个新的维护面；每一个按钮，都会带来一个新的解释成本；每一个配置项，都会带来一个新的误操作空间。
同样，每一个“无”，也不是偷懒。
不做某个功能，可能是在保护主流程；不暴露某个配置，可能是在保护用户；不支持某种极端场景，可能是在保护系统复杂度。
好的产品经理，不是把需求池填满的人，而是能判断哪些“不做”同样有价值的人。
好的程序员也一样。
有时候，最好的代码不是多写一层抽象，而是让逻辑停在一个足够清楚的位置。
因为“无”不是空白，它也是设计的一部分。
四、“难易相成”：你觉得简单，可能只是有人替你扛了复杂
“难易相成。”
难和易，也不是固定的。很多“简单”，只是复杂被转移了位置。
用户觉得扫码登录很简单，是因为背后有人处理了二维码生成、状态轮询、过期机制、账号绑定、设备信任、异常提示和安全风控。
业务觉得“加一个字段很简单”，是因为他只看到了页面上的输入框，没有看到数据库迁移、接口兼容、历史数据、导入导出、权限控制、埋点统计、测试用例和下游依赖。
产品觉得“这个页面很简单”，是因为他只看到了静态原型，没有看到各种空状态、异常状态、加载状态、权限状态、边界状态。
前端觉得后端“给个接口就行”，后端觉得前端“调一下接口就行”。两边都觉得自己说的是小事，最后一联调，发现小事全挤在一起，谁都不小。
所以，技术协作里很重要的一种能力，就是看见别人那边的难。
一个产品经理如果只会说“这不就是加个按钮吗”，很难获得研发信任。
一个程序员如果只会说“这需求很简单，你们怎么还没想清楚”，也很难真正理解业务。
难和易是互相生成的。
你把用户使用变简单，系统实现就可能变复杂。
你把配置做得更灵活，维护成本就可能变复杂。
你把研发排期压得更短，测试和线上风险就可能变复杂。
你把当前版本做得更快，未来迭代就可能变复杂。
成熟的团队不会只问“这件事难不难”，而是会问：
这个难，应该由谁来承担？
这个复杂度，放在哪里最合适？
这个版本先简单，未来会不会更难？
我们现在省下来的成本，会不会在上线后加倍还回来？
这才是“难易相成”的工程理解。
五、“长短相形，高下相倾”：评价永远来自对比
“长短相形，高下相倾。”
长和短，是比较出来的；高和下，也是关系里出现的。
在团队里，很多焦虑都来自这种比较。
你看到别人一天能写很多代码，就觉得自己效率低。
你看到别人会很多框架，就觉得自己技术浅。
你看到别人负责核心项目，就觉得自己不重要。
你看到别的产品增长很快，就觉得自己的产品没价值。
但比较如果脱离上下文，就很容易伤人，也很容易误导判断。
一个人提交代码多，不代表他解决的问题更难。
一个人话少，不代表他没有思考。
一个功能增长快，不代表它长期健康。
一个系统看起来老，不代表它没有价值。
一个新人问很多问题，不代表他不聪明，可能只是团队文档太少、上下文太乱。
管理者尤其要小心这种对比。
如果你只用产出数量评价研发，就会鼓励大家多写代码，而不是少造复杂度。
如果你只用上线速度评价产品，就会鼓励大家堆功能，而不是解决真问题。
如果你只用故障次数评价运维，就可能让团队害怕变更，系统反而越来越僵。
指标一旦成为唯一标准，就会开始塑造行为。
这也是为什么“皆知善之为善，斯不善已”很适合讲绩效。
当团队公开说“我们最看重效率”，大家可能会牺牲质量。
当团队公开说“我们最看重质量”，大家可能会害怕试错。
当团队公开说“我们最看重创新”，大家可能会包装概念。
当团队公开说“我们最看重结果”，大家可能会忽视过程里的债务。
不是这些价值观错了，而是任何单一价值，一旦被推到极端，都会产生副作用。
六、“音声相和，前后相随”：系统不是一个点，而是一串关系
“音声相和，前后相随。”
声音和回声互相应和，前和后互相跟随。
这句话放到软件系统里，就是一句大白话：
没有孤立的改动。
你改一个接口，调用方会跟着变。
你改一个字段，数据报表会跟着变。
你改一个流程，客服话术会跟着变。
你改一个权限，运营后台会跟着变。
你改一个价格策略，销售、财务、用户心智都会跟着变。
很多事故并不是因为某个改动本身很大，而是因为团队低估了它的关系链。
比如一个看起来很简单的需求：
注册页增加一个“邀请码”字段。
如果只看页面，它确实不复杂。
但往后看，它可能牵动：
- 邀请码生成规则
- 邀请码有效期
- 邀请关系绑定
- 老用户补绑逻辑
- 奖励发放规则
- 作弊检测
- 数据统计
- 客服查询
- 财务对账
- 活动结束后的存量处理
这就是“前后相随”。
一个需求不是孤零零地站在那里，它站在一串关系里。
所以优秀的研发和产品，都有一种“关系感”。他们看到一个按钮，不只看到按钮；看到一个字段，不只看到字段；看到一个接口，不只看到接口。
他们会自然地问：
- 谁会使用它？
- 谁会依赖它？
- 谁会误用它？
- 它失败时谁来兜底？
- 它上线后谁来维护？
- 它未来不需要了，能不能下线？
这不是想太多，这是在看系统。
七、“无为”不是躺平，而是不乱作为
第二章后半段开始讲“圣人”。
“是以圣人处无为之事，行不言之教。”
很多人一听“无为”，就容易误解成什么都不做。
其实不是。
老子的“无为”，更接近于：不强行干预，不为了证明自己有用而乱作为。
这放到团队管理里，非常重要。
有些管理者一上来就喜欢抓存在感：
- 每个需求都要改两句
- 每个设计都要提意见
- 每个方案都要重新排优先级
- 每个会议都要总结一套方法论
- 每个问题都要找一个负责人背锅
看起来很负责，实际上团队很累。
因为大家不再围绕问题工作，而是围绕管理者的判断工作。
真正好的管理，不是把自己的手伸进每一个细节，而是让系统自己能运转。
比如：
- 让目标足够清楚，减少反复解释
- 让边界足够清楚，减少互相甩锅
- 让信息足够透明，减少猜测和内耗
- 让反馈足够及时，减少问题堆积
- 让规则足够稳定，减少临时拍脑袋
这就是“处无为之事”。
不是不做事，而是少做那些会制造噪音、制造依赖、制造表演感的事。
八、“行不言之教”：好的团队文化，写在日常里
“行不言之教。”
这句话也特别适合技术团队。
很多团队都喜欢说自己重视工程质量，重视长期主义，重视用户价值，重视复盘，重视协作。
但团队真正相信什么，不看口号，看日常。
你说重视代码质量，但每次排期都把测试时间压掉，大家自然知道质量不重要。
你说鼓励坦诚沟通，但每次有人指出问题就被认为“不积极”，大家自然学会沉默。
你说允许试错，但每次试错失败都被追责，大家自然只做安全的事。
你说重视用户价值，但每次评审只看老板喜不喜欢，大家自然会服务老板的偏好。
文化不是说出来的，是被一次次选择教出来的。
对程序员来说，“不言之教”也可以很具体。
一个项目里，如果好代码真的更容易被理解、复用和扩展，大家会自然学习它。
一个团队里，如果认真写文档的人真的减少了沟通成本，大家会自然尊重文档。
一个流程里，如果自动化测试真的能挡住线上问题，大家会自然愿意补测试。
一个 code review 里，如果评论是为了帮助对方变好，而不是展示自己厉害，大家会自然接受 review。
好的规则不需要天天喊。
如果它真的有用，系统会替它说话。
九、“生而不有，为而不恃”：别让团队依赖英雄
“万物作焉而不辞，生而不有，为而不恃。”
这几句很适合讲技术骨干。
很多团队里都有“超级英雄”：
- 线上故障只有他能排
- 核心模块只有他敢改
- 历史逻辑只有他知道
- 关键客户只有他能搞定
- 所有疑难杂症最后都找他
短期看，这是能力强。
长期看，这很危险。
因为系统、知识和流程都被绑定在一个人身上。这个人请假，项目就卡住；这个人离职，团队就失忆；这个人太忙，所有人都等他。
“生而不有”，是创造了东西，但不把它占为己有。
“为而不恃”，是做成了事情，但不让别人永远依赖自己。
一个成熟的技术负责人，不是把自己变成不可替代的人，而是让关键事情逐渐不再依赖自己。
他会写文档，会带新人，会拆模块，会补监控，会推动自动化，会让排障路径标准化，会把脑子里的经验变成团队可复用的资产。
这听起来好像降低了自己的“稀缺性”。
但实际上，真正高级的影响力不是别人离不开你，而是你让更多人变强。
一个人越是需要反复证明“没有我不行”，越说明他的价值还停留在占有资源上。
一个人越能让事情离开自己也运转，越说明他的价值已经变成了系统能力。
十、“功成而弗居”：做成事后，别急着占住功劳
“功成而弗居。夫唯弗居，是以不去。”
事情做成了，却不把功劳牢牢占住。正因为不占住，所以它反而不会离开。
这句话很适合职场。
很多人做出成绩后，第一反应是证明：
这是我做的。
这是我推动的。
没有我，这事不可能成。
你们要记得我的贡献。
这种心情很正常。职场不是修仙，功劳当然需要被看见。
但老子提醒的是另一层东西：如果一个人太执着于占有功劳，他的影响力反而会变窄。
因为大家会觉得，你做事不是为了事情本身，而是为了证明自己。
在团队协作里，真正让人信任的，往往是那些能把功劳分出去的人。
产品上线成功，他会说研发解决了关键复杂度。
故障恢复及时，他会说运维和测试提前准备了预案。
项目推进顺利，他会说设计、业务、数据都补上了关键拼图。
新人有成长，他会让新人站到台前讲自己的方案。
这种人不是没有贡献，而是很清楚：一个复杂项目不可能靠一个人完成。
他越不急着把功劳攥在手里，别人越记得他的分量。
这就是“夫唯弗居，是以不去”。
你不占有，反而留下；你不抢，反而被看见。
十一、总结
如果说第一章讲的是：不要把名字当成真相。
那第二章讲的就是：不要把标准当成绝对。
美和丑，善和不善，难和易，长和短，高和下，都不是孤立存在的。它们都在关系里生成，在对比里变化，在场景里成立。
所以，技术人真正要训练的不是背更多标准答案，而是培养一种关系感和场景感。
看到“好代码”，要问它好在哪里，适合什么场景，代价是什么。
看到“最佳实践”，要问它解决了什么问题，又制造了什么问题。
看到“简单需求”，要问复杂度被放到了哪里。
看到“团队规范”，要问它是在帮助协作，还是在制造形式。
看到“个人贡献”，要问它能不能沉淀成团队能力。
老子说“无为”，不是让我们少做事。
而是提醒我们：别为了显得正确而过度判断，别为了显得先进而过度设计，别为了显得负责而过度干预，别为了显得重要而占住功劳。
真正好的程序员，不是永远选择最炫的技术，而是知道什么场景该复杂，什么场景该简单。
真正好的产品经理，不是永远满足更多需求，而是知道什么应该做，什么应该留白。
真正好的管理者，不是把自己的意志压到每个角落，而是让团队在清楚的边界里自然生长。
第二章最后其实是在讲一种很高级的工作状态：
把事情做成，但不让事情变成对自己的证明；把系统建好，但不让系统依赖自己的存在；把标准立起来，但永远记得标准只是工具，不是真理。
这对技术人来说，已经足够深了。
