软件工程师罗小东，多年架构和平台产品设计经验，目前在研究平台产品与新技术结合中。

概述

针对的背景是中小项目运维管理，前期的产品研发上在运维体系上，已集成自动化操作和可视化监控，比如k8s/promethes/jenkins/ansible等自动化工具，并结合设计出对应的运维套件，包括流程化和数据治理工具，devops/chatops体系等，结合开源的工单工具形成运维的标准化管理和流程。

在大模型的新技术的产出上，将进一步为运维提升，达到整体运维产品体系往上升一级的目标，以更为智能化，更贴近于人性化目标。

前期在开源平台产品运维阶段会遇到一些突出类的问题，比如:

1. 系统问题的分析：缺少初步分析的结果，系统横向知识多，问题分析过分依赖经验和高工，分析深度不足，排查过程长。
2. 数据和知识库归纳：工单和分析结果，问题场景和问题现场维护丢失，形成经验沉淀太多，查找困难，重复性问题出现等。
3. 数据的分析报告：在全链路的监控下，分析的支撑繁琐，运维数据的治理和后期的总结分析依据，对人工依赖，运维数据治理不足；
4. 处理报告结果分析：针对会议或者结果性报告输出内容较多，对报告性编写有一定要求，会议或者报告类输出问题依据说明有些情况说不清；
5. ….

注：这里不涉及项目资金和客户沟通层面，比如运维费用依据，只做辅助类设计。

总会有一种好像不难解决或者可以解决(可解决)，但过程就是不是特别顺的情况，在标准的执行上总会有一种可以有更优化的依赖工具自我感觉。在升级设计思路，从新技术结合的思路进行阐述:

1. 运维Agent员工的设计和概念介入
2. 结合数据分析的形成运维数据资产
3. 结合大模型的数据分析报告输出

以上与ChatOps的概念相类似，在交互和输出上将会更加的达到精细化的解决思路，以供相关人员的排查和处理。每个产品设计和架构方案思路不一，以供参考与交流，我有我思.

设计思路

设计是基于原有的开源平台产品上的进一步升级，从初步的探索和目前大模型的成熟来结合，结果会控制一定的发散性，初期以达到可用为目标。

运维Agent员工的设计和概念介入

将进一步的设计出智能体员的概念，大模型Agent员工的介入，在特定阶段或者消耗时间阶段设计出处理角色，以切入运维工具和管理流程，形成初步的Agent运维团队，以解放部分人力思考分析过程。

这里设计的角色比如:

• K8S分析工程师：分析k8s问题并得出初步的解决思路，包括执行命令，解决思路；
• SpringBoot分析工程师：分析java应用异常并得出初步的配置方式，并给出对应建议；
• 报告分析工程师：分析问题结果，并结合处理内容，与当前模板结合，得到处理过程分析报告；
• 安全分析工程师：分析异常链接，然后得出相应的解决思路；
• ….

参考: 结合的k8s运维的产品示例自定义k8s运维Agent插件:仿k8sGPT设计.

这些Agent员工的设计会形成初级的运维团队，结合大模型的经验分析，知识库内容等得出初步结果给工程师，减少初步的排查及初级的问题处理，在沙箱环境进行验证。当然也可以结合工作流，但是带有操作风险，毕竟是生产，需要过一步人工。

结合数据分析的形成运维数据资产

单纯的自动化管理体系还有可视化，并不能将整个运维过程闭环激活，它需要反馈和成长机制，以解决当前的问题和规避未来出现的可能性。运维结合大数据，会达到更优化的效果。

在自动化运维工具套件中，已经可以采集到全链路的过程数据，这些数据一般的系统难以承接，统一导入大数据套件进行管理，形成运维特定的数据资产，从而形成运维的知识库。

基于数据治理套件的实时、离线、清洗、分析等工具，将进一步的得到应用的生命状态，系统的健康状态，每个微服务，每个应用的健康评分，常见问题和后期开发的重点处理内容，形成数据的反馈闭环，从而在研发过程中进一步的完善规范，在DevOps流程中进一步的添加检测。

这些也是提供给Agent员工的数据接口来源。也可以结合业务数据一起，这里是平台性的运维，偏向的系统型数据，但流程管理是一致。便于在后期的管理中，包括商务沟通等形成一定的依据，还可以在处理过程中，处理后还原问题现场，这些都需要大数据套件的存储和治理。

如果有资源，同样也可以结合机器学习进行算子优化，这里不涉及机器学习内容。

结合大模型的数据分析报告输出

运维工单处理，问题解决方案和思路，沉淀方式形成知识库体系，而不同于传统知识库层面的是，结合大模型的知识库会更好的体验，大模型聊天机器人当前也比较普遍。

在前期的数据和Agent工员结合下，通过指定的模板分析，比如ChatPPT工具，形成统一的分析报告，形成会议的相关依据初始稿，再由工程师进一步的做加减法处理，比如：

• 系统运行的日报/周报/月报，异常处理，处理方式还有建议思路。
• 工单的处理结果报告分析，处理思路归纳归档，更完善的说明描述等。
• 结合知识库进行相关材料的编写，比如部署方案、资源配置等
• 需要根据具体情况进行的分析和处理，以确保运维工作的高效性和质量。
• …..

写报告过程就会发现，即使在特定的模板之下，初中级工程师在这块上偏向于短板，同时每个输出过程需要一定的工作量，还有过程QA/PM等审核，再出现在会议上，这个过程可以解决，但周期长短不一，沟通多，总有一种不是特别顺的感觉。也许分析内容未必达到要求，但已经相当于出了初稿，可以更快的投入到解决思路的讨论评审中。

其它

以上为在前期做平台产品基础上的进一步升级优化方案及思路，在运维工具的选型中，针对于中小型项目或者团队的比较多，前期通过多次的整合形成的devops/chatops/自动化标准及流程，
在大模型的切入下，提升更好的思路和解决方案，当前已在结合验证，同时也是下一步产品优化的方向。

期望给一些同学参考，也期望有兴趣的同学可以一起讨论，分享经验。

软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。

背景

内容针对的是社区产品建设新人切入的指导性思路，目标是打开自我思维，有基础，能设计，能思考，能实践，会自我价值体现。合理利用社会资源工具，将时间和精力放在最有价值的地方，创造价值，提升价值。

产品是以开源状态进行开发管理，当前社区团队在接纳新人，有部分还是大二大三学生，有一些可能没有接触过设计体系这块，考虑更系统的体现基础层，这里进行阐述说明。针对于新人来说需要一些方向的引导，以快速的进入状态，跟上梯度成员，便于他们有方向的成长和学习方向，也是规避迷茫，缺少方向感，导致负面和误导，消耗无谓的时间。

当前维护的社区团队非常小，还是兼职，自动化和低成本的基础设施对团队来说，会比较看重，应用最少的人力去维护好产品，同时为了更方便的办公。工具的使用，可以让新人和加强的技术理解、架构思维、使用场景、解决能力、还有方案输出等能力。

设施包含

这里的基础设施工具，主要是使用开源和常用的SaaS化工具来进行平台产品研发的管理，以减少成本和学习路线，可以有大量的学习内容让团队可以快速解决问题，如下图中的这张架构内容。

基础层主要是包括【基础设施、代码级、模块层、应用级】，这个主要是基础环境设施，上面系统级主要是软件服务应用。在基础层，基本上使用的都是免费工具类型，包括免费服务器，免费的DevOps套件、免费的代码检测、安全检测等。每个人都可以使用，开个账号就可以学习，可以使用一些效能工具更快的提高自己的效率。

有一部分是现成的，有另一部分的自己设计的，总的来说，类似于PaaS层，但是又高于PaaS层，最大化的贴近于应用层，以减少底层的建设，确定好规范之后，外加GPT的加持，会更加提高效率和输出服务能力。

这里主要的内容包括几个主要部分：

1. 基础PaaS层：阿里云ECS服务器、Kubernetes、阿里云ECS网络安全、阿里域名
2. DevOps套件：Github、GithubAction、阿里云效Maven私服、阿里云ACR镜像
3. 中间件层：Redis、阿里云MySQL、七牛云存储、Clickhouse存储、Kafka消息、Nacos等
4. 基础服务层：Infra核心包、Infra单点登陆、Infra代码生成器、Infra权限引擎、Infra网关服务等
5. 质量管理层：SonarCloud、GithubSecurity、墨菲安全、ApiFox
6. 自动化层：GithubAction、Ansible
7. 项目管理层：阿里云效项目管理、阿里钉钉、WPS、腾讯会议
8. 项目预警层：Prometheus、Ansible、阿里钉钉
9. AI智能层：Hugging face、百度飞浆、阿里云AI系列
10. 数据治理层：阿里云DataWorks、Infra数据治理套件
11. LLM大模型层：ChatGPT、星火大模型、百川AI、Infra智能体服务

这些大部分社区工具和云服务平台，作为入门的基础内容，难度系数并不高，要求只是基础能接入使用就可以，另一部分是基础架构里面进行补充的内容(以Infra开头)，这些都提供出对应的接口和使用说明文档。当中有一部分会混着用，比如数据治理层，后期做为平台型产品会做一些场景进行针对性替代的研发。

上面这些，在这进里统一规划层基础设施层，这些会考虑使用低成本的方式去运营管理，方便产品的正常开发和演示运营，同时确保可以新人更好的针对性的自我学习。

学习路线

在工具选定之后，针对新人来说，怎么接触练习，这个可能来说，先对比较简单一些，对于线上可以注册的工具，基本可以自己学习就可以，学习主要通过以下路线，先熟悉工具，在进行应用层服务的开发。

学习路线主要是下面：

1. 了解开源工具：账号的注册和示例的学习，了解这个工具是做什么的。
2. 了解服务能力：了解Infra组件提供的基础能力有哪些，怎么使用当前的服务模板。
3. 熟悉研发流程：了解产品的项目管理流程，敏捷开发流程，知道从哪步到哪步。
4. 创建服务能力：能根据需求自主创建出服务并提供出服务能力，价值体现。

学习工具主要是了解怎么使用，这里使用的层面就是自己注册跟学习了，然后自己关联自己的demo进行学习。这个过程看个人，不合适人员并不会要求往下，合适人员接触起来，其实也比较容易，大部分就是看教程或者视频操作。

这也是进入产品维护的一个简单门槛，基本工具使用的还是helloworld级别，深入会过程再慢慢沉淀这样。在长期接触过程中，其实大部分场景都是可以满足，即使不满足，也不会达到多难的程度。

这里除了编码层面的，其他都是自动化，编写一套之后，留着自动任务执行就可以，根据预警情况，看是否需要处理，其他的，出问题再需要人工介入。

编码层面的，这里主要是通过结合代码生成器，GPT和定制的Prompt来进行，因为是产品型和服务型应用，逻辑还是先出一般本，先可以看到，然后后续根据产品功能，进一步的完善。先用起来为主，这部分对一般没怎么接触过的人员，先做一个功能就可以上手，因为规范都统一化，这些入门成本会比较低，参考着复制粘贴就可以。

另外就是Agent智能体服务的，这个整合起来就是调用GPT的接口外加基础服务的接口，当然，这个需要一些规范，前期已经解决了这个问题，目前主要是根据规范，结合工具API接口写Agent插件就可以，集成架构也已经集成。

能力输出

这部分重点还是在需求和设计上面，到进入服务输出来说，到这步已经很容易了，服务能力的输出，才是最贴近业务层的，这里会把精力放在这块上面，时间成本最大的，也是在这块上面。这部分可以花时间在需求和设计上面，后期通过AI编程和微调整来实现，另外就是参考其它网上代码或者开源项目。

自我能力提升，还有AI的引用也是在这块上，这块要考虑的编码，但是更多的期望可以使用现成的代码，可以复制或是开源的，符合的拿过来就可以，没有的，使用GPT协助建设也可以。这部分偏于码农路线，但是我们能做但是不代表一定需要做。

时间精力放在优化，某个框架深入，思维的理解，场景的运用，解决方案沟通上，这个是目前团队特别关注也是重视的。

总结

上面是当前产品研发过程中，使用的基础设施工具，有部分是使用现成的，有部分是结合开源项目进行的研发，有部分是自主开发，通过设计整合起来的基础设施能力，为上层服务建设提供良好的条件，也可以让新人更专注于场景解决方案和业务能力分析设计上面。

这里提出了一套基于开源工具和社区资源的学习和实践方法，强调了基础设施、代码级、模块层、应用级的基础知识，以及使用免费或低成本的工具和服务的重要性。并给出了一个学习路线，包括了解开源工具、了解服务能力、熟悉研发流程和创建服务能力等步骤。强调了能力输出的重要性，包括业务能力、AI引用、编码能力、优化能力、框架深入理解、思维理解和解决方案沟通等方面。

软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。

背景

背景交待，设计无法脱离背景，经验偏向于中大型业务应用，重业务和落地，偏于ToB体系，也有互联网经验参合。中小型团队(比如几十到几百人)类型，会有一定的资源缺乏，偏于业务应用层面。

以前也会太过于理想化的设计，经过遇到的和接触过到很多团队，反而更加相信自己的设计，或者说每个设计师有自己的思路。

概述

接触过很多做架构设计的团队，也在架构部门(专门做SA的团队)有很多讨论，临时记录的笔记，一家之思，做一些经验参考。

在以前接触的项目中，会跟很多架构师，技术经理，总监等做过很多讨论，很多感受到的一点，在整体型的平台架构设计上，能落地的团队偏少，小的设计上往往难统一意见，很多不同经验的人员，会带来很多不一样的想法，走向极端和误区性的也比较多多，过程放弃跑路的，做到一半一半的也不是没有，有些每一两年换一个架构方向也遇到。

这里主要做一些记录过程问题，架构的方向和设计，往往会决定企业或者团队未来3-5年的发展情况，做得好，商务和市场上的配合，可能达到事半功倍的情况，做得不好，可能就是其它地方事倍功半。这里以小团队做中台化产品的一些记录，同时结合其它团队沟通和接触过程中见到问题。

• 团队基础条件: 每个团队有自己的情况，有自己的能力，有自己的缺点，不要过分否定自己，也不要过分抬高自己
• 规避技术成本: 不要过分的引入以为好的技术，以合适为主，以简单为主，以容易上手为主，避免过度封装
• 规避学习成本: 尊重开发人员的习惯，尊重行业的发展现状，部分人会不代表其它人就可以，习惯自然而然最简单
• 敢于做决策: 在没有结论或者结论自己无法把控时，相信自己的想法，即使是错的，先做，重点是要能自己把控得往
• 顶层思维思考: 从顶层思维看问题，规避过份纠结细节，整体能正常，不追求100%，保持后面有持续优化的心态
• 其它 ……

以上为一些或者前期遇到的，很多都会有类似的问题，来来去去围绕的很多，设计开始否定的人一般会很多，甚至很多年经验的架构师一眼就会否定，觉得都不是问题，重点是个人有没有自己否定自己的设计，是否相信自己的设计，是否可以坚持自己的设计，每个设计师有自己的思路，我有我思。

经验内容

以下为一些具体遇到的问题和场景展开的分析说明，结合实际场景遇到的情况。

团队基础条件

设计不仅仅只是设计，这里业务架构设计层面不包含

在考虑团队基础条件时，我们必须理解每个团队都有其独特的情况和能力。这包括团队成员的技术水平、工作习惯以及团队内部的协作方式。不应过分否定团队的能力，也不要过度抬高。相反，应该在现有条件下寻找最佳解决方案，并努力提升团队的整体素质。

不仅如此，还有包括后期的招聘，管理，成长，城市环境等多重因素，做好一定的预案处理，这些好像不是本身的工作或者其它部门的考虑，但是存在的风险依然会需要考虑到这块的内容点上。在非大集团的情况下，或者中小团队，或者说二三线城市，或者一线城市特殊约束，都会有各种可能性，不仅如此，还包括商务、销售、市场、营销等等符合性的设计，以渐进式的方式进行的推进。

设计岗有一点类似于不上不下的角色，但是要落地，怎么推进，沟通，向上向下管理，输出都需要精细的考虑，看似跟这个不相关的事情，但是依然会带有一定的关联，在设计层面，会尽可能考虑到因素，以确定设计可落地，以保障架构的实施和后期的发展，这些都需要考量团队的基础条件。

这并不是为其它角色或者部门考虑，而是在本身的范围里面确保自己的设计可正确的实施，到这步，某个角度上，跟技术的关联性其实还比较小。不代表没有土壤就无法种树，同样需要考虑在各个部门当前的条件下，怎么创建土壤和培育。

规避技术成本

对技术的尊重和敬畏，但是不崇拜

对技术来说，不再过度去崇拜技术，而是尊重技术，尊重它带来的成果。在很多场景上的解决能力。

很多设计人员一上来会有高并发，分布式，微服务，容器化，人工智能，或者大数据等等很多的设计名词，这些并不是在每个项目上使用得到，有大有小，有高有低，并不代表它就会使用到。其实并不代表这些新的技术就是怎么样的，主要还是建立在业务和团队基础之上，以落地为主。

后来发现，这并不是一个好的事情。新的技术引入，以选择合适为主，简单为主，比如微服务，以前会听说很多springcloud技术，还有多个变种，官方版本，阿里版本，腾讯版本 … 还有k8s版本，在前期过程中你会发现，有可能会喜欢将“好”的东西运用上去，会成为一个臃肿的设计，或者追求各类型的过度封装，觉得这样会给开发过程带来很多方便。优劣好坏某个角度来说，很难区分，怎么选择。

后面发现，过重的微服务设计，使用的东西并不多，过多的设计理念，过分的封装，会带来后期很多无用的成本，后面的设计将springcloud组件能去掉的就去掉，保留最基础的springboot版本，其它按需引入，将非业务下沉到PaaS层，能轻量就轻量。

规避学习成本

尊重习惯的同时改变习惯

推行新的设计，以前很多情况下会走一到两个项目或者前期小团队试行，以积累后带大团队进行，这是一个常用方式之一。但是在不断的接触和积累过程中发现，这部分的成本也是非常大的，包括时间成本，学习成本，培训成本等。有时候需要找到新的血液进入，这个就更不用说了，周期往往一来就是半年以上，团队完全消化，甚至有可能1-3年。

尊重开发人员的习惯和行业的发展现状是至关重要的。虽然部分人的习惯可能不符合我们的预期，但我们应该尽量与之和谐相处，避免强行改变。同时，我们也应该意识到行业技术的更新迭代是不可避免的，但不是所有新技术都值得投入大量时间和精力学习。应该谨慎选择学习的方向，以避免浪费时间和资源。

效能工具方面，新的设计应该带来更好的效能，更好的减少学习成本。假如说将工作比作开车，前期可能大家习惯的手动档，在新的设计上，应该是提供出自动驾驶，或者自动档，依然是开车，提供更好的工具，以确保习惯的同时，提供更好的工具，在后期转变过程中，通过工具升级进一步的升级习惯，在过程中进行转换。

敢于做决策

决策有对跟错，没有决策往往是最大的错

前期带过很多Leader型的角色，新Leader有的时候，不太敢于做决策，包括我自己也一样，没做过，别人也没有类似场景，在决策时心理会有多个打鼓点。

在后面发现，在面对没有明确结论或自己无法完全把握的情况下，我们必须敢于做出决策。尽管决策可能是错误的，但关键是要相信自己的想法，并且能够承担后果。即使决策出现问题，也可以从中学到经验教训，并不断优化和改进。

这个的效果会带来一些误伤，但是错误和修正的成本相比于没有明确决策成本，会更大，而且后期成本相当隐形。

以前在做一个SaaS型平台产品，有上百个基线，同类的设计场景团队有时候也没遇到，但是先走，错了就调整，做好风险把控，结果在半年时间产品成型，形成团队转型基础，当时3个月出演示，半年成产品，后面都是接入项目。对比另一个公司团队也在做，2年基础版本才刚刚体现，基本上很难跟上市场和行业发展。设计 在决策上很多时候(注意是很多不是所有)不怕出错，就怕没有结论。

顶层思维思考

从顶层往下看，规避一叶障目

遇到的，不管是哪类型的设计，即使考虑是最好的，是减轻或者有利的团队或者发展的，依然很难达到100%的愿景目标。

这类型问题出现比较多的情况在于细节性的体现，管理太细或者太粗都不太合适，需要适当的下发权限，在一定的规则范围内，形成一定的容错性。在一开始的时候，同样也会纠结很多细节，这个不好那个不对，过分的追求理想化，常常导致的消极的反噬。

在设计时，从顶层思维看问题，避免过分纠结于细节。重要的是要确保整体系统能够正常运行，并且有一定的容错和恢复机制。不应也不要(以前可能犹豫，现在是明确不要)追求完美，而是要保持持续优化的心态，随着系统运行和需求变化，不断进行调整和改进。

高工跟设计的思考区别会比较明显，特别在处理在高工阶段的时候，这也没有问题，但是在设计层面，更多的思考全局性的，保持良好的扩展和耦合管理机制，在之前遇到的，先能用，最坏的就是模块重构一下。

总结

以上是前期设计的一些经验，可能会跟遇到的理想化或者架构模式会有一定的区别，但是总的来说，是过程遇到的问题和一些经验记录，期望给一些同学进行参考。

在设计架构时，应该注重适应实际情况，避免过度追求新技术和复杂解决方案。尊重团队成员的能力和习惯，勇于做出决策，并确保系统具备一定的容错和风险保障机制。通过不断总结经验，并持续优化改进，实现架构设计的有效落地和业务发展的持续增长。

注：文章图片由讯飞星火大模型生成

软件工程师罗小东，多年平台架构设计经验，目前在研究平台与新技术结合中。

概述

做开发久了，发现身体的变化管理也是开发工程师的一个部分，貌似很难脱离这个话题，做了一下笔记。

三个月指的是23年9月到12月期间，原很早想记录做下笔记，过于零散，刚好跟新年的电影有类似（电影角色100斤的掉秤是很厉害的）。便做了梳理记录输出，下面以程序员的角度进行的阐述。

起因是行业的快速发展，会导致方向感的缺失而产生迷茫感，方向定位的不明确，在思考但是无法找到自我破局的方法， 干脆不思考进入机械式的生活，

大致是对生活缺少激情，处事机械式，不愿意思考，也不愿去讨论… 带来的负面就是会消极，失眠，夜宵，抽烟，熬夜，精神不振 … 除了躺着，对很多事情缺失兴趣。前期有过一些心理准备，但略微超出预期，带来了182斤的体重 … 开始进入胖子大军行列。

经过2-3个月的调整，大概减重33+斤左右，进行的整体改造的变化（第一张是减前的变化，第二张是减后的变化）：

好吧，最大号的T恤也被撑满了 :-(

计划是23年9月底，这里的改变会带来一些侧面的生活改变，属于积极的一面。大概有2-3个月的调整，改造的前提是自己在把控体质还有习惯，还有部分坚持方面自己可以把控，前期是带有一定的信心，也觉得是可行，每个人的体质和习惯不一样的，这里给出一些经验的参考。

调整方面

这里调整的方面，主要从几个角度来进行的进行的整体调整，包括以下的方面:

• [运动]生活节凑
• [运动]饮食情况
• [方向]衣服外表

以下是主要调整的内容点，细节较多，这里主要描述主要点。

生活节凑调整

一定要动起来，尽量(只能说尽量)正常作息。

职业还有本能的习惯，会在长期的电脑面前，还有各类电子设备，包括多种思考处理问题都在电脑面前，这导致一个非常明确的问题是不知不觉的熬夜，大脑会长期处于高度集中的状态，再加”来一根烟”，一下就到凌晨，自然而然的外卖就点了 …

再看时间已经到凌晨1-2点，但是大脑还没有休息的意愿，带来的结果就是第二天的精神不振，后期的注意力可能不集中，体现的外在就是皮肤、眼圈、形态、体重、沟通、思维等等方面的问题等 … 会有一种感觉怎么休息总不够，动的方面就不太好说了。

这并不是一个良性的习惯。

在9月底的前一个星期，主要调整的就是作息，所谓的作息就是尽量早睡，控制在电脑面前的时间段，晚上处理不完的，放到第二天早上，解决生物钟的问题，将身体机能恢复到正常的生物状态。这个过程大概是一个星期左右，你会发现精神会好很多，早上6-7点会自然醒，皮肤会好很多的，当然，这个过程主要是想把身体的代谢以恢复到正常状态，这个是减下去的关键。

运行方面，每天早上10-15分钟的运动，跑步就可以，先动起来，自己开始只是5分钟不到就累得不行不行的感觉，后面慢慢到20分钟，有个过程，这里因为前期有规划，在节凑上并不是特别的着急，按计划。甚至时间方面，在放下手机、电脑、早起的时候，会发现，时间会多很多，因为熬夜少，上床的时间早，早上一般是6点半到7点左右自然醒，跑步运动回来再洗个澡，也不到8点这样。

这个重点还是在于计划和坚持上面，有个过程。

饮食情况调整

尽量不要点外卖，能自己带就自己带。

吃的方面是重点，自己走的比较极端的路线，原来的计划是快速减体重，再保持，再塑身。前面两个月基本上严格控制:

• 水煮菜、鸡蛋、晚餐不吃或者说在6点前吃，吃也是水果蔬菜
• 大部分情况是早上吃1-2个鸡蛋，再加一个水果，有时候是瘦肉和荞麦面
• 中午还是两个鸡蛋，晚餐不吃或者一个鸡蛋，不吃米饭
• 饮料不喝带颜色的，只喝热水或者温水，保持肠胃的正常
• 每周吃一个大餐，就是那一天你想吃什么都可以，下馆半只文昌鸡
• 其它特殊情况较少，并不会影响

重点说明，这里需要根据每个人的体质去做调整，看视频一直听说这样会伤身，还有抑郁的可能，但是个人并没有什么感觉，而且会发现精神状态会好很多，不会带有以前外卖暴饮暴食的那种压力感，除了前一两周会晚上肚子特别饿以外，其它还好。

运动外加饮食的调整，这个基本上每天会按减1斤的步子走下去。好了，这便是想要的效果，找到减下来的方式，按每天1斤，这样第1个月基本上达到20+斤左右的减下来，开始会体现衣服的已经宽松了很多。

在第二个月的时候，中下旬已经达到近30斤的效果，下面的就是慢慢调整饮食到正常，还有保持运动下去，这个过程基本上饮食需要慢慢进入正常，对油腻的食品已经没有什么欲望，明显会感觉胃小了很多，吃饭可以达到七八分饭，对所谓的美食基本上只是觉得是一个份正常的餐饮，也不会特别强的食欲。

在第二个月底的时候，基本上达到预期，后面的几斤上下基本上就没啥感觉了，整个过程大概是2个月的时间。

后面一个月是预留下来的计划，想看一下1个月的情况是怎么样的，是否会反弹，还有如何自我控制，是否能控制。目前效果还比较理想，体重保存到144左右，有上有下，但是并不影响。

衣服外表调整

注意一下外表，除了爱自己也是尊重别人

在减到差不多35+斤的时候，你会发现，各个方面都会有较好的情况，包括心态、思维、还有生活等，特别是信心的提升。

下面是运动前后的形态对比，第一张是运动前的，大脸，眼神空洞，精神不振。另一张是调整后的，会体现干净和少年感。

好吧，状态确实不好，跟长期没睡眠似的 :-(

运动之后精神会好很多，而且脸型棱角也会体现，合适的衣服会让人更加立体，选择合适发型很重要，适当做好定型。

会体现一些少年感，进行外表的一些改造，原来是考虑走一些干练的路线。

• 衣服方面：尽量减T恤换成合适自己的，定制和买一些符合自己的西服，整个人会立起来，旧的衣物需要替换掉
• 发型方面：选择好合适自己的发型，做一下定型处理，定期或者每月进行一次修理，以干净即可
• 鞋子方面：基本把以前的鞋子都做了替换，选择合适自己的鞋子，这样结合上衣服，会立体很多，至少看起来
• 其它方面：比如生活不邋遢，经常倒垃圾等，这些看个人习惯

以上主要的调整方式效果还算较为理想，以前可能做一些连自拍的角度都找不到，现在还可以给自己留下一些自己的回忆纪念。

调整前后的对比

会出现各种心态的变化，这里改变的主要从体重身材、思维心态、生活状态等，从这几个维度来进行一些阐述和对比的状态其实还是达到预期的，而且各种方面会有一些负面的影响:

• 体重身材：身高不高，体重在182左右，三高开始出现，类似于你每天扛着三十几斤的肉在身上
• 思维心态: 带有一种习惯性的操作，很多操作都带是前期经验的习惯性，思考性的比较少
• 生活状态：比较消极，圈子也比较少，带有比较大的焦虑感，易燥情绪把握感并不是特别强
• 其它: 结构化思维不突出，出差或者沟通层面上略有疲倦感，缺少说服力
  …..

后期的改变状态，效果略带有明显，效果还是达到预期:

• 体重身材：体质恢复正常，144左右，各项指标开始回到正常，类似于把三十几斤肉从身上去掉
• 思维心态: 心态上会较为平稳，急燥的心态很少出现，同时在新设计方案和思路上会比较稳些
• 生活状态：会更加积极，结合经验会做好更好的自己规划还有落实，心态上会更偏于平衡
• 其它: 会更乐于沟通和交流，对外展示一些生活方面
  …..

上面的内容点身边遇到的人很多都遇到，毕竟圈子氛围比较明显，一些调整的经验，以做为参考。

总结

这个是在三个月的自我调整和改造，原来很早想做一下笔记，调整后会前期是带来一些生活的自信，每个人的体质和习惯不一样的，需要针对性做一些定制计划，这里给出一些经验的参考。

软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。

概述

年度输出规划会偏向于主动表达的意向，主要的目标让更多的人了解一些研究的方向，期望可以认识这方面有兴趣的朋友和交流，共同推进一些愿景，促进交流。

遇到问题

在前期研究和输出的方向偏向于中台或者中台产品化一些设计和在过程中的实践心得，主要遇到的问题比较多，原寄托的解决方案是超自动化理念，想结合类似于自动驾驶的概念，实现是中台自动驾驶的能力，类似于基于中台产品基础设施之上，进一步的实现更简便的落地的能力。

前期的产品化经验，基本上中台达到标准架构，标准接口，从技术、数据、运维、自动化、商务、支撑等几个维度的融合，服务的可折可分的模块化，可减可加的能力。但是依然在落地过程依然需要比较多的经验、架构师、团队、培训等磨合等，落地和建设成本依然较高。即使有一个技术中台，并不代表团队就可以用起来，用好，结合业务、企业方向发挥出能力。

原考虑通过研发中台自动驾驶操作模式进行管理。使该中台可以管理项目和软件的底层基础设施，能在不干涉的情况下生成优化中台。自动根据多年的中台研发和产品化经验，运用经过实践检验和强化的最佳实践来管理和维护中台，特别是优化在最低级别的场景方面。这些工作有助于保护中台，提高基础中台的稳定性和可控性，使中台管理更加自动化和智能化，结合实践过程中的指导和管理的最佳实践。

输出内容

输出部分主要是针对以上问题的解决方向，结合大模型Agent一起，将整个中台进行重新调整，结合未来3-5年的技术，还有AIGC的能力,结合LLM的推理能力，实现更加智能化的中台。

以下是整个架构图:

这里的处理思路是在原来的中台上面加上一层LLM的推理能力，通过Agent来与中台进行交互，中台类似于沙箱，来进行整体的执行。

可以理解成LLM的推理是一个协调的大脑，而执行的操作，视觉，触觉，感知等，由中台来进行收集处理，这部分怡好是技术中台的强项。不断新增加的能力会沉淀到中台(按中台标准化)进行管理和输出，Agent通过上层进行交互管理。

在积累沉淀的Agent和团队实际情况结合，经验以Agent和知识库进行沉淀积累，不断下沉行业的内容，做加法。当然，也可以配置出Agent来不断的自动增加服务能力，比如自动生成代码生成器的插件。规避掉落地的成本，毕竟Agent是可以复制的，角色也是可以复制的。

前期架构于23年搭建，当前整体架构设计已输出一版本，前期做了部分工作，今年的主要的目标是调度和优化交互，还有完善底层各个服务组件的内容。在这个过程中，同步以电子书的形式做为记录。

这个过程以github开源和记录的形式进行内容输出，通过对自动化技术和多Agent协作的探索，希望能进入另一个产品和智能化产品开发时代。此为业余时间研究内容，只为学习使用，暂时不涉及商业性的，后期会跟一些朋友公司进行一些探索和内部团队落地测试，以技术讨论交流为主。

总结

以上为年度输出规划，过程会有细节性的调整，会根据一些交流的意见还有建议等进一步的优化，包括更新，升级等，总体架构基本不变。每个架构师和设计人员都有自己的思路，我有我思，期望可以认识这方面有兴趣的朋友和交流，共同推进一些愿景，促进交流。

个人知识和经验有限，为规避误导，过程以原创和实践操作过为输出的基本要求。

相关地址:

电子书同步开源项目: http://portal.infra.linesno.com