一个大模型应用场景：把任意书籍，变成在线AI互动课。

厉害了

这个牛逼啊！把所有的教学通过影视剧的形式，或者游戏的形式进行处理，这样的话可以通过引人入胜的剧情把知识学习了，效果应该很好

向阳老师这个互动课程平台体验不错👍，刚好和AI共创联盟一批伙伴在共创推动的「AI领导力」开放学院思路很match，现在大家已经有书、有课程、有周刊、有系统、有大赛、后边还有峰会，很齐整了，欢迎各位AI领域的伙伴一起共创（船长微信：jack00144）

这东西谷歌在2个月前不是已经做好了吗? 你在靠信息差赚钱?,感觉这样很容易被大企业干掉.

什么产品，是谷歌deep research后生成练习题和网页？ 还是NotebookLM生成思维导图、生成播客音频？ 求分享，好像没见过谷歌有把内容变成对话式剧本的产品。

大佬这个AI领导力学院平台我们需要

嗯嗯，可以加微信聊聊：vista8 和朋友也计划帮出版社或个体做各种互动课程。

具体怎么互动？

“所有的RPA可以去死了！Claude Code可以只靠口喷完成一切！” 原文地址： 下面演示，只需一句话，Claude Code自动完成画图、编辑文案、发布小红书的全流程！一镜到底！全程零干预！ 具体步骤如下⬇️

一文看懂“提示词” 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 的上下文窗口填充恰好的信息。

你有没有一直想学大模型原理，但是感觉教程都太晦涩难懂了？ 中文教程来了！happy-llm，这个教程教你从0构建一个参数大小为 215M 的大模型。看的时候一定要记得那个小技巧哦：看不懂的地方直接复制给大模型，问它我这里看不懂，你给我解释下。 教程：

这周藏师傅呕心沥血的大活来了！ Gemini CLI 不写代码帮普通人提效的的一万种用法！ - 如何低门槛两步用上 Gemini CLI - 批量修改系统设置 - 编辑查找文档，生成 PPT - 剪辑视频、修改图片、下载视频 -不同文档格式的互转 等等 下面是详细的教程和案例🧵