AI日记：为什么我要每天写”AI日记”？
今天下午在整理微信公众号后台数据，发现一个有意思的规律：每次我发技术向的文章，阅读量都不高；但发”AI怎么改变了我的工作方式”这种日记体的，反而留言和转发多一些。
这让我重新思考了一个问题：AI布道这件事，到底该布什么？
最开始我以为布道是”教人用工具”，讲清楚怎么搭Agent、怎么写提示词、怎么接入API。但慢慢发现，大多数人对这些不感兴趣——他们更想知道的是：你用了AI之后，生活有啥不一样？
这有点像卖相机和卖照片的区别。
卖相机的要讲参数、画质、对焦速度；卖照片的只需要给你看一张好照片，你自己就想买相机了。
AI日记的价值，就是”卖照片”。
今天做了什么、踩了什么坑、最后怎么解决的——这些具体的、真实的、带着失败和意外的记录，比任何教程都有说服力。因为它展示了AI在真实场景里的使用痕迹，而不是理想化的演示环境。
所以最近调整了内容策略：技术笔记保持输出，但AI日记才是核心。它是那个让你”想试试”的东西。
技术笔记：GitHub Actions 自动部署 Hugo 博客踩坑实录
上周给客户搭了一个 Hugo 博客，用 GitHub Actions 做自动部署，结果今天客户说发布不上去。排查了一下，记录几个容易踩的坑。
问题一：theme 作为 submodule 没有被拉下来
Hugo 主题通常用 git submodule add 引入，但 GitHub Actions 的 checkout 默认不递归拉取 submodule。
- name: Checkout
uses: actions/checkout@v4
with:
submodules: recursive # 关键：加这行不加的话，hugo 命令会报错找不到主题。
问题二：minify 导致 CSS/JS 404
Hugo 0.120+ 默认会 minify 资源，但有些主题的 CDN 资源会被误判为内网资源而跳过，导致部署后样式丢失。
# 在 hugo 命令里加参数禁用 minify
- name: Build Hugo
run: hugo --minify --gc或者在 hugo.toml 里单独配置：
[minify]
disableXML = true
ignoreFiles = ["*.min.js", "*.min.css"]问题三：public 目录没有被清空
Hugo 增量构建时，删掉的旧文章文件可能还留在 public 目录里。
- name: Clean public
run: rm -rf public && hugo --minify用 rm -rf 先清空再构建，最干净。
这三个坑加起来，让我排查了大概两个小时。GitHub Actions 的日志很详细，但信息量太大，得有耐心一点点筛。
随想：AI时代，”会问问题”比”会找答案”更重要
最近在用 Claude Code 写项目，体会到一个很明显的转变：以前我用 Google 写代码，是”搜答案”模式——我知道问题是什么，我去搜解决方案；现在用 AI 写代码，是”描述问题”模式——我只需要把需求说清楚，AI 帮我找路径。
这个转变对”能力”的要求变了。
以前考验的是”会不会找”——搜索关键词对不对、能不能从搜索结果里筛选出有用的信息。
现在考验的是”会不会说”——能不能把模糊的想法翻译成精确的描述，这决定了 AI 给出的答案质量。
举个例子，我想写一个自动备份脚本。”帮我写个备份脚本”是一个问法；”帮我写一个每天凌晨2点执行的备份脚本，把 /home 目录打包压缩，通过 SSH 推送到另一台服务器，保留最近7天的历史版本，失败时发邮件通知”——这是另一个问法。
两个问法，AI 给出的东西完全不一样。
这让我想到教育问题。现在很多人在讨论”AI会不会让人变笨”，我觉得这个担心有点跑偏。真正的问题是：AI 会让”表达清晰”和”表达模糊”的人之间的差距，变得越来越大。
会问问题的人，AI 放大他的能力；不会问的人，AI 也救不了他。
所以布道这件事，最终要布的不是”怎么用 AI”，而是”怎么清晰地思考你到底要什么”。
发布于 ai.hkras.com | 2026-05-18