先回答入口本身的问题：它凭什么撑得久，所谓稳定落在哪几件能被看见的事上，老用户熟悉的规则为什么必须守住。
稳定不等于服务器从没出过故障。它更接近一件日常的事：不管谁来、从哪个城市来、用手机还是电脑，页面都在合理时间内打开，登录状态还在，地址没变。这些事每天成立一次，才叫稳定。
所以入口稳定更像一种值班安排，而不是一次技术选择。有人固定盯着它，它才稳。
小结把“入口没坏过”换成“每天有人确认它没坏”，稳定才有抓手。
不少团队把稳定理解成“不宕机”。对访客来说，稳定是更具体的几件事：地址记得住、打开够快、登录不用重来、页面上的联系方式是对的。少一件，体验就打折。
这几件事都能单独确认，也都能单独退化。逐条盯住，比笼统地说“保持稳定”有用得多。
小结稳定是一组能被逐条确认的小事，不是一句形容词。
规则来回变动，受伤最重的是每天都要进来的人。他们记住的是路径和习惯，改一次就得重新学一次，改两次就开始怀疑这个入口还值不值得依赖。
新访客需要被引导，老用户需要被放过。这两件事本来就不冲突，冲突的是把它们塞进同一套规则里。
小结把规则稳定下来，是对每天都要进来的人最基本的尊重。
接着看站点本身：什么样的做法两年后还改得动，内容结构该在哪一步定下来，上线之后这件事落到谁的日程上。
耐用不是指代码写得漂亮，而是两年后换人接手时，还能看懂、敢改、改完不出事。这件事在搭建阶段就决定了，后期补不回来。
判断方法很朴素：把站点交给一个没参与搭建的人，让他改一句标语、换一张图，看他需不需要问人。
小结耐用靠的是搭建时留出的余地，不是上线后打的补丁。
内容结构决定之后每一次更新的成本。首页、栏目页、内容页各自承担什么，最好在第一版就分清，越往后改越贵。
结构定得清楚，运营的人不用每次重新想“这条内容放哪儿”，改文案的人也不用担心牵一发而动全身。
小结结构定得越早，后面改一句话的代价越小。
站点上线那天，维护才真正开始。这件事要落到具体的人名和具体的周期上，不能停留在“大家一起看看”。
团队 58 人的分工摆在明面上：谁搭建、谁对接渠道、谁盯入口，各归各的班次，客户才知道遇到哪种事该找哪一组。
小结把维护交到具体的人和具体的周期上，站点才不会在第二个月开始荒。
再往下一层看交付怎么落到城市：六个片区怎么分，跨片区的活谁牵头，伙伴站在什么位置、承担什么。
片区不是在地图上随手切的。它要满足一个条件：一个需求从提出到落地，牵头的人不超过一个。
所以划法的标准是责任能不能落定，而不是线条好不好看。同一个城市出现两个接口人，协作就会开始打结。
小结片区划分的目标是让责任唯一，不是让地图好看。
跨片区的需求最容易掉在地上，因为每一方都觉得该由别人先动。规则得简单到不用讨论：需求落在哪个片区，就由那个片区牵头，其他片区配合。
客户只需要面对一个牵头人，不用自己把多方凑齐再开会。
小结客户面对的应该是一个牵头人，不是一张组织架构图。
伙伴在最前面接触客户，我们在后面兜交付质量。分工写在前面，配合才不拧巴，客户也不会因为中间多了一层而多等。
判断配合顺不顺，看一个指标就够了：品牌方在关键节点上，是不是直接和做交付的人对话。
小结配合的底线是：中间多了一层，客户不能因此多等一天。
最后一组落在数字上：时效从哪一刻开始算，四小时的承诺到底承诺了什么，交付完的那道关口怎么提前定好。
时效算不准，往往不是运得慢，而是起点算错了。从下单那天算，还是从验收通过那天算，结果能差好几天。
把起点写清楚，双方对同一句话的理解才一致，后面也不会为了“到底几天”反复解释。
小结写不清起点的时效，等于没有承诺。
响应时限说的是“有人接手”，不是“问题解决”。把这句话提前说明白，比含糊地承诺“快速响应”更负责。
真正能兑现的方式也不复杂：第一次回复里就把谁在跟、下一步做什么、什么时候有结论写清楚。
小结响应时限的价值在于可预期，不在于听起来快。
验收标准最好在方案阶段就写下来。等交付完再谈，双方都在凭印象，最后往往变成谁声音大听谁的。
方案里写清看什么、怎么算通过，验收当天就只是走一遍清单，不是重新谈判。
小结验收标准是提前谈好的，不是最后争出来的。
12 章读完，落到动作层面其实只有一份清单。可以先对着它看一遍，再决定下一步找谁。