桌面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 四个层级的指令与它们的加载顺序成熟的实现一般支持多个层级的指令理解它们的叠加关系是写好的前提。我把它分成四层全局层放长期偏好比如语言、语气、输出习惯、目录约定这些跨项目不变场景层放特定工作类型的规则比如写文档时要求什么结构、做数据分析时要求什么口径、写代码时要求什么风格项目层放单个项目的专属上下文比如这个项目的术语表、干系人、历史结论临时层是单次会话里的交代优先级最高。加载顺序一般是全局 → 场景 → 项目 → 临时后者覆盖前者。理解这个叠加关系能解决一大类困惑为什么我在项目指令里写了“输出用表格”结果还是给我一大段文字多半是全局指令里有“优先使用段落叙述”这类更早加载但被误认为优先级更高的规则或者反过来某一层写得过于笼统把具体的覆盖掉了。我在实际使用中养成的习惯是每层只写这一层该管的事全局层绝不写具体业务规则项目层绝不写通用格式偏好边界一清楚冲突就少。层级管什么典型内容建议长度全局跨项目不变的偏好语言、语气、单位、目录约定、禁用表达300 到 600 字场景某类工作的通用规则文档结构、数据口径、代码风格400 到 800 字项目单项目专属上下文术语表、干系人、已知约束500 到 1500 字临时单次任务的具体交代这次要什么、不要什么、截止条件不限越具体越好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(rIMG_(\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_runTrue): DST.mkdir(parentsTrue, exist_okTrue) 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_runTrue) # 先跑预演确认无误再把 dry_run 改成 False这段脚本没什么花活但有几个设计点值得说。先 plan 再 apply两段分开预演和真跑共用同一份计划保证看到的就是要做的。冲突检测放在执行前目标文件已存在就跳过而不是覆盖。跳过项要打印原因不然你看着少处理了几个文件会一头雾水。默认 dry_runTrue这是最后一道保险防止手滑直接跑。技能描述文件里对应的description要写清楚触发场景和排除条件同时把“默认预演”写进约束里。我一开始没写结果它直接开跑把一批文件移走了好在没覆盖改回来花了不少时间。4.4 调试、日志与失败兜底技能跑不通是常态关键是要能快速定位。我的做法是三条。第一每一步都留痕。扫描了多少条、分组结果是什么、哪一步开始不对打印出来别让它静默执行。第二失败要能重来。技能设计成幂等的重复跑不会产生重复文件或者污染结果这样调试的时候可以放心重跑。第三给不可逆操作设卡。移动、删除、覆盖、发送这类动作一律加人工确认环节确认方式可以是让它先输出计划等你回一句“执行”再动。还有一个容易被忽略的点技能不要写太大。一个技能干五件事其中一件出问题整个链路就断了排查起来也费劲。我的习惯是拆细一个技能只干一件主线的事需要串联的时候用会话上下文串起来。这样单个技能可测、可复用、可替换维护成本低很多。5. 常见问题与排查实录用这类工具八成的时间不是花在“怎么用”而是花在“为什么不行”。这一节把我遇到过的典型问题整理成速查表按症状分类配排查顺序。5.1 连接与权限类装了但“没反应”怎么查这类问题最典型的表现是输入之后一直转圈或者干脆没反应。排查顺序建议从外到内。症状最可能的原因排查动作登录卡住或超时网络出口策略未放行确认需要的域名和端口找负责网络策略的同事能登录但对话无响应模型调用链路不通用最简单的问题测试看是否返回能对话但读不到文件目录绑定路径不对或权限不足检查绑定的是父目录还是目标目录手动创建测试文件验证能读但写不进去输出目录无写权限或磁盘满换一个目录测试检查磁盘剩余空间快捷键没反应与其他工具冲突换一个组合键先关掉同类工具验证某个服务连不上该服务的授权未开或已过期逐个检查授权状态重新授权排查的核心原则是从最外层往里收先确认网络通不通再确认账号能不能用然后确认模型调不调得动最后才是具体功能和权限。很多人一上来就在功能层面折腾结果兜了一圈发现是网络出口的问题。5.2 输出跑偏九成的锅在输入和指令输出不符合预期是最让人挫败的问题因为每次表现还不一样。我总结下来根因集中在三处输入没交代清楚、指令互相冲突、上下文太长被稀释。输入问题的表现是它“理解错方向了”你给了一堆材料说“总结一下”它总结成了摘要而不是结论。这种情况改法很简单把你要什么说清楚要结论、要数字、要三条以内、每条不超过三十字。指令冲突前面讲过排查方式是先把所有层级的指令临时清空只留最小集然后一层层加回来看哪一层引入问题。上下文稀释的表现是前面几条要求都做到了后面几条全部忽略这时候不是加内容而是要减内容或者拆成两步走。提示遇到输出跑偏先别改提示词把同一个任务用最短的话重新问一遍。如果短版反而对了说明是上下文太长或者指令打架不是模型不行。5.3 越来越慢、越来越贵上下文和调用次数管理用久了会觉得响应变慢账单也上去了。原因通常有两个会话开得太长以及技能设计得太碎。会话太长会导致每一轮都要把前面的所有内容重新过一遍越往后越慢。我的习惯是一个任务一个会话任务结束就归档需要延续的时候把结论粘贴到新会话的开头而不是接着聊三十轮。技能太碎指的是为了“模块化”把一件事拆成六七个技能来回调用每次调用都是一次完整的上下文加载成本翻倍。合理的做法是把强相关的步骤合并成一个技能内部处理只在需要人工介入或者跨场景复用的地方拆开。衡量标准很朴素这个拆分的边界是不是一个需要人确认的决策点是就拆不是就合。6. 跑顺之后我自己的几条使用体会这套东西用到现在我最大的变化不是效率数字而是工作方式从“想起来再干”变成“定好规则自动跑”。以前周报是拖到最后一刻才回忆现在每周五下午一句话生成剩下时间用来核对和补充判断。以前文件归档要挑个整块时间现在是每完成一个项目就触发一次归档流程。如果只能给一条建议我会说别贪多先把最烦的那一件事写成一个技能跑通。大部分人失败的原因是想一次性搭个完整体系写了十几个指令、五个技能结果每个都不好用最后全部弃用。正确路径是先找一个每周都在重复、步骤固定、出错代价低的流程比如周报、比如会议纪要、比如某类文件的整理把它做成一个能跑通的技能跑两周把不顺的地方改掉再考虑第二个。跑通一个的价值远大于规划十个。第二条是永远保留人工卡点。再顺的流程在动作执行之前都留一步确认尤其是写文件、发消息、改数据这类操作。这不是不信任工具是因为你自己也有状态不好的时候你给出的指令本身就可能是错的多一道确认能兜住这类错误。我吃过这个亏一次批量改名把一批文件的扩展名改坏了恢复花了两小时。第三条是定期清理。指令会越写越多技能会越攒越杂授权会越开越大。隔一个月回头过一遍砍掉不用的合并重复的收紧权限。这一步做起来枯燥但能让整套东西保持可用状态不至于半年之后自己都看不懂自己写了什么。