00A｜AI 基础概念速读：从 LLM 到项目助理 Agent
文件路径：
/Users/apple/Documents/4.0 Sanyuan/2.4 环境公益"新"力量/course/part-00-prework/ai-basics-reading.md阅读时间：25–35 分钟 | 形式：课前阅读 | 目标：听懂第 1–3 课的关键概念
建议顺序：先读本页，再开通 LLM API，最后填写《项目助理立项书》。
一、这份导读要解决什么
这不是一份技术百科，也不是开发教程。
它只解决一个问题：在第 1 课开始写 Skill 之前，先让你知道一个「项目助理 Agent」到底靠什么工作。
整个课程的主线可以先记成三句话：
| 组件 | 它解决什么 | 公益工作里的类比 |
|---|---|---|
| Skill | 怎么做事 | 机构 SOP、工作手册、输出模板 |
| 知识库 | 依据什么资料做 | 项目档案、资助指南、案例库 |
| Agent | 如何把任务、资料、工具和人串起来 | 一个有边界的项目助理流程 |
第 1 课先做 Skill，第 2 课做知识库，第 3 课把它们组装成项目助理 Agent。下面 10 个概念就是这条学习线的前置地图。
二、建议学习线路 1–10
1. 先从一个项目助理任务开始
不要从术语开始，先想一个真实任务：
请根据项目执行记录、活动清单和资助方模板，生成一份月度进展摘要。这句话背后至少有 5 件事：
- AI 要知道自己在帮谁。
- AI 要知道任务目标是什么。
- AI 要看到足够的项目资料。
- AI 要按指定格式输出。
- 高风险内容需要人来确认。
所以，一个可用的项目助理不是「一个更聪明的聊天框」，而是由任务说明、资料、工具和审核边界共同组成的工作流。
2. LLM 是什么：会生成，不等于会查证
LLM 是大语言模型，可以理解成一个很擅长处理文字的通用助手。它能理解问题、归纳材料、改写文本、生成草稿，也能按格式输出表格和清单。
但它不是数据库，也不是机构老同事。它不会天然知道你的项目背景、资助方要求、历史活动记录或内部口径。
对公益项目来说，LLM 适合先做这些事：
| 适合 | 不适合直接交给它 |
|---|---|
| 整理活动记录 | 编造项目成效 |
| 改写项目摘要 | 判断政策最终口径 |
| 生成报告初稿 | 代替财务或法务审核 |
| 提炼案例亮点 | 自动对外发布承诺 |
一句话：LLM 可以做高质量初稿，但不能替人承担事实、伦理和对外承诺责任。
3. Prompt 与 Skill：从一次性委托到可复用能力
Prompt 是一次性的任务委托，例如：
请把下面的项目流水账整理成结项报告。Skill 是可复用的工作说明书，它会写清楚：
| Skill 里要写什么 | 作用 |
|---|---|
| 什么时候使用 | 避免误触发 |
| 需要哪些输入 | 避免材料不够还硬写 |
| 按什么步骤处理 | 把人的经验沉淀下来 |
| 输出什么格式 | 让结果可直接复用 |
| 哪些事禁止做 | 控制幻觉、隐私和越界 |
第 1 课做的不是「写一句厉害的提示词」，而是把机构的一类稳定工作做成可复用 Skill。
4. 上下文窗口：AI 一次能看多少，不等于能稳定用好多少
上下文是 AI 当前能看到的所有内容，包括系统说明、历史对话、用户输入、上传资料、知识库检索片段和最终输出空间。
这里要分清三层：
| 层级 | 含义 | 实战判断 |
|---|---|---|
| 总上下文窗口 | 模型理论上一次能容纳的总 token，例如 256k、1M | 代表能放多少，不代表都能稳定用好 |
| 有效上下文 | 模型在长上下文中真正能可靠引用和整合的部分 | 上下文越长，漏读、混淆、引用错资料风险越高 |
| 可控上下文 | 当前任务最需要、最相关、最干净的一组材料 | 项目助理应优先追求可控，而不是一味塞满 |
可以用下面的经验区间做判断。它不是绝对规律，但适合课程实操：
| 上下文使用比例 | 风险判断 |
|---|---|
| 0–30% | 通常比较稳定，适合结构化任务 |
| 30–60% | 可用，但需要清晰标题、分段、来源和输出要求 |
| 60–80% | 幻觉、漏读、混淆风险明显上升 |
| 80% 以上 | 不建议常态使用，除非只是粗读、摘要或人工复核 |
256k 和 1M 的差别可以这样理解：
| 模型上下文 | 更适合什么 | 仍然要注意什么 |
|---|---|---|
| 256k | 中等规模材料包、单个项目资料、若干报告对比 | 需要提前筛选材料，不能把机构档案全塞进去 |
| 1M | 临时阅读长材料包、全局摘要、跨多份文件初筛 | 大上下文不是知识库，长材料越多越需要结构和引用 |
关键判断：1M 上下文比 256k 能临时放入更多资料，但不能替代知识库。 机构长期资料仍然应该进入知识库，用检索、metadata、rerank 和人工审核来控制输入质量。
5. 幻觉与事实边界：看起来完整，不代表真的可靠
幻觉不是 AI「故意乱说」，而是在资料不足、上下文过长、资料冲突或任务边界不清时，模型生成了看似合理但未经验证的内容。
公益项目里最容易出问题的是这些内容：
| 内容类型 | 风险 | 应对方式 |
|---|---|---|
| 项目成效数据 | 把估计写成事实 | 必须来自项目记录或人工确认 |
| 资助方要求 | 引用过期版本 | 要求标注来源和年份 |
| 受益人故事 | 个人信息泄露 | 先脱敏，再进入 AI 流程 |
| 政策解释 | 口径过度确定 | 标注「需人工复核」 |
| 预算和财务 | 数字错误代价高 | AI 只做整理，不能最终确认 |
降低幻觉的办法不是只换更强模型，而是同时做好四件事：
- 给清楚任务。
- 给准确资料。
- 控制上下文比例。
- 要求 AI 标注缺失项和不确定点。
6. 知识库与 RAG：先找资料，再基于资料回答
RAG 可以简单理解为：
用户提问 → 检索相关资料 → 筛选排序 → 放入上下文 → LLM 生成回答 → 人工复核关键内容知识库不是把文件堆在一起，而是让项目助理在回答前能找到正确资料。
例如用户问：
我们有没有类似“湿地公众参与”的成功案例？如果没有知识库，AI 可能只能泛泛建议。 如果有案例库，AI 就可以先找相关案例，再按背景、行动、结果、反思输出。
这就是第 2 课要正式处理的内容。
7. Embedding 与切片：资料不是越大块越好
Embedding 可以理解成把文字变成「语义坐标」。这样 AI 不只按关键词找资料，还能按意思找资料。
例如：
| 用户说法 | 知识库里可能的资料标题 |
|---|---|
| 湿地公众参与案例 | 河岸生态观察志愿者活动复盘 |
| 社区环保行动 | 垃圾分类居民倡导项目总结 |
| 志愿者培训流程 | 巡河志愿者入门手册 |
但 embedding 模型也有 input token 限制。资料太长可能失败、被截断，或者虽然入库成功但检索效果很差。
课程里建议先按中文字数做实用判断：
| 资料类型 | 建议切片长度 |
|---|---|
| FAQ、制度条款、操作步骤 | 300–800 中文字 |
| 项目总结、案例、活动记录 | 800–1500 中文字 |
| 政策、指南、报告章节 | 1500–2500 中文字 |
| 一般不建议超过 | 3000 中文字/片 |
三条规则最重要：
- 一片只讲一件事：一个案例、一个流程、一个条款、一个项目阶段。
- 按标题和自然段切，不按机械字数硬切。
- 上下片可保留 80–200 字重叠，避免关键信息断裂。
第 2 课会继续讲文件类型处理、metadata、全文检索、向量检索和混合检索。
8. Rerank 与检索方式：先粗找，再精排
检索不是一次完成的。常见流程是先找出一批可能相关的片段，再用 rerank 重新排序，把最值得看的片段放进上下文。
可以这样理解：
| 检索方式 | 适合什么问题 | 例子 |
|---|---|---|
| 全文检索 | 精确词、编号、日期、文件名 | 2025 年清河项目巡护次数 |
| 向量检索 | 换一种说法找相似内容 | 找一个社区参与成效案例 |
| 混合检索 | 既要关键词，又要语义判断 | 湿地教育 + 志愿者数据案例 |
| Rerank | 候选资料多、排序不稳 | 从 20 段候选里挑最相关 5 段 |
课前只要知道它们解决的问题： 全文检索管准词，向量检索管意思，混合检索两者都要，rerank 管最后排序。
9. Agent、工具、API、MCP：让 AI 不只回答，还能办事
Agent 可以理解为一个有边界的 AI 工作流：
Agent = LLM + 任务目标 + Skill + 知识库 + 工具 + 权限 + 人工审核几个概念先这样记：
| 概念 | 一句话解释 |
|---|---|
| Agent | 围绕目标完成多步任务的 AI 助理 |
| 工具 | Agent 可以调用的外部能力，例如查表、读文件、生成文档 |
| API | 系统之间按规则交换数据的接口 |
| MCP | AI 连接外部工具和数据源的一种标准插座 |
| 工作流 | 规定先做什么、后做什么、何时停下来问人 |
MCP 在课前不需要讲开发细节。现在只需要知道：它不是一个更聪明的模型，而是一种让 AI 更标准地连接工具、文件、系统和服务的方式。
10. 权限、审核与课程路线：最好的 Agent 是边界清楚的 Agent
Agent 能调用工具之后，能力会变强，风险也会变高。
适合自动辅助的任务：
| 可以自动辅助 | 必须人工审核 |
|---|---|
| 会议纪要整理 | 对外声明 |
| 项目周报初稿 | 资助方正式报告 |
| 案例标签生成 | 预算、财务和合同 |
| 待办提醒 | 敏感个人信息 |
| 资料摘要 | 机构战略判断 |
本课程最终要做的项目助理，不是自动替机构做决定，而是帮人更快、更稳地完成重复工作。
最后再把课程路线串起来：
| 阶段 | 学什么 | 产出 |
|---|---|---|
| 课前 | 看懂 LLM、上下文、知识库、Agent 的基本关系 | 立项书更容易填准 |
| 第 1 课 | Skill | 至少 1 个可复用能力 |
| 第 2 课 | 知识库 | 可检索资料库 + 命中率测试 |
| 第 3 课 | Agent | 统一入口 + 技能路由 + 知识库增强 |
| 第 4–5 课 | 多技能协同与预发布 | 能被同事试用的项目助理 |
三、课前自测
不用提交分数，只用来判断自己是否准备好进入第 1 课。
- LLM 为什么不是数据库？
- 为什么上下文窗口很大，也不能把所有资料都塞进去？
- 256k 和 1M 上下文的主要差别是什么？
- embedding 更适合解决关键词匹配，还是语义相似？
- 为什么切片一般不建议超过 3000 中文字？
- rerank 解决的是「找不到资料」还是「候选资料排序不稳」？
- MCP 更接近模型能力，还是工具连接方式？
- 你的项目助理最需要引用哪三类资料？
- 它最不应该接触或输出哪三类信息？
- 如果要把你的任务做成 Skill，最需要写清哪三条规则？
四、带着这 3 个答案去填立项书
读完后，在填写《项目助理立项书》前先写下三句话：
我的项目助理 Agent 主要服务对象是：__________
它最需要查找或引用的资料包括：__________
它不应该接触或输出的信息包括：__________如果这三句话能写清，第 1 课构建 Skill、第 2 课整理知识库、第 3 课组装 Agent 都会更顺。
→ 继续：LLM API 开通指南 → 继续：项目助理立项书