本文永久链接 – https://tonybai.com/2025/08/06/blitzkrieg-vs-attrition-in-ai-age

大家好，我是Tony Bai。

最近，我们的社交媒体时间线上，充斥着各种令人惊叹的 AI 效率神话。一些出海独立开发者，凭借 AI 的强大能力，在极短时间内“闪电般”地产出数个产品，上演着“一人成军”的传奇。

这景象，在令人惊叹之余，也难免给我们这些在大型项目和复杂系统中深耕的工程师，带来一丝焦虑：世界变化这么快，我们传统的开发模式和节奏，是否已经落伍了？

今天，我想和你深入探讨这背后的本质。我们需要清醒地认识到，这其实是两种目标、路径、评价体系都截然不同的开发模式。我称之为：“闪电战”与“持久战”。

“闪电战”模式：速度优先的“代码喷射器”

首先，我们必须理解那些“效率神话”主角们的战场。这是一种典型的“闪电战”模式。

• 核心目标： 快速验证想法，通过大量的产品“赛马”，在广阔的市场中捕捉稍纵即逝的流量和商机。
• 产品生命周期： 极短，甚至可以说是“阅后即焚”。一个产品可能只有一周的生命周期。若数据不佳，便会毫不犹豫地被下线，开发者则迅速转向下一个想法。
• AI 的角色： 在这个模式下，AI 是一个速度优先的“代码喷射器”。它的核心任务是在最短时间内生成能运行的代码。至于代码质量、设计一致性、可维护性、乃至长期的技术债，通通不在首要考虑之列。因为代码本身，就是一种“快速消费品”。

我们工程师的“持久战”模式：严谨可靠的“副驾驶”

现在，让我们回到自己的战场。我们绝大多数人从事的，是截然不同的“持久战”。

• 核心目标： 构建稳定、可靠、可长期演进的系统。我们写的代码，很可能需要在金融、医疗、基础设施等关键领域，7×24 小时不间断地运行数年。
• 产品生命周期： 长期，以年为单位。每一次代码提交，都是在为一座摩天大楼添砖加瓦。
• AI 的角色： 在这里，AI 必须是一个严谨可靠的“副驾驶”。它生成的每一行代码，都必须经受我们最严格的审视。因为我们，作为工程师，需要对 AI 产出的质量、安全性、性能、可维护性负全部责任。在这里，代码不再是消费品，而是需要长期持有和维护的核心资产——或者，沉重的技术负债。

看清这一点，我们就能明白：用“闪电战”的效率标准来衡量“持久战”的工作，是毫无意义的。 我们的战场不同，评价标准也完全不同。因此，我们完全没有必要为那种“一人一天N个产品”的神话而感到焦虑。

我们“持久战”工程师的 AI 打法与“护栏”

那么，在我们的“持久战”中，应该如何正确地使用 AI，既享受其带来的效率提升，又保证工程质量呢？关键在于建立清晰的“护栏”。

1. 代码审查是最后防线： AI 生成的代码，必须经过比人类编写的代码更严格的审查。审查的重点，不应仅仅停留在功能实现，更要深入到安全漏洞、性能陷阱、设计模式是否恰当等深层问题。

2. 建立团队级“Prompt 知识库”： 鼓励团队沉淀高质量、包含完整上下文和明确规范要求的 Prompt 模板。这能保证 AI 输出的“起点”质量更高，更符合团队的架构和规范，而不是每次都从零开始“随机”生成。

3. AI 专攻其擅长领域： 我们可以放心地让 AI 生成单元测试、API 文档、数据结构模板，或是在明确的模式下进行代码重构。但在核心架构设计、复杂业务逻辑实现等“高风险”领域，AI 只应作为提供思路参考的“顾问”，绝不能成为决策者。

4. 引入“AI 生成”标识： 在代码提交或 Code Review 流程中，可以引入规范，要求开发者明确标识出哪些部分是由 AI 主要生成的。这就像在施工图纸上标注出“预制件”，提醒审查者需要重点检查其接口和集成质量。

小结：认清你的战场，定义你的价值

首先，我们需要明确一点：“闪电战”与“持久战”之间，没有高下对错之分，只有战场类型和战略目标的不同。 如果你是一位寻求市场机会的出海独立开发者，那么“闪电战”无疑是极佳的策略。它能让你以最低成本快速试错，抓住机会，并在数据不佳时果断放弃，及时止损。这是一种聪明且务实的生存之道。

而对于我们绝大多数在企业中构建关键系统的工程师来说，认清我们身处“持久战”的现实，并重新定义我们在 AI 时代的价值，则至关重要。我们的核心竞争力，正在加速地从“编写代码”，转向“定义问题、设计系统、制定标准、审查质量、保障稳定”。

AI 越是能高效地“写”，我们就越需要成为那个能提出正确问题、设计出健壮蓝图、并能精准鉴别优劣的“架构师”和“质检员”。我们的工作变得更“上游”，我们的思考变得更具决定性，我们的价值也因此而更高。

所以，朋友们，请放下焦虑。清晰地认识到自己的战场，然后拥抱 AI 这个强大的“副驾驶”，在我们的“持久战”中，更高质量、更有效率地去构建那些真正能够改变世界、并经受住时间考验的系统。这，才是属于我们的战场，和我们的荣耀。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2025, bigwhite. 版权所有.

刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。

* 缘起

我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前，我们终见其导致的巨大的影响了。

由于客户方成本压缩，单节点性能低意味着需要更多的硬件投入，并连带着报价升高，导致我们的产品市场竞争力下降。而竞争对手产品的性能是我们的 3-5倍，这终于引起了领导的重视，并下达了开发高性能版本的任务命令。

* 抉择

遗留系统的问题有很多，性能差仅仅是表象之一。可维护性差更让人印象深刻。遗留系统就像一件打满补丁的旧衣裳，虽然依旧能穿着遮体御寒，但却让我 们时刻战战兢兢，生怕一个动作会导致它解体，变得支离破碎。

对于我们这样一个mission-critical的系统来说，开发周期显然是不会短的。在性能达标的同时，更为重要的是保证产品的质量，确保上 线后运行稳定。因此摆在我们面前有两条路：
    1、在遗留系统上做“大修” – 大规模重构；
    2、重写，把构成系统的骨架重新设计和实现，使它能够足够坚固，满足在“高速公路”上驰骋的要求。

我们最终选择了重写，也就是风险较大的那条路。在我们的理解中，重写软件就好比汽车升级平台，就像大众将传统的PQ25、PQ35等统统升级为 MQB平台那样。平台的升级，不光影响技术，还会影响方方面面，比如团队的能力、思维方式、合作模式以及团队过程改善等等。做 得好的话，会使整个团队迈上一个新台阶，这是原地修补所不能够带来的。

对于我个人来说，这也是我期望中的实验田，我将把之前研究的诸多实践落地，帮助团队提升能力。

自私地说，重写系统也是我的一个小理想，能遇到这样一个从无到有构建一个系统的机会是不多的，因此很是希望能看到一个系统一点一点的在自己的呵护 下“成长”起来。虽然我也清楚完成这样一个系统需要很长时间，而这期间我可能需要时刻紧绷着神经，直到系统正式上线后，才能感受到那一抹释然。

* 建立“骨架(skeleton)”

我们将项目分成两个阶段：建立系统“骨架”和为系统“添肉”，即添加业务逻辑。

系统的性能目标是原遗留系统的10倍，这样我们建立的骨架的性能至少要高于原遗留系统的10倍。在“添肉”之前我们要充分证明骨架的设计是合理、 有效、稳定和高性能的。

遗留系统性能低，并非因为当初的设计者能力有什么问题，更多是局限于当初的设计目标。系统初期业务量不大，接入的外部网元不多，因此系统大量使用 了链表这种简单但低效的数据结构；为了easy coding，当初的设计者选择了全局大锁；在客户端-服务器处理模型上，选择了一个连接一个进程的“高耗能”模式。最初这样的设计应对当年的业务量也是 绰绰有余的，但应付今天的业务规模就显得颇为捉襟见肘了，以至于我们不得不通过罗列机器来满足业务增长的状况。服务器增多，却导致了我们维护 和监控难度的增加。

为了应付现有业务量规模以及未来若干年的业务量增长，我们的新系统的骨架在设计时显然要扬长避短：
    – 我们重新设计了通用的服务端框架和客户端框架，使得系统各个业务模块采用相同的通信处理机制；
    – 我们没有选择线程，而是依旧采用成熟的进程（资源隔离式） + IO多路复用（linux下epoll机制）的服务器-客户端模型，与以往不同的是，我们在每个进程中处理多个链接，设定进程数量在合理水平，避免大量上下文切换带来的性能损耗；
    – 将传统的全局big lock更换成了细粒度锁；
    – 采用高效的数据结构和算法，比如用hash和array替代掉list等；
    – 用简单队列替换掉原先复杂的队列调度结构，降低代码理解难度和后续维护门槛。
    – … …

我们要求对骨架代码进行严格的单元测试，通过lcut为骨架代码建立起单元测试集，并结合持续集成对骨架代码进行持续的单元测试验证。

骨架完成后，我们对其进行了全面的压力测试，确保其性能水平达到我们设计要求，这是我们进入下一阶段的前提条件。

* 添肉(business logic)

有了稳定、可靠、高效的骨架，我们在”添肉“阶段就更加有信心了。用C写纯业务逻辑是苦逼了一些，但还好我们没有全部将以前遗留代码扔掉，我们为了保证功 能Feature不丢失，我们会尽量复用之前的业务逻辑，当然是“规范地”搬到新系统中的，尽可能地去除原有代码中的Bad smell。

与骨架相比，业务逻辑相对复杂，且耦合较多，因此对这些业务逻辑做单元测试真是一件让人头疼的事情。不过这也和我们最初的估计相符，最初制定的策略就是对骨架代码做高覆盖，对业务代码则宽松些，尽量覆盖即可。

* 附加实践

就像前面所说的那样，围绕着这次重写系统，我策划了很多实践有了落脚之地，包括：
    – 试点知识管理 ：通过这次重写，建立起关于该系统的知识库；
    – 增加基于ReviewBoard的在线代码评审环节；
    – 引入基于Jenkins的持续集成；
    – 重新思考和设计构建环节，通过buildc提高构建效率；
    – 重新设计通用安装包；
    – 使用LCUT对骨架进行单元测试覆盖；
    – 规范commit log以及代码提交流程；
    – 应用代码风格检查工具，使得所有代码风格一致。

事实证明上述实践在这次系统重写的过程中产生了很好的效果，尤其在代码质量保证方面，系统上线后的结果也恰恰印证了这一点。

* 上线

“丑媳妇总要见公婆”。我们的新系统也到了该上线服务的时候了。为了这次上线，我们做了较为充分的实施准备，无论是人员还是时间，都有倾向性的向这个系统 投入。我们也提前做好了应对各种突发问题的预案。可实际情况出乎预料，与遗留系统的版本升级相比，这次全新系统上线显得十分顺利，系统的核心相当稳定，出 现的一些问题也都比较边缘，对这次成功上线已经不构成什么影响了。

* 那一抹释然

在实施人员庆贺上线成功时，在领导口头表扬时，我的内心却显得十分平静。对于新系统来说，这是一个好的开始。对我个人来说，我感受到了那一抹期望已久的释 然。在这个领域里这个方向上已经摸爬滾打了多年，虽然还有好多地方需要改进，好多实践需要完善，但我的内心告诉我：“够了”、“已经没什么牵挂了”、“是 时候换换方向、换换领域了”、“让其他人去做吧”。我已经在产品和团队中融入了我的思想，我相信他们都能很好的演化和发展。而我则为接受新思想、新领域做 好了准备。

的确也到了为自己设立新目标的时候了！

© 2013, bigwhite. 版权所有.

关于我的工作原则，感觉之前的那篇总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。

* 重塑标准

简单来说就是根据组织实际情况，重新建立各种标准 – 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。

* 问题理解要透彻

很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。

* “眼见为实”还不够

俗语讲：眼见为实。但在工作中，有些时候“眼见为实”还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的“事实”。要追求逻辑的全局合理性，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。

* 把事情做在前面

以推进知识管理为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。 

© 2013, bigwhite. 版权所有.

下面是这两年来部门内部知识库建设的一个Timeline：

- 2011年中旬，我所在产品线私下在一台PC上建立了基于MediaWiki的知识库。
- 2011年末产品线在部门内部做了有关知识库与知识管理实践的分享。
- 2012年初，部门在新采购的高性能服务器上建立基于MediaWiki的知识库，并指定专人负责；我们产品线将已经积累的内容迁移到了部门知识库中，这 也标志着部门知识库1.0版本正式上线。知识管理的策划和推广事宜也交由专门的子部门负责。
- 2012年中，设立子部门KM负责人，设立子部门KM定期工作会，设立子部门技术交流汇报会，旨在各子部门之间分享最新信息，减少重复劳动，提高效率。
- 2012年末，启动知识库2.0建设方案。
- 2013年3月末，知识库2.0版本上线。邀请专业设计人员策划和实现了全新主页，提高了UE；重新策划了分类；重新划分了知识版块，专人负责更新；增加 了知识达人等多个激励内部童鞋分享知识的手段和方法；通过piwik统计和分析知识库的最新访问动态；通过一些实用的插件来简化Wiki Page编写工作、更好地展示内容；提炼高质量知识文章，形成知识周刊、月刊，作为内部知识库营销推广手段，吸引大家来到知识库，并尝试留下自己的知识。

两年来，我这个“始作俑者”在知识库建立起来后已经不做什么具体的工作了（骨子里其实是不愿意做重复性、事务性工作），只是充当着“幕后推手”。值得我庆幸的是有那么几位同事都认同知识管理 的重要性，愿意参与进来执行具体的工作。专职负责知识管理的子部门的领导也十分重视此事，这才有了部门知识库的持续演进，才有了目前的2.0版本 上线，他们才是真正的猪角。

这两年来，我在知识管理方面所作的工作主要有如下几方面：

* 找人，形成圈子

知识管理和推广虽然重要，但并非核心业务，不能显式地让大家看到其对部门发展的贡献度，因此多数人对此工作并不感兴趣，找到适合且对此有兴趣和热 情的人也就并非易事。另外还要得到相关子部门领导的长期支持，事情才好持续办下去。在1.0上线后，经过大半年的观察，我们找到了真正合适的人 选。也有两位志同道合的子部门领导十分重视此事，也亲自参与到知识库建设的交流讨论中。这样一个知识管理和推广的小圈子形成了。

* 识别广泛的需求，形成可行性共识

最初之所以在产品线私下建立起Wiki知识库，显然是因为我们遇到了诸多具体问题，诸如知识如何共享、知识的发现、知识更新以及一致性等（那时的 知识局限在项目过程中的各种文档资料等）。我们想通过一个共享的协作平台解决掉遇到的问题，于是有了我们自己的Wiki。这些问题其实是有共性 的，我们遇到了，其他产品线、开发组、子部门也会遇到。也就是说这个Wiki不仅仅能解决我们的问题，还能帮助解决其他人的问题。为此，我们做了 多次公开调查和私下交流，确定了知识库的必要性和大力推广的可行性。

* 保持与知识库的直接负责领导常沟通

我顶多算是一个“推手”，具体的知识库运营是由某子部门领导负责的。因此在用人以及知识库演进方面，还要常与领导沟通，达成一致后，推动执行起来 就方便的多了。

* 元策划

所谓的元策划就是为负责策划的具体执行人提供策划咨询，指导如何策划，仅此而已。当然有时也提供具体策划思路^_^。

* 监督实施

这个很关键。虽然我不直接负责知识管理这块，但我心目中是有一些期望达成的里程碑点的。因此我会不时的与具体的执行人了解进度情况，也算是一种督促和监督了。

知识库2.0上线一月有余，他们弄了个知识月刊首期，居然把我评为月度“知识达人”，还问我是否可以分享些知识积累和总结方面的心得。以前从未系统考虑过这个问题，冷不丁的提起来还真没啥思路。不过花些时间深入想了想，还是有点体会的，也许这个体会比较另类。

我承认我日常喜欢做一些知识积累和总结，只是喜欢并习惯为之而已，谈不上什么擅长，无论是工作中还是业余时间的学习过程中。为什么会这样呢？这么做到底动 机何为？我也仔细想了一下：从心理上来说这可能是源于一种“忧患意识”吧。真的是忧患：担心记性差，导致设计思路等知识和技巧的遗忘，那可真是种浪费和损 失；担心无地儿去回顾/查找（因此要起个好标题，找个好分类，贴上适当标签）；担心体验和心得的消失；担心自己每天没有进步（一直追求每天进步一点点，而 积累和总结则是一种显式地进步的体现）；担心别人看不到自己最新更新的内容(因此放到Wiki这种载体)；担心大脑容量不够，无法装得下那么多内容，所以 持久化到一类“永恒”的介质(blog、wiki)中；担心自己说不清楚，讲不明白，就写下来，并反复揣摩修改，直到自己满意；担心太多的东西放在大脑 中，太沉重，无法轻装前进，因此写出来，腾出一些空间，容纳点新东西等等。

两年了，还是那句话，自己在知识管理方面依旧是野路子+新手！估计自己以后依旧不会直接做知识管理方面的执行工作，但肯定会是一个知识分享者以及一个旁观 参与者。知识库的建立为组织内的每个人、项目、产品线、子部门提供了一个分享的平台，也是一个自我展示的平台。知识库的内部营销才刚刚上路，前途光明，道 路坎坷，猪脚们要有一颗耐心。

最后和大家分享一下我们知识库的slogan：“知识不怕从头积累，就怕从不积累”。

© 2013, bigwhite. 版权所有.

领导层的原因我这里不去分析。领导自然有生存问题要考虑。知识管理这等重要但不紧急的事情，还是留给我们去考虑吧。知识管理没有预想中的那样在组织内形成 工作风气，究其原因还是缺少持续的运营。大家知道即便是再好的事物如果缺少了持续经营和关注，也会逐渐消亡的。试想如果新浪微博没有持续的宣传投入哪会有 今天这种地位。

上周和几位组织内的资深同事一同讨论了知识管理的现状，不能再这样下去了，我们要在民间做点工作。由于都不是专业搞知识管理的，所以把我们讨论出来的策略暂且称为“野路子”^_^。我这里也将我们产品线兼职做知识管理的MM“贡献”给组织，协助做组织知识管理的经营工作。

以下是初步确定的几点经营策略：

1、团队经营

之前只是有一个临时知识负责人，除了职责范围不明确外，一个人“单打独斗”也确实心有余而力不足。因此知识管理的经营必须要有一个团队，可以是实体专门团 队，也可以是虚拟团队。团队必须有专门的负责人，专职也好，兼职也罢，有胜于无。团队应该按照做项目或做产品的方式去对待知识管理，有计划、有目标、有阶 段步骤的去经营；另外团队内部人员有分工，有些负责策划、有些负责技术、有些负责推广等，总之团队经营是一个组织搞好知识管理的必要条件。

2、借鉴和效仿

我们不是专业的知识管理团队，但业界却有好多已经做得很成功的知识管理策略值得我们借鉴和效仿，比如智库(MBAlib)等。另外一些知名SNS服务的提供商的经营策略也是值得我们学习的，即便知识管理与通常的SNS有很大不同。

以下列举一些参考策略：

- 培养达人(名人)，影响长尾。新浪从其博客开始一直就是这么做的，后期微博更是复制这一策略，腾讯微博也是照搬效仿。在组织内部，培养分享和总结知识的达 人，树立他们在知识库贡献中的领袖地位。并在这一过程中，通过宣传和引导，逐渐让更多人了解知识库，效仿达人们形成总结和分享知识的良好工作习惯。

- 持续让大家被动关注。通过各种手段让大家持续感受到知识管理在组织内的存在，比如定期全员发送知识简报、组织知识管理达人秀活动、白板宣传等方式。 

- 持续改善页面体验。一个易用和好用，可以快速上手的知识库是让大家积极参与到知识管理中的一个前提条件。因此作为知识管理重要环节的知识库，我们务必做到对其使用体验的持续改善。通过各种技术手段，让大家易访问、易编辑、易归类、易检索等等。

3、引入竞争机制，激发荣誉感

在知识管理过程中引入竞争机制。就像新浪微博勋章系统一样，为知识达人们分级，让大家产生知识分享的荣誉感。另外如果组织内部由多个子部门组成（就像我所在的组织那样），还可在子部门间引入竞争机制，这块具体采用何种机制就要看具体情况而定了，比如通过排名，或也给部门授予类似勋章的机制。

4、善用行政手段

知识的来源有随机自发的，也有规定必须的。因此有些知识整理和分享是在组织行政规定之下必须要做的，这部分内容也不能忽略，这可以让知识库内容更加丰满。另外还可以从长远考虑，将子部门对组织知识库的贡献纳入到子部门的业绩当中去。这手段有些别扭但可能真的有效。

© 2012, bigwhite. 版权所有.

© 2012, bigwhite. 版权所有.

我所在的部门已经成立10余年了，但说实话部门在知识积累和管理方面做的比较一般。例如，没有统一的知识积累和管理平台，知识分享多靠mail列表，或将知识存储在文件中放入Microsoft Visual SourceSafe，若干日子后，再无人能找到之前的知识(VSS绝对不是一个知识管理平台，顶多就是一个版本管理工具，还是个有些落伍的工具)；没有专人负责知识积累和管理；知识积累与管理似乎始终是优先级最低的那个任务。

近些年随着公司层面加强了对知识积累和管理的重视度，部门似乎也认识到了知识"丢失"现象的严重性，遂加强了知识积累方面的投入，但始终没有系统的知识积累和管理方案出台，部门内部依旧没有形成很好的知识积累的习惯。知识"丢失"不免让人痛心，于是今年年初我们决定自己在产品线内部搭建知识积累平台(采用MediaWiki)，并指派专人负责知识库建设、策划、知识整理以及知识库的备份(自动备份)。就这样我们"摸着石头过河"，一年下来收获颇丰。这里的收获指的不仅仅是积累的知识，还有宝贵的知识积累和管理的实践经验，更重要的是通过实践让我们更加认识到知识积累和管理的重要性，特别是对一个中等规模的组织而言。

我们的知识管理大致分为以下几个阶段。
一、知识库平台的建设
要想做知识积累和管理，首先要搭建一个知识管理的平台 – 知识库系统。组织内部的知识是由组织内部的人员协同生产出来的，除非你的组织需要特别专业的知识库管理平台以及特定的知识管理咨询服务，否则很多开源的Wiki工具可作为知识库的候选，比如TWiki、MediaWiki等。MediaWiki大家一定不陌生，因为世界上最大的知识库 - 维基百科(wikipedia)就是基于该工具搭建的，另外MediaWiki插件众多，也便于实现一些特定的需求。我们最终选择的也是MediaWiki。我这里倒没有什么选型的标准，只是觉得一款合格的知识库工具至少应具备一下几个特点：
- 访问方便，便于知识积累(例如，MediaWiki通过Browser访问，无需客户端装任何插件)
- 支持快速发现知识(例如，MediaWiki支持分类，标签，支持全文搜索，支持主题订阅)
- 适于协同创作，知识修改容易(这个本身就是Wiki的强项)
- 功能易扩展(例如，MediaWiki通过插件实现各种各样的功能，比如甘特图，日历)
- 知识展示手段丰富(例如，MediaWiki支持富文本，支持图片，内部和外部超链接等)

二、知识库结构策划阶段
每个组织都有自己特定的知识领域。知识库积累的就是在该领域内知识。积累前需要投入专人或小组来策划知识库的结构。将预想到的知识分门别类。分类由粗到细，甚至可以设置多级分类。为了便于知识发现，最好初始设定好一些常用的标签，这样通过搜索，我们就可以快速定位到知识所在。另外知识库的结构不是一成不变的，它应该随着知识库积累的知识的变化而适当变化，必要时需对知识库的结构做重构（比如发现之前的分类不合理）。知识库结构的重构带来的工作量有时候是很大的，所以尽量在初始情况下就全面合理地做好分类，避免后续重构。

三、知识积累阶段
知识库平台建立完毕后，就到了知识积累的阶段了，这个是全员参与的阶段。组织中的每个人都是知识库的贡献者。但事前最好制定一些知识积累的简要规程，比如规范知识提交的格式，规范主题的命名，段落格式等。知识积累阶段其实才是知识管理中最难的一个阶段，关键难在如何让组织内成员养成积极主动的进行知识积累的习惯，下面是一些可供参考的方法。

a) 适当宣导，让组织内成员意识到知识积累的重要性
b) 针对知识库平台的使用做适当的培训和交流
c) 将知识库平台打造的尽量易用，避免因复杂而导致排斥行为
d) 日常沟通多引用知识库中知识的位置，让大家在潜移默化中对知识库产生依赖

e) 引导关注。如果一个人贡献的知识受到大家的广泛关注，那么这个人将会有更大的热情贡献知识。组织内知识管理负责人可定期整理新增精品知识的简要并发给大家，吸引大家阅读知识，关注知识；通过展示知识关注度排名也可以激发大家的知识分享热情。

f) 发掘和鼓励"知识分享达人"。由"二八定律"我们可以推断，组织内20%的人贡献了80%的知识。我们要发掘出这些"达人"，给予鼓励，必要时给予一定奖励。
g) 将之前组织积累的以文件形式存在的知识迁移到新平台上。尽量将内容Web化而不是以文件附件（不利于知识发现）形式存在；如果没有精力，可对知识做简要描述，建立文件位置索引，方便大家发现。并鼓励大家在知识库平台上查找以前积累的知识。

四、知识整理
由于知识库是组织内人员协同丰富的，新知识的提交带有一定随意性，点状分布，不成系统，所以这些知识需要专人定期整理，划入适当分类，赋予更加合理的标签，尽量使其系统化。这个工作十分必要，否则一旦长久，知识库内的知识就像一根根独木，独自生长，永远也成不了连片的树林。

五、知识备份
知识是宝贵的，大家花了心血贡献的知识要保存好，保存完整。这样就需要定期对知识库进行备份。一般可通过后台运行的脚本自动备份，粒度做到每天备份一次自然就最好了。

六、做好知识在不同层次知识库的流动
不同组织知识库的建设是不同的，有的组织采用统一的知识库，有些组织有不同层次的知识库。对于前者，没有什么可说的，大家的知识都会汇集到一个库中；对于后者，我们需要弄清楚知识库的层次，让知识合理地在不同层次的知识库间流动。一般而言，低级别知识库(如部门的知识库）会定期将精华的且适合在上一级组织(公司的知识库)分享的知识导入上一级别知识库，换句话说低级别知识库可作为高级别知识库的素材库。

关于我们的知识管理实践大致就这么六点内容，我们现阶段也是这么做的。后续我们要想在知识管理这块有所进阶，估计是需要请知识管理专家授业解惑了。

© 2011, bigwhite. 版权所有.