ARTICLE · 1226028
我如何打造自己的 AI 助理与工作流
我如何打造自己的 AI 助理与工作流：从多设备混乱到自动化闭环
一、痛点：一个人，一堆设备，永远在找文件
我不是那种只用一个笔记本的人。我的"生产现场"散落在好几台设备之间：
一台装了各种设计、剪辑、工程软件的 Windows 工作站，是日常主力 两台家用 NAS（网络存储），一台跑应用服务、一台纯存项目归档和媒体素材 一台随身 MacBook，路上回消息、写东西、看文档 公有云上还有一两台 云服务器，跑官网和对外服务
过去我的工作流是这样的：脑子里记着"合同在 NAS 哪个目录"，微信里收到甲方文件顺手存桌面，承诺"明天发你"然后忘了——直到对方来催。跨设备、跨项目的文件像沙子一样漏。
我试过买 SaaS：笔记软件、任务工具、网盘同步……结果又多了一层要维护的东西，而且数据在别人手里。真正的转折是：与其再买一个工具，不如自己造一个 24 小时在线的 AI 助理。
二、我的 AI 助理长什么样
它不是聊天机器人，而是一个有记忆、能执行、会主动的私人助理（底座是一个开源 Agent 框架）。三条核心能力：
1. 记忆持久化
跨会话记住你的偏好、设备清单、项目状态，甚至"哪些事不可逆必须先问"。你不用每次重新介绍自己，它也不会重复问你已经答过的问题。
2. 工具执行，而不只是问答
它能直接调用终端、读写文件、驱动浏览器、收发邮件、调度定时任务。你说"帮我把合同改成含税并盖章发我"，它真的去改 HTML、嵌入电子公章、导出 PDF、归档、再发给你——不是给你一段操作指南。
3. 主动托管，不等你问
每天凌晨自动跑一些公益站签到；定时复盘当日待办；发现系统盘快满就先做深度研究、确认无风险后帮你清理释放出可观空间；监控邮件和店铺动态。它像一个有手的实习生，而不是一个搜索引擎。
顺带说一句边界：我给它的红线写得很死——不可逆、破坏性、花钱、法律相关的事，一律先汇报。其余它自己干。这个边界不是限制效率，是让我敢放心把钥匙交给它。
三、工作流架构：一张网，一个事实源
（图：设备拓扑——本地 Windows + 两台 NAS + 便携 Mac + 云服务器，AI 助理通过密钥无密码运维，NAS 上的项目文件夹作为单一事实源）
几个让这套东西跑起来的关键设计：
- 密钥无密码运维
：所有设备用 SSH 密钥登录，助理能随时跨设备干活，但绝不碰系统容器和不可逆操作——钥匙在手，边界在心。 - NAS 项目文件夹 = 单一事实源
：所有项目产物进统一的项目目录，按项目实际内容设计子结构，不散落桌面、不靠记忆。换设备、重装系统，项目都在。 - 定时任务驱动节奏
：晨间复盘 → 全天监控 → 夜间维护，形成可预期的自动化节拍，而不是"想起来才做"。
一天的典型流程：早上助理把昨日待办和今日节点推给我；白天我口述需求，它落地执行；夜里它自己把该清的清了、该签到的签了。我只在"需要决策"的节点被叫醒。
四、开源项目一：wxwright —— 让 AI 写的东西直接能发
（图：wxwright 客户端界面，左侧写 Markdown，右侧实时预览多平台效果）
写这篇文章时最大的麻烦从来不是"写"，而是"发出去"——你精心排的版，粘进公众号编辑器往往被阉割得面目全非：行距被重置、代码块变纯文本、引用块丢了样式。多平台发更要重复劳动。所以我做了 wxwright。
它是什么：一个把 Markdown 转成微信公众号 / 小红书 / 知乎多平台富文本的引擎（Rust 写的命令行工具 + 桌面客户端，MIT 开源）。
为什么能做到"零样式失真"
公众号编辑器只认一小撮 HTML 标签，大多数排版工具要么输出它不认的样式，要么干脆丢样式。wxwright 的渲染管线只生成平台支持的标签与内联样式，所以粘贴后所见即所得，不崩。
完整流水线就一行：
wxwright copy article.md --json它会跑完 解析 → 主题渲染 → 图片管线 → 规范化 → 校验 → 剪贴板，把可以直接粘贴的富文本递到你手里，并附一份机器可读的 JSON 报告（警告、自动修复记录、校验结论）。
几个我用着顺手的点：
- 多平台一套稿
：同一份带元信息的 Markdown，切换平台自动变体，不用每平台重排 - 本地图片内联
：不用先传图床，写完即发 - 校验 + 自动修复
：转换后自动检查平台官方规范违规并修复，Ship 前零 blocking 问题 - 草稿箱 / 群发
：登录后一条命令推草稿箱，群发需显式确认（对外发布必须人点） - 内置多主题
：极简、科技蓝、杂志风、和风等，写技术文我常用科技蓝
五、开源项目二：SerialRUN —— 给硬件调试也配上 AI
（图：SerialRUN 多标签页同时监听 Modbus 轮询、CAN 帧、串口日志）
如果你也做硬件、工控或物联网，会懂这种痛：一个 Modbus 轮询追另一个 Modbus 轮询，设备没响应时你不知道是串口掉了、从站离线、还是有人改了寄存器——所有人都盯着同一块屏。
SerialRUN 是我用 Rust 写的串口 / 工业通讯调试工具，核心思路是：每个标签页是一个独立的工业通讯系统会话，可以同时挂着原始串口、Modbus 寄存器视图、CAN 帧、日志，各看各的，不互相挡。
1. 一套 core，GUI / CLI / AI 共用
架构分 core / cli / gui / mcp / plugin-api。任何执行逻辑都写在 core 里，GUI 按钮、CLI 命令、AI 工具调用全都打到同一个核心。这意味着 AI 能做的操作和你手动点的一模一样，不会出现"AI 走后门"的情况。
2. MCP 服务器，19 个工具
SerialRUN 内置 MCP server（Model Context Protocol，让 AI 调用外部工具的标准协议），暴露 19 个工具给 AI 调用：list_ports、connect、modbus_read、plc_write、get_access_log……
不用让 AI 自己拼 Modbus 帧——你只要说"读一下 1 号从站保持寄存器前 10 个"，它调 modbus_read 就行，CRC 校验和帧格式由 core 兜底。写代码的同事用 CLI 也能自动化：
const client = new MCPClient("127.0.0.1", 9527); await client.call("connect", { port: "COM4", baud_rate: 115200 }); await client.call("modbus_read", { slave: 1, function: 3, address: 0, count: 10 });3. 插件边界用 C FFI
要给 SerialRUN 加自定义协议？插件走 C 接口，不碰 Rust ABI，内存安全由边界层兜底。
安全边界：读写工具分离（运维只能看、不能改）、每次操作写访问日志、本地端口记录调用方信息。AI 碰真实设备，审计不是可选项。
六、元叙事：这篇文章就是这么生出来的
回看开头那句话——本文本身就是闭环的产物：
我口述大纲 → AI 助理落地成带元信息的 Markdown 本地 wxwright 把它转换（convert）成公众号 HTML，校验（validate）零违规 助理把成品推进公众号草稿箱，群发那步交给我自己点确认
造工具的人，最先用上工具。 这也是我做开源的动力：把踩过的坑变成别人的捷径。
七、给创业者的三条建议
- 别先买工具，先固化你的操作铁律。
工具是铁律的载体，没有铁律，十个 SaaS 也只是十个待办。 - AI 助理要"敢执行"，但边界要写死。
我给助理的红线是：不可逆、破坏性、花钱、法律相关的事，一律先汇报。其余它自己干。 - 小团队用开源 + 自托管，成本可控、数据在手。
wxwright 和 SerialRUN 都是我自己用、自己开源，不依赖任何一家 SaaS 的生死，也不把数据交出去。
八、写在最后
关注我的公众号，或者去 GitHub 给 YaoIsAI 点个星——这两个项目都在持续迭代。下期我打算写写"如何用 AI 助理托管一家跨境店铺"，那是另一个更有意思的坑。
如果这篇文章帮到了你，转发给你的技术合伙人。我们下篇见。
