首先，查看这个 StackOverflow 线程。一个类似的问题被问到了关于 Sharepoint wiki 的问题，赞成和反对的答案都非常有用，并概述了您问题的“在 Sharepoint 中不可能”部分。
在将 Sharepoint 用于团队文档几年之后，我现在正试图在 Sharepoint 中实现一个团队 wiki，因为他几乎和你一样。我的观察：
Sharepoint 文档库
我的经验是用于文档的 Sharepoint 是不错的。它可能很不稳定，有时您会丢失编辑或出现性能问题，尽管优秀的 Sharepoint 支持团队可以帮助解决其中的一些问题。我确实发现 Sharepoint 文档库比在网络上存储东西更好。它使文档和库易于链接。明智地使用元数据属性可以使 Sharepoint 列表视图对于查看文档的内容、用途和状态非常有用，因此我们的分析师、PM、开发人员等都一眼就知道谁拥有球和什么时候等着他们。那是几年前开始的一个项目。今天，Sharepoint 2007 的工作流程可能会提供通知。
还有文档的版本控制。但正如其他一些人所指出的那样，在文档中做事在撰写、下载和共享方面存在开销和缺陷。签出文档会有所帮助，但松散的大炮开发人员可以下载文档、编辑它们，然后将它们存储在其他地方，从而破坏版本控制。这发生在我们身上，尽管这是一个纪律问题，而不是 Sharepoint 的错。
共享点维基
根据 Chris Hynes 的回答，摩擦是描述问题的好词。为了快速参考团队内部基础设施的详细信息，wiki 似乎对我们更有效。wiki 使数据几乎立即可见，无需先单击链接并等待 Word 加载。编辑也更快更容易......虽然我仍在尝试它，但 Sharepoint wiki 具有版本控制并允许“签出”wiki 文章。
正如您和其他 SO 线程所指出的，与其他 wiki 引擎相比，Sharepoint 是轻量级的。它更擅长什么？好吧，我使用它是因为它就在那里，不需要任何特殊设置，总比没有好，坦率地说，它适用于不需要强大或面向客户的内部东西。卖给老板很容易，因为它的成本不会超过我们已经花费的成本。wiki 也不容易被我前面提到的松散大炮类型所破坏，我们可以在必要时查看审计跟踪或回滚。
添加和交叉链接条目很容易，但如果要嵌入图形，则必须先将它们上传到 Sharepoint 库。您也可以在 wiki 中编辑 HTML，尽管我不确定这样做有什么限制，并且如果没有安全访问和 Sharepoint Designer，我认为无法控制 CSS。所以除了文本（比如表格）之外的任何东西都不是很健壮。
到目前为止，我比将所有内容都存储为文档更喜欢它。查看和编辑数据的即时性为 wiki 提供了真正的优势。这肯定比拉下文档并重新签入要容易。对于一般厌恶文档的开发人员来说，它有助于消除保持信息更新的障碍。
还有其他要考虑的。您希望您的开发人员热情并积极参与编辑 wiki 吗？如果是这样，您可能需要不同 wiki 引擎的讨论功能。我的开发人员和大多数人一样；他们最讨厌的两件事是测试和文档。所以我是创建文章的人，解释构建过程、数据库环境使用、应用程序实例、服务器映射、SOX 文档清单等。其他开发人员将主要参考它并发布小的更新。我们的版本控制和并发支持并没有受到太大压力。