崔安兵的博客

不要教AI做事：限制AI能力的，其实是我们自己这段时间和 AI 协作做项目，踩了一个反复出现的大坑，慢慢悟出一个反常识的道理：很多时候不是 AI 能力不足，而是我们在用固有的思维框住它，亲手锁死了它的潜力。 我踩过的坑：习惯性教 AI 怎么解决问题过去很长一段时间，我使用 AI 的模式是：遇到问题，先在脑子里构思一套自认为可行的方案，把步骤丢给 AI，要求它按我的思路落地。 AI 只负责执行细节，不能偏离我预设的路径。可往往折腾很久，产出结果不尽人意，边界问题层出不穷，不停返工。 直到某次我放下预设，反问 AI 有没有别的思路，它给出了更简洁高效的方案，很多我完全想不到的捷径，就这样摆在面前。 正确的协作方式：讲目标，而非教步骤高效使用 AI，核心不是告诉 AI 怎么做，而是把目标、问题背景、业务要求、约束限制完整交代清楚。 把原始问题摊开，交给 AI 去推导多种可行方案。我们的重心放在和 AI 反复研讨方案优劣，不要着急进入落地环节。 先一起找到最优捷径，再动手执行，不要一上来就把老旧的固有思路强加给 AI，限制它的思考空间。 沟通小技巧：语音沟通，补齐完整上下文打字沟通有天然...

M.2固态硬盘接口和协议M.2接口也叫NGFF，英文全称Next Generation Form Factor，是Intel推出的一种替代MSATA新的接口规范。自2012年M.2标准正式推出以来，至今已经有13年时间了。这个标准最初被称为下一代外形规格（NGFF），2013年被正式更名为M.2。M.2标准是一种用于计算机内部扩展卡的规范，之所以能被广泛采纳，主要得益于其在性能、应用灵活性、多接口兼容以及紧凑外形上的显著优势。M.2不仅提升了性能和容量，还能有效减少模块体积。 M.2尺寸、钥位/接口及插槽的术语含义M.2模块不仅有多种尺寸选择，还广泛应用于无线通信扩展卡，比如Wi-Fi和蓝牙适配器。此外，还可用于近场通信（NFC）、卫星导航（GPS）、数字广播、WiGig无线模块以及用于蜂窝网络连接的无线广域网（WWAN）模块等场景。为了确保不同类型的M.2模块能精准匹配主板插槽，PCI Express M.2规范制定了一套统一的命名和接口标识方式。 M.2尺寸命名下表列出了PCI Express M.2规范5.1版中有关M.2命名方式的详细信息 通过上述标准命名规则，...

使用 Docker 部署自定义 DERP 服务器，支持域名反代和纯 IP 两种方案，配合 ACL 配置，支持 IPv6。 Tailscale 默认使用官方的 DERP 中继服务器，但在某些网络环境下延迟较高。自建 DERP 服务器可以显著降低中继延迟，特别是当你的节点分布在特定地区时。 前置条件 一台有公网 IP 的 VPS（建议选择延迟低的地区） 已安装 Docker 和 Docker Compose 域名并配置好 DNS 解析（方案一需要，方案二不需要） Nginx（或其他反向代理）处理 SSL（方案一需要，方案二不需要） 方案一：域名部署 DERP（反向代理模式）Docker Compose 配置创建 docker-compose.yml： 12345678910111213services: derper: container_name: derper image: fredliang/derper restart: always network_mode: host # 直接使用宿主机网络，支持 IPv6 environment: ...

通过 Tailscale ACL 配置客户端端口随机化，绕过针对 41641 端口的封锁。 Tailscale 默认使用 UDP 41641 端口进行 WireGuard 通信。如果该端口被运营商或网络环境封锁，会导致无法直连，只能通过 DERP 中继，速度大幅下降。 问题分析Tailscale 的默认端口 41641 可能被以下情况封锁： 运营商针对特定端口的 QoS 限速或封禁 公司/学校网络防火墙规则 某些地区的网络审查 被封后的典型症状： 节点间延迟明显增加 传输速度只有正常的几分之一 tailscale status 显示通过 DERP 中继连接 解决方案：开启端口随机化这是 Tailscale 官方提供的功能，通过 ACL（访问控制列表）全局设置，强制所有客户端使用随机端口。 配置步骤 登录 Tailscale Admin Console 点击左侧菜单的 Access Controls 在 JSON 配置文件的 acls 部分之前，添加以下设置： 1"randomizeClientPort": true, 完整示例： 1...

解决笔记本在 Debian 13 无法调节亮度问题通过修改 GRUB 内核参数解决 Debian 13 笔记本亮度调节问题 切换背光接口（常见修复法）1sudo nano /etc/default/grub 找到： 1GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" 在里面添加一个参数（常见几个可尝试）： 1acpi_backlight=vendor 或 1acpi_backlight=native 最终那一行类似于 1GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_backlight=native" 保存后更新 GRUB： 1sudo update-grub 然后重启系统即可。

腾讯云 DD 重装系统教程操作前重要提示 数据备份：DD操作将完全覆盖磁盘数据，请提前备份重要文件 网络要求：确保服务器已开放全部出站端口（建议临时开启） 风险须知：操作可能导致服务不可用，建议在业务低峰期进行 一、清除腾讯云组件12345678910# 停止并禁用监控组件systemctl stop tat_agentsystemctl disable tat_agent# 删除相关文件rm -rf /etc/systemd/system/tat_agent.service rm -fr /usr/local/qcloud# 检查残留进程（按需处理）ps -A | grep agent | awk '{print $1}' | xargs -I {} kill -9 {} 二、系统重装操作1. 准备环境12apt-get updateapt-get install -y xz-utils openssl gawk file curl wget 2. 下载DD脚本1curl -O https:/...

ZeroTier 禁用 IPv6 或 IPv4，让连接更顺畅通过配置 local.conf 绑定特定协议，解决 ZeroTier 在国内 IPv6 丢包严重的问题 ZeroTier 使用 IPv6 在国内非常容易丢包，禁用 IPv6 后连接会更稳定。 配置文件位置需要在 ZeroTier 目录下创建 local.conf 文件： 系统 路径 Windows C:\Users\<User>\AppData\Local\ZeroTier macOS ~/Library/Application Support/ZeroTier Linux /var/lib/zerotier-one/ OpenWrt /overlay/upper/etc/config/zero 以 Linux 为例，目录下通常有这些文件： 123root@VM71695:/var/lib/zerotier-one# lsauthtoken.secret identity.public metrics.prom networks.d planet ...

dd命令简介很多刚学Linux的朋友，都会听过一个又强又危险的命令：dd。 大家常说它是「Linux数据复制界的手术刀」「磁盘操作瑞士军刀」，既能做普通文件复制，也能做底层磁盘备份、做系统启动盘、清空硬盘。但同时它也被称为删库跑路神器，参数写错就能直接清空硬盘数据。 一、dd命令到底是什么？1. 全称与核心作用dd 全称 Disk Dump（磁盘转储），是Linux系统原生自带、底层级的数据操作命令。简单一句话总结： cp是复制「文件」，dd是复制「原始数据块」 普通的 cp、mv 命令，是基于文件系统工作的，只能复制完整文件； 而 dd 不看文件、不看格式、不看分区，直接读写硬盘/U盘的原始二进制数据，按「数据块」逐字节搬运。 2. 它能做哪些普通命令做不了的事？ 完整备份整个硬盘、整个分区（包括隐藏数据、删除残留数据） 制作系统镜像、写入U盘启动盘 生成指定大小的空文件（测试磁盘速度专用） 彻底清空磁盘数据（不可恢复） 磁盘对拷、数据裁剪、数据格式转换 二、dd核心语法（全网最好懂的解释）1. 固定语法格式dd 的语法和所有Linux命令都不一样，不使用短横杠...

重构：聊聊代码的复杂性写代码这么多年，我大部分时间都在和代码复杂性较劲。早在 20120年我就写下了这份思考，一直存于本地没有对外发布。后来再读，很多观点依旧没有变化，整理出来，供大家参考。 复杂从哪里来代码的复杂性可以拆成两层：业务本身的复杂性，以及代码结构带来的额外复杂性。 对于具备一定规模的系统，程序员的工作不只是完成功能，更重要的是消除结构带来的额外复杂度，让代码结构在各个抽象层级，和真实业务逻辑对齐，也就是常说的：写出来的代码，就是你想表达的业务。 业务逻辑变复杂，大多来自业务迭代发展，这是客观现实，开发只能接受并提供支撑。当然如果你同时承担产品角色，可以从产品层面对需求做取舍权衡，但这不在本文讨论范围。 抛开业务固有的复杂度，真正折磨人的，是代码结构越跑越乱。 根源往往不在于某个惊天动地的大 bug，而在于开发者对代码结构的把控能力不足。很多不起眼的小问题，比如方法内充斥大量临时变量、方法参数过多，开发者察觉不到隐患。随着业务迭代，这些小问题会持续堆积。 等到某天代码变得难修改、难复用的时候，很多人不会选择重构，而是本能地打补丁：多加一个参数、新增一堆 if 分支处理...

论架构自上而下与开发自下而上的协作平衡当下不少团队里弥漫着一种风气：人人谈架构，事事讲设计。会议上架构图层层叠叠，方案推演天花乱坠，大家热衷于讨论顶层概念、模块划分、系统边界，却很少沉下心审视底层实现、技术细节、落地风险。最终产出一堆漂亮的设计文档，真正落地的时候却处处碰壁，方案和实际代码脱节，理想蓝图难以转化为可运行的系统。 这种现象本质上混淆了两种核心能力：架构师的化繁为简，与开发执行者的化简为繁。二者是软件研发一枚硬币的两面，缺一不可。架构负责自上而下定义方向，开发负责自下而上填充细节；脱离细节的架构只会是空中楼阁，缺少顶层指引的开发只会不断制造代码泥潭。 一、两种核心能力：化繁为简 vs 化简为繁架构师的核心能力，是化繁为简，自上而下做设计。 面对杂乱的业务诉求、错综复杂的现状系统，架构师需要拨开表象，提炼共性、抽象模块、划定边界、定义接口。把一堆混乱的业务问题，收敛成清晰的系统结构，回答清楚：系统分为哪些模块，模块之间如何交互，核心的技术选型是什么，整体演进方向往哪里走。 这份工作的产出往往“看不见”：可能是一份架构文档、一组接口定义、一次关键决策、寥寥几处核心改动。它...