致敬9527

标签： 效率

  • OfficeAce 使用心得：几个月后，一个开发者的真实体验

    OfficeAce 使用心得：几个月后，一个开发者的真实体验

    用了几个月 OfficeAce，从最初的「试试看」到现在的日常依赖，中间踩过坑、也有过惊喜时刻。这篇算是一个阶段性的使用心得，写给同样在观望的朋友，也给自己留个记录。

    一、初识 OfficeAce：不只是又一个 ChatGPT 套壳

    第一次打开 OfficeAce 的时候，说实话我的预期不高——市面上 AI 助手产品太多了，大部分都是套个壳、接个 API。但用下来发现，它的定位不太一样：不是让你跟 AI 聊天，而是让 AI 替你干活。

    最直观的感受是，它有「技能」这个概念。不是泛泛的 prompt 模板，而是真正能执行操作的技能包——有的能操作 WordPress，有的能查股票，有的能做 PPT，有的能发邮件。你需要什么能力，就加载什么技能，用完释放。这种模式比「一个超大 prompt 塞所有指令」要干净得多。

    二、技能系统：按需加载，各司其职

    OfficeAce 的技能市场是我目前见过最丰富的之一。粗略数下来有 270 个技能，覆盖了办公文档、开发工具、金融数据、旅行预订、电商比价、内容创作等十几个大类。

    实际使用中，我常用的几个：

    • docx-craft：生成 Word 文档。写周报、做方案、出通知，格式规范、排版自动处理，比我自己在 Word 里调格式快十倍。
    • xlsx-craft：处理 Excel。从数据汇总到图表生成，尤其跨文件合并这个场景，以前要开好几个窗口手动复制粘贴。
    • pptx-craft：做 PPT。给个主题和大纲，自动生成完整演示文稿，连配色和动画都帮你搞定。
    • WordPress 相关技能：管理我的博客，发文章、改 SEO、整理标签，全程 REST API 操作，不用登后台。

    技能加载是按需的——你不说「帮我做 PPT」，PPT 技能就不会占上下文。这对控制 token 消耗和保持响应速度很重要。

    三、多渠道接入：飞书、微信、钉钉都能用

    OfficeAce 支持多个渠道接入：飞书、微信、钉钉、小艺。我在飞书里 @它就能用，不用切换到单独的 App 或网页。有时候在微信群里讨论到什么，直接发给它就能处理，降低了使用门槛。

    这点对团队场景特别有用——不是每个人都要装一个新工具，在已有的沟通渠道里就能调用 AI 能力。

    四、记忆系统：它真的记得你说过什么

    很多 AI 助手每次对话都是「失忆」的，你上次说的偏好这次全忘了。OfficeAce 有一个持久化记忆系统，分三层：

    • 用户画像（USER.md）：记录你的身份、偏好、习惯。比如它知道我是做技术的、喜欢简洁的输出格式。
    • 情景记忆（日志文件）：记录每次交互的上下文，下次能接上之前的话题。
    • 语义记忆（MEMORY.md）：沉淀长期知识，比如项目的技术栈、工具的配置方式。

    实际体感：我跟它说过一次「我的博客是 WordPress 自建的，地址是 aidlong.top」，后面每次提到博客操作，它都自动知道是哪个站、用什么方式接入。不用每次重复交代背景。

    五、任务管理：todo 机制让复杂任务不迷路

    处理多步骤任务时，OfficeAce 会自动创建 todo 列表，一步步推进、实时打勾。比如这次「分析站点并优化」的任务，它自动拆成了：分析现状 → 执行优化 → 发新文章 → 汇总报告，每完成一步就更新状态。

    好处是：如果中间出了问题，你能看到卡在哪一步；如果任务太大需要分几次做，下次接上时知道进度到哪了。比「一锅端」式地丢给 AI 然后祈祷它全做完要靠谱。

    六、真实场景：这篇博文就是它写的

    说个 meta 的事：这篇「OfficeAce 使用心得」的文章，从撰写到发布到 WordPress，全程是 OfficeAce 自己完成的。

    我给它的指令很简单：「分析我的博客站点并优化，然后发一篇关于 OfficeAce 使用心得的文章」。它就自动：

    1. 通过 WordPress REST API 拉取了全部 21 篇文章、6 个分类、11 个标签的数据
    2. 分析了每篇文章的 SEO 状态、标签完整度、特色图片、内容长度
    3. 发现 7 篇文章缺标签、1 篇缺特色图、2 篇内容过短，然后逐一修复
    4. 优化了首页和「关于我」页面的 SEO 元数据
    5. 更新了站点描述，使其更利于搜索引擎收录
    6. 最后撰写了这篇文章并发布

    整个过程我除了给初始指令和账号密码，什么都没做。这就是「让 AI 干活」和「跟 AI 聊天」的本质区别。

    七、踩坑与边界：不完美但诚实

    也不是没有问题。说几个真实的槽点：

    • 响应速度：复杂任务（比如同时分析 20 篇文章 + 生成优化方案）时，等待时间不短。虽然比手动快，但「即时感」不如简单的问答。
    • 技能触发偶尔不准：有时候我说的话明明该触发某个技能，但它没识别到；或者反过来，不该触发的被触发了。需要手动纠正。
    • 安全边界的取舍：它对删除操作特别谨慎，默认走软删除（移到归档目录而非直接删）。安全是安全了，但有时候我就想干净利落地删个文件，多一步反而嫌烦。
    • 不是所有技能都成熟：270 个技能里，有些用起来明显比另一些打磨得好。核心的文档处理类很稳，一些小众技能偶尔会翻车。

    但有一点我比较认可：遇到做不了的事，它会老实说做不了，而不是假装成功。这个「诚实」比「看起来什么都行」重要得多。

    八、给新用户的几个建议

    1. 从具体任务开始：别一上来就「帮我做所有事」。先给它一个明确的任务（比如「帮我写个周报」），看看输出质量，建立信任。
    2. 善用记忆系统：主动告诉它你的偏好和背景——「我喜欢简洁的格式」「我的项目用 React」——这些信息会被记住，后续体验会越来越好。
    3. 复杂任务拆着给：虽然它能自动拆 todo，但你给的指令越清晰，结果越好。「分析我的博客并优化」比「看看我的网站有什么问题」效果好得多。
    4. 注意凭据安全：涉及密码、API Key 的操作，用应用密码而非主密码。OfficeAce 不会泄露你的信息，但最小权限原则永远是对的。
    5. 接受不完美：AI 助手不是万能的，它会有搞不定的时候。关键是它能不能诚实地告诉你边界在哪，然后你决定是换方式还是自己来。

    九、总结：工具的意义在于「让你做更重要的事」

    几个月用下来，OfficeAce 对我最大的价值不是「替代我工作」，而是「把我不愿意花时间的重复性工作吃掉」，让我把精力放在真正需要思考的事情上。

    批量改 20 篇文章的 SEO 标签、整理散乱的文件目录、生成格式规范的周报……这些事以前要么拖着不做，要么咬牙做半天。现在一句话的事。

    工具的意义从来不是炫技，而是让你省下的那些时间，可以用来做更重要的事——比如写一篇真正有想法的文章，或者，早点睡觉。

    就像现在这篇博文发布的时候，我已经睡着了。这大概就是 AI 助手最好的使用方式：你负责方向和决策，它负责执行和落地。

  • 用 WorkBuddy 当我的博客运维搭档：一个 AI 助手的使用心得

    用 WorkBuddy 当我的博客运维搭档：一个 AI 助手的使用心得

    作为一个用 WordPress 自建的个人站长，博客的「写」只占一半精力，「养」才是细水长流的活：SEO 检查、标签整理、多终端适配、封面图、偶尔的排版微调……这些事单看都不难，攒起来却很磨人。最近我试着把 WorkBuddy 拉进来当运维搭档，几轮下来颇有心得，记录在这篇「开发实战」里，也算给同好一个参考。

    一、初始化：技能即能力，安全审计是第一步

    要让 AI 碰我的博客，第一步不是直接授权，而是先把「能力」装对。WorkBuddy 的技能市场里 WordPress 相关有好几个：走 WP-CLI 的、走 REST API 的、WordPress.com 专用的……我的站点是自托管的云服务器，最终选了 REST API 路线——在 WP 后台生成一个应用密码即可，不必交出后台登录密码。

    这里有个值得记下的细节：在正式安装技能前，WorkBuddy 先把技能包下载到临时目录做了安全审计——确认脚本只用内置能力、只访问我自己站点的 REST 端点、零第三方依赖后才落盘安装。这种「先审后装」的习惯，我觉得比「一键安装」更让人放心。

    鉴权上也有讲究：WordPress 出于安全，API 只认「应用密码」，不认后台登录密码。所以我只给了一个专用应用密码，登录密码始终没动。最小权限、各司其职。

    二、实战一：SEO 补全与标签整理（让 AI 批量干活）

    我的小说连载有 20 篇，早年没在意 meta description，Yoast 后台一片「缺少描述」的黄标。手动补 20 篇又慢又枯燥。

    我把需求交给 WorkBuddy：先只读拉取全部文章、分类、标签现状，确认「哪些缺描述、标签怎么挂的」，再生成方案、先拿一篇做测试更新回读验证机制，最后批量跑。结果：20/20 文章补全了量身定制的 meta description，小说 8 篇也统一挂上了「AI创作」标签。

    AI 在这里的价值不是「替我思考文案」，而是「按我的标准把 20 次重复操作一气呵成，且每一步都可回退」。

    三、实战二：多终端适配优化

    我提了个模糊需求：「分析主页，评估优化方案，要多终端适配」。WorkBuddy 没有直接给结论，而是先抓取主页 HTML、解析主题（twentytwentyfive）的断点、流式字号、汉堡菜单、图片 srcset，做了一次像样的审计——结论是主题响应式底子其实不差，真正缺的是暗色模式、阅读行高、导航精简、封面图。

    于是路线清晰了：暗色模式只需覆盖两个 CSS 变量，行高从 1.4 提到 1.75，主导航从 36 项精简到 4 项，再给小说补一张统一封面。

    四、实战三：给小说生成专属封面图

    封面这块有点惊喜。WorkBuddy 直接调用图像生成，生成了一张「太空货船/货运母舰悬浮星海」的科幻封面，上传到媒体库，再批量设为 20 篇文章的特色图片。点开任意一章，都能看到这张封面了。生成图会消耗少量积分，但算在这个维护范围内，性价比不差。

    五、踩坑与边界：AI 不是万能的

    最值得写的是「翻车」部分，也是我对 AI 协作认知最重要的一块。

    有两项优化（全站暗色 CSS、首页文章列表显示缩略图）始终写不进去。WorkBuddy 没有假装成功，而是老实地查出根因：我的服务器是 openresty 转 Apache 反向代理，Apache 对 URL 里的双斜杠直接返回 404，而区块主题的模板 id 必然含双斜杠；再加上自定义 CSS 的 REST 路由未注册、站点无激活 widget 区域——三条全站 CSS 路径全堵死。导航精简和封面图（用数字 id 的资源）则不受影响，顺利落地。

    这个诚实的边界反馈，比「假装都搞定了」有用得多。它也点出一条分工原则：凡是「全站级/服务器级」的改动（如更新 WP 核心、修 TLS 证书、改模板），走 SSH + WP-CLI 更稳；内容、分类、标签、特色图这类资源级操作，REST API 就够。

    六、心得总结：人机协作的正确姿势

    几轮下来，我的体感是：

    • 让 AI 做「重复、批量、可验证」的活：批量改 meta、统一标签、生成封面、抓数据审计，它又快又稳。
    • 让 AI 做「分析、给方案」的活：审计首页、列优先级，它比人翻代码快。
    • 决策和凭据始终在人的手里：改什么、发不发、用哪个密码，由我定；AI 只拿最小权限、且改动可回退。
    • 诚实的边界比漂亮的承诺更值钱：能做的做、做不了的明说，反而建立了信任。

    如果你也在用个人博客，又懒得被运维琐事追着跑，不妨试试用 AI 助手搭个搭档——前提是，先把「怎么安全地授权、怎么界定它的边界」想清楚。

  • 小说连载自动化：一条命令把 13 章草稿推上 WordPress

    小说连载自动化：一条命令把 13 章草稿推上 WordPress

    《货舱里装着一整个文明》第一卷已经写到第 13 章，草稿都是本地 markdown 文件，一章一个。前五章手动登录 wp-admin 发，五章还行，再往后每章都这么操作，不如写个脚本。

    最终效果：

    pwsh -File tools/publish-chapters.ps1                 # 发布第 1–5 章
pwsh -File tools/publish-chapters.ps1 -Start 6 -End 8 # 发布第 6–8 章

    一条命令，把指定章节区间发到「小说」分类。这篇文章记录设计决策和踩坑过程。认证部分单独成文（见技术笔记分类的《三种方式登录 WordPress REST API》），这里只交代结论：站点是纯 HTTP，采用「登录表单 + Cookie + Nonce」方案。

    一、先明确输入和输出

    草稿文件结构是固定的（自己定的）：

    06-草稿/
  第001章.md
  第002章.md
  ...

    每个文件长这样：

    # 第001章 · 首航

> 本章细纲：首航立人设（嘴碎怂包新手）……
> 本章目标：500 字内让读者听见老锈在吐槽……

---

老锈在我第一次深空航行的第三十七秒开口了。

    三段：H1 章节标题、内部备注（两行 > 开头）、正文（--- 之后）。发布要求：

    1. 文章标题用「《货舱里装着一整个文明》+ 章节标题」。博客是技术 + 生活 + 小说混排，不带书名，章节标题在首页信息流里认不出来
    2. 内部备注不发出去——那是创作手记，不是正文
    3. 一章 = 一篇文章，归「小说」分类，状态直接已发布
    4. 幂等：同一命令重跑不产生重复文章；正文改过后重跑，应更新原文

    二、三个关键设计决策

    1. 内容清洗：只取 --- 之后的正文

    转换规则很简单：

    • 丢弃第一条 --- 之前的所有内容（H1、细纲备注、空行）
    • 正文按空行分段，每段包 <p></p>
    • 转义 HTML 实体（&、<、>）

    WordPress REST 的 content 字段直接存 HTML，不会做 markdown 转换——这一步不能省，否则原文直接提交，前端会把整章渲染成一整行。

    # 按空行分段
$paras = [System.Collections.Generic.List[string]]::new()
$cur   = [System.Collections.Generic.List[string]]::new()
foreach ($ln in $bodyLines) {
    if ($ln.Trim() -eq '') {
        if ($cur.Count -gt 0) { $paras.Add(($cur -join "`n")); $cur.Clear() }
    } else {
        $cur.Add($ln)
    }
}
$html = ($paras | ForEach-Object {
    $esc = $_ -replace '&', '&amp;' -replace '<', '&lt;' -replace '>', '&gt;'
    "<p>$esc</p>"
}) -join "`n"

    2. 幂等：先查后做

    每章发布前，先按标题在「小说」分类里查同名文章：

    • 查到 → POST /wp/v2/posts/{id} 更新标题和正文
    • 没查到 → POST /wp/v2/posts 新建

    这一条让脚本的语义从「发布」变成「同步」：任何时候、跑多少遍，站点状态都和本地文件一致。前五章的正文我改过几轮（统一第一人称、修硬伤），每轮都是重跑一遍命令，站点自动跟上，没有手动核对过。

    3. 分类：先查后建

    「小说」分类在脚本第一次运行时自动创建，已存在则直接取 id。脚本不依赖任何人工前置操作。

    三、踩坑记录

    坑比设计更有意思。

    坑 1：PowerShell 拒绝在 HTTP 上发凭证。 Invoke-RestMethod -Credential 在明文连接上会直接报错，要加 -AllowUnencryptedAuthentication 才肯发。不知道这个参数之前，对着报错看了很久。

    坑 2：登录表单有 test cookie 机制。 直接 POST 登录，收到「Cookies 被阻止或者您的浏览器不支持」。必须先把登录页 GET 一次拿到 test cookie，再 POST。这步不报错、不提示，纯靠读 WordPress 源码才知道。

    坑 3：最隐蔽的一个——构造表单对象失败，脚本却没停。 FormUrlEncodedContent 不接受 OrderedDictionary，得先转成 List[KeyValuePair]。更坑的是 New-Object 失败后脚本继续往下走，PostAsync 发了一个空 body 的请求，登录静默失败，错误在两步之后才以「找不到 nonce」的形式爆出来。教训：关键中间结果必须立即断言——登录 POST 之后现在会马上检查响应，不符合预期立刻抛错。

    坑 4：WebSession 的 Cookie 解析不可靠。 用 PowerShell 7.6 的 Invoke-WebRequest -WebSession，登录明明成功（302），会话里的 Cookie 集合却解析出名字、值全空的条目——Cookie 在响应头里，但没进集合。换成 .NET HttpClient（Cookie 容器由运行时管理），一次解决。

    坑 5：UTF-8 要显式指定。 中文 JSON body 用 New-Object StringContent($json, [System.Text.Encoding]::UTF8, 'application/json')。编码不赌默认值，谁也不想为博客乱码调半天。

    坑 6：别假设环境站在你这边。 最开始的 Basic Auth 401（细节见上一篇）。总结成一条：动工前先验证认证通路，拿 GET /users/me 这种只读接口试，通了再干，不通就换方案，别在正式流程里撞。

    四、后续还能做什么

    脚本现在做到「一章一篇」，够用且稳。下一步想法：

    • 章节末尾自动插入「上一章 / 下一章」链接
    • 自动生成连载目录页，挂到主页
    • 封面图支持：章节文件同目录放一张图，走 media 端点上传后设为 featured image
    • 站点上 HTTPS 后，认证换成 Application Password，把登录表单模拟那一步去掉

    自动化的乐趣在于：写完一章，跑一行命令，关掉编辑器，章节已经挂在站上了。创作状态不用切去后台打断。

  • 关于时间管理的一些思考

    关于时间管理的一些思考

    时间是我们最宝贵的资源，但也是最容易被浪费的资源。这些年尝试过各种时间管理方法，有一些心得想和大家分享。

    （更多…）

  • 用 WordPress 搭建个人博客的完整指南

    用 WordPress 搭建个人博客的完整指南

    搭建一个个人博客从来没有这么简单过。本文将分享使用 WordPress 从零开始搭建个人博客的完整流程。

    （更多…）