PromptX Wiki：AI 与本地 AI 教程库
面向中文读者的 AI、本地 AI、提示词、上下文工程、智能体、多智能体与大模型工程教程网站。
核心栏目
专题路径
推荐入门
- AI、本地AI、Token与上下文工程：从词元到可部署智能体的完整入门
研究聚焦初学者进入 AI 应用工程时最容易混淆的三个层次：模型能力、上下文组织与执行系统。方法上，文章以 Token 作为资源计量单位，以上下文窗口作为运行时工作台，再把本地部署、检索增强、工具调用、记忆、安全与评测纳入同一工程框架。结论是，可部署智能体的核心不在于把提示词写得更长，而在于用可计量的 Token 预算、可追溯的证据、可控的工具权限和可复验的评测闭环，把模型能力转化为稳定系统行为。
- 从提示词工程到Harness工程：让大模型稳定完成任务的系统方法
研究聚焦提示词工程在生产级大模型应用中的能力边界：为什么清晰指令能够改善单次回答，却难以保证长链路任务稳定完成。方法上，文章把 Harness 视为围绕模型构建的任务执行系统，从上下文装配、工具权限、状态管理、结构化输出、评估观测与人在环路六个维度重构 AI 功能。结论是，提示词仍是必要语言接口，但稳定交付依赖可恢复、可验证、可追踪的外部结构；成熟 AI 产品应把“模型会说”转化为“系统会干活”。
- 上下文工程实践：长上下文、RAG、记忆、压缩、路由和缓存
研究聚焦上下文工程在大模型应用中的实践问题：如何在长上下文、RAG、记忆、压缩、路由和缓存之间做系统性取舍。方法上，文章把上下文视为面向模型的动态供应链，分析任务上下文、知识上下文、会话上下文、记忆上下文、工具上下文和治理上下文的组织方式。结论是，稳定 AI 应用不应依赖“把材料全部塞进去”，而应通过边界定义、证据选择、状态压缩、链路路由和缓存治理，让模型在每次请求中获得最少但足够的信息。
- 本地AI部署入门：Ollama、llama.cpp、vLLM、LM Studio与Open WebUI
研究聚焦本地 AI 部署的入门误区：为什么“模型能在电脑上跑起来”不等于构建了可维护的本地 AI 能力。方法上，文章从硬件约束、量化格式、推理后端、桌面工具、网页入口、OpenAI 兼容接口、安全边界和运维治理几个维度比较 Ollama、llama.cpp、vLLM、LM Studio 与 Open WebUI。结论是，本地 AI 的核心价值在于控制模型、数据、成本和接口边界；稳定方案应从最小可行环境开始，逐步补上评测、知识库、权限、监
- 工具调用与函数调用：Schema设计、错误恢复、幂等性和安全边界
本文把工具调用和函数调用解释为一套受控执行系统，而不是模型输出 JSON 的技巧。Schema 设计、参数来源、错误恢复、幂等性、安全边界和提示注入防护共同决定模型能否从“会说”走向“会办事”。文章强调，模型只能提出调用意图，真正执行权必须保留在应用和业务系统中；高风险动作要拆分为可审计的工具、可验证的参数和可恢复的状态。工具调用的生产价值，不在工具数量多，而在模型、接口和权限之间形成清晰契约。
- 模型网关教程：统一API、供应商路由、降级、重试、计费和审计
模型网关不是把不同供应商的接口包装成同一个路径，而是把模型调用从业务代码中抽离为可治理的基础设施。统一 API、模型别名、供应商路由、降级、重试、超时、缓存、计费和审计应被放在同一条调用链中分析，因为网关的核心作用，是把“选哪个模型”转化为可版本化、可观测、可回滚的策略问题。任务语义在这里尤其关键：不同业务对延迟、成本、质量、数据出域和失败后果的约束不同，网关必须处理这些差异，而不是把所有请求压平成普通聊天调用。
最新整理
- 可核验AI答案的证据链工程：从引用、检索、审计到评测的生产方法
可核验AI答案不是在段落末尾补几个链接，也不是让模型在回答里声明“我基于资料作答”。真正的证据链工程要把问题、检索、证据、主张、引用、审计、评测和纠错连接成一条可检查的生产链路。本文把可核验性定义为：读者能从答案中的每个关键事实回到明确证据；系统能记录该事实由哪个版本、哪段资料、哪个检索策略、哪个生成请求产生；运营团队能用指标判断证据是否覆盖主张、引用是否精确、答案是否忠实于资料、风险是否超过上线阈值。文章基于RAG、RAGAS、ARE
- 从零建设AI能力中心：平台、模型、数据、智能体、团队和路线图
AI 能力中心不是统一聊天入口，也不是模型账号采购清单，而是让组织把模型能力、数据上下文、工具执行、评测治理和业务交付连接起来的生产体系。它要解决分散采购、密钥失控、资料过期、成本黑箱、智能体越权和经验无法复用等问题。本文提出从零建设 AI 能力中心的路线：先用模型网关收敛调用和成本，再以可信知识库建立上下文能力，随后通过受控工具和智能体把回答扩展为任务执行，并以评测、观测、安全治理和团队责任支撑持续运营。能力中心的价值不在堆满组件，而
- AI治理与组织制度：角色、流程、评审、审计、采购和成本控制
AI 治理不是限制创新的审批墙，而是让组织在模型、数据、工具、供应商和业务责任不断变化时仍能做出可复盘判断的管理系统。生成式 AI 与传统软件不同，它会根据上下文生成结果、调用工具、受模型版本和资料质量影响，并可能把错误输出包装成流畅语言。本文把 AI 治理拆成角色、用例台账、风险分级、上线评审、审计证据、采购管理、成本控制和智能体治理八个部分，强调制度必须落到工具和流程里。生产级治理的目标，是让低风险探索有快车道，让高风险用例有足够证
- AI开发者平台：SDK、API、插件、权限、示例和开发者生态
AI 开发者平台的本质不是模型接口集合，而是把模型、工具、数据、插件和治理能力转化为开发者可持续构建产品的契约系统。SDK、API、插件、权限、示例和生态并不是并列栏目，而是从首次调用到生产运营的一条路径：开发者需要稳定接口、清晰错误、可调试链路、可控权限、可复用示例和可治理扩展；管理员需要预算、审计、密钥、模型路由、数据边界和插件治理；生态开发者需要分发、反馈、收益和版本机制。本文主张用“开发者生产闭环”评估 AI 平台，而不是用模型
- AI客服系统：知识库、工单、质检、交接人工和风险控制
AI 客服系统的目标不是把人工座席替换成一个更会说话的聊天框，而是把客户问题在正确边界内更快转化为可解决、可追踪、可复盘的服务流程。客服场景连接客户权益、订单、账户、隐私、退款、投诉和品牌信任，因此不能用自动化率作为唯一目标。本文主张以服务边界为起点建设 AI 客服：低风险高确定性问题自动解决，中风险问题由 AI 收集条件和创建工单，高风险问题及时交接人工并保留证据。系统能力应覆盖知识口径、身份权限、工单流转、工具调用、人工协作、质检评
- AI办公系统：会议纪要、知识管理、邮件、表格、PPT和项目协作
AI 办公系统的目标不应是给邮箱、会议、表格、PPT 和项目工具分别增加一个生成按钮，而应是让组织工作中的证据、责任、状态和下一步动作更清楚。会议纪要、知识问答、邮件起草、表格分析、汇报材料和项目协作看似是不同功能，本质上都在处理同一类问题：工作信息如何从讨论进入行动，从行动进入复盘，从复盘进入组织知识。本文把办公 AI 定义为“工作上下文层”，强调它必须连接身份、权限、文档、会议、消息、任务、日程、表格和知识库，并以可追溯证据支持生成
- AI教育应用：个性化导师、知识诊断、题目生成和学习反馈
AI 教育应用的核心不是把大模型包装成随问随答的聊天入口，而是把学习目标、学生证据、教学活动、反馈修订和教师判断组织成可持续闭环。个性化导师、知识诊断、题目生成和学习反馈只有放在同一条证据链中才有教育意义：诊断需要真实学习过程，题目需要课程口径和错因设计，反馈需要指向下一步行动，教师需要能审阅、修正和干预。本文主张把 AI 教育系统设计成“学习证据处理系统”，而不是答案生成系统。模型可以提供解释、变式、反馈和报告，但不能取代课程标准、评
- AI视频生成工程：脚本、分镜、素材、字幕、配音和渲染流水线
AI 视频生成的生产问题，不能用“提示词更长、模型更强”来解决。视频成片是一种时间性产品，脚本、分镜、镜头、素材、配音、字幕、剪辑、渲染和发布版本必须同步设计。模型能够生成片段，但片段不等于成片；如果没有镜头表、素材账本、字幕主源、配音控制、版权记录和渲染模板，项目会很快陷入画面好看但不可剪、字幕不同步、版本混乱和素材风险不明的状态。本文把 AI 视频工程视为一条可复用流水线，强调从成片目标倒推镜头任务，再按镜头选择视频模型、图像模型、