你现在正在看的这篇文章，既是AI写的，又不完全是AI写的；既是我写的，又不完全是我写的。是的，至少在写文章这件事上，我已经实现了人机结合。
那就以写文章为例，分享一下我对Prompt、Skill和Workflow的认识，以及把它们真正用起来的过程。
刚开始使用AI写文章时，我也觉得，最重要的是学会写Prompt。而且当时Prompt还是一个很时髦的概念，网盘里到处都是各种提示词大全，甚至一度出现过以Prompt Engineer命名的专职岗位。
写Prompt，说白了就是尽可能把自己的需求、目标和边界描述清楚。例如题目是什么、写给谁看、重点讲什么、采用什么结构，再补上几条“语言自然”“不要编造”“保留作者风格”，全部输入对话框里，AI很快就能生成一版文章。
如果只是玩票性质、表演性质，这样已经够用了。
当然，在这一阶段，我对AI写文章是不屑一顾的，甚至有点厌恶。时至今日，各大自媒体平台上仍然存在这种一眼假的AI文章。我都不由得感叹，这些所谓的作者也是懒到连AI味儿都不愿意去掉，哪怕先随便在GitHub上找个“去AI味儿”的Skill跑一遍，再自己改一改呢。
问题出现在同一类任务反复发生以后。每次修改文章，都要重新交代文章类型、事实边界、表达要求和输出格式，既麻烦，也容易遗漏。于是，我开始保存那些曾经有效的提示词，下一次遇到类似任务就直接复制。
在这一阶段，我研读了数字生命卡兹克的《分享6个平时我最常用的Prompt心法》，确实对我帮助很大。其中有一条Prompt，我实际使用过，还帮助我处理了一次境外投资咨询：
我想探讨【领域】里的【问题类型/场景】。先别回答。
请你先选一位最适合的领域顶尖名人专家来思考它。可以是活人或历史人物，名字可以小众，但必须在该细分领域很专业。如果你不确定该选谁，可以先反问我2个定位问题再选。
先输出1.你选谁，他对应的细分领域2.为啥选他，三句话然后再让我描述详细的问题。
只能说，提示词写得好确实是第一步，而且是很重要的一步。
现在很多AI产品之所以越迭代越顺手，一个重要原因，就是不少过去需要用户反复写进Prompt里的通用要求，已经被做进产品的默认能力或者交互流程中，不需要再由用户逐条手写。
再后来，保存下来的提示词越来越长，也越来越多。针对不同需求去找不同提示词，这个动作本身就是一种负担。而且一旦用一条提示词得到了比较好的结果，就更想继续复用；临场重新写，又总会担心效果不稳定。
这个时候，Skill对我才真正有了用处：把已经验证过的方法保存下来。
安装以后，Agent在识别到相关任务时可以调用对应的Skill，我也可以直接指定使用，不必每次都把原来的整段提示词重新复制进去。
回到写文章的场景。目前这个公众号既会发法律实务文章，也会发一些普通文章，比如这一篇。显然，这两类文章的写法不一样，我对它们的审美和质量评价标准也不一样。于是，我把普通文章和法律实务文章的不同写法整理成了不同的Skill。
不过，有了写作Skill，一篇文章从选题到发布还包括以下环节：
选题需要先讨论，框架需要确认，正文要经过起草、事实核验和反复修改。正文稳定以后，后面还有配图、排版和发布前检查。
这时要解决的，已经不是某一类文章通常应该怎么写，而是一篇文章从想法到正式发布，整件事情应该怎样一步一步往前推进，这时Workflow就出现了。
到这里，我真正需要区分的是三个问题：
这一次具体要做什么？
以后再遇到同类任务，哪些方法不想重新解释？
一整件事情应当分成哪些阶段，又怎样一步一步推进？
这三个问题分别对应Prompt、Skill和Workflow。
它们并不是三个严格平行的技术概念，也不是什么从低到高的三个阶段。Prompt可以写得很长，Skill里面也可以包含多个步骤，Workflow中的每一步同样需要具体Prompt。把它们放在一起讨论，只是因为在实际使用中，它们正好对应三个不同的问题。
一、Prompt先把这一次任务交代清楚
Prompt通常翻译为提示词。但在实际使用中，我更愿意把它理解成：这一次到底要让AI做什么。
任务背景是什么、处理哪份材料、希望达到什么目的、哪些内容不能改、需要参考什么资料、最后以什么形式交付，都可以写进Prompt。
“帮我修改这篇文章”是一条Prompt。
“这是面向法律人的AI科普文章，请检查事实错误，统一产品名称，保留作者已经手工修改的内容和个人化表达，不要改成法律报告，也不要为了显得严谨而加入大段免责声明”，同样是一条Prompt。
两者的差别不只在于长短。后者至少让AI知道，它面对的不是一篇从零开始代写的通用科普文章，而是一篇作者已经深度参与修改、需要继续保留个人声音的文章。
所以，写Prompt最重要的不是堆砌要求，而是把这一次任务真正有用的信息交代清楚：要处理什么，已经确认了什么，哪些地方不能擅自改变，这一次和以前的同类任务又有什么不同。
有些常用要求当然可以保存成模板，一段Prompt也可以要求AI按照多个步骤完成任务。但只要材料、目的和限制条件发生变化，具体要求通常也要跟着调整。
合同审查就是一个很典型的例子。
同样是审查合同，采购合同、销售合同和服务合同的风险重点可能不同；站在买方和卖方立场，结论也可能完全相反。合同有没有附件、业务是否已经接受部分风险、最后需要的是风险清单还是逐条修改稿，也都会影响AI的处理方式。
这不是把原来的Prompt再写长一点就能彻底解决的问题。每一次具体审查仍然需要Prompt，但那些反复出现、已经基本稳定的方法和判断标准，不应该继续只靠临时Prompt保存。
临时问答、修改一段文字、整理一份材料，本来也不需要另外设计一套复杂机制。一条写清楚的Prompt通常已经够用。
只有当同类任务反复出现，其中一些方法和判断标准也逐渐稳定，才需要把它们从一次次临时Prompt中提取出来，交给Skill继续处理。
二、Skill保存同类任务中反复使用的方法
很多个人Skill，确实是从一条不断复制、不断补充的长Prompt发展来的。第一次是针对当前任务临时写，下一次觉得好用就继续复制，反复出现的部分越来越稳定，最后才有必要把它单独保存下来。
一个最简单的Skill可以只有一个SKILL.md文件。但它并不只是给原来的Prompt换了一个文件名。
文件开头的名称和描述，帮助Agent判断这个Skill是做什么的、什么时候可能需要调用；正文再写清楚需要什么材料、按照什么方法处理、输出什么结果，以及完成以后怎样检查。
从使用体验来看，这种简单Skill和一条保存下来、以后反复使用的完整Prompt确实很接近。区别在于，Prompt主要交代这一次任务，Skill开始把同类任务中已经稳定的方法单独保存下来。
任务越来越复杂以后，把所有内容都塞进一个SKILL.md里，很快又会遇到新的问题。参考资料会不断增加，模板和示例需要单独更新，有些步骤还需要运行脚本。这时，就可以把它们拆开放置，再由SKILL.md说明什么时候读取、怎样使用。
这背后还有一个很重要的设计，就是渐进式加载。
Agent通常不会在一开始就把所有已安装Skill的全文都塞进上下文，而是先读取它们的名称和描述。识别到某个Skill与当前任务相关以后，再读取完整的SKILL.md；其中引用的参考资料、模板或者脚本，则等到真正需要时再调用。
这也是Skill现在受到关注的原因之一。它不只是帮助我们沉淀经验，也可以把大量资料留在上下文之外，需要什么再读取什么。
但渐进式加载并不意味着可以放心地把所有东西都写进Skill。
一个Skill被调用以后，完整的SKILL.md仍然会进入当前上下文。如果主文件本身写得过长，把大量只在特殊情况下才需要的资料、例子和说明全部堆在里面，还是会挤占上下文，也可能让Agent更难抓住真正重要的规则。
我在上一篇文章中专门讨论过上下文管理。上下文窗口越来越长，不代表放进去的东西越多，AI就一定越聪明。信息太多、重点不清，AI仍然可能漏掉关键要求，或者被无关内容带偏。
所以，Prompt和Skill不是非此即彼的关系。Prompt里反复出现并且逐渐稳定的部分，可以沉淀为Skill；执行具体任务时，Skill仍然需要结合这一次的材料和要求。至于大量参考资料和特殊处理，则没有必要全部挤进主文件，可以留到真正需要时再读取。
我的文章写作Skill就是这样逐渐形成的。
目前，“法律人周全”分别使用legal-general-article和legal-practice-article处理普通文章和法律实务文章，再用humanizer进行发布前的语言检查。
至于humanizer，当初也是看着它在GitHub上的热度装的，实际用下来，我觉得效果非常平庸。如你所见，这篇文章最后还是需要我一轮轮手动修改。
两类文章都可能从一句“帮我修改这篇文章”开始，但我评价它们的标准并不一样。
法律实务文章需要保留法律依据、适用条件和能够直接使用的实务内容；普通文章则更重视作者声音、真实经历、阅读节奏和自然表达。
如果每次都在Prompt中重新解释这些差异，不仅麻烦，也很容易遗漏。把已经稳定的标准写进不同的Skill以后，我只需要在当前Prompt里交代这篇文章的具体情况。
但把要求写进Skill，并不意味着这套规则从此就固定下来了。
第一篇科技专栏文章写出来以后，我就发现了问题。它明明是一篇面向普通读者的AI科普文章，行文却不知不觉被带回了法律实务报告的结构。概念解释得很完整，观点也不能说错，但读起来像一份研究材料，不像一篇有真实经历和个人判断的公众号文章。
后来，我又在普通文章Skill里补充了科技类文章的专项处理规则，包括产品事实核验、作者声音和真实使用场景等要求。后面的文章继续使用这些规则，再根据实际效果决定哪些保留、哪些修改。
这篇文章现在的修改过程也是一样。
AI先整体修改一版，我再逐段审查。有些修改我会接受，有些会直接删掉，有些则由我重新改写。最后还要对比原稿、AI修改版和我确认的版本，看看哪些方法确实有效，哪些只是AI根据这一篇文章作出的临时判断。
并不是每一次不满意，都需要立刻修改Skill。问题可能出在这一次Prompt没有说清楚，也可能只是当前文章的特殊情况。
只有同类问题反复出现，我的修改方向也比较稳定，才值得把它写进Skill。
三、Workflow把一件事从头到尾串起来
Prompt可以交代这一次要做什么，Skill可以告诉Agent这类任务通常怎样处理。但一篇文章从产生想法到正式发布，并不是把其中某一个环节做好就结束了。
以这组科技专栏文章为例，我并不会向AI输入一个标题，然后等它直接生成可以发布的终稿。
确定文章方向以后，我通常会先围绕真实经历、核心观点和技术边界进行第一轮讨论，再根据回答进行必要的第二轮追问。两轮结束以后确定文章框架，然后才进入起草、事实核验和人工修改。
正文基本稳定以后，才适合提取标题、重点句和配图需求，继续制作封面和正文配图，再完成排版和发布前检查。
这里面存在很明确的先后关系。正文还没确定，就急着做封面和排版，后面只要标题、结构或者核心观点发生变化，相关内容往往都要跟着返工。
所以，现在“法律人周全”的文章生产大致遵循这样的顺序：
确定选题和文章类型 → 补充真实经历与观点 → 确认框架 → 起草正文 → 核验事实 → 人工修改 → 形成稳定版本 → 制作配图和排版 → 发布前复核 → 人工确认发布
这已经不是一条Prompt能够管住的事情了。
Workflow要解决的，不是其中某一步具体应该怎样完成，而是前一步形成什么结果，下一步拿什么继续，哪些步骤可以直接往下执行，到了哪里必须停下来等我确认。
其中每一个环节，仍然可能调用不同的Skill。
进入正文修改时，可以调用普通文章Skill；需要核验产品和技术事实时，可以使用相应的核验方法；正文确定以后，再调用配图和排版相关的Skill。每个Skill执行时，又会收到这一次任务的具体Prompt，比如哪些表达必须保留、需要生成几张图片、采用什么尺寸和风格。
所以，Prompt、Skill和Workflow并不是互相替代的关系。Workflow把一整件事串起来，Skill负责其中某一类任务，Prompt则交代当前这一步的具体要求。
四、三者怎样放进同一套工作中
我现在更习惯这样判断：
只服务于当前任务的具体要求，写进Prompt。
同类任务中反复验证、以后不想重新解释的方法，整理成Skill。
一件事情包含多个阶段，前后又存在依赖关系，再用Workflow把它们串起来。
它们不是三个从低到高的阶段，也不是每一项工作都必须配齐的“三件套”。
临时修改一段文字，一条Prompt通常已经够用。某个要求虽然反复出现，但还没有经过实际验证，也不用急着写进Skill。只有两个简单步骤的任务，同样没有必要专门包装成Workflow。
沉淀经验本身也有成本。
Skill和Workflow建立以后，都需要继续维护。产品能力、工作方法和实际需求发生变化，原来有效的规则可能逐渐失效。如果没有及时更新，它带来的问题甚至比每次重新说明更麻烦。
最麻烦的不是AI偶尔答错，而是它严格按照一套已经过时的规则，稳定地错下去。
所以，沉淀经验是为了减少重复解释和无谓返工，让已经验证有效的方法能够继续使用，而不是把所有临时做法都变成规则文件，更不是搭建一套看起来很复杂、最后却没有人维护的“AI系统”。
Prompt、Skill和Workflow分别处理当前要求、稳定方法和完整流程，但它们最终都要在具体的产品入口中运行。
同一套方法放在网页对话、桌面应用、移动端、CLI或者IDE里，能够接触的文件、工具和权限并不相同，也会直接影响AI究竟能够承担哪些任务。
下一篇是概念介绍的最后一篇：网页版、桌面版、移动端、CLI和IDE这些不同入口，究竟只是界面不同，还是会真正改变AI的工作能力。