总结 on 冯威的博客

2025 年终总结

Tue, 17 Feb 2026 02:16:00 +0800

岁月匆匆，华章日新，今年春节比较晚，现在 26 年都已经过了快 2 个月了。还是来对 2025 年做下总结吧。

整体感觉就是快，时间过得很快，AI 的发展速度也非常快。

怎么应对 AI 时代

从年初的 DeepSeek R1 到现在的 Agent Skills，几乎隔几天就会有新的模型、工具、应用出现。最近爆火的 Seedance 2.0 也在豆包移动端上线了。

我在手机上打开豆包，却不知道要做什么视频，因为我没有任何视频制作的经验。

所以说 AI 工具是在放大专业者的能力，而对菜鸟来说，只能是找点乐子的玩具。

[[AI 时代其实对人的要求更高了]]

放假前，在公司组织了一场 AI 技术应用分享。几乎所有人都用过 AI 相关的工具，但使用程度各有不同，对新技术和工具的了解和使用只是少部分人。很多人还停留在让 AI 协助排错的阶段。

AI 时代，持续学习显得尤为重要，持续关注、持续实践。

近一年也写了不少跟 AI 相关的文章：

[[理性看待 Manus]]
[[12个问题深入理解DeepSeek（含开源周内容）]]
[[在Windsurf中使用李继刚提示词]]
[[MCP 和 Function Calling：概念]]
[[MCP 和 Function Calling：示例]]
[[生成式AI 在 B端软件中实践的思考]]
[[A2A 介绍：概念篇]]
[[如何构建多智能体系统？]]
[[AI 时代，低代码该如何演进？]]
[[Agent Skills 全景指南：从概念机制到实战开发]]

成长

个人成长对我而言，是信息的获取到内化的闭环：输入阶段保持开放，消化阶段保持批判，内化阶段保持实践。

信息的获取源有：公众号、小红书、小报童、读库、得到、X、语鲸、Folo 。

语鲸和 Folo 是聚合工具，可以快速浏览，如果需要看原文的讨论，也能方便跳转过去。Get 笔记是最近比较喜欢使用的一款工具，支持公众号、抖音、小红书、B 站、小宇宙的链接分析。他们自己家的得到 APP 更是可以无缝同步。

[[我为什么喜欢用Get笔记了？]]

输出工具还是使用 Obsidian，而且用的更深入了，最近也准备写一篇 Obsidian 常用插件的使用。在没有找到合适插件的时候，也可以借助 AI 的能力自己写一个插件。

[[插件开发：实现Obsidian同步到墨问笔记]]
[[插件开发：实现 Obsidian 同步到 hexo]]

在 [[2024 年终总结]] 中我提到在 25 年要慢下来，注重消化。我自认为做的还是不错的。比如说我在看一些知识类的视频或书籍时，会选择在电脑端开着笔记工具去看，边看边记录，避免走马观花，觉得自己会了。

2026 年 1 月看了马伯庸和脱不花的长谈，学到了一个习惯：写日记。

这种记录日记的方式，只记录事实，不发表评论，希望 2026 年可以坚持下去，等到年末回顾的时候应该挺有意思的。

跑步

2025 年比赛历程：

3 月，仙桃半马跑到了 133 ，得益于赛道的平坦和天气的给力，425 的平均配速，平时可是连 10 公里都跑不到
4 月，云丘山越野赛 50 公里组别，虽然跑的慢，还是安全完赛
12 月，杭州隆 6 越野赛，42 公里组别，因为赶车而退赛

[[天气和赛道的加持，仙桃半马 PB 9分钟]]

2024 年终总结

Fri, 31 Jan 2025 16:30:00 +0800

律转鸿钧，新元肇启。2024 已然过去，这一年有很多的变化，特别是 AI 的发展迅猛，变化是好事，意味着有会带来更多的机遇，关键是我们需要时刻做好准备才能抓住。

下面还是按照我的习惯方式给 2024 年做下总结。

成长

在这个 AI 飞速发展的时代，各种工具层出不穷，按说效率应该更高更快，但我并没有觉得变得轻松了，反倒是更累。因为我们接收的信息需要消化才能转化为自己的知识，而在 AI 时代，同等时间接收的东西更多了，需要消化的就更多了，如果消化能力没有提升，就会很累。

还发现了一个现象，现在很难沉下心来进行长文的阅读，阅读长文需要「慢」下来才行，在 AI 这个「快」的时代，慢下来很难，但也可能会收获更多。

信息的处理工具很多还在探索中，这个探索是没有期限的，但总的来说有四个方面：

信息源：Follow、公众号、得到、小报童、读库
输入：flomo、get笔记
消化：暂无
输出：obsidian

所以 2025 年，我的关键词是：慢、消化。

跑步

2024 年立下的 Flag 基本达成：

跑量 2000+
全马突破 330
跑一次 70 公里的越野（目标赛事：崇礼 168）

2024 年总跑量 3000 整，虽然这个数字是凑出来的（最后几公里），但也体现了坚持的成果。11 月 17 日的光谷马拉松官方成绩是 3 小时 30 分 51 秒，算是勉强达成了目标。7 月去崇礼跑了 MTC 组别（70 公里），安全完赛，这是一个重要的突破。

2024 年的跑步历程：

3 月，PB 计划的训练结束，参加了石家庄马拉松，全马 PB 了 80 分钟
7 月，挑战 70 公里越野
11 月，全马又有小的进步

整个 24 年一直没有停下脚步，也取得了一些成绩。非常感谢跑者日历四群的陪伴。

25 年，已经确定的比赛有 4 月份的云丘山越野，其他就看缘分了。比赛不是关键，关键是能一直健康跑下去。

旅行

24 年的国庆长假依旧选择了自驾出行，不过这次多了些不一样的体验。以前的老同事一家和我们一起同行，女儿也多了一个玩伴，使整个旅途充满了更多的乐趣。

行程从武汉出发，途经池州、宣城、泾县、徽州、安庆，最后回到武汉。值得一提的是，出行的这些天，每天都坚持跑步，将运动和旅行完美结合。

公众号

因为始终坚持「为自己而写」的理念，今年的更新比较随性，一共只发布了 38 篇文章。

今年公众号的信息流策略发生了变化，推荐带来的阅读占比越来越大。比如最近写的《信创浪潮下的.NET困境与技术转型思考》就因为推荐获得了 6000 多的阅读量。

这个改变带来了几个影响：

即便是晚上或凌晨发布文章，也不会被淹没
对大众有共鸣的选题或热点事件选题，更容易带来更高的阅读量
标题显得更重要了，当然内容更重要

2025 年还会继续写作，可能更多、也可能更少，保持随性就好。

读书

今年在公众号输出了三本书的读后感：《笔记的方法》、《强风吹拂》、《华为项目管理之道》。但实际的阅读量远不止这些，在得到电子书看了不少书籍，还有读库、follow 上的订阅和大量的公众号文章。

25 年想多看看「闲」书，避免自己掉进信息茧房。有时候，跳出专业领域的阅读，反而能带来意想不到的收获。

播客

Follow 中虽然可以订阅小宇宙的播客，但因为不能登录，无法记录播放时长和评论，所以使用频率不高，主要是看看 shownotes。所以播客主要还是在上下班途中和跑步时听。

除了跑步相关的播客，今年听了很多商业和 AI 相关的节目：

OpenAI 连续 12 天 AI 发布会汇总

Sat, 21 Dec 2024 16:25:00 +0800

随着凌晨第十二天的 o3 模型的发布，OpenAI 连续 12 天的 AI 发布会结束了。下面回顾下这十二天都发布了些啥。

第一天

在 OpenAI 的第一天发布会上，主要发布了两个重要的更新：o1 的完整版本和 ChatGPT Pro 订阅服务。

1、o 1 完整版本：这个版本在多个方面实现了突破性进展，包括更智能、更快的响应速度、多模态输入能力（能够处理图像和文本信息），以及在指令遵循方面的表现更好。o1 在重大错误率上降低了约 34%，思考速度提升了约 50%。o1 模型现在能够同时处理图像和文本进行推理，这为视觉相关的应用开辟了广阔的应用前景。

2、ChatGPT Pro：这是一个高级订阅服务，每月收费 200 美元，提供了无限访问 OpenAI 最先进的模型 o1，以及 o1-mini、GPT-4 o 和 Advanced Voice 等功能。特别引人注目的是 o1 Pro 模式，这是 o1 的一个高阶版本，利用更强大的计算资源，深度分析问题并为最复杂的问题提供更优解答。

用户价值：

提升效率和准确性：o1 的升级版为用户提供了更快、更准确的服务，尤其在复杂问题的处理上，减少了错误率，提高了思考速度。
多模态能力：多模态输入的支持使得 o1 能够处理更多样化的任务，如图像分析和图文结合的创作等。
专业级服务：ChatGPT Pro 为高需求用户提供了更强大的功能和更稳定的服务，适合在数学、编程等领域需要极致性能的用户。

o1 完整版本需要 Plus 用户才能体验，ChatGPT Pro 对个人来说太贵了，况且那些高级推理能力一般人也用不上。

第二天

第二天的发布会重点介绍了「强化微调（Reinforcement Fine-Tuning）」技术。

强化微调技术：这项技术允许用户在极少的训练数据基础上，创建特定领域的专家模型。通过强化学习的理念，这一技术使得模型具备更自主的推理能力，并在各项指标上显著提升。强化微调能力可以让小体量模型「从高中水平跃升至专家水平」，预计将在 2025 年春季开放给用户。

用户价值：

定制化 AI 应用：强化微调技术使得企业或科研单位能够根据特定需求，快速训练出专家级别的 AI 模型，提升了定制化 AI 应用的可能性和效率。

第三天

第三天，OpenAI 发布了备受期待的 Sora 视频产品。

Sora 视频产品：Sora 支持生成 1080p 高清视频，并提供多种视频编辑智能功能，如替换元素、最佳帧隔离等，减少了视频创作的门槛。Sora 提供了文本转视频、图像转视频和视频转视频功能，并配备了精美的分镜工具，让用户精准指导视频创作。

用户价值：

视频创作民主化：Sora 的发布极大地降低了视频创作的技术门槛，使得普通用户也能创作出专业级别的视频内容。
创意表达工具：Sora 为创意人员提供了强大的工具，帮助他们更好地表达自己的想法和创意，推动了内容创作的创新。

最近看了檀东东的一个海螺和 Sora 对比评测视频，感觉 Sora 有点拉胯，有点对不起那么贵的价格。

第四天

第四天，OpenAI 为 Canvas 推出了三项重大更新，这些更新使得 Canvas 更加强大，为用户提供了全新的使用体验。

1、Canvas 全面开放与主模型集成：OpenAI 将 Canvas 面向所有用户开放，并直接将其整合到主模型中，免去了额外的加载步骤。用户可以直接从首页的输入框跳转到 Canvas，进行文档编辑和创作。

2、Python 代码实时执行能力：Canvas 集成了一个 Web Assembly 的 Python 模拟器，允许用户直接在 Canvas 中运行 Python 代码，并实时查看文本或图形输出。这个环境不仅能够实时运行与反馈代码，还能智能报错提醒和提供代码建议，极大地提高了编程效率。

2023 关键词：做减法

Sun, 22 Jan 2023 07:25:50 +0800

今天是 2023 年 1 月 21 日，农历癸卯年正月初一，新的一年开始了，祝大家：兔年大吉、大展宏兔、兔然暴富。

很多人都有一个惯性思维就是做加法，这样会比较“心安”，比如：看更多的书、学习更多的课程、让小孩刷更多的题、产品上添加更多的功能，似乎，多就是好。

为什么都爱做加法呢？

在少楠的知识资产中看到，人们爱做加法的原因多半是出于：

首先，我们默认在日常的事物中一切都是「合理」的，不需要减少。比如我们很少会怀疑教科书上有「冗余」的内容，或者使用的工具有什么「多余」的部分。

再次，损失厌恶。毕竟做加法没有什么损失，但是如果要做减法，就得做出断舍离的决策。所以人们默认会倾向于获得更多，而不是舍弃一些。

最后，做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。但如果少看了一本烂书，删掉了一些无用的东西，这种「减法」的好处很难直观地感受到。

而我决定在 2023 年要做减法，做减法可比做加法难多了，意味着要有更多的思考、更多的断舍离。

这个减法可以体现在很多方面，比如：个人成长、产品功能、代码架构。

个人成长

现在信息摄入的途径和内容都非常多，眼花缭乱。要很笃定的知道自己需要什么，然后把信息消化吸收后变成自己的养分。

所以，这里的减法是指内容的处理和消化。只吸收不消化，跟捡垃圾没什么区别。

枝叶需要进行修剪才能长得茂盛、铁路线越来越多，也需要合理规划、并站才能高效地进行调度，所以信息的获取不能一味的进行增加，还需要我们抽出来时间进行修剪，把核心的连接加强，把无用的节点删除或合并，才能让我们信息慢慢转化为自己的知识。

现在我的信息摄入途径有：

书籍：纸质书、电子书、樊登读书、读库；
社交媒体：即刻、知乎、豆瓣、B 站、小宇宙；
专业 APP：极客时间、得到；
其他：公众号文章、订阅的 RSS 和 Newsletter 。

2023 我想这样来做减法：

不设置读书目标，养成每天都看半个小时或一个小时的习惯；
看过的内容要思考做笔记和回顾；
尽可能地多输出、多和不同的人交流；
定期梳理笔记、抽取主题、形成文章。

个人成长的减法并不是说减少输入的途径，而是增加中间的处理和思考的过程，让积累的东西慢慢变少，沉淀出来自己的东西慢慢变多。

产品功能

做产品也是一样，要做减法，很多时候冷静思考，沉寂一段时间后，发现很多原先紧急的需求都可以不用做了。

为产品做减法，首先就是要搞清楚产品的定位。

定位不准确，就很容易什么功能都相加，加到最后就变成四不像了，看着什么功能都有，但又什么功能没有做到极致，甚至互相之间还是矛盾的。

假如产品的定位就是做一个给开发人员提升效率的低代码平台，明确了这个目标，就很容易知道哪些是可以不做的，比如：

完全配置化，不考虑二开；
按业务人员使用的视角去设计产品功能。

哪些是需要做的也很清晰：

能减轻开发的重复性的操作实现配置化；
提供各种批量操作，比如批量修改表单控件的属性；
提供二开的辅助调试工具，自定义组件、在线脚本能够更好地进行对接和排错。

产品功能的减法不是说啥功能也不做了，而是搞清楚哪些是可以不做的，该做的还是要按照正常的节奏去迭代。

代码架构

在产品的代码构架上会存在两个问题：

初学者使用复杂的架构解决简单的问题，而出现学以致用的幻觉；
因为各种「紧急」，而在项目中添加各种临时补丁或重复代码，这些通常被称为「技术债」，这些「技术债」会在以后有时间就处理，正常情况以后都不会有时间。

越简单的东西越容易理解，越不容易出错，所以在产品架构中要避免出现过度设计，架构方案需要进行评审。

上面提到的技术债，其实也是有时间处理的，比如，你们采用的是敏捷开发模式，在一个迭代周期内，所有人都是为这个迭代目标而冲刺，那么在迭代版本发布前，某些开发人员的开发任务已经完成，除了可以参与测试之外，就可以处理这些「技术债」。

代码架构的减法是通过这个减法让产品代码始终保持一种合理的架构，毕竟，合适的才是最好的。

最后

加法容易，减法难，那么我们选择难的这条路，必然会结出更艳丽的果实。而你也会因为走了这条难的路而更加光彩夺目。

2023 年总结（工作）

Thu, 19 Jan 2023 15:47:06 +0800

涂总，您好！提前祝您春节快乐。

组织架构的调整，使得我对产品的定位以及产品部门的职责变得非常清晰，前所未有的清晰。

最近一直在思考现有的问题和来年的规划，以邮件的形式跟涂总您分享下。

现状

1、目标一致性问题

目标如果不一致，所有的方向都很使劲，但会停留在原地。

2022 年上半年，项目的需求到不了我这里，而我们做的事情对项目的落地和增效又没有任何帮助。

项目组的需求得不到响应会有两个后果：

项目要想各种变通的方式来实现功能，花更长的时间；
变通的方式可能不是客户想要的方式，客户的体验差，这些日积月累的不好的体验可能就是日后投诉的根源。

甚至一些个别项目禁止使用二开，采用完全搭建的方式来实现，满足不了的地方需要借助一些第三方工具，这些工具都有学习成本，最终结果就是实施周期变长。

2、搭配问题

人无完人，我们需要充分利用每个人的长处，这样就可以拼成任正非所说的「高桶」。

元旦后，我被琪雅拉进了葛洲坝路桥的项目群，目的是要做技术支撑，经过几天的紧急问题处理和事后的分析复盘，发现了一些问题：

项目的顶层设计出现问题，交付给客户的是一个考评系统，互相交叉评价会产生大量的数据，没有提前预判；
技术上错误地使用数据库触发器，导致大量的表死锁，导致考评数据的生成不及时、客户使用过程中频繁出错；
不得不中途修改方案，这是项目实施大忌；
项目组成员非常幸苦，元旦假期加班、周末加班、工作日也每天晚上很晚还要响应客户的问题。

让本来不到一周就能顺利完成的事情，最终花了两周多的时间。

我在想，项目是不是应该分下类型，适合一线人员做项目经理的，就由一线人员担任；适合二线人员做项目经理的，那就应该让二线人员来担任？

每个人还是要在适合的位置，才能发光发热。

3、加减法问题

做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。

正是因为这种思想，产品上会不停地加功能，说好听点，产品功能非常丰富，说不好听的，臃肿，易用性差。

那产品应不应该加功能呢？答案是肯定的。产品团队肯定要按照节奏去迭代产品，但出发点是以项目落地增效为导向、以一线实施人员的使用痛点为导向、以最终用户的用户体验为导向。

以这些为导向，那产品的迭代就不完全是功能的叠加，而是：

解决用户实际问题的功能的增加；
某些功能使用体验的优化；
某些淘汰功能的弱化甚至删减。

4、复用问题

在代码架构中经常说要提升代码的复用性，目的就是为了提升效率。

在 2022 年了解到存在升级难、迁移难的问题。

葛洲坝事务系统花了很大精力做完，需要迁移到其他项目，有大量的改造工作，接近重做；
省厅的项目想要迁移到其他地方，也几乎不可能，或者说需要花费大量的精力；
江铃从版本 6 是升级到 7，前前后后花了好几个月。

很多项目应该是能盈利的，但因为升级和迁移的不顺畅，最终可能导致赚不了钱，甚至亏损。

我认为这一部分也应该作为产品团队 2023 年工作的重点。

2023 规划

目标清晰了，事情就好办了，剩下的就交给时间，静待花开。

根据涂总的的指示，我理解的产品部职责如下：

作为项目落地的强有力支撑；
项目资源不足，产品优先支持响应；
产品功能的迭代必须是能提升项目落地效率、提升用户体验。

目标明确，所以，2023 ，我非常有信心。

年前跟团队的每个人面谈时，我说我们应该往一个终极目标去努力，就是将 S2 交付给一线或二线之后，他们不会来找我们了，这样，我们可以做更重要的事情。

这个不找不是说部门之间有墙的屏蔽，而且他们自己在实施和运维的过程中碰到问题，可以自己找到答案。

当然，达到这个目标很难，可以先从下面的一些方面先入手：

收集一线人员的想法，他们跟客户直接接触，能更清楚客户的问题和习惯，以此来反推需求（已经跟一二线人员做了座谈）；
构建内部文档库，使用引导的方式进行让实施人员能自己找到各种问题的答案；
平台代码层优化，让每一个异常情况都是明确的，有路可寻的，运维阶段的问题排查可以大大提升效率；
项目代码的提交记录要和任务进行强绑定，为迁移和升级做好保障；
将项目运维过程中的很多重复性工作，工具化。

一定要打破「又不是不能用」这种错误的思想。

2022 年初，我在团队实行敏捷模式，大家觉得效果不错，沟通变多了，问题变少了。后来由于一些阻力没有继续。2023 年我将恢复敏捷模式，三周一个迭代，有序地进行平台功能的升级。

每个迭代的内容会和项目团队进行沟通确认，然后跟涂总您进行汇报，确保所做的事情都是有用的，有效的。

最后，我想说，不管经济形势怎么样，疫情是否反复，只要大家心是齐的，就不惧怕任何困难。

2022 年读过的书和 2023 年阅读规划

Mon, 16 Jan 2023 09:15:11 +0800

2022 年读的书不多，可以找到很多的理由，但我觉得根因还是没有养成一个好的读书习惯。年初制定了每月至少阅读两本非技术书籍的目标，看似非常容易，但到现在一回顾，发现差的很远。

2022 年终总结

Tue, 03 Jan 2023 09:00:23 +0800

往年的年终总结都是在春节期间写，但元旦确实是更好的一个分界线，所以便决定今年开始在元旦左右来写年终总结了。

技术人如何打造个人品牌？

Mon, 20 Jun 2022 08:20:20 +0800

对技术人来讲，个人品牌非常重要，个人品牌的建立是自我营销的一种方式，也是提升个人价值的一种方式。

那什么是品牌呢？一篇文章、一个视频火了，这个不算是品牌，如果提及某个领域，大家能想到你，这就是品牌了。

当谈研发效能时，在谈些什么？

Wed, 01 Jun 2022 00:00:00 +0800

最近翻了下之前写的公众号文章，发现研发效能相关的就有三篇：

怎样提高开发效率
关于增效，需要做好这两点
再谈研发效率提升

从工具使用、业务的理解、团队的沟通协作到流程、组织、分享等内容，我能想到的大部分有关研发效能的点都有涉及到。

做个成年人

Mon, 23 May 2022 00:00:00 +0800

奈飞内部曾经流传出一份企业文化的 PPT ，被誉为硅谷最重要的文件，后来这份 PPT 经过重新整合出版，就是《奈飞文化手册》。

在《奈飞文化手册》中介绍的第一个文化准则就是：我们只招收成年人。

这里所说的成年人不是年龄上的成年，而是心智上的。所谓成年人，就是有责任，有担当，能控制好情绪。

程序员还有35岁的坎吗？

Mon, 23 Mar 2020 07:48:55 +0800

昨天晚上和一多年未见的前同事聊天，提到了程序员的年龄歧视问题：

自己年龄也 30 出头了，在思考 IT 届流传的 35 岁是一个坎的问题；
开始注重提升管理能力，担心35岁之后，一线写代码的岗位不能胜任；
公司在招聘新人的时候，有明确的年龄限制。

远程办公也可以高效

Mon, 09 Mar 2020 07:19:57 +0800

因为疫情，全中国人民都过了一个难忘的春节，而身在武汉的我，更是没有出家门半步，坚决做到不过国家添乱。从开始的2月14到后来的2月20日，再到现在的3月10日，官方发布的复工日期一次次的推迟，我们也做好了长时间远程在家办公的准备。

写公众号的这一年多

Tue, 28 Jan 2020 14:29:57 +0800

2018年五月，在微信发布公众号助手之时我开通了个人公众号「不止dotNET」，到现在已经一年半多的时间了，非常时期，在家自我隔离，没事写写总结。

2019 年终总结

Sat, 25 Jan 2020 14:21:57 +0800

老板每次跟我们开会总会说起写总结的重要性，很庆幸我一直都有这个习惯。依然是要在大年初一到来之前写完这个总结。

2014 年终总结

Thu, 19 Feb 2015 00:00:00 +0800

本文已是今年写的第三篇总结了，为了得池大大的一本书写了第一篇总结，还好结果还算不错，《第一本Docker书》已在邮寄的途中；第二篇是公司要求写的个人总结。本篇还是以生活和工作两方面来写下2014年的点点滴滴。

生活

2014年5月16日，女儿顺利降生，这是今年最大的事情了。有了女儿，家里更热闹了，不过时间也更少了。现在每天的生活都是这样的：

1、白天上班，不加班的话下班到家将近7点；

2、9点之前我跟女儿的互动时间，这期间老婆做饭、吃饭、跳操等等；

3、9点后老婆哄女儿睡觉，我就有自己的时间了，或处理工作上的事情、或看书学习、或写写代码，或看看电影美剧；

4、如果没有特殊的事情，通常都会在12点前睡觉，早上一般5点半或6点起床，7点40驱车上班。

早在老婆怀孕的时候，和老婆商量无论生男生女都叫”fengzihan“这个读音，随即就注册了fengzihan.me的域名，作为女儿的个人网站。前不久将之前的空间迁移到了Linode的VPS，并将女儿的站点搭建起来，由老婆执笔记录女儿的成长。

工作

2013年底才来到现在这家公司，公司很小，项目型公司，研发人员有的在公司，有的在客户现场。公司之前的代码各个项目是分别管理，有的用snv，有的用tfs，有的甚至都没有使用源码管理工具。

所以2014年上半年我做的第一件事就是将公司所有代码进行梳理，并迁移到git上，这样再也不用担心这种分布式的人员了。因为当时公司外网服务器的原因，使用的是开源中国的git托管，目前准备使用gitlab在公司服务器上搭建git环境。最近开源中国的git托管做了升级，越来越有github的味道了。

2014年上半年第二件事是将公司的主后台管理平台进行重构:

1、使用Bootstrap进行UI重构，后面的项目实施中有不少客户觉得很高大上；

2、项目的组织方式进行了重构，这可以算是比较大的一个手术，需要了解整个平台的很多细节。调整后的好处是更便于项目的分模块开发和部署。

2014年下半年也做了两件事，由于公司项目太多，人手不够，我被推到了项目经理兼技术经理的位置，带着3、4个人历时5个月做了一个项目。小公司就是这样，可能会涉及很多的角色，这不，第二件事就是负责招聘，整个下半年面试了近百人，只招进了5个人。

总体来说，整个2014年很忙碌也很充实，2015年会做更多基础平台完善和团队建设的事情。

2015年展望

1、老婆顺利考到驾照；

2、女儿健康快乐成长；

3、书架上的书能慢慢看完并消化；

4、2015年冠上了产品部经理的头衔，15年要带领团队好好做产品；

5、团队建设。

2013 年终总结

Sat, 22 Feb 2014 00:00:00 +0800

从毕业后几乎每年都会写一篇总结，而且习惯子农历的新年前写，在我的思想观念里，农历的新年才算过年。今年也不例外，不过由于一些原因推迟到年后了。还是从工作和生活两方面来总结下即将过去的2013年。记得去年的总结最后写的对2013年的展望是这样的：

能尽快的把驾照拿到手；
准备要小宝宝；
买车；
工资有所突破；
职位有所突破；
深入研究几种技术，性能优化为主。

除了第六条，其他的都已达成，还是比较欣慰的。

工作

去年利用业余时间做了一个工具，并在部门内使用起来，在年终获得了一些奖励。不知道是不是因为这个原因，今年年初的人才盘点我的职位被调成了Team Leader，公司的Team Leader主要职责是技术攻关和团队建设，而团队成员的积极性方面则不需要过多操心，因为有绩效制度在鞭策。

2013年夏天，一个做企业信息化的小公司希望我能加入他们，经过几次沟通后，我最终决定了加入这家小公司。之前的公司算的上是一个中型公司，在武汉这边的研发就有4、5百人，而且也基本上做到了行业老大的位子，部门老大对我也很不错，上升空间还是很大的，按理说我应该不会离开才对。但正是因为公司比较大，各种规范流程比较繁琐，而且还有很“不合理”的KPI考核，尽管每年都在做优化，每个人员都各司其职在条条框框内做事。这些方式方法的存在肯定有其道理，作为管理者来说，依赖这些规则可以节省成本，提高效率，但我却很不喜欢，所以我选择离开。

经过半个多月的交接，9月1日到新公司报道，在这里的自由度相对较大，也能做自己喜欢的事情，自己所学的东西在工作中能够得以施展。到现在已经近半年的时间，工作还是很开心的，希望能再接再厉。

生活

12年的一次错误决定，导致我现在得时不时的回家去，因为在家里报的驾校，起初的原因是户口在老家，而且当时老家的报名费比武汉要便宜1000多，现在看来真是得不偿失。体检得回去、科目一的测试得回去、科目一的考试得回去，当然这些都只是周末，最后发现到练车的时候不是仅仅周末回去就能解决的。无赖之下请了一个月的假回家专门学车，正值夏日，每天早出晚归，其实也只能练习5、6次，其余的时间都是在等待中，等待中的时间除了聊天还是聊天，驾校里会有形形色色的社会人或是学生，与人聊天或是听人聊天感觉也还不错。一个月的时间就这样机械化的度过了，也顺利的考过了科目2，最终10月份拿到驾照。

9月份的一次检查得知老婆怀孕，也没有什么特别的感觉，因为一直也在准备在事。之后老婆说能感觉到胎动的时候，我用手也能感觉到的时候，特别的兴奋，可能在这个时候才真正感觉到这个小生命的存在，之后的每天睡觉前，我都会和小宝宝说说话。让人欣慰的是从怀孕到现在的产检都比较正常，现在很期待在5月份看见宝宝的样子时的感觉。

2014展望

5月宝宝能顺利出生；
工作上能跟进一步；
持续学习，不局限于编程。

2012 年终总结

Wed, 16 Jan 2013 00:00:00 +0800

在我的2011年总结是以年度记事作为开头，2012虽然特别，但对我来说还算是比较平淡的一年，并没有很多事情发生，所以2012年的总结就以工作和生活两个方面来说。

2011 年终总结

Sat, 14 Jan 2012 00:00:00 +0800

2011年记事：

2月从北京返回武汉
3月进入一家做信息化的IT公司A
5月和老婆领证了
7月因A公司频繁出差，跳槽到了B公司
8月买房子
10月结婚 2011年对我老说是重要的一年，人生中的几个重大事情都发生在这一年。

回武汉

在北京呆了还不到一年的时间，按照之前的计划本不应该选择在2011年初回武汉的，但因为计划2011年结婚，婚前必然有很多的事情要准备，所以经过多方面考虑还是决定2011年回武汉，这次回了就是要定居武汉了。

进入公司A

选择回到武汉，那么回来后的工作是首要问题，经过朋友介绍谈好了一家做企业信息化的公司，电话中沟通过几次，后来回到武汉去公司和开发部的经理以及公司老总进行了面谈，双方感觉还不错，3月份顺利入职。可能是之前沟通的不够充分，入职后发现后想象的不一样，频繁的出差让我不能接受，可能有些朋友喜欢出差，但对于即将结婚的我确实不太适合。再三考虑之后我提出了离职，老板和部门经理强力挽留，说把我调回到武汉的一个项目中，不用去外地，但我的态度很坚决，最终还是辞了。因为即使这个项目在武汉，下一个可能有得去外地了。对于这次离职我心里感觉不是很舒服，毕竟老板和部门经理对我不错，而且也极力挽留，只能说我的需求和公司的特点不适合。

领证

5月20日是老婆定的，也算是一个比较有纪念意义的日子。关于领证那天发生的事情，请看-纪念日-领证

进入公司B

其实在公司A的后半段我就已经将51上的简历更新了，随后就接到了很多公司的面试电话，基本上都被我推掉了，最终也就面试公司B一家，之前对B公司也有一定的了解，而且以前有同事在B公司也跟我介绍了一些情况，面试顺利通过，但由于面试是发挥的不是很好，薪资还不如在A公司的。之所以选择B公司有以下三个原因：

1 公司规模大，开发流程规范；
2 不用出差；
3 每周公司都有篮球活动。

买房子

老婆一直都想买市区的房子，比如软件园附近的。我们也去看过“锦绣龙城”的房子，那会二手的毛坯房也得6000多一平，这个价格在武汉来说也不算很贵了，但算下来交首付然后每个月几千的还贷压力还是不小。经过一番周折最终买的是老婆亲戚家还建的房子，离市区稍微远了点，但价格便宜。还不到3000一平，80平的房子也就在市里买房的一个首付。老婆后来一直都抱怨说应该买市里的房子，嫌那个太偏了，不过我倒是觉得挺好：

1 到鲁巷的车程也就20多分钟；
2 离老婆家很近；
3 不远的地方就是一个高速的入口，如果有车走高速1个小时我就可以回家了；
4 买这房子压力相对小，以后买车就变得现实了。

买房子期间老婆家里人忙前忙后帮了很多忙，真的是非常感谢。也请老婆放心，我会努力赚钱早日买车，这样你就不会嫌远了。

结婚

结婚是在10月3号，所以去了不少同学，为了热闹还请了我们市里面的婚庆公司来策划。对于我们那小地方来说也算是不错的了。有关结婚的详细情况，请看-结婚小记，婚后我和老婆去的三亚度的蜜月，这可能是很多新人在国内蜜月的首选，我们也没能免俗。蜜月1–我的蜜月之旅

这就是我的2011，经历了很多事情，一年下来忙碌而充实着，人也成熟了很多，期待更精彩的2012。

回顾2010 计划2011

Wed, 05 Jan 2011 00:00:00 +0800

2010年对于我来说是不平凡的一年。

2010年我脱离了单身，找到了属于我的幸福。

2010年我不远千里从武汉来到北京，一方面寻求事业上的发展，同时和小妹也算有个照应。

2010年3月2号是个很特别的日子，就是在这一天我脱离了单身。也是在这一天我们相聚又别离了，我来了北京，她仍在武汉。1个月后我在北京西站接到了她，从此便开始了近一年的甜蜜蜗居生活。

北京的工作相对于武汉来说有更多的机会，所以找工作还算比较顺利，两个星期的东奔西跑迎来了3份offer，再三思考权衡之下选择了工资不是最高但最有发展最能学习技术的公司留下了，也就是现在就职的公司。

在公司的8个月的时间里也发生了不少事情，第一个项目的搁置、长达一个月时间的无事可做、换项目组、头的离职乃至公司内部的一些变动，尽管这些让人感觉有些动荡，但也学习到了很多，并且公司的一些制度还是非常人性化，弹性时间的上下班，平时有事请假可以算到日后调休等等。所以我还是很希望自己能在这里长期待下去。

2010端午节老婆的姐弟来北京玩，短短几天的时间跑遍了很多地方，很累但很难忘。

2010年国庆节我们为了一张回家的车票起很早去排队，最终还是不得不请了3天的假提前回家。这次是离开学校后离家最长的一次，所以回家的心情也格外激动。还有件更重要的事情就是十一要去老婆家上门，还好整个过程非常顺利。

总体看来2010年还算是比较顺利，顺利让女友来北京；自己顺利找到工作；幸运的找到现在所租的房子；国庆顺利的上门，年底顺利的买空间域名搭建我和老婆的小窝。希望在2011年各方面能做的更好。

2011年对我来说是充满期待的一年。 2011年我将会走进婚姻的殿堂，延续我的幸福。

2011年我也许会从北京回到武汉，找个稳定的工作，过上稳定的生活，当然仅仅是也许。

2010年很多事看上去很顺，但缺少规划，一切都是按部就班，顺其自然的在进行，这个主要是指技术学习方面。所以2011年在技术学习上要有计划，基本要按照计划来执行，比如学习一门动态语言Python，学习一门函数式语言F#等。

2011年应该是很忙碌的一年，春节后可能面临着工作的变动，五六月份要和老婆去照结婚照，10月举行婚礼，希望这些都能顺顺利利。

2011年对于技术的学习，大致规划如下，具体可能根据实际情况做相应调整。

学习Python
学习F#
关注软件架构方面研究（涉及设计模式、并发、性能等）
根据需要学习DotNet相关的框架
所买的书争取看完，关键是要吃透

写于2011年1月5日北京天通苑