两个 AI 窗口，怎样接力完成一篇文章？

在日有所见里，笔者会和 AI 讨论报告功能、研究方法和产品设计。有些讨论值得写成博客，却不适合原样公开：里面可能夹着个人背景，写给开发助手的说明，也未必适合订阅者阅读。

博客这边又有另一套要求：文章用什么语气，怎样分类，图片从哪里加载，检查通过后怎样发布。如果每次都把整段聊天复制过来，博客助手得重新猜重点、辨别隐私，还可能接过一堆技术细节，认真写出一篇读者不想看的工程记录。

希望得到的体验倒很简单：在研究窗口说一次“整理交接”，再在博客窗口说一次“接收并处理”。重复的文件定位、版本核对和检查步骤，应当有稳定的办法。

这篇就讲这套办法：为什么分开两个项目，材料怎样接棒，又怎样把反复使用的流程写成 Skill。Skill 在这里可以理解为一份 AI 能按需读取的任务操作手册。它不会替人凭空多做什么，却能让下一次少重新解释一些事情。

为什么保留两张工作台

这里的两个项目，是日有所见与 MyNote 各自维护的 Codex 工作环境和对话。它们可以访问部分相同仓库，但主要职责不同。

有三个容易混淆的词，先拆开：

把仓库加入环境，不等于另一个窗口的聊天也搬了过来。仓库有了新提交，已有的本地副本也不会因此实时更新；接收时仍要主动获取远端信息，或直接读取指定版本。

日有所见主要负责研究项目本身：理解设计、核实功能与变化，把可分享的经验整理出来。MyNote 主要负责读者看到的东西：按博客风格组织文章、处理资源、检查构建和发布结果。

可以把前者看成作者的工作台，后者看成编辑的工作台。作者不必掌握博客每一个部署细节，编辑也不应该为了写一篇文章而翻遍私人研究资料。

这种分工常叫“职责解耦”，意思是一边调整内部做法时，另一边不必跟着一起改。例如报告更换了内部生成步骤，只要交出来的材料仍讲清背景、事实和限制，博客就能继续处理；博客换了排版办法，研究助手也不用重新研究整套网站。

拆开当然有代价：要维护交接约定、更新文件、核对两边的结果。偶尔写一篇短文，一个窗口可能更省事。这里已经有持续研究和独立博客，才值得保留两张工作台。

交出去的是材料，不是全部记忆

两个窗口之间的桥梁，是一份交接包。

交接包的主体叫 brief.md，使用 Markdown 编写。Markdown 就是带有标题、段落和简单格式的文本，便于人阅读，也便于 AI 处理。这份材料需要让接收方在不读原始聊天的情况下，知道这次该写什么。

至少应当回答六个问题：写给谁，想解决什么问题，哪些事实已核实，建议怎样组织，哪些内容不能写，以及希望新建文章还是修改原文。是否允许发布，则仍以用户给接收方的指令为准。

举个通用例子。研究窗口刚讨论完一个新功能，可以交出这样的摘要：

读者：已经收到报告，但不了解开发细节的订阅者。
目的：解释新增内容怎样帮助阅读。
已知事实：邮件有摘要，附件有完整分析。
组织方式：先讲收到什么，再讲怎样使用。
边界：不披露私人数据，不承诺收益或准点送达。
目标：更新现有介绍文章，保留原地址。

这是一份示意材料，不是需要执行的真实交接。它比整段聊天更容易接住，因为工作中的零散上下文已经整理成下一位处理者能够使用的输入。

输出侧会先去除私人信息，接收侧仍要再次检查。目录叫 ready，只表示“可以交给接收方”，不等于已经适合直接发表，更不等于获得发布许可。

这里也有一个重要限制：博客环境如果能访问整个私有研究仓库，技术上仍可能读到交接目录以外的文件。“只读这份材料”是操作约定，不是文件夹级访问控制。需要严格隔离时，应把脱敏素材放进独立仓库，只开放那个仓库。

编号找材料，提交找版本

仅说“读一下最新素材”，不够可靠。作者说这句话以后，素材可能又改过；文件名不变，内容也未必还是刚才复核的那份。

因此，每个包都有唯一编号，目录形如下面这个占位示例：

handoff/mynote/ready/YYYY-MM-DD-example-topic/
    brief.md
    assets.json    # 有配图时才提供

编号负责定位主题，Git 提交标识负责固定版本。Git 是记录文件变化的版本管理工具；每次提交形成一个版本记录，并得到一串提交标识。接收时提供完整标识，就是要求“读取已经确认过的这一版”，而不是碰巧看到的最新内容。

对于熟悉命令行的读者，核心操作可以概括为：

git show <固定提交>:handoff/mynote/ready/<交接编号>/brief.md

这里的尖括号是占位符，不是可以原样执行的命令。这种读取方法不用把整个工作目录切换到旧版本，也就减少了为了拿一份材料而干扰其他修改的机会。实际操作仍要先核对仓库身份和现有改动。

交接包需要修订时，新建编号，并用 supersedes 记录它替代哪一版。这个词在这里就是“替代”。博客接收方顺着它找到原文章，判断应该更新原文，还是确实新建一篇。

例如，同一篇报告介绍换了受众和配图，新交接应更新原地址；这次讨论两个 AI 项目如何交接，则是另一个主题，应新建文章。版本变了，不自动意味着读者需要再收到一篇几乎相同的文章。

图片也要有说明卡

图片和 GIF 等静态资源放在 Gallery 仓库。所谓静态资源，就是不必执行程序便能使用的文件，例如一张配图。

有图时，交接包增加 assets.json。JSON 是一种机器容易读取的结构化文本；在这里，把它理解为每张图的说明卡就够了。

这张卡不仅写“图在这里”，还要交代固定的 Gallery 提交、文件路径、校验值、尺寸、替代文字、图注、放在哪里，以及为什么可以公开使用。替代文字描述图中内容，帮助看不到图片或使用屏幕阅读器的读者。

图片校验值常用 SHA-256。它按文件内容计算出一串值，接收方重新计算后比较，可以发现文件是否发生变化。它和 Git 提交标识分工不同：前者核对某个文件的字节，后者定位一组文件的版本。两者都不能证明图片内容真实，也不能代替隐私与版权复核。

接收方仍要看最终图片，GIF 则查看全部帧，还要检查是否夹带个人信息或不必要的附加元数据。生产方写了“已复核”，不表示编辑可以闭眼签收。

上传顺序也有理由：先确认图片已推到 Gallery，再推包含清单的文字材料。否则博客可能先拿到一份指向尚不存在图片的说明。不过，两次推送不是不可分割的一次操作，仍可能图片成功、文字失败；这时只能报告部分完成，不能宣称交接成功，也不应随意删除已经上传的图片。

最后还要检查公开访问。能通过 Git 取出文件，不代表读者无需登录就能打开图片链接。博客可以使用经过验证的固定版本公开链接；无法确认外链时，也可以将已校验的文件随站点一起发布。

旧图不要覆盖，新图用新文件名或新版本。这能避免一张图片的替换，悄悄改变已经发表的其他文章。

用两个 Skill 收起重复步骤

文字和图片的手动交接走过以后，重复工作逐渐稳定下来，便可以写成项目级技能：

技能入口是项目中的说明文件，例如：

.agents/skills/handoff-in/SKILL.md

文件开头给出技能名称和用途，后面说明适用场景、应读取哪些规则、怎样执行以及怎样判断完成。技能可以引用脚本和模板，但本案例首先落地的是操作说明，并没有因此多出一套自动运行的后台服务。

项目里的几种文件也各有位置：AGENTS.md 是长期协作约定和阅读入口；SKILL.md 负责某类任务怎么做；交接协议定义双方应理解的材料；素材模板帮助填写具体内容。技能引用已有规则，尽量避免复制三遍，日后改了一处却漏掉另外两处。

调用时，用户可以这样提出要求：

研究窗口：使用 $handoff-out，把这次讨论整理成给订阅者看的素材。
博客窗口：使用 $handoff-in，接收指定编号与提交，先生成草稿。

如果接收端没有明确的发布要求，就停在草稿。若明确要求发布，才进入博客已有的检查和部署流程。这里没有让两个对话自动互发消息，也没有让一份素材自己取得推送权限。

接收端究竟实现到了哪里

本次成文前，博客端实际检查了自己的技能文件与 Git 历史。

handoff-in 已创建，技能文件与 AGENTS.md 入口提交在独立分支 docs/handoff-in-skill 上，提交为 8d835cc。创建时已验证文件结构、仓库根目录定位和引用路径。这次也是按用户提供的文件路径读取并使用它，而非假定客户端已经自动发现。

但这份技能尚未合入主分支，不能因此宣称以后从主分支创建的新任务必然能够找到它。当前也没有专门用技能完成纯文字、带图、旧文更新等全部场景的统一验收。此前手动完成过这些类型中的交接，不等于新技能的每一条规则都经过独立测试。

技能发现本身也可能需要新任务或重新加载。文件已存在、助手本次读过、客户端自动列出技能，以及所有流程都经过验证，是几个不同结论。

核查之后，没有必要为了让文章显得完整而再造一份接收技能。本次只发布这篇新文章，既有技能分支保持独立，原来的报告介绍也没有改写。

一次交接成功，还得看文章写给了谁

此前那篇《每天这份「日有所见」，能帮你做什么？》，就经历过一次很有代表性的返工。

第一版文字和图片已经传过去，文章也发布了，但内容太像写给开发者的工程复盘。订阅者更需要知道报告提供什么、怎样读、哪些判断不能直接照搬，技术细节却抢走了主线。

所以，“文件传成功”和“文章写对了”必须分开验收。后来交接材料重新明确受众，博客把整篇文章改成使用介绍，保留原地址，而非再发一篇同题文章。

配图也改了一次：标题从英文品牌名换成中文“日有所见”，通过新版本清单替换引用。这件事提醒我，交接标准不只包含路径和哈希，还包括读者定位与视觉表达。

于是输出侧把“先确定读者”放到开头。接收侧则检查标题、摘要和正文是否都服务于这个目标，不能只把几个技术词换成通俗词，就认为已经完成改写。

本篇稍微技术向，是因为这次明确要求解释交接方法。规则帮助文章贴近各自目标，不应把每篇文章压成同一个模样。

为什么暂时还要人说两次

目前仍保留两次指令：研究窗口先决定什么可以交出去，博客窗口再决定接收后写成草稿、更新原文，还是公开发布。

这两个决定不同。材料从私人工作中整理出来，不意味着立刻适合发布；编辑认可一段表达，也不等于希望马上推送。素材里即使写了建议命令和外部链接，接收方仍只把它们当作待审资料，不能自动执行。

有一个实际踩过的边界：博客当前配置会在向 main 主分支推送时自动构建部署，即使提交里只有技能文档。main 可以理解为网站用于发布的主要版本线。因此，“我只改文档”不等于“不会部署”。

创建接收技能时，为了遵守当时“不触发部署”的要求，采用了只推独立分支、不合入主分支的办法。本篇则明确得到发布要求，才将新文章提交到发布分支。自动化开始之前，先看清它会触发什么，比事后解释它为什么动了更省事。

下一步，先补可验证的小事

目前两端已有约定，也有技能文件，接下来更值得做的是补证据和减少机械错误，而不是急着宣布无人值守。

首先，为接收技能补齐纯文字、带图和更新原文的代表性验收，并明确它在主分支的落地与发现方式。验证应检查结果，而不是只确认文件存在。

其次，可以增加交接包检查工具，自动核对必填字段、路径、版本和图片哈希。今天这些步骤仍由助手按说明组织执行，不能写成已经部署了一个统一校验服务。机器擅长机械比较，语义、隐私和使用依据仍需要判断。

接收记录也可以继续完善。博客文章目前已有交接编号和素材提交等元数据，可以追溯来源；以后若材料多起来，再考虑增加轻量索引，记录对应文章路径和实际处理结果，避免每次靠搜索定位。没有必要为此强迫博客回写私人研究仓库。

如果生产素材的项目越来越多，再讨论统一接口和检索。若隐私要求变严，优先考虑独立素材仓库和访问权限，而不是继续往操作说明里堆“请不要读取”。

最后，真要自动触发另一端任务，还得设计失败恢复、重复处理防护和发布控制。能触发一次任务，只解决了开始；能不能安全结束，是后面的事。这些都属于未来迭代，不是当前已有的服务保证。

可以先从一页交接说明开始

这套办法不要求一开始就建立三个仓库、两个技能和一套检查程序。

先把下一位处理者需要的内容写清楚：谁读、做什么、依据什么、哪些不能写、希望做到哪一步。实际用过几次，观察哪里反复解释、哪里容易误解，再把稳定的方法整理成技能。

对于笔者，值得留下来的经验是：一端知道该交出什么，另一端知道怎样接住，协作就已经比互相猜测可靠。版本让材料找得到，边界让责任分得清，检查则让“完成了”这句话有东西可以核对。

窗口开得再多，最终也还是要有人读那篇文章。先把文章写对，再让步骤少一点。