# 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. 先从一个项目助理任务开始 不要从术语开始,先想一个真实任务: ```text 请根据项目执行记录、活动清单和资助方模板,生成一份月度进展摘要。 ``` 这句话背后至少有 5 件事: 1. AI 要知道自己在帮谁。 2. AI 要知道任务目标是什么。 3. AI 要看到足够的项目资料。 4. AI 要按指定格式输出。 5. 高风险内容需要人来确认。 所以,一个可用的项目助理不是「一个更聪明的聊天框」,而是由任务说明、资料、工具和审核边界共同组成的工作流。 ### 2. LLM 是什么:会生成,不等于会查证 LLM 是大语言模型,可以理解成一个很擅长处理文字的通用助手。它能理解问题、归纳材料、改写文本、生成草稿,也能按格式输出表格和清单。 但它不是数据库,也不是机构老同事。它不会天然知道你的项目背景、资助方要求、历史活动记录或内部口径。 对公益项目来说,LLM 适合先做这些事: | 适合 | 不适合直接交给它 | |------|----------------| | 整理活动记录 | 编造项目成效 | | 改写项目摘要 | 判断政策最终口径 | | 生成报告初稿 | 代替财务或法务审核 | | 提炼案例亮点 | 自动对外发布承诺 | 一句话:LLM 可以做高质量初稿,但不能替人承担事实、伦理和对外承诺责任。 ### 3. Prompt 与 Skill:从一次性委托到可复用能力 Prompt 是一次性的任务委托,例如: ```text 请把下面的项目流水账整理成结项报告。 ``` 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 只做整理,不能最终确认 | 降低幻觉的办法不是只换更强模型,而是同时做好四件事: 1. 给清楚任务。 2. 给准确资料。 3. 控制上下文比例。 4. 要求 AI 标注缺失项和不确定点。 ### 6. 知识库与 RAG:先找资料,再基于资料回答 RAG 可以简单理解为: ```text 用户提问 → 检索相关资料 → 筛选排序 → 放入上下文 → LLM 生成回答 → 人工复核关键内容 ``` 知识库不是把文件堆在一起,而是让项目助理在回答前能找到正确资料。 例如用户问: ```text 我们有没有类似“湿地公众参与”的成功案例? ``` 如果没有知识库,AI 可能只能泛泛建议。 如果有案例库,AI 就可以先找相关案例,再按背景、行动、结果、反思输出。 这就是第 2 课要正式处理的内容。 ### 7. Embedding 与切片:资料不是越大块越好 Embedding 可以理解成把文字变成「语义坐标」。这样 AI 不只按关键词找资料,还能按意思找资料。 例如: | 用户说法 | 知识库里可能的资料标题 | |----------|----------------------| | 湿地公众参与案例 | 河岸生态观察志愿者活动复盘 | | 社区环保行动 | 垃圾分类居民倡导项目总结 | | 志愿者培训流程 | 巡河志愿者入门手册 | 但 embedding 模型也有 input token 限制。资料太长可能失败、被截断,或者虽然入库成功但检索效果很差。 课程里建议先按中文字数做实用判断: | 资料类型 | 建议切片长度 | |----------|--------------| | FAQ、制度条款、操作步骤 | 300–800 中文字 | | 项目总结、案例、活动记录 | 800–1500 中文字 | | 政策、指南、报告章节 | 1500–2500 中文字 | | 一般不建议超过 | 3000 中文字/片 | 三条规则最重要: 1. 一片只讲一件事:一个案例、一个流程、一个条款、一个项目阶段。 2. 按标题和自然段切,不按机械字数硬切。 3. 上下片可保留 80–200 字重叠,避免关键信息断裂。 第 2 课会继续讲文件类型处理、metadata、全文检索、向量检索和混合检索。 ### 8. Rerank 与检索方式:先粗找,再精排 检索不是一次完成的。常见流程是先找出一批可能相关的片段,再用 rerank 重新排序,把最值得看的片段放进上下文。 可以这样理解: | 检索方式 | 适合什么问题 | 例子 | |----------|--------------|------| | 全文检索 | 精确词、编号、日期、文件名 | 2025 年清河项目巡护次数 | | 向量检索 | 换一种说法找相似内容 | 找一个社区参与成效案例 | | 混合检索 | 既要关键词,又要语义判断 | 湿地教育 + 志愿者数据案例 | | Rerank | 候选资料多、排序不稳 | 从 20 段候选里挑最相关 5 段 | 课前只要知道它们解决的问题: **全文检索管准词,向量检索管意思,混合检索两者都要,rerank 管最后排序。** ### 9. Agent、工具、API、MCP:让 AI 不只回答,还能办事 Agent 可以理解为一个有边界的 AI 工作流: ```text 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 课。 1. LLM 为什么不是数据库? 2. 为什么上下文窗口很大,也不能把所有资料都塞进去? 3. 256k 和 1M 上下文的主要差别是什么? 4. embedding 更适合解决关键词匹配,还是语义相似? 5. 为什么切片一般不建议超过 3000 中文字? 6. rerank 解决的是「找不到资料」还是「候选资料排序不稳」? 7. MCP 更接近模型能力,还是工具连接方式? 8. 你的项目助理最需要引用哪三类资料? 9. 它最不应该接触或输出哪三类信息? 10. 如果要把你的任务做成 Skill,最需要写清哪三条规则? --- ## 四、带着这 3 个答案去填立项书 读完后,在填写《项目助理立项书》前先写下三句话: ```text 我的项目助理 Agent 主要服务对象是:__________ 它最需要查找或引用的资料包括:__________ 它不应该接触或输出的信息包括:__________ ``` 如果这三句话能写清,第 1 课构建 Skill、第 2 课整理知识库、第 3 课组装 Agent 都会更顺。 → [继续:LLM API 开通指南](./llm-api-setup.md) → [继续:项目助理立项书](./README.md)