N+, 一款从 Flash 游戏移植到 PSP/DS/XBOX 的游戏, 很好玩~

介绍就不贴了, 到处都是, 可以归为逃脱类的游戏, 吃黄钻可以加时间, 在时间耗尽前吃到绿钻石再从大门逃脱就可以了. 玩下来感觉一般时间不会太紧张.

最早玩 Flash 版的时候只觉得挺有趣, 玩了一段时间就放下了. 最近玩了 PSP 版的那叫一个畅快, 几天时间就通关了. 感觉很爽就是了.

游戏中其他的隐藏关和隐藏颜色都在游戏进行到一定程度的时候会自动打开, 只有 ATARI BONUS 这个隐藏关需要通过作弊码打开. 先进入 UNLOCKABLES 界面, 按住 L 和 R, 再依次按下 X, O, X, O, X, X, O, 哇咔咔, 隐藏关打开了, 进入单人游戏, 在选关的地方往上多出来一些心的关卡, 不过似乎没什么挑战性. 不知道是不是还有什么隐藏元素, 有新发现的记得留言告诉我.

Cheat Codes to Unlock Atari Bonus Level: Go to the UNLOCKABLES screen, hold down L and R and press X, Circle, X, Circle, X, X, Circle.

点此下载美版 N+ for PSP (BT)

软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：“拥有多年的丰富的项目管理经验”，但在实际开发中，“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于“无间”（十八层地狱）。一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。

记得一个格言曾经说过“人类最愚蠢的行为在于忘记常识”。另外一句较为相仿的格言则是“不知道历史的人必然会重蹈覆辙”。作为项目管理来说亦为同样的道理。很可惜，我们中的大多数管理者口口声声“软件工程”，工作时“用程序代替用户需求”，极具政客的嘴脸。其结果必然如目前媒体“程序员生存状况”所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。

如何改善我们的软件开发管理，一条便捷之道便是“尊重常识，尊重历史经验教训”。在软件项目管理中，有许多的原则和经验可以供我们借鉴。

一、 计划原则

没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为“变化比计划快”，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清的“混沌”状态。此外，对于开发人员来说，“目标导向（Objective Oriented）”是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。

二、 Brooks原则

向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，“人多力量大”也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性

所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。

三、 验收标准原则

我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。

四、 默认无效原则

你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为“沉默意味着同意”。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。

五、 80-20原则

80-20原则在软件开发和项目管理方面有许多“实例”。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在“最好有”这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。

80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以“经验”这样的思维定势来做决定。导致的结果如系统论所言：由于“抱怨”的作用和反作用循环，结果是大家都不欢而散。

六、 帕金森原则

帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。

七、时间分配原则

在项目计划编制过程中，我们常常将资源可用率（人、设备）等设置为100％，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“ 无知”，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80％就已经时很不错的了，我个人比较倾向于60％左右（黄金分割点）。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划（该计划没有考虑到资源可用率）的4/3－5 /3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。

八、变化原则

也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。

九、作业标准原则

一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以“作坊式”为主，高举“我们符合国际CMM X规范（ISO某某规范）”的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你就不会是今天的这副狼狈相。

十、 复用和组织变革原则－解决项目问题的未来之路

如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速的进入项目问题定义之中，减少项目开发人员的工作量，从而尽可能的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革（Moc），精简项目管理机构、重新定义工作职责，制定柔性的项目工作流程，改善项目开发人员的沟通状况，提高项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。

结论：作为一个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知识和技巧，还必须深入学习项目管理（建议参看PMI 《PMBOK》）、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的项目管理人员看自己个人简历时方不会觉得脸红，才能在公司中树立自己的管理权威性，同样也才会有一个良好的职业经理生涯的开端。

作者介绍

张华，国家系统分析员，CSAI高级顾问。先后从事过企业信息管理，项目管理和应用系统分析与设计等工作，能熟练运用多门外语，并在自动化软件生成颇有建树。　　个人熟谙PMI项目管理体系、富士通SDEM方法、IT审计和软件企业信息事业推进，熟悉多种建模方法、设计工具，具有丰富的多种业务领域建模经验。个人目前热切关注的对象有：软件哲学、软件思维工程和知识管理。

最近做多了 UI 和 UE 方面的活, 觉得 UE 是一项很有意思又极富挑战的工作, 找资料的过程中搜到这么一份质量很高的 Presentation, 作者是 Alan Cooper, 用户体验大师, 似乎也是 VB 之父吧.

Presentation 的地址:
http://www.cooper.com/journal/agile2008/

留个档, 方便以后查阅, 也算拿出来分享.

工作太忙, 没时间做一些自己的东西, 连 Blog 都懒的更新了. 快开学了, 请了3天假带上我亲爱的双休日一起回老家休养, 老妈不会上网找歌听, 闲来无事干起老本行, 盗链囧

找到一个好源头, 怕用的人多了遭封, 本不想公开, 虚荣心作祟还是发上来了. 不过不会再像以前做大站, SEO, 搞广告, 再被版权局盯上了. 喜欢用的朋友收藏一下自己用用, 也不必到处宣传了~ 有建议意见或者 Bug 报告的就在这里留言吧~ 源代码我就不发了… 代码和界面都没有做太多的优化, 只求快捷方便.

差点忘了地址:
http://www.imallen.com/player/player.php
咱们也国际化, English Version of My Mini Player:
http://www.imallen.com/player/player_en.php

Enjoy it~

更新记录

2008-08-24 加入了自动抓取的歌词

Google 二面落榜了，转一篇文章，看到这篇文章虽然晚了一些，但是希望对自己将来求职有所帮助。

发表者：Google（谷歌）中国工程研究院 工程师 方坤

自去年春天加入谷歌，我曾多次随公司校园招聘团队一起走访各地院校，帮助公司发掘人才。利用这样的出差机会到处走走看看，饱览祖国大好河山，是我一点小小的 私心。但更具挑战性、更激动人心的，还是和我未来的同事们过招，不打不相识嘛。一想到马上就要和这样优秀的人才一起工作，我就兴奋不已，真恨不得现在就买 一张单程机票把他/她拽回北京。

然而，在面试过程中，我也相当惋惜地看到，由于种种主客观原因的限制，很多青春韶华的学子未能充分发挥出他们应有的潜力。这里我不讲成绩，只把我遇到过的一些普遍的问题归纳一下，希望对即将踏入社会的学生朋友们能有些许帮助。

实战！实战！

纸 上得来终觉浅，绝知此事要躬行。对于一个未来的软件工程师来说，实际编程经验是相当重要的。我们会要求应聘者在紧凑的时间内编写大量的代码，从中考察应聘 者的分析能力，编码速度，代码可读性，对所用编程语言的掌握程度，对边界条件与异常状况的处理，数据结构与函数接口的定义，程序运行的效率和应聘者查错纠 错的能力等等。一口气列出这么多要求，听上去似乎过于苛刻，其实只要积累了足够的实战经验，每一个应聘者都完全可以满足这些最低限度的要求。

我 记得开复对于青年学子们有一个建议，大学四年，至少要编写 10 万行代码。不是每一个人都期望进入谷歌这样的顶级技术公司，但即使对开复的建议打个三折，也还有 3 万行呢，不努力，能行嘛。前来应聘的学生们在编写代码时暴露出这样那样的问题，大都可以归结到同一个原因：锻炼太少。比如”for (int i = 0; i < strlen(s); ++i)”，没有实战经验的人，怎么可能意识到暗藏其间的效率陷阱。再比如内存泄漏，就和初恋一样，没有亲身经历过的人，不会有刻骨铭心的感受，而一旦经 历，终身难忘，根本用不着你有多聪明。遗憾的是，我看到许多相当聪颖的学生写出来的代码只能用惨不忍睹来形容，真让我怀疑这是不是就是他们的第一次。大家 不要怪谷歌要求高，恕我直言，如果不能持之以恒，下点儿苦功夫，不光谷歌一家，其它公司恐怕也是进不去的。

北京、上海等地的学生，往 往有更多实习、兼职机会，接受锻炼之余，还能攒下一笔小钱作零用之资。其它一些地区的学生也许就没有这么幸运，这就尤其需要积极主动，寻找机会，创造机 会，把握机会。世界正在变平，互联网的发展改变着地球的面貌，让不发达地区的学生也能相对容易地接触到发达地区的资源。前不久我在西安遇到一个学生，他半 年来一直坚持在北京大学的 ACM 网站上参赛、做题，我看他写出来的程序就确实比他大多数同学都要好一些。我相信，只要他能够持之以恒，还会取得更大的进步。我听说浙江大学的 ACM 网站、TopCoder 网站也都是不错的教育资源，感兴趣的同学不妨一看；虽说做竞赛题距离真正的软件开发还有着显著差别，但也不失为一个不错的出发点。

在 积累一定编码量的基础上，我建议大家总结经验教训，不断提高自我。如果几万行代码写下来，学 C++ 的不知道 const 怎么用，学 python 的没听说过 GIL，我看也没什么意思。到了这个阶段，我推荐大家读一些经典的进阶书籍，例如《Effective C++》、《Effective Java》等，即使地处偏远地区，也可通过网上书店买到。（我建议编码量太少的同学就先不要读了，会走火入魔的。我见过有学生连引用和指针都没搞清楚，就 在那里重载操作符的。）交流也很重要，如果能够与网上网下志同道合的朋友互相帮助，共同进步，当收事半功倍之效。在这一方面，各校的 Google Camp 也许能够起到一定作用。

“我会写代码呀，为什么谷歌不要我？”

在谷歌，研究与开发融为一体，软件工程师与计算机科学家当然也合二为一。计算机这几年算是比较热的，能够得偿所愿挤进计算机科学相关专业的学生都是全中国顶尖的人才，如果大学四年荒芜学业，未能取到真经，浪费了这一来之不易的学习机会，是不是太可惜了呢。

遍 历一个数组或链表的时间复杂度是多少？对于这样一个不是问题的问题，竟然各地都有相当数量的学生回答说是 O(logN)！有一次我实在忍不住了，提示应聘的学生说：”你是如何理解’遍历’一词的涵义呢？”他立刻做恍然大悟状，回答说：”哦，对，应该是 O(NlogN)”。我当时失望得一句话都说不出来。类似的例子还有很多。坊间一直传说谷歌的面试题有多难，其实大多数学生都卡在最基础的问题上。少数人 费尽气力要收集谷歌曾经用过的面试题，其实我们大多数题目都来自或改编自经典计算机科学教材的习题。

顺便提一句，上面提到的那个答错的学生乃是一流大学中成绩名列前茅的优秀生，门门功课（包括所有计算机专业课）均在 90 分以上。反差何其大也！

诚信为本

我曾服务于多家公司，注意到不同的公司之间，乃至同一公司内不同的面试官之间，对应聘者的要求都会有所差别，或看重潜质，或偏好经验，或强调态度。但有一点大家是共同的：如果应聘者在诚信上有疑问，谁也不敢要。

总 体而言，现在的学生其诚信还是相当不错的，大大超出了我们的期望。然而，不和谐音也还是有的。我们曾在某著名高校进行笔试，就发现有学生严重作弊，他们毁 掉自己的机会不说，整个学校的名声也受到拖累。面试中偶尔也能遇到诚信堪忧的学生。有一次我出了一道题，前来应聘的学生明明以前见过这道题，却告诉我说没 见过，自以为得计，可他那一纵即逝的狡黠一笑哪里逃得过我的眼睛。两点之间直线最短，说真话最简单。

做最好的自己

不 是每一个人都会加入某一家具体的公司，但每一个人都可以成功，成为最好的自己。我这里所谈，既不系统亦欠简练，但确实是我在几次校园招聘之旅中发现的一些 具有共性的问题，故不避好为人师之讥，罗列于此。我当然知道，本文的首要目标读者——大一新生是不听劝的，他们更愿意把所有的错误亲自重犯一遍。话虽如 此，只要能够对一个学生有所启迪，我的时间就不算白费。

先看一个宣传视频, 喜欢无以言喻.

惊艳吧, 不得不承认 Apple 很有前瞻性, 把整个手机产业往一个新的方向带. 后起之秀们虽有模仿之嫌, 却也有赶超之势. 个人觉得 HTC Touch Diamond 已经很靓了, 不过总是只有溜口水的份, 袋里没钱嘛.

HTC Touch Diamond 是基于 Windows Mobile 的, 所以扩展性肯定没的说, 因为 iPhone 也开放了 SDK, 所以今后的平台扩展资源之争必定是很关键的, 有更多应用的才能吸引更多用户. 在 Apple 的带领下, 大家都开始注重 UI, 注重 “切换动作” 的可看性. 个人觉得 HTC Touch Diamond 在这里下了很多功夫, Apple 只是一个 “带加速度的滚动”, 但是 HTC Touch Diamond 有很多或许会被认为华丽却无用的 “效果”, 具体看视频, 比如 Contacts 的头像之间的切换, 照片的切换, Message 之间切换时文字的飘逸, Weather 的动态效果, 都很感人… 恩, 应该用感人这个词.

PS: 相较而言, 同样基于 WM 开发的魅族 M8 似乎不但开发太慢, 而且基于模仿的创新也太少了, 只剩下了模仿. 另外 Nokia 在这方面似乎也在努力, 但还未看到革命成果. 期待早日看到 HTC Touch Diamond 发售, 如果有米就入他一个!

下面是一些 Youtube 上的视频集合, 有兴趣的进来看全文~~~

一个简单的广告

外观的一些照片, 有点像我 GF 的 7500 Prism…

Hands-on video

Just another demonstration

作为 Vista 的绊脚石, XP SP3 终于 Release 了, 我用的是之前的 RTM 版本, 因为最终版本没有改动, 所以也就没有再折腾.

但是在 SP3 安装完以后, 默认的 TCP/IP 连接数又被改回了 10 (还是 20? 忘了…), 网上找到了 for SP3 的补丁, 分享一下. 感觉在 BT 或者迅雷的同时开网页的话这个连接数的修改还是很重要的, 不只是为下载提供更多通道, 也是让浏览器还有机会开网页… 补丁提示建议修改到 256 或更高~~~ 我改的 500… 没有最高只有更高!

点此下载 TCP/IP Patcher for XP SP3

PS: SP3 挺稳定的, 作为补丁集加小小的改动, 性能上是不会有太大的改进了, 不过 XP 已经比较完善和稳定了. 而且 XP 的 VOL 版本我特别喜欢 ^_^ 其实 Vista 的确挺好挺漂亮的, 不过谁赐我个正版序列号我再考虑装吧 囧, 何况我有我的 Hackintosh~

Consolas 是微软出的一款 for VS 2005 & VS 2008 的等宽字体, 写代码时用等宽字体看上去会比较舒服, 例如常见的 Courier New.

但是这些字体都只是英文字体, 不包含中文字型, 而作为 Vista 自带的字体, 微软雅黑是一款在 ClearType 下非常漂亮的中文字体. 下面提供的文件是两者的结合, 其中英文字体为 Consolas, 中文字体为微软雅黑, 这样中英文显示都会很舒服, 不用再为中文显示而让英文显示不舒服, 也不必为了使用英文的等宽字体而放弃雅黑了. 建议在各类 IDE 中使用.

点此下载 Consolas Plus MS Yahei 1.11

效率真高, 前一天笔试后一天就通知了, 那可是莽莽几百几千号的简历. 不管怎样, 算是通过笔试了, 挺开心的.
不过又很慌, 貌似第一轮面试的人还是很多的, 担心自己表达能力不够强, 底子也不厚.

人生第一次面试… 紧张…

唉, 硬着头皮上了! Jesus bless me~ 金钱豹等我来! 哇咔咔咔, 每周一次, 每周一次…

右键点击 QQ 主程序, 选择 “Show Package Contents”, 中文版大概就是显示包内容之类的.
然后依次打开 “Contents/Resources”, 该文件夹中有一个名为 msg.wav 的文件, 是 QQ 的消息提示音, 因为编码格式的问题, 导致了 CPU 100% 的占用率.
解决方法很简单, 删除 msg.wav 或者拿你喜欢的声音改名后替换.
这里我给一个从 Live Messenger 里转过来的提示音, 你复制进去替换就可以了.
另一个包是已经替换好了的, Preview 2 的, 给不会替换或者懒得替换的人用.
虽然问题解决了, 还可以自定义消息提示音了, 但还是希望腾讯加油让 QQ for Mac 更完美.
Enjoy~

点击这里单独下载 msg.wav

点击这里下载替换后的 QQ for Mac