@
autoxbc 这并不是单单需要多少人月开发的问题，通常在正式制定开发方案之前就要首先评估需求的“合理性”，可能要考虑更多的问题：
1. 受众有多少？目标用户在其中的占比为多少？
2. 能带来多少盈收或潜在盈收？
3. 长期维护成本有多少？
4. 运营成本有多少？
5. 目前全公司整体项目计划优先级和排期以及人力资源的分配是什么情况？
第 1 项我已经做过简单说明，我不清楚知乎自己在市场营销和产品设计方面的“目标与用户”是什么定义，所以也无法给出估计。
第 2 项需要有进行中的或者实验中的盈利模式，和内部的数据分析，这个外部人是不知道的。
第 3 项肯定是存在的，而且不一定会少，基本上日后所有产品需求设计都需要考虑是否要同时在两个前端上实现（或修改）、有什么区别设计、功能逻辑是否互恰、现有架构是否能够实现、因为差异化带来的额外技术成本有多少。
第 4 项不一定会便宜，最起码渲染用服务端要有一套分布式集群，要做负载均衡和弹性伸缩，而且也要长期负担带宽和流量费用，也要有足够的人力运维。
第 4 项要看知乎内部的具体情况了，如果项目排满而且有很多更高优先级的项目在占用资源的话，即便服务端渲染机制要开发，也会被排到后面，而且前面有可能会不断有更高优先级的新项目插入。
以上几项评估出来的结果会被作为此项需求“合理性”的参考。举个例子，如果成本远大于盈收期望，而现阶段还有更多盈收期望大于成本的项目在计划中，那么这个需求就暂时可以被定为“不合理”。
如果是“合理”的需求，可以安排开发计划的话，只从开发成本上来说：
1. 因为之前是前后端完全分离的项目，至少需要单独写一套渲用染服务端，渲染用模板要重新开发，简单来说会按照原有纯前端渲染的产品能设计取一定的完成度比例重制。
2. 原有提供数据和业务逻辑的服务端，要针对渲染用服务端，进行 API 和业务逻辑的重新设计，以保证通用性或者兼容性；因为如果服务端渲染的产品呢不能完全实现纯前端渲染产品的所有功能的话，必须要确保服务端渲染的产品也能够具备严密的业务逻辑。这其中最恶心的莫过于在两个前端产品中出现完全不同的功能逻辑设计，这会增加数据资源服务端的复杂度。
3. 原有纯前端项目里，要重新考虑整个优雅降级的机制如何糅合进去，如果遇到架构或可行性问题的话可能要对其进行一定程度的重构。
具体工作量要按照产品设计者规定的产品设计来评估。当然因为并不清楚知乎内部的项目运作方式，这里只是做一个简单的猜测。