道可道非常道名可名非常名。无名天地之始有名万物之母。故常无欲以观其妙常有欲以观其徼。此两者同出而异名同谓之玄。玄之又玄众妙之门。《道德经》第一章一上来就很“反直觉”。我们平时做技术、做产品最喜欢什么喜欢定义。需求要定义字段要定义接口要定义流程要定义指标要定义。最好每个东西都有名字、有边界、有负责人、有排期。这当然很重要。没有定义团队无法协作没有命名系统无法表达没有文档复杂工作很快就会变成一团乱麻。但老子第一章提醒我们能被说清楚的往往只是事物的一部分能被命名的往往已经不是事物的全部。这句话放到今天的技术和产品世界里依然非常锋利。一、道和名到底在说什么“道可道非常道。”这里的第一个“道”可以理解为事物背后的规律、运行方式、真实逻辑。第二个“道”是说出来、表达出来、描述出来。所以这句话不是说“道不能说”而是说凡是能被完整说出来、固定写下来的规律都不是永恒不变的规律本身。比如你写了一份《系统架构设计文档》它当然有价值。但它不是系统本身。真正的系统存在于代码、流量、依赖、历史包袱、团队习惯、线上故障和用户行为里。文档只是地图系统才是地形。“名可名非常名。”这句话也不是反对命名。恰恰相反命名非常重要。程序员都知道好的命名能救命坏的命名能让人怀疑人生。但老子提醒我们名字只是人为切出来的标签不等于事物本身。比如一个字段叫status看起来很简单。可你真去维护它可能会发现里面藏着十几种状态未提交审核中审核失败已发布已下架已删除被风控拦截用户不可见但运营可见名字叫status但真实世界从来不只是一个字段名那么清爽。“无名天地之始有名万物之母。”没有名字之前世界是混沌的、整体的、未被切分的。有了名字之后我们才能分类、识别、沟通、管理。这和做产品很像。用户最开始只有一个模糊感受“这个东西不好用”“这里很麻烦”“我找不到我要的”。产品经理要把这种模糊感受拆成需求、流程、页面、交互、指标。命名让世界可操作但也会让我们误以为自己已经理解了世界。二、需求文档不是需求PRD 也不是用户做产品的人最容易遇到这个问题。用户说“我想要一个导出功能。”于是需求文档里写增加数据导出功能支持 Excel 下载。看起来很明确对吧但这只是“名”。它被命名成了“导出功能”。真正的“道”可能是用户要向老板汇报所以需要一张能直接放进周报的表用户要做二次分析所以需要结构化数据用户不信任系统页面所以想把数据拿到本地留档用户只是想分享给同事并不是真的需要 Excel如果不继续追问你可能会做出一个非常标准、但并不好用的导出按钮。最后用户还是不满意因为他真正想要的不是“导出”而是“可交付”“可分析”“可证明”“可协作”。这就是第一章的意思名字是入口不是真相。产品经理如果只停在需求名称上就会变成“功能搬运工”。用户说要什么就排什么老板说做什么就拆什么竞品有什么就抄什么。但真正好的产品判断往往发生在命名之前。你要问用户为什么这样说他在哪个场景下说的他说的是方案还是问题这个需求背后有没有更简单的解决方式很多时候用户嘴里的“我要一个按钮”翻译成人话其实是“我现在没有安全感。”这才是产品工作有意思的地方。三、变量名不是业务接口名也不是设计程序员同样逃不开“名”的陷阱。比如你看到一个变量constisValidcheckUser(input)看起来很清楚用户有效。但什么叫有效是格式有效权限有效账号状态有效风控有效会员有效当前业务场景下有效如果你不看上下文只相信变量名很容易踩坑。因为代码里的“名”常常只是某个历史时刻留下来的简化表达。再比如一个接口叫GET /api/order/detail听起来只是“订单详情”。但它可能承担了太多职责返回订单基础信息返回支付状态返回物流信息返回售后入口返回优惠券展示返回运营活动配置顺便埋点顺便触发一次状态刷新接口名叫 detail但真实行为可能已经变成了“订单详情页后端总控中心”。所以成熟的程序员不会只看名字。他会看调用链、数据流、异常分支、历史提交、线上表现。因为他知道命名帮助我们理解系统但系统不会因为命名好听就变简单。四、“无欲以观其妙”先别急着下结论“常无欲以观其妙”这句话特别适合排查问题。线上出故障时很多人的第一反应是找一个熟悉的原因“是不是数据库慢了”“是不是缓存穿透了”“是不是前端没传参数”“是不是某个人昨天改坏了”这些猜测不一定错但如果太早认定答案就会被自己的经验带偏。“无欲”不是没有目标而是先放下执念。先看现象别急着贴标签。比如一次接口超时你可以先看超时从什么时候开始是全部用户还是部分用户是所有接口还是某个接口是平均耗时上升还是 P99 抖动是代码变更、流量变化还是依赖服务异常这就是“观其妙”。它不是玄学而是系统性观察。你暂时不急着证明自己是对的才更可能看到事情真实的样子。五、“有欲以观其徼”带着目标看清边界但只观察也不够。“常有欲以观其徼”意思是当你带着目标去看就能看到边界、结果、路径和限制。排查问题时观察之后要收敛哪条链路最可疑哪个依赖最近变更过哪个指标最先异常哪个修复动作风险最低做产品也是一样。你既要“无欲”地观察用户不急着把用户行为塞进自己的预设里也要“有欲”地做取舍明确当前版本到底解决哪个问题。只无欲容易变成漫无边际的调研。只有欲容易变成带着 KPI 找证据。好的产品和好的工程都需要这两种视角来回切换。先打开再收敛。先看见复杂性再做简化。六、一个产品例子用户真的需要“标签”吗假设你在做一个笔记产品。用户反馈“能不能加一个标签功能我想给笔记分类。”这听起来很合理。很多产品都有标签做起来也不算太难。但如果你只听到“标签”这个名字就很容易直接进入方案支持新建标签支持给笔记打标签支持按标签筛选支持标签管理功能上线后用户可能一开始很开心但过一阵子就不用了。为什么因为他真正的问题可能不是“缺少标签”而是笔记太多找不到以前写过的内容内容之间没有关联知识很难沉淀分类本身太累坚持不下去搜索不好用只能靠人工整理如果看到了这一层你的方案可能就不一样了。你也许会优先优化搜索也许会做自动关联也许会在用户写作时推荐相关内容也许会减少手动整理成本。标签是“名”信息找回才可能是“道”。七、一个技术例子重构不等于变好技术团队里也有很多容易让人兴奋的词。比如“重构”。一听到重构很多人会默认这是好事代码更优雅架构更清晰系统更现代。但真实情况没那么简单。有些重构确实是在降低复杂度也有些重构只是把熟悉的复杂度换成了不熟悉的复杂度。旧系统的问题是方法太长、模块太乱新系统的问题可能变成抽象太多、链路太深、排查太难。表面上看名字从“老代码”变成了“新架构”。但系统的本质问题未必解决了。所以判断一次重构值不值得不是看它用了什么模式也不是看目录结构漂不漂亮而是看变更成本有没有下降故障定位有没有更快新人理解有没有更容易核心链路有没有更稳定业务迭代有没有更顺畅名字会让人兴奋结果才会说明问题。八、穿过名字看见结构这一章看起来很玄其实非常务实。它不是让我们否定语言、否定命名、否定文档。恰恰相反我们需要这些东西。没有名字人无法协作没有定义系统无法建模没有抽象复杂度会把人压垮。但老子提醒我们使用名字但不要被名字困住。看到“增长”要问增长什么、为什么增长、代价是什么。看到“留存”要问用户留下来是因为价值还是因为迁移成本。看到“中台”要问它是在复用能力还是在制造流程。看到“AI 能力”要问它到底解决了什么真实问题。技术世界尤其如此。看到“微服务”别先激动先问团队有没有治理能力。看到“低代码”别先排斥先问目标用户是不是需要降低门槛。看到“DDD”别先套概念先问领域边界是不是真的清楚。所有名词都有用但所有名词都危险。因为它们一旦变成口号就会遮住真实问题。九、总结如果把第一章翻译成今天的工作语言我会这样说需求文档不是需求接口名称不是接口行为产品指标不是用户价值技术方案不是系统本身。我们需要命名因为命名让复杂世界变得可讨论。但我们也要穿过命名因为真正的问题常常藏在名字后面。一个人变成熟的标志是不再轻易被词带着跑。听到一个概念他会问场景。看到一个方案他会问代价。拿到一个需求他会问动机。面对一个系统他会问它真实如何运行。这就是《道德经》第一章给技术人的第一课别急着定义世界先学会看见世界。当你能在“名”之外继续往前走一点就已经站在“众妙之门”前了。