思想随笔

多平台发布为何需要隔离 去年帮一个内容团队做季度数据复盘时，发现了一个让所有人都困惑的现象：同一篇文章发布在微信公众号上，平均阅读量能达到五万左右，互动率稳定在百分之三上下，留言区经常出现高质量的讨论；但同一个内容同步发到小红书，数据惨淡到连基础曝光都难以突破三位数，点赞和收藏的比例严重失调——收藏不少但点赞极少，说明内容有价值但缺乏即时的视觉冲击力；发到微博呢，情况稍好一些，能蹭到一些热点流量带

问 headroom 是否在工作，其实是在问适配 “目前 headroom，已经适配了在工作了吗？”这句话看起来有点口语，甚至带着停顿，但它是很真实的人机协作问题。助手的回应是：“我来检查一下 headroom MCP 服务器当前的运行状态。”从表面看，这个回答合理；从协作角度看，它也暴露了一个常见分岔：用户问的是状态，还是适配？ 素材里没有给出完整检查结果，所以不能编造 headroom 到底运

微信排版：风格是内容呈现的体现 有一次，一位用户把一篇刚写好的公众号文章发给我，语气里带着一点不确定："排版感觉不太对，但我说不清楚哪里有问题。"这种描述听起来模糊，但对我来说是个好信号——至少他意识到有问题了，而不是直接发出去等读者来反馈。很多公众号作者缺乏这种自我审查意识，直到后台数据下跌才后知后觉。 我的第一反应是好的。打算从技术层面入手：调整正文字号、优化段落间距、统一下颜色方案、把该加粗

页面截图的真相与陷阱 做数字化协作的人，大概都经历过这种事：AI助手给你发了一张页面截图，看起来完美无缺，布局整齐、元素到位、色调统一、间距舒适。你点头通过了，心想这回没问题，上线应该稳了。结果真正使用这个页面的时候，发现有些地方布局错位了，有些信息莫名其妙消失了，有些模块在不同设备上表现完全不同。 你开始怀疑：是助手做错了？还是我验收的时候漏了什么？ 答案往往是后者。但问题的根源，比"漏看"要复

同一个主题，为什么要先匹配账号画像 有些选题本身没有错，发出去却总是不对味。问题不一定在观点，也不一定在标题，而可能在更前面：它还没有先匹配账号画像。素材里关于“账号画像选题”的证据很少，只有“account topic suggestions”和一句判断：同一个主题为什么要先匹配公众号。但这句话足够展开一次很实用的人机协作复盘。 当用户拿一个主题来问 Agent，最常见的路径是让它直接生成标题、

旧文的新生之旅 整理旧文章时，最容易产生一种宽容心态：反正是旧内容，差不多能用就行了。可当13篇旧文章要一起升级成幻灯片格式时，这种宽容会立刻变成问题。单篇看只是风格差一点，放在一起就会显得节奏不齐、标准不一，看起来像是来自完全不同团队的作品——有的文字密密麻麻，有的只有稀疏几行；有的配色偏蓝绿冷调，有的则是一片暖色大杂烩；有的页面信息密度极高恨不得把所有内容都塞进去，有的又单薄得像提纲而缺乏实质

人机协作解目录之谜 用 AI 辅助工作久了，有时候会遇到一些看似简单的技术问题，却藏着值得反复咀嚼的协作智慧。最近一段关于访问受限目录的对话，让我重新理解了"提问方式"这件事的价值——原来在一个人机协作的环境里，最重要的能力不是知道答案，而是知道该问什么问题。 从一个看似简单的问题开始 我像往常一样向 Agent 提出需求："如果我要能打开 ~/.agent/skills 作为工作目录，应该怎么

GitHub工具的闭环管理艺术 我一直以为自己是个爱折腾的人。GitHub上收藏了上百个项目，有效率工具、有自动化脚本、有各种前沿框架。每次刷到看起来有用的东西，手指就自动点下Star，心里还美滋滋地想：收藏了就是学会了，留着以后肯定用得上。 结果呢？这些Star躺在收藏夹里，像一柜子落灰的书，再也没打开过。 为什么收藏的工具用不起来 有一天我实在忍不了了，主动去问AI助手："为什么我收藏了这么

与AI助手的对话背后 你有没有想过，当你向AI助手提出一个问题，它的回答是怎么"组装"出来的？ 我很长一段时间没有想过这个问题。在最初的认知里，AI就是一个"问答机器"——输入问题，输出答案，中间发生了什么，不需要知道，也不需要关心。直到有一次，我开始追问它本身的工作过程，发现这比它给我的任何答案都更有价值。 一次意外的追问 事情是这样的。有一次我向AI助手提出一个比较复杂的问题，它给出了一个很

为什么 task graph 要写 readset 和 writeset 作为一个长期和 Agent 协作写代码的人，我踩过一个坑：让 Agent 改一个功能，它直接跑起来，结果改错了、改漏了、甚至覆盖了不该碰的文件。不是 Agent 能力不够，是我没说清"哪些文件你能读、哪些文件你能写"。 直到我在 jianfeiplan 的 prewrite gate 里看到 task graph 的 rea

Readonly planning：不动手先想清楚 那条指令很明确："Readonly planning review. Project: /Users/apple64/.agent/skills/jianfeiali. Plan jp048: integrate full AliWangWang/Qianniu customerservice capabilities. Do not edit

ping only：三个字里的协作默契 那条指令很短："ping only. Reply OK. Do not edit files." 三行指令，但每一行都在做一个非常具体的约定。这三个约定加在一起，定义了一种最轻量但最精确的协作状态：Agent 在线、不做任何事、无副作用。 ping 是什么 在 Agent 协作里，ping 不是网络探测工具，而是确认 Agent 是否在线、是否理解了当前上

自动化失败后，先判断失败类型 最近一个自动化流程输出结果完全不对。第一反应是改代码，直接修参数。但这个念头刚冒出来就被我压住了——改代码之前，得先搞清楚这次失败到底是什么类型。 不是所有失败都用同样的方法修。如果失败类型判断错了，你修的方向就错了。方向错了，你花的所有时间都是在做无用功——你可能修了逻辑层但问题在数据层，可能调了参数但问题在环境层，可能改了代码但问题在交互层。修了不该修的地方，不仅

不是所有优化都该马上做 写稿子的时候，最容易陷入的一个循环是：改了一遍觉得不够好，再改一遍，还是觉得差一点，然后无限改下去。 那次我正在改一篇稿子，改到第三遍时，Agent 给了我一条优化建议。我本能地接受了，开始第四遍修改。改完再看，还是觉得差一点。Agent 又给了建议，我又改。 改到第六遍时，我停下来。不对劲。越改越不满意，但每一遍都确实比上一遍有改进。改进了还是不满意，说明问题不在稿子本身

从主观审美到可测规则 做内容的人都知道一个痛点：判断一篇稿子好不好，往往是主观审美。你觉得好，别人觉得不行。换一个审稿人，结论又变了。 这种主观判断在个人创作时还能忍，但在团队协作和自动化流程里就成了硬伤——因为没有共识标准，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写得很清楚："要有具体场景""不要泛泛而谈""紧扣主题"，但这些要求对模型来说，只是建议，不是硬门槛。模型可以忽略它们，而你也拿不出证据说"你违反了哪条规则"，因为规则根本不是可执

这几天我在处理一套挺典型的 AI 协作任务。表面看，是几个 Agent 启动、偏好配置、任务审核队列的问题。换成过去，我大概率会直接把任务丢给 AI，让它看上下文、拆步骤、跑检查，能做就往前做，不能做就告诉我卡在哪里。 但这一次，我中途停了一下。 我突然意识到，自己真正想问的不是「接下来怎么办」，而是「这些任务为什么会出现在这里」。它们从哪里来，背后的流程逻辑是什么，如果我现在只是把它们做完，会不

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

跨计划依赖的红绿灯：并行执行时的阻塞问题 三个计划同时跑，却互相等 有一段时间，系统里跑了多个计划。它们各自独立，互不干扰，看起来是真正的并行执行。 但仔细看日志，发现问题：计划 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

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

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

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

最近我在改一个写文章的流程。最早它特别简单，一台电脑上开一个窗口，把想法写成正文，预览一下，没问题就收口。这个时候几乎没有什么复杂度，因为所有东西都在同一个地方发生，文件在哪里，状态到哪一步，失败了该找谁，其实一眼就能看见。 后来我把它放到了3台电脑上。事情一下子变了。不是因为3台电脑有多高级，也不是因为我突然做了什么大系统，而是因为一个原本只需要自己记住的流程，突然需要被几台机器共同理解。真正变

上个月，我一个人用了一周时间，完成了一个以前需要三个人忙半个月的内容项目。不是因为那三个人效率低，而是因为 AI 改变了内容创作的游戏规则。 你有没有这种感觉，做内容最痛苦的不是没想法，而是有想法之后那一堆琐碎的执行工作。查资料、整理素材、写初稿、修改、排版、分发。每一步都不难，但每一步都耗时间。结果就是，一个好想法，要折腾好久才能变成一篇好文章。 说实话，这种情况在 AI 时代已经改变了。不是说

过去 5 天，我搭了一个很大的系统。最开始，我只是想让 AI 帮我完成一些事情，比如写文章、整理资料、跑脚本、改程序、检查结果。做着做着，我发现真正麻烦的地方不在 AI 会不会回答，而在它能不能进入我真实的工作环境。 你想想看，我家里不止一台电脑。有些软件在这台电脑上，有些文件在那台电脑上，有些设备又插在另一台电脑上。旁边还有安卓手机、苹果手机、NAS、网卡、交换机、USB Hub、TypeC 转

你有没有这种感觉？ 周五下午 4 点，你坐在电脑前，面前是三个打开的文档，周报要写、方案要改、会议纪要要整理。你知道这些内容「有它应该有的样子」，但你就是提不起劲。不是因为懒，是因为你隐约觉得，这些事，不该这么费劲。 但现实是，你还是会花 3 个小时，把这些东西一点点磨出来。这不是你的问题。这是工具的问题。更准确地说，是你和工具之间的关系，该更新了。 不是任务变多了，是工作方式该换了 我最近跟一

这几天整理候选对话，我反复看到一个很熟悉的场景。很多事已经能跑了，结果人还在问，要不要再优化一下。文章已经成形了，要不要再换一个标题。页面已经能用了，要不要再加一个按钮。计划已经够清楚了，要不要再补一层说明。说实话，这种想法太正常了，因为我们总觉得再改一点会更稳，再磨一下会更像样，再多准备一点就不容易被别人挑毛病。 可问题也在这里。很多时候，真正拖住人的不是能力不够，而是一直不肯让东西进入真实世界

上周五下午，我正在整理办公室抽屉，翻出一个老旧的录音笔。鬼使神差地按下播放键，一段断断续续、杂音不断的对话传了出来，是我和一位客户三个月前的通话。 我的天，这录音质量也太差了！根本听不清在说什么。 但是听着听着，我突然愣住了。 这段被我认为"失败"的录音，竟然让我听出了当时没注意到的细节。 那段"失败"的录音 说实话，我从未想过这段录音会有什么价值。 那天下午，我和这位客户谈了整整40分钟，当时

昨天凌晨三点，我猛地从床上坐起来，盯着电脑屏幕上的写作计划列表，突然意识到：这个月已经过去了四分之三，而我连一半任务都没完成。那种焦虑感瞬间攫住了我，心脏砰砰直跳，手心冒汗。 说实话，这种场景你熟悉吗？不是我说，我相信很多人都有过类似的经历。白天忙忙碌碌，晚上熬夜赶工，却总觉得时间不够用。你想想看，为什么我们制定了那么多计划，却总是完不成？ 写作计划的幻象 我跟你说，我的朋友小李是个计划狂魔。他

上个月我干了一件以前从来没有干过的事，让多个AI同时审我一篇稿子。不是让一个AI从头审到尾，而是让不同的AI各管一摊，有的盯创新性，有的盯逻辑，有的盯数据。说实话一开始我没想到结果会这么不一样。 以前找同行审稿，五个人给五份意见，互相矛盾。有人说创新不够，有人说方法有问题，有人说结论太武断。你拿着这五份意见，就像拿到五张不同比例的地图，哪张都像，哪张都不全。说到说到最后改不改、怎么改，全靠自己判断

那天下午，小李盯着电脑屏幕已经二十分钟了，光标在文档上闪烁，却一个字也没敲出来。同事小张推了推眼镜，递过来一张便签纸："试试这个，一分钟练习，我保证你能写出来。"小李半信半疑，但看着空白的文档，还是接了过来。 说到这个一分钟练习 "一分钟练习"听起来简单，对吧？ 但你知道，很多时候我们不是缺时间，而是缺开始的力量。怎么说呢，就像你想跑步，却在门口犹豫了十分钟，最后干脆不跑了。一分钟练习就是那个"

上周五下午三点，我正坐在咖啡馆角落对着空白的文档发呆。截止日期就在明天，灵感却像被猫追着跑的老鼠，怎么都不肯出来。突然，我脑中闪过一个大胆的想法，为什么不试试让三台AI一起帮我写呢？说干就干，我立刻打开Claude、ChatGPT和Cursor，准备来一场前所未有的机器协作写作实验。 说真的，这个想法太疯狂了，我当时自己都笑了。想象一下，三个不同性格、不同特长的AI同时工作，会碰撞出什么样的火花？

上周五晚上，后台收到一条很典型的留言："最近总是睡不着，有没有好用的冥想APP推荐？"我先看了一眼问题，发现这不是单纯的工具选择题。 这种情况太常见了。我们现代人遇到情绪困扰的第一反应，往往不是向内看，而是向外找工具。冥想APP、情绪日记、白噪音、心理课程，我们仿佛相信只要找到那个"完美工具"，一切问题就能迎刃而解。 怎么说呢，这种思路其实挺有道理的。毕竟工具看起来立竿见影，容易上手，而且有种"我

凌晨三点，我盯着电脑屏幕上那篇写了又删、删了又写的文章，咖啡已经凉了，灵感却迟迟不来。 说实话，我已经连续一周没有睡个好觉了。 "这破文章怎么这么难写啊！"我忍不住低声抱怨，右手无意识地敲着桌子，发出哒哒的声响。 然后，我脑子里突然闪过一个大胆的想法。 为什么不试试三台机器协作写作呢？ 说起来你可能不信 那是一个周末的下午，我正蹲在咖啡馆角落里，对着笔记本屏幕发呆。 旁边桌的大姐突然问我："小伙