#AI应用

#上下文工程 我最近在做一个内容摘要生成的小功能,本来以为是个简单的任务:用户输入长文本,我调用更强、更大上下文的模型,让它生成优质摘要。结果发现,这一过程的成本比我预想的高得多。 高质量模型 → 价格昂贵 大上下文窗口 → Token 消耗成倍增长 每月 20 美元的订阅费 → 很难覆盖这些成本 对比下来,连 OpenAI 和 Cursor 这样的公司都不例外。以我自己为例,上个月在 Cursor 上花了接近 100 美元,其中大部分都用在 Claude 模型上,这意味着 Cursor 从我这里几乎没赚到钱。 这背后反映了一个更大的行业问题: 用户对高质量体验的要求 → 迫使应用方使用昂贵的大模型 长上下文输入 → 成本随 Token 增长呈线性甚至指数级上升 订阅模式的收入上限 → 无法有效平衡高频、高消耗用户 因此,对于任何想做 AI 应用的人来说,“上下文工程”是不可回避的核心能力。它的目标是在满足任务效果的同时,最大限度减少传给模型的内容量,用结构化、抽取关键信息的方式,让模型少读冗余、多读核心,从而显著降低计算开销。 因此,对于任何想做 AI 应用的人来说,“上下文工程”是不可回避的核心能力。它的目标是在满足任务效果的同时,最大限度减少传给模型的内容量,用结构化、抽取关键信息的方式,让模型少读冗余、多读核心,从而显著降低计算开销。
宝玉
1个月前
一文看懂“提示词” vs “提示词工程” vs “上下文工程” 很多人分不清楚什么是“提示词”(Prompt),什么是“提示词工程”(Prompt Engineering),现在还又多了一个概念叫“上下文工程”(Context Engineering),这又和“提示词工程”什么区别? 什么是提示词(Prompt)? 提示词很好理解,就是给 AI 模型的输入文本,就是你直接向模型输入的问题或指令。 比如你让 ChatGPT 总结一段文本、调用模型 API 传入提示词去翻译一篇文章等等。 提示词是一段文本,有点像代码。 什么是提示词工程(Prompt Engineering)? 提示词工程是一个过程,系统化地设计、测试、优化提示词的过程。 就像软件工程,我们为了完成某个需求,要有一套科学的方法来帮助完成软件开发的过程,有方法论(比如敏捷开发),要使用工具,要保证质量,不断迭代,最终交付软件,或者说代码。 举个例子 比如我们要有个提示词帮助翻译英文文章到中文。 普通人都可以写: “请把下面的英文内容翻译为中文:” 这就是一段提示词。 但是你会发现虽然能翻译,但是似乎翻译效果不够好,于是你开始想办法优化,让 AI 扮演一个英文翻译到中文的专家,发现似乎有点效果。 但还是翻译有点生硬,然后你看有人介绍了 CoT(思维链,Chain of Though),于是尝试在提示词中让 AI 去先直译再意译,但你也不知道这样的改动是不是真的有用,于是你找了10篇文章,分别用加了 CoT 和没加 CoT 的文章,去用相同的模型去翻译,然后找了几个人,在不告诉他们使用什么方法翻译的情况下让他们评估好坏,结果绝大部分都认为加了 CoT 的效果更好,那么你就明白了,原来加了 CoT 对翻译是有效果的。 于是你受到鼓舞,即然 CoT 有效果,那么我在直译、意译的基础上,继续增加一个 AI 对直译结果的评估,再去意译,甚至再多加几步是不是效果更好?再继续改进提示词,拿着之前的测试集去评估测试,果然测试效果更好,但是也带来新的问题,Token 消耗更多,时间更长,还可能会偏离原意。CoT 也并不见得步骤越多越好。 再后来推理模型发布了,你发现模型自己会 CoT 了,语言能力也更强了,原来繁琐的一步步翻译似乎没有必要,于是进一步优化,发现只要在提示词中让模型“用中文重写”就可以达到很好的翻译效果,测试集评估结果也是正面的。 这整个对翻译提示词“设计”、“测试”、“优化”的过程就是提示工程。 最终通过这样的过程,产生出一个版本一个版本的提示词。 再精炼浓缩一下:提示词工程是产生提示词的过程。 什么是上下文工程(Context Engineering)? 要理解上下文工程,先得搞清楚什么是“上下文”(Context)? “上下文”不仅仅是发给大语言模型的一句提示词,而是模型生成回答之前所看到的一切信息,这些信息包括系统提示词、用户输入的问题、当前对话的历史消息、系统对你的历史记忆、工具返回的信息等等。 另外上下文窗口不是无限的,每个模型都对上下文的长度有限制,通常上下文内容多了会影响性能,所以控制好发送给 AI 的上下文很重要,既不能遗漏,又不能什么都放进去要控制体积。 举个例子,你跟 ChatGPT 说: “今天都有什么重要的 AI 新闻?” 看起来只是一句话,但是对于大模型来说,初始的上下文有这些: • 系统提示词:“你是个有用的助手,总是帮用户解决问题” • 用户输入:“今天都有什么重要的 AI 新闻?” • 可用工具:“日期工具、搜索工具、网页抓取工具” • 长期记忆:“用户主要使用中文” • 历史会话消息:无 • 工具返回信息:无 这些上下文不足以让 AI 回答你的问题,于是它需要自己去调用工具找齐上下文: • 根据日期工具获取到今天的日期(大模型自己不知道今天是几号) • 根据今天的日期去调用搜索工具检索 AI 新闻 调用完工具后,现在 AI 的信息完整了: • 系统提示词:“你是个有用的助手,总是帮用户解决问题” • 用户输入:“今天都有什么重要的 AI 新闻?” • 可用工具:“日期工具、搜索工具、网页抓取工具” • 长期记忆:“用户主要使用中文” • 历史会话消息:无 • 工具返回信息: • 2025-7-1 • Hollywood Confronts AI Copyright Chaos in Washington, Courts • Mark Zuckerberg Announces New Meta ‘Superintelligence Labs’ Unit 现在信息够了,考虑用户偏好中文,最后返回的内容如下: 今天的 AI 新闻有: • 好莱坞在华盛顿和法院直面人工智能版权混乱 • 马克·扎克伯格宣布成立新的“超级智能实验室”部门 马克·扎克伯格宣布成立新的“超级智能实验室”部门 假如用户再追问一句: “帮我返回第二条新闻的详情” 那么模型要从历史会话里面,找到第二条新闻的链接,再去调用网页抓取工具,把新闻内容抓取下来,根据用户的偏好翻译成中文,最后返回用户中文的新闻内容。 注意看这个构建上下文的过程是完全动态的,并不是按照设计好的工作流去收集上下文,而是模型自己根据当前上下文状态去自主动态的调用工具收集上下文,并且不同的任务需要调用的工具也不一样。 这其实也就是现在 AI Agent 的工作原理:能分辨是否已经收集够了完成任务必要的上下文,能自主决定是不是需要借助工具或者对话来补齐上下文。 上下文工程的概念也正是在 AI Agent 爆发的背景下诞生的。原来单纯靠提示词工程已经无法满足 AI Agent 产品的需求了,AI Agent 需要的更多的是为系统设计好工具、定义好工具和模型之间交互的数据格式、有效组织上下文信息提供给模型(内容长了要不要压缩、怎么压缩)等等。 上下文工程(Context Engineering),就是一门为 AI 设计和构建动态上下文的学科,为大语言模型提供恰当的信息和工具,帮助模型高效完成任务。 > “上下文工程”指的是一种精妙而复杂的技术:你要精准地将上下文窗口填充上恰到好处的信息,让模型能准确地迈出下一步。 > 这是一门科学,也是门艺术。 > > 说它是科学,因为你要把任务描述、说明、少量样例(few-shot examples)、检索增强生成(RAG)、各种相关数据(甚至可能是多模态数据)、工具、状态、历史信息等全部巧妙地组合在一起,同时还要考虑如何压缩信息。这就像烹饪一道精致的菜肴,配料太少或搭配不对,模型无法获得足够的信息,性能会变差;配料太多或毫无关联,则会增加成本甚至降低表现。要做好这件事,需要的不仅仅是简单堆叠,更是高度专业化的技巧。 > > 说它是艺术,则是因为操作者还要掌握一种近似“心理学”的直觉,敏锐地洞察 LLM 和人类用户心理之间的微妙互动。 > > ——Andrej Karpathy 最后 分别一句话总结一下 • 提示词: 发送给 AI 的问题或者指令文本 • 提示词工程: 系统化地设计、测试、优化提示词的过程。 • 上下文工程: 为大语言模型提供恰当的上下文、帮助模型高效完成任务的科学和艺术。 如果没理解这些概念也没关系,对于普通人来说,能写提示词就够了,要开发 AI 应用才需要考虑提示词工程去不断优化提示词,要开发动态的 AI 智能体才需要去搞上下文工程为 AI 的上下文窗口填充恰好的信息。
凡人小北
2个月前
搞 AI 的不写 Python?现在真不是笑话了。 最近越来越明显——在 AI 应用领域,TypeScript 正在一点点蚕食 Python 的霸主地位。 过去你说搞 AI 的,十个有九个写 Python,模型、数据处理、训练、部署,一条龙服务。 但现在越来越多场景变了:不是“训练 AI”,而是“用 AI”。 用 AI 干嘛?做产品、做 UI、做交互代理、搞插件、接入 SDK… 这些一落地,就全是 TypeScript 的主场。 说几个已经发生的和正在发生的事情: 1️⃣ LangChain 和 LangGraph 现在已经有了 TypeScript 支持,能直接跑在浏览器、Node.js、Cloudflare Workers 上。写 agent、接工具、搞多轮对话,在 TS 世界里越来越丝滑。 2️⃣ OpenAI 的 Assistants API 也不给 Python 独宠,今天还贴心地发布了 TS 版本的 Agents SDK。 3️⃣ JetBrains 的统计显示,TypeScript 使用率从 2017 年的 12% 涨到 2024 年的 37%。在企业里,TS 已经不是前端才用的语言,而是你要做 AI 产品就得学的语言。 这些不是趋势预测,而是已经在开发现场发生的事实。 技术栈正在迁移。你要构建个 AI Copilot、Web 插件、对话助手,Python 行不通。 TypeScript 天然和 UI、API、用户互动贴得更近,类型安全又稳,越来越多团队把它当默认选项。 而且别忘了,过去十年,前端其实一直在默默吞噬后端的地盘。 这波 AI 应用化,刚好又给了前端一记重拳,原来你以为是写页面的,结果人家直接搞起 AI Copilot 了。 再看看 Python 那边,Streamlit、Gradio 这些本该承担AI UI 桥梁的工具,一个不争气,一个半死不活,完全没接住这波热潮。 我看了看趋势,有点慌了……我要去学学 TS 了。 以前是“全栈前端”说说而已,现在是真的“前端越来越吃香了”。 但要冷静两秒(防杠专区): 1️⃣ Python 依然是 AI 训练和科研的王者,PyTorch、TensorFlow、scikit-learn 这些生态太厚实了,训练大模型你离不开它。 2️⃣ TS 在底层 AI 能力上还没那么能打,GPU 加速、模型优化这些,暂时还得靠 Python 打底。 但是,现在 AIGC 丰富的是应用的生态,相比做模型的人,做 AI 应用的人数万倍了吧。 最后,非要有个定位的话,Python 搞理论和模型,TypeScript卷体验和交付。 TS 正在从应用这一层切入,把 AI 真正推向了每个 Web 页面的角落。 爆款 AI 产品,正在越来越多的全栈 TS 了。