CDPR技术文档的八年弯路：从8000页废纸到跨项目共享|cdpr|废纸|知识库|程序员

你有没有想过，那些让你肝到凌晨三点的3A大作，背后可能是用"考古"方式做出来的？

CD Projekt RED最近自曝了一段挺离谱的家丑：从《巫师1》《巫师2》的"零文档"，到《赛博朋克2077》的8000页"文档垃圾山"，再到如今《巫师4》和《赛博朋克2》的跨项目知识共享——这家波兰蠢驴花了整整十几年，才弄明白"写文档"这件事到底该怎么做。

这事我是在Digital Dragon的开发者论坛上看到的，CDPR的首席技术文档工程师Jarosław Ruciński和高级技术文档工程师Adrian Fulneczek聊得相当坦诚。听完我只想说：能把自己怎么搞砸的讲得这么细，也算是种勇气。

一切从"什么都没有"开始

事情得追溯到《巫师》系列最早那两作。Ruciński的原话是："那个时期的东西，什么都没有留下来。"

这话听着夸张，但仔细想想也挺合理。2007年的《巫师1》是CDPR的第一款游戏，那时候团队规模小，大家靠喊、靠记忆、靠"那个谁上次怎么做的"就能把事情推进下去。到2011年的《巫师2》，虽然技术升级了，但文档习惯显然没跟上。

后果是什么？Ruciński举了个现成例子：现在Fool's Theory正在重制《巫师1》，目标是"为主流玩家重现经典"。结果CDPR翻遍仓库，发现"几乎没有保留任何技术知识"。重制团队想参考当年的设计思路、技术方案、甚至某个功能为什么这么实现——对不起，没有。全在当年某个程序员的脑子里，而那位程序员可能早就去别的公司了。

这就像一个厨师做了道成名菜，但菜谱没写，调料用量靠手感，火候凭经验。十年后你想复刻这道菜，只能对着成品猜。

《赛博朋克2077》的" fresh start"翻车记

到了《赛博朋克2077》，CDPR终于意识到需要系统化的文档管理。他们的解决方案是Confluence——一款"活文档工具"，理论上可以让团队成员实时协作、随时更新。

初衷是好的，执行是崩的。

Confluence确实被用起来了，但用着用着就变成了"文档坟场"。Ruciński透露，最终攒出了超过8000页的文档。8000页是什么概念？按A4纸算，摞起来大概有一米高。问题是，这些页面"几乎没什么用"。

为什么？因为维护文档被当成了"低优先级"任务。开发赶进度的时候，谁有空去更新Confluence？新功能上线三个月，文档还停留在设计稿阶段；某个系统被重写了，旧文档没人删，新文档另起炉灶。结果就是8000页里，不知道多少是过时的、矛盾的、或者干脆没人看的。

更乱的是2023年《往日之影》（Phantom Liberty）资料片开发时，团队又搞了个"云端Confluence实例"。Fulneczek的原话是：" chaos，对吧？两个空间，两个实例。对我们来说很难理解，对我们的外包合作伙伴来说也是……如果可以的话，不要在不同平台或工具之间分割。你必须在它们之间建立非常清晰的链接。"

想象一下：你查一个功能的实现方式，发现Confluence A有一份文档，Confluence B有另一份，内容还对不上。你问同事，同事说"以B为准"，但B的最后更新日期是半年前。这种场景重复一百次，8000页文档的信任度就归零了。

从"各扫门前雪"到"公司级知识库"

现在CDPR终于换了打法。Fulneczek说得很直接："未来对我们来说真的很光明。我们吸取了教训。"

核心变化有几个：

第一，重新定义"完成"。以前项目 milestone 过了就过了，文档爱写不写。现在每个开发阶段结束都有个" gate "（关卡），过关条件之一就是文档必须到位。不是可选任务，是硬性要求。

第二，打破团队壁垒。Ruciński解释："与过去不同，现在、今天，我们的知识不会被锁定在特定团队的权限后面。它是一种共享资产。"

具体什么意思？假设《巫师4》团队解决了一个技术难题——比如某种开放世界植被渲染的优化方案。以前这个方案可能只存在那个程序员的本地文件夹里，或者某个小团队的私有Confluence空间里。现在，这个方案会被记录进公司级知识库，《赛博朋克2》团队也能看到、能借用、能根据自己的需求修改。

Ruciński算过账："问题不会被不同团队重复解决，而且如果某个项目取得突破，整个公司都能受益。"

这话听着像企业管理的陈词滥调，但在游戏开发这种创意+技术高度混杂的行业里，确实能省大量成本。两个项目并行开发，意味着两拨人可能卡在同一个技术坑上。以前各自爬坑，现在前面的人插个路标，后面的人绕道走。

一个让人既安心又焦虑的事实

聊完CDPR的文档进化史，有个念头一直绕在我脑子里：

他们以前那么混乱，居然还能做出《巫师3》和《赛博朋克2077》（发售灾难 notwithstanding，最终销量和口碑都翻盘了）。