考上研究生就是人生的成功吗？过来人告诉你考试容易读书难
今年的研究生考试的结束，今年的报名人数，已经高达341万，创下历史新高。考试成功只是一个开始，真正的难题，还在后面。
作为学历和学术的金字塔尖，“研究生”“博士”被标上了各种魔幻的标签。这本书用直白的语言告诉我们，学霸到底是怎么炼成的。作者是斯坦福大学的博士生，在书中记录下他在读博期间的苦乐。沿着回忆的时间轴，我们就像作者的同学，跟随着他完整地感受和经历了一次博士的学习生涯。
有迷茫和绝望——在博士前期找不到方向及面对瀚如烟海的文献时；也有笃定与兴奋——在发现一个可能的研究问题或创新点并为之努力奋斗时；有低谷和挫败——在一次次收到论文的拒信和得不到导师的理解与支持时；也有幸运与满足——在会议报告和交流中认识专家前辈并能得到他们的指导与肯定时。
选择读书，其实就选择了一种生活方式。它可能是枯燥乏味的，你会被“研”磨上万个小时甚至更多，每天面对着字迹娇小的外文文献、复杂的公式和中规中矩的代码；它当然也可能是有趣的，在加班加点终于解决缠绕你脑海里数日的难题后的兴奋能带给你最真实难忘的满足与欣慰，那时或许会更加理解“生命在于折腾”的真谛吧。
最终，作者告诉你：“趣味稍纵即逝，容易取得，但是，满足感，却只有在攻克了重要的，有意义的研究挑战后，才能收获。”
点击下方阅读原文，免费看《研磨记》
【书名】“研”磨记：一名博士生的回忆录 (The Ph.D. Grind)
【作者】[美]Philip J. Guo
【作品简介】斯坦福大学计算机博士Philip Guo写的一本关于他的博士经历的小书，对他在斯坦福大学的六年博士生涯（2006年至2012年）做了一个编年形式的记载。所谓“横看成岭侧成峰，远近高低各不同”，各行各业的人看过此书以后虽然会各有不同的体会，但是总归都会对“博士生过的是怎样的生活，会有怎样的思绪”有一个大致的了解。
其中一些人群会受益更多，包括但不限于：有志读博的本科生、正在寻找帮助和他人激励的在读博士生、想更好理解博士生的教授们、想雇佣和管理博士生的雇主们、在创造性和竞争性比较强的领域工作，亟需自我激励来不断前进的专家们以及受过教育，想了解学术研究成果是如何产生的成年人们（或者好奇心旺盛的孩子们）。
【作者简介】PhilipGuo，美籍华人，现任美国罗彻斯特大学计算机科学系助理教授，研究方向为人机交互、教育技术和在线教育。PhilipGuo于2001年入麻省理工大学电子工程与计算机科学系读本科，2005年毕业后留校攻读硕士学位，2006年毕业后入斯坦福大学计算机系攻读博士学位，并于2012年顺利毕业。毕业后在谷歌担任软件工程师，2013年6月作为访问学者在edX交流三个月。2013年10月在麻省理工大学从事博士后工作并于2014年7月出站，出站后在罗彻斯特大学担任助理教授至今。
【精彩段落】
战斗了两个月后，我开始取得零星胜利了。在我的不懈努力下Klee终于可以发挥作用，找出小设备驱动中的新错误了。为了确认这些错误是否属实（而非由于Klee的局限导致的误报），我给开发这些驱动程序的Linux程序员发邮件，描述Linux程序中可能有的错误。一些开发人员确认了我在他们的代码中找到的错误。由于他们是我验证Klee功能的第一块试金石，我收到这些确认邮件时，非常兴奋。虽然我并没有做什么开创性的新研究，但是由于我的努力，Klee终于可以找到其他工具找不到的错误了。为了这件事，我仍然非常满足。
在确认了一些最小设备驱动的错误后，我提升了一点点士气，把目光放在了让Klee工作在更大，更复杂的驱动之上。然而，接下来的几周里出现的新的技术问题更难以忍受，以至于我一度想直接放弃。长话短说，问题是这样的：Klee只能在包含约少于3000行C代码的软件中才能够有效找到错误。最小的Linux设备驱动包含约100行代码，所以在Klee的处理能力之内。
更大的驱动包含约1000行代码，但是这1000行与Linux操作系统其他部分的10,000到20,000行代码错综关联。Klee没有像做“外科手术”一样，将代码从每个设备驱动中提取出来并且分别分析每1000行代码的能力，因此这些更长的驱动代码远远超过了Klee的分析能力。我尝试过不同的方法，减少这些代码间的外部联系（称为依赖性），但是这么做又需要花好几天手工自定义每个驱动，非常复杂。
面对那个令我望而却步的任务，我和Dawson见了面，期间我歇斯底里，绝望不已。花好几天时间让Klee可以对每一个新设备驱动进行分析，这个行为非常荒谬。况且，这事不仅让我精疲力尽，我甚至觉得它连科研都算不上！试想，写文章时我能写些什么呢——难道写，我花了将近1000个小时，手动使Klee分析设备驱动，却没有获得真正的见地？这绝不是对学术界的任何贡献，只能说，这很愚蠢。
与此同时，我还开始惶恐不安，离大限只有五周了，Dawson还没有跟我们小组提到任何关于论文写作的事。一般情况下，写出一篇可以提交的论文至少需要四周，更何况当时我们的项目有六个学生共同参与，协调每个组员的贡献到一篇文章里会花费更多时间。
开会之后几天，Dawson想出了一个提升Klee性能的方法，来克服我遇到的依赖性问题。他发明出来的新技术叫做受限执行（underconstrainedexecution，简称UC），也许能够让Klee像“做外科手术”一样将Linux设备驱动从外部的10,000到20,000行代码中提取出来，分别分析这些驱动。他马上开始和一个高年级学生，一起将UC技术编入Klee。
这个升级版的Klee叫做Klee-UC。尽管当时我累得不行，我还是非常高兴，因为我的努力和挣扎至少帮助Dawson想出来了一个全新的点子，这个点子也有可能会成为非常有价值的学术贡献。
接下来的几个星期Dawson和其他学生主攻Klee-UC。他们也让我继续用旧的手工方式寻找Linux设备驱动的错误。他们计划通过用Klee-UC重新寻找我用人工的方法利用Klee找到的错误，来展示Klee-UC的高效性能。
到此为止，他们想在会议文章中表达的观点是，相对于一个博士生（就是我！）花长时间设置Klee来找错误，Klee-UC更好用，因为它能在几分钟内自动找到所有的错误，不需任何额外设置。
于是就这样，我继续被“研”磨了几个星期，最后终于可以让原版的Klee分析937个Linux设备驱动并发现55个新错误（驱动开发者通过邮件确认了其中32个）。然后，我又得设置那个刚刚面世的Klee-UC，用它分析这937个驱动。
由于在我试着用这个软件分析驱动的同时，Dawson和其他学生仍然在实现Klee-UC，这个过程变得更为棘手。谢天谢地，Klee-UC确实能够再次发现源代码中的大多数错误。这样我们至少做出了一些研究贡献，写完了会议提交的论文。
然而问题，而且是个大问题，仍然存在。尽管我们得到了很好的结果，但是距离提交文章的截止日期只有三天了，而且还没有人动笔。这么短的时间里，撰写、编辑并且完善出一篇能够有机会被顶级计算机科学会议录用的文章，简直是不可能的任务。但我们硬着头皮上了。
在大限前72小时，Dawson和组里的五个学生（有一个当时已经退出了项目组）为了完成实验和撰写文章，通宵两个晚上，住在办公室。其实我们几个学生内心深知这篇文章肯定不可能被接收，但是Dawson的领导下，我们也只能乖乖听指挥。
最后论文交上了。但是那论文错字连篇、语法不通，更是对图表没有充分解释，也没能对全文做出总结。想起这文章我都觉得非常尴尬，因为它实在是太一塌糊涂了。那时我琢磨不明白，在这样杂乱无章的组里读博士，我怎么能拿到博士学位。三个月后审查结果如期而至，文章被批评得惨不忍睹，例如：“[程序委员会]认为这篇文章马虎得肆无忌惮，决不能录用，请不要提交远达不到审稿要求的文章。”