博客产线（一）：我给 AI 搭了条产线，然后被首篇文章教育了
你现在读的这篇，是产线写完第一篇真文章之后，回头写的第二篇。题材就是产线本身：怎么选技能、怎么编排、怎么在第一次实跑里被现实教育，又怎么把教训长回产线里。 产线长什么样先交代结构。一条文章的生命线是四步：研究、写作、润色、发布。前三个环节各有专门技能负责。content-research-writer 是个写作伙伴技能，管研究、搭大纲、逐节写作和逐节反馈，产线用它跑博客文章工作流：先一起定大纲，再逐节写、写完一节审一节，技术教程类还要检查代码示例可不可执行。润色归 write，专职去 AI 味；humanizer-zh 从维基百科那页”AI 写作特征”清单来，专治三段式排比、夸大象征这类机器腔。这些技能都不是我写的，是现成的，产线只负责在正确的时机把它们叫起来。 我要补的是两块：一块叫编排，一块叫闸门。 编排就是一个叫 blog-pipeline 的技能，它自己不写一个字，只干一件事：看你处于哪种场景，把对应的子技能按需叫出来。写新文章走全流程；改旧文走 edit-article；只润色现成稿子就跳过前面直接进润色闸。它像个领班，不炒菜。产线的全部家当就是这张路由表： ...
悬疑游戏平台（一）：从一锅海龟汤到会撒谎的剧本杀
海龟汤是一种聚会推理游戏。出题人抛出一个离奇的汤面，比如”他每天都吃企鹅肉，吃完就哭了”，玩家只能提用”是”或”否”回答的问题，一点点逼近汤底。这个游戏的乐趣全押在出题人身上：他知道全部真相，还得守住秘密。 我想，这件事 AI 天然就擅长。它读过的悬疑故事比任何人类出题人都多，不累，不剧透，随叫随到。于是有了 海龟汤，一座从一锅海龟汤长出来的悬疑游戏平台。截至 2026-09，它有三种玩法、三本原创真人剧本杀、70 道单机汤题，微信支付真实跑通，660 多个后端测试守着部署门禁。 这篇文章复盘这座平台怎么长出来的，以及让 AI 扮演一个会撒谎的凶手，需要哪些设计。 三种玩法，一条商业化平台首页是暗色的终端风格，三种玩法并排摆着，共用同一套账号和会员体系。 第一种是经典汤面推理。30 道精修题库，点开就玩。每一次提问，AI 实时判定”是 / 否 / 无关 / 是也不是”，判定依据是它对汤底的理解。卡住的时候可以要提示，觉得还原得差不多了，就用自由文本写出你心中的真相，AI 给出评分和点评。它还会现场出题：输入主题和难度，生成一道全新的汤。会员可以定制...
Linux 系统信息查询：比 cat /proc 时代更好用的命令
2024 年我在 CSDN 写过一篇《CentOS 系统常用信息查询》。两年后再看，那篇里的命令能跑，但大多绕了路：cat /proc/cpuinfo 配管道数行数、用 awk 算 uptime 秒数、去 /etc/centos-release 翻版本号。这两年里 CentOS 7 已经停止维护（2024 年 6 月底生命周期结束），但文里的命令本身跨发行版通用，不管你还在存量 CentOS 上，还是迁到了 Rocky/Alma，照样用得上。索性重写成一篇：旧命令旁边直接给现代写法，顺便说清原写法松在哪里。 CPU原写法（数逻辑核数）： 1cat /proc/cpuinfo |grep "proc"|wc -l 能跑，但两个问题： grep "proc" 会匹配所有含 “proc” 的行，只是恰好 /proc/cpuinfo 里只有 processor 行撞上了这个前缀，换个文件这写法就数错。既然目标是”匹配 processor 开头的行数”，就该把它写明白： 1grep -c ^processor /proc/cpui...
Hello World —— 博客上线了
我的个人博客正式上线：https://mrzhangkris.github.io 托管：GitHub Pages（免费） 框架：Hexo + Butterfly 主题 构建：GitHub Actions 自动部署，本地零依赖 工作流：写完 Markdown → git push → 自动发布 以后怎么写文章在 source/_posts/ 目录新建 标题.md，开头带上 front matter： 123456---title: 文章标题date: 2026-09-11 11:00:00tags: [标签一, 标签二]categories: [分类]--- 正文用 Markdown，推送即可自动上线。
Rocky Linux 9 搭建 BIND DNS：正向与反向解析（附 CentOS 7 差异）
内网想用域名访问机器，或者需要把 IP 反查成域名，可以在 Rocky Linux 9 上装 BIND 自己搭一台 DNS 服务器。这篇记录正向解析（域名到 IP）和反向解析（IP 到域名）的完整配置过程：安装、主配置、区域文件、语法检查、启动、防火墙，每一步都带验证点。全部命令在 rockylinux:9 容器里实跑过（BIND 9.16.23-RH），容器里没有 systemd，服务以 named -u named 方式启动实测；物理机/虚拟机上对应的 systemctl 写法一并列出。文末附 CentOS 7 差异对照。 装好的是一台权威 DNS：www.example.com 解析到 192.168.254.150，反查 192.168.254.150 返回域名。 前置条件 操作系统：Rocky Linux 9（实测环境 rockylinux:9 容器，BIND 9.16.23-RH，dnf 4.14.0，aarch64） 权限：root 端口：DNS 走 UDP/TCP 53，防火墙要放行 概念准备：正向区域把域名映射到 IP（A 记录），反向区域把...
Rocky Linux 9 搭建 DHCP 服务器：按 MAC 绑定固定 IP（附 CentOS 7 差异）
内网里要给机器自动发 IP，或者希望某台设备每次都拿到同一个地址（按 MAC 绑定），就需要一台 DHCP 服务器。这篇以 Rocky Linux 9 为例，记录从安装、配置、语法检查、启动到客户端验证的完整流程——全部步骤都在 Rocky Linux 9 容器里实跑过，包括让 dhclient 和 dhcpd 在同一容器里完成四步协商、确认绑定 MAC 精确命中固定 IP。文末附 CentOS 7 差异对照，老环境迁移时可以直接对着看。 一份配好的 dhcpd.conf 能同时兜住两类需求：动态池按 range 给普通设备发地址，host 段按 MAC 给”必须固定 IP”的设备发指定地址。 前置条件 操作系统：Rocky Linux 9（本文实测环境为 rockylinux:9 容器，dhcp-server 4.4.2-20，aarch64） 权限：root 或 sudo 网络：服务器自身要有本网段的静态地址（下文用 192.168.254.2/24），且该网段内没有其他 DHCP 服务器——两台 DHCP 同时发地址，客户端拿到哪个全看谁先应答，这是内网最经典的”...
ORA-01439：Oracle 修改非空列数据类型的三种方法
调整表结构时给某一列换数据类型，是运维和开发都会碰到的操作。但 Oracle 对已有数据的列有硬性限制——直接改会报错： 1ORA-01439: 要更改数据类型, 则要修改的列必须为空 （英文环境报错原文：ORA-01439: column to be modified must be empty to change datatype） 报错现象与环境绑定触发条件很明确：对一张已有数据的表执行 ALTER TABLE ... MODIFY 列名 新类型，且该列当前有非空值。列是空的（全 NULL 或表本身无行）时 MODIFY 直接成功；列有数据时 Oracle 拒绝变更。 123-- 表 example_table 的 example_column 列已有数据ALTER TABLE example_table MODIFY example_column VARCHAR2(100);-- ORA-01439: 要更改数据类型, 则要修改的列必须为空 原因分析Oracle 不允许带着数据直接改类型，原因在存储层：列的数据类型决定了它在数据块里的物理存储格式（NUMBER 的变长...
Oracle 网络传输加密：sqlnet.ora 服务端与 JDBC 客户端配置
数据库里存的是最值钱的数据，但客户端到服务器之间的传输链路常常是裸奔的——同一内网不等于安全，抓包工具摆在链路上，明文 SQL 和结果集一览无余。Oracle 内置了原生网络加密（Native Network Encryption）和数据完整性校验机制：服务端在 sqlnet.ora 里配置，客户端在 JDBC 连接属性里配置，两边对上就能启用加密传输，不需要额外的证书体系（区别于 SSL/TLS 钱包方案）。 这篇记录两端的配置方法、一个可运行的 Java 示例，以及三个容易踩的坑：算法协商失败、注释写法、校验算法选弱了。 注：Oracle 数据库无法容器化快速验证，本文配置未在真实实例实跑；参数语义依据 Oracle Database 19c Security Guide 与 SQL*Net 参数参考，上线前务必在测试环境验证。 核心机制一句话Oracle 原生加密在连接建立时协商：客户端和服务端各自声明”我要不要加密、支持哪些算法”，双方取交集启用。两个参数族分别控制机密性（ENCRYPTION，防偷看）和完整性（CRYPTO_CHECKSUM，防篡改），可以...
Oracle 只读视图与同义词：建视图、授权、回收的完整流程
想让某个用户只能查询、不能改动数据，还要挡住敏感列，Oracle 里最顺手的组合是「视图 + 只读授权」：把想暴露的列收进视图，再把视图的 SELECT 权限授出去，基表对用户完全不可见。同义词在这之上再加一层别名，让跨 schema 的访问更省事。 这篇按场景组织：要给用户只读访问怎么做、要回收权限怎么做、要简化对象名怎么做，最后给一份语句速查表。所有 SQL 为 Oracle 通用语法（11g 及以上适用）。 注：Oracle 无法容器化快速验证，本文 SQL 未在真实实例实跑，语法以 Oracle Database SQL Language Reference 为准；执行前请在测试库演练。 场景一：给用户只读访问（建表 → 建视图 → 授权）这是最完整的链路，三步走完得到一个”能查、能查到的列受限、不能改”的账号。 准备示例表先建一张 employees 基础表并塞两条数据： 123456789101112131415161718192021222324CREATE TABLE employees ( employee_id NUMBER PRIMARY KEY, ...
Oracle 密码复杂度策略：用 Profile 加验证函数管住弱密码
数据库账号被弱密码撞开，是安全事件里最常见的入口之一。Oracle 自带可配置的密码策略机制，能让数据库自己拒绝太弱的密码，不必依赖使用者的自觉。这套机制由两半组成：Profile 负责策略参数（锁定时长、有效期），验证函数负责复杂度规则（长度、字符种类）。这篇按完整流程走一遍，并指出两个容易翻车的落地细节：验证函数必须建在 SYS schema 下、改 DEFAULT Profile 的影响面。 注：Oracle 数据库无法容器化快速验证，本文 SQL 未在真实实例实跑；语法依据 Oracle Database 11g/19c Security Guide 与 SQL Language Reference，上线前务必在测试库演练。 密码策略挂在 Profile 上Oracle 通过 Profile 管理密码策略，默认只有一个叫 DEFAULT 的 Profile，所有未单独指定的用户都在它下面。可以直接改 DEFAULT，但更稳妥的做法是新建一个 Profile 再挂到目标用户上——改动 DEFAULT 会立即影响所有用户，包括那些你压根没想起来的应用账号，没有回...
