Jason's Blog - 原创文章
type: channel
link: https://www.okjason.com/category/original/
items: Typecho MCP Workbench 开发手记 05：图床、文件床和 v1 之前的安全边界
items: Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台
items: Typecho MCP Workbench 开发手记 03：把博客操作变成 AI Agent 能安全调用的工具
items: Typecho MCP Workbench 开发手记 02：SSH 零操作，把远程博客接成本地工作台
items: Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客
items: 别再只让 AI 写代码了：给编程助手接上浏览器和 MCP，效率直接上一个台阶
items: AI 行业一周观察：从 Google I/O 到内容溯源，AI 正在从“会聊天”走向“能落地”
items: 直链测试
items: 宝塔面板解决反向代理与SSL冲突的方法
items: Transfer Files Between Any Devices Using Piping Server-转载

Typecho MCP Workbench 开发手记 05：图床、文件床和 v1 之前的安全边界
type: item
date: 2026-06-01T16:09:16+00:00
description: Typecho MCP Workbench 开发手记 05：图床、文件床和 v1 之前的安全边界前四篇基本把项目的骨架讲完了。第一篇讲为什么做：不是再造一个 Typecho 后台，而是把远程博客变成一个本地可控、AI Agent 可操作、远端尽量轻量的发布目标。第二篇讲怎么够到远端：SSH zero-touch，自动探测 Docker 里的 Typecho，部署一个很小的 PHP agent，用 stdin/stdout 做受控调用。第三篇讲 AI 被允许怎样操作：MCP 工具不是裸数据库函数，而是一组有策略、有快照、有审计的本地工作流。第四篇讲人类入口：localhost Web UI 只是原型，长期目标应该是一个类似 Obsidian 或 Typora 的本地桌面工作台。这一篇想把素材和安全模型收一下：图片、附件、外部 URL、图床、文件床、对象存储、桌面打包和 v1 路线，最后都要回到同一个问题：AI 可以帮我把内容准备到什么程度，人类又必须在哪些地方保留边界。为什么第 5 篇要讲素材博客文章不只有文字。一篇真正要发布的文章，里面会有截图、架构图、流程图、下载文件、外部链接、以后可能还有视频或大型附件。它们不一定都适合放在 Typecho 服务器上。Typecho 自己的上传目录很稳定，默认会把文件放到类似这样的路径：usr/uploads/YYYYMM/对于小图、普通截图、兼容性测试，这很好。第一版工作台也已经支持 typecho.media.upload：把文件上传到 Typecho 本地媒体目录，注册附件记录，再返回 Markdown。但如果所有图片和文件都塞进博客服务器，就会遇到几个现实问题：博客服务器磁盘不一定大。大文件会拖慢备份和迁移。热门图片会吃掉站点带宽。有些用户本来就有图床、文件床、对象存储或 CDN 工作流。AI Agent 插入素材时，需要知道这个链接来自哪里、是否可访问、是否应该被允许。所以这里不能只做一个“上传按钮”。更合适的抽象，是 asset provider。local media 和 external URL 是第一组边界当前项目里已经有两种最基础的素材路径。第一种是 typecho-local。它把文件上传到 Typecho 自己的上传目录，并注册成 Typecho 附件。优点是兼容、直观、不需要第三方配置。缺点也很明显：它消耗博客服务器存储和带宽，不适合大文件，也不适合把 Typecho 当成通用文件仓库。第二种是 external-url。它不上传文件，只注册一个已经存在的外部 URL，然后把它作为图片或文件链接插入 Markdown。这个 URL 可以来自图床、文件床、CDN、OpenList/AList、R2/S3，也可以是用户手工上传到别处后复制过来的链接。这两种能力看起来简单，但它们给后续 provider 系统定了一个重要形状：文章正文里插入的是 Markdown，工作台内部要保留 provider、URL、类型、来源和可检查状态。未来无论资源来自哪里，返回结果都应该长得差不多：{ "provider": "external-url", "media": { "filename": "diagram.png", "url": "https://cdn.example.com/diagram.png", "mime": "image/png", "external": true, "kind": "image" }, "markdown": "![diagram.png](https://cdn.example.com/diagram.png)" }这样 MCP Agent 和人类工作台不需要关心底层是 Typecho 上传、R2、S3、WebDAV，还是 OpenList。它们只需要知道：这是一个可插入文章的资产，它属于哪个 provider，它是否是外部链接，它应该怎样被审计和检查。asset provider 不是图床配置页如果把这个功能做窄一点，它很容易变成一个普通的“图床配置页”：填 endpoint、填 token、点上传、复制 URL。但在 Typecho MCP Workbench 里，asset provider 应该是发布工作流的一部分。因为 AI Agent 会参与写作，它不只是帮你复制图片链接。它可能会做这些事：根据文章内容建议需要哪几张图。把本地截图上传到默认 provider。把已有 CDN 图片注册到文章资产列表。检查 Markdown 里所有图片链接是否可访问。在发布前报告哪些资源是 Typecho 本地媒体，哪些是外部 URL。发现某个外链图片返回 404 后提醒人类替换。这时 provider 就不能只是“能上传就行”。它至少要回答几个问…

Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台
type: item
date: 2026-06-01T14:34:53+00:00
description: Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台上一篇写到 MCP 工具层：AI 不应该直接拿 SSH 或数据库，而应该通过一组有语义、有策略、有快照、有审计的本地工具来操作博客。到这里，项目已经有了一条比较清晰的秩序：先预览，再保存；先检查，再发布；先快照，再回滚；先记录，再排查。这篇想继续往人类端推进一步：当前的 localhost Web UI 能证明方向，但它不是终点。真正的目标，是一个类似 Obsidian 或 Typora 的本地人类工作台。localhost 能跑通链路，但不能回答日常使用问题http://127.0.0.1:4783 对早期开发非常好。前端可以直接改，后端 API 可以直接接，CLI、MCP、Web UI 都能复用同一套 local-ops。出问题时，打开浏览器、看控制台、看请求日志，很快就能知道链路断在哪里。但 localhost 页面只能回答一个工程问题：这条链路能不能跑通。它还没有回答一个更日常的问题：我明天、下周、半年后，愿不愿意每天打开它写东西？写作不是一次性的调试动作。它有草稿、素材、上下文、窗口布局、快捷键、预览习惯、发布前焦虑，以及出了问题之后必须能快速排查的安全感。长期使用时，人更希望打开的是一个稳定的本地工作空间，而不是“某个还开着的浏览器标签页”。所以这一步的判断是：Web UI 是很好的 renderer 原型，但产品形态不能停在浏览器里。这不是普通后台，也不是自动发布按钮如果只是为了管理文章，Typecho 官方后台已经能做很多事情。这个项目并不是要把官方后台换个皮肤重新做一遍。普通后台的中心是“人点按钮管理内容”。Typecho MCP Workbench 的中心是“AI 准备，人类审阅，人类授权，本地记录”。这两种心智模型差别很大。普通后台关心 CRUD 页面：新建、编辑、删除、设置、保存。这个工作台更关心一次操作是否可预览、是否有快照、是否被策略允许、失败后是否可诊断、事后能不能追踪。普通后台默认远端是主场：登录后台，修改远端状态。这个项目默认本地控制面是主场：SSH、缓存、审计、快照、策略、Debug Bundle 都留在本地；远端 Typecho 尽量轻，只接受窄而明确的 agent 调用。所以它更像一台本地写作驾驶舱。AI 可以整理、生成、检查、准备；人类负责判断、取舍、确认和追责。为什么最终应该像 Obsidian / Typora写作软件和管理后台的感觉不一样。Obsidian 或 Typora 给人的感觉是“我的本地工作空间”。它们有稳定的窗口、熟悉的快捷键、文件和草稿的归属感、长期沉淀的布局偏好。你打开它，不是在“登录一个系统”，而是在回到自己的写作现场。Typecho MCP Workbench 也应该往这个方向靠。它需要承载的不只是一个编辑框：本地草稿和远端文章之间的同步状态。AI Agent 准备好的修改建议和发布报告。保存前的 Diff Preview。发布前的 Prepare / Review / Confirm。回滚前的 Snapshot Preview。媒体、图床、文件床和未来 asset provider。request log、audit log、debug bundle。多站点 profile、窗口布局、命令面板、系统菜单和快捷键。这些东西如果都塞进一个后台页面，就会越来越像“按钮堆叠”。但如果按本地工作台设计，它们可以变成稳定的信息架构。工作台空间应该怎样组织我现在更倾向于把界面拆成几个长期稳定的区域。顶部栏放站点、host、同步状态、命令面板入口和全局状态。左侧 Activity Bar 不直接堆功能按钮，而是切换工作模式：Content、Review、Media、Operations、Site、Settings。Sidebar 服务当前模式。写文章时，它是文章列表和筛选器；看媒体时，它是素材来源和资产分组；排查问题时，它是日志和诊断入口。主区域永远优先给写作和审阅。Markdown editor、Preview、Diff、Snapshot Review 都应该在这里发生。右侧 Inspector 放 metadata、slug、tags、categories、publish context、snapshot context、policy context。它不应该打断正文，而应该像一个随时可看的上下文抽屉。底部 Operations Panel 放 request log、diagnostics、audit、cache、debug bundle。这些东西很重要，但不应该抢走写作主场。底部状态栏则负责低噪音地显示 host、cache freshness、sele…

Typecho MCP Workbench 开发手记 03：把博客操作变成 AI Agent 能安全调用的工具
type: item
date: 2026-05-31T14:07:48+00:00
description: Typecho MCP Workbench 开发手记 03：把博客操作变成 AI Agent 能安全调用的工具上一篇写到 SSH zero-touch：本地工作台通过 SSH 自动找到 Docker 里的 Typecho，部署一个极轻的 PHP agent，然后用 stdin/stdout 调用它。这篇自然接上：远端 agent 只是执行器，真正的控制面在本地 MCP 和 local-ops。如果说第二篇解决的是“怎么安全地够到远端”，那第三篇解决的是“够到之后，AI 到底被允许怎样操作博客”。为什么 MCP 是主入口最直接的做法，是把 SSH、数据库路径、Typecho API 或某个管理接口直接交给 AI。这样当然也能完成任务，甚至短期看起来更快。但这条路的问题也很明显：它把能力暴露得太原始了。AI 如果直接拿 SSH，它看到的是一台机器；如果直接拿数据库，它看到的是一堆表；如果直接拿远端 API，它看到的是一组远程写入口。这些接口都太接近底层状态，缺少“写作流程”本身应该有的约束。我想要的是另一种边界：AI Agent 只调用本地 MCP 工具 本地 MCP 工具表达编辑意图 local-ops 负责策略、快照、审计和缓存 远端 PHP agent 只执行很窄的原子操作这样 AI 拿到的不是“服务器权限”，而是一组有名字、有语义、有确认策略、有审计记录的工具。它可以写文章，但不能绕开发布确认；它可以预览修改，但不能跳过快照；它可以请求回滚，但必须明确确认。这就是 MCP 在这个项目里的定位：不是“多一种 API 封装”，而是给 AI Agent 设计的本地安全控制面。工具名要贴近编辑流程我不希望 MCP 工具长得像数据库函数，比如：contents.insert contents.update_status metas.attach relationships.delete这些名字对机器很友好，但对真实工作流不友好。写博客不是在操作 contents 表，而是在经历一套编辑动作：先看站点和文章列表。打开一篇文章。创建草稿。预览这次修改会改变什么。保存前生成快照。发布前做检查。明确确认后发布。必要时从快照回滚。所以现在的 MCP 工具更接近这个节奏：typecho.posts.list typecho.posts.get typecho.posts.create_draft typecho.posts.preview_update typecho.posts.update typecho.posts.prepare_publish typecho.posts.publish typecho.posts.rollback媒体也一样，不是“写附件表”，而是：typecho.media.list typecho.media.upload typecho.media.register_external_url而围绕安全、诊断和可观测性的工具，则是另一组辅助控制面：typecho.audit.list typecho.cache.status typecho.cache.clear typecho.snapshots.list typecho.snapshots.get这些工具名的目标，是让 AI 在调用之前就能理解动作的风险。preview_update 听起来就是预览；prepare_publish 听起来就是发布前检查；publish 和 rollback 则天然应该被策略系统盯住。工具不是数据库函数，而是可审计工作流一个好的 MCP 工具，不应该只是把远端方法暴露出来。它应该把一次操作拆进工作流。比如更新文章，看起来只是改标题和正文，但实际链路应该是：posts.preview_update -> 对比当前远端文章和目标修改 posts.update -> 强制读取远端最新状态 -> 创建本地 snapshot -> 调用远端 agent 写入 -> 写 audit log -> 失效相关缓存发布文章也是：posts.prepare_publish -> 检查标题、slug、正文、分类、标签、图片链接 -> 给出 blockers / warnings posts.publish(confirm=true) -> 检查 Operation Policy -> 创建 before_publish snapshot -> 调用远端 agent 发布 -> 写 audit log这就是“工具层”和“远端执行器”的差别。远端 PHP agent 可以有 posts.update 这种原子能力；但本地 MCP 暴露给 AI 的，不应该只是一个裸写入口。它必须把快照、策略、审计、缓存失效这些事情纳入默认路径。发布和回滚必须有确认策略发布…

Typecho MCP Workbench 开发手记 02：SSH 零操作，把远程博客接成本地工作台
type: item
date: 2026-05-31T13:19:51+00:00
description: Typecho MCP Workbench 开发手记 02：SSH 零操作，把远程博客接成本地工作台上一篇写的是这个项目为什么存在：我不想再做一个“更漂亮的 Typecho 后台”，而是想把远程博客变成一个本地可控、AI Agent 可操作、远端尽量轻量的发布目标。这篇继续往下走，讲最关键的一段链路：SSH zero-touch deployment。所谓 zero-touch，不是说系统里没有部署动作，而是说远端不需要人手工登录后台、安装插件、改配置、开公网接口。用户给本地工作台一个 SSH 目标，本地侧自己完成探测、部署、健康检查和后续调用。远端 Typecho 仍然是原来的 Typecho，只是多了一个很小、可审计、可移除的 PHP agent。为什么不用 Typecho 插件起步一开始很容易想到“写一个 Typecho 插件，暴露 JSON API”。这条路并不奇怪，甚至很自然：Typecho 是 PHP 应用，插件机制也在那里。但它有几个我不太喜欢的前提：用户要先登录后台安装插件。远端要新增一个公网可访问的 API 面。鉴权、限流、日志、撤销策略都要在博客服务器上承担。如果 AI Agent 误操作，远端插件会直接站在第一现场。对于一个面向写作和发布的 MCP Workbench，我更想要的边界是：MCP 留在本地，远端只做被调用的最小执行器。AI Agent 不直接碰服务器，不直接连数据库，也不拿到一个公网管理 API。它只调用本地 MCP 工具；本地工具再走统一的策略、快照、审计和 SSH 调用链。所以当前方案变成了：AI Agent / 人类工作台 -> 本地 MCP / local-service -> SSH -> 远端 PHP agent -> Typecho 文件和数据库这条链路看起来绕了一点，但每一层都有清楚的职责：本地负责控制和安全，SSH 负责传输，PHP agent 负责很窄的 Typecho 操作。第一步：先找到 Typecho 在哪里zero-touch 的第一件事不是上传文件，而是探测。很多 Typecho 博客不是标准的一台机器一个目录。有的人放在 /www/wwwroot，有的人放在 public_html，也有人用 Docker、Dockge 或别的面板把 Typecho 跑在容器里。这个项目当前优先支持的真实场景就是 Docker 里的 Typecho：本地通过 SSH 进宿主机，再找到能够执行 PHP 的容器。探测逻辑不会全盘扫服务器，而是看一组高价值线索：config.inc.php index.php var/Typecho/ var/Widget/ usr/themes/ usr/plugins/这些标记组合起来，比单独看一个 index.php 靠谱得多。探测结果会带上候选根目录、置信度、运行模式和可用执行方式。如果只有一个高置信候选，本地可以自动选择；如果有多个候选，未来工作台应该让用户确认。这个设计的重点是克制：探测只回答“这里是不是一个 Typecho，以及应该怎样执行它”，不顺手做写入，不修改站点，也不猜测业务配置。第二步：部署一个很轻的 PHP agent找到 Typecho 之后，本地会准备远端 runtime。理想位置是 Typecho 根目录下的：.typecho-mcp/如果站点目录不可写，后续也可以退到用户 home 目录下的项目私有路径。无论放在哪里，原则都一样：只写项目自己的目录，只删除项目自己的目录，不碰主题、插件、上传文件和 Typecho 核心文件。PHP agent 本身也保持小。它不是一个常驻服务，不监听端口，不对公网开放。它只在本地通过 SSH 触发时运行一次，从 stdin 读 JSON，请求完成后把 JSON 结果写到 stdout，日志走 stderr。这条约束很重要：stdout 只能是协议 JSON stderr 才能放日志因为本地侧要把远端执行看成一个可组合的函数调用。如果 stdout 里混入 warning、debug 或 HTML，协议就会变脏。把协议输出和日志输出分开，后面做 MCP 返回、审计、错误分级都会轻松很多。第三步：通过 SSH/stdin/stdout 调用Docker 场景下，最终调用大致长这样：ssh sg1 "docker exec -i typecho-php-1 php /app/.typecho-mcp/current/agent.php"本地把请求写进 stdin：{ "jsonrpc": "2.0", "id": "op_xxx", "method": "posts.get", "params": { "cid": 87 } }远端把结果写回 stdout：{ "jsonrpc": "2.…

Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客
type: item
date: 2026-05-31T11:24:35+00:00
description: Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客这篇是《Typecho MCP Workbench 开发手记》的第一篇。它不是一篇正式的产品发布稿，更像是一份边做边记的开发日志：我们从一个很朴素的愿望开始，把一个远程 Typecho 博客改造成可以被本地工作台和 AI Agent 一起操作的写作系统。我准备把这个过程拆成 5 期：从需求到架构：为什么不是再做一个博客后台，而是做本地控制台加 MCP。SSH 零操作部署：本地连接服务器、自动探测 Typecho、自动部署轻量 agent。MCP 工具层：让 AI Agent 能创建草稿、更新文章、发布、回滚。人类工作台：Markdown 编辑、预览、媒体插入、审计和发布确认。图床、文件床和安全策略：让图片文件走外部存储，同时保留审计、快照和权限边界。这个项目想解决什么传统博客后台更适合人手动写文章：打开网页、登录后台、点新建、写正文、传图、预览、发布。这个流程很稳定，但当 AI Agent 开始参与内容生产之后，它就有一点别扭了。Agent 更擅长连续操作：整理素材、起草大纲、补充章节、检查错别字、生成摘要、给旧文补链接。它需要的是一组可靠的工具，而不是一个必须用鼠标点击的后台页面。所以这个项目一开始没有被定义成“漂亮一点的 Typecho 客户端”，而是被定义成：让 Typecho 成为一个本地可控、AI 可操作、远端尽量轻量的发布目标。人类界面负责检查、微调和确认；MCP 负责主要操作；远端服务器只需要 SSH，不额外暴露公网 API。第一版长什么样先看本地工作台。它不是一个花哨后台，而是一个能快速完成写作和审核的控制面：左边看文章和媒体，中间写 Markdown，右边预览，下面能看到快照和审计记录。这个界面只是入口之一。更关键的是，所有核心能力都下沉成了本地操作和 MCP 工具。也就是说，人可以点按钮，AI Agent 也可以直接调用工具完成同样的事。架构：本地重一点，远端轻一点当前方案分成三层：本地工作台：给人看的 Markdown 编辑和审核界面。本地 MCP Server：给 AI Agent 调用的工具入口。远端 PHP Agent：通过 SSH 自动部署，只在需要时执行。我喜欢这个结构的一点是，它没有要求远端 Typecho 改造成一个新系统。远端不需要手动安装插件，也不需要长期跑一个新服务。第一次连接时，本地程序通过 SSH 探测 Typecho 目录，识别 Docker 或宿主机 PHP 环境，然后上传一个很小的 agent。在这个真实环境里，Typecho 跑在 Docker 里，站点目录挂载到容器的 /app，SQLite 数据库是 /app/usr/typecho.db。本地只需要知道 SSH 主机别名 sg1，剩下的探测、部署和调用都由工作台处理。这次 vibe coding 做到了哪一步目前第一版已经跑通了一条真实链路：通过 SSH 连接远端服务器。自动识别 Docker 里的 Typecho。自动部署远端 PHP agent。读取站点信息和文章列表。创建草稿、更新文章、发布文章。发布前写本地快照。支持回滚。支持上传 Typecho 本地媒体。支持注册外部图床和文件床 URL。本地记录审计日志，方便回看每次操作。这篇文章本身，也是用这套流程创建出来的：先把配图通过媒体工具上传到 Typecho，再由 MCP 创建草稿。发布这一步默认需要显式确认，所以我先把它留在草稿状态，让人类最后看一眼。为什么第一步先做 MCP因为这个项目真正的主角不是编辑器，而是 Agent 工作流。如果只是做一个本地 Markdown 编辑器，那它和很多现成工具差别不大。但如果 Typecho 能被 MCP 工具稳定操作，AI 就能完成更多连续任务：创建系列文章、维护标签、插入外部图片、检查旧文、补链接、发布前生成摘要。更重要的是，MCP 把“能做什么”和“怎么展示”拆开了。人类工作台可以继续变好看，CLI 可以继续变顺手，AI Agent 也可以直接调用同一组能力。它们不需要互相抢主入口。这版里最重要的安全边界我不想让“AI 能发博客”变成“AI 一不小心就发出去了”。所以第一版里有一个很硬的默认策略：创建草稿可以直接做。更新文章前先写本地快照。发布必须显式确认。发布、更新、上传媒体都会写审计日志。回滚从本地快照恢复，不依赖人脑记忆。这套策略目前还很朴素，但已经足够支撑一个重要原则：Agent 可以帮我做很多事，但最后一步必须有清晰边界。下一篇写什么下一篇会拆 SSH 零操作部署这一层：本地如何探测远端目录，如何识别 Docker 容器，为什么让 agent 通过 stdin/stdout 通信，以及这样做比公开 HTTP API…

别再只让 AI 写代码了：给编程助手接上浏览器和 MCP，效率直接上一个台阶
type: item
date: 2026-05-28T04:22:49+00:00
description: 如果你最近还在把 AI 编程助手当成“会补全代码的聊天框”，那真的有点亏。2026 年的开发者工具热点，已经从“让 AI 写函数”变成了“让 AI 看到真实运行环境、读到项目上下文、调用外部工具，然后自己验证结果”。简单说：AI 编程助手正在从副驾驶，变成能干活的实习同事。这篇就聊一个特别实用的方向：把 AI coding agent 接上浏览器、MCP 和项目规范，让它不只是写代码，还能帮你调试、审查、跑测试、查文档。先说结论：这套工作流适合谁？如果你有下面任意一种场景，就很值得试：经常改前端页面，但反复截图、刷新、查控制台很烦；项目文档、数据库、云服务、Issue 分散在不同地方；想让 AI 帮你改代码，但又怕它胡写、瞎猜 API；你维护的是个人博客、小工具、Docker 服务、管理面板这类“东西不大，但杂活很多”的项目；希望 AI 帮你做重复任务，比如写测试、整理 PR、查日志、补文档。核心思路只有一句话：不要只给 AI 一个问题，要给它工具、上下文和验收标准。最近为什么突然火？1. 浏览器调试终于能交给 Agent 了Chrome DevTools for agents 1.0 已经发布。它的重点不是“又多了一个聊天助手”，而是把浏览器调试能力开放给 AI coding agent：看页面、查 DOM、跑 Lighthouse、做设备模拟、定位内存泄漏。这对前端和全栈开发特别关键。以前 AI 写完页面，只能靠你描述“这里歪了、那里不对”。现在它可以自己打开页面、观察结果、再回去改代码。2. MCP 变成 AI 工具接入的通用插座MCP，全名 Model Context Protocol，可以理解成 AI 连接外部工具和数据源的一套开放协议。Anthropic 最早开源后，现在越来越多工具围绕 MCP 做集成。你可以把它想成 USB-C：GitHub、Postgres、浏览器、文件系统、云服务，都可以做成 MCP Server；AI 客户端作为 MCP Client，按权限调用这些工具；你不用为每个 AI 工具重复写一套私有插件。 3. 云厂商也开始给 Agent 准备“安全栏杆”AWS 最近发布 Agent Toolkit for AWS，把 MCP Server、Agent Skills、插件和 IAM 权限边界放到一起。这个信号很重要：企业不是不想用 AI Agent，而是怕它乱动生产环境。所以未来真正好用的 AI 开发工作流，一定不是“给 root 权限让它随便跑”，而是：能查文档；能读日志；能在沙箱里执行；能跑测试；能被权限和审计限制住。一套个人开发者也能落地的配置清单下面这套不追求玄学，适合个人项目、小服务器、博客、Docker 应用。第一步：给项目写一份 AGENTS.md很多 AI coding agent 都会读取项目里的说明文件。你可以在项目根目录放一个：# AGENTS.md ## 项目说明 这是一个 Typecho + Docker Compose 部署的个人博客。 ## 常用命令 - 查看容器：docker ps - 查看日志：docker logs --tail=100 <container> - 检查 Compose：docker compose config ## 修改规则 - 修改数据库前必须备份 - 不要在生产服务器安装新软件 - 所有文章发布前检查标题、slug、分类关系 ## 验收标准 - 页面 HTTP 200 - 首页能看到新内容 - 图片和 iframe 不被过滤这东西看起来朴素，但非常有用。它能把你的偏好和安全边界变成 Agent 每次都会参考的“项目说明书”。第二步：把浏览器接进调试流程如果你做前端，建议至少准备一个能让 AI 观察页面的环境。官方示例里，Chrome DevTools for agents 支持 MCP Server、CLI 和 Agent Skills。它能让 Agent 做这些事：打开页面并截图；检查控制台报错；模拟移动端窗口；跑 Lighthouse；检查可访问性和 SEO；调试复杂的浏览器状态。这一步的价值很大：AI 不再只听你说页面错了，它能自己看。第三步：只开放必要工具，不要一上来给全权限这是很多人会踩的坑。别为了省事直接给 AI：sudo su chmod -R 777 /opt 把生产数据库直接给它随便改更推荐这样拆：# 只读观察 ssh myserver "docker ps && docker logs --tail=80 app" # 修改前备份 cp data.db data.db-before-change-$(date +%Y%m%d-%H%M%S) # 改完验证 curl -I https://example.com让 Ag…

AI 行业一周观察：从 Google I/O 到内容溯源，AI 正在从“会聊天”走向“能落地”
type: item
date: 2026-05-28T02:30:27+00:00
description: 最近几天 AI 圈最明显的信号，不是某一个模型参数又涨了多少，而是“大模型开始进入产品、创作工具、搜索、开发者工具和内容可信体系”的速度越来越快。换句话说，AI 仍然在卷能力，但真正值得关注的是：它正在变成基础设施。1. Google I/O 2026：AI 从功能点变成整套产品语言Google 在 I/O 2026 上集中发布了一大批 AI 相关更新，官方甚至整理成了“100 things we announced at I/O 2026”。最值得普通用户关注的，是 AI 不再只是一个单独入口，而是被塞进搜索、购物、创作、工作流、眼镜等场景里。这件事的含义很直接：未来我们接触 AI 的方式，可能不是“打开一个聊天框”，而是在搜索、写文档、剪视频、写代码、逛商品页面时，顺手让 AI 替你完成一段判断、生成或执行。2. 生成内容越来越多，可信来源会变成新刚需OpenAI 最近也在强调内容溯源和真实性问题。随着图片、视频、音频都能被模型高质量生成，“这是谁做的”“有没有被改过”“能不能追踪来源”会越来越重要。这不是一个只属于媒体公司的问题。普通博客、教程站、独立开发者和小团队，未来也会遇到类似需求：当 AI 内容越来越像真人产物时，清楚标注来源、引用、生成方式，反而会成为一种信任资产。 3. Anthropic 收购 Stainless：AI 公司开始补“工程落地”的短板Anthropic 收购 Stainless 也挺有代表性。Stainless 的方向是帮助公司生成和维护 SDK、API 文档等开发者基础设施。这个动作说明一件事：模型公司不仅要拼模型本身，还要让开发者更容易把模型接进真实业务。如果说过去两年 AI 的主角是“模型能力”，那么下一阶段的主角很可能是“可用性”：API 是否稳定，SDK 是否顺手，文档是否清楚，成本是否可控，部署和监控是否成熟。我自己的判断接下来一段时间，AI 行业大概会有三条线并行推进：模型继续升级，多模态、长上下文、Agent 能力都会往前走；大厂把 AI 深度塞进已有产品，普通用户感知会更强；内容可信、开发者工具、企业集成这些“无聊但关键”的基础设施会变得更重要。对普通人来说，最值得关注的不是每天追一个新模型名字，而是观察：哪些 AI 能真正进入自己的工作流，帮你少做重复劳动，或者让原本做不了的事变成可操作。参考链接：Google: 100 things we announced at I/O 2026OpenAI: Advancing content provenanceAnthropic acquires Stainless这是一篇通过数据库直写发布的测试文章，用来验证 Typecho 发文、图片和视频嵌入是否正常。

直链测试
type: item
date: 2026-05-27T15:23:00+00:00
description: BGM.mp3

宝塔面板解决反向代理与SSL冲突的方法
type: item
date: 2022-04-24T18:04:31+00:00
description: 需要注意2点：先申请SSL后再设置反向代理，或者将反向代理暂停后再申请SSL再开启；申请完证书后，通过如下代码将.well-known目录伪静态化，使得该目录可以被外部访问，即可实现自动续签。[hide]location /.well-known/ { }[/hide]

Transfer Files Between Any Devices Using Piping Server-转载
type: item
date: 2022-04-24T12:28:17+00:00
description: This guide teaches you how to easily and securely transfer files between any devices using Piping Server from command line and via a web browser. You can transfer any kind of data infinitely with Piping Server. It could be a directory, a text file, an audio, video, or anything. Also, It doesn't matter which OS or device you're using. Sharing files with Piping Server is quite easy and straight forward.A brief introduction to Piping ServerPiping Server is a free web service used to share any data between any devices over HTTP/HTTPS. The data can be transferred either from the Terminal using curl program or via a web UI. No sign-up or registration required! You don't even need to install any extra software. All you need is either curl command line program or a modern web browser, which are pre-installed in most operating systems.The Piping Server transfers the data securely with end-to-end encryption. It never stores your data in any central location or public cloud. Piping Server uses peer-to-peer method to relay data from one device to anther.It can able to share data between multiple devices at the same time. Just send a file from one device and receive it from multiple devices. If a file or folder is too big to share, simply compress it and send it.The developer has also created a few more applications and scripts that uses Piping Server:Text stream chatShare Drawing via Piping Server with End-to-End EncryptionTerminal screen sharingPiping UI - A web interface to easily and securely share data between devices over HTTPSPiping-ssh-web - SSH over HTTPS via Piping Server on Web browserPiping-vnc-web - VNC over pure HTTPS via Piping ServerThe link to the aforementioned applications are given in the Piping Server main GitHub repository.Transfer files between any devices using Piping Server from commandlineSharing files between multiples devices with Piping Server is very easy! First, we will see how to share data between two systems using curl program.For example, I am …