针对这个问题其实我有不同的观点，不是解决AI代写而是就AI内容泛滥的问题。

人类的想像和创造推动了社会的发展，包括AI技术到现在也是人类从想象走向现实，作家有想像创造出了优美的文章，艺术家有想像和创造力创造了美妙的画卷、音乐等。 而论坛、博客其实本质上就是一个内容和创造力分享平台，我们分享自己的经验、分享自己的想法，让更多的人能够看到，如果AI内容泛滥，那分享的意义又在哪里，同时看文章的受众的过滤与识别成本也会很高。 AI我认为是一个辅助工具，我们可以用在工作、生活的辅助甚至创意的辅助上，但是不建议完全照搬，建议同学可以在写文章时以AI为犁辅助我们进行大纲梳理、内容调教、数据检索等，但核心根本还是要注入自己的思想，愿同学能够写出更好的文章！！！

这个问题不是绝对的，要看公司或部门当前的业务规模，评估当前是采用 管技分离 还是 管技一体： 管技一体：通常初创公司，人手有限，架构师通常也是研发部门主管，这种情况下架构师就是整个公司的技术灵魂，为整个产品技术栈的长期演进与当前的基础负责，那就需要既能设计技术架构编写基础代码，又能够根据部门内不同人员的技术栈、能力水平去分配任务。 管技分离：公司规模大了后，通常分工更清晰一些，一个部门会有部门主管（类似总经理）、架构师（类似总工）、项目主管、小组TL等，此时架构师的工作通常主要以技术分析、技术路线研究、关键技术攻关为主，架构师确定技术架构与技术栈后通常会由项目主管来分配给具体的小组去进行工作执行。 但部分公司也会有技术攻坚小组，此时会由架构师担任组长，有一些高级技术专家负责技术攻关负责编写技术代码，编写完毕后再由项目主管交由各小组去编写产品代码合入。

这个问题提的非常好，桌面云是一个面向B端的更偏C的云计算方案，是用户一天工作最主要的基础平台，最终用户的体验相比做其他平台（如邮件、OA）更为重要。 第一个问题：技术深度与用户体验的流畅性需求 宗旨是保证用户体验的前提下寻求合适的交付方案 用户体验决定项目的成败，通常我们在设计项目时会从用户体验维度作为目标值再去评估技术满足度或解决方案，如用户的色彩、帧率、操作流畅度要求等基础体验 以及特殊场景如3D设计场景的图纸模型加载时间、操作处理响应延迟（平移、旋转）、图纸渲染时间等方面评估目标值进行POC测试与方案论证，再评估达到这个目标所需要的网络（延迟、带宽）、服务器（CPU、GPU、存储）、终端（终端解码性能）等方面需求下的成本与复杂度，最终设计整体方案的部署模式（如3D对网络要求比较高，则只考虑本地化部署与接入；如硬件上可根据不同场景选择不同硬件，3D选择高主频、非3D选择多核心如更低成本的AMD处理器）；在保证用户体验的前提下选择合适硬件、网络与服务器密度后还可考虑不同的部署模式，如办公场景、运维场景可考虑部署更灵活的重启还原池的标准化模式；部分低密度使用的3D设计程序可考虑使用SBC虚拟应用方式交付等来降低成本。 第二个问题：如何从成本对比到长期价值转变 只要对比到成本维度，说明要么非刚需要么可选择项较多，其中桌面云项目中更多是非刚需或没有挖掘出刚需痛点。桌面云项目一定要从需求角度出发，能够较好解决用户的痛点，这样才会更高买单。桌面云的主要价值总结就3点，数据安全、简化运维、灵活弹性。 在国外由于办公方式较为灵活，灵活弹性需求购买云桌面居多，而在国内则数据安全占到一半以上或更多。 例如在制造业，当前我国正在进行低端制造到高端智造产业升级、竞争激烈，核心研发代码图纸数据就是命脉，那这种情况就要去从桌面云的天生数据不落地安全角度出发（用户摸不着数据，不会出现极端的用户抱着数据走或格式化数据销毁证据情况），影响客户或客户高层以建设安全研发平台而非替换PC来施行云桌面。

有一句话叫，不要因为路上遇到的野草而影响了去看终点的鲜花。架构设计也是这样，我们总想系统大而全，而最终导致做了一个非常臃肿的架构，后续在做改进的时候就变成了“屎上雕花”。 通常我在设计一个架构的时候，会采用“最小化可行性”与“可扩展预留”两个方面考虑： 1. 最小化可行性： 在初期先构建最小化可运行的骨架作为架构底座，再逐步根据功能需求渐进式填充肌肉，初期阶段只跑通最为基础的功能，如设计一个桌面云产品，初期仅开发支持最小化用户能接入云桌面，后期再逐步完善桌面自动化创建、精细化安全策略管理等功能，快速验证产品可行性。 后续功能扩展阶段，也需要充分考虑功能优先级，按照通用性、行业性、个性化等进行分级，将需求分为L0~L5级别，优先做L0级功能。

2. 模块化设计，可扩展预留：

平台架构设计尽可能采用模块化设计，每个模块可独立运行独立升级扩展；架构底座支撑多种技术栈同时具备未来技术可扩展性的设计，并能支持分布式模式部署，便于后续架构底座面临性能瓶颈时的扩展。 如设计云计算产品时，系统总线作为整个平台的基座，管理模块、网络服务模块、存储服务模块、认证服务模块、日志模块全部采用独立模块设计，模块之间采用标准的总线协议通讯，同时系统总线能够支撑未来扩展更多服务模块预留（如未来引入AIOps模块）。系统总线也要充分具备可扩展性，如现阶段需要20个模块，系统总线需要设计为远超过20个模块的架构同时在未来更大规模的时候，系统总线需要具备性能提升的可行性（如支持分布式部署模式等）。

当前正在做的产品主要是To B，且有大部分客户面向央国企，当前主要使用OpenGauss DB

从通常的意义来讲“架构师”，需要有“写代码”的能力，但这个是加分项，更重要的是 架构师作为一个集管理与技术于一体的角色，在架构理念和工作分配的全局性是更重要的。另外一点，或者至少从写代码的过程过来的，但这个地方如果仅仅拿写代码来说确实是把架构师描述的范围有点小了，限制到了开发的范围，然而架构师其实还有网络架构师、云计算IaaS架构师以及各细分行业的架构师等。

我不认为一个勤奋的代码能力高超的架构师能够带好一个团队，打造一个好的产品，但是一个好的管理者，能够调动大多数人员积极性和用其所能的架构师，是可以让团队在自我认可中发挥出每个人积极性的，这样的团队更具有多元化，效率相对更高一些，毕竟0.5+0.5+0.5是＞1的