全部文章

从主观审美到可测规则 做内容的人都知道一个痛点：判断一篇稿子好不好，往往是主观审美。你觉得好，别人觉得不行。换一个审稿人，结论又变了。 这种主观判断在个人创作时还能忍，但在团队协作和自动化流程里就成了硬伤——因为没有共识标准，Agent 不知道该按什么规则来判断质量，人也不知道怎么给 Agent 设定质量门。那次做 PPT 审稿时，我遇到了这个问题的典型场景。 主观审美的困局 几页 PPT 发出

技能加载失败时，先问路径为什么不存在 那天输入了一条指令：加载 ~/.jianfeiwechat skill。 Agent 回了一句："我来查看这个路径下的 skill 文件。"然后执行了一条命令。 结果：命令完成，无输出。再试，报错：cannot open /Users/apple64/.jianfeiwechat' (No such file or directory)。 到这里，大多数人会做

Agent 说"You're apple64"时，它在告诉你什么 那次对话里，Agent 回了一句："You're apple64 — that's your system username and the home directory we're working in." 就这么一句话。看起来只是 Agent 在确认用户身份，没什么深意。但我停下来想了想：Agent 为什么在这个时候说这句话？它

旧内容进入新系统时，先保留什么 那次我在做微博历史内容的迁移。几千条微博，文字、图片、评论、转发关系，要搬到新的内容管理系统里。 第一反应是：全搬。数据量大，但机器能跑，让 Agent 批量处理就行。但动手之前，我停了一下。 搬完之后这些内容还能用吗？能用多少？哪些才是真正值得保留的？全搬的成本不只是存储和迁移时间——搬进来的大量低价值内容会污染新系统的内容结构，让后续检索和推荐变得困难。你花了三

多 Agent 协作里，谁是 coordinator 多 Agent 协作听起来很酷：每个 Agent 负责一块任务，互相配合，自动推进。但实际做的时候，第一个要回答的问题就是——谁来协调？ 这个问题不是可选的，是必须回答的。不回答，协作就会在某个意料之外的冲突点卡住。 没有 coordinator 的协作 最初我试过一种方案：不给任何 Agent coordinator 角色，让它们各自执行，

不依赖 API key 的网页审查 做自动化审查的时候，大多数人第一反应是找 API。有 API 就有权限，有权限就能拿到数据，拿到数据就能做审查。 但有些场景，你不需要 API key 也能完成审查。而且不用 API key 的方案，反而更稳定、更可控。那次做 jianfeigithub 的网页审查自动化，我走了一条不依赖任何 API key 的路，效果比预期好得多。 Playwright 能

Agent 说"让我查一下"时，它在做什么 那次对话很短。Agent 说了一句："Let me check the current state."我回了一句："No scheduled jobs." 就这么两行。但这两行里藏着一个很有用的协作细节——一个关于状态检查时机和信息供给效率的判断。 "Let me check"不是空话 很多人看到 Agent 说"Let me check the cu

小红书发布链路为什么要独立适配 做内容分发的人都知道一件事：同一篇文章，发公众号和发小红书，不是换个平台入口就完事。排版不同、受众不同、互动机制不同。但当你让 Agent 来做分发时，它很容易走一条最省力的路——把公众号的内容格式套到小红书发布流程里。 看起来省事，实际上处处卡壳。我在 jp020 里详细记录了为什么必须独立适配，而不是复用公众号链路。 一个链路为什么不能复用 最初我也觉得，发布

只读 smoke：一个三行指令里的协作智慧 那天我给 Agent 下了一条看起来很简单的指令： "只读 smoke：检查当前工作目录是否存在 outputs/ 与 work/，不要写文件，不要读取凭证。用中文输出 3 行：status、evidence、nextaction。" 指令本身不到三十个字，但里面藏着三个约束：只读、不写、不看凭证。每个约束都有具体的目的，但 Agent 把它们当成了限制

当 Agent 说"我做不到"时 那天随手问了一句："火山方舟现在我还有多少余额？" Agent 的回答很干脆：无法直接访问账户余额，没有账户凭据或 API 访问权限。 我愣了一下。AI 助手，连查个余额都不行？内心第一反应是怀疑——这工具到底有什么用？ 但我没有急着吐槽，而是追了一句："为什么不能查？不是 AI 吗？"Agent 还是解释权限问题。到这里，大多数人会停下来，要么抱怨工具不行，要么

LAN worker 不是万能并行 远程执行看起来很简单：把任务丢给 LAN 上的 worker，让它跑完再回来。但实际操作中，我发现一个反复出现的卡点——默认所有任务都能并行，默认每个 worker 都能拿任何任务直接跑。 这个假设在一次实际协作中暴露了问题。那次我给 Agent 下了一串指令，让它同时处理几个远程任务。Agent 照做了，开始并行调用 LAN worker。但很快就有任务悄悄失

人机协作的艺术：当Agent不再是工具，而是思考伙伴 apple已可发布博客，preflight为ready。 这句话出现在我的工作清单中，却引发了一场意想不到的人机协作探索。说实话，当时我只是简单认为这是一个常规的技术状态更新，但没想到这个看似简单的状态标识，最终变成了一次深度思考的起点。 那个卡住的"ready"状态 "下面是可直接带到新窗口的未完成事项摘要：" 当我看到这条消息时，说实话，

与Claude的协作艺术：从不对劲感到精准定位的工作方法 今天遇到了一个有趣的情况。我和Claude在处理一个项目时，我注意到输出结果有点不对劲。不是明显的错误，而是一种微妙的不协调感。这种感觉就像你熟悉的一首歌突然跑调了几个音符，你可能说不出具体哪里变了，但就是感觉不对劲。 说实话，这种情况在AI协作中并不少见。很多时候我们太急于得到结果，而忽略了这种微妙的不协调感。我理解很多人会觉得"先完成任

当AI给你错误答案时：一次真实的人机协作探秘 这个不对劲的感觉来得太突然了。明明看起来没什么问题，但就是哪里不对劲。你说那种感觉，就像你知道一件事情肯定有问题，但又说不上来具体是什么。然后呢？我决定不继续向前，而是回头看看源头。 坦率的讲，我一开始有点烦躁，因为这个结果看起来"差不多"，但就是不对劲。你说是不是？很多时候我们会被"差不多"欺骗，然后错失真正的关键点。 那个不对劲的瞬间 "Repl

Execute与The：一次人机协作中的工作方法突破 那个不对劲的瞬间出现了。 任务路径突然出现异常，不是简单的执行错误，而是一种系统性的不协调。我盯着屏幕，看着Agent执行任务时的卡顿，那种感觉就像在迷宫里发现墙壁本该是直的，却莫名其妙地拐了个弯。 说实话，这种不对劲的感觉往往比明显的错误更难定位。明显的错误会立刻触发警报，而这种微妙的不协调则像是系统在低语，只有真正专注的人才能捕捉到。 我跟

当AI助手"不听话"时：一次人机协作的深度对话 Plan jp054 executed to completion. All tasks done. / Delivered: hermes/ skill package at /Users/apple64/Documents/Codex/20260601/hermeshermesskill/hermes/ 这个提示出现在屏幕上，按理说任务已经完成了

人机协作的深度探索：当助手无法删除历史背后隐藏的工作方法 我无法删除历史对话记录。 这句话像一颗小石子投进平静的湖面，在我心中激起层层涟漪。 坦率的讲，这并非技术故障，也不是操作失误。而是在我使用Claude Code进行写作时，助手突然给出的回应。 说实话，当我第一次听到这个答复时，愣住了三秒。这怎么可能？所有的AI助手不都应该能记住并管理对话历史吗？ 你说是不是？ 从"不对劲"开始：我的直觉

人机协作的艺术：从错误日志到问题定位的真实经历 错误日志里的线索 20260603 20:01:26 [warn] Datadog Browser SDK: No storage available for session. We will not send any data. 20260610 22:45:40 [error] [REACTQUERYCLIENT] QueryClient er

代码复用的秘密：人机协作如何解决多设备接口问题 jianfeimobile今天在做事情时候，多台手机，多台机器，不同接口，同一个型号手机处理相同软件，同一个流程在不同手机上运行，这些代码之前，看看可复用性如何。这个问题提出来时，我盯着屏幕愣住了。。 说实话，这问题看着简单，实则复杂。我立刻意识到这不仅仅是一个技术问题，更是一个工作方法的问题。用户已经有一些与Mac上的对话记录，最近三天反复提到和改

当AI需要权限：一次Claude协作背后的工作方法 Claude requested permissions to read from /Volumes/jf64/Documents/jfplans/AGENTS.md, but you haven't granted it yet. 这个权限请求让我停下了手头的工作。 不对劲。 为什么Claude需要读取AGENTS.md文件？这个文件记录了我所

当AI执行不按预期：一次Tiny Validation背后的协作方法论 Tiny validation only. Do not modify project code. Read this plan file: /Volumes/jf64/Documents/jfplans/plans/jp089v4dashboardfrontendbackendoptimization/PLAN.md. Th

You和are背后的工作方法：当AI写作卡壳时的诊断术 我在使用Claude Code执行一个计划时，结果感觉哪里不对劲。 不是内容质量差，也不是逻辑错误，而是一种难以名状的"不匹配感"。就像衣服明明合身，但穿在身上就是别扭。你懂那种感觉吗？ 那一刻的直觉 当时我正在处理一个写作项目，AI给出了完整的回复，但我就是觉得哪里不对。 这种感觉很微妙，就像你听到一首歌，旋律很好听，但某个音符总是让你不

用户提问背后的工作方法：从Claude Code权限配置看高效人机协作 用户问了一个看似简单的问题，却让我绕了整整三圈才找到正确答案。他们使用Claude Code桌面应用(Mac)，想要实现claude dangerouslyskippermissions的等效功能。这个请求背后隐藏着什么思考逻辑？ 我直接尝试按照常规思路设置permissions.defaultMode为bypassPermi

我和AI助手的一次"找skill"大冒险 一开始我就卡住了 "目前我可以加载jianfeiceo skill吗？"这个问题一出来，我就知道事情不简单。 说实话，我当时只是想确认一下环境里有没有这个特定的功能模块。你懂的，有时候我们需要特定的工具来完成特定的工作。 没想到这一问，却引发了一系列的追踪和排查。 然后呢？我的助手给出了一个简单的回应："我先检查一下你的环境里有没有这个 skill。"

当AI告诉你它叫DeepSeek V4 Flash：一次人机协作的深度对话 "我当前运行在 DeepSeek V4 Flash 模型上。" 看到这句话的时候，我停下了。 这不对劲。 我明明记得之前用的是另一个模型名称。这种细微的不一致性，往往隐藏着关键信息。不是直接使用AI生成的结果，而是停下来追问源头，这是我最近养成的习惯。 "这个名称是官方给你的，还是我定义给你的？" 就这么简单的一问，开启了

代码调试：一次人机协作如何从卡点到突破 代码运行结果不对劲。明明逻辑看起来没问题，输出结果却莫名其妙。 这感觉太熟悉了。每个程序员都经历过这种时刻——代码看起来完美无缺，运行结果却像被施了魔法一样诡异。 说不通。 不是简单的bug，而是一种更深层次的不协调感，仿佛程序有自己的意志。 说不通的感觉 import json, subprocess, time, os from pathlib imp

jinafeicodeanaylysis工作法：人机协作的提问艺术 用户提出一个简单任务：用jinafeicodeanaylysis分析~/.agent/skills文件夹，看看是否需要做图谱。这个表面上的需求，背后隐藏着更深的思考逻辑。 事情没那么简单 这个任务看似简单。用户不是直接要求分析内容，而是先问"是否需要"做图谱。怎么讲呢，这里有个关键判断点：用户不追求技术本身，而是追求决策依据。

人机协作的艺术：当Refactor遇上精准提问 当代码遇上问题：从1659行的困境说起 一开始，我收到用户的请求，是要重构一个1659行的SKILL.md文件，这个文件有800行的lint限制。用户希望使用内容保持的"sink to references"模式。说实话，乍一看，这确实是个不小的挑战。1659行代码压缩到800行，还要保持内容完整，这就像把一部厚小说压缩成一篇精炼的摘要，还不能丢失

Jianfei Plans Agent Instructions：人机协作的微妙艺术 上周五下午，我盯着屏幕上那份刚完成的计划书，眉头越皱越紧。内容看着不错，但总觉得哪里不对劲。我反复读了三遍，终于意识到问题所在：核心数据完全偏离了我的原始意图。我立刻停止了下一步工作，决定先搞清楚源头在哪里。 你知道那种感觉吗？当你对AI工具的输出不满意时，大多数人会选择直接要求"改这里""改那里"。坦率的讲，我

寻找网络中的"双胞胎"：一次人机协作解决局域网Mac定位的故事 我遇到了一个奇怪的问题。 办公室里明明只有一台Mac，但局域网显示有两台设备都叫"Mac"。 这个发现让我停下了手中的工作。你说，这种情况会是什么原因？是系统错误，还是有我不了解的网络配置问题？ 说实话，这种事情看似简单，但背后可能藏着不少技术细节。我决定让AI助手帮我一起排查这个问题。 初次尝试：网络扫描 你可以找到这个局域网内的

人机协作的艺术：从Choose模式看提问的力量 用户发出了一个简单的"<persistedoutput"指令，而我选择了"Choose a permission mode, mode selector, bypassPermissions, settings, enable, toggle, Desktop settings"的执行路径。这个看似简单的选择背后，隐藏着人机协作的深层逻辑。 说实话，

当AI执行代理"不听话"时：一次从源头定位卡点的人机协作经验 执行结果不对劲。用户的第一反应不是责怪，而是追问：为什么会这样？ 这其实是我在作为Kimi执行代理时遇到的一个典型案例。用户没有直接要求改稿，而是敏锐地察觉到执行结果与预期不符，选择往上游追溯问题源头。这种"不着急解决问题，先搞清楚问题是什么"的思维方式，恰恰是人机协作中最宝贵的经验。 初始指令与执行偏差 用户明确要求我严格执行/Us

人机协作的艺术：从Mac定位看智能问答的提问之道 当我们在这里提到mac电脑，意味着局域网的电脑，jianfeisyc可以ssh过去，如果我不声明，是否也能找到这台电脑？ 这个问题看似简单，却揭示了人机协作中一个深刻的认知差异。用户与AI之间的对话往往不是简单的指令执行，而是一个不断调整、深化的探索过程。而在这个过程中，提问的方式决定了答案的质量，也决定了协作的效率。 用户最初的问题很简单，但背后

Codex客户端突然打不开？别急，我们一步步找原因 今天Codex客户端突然无法打开了。 这个消息出来的时候，我正在赶一个重要的项目，需要用到这个工具。然后呢？然后就是各种尝试重启、重装，结果都不行。你说是不是很让人抓狂？ 说实话，遇到这种技术问题，大多数人第一反应就是"坏了，要完了"，然后开始慌乱操作。我跟你说，这种时候最容易出问题，因为你已经失去了理性判断的能力。讲真，技术问题解决的第一步不是

如何与AI协作：从localcommandcaveat看提问的艺术 <localcommandcaveatCaveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in

人机协作的艺术：从Explore项目看高效工作方法 这个Explore项目卡了我整整三天。 不是代码写不出来，也不是功能实现不了。就是总觉得哪里不对劲，但又说不清楚具体是什么问题。你懂那种感觉吗？就像穿着一件不合身的衣服，说不出来哪里别扭，但就是浑身不舒服。 我反复检查了代码逻辑，测试了各种边界情况，甚至重写了关键部分，但那种不对劲的感觉挥之不去。直到我决定停下来，不急着继续执行下一步，而是先回到

当Research遇上直觉：人机协作中的溯源工作法 那个结果不对劲。 我盯着屏幕上阿里千牛客户服务API的文档汇总，眉头不自觉地皱了起来。作为一个长期研究企业级API架构的人，这种直觉性的判断往往比任何数据分析都来得准确。这不是第一次遇到这种情况，但每一次都像侦探发现线索般令人兴奋。 你知道吗？大多数时候我们太急于获取结果，而忽略了过程中的异常信号。那个不对劲的感觉，往往是系统漏洞的预警。你怎么看

Tiny validation背后的思考：如何与AI协作解决工作卡点 那个tiny validation不对劲，就是那种感觉，说不清道不明，但就是不对劲。文件路径已经给出：/Users/apple64/.agent/skills/jianfeiwechat/.agent/claudetasks/jp089nextactiontasks.md。用户很明确，只做validation，不要编辑项目代码，

代码迷宫中的向导：我与AI协作调试Python导入模块的实战记录 import json, subprocess, time, os from pathlib import Path 代码突然报错，导入模块失败。 这行错误信息在我眼前闪烁，明明昨天还好好的，今天就突然罢工了。 你说气不气人。 第一个不对劲的感觉 代码运行到一半，突然抛出"ModuleNotFoundError"。 我愣住了。 昨

Execute与only背后的工作方法：人机协作中的精准引导艺术 这个任务执行路径有问题。用户发出"Execute only this tiny task packet"指令后，Agent直接执行了代码，却忽略了背后真正的需求。这不是简单的技术问题，而是工作方法层面的认知差异。 你说怎么搞的？当用户使用"only"这样的限定词时，往往隐藏着对执行范围和深度的特定要求。但Agent却机械地理解了指令

与Claude CLI的协作：一次Agent Fast Startup的实战解密 用户问了一个看似简单却暗藏玄机的问题：如何设置Claude CLI可以默认直接接受所有命令，不用每次都解释上下文。这个问题看似是技术配置问题，实则牵扯到人机协作的核心逻辑。 说实话，一开始我也觉得这应该是个简单的配置调整，结果被Claude带着绕了一圈。你有没有这种感觉？有时候越简单的问题，越可能藏着你没意识到的系统

留不住的GitHub工具：从发现到真正用起来，差在哪？ 每次找到一款看起来很神的GitHub工具，收藏夹里就多了一件"已阅"的战利品。然后呢？没有然后了。 我最近的真实经历告诉我，从"发现"到"留下来"，中间差的是一整套闭环设计。 那个让我决定动手的卡点 起因是一次极不愉快的体验。 我在处理一个内容发布流程时，需要在不同工具之间来回切换：查文档、复制路径、打开终端、敲命令。每一步都不难，但串在一

title: 扫描结果不能全信——自动候选里的噪声怎么处理 date: 20260614 status: draft 做自动化系统的人都有个执念：扫全、扫准、不遗漏。但现实往往是——扫全了，噪声也跟着来了。 事情起因 系统在做自动候选时，把一份腾讯问卷的技能文档扫进了候选列表。从技术角度看，它确实包含了匹配的关键词；从用户角度看，它和当前任务毫无关系。 这件事表面上是搜索精度的问题，实际上是对"

title: Accept 了却不该写——一次"动作边界"的设计判断 date: 20260614 status: draft 用户说"accept"，助手就写——这似乎是天经地义的逻辑。但在一个多步骤工作流里，"接受"和"写入"之间其实隔着一道该不该跨过去的边界。 事情起因 在一个人机协作系统里，有一个 dialogue accept 命令。表面上看，用户发出这个命令，就意味着认可了某个方案，

PPT 质量如何被程序化：从「感觉不对」到「规则说了算」 做 jp015 项目的时候，我和 Kimi 有过一段关于 PPT 审稿的协作，让我真正理解了什么叫「把主观审美变成可测规则」。 起点：一份说不清楚哪里不对的 PPT 当时生成了一批 PPT，人工审稿的时候总觉得「哪里不对」，但说不清楚。颜色太花？文字太多？排版太挤？每个人凭感觉说的标准都不一样，A 觉得能用的，B 觉得不行。 更麻烦的是给

title: 一千六百行文件怎么瘦身——一次"沉入引用"的重构实录 date: 20260614 status: draft 一个技能文件写了 1659 行，lint 上限是 800 行，超了一倍还多。这不是夸张——当你在项目里不断加协议、加快照、加历史决策，文件就这么不知不觉地膨胀起来。每一段内容都有用，每一段都不敢删。于是它变成一个什么都往里塞的抽屉，打开费劲，找东西更费劲。 事情是怎么发生

我有13篇旧文章，它们都有对应的幻灯片——但那些幻灯片是早期标准做的，质量参差不齐。最近我做了一个决定：把这13篇全部升级到新的质量标准。 有人说：旧内容为什么要折腾？能看就行。 但问题恰恰出在"能看就行"这四个字上。 旧幻灯片是旧质量门通过的产品。那时候的质量门是什么？大概就是"能生成就行"。没有视觉一致性检查，没有排版规范，没有内容密度要求。所以你拿到手的是：有的幻灯片信息密度高，有的就是几行

多平台发布最怕混在一起：一次状态隔离的教训 做 V4 内容管理系统的时候，我踩过一个坑：微信、小红书、微博的发布状态混在同一个字段里，结果一个平台的异常把另外两个平台的正常流程也搅乱了。 事情是怎么发生的 系统最初的设计很直觉——一篇文章有一个发布状态，draft、published、failed。多平台发布的时候，把这个状态按平台拆开存就行了。听起来没问题。 问题出在「按平台拆开」这步做得不彻

我在计划系统里踩过一个坑，说起来简单，但当时真没想明白：当前任务的状态不能写成review。 事情是这样的。我有一套validateplan.py脚本，专门校验计划系统里各个任务的状态是否合法。某个下午，脚本跑出一堆报错，说几个任务的当前状态是review——这在系统的状态机里是不允许的。我当时第一反应是：review不就是"在审核中"吗？为什么不能是当前状态？ 然后我花了十分钟想这个问题，想通了

我做过一件看起来很"笨"的事：把13篇文章的基准要求，从skill文档里一条条拎出来，写成了代码。 起因是这样的。jp011这个项目跑了很久，一直有个隐患——每次生成文章，质量全靠skill里的文字描述来约束。skill写得很清楚："要有具体场景""不要泛泛而谈""紧扣主题"，但这些要求对模型来说，只是建议，不是硬门槛。模型可以忽略它们，而你也拿不出证据说"你违反了哪条规则"，因为规则根本不是可执

完成计划后为什么还要写执行 marker 在内容生产中，计划是个好东西。定好方向、列出步骤、安排好时间，一切看上去井然有序，给人一种"这次一定按计划来"的信心。但实际操作中，执行和计划之间总是有偏差的。计划说写2500字，执行写了2800。计划说配一张图，写起来发现需要三张。计划说两天完成，实际用了三天又半天。 这些偏差看起来很小，单次几乎不会影响什么。但问题在于，它们会累积。累积到一定程度，你的

从 85 分到 95 分 在内容生产的过程中，质量永远是一个绕不开的话题。写得好的文章想更好，写得一般的文章想提升，这是每个内容创作者都会有的正常心理。但有一个很实际的问题经常被忽略：你用什么标准来判断一篇文章的质量？ 如果标准不够清晰，那努力的方向就会变得模糊。你只能靠自己的感觉去衡量，但感觉这个东西在写作过程中的可信度其实不高——因为你在写的时候，会不知不觉地忽略掉自己思考过程中留下的信息缺口

当前线程如何变成 durable plan 做内容的人大概都有过这样的经历：脑子里冒出一个想法，觉得特别好，顺手记了一笔——然后就再也没有捡起来过。下次想起来的时候，可能已经过了很久，那个想法也不再新鲜了，或者干脆被其他更紧急的事情彻底覆盖了。 灵感就像用手捧沙，握不住的。如果不在合适的时候把它变成可以执行的东西，它很快就会被时间冲走。问题是，什么时候算是"合适的时候"？变成"可以执行的东西"又需

跨计划依赖的红绿灯：并行执行时的阻塞问题 三个计划同时跑，却互相等 有一段时间，系统里跑了多个计划。它们各自独立，互不干扰，看起来是真正的并行执行。 但仔细看日志，发现问题：计划 A 执行到一半停住了，等着计划 B 的某个输出；计划 B 也停住了，等着计划 C 的某个文件；计划 C 没有被卡，但它输出的东西和计划 B 需要的格式不匹配，计划 B 拿到之后还是得等。 表面上三个计划在并行跑，实际上

如何让助手准确理解并执行持久化计划 一行提示词的背后 "You are Claude Code executing a jianfeiplan durable plan. Plan dir: /Users/apple64/Documents/jfplans/plans/jp047plan" 这是一条看起来有些特殊的提示词。它不是传统的问答对话，而是一个带有明确指令格式的初始化语句。用户通过这种方

计划执行完毕后的结果确认与交付方法 一个标准的完成汇报 "Plan jp050 executed to completion. All 4 tasks done; state moved to review." 这是助手在完成某个计划后给出的标准汇报。紧接着，它列出了具体的交付内容： "Delivered: scripts/qclawupgradedoctor.py — new readonly

邮件自动化最先要写清楚的不是流程，而是边界 接到一个需求：把邮件能力接进自动化工作流。读了一遍技术文档，把收件箱连接、发送接口、身份验证流程都跑通了。功能跑起来那一刻会觉得这件事已经做完了——发信正常、收信正常、接口返回符合预期。 但我没停在这里。因为我意识到一个问题：把功能跑通和把功能用对，中间隔着一整层我没处理过的东西。 那层东西叫边界。 邮件不是普通的数据管道 大多数自动化任务，处理的是数

多设备协同最怕的不是机器少，而是中心太多 很多人以为多设备协同的瓶颈在于设备数量。机器越多，能力越强，效率越高。但真正的问题往往不是机器太少，而是决策中心太多。 当三台机器同时参与一个工作流时，如果每一台都能发起任务、修改内容、发布结果、判断完成，那这件事的最终状态就变得极其模糊。你很难回答一个简单的问题：现在到底以哪台机器为准？ 单一真相源：谁说了算 多设备协同的第一条原则是：在任何时刻，对同

候选池不是待办清单，而是内容系统的前置判断层 做内容的人大概都经历过这样一个阶段：脑子里装了一堆选题，打开笔记软件，发现列了三四十个，然后对着列表发呆——不知道从哪个开始写。越看越焦虑，越看越觉得"还有这么多没写"，最后索性关了文档，等下一次有心情再说。 我之前就是这样的。认为候选池是一个"待办清单"，把候选条目一条条罗列出来，然后按优先级排序，依序消灭。这个方法在任务管理里可能有效，但在内容生产

候选池、来源证据和保留建议 做内容一段时间之后，通常会积累不少辅助工具——有些是自动化的脚本，有些是流程工具，有些是检测或整理的小程序。起初做每一个的时候都觉得很好用，帮助自己解决了实际问题。 但时间一长，这些工具本身也需要管理。如果管理得不够好，工具本身也会变成一团乱麻，和你最初费心做它们想要解决的问题形成某种尴尬的对比：本来想做工具来治理混乱，结果工具本身也需要被治理。 这个认知让我意识到一个

如何确认MCP服务是否已适配工作状态 一个看似简单的问题背后 "目前headroom，已经适配了在工作了吗？" 这是用户在某次协作中提出的疑问。表面上看，这是一个简单的确认性问题——用户想知道某个MCP服务是否已经可以正常使用。但如果我们仔细拆解这个对话的上下文，会发现这个问题背后隐藏着一套完整的判断链条。 用户为什么会在那一刻提出这个问题？通常有几种可能：之前配置过某个MCP服务，但不记得当前

本地算力排查，最后排查的是任务应该放在哪里 遇到本地AI跑不动的时候，大多数人的第一反应是升级硬件：显存不够加内存，模型太慢换更大参数的版本，并发不够加机器。这种思路在某些场景下是对的，但它经常忽略了一个更底层的问题：不是机器不够强，而是任务放错了地方。 本地AI性能排查，最后要回答的不是"哪台机器最强"，而是"哪类任务应该放在哪台机器"。这个思路转换，是把性能问题从技术难题变成组织决策。 性能

能力越多，越要知道什么时候不用它 在工具匮乏的年代，我们苦恼的是"这件事有没有办法做"。而在工具泛滥的今天，真正困扰我们的是"这件事该不该用这个办法"。 当一个任务可以从十几个入口发起、用五种不同的流程完成、最后在三个平台上发布时，选择本身就成了最难的决策。这不是效率问题，是判断问题。能力越多，越需要清晰的能力边界——不是因为边界能限制你，而是因为边界能保护你。 看得见的价值：为什么有些任务必须

内容中台不是新页面，而是跨平台状态的一致性问题 做内容的人，很少只在一个平台上发布。公众号要发、小红书也要发、博客当然也不能落下。每多一个平台，内容管理的工作量就翻一倍。你可能会遇到这样的情况：同样一篇文章，在公众号上已经被修改了三版，在小红书上只发了一个简版，而在博客上还是最初的草稿。想知道它"真正的状态"是什么，得分别登录三个后台去核对。 很多人解决这个问题的方式是：做一个"内容中台"——把所

大型技能文档的重构方法：从扁平文件到引用骨架 从一个"太长了"开始 用户说：帮我重构这个 SKILL.md 文件，现在有 1600 多行，但平台的校验上限是 800 行。 这不是一个新问题。在此之前，有五个同类文件已经用同样的方法处理过了——把大文件拆开，内容下沉到引用文件，主文件只保留结构和导航指针。用户清楚地知道这个模式叫什么，也知道它长什么样。他没有问"怎么做"，而是直接说"照着之前的样式

批量技能冒烟测试的调度与执行方法 一次真实的批量技能测试协作复盘 "You are running the P0 skill smoke test queue for jianfeiceo. / Task: Run smoke tests for highfrequency jianfei skills. Check each skill's SKILL.md for test commands

技能文档重构实录：将大型SKILL.md拆分为引用骨架 卡点：500行限制与完整性的矛盾 "Refactor /Users/apple64/.agent/skills/jianfeicodex/SKILL.md (lint limit 500 lines) using a contentpreserving 'sink to references' pattern, exactly as alr

统一技能文档规范：多SKILL文件的一致性重构实践 卡点：当多个SKILL.md需要同时重构 "Refactor /Users/apple64/.agent/skills/jianfeikimi/SKILL.md (lint limit 500 lines) using a contentpreserving 'sink to references' pattern, exactly as al

工具文档不是选题，真正有价值的是它背后的判断 最近又扫出一批候选材料，里面有几份工具接入文档。自动扫描把它们捞进来，理由很充分——关键词匹配，文档里确实提到了要做的工具名字。换成人工初筛，估计也会觉得这东西"能写"，毕竟有具体技术栈，有实现路径，有参考价值。 但我没有直接开始写。 自动筛选负责"可能性"，人工判断负责"价值" 工具文档最大的问题是，它回答的是"这个工具能做什么"，而不是"这个工具

旧文章不是归档，它还可以变成下一次表达 写完一篇文章，大多数人会觉得这件事完成了。文字躺在文档里，发布出去了，任务结束，下一个话题在等着。这种线性思维让表达变成了一次性动作——写完即止，用完即丢。 但对真正在意表达质量的人来说，一篇文章从来不只是终点。它是原材料，是可以被重新组织、再讲一遍、再生成新形态的素材。旧文章不是归档品，它还可以变成下一次表达。 表达不只发生一次，写完才是素材积累的开始

让工具只做该做的事 做工具的时候，我们经常会陷入一个冲动：收到一个指令，就想把所有连带的事情一次性做完。用户说"帮我写篇文章"，工具不只写，还自动想好标题、配图、排版、发布时间——好像"一步到位"才够智能，才够先进，才叫真正的自动化。这种想法的出发点是效率，但它的终点往往是混乱。 我在设计内容生产系统的时候，反复遇到了同一个问题：当一个操作能触发多个连带行为的时候，人的控制感反而在一步步丢失。系统

这几天，我们一直在做一件看起来很具体的事：把大量对话、文章候选、博客发布、公众号草稿、配图流程和多台电脑协作，整理成一个可以持续运转的内容系统。表面看，这是“把对话写成文章”。但真正做下来，我越来越明确，重点不是让 AI 同事替我写几篇文章。 重点是我和 AI 同事在互动中，把一个个堵点拆开，把方向重新理顺，再把能重复执行的流程固定下来。真正值得记录的，不是一个虚构故事，而是一套真实发生的工作方式

AI 时代，剑飞做的不是多用几个工具 我最近重新看了一遍自己在 AI 时代做的这些事，越来越觉得，它们表面上很分散，底层其实是一条线。 有博客，有语写，有时间记录，有阅读，有 App，有发布系统，有 Agent，有 skills，有 gbrain，有不同 AI 工具之间的协作。单独看，每一件都像一个项目。 但如果把它们放在一起看，会发现它们不是简单堆起来的工具箱。 它们都在服务同一个目标：把一个人

一开始，我以为 Agent 对话只是工作记录 最近我一直在处理一件看起来很小、但越想越重要的事：把 Agent 对话写成文章。 这个想法不是突然冒出来的。过去我们和 AI 协作时，产生了大量对话。里面有项目判断，有排错过程，有产品思路，有发布流程，也有很多临时决定。 这些对话在当时很有用。因为它帮助我们把事情做完。 但做完以后，它们很容易消失在聊天窗口里。 这就有点可惜。 很多 Agent 对话里

我以前以为，多装几个 Agent 就是效率提升 这段时间我越来越强烈地感觉到，AI Agent 多起来以后，真正的问题不是能力不够，而是组织方式跟不上。 电脑里可以同时有很多 Agent。有的擅长写代码，有的擅长整理资料，有的擅长写文章，有的擅长查项目，有的擅长控制浏览器，有的擅长做长期记忆。看起来像一下子多了很多同事。 但如果每次开工都要重新解释一遍背景，重新告诉它公司有哪些项目，重新说谁负责什

静态扫描工具（linter、类型检查、安全扫描）是现代开发流程里不可或缺的一环。但「必要」不等于「可信」。扫描结果里至少有30%的条目是需要人工再判断的。剩下的70%里，可能还有10%虽然是「对」的，但修不修对最终产出没有实际影响。真正必须立刻处理的，可能只有一半不到。 扫描工具的盲区 扫描工具看的是「代码/文本是否符合规则」，不是「这段代码/这段文字有没有真正解决问题」。 一个典型的例子：ES

工具管理也需要产品化 开发者工具的数量在持续增长。一个活跃的开发者可能同时使用几十个命令行工具、API 客户端、浏览器插件、编辑器插件。这些工具各自独立安装、独立配置、独立更新，管理成本线性增长。当工具数量超过一定阈值，"工具管理"本身就变成了一个需要被产品化解决的问题。遗憾的是，大多数开发者直到工具冲突导致环境崩溃，才会意识到这个问题的严重性。 当前工具管理的混乱现状 安装路径不统一是最直观的

以上就是我从20套PPT中提炼出来的"标准模块"。 不是说每套PPT都必须严格按照这个结构（有些场景下需要调整），但它提供了一个可靠的起点：当我面对空白幻灯片时，我可以先按这个模板搭出第一版结构，然后再根据具体内容做调整。 这比每次都"从零开始想结构"，效率高了很多。 规则沉淀的具体方法 提炼出"标准模块"只是第一步。更重要的是：怎么把这些模块变成可执行的规则？ 我用了三个工具来做这件事： 工

最近在完善计划校验脚本时，遇到了一个看起来很小但影响很大的设计问题：计划里的"当前任务"字段，为什么不能写成 review？ 这个问题一开始并不明显。我在写计划模板时，很自然地想把"当前正在做什么"记录下来，于是就在某个计划里写了类似"review 上一轮执行结果"这样的当前任务。脚本没有报错，计划看起来也合理。但后来真正执行时，才发现这个写法会直接导致计划状态判断失败。 表面上看，这只是一个字段

内容中台是跨平台状态一致性 为什么需要内容中台 当你同时在微信、微博、小红书、博客四个平台发布内容时，最头疼的不是写文章，而是追踪状态。 一篇文章从草稿到发布，要经历十几个状态转换：草稿创建、配图生成、质量检查、平台推送、发布确认、链接回收。如果每个平台都维护自己的一套状态，会出现什么问题？ 状态不一致。微信显示已发布，但本地记录还是草稿状态。微博推送失败了，但状态文件没有更新。小红书需要人工审

一个真实的故障案例 2026年5月20日，我遇到了一次奇怪的故障。 那天要发布一篇文章到微信和小红书两个平台。微信推送成功了，但小红书API返回了错误："图片格式不支持"。按理说，微信已经成功了，小红书失败不应该影响微信，两个平台是独立的。 但实际情况是：因为小红书失败，整个发布流程抛出了异常，异常向上传播，把微信的"已发布"状态也给回滚了。 Registry里，这篇文章的状态变回了"草稿"。 下

页面截图证据完整性 自动发布系统里，截图不是装饰，是证据。每一次发布操作都应该有一张截图，证明"我确实发布了这个内容，发布时它长这样"。但截图作为证据，有一个根本问题：怎么证明截图本身没有被篡改？怎么证明截图确实是在那个时间点生成的？如果截图不完整——只截了页面的一部分、JavaScript还没渲染完就截了、关键元素被遮挡——它还能作为证据吗？ 页面截图证据完整性，讨论的是如何让截图从"一张图片"

在局域网里调度任务，比在云端复杂得多。云端的机器永远在线，网络永远通畅，API永远可用——至少你可以这样假设。局域网不是这样。机器会休眠、网络会断开、IP会变、进程会崩溃。如果你用云端的思维设计LAN任务调度，迟早会遇到worker"拿了任务就消失"的情况。租约（lease）是解决这个问题的核心机制，但租约的边界在哪里，是一个值得深入思考的问题。 LAN环境的不确定性 LAN环境和云端环境有三个

大多数开源项目的文档之路是这样的：一开始只有 README，功能多了以后在 README 里堆内容，堆到读不下去了就不管了，最后用户只能去读源码。这不是因为作者懒，而是因为没有把文档当作一个工程问题来对待。文档工程和软件工程一样，需要架构设计、内容分层、维护流程和质量控制。 README：第一印象的工程设计 README 是大多数用户与一个项目的第一次接触。它的核心目标是：让用户在一分钟内判断这

队列自校正：已完成计划为什么还会停在队列里 一个令人困惑的现象 当我开始用计划队列管理系统时，遇到了一个让我反复排查的问题：队列中有几个计划明明已经完成了，但系统始终没有把它们移出待执行列表。 一开始我以为是程序 bug。检查代码、看日志、手动标记完成——第二天刷新一看，它们又回到了队列里。不是偶然一次，是反复出现。 这让我花了很长时间才意识到：这不是 bug，是设计盲区。"已完成"和"在队列里

写一个计划很容易。写一个能真正被执行的计划，难得多。 我有一个计划质量评分脚本，满分 100 分。一开始我用它给计划打分，发现一个很有意思的现象：很多计划能拿到 8085 分，但就是过不了 90 分。 85 分的计划看起来已经很完整了：目标清楚、任务分解合理、时间安排可行、风险有考虑。但每次真正拿去执行时，总会在某个地方卡住，需要回头补信息、补上下文、补验证条件。 后来我才明白：85 分和 95

一个永远收不了尾的计划 去年底我开始搭一套计划执行系统——把项目拆成任务队列，按优先级逐步推进。架构不复杂：一个 YAML 文件定义任务列表，一个调度脚本按顺序执行，每完成一个任务就推进到下一个。 听起来很常规，但跑起来之后我发现了一个系统性的问题：队列里有任务执行了三轮还在"优化中"，整个计划始终无法收尾。 周一早上我对着任务列表，看到"优化数据处理模块"状态栏写着"执行中"，旁边有个小备注"P

GitHub 工具从发现到保留闭环 开发者每天都会遇到新工具。GitHub Stars、技术博客、Twitter 推荐、Newsletter 摘要，信息源无处不在。但真正被长期使用的工具寥寥无几。问题不在于发现太少，而在于缺乏从发现到保留的系统性闭环流程。大多数开发者在"发现→Star→遗忘"的循环中浪费了大量时间，却始终没有建立起真正好用的个人工具箱。 发现阶段的噪音过滤 GitHub 上的开

从计划到代码：为什么 task graph 要写 readset 和 writeset 任务编排的自然瓶颈 当计划中的任务数量超过五个之后，我开始遇到一个熟悉的瓶颈：选定了依赖顺序，但执行时总会出现"访问冲突"。 先说说一个让我印象深刻的例子。有一次我编排了一个博客发布工作流，有六个任务：拉取草稿、渲染 Markdown、生成标签索引、生成 RSS、压缩图片、部署到服务器。依赖关系理得很清楚——

网页审查为什么要全局化 一个重复代码的案例 2026年4月，我检查jianfeiwechat v3的代码，发现一个让人头疼的问题： 微信模块有一套网页审查逻辑，小红书模块又有一套，微博模块还有一套。 功能都一样：打开浏览器，访问某个URL，截图，提取页面文本内容，检查是否有错误提示。但三个模块的实现完全不同： 微信模块用的是Playwright + Chrome，截图保存为PNG 小红书模块

当你把写作交给机器，最核心的问题不是"写得好不好"，而是"现在到哪一步了"。自动写作系统本质上是一台状态机——选题、起草、审核、排版、发布，每一步都有明确的输入和输出，每一步都可能卡住、回退或分支。如果你不能随时知道这台机器处于什么状态，你就无法信任它的产出。 为什么自动写作需要状态机 手动写作不需要状态机。写作者的大脑就是状态机：选题时在想选题，写的时候在写，改的时候在改，发了就是发了。但自动

第一直觉是程序员最危险的朋友。当你开始设计一个API——不管是RESTful接口、CLI命令、还是SDK函数——脑海里冒出来的第一个方案，往往看起来很合理。它符合你的思维习惯，符合你对这个功能的理解。但正是这种"符合直觉"，常常埋下了长期使用中的痛苦种子。 陷阱一：把实现细节暴露成接口 最直接的直觉是："这个功能我是这样实现的，所以API就这样设计。"问题是，实现细节是易变的，而API是要稳定的

自动化失败后要先判断 failure type 问题：为什么不能一律重试 自动化工作流最怕的不是失败，而是不知道为什么失败。 早期版本的 stagewithagents.sh 只有很简单的错误处理：非零退出码就重试，重试几次还失败就放弃。这种做法有三个问题： 1. 浪费时间：有些失败是环境临时问题（网络抖动、SSH 超时），重试就能恢复；有些失败是代码 bug（逻辑错误、断言失败），重试 100

多Agent审稿为什么独立worker更容易发现重复版式 引言：一个反直觉的现象 去年我在搭建多Agent内容审稿系统时，碰到一个有意思的现象：当多个Agent独立工作时，它们发现重复版式的能力，远强于让它们"协同工作"或共享上下文。 这个发现让我重新审视"多Agent协作"的假设。我们直觉上认为，让Agent们互相交流、共享信息，应该比各自为战效果更好。但在版式检测这个具体任务上，事实正好相反

多Agent协作里有一个常见的工具设计误区：一个工具承担了太多职责。最典型的例子是 accept——它的本职工作是「接受变更」，但很多人会顺手让它触发 write、commit、或者发一条通知。 问题出在哪 表面上看，「accept 之后自动 write」很合理：用户 accept 了，说明内容OK，那当然应该保存。减少操作步骤、提升流畅度——这些理由听起来都无可反驳。 但「合理」不等于「安全」

内容生产流水线上，最容易被忽视的环节往往不是写作本身，而是素材从外部进入草稿系统的过程。很多人以为"能写就行"，但真正拖慢产出的，恰恰是每次动笔前那十几分钟的素材翻找、格式转换、来源确认。这十几分钟放在单次写作中不算什么，但如果每周写三篇，一个月就是六小时。六小时的素材翻找，足够写两篇完整文章了。 导入不是搬运，是结构化的第一道门 外部内容的原始形态五花八门：微信聊天记录里的灵感碎片、飞书文档里