《代码之外程序员重启人生》· 第05篇上一世他连续加班两个周末项目仍然延期。复盘会上却有人说“研发团队的投入度还不够。”周五下午五点四十二分。距离下班还有十八分钟。办公室里已经有人开始收拾桌面有人关掉测试环境有人在群里讨论晚上吃什么。林川刚提交完最后一个合并请求。订单查询优化已经完成压测结果也符合预期。他合上笔记本正准备去接一杯水项目群突然弹出一条全体成员的消息。项目经理周凯接业务通知积分商城项目必须提前到下周一上线。时间比较紧请研发、测试和产品周末全员投入大家要有主人翁意识共同保障重点项目顺利交付。消息下面很快出现一排回复。收到。没问题。全力配合。大家一起加油。赵明转过椅子看了林川一眼。“周末又没了。”前端同事苦笑“我刚订了明天回家的票。”测试负责人在群里问周末具体怎么安排需求范围是否已经确认周凯没有回答。他又发了一句先把困难放一放想办法把事情做成。今晚七点开紧急启动会所有人参加。林川盯着“主人翁意识”五个字。他记得这个项目。上一世他就是从这条消息开始连续加班了两个周末。第一个周末研发团队完成了积分商品、库存、兑换订单和优惠券发放功能。到了周一业务提出积分需要支持冻结和过期。周二产品补充了组合兑换。周三领导又要求增加实物物流和退款流程。第二个周末所有人继续加班。上线前一天第三方物流接口仍然无法稳定调用测试环境的数据也没有准备完整。项目最终延期了一周。复盘会上周凯说项目过程中各团队的投入还不够坚决。特别是研发面对紧急任务时缺少主人翁意识。没有人提需求连续变更。没有人提外部接口延期。也没有人提两个周末二十多个人连续加班。所有不可控问题最后都被归纳成一个人的态度问题你还不够拼。上一世林川在复盘会上听到这句话时只觉得荒谬。但他没有反驳。因为没有人愿意在领导面前承认加班也解决不了一个没有范围、没有资源、没有决策机制的项目。这一世同样的消息再次出现在屏幕上。林川没有回复“收到”。他打开项目需求文档。文件一共十二页。其中三页是项目背景两页是领导讲话截图四页是页面原型。真正涉及业务规则的内容不到两页。项目上线时间写得非常清楚下周一。但上线范围没有写。负责人没有写。验收标准也没有写。林川拿出自己的工作记录在新的一页写下三个问题第一谁有权决定范围第二谁能调配资源第三项目完成后谁获得对应收益如果三个答案都不是你那么对方要求的很可能不是主人翁意识。而是希望你承担主人翁的责任却只保留员工的权限和收益。一、所谓“主人翁意识”为什么总在下班前出现晚上七点。紧急启动会准时开始。会议室里坐满了人。周凯站在投影屏幕旁脸上带着一种重点项目特有的严肃。“大家应该都看到群消息了。”“积分商城是业务部门本季度的核心项目原计划月底上线现在领导希望提前到下周一。”“时间虽然紧但这也是体现团队战斗力的时候。”他说到这里环顾会议室。“我希望大家不要计较个人得失要有主人翁意识。”林川看了一眼时间。七点零五分。程序员都知道一条规律凡是需要你放弃周末的项目通常会先要求你放弃计算成本。只要开始计算就显得不够团结。只要提出风险就显得缺少担当。只要问为什么突然提前就会得到一句这是业务需要。最后所有具体问题都会被一个抽象概念压住主人翁意识。可一个真正的主人翁可以决定做什么、不做什么。可以控制预算。可以安排人员。可以选择上线时间。也能分享项目成功后的收益。而大多数被要求拥有主人翁意识的程序员能够决定的事情只有一件今晚几点下班。有时连这一件也决定不了。周凯打开任务列表。“产品今晚把需求再过一遍。”“研发从明天开始开发周日晚上完成联调。”“测试周日晚开始执行核心用例。”“下周一上午验收下午正式上线。”测试负责人抬起头。“周日晚才开始联调测试时间只有半天”周凯说“重点流程先测其他问题上线以后再迭代。”前端负责人问“现在原型还是昨天的版本吗”产品经理回答“整体不变但业务刚刚补了几个规则今晚会更新。”后端同事问“积分、库存和订单数据从哪里来”产品经理看向业务负责人。业务负责人说“积分数据有接口库存可能先从现有商城同步订单部分还需要再确认。”林川靠在椅背上。和上一世一模一样。上线时间已经确定。需求还没有确定。技术依赖也没有确定。项目计划却精确到了周一下午。周凯问“大家还有没有问题”会议室安静下来。很多人有问题。但没人愿意成为那个在所有人准备表态奋斗时说“这个计划不成立”的人。林川抬起手。“我有三个问题。”周凯看向他。“你说。”“第一个问题这个项目下周一必须上线的具体原因是什么”周凯皱了皱眉。“业务领导已经定了时间。”“我问的是业务原因。”“是有活动吗已经对外发布了吗还是存在合同节点”业务负责人回答“下周一要向集团领导做阶段成果展示。”林川点头。“所以真正不能变的是展示时间不一定是完整生产上线时间对吗”会议室里几个人同时抬起头。业务负责人停了一下。“领导希望看到系统能用。”“演示环境可用和生产环境全量上线是两个不同目标。”“如果目标是下周一展示我们可以优先保证演示闭环。”“如果目标是生产上线就需要完整测试、数据准备、监控和回滚方案。”周凯打断他。“林川现在不是讨论概念的时候。领导要看的是成果。”林川平静地说“正因为要交付成果才需要先确认交付的是演示版还是生产版。”“这会直接决定周末需要完成的工作范围。”业务负责人看向周凯。“这个确实要分清楚。”周凯没有继续反驳。“那就按生产可用的标准准备至少核心流程要能真实运行。”林川点了点头。“好这是第一个答案。”“第二个问题当前版本范围由谁最终确认”产品经理说“产品和业务共同确认。”“需求变更由谁决定是否进入本次上线”“也是我们讨论。”“如果周末增加需求研发是否有权拒绝”产品经理下意识说道“要看需求重要程度。”林川看向周凯。“也就是说研发承担下周一上线的结果但没有控制上线范围的权限。”周凯脸色沉了下来。“不是没有权限是大家共同协商。”“共同协商最后由谁拍板”没有人回答。林川没有继续逼问。他翻到下一页。“第三个问题为了提前上线公司增加了哪些资源”周凯说“所有人周末全员投入。”“除了现有团队加班还有新增研发、测试或外部支持吗”“目前没有。”“原有任务是否暂停”“大家先协调。”“加班后是否安排调休”“先把项目做完再说。”“项目提前上线带来的业务收益会不会进入团队奖励”会议室突然安静下来。有人低下头。有人忍不住抬头看林川。周凯的语气明显冷了。“你问这个是什么意思”林川回答“没有别的意思。”“只是需要确认这次提前上线究竟是公司通过增加资源完成还是由现有团队通过牺牲个人时间完成。”“如果是后者就应该明确牺牲多少、如何补偿以及哪些原任务需要调整。”周凯盯着他。“林川现在是关键时刻。不要什么事情都先谈条件。”林川笑了一下。“项目管理本来就是管理条件。”“没有条件只有口号最后无法形成可执行计划。”二、当你提出成本有人就会开始谈格局会议室里的气氛变得有些僵。周凯把翻页器放到桌上。“我说得直接一点。”“公司给大家提供平台遇到紧急项目时每个人都应该有基本的责任感。”“不能平时只关注自己的任务一到需要付出的时候就开始计算得失。”这段话听起来很有力量。也很容易让人产生羞耻感。好像你问调休就是没有责任感。问范围就是缺少大局观。问资源就是只会讲困难。很多程序员面对这类表达会立刻后退。因为技术问题可以用数据讨论。道德问题很难自证。你越解释越像是在证明自己确实不愿意付出。上一世的林川也曾经被这种话击中过。他会想是不是自己真的太计较别人都愿意加班为什么自己要提出这些问题团队遇到困难时难道不应该共同承担吗后来他才明白真正的团队困难当然可以共同承担。但你至少需要知道自己承担的究竟是意外还是管理者长期把计划失误转化成个人义务。林川看着周凯。“我愿意为真正的紧急情况加班。”“线上事故、客户故障、不可预见的生产问题我都可以第一时间处理。”“但这次项目提前是因为汇报时间变化不是系统突发故障。”“这种情况应该先调整范围、资源和计划而不是默认所有人放弃周末。”周凯问“那你认为应该怎么办”林川打开电脑把一张表投到屏幕上。“我给三个方案。”方案一下周一完成领导演示范围仅包含积分余额查询商品列表单商品兑换兑换结果展示使用独立演示环境和准备好的测试数据。不连接真实库存、物流和退款流程。周末需要产品、两名前端、两名后端和一名测试参与。可以保证演示效果但不能直接面向真实用户。方案二下周一灰度上线核心功能在方案一基础上接入真实积分接入有限商品库存完成基础订单增加监控和回滚需要冻结需求。原有项目任务全部暂停。第三方接口人员周末在线支持。测试至少需要一天半。存在一定风险只建议内部员工或白名单用户使用。方案三月底正式上线完整版本按照原计划完成积分冻结与过期多商品兑换物流状态退款退积分库存补偿异常订单处理完整测试与灰度风险可控不需要团队连续透支。林川说“如果下周一的目标是领导展示选择方案一。”“如果一定要产生真实订单可以选择方案二但需要接受范围限制和灰度风险。”“如果要求完整生产上线就只能选择方案三。”周凯问“能不能大家再努努力下周一把完整版本一起上线”林川回答“不能。”这两个字说得很平静。没有愤怒。也没有犹豫。会议室里安静了几秒。上一世他从来不敢这样回答。他总会说我们尽量。可“尽量”是一个非常危险的词。在说出口的人那里它代表我会努力但不能保证。在听到的人那里它常常代表他已经答应了。等到没有完成时大家不会讨论当初的条件。只会问不是说尽量保证吗这一次林川不准备再用模糊语言签下明确责任。业务负责人看着屏幕上的三个方案。“如果做方案一领导能看到完整流程吗”“可以看到从查询积分到兑换成功的完整主流程。”“后续真实上线会不会全部推翻”“不会。核心代码可以继续复用只是先用模拟库存和演示数据替代外部接口。”“那我觉得可以。”产品经理也说道“方案一的范围今晚能够确认。”测试负责人松了一口气。“如果只是演示闭环我们可以周日白天开始测试。”周凯的脸色并不好看。但当业务负责人已经接受方案一时他也无法继续要求完整上线。最后他说道“那先按演示版推进但大家还是要全力投入。”林川补充“需要再确认参与人员和周末时间。”周凯看着他。“你还有什么问题”“不是所有人都需要全程在场。”“根据任务产品今晚确认规则。”“研发周六开发测试周日介入。”“没有任务的人员不需要到办公室待命。”“另外周末工作需要在下周安排调休原定任务同步顺延。”周凯问“调休到时候再说不行吗”林川回答“现在不确认项目结束后通常就没有合适时间。”会议室里有人笑了一声又迅速忍住。业务负责人说道“调休按公司制度执行原任务一起调整这个没问题。”周凯只能点头。那一刻会议的讨论终于从“大家要拼”变成了谁做什么。什么时候做。需要付出什么。付出后如何补偿。项目第一次从一条激昂的群消息变成了一个可以执行的计划。三、真正让人愤怒的不是偶尔加班会议结束后赵明跟着林川走出会议室。“你刚才太猛了。”林川问“哪里猛”“当着业务领导的面问有没有奖励。”“我只是问项目资源和补偿。”赵明压低声音。“大家心里都知道但没人会这么直接问。”林川笑了笑。“所以大家心里都不满意表面上还要回复全力以赴。”两人走进电梯。赵明靠在墙上。“其实我也不是完全反对加班。”“项目真出问题了谁都不会不管。”“但最难受的是每次都是周五快下班才通知。”“然后告诉你这是紧急任务。”林川点头。程序员真正反感的通常不是所有加班。线上发生严重事故时很少有人会在系统崩溃后说现在下班了周一再处理。大家会主动查问题恢复服务。因为那是一个真实、明确、无法提前预见的紧急情况。真正消耗人的是另一类加班需求早就存在只是没人提前规划。领导临时改变想法却要求团队承担全部后果。外部部门延期最后让研发用周末追回进度。项目时间不足却不愿意缩减范围或增加资源。这种加班不是在解决意外。而是在替管理问题付费。更让人难以接受的是个人付出了周末、健康和家庭时间。项目完成后却很少有人记得这些成本。成功了是领导决策正确、团队有战斗力。失败了是员工投入不足、缺少主人翁意识。所谓主人翁常常只在承担责任时出现。到了分配权限、收益和荣誉时大家又会提醒你要服从公司安排。电梯到了一楼。赵明问“你不怕周凯以后针对你”林川走出电梯。“怕。”“那你还说”“因为上一世我什么都没说他也没有因此更尊重我。”赵明没有听懂“上一世”。以为他只是在打比方。林川也没有解释。他只是突然明白沉默从来不能购买安全。它最多只能把冲突延期。而被延期的冲突往往会以更高的成本重新出现。四、周六早上他第一次没有看到整个团队坐满办公室周六上午九点。林川来到公司。办公室里只有七个人。产品经理、两名前端、两后端、测试负责人和周凯。没有行政。没有与项目无关的研发。也没有被要求来办公室“随时待命”的人员。上一世同样的周六整个部门几乎全员到场。很多人没有明确任务只能坐在工位上等待。有人刷了一天文档。有人每隔半小时问一次有没有需要支持的事情。到了晚上所有人还要在群里汇报今日全力支持重点项目。看起来声势浩大。实际产出却没有增加多少。管理者很容易把“办公室坐满人”当成投入。但软件开发不是搬砖。不是人越多、工作时间越长产出就一定越高。一个范围模糊的项目里增加更多人往往只会增加沟通成本。林川打开任务看板。所有工作已经拆分清楚。产品经理负责冻结流程和页面字段。前端负责商城页面和兑换交互。林川负责积分、商品和订单接口。赵明负责演示数据和结果页。测试负责人下午开始准备测试用例。周凯坐在会议室里定期查看进度。上午十一点产品经理走过来。“业务又想加一个兑换记录页面。”林川问“下周一演示必须用吗”“领导可能会问。”“‘可能会问’不等于必须开发。”产品经理有些为难。“做一个简单列表应该不复杂。”赵明在旁边听到这句话抬起头。“先别说简单。”“上次我说导出简单最后改了两天。”办公室里几个人笑了起来。林川也笑了。“可以准备一个静态演示页面。”“正式查询接口放到后续版本。”产品经理问“为什么不直接做接口”“接口不只是查询。”“要考虑分页、数据权限、状态展示和异常订单。”“今天加入会占用核心兑换流程的联调时间。”“如果业务确认比兑换主流程更重要我们可以调整。”产品经理想了想。“那还是先做静态演示。”需求就这样被控制住了。没有争吵。也没有人说研发不配合。当新增需求必须明确替代哪项工作时很多“顺便做一下”的功能都会突然变得不再重要。五、项目经理试图再次扩大范围周六下午四点。核心流程已经可以跑通。业务负责人来看演示。看完以后很满意。“整体效果不错。”“要是能把真实物流状态也展示出来就更完整了。”周凯立刻说道“物流接口应该可以接一下。”他说完看向林川。“你评估一下今晚能不能完成”办公室里安静下来。上一世林川一定会先打开接口文档。然后估算最理想情况下的开发时间。如果四小时能够完成他就会觉得自己没有理由拒绝。最终工作常常拖到深夜。这一世他没有看接口文档。而是先问业务负责人“下周一展示中物流状态是核心验收项吗”对方说“不是必须但有会更好。”“那建议不加入当前版本。”周凯说道“接口如果简单顺手接上也不会影响太多。”林川看向他。“项目启动会已经确认新增范围必须重新评估。”“现在核心流程刚完成还没有开始完整测试。”“物流接口不是当前目标。”周凯皱眉。“大家今天都在可以多做一点。”林川问“多做一点的边界是什么”“接完物流以后如果业务再提出退款状态我们是否也继续加”“如果每个需求都只需要多做一点最终为什么还需要版本范围”周凯明显不耐烦了。“你现在怎么做什么都要讲规则”林川回答“因为没有规则的加班最后通常只会制造更多加班。”业务负责人看了看两人。“物流先不加核心流程稳定最重要。”周凯没有再说话。林川回到工位。他知道周凯并不是不知道范围管理的重要性。只是对管理者来说让团队多做一点短期看几乎没有成本。真正支付成本的是开发人员的时间。如果额外需求成功他可以获得更完整的展示效果。如果导致延期也可以解释为研发执行不够。这是一笔对决策者极其有利的交易。除非承担成本的人主动把成本摆到桌面上。六、晚上九点周凯在群里发了一段“感谢”周六晚上八点四十分。核心功能完成第一次联调。测试负责人确认没有阻塞性问题。按照计划大家可以结束当天工作。周凯在项目群发了一段话感谢大家今天的辛苦付出。重点项目考验的是团队凝聚力和责任意识事实证明只要大家目标一致没有克服不了的困难。希望明天继续保持状态全力保障周一顺利交付。下面很快出现几个点赞表情。林川看着这段话。内容听起来没有任何问题。但它再次把一个具体项目抽象成了态度叙事。项目为什么能顺利推进不是因为“没有克服不了的困难”。而是因为把生产上线改成了演示交付冻结了需求范围没有让无关人员到场明确了任务分工拒绝了临时增加的物流功能给测试保留了一天时间如果没有这些调整再强的凝聚力也无法让一个星期的工作在两天内完成。林川没有在群里反驳。但他发了一条进度总结今日完成情况积分查询、商品展示、兑换下单及结果反馈主流程已联调通过演示数据和商品库存已准备完成兑换记录采用静态演示物流接口不纳入本次范围明日进行完整测试、问题修复及演示预演。当前不存在阻塞风险按计划可完成周一展示。他没有讨论主人翁意识。只把真正让项目成功的条件记录下来。周凯没有回复。但项目群里的所有人都知道这不是一次靠燃烧员工换来的奇迹。而是一次通过缩减范围和重新规划获得的正常交付。七、项目成功后最先消失的往往是员工付出的成本周一上午。演示顺利进行。领导从积分查询开始完成商品兑换最终看到成功页面。整个流程没有卡顿。业务负责人介绍“目前核心功能已经具备完整版本将在月底正式上线。”集团领导点了点头。“推进速度不错也要注意后续稳定性。”演示结束。没有人要求当天直接开放给真实用户。也没有人追问为什么没有物流和退款。那些周五晚上看起来“必须全部完成”的功能到了真正汇报现场甚至没有被提起。回到办公室后周凯在群里宣布积分商城阶段成果顺利交付感谢全体成员展现出的主人翁精神和战斗力。部门负责人也发了一个红包。大家抢完以后群里气氛很好。赵明看着自己抢到的两块七毛三笑道“这就是主人翁收益。”前端同事说“别乱说主人翁最重要的是精神收益。”办公室里笑成一片。林川也笑了。但笑完以后他打开项目记录补充了最后一项周末参与人员共7人工作时间已登记原任务顺延1个工作日调休安排待确认。下午周凯组织项目小结。他对大家说道“这次项目证明只要愿意担当很多看似不可能的任务都可以完成。”林川听到这里抬起头。“我建议总结里不要写成‘完成了不可能任务’。”周凯看向他。“为什么”“因为我们没有在两天内完成完整项目。”“我们调整了交付目标只完成了演示版本。”“如果总结成靠加班完成不可能任务下次遇到同样情况管理层会认为还可以继续压缩时间。”会议室里突然安静了。林川继续说道“这次真正有效的经验是”“明确了展示目标。”“缩减了版本范围。”“控制了需求变更。”“按照任务安排人员。”“这些方法可以复用。”“但如果只总结为团队拼搏下次大家仍然不知道该怎么做。”测试负责人第一个点头。“确实。”“这次能保证质量主要是周日有完整测试时间。”产品经理也说道“需求冻结很关键不然周六继续加功能肯定来不及。”赵明补了一句“任务范围也比最开始小了很多。”周凯看着会议室里的人。他原本准备好的“战斗力总结”突然失去了支撑。最后只能说道“那项目总结里把这些条件写进去。”林川点头。“另外周末参与人员的调休时间也建议现在确认。”周凯皱眉。“大家自己找时间安排。”林川说“需要同步调整项目计划否则每个人都没有合适时间。”部门负责人恰好坐在会议室里。他问“周末一共哪些人参加”林川把记录发到屏幕上。“七个人周六全天周日大约半天。”负责人看完后说“本周和下周各安排部分人员调休不要影响正常交付。具体时间由项目经理统一协调。”周凯只能回答“好。”项目成功后的第一个工作日调休被正式确认。上一世所有人都说项目结束以后会安排。但新任务一个接一个。最后没有人真正休息。这一次付出的成本没有随着掌声一起消失。八、他终于问出了上一世一直想问的话小结会结束后周凯把林川留了下来。“你最近每个项目都要挑战我的安排吗”林川说“我没有挑战谁。”“只是在确认项目是否可执行。”周凯冷笑了一下。“你觉得自己现在很懂管理”“不敢。”“那你为什么总觉得我的安排有问题”林川沉默几秒。“因为上一……因为我以前按照这些安排执行过。”“结果是团队持续加班项目依然延期。”“风险没有减少只是被隐藏到了最后。”周凯说“管理不可能把所有事情都计划得完美。”“同意。”“所以遇到意外需要团队共同承担。”“我也同意。”林川看着他。“但这次不是意外。”“展示时间可以提前知道需求也可以提前拆分。”“真正的问题是决策变化以后没有人愿意同步调整范围和资源。”“于是所有差额都由员工的周末填补。”周凯脸色变得很难看。“你是不是觉得公司在压榨你”林川没有回避。“当额外责任没有对应权限没有明确补偿也不允许讨论成本时它就不是主人翁意识。”“只是单方面转移成本。”周凯盯着他。“那你觉得什么才叫主人翁意识”林川回答“可以对结果负责。”“但也有权参与目标、范围和资源决策。”“愿意在紧急时刻多承担。”“但公司同样承认个人付出的成本。”“项目成功以后功劳、收益和成长机会不会只属于管理者。”“这才是双向的。”“如果只有责任是主人翁级别权限和收益仍然是普通员工级别那不是主人翁。”林川停顿了一下。说出了上一世一直想问却始终不敢问的话“主人翁既然是我公司什么时候也能算我一份”会议室安静了很久。周凯没有回答。因为这个问题本来就不是用来获得答案的。它只是让一个长期被包装成美德的单向要求重新露出真实结构。九、真正的责任感不是无条件牺牲很多人会把拒绝无效加班理解为没有责任感。但真正成熟的责任感不是接到任何任务都说没问题。而是在看到目标不合理时敢于指出问题。在资源不足时推动决策者做取舍。在风险过高时拒绝用一句“大家努力”掩盖事实。一个明知道项目会失败却为了表现配合而保持沉默的人未必比提出反对意见的人更负责。有时候真正对项目负责的表现恰恰是这个时间可以但范围必须缩减。这个范围可以但资源必须增加。这个风险不能接受需要调整上线计划。我可以周末支持但原任务和调休需要同步安排。这不是缺少主人翁意识。这是不再把自己的时间当成一种无限、免费、无需记录的公共资源。团队偶尔需要冲刺。项目也可能遇到真实意外。但冲刺应该是例外不应成为默认工作方式。加班可以解决短期交付问题。它解决不了需求长期失控计划持续失真资源严重不足决策反复变化管理责任向下转移如果每一次项目失败都归结为员工不够拼那么管理永远不需要进步。真正优秀的团队不会依赖成员长期牺牲来证明战斗力。它会努力让普通人按照正常节奏也能稳定完成工作。写在最后“主人翁意识”本身并没有错。错的是有人只在需要你付出时把你称为主人翁。需要你加班时你要以公司为家。讨论预算时你只是执行人员。需要你承担结果时你要有全局意识。讨论项目决策时你又没有发言权。项目失败时你缺少担当。项目成功时成果属于管理有方。所以下一次再有人要求你有主人翁意识不必急着生气也不必立刻拒绝。先问清楚三个问题我能决定什么公司为这个目标增加了什么资源我承担额外责任后会获得什么对应保障真正合理的安排经得起这些问题。只有依靠模糊责任运行的管理方式才害怕你把问题问清楚。林川的重启还没有结束。下一次他将重新面对那场几乎毁掉整个系统的上线事故。三个月前他已经明确提出数据库存在单点风险。没人愿意为暂时“不会出问题”的隐患投入时间。直到服务彻底崩溃所有人突然问他“你早就知道有风险为什么不坚持阻止上线”上一世他背下了这个责任。这一世他决定让每一次被忽视的预警都带着明确的接收人和决策结果。本篇留一句话真正的主人翁可以决定方向、调配资源并分享收益只让你承担责任的主人翁意识不过是给无偿付出换了一个更好听的名字。
)
