桌面AI工作台：自定义指令与技能从入门到精通

1. 先想清楚它是什么：桌面 AI 工作台的定位与能力边界

桌面端的 AI 工作台，这几年从“聊天框外面套个壳”一路演进成了“能读你本地文件、能调你常用服务、能按剧本连着干好几步活”的东西。我日常在用的这一类产品，骨架其实就三块：第一块是上下文接入，它能把当前正在处理的东西——打开的那个表格、某个目录里的资料、日程和待办——一起喂给模型，而不是让你手动复制粘贴；第二块是动作执行，它真的能动手，写文件、改文件名、生成一份对照表、往协作工具里发一条待办；第三块就是标题里点到的两个机制，自定义指令和技能，前者把“每次都要重新交代一遍”的偏好固化成常驻规则，后者把“每周都要走一遍”的流程固化成可复用的剧本。所谓从入门到精通，说白了就是从“会打字提问”走到“会写规则、会编剧本、会调流程”。

这篇东西适合三类人看。刚装上、打开界面之后不知道从哪下手的新手，可以直接跳到第 2 节按步骤走；已经用了一阵、但每次都在重复粘贴同一段提示词的中级用户，第 3 节的指令模板能省下大量时间；想把这类工具推给团队、又不知道怎么定规范的老手，第 4、5 节关于技能结构和排错的部分会更对胃口。需要提前说明的是，不同厂商的实现细节差异不小，界面叫法、技能目录约定、权限颗粒度都不一样，我下面讲的是这类产品通用的骨架和我在实际使用中验证过的做法，具体到某个按钮叫什么，你得对着自己那套的文档再核一遍。另外下文统一用“工作台”指代这类桌面 AI 办公助手，不特指某一家的具体版本，因为招式是通用的，换个壳照样能打。

1.1 它和普通聊天窗口的差别到底在哪

很多人第一次打开工作台，会觉得“这不就是个内置了模型的对话框吗”，用两天就丢下了。差别不在聊天体验，在于它能拿到只有你的电脑才拿得到的东西。普通聊天窗口里，你得先把文件内容复制进去，导出成 PDF，截图贴上去，一轮对话结束这些上下文就散了。工作台不一样，它站在你的文件系统和使用习惯之上，能直接读取指定目录、能感知你当前在编辑哪份文档、能记住上次会话留下的结论。这个差别听起来抽象，落到具体场景上就很实在：写季度总结的时候，它能把你散落在十几个文件里的记录一次性扫一遍，而不是你一份份打开复制。

第二个差别是动作能力。聊天窗口的产出是文字，你还得自己复制到目标位置；工作台可以自己写入文件、自己建目录、自己批量改名、自己把结果整理成表格存好。这个能力一旦接上，工作性质就变了，从“我描述一遍、你给我一段文字”变成“我交代一件事、你把它办完”。我给同事演示的时候常用一个类比：聊天窗口像坐在你对面的顾问，说得头头是道，但活还得你自己干；工作台像能进你办公室的助理，你说完需求，它真的会去翻柜子、填表格、把文件夹整理好。

第三个差别，也是拉开效率差距的地方，是流程可固化。顾问每次来你都得重新讲一遍背景，助理干熟了就不用了。自定义指令解决的是“长期偏好”这个层面，比如你写东西不喜欢用长句、给数据必须带单位和来源、输出必须按固定结构来，写进指令里就一次管到底。技能解决的是“多步骤流程”这个层面，比如每周五要把这周的记录汇总成周报、每月初要把上月的项目文件归档并按规则重命名，这些流程写成技能之后，以后就是一句话触发。这两层加起来，才叫“精通”，光会提问顶多算“入门”。

1.2 安装之前值得花十分钟盘点的四件事

我见过太多人装完之后各种报错，回头一查全是安装前没盘点导致的。第一件事是系统版本和运行环境。这类工作台通常依赖较新的运行库，也有的需要本地运行时支持，Windows 上要确认系统版本不太老、磁盘上留够空间，macOS 上要注意芯片架构（Apple Silicon 和 Intel 的安装包是分开的，装错了要么跑不起来要么性能打对折）。第二件事是账号与组织归属。企业环境里工作台往往绑在某个组织空间下，个人账号装完登录进去发现看不到公司资料，这时候别急着重装，先确认自己登的是哪个空间，能不能切换。

第三件事是目录规划。这看起来是小事，实际影响巨大。工作台读文件靠的是路径和目录名，你把所有东西一股脑放在桌面和下载文件夹里，它面对的就是一堆命名混乱的散件，理解成本高、召回准度差。我建议在安装之前就先把工作目录搭出来，装完之后直接指向这个目录。第四件事是网络与内网策略。企业网络通常会限制某些域名的访问，装完发现登录卡住、模型调用超时，八成是出口策略没放行。这时候别自己瞎试，先找负责网络策略的同事确认需要放行哪些域名和端口，比自己折腾半天强得多。

提示：安装前把这几项写在一张纸上逐条确认，比装完再一个个排查要省两个小时。尤其是账号空间归属和网络出口这两项，出问题时报错信息往往很含糊，容易被误判成软件本身有毛病。

1.3 能交给它的活和不能交给它的活

用了一段时间之后我总结出一个判断标准：把工作台当成一个刚入职、能力不错但完全没有上下文的实习生。实习生能干的活——整理会议记录、把散乱的表格合并清洗、按模板生成一份文档骨架、把一批文件按规则改名归档、从十几份材料里提取关键结论——这些交给它都没问题，而且比人快很多。但实习生不能干的事，也别让它干。第一类是不可逆的操作，批量删除、群发消息、覆盖原文件，这类操作一旦出错没有后悔药，必须加人工确认卡点。第二类是需要担责的判断，比如合同条款能不能接受、这个方案要不要砍掉，它可以给你摆事实列选项，但拍板必须是人。第三类是强合规场景，涉及敏感数据的处理，得先看清楚组织的数据使用规范，别图省事把不该出的东西递出去。

这个边界感很重要，因为很多人的失望都来自预期错位：以为装上之后能全自动干活，结果发现它连自己要的文件都找不准。事实是，它擅长的不是“替你做决定”，而是“替你把决定之前的脏活累活干完”。你把边界划清楚，只把第一类活往里塞，体验会好非常多。

2. 安装与首次配置：把工作台接进日常动线

安装这件事本身没什么技术含量，但配置决定了它到底能不能融进你每天的工作流。我的经验是，装完之后的第一小时比装的过程重要十倍，因为这一小时里你要完成账号登录、权限授权、工作目录绑定、连通性验证这几件事，每一件做错了都会在之后的日子里以各种奇怪的方式反噬你。这一节按顺序把这几个环节拆开讲，中间穿插我踩过的具体坑。

2.1 安装包获取与安装路径的三条硬规矩

安装包一定要走官方分发渠道，别从第三方站点下载。原因不只是安全，更现实的是版本问题：第三方站点上的包经常是半年前的旧版，功能和文档对不上，你照着最新文档操作发现按钮根本不存在，能把人折腾到怀疑人生。拿到包之后如果官方提供了校验值，花三十秒比对一下，这一步在团队批量部署时尤其值得做。

安装路径上有三条硬规矩，我是被坑出来才记住的。第一条，路径里不要有中文和空格。很多命令行工具、脚本执行环境对含中文的路径支持不好，轻则报错重则静默失败，你根本不知道是哪一环断了。第二条，不要装在系统盘的深层目录里。有些安装器默认装到用户目录下，路径长得像迷宫，后面写脚本引用路径的时候容易打错。我自己习惯在非系统盘建一个简洁路径，比如D:\tools\workspace-desk，一眼能看清。第三条，多版本共存要先想清楚。如果你既想用正式版又想要尝鲜版，别装在同一个目录互相覆盖，分开两个目录、快捷方式名字带版本后缀，能省掉很多“为什么我的配置丢了”的困惑。

2.2 授权范围的最小化：把权限当成信用卡额度来管

首次登录之后，工作台会向你要一堆权限：读某个目录、访问日历、访问消息、访问云文档、使用剪贴板。绝大多数人的做法是全部点“允许”，图省事。我建议把这一步当成办信用卡来对待——额度够用就行，不必追求无限。原因很实际：授权范围越大，它的搜索空间越大，输出跑偏的概率也越高。你给它整个硬盘的读取权限，它找“上个月的项目记录”时可能会翻出一堆同名文件，最后给你拼一份张冠李戴的东西出来。

我的做法是分级授权。第一步，只授权工作目录，就是第 2.4 节要讲的那个结构化的目录树，其他地方一律不给。第二步，消息与日历按需开。如果你只是想让它帮你整理待办，那日历只读权限就够了，不需要写权限。第三步，云文档按项目授权，别把整个空间的读权限一把交出去。这套做法还有一层好处：万一哪天发现输出里出现了不该出现的内容，你能顺着授权清单快速定位是哪一环漏了。

注意：授权不是一劳永逸的，组织调整、项目结束、换岗位之后要回头清理一遍。我见过有人离职交接时才发现自己的工作台还挂着一堆历史项目的访问权限，这种遗留问题在团队协作里很麻烦。

2.3 首次启动的连通性自检清单

装完登录进去，界面能打开不等于能用。我习惯在正式使用之前跑一遍自检，把可能出问题的环节提前暴露出来。这个清单有五项，十分钟能跑完，但能省掉后面几天的抓瞎。

第一项，模型调用是否通。随便问一个需要推理的问题，比如“把这段话压缩成三句并保留数字”，看它是不是正常返回。如果转圈转到超时，多半是网络出口策略的问题，去确认放行的域名列表。

第二项，文件读取是否通。在工作目录里放一个测试用的文本文件，让它读出来并总结。这一步验证的是目录绑定有没有生效、路径有没有写错。很常见的情况是路径绑到了父目录但实际文件在更深一层，导致它“看得见文件夹却看不见文件”。

第三项，文件写入是否通。让它在你指定的输出目录里新建一个文件并写入一句话。这一步能验出目录写权限、磁盘空间、以及某些系统上的安全策略拦截。

第四项，常用服务连接是否通。如果你绑了日历、待办、云文档，逐个点一下读取，别等到真正要用的时候才发现没接上。

第五项，快捷键冲突。工作台一般会注册一个全局唤起快捷键，如果你的机器上装了别的效率工具，很可能撞车。撞了之后表现为“按了没反应”，很容易被误判成程序崩了。改一个不常用的组合，比如加个修饰键，就解决了。

2.4 工作目录的初始化：用目录名当提示词

这一步是我认为最值得花时间的地方。前面说过，工作台理解你的文件靠的是路径语义，那么目录结构本身就是一份写给它的说明书。你在目录名里写清楚“这是收件箱、这是项目、这是模板、这是产出、这是归档”，它找东西的时候就多了一层天然的路标。我自己的工作目录结构大概是这样：

workspace/ 00_inbox/ 临时收到的、还没分类的东西 10_projects/ 每个项目一个子目录，子目录名带项目代号 20_templates/ 各类文档模板、指令模板、技能模板 30_output/ 工作台生成的产物，按日期分子目录 40_reference/ 长期参考的规范、手册、资料 90_archive/ 已完成项目，按年月归档

这个结构的价值在于三点。第一，收件箱和归档分离，00_inbox是缓冲区，允许乱，但面积有限，逼着你定期清；90_archive是冷存储，工作台默认不需要进去翻，检索范围自然收窄。第二，产出和原始素材分离，30_output只放生成的东西，出了问题一眼能看出是它写的还是你写的，回滚的时候也好处理。第三，数字前缀固定排序，在文件管理器里顺序永远是稳定的，不会被字母序打乱，找东西的时候肌肉记忆能建立起来。

建完之后，把这套约定写成一段话，放进全局自定义指令里（第 3 节会讲怎么写），告诉它每个目录的用途。这一步只要做一次，往后所有跟文件相关的任务都会顺很多。我做过对比：目录混乱的时候，让它找一份上个月的会议记录，十次里有三次找错；目录规整并且指令里说明清楚之后，基本一次到位。

3. 自定义指令：把个人习惯固化成可复用的规则

自定义指令是这类工作台里性价比最高的功能，也是最容易被写废的功能。我见过两种极端：一种是一行都不写，每次对话都要重新交代“用中文、别啰嗦、给数据带来源”；另一种是写了一万字，恨不得把人生哲学都塞进去，结果模型被稀释得抓不住重点，输出反而更飘。这一节讲的是中间路线——用分层结构管住复杂度，用固定模板保证可用性。

3.1 四个层级的指令与它们的加载顺序

成熟的实现一般支持多个层级的指令，理解它们的叠加关系是写好的前提。我把它分成四层：全局层放长期偏好，比如语言、语气、输出习惯、目录约定，这些跨项目不变；场景层放特定工作类型的规则，比如写文档时要求什么结构、做数据分析时要求什么口径、写代码时要求什么风格；项目层放单个项目的专属上下文，比如这个项目的术语表、干系人、历史结论；临时层是单次会话里的交代，优先级最高。

加载顺序一般是全局 → 场景 → 项目 → 临时，后者覆盖前者。理解这个叠加关系能解决一大类困惑：为什么我在项目指令里写了“输出用表格”，结果还是给我一大段文字？多半是全局指令里有“优先使用段落叙述”这类更早加载但被误认为优先级更高的规则，或者反过来，某一层写得过于笼统把具体的覆盖掉了。我在实际使用中养成的习惯是，每层只写这一层该管的事，全局层绝不写具体业务规则，项目层绝不写通用格式偏好，边界一清楚，冲突就少。

3.2 一份能长期用的六段式指令模板

写指令最怕写成散文。我试过好几版，最后稳定下来的结构是六段，每段回答一个问题。这套结构的好处是填空式写作，不需要每次都从零构思，也不会漏掉关键项。

第一段，角色与边界。告诉它在这个场景下扮演什么，以及明确不做什么。比如“你负责把分散的记录整理成结构化文档，不负责判断这些记录的业务价值”。

第二段，目标与验收标准。用可检验的方式描述什么叫干完了。避免“整理得好一点”这种没法验收的表述，改成“每个条目包含时间、事项、结论三个字段，缺一不可”。

第三段，输入约定。说清楚你会给什么、格式是什么、在哪个目录、哪些是必须的哪些是可选的。这一段在实际使用中价值极高，因为大量输出跑偏的根源是输入没交代清楚。

第四段，输出格式。给出具体的结构，最好是能照抄的骨架。如果输出是文件，说明文件名规则、编码、放在哪个目录。

第五段，约束与禁忌。列出不能出现的东西：不要编造数据、不要合并语义不同的条目、不要使用某些表达、数字必须带单位。这一段是防止翻车的关键，宁可多写几条。

第六段，自检清单。让它输出之前自己过一遍，把不合规的地方改掉再给。这个技巧效果出奇地好，尤其是格式类要求。

## 角色 你是文档整理助手，负责把零散记录整理成结构化纪要。不判断业务价值，不做取舍建议。 ## 目标 输入的每条记录必须落到输出中的某个条目下，不允许遗漏，不允许合并语义不同的记录。 ## 输入约定 - 目录：00_inbox/ - 格式：纯文本或 Markdown，每条以日期开头 - 缺日期的记录单独归入“待确认”分区 ## 输出格式 - 文件名：YYYY-MM-DD-纪要.md - 结构：一级标题为日期，二级标题为事项分类，每条含时间、事项、结论三个字段 - 保存到：30_output/YYYYMMDD/ ## 约束 - 不得编造未在输入中出现的信息 - 数字必须保留原始单位 - 不得使用“显著提升”“全面优化”这类无信息量的表述 ## 自检 输出前逐条检查：是否有遗漏记录、是否所有条目三字段齐全、文件名是否符合规则。

这套模板我用了大半年，改动很少。它的价值不在于写得多漂亮，而在于它把“什么算干好了”这件事提前说清楚了，后面就不用来回拉扯。

3.3 让指令不飘的四条实操心得

写指令这件事，我踩过的坑比成功的次数多。总结下来有四条。

第一条，具体压过抽象。写“语气专业”没用，写“不用感叹句、不用反问句、每段不超过四句”才有用。写“格式清晰”没用，写“用二级标题分节，每节三个以内的要点”才有用。模型的执行力跟你给的确定性正相关，你越模糊它越自由发挥。

第二条，给正例和反例。有些要求光靠描述说不清楚，比如“纪要要写得像人写的”，这句话谁看都糊涂。但如果你贴一段你认可的样例，再贴一段你不认可的样例并说明哪里不行，它立刻就能抓住你要的那个调性。我在写对外文案的指令里放了两组对照，效果比写十条形容词好。

第三条，控制总长度。指令不是越长越好，超过一定长度之后，后面的内容会被前面的稀释，模型开始抓大放小。我的经验是全局层控制在六百字以内，项目层控制在一千五百字以内，超出的部分拆到技能里去，或者做成参考资料让它按需读取而不是常驻上下文。

第四条，用编号不用散文。同样的内容，写成段落和写成带编号的清单，执行效果差别明显。因为编号天然带有“逐条核对”的暗示，它会更倾向于一条条对照而不是整体感觉一下。

提示：写完一版指令之后，拿三个不同的真实任务去测。如果三个任务里有两个输出不符合预期，别急着加内容，先看是不是某条要求本身写得有歧义。砍掉模糊表述比堆更多要求有效得多。

3.4 版本管理与灰度替换：别把自己改瞎

指令改着改着就不知道哪版好用了，这是常态。我的做法是给指令文件加版本号和改动记录，每次改动写一句为什么改，改完拿几个固定任务回归测一下。测试用例不用多，三五个覆盖主要场景就够，但要固定下来，每次都用同一批，这样才有对比性。

替换策略上，我倾向于灰度。新版本先在一个场景里用一周，确认没退化再推全局。因为指令的改动经常是“修好了一个问题，带出两个新问题”，尤其是当你加了更严格的格式要求时，可能会压制住它本来做得不错的部分。有一次我给输出加了严格的字数上限，结果它为了凑字数把关键结论删了，得不偿失。这种问题只有跑过才知道。

4. 技能实战：把重复流程压成一句话

技能是这类工作台真正拉开差距的地方。指令管的是“怎么说”，技能管的是“怎么干”。一个技能本质上是一份可被触发的剧本，包含三样东西：什么时候该用它（触发描述）、需要什么输入（参数约定）、按什么步骤干（执行流程加工具调用）。写得好，以后一句“帮我出本周周报”就能跑完全程；写得糙，它要么不被触发，要么触发了乱跑。

4.1 技能的结构：描述文件、脚本与参考资料

不同实现的目录约定不一样，但骨架大同小异。常见的是一个技能一个文件夹，里面有一份描述文件（说明名称、用途、触发条件、输入输出），若干脚本（干具体活的），以及可选的参考资料（模板、规范）。触发靠的是描述文件里那段“什么时候用我”的文字，这段写得好不好，直接决定技能能不能被正确唤起。

我见过的最大误区是把这段描述写成功能介绍。“本技能用于处理周报相关事务”这种写法基本等于没写，因为模型判断要不要用它靠的是场景匹配，你得把用户可能说的话写进去。好的写法是把触发条件具体化：“当用户提到本周工作汇总、周报、weekly report、需要把一周记录整理成汇报材料时使用”。

name: weekly-report description: > 当用户提到周报、本周汇总、一周工作整理、weekly report， 或要求把 00_inbox 里一周内的记录整理成汇报材料时使用。 不适用于月度总结、季度复盘、项目结项报告。 inputs: - name: week_offset type: integer default: 0 desc: 0 表示本周，-1 表示上周，以此类推 outputs: - path: 30_output/{date}/weekly-{date}.md format: markdown steps: - 扫描 00_inbox 中目标周的全部记录 - 按项目分组，无法归组的放入“其他” - 每组提炼三条以内的关键进展，保留数字与单位 - 按模板填充，缺字段留空并标注“待补充” - 写入输出目录，同时在会话中回显摘要 constraints: - 不得编造未出现的事项 - 不得删除原始记录 - 涉及人名一律用岗位代称

这份描述里最值得学的是description里那句“不适用于什么”。写明不适用范围比写明适用范围更能减少误触发。我刚用技能的时候经常遇到“明明只想让它读个文件，它非要给我生成周报”，后来在几个技能的描述里都加了排除条件，误触发率降下来一大截。

4.2 实战一：周报汇总技能从零到跑通

这个技能是我第一个写成的，也是复用率最高的。流程拆开看有五步，每一步都有讲究。

第一步，扫描。指定目录、指定时间范围。这里有个坑：时间范围不能按文件修改时间算，因为有些记录你可能今天才补写上周的。我的做法是在记录文件内部要求以日期开头，扫描时读内容而不是看属性。这一步的产出是一份原始条目列表。

第二步，分组。按项目归类。这里必须给它一个项目清单，否则它会自己发明分类名。项目清单放在项目层指令里，技能执行时自动带上。归不了组的进“其他”，不要强行塞。

第三步，提炼。每组提炼三条以内的关键进展，保留数字与单位。这个“三条以内”是硬约束，不写的话它会给你列十几条，汇报的时候根本讲不完。数字保留单位是因为“提升了 30%”和“提升了 30 个百分点”完全是两回事。

第四步，填充模板。模板放在20_templates/里，技能按模板结构填。缺字段怎么办？我的规则是留空并标注“待补充”，绝不允许它自己脑补。这一点在汇报材料上尤其重要，编出来的内容传出去要出事。

第五步，写入与回显。结果写到输出目录，同时在会话里回显一份摘要，方便你快速确认有没有大问题再去看全文。这一步是人工卡点，别省。

跑通之后，整个流程从原来的一小时压到五分钟，其中四分钟是我在核对。省下来的不是打字时间，是“回忆这周干了啥”的痛苦。

4.3 实战二：文件批处理的技能与它的安全边界

文件批处理是另一类高频需求：一批截图要按规则改名、一批文档要统一转格式、一批表格要合并成一张。这类技能必须带预演模式，也就是先打印出“我打算怎么做”的清单，你确认之后才真动手。批量操作一旦出错，恢复起来极其麻烦。

import os import re import shutil from pathlib import Path SRC = Path("00_inbox/photos") DST = Path("30_output/renamed") PATTERN = re.compile(r"IMG_(\d{8})_(\d+)\.(jpg|png)", re.I) def plan(src: Path): """只生成计划，不动文件""" actions = [] for f in sorted(src.iterdir()): if not f.is_file(): continue m = PATTERN.match(f.name) if not m: actions.append((f, None, "命名不符合规则，跳过")) continue date, seq, ext = m.groups() new_name = f"{date}-{seq.zfill(3)}.{ext.lower()}" actions.append((f, DST / new_name, "重命名")) return actions def apply(actions, dry_run=True): DST.mkdir(parents=True, exist_ok=True) for old, new, note in actions: if new is None: print(f"[SKIP] {old.name} -> {note}") continue if new.exists(): print(f"[CONFLICT] {new.name} 已存在，跳过") continue print(f"[{'PLAN' if dry_run else 'DO'}] {old.name} -> {new.name}") if not dry_run: shutil.move(str(old), str(new)) if __name__ == "__main__": acts = plan(SRC) apply(acts, dry_run=True) # 先跑预演，确认无误再把 dry_run 改成 False

这段脚本没什么花活，但有几个设计点值得说。先 plan 再 apply，两段分开，预演和真跑共用同一份计划，保证看到的就是要做的。冲突检测放在执行前，目标文件已存在就跳过而不是覆盖。跳过项要打印原因，不然你看着少处理了几个文件会一头雾水。默认 dry_run=True，这是最后一道保险，防止手滑直接跑。

技能描述文件里对应的description要写清楚触发场景和排除条件，同时把“默认预演”写进约束里。我一开始没写，结果它直接开跑，把一批文件移走了，好在没覆盖，改回来花了不少时间。

4.4 调试、日志与失败兜底

技能跑不通是常态，关键是要能快速定位。我的做法是三条。第一，每一步都留痕。扫描了多少条、分组结果是什么、哪一步开始不对，打印出来，别让它静默执行。第二，失败要能重来。技能设计成幂等的，重复跑不会产生重复文件或者污染结果，这样调试的时候可以放心重跑。第三，给不可逆操作设卡。移动、删除、覆盖、发送这类动作，一律加人工确认环节，确认方式可以是让它先输出计划等你回一句“执行”再动。

还有一个容易被忽略的点：技能不要写太大。一个技能干五件事，其中一件出问题整个链路就断了，排查起来也费劲。我的习惯是拆细，一个技能只干一件主线的事，需要串联的时候用会话上下文串起来。这样单个技能可测、可复用、可替换，维护成本低很多。

5. 常见问题与排查实录

用这类工具，八成的时间不是花在“怎么用”，而是花在“为什么不行”。这一节把我遇到过的典型问题整理成速查表，按症状分类，配排查顺序。

5.1 连接与权限类：装了但“没反应”怎么查

这类问题最典型的表现是输入之后一直转圈，或者干脆没反应。排查顺序建议从外到内。

排查的核心原则是从最外层往里收：先确认网络通不通，再确认账号能不能用，然后确认模型调不调得动，最后才是具体功能和权限。很多人一上来就在功能层面折腾，结果兜了一圈发现是网络出口的问题。

5.2 输出跑偏：九成的锅在输入和指令

输出不符合预期是最让人挫败的问题，因为每次表现还不一样。我总结下来根因集中在三处：输入没交代清楚、指令互相冲突、上下文太长被稀释。

输入问题的表现是它“理解错方向了”，你给了一堆材料说“总结一下”，它总结成了摘要而不是结论。这种情况改法很简单，把你要什么说清楚：要结论、要数字、要三条以内、每条不超过三十字。指令冲突前面讲过，排查方式是先把所有层级的指令临时清空，只留最小集，然后一层层加回来，看哪一层引入问题。上下文稀释的表现是前面几条要求都做到了，后面几条全部忽略，这时候不是加内容，而是要减内容或者拆成两步走。

提示：遇到输出跑偏，先别改提示词，把同一个任务用最短的话重新问一遍。如果短版反而对了，说明是上下文太长或者指令打架，不是模型不行。

5.3 越来越慢、越来越贵：上下文和调用次数管理

用久了会觉得响应变慢，账单也上去了。原因通常有两个：会话开得太长，以及技能设计得太碎。会话太长会导致每一轮都要把前面的所有内容重新过一遍，越往后越慢。我的习惯是，一个任务一个会话，任务结束就归档，需要延续的时候把结论粘贴到新会话的开头，而不是接着聊三十轮。

技能太碎指的是为了“模块化”把一件事拆成六七个技能来回调用，每次调用都是一次完整的上下文加载，成本翻倍。合理的做法是把强相关的步骤合并成一个技能内部处理，只在需要人工介入或者跨场景复用的地方拆开。衡量标准很朴素：这个拆分的边界，是不是一个需要人确认的决策点？是就拆，不是就合。

6. 跑顺之后，我自己的几条使用体会

这套东西用到现在，我最大的变化不是效率数字，而是工作方式从“想起来再干”变成“定好规则自动跑”。以前周报是拖到最后一刻才回忆，现在每周五下午一句话生成，剩下时间用来核对和补充判断。以前文件归档要挑个整块时间，现在是每完成一个项目就触发一次归档流程。

如果只能给一条建议，我会说：别贪多，先把最烦的那一件事写成一个技能跑通。大部分人失败的原因是想一次性搭个完整体系，写了十几个指令、五个技能，结果每个都不好用，最后全部弃用。正确路径是先找一个每周都在重复、步骤固定、出错代价低的流程，比如周报、比如会议纪要、比如某类文件的整理，把它做成一个能跑通的技能，跑两周，把不顺的地方改掉，再考虑第二个。跑通一个的价值远大于规划十个。

第二条是永远保留人工卡点。再顺的流程，在动作执行之前都留一步确认，尤其是写文件、发消息、改数据这类操作。这不是不信任工具，是因为你自己也有状态不好的时候，你给出的指令本身就可能是错的，多一道确认能兜住这类错误。我吃过这个亏，一次批量改名把一批文件的扩展名改坏了，恢复花了两小时。

第三条是定期清理。指令会越写越多，技能会越攒越杂，授权会越开越大。隔一个月回头过一遍，砍掉不用的，合并重复的，收紧权限。这一步做起来枯燥，但能让整套东西保持可用状态，不至于半年之后自己都看不懂自己写了什么。