三十辐共一毂，当其无，有车之用。
埏埴以为器，当其无，有器之用。
凿户牖以为室，当其无，有室之用。
故有之以为利，无之以为用。
真正产生作用的，往往不是你堆出来的东西，而是你留出来的空间。
老子说：
有之以为利，无之以为用。
"有"给我们带来条件、结构、边界和材料。
"无"才让这些东西真正被使用、被进入、被流动、被容纳。
这句话放到技术和产品世界里，太重要了。
很多系统失败，不是因为"有"太少，而是因为"无"被填满了。
所以说：
设计不是把一切都做出来，而是知道哪些地方必须留空。
先解释原文：空，不是没有价值
"三十辐共一毂，当其无，有车之用。"
车轮上有辐条，有轮毂，有结构。但车轮真正能转，是因为轮毂中间有孔，可以装轴。
如果这个孔被填满，车轮再漂亮也不能用。
"埏埴以为器，当其无，有器之用。"
揉捏泥土做成碗、杯、罐。你能看见的是泥土的形状，但真正能装东西的，是器皿中间的空。
如果杯子是实心的，它就只是一个泥块。
"凿户牖以为室，当其无，有室之用。"
建房子需要墙壁、屋顶、门窗。但房子真正能住人，是因为里面有空间，门窗让人和光可以进出。
如果房子全被砖头填满，它就不能住。 这就是"有之以为利，无之以为用"。
"有"提供形体，"无"产生用途。这个思想非常现代。我们习惯崇拜"有"。
有功能，有页面，有指标，有文档，有规则，有会议，有 OKR，有组织架构。
代码里的"无"：不是没写，而是留出可维护空间
程序员最容易把价值等同于"写了多少"。
写了多少代码，抽了多少组件。
但很多时候，真正让系统长期可用的，不是你多写了什么，而是你少写了什么。
少写重复的逻辑，少把业务分支塞进同一个方法，少让调用方知道太多不该知道的东西。
这些"少"，其实就是代码里的"无"。
比如一个函数：
js
function submitOrder(order) {
validateUser(order.user)
validateCoupon(order.coupon)
calculatePrice(order)
lockInventory(order)
createPayment(order)
sendMessage(order)
writeLog(order)
updateMarketingData(order)
}看起来很完整，但它太满了。
所有事情都挤在一个地方，未来任何变化都会来改它。
这个函数的"有"很多，但"无"很少。
它没有给变化留出空间。
更好的设计，不一定是立刻做一个复杂架构，而是至少让不同职责有自己的位置。
这样未来变化来了，才有地方可以落。
可维护性很多时候不是靠写更多代码获得的，而是靠留出正确的空隙获得的。
好的代码像房子。
墙壁要有，门窗也要有；结构要稳，空间也要通。
接口设计里的"无"：不要让调用方背太多东西
接口设计也很能体现"有"和"无"。
一个坏接口，往往看起来很强大。
参数很多，配置很多，返回很多，能力很多。
比如：
txt
POST /api/search
keyword
type
scene
source
sortType
filterMode
permissionLevel
includeDeleted
includeOffline
enableCache
cacheStrategy
fallbackMode
debug这接口非常"有"，什么都能控制，但调用方会很痛苦。
因为他需要知道太多内部细节：
什么场景用什么参数，哪些默认值安全，哪些参数最好不要碰。
这时候接口的"有"，变成了调用方的负担。
好的接口要留出"无"。
这个"无"不是没有能力，而是让调用方不用知道不该知道的复杂度。
所以接口真正的价值，不只是提供能力，也在于吸收复杂度。
一个好的平台，不是把所有复杂度扔给使用者，而是把复杂度留在平台内部，用简单稳定的方式对外输出。
这也是"有之以为利，无之以为用"。
你写出来的接口是"有"，调用方不用操心的部分才是"用"。
产品设计里的"无"：用户需要的不是更多按钮
产品经理也很容易迷恋"有"。
有首页，有导航，有搜索，有筛选，有导出，有通知。
每个功能都有价值。
但功能一多，用户不一定更幸福。
因为用户真正想要的，不是拥有更多按钮，而是更少阻力地完成任务。
比如一个数据后台。
产品经理为了灵活，提供了很多筛选条件：
时间范围，地区，渠道，用户类型，订单状态，商品分类，活动来源，支付方式，客户等级，是否复购等等。
这些条件都可能有用。
但如果用户每次都要重新选择一堆条件，才看到自己最关心的结果，这个产品就很累。
功能是"有"，但缺少"无"。
缺什么？
缺少场景化入口，缺少保存常用筛选，缺少自动推荐重点指标，缺少用户不用思考也能开始的位置。
好的产品设计，不是把所有可能性都摊开，而是在用户需要时提供，在用户不需要时收起来。
很多产品的体验提升，不来自新增功能，而来自减少用户要面对的东西。
这些"减少"，就是产品里的"无"。
它们让用户的注意力重新流动起来。
架构里的"无"：边界之间要有空气
技术架构也需要"无"。
很多系统的痛苦，不是模块太少，而是模块之间没有空气。
服务 A 调服务 B，服务 B 查服务 C 的库，服务 C 又依赖服务 A 的配置。
前端直接理解后端状态机，后端又依赖前端传来的业务标记。
订单模块调用用户模块内部方法，用户模块又反过来处理订单状态。
看起来大家连接很紧密。
实际上，这是耦合，系统之间没有"无"。
没有缓冲层，没有稳定接口，没有明确边界。
一个好的架构，不是所有模块都互相知道，而是该隔开的地方隔开。
这不是为了洁癖。
而是为了让系统能各自变化。
比如订单服务不应该知道优惠券内部怎么计算，只应该拿到一个清楚的优惠结果。
用户服务不应该被订单流程绑死，只应该提供稳定的用户身份和权益能力。
营销活动不应该侵入每个业务模块，而应该通过统一规则和事件机制接入。
架构里的"无"，就是模块之间的边界空间，这个空间让系统不至于一动全动。
微服务也好，模块化也好，领域设计也好，本质都不是为了图上好看，而是为了制造可演进的空间。
没有空间，架构就是一块实心砖。
有了空间，系统才像房子。
管理里的"无"：别把人的判断空间填满
管理者也很容易迷恋"有"。
有流程，有日报，有周会，有评审，有审批，有模板，有考核。
这些东西都可能有用。
但如果管理把所有空隙都填满，团队就会失去判断能力。
管理一旦过度依赖审批和流程，员工就容易少思考、少判断，最后只求把事情做"对"，却不再真正对结果负责。
流程的目的，本来是帮助协作，但流程太满，就会替代思考。
好的管理者要知道，制度是"有"，人的主动性是"无"。
你不能只靠制度把团队管好。
你还要留出空间，让成员自己判断、自己负责、自己成长。
比如：
- 明确目标，但不规定每一步怎么做
- 明确边界，但允许团队选择路径
- 明确风险上升机制，但不事事审批
- 明确质量底线，但不把所有细节写死
- 明确复盘要求，但允许团队讨论真实原因
这就是管理里的"有之以为利，无之以为用"。
制度提供框架，空间产生责任。
一个没有制度的团队会乱。
一个只有制度、没有空间的团队会僵。
好的管理，是在两者之间找到平衡。
"有之以为利，无之以为用"：做事要同时设计有和无
有之以为利，无之以为用。
这不是说"有"不重要。
车轮离不开辐条，器皿离不开泥土，房子也离不开墙壁。每一样东西，都有支撑它存在的基础。
所以不要把这一章理解成什么都不做。
真正的意思是：
有和无要配合。
只有"有"，系统会变成实心的、堵塞的、无法使用的东西。
只有"无"，系统没有结构，也没有承载能力。
好的代码要有实现能力，也要留出扩展空间。
好的产品如此，好的架构如此，管理和领导也是如此------既要有规则和方向，也要给人留下判断、发挥和成长的空间。
做技术和做产品，最难的就是同时看见这两面。
真正的设计，不只是知道该做什么，更要知道什么该舍弃、什么该保留。该明确的明确，该留白的留白，让结构服务于目标，也让人保留选择的空间。
这就是成熟的设计感。
写在最后
"无"不是少做一点这么简单，它是使用得以发生的条件。
代码之间要有边界，产品要给用户留出理解空间，制度也不能填满成员的判断。我们做出来的东西提供结构，没有被写死的部分则保留生命。两者能否同时存在，决定了一个系统是工具，还是一块实心的负担。