以后推荐开源项目： ❌ https://github.com/xx/yy ✅ https://deepwiki.com/xx/yy
Devin （就是那个每月 500 刀的 AI 程序员）团队推出了 DeepWiki（https://deepwiki.org/），从此阅读源码更方便了。
只需要将开源项目链接的 github.com 替换为 deepwiki.com，就可以得到一份详尽的项目文档，比如：https://deepwiki.com/vercel/ai-chatbot。
（比源文档详细的多：https://chat-sdk.dev/docs/getting-started/overview）
甚至文档内还有图表：
并且可以基于文档进行问答：
快去试试吧！
最后祝大家五一假期快乐！
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
接上文谷歌提示词工程 - 模型原理和提示词技术，讨论提示词的最佳实践。
正如上文提示词技术提到的单样本、少样本那样，在提示中提供样例十分重要。这样模型就能在示例的参考下输出更加准确的内容。
基本原则是：若你自己都觉得困惑，模型很可能也会困惑。避免使用复杂语言，且不要提供无关信息。
尝试使用描述动作的动词。以下是一组示例：
行动、分析、归类、分类、对比、比较、创造、描述、定义、评估、提取、发现、生成、识别、列举、测量、组织、解析、挑选、预测、提供、排序、推荐、返回、检索、改写、选择、展示、整理、总结、翻译、撰写。
详细说明期望输出。简短的指令可能无法充分引导大语言模型，或过于笼统。在提示中提供具体细节（通过系统或上下文提示）有助于模型聚焦相关内容，提高整体准确性。
提示中使用的指令和约束用于引导大语言模型的输出。
尽可能使用正向指令：用“应该做什么”替代“禁止做什么”，这能避免混淆并提高输出准确性。
约束条件在特定场景仍具价值：当需要防止模型生成有害/偏见内容，或要求严格输出格式时。
作为最佳实践，应优先处理指令，明确说明您希望模型执行的操作，仅在出于安全性、清晰度或特定需求时使用约束条件。通过实验与迭代测试不同指令和约束的组合，以找到最适合您特定任务的方案，并予以记录。
要控制生成式大语言模型(LLM)的响应长度，您可以在配置中设置最大令牌限制，或在提示词中明确指定所需长度。例如：
"Explain quantum physics in a tweet length message."
为了实现提示词复用并增强动态性，可在提示词中使用变量，这些变量可根据不同输入进行替换。
不同模型、配置、提示格式、措辞和提交方式会产生不同结果。因此需对提示属性进行实验，如风格、措辞及提示类型（零样本、少样本、系统提示） 。
一般而言，小样本示例的顺序影响不大。但在执行分类任务时，务必在少量示例中混合可能的响应类别。这是因为固定顺序可能导致模型对示例顺序产生过拟合。通过混合响应类别，可确保模型学会识别各类别的关键特征，而非简单记忆示例顺序。这种方法能提升模型在未见数据上的鲁棒性和泛化性能。
经验法则建议从6个少量示例开始，并由此测试准确度。
紧跟模型更新，尝试新版模型调整提示词充分利用新特性。
除输入格式外，还可探索输出格式。对于数据提取、筛选、解析、排序、分级或分类等非创造性任务，建议采用JSON或XML等结构化格式返回结果。
JSON 格式校验严格，可以使用 PyPI 的 json-repair 智能修复 JSON 格式。
输入数据也可以使用 JSON 格式高效的组织数据。
当每个人都遵循本章所述的最佳实践时，您将观察到不同提示方案间的性能差异。
进行思维链提示时，必须将答案置于推理过程之后，因为推理过程的生成会改变模型预测最终答案时所获得的标记（token）。
使用思维链与自洽性方法时，需确保能从提示中分离出最终答案，使其独立于推理过程。
思维链提示的温度参数应设为0。
思维链提示基于贪婪解码机制，即语言模型根据概率最高中的下一个词。一般而言，当涉及推理得出最终答案时，通常存在唯一正确答案，因此温度参数应始终设置为0。
细记录每次提示尝试的完整细节，这样才能逐步总结出哪些方法有效，哪些无效。
提示工程是一个迭代过程。设计并测试不同提示方案，分析记录结果，根据模型表现优化提示词。持续实验直至获得理想输出。当更换模型或调整模型配置时，需重新用先前提示词进行实验验证。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
谷歌前段时间发布了提示词工程白皮书，已经有很多博主推荐了，最近终于有时间阅读一下。以下是笔记记录。
原文：https://drive.google.com/file/d/1AbaBYbEa_EbPelsT40-vj64L-2IwUJHy/view?pli=1
大语言模型的本质是预测。模型接受输入文本，根据训练数据循环预测后续的文本。提示词就是在引导模型正确的预测。
另外需要了解模型的输出配置，如果你调用过大模型的 API 应该对这些参数比较熟悉。
Output length：输出长度限制对于大模型的性能，响应时间尤为重要。
Sampling controls：控制预测结果
Temperature，越高则输出结果越发散，越低则结果更具有确定性。top-K 和 top-P 和 Temperature 类似，值越高，则输出结果越具有创造性和多样性。越高。
文档中给出了几个场景的配置样例：
零样本仅提供任务描述和供大语言模型处理的文本。不过可以通过增加单个示例（单样本）或者多个示例（少样本）让模型输出更符合要求的内容。
系统提示设定语言模型的整体语境和目的，明确模型应执行的宏观任务，如语言翻译、评论分类等。
给模型分配特根据定角色，使模型能角色定位生成更相关、信息量更大的输出。
给模型提供上下文提示，比如：
背景：您正在为一家关于80年代复古街机游戏的博客撰稿。请建议3个文章主题，并附上简要说明每篇文章应包含的内容。
回退式提示法是一种通过让大语言模型先思考与当前具体任务相关的宏观问题，再将宏观问题的答案作为后续具体任务提示的输入，从而提升模型表现的技术。
思维链一种通过生成中间推理步骤来提升大语言模型推理能力的技术。思维链特别适合代码生成时，分解需求逐步输出代码的过程。
思维树允许大语言模型同时探索多条不同的推理路径，而非仅遵循单一线性思维链。适合探索复杂任务。
大模型基于自然语言推理和外部工具（搜索、代码解释器等）来解决复杂任务。只是实现智能体（Agent）第一步。这部分需要有编写代码的能力，或者借助其他智能体构建工具。
可以借助大模型优化提示词。
文档还专门提到了代码相关的提示，编写脚本、解释代码、调试、Review等等。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
AI Agent 应该是 AI 出现后讨论最多的一个词了，因为他代表着 AI 应用的最高层次了，从上次 Manus 的火爆就可见一斑。AI 给人的感觉无所不能又高深莫测，普通人又充满好奇但只能敬而远之，那是到底什么才是 AI Agent？
通常很多文章在讲解 AI Agent 时又会引入很多新的概念和名词，这就让 AI Agent 的概念更加难以理解。
我们可以换个角度看，AI Agent 的最终形态就是可以和人一样处理任务，那如果直接把 Agent 看做人类，一切就变得非常容易理解。
想象一下，作为前端，我要完成一个后台管理页面的需求，我是怎么做的：
此时，如果需要 AI 完成这个事情，同样也是按照上述步骤：
检索增强生成（RAG）旨在通过检索和整合外部知识来增强大语言模型生成 文本的准确性和丰富性，其是一个集成了外部知识库、信息检索器、大语言模型等 多个功能模块的系统。RAG 利用信息检索、深度学习等多种技术为大语言模型在 生成过程中引入最新的、特定领域的知识，从而克服传统大语言模型的局限性，提 供更加精准和可靠的生成内容。（引用自：https://github.com/ZJU-LLMs/Foundations-of-LLMs）
可以看出 AI Agent 做事情的方式就是在无限的接近于人类的做事方式：有知识储备，有规步骤规划，有工作流，有工具，最终输出结果。而整个流程中，AI Agent 作为一个完备的系统（没错，AI Agent 是一个系统），内部各部分有条不紊的工作。这一点和人类也一样，人类是一个完美的系统！
最后我们总结一下什么是 Agent：
目前已经有很多细分领域的 Agent 了，比如大火的 Cursor，生成代码建议、代码生成、询问人类意见，通过更多的案例学习，后续的编码 Agent 会变的更加智能。
本文只是个人对 AI Agent 的简单理解，对于详细的定义概念和分类，还是要参考资料和专业书籍，推荐文章 https://weaviate.io/blog/what-are-agentic-workflows。另外如果想要动手实践，可以看一下微软的 AI Agent 课程：https://microsoft.github.io/ai-agents-for-beginners/。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
最近看到很多人都在聊一个 DeepSite 的应用，应用部署在 huggingface：https://huggingface.co/spaces/enzostvs/deepsite，功能很简单直接：基于 DeepSeek 一键生成纯 html 应用并且可以发布至 huggingface space。
我试了一下，让 DeepSite 生成一个炫酷的个人博客首页。
整体效果很不错，页面完整，效果炫酷，我已经部署到我的 space ：https://huggingface.co/spaces/sleepy-zone/sleepyspace：
代码位于：https://huggingface.co/spaces/enzostvs/deepsite/tree/main。
DeepSeek 生码的逻辑位于 server.js：
const chatCompletion = client.chatCompletionStream({
model: MODEL_ID,
provider: selectedProvider.id,
messages: [
{
role: "system",
content: `ONLY USE HTML, CSS AND JAVASCRIPT. If you want to use ICON make sure to import the library first. Try to create the best UI possible by using only HTML, CSS and JAVASCRIPT. Use as much as you can TailwindCSS for the CSS, if you can't do something with TailwindCSS, then use custom CSS (make sure to import <script src="https://cdn.tailwindcss.com"></script> in the head). Also, try to ellaborate as much as you can, to create something unique. ALWAYS GIVE THE RESPONSE INTO A SINGLE HTML FILE`,
},
...(previousPrompt
? [
{
role: "user",
content: previousPrompt,
},
]
: []),
...(html
? [
{
role: "assistant",
content: `The current code is: ${html}.`,
},
]
: []),
{
role: "user",
content: prompt,
},
],
...(selectedProvider.id !== "sambanova"
? {
max_tokens: selectedProvider.max_tokens,
}
: {}),
});
prompt 也很简洁：仅使用 HTML、CSS 和 JavaScript。如果您想使用图标，请确保首先导入库。尽量仅使用 HTML、CSS 和 JavaScript 创建最好的 UI。尽可能多地使用 TailwindCSS 进行样式设计，如果无法使用 TailwindCSS 完成某些样式，则使用自定义 CSS（确保在中导入 ）。此外，尽量详细 elaboration，以创建一些独特的东西。始终将响应提供为单个 HTML 文件。
其他都是前端代码，目前看自己部署一个成本也不是很高。喜欢折腾的朋友可以玩一下看。
最后感叹一下，现在模型的能力突飞猛进。而模型能力跟上之后，应用的创意和交互体验就显得尤为重要。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
AI 公司貌似喜欢在中国的节假日搞动作，清明节短短三天假期就有很多猛料。
github 博客链接：https://github.blog/changelog/2025-04-04-github-mcp-server-public-preview/
官方仓库：https://github.com/github/github-mcp-server
今天，我们发布了一款新的开源官方本地 GitHub MCP 服务器。我们与 Anthropic 合作，用 Go 重写了他们的参考服务器，并提高了其可用性。新服务器包含旧服务器的 100% 功能，此外还能够自定义工具描述、支持代码扫描，并新增了 get_me 函数，该函数可改善自然语言用户体验，例如询问“显示我的私人存储库”。
今天又看到一则消息，后面的模型将不再支持 Tool。还是那句话，持续看好 MCP！
Meta Llama 4 发布，号称最强模型。
不过社区评价看起来好像不怎么好，虽然有超大的上下文窗口，但体验一般，知乎的讨论也是一边倒的看衰：https://www.zhihu.com/question/1892067881098903620
另外，Qwen、DeepSeek R2 据说也快发布了，还是期待国内的模型吧。
OpenRouter（https://openrouter.ai/），是一个模型服务商，他们也发布了自家模型，上下文达到 1m，特别适合代码，并且免费！
This is a cloaked model provided to the community to gather feedback. It’s a powerful, all-purpose model supporting long-context tasks, including code generation. All prompts and completions for this model are logged by the provider as well as OpenRouter.
这是提供给社区以收集反馈的隐藏模型。这是一个功能强大的通用模型，支持长上下文任务，包括代码生成。此模型的所有提示和完成都由提供商和 OpenRouter 记录。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
在上篇文章 动手开发一个 MCP Server 中讲了怎么开发一个 MCP Server，本文简单聊聊我对 MCP 的看法。
一直以来，我认为大模型工具的最终形态就是一个输入框。用户的任何需求，不论是写文章查资料写代码，还是旅游攻略订酒店，都只需求在输入框内输入需求，AI 会自动找到合适的工具去解决问题并最后进行反馈。
听起来非常的 Agent。
AI 擅长自然语言理解，擅长知识输出，擅长内容总结，而自动找到合适的工具，这是一个很大的挑战。
当前 AI 能自动找到合适的工具的前提是我们需要给 AI 提供足够多的工具，而大多数时候我们只能依赖使用的 AI App，比如 App 提供了联网功能，我们才可以使用联网搜索，但当我们希望使用一个操作本地文件的工具，只能等待 AI App 内置，或者自行开发；当我们因为工作环境切换，使用新的 AI app 时，一切可能都变了，要么没有对应的工具，要么不兼容，只能从头开始适配。
MCP 的出现很好的解决了这个问题，他将 AI 和外部数据如何交互进行了约定，保证一个符合 MCP 协议的工具是处处可用的。正因为如此，目前几乎能想到的服务都进行了 MCP 化，甚至高德百度地图都推出了 MCP Server。
对于用户来说，不必为了某个工具局限于某个 AI App 或者 Agent，有了 MCP 用户通过自由的组合 MCP Server 来创建独属于自己的 Agent，一切变得可插拔和模块化，给了用户极大的自由。另外，对于各种各样的外部服务，也不必再去想如何开发 Agent，而是暴露通用的 MCP Server 即可。
不过目前 MCP 并非完美，配置和使用成本对于普通用户来说并不低，并且如果要定制自己的 MCP Server 还需要有开发能力。在社交媒体能看到很多人表示“没有配置成功过”，也表示不如其他的 AI 功能效果来的快。
但我依旧非常看好 MCP，我认为这是 AI 能力扩展上的一个正确而可行的路线，真正可以让 AI 接触到真实世界，从而更好的为人类服务。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
MCP，Model Context Protocol，模型上下文协议，是由 Anthropic （Claude 系列模型公司）提出的一种 AI 和外部数据（本地文件、远程 API、数据库以及其他所有你能想到的）交互的协议，以此来增强 AI 的能力。
MCP 遵循客户端-服务器模型，包含 3 个关键组件：
如果你之前了解过 Function Call 或者 Tool（后面两者统一称为 Tool），应该对 MCP 这个概念会感到很熟悉，同样都是扩展 AI 的能力，但 Tool 需要在每个 AI 应用内单独集成无法复用，而 MCP 可以看做是一个更通用的 Tool，不论你使用哪个 AI App，只要 AI App 内置 MCP Client，就可以使用 MCP 市场的 Server。
一般来说，AI App 会集成 MCP Client，所以对于使用 AI App 的我们来说，我们唯一需要做的是定制 MCP Server，使我们的工具更加强大。
接下来我们要开发一个获取 Pixabay（https://pixabay.com/）图片的 MCP server。简单起见，我们直接使用 JavaScript。
首先，创建项目：
# Create a new directory for our project
mkdir pixabay-mcp-server
cd pixabay-mcp-server
# Initialize a new npm project
npm init -y
# Install dependencies
npm install @modelcontextprotocol/sdk zod
# Create our files
touch index.js
更新一下 package.json，这里设置一下 bin 和文件权限，其实 node 写 MCP Server 和写命令行工具差不多。
{
"type": "module",
"bin": {
"pixabay": "index.js"
},
"scripts": {
"build": " chmod 755 index.js"
},
"files": [
"index.js"
],
}
下面开始编写逻辑代码。 @modelcontextprotocol/sdk 这个包来辅助我们编写 MCP Server。
首先定义 server：
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';
const baseUrl = 'https://pixabay.com/api/';
const server = new McpServer({
name: 'pixabay-mcp-server',
version: '1.0.0'
});
// 插入 tool 代码
async function startServer() {
const transport = new StdioServerTransport();
await server.connect(transport);
}
startServer();
下面定义 server 内的 tool（server 由一个个的 tool 组成）。
server.tool(
'image-search',
{
query: z.string(),
type: z.string()
},
async ({ query, type = 'all' }) => {
try {
const requestUrl = `${baseUrl}?key=${process.env.PIXABAY_KEY}&q=${query}&image_type=${type}`;
const response = await fetch(requestUrl);
const json = await response.json();
return {
content: [{
type: 'text',
text: JSON.stringify({
images: json.hits || [],
total_results: json.total,
query,
}, null, 2)
}]
}
} catch(e) {
return {
content: [{
type: 'text',
text: `Error: ${e.message}`
}],
isError: true
};
}
}
)
官方提供了一个测试工具，https://github.com/modelcontextprotocol/inspector，可以执行下面的命令测试：
npx @modelcontextprotocol/inspector node index.js
访问 http://localhost:5173 调试。如下图，我们可以看到连接成功后，列举出我们定义的 tool，并且可以解析出 tool 需要的参数，我们输入参数后，点击 run tool 获取到数据，就说明成功了！
调试成功后，将上述代码发布到 npm，后面就可以在你喜欢的 AI App 使用你的 MCP sever 了，比如你的包的名字就叫 pixabay-mcp-server，这里以 Cursor 或者 Cline 为例配置：
{
"mcpServers": {
"pixabay-mcp-server": {
"command": "npx",
"args": [
"-y",
"pixabay-mcp-server"
],
"env": {
"PIXABAY": "xxxxx"
}
}
}
}
当我们向 AI 提出问题 search cat photos，AI 会识别到需要调用我们的工具，并且准确识别到需要提供的参数：
使用 Node.js 写一个 MCP Server 还是很简单的，可以通过官方文档了解更多：https://modelcontextprotocol.io/quickstart/server。
MCP Server 大大扩展了我们使用 AI 的边界，下一篇文章简单聊聊我对 MCP 的一点看法。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。
vibe coding，中文翻译为氛围编程，初次听这个词一头雾水。这个词由Andrej Karpathy （ OpenAI 联合创始人、前特斯拉 AI 负责人）最早提出：
我最近创造了一种新的编码方式，叫做“氛围编码”。在这种编码中，我完全沉浸在氛围中，接受代码指数级别的变化，甚至忘记代码本身的存在。这是因为大型语言模型（比如结合了 Cursor Composer 和 Sonnet 的工具）越来越强大。此外，我几乎不需要碰键盘，只要通过 SuperWhisper 和 Composer 进行对话。我问一些非常简单的问题，比如“将侧边栏的内边距减少一半”，因为我懒得找相关的代码。我总是选择“接受全部”，也不再查看差异了。当出现错误信息时，我只是简单地复制粘贴这些信息，通常这样就能解决问题。代码的发展超出了我平常的理解，假如想彻底理解它，我得花比较长的时间认真阅读。有时候，LLM（大型语言模型）无法修复某个错误，我就通过变更一些随机的内容或请求其他修改来绕过问题。虽然这样做对随便的周末项目来说还不错，但也非常有趣。我正在构建一个 项目或网页应用，但这已经不算真正的编码了——我只是看看、说说、运行和复制粘贴，最后大多数情况下都能正常工作。
也可以这么说，vibe coding 是一种完全依赖 AI 的一种编程方式，这种编程方式下人本身只是用语言输出需求，而 AI 生成实际代码。和之前完全由人编写代码截然不同。因为完全由 AI 生成代码，这就导致代码数量和代码质量其实并不可控。当 AI 生成的代码越来越多时，就会越来越不可控，人已经完全无法理解代码，只能通过观察运行结果不段的让 AI 去修改来达到最终的效果。由此在编码过程中，人只是享受这种编码的氛围而不是在实际的编码。所以叫做氛围编程。
（这样讲，产品经理是不是早就走在氛围编程的前列了😂）
vibe coding 得到了许多人的关注和讨论，信奉 AI 编程的人终于找到了归宿，而对 AI 编程不那么执着的人也终于找到一个适合嘲讽的词汇。现在这个阶段，我们既能看到 AI 编程带来的便利：
也能看到 AI 编程带来的隐患：
虽然各方对 vibe coding 的讨论各执一词，但现阶段的 AI 编程说到底还是 Copilot 的角色，还是需要一个掌舵人 的角色，所以我们要保持清醒，可以享受 AI 编程带来的美妙的 vibe，但切不可沉迷其中无法自拔。
欢迎关注我的公众号：前端生存指南，一起聊聊前端、AI 和生活。