前两篇讲了为什么把散装 AI 工具拼成小队、任务卡长什么样。这篇是实战篇：怎么让这支小队在你睡觉的时候自己干活，早上起来活已经干完了。讲两件事——无人值守流水线由哪几块拼成、真正跑起来踩过的坑。所有数据来自一次真实的夜间运行，不是设想。 一、先看一次真实的夜班不画饼，先放战绩。某天晚上到第二天凌晨，这条流水线的实际运行记录： 时间 发生了什么 23:00 额度窗口开启，自动派发启动 01:27–02:02 第一批任务卡陆续收口 03:00–03:55 崩溃面扫描、无障碍走查等卡完成 04:39 最后一次模型调用，额度基本打光 08:30 晨间战报自动推送：完成 25 张、受阻 4 张、剩余待领 14 张 连续跑了约 5 小时 40 分钟，把 3 亿单位的夜间额度用到只剩万分之零点五，收口十几张任务卡，全程没有人干预。我早上起来看到的是一条汇总消息，而不是一堆待处理的报错。 这不是 demo。是每天都在跑的东西。下面拆它是怎么拼起来的。 二、流水线由哪几块拼成四个角色，各管一摊： 块 谁 干什么 大脑 Hermes（本地常驻 AI 助手）

一篇关于「药店智能 Agent 系统」的实践记录。这是我自己独立开发的全栈 AI Agent 项目：LangGraph 编排 11 节点工作流 + 三级 RAG（向量 / BM25 / 交叉编码重排）+ Function Calling 工具系统 + Guardrails + 真 SSE 流式输出，知识库 702 条，一套 FastAPI 服务端加 Web 前端。这篇是系列总纲，讲清楚系统长什么样、为什么这么设计，以及后续会拆开的几个技术点。 一、为什么是药店？选药店场景不是随手挑的。 Agent 落地最常见的形态就是客服助手——LangChain《State of AI Agents》报告里，客服场景占了生产用例的 45.8%。药店恰好是客服助手的理想样本： 有真实检索需求：顾客问药，回答必须基于可靠的药品知识，不能靠模型硬编——RAG 的天然落地场； 有工具调用场景：查库存、查销售、查药品相互作用，需要接数据、接 SQL，而不是纯聊天； 有安全底线：医药回答错不得，幻觉检测、来源引用、Guardrails 都是刚需，正好把”安全”这个面试必考点做扎实。

上篇讲了为什么要把散装的 AI 工具拼成一支小队。这篇是落地篇：任务卡到底长什么样、怎么派下去、怎么验收，以及真正跑起来之后踩过的坑。 一、一张图看懂全流程先放全貌，后面逐段拆： 12345678910111213141516171819202122232425262728flowchart TD A[需求/缺陷/新功能] --> B{能派 AI 做吗?} B -- 否 --> B1[自己直做或等条件] B -- 是 --> C[写任务卡入收件箱] C --> C1{写卡前四查} C1 --> C1a[工作区是否干净] C1 --> C1b[编号防撞] C1 --> C1c[现状核实 防重复派卡] C1 --> C1d[文件锁] C1 --> D[卡结构六要素] D --> E{选派发通道} E -- 有 CLI --> E1[headless / 直发] E -- 无 CLI --&g

一篇关于「让本地跑着的 Hermes 当管家，把 Kimi、ZCode、Qoder、WorkBuddy 这些我用过的 AI 编码工具的免费额度拼成一支小队」的想法记录。这篇是预告，不讲实现细节，讲为什么这么想：免费额度为什么值得拼、管家管什么、人和 AI 怎么分工、边界划在哪。 一、起因：工具很多，但都是「散装」的这两年 AI 编码工具一个接一个冒出来，Kimi、ZCode、Qoder、WorkBuddy……几乎每家都给免费额度。白给的东西，道理上讲，等于白嫖了一支外包小队。 但用起来很快发现问题：这些工具全是散装的。 额度分散。 这个用完了那个还有，全靠手动切，忘一次就浪费一次。 项目分散。 手上有好几个项目在推进，每个干到哪个节点了，全靠记忆。 上下文断裂。 换个工具，得把需求从头再讲一遍。 转折点在于：我电脑上常年挂着一个本地 AI 助手 Hermes。它已经能理解需求、跑定时任务、记得我的习惯和红线。那为什么不干脆让它当调度员，把所有工具管起来？ 二、核心想法：管家不写代码，管家派活一句话讲清楚：Hermes 不直接写代码，它管「谁来做」。 流程是这样的：丢一句话需求

一篇关于「AI 大量代写代码之后，自己写代码的能力会弱化，所以要把学习重心上移到框架层」的实践记录。讲四件事：为什么该学的是框架层而不是细节 API、怎么系统学框架、怎么指挥 AI 搭出坚固的架子，以及底座扎实之后 AI 写业务为什么更稳。 一、承认一个不舒服的事实：写的手感会弱化现在我的日常开发，大部分代码不是自己敲的，而是「需求 → 派卡 → AI 写 → 我来验收」。这个流程效率很高，但有一个副作用我观察了很久，也跟不少同行聊过：手写代码的能力，确实在钝化。 具体来说，弱化发生在三个地方： 语法和 API 的记忆在衰减。 以前闭着眼睛能写的 API，现在会习惯性去问 AI；不是不会，是”想不起来”，大脑的检索路径被”问一下就有答案”替代了。 调试直觉在变钝。 以前定位 bug 靠的是对代码的熟悉和手感，现在下意识就是”把报错丢给 AI”。定位问题的肌肉记忆，用进废退。 对代码的”所有权感”在下降。 不是我亲手写的代码，出了问题第一反应是”看看 AI 写的什么”，而不是”我哪写错了”。 但我要先说清楚：对抗这个趋势是徒劳的。 AI 写代码是回不去的方向，回到”全部手写”既不

上一篇《把飞书变成 AI Agent 的日常操作台》拆的是「AI 在飞书里怎么干活」——运行时接入层的架构和踩坑。但那篇文章默认你已经有了一个能对话的机器人。这篇补上前半截：一个不懂代码的普通人，怎么从零开始，把 AI 真正装进飞书。全程网页后台点击 + 一份五层体检脚本，大概 20 分钟能跑通。 一、先说清楚：这件事其实只有两层很多人卡在第一步，是因为把「开通」想象成了一个庞然大物。实际拆开看，把 AI 装进飞书只有两层事： 层 干什么 占的工作量 需要写代码吗 飞书侧开通 在飞书开放平台建应用、开权限、订阅事件、发布版本 约 80% 不需要，全程网页后台点击 agent 侧接入 把 app_id / app_secret 填进你用的 AI agent 配置 约 20% 复制粘贴一段配置 关键点在于：飞书侧这 80% 和你在 agent 侧用什么框架完全无关。你在飞书后台做完所有配置，拿到的唯一产出就是两个值——app_id（形如 cli_xxxxxxxx）和 app_secret。之后不管你是接 Hermes Agent 还是别的任何支持飞书机器人

一篇关于「AI 怎么在聊天软件里成为一个正式角色」的实践拆解。我每天都在飞书里跟我的 AI Agent 协作：发消息派活、在文档里 @ 它改稿、点卡片批准命令。这套体验不是「接了个机器人」，而是一整个平台接入层的设计。这篇文章拆一拆 Hermes Agent（开源）的飞书接入层是怎么做的，以及我用下来踩过的坑和还欠着的优化。 一、为什么要把飞书当 AI 的操作台做 AI 工具的人有个共识：AI 最好长在用户已经在的地方，而不是让用户多开一个工具。 对我来说，那个「已经在的地方」是飞书——上班开着它，手机上也有它，同事、文档、日程全在里面。于是我把自己的 AI Agent 接进了飞书，日常用法就三种： DM 里直接发消息：派活、问问题、传文件，像跟同事聊天一样； 文档里 @ 它：在飞书写完的东西，选中文字评论 @ 一下，AI 读完上下文直接在评论线程里回； 点卡片做决策：AI 要跑危险命令时，发一张「允许一次 / 本次会话 / 总是允许」的卡片，我点一下按钮就完成授权。 体验好的背后是大量看不见的设计。这篇拆的是 Hermes Agent（NousResear

一篇关于「把 MCP 用好」而不是「把 MCP 装好」的实践记录。我在一个车企超级 APP 项目的 iOS 迭代里，用蓝湖（Lanhu）MCP + Lookin MCP 搭了一套项目无关的工具层（harness），把 AI 写代码从「看着截图猜」变成了「读着需求写、对着真机验」。这篇文章讲清楚两件事：MCP 和 harness 到底差在哪一层，以及这套东西是怎么一步步落地的。 一、先分清两件事：MCP 是协议，Harness 是交付形态这两年 MCP（Model Context Protocol）很火，但很多人把它当成万能药：装个 MCP server，AI 就能用了。实际用下来你会发现，MCP 只解决「连接」，不解决「复用」。 我的理解是两层： MCP 层：一种开放协议，让 AI 应用（Claude Code、Cursor、ZCode……）以统一方式调用外部工具。它回答的问题是「AI 怎么连上某个能力」。 Harness 层：在能力之上做一层项目无关的封装——命令行入口、接入模板、提示词模板、产出目录约定。它回答的问题是「这个能力怎么被任何项目、任何 AI 工具顺手用起来」。

一、起因：一个文件夹引发的思考前两天发博客的时候我突然意识到一件事：我这套 Hexo 博客环境，从安装依赖、配置主题、写文章到部署上线，整个流程已经被 AI 跑得很顺了——顺到我自己都快要记不住具体命令了。 然后我就冒出一个想法：既然这套东西对我来说已经是”一键”的，为什么不把它打包出来，让别人也能一键拥有？ 于是有了这个项目：HexoBlogStarter —— 一个开箱即用的 Hexo 博客工具包，内置 Fluid 主题，clone 下来改 3 处配置，10 分钟就能拥有自己的博客。 但它真正有意思的地方不在”又一个 Hexo 模板”，而在于它的设计思路。 二、双通道设计：README 给人看，AGENTS.md 给 AI 看这个仓库里有两份”说明书”： README.md —— 传统的，给人类看的教程：四步上手、目录结构、FAQ AGENTS.md —— 给 AI Agent 看的操作手册：环境怎么装、文章怎么发、故障怎么排查、红线是什么 为什么要专门给 AI 写一份？因为这是我上一篇文章里那个观点的又一次实践：Markdown 正在同时成为人和 AI 的共同语言。 拿到这个

一、先说一个我踩过的坑上个月做一个会员功能，规则是”连续包月用户，取消后已付费周期内权益保留”。规则是在群里聊定的，我（iOS）看完聊天记录的理解是：到期那一刻权益失效。Android 的理解是：取消那一刻还能用到周期末。后端的理解又是另一回事：他返回的字段里压根没有”到期时间”，只有一个”是否有效”的布尔值。 联调那天三方一对，全对不上。翻聊天记录，产品原话是”取消了当然还能用到月底啊”——这句话同时支持我们三个人的三种理解。 最后后端加字段、两端改逻辑，白花了两天。这种事的根源不是谁水平差，而是沟通介质有问题：群聊、语音、口头传达，天然就是模糊的、易丢失的、无法比对的。 而规则类、逻辑类的需求，恰恰是最经不起模糊的东西。 尤其是一个需求涉及 iOS、Android、前端、后端好几个端的时候——同一条产品规则，后端是校验逻辑，前端是交互提示，客户端是本地展示加兜底，每个端的实现方式都不一样。没有一份统一的、精确的参照物，误解是必然，一致才是运气。 二、解法：规则不靠”聊”，靠一份 AI 生成的 Markdown 文档后来我在项目里换了个流程，核心就一句话： 任何涉及规则、逻辑的需求