有能力的员工走了，现在公司内部不少业务处于半瘫痪状态，公司大领导现在对我很不满意，有什么办法处理吗？

我一直在成功的敏捷团队中工作，包括我现在自己带团队也一直是成功实施敏捷模式的。同时回国工作几年我也亲眼目睹了很多不成功的团队。最近知乎频繁给我推吐槽敏捷开发的文章，通过这些文章里吐槽来看，貌似舆论的风向绝大部分是批判敏捷，认为国内没有几家把敏捷开发用好的，大部分都是滥用，变成了领导压榨员工，压进度，随意改需求等等的借口。和我自己的经历对比，比较有意思，所以也来谈一谈我的看法。

先讲我所经历的成功的敏捷开发。

回顾以往，在老外的对冲基金里工作时候我所在的团队可以被认为是非常完美的敏捷开发，可以说是敏捷的不能再敏捷了，这个团队有如下特点：

不开站会，不开回顾会，不写文档，不写需求，不写注释… 但是产出极为高效。

这个团队的组成是大部分时间是四个博士，包括我在内，在我前面一篇回答里面有描述过这个团队，有德国人澳洲人斯里兰卡人还有我组成的多国部队，专业包括数学、物理、计算机，人员流动很少，截止到现在有人已经干了十多年了还在继续干。我们这个团队是一个做程序化交易的团队，但是团队成员在刚被招进来的时候的很多人的title都不是quant，而是software developer，而职责描述里面强调了Agile, R&D, full stack,quantitative developer等等。这个团队工作模式有如下特点。

1. 每个人都是“大全栈”，我所谓的“大全栈”不是指一般狭义的既做前端又做后端，而是也包括业务、商业逻辑。这个大全栈有多大呢？按照IT行业的语言，可以说每个人的职能都身兼产品经理、项目经理、架构师、开发、测试、生产管理员、运维，等等。 换句话说，每个人都有这个公司的业务的full picture，每个人思考问题都是从业务逻辑到技术实现到成本到产出等等一系列的闭环全都考虑进去的。平时工作中没有任何一个人会说，我不负责xx工作，我的职责只有xxx，不包括xxx。因为每个人从提出观点到coding到测试到最终实现落地，都是自己完全把控，自己对全闭环负责，不可能出现很多吐槽文里面说的开发指责项目经理，项目经理指责产品经理这种现象。
2. 老板放权尺度大。尽管生产环境24小时跑着上亿的资金, 公司也没有对生产环境的权限做绝对严格控制。我们每个人都有权限改生产环境。自己负责的策略、功能，自己都可以最终上生产环境来改。但是因为每个人都对全局足够了解也足够自觉，所以一般我们自己也不会去乱动生产环境，平时工作会默契的都由一个人去日常管理生产环境，只是在紧急情况下其他人才会插手。这种自觉是怎么形成的呢？因为每个人都是大全栈，都熟悉公司整体商业逻辑，知道如果自己乱动公司会亏钱，最终会影响自己的收入，这种直接的责权利关系，会让我们每个人都足够自觉。
3. 开发习惯上，因为每个人都是独立的大全栈，基本上自己负责的业务的所有代码都是自己一个人写，很少用公用的代码，因此很少多个人一起写屎山后期无法维护的现象。当然每个人也都主动写一些可以被他们人调用的函数和接口，这种情况都会自己做充分的设计，也会写大段注释，这个过程也主要靠自觉。团队里某个计算机博士老大哥也会不定期的阅读和整理所有人的代码，对更全局的架构和设计做把控，使得我们这种每个人各自为战的模式能够平滑的往下运行。
4. 没有站会和回顾会，不写文档，不写需求。因为每个人都是自己给自己提出的业务需求，自己来实现，最后自己来交付。每个人对整个闭环都是清楚的，所以当然就不需要这些会议和文档了。需求是怎么来的呢？是每周和老板一起开例会的时候讨论出来的，比如要做什么策略，要研究什么品种，要实现什么功能，讨论完，老板说做。那么就可以开始做了。因为我们提出来的需求基本上都是研究型的，可以说提出的是“课题”而不是需求，在刚提出课题的时候，因为答案是未知的，是需要研究的。我们会自己写大量代码来研究这个课题，最终生成结论，和团队讨论过了以后，这个时候才会形成所谓的明确的需求。中间的研究可能需要一个月的时间，最终需求明确了需要上生产，那个开发工作可能只需要1-2天。而在需求明确的时候，大量的代码已经在之前的研发的一个月里面写好了。所以根本用不着那种所谓的站会、泳道，sprint的概念。
5. 不写注释。有些人会主动写少量注释，而一般我们互相也是能基本看懂别人的代码的，代码在设计的时候就考虑了可读性，所以注释就不那么重要了。如果需要看别人的代码，平时大家都坐在一起，直接让同事给自己讲一下就行了。敏捷开发的一个非常重要的要点就是所有人必须坐在一起，坐成一圈，有问题直接拉同事当场问。
6. 老板完全懂技术，完全理解整个研发的流程，所以从来没有出现老板要求必须多久多久上线的情况。只要和老板说明自己负责的事情的进度和问题，老板都能理解。这也和需求的性质有关。我们的大部分的需求都是交易策略，是要直接跑真金白银的。如果催着赶着上线，后果很有可能是亏钱，所以上线这个事催不得，都是经过充分研究讨论以后才上线。

总体来看，能实现如此敏捷的一个团队，有如下几个条件，

1. 每个人都是大全栈且足够强
2. 老板懂技术且充分放权

而这两点只是表象，更深层次的原因是 — 权责的分配。

这样一个团队，可以说每个人都是product owner， 因为整个团队的利益是绑定在一起的，是系在一根线上的蚂蚱。大家都知道如果自己不给力，影响的是整个团队，这也就倒逼每个人必须成为大全栈，而老板也比较放心的能把生产权限下放，因为大家心理都清楚，团队亏钱，每个人都没有好日子过。团队赚钱，每个人的工资和奖金就多。有点相当于变相的全员持股。

有了这种利益格局，网上吐槽的这些中华田园敏捷的乱象基本上不会发生。

• 随时加需求： 不可能发生，因为需求是自己提的自己给自己提的，老板只提课题
• 上线不改期： 不可能发生，因为老板不敢逼我们，否则上线了出问题亏钱他自己要兜着
• 996： 不存在，老外没有加班文化。你如果总加班老外会认为你智商低工作能力有问题，无法 在常规的时间内完成工作
• 站会回顾会： 不需要，需求都自己提的，每周例会和老板汇报一下自己进度就可以了
• Sprint，backlog： 不需要

以上可以看出来，真正成功的敏捷开发不是不存在，而是要求非常高。只有在团队的整体技术素养非常高的情况下才能实现真正的敏捷。

再反观一直被吐槽的中华田园式敏捷，以上提到的几个条件都不满足

1. 没有大全栈，而是要分一堆岗位，所谓产品经理，项目经理，架构师，开发，测试。。等等，《人月神话》里有讲，一个项目每引入一个新人，沟通成本会呈几何级数增加。弄这么多岗位，沟通成本可想而知。我其实一直比较嗤之以鼻的是为什么国内要把软件工程的整个流程切分成这么多岗位，好端端的一个大闭环，非要切分成产品经理，项目经理，架构师，开发，测试，生产运维，然后成天低效扯皮。假设每个岗位的用工成本是一年30万(对应年薪20-25万)，以上6个岗位加在一起的用工成本就是一年180万。与其这样我不如年薪百万招一个上文提到的德国博士那样的，一个人就够了。 国内的很多公司文化是由于种种拿不上台面的原因，不愿意招这种强人，而是非要把岗位切分成一堆螺丝钉岗位，搞得成天团队扯皮又996，戾气很重，团队成员长期做螺丝钉，得不到提高，到35岁高概率被淘汰。而为什么一些领导非要样做呢，因为怕招到一个足够强的人威胁到自己的位子。

2. 老板不懂技术，拍脑袋。老板要么自己懂技术，要么就能够把权力下放给一个懂技术的二老板，由二老板来带，这样也可以。如果遇到拍脑袋的老板，那无解，只能走人，没底气走人就只能忍受了。作为打工人，只能不断的自己努力提升自己，使得自己有底气选择老板。

3. 有责无权。分那么多岗位，就只是拿一份工资而已，工资又低，每个人只负责自己这一块，不归自己管的，自己想管也没有这个权力。这种现象要解决的话，需要有利益绑定的方案，高至股权期权，低至明确的奖金分配方案。如此才能让大全栈充分的负责起来。而如果自己所在的公司没有这种制度在怎么办呢？这时候只能靠自己，不能觉得自己就拿这么点工资，凭什么既负责这个又负责那个。如果这么想的话，就一直很难提高。如果自己抢着既想负责这个也想负责那个，慢慢自己就会变强的。等到自己变强的时候，就有资本有底气选择老板了，就可以跳槽到钱更多级别更高的地方。

这种现象更底层的原因，我觉得是我国高速发展的经济，使得有大量不具备老板素质的人做了老板，也有大量本来不具备足够技术素养的人做了程序员，结果只能一起折腾互相伤害。这是一种经济高速粗放发展的阵痛，短期无解也不需要解决，因为提供了大量的就业和机会，虽然大家996互相伤害着，但是至少有饭吃有机会。等到逐渐发展到发达国家的程度，自然而然就会变好的。

———————-追更1———————-

不到24小时就有这么多回应，根据各位的反馈追更一下

很多人说因为我们每个人相对独立，所以用不上敏捷，这个说法其实本末倒置了，“每个人相对独立”，“业务相对独立”这个现象是结果而不是原因。

敏捷是和人本身的关系很大的，因为我们每个人都有大全栈的能力，所以团队就自然而然演变成这个模式；如果团队成员不具备大全栈能力，可能就会演变成别的样子。因为我们每个人都知道效率最高的样子是什么样子，所以在设计代码和业务逻辑的时候就会自然而然往每人大全栈方向去设计。这是一个自然的过程，并不是因为业务性质导致的。我也带过那种和互联网类似的写web和bs架构的金融科技项目，也是可以采用这种模式的。所以团队成员的综合个人能力是最直接的原因。敏捷的一个精神实质就是“以人为本”，而瀑布模式则是拿人当机器，这是截然不同的两种理念

团队里也并不是每个人都需要大全栈，有那么两三个能大全栈掌控全局就可以了，比较初级的成员会被牛人带，从一开始就被按照大全栈的思维来带，在这个过程中初级成员的成长也很快。

我这个例子确实在国内不具有代表性，不过拿出来讲也是有意义的。在这个问题下面的绝大多数回答讲的都是失败案例，通过和我们这种成功案例对比，可以说明一个问题：

敏捷是有适用范围的，它的适用前提是老板和员工的综合水平都要足够高；如果自身水平不够，尤其是老板自身的水平不够就谈敏捷，那就是耍流氓，就变成了“中华田园敏捷”。

如果老板水平低，员工自己也是螺丝钉，一群人不知道自己该干什么，等着人提需求，提需求的人自己也不懂技术，天马行空想一出是一出。这样还真的只能按照瀑布模式来管理，瀑布式式管理是都把人往最恶的方向揣测的管理模式。员工本身又弱势，最终结果一定会形成不靠谱领导乱改需求又压进度，全员996怨声载道。

大全栈员工就不会出现这种问题，客户提出不靠谱的需求，大全栈员工会给客户和领导分析你这个需求是不合理的，你其实可以这么做，你的业务诉求是xxx，技术上我们可以blablabla，同时我们还有方案B方案C，你的业务需求还可以这么来…..，客户和领导一听，很有道理！那就按照你说的做。慢慢的客户和领导就会越来越听你的了。然后你就可以和领导提条件，这样做一周是上不了线的，但是如果我们如何如何做，一周可以先上线一个简化的xx版本让客户先看到界面，然后后台我们再慢慢排期慢慢改，甚至可以先不写crud界面，手动改生产数据库撑一段时间。如果要最终实现xxx，我需要招两个博士，使用xx技术方案和模式，后面1个月可以做什么样，3个月可以做到什么样，6个月可以做到什么样….. 如此几轮下来，客户和领导就越来越听你的了。

这个过程有可能会发生如下几种情况：

1. 你的领导听不懂，坚持他的不合理需求， 这种情况很简单，只能炒了这个领导，换一家，就这么简单。
2. 你的领导听懂了，愿意采纳，如此你会在团队里逐渐成为资深员工，升职也不远了
3. 你的领导不愿意听懂，他怕你太强取代他的位置，这个时候就是考验政治智慧和勇气的时候了，这个时候需要做的就是找更上一层的领导来说明情况，就是传说中的“越级汇报”。如果效果好，你会很快就升职。如果效果不好，那就把这家公司炒掉，换一家。看你敢不敢了。

如果自身水平不够，那就只能弱势了，弱势就会容易被压榨成996了。

———————-追更2———————-

也有人问到我们这样一个团队是怎样形成的。

因为可能人们会理解成我们每个人在来这个公司之前就已经是这个水平了，其实不是的，这种模式是这个团队形成的自己的文化，在来这个团队之前我们每个人也是常规的找工作的fresh phd。

能够形成这种模式主要是我们的老板比较牛，俗话说，”兵熊熊一个,将熊熊一窝 ”，反过来也成立，将牛牛一窝。跟着牛老板一起干，自己提高也很大。

团队的演变大概是这样的：

首先老板自己是个博士也是个大全栈，团队在创始阶段的时候系统代码和业务逻辑都是他自己设计的。然后他会招来两个博士作为初始团队员工。初期他就按照大全栈的模式来带这两个博士。这个完全是老板的个人偏好。我知道尤其是在国内有很多老板不愿意这样做，因为不想把自己的东西都教给员工，也不想员工变牛起来威胁到自己。但是我们老板没有这个担心，因为他有足够的自信我们是不可能在短短几年内超越他的。按照大全栈来培养员工对团队整体是有利的，如果他不按照大全栈这么搞，而是招一堆产品经理，架构，开发，测试，运维，成天扯皮，国外人工那么贵又不许加班，其实是不划算的。同时我们的核心竞争力是交易策略，老板更愿意每个员工都变强从而输出比较牛的交易策略，而不是一直当螺丝钉。

如此团队成熟一些后，又会招来后续的员工，就延续了这种模式，后面来的人也会被按照大全栈的模式被老板和资深员工往下带。

这种模式也解释了为什么我们喜欢招博士，因为科研本身也是一个大全栈的过程，一个合格的博士毕业生本身就是有自己独立承担过科研课题的，已经具备了一定程度大全栈的素养了。

我应该是第二波进入这个团队的，进来以后被老板和老员工同时带，后面又来新人有些就是我来带了。于是这种人人大全栈的模式就这样延续下来了。而且这是我的第一份工作，所以我本来以为技术类工作本来就是这个样子的，回国以后才大吃一惊。

因为习惯了这种大全栈，刚回国工作的时候，和常规技术团队对接的时候，不习惯了很长一段时间，我总想这也管那也管，既当产品又当开发，代码要自己写自己测，和原有公司文化格格不入，不愿意成为螺丝钉。正是因为如此，在国内公司很快就把相关的项目都由我自己来带团队。

想到一个段子，有个儿童乐团，孩子才十几岁就可以演奏很复杂的巴赫平均律作品，参观的人很惊讶问乐团的leader说是如何培养这么小的孩子演奏这么难的作品的，乐团leader说：“嘘，如果你不告诉他们，他们永远也不知道这些曲子有这么难”。

——————————–追更3————————-

还有很多人反馈说小团队才能这么玩，大团队搞不了。

这个说法也是经不起推敲的。

仔细想一想，很多时候之所以团队变得很大，动辄几十号人上百号人，产品经理、项目经理、架构师、开发、测试一大堆，其实经常也是人员总体水平不够高导致。其实很多工作配一个三四个强人的大全栈团队就够了。所谓的大项目，一般都是可以拆成多个精英小团队。

而之所以招这么多平庸的人搞的拖拖拉拉好几十人，可能的原因有：

1. 管理者自己水平低，以为世界就是这个样子的，既没吃过猪肉也没见过猪跑，不知道世界上还存在那种大全栈小团队模式
2. 即便管理者这道有这种模式，但是也不愿意招牛人，招个年薪百万的牛人比自己收入都高了，可能自己位子就不保了
3. 招一堆水平平庸的人，堆人数，搞个几十人上百人团队，铺摊子，然后美其名曰“管理数十人百人团队”，“大项目”，“项目群”，其实只是为自己增加政治资本罢了。
4. 国内员工好压榨，随随便便996都不敢吭声，所以即便堆人数效率低，可以通过996来粗放的提高效率，同时又能铺成大团队，增加政治资本，何乐而不为呢

1.产品口头描述需求，必要时可由老板担任产品经理，减少从头脑风暴到开发的中间过程。

2.欢迎老板的需求变化，善于利用需求变化，帮助老板获得掌控感，消除焦虑。

3.不断的交付软件，周期通常是一周，正常的时间安排是周一出需求，周二原型设计，周三开发，周四需求变更，周五开发，周六联调测试，周天封版发布。但通常需求都很简单，简化流程后，当天开发，第二天就可以上线。

4.产品是对需求最了解的人，应该同时担任测试的工作，通过在页面上的极限测试快速发现问题。

5.项目必须围绕那些有内在加班动力的人建立，他们能够带动团队提高工作饱和度。

6.避免频繁的一对一沟通导致的时间浪费，可以在每天早晚会时集思广益。

7.会议是最好的团队沟通方式，但会议时间应该和工作时间区分开。

8.不用关注技术是否优秀，设计是否良好，迭代会解决所有问题，快速迭代，不仅是对项目的迭代，也是对团队本身的迭代。

9.开发速度总是随着开发人员的增加而线性增长，同一模块应该让尽可能多的人同时开发，不仅可以缩短开发周期也可以增加开发人员的可替代性。

10.功能的完善性至关重要，“主流程”级别的交付没有任何意义，缩短交付时间的逻辑写死是每个开发人员都应该具备的能力。

11.加时不加薪可以帮助团队成员保持饥饿感，配合对狼性文化和福报论的宣讲，能够有效提高团队成员的主观能动性，从而提高交付速度，节约项目成本。

12.一切都问题都是开发的问题，开发人员应该定期反思，并快速地进行调整。

物理学博士对题主的回答

 

半夜吃瓜吃到自己头上了，前老板居然把自己的经历给发了出来。最近几年只在知乎偶尔发发科普，从来没讨论过自己的工作。一开始也确实想着靠科普吃饭，但最终热情还是被现实浇灭了。

也没什么隐瞒的，自己是学物理学专业出生，选错专业了认命。如果问我有什么过人之处，其他的我不敢说，但好奇心真的旺盛。从小学开始就喜欢刨根问底，问到了亲生父母都怕的地步，父亲买了一堆百科全书，可惜还是有一堆问题找不到答案。

刨根问底，又一意孤行的性格自然而然的钻到了物理的深坑里，毕竟，任何问题一直问为什么都会变成物理学问题。留英学完粒子物理和量子物理后，发现再问下去，没人能回答了。遂放弃，没有读研直接去学代码去了。其间接触的选课 physical symbol system，让我对ai有了很强的兴趣。可以说，从那天开始，我才从一个问问题的人，变成了一个想要解决问题的人。

物理本科很尴尬，我也确实需要一家起步的公司做铺垫，没有想着要在小公司拿多少钱，只求相处融洽身心健康，积累经验技术才是最重要的。这次的事件只是个导火索，主要原因还是已经没有能学到的东西了，如果一个程序员学不到东西，那他的职业生涯也就到此为止了。

这件事情其实我一直在打算，但因为不知道怎么开口，就没有提起过。自己不擅长拒绝也占一部分原因，甚至有一次老板让我去给一堆破烂电脑做排名，我都答应了，这里也能看出上级是完全不懂计算机。我是想着找机会提前打个招呼，结果没等我说，老板就在偷偷谋划，也确实实施了。

前老板谈到的其实是其次，只是根稻草而已。最终下决心还是因为在老家接到了一个朋友介绍的外包活，几个月估摸能干完，暂时不愁吃喝了。可惜我没有稳定的客户，看到前老板的问题居然火了，我也蹭蹭热度给自己打个广告吧。

听了知友们一顿吹，略微膨胀了一秒，但自知之明还是有的，简单说一下自己的技术栈：

产品：跟正经的产品经理肯定是天壤之别的，沟通弱于技术，给自己做需求是不需要沟通的。听别人的描述自己去写程序没问题，但如果要转达需求给另一个程序员，我认为是件令人头疼的事情。意思转达错了，误解了还要撕逼/维护同事关系，浪费时间又学不到东西。

开发：试着去看系统设计，看到一堆第一眼看不懂的术语，但如果落实到具体的业务项目要怎么设计和搭建，我还是能说出个所以然来的。

前端：vue/react/ant design/elemet/bootstrap。css学了一点，但也就到基础，工作上都是to B的比较多，注重功能，没有对高大上美感的需求，学了几个前端框架就够用了。如果要让我做出华丽炫酷的效果，还是在我能力范围之外的。报表什么的就用echarts。

后端：go/node/mysql/mongodb/redis。我认为后端才是自己的核心竞争力，如果让我放弃全栈选一个肯定是去干后端。对算法感兴趣，最近喜欢在leetcode上刷题，可惜在项目里都是crud，感觉没有施展的空间。

运维：自己去官网租服务器，低耦合代码微服务架构k8s部署，有些短期的项目会白嫖一些免费的mysql云和图床。性能优化，健康监测，负载均衡，基本能保障项目稳定运行。

测试：比起上面应该是最简单的了，略。

点发送之前，其实想了很久，但找工作的问题也不能一直拖着。知乎几百个回答，只有这篇对评论做了筛选，希望大家不要深挖和人肉，见谅了。

其他网友评论

你适合到创业公司当个技术合伙人，当然风险比较大。

也可以到大厂当一个设计师转架构师，但是目前大厂招人可能困难。但你也缺一点大厂的流程规范训练，都是野路子摸起来的，需要点时间适应。

别做外包，糟贱了。

你原来干的活儿，等于CIO，首席信息官，整个公司的业务信息系统，市场行情百万以上。如果钱给到位，权授到位，可以考虑一下。

或者干脆自己创立一个信息服务公司，专攻企业信息化，把老东家活儿给接了。类似这样企业可以接一批。

---

太真实了老哥这个心态很棒。我去年也在一个制造业初创公司做这种计算机系统全包的工作，本来说是给他们搞定个核心算法就给股份，结果入职之后什么都要做，厂房建设网线都是我去拉，一个人从各种网络基础设施一路搞到各种辅助软件系统工具，还都是能省钱就省钱。到后面开始整核心业务了，各种参数和需求都当商业机密一样对我藏着掖着，聊个软件需求跟cia审间谍一样，一句话能模棱两可就不会有准，各种保密协议签个没完还得藏着掖着，更别提软件著作权这些东西都签协议转让了。到后面融到资立刻开始瞒着我招人，转过头就把我股份给否了，骑驴找马玩的不要太六。五个人的公司就开始抓纪律抓考勤，加班到九点没有加班费，第二天早上晚一点点就掐着表扣钱，中午吃饭统一收费就算了，打多点菜还要被叫到会议室三堂会审。磨到后面又说股份可以给一点点，不过不像原来说的可以按比例拿了，还得押几十万进去，压七年，到时间可以兑现之前有一百种方法无偿收回。

---

本来他们吹得挺大的，说是什么只有他们能做的高精尖技术，我也是看到了一点把这个事情做大的机会。后来开始做核心部件了，发现他们就是拿上游的scanlab元器件做组装，别人给多少精度就是多少精度。然后试验优化参数他们也没有一个指导性的公式，就是靠反复试验调参，每批原材料都得分别试验分别调参，要是舍得花点钱我还能把这个试验过程给自动化一些，但他们就不，就要手工操作匠人精神。再后来看到美国一家公司搞这个东西就按照我说的这套密集传感器矩阵动态调参的思路做的，而且早几年就做成了，还卖给马一龙了，我就彻底不想玩了。

---

可能我看的比较早？那个答主也是为了捡漏？

何况跟题主公司比，已经很厚道了

有人建议题主用外包形式重新合作，然后那个题主觉得给5w的话好像多了点（一年），原话大意是“他来坐班一年才10w，不坐班的话5w差不多了吧”

---

STEM，不算选错专业。物理数学可能不如CS那种能够直接变现，但b格更高，转码根本没障碍。别外，你在那公司解决的B端全栈类的项目，根本并不简单，能做好的人很少，而且也可以做的很深入的。国内互联网的卖菜、外卖、抢购、打车、社交、游戏、内容媒体不比国外互联网差多少，但国内b端的金蝶、用友、阿里钉钉等则与国外同行比相差太远，我感觉类似这种全面性很强的人如果以一专多能的方式发展自己，搞B端可以大杀四方的。当然C端更看重算法、B端更看重模型（比如给企业流程、组织进行、数据进行抽象建模的能力）。 另外，外包就算了，没有沉淀与积累。

其他知乎网友回答