企业官网建设流程全解析

1. 先别急着怪客户，问题多半出在团队自己身上

“客户天天问进度，团队天天应付”——这个场景做项目的人太熟了。我见过太多项目组，不是在写代码、做方案，而是在回复“进度怎么样了”、“什么时候好啊”、“能不能快点”。团队每天光应付进度查询就耗掉大半天，真正干活的时间反而被挤没了。客户越催，团队越烦，团队越烦，就越不愿意主动同步，客户越得不到消息就越催，一个死循环就这么形成了。

先说一个我踩过无数坑之后总结出来的判断：客户频繁问进度，90%不是客户难缠，而是团队没有建立让客户“不需要问”的机制。客户不是闲得慌，他是心里没底，不知道项目到底走到哪一步了、能不能按期交付、有没有出问题。人一旦心里没底，就会本能地想抓点确定性的东西来缓解焦虑，而“问进度”是最直接、最不需要成本的方式。换个角度想，你自己点外卖的时候，如果骑手一直不点“已送达”，你会不会去刷新配送动态？一个道理。

那团队为什么“天天应付”？因为团队自己也没底。进度是不是真的健康？有没有延期风险？风险都在哪里？很多团队其实根本说不清楚。你说一个项目组，连自己项目当前真实状态都描述不出来，客户来问的时候，就只能东拼西凑回一套“正在推进”、“快了”、“遇到点小问题在解决”这样的话。这些话听一次还行，听十次，客户只会更慌，问得更勤快。所以表面上是沟通问题，底层是项目管理机制问题，再往深挖一层，是团队的进度可见性和目标对齐出了问题。

这篇文章我就想彻底拆一拆这件事。我既聊学院派那套项目管理理论里的有效框架，也聊实战派在日常交付里打磨出来的土办法。你会发现，真正能解决问题的，往往是理论框架和实战技巧结合之后的产物。这不是给项目经理一个人看的，团队负责人、产品经理、研发leader，甚至被客户问怕了的普通执行者，都能在这里找到自己能用的东西。

2. “学院派”项目管理为什么失灵了

2.1 计划赶不上变化，甘特图再漂亮也救不了延期

说到进度管理，学院派最喜欢甩出来的家伙就是甘特图、里程碑计划、偏差分析。逻辑上这套东西没有任何毛病：先拆任务，排日期，定责任人，然后按计划追踪，发现偏差就调整。问题是，这套逻辑默认了一件事——项目环境是相对稳定的，计划本身是可信的。

但真实项目根本不是这样。我在一个交付型项目里见过这样的场景：需求方周一刚确认了一版方案，周四说“老板觉得方向要调整”；研发排了一个星期的工期，结果第三方接口文档迟迟不给；测试刚准备提测，线上突然出了个紧急故障要优先处理。你说这些变化，哪个是甘特图能预判到的？计划画得再细，一变化全得推倒重来，团队每天花在“改计划”上的时间比干活还多。这时候如果还抱着学院派的计划管理流程不放，就等于开着一辆车，前方全是坑，你却在车里反复校准导航地图，而不是盯着路况踩刹车打方向盘。

那学院派的理论是不是就完全没用？也不是。关键在于学院派的计划管理框架适合的是“确定性高、变更少、边界清晰”的项目，比如建筑工程、大型制造业排产，需求在开工前就被锁定了。而我们很多人实际面对的是互联网交付、软件定制、营销活动这类高变化项目，直接把工程管理的打法搬过来，自然处处碰壁。所以第一步要承认：不是理论错了，是场景不匹配。

2.2 汇报机制变成形式主义，是团队学会“应付”的开始

学院派还有一个典型产物，就是周报和定期汇报。理论上定期同步进度没问题，但实际上几乎每个团队都会把它跑偏成形式主义。我见过最极端的例子，某项目周报模板有十多个字段，要填完成度百分比、风险等级、偏差原因、下周计划、资源占用、依赖项状态……每个字段还要写一大堆备注。团队每周四下午啥也不干，全在编周报。

更要命的是，这种周报填完发给客户之后，客户该看不懂还是看不懂。“完成度80%”是什么意思？是功能做完了80%，还是时间花了80%，还是工时消耗了80%？客户看到这种数据，非但不能安心，反而会产生更多疑问，然后就跑过来问。团队一看，我周报都写了你还来问，你这客户真难伺候。其实客户想问的是“那剩下的20%什么时候能好”，而周报里没写，或者说写得太含糊。这个信息差，就是双方互相觉得对方有问题的根源。

学院派还特别喜欢提“透明”——让所有干系人看到项目状态。方向没问题，但落地方式很成问题。你扔一个共享表格给客户，里面全是专业术语，什么“Sprint Burndown”、“Blocked Issue”、“SLA”，客户看一眼就懵了。透明不是你提供了信息就叫透明，而是对方不需要额外解释就能理解，这才是透明。所以后来我把汇报机制整个重做了一遍，核心原则就三条：频率要比客户问的更高、内容要比客户想知道的更具体、表达要比客户的理解成本更低。后面我会详细展开到底是怎么做的。

2.3 工具选了一堆，反而成了团队的新负担

学院派思维还有一个惯性，就是一上来先选工具。项目管理软件买一套、协同文档开一个、IM群拉二十个、看板建八块，听起来很正规，实际效果呢？团队每天要花大量时间在工具之间来回切换，更新状态、挪卡片、写评论。状态还没同步完，客户已经在IM上直接问了——“这个功能到底做了没？”于是工具里的状态成了摆设，IM里的口头回答才是真进度。

我见过一个团队特别夸张，项目进度数据散落在四五个地方：甘特图里有一份、看板里有一份、共享表格里有一份、聊天记录里还有一份。四份数据经常对不上，有一次给客户汇报时，他们自己都发现甘特图上的日期和看板上的截止日不一样，场面非常尴尬。

后来我总结出一个原则：工具不是越多越好，而是“能在一个地方看到全貌的地方，绝不超过两个”。而且工具是为人服务的，不是人为工具服务的。如果一套工具需要团队额外付出大量维护成本，那它就应该被砍掉。后面我在实战部分会讲，我们最后是怎么把一个项目的进度管理体系收敛到“一张表+一个群”的，效果反而比之前那一堆工具好得多。

3. 实战派破局：把“客户总在问”变成“客户不用问”

3.1 核心思路：不是管住团队，而是管住客户的“不确定性焦虑”

聊完了学院派为什么失灵，接下来讲实战派怎么干。我先给一个核心判断：客户天天问进度，本质上不是管理问题，是心理学问题——不确定性引发的焦虑。人类对不确定性的容忍度天然很低，一旦感到失控，就会用各种方式来抓取确定性。客户问进度，就是他在“抓确定性”。

所以实战派的破局思路也跟着变了：不去管团队怎么“应付”客户，而是想办法从根上消除客户对项目的不确定感。客户之所以不确定，是因为他看不到项目走向、不知道下一阶段会发生什么、不知道问题被处理得怎么样。那我们就给他一双“眼睛”，让他随时能看到项目最真实的样貌。当客户随时都知道项目在推进、有风险在暴露但有人管、下一周会发生什么，他就没有再问的必要了。

这个思路听起来简单，但落地的时候有一个容易做歪的地方：有人会把“给客户看”理解成“给客户看好的”。报喜不报忧，隐藏风险，美化进度，这路走不通。客户又不傻，他问两次发现你在粉饰太平，接下来的手段就不是发消息问进度了，而是升级投诉、半夜打电话、越过项目对接人直接找老板。真正能让客户放心的是什么？是他发现你连坏消息都敢主动告诉他，而且告诉他的时候还带着解决方案。这种透明感和掌控感，比一百句“一切顺利”都管用。

3.2 把交付目标拆到让客户“看得见摸得着”为止

光有思路不够，还得有具体的抓手。我每次接手一个新项目，第一件事就是拉着团队把交付目标重新拆一遍。很多项目不是没有目标，而是目标太大、太抽象、太遥远，客户看着那个大目标，心里完全没概念。

举个例子。我之前做过一个企业内部管理系统项目，合同写的交付物是“完成供应链管理模块”，客户负责人每天问“模块好了没”。团队没法回答，因为“供应链管理模块”拆开有采购、库存、供应商、对账、报表五六个子模块，有的在做、有的还没排上。这种时候你让团队怎么回？只能说“在推进”。客户听完更焦虑了，因为“在推进”没有信息量。

后来我做的事，说白了就是把大象装进冰箱的步骤亮出来。我把“供应链管理模块”拆成了三层颗粒度：第一层里程碑，比如“需求确认”、“开发完成”、“测试通过”、“上线验收”；第二层是当前的冲刺任务，比如“这周完成库存模块的采购入库接口开发”；第三层是更细的任务项，比如“周三前完成接口联调”。拆完之后，我把这张拆解图直接同步给客户，他一看就明白原来是先做采购再做库存，这周在做接口。下次再问，他会直接问“接口联调好了吗”，而不是问“模块好了没”。问题变具体了，回答也就不再是空话，双方都舒服。

拆解这件事还有一个隐藏的好处：团队内部的目标感也会变清晰。很多时候团队自己都在疲于应付，也是因为目标太模糊。你把目标拆到具体可执行、可验证的程度之后，每个人都知道自己今天要交付什么、做完什么算完、对整体进度有什么贡献，干活的心态会完全不一样。

3.3 “主动汇报比被动回答省钱”这个账，算一笔就懂

很多团队不愿意主动向客户同步进度，觉得没必要、太麻烦、客户也没要求每天汇报。这个想法我特别想纠正一下。你算一笔账就明白了：被动回答的代价是隐形的，但一点都不便宜。

客户每来问一次“进度怎么样”，他是在打断你的工作节奏，你要停下手头的活去组织信息、回复消息。一个客户一天问三次，每次打断你15分钟，一天就是45分钟，一周就是将近4小时。这还只是你一个人的损失，如果这个客户同时问了项目经理、产品经理、技术负责人各一遍呢？三个人各花15分钟，团队一周就在“回复客户”这件事上丢了十几小时。更惨的是，回复完之后工作状态被打断，重新进入深度专注又需要时间，这个损失根本没法量化。

反过来算主动汇报的账：每天花十分钟给客户发一条简短、结构化的进度消息，把今天的完成事项、明天计划、当前风险和需要客户决策的问题写清楚。客户一看，哦，今天有进展，明天有安排，有一个风险但有人管着，还有一个问题需要我拍板。他心里有底了，自然就不来问了。每天十分钟，换来的是全团队一天的安静，这笔账怎么算都划算。

我见过很多团队不做主动汇报的另一个心理障碍是“没什么好报的”——今天没干什么大事，总不能硬凑吧。我教大家一个办法，把进度汇报从“成果导向”改成“状态导向”。没干大事也肯定有状态变化：外部依赖在等接口、内部在做代码走查、昨天下班前发现一个问题正在定位根因。这些都是信息，都是让客户觉得“一切在掌控中”的素材。你不需要每天都有惊天动地的进展，你只需要让客户每天都知道“项目没死，在往前走”。这就够了。

4. 实操落地：一套用了三年、被客户追着夸的进度同步方案

4.1 方案总览：一张同步表 + 三类角色 + 四条消息

理论聊完，落到实操。这套方案我管它叫“信任型进度同步方案”，核心是把常规的“客户来问我们答”改成“我们主动给客户铺信息”。整个方案由三部分组成：一张给客户看的同步表、三类角色的分工、四条固定的消息节奏。

同步表是核心载体，但它不是给客户一个编辑权限的共享文档，而是我们内部维护、每天自动/手动更新、然后导出发送或共享链接给客户看的“一页纸看板”。这一页纸上只放五块内容：当前里程碑、本周目标、今日进展、当前风险（含应对措施）、需要客户决策的事项。字段就这五个，多一个都不要。每行字必须短到客户扫一眼就能看懂，禁止术语，禁止含糊词。

三类角色分别是：项目负责人（统筹整体进度、对外汇报、风险预警）、交付执行人（更新任务状态、标记阻塞、上报风险）、客户联络人（定期从同步表中提取信息，以统一渠道发给客户）。小团队可能一人兼任多角，但职责必须分开，尤其是“对外汇报”这件事，一定要指定唯一出口，否则不同人说出不同口径，客户马上就会对团队的专业性打问号。

四条消息节奏是我踩坑踩出来的：每天早上10点前发“今日计划”（今天做什么）、每天下午6点发“今日进展”（今天做完了什么、有没有风险）、每周五发“本周总结与下周计划”、里程碑节点发“阶段性验收报告”。其中前两条是重中之重，只要这两条坚持住了，客户再来问进度的频次至少能降一半。

4.2 每日同步消息怎么写、什么时候发、发到哪里

写每日同步消息是这套方案里最核心的动作，也是大多数人做不好的地方。很多人把进度同步写成了工作汇报，一大堆字，看着像公文。我说一个判断标准：你发的消息如果超过手机一屏，就太长了，客户大概率不会看完。客户要的不是信息量，而是安全感和掌控感。

我给大家一个我打磨了很久的模板，每天直接套用。

【项目名】X月X日 进度同步 今日完成：A功能接口联调、B页面UI走查（2项，延迟1项） 明日计划：C模块代码评审、D环境部署 当前风险：第三方支付接口文档延迟，预计影响1天，已在协调 需要您决策：验收标准里“批量导出”的格式，是用Excel还是CSV？麻烦今天确认。 ——有事随时找我，20分钟内响应。

这条消息的信息密度很高，客户一看就知道：今天做了啥、做完了没、有没有问题、有没有需要他拍板的事、找谁问。五个问题全部在一条消息里解决，他还有什么理由再来追问？

发布时间也有讲究。早上那条建议10点前发，太早团队自己都还没进入状态，报出来的计划可能就是拍脑袋；太晚客户已经开始焦虑了。晚上那条建议6点左右发，既能看到当天完整的进展，又不至于拖到客户下班了才打扰。时间段选对了，客户体验会好很多。

发到哪里也有门道。我建议拉一个专门的项目同步群，客户方把所有相关的人都拉进来，我方只需要项目负责人和客户联络人在群里。这个群只做同步，不闲聊、不讨论、不解决问题，所有讨论性内容都拉到另一个“项目协作群”里。这样客户翻聊天记录的时候，看到的全是干净整齐的进度消息，体验感极好。

4.3 风险暴露机制：客户最怕的不是有风险，而是风险“被藏起来”

这个方案里我要拿出来单独讲的，是风险暴露这件事。很多团队不敢跟客户讲风险，怕讲了显得自己不行，怕客户焦虑升级。我的观点恰恰相反：客户最怕的从来不是项目有风险，而是风险被藏着掖着，最后在某个节点猝不及防地爆出来，搞得大家都很难堪。

想一想，你自己是不是也这样：项目出了问题，第一反应是“再撑一撑，可能明天就好了”。结果撑了一周没撑住，问题还是被客户发现了，这时候客户的愤怒程度会翻倍。他愤怒的不是问题本身，而是“你为什么不早告诉我”。我遇到太多客户，在交付质量还行的项目上暴跳如雷，原因就一条，他觉得团队骗了他。信任一旦破裂，你说什么都像在找借口。

所以这套方案里，所有风险都要在同步表里占一个固定位子。我的原则是“有风险必报、有影响必说、说的时候必带方案”。比如接口延迟了，不是说“第三方接口延迟了”就完了，而是要说“第三方接口延迟预计导致整体延期1天，我们已经和对方约了今天下午加急沟通，同时并行做了内部任务的重新排布，尽量把影响压缩在1天内”。客户听完这个，第一反应不是责怪，而是觉得这个团队靠谱，有掌控力。你连坏消息都在主动管，他还有什么不放心的。

4.4 从“日报周报”升级到“里程碑验收”，让交付有仪式感

每日同步和每周总结是用来维持日常信任的，但真正能让客户记忆深刻的，是里程碑节点上的“验收时刻”。很多人只会在项目最终交付的时候做一次验收，中间过程从不做。这就导致客户对项目中间段的印象是模糊的，而你每天发的那些日报，对他来说可能看完就忘了。里程碑验收不一样，它像一个路标，让客户清晰地意识到“这一段交付完成了，下一段要开始了”。

我做里程碑验收的时候有一个固定动作：提前三天预约会议，会上由项目负责人逐条演示已完成的功能，客户当场体验，现场答疑，最后双方签一个简短的验收确认记录。确认记录不用多复杂，就三行：本次验收了什么、验收结果如何、遗留问题清单。这个东西的法律效力不太重要，但在心理层面上非常关键——客户亲手确认“这一步过了”，他的掌控感会大大增强，同时也为后续可能出现的范围蔓延提供了依据。

再说一个细节：里程碑验收不只是给客户看的，也应该是给团队看的。团队辛苦干了一个月，连个“阶段性成果确认”都没有，很容易产生“干了也白干”的倦怠感。里程碑验收时，我会在会议上把团队的贡献和成绩摆在客户面前，让客户当面说一句“你们这阶段做得不错”。这句话对团队士气的正向作用，比发奖金有时候都管用。

4.5 工具收敛：为什么我用“一张共享表”替代了一整套软件

前面我说了学院派的工具依赖症问题，这里展开聊聊我们实战派最后的工具收敛结果。一个项目，团队和客户的进度沟通，最终收敛成了一张共享在线表格加一个同步群，这俩就够了。

共享表长这样：顶部是项目基本信息（项目名、客户对接人、我方负责人、当前里程碑），下面是五列核心字段——里程碑/任务项、计划完成日期、当前状态（未开始/进行中/已完成/有风险）、风险说明与应对、负责人。每一行对应一个可交付的小任务，颗粒度控制在“两周内能完成”的水平，太细了维护成本高，太粗了客户看不到细节。这张表每天早上更新一次，由各任务负责人更新自己的行，项目负责人巡检一遍后，把链接发给客户。客户想看任何时刻的项目全貌，打开表就有，不用问任何人。

有人会问，那些专业的项目管理工具不也有类似功能吗？有，而且功能更强。但问题在于，功能越强意味着维护成本越高，而你让一个满负荷的研发团队每天去维护一套复杂工具的状态，现实吗？共享表格的布点就在于极低的使用门槛：会打字就会更新，打开就能看，不需要学习成本。实际上表格工具做得好的话，还能保留修改历史，功能并不弱。工具这个东西，永远是“用起来才行”，藏在系统里没人在乎的进度的更新，不如一张团队每天都在维护的表格有生命力。

5. 避坑指南：这套方案在真实项目里容易踩的五个坑

5.1 汇报内容过度美化，客户感受不到“真实感”

这套方案刚在一个团队推行的时候，最容易出现的问题是团队把每日同步写成了“功劳簿”。今天明明只完成了一个小功能，非要把措辞包装成“核心模块取得突破性进展”；明天计划明明只有两件事，为了实现“今日计划”的丰富感，硬凑了五件根本排不上的事。客户前两周还觉得挺好，第三周开始就不对劲了，因为他发现“突破性进展”了好几次，项目进度却没什么实质性变化。

真实感的建立，远比“看起来很好”重要。我后来在团队里立了一个规矩：每天同步消息里的“今日完成”，必须做到“可被验证”，就是客户只要打开系统或看一个截图，就能确认这个事确实做了。完成的事就写完成了，没完成的事就写“在推进中，预计明天完成”，风险就摆在那，不用遮掩。当客户发现你写的每一句话都能被核实，他对你所有的话都会加信任分，这个信任资产是任何话术都换不来的。

5.2 客户决策不及时，风险变成“我们背锅”

这套方案运行顺畅之后，会遇到一个新的问题：客户觉得项目很透明，他就会对信息里的“需要您决策”事项产生一点拖延心理，总觉得“你们已经管得这么好了，我晚两天回复也没事”。这个心态带来的后果是，很多任务的阻塞责任从客户自己那里开始累积，最后延期了，客户却觉得是团队没做好。

这个问题我在项目里处理过很多次。最有效的办法是在同步消息里给决策项加一个“截止时间”。不写“麻烦尽快确认”，而是写“麻烦在今天下午6点前确认，如果届时未回复，我们将按方案A继续执行，事后支持返工”。这个写法既给了客户压力，又显得团队很专业、很有掌控力。只要这个规矩立住了，客户就会知道“这个团队的决策项是真不能拖”，后续配合度会好很多。当然，执行这个规则要注意语气，不能变成威胁，而要表达成“为了不影响您的交付时间，我们预先设了一个兜底方案”。

5.3 同步流于形式，坚持两周就名存实亡

这套方案看起来简单，执行起来其实有门槛，最大的门槛就是坚持。前两周热情还在，大家每天准时更新，第三周开始有人忘了发，第四周变成“想起来才发”，第五周客户又回到天天问进度的状态。我见过太多团队死在这一步，包括我自己带的团队，第一次推行时也差点翻车。

后来我反思清楚了一件事：每日同步不是靠自觉维持的，是靠机制维持的。机制怎么定？我做了三件事：第一，把同步时间固化到日程表里，每天10点和18点的闹钟一响，全员有意识停下手里的事先报状态；第二，把更新同步表变成任务负责人的“当日最后一件事”，没更新不算下班；第三，项目负责人每天巡检同步表，发现缺漏当场在群里@提醒，连续缺三次的，一对一聊一次。这三板斧下来，两周之后大家就形成了肌肉记忆，反而觉得不更新浑身不舒服。习惯的力量，比意志力靠谱得多。

5.4 一个项目多个对接人，口径混乱导致客户更加焦虑

有些项目客户方不止一个对接人，有的管业务，有的管技术，有的管行政汇报。如果不做统一管理，你每天的同步发在群里，不同人看了产生不同理解，就会分别来问。这等于你每天同步了，客户问的次数反而多了，非常挫败。

对付这种情况，我的做法是：在项目启动的第一周，就和客户方负责人确认一个“信息接收人”。每天同步消息只发给这个人，其他人要看就让这个人转达。同时每周的总结抄送给客户方的决策层，让高层有全局感又不至于陷入细节。这个机制的好处是，客户方内部的信息流转由他们自己负责，而不是让你一个外来者分别面对七八个人。再加上同步表链接可以分享给所有需要看的人，大家如果想看细节，自己打开表就行，不需要来问你。这样“表负责细节，人负责重点”，各归其位。

5.5 把“同步”当“沟通”，该有的当面交流反而省了

最后一个坑，也是最容易被误解的一个：这套方案做得好，客户不怎么问进度了，团队就容易觉得“万事大吉”，连每周电话会、阶段碰头会都开始想省掉。其实同步消息解决的是“信息对称”问题，它替代不了面对面的深度沟通。有时候客户说“进度没问题了”，但话里还有没说完的意思，比如对某个交互细节不满意、对验收标准有疑虑、对某个功能的优先级有自己的想法。这些东西，光看文字消息是看不出来的，必须当面聊。

我把两种沟通的分工总结成一句话：“文字同步保日常，见面沟通解疑难。”日常同步消息负责让客户安心，定期的电话会/视频会负责挖掘更深层次的诉求和风险。尤其是项目进入关键阶段、双方对某个设计有分歧、或者客户方的内外部环境发生变化时，一定要主动约一个多方会议，面对面把问题摊开说透。这套打法配合起来，项目推进才会真正顺滑，客户满意度也会持续保持在比较高的水平。

6. 从“应付式回答”到“信任式协同”，差的不是能力而是机制

做了这么多年项目，我越来越确信一件事：客户天天问进度的时候，往往是这个项目最有救的时候，说明他还愿意问、还在关注、还对交付有期待。真正危险的是客户问都懒得问了，直接把不满反馈到商务层面或者高层那里，那才是真正的危机。所以“客户天天问”不是项目失败的信号，而是项目沟通机制失效的信号，抓住这个信号去重建机制，反而能把客情关系做得比那些“客户从来不过问”的项目更铁。

这套信任型进度同步方案，看起来只是改变了“发消息”的方式，本质上改变的是你们和客户之间的权力结构。以前的模式是客户掌握着“问的权利”，你掌握着“答的义务”，一问一答之间，双方地位天然不对等，客户永远在审视你，你永远在防守。现在的模式是你主动把信息铺到他面前，他不需要问，你也不需要答，双方的关系从“审查与被审查”变成了“协同与共担”。这个微妙的转变，会让整个项目的氛围完全不一样。

说实话，这套方案刚开始推的时候，我自己也带着抵触情绪，觉得“天天给客户写小作文”太卑微了。但当我发现，同样的团队、同样的项目难度，客户从每天问三次变成一周只问一次，从“你能不能给我个准信”变成“你们办事我放心”的时候，我才意识到，这根本不是卑微，这是专业。让客户带着安全感工作，是一种被低估的交付能力。

最后我分享一个实操中总结的小技巧：只要你把每天的同步消息坚持发满21天，客户的问询频率一定会出现肉眼可见的下降。前面我的体会是，这个时间点恰好是客户建立“不看消息也安心”习惯的临界点。过了这个坎，后面你会轻松非常多。你与其每天被客户追着问、挤出时间组织那些含糊其辞的回复，不如每天花十多分钟主动打好这条消息。这笔投资，稳赚不赔。