1. 项目概述当AI规划师学会“翻阅资料”最近在折腾AI智能体Agent和自动化工作流我发现一个挺有意思的痛点很多规划类或决策类的AI应用其知识库是“静态”的。换句话说你训练或微调好一个模型它就用那套固定的参数来回答所有问题。但现实世界的决策尤其是项目规划、方案制定往往需要参考大量的、最新的、非结构化的外部文档——比如一份刚发下来的产品需求文档PRD、一份竞品分析报告或者一堆杂乱的市场调研数据。让AI模型去“理解”并基于这些文件内容做出规划就成了一个关键挑战。这就是“planning-with-files”这个项目吸引我的地方。它不是一个完整的应用而更像一个精巧的“连接器”或“方法论”演示。其核心思路非常直观赋予大型语言模型LLM实时读取、理解用户上传的各类文件如PDF、Word、Excel、TXT并基于这些文件的具体内容进行结构化规划Planning的能力。想象一下你丢给AI助手一份几十页的项目章程和一堆会议纪要然后直接问它“基于这些材料帮我制定一个接下来两周的详细执行计划。” 这个项目探讨的就是如何实现这个场景。从技术角度看它巧妙地串联起了几个当下非常热门的技术栈大语言模型LLLMs作为“大脑”负责理解指令、解析内容、生成规划检索增强生成RAG技术作为“记忆外挂”负责从海量文件内容中快速找到相关信息智能体Agent框架作为“执行骨架”负责协调整个“读取-分析-规划”的工作流。它没有重新发明轮子而是基于 LangChain 这类成熟的框架进行构建展示了如何将文件处理、信息检索和任务规划这几个模块有机地组合在一起。这个项目非常适合以下几类朋友AI应用开发者正在构建需要处理文档的智能助手、自动报告生成或项目规划工具。技术爱好者/研究者对RAG、Agent以及LLM与外部知识库结合应用感兴趣想找一个轻量级、可实操的案例。有自动化需求的从业者比如项目经理、分析师希望了解AI如何辅助处理日常文档并生成初步计划。接下来我会深入拆解这个项目的设计思路、技术实现细节并分享在复现和拓展过程中可能遇到的“坑”以及我的解决方案。2. 核心架构与设计思路拆解2.1 问题定义从“空想”到“有据可依”的规划传统的聊天机器人或基于固定知识库的QA系统在应对复杂规划任务时显得力不从心。其根本局限在于信息滞后性模型训练数据有截止日期无法知晓训练后产生的新文档内容。缺乏针对性通用模型无法深入理解你手头这份特定文档的细节例如文档中提到的某个专有名词、特定时间节点或内部数据。规划 grounded 在事实上一份可靠的计划必须基于确凿的事实和约束条件。这些条件和事实往往就藏在用户提供的文件里。planning-with-files要解决的核心问题就是让LLM的规划过程“有据可依”。它不是一个开放式的头脑风暴而是一个基于给定文档证据的、结构化的推理和输出过程。这本质上是一个条件生成任务在给定用户问题Query和参考文档集Files的条件下生成一个规划Plan。2.2 技术选型为什么是RAG Agent要实现上述目标有几种技术路径可选微调Fine-tuning将文档内容作为训练数据微调一个专用模型。缺点是成本高、不灵活每份新文档都需要重新微调且难以处理超长文档。全文输入Full-Context将整个文档内容作为提示词Prompt的一部分输入给LLM。这受限于LLM的上下文窗口长度Context Window对于动辄数万token的文档不现实且会带来极高的计算成本和“中间信息丢失”问题。检索增强生成RAG这是当前最主流且平衡的方案。它先将文档切分、向量化存储当用户提问时只检索出与问题最相关的文档片段将这些片段作为上下文连同问题一起送给LLM。这完美解决了长文档处理和信息精准获取的问题。planning-with-files项目选择了RAG Agent的架构这是一个非常务实且高效的选择。RAG部分负责“翻阅资料”。它处理文件上传、文本提取、分块Chunking、向量化Embedding和存储Vector Store。当用户提出规划请求时它能快速从向量库中召回相关的文本块。Agent部分负责“思考与规划”。它将LLM、工具Tools和记忆Memory组织起来。在这里检索器Retriever被封装成一个“工具”ToolAgent可以“决定”何时、如何使用这个工具去查询资料然后基于查询结果进行规划推理。这种架构的优势在于模块化与灵活性文件处理、检索、规划逻辑相互独立易于替换或升级其中任一模块例如换用不同的Embedding模型、向量数据库或LLM。符合LLM的推理习惯通过Agent框架我们可以用更自然的方式设计提示词让LLM“主动”决定是否需要检索、检索什么关键词模拟了人类先查资料再制定计划的过程。可解释性最终生成的规划可以附带引用的文档片段来源增加了结果的可信度和可追溯性。2.3 核心工作流设计项目的核心工作流可以概括为以下四个步骤这是一个清晰的单向流水线文件加载与处理Ingestion用户上传原始文件支持多种格式。系统使用文档加载器如PyPDFLoader,Docx2txtLoader提取纯文本。文本分块与向量化Chunking Embedding将提取出的长文本按语义或固定长度切割成大小合适的“块”Chunks。每个块通过嵌入模型Embedding Model转换为一个高维向量Vector并存入向量数据库如Chroma, FAISS。问题解析与检索Query Retrieval用户输入一个规划类问题如“制定一个营销计划”。系统将问题也转换为向量并在向量数据库中执行相似性搜索Similarity Search找出与问题最相关的若干个文本块。规划生成Planning Generation将用户原始问题、检索到的相关文本块作为上下文填充到一个精心设计的“规划生成”提示词模板中发送给LLM如GPT-4, Claude等。LLM基于这些“证据”生成一个结构化的规划可能是Markdown列表、JSON格式或纯文本步骤。注意在实际的Agent实现中步骤3和4可能不是简单的线性关系。Agent可能会先对复杂问题进行拆解生成多个检索查询Query进行多轮检索再综合所有信息进行规划。这体现了Agent相较于简单RAG pipeline的智能优势。3. 关键技术细节与实现解析3.1 文档处理不止于文本提取文件处理是第一步也是容易埋坑的地方。planning-with-files项目需要稳健地处理多种格式。1. 格式支持与工具选型PDF使用PyPDF2或pdfplumber。对于扫描版PDF图片则需要先进行OCR光学字符识别可以集成pytesseract或使用pdf2image转换后再识别。这里有一个细节PyPDF2对某些复杂格式的PDF解析可能不完整pdfplumber在提取表格和精确定位文本上通常更优。Word (.docx)使用python-docx库。相对简单但要注意处理文档中的图片、表格和页眉页脚这些元素在纯文本提取中可能会丢失或格式混乱。Excel (.xlsx, .csv)使用pandas。关键点在于如何将表格数据转化为适合LLM理解的文本。通常的做法是将每个工作表Sheet或关键区域转换为用“|”分隔的Markdown表格字符串或者用自然语言描述表格摘要。纯文本 (.txt) Markdown (.md)直接读取处理编码问题确保使用utf-8。PPT (.pptx)使用python-pptx提取每页幻灯片中的文本框内容。实操心得在实际项目中我强烈建议使用LangChain 的Unstructured库或LlamaIndex的对应加载器。它们封装了上述各种格式的处理并且对复杂布局的文档如多栏排版、包含图片的PDF有更好的支持能通过AI模型进行更智能的版面分析和元素识别提取出的文本质量更高。2. 文本分块Chunking策略这是影响检索效果的关键环节。分块过大会引入无关噪声分块过小会割裂语义。固定大小分块最简单的方法比如每500个字符一块重叠50个字符。使用LangChain的RecursiveCharacterTextSplitter可以方便实现。重叠是为了避免一个完整的句子或概念被硬生生切断。语义分块更高级的方法尝试在自然语义边界如段落、章节标题处进行切割。这需要利用NLP模型进行句子或段落分割效果更好但更复杂。针对规划场景的优化由于规划任务可能需要关注文档中的“目标”、“时间线”、“责任人”、“资源”等信息可以考虑在分块后为每个块添加一些元数据Metadata例如“所属章节”、“包含的关键词如‘预算’、‘Q3’”。这样在检索时除了向量相似度还可以加入元数据过滤让检索更精准。我的常用配置示例使用LangChainfrom langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size1000, # 每个块约1000字符 chunk_overlap200, # 块间重叠200字符保持上下文连贯 length_functionlen, separators[\n\n, \n, 。, , , , , , ] # 中文优先分隔符 ) chunks text_splitter.split_documents(documents) # documents是加载后的文档对象列表3.2 向量化与检索寻找最相关的证据文本变成向量后检索的本质就是计算“向量距离”。1. 嵌入模型Embedding Model选择OpenAItext-embedding-ada-002效果稳定API调用方便但会产生费用且数据需出境。开源本地模型如BAAI/bge-large-zh中文效果优异、sentence-transformers/all-MiniLM-L6-v2英文轻量级。需要在本地部署隐私性好零调用成本。使用HuggingFaceEmbeddings可以轻松集成。选择考量如果处理中文文档为主bge系列是首选。planning-with-files作为演示项目可能会优先考虑本地模型以避免API依赖。2. 向量数据库Vector Store选型轻量级/内存型Chroma、FAISS。非常适合原型开发、演示或数据量不大的场景。它们可以轻松集成到Python进程中无需额外服务。生产级/可持久化Pinecone、Weaviate、Qdrant。提供云服务或可自托管支持大规模数据、高性能检索和高级过滤功能。对于此项目考虑到易用性和快速启动Chroma是一个极佳的选择。它持久化简单和LangChain集成度极高。3. 检索器Retriever配置简单的相似性搜索有时不够用。LangChain提供了多种检索器VectorStoreRetriever: 基础向量检索。ContextualCompressionRetriever: 在检索后对结果进行压缩或重排序例如使用一个小的LLM来筛选最相关的片段可以显著提升最终效果。MultiQueryRetriever: 自动从原始问题生成多个相关问题并行检索然后合并去重。这能有效解决用户提问方式与文档表述方式不一致的问题对于规划类问题问题可能比较宏观特别有用。一个提升规划质量的关键技巧混合检索Hybrid Search。单纯基于语义向量的检索稠密检索可能错过一些关键词完全匹配的重要信息。可以结合稀疏检索如BM25。例如文档中明确写了“项目必须在2024年6月30日前交付”这个日期是强约束。如果用户问“时间安排”基于BM25的检索能牢牢抓住“2024年6月30日”这个关键词。LangChain可以很方便地整合Chroma稠密和BM25稀疏进行混合检索取长补短。3.3 智能体与规划生成从检索到决策这是项目的“大脑”部分。简单的RAG Pipeline是“检索 - 拼接上下文 - 生成”。而Agent模式赋予了系统多步推理和工具调用的能力。1. Agent 类型选择LangChain 提供了多种Agent类型如ZERO_SHOT_REACT_DESCRIPTION,OPENAI_FUNCTIONS,PLAN_AND_EXECUTE。对于“基于文件的规划”这个任务ReActReasoning Acting模式非常合适。Agent会先“思考”Reasoning“用户需要一份营销计划我需要先查阅资料中的市场分析和产品定位部分”然后“行动”Acting调用检索工具去查找相关内容最后基于观察到的结果进行下一步思考或输出。OPENAI_FUNCTIONS或STRUCTURED_CHAT类型的Agent则更适合工具调用格式严格定义的场景。2. 工具Tools定义我们需要将检索能力封装成Agent可以调用的工具。from langchain.tools import Tool # 假设我们已经有了一个检索器实例 retriever def search_documents(query: str) - str: 根据查询从上传的文档中检索相关信息。 docs retriever.get_relevant_documents(query) return \n\n.join([doc.page_content for doc in docs]) search_tool Tool( nameDocumentSearch, funcsearch_documents, description当需要从用户上传的文件中查找具体事实、数据、条款或细节时使用此工具。输入应为一个具体的搜索查询语句。 )这个工具的描述description至关重要它直接指导LLM在什么情况下、如何调用这个工具。描述要清晰、具体。3. 提示词Prompt工程规划生成的提示词是灵魂。它需要明确告诉LLM角色你是一个专业的规划助手。任务基于提供的文档内容而不仅仅是通用知识来制定计划。约束计划必须具体、可操作并严格遵循文档中给出的限制条件如时间、预算、人员。输出格式明确要求结构化输出例如“请以Markdown列表形式输出包含阶段、主要任务、交付物和预计耗时”。一个基础的规划提示词模板示例你是一个资深的项目规划专家。你的任务是根据用户提供的参考文档为用户的问题制定一个详细、可执行的计划。 请严格遵循以下步骤 1. 仔细分析用户的问题{user_question} 2. 仔细阅读以下从相关文档中提取的上下文信息这些信息是你的唯一依据 context {retrieved_context} /context 3. 基于且仅基于上述上下文信息制定一个分步计划。如果上下文信息不足以支持计划的某一部分请明确指出“根据现有文档无法确定...”。 4. 计划必须包含具体任务、负责人如果文档中提到、时间节点如果文档中提到和所需资源。 5. 以清晰的Markdown列表格式输出最终计划。 开始你的工作将{user_question}和{retrieved_context}替换为实际内容就构成了最终的提示词。4. 实战构建从零搭建一个简易原型让我们抛开复杂的框架用最核心的组件快速构建一个可运行的“规划助手”原型。这里我们选择全本地化方案避免API调用。4.1 环境准备与依赖安装首先创建一个新的Python环境推荐3.9然后安装核心库。# 创建虚拟环境可选 python -m venv planning_env source planning_env/bin/activate # Linux/Mac # planning_env\Scripts\activate # Windows # 安装核心依赖 pip install langchain langchain-community langchain-chroma # LangChain核心及Chroma集成 pip install sentence-transformers # 用于本地Embedding模型 pip install pypdf pdfplumber python-docx pandas # 文档处理库 pip install jupyter # 可选用于在笔记本中运行sentence-transformers将帮助我们使用开源的嵌入模型。4.2 核心代码实现我们将在一个Python脚本中实现主要逻辑。假设我们有一个名为project_docs.pdf的文件。# planning_assistant.py import os from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma from langchain.chains import RetrievalQA from langchain.llms import Ollama # 假设使用本地运行的Ollama如Llama2 # 如果使用OpenAI则 from langchain.chat_models import ChatOpenAI # 1. 加载文档 print(步骤1: 加载文档...) loader PyPDFLoader(./project_docs.pdf) # 替换为你的文件路径 documents loader.load() # 2. 文本分块 print(步骤2: 文本分块...) text_splitter RecursiveCharacterTextSplitter( chunk_size1000, chunk_overlap150, length_functionlen, ) chunks text_splitter.split_documents(documents) print(f文档被切分为 {len(chunks)} 个块。) # 3. 初始化嵌入模型和向量数据库 print(步骤3: 创建向量数据库...) # 使用开源嵌入模型首次运行会下载模型 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh) # 中文小模型速度快 # 持久化存储到本地目录 ./chroma_db vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) vectorstore.persist() # 保存到磁盘 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 检索最相关的4个块 # 4. 初始化LLM这里以Ollama为例需提前在本地运行Ollama服务并拉取模型 print(步骤4: 初始化LLM...) # 确保已安装Ollama并在运行例如运行了 ollama run llama2:7b llm Ollama(modelllama2:7b, base_urlhttp://localhost:11434) # 如果使用OpenAI则 # llm ChatOpenAI(modelgpt-3.5-turbo, temperature0, openai_api_keyyour-key) # 5. 创建检索增强链 print(步骤5: 创建QA链...) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 简单地将所有检索到的文档“堆叠”进上下文 retrieverretriever, return_source_documentsTrue, # 返回源文档便于追溯 chain_type_kwargs{ prompt: ... # 这里可以传入一个自定义的、针对规划优化的PromptTemplate见下文 } ) # 6. 自定义规划提示词 from langchain.prompts import PromptTemplate planning_prompt_template 你是一个项目规划专家。请严格根据以下上下文信息为问题制定一个详细计划。 如果上下文信息不足请说明哪些部分无法确定。 上下文 {context} 问题 {question} 请输出一个结构化的计划包含主要阶段、关键任务和依赖关系如果上下文中有。以Markdown格式输出。 PROMPT PromptTemplate( templateplanning_prompt_template, input_variables[context, question] ) # 更新qa_chain的prompt qa_chain.combine_documents_chain.llm_chain.prompt PROMPT # 7. 进行查询 print(\n系统就绪请输入你的规划问题输入quit退出) while True: query input(\n你的问题: ) if query.lower() quit: break print(正在思考...) result qa_chain({query: query}) print(\n--- 生成的计划 ---) print(result[result]) print(\n--- 参考来源前2个---) for i, doc in enumerate(result[source_documents][:2]): print(f[来源{i1}]: {doc.page_content[:200]}...) # 打印前200字符这个原型完成了从文档加载到生成规划的全流程。它使用了本地嵌入模型和本地LLM通过Ollama所有数据都在本地处理保证了隐私性。4.3 进阶将其升级为真正的Agent上面的例子是一个简单的RAG链。要升级为能主动决定检索时机的Agent我们需要使用LangChain的Agent框架。# planning_agent.py (进阶版) from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # ... 前面的文档加载、向量库创建代码与之前相同 ... # 定义检索工具 def doc_search(query: str) - str: 在项目文档中搜索相关信息。输入应为明确的关键词或问题。 docs retriever.get_relevant_documents(query) content \n\n---\n\n.join([f片段{i1}:\n{doc.page_content} for i, doc in enumerate(docs)]) return f从文档中检索到以下相关信息\n\n{content} if content else 未找到相关信息。 search_tool Tool( nameProjectDocumentSearch, funcdoc_search, description当需要从项目文档中查找具体事实、数据、时间线、目标或约束条件时使用此工具。输入应为一个具体的搜索查询。 ) # 初始化LLM和记忆 llm Ollama(modelllama2:7b, base_urlhttp://localhost:11434) memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 初始化Agent # 使用CONVERSATIONAL_REACT_DESCRIPTION类型它适合多轮对话和工具调用 agent initialize_agent( tools[search_tool], llmllm, agentAgentType.CONVERSATIONAL_REACT_DESCRIPTION, verboseTrue, # 设置为True可以看到Agent的思考过程ReAct步骤 memorymemory, handle_parsing_errorsTrue # 优雅处理解析错误 ) # 运行Agent print(Agent已启动。你可以开始询问关于文档的规划问题。) while True: human_input input(\n你: ) if human_input.lower() quit: break response agent.run(inputhuman_input) print(f\n助手: {response})在这个Agent版本中你不再需要手动构造复杂的提示词。你可以直接问“基于文档我们产品发布的第一阶段应该做什么” Agent会自己“思考”“要回答这个问题我需要先查一下文档里关于产品发布阶段的部分。”然后调用ProjectDocumentSearch工具获取资料后再组织语言回答。verboseTrue会打印出它的思考链非常有助于调试和理解其工作原理。5. 常见问题、优化策略与避坑指南在实际搭建和运行过程中你肯定会遇到各种问题。下面是我踩过的一些坑和总结的优化经验。5.1 检索效果不佳找不到关键信息这是最常见的问题。生成的计划空洞无物或者完全忽略了文档中的关键约束。可能原因1分块策略不当。块太大包含了太多无关信息稀释了关键内容的向量表示块太小割裂了完整语义。解决调整chunk_size和chunk_overlap。对于技术文档或报告500-1500字符的块大小比较常见。重叠部分建议在10%-20%之间。可以尝试不同的分块器如按标题分割的MarkdownHeaderTextSplitter。可能原因2嵌入模型不匹配。如果文档是中文却用了针对英文优化的嵌入模型如all-MiniLM-L6-v2效果会大打折扣。解决务必使用与文档语言匹配的嵌入模型。中文首选BAAI/bge系列如BAAI/bge-small-zh英文可选all-MiniLM-L6-v2或text-embedding-ada-002。可能原因3检索器返回结果数k值不合适。k太小可能遗漏重要信息k太大会引入噪声并增加LLM上下文负担。解决根据查询复杂度调整k。简单事实查询k2~3可能就够了复杂的规划问题可能需要k4~6。可以尝试使用MultiQueryRetriever或ContextualCompressionRetriever来智能地优化检索结果。可能原因4用户问题太笼统。例如“做个计划”LLM和检索器都不知道该找什么。解决引导用户提出更具体的问题或者在Agent的System Prompt中要求其先对复杂问题进行拆解生成多个具体的子问题再去检索。5.2 生成的内容“幻觉”Hallucination或偏离文档LLM可能会忽略检索到的上下文基于自身知识生成与文档不符的内容。可能原因1提示词不够强硬。没有明确指令LLM必须“严格基于”上下文。解决在提示词中反复强调“仅基于以下上下文”、“如果上下文没有提到请说不知道”、“禁止使用外部知识”。使用类似“你必须”、“严格限制”等强动词。可能原因2上下文位置或权重不够。检索到的上下文被淹没在冗长的提示词中。解决使用特殊的XML标签如context.../context将上下文包裹起来使其在提示词中更突出。或者在架构上采用Map-Reduce或Refine等更复杂的链式类型让LLM对多个文档块进行多次、逐步的消化。可能原因3LLM的“温度”Temperature参数过高。温度越高生成越随机、越有创造性但也越容易偏离事实。解决对于规划类任务将温度设置为较低值如0.1或0以增强其确定性和对上下文的忠实度。5.3 处理速度慢或成本高文档嵌入耗时首次处理大量文档时向量化过程可能很慢。解决将向量数据库持久化只需在文档更新时重新处理。对于生产环境考虑使用更快的嵌入模型如量化版的小模型或异步处理管道。LLM调用成本/延迟使用GPT-4等商用API费用和延迟是必须考虑的。解决本地LLM使用Ollama运行Llama2、Mistral等开源模型。虽然能力可能稍弱但零成本、隐私性好、延迟低。对于企业内部文档规划这通常是首选。模型分级简单的规划用小型/快速模型如GPT-3.5-Turbo复杂分析再用大模型。缓存对相同的查询和文档集缓存LLM的响应结果。5.4 安全与隐私考量文档内容泄露如果使用云端API如OpenAI Embedding或LLM你的文档内容会被发送到第三方服务器。解决对于敏感文档坚持全链路本地化本地嵌入模型如sentence-transformers 本地向量数据库如Chroma 本地LLM通过Ollama、vLLM等部署。这是企业级应用必须考虑的底线。提示词注入用户可能通过精心设计的输入让LLM执行非预期的操作或泄露系统提示词。解决对用户输入进行基本的清洗和过滤。在System Prompt中明确其角色和边界。在Agent框架中严格限制其可用的工具。5.5 我的独家优化清单元数据是黄金在分块时为每个块添加元数据如“文件名”、“章节标题”、“页码”。在检索时除了向量相似度还可以用元数据过滤例如只检索“技术方案.docx”这个文件里的内容精度大幅提升。查询重写Query Rewriting在用户查询送入检索器之前先用一个小LLM或规则对其进行改写或扩展。例如将“制定计划”扩展为“制定计划 目标 时间线 任务 负责人”。这能显著改善检索召回率。LangChain的MultiQueryRetriever就内置了这种思想。后处理重排序Re-ranking检索返回的Top K个片段按相似度排序不一定是最优的。可以使用一个专门的交叉编码器Cross-Encoder模型如BAAI/bge-reranker对它们进行重新打分和排序将最相关的片段排到最前面再送给LLM。这是提升RAG效果的大杀器。让规划“可执行”生成的计划不仅是文本可以尝试让其输出为结构化的数据格式如JSON。定义一个JSON Schema要求LLM输出包含tasks(列表),dependencies(依赖关系),estimated_hours(预估工时) 等字段的对象。这样后端可以直接解析并导入到项目管理工具如Jira, Asana中实现真正的自动化。构建一个基于文件的规划系统就像是为AI配备了一个私人资料库和一位善于查阅资料的助理。planning-with-files这个项目为我们提供了一个绝佳的起点和设计范式。从简单的RAG管道到智能的Agent架构其核心思想始终是让AI的决策和创造过程扎根于具体的、最新的信息土壤之中。在实际操作中最大的挑战往往不在算法本身而在于对文档特性的理解、对业务场景的把握以及那些细微的工程优化点上。希望这篇详细的拆解和实战指南能帮助你顺利搭建起自己的“AI规划师”并让它真正成为你处理复杂文档和任务的得力助手。