节选自《Netkiller Architect 手札》第 2 章 AI 时代的逆向操作目录2.1. 重回服务器渲染走过 26 年互联网技术路我为何逆向选择2.2. 重回 HTTP Auth Session2.3. 重回 hardcode 硬编码2.4. AI 驱动运营2.1. 重回服务器渲染走过 26 年互联网技术路我为何逆向选择2000 年入行完整走完互联网渲染技术的全周期从最早的 CGI 到如今遍地开花的前后端分离最后在 AI 浪潮里反向折返重新拥抱服务端渲染这段经历藏着互联网技术的轮回与当下 AI 时代的新解法。2000入职场我经历了什么最早 Apache HTTPD C语音 / Perl语音开发CGIIIS JSP Access SQL Server / Apache/Nginx fastcgi PHP MySQLTomcat Java JSP JavaBean PostgreSQLEJB Jboss, Oracle Weblogic , IBM websphere前后端分离 Nginx Jquery / Angular / React /Vue.js /Next.js Java Springboot前端发展过程HTML拼接HTML模版前后框架后端分离事实上前后端分离这些问题才出现的页面刷新每次访问页面都需要重新渲染和刷新加载性能页面全量加载网络传输慢HTML拼接繁复等等问题请帮我补充。前后端分离并为解决所有问题而为还带来新的问题前端越来越复杂导致全栈能力要求越来越高不得不前后端变成两个岗位。诞生了新的岗位前端和后端开发开发工作需要贫富密切沟通对齐接口。数据安全接口json数据安全带来全新挑战以往数据在服务端处理用户只能看到输出经过。现在不得不为前端提供很多明文接口。一旦权限疏忽就存在泄漏数据风险。随之AI时代的到来加上 IPv6 HTTP3 Ajax HTML模版 分级缓存等等技术。我决定重回服务器端渲染甚至重拾PHP我需要的是立即看到效果不想每次启动服务。我的做法是使用模版技术动态渲染HTML同时给渲染结果做缓存。替代前端每次build dist 的过程。Web 服务器做 etag, 修改时间cache 头缓存所有所有静态资源。局部更新 ajaxjson 也会做一层缓存etag修改时间Cache-Control开启 HTTP3Ipv6实际每次加载都是走本地缓存。动态内容 ajax最后用户体验超好AI写程序也不即完成前端还要写API接口。目前我已经有多个项目用这种方式落地。Springboot Webflux Thymeleaf TemplatePython FastAPI Jinja2 Template下一个项目我打算回到 PHP 时代因为 Springboot 和 FastAPI 每次都需要重启加载真的太烦了。架构这东西要复合时代不同时代适合不同架构现在是AI时代给了打工人一次逆天改命的机会需要考虑用AI加杠杆放大自己的能力。所以我不禁回到服务器端渲染我还放弃了“微服务”返回到“单体服务”时代。2.2. 重回 HTTP Auth Session从业26年我经历了 SessionRedis token, JWT, OauthOpenID……等各种认证与授权方案。早些年我也很喜欢追随大厂的技术路线Kubernets, gRPC……如今人变得成熟了不再一味追求新技术每次架构选型更多是考虑用户需要什么产品如何快速落地安全性扩展性鲁棒性……我们选择了 HTTP Basic/Digest 认证 Session 方案放弃了 Oauth 和 JWT甚至没有 Login 页面登录对话框是客户端浏览器的也没有退出和注销按钮用户必须关闭浏览器退出。一切变得简单了HTTP Auth 是 Web Server 级别的认证不需要写额外代码他还有一个其他方案不具备的优势。能把联通静态资源一起纳入认证范畴哪怕是 css,js,image 都必须登录之后才能访问。机遇这个特点HTTP Auth 天然防爬虫爬虫什么资源都拿不到。回到 Session 方案用户状态信息在服务器端保存而 JWT 就像泼出去的水你对用户端失去了控制。经常关注 Spring Session 的小伙伴会发现它还在持续更新也就是 Session 并没有死人们也没有放弃他。当年我们选择放弃他是因为大型网站的 Session 开销成本巨高Session 是大型网站的瓶颈主要来源。而如今我们做的系统更多是小而美企业级的产品并不是海量互联网级别应用。在考虑系统架构的时候我们没有必要把互联网产品思维套用在企业应用上。机遇这个思维我决定回到 Session 方案。目前我们已经在多个企业级产品中使用 HTTP Auth Spring Session Spring Security 解决安全问题。2.3. 重回 hardcode 硬编码什么是 hardcode硬编码一句话 hardcode 就是把本该可配置、可变化的值直接写死在代码里。在过去的数十年中我们开发规范 不允许 hardcode 但是很多业务逻辑的使用频率不足 20% 把这些功能全部用动态实现即产生开发工作量得不偿失。对于低频率的修改反而我们区代码中改一个字符串成本更低。在过去数十年的软件开发实践中开发规范通常都强调避免 hardcode。但在真实业务中很多业务逻辑的使用频率并不高甚至不足 20%。如果为了这些低频功能全部设计成动态配置不仅会增加开发复杂度也会带来额外的维护成本甚至各种配置动态加载和事件监控影响主程序的性能往往得不偿失。对于低频变更场景与其构建一套复杂的动态配置机制不如直接在代码中修改一个字符串成本反而更低。我们都经历过微服务和配置中心还有印象吗当年很多系统为了追求“灵活”和“解耦”把原本简单的配置不断外置把原本可以直接写清楚的逻辑拆成分布式配置项。结果系统看似更加灵活实际却变得更难理解、更难排查也更难维护。很多问题不再能通过阅读代码直接定位而是需要同时查看数据库、配置中心、缓存、环境变量和多个服务之间的调用关系。所谓的“灵活性”最后变成了认知成本和运维成本。对于高频变化、强运营驱动的场景动态配置当然有价值但对于低频变化、规则稳定、影响范围可控的业务逻辑过度动态化反而是一种工程负担。一个配置中心里大几十个配置文件每个配置文件的配置项超过一页A4纸其中 80% 自它们创建以来就安静地躺在那里从未被修改过。每次升级光是核对配置文件就要花掉一些时间由于配置产生的故障比比皆是甚至可以说上线后的验收测试的核心之一就是检查这些配置是否正确。如今我们开始主动“去微服务”、不在使用配置中心清理大量无用配置项。对于低频变更、规则稳定的业务逻辑更多采用常量配置让系统回到清晰、可读、可控的状态。最终带来的结果是升级链路更短系统复杂度更低发布更可控真正实现了一键升级、秒级完成。至于大量 hardcode 会不会增加维护成本在过去答案是有可能。但在 AI 辅助开发时代低频、明确、局部的规则修改已经可以交给 AI 完成几乎是零成本。2.4. AI 驱动运营以往我们通常会给运营团队提供一个管理后台里面包含各类数据报表运营人员可以从不同维度查看业务数据。不同公司的叫法各不相同有的叫“报表系统”有的叫“BI商业智能”还有的包装成数据中台等等。这些概念听起来都很高大上还常常堆砌大量互联网黑话大数据、数据萃取、OLAP、ETL、数据建模、指标体系……但说到底很多场景只是把数据筛选、汇总、排序、统计和导出做了一遍而这些功能Excel 本身就能胜任。如果你是打工者这样做不仅可以增加工作量同时还能提升 KPI 绩效包装个人形象甚至形成技术壁垒把自己变成系统里“看似不可替代”的一环。但如果这是你的创业项目或者你自己的产品就不要再用这种方式自欺欺人了。大家都心知肚明很多复杂系统并不是业务真的需要而是组织内部人为制造出来的复杂性。最近我们又立项做了一个新系统。按照过去的惯性当然也要配套一个管理后台提供数据报表、筛选查询和运营分析能力。按照传统做法我们至少需要配置两名开发人员长期响应运营提出的各类数据查询、报表调整和临时统计需求。看似是在支持业务实际是在用人力维护一套低频、重复、碎片化的报表系统。但这一次我的想法发生了变化。我认为在 AI 时代我们已经不再需要为每个系统都单独开发一套报表后台了。很多报表类需求本质上只是数据查询、筛选、汇总和展示。过去运营人员必须通过后台页面交互查询报表数据而现在完全可以交给 AI 通过对话完成。接入 Hermes 与 OpenClaw 后AI可以覆盖运营人员的绝大部分数据分析需求。运营人员不再需要进入后台在一堆菜单、筛选项和报表页面中反复点击他们只需要在对话框中输入帮我统计第二季度的销量分析XXX产品销量下滑的原因请每天统计用户注册数量用柱状图展示最后发到 netkillermsn.com 邮箱中监控XX产品销量达到 10k 后用飞书发送消息提醒我。这是 AI 驱动运营在 AI 时代想象力才是真正的边界。AI 让能力边界无限延展限制我们的不再是工具而是想象力。