AI 时代，技术人的价值在哪里一、一个 AI 无法给出好答案的真实场景2025 年初，我们要做一个关于系统改造方向的决策。 背景是：我们有一套运行了四年的订单系统，现在要支持新的业务形态——B 端企业采购，和原有的 C 端逻辑差异比较大。问题是：到底是在原有系统上做扩展，还是单独起一套新系统？ 这是一个真实需要做决定的问题。我试着把背景描述给 AI，让它给出判断。 AI 给了一个结构很完整的分析：从扩展性、维护成本、迁移风险几个维度分析了两个方案的利弊，说如果业务差异大且规模允许，可以考虑新系统；如果资源有限，扩展原系统风险更小。最后结论是”根据实际情况权衡”。 这个答案没有错，但对我没有用。因为”实际情况”正是那些 AI 不知道的部分： 我们团队现在只有 6 个人，新起一套系统意味着这 6 个人要维护两套代码； 产品侧对这个 B 端方向还没有想清楚，有可能三个月后就砍掉； 原有系统的订单模块有一个老同学在维护，他今年年底可能会离职； 这些因素是无法通过提示词传达给 AI 的。不是因为 AI 笨，而是因为这类信息根本没有结构化，它们存在于我的脑子里、团队的对话里、和产品同学一次次讨 ...

用 Ollama 在本地跑大模型：隐私场景下的可行方案为什么要在本地跑有一类场景，把代码发给云端 API 让我不放心：公司项目的核心业务逻辑、还没上线的功能代码、包含内部命名约定的配置文件。 不是公司有明确规定不让用，而是把这些东西发给外部 API，总是有些说不清楚的顾虑。Ollama 解决的就是这个场景：模型跑在本地，数据不出局域网。 另外一个使用场景：有时候想随手问个简单问题（比如 SQL 怎么写），但 API 计费或者要开梯子，懒得切。本地模型的代价是响应慢一点，但「随时可用、不联网」这个特性有时候比速度更重要。 三步跑起来第一步：安装 Ollama # macOSbrew install ollama# Windows / Linux：直接下载安装包# https://ollama.ai/download 安装完成后，Ollama 会在后台启动一个本地服务，默认监听 http://localhost:11434。 第二步：拉取模型 # 推理能力较强，7B 参数，约 4.7GBollama pull deepseek-r1:7b# 轻量快速，约 2GB，适合代码补全ollama ...

让我真正开始思考”架构”的那次讨论一、那场讨论的背景2024 年年初，我们有一个商品详情页面的性能问题。 用户反馈这个页面偶发性慢，SkyWalking 上看到最慢的请求超过 3 秒，但平均响应只有 400ms 左右，分布两极化。页面涉及的数据来源有三个：基础商品信息、库存状态、营销活动。 组内开了个讨论会，把负责这几个模块的同学都拉进来，想找一个解决方案。 二、我当时的第一反应我的第一反应很直接：加缓存。 技术路线很清晰：Redis 缓存商品详情聚合数据，TTL 设 5 分钟，命中率上来之后数据库压力下去，响应时间自然稳定。我在会上把这个方案说出来，几个人点头，觉得可行。 从纯技术角度，这个方案没毛病——Cache Aside 是标准模式，复杂度不高，我大概估了一下，两天能实现，一天测试，上线。 三、转折：约束条件比技术方案更重要会议进行到一半，技术负责人问了几个问题，让讨论转了一个方向。 第一个问题：**”这个页面的数据，业务上能接受多少延迟？”** 我说 5 分钟 TTL 应该可以接受。他说：库存状态能接受吗？如果活动刚开始或者库存刚售罄，用户看到的是旧数据，会发生什么？ 我想了 ...

用了一年 AI 辅助编程，它重构了我对”效率”的定义一、我用 AI 工具做过的最典型的几件事从 ChatGPT 到 Cursor，大概算下来用了将近一年半。挑几个最典型的场景说： 场景一：写模板代码。 Controller / Service / DTO 这类有固定格式的代码，以前靠 IDEA 插件生成，现在直接告诉 AI “给我生成一个带分页查询的 CRUD 接口，参数是 XXX”，30 秒出来，我再对照业务做微调。这类任务提效最明显，大概节省了 70% 的时间。 场景二：解释遗留代码。 接手一段历史代码，看不懂意图，以前要靠 debug + 问老同学。现在贴给 AI，让它解释这段代码在做什么，十次有八次能给出合理的解读，帮我快速定位看哪里。 场景三：排查报错。 把 stack trace 粘给 AI，问它可能是什么原因，它能给出几个方向。不是每次都对，但作为第一步定位很有效，省掉了盲目搜 Stack Overflow 的时间。 场景四：写 SQL。 复杂的多表关联 SQL，以前要想很久。现在描述需求，AI 给出 SQL 草稿，我 review 一遍，改掉不符合我 ...

从 IDEA 到 Cursor：一个 Java 后端的 AI 编辑器迁移记录为什么开始试 Cursor在 IDEA 里装了 Copilot 插件用了大概半年，效果是有的，补全有时候挺准，但用起来有一种「工具叠工具」的感觉——IDEA 的功能和 Copilot 的补全是两套逻辑，偶尔会互相打架。 真正让我决定试 Cursor 的是一次帮同事看代码，他在用 Cursor，我看他用 Ctrl+K 直接在代码里问问题、用 @file 引用多个文件上下文，那个交互方式和 Copilot 的行内补全感觉不是一个量级的东西。回去之后我下载了 Cursor，然后就没再用 Copilot 了。 三个维度的对比1. 代码补全质量 Copilot 的补全更像是「续写当前行」——根据已有代码的上下文预测你接下来要写什么，对熟悉的模式很准，但它不太理解「这段代码在整个项目里是做什么用的」。 Cursor 的补全明显感觉「知道更多上下文」。同样是写一个 Service 方法，Cursor 会把同文件里的其他方法、@Autowired 的依赖一起纳入补全参考，给出的方法体更贴近项目风格。差异在复杂场景下尤其明显—— ...

没有那么不堪，不要妄自菲薄享受存钱，享受运动，静心读书，早睡早起， 今天从一个博客中听到上面四个好的生活方式，发现自己已经符合其中几项。 存钱是我从小到大的消费观。 运动近三个月已经逐渐开始，并且接受。 读书，或许从离开校园后已经很久没有认真读书了，应该重新捡起这个习惯了。 早睡早起，生物钟本来就这样，哈哈。 今年刚开始去健身房，发现很多人的体态和强度都很好，感觉自己要努力很久才能达到正常人的水平，有点自卑和惋惜。 直到今天，我又想起了那句话：”种一个树最好的时间是十年前，其次是现在。” 受穿越重生逆袭剧的影响，我也曾白日梦过自己回到上学时期，要求当时的自己更努力，找更准的方向。不如当做40岁的自己现在就在我身边，告诫我要努力，才能摆脱十年后的困局或者疾病。 加油！

一道我曾经答不好的架构问题，今天我来重答一、那道题是什么，当时的背景2019 年参加一次技术面试，面试官问了这么一道题： 「你们系统的缓存和数据库是怎么保持一致的？」 当时我的回答大概是：「用 Redis 缓存，查询先查缓存，没有再查库，更新时先更新库再更新缓存，或者让缓存过期。」 面试官追问：「如果先更新了数据库，还没来得及更新缓存，另一个线程来读，读到了脏数据，怎么处理？」 我有点慌，说「设置缓存过期时间，等它自动失效」。面试官没有继续追问，面试最后也没有通过。 那道题我当时就觉得答浅了，但不知道浅在哪。 二、当时我的回答，为什么没答好回头看，当时的答案有两个问题： 第一，没有意识到「先更新库还是先更新缓存」是一个有具体权衡的选择。 我把它当成了一个无所谓的实现细节，其实两种顺序各有不同的风险，需要根据业务容忍程度来选。 第二，「过期时间兜底」是一个工程策略，不是一个解答。面试官在问「并发情况下的数据不一致窗口怎么控制」，我用一个「最终一致性兜底」直接跳过了这个问题。 三、后来哪些经历让我真正理解了这个问题两次经历。 第一次是 2021 年，我们的商品详情页缓存出了一个问题：商 ...

这篇是搭建测试环境的操作手册，整理给自己和团队成员参考用。 背景是项目从开发转测时，需要在一台干净的 CentOS7 服务器上从头搭起来：基础中间件、CI/CD 环境、微服务部署，整套跑通。记录下来，下次换机器或者新人入职可以直接照着走。 前置假设：CentOS7.6，已安装 Docker，已有 GitLab/Minio/MySQL/Redis/RabbitMQ 等基础资源（如果没有，参考下面的基础中间件启动部分）。 0. 基础中间件 Docker 启动 这部分适用于没有独立中间件服务器的情况，直接在当前机器上用 Docker 启动。 MySQLdocker run -p 3306:3306 --name mysql \ -v /home/mydata/mysql/db:/var/lib/mysql \ -v /home/mydata/mysql/conf:/etc/mysql/conf.d \ -v /home/mydata/mysql/log:/var/log/mysql \ -e MYSQL_ROOT_PASSWORD ...