@caomu 好问题啊，我也开始反思，不该经常推荐Confluence。从搭建、维护、同步、备份等一系列问题来看，对大多数人都不合适。

不过，如果只是与同类的wiki相比，Confluence优势还是很明显的，即使是个人使用。面向企业、高额收费(但是，10个用户以内只需要10$)这些还是保证了文档、技术支持等强于其他开源wiki。而且，CF其中一个定位就是知识库，所以个人做知识管理还是强于Mediawiki之类的。

另外，就是我个人偏好了。
首先，我强依赖于结构，而不是某些wiki的词条方式。也有些wiki结构组织能力强，但是Confluence原生的目录树结构是我目前最满意的。
然后，我需要的不是收集，而是创建和管理。
p.s. Confluence 4.x系列对编辑效率大幅度提升了。

@yangg 使用tag我也考虑过，感觉不太习惯。
我更倾向于提前设计好严格的目录树，在将来逐渐往里添加内容。带有更强的目标性。
例如，我想要学习时间管理的话，会查阅相关资料，了解涉及的类别、知识结构，设计好目录结构。然后有资料的话就往里添加，并能够清晰的知道哪方便比较薄弱，需要加强学习和实践。
另外，Confluence也支持tag

@hpowen 收费的企业级知识管理wiki。
相比Media Wiki等面向词条的wiki来说，Confluence以树状结构组织页面（类似与目录层级）。
以前用Evernote什么的，在一个Notebook中不能搞多级结构，把笔记平铺下来的话，积攒多了就很难查找、阅读。我知道有些人的Evernote已经退化成记录的工具了。

@wynemo 数据主要就是页面的文字内容保存在mysql中、附件在特定目录下。
Confluence支持导出到pdf，脚本只是模拟手动操作，能自动完成这个事情而已。

不能停留在记笔记，甚至是弱爆了的做题应试阶段啊。
建议
1. 整理知识点、每个知识点评估标准（是否掌握、掌握程度）
2. 提供系统，学生可以按照自己的喜好制定学习计划，跟踪学习进度，从中享受成长的乐趣（可视化方式看到学习成果）

逛街都认真不起来，学习能认真？
要学习上咖啡厅去，原因很简单，在那里，出了学习啥也干不了。你的mm没法支使你去洗水果、不会让你去做饭、不会…… 顶多就偶尔调调情而已

@mlzboy 好吧，我这周改改后提交到github上

python，自动把Confluence所有的空间内容导出为PDF，算是最后一个备份。
除此之外，Confluence其他的备份有：自带备份机制、定期mysqldump、TimeMachine；
有了这些备份才能彻底放心去记录各种笔记。

使用Confluence wiki感觉良好。
一切不方便立即写入Confluence的场合，使用纸笔+康奈尔笔记系统。事后根据记录结果考虑是否编辑到Confluence中。

Confluence

@zealot 对了，我大半年没用Chrome了。。。。

jsonview
btw: 不设置Content-Type: application/json头的json接口都是流氓

我就会用.download作为隐藏目录放片

考驾照那个不能找个包教包会，一次性交的报名费里包括饭费的那种。
考不过就天天过去学车、蹭饭啊
http://news.51xueche.com/news_htm/20096/1200966115835.htm

@tokki 刚满25，7、8年没玩星际了，没有了高中那种一起翻墙溜出去玩星际的人、条件和兴致了。

@chairo 如果这样理解：RD只是PD实现想法的工具。那么不要趟创业这趟水，IBM/Oracle(中国)或许更合适。
p.s. PD参不参与市场分析这个得分公司，不同公司有不同的组织结构。

修改：创业公司里独立产品线(不是项目)走事业部制最理想了

@chairo
我的想法绕来绕去就那些，不逐条回复了
还是些个人暂时的想法

文档粒度
"足够细粒度"的文档，在我看来既不是很好的定义，也没办法执行；除非补充一下详细说明：细化到伪代码粒度。产品经理做High Level的设计就好了，细节根据任务特点分别由美工和研发做更专业、更自由。至于产品经理职责不是设计产品，而是分析产品、用户行为等，设计产品是指一个产出而已。所以非常细的粒度完全没有必要，但文档是必要的、变更记录是必要的，产品回顾、效果分析与分享是必要的。
开发、测试、产品、运营坐在一起办公，很多问题都能解决掉了。我说的”一起“意思是旁边或对面，有问题靠吼来解决，而不道社区讨论，比如站起来，冲旁边经常一起踢球的产品经理吼“你他妈的上午刚提的需求，我都要开发，怎么下午就要改了？”
创业公司里独立项目走事业部制最理想了

复制代码问题
这个我完全不认为复制代码提高效率，即使短期效率提升也未必。这个我很难三言两语说清我的想法。长期来说自然没好处：1）维护性差，很多复制代码风格、实现方式没法融入 2）不求甚解的复制最可怕 3）没有学习和理解，到头来终究是有报应的 短期也未必提升效率：1）N多次帮人调代码都是赶在上线前发现拷贝的代码根本没理解，出了问题不会调试不会解决 2）相当一部分bug出在复制代码上 3）复制代码就是花20%时间完成80%的开发，外加100%的时间去调试和解决bug，再加300%的时间去解决上线后的bug，再花不知道多少时间去重写

产品经理(PD)和研发分工(RD)，再扯上美工(UE)
这个不同公司、不同的职责定位都有差异，我更倾向于PD做产品分析、用户行为分析，而不是去纠结用户名最长多少字节，不是纠结实时性服务延迟1分钟还是1分半。最牛叉的PD，我也不敢跟着他拍脑袋决定的想法去干活。如果可以的话，我更希望知道做个产品、加个特性究竟是为什么，而不是说这个人经验丰富。
要我做PD，RD问我用户名最长多少，那就不限制最好了；实时服务延迟多长时间能接受，是个做产品设计的都希望不要延迟；
再回到用户登陆用例上来说一下我想象中的分工
1) 假设用户登陆长远来看并非重要功能，仅仅只是产品中若干个地方真的依赖注册用户，那就随意设计就好了，当面跟UE、RD聊一下想法，记录下来UE作图、RD按照自己的想法去做。不重要的内容PD就不用太关心、纠结细节了。至于担心页面风格不伦不类，那是UE职责，相信他；至于安全、开发细节等相信RD；至于若干功能细节，讨论前整理一些基本资料，开会确定一下就好了。
2) 如果用户中心是个非常重要的功能的话
我希望PD能够知道（或调研）一下各种方案，包括中文用户、英文用户还是邮箱作为用户名；注册页面是ID+密码，还是再加详细信息；是立即注册，还是填写订单后再注册；是否采用OAuth登陆；分析优缺点，结合产品属性与规划，做出相应决策；；同样，用户名长度不是重点。
RD需要知道（或调研）各种实现细节，比如OAuth；安全，比如密码保护、加密方法；是否采用https等。最重要一点：在技术上给PD提供参考与建议。比如单点登陆、https等有些技术，或者某些新技术PD可能不知道，这时候就是RD参与产品设计的一个点。
UE去页面美工、交互，比如js验证一下用户名长度等