前几天整理旧硬盘，翻出了web_sy这个项目。文件时间戳显示。那是我学 Java 的第一年，写出的第一个"能跑"的系统。20年后的今天再看这些代码，我笑着笑着就哭了。

后端封装组件靠类和方法。Android封装UI靠自定义View。我的就是一个自定义标题栏——继承，在构造函数里 inflate 布局，在代码里处理按钮事件。任何一个Activity想用这个标题栏，一行就行。这不就是前端组件化的思想吗？只是Android比Vue/React早了很多年。有Java基础的人学Android原生开发，不是从零开始，是从80分开始。

它们都是"重复决策"。每次配置 Bean —— 重复每次解析请求参数 —— 重复每次取参数转类型 —— 重复每次写日志开连接 —— 重复每次管事务的提交和回滚 —— 重复每次拼接 SQL —— 重复框架做的事，就是把重复决策变成约定。你遵守约定（加注解、用统一格式、按命名规则传参），框架替你处理剩下的所有事情。Spring 的每一个模块背后，都是一个具体的痛点。理解了痛点，你就理解了 Spring

不要为了"可能的未来"做抽象——adapter 层就是为永远不发生的 UI 切换付出的成本数据来源应该是组件的隐式依赖而非显式参数——字典中心比 props 更适合跨组件共享数据绑定协议比 v-model 更适合低代码场景——父组件不需要管理 form 对象，切换编辑目标只需要一次赋值。

*** 装饰模式角色枚举*//** 被装饰的原始对象 */COMPONENT("基础组件"),/** 装饰器抽象类 */DECORATOR("装饰器基类"),/** 具体装饰器 */CONCRETE_DECORATOR("具体装饰器");角色Java IO对应框架对应COMPONENTReader业务BeanDECORATOR✅ Java IO 标准库案例，无需额外依赖✅ 框架代理代码可直接运行✅

这些内容不难，难的是在写代码的时候意识到自己在踩这些坑。抛空指针的时候，如果不知道是因为str是 null，就只能猜。知道了，以后所有字符串比较都反着写。这就是培训的价值——不是讲高级概念，是把踩过的坑标出来，让别人不用再踩一次。

1. 先单用户基准测试——确认接口本身没问题2. 逐步加并发（10→30→50→100）——找到拐点3. 在拐点处分析瓶颈——是线程不够、CPU不够、还是网络不够4. 针对性优化——调线程池、加队列、加机器5. 稳定性测试——跑1小时以上，排除内存泄漏不要一上来就100并发——先摸底再加压，才知道瓶颈在哪。政务系统的压力测试，关键不在工具多高级，在于方法对不对从低到高逐步加压，找到性能拐点在拐点处

摘要：本文记录了一位20年老程序员与AI协作，仅用2-3小时搭建社保智能客服系统的实战过程。系统从单轮问答升级为多轮Agent，实现了12项社保业务办理功能。开发采用真/假服务分层策略，核心功能使用真实服务，非关键模块用桩模拟。文章详细记录了14个关键问题的解决过程，包括字段校验、上下文处理、语音集成等挑战。最终系统支持多业务配置化扩展、敏感信息后置采集、移动端语音交互等特性，展示了AI辅助开发的

组件安装方式EasyOCR，首次运行自动下载模型（约100MB）PaddleOCR，表格模型需手动下载讯飞语音，需注册讯飞开放平台获取APPID/KeyPython3.9-3.11三个工具都不需要GPU，CPU就能跑。PaddleOCR和讯飞语音在有GPU的环境下会更快。工具做了什么关键点EasyOCR简单文字识别安装最简单，中文准确率一般PaddleOCR中文文字+表格识别政务场景首选，表格识别

LLM必须本地部署——社保数据不能出域，不是选择题GPU按参保人口推算——700万参保→峰值30-40 QPS→4卡A800或6卡昇腾910B方案可以等比缩放——换成300万人的市就砍半，换成1500万人的省就加50%昇腾是信创的最优解——比A800便宜，还自带合规加分先问大数据局有没有算力池——一个电话可能省几十万便民不是技术指标——是让不懂政策的人也能自己办事这个方案给的是小型省份（1000万