1. 先说清楚我要沉淀的专家到底是什么1.1 一个真实的痛点我不是不会是每次都从零开始我做内容策划和方案交付有五六年了最烦的从来不是不会做而是每次都从零开始解释同一件事。同一个客户背景、同一套判断标准、同一批格式要求我在不同的对话里重复描述过几十遍。每次开一个新窗口工具对我是完全陌生的它不知道我讨厌赋能、闭环、抓手这类空词不知道我交付的方案必须在三页内讲清成本收益不知道我整理会议纪要时习惯把待确认事项单独列一栏。这种重复消耗非常隐蔽。单次看起来只有五六分钟一天下来两三次一年就是几百个小时。更麻烦的是判断标准会漂移今天心情好写得松一点明天赶时间写得紧一点最后自己都不确定哪一版才是我的水准。WorkBuddy 这类工具真正打动我的地方不是它比通用对话工具更聪明而是它允许我把这些东西固化下来。规则写一次之后所有任务默认生效资料放进去一次之后能被反复检索流程打包一次之后一句话就能调度。所以标题里说的把自己沉淀成一个专属专家说白了就是三件事让工具认识我让工具记住我的判断标准让工具替我把重复的部分跑掉。1.2 三层结构规则层、知识层、技能层我踩过的最大的一个坑是一开始把所有东西都往提示词里塞。结果提示词写了两千多字模型反而抓不住重点输出越来越飘。后来我把整个体系拆成了三层各管各的才稳定下来。层级解决的问题主要载体更新频率规则层我是谁、我的偏好、我的红线全局自定义指令低频一两个月调一次知识层我做过什么、资料在哪、结论是什么本地知识库/笔记库持续每周都在加技能层重复动作怎么标准化执行Skill/自定义流程中频遇到重复第三次就做这三层的分工逻辑很重要。规则层是长期不变的身份信息比如我的行业、我的角色、我的输出风格。知识层是不断增长的资产比如过往案例、行业数据、客户反馈。技能层是可复用的动作序列比如把一份会议录音整理成结构化纪要、把一份长文档压缩成三条结论。分层之后有个很直观的好处调试的时候你知道该改哪一层。输出风格不对改规则层事实记错了改知识层步骤漏了改技能层。如果全堆在一起你只能整段重写越写越长最后自己都读不下去。我的判断标准很简单一个东西半年内不会变放规则层一周内会变放知识层每次都要重走一遍的动作放技能层。1.3 为什么不直接用通用对话工具很多人会问这些东西我开个对话框每次粘贴一段背景说明不就行了能行但有两个问题绕不过去。第一是上下文会被稀释。你把背景、资料、任务要求全塞进一次对话模型要在这堆信息里找重点。资料一多前面写的规则就容易被淹没输出质量断崖式下滑。这不是模型不行是注意力本来就是稀缺资源。第二是资产无法积累。你在对话框里写的东西关掉就没了。下次开新对话还是从零开始。这就像租房子住——每个月都付租金但房子永远不是你的。而搭一套规则知识技能的结构相当于给自己装修了一套房越住越顺手东西越攒越多。我自己的体感是前两周花在搭建上的时间大概十几个小时之后每天的重复劳动至少省掉四十分钟。第三周就回本了。这也是我愿意写这篇东西的原因——它不是那种看起来很酷但用不上的技巧而是真的能算清账的投入。2. 环境落地WorkBuddy 工作台怎么改成自己的形状2.1 安装与第一次配置别急着用先做三件事安装本身没什么好说的官网下载对应平台的版本跟着向导走就行。Windows、macOS 都有Linux 版本我用的 Ubuntu 也跑得起来装完第一次启动会让你选工作目录和登录账号。真正决定后面顺不顺手的是第一次配置。我建议你坐下之后别急着发第一条指令先做完这三件事确定一个固定的工作根目录比如~/workbuddy-workspace所有项目子目录都挂在它下面。不要东一个西一个散在桌面和下载文件夹里后面接知识库会非常痛苦。把常用资料做一次粗分类哪怕是先建五个空文件夹01-项目案例、02-行业资料、03-模板库、04-客户信息、05-临时草稿。分类标准不重要重要的是先有个容器。登录并确认模型来源。有的版本支持切换本地模型和云端模型具体能选哪些取决于你装的版本和账号权限以你界面里实际显示的为准。这里有个小细节值得说目录名一定要用英文或者拼音别用中文加空格。我一开始用客户资料 汇总这种命名后面写脚本批量处理的时候各种转义问题改名字改了半小时。还有一个容易被忽略的点如果你打算接本地模型先把机器的内存和显存摸清楚。量化后的小参数模型8G 内存勉强能跑但响应会慢16G 以上体验会好很多。硬盘也要留出空间模型文件动辄几个 G。这些信息在设置页面的模型管理里一般能看到当前占用装之前先看一眼省得装到一半发现跑不动。2.2 自定义指令写规则比写提示词重要自定义指令是整个体系里性价比最高的一块。它的作用是对所有任务默认生效不用你每次重复交代。我现在的全局指令大概是这样组织的你可以直接抄结构内容换成你自己的# 角色 我是一名内容与方案策划主要交付对象是中小企业的市场负责人。 # 输出偏好 - 结论先行第一段必须给出核心判断不要铺垫。 - 段落短单段不超过五行。 - 禁止使用空泛词汇赋能、闭环、抓手、生态位、打法。 - 涉及数据必须标注来源或说明是估算不允许编造精确数字。 # 工作习惯 - 给我方案时永远同时给出一个更省成本的替代版本。 - 不确定的地方直接问我不要自己猜一个答案往下写。 # 红线 - 不涉及任何法律法规解读、政策评价、社会争议话题。 - 不生成任何涉及他人隐私的具体信息。写规则有几个经验都是踩出来的。规则条目要短一条只讲一件事。我最早写过一条巨长的规则把风格、格式、语气全塞在一句里结果是模型每次只执行一半。拆成五六条短句之后命中率明显上去了。用否定句要谨慎。不要啰嗦这种表述很模糊模型理解不了边界。改成单段不超过五行这种可量化的描述效果立刻不一样。规则越具体执行越稳定。规则总数别超过二十条。超过之后边际收益急剧下降而且互相之间容易打架。我现在的习惯是每个月月底翻一遍把三个月都没触发过的规则删掉。规则库和衣柜一样不清理就会越来越乱。一个反直觉的发现加了不确定就问我这条规则之后输出速度变慢了但返工率下降了一大截。慢一点比反复改要划算。2.3 目录结构设计给专家一个书桌工作目录怎么设计直接决定后面知识库能不能用。我现在的结构大概是这样workbuddy-workspace/ ├── 00-inbox/ # 临时丢进来的东西每周清一次 ├── 01-cases/ # 过往项目一个项目一个文件夹 ├── 02-knowledge/ # 行业资料、方法论笔记 ├── 03-templates/ # 各类模板方案、周报、纪要 ├── 04-clients/ # 客户背景与历史沟通要点 ├── 05-output/ # 所有交付物按年月归档 └── 06-skills/ # 自定义技能的定义文件这个结构里最关键的是00-inbox和05-output两个。00-inbox是缓冲池任何临时素材先扔进去不立刻归类避免因为要想怎么归类而拖延。05-output是成果池所有对外交付的东西统一放这里按2025-01这种年月命名半年后回头看自己的产出曲线一目了然。中间的01到04是资产区。这里有个原则资产区只放已经整理过的东西。原始录音、聊天记录截图、没读过的 PDF一律不进资产区。因为知识库检索的时候垃圾素材会严重干扰结果质量。我吃过这个亏——把一堆半成品丢进去结果每次检索都返回一堆没用的片段反而把好的内容挤下去了。清理节奏我定的是每周五下午半小时。Inbox 清空Output 归档顺手删掉三份最没用的素材。半小时听起来不多但它保证了整个库不会腐烂。3. Skill 体系把重复劳动打包成可复用能力3.1 什么该做成 Skill什么不该Skill 的本质是把一段固定的动作序列封装成一个可调用的单元。你可以理解为给工具装了一个快捷键按一下就自动走完一整套流程。但不是所有重复动作都值得做成 Skill。我用的判断标准叫三次法则同一个动作如果我已经手动做过三次以上且步骤基本固定就值得封装。反之如果每次的输入形态都不一样、中间需要大量人工判断就先别急硬做成 Skill 只会变成一个谁都不想用的摆设。具体到我的场景值得做的典型是这几类类型特征是否适合封装格式转换输入形态固定输出格式固定非常适合结构化拆解有明确的分层规则适合内容审核有清晰的检查项清单适合创意发散每次路径都不同不适合人际沟通高度依赖具体语境不适合这个表的意思是凡是能被写成检查清单的东西都能做成 Skill凡是要靠感觉的东西都别做。比如把一份长文档压成三条结论就很适合因为规则明确——三条、每条不超过三十字、必须包含一个动作动词。而帮我写一封得体的道歉邮件就不适合因为得体与否取决于具体关系封装之后反而会变得生硬。3.2 我的第一批 Skill 清单与写法模板我第一批做了六个 Skill跑了大半年还在用的有四个。这里把定义模板放出来你可以照这个结构写自己的# Skill 名称长文压缩成三条结论 ## 触发条件 输入内容超过 2000 字且明确要求提炼或总结。 ## 执行步骤 1. 通读全文识别作者的核心主张不要只抓每段的第一句话。 2. 找出支撑核心主张的关键证据或数据。 3. 生成三条结论每条格式为判断 一个支撑点。 4. 每条结论控制在 30 字以内必须包含动词。 5. 输出后附一行未覆盖的重要信息列出被舍弃的一到两点。 ## 输出示例 - 该方案应优先做渠道因为现有流量成本已高于行业均值。 - 建议先小范围验证因为同类尝试的失败率缺乏数据支撑。 未覆盖财务测算部分、团队配置建议。 ## 边界 不适用于诗歌、小说等虚构类文本。写这个模板的时候有几个细节很关键也最容易漏。触发条件必须写。不写的话你会在不该用的时候条件反射地调用它结果格式被硬套到完全不合适的任务上。我就干过把压缩成三条结论用在头脑风暴记录上把一堆有价值的发散想法硬压成三条白白浪费了一轮灵感。输出示例必须给。这一步比任何文字描述都管用。给一个具体的样例模型对齐格式的成功率会高非常多。示例不用写得完美但结构要和目标输出一致。边界必须写。这一条是最容易被忽略但最有用的。写明什么时候不该用等于给未来节省了一次返工。另外提一句Skill 和插件不是一回事。插件更多是把外部能力接进来Skill 是把你的内部流程固化下来。两者可以配合但顺序是先有 Skill 再考虑插件——因为流程没理顺之前接再多外部能力也只是把混乱放大了。3.3 版本管理与迭代节奏Skill 一定要做版本管理否则改着改着就忘了当初为什么这么改。我的做法很简单在每个 Skill 文件头部加两行版本v3 最后修改2025-03-11原因输出示例太抽象替换为真实案例看起来笨但真的有用。有一次我把一个 Skill 改坏了靠这两行记录五分钟就回滚了。没有记录的话你得凭记忆重建那基本等于重写。迭代节奏我定的是不主动改。只有出现下面三种情况之一才动手连续三次输出都不符合预期说明规则本身有问题任务场景发生了结构性变化比如客户从 To C 换成了 To B发现了更好的输出示例值得替换进去。除此之外一律不动。原因很实际每次改动都要重新适应频繁改会让你对工具的稳定性失去信任最后干脆不用了。稳定比优化重要得多尤其是前三个月。4. 知识沉淀把散落资料变成可检索的专家记忆4.1 素材来源与清洗原则知识层是最花时间但回报最持久的一层。我的素材来源主要四块自己写的交付物、整理过的会议纪要、读过的行业材料、以及自己总结的方法论笔记。注意这四个来源有一个共同点——都已经被我加工过一遍了。这是我给自己定的硬规则原始素材先进 Inbox 加工加工完才进知识库。为什么这么在意加工过这件事因为检索的本质是匹配语义相似度。一堆没整理过的原始文本里面充斥着口语、重复、中途放弃的句子它们会跟真正有价值的内容抢位置。我做过一次对比同一批资料不加工直接入库存一份加工后入库再存一份同样的检索词加工版返回的结果相关性明显更高。差距大到什么程度不加工的那版前五条结果里只有一条能用。清洗的具体动作有三步去重同一份资料在不同时间整理过两版保留更完整的那版另一版删掉。重复内容会在检索时重复占位。加标题每份资料必须有一个能被检索到的标题不要用未命名文档3这种。标题本身就是最强的检索锚点。标注时间在文件里写清楚资料的形成时间。行业数据有保质期的三年后还按老数据做判断是要出事的。这三步每份资料大概多花两三分钟但它是整个体系里最值钱的三分钟。4.2 和笔记工具打通我平时记笔记用 Obsidian好处是文件都是本地 Markdown天然适合作知识库的素材源。打通的方式有两种看你的使用习惯。一种是直接把笔记库目录挂进工作区的知识库。优点是省事改完笔记立刻生效缺点是笔记库里通常有大量私人内容混进知识检索会干扰结果。我一开始就是这么干的后来发现会议纪要检索经常返回我的个人日记片段非常尴尬。另一种是建一个单向同步目录。笔记库是主库定期把里面适合共享的部分复制到02-knowledge。优点是干净、可控缺点是要维护同步动作。我现在用的是这种每周五清理目录时顺手同步一次五分钟的事。具体选哪种我建议按一个标准判断如果你的笔记库里有超过 30% 的内容是你不想让工作场景看到的就选同步方案。如果没有直接挂目录更省事。提醒一句同步的时候不要双向同步。我踩过这个坑——工作区里改了一版笔记库里也改了一版两边冲突最后靠翻备份才找回来。单向永远单向。4.3 本地模型还是云端模型怎么选这是个经常被问的问题我的答案取决于三件事数据敏感度、机器配置、任务类型。数据敏感度高比如涉及未公开的客户信息优先本地模型宁可慢一点。机器配置一般内存 16G 以下量力而行。本地模型跑不动硬跑体验会差到让你放弃整个体系。任务偏重推理和长文本理解云端模型通常更稳任务偏重格式转换和批量处理本地模型够用还省钱。实际操作里我通常是混着用日常的格式清洗、批量改名、简单摘要走本地需要深度分析和长文档交叉引用的时候切云端。截图里能看到切换入口操作本身一键的事。关于本地模型还有两个细节值得说。第一量化版本号要选对同一模型不同量化等级的效果差距比想象中大宁可多占点硬盘也别选太激进的压缩。第二本地模型首次加载会慢之后有缓存会快很多别在第一次加载慢的时候就断定本地模型不能用给它十分钟。5. 跑通一次完整任务从接需求到交付5.1 任务拆解与指令编写光有结构不够得跑一遍才知道哪卡。我拿最近一个真实任务举例给一家做企业服务的客户出一份竞品分析最终要交付一份不超过十页的材料。我的实际流程是这样的。第一步不是写指令而是先想清楚交付形态。十页、给市场负责人看、要能直接进汇报材料——这三个约束决定了输出不能是那种长篇大论的分析必须是结论密集、每页一个判断的结构。想清楚之后才写指令。我的指令有个固定结构四段目标产出一份不超过十页的竞品分析读者是客户的市场负责人。 输入知识库中 02-knowledge/行业资料 下的五份材料以及 01-cases 里两个同类项目。 约束每页一个核心判断判断后必须跟一个数据或事实支撑不允许出现没有出处的时间。 输出先给一页目录我确认后再展开正文不要一次性全写完。最后那句先给目录确认后再展开是我后来加的非常重要。一开始我让工具一口气写完结果方向错了十页全废。加了这道关卡之后返工成本从重写十页降到改一行目录。这里的原则是大任务一定要拆成可检查的中间节点。一次跑完看起来很爽但出错的时候你只能全部推翻。中间加两三个确认点总耗时反而更短。5.2 中间产物管理与人工复核点任务跑起来之后中间产物的管理很容易被忽略。我的做法是每个任务建一个子目录按阶段命名05-output/2025-03-竞品分析/ ├── 00-需求记录.md ├── 01-目录.md ├── 02-素材摘录.md ├── 03-初稿.md ├── 04-复核意见.md └── 05-终稿.md这个结构最大的价值是让复核有据可依。你能看到目录改了几次、素材摘录是不是漏了什么、复核意见是不是都落实了。没有这个结构你只能靠记忆而记忆在第三天就不准了。人工复核点我只设两个设多了就变成给自己找活干。第一个在目录确认时检查方向对不对第二个在初稿完成时检查事实有没有错。事实核查是绝对不能省的尤其是数字、时间、名称这三类。工具在长文本里偶尔会把两个来源的数据混在一起不查就会带着错误交付出去那是事故级别的。复核的时候我有个小技巧不看正文只看每段的主题句。因为主题句是骨架如果骨架错了细节再对也没用。骨架过了再通读细节效率高很多。5.3 成本、积分与速度的平衡成本这块值得单独说。这类工具通常有配额或者积分机制具体规则看你的版本和套餐我这里只讲通用思路。我的原则是把贵的算力用在刀刃上。具体分三类任务任务类型处理方式理由素材清洗、去重、改名本地模型或简单规则不涉及推理结构拆解、目录生成云端快速模型需要理解力但输出短深度分析、交叉引用云端强模型直接影响交付质量最容易浪费的是第一类。很多人拿最强的模型去干批量改名的活一次几十条配额哗哗掉。这类任务用最简单的处理方式就行甚至写个正则都能搞定。还有一个隐藏的成本是重试。同一个任务反复跑五次成本是五倍。减少重试的关键不在模型在输入质量——素材乱怎么跑都跑不对。所以我把大量时间花在整理素材上而不是花在调参数上。这个取舍我用了很久才想明白上游的十分钟整理能省掉下游的一小时重试。速度上也有个反直觉的经验。给工具设置先出目录再展开之后总耗时其实变长了但返工少了端到端的时间反而缩短。如果只看第一次输出的速度你会觉得加确认点是在拖慢流程拉长到整个任务周期看结论正好相反。6. 踩坑实录与排查速查表6.1 我遇到过的六个典型问题跑了几个月问题攒了一堆挑最典型的六个说。第一个规则写了但不生效。排查下来原因通常是规则写得太长太笼统或者和另一条规则冲突。解决办法是把规则拆短一条一件事然后逐条测试——每次只开一条规则跑一次看哪条没命中。听起来笨但这是唯一靠谱的排查方式。第二个知识库检索返回不相关内容。百分之八十的情况是素材没清洗干净。先在 Inbox 里筛一遍把半成品和有重复内容的文件清出去再重建索引。我遇到过一次怎么调都不对最后发现是同一个文件存了三份删掉两份立刻正常。第三个网络连接异常。切云端模型时偶尔会连接不上先看本地网络再看是不是代理设置干扰。如果是公司网络环境有限制切回本地模型通常能继续干活别干等着。第四个响应特别慢。三个常见原因素材一次塞太多、本地模型没加载完、后台有其他任务在跑。我的处理顺序是先看素材量把单次输入控制在合理范围长文分批处理。第五个本地模型输出质量波动大。量化等级、上下文长度、输入长度都可能影响。可以先固定输入长度做一次对比测试定位到底是哪个变量在捣乱。如果机器配置确实有限别硬撑把重推理的任务切云端。第六个不同设备上规则不一致。这是在多台机器上使用时最容易出的问题。养成习惯所有配置文件放在工作区目录里换机器时整个目录搬过去不要依赖工具自带的云同步——两边覆盖过一次就很难查清楚。6.2 一份可以贴在显示器旁边的避坑清单下面这些是我用血换来的直接抄先想交付形态再写指令。顺序反了指令写得再漂亮也是白写。大任务必须有中间确认点。一口气跑完看起来快出错就是全废。素材没洗完不入库。垃圾进垃圾出这条没有例外。数字、时间、名称必须人工核查。这三类是错误的高发区也是最难在事后发现的。一次只改一个变量。同时改规则又改素材出问题你根本不知道是哪边的事。每周固定半小时清理。Inbox 清空、Output 归档、删三份最没用的素材。规则库和 Skill 都要写版本记录。两行字的事救过我好几次。别追求一次到位。第一版一定是粗糙的先用起来用起来了才知道哪里该改。我在实际使用中最深的一个体会是这套东西的价值不在用得多花哨而在用得有多稳定。我见过太多人一开始兴致勃勃搭了一堆规则和技能两周后全弃了原因通常是追求完美——规则改来改去任务跑一半不满意就推倒重来最后把自己耗没了。真正跑得下去的做法恰恰相反规则先写五条够用的Skill 先做两个最刚需的知识库先放二十份整理干净的材料。粗糙地跑起来然后每周改一点点。三个月后回头看你会发现整个体系已经和当初完全不一样了而这个过程里你从来没有经历过那种推倒重来的挫败感。最后分享一个我最近才开始用的小扩展给每个 Skill 加一行最近一次使用日期。用不上的自然就沉淀下去了用得多的会自动浮出来。这个动作几乎零成本但它让整个体系的迭代方向变得非常清晰——你不需要靠感觉判断该优化什么数据会告诉你。