“新高端职业：编写技能而非制作幻灯片”这句话，我第一次看到时觉得有点像是在制造概念焦虑。但后来仔细观察自己和周围人的工作方式，发现它戳中的不是表面上的“幻灯片该不该做”，而是整个职场人在AI时代重新分工的问题：到底什么样的劳动，会在未来变得稀缺、值钱、难以替代？
如果你花了一整天，把一份报表做成了精美绝伦的PPT，明天发出去，后天就没人再看。但如果你花了一整天，把一个三天才能跑完的数据处理流程，编写成一个以后只要双击就能完成的技能，那它会在未来几年里持续为你创造价值。从“制作幻灯片”到“编写技能”，本质上是两种职业逻辑的切换：前者是一次性的展示型劳动，后者是可复用的系统型劳动。这篇文章，我想把这个判断拆开讲清楚。
1. 为什么“制作幻灯片”突然不够用了
1.1 一次汇报背后，是大量不可复用的劳动
我见过很多优秀的职场人，尤其在企业里做分析、做运营、做管理的朋友，经常陷入一种循环：接任务、做分析、做PPT、汇报、通过，再来下一个任务。他们最常抱怨的，不是任务太难，而是“又从头来一遍”。
举个例子。一个做用户运营的同学，每周都要给领导汇报竞品动态。他每周花半天时间到处找竞品上线了什么功能，截图，贴进PPT，写一句“值得关注”。看起来每周都在做“新”的东西，实际上其中的流程是一样的：搜索信息、筛选重点、整理成结构化表达。真正发生变化的是信息内容，而不是处理逻辑。可悲的是，这周做完，下周从零开始。上一周找到的信息源、筛选标准、表达框架，全都没有沉淀下来。
这不是他不够努力，而是他被困在了“制作幻灯片”这个范式里。幻灯片的本质是展示，是给人看的最终输出。它默认每一张都是新的、每一次都是不一样的。但真实工作中，有大量看起来定制化、实际上高度重复的任务。
1.2 从“展示结果”到“生产结果”的范式转移
过去我们写PPT，是因为没有人能把过程自动化，所有判断都要靠人来做，所以人和人之间需要通过幻灯片来同步认知。但现在，AI和自动化工具已经可以在很多环节直接生产结果，比如生成初稿、清洗数据、整理摘要、生成图表。
当工具可以生产结果时，稀缺的就变成了“如何定义生产规则”。换句话说，过去我们竞争的是谁能把结果表达得更好，现在竞争的是谁能把结果生产得更快、更稳定、更可复用。
“编写技能”说的不是让你去写多么复杂的代码，而是让你有能力把一类任务的执行过程，变成一套别人也可以使用、机器也可以执行的方案。幻灯片是静态的，它记录的是已经发生的事情；技能是动态的，它面向的是未来同类的事情。
1.3 旧范式的隐藏成本：时间黑洞与知识流失
做PPT并不可怕，可怕的是大量隐性知识跟着PPT的关闭而流失。你今年做了一份非常漂亮的年度复盘PPT，记录了项目为什么成功、数据为什么上升、用户为什么活跃。但明年换一个人来做，他不知道你当时是怎么筛选数据的，也不知道为什么某个指标被排除了，更不知道你在分析过程中做了哪些假设。他只能看到PPT的结论。那些真正有价值的中间判断、思考路径、取舍逻辑，全都丢了。
这就是知识流失。而编写技能，恰恰是把中间过程固化下来。它不一定是一个完整系统，可能只是一个模板、一个检查清单、一个脚本，甚至是一条经过设计的Prompt。关键是下一次执行时，不需要重新发明一遍，只需要调用、微调、验证。
2. 技能编写者到底在“写”什么
2.1 技能不只是脚本，而是一个“可执行文档”
很多人一听到“技能”这个词，会想到编程语言、自动化脚本、爬虫。这确实是一种形式，但技能的范围要宽得多。
一个技能，可以是一套处理客户投诉的SOP，可以是一个自动生成周报的Prompt模板，可以是一个批量重命名文件的脚本，可以是一个设计智能体工作流时的节点配置。它本质上是把“如何做一件有明确规则的事情”记录成可重复执行的形式。
和幻灯片相比，技能有三个特征：
- 有明确输入：它知道接收什么格式的数据、什么范围的信息。
- 有清晰处理规则：它不是靠灵感和临场发挥，而是固化了判断逻辑。
- 有验证机制：它能判断输出是否符合预期，至少能发现问题。
过去我们写文档，是写给人“看”的；现在编写技能，是写给“人+机器”共同执行的。因此，技能要处理的不只是内容，还包括边界、异常和容错。
2.2 技能编写的四层结构
我把它拆成四个层次，从低到高是：
第一层：拆解任务流。你要把一个看似复杂的任务，拆成更小的步骤。比如“做一份销售周报”，可以拆成：读取销售数据、清洗无效记录、按区域汇总、计算环比变化、生成摘要、输出表格。
第二层：定义处理规则。每一步要做到什么标准，用什么方法。例如“清洗无效记录”的规则是：删除状态为已取消的订单，剔除交易金额为0的记录，保留数据更新时间在最近7天内的数据。
第三层：选择合适的执行工具。有些步骤用脚本更稳，有些步骤用Excel公式就够，有些步骤用AI助手处理文本摘要更快，有些步骤可能需要几个工具配合起来。技能编写者不一定自己写所有工具，但一定要知道每种任务该交给什么工具。
第四层：封装与验证。把步骤串起来，设计输入接口和输出格式，并且用至少一组真实数据去验证。如果跑通了一次，只能说实验成功；如果换一组数据也能跑，才算是技能。
很多人的误区是，一上来就追求“写一个自动化程序”，结果被工程细节困住。其实技能的核心不是程序代码，而是你对任务本身的理解。你把任务拆得越清楚，规则定义得越准确，后面无论用什么工具实现，都不会跑偏。
2.3 人人都能编写技能吗
如果把“技能”等同于“专业软件开发”，那确实不是人人都能做的事。但如果理解为“把重复劳动变成一套可复用流程”，这件事的能力门槛其实没有那么高。
关键在于你是否具备三种思维：
- 拆解思维：能不能把一个模糊的任务变成明确步骤。
- 标签思维：能不能给输入、输出、规则打上清晰的标记。
- 迭代思维：能不能接受第一次不完美，然后小步快跑地改进。
我见过一个完全不会编程的行政同事，用Excel函数、模板和截图工具，把每月要做的十几张报表精简成了三个固定步骤。她也算在编写技能。真正阻碍普通人的，不是技术基础，而是长期以来习惯了“每次重做”的思维惯性。
3. 判断一个技能是否值得写的三条标准
不是所有事情都值得编写成技能。写技能本身也有成本，如果你花三天写一个以后可能只用到一次的东西，那大概率是亏的。我一般会用三条标准来判断。
3.1 第一，是否高频重复
这里说的高频，不是绝对次数，而是相对你时间的价值。比如你每周都要做一次数据汇总，一个月四次，一年四十八次。如果每次做要两小时，一年就是九十六小时。用十小时把流程固化成技能，即使不节省人工时间，它至少能降低你的认知负担。这类任务，值得写。
反过来，如果你一年只做一次述职报告，而且每次内容、形式、对象都不一样，那就不值得设计成一个固定技能。这种情况，更应该用写作模板或结构化思考来辅助，而不是试图自动化。
3.2 第二，是否有明确规则
技能最怕的是“没有规则”。如果一件事情连人类处理的时候，都是靠直觉、靠灵感、靠现场判断，那你很难把它变成可重复的流程。比如“构思一个新产品的创意”，这个就没有明确规则，不适合写成技能。但“搜集竞品前十条用户差评并归纳为五个痛点”，规则就明确得多。
这里有一条重要边界：规则不是说不能变，而是说在“当前你能想象到的场景”里，它足够稳定。如果你发现每次执行的时候判断逻辑变化很大，那就说明它还不是一个成熟技能，需要先做知识整理，而不是强行自动化。
3.3 第三，结果能否自动验证
这条经常被忽略。一个技能要做成自动化或半自动化的流程，必须有一个反馈机制，让你知道输出对不对。
比如你写了一个自动生成周报的技能，如果它能跑完就算成功，那这个技能未必可靠。更好的情况是，它能检查数据是否更新、汇总行是否缺失、环比是否有异常值，然后抛出提示。没有验证机制，技能跑得越快，错得越离谱。
这也是为什么很多人用脚本明明跑通了，却不敢交付的原因：他们不确定在输入变化的时候，输出是否还正确。因此，真正值得写的技能，一定要包含一个验证步骤，不管是用日志、断言，还是简单的人工抽检。
下面是我常用的判断表，供你参考：
| 判断维度 | 值得写 | 观望 | 暂时不写 |
|---|---|---|---|
| 频率 | 每周至少一次以上 | 每月一次 | 一年一次或更少 |
| 规则清晰度 | 处理步骤明确，输入输出稳定 | 大部分规则清晰，但边缘情况多 | 高度依赖临场判断 |
| 结果验证 | 可以自动或半自动校验 | 需要人工仔细核对 | 几乎无法判断好坏 |
| 维护成本 | 少于手工执行节省的时间 | 偶尔需要调整 | 每次使用都要改 |
4. 从零开始编写你的第一个技能
如果你已经被前面的道理说服，现在想动手试试，我建议你不要从大项目开始，而是从一个小到不能再小的任务开始。关键是先跑通一个完整的“输入到输出”闭环，建立起对技能的体感。
4.1 从最小技能开始
挑一个你本周就要做的重复性任务。不要挑那种特别复杂的任务，宁可小，也不要难。比如“把下载的文件夹里所有图片压缩到80%宽度”“把一堆txt日志合并成按日期分类的目录”“让AI帮你把口语化笔记改写成结构化周报”。随便选一个，只要能在一小时内完成，并且你确定以后还会用到就可以。
我自己最初练习的技能，是一个自动整理下载文件夹的脚本。规则极其简单：按文件类型建立目录，然后按时间移动到对应目录。虽然简单，但这个任务让我体验到了“技能”的基本单位是什么：输入是一堆乱糟糟的文件，处理规则是类型和日期，输出是整理好的目录结构。
4.2 用“人先跑一遍，再让机器跑”的方法
很多人学自动化，习惯先去找工具、找代码，然后对着别人的方案改。我更建议反过来：先把你在手工处理时做的每一步写下来。
拿“制作竞品周报”举例，手工流程是：
- 打开竞品官网和公众号，查看本周更新。
- 记录新增功能点。
- 判断对自身业务是否有影响。
- 将结论写成一段摘要，并附上截图。
如果你能写出这三到五步，你就可以把它翻译成技能逻辑。步骤1可能依赖爬虫或RSS订阅，步骤2需要结构化存储，步骤3作为判断规则，步骤4通过模板生成报告。你不用一次完成全部自动化，哪怕只把步骤4做成一个模板，就比每次从空白页开始要高效得多。
关键是要用“话术”去写规则。比如：
- 如果某功能提到支付、交易、订单，则标记为“商业化相关”。
- 如果某功能涉及移动端体验，则标记为“体验升级”。
- 如果三天内没有新增功能，则写“本周无重要更新”。
这些规则写出来的时候，你就已经成为一个技能编写者了。
4.3 为什么说“能跑通”和“能复用”是两回事
第一次写出来的技能，大概率只能处理你设想中的标准情况。你能跑通一次，不代表它可以长期稳定使用。真正的分水岭，是你开始考虑以下三个问题：
- 输入边界：如果输入是空文件、乱码、异常值怎么办？
- 规则漂移：如果数据格式变了一点，结果会不会崩？
- 维护责任：下次使用的时候，你还记不记得这个技能是怎么设计的？
解决这些问题不困难，但需要你建立版本意识。我给自己的最低要求是：技能使用的关键配置文件或Prompt模板，我会写清楚“最后更新时间”和“适用场景”。当发现它跑不通时，我会先看是不是输入格式变了，再看是不是规则需要调整。这让我避免了很多反复试错的时间。
5. 故障排查：为什么你的技能总在关键时刻掉链子
技能一旦用起来，你会遇到各种问题。常见的情况是：上周还能正常跑，这周换了数据源就报错；或者别人用你写的技能，结果完全不对。遇到这些问题不要急着怀疑人生，大多数时候是这四类原因。
5.1 先看输入是否比设计时更复杂
技能的设计往往是基于你常见的输入。但真实世界里的输入，很容易出现你没考虑过的情况。比如日期格式从“2025-02-01”变成了“2025/2/1”，或者数据列名从“销售额”变成了“销售金额”。一个成熟的技能，应该在入口处有一个“数据校验”环节，把输入格式先做统一。如果你没有做，那么排查时就先检查输入文件、输入参数、输入Prompt是否和设计时一致。
5.2 再看规则是否有“硬编码假设”
这是最容易忽略的问题。你的规则里可能藏着某些一次性的假设。比如：
- 假设销售数据一定从第3行开始读；
- 假设城市列表中只有北上广深；
- 假设产品名称不会出现重复；
- 假设汇报模板标题永远是“2025年X月”。
当这些假设被打破时，技能就会出问题。排查的时候，把技能内部所有写死的值列出来，逐一问自己：这个值在未来会不会变？如果会变，就应该变成参数，或者拆成配置项。
5.3 再看输出是否被人工接续
有的技能看起来是自动化的，实际却是半成品。它输出了一份中间文件，后面还有大量人工操作。比如自动生成了表格，但表格里的结论还需要人逐条去看才能定稿。这不能叫失败，但它意味着技能的责任边界没有划清楚。如果设计时明确了“技能只负责数据整理，不负责判断”，那反而问题不大。怕的是你一直以为是全自动，结果有一天它输出的数据没有经过人工复核，直接导致错误结论。
所以我建议，每个技能在设计时，都要明确一个问题：哪些环节机器负责，哪些环节人负责。这个人机边界如果写不清楚，技能越强大，隐患越大。
5.4 最后看维护成本是否失控
一个技能突然失效，也许不是因为逻辑错了，而是因为它已经太久没更新了。维护成本失控的典型表现是：你听到“技能又跑了半小时”就头疼，因为你不知道哪里会出问题；或者你需要每天手动改规则，才能让它跑通过。
这不是你的错，而是你选的场景可能并不适合完全自动化。有些任务变化频繁，最佳状态是半自动：机器处理固定的部分，人来处理变化的判断。维护成本失控时，你应该做的不是继续打补丁，而是重新评估这个技能是否值得维护。
6. 技能编写者的长期价值与边界
6.1 一个技能库，相当于一个私人“可复用员工”
如果坚持半年到一年，你会发现你不只是在处理单个任务，而是在积累一个技能库。每一个技能，都是一块能力模块。单个技能的价值可能有限，但它们组合起来，会形成一种新的工作方式：
- 你不需要什么都从零开始。
- 你可以把注意力放在更上游的问题定义上。
- 你遇到新任务时，第一反应是“这里面哪些可以复用已有技能”。
- 你的工作成果不再只是一份份报告，而是一套不断生长的系统。
这种能力，很难被一次PPT所衡量，但它会让你的工作越来越轻盈。你不需要每天加班去做重复劳动，因为过去积累的技能在替你兜底。
6.2 它不是取代人，而是把人的判断放在更上游
有人担心，如果大家都编写技能，那还需要人做什么？这种担心其实是误解。技能替代的是重复执行，而不是判断和洞察。一个技能可以自动生成一份趋势分析报告，但它无法替你想清楚“为什么这个指标掉下去了”“要不要调整业务策略”。后者需要的是经验、直觉、对业务的理解和敢拍板的勇气。
所以技能编写者的角色，更像是“系统的定义者”。你把目标设定好，把规则设计好，把验证机制建立好，然后把执行交给机器。人不仅没有被取代，反而站到了更有价值的位置上：不再当执行者，而是当设计者和决策者。
6.3 什么情况下，不需要执着于编写技能
写作边界也要说清楚。并不是所有工作都适合技能化。
- 如果你的工作内容高度模糊，连你自己都不知道下一步该干什么，这时候更应该做的是提升认知和探索能力，而不是急着写技能。
- 如果你所在的行业变化极快，上个月总结的规则下个月就失效，那技能维护成本可能高于手工操作。这时候，不如采用极轻量的模板，把变化的部分留给人工。
- 如果你本身只是想在某个领域偶尔体验一下，那完全不需要把每一份任务都制作成技能。技能是长期主义者的工具，不适合所有性格。
但即使不适合全员技能化，我认为有一个能力是所有人都值得练的：在做事之前，先想一想这件事会不会重复发生，值不值得沉淀。哪怕只是多写一个检查清单，也是一个微观技能。
说到底，制作幻灯片不是原罪，真正的问题是太多人在应该“编写技能”的时候，却只能依赖“制作幻灯片”来证明自己的价值。新高端职业不是一句口号，而是对工作方式的一次重新排序：把展示型劳动交给工具，把自己留给定义问题、编写规则、验证结果和持续改进。如果你也想切换到这个模式，现在最好的时机，就是从手边那个已经让你重复做完第三次的任务开始。把它拆开，把流程写下来，把规则讲清楚，然后交给一个能自动执行的容器。哪怕今天只完成一小步，你拥有的也不再是一份成果，而是一个可以不断生长的能力单元。
