最佳实践
清晰的表达结构：
- 通过换行，空行表达来区分要执行的具体内容，类似文章编写流程
- 明确的分隔符：使用ai能理解的分隔符，例如 [] , ``` ```，<> 来区分的内容：
- 用户输入
- 概念内容
- 表达格式
- 固定格式输出：告诉 AI 输出对应格式的内容：html, json
- 拆解任务步骤：给出明确清晰的任务步骤：步骤1 - xxx ，步骤2 - xx
- Few-shot：给出正确答案实例，再让AI回答
更长的思考窗口
给AI足够的思考时间，ai在输出的过程中会思考，更长的思考窗口期有利于后续生成结果
- 让 AI 先分析问题，再给出答案，可以的话在和现有答案比较对错
- 先解释问题内容/ 分析问题，再回答结果
- 结合任务拆解来进行表达，先思考后解答
迭代
好的提示词是在不断迭代中去逐步完善的，就和功能迭代类似的概念
在日常开发中，我会经常迭代自己的提示词，不断完善和参考，假如我们要用 AI 去做一件没有多少经验的事情，提示词迭代是必不可少的步骤，通过完善提示词我们可以在后续得到更好的输出结果，并形成自己的一套工程实践和方法论。
- 给出清晰的提示词内容
- 分析哪些内容导致无法达到期望的输出
- 长度是否限制：基于 token 分词，所以最终输出结果可能会存在偏差
- 是否对输出结构和内容有要求
- 最佳实践是否应用
- 重写表述内容和提示词
重复上述步骤，达到想要的结果
摘要
让大模型生成内容摘要，协助我们概括内容，减少阅读理解的时间
- 指定生成的内容：更精炼的关键内容，关键词，长度限制
- 指定生成的目标：查看该内容的人或对象是谁，方便 ai 提取合适的关键信息
内容推理
类似摘要功能，但是是对更深层东西的表达
例如情绪的处理和表达，对关键词的提取，便于对用户进行行为分析，产品改进和内容推理
- 让模型统计关键词出现次数
- 让模型判断用户评论的情绪表达，内容含义
- 可以结合json输出，方便后续对用户内容进行处理
内容翻译/转换
大模型非常适合用于做内容翻译和内容转换操作，用于日常沟通翻译和代码内容转换
- 语言识别：让模型识别输入的内容是什么语言/计算机语言
- 语言翻译：让模型讲输入内容翻译为其他语言/计算机语言
- 把英语翻译成法语/中文
- 把 JS 代码用 Python 格式重写一次
- 语法检查：让模型检查输入内容的语法是否正确/符合特定场景的要求
参数 - 温度（Temperature）
Ai 配置时有一个温度的选项
温度越高，ai的表达随机性就越大，但结果准确率也会有所下降（类似于语言表达会更热情）适合于邮件编写，日常沟通等场景
温度越低，ai的表达就越固定，输出答案的结果也会高度一致（类似于语言表达的死板，像背答案一样），适合于学术研究，编程等场景
参数 - 角色
在日常 Ai 聊天中，为了使ai存在记忆
通常会对话上下文一起发送给 ai
日常看到的对话消息格式在代码中的表示是：
plain
const message = [
{
role：'assistant'
content：''
},
]即调用 ai 时，会通过一连串的上下文消息来完成对话流程
Role 即是当前消息的角色，可以理解成餐厅里的服务员，顾客这种角色定位
Content 即是当前角色本次对话的内容，类似于在点餐时候每个人的对话
Role 角色分为 3 类
- user：用户本身，即我们输入的信息，也可以理解为 喂给 ai 的 prompt
- assistant：即 Ai 助手本身，代表当前内容是 Ai 输出的
- system：系统角色，其对应的 content 也是常说的 system prompt，代表 ai 的角色定位，这部分内容对用户不可见，但是 ai 会根据对应的 prompt 提示词来规范自己的消息回复，在设计插件起到非常重要的作用，可以参考豆包插件，以及 vscode cline 插件的源码设计
如上所述，记忆上下文是当前完成 AI 大部分功能的前提，例如 RAG 的引用，Agent ，插件等
由于需要携带大量对话信息，会导致 token 被大量消耗，因此目前如何管理，精简提取上下文（例如 GPT5-Codex)，减少 token（你的 dollar） 消耗也是 AI 对话优化的一个方向
工具调用Toolcall Toolresponse
提示词工程：怎么编写更好的提示词让ai输出想要的结果
上下文工程：怎么精简和优化管理的上下文，保证结果不会跑偏
这个概念存在于 Agent 机器人本身，Agent可以简单理解为带有工具函数的聊天机器人
Agent将消息以及自身有的工具整合给 LLM，LLM 会根据情况回复是否调用工具来完善结果（网络搜索）/执行操作（修改文件）
toolcall 就是对工具的调用，会包含调用工具函数名，调用的参数，agent 会根据函数名和参数，调用真正的函数执行对应的操作，然后得到结果返回
toolresponse 指的就是返回的结果
这个过程可能持续好几轮对话，直到 LLM 觉得可以了，就会把结果整合，返回给agent，最终给到用户本身
上下文工程
但是工具调用会产生过长上下文，这时就需要有些功能约束 Ai 行为，避免ai 生成不符合结果的输出，因此需要一些方案来规范，精炼上下文内容
- 笔记工具：给 ai 提供记录工具函数，让ai 拆解任务并写下任务清单和关联信息，之后根据任务清单逐步完成和更新步骤，完成后，步骤内容会被插入开头和结尾（transformer 模型对开头和结尾内容较为关注）
- 信息丢弃：丢弃不重要的信息，通常会丢弃中间，保留开头和结尾比较的提示词，因为这部分比较重要，但对于如何丢弃，怎么丢弃，这是需要思考的一个问题
- 上下文精炼：提取老旧的上下文，让 llm 模型精简上下文，再将精简后的上下文覆盖原来的上下文
- 内容精炼：对于大量内容，比如精简不重要的结构化标签，不重要的语言信息表达，再放入上下文中
- RAG：基于 embedding 模型，agent把内容处理后放入向量数据库变成，形成向量上下文，提供工具让ai查找自己需要的内容，只把需要的内容放入上下文，避免了上下文膨胀，以此精简上下文信息，例如现在的个人知识库应用
RAG
Embedding模型会把输入内容，输出成固定长度的向量数组（类似于有损压缩但是能保留原语义），一个向量数组每一位值都代表向量坐标系一个维度中的向量值（即数组1000位，向量坐标系就有1000维，更高的维度能使结果更为精确）
整个向量数组构成该内容在向量坐标系中的位置，向量坐标系中，距离越近，其内容的语义近似值也会越接近，后续把用户输入的内容同样也转换为向量坐标系中，以此来进行匹配，最终讲近似语义的内容提取并整合一起发送给 LLM
Chucking：即决定如何对文章内容进行切块，将切取结果作为一段内容提供给模型生成向量数组，可以按句子切，按段落切
向量数据库：设计用于找到距离最近的向量结果，即近似值，更适用于 ai 的场景，而不是像数据库的精确匹配
- Pinecone
- Chroma
- Postgresql+pgvector
RAG 现在存在的问题：
- 如何 chuking 保持语义正确：算法优化，让llm模型参与到其中
总结
Ai 对话其实就是作为管理者/架构师，与通用领域技术专家合作的一个过程，是个人架构和思维能力的体现，如何用好 AI ，怎么让 AI 能力辅助自己日常提效，怎么把日常生活可重复效率低的流程自动化，这是未来技术岗位都需要思考的问题。