提示词、Skill、Agent和工作流的碎碎念
写在开头
这一篇经过高强度使用和学习使用AI的随笔，或者是碎碎念，陈述的都是个人观点，仅作个人学习阶段性的记录。
心得提炼之后，其实就是这几句话：
- AI在某些程度上，让作为一个半桶水的工程师编程一个一桶水工程师。
- 高强度的和AI协同，会和刷短视频一样，令人疲倦和头疼，因为我需要为产出物负责，需要一遍又一遍校对AIGC的内容。
- 在应用的层面上，提示词的技巧有用，但并不太有用。
- AI协同工作，并不会改变你在必须在办公室待够十多个小时的工作时间，甚至会出现额外要求一天处理之前三四天的工作内容，这种情况。
提示词工程的原则
随着Ai的进一步发展，作为头部的Anthropic推出了一系列的Ai相关教程，围绕其Agent，Claude完善衍生出了一套和提示词相关的理念或原则。
提示词是由自然语言描述的命令，Ai能够通过底层的大参数模型解析推演命令意思，并执行。
但这个解析推演的过程是高度抽象和数学化的，是基于庞大的历史数据进行机械学习演化的能力。
其中Anthropic的提示词原则简洁的提炼出来一共有以下的几个点：
- 少量样本好于描述
- 明确标准好于模糊指令
- 访谈模式提前收集信息
- 使用链条规划工作流
- 验证和带反馈的重试设定
- 冲突解决模式(即自我矛盾纠正)
从上述Anthropic总结出来的原则上，能够提炼出一个观点：用精准的场景化、流程化、工程化的角度构建提示词。
不用层级的原则实践
Anthropic提示词的原则作用于全局，包含了Agent、skill、query（用户提问）三个层级。
这三个层级分别因为agent的设计，能够在不同的工作流程的颗粒度上发挥积极的作用。
Agent 层级
这个层级的代表文件是 AGENTS.md 和 CLAUDE.md 两个代表性的文件：
Agent是一个作用于整个工程项目空间的规则性描述，工作流程化就是在这个位置进行编排，并且包含了一些通用的安全性描述和标准声明。
受限于Agent.md本身的属性：一个先验性的指导自然语言描述，所以很多时候对于在Agent添加什么内容效果会比较好，是没有答案和参考的。
故此，应该用测试的结果或重复处理的测试方法，来评判Agent是否真的起作用。
Agent经过高度抽象之后，从流程、上下文、约束、规范、复杂场景拆解等事情上总结下来就是：现在是什么情况，要用什么方法，解决什么问题。
Anthropic的经验实践的总结，Agent一套明文规定的采用自然与书写的决策说明书。
提供一个仅供参考的大框架，通过自然语将判断对错、好和坏等对立的标准确定下来，之后才是针对于工作细节进行填充，什么环节参考什么节点的Skill工作环节说明，有哪些工具是能够派上用场。
在纯粹的效果导向的视角中，
一个比较合理的Agent能够结合skill、tools、甚至是hook，共同组成一个半自动化的工作流程，处理特定的工作。
在整个Agent工作的系统中，Agent将会将自然语言的编排（Agents.md）发送到LLM中，相当于省去了最开始初始化和磨合阶段。
这些都是框架之下进行填充的骨肉部分，是额外的、属于隐形知识的范畴。
Skill 层级
Skill从文件内容的表现（大概的核心结构、分层次的设计）形式上和Agent是基本一致的，同样也遵守提示词原则设计逻辑。
和Agent的区分是：skill只对某个具体的工程流程节点负责，是用于指导具体工作环境要如何进行的说明，除了主干 skill.md 之外，还有其他的scripts 草稿、references 参考模版、examples 参考 或者是相关联的tool 工具、Hook 钩子这些额外的部分辅助。
这部分额外的辅助资料，不外乎都是在对抗LLM本身的缺陷，LLM本质是数字化的推理生成，并没有决定性的决策框架，所有的一切都来源于外界输入。
既然一切源于外在，那就说明内在的混沌是无法真正避免的，Skill的职能和其在整个AIGC中的生态位置，就是要向补充完善，在面都实际的有特点的问题时，应该如何解决和处理。
比如进行方程式计算、数据统计、或修正更新文档。
以更新文档这类工作场景作为例子。
一个文档更新的责任人处理的逻辑是：
- 确定更新内容。
- 确定更新相关的文档和具体位置
- 游览更新要点的上、下文本逻辑连通和一致性表述。
- 对内容更新，确定更新后效果。
在这个逻辑中，更新的行为始终在为一个没有明说的需求驱动，这个需求就是对信息及时性和文档准确性的追求和责任，这是当前实际工作场景之下具体需求。
Ai是没有这个需求驱动的能力，自然就是按部就班的执行自然语描述的工作环节。
而思考模式、thking等能力就是为这种缺失需求驱动的工作流进行兜底的产物，像人的神经网络那样工作，反思工作中的内容。
AI的自动化流水线依旧像是来料加工的流水线一样，严格意义上来说，以目前我的技术水平还没有办法装载自动化的流水线工程，被需求驱动这个举措还是需要一个触发条件，不论触发条件来源于AI还是人工。
在向AI转化工作流程和经验的时候需要这样：
- xx部分已经过时了，xxx是新的内容。
- 现在需要将过时的内容更换成新的内容
- 并且进行一轮矫正和逻辑检查，矫正的标准是xxx，逻辑重点是xxx。
满足需求驱动的注入、新旧概念的确定、要完成的动作、对于动作的标准，和工作中的重点。
这部分提示词演化之后，细化，按照近似工程的排列起来，就是一个Skill，技能。
skill就像产品说明书一样，告诉AI在一个完全陌生空白的环境中，任务的某个环节要如何解决和处理。
在Skill中明确指定的标准和示例就是对应：
- 提供少量样本优于描述
- 具体标准好过模糊
但是话又说回来，LLM本身的幻觉是不可避免的，然和利用工程化或者是控制的手段，约束一个混沌系统，不亚于中世纪女巫药罐子里到底要怎么炼制感冒药一样不可靠。
LLM的价值是在于解放人的重复劳动部分，实际最终的核心依旧是提高生产效率，解放人力，让人的精力能够被放置在更有价值或更需要的地方中，而不是所谓的替代人工论。
用户提示词
用户提示词如果按照作用级别来说，是最高级的来自于用户的直接输入，但他的作用效果有可能并不会对skill和agent进行覆盖。
在LLM中存在不同性质的提示词，比如其中的skill或agent的提示词会被标记为 system ，而用户的提示词是 user。
LLM的注意力是有限的，通常在开头和结尾的内容要更加有效，skill和agent就是在会话开始的时候被封装到消息中，按照LLM的工作和实践经验，通常在用户层面会出现LLM明显更加倾向于Skill和Agent上的内容。
LLM阶段性使用总结
当前对于agent、skill、query三个不同的提示词作用层级的划分是受了工程化和规范化的影响，实际在LLM工作中，三者的概念和能力划分都是模糊的。
花费足够多的时间和对话，以及多次 query 输入矫正，也能够起到相同的效果，只是无法被其他会话复用。
skill和agent就是为了将工作流程或者是工作说明等，这部分细节的内容沉淀之后的产物，是实际工作流的文字抽象。
既然是抽象，就会存在抽象后的损失。
再结合LLM本身的理解能力差异、语义差异、对最终的效果会有浮动产生。
越是精细的skill或agent，多少回触发边际效应，投入和产出不成正比。且整个工作流都失去灵活性，趋向一种静态化，需要额外的设置示例，才能够处理额外的情况。
个人感觉
当前关于文档工作流的情况是：
文档重点是为读者提供技术示例，说明，对于可用性要求较高，及时性较弱。
且对于格式要求严格，需要兼顾一些文档站点中的css标签。
在利用agent进行更新、审计、检查、校对等工作时，需要额外的通过渲染器观察效果。
人工校对在整个工作流中依旧占据主导。
持续的投入Token让AI矫正skill或者是agent，在缺乏一些知识支持的时候，容易陷入到bug越改越多的情况，且黑箱也越来越大。
无法理解，超出认知之外的部分，也就无法控制，工程化的控制理论在这部分也就失去的意义，人是没有办法先知先觉的了解所有可能的生产故障或细节。