AI Agent项目启动指南：四步搭建通用工作流框架

很多人学了不少AI Agent的技巧——知道Git怎么用、MCP怎么配、大模型和输入法是什么关系，但真正要让AI帮自己干一件具体的活时,却卡在了第一步：不知道从哪儿开始。这其实是一个「破冰」问题。本文以一个几乎所有职场人都躲不掉的任务——年终总结汇报PPT为命题，从一个空文件夹出发，完整演示如何把AI Agent拉进自己的工作流。

需要说明：本文不教你具体怎么做年终总结PPT，而是教你「这件事该怎么开始」——一套可以复用到任何项目上的启动方法论。

核心转变：从「干活的人」到「派活的人」

整个方法论的起点，是一个角色的根本转变。

以前我们做PPT或文档，基本都是自己策划、自己动手：翻这一年的日报周报月报，找数据、找截图，一页一页往PPT里贴，所有逻辑都在自己脑子里过一遍。而现在换成AI来做，风向就变了——我们负责收集资料和统筹，AI负责具体动手。

这种角色转变在管理学中被称为「委托-代理」模型（Principal-Agent Model）。传统知识工作者习惯于端到端完成任务，但AI Agent的引入本质上创造了一个虚拟团队协作场景。麻省理工学院的研究表明，使用AI协作时，任务分解能力（而非具体执行能力）成为效率差异的关键因素。这意味着「提出好问题」比「给出好答案」更重要——这恰恰是管理者而非执行者的核心能力。掌握这种思维切换，是用好AI Agent的认知前提。

自己完成一件工作

这个转变会连带引出三件必须改变的事：

资料不再是自己看，而要放到AI能读到的地方。 有些资料受限于工具和环境（比如邮箱邮件、聊天记录），AI读不到，我们得想办法把它们导出、整理到一个AI能访问的文件夹里。这里涉及到MCP（Model Context Protocol）协议的应用——MCP是一种标准化协议，用于让AI模型能够安全、结构化地访问外部数据源和工具。它定义了AI Agent如何连接文件系统、数据库、API等资源的规范接口。通过MCP，我们可以让AI读取本地文件、访问云端服务或调用第三方工具，而不需要每次都手动复制粘贴内容。这个协议的核心价值在于标准化——就像USB接口统一了设备连接方式，MCP让不同的AI工具能以相同方式访问各类资源，大大降低了配置复杂度。在实际应用中，MCP解决了AI Agent「读不到数据」的根本问题：邮箱、聊天记录、企业内网文档等信息孤岛，都可以通过MCP适配器暴露给AI，让它真正成为能穿透多数据源的智能助手。MCP由Anthropic公司于2024年底正式提出并开源，迅速获得了行业广泛采纳。它的架构分为三层：MCP Host（宿主程序，如Claude Desktop或VS Code中的AI插件）、MCP Client（协议客户端，负责通信）和MCP Server（服务端，封装具体的数据源或工具能力）。开发者可以为任何数据源编写MCP Server——比如一个读取Notion数据库的Server、一个查询企业ERP系统的Server——然后任何支持MCP的AI工具都能无缝接入。这种「一次封装、处处可用」的设计，正在改变AI Agent与企业数据交互的方式。
资料要收集得足够齐备，且逻辑要串得起来。 自己做的时候可以「想起来了临时补」，但交给AI，如果资料不全，它要么跳过、要么会「编」出一些数据——而这些编造往往在最后审核时难以发现。这种现象在AI领域被称为**「幻觉」（Hallucination）**，是大语言模型最棘手的可靠性问题之一。模型的工作原理是基于概率预测下一个最可能的token（词元），当缺乏足够的上下文约束时，它会生成看似逻辑通顺、语言流畅但实际上完全虚假的内容——比如编造一个不存在的数据指标或杜撰一段从未发生的项目进展。幻觉之所以危险，是因为它的「置信度」很高：AI不会标注「这段是我编的」，输出的语气和真实信息一模一样。因此，提供充足、准确的输入资料是降低幻觉的第一道防线；第二道防线则是人工审核——永远不要跳过对AI输出的核实环节，尤其是涉及数字、日期和具体事实的部分。
必须明确告诉AI最终输出给谁看、要突出什么。 这些以前都是隐性知识，藏在我们脑子里；现在需要另一个角色来完成输出，就必须把它们显性地写出来。「隐性知识」这一概念源自日本学者野中郁次郎（Ikujiro Nonaka）的SECI知识转化模型。职场中大量关键信息——比如领导的审美偏好、汇报中应避免的敏感话题、数据呈现时该强调增长率还是绝对值——都以隐性知识的形式存在于个人头脑中，从未被文字化。将这些写成AI能理解的显性文档，实际上是一次强制性的认知结构化过程。很多人在撰写project.md时会发现，自己对「这份PPT到底要传达什么」的理解远没有想象中清晰——这个「被迫想清楚」的过程本身，就是引入AI协作带来的额外收益。

归结起来：我们从「自己完成一件工作」变成了「统筹一个项目」，角色从执行者变成了管理者。

借鉴程序员：项目启动需要四样东西

既然是统筹项目，就要有项目的样子。而AI帮我们处理具体事项时，本质上也是在「写代码」，因此最值得借鉴的就是程序员开发一个功能的标准流程。

这套流程并不复杂，核心只需要准备四样东西：

一个固定的项目文件夹（项目路径）
一份 System Prompt（规矩，规定AI如何执行任务）
一份项目说明文档（类似 project.md，讲清背景与诉求）
一份进度记录（一部分给AI看，一部分给自己看）

这四样东西的组合，本质上对应了软件工程中「代码仓库 + 配置文件 + 需求文档 + 版本控制」的经典四件套。程序员用这套方法管理代码已经数十年，其可靠性经过了无数大型项目的验证。现在我们要做的，只是把「代码」换成「PPT」「报告」「方案」等知识工作产物，底层逻辑完全一样。

演示工具选用的是程序员最常用的免费编辑器 VS Code。VS Code（Visual Studio Code）是微软开发的开源代码编辑器，但它的价值早已超越纯编程场景。它提供的「项目文件树+编辑区+终端」三栏布局，天然契合AI Agent的工作模式：左侧文件树让你掌控项目全局结构，中间编辑区用于查看和修改文件内容，底部终端则是与AI Agent交互的命令行界面。更重要的是，VS Code支持丰富的扩展生态——你可以安装Markdown预览、PDF查看、甚至直接集成AI对话窗口。它的设计哲学是「一切皆文件、一切可编辑」，这恰好匹配了AI Agent处理任务的方式：读取文件、分析内容、生成输出、写回文件。VS Code能成为AI Agent首选工作台，还有一个深层原因：它的底层架构基于Electron框架，本质上运行在一个浏览器环境中，这意味着几乎所有基于Web技术构建的AI工具都能以扩展（Extension）形式嵌入其中。Cursor、Windsurf、Augment Code等新一代AI编程工具也都是基于VS Code内核的分叉版本（Fork），验证了这种架构的通用性和扩展能力。对于非程序员用户，VS Code的学习曲线虽然存在，但一旦掌握这套「文件夹→文件→内容→执行」的工作流，就能将其应用到文档写作、数据整理、项目管理等几乎所有知识工作场景。

这里有一个有意思的观察：虽然VS Code出现很久了，但如今我们用Codex、以及各类Agent桌面端工具时会发现，它们的结构和要满足的需求都大同小异——熟悉了VS Code这个最经典的界面，再上手其他Agent工具都会很顺。

界面上，左侧是文件列表，右上方是查看文件内容的区域，右下方则是一个终端——所有的Agent命令都在这里输入。

第一步：建文件夹并初始化Git仓库

先创建一个项目文件夹，比如「工作总结汇报」。这里有一个关键提醒：文件夹一旦建好，最好不要自己去改名或挪动位置。

原因在于，大语言模型是靠文字记录来「寻找记忆」的。模型本身没有持久化的内存系统——它不像人脑那样有长期记忆，而是依赖对话历史和文件内容来建立「工作记忆」（Working Memory）。每次会话开始时，模型会读取上下文窗口（Context Window）内的所有信息来理解当前状态。当路径改变而对话记录中仍引用旧路径时，就会产生类似程序中的「空指针引用」错误——AI认为文件在A位置，实际上已经搬到了B位置，导致操作失败或产生混乱。这个问题在多会话、跨天工作的场景下尤为突出。如果你在不告诉AI的前提下改动了路径或文件名，它就找不到之前关于这个文件的相关记录，从而产生信息差。所以就算要改，也要让AI去帮你改路径、移动或重命名，让这个动作进入它的记录。

文件夹建好后，引入AI Agent。演示用的是一个开源、精简、运行极快的Agent工具，配合本地部署在Mac Studio上的**通义千问^广告开源模型**运行。通义千问（Qwen）是阿里云推出的大语言模型系列，其开源版本可以部署在本地设备上运行，无需联网或上传数据到云端。相比GPT-4、Claude等闭源商业模型，本地部署的开源模型有三大优势：第一是数据隐私，所有处理都在本地完成，公司机密、个人文件不会离开你的设备——这对处理年终总结这类包含业务数据的敏感文档尤为重要；第二是成本可控，无需按Token付费，适合大量文档处理任务；第三是响应速度，在高性能硬件（如Mac Studio配备M系列芯片的统一内存架构）上，本地模型的推理速度可以媲美甚至超过云端API。当然，本地部署也有代价：需要足够的硬件资源（至少16GB内存，最好有专用GPU或高性能CPU），模型能力可能略逊于最新的闭源旗舰模型。但对于处理敏感文档、需要大批量重复任务、或网络环境受限的场景，本地开源模型是更优选择。目前主流的本地模型运行框架包括Ollama、LM Studio和llama.cpp等，它们将复杂的模型部署简化为几条命令，大幅降低了非技术用户的使用门槛。

这是一个特别精简的AI Agent

启动Agent后，第一件事是初始化Git仓库。Git是由Linux之父Linus Torvalds于2005年创建的分布式版本控制系统，最初为管理Linux内核源代码而设计，如今已成为全球软件开发的事实标准。但其核心价值——「追踪每一次改动的完整历史」——对AI协作同样关键。在AI Agent场景下，Git解决了三个痛点：第一，它记录了「谁在什么时间改了什么」，当AI产生错误输出时，你可以精确回退到上一个正确版本，而不是从头再来；第二，它让AI能「看到」项目的演进轨迹，理解当前状态是如何一步步形成的，这对于跨会话的连续工作至关重要；第三，当多个AI Agent或人机协作时，Git的分支（Branch）机制可以让不同思路并行试验而不互相干扰——比如你可以让AI在一个分支上尝试「数据驱动」风格的PPT，在另一个分支上尝试「叙事驱动」风格，然后选择更好的那个。commit（提交）操作就像游戏存档点，每次阶段性完成都应该提交一次，确保有清晰的回溯路径。这相当于给整个项目文件夹装上了一个「带时间线的另存为」。Git的操作虽然最初通过命令行进行，但现在VS Code已经内置了图形化的Git面板，点击几下按钮就能完成提交、回退、查看历史等操作，完全不需要记忆命令。

紧接着让AI创建一个 .gitignore 文件。.gitignore是Git的配置文件，用于指定哪些文件或文件夹不应该被版本控制追踪。为什么需要它？因为项目中并非所有文件都有追踪价值：临时文件（如macOS的.DS_Store、Windows的Thumbs.db）、编译产物、大型媒体素材、敏感信息（密码、API密钥）等，既占用仓库空间，又会干扰版本历史的可读性。在这个项目中，我们让AI忽略掉MP4、AVI等音视频素材和系统临时文件——否则一个几百MB的视频文件提交进去，整个Git仓库的性能就会急剧下降。Git本质上是为文本文件优化的系统，对二进制大文件的处理效率较低。正确配置.gitignore可以让Git仓库保持轻量、聚焦于真正重要的文本和配置文件，同时避免因文件过大导致仓库损坏或操作缓慢。如果确实需要管理大型二进制文件，可以使用Git LFS（Large File Storage）扩展，但对于PPT项目来说，.gitignore通常已经足够。

先建仓库再做后续工作的好处是：从创建第一个文件起，整个项目就已经有了完整的执行历史，且这个记录在AI删改任何东西之前就已生效。

第二步：编写执行规矩（agents.md）

别急着做PPT，先写规矩。

在项目文件夹里放一个固定命名的文件 agents.md，这是行业通用约定（Claude单独读 CLAUDE.md，但多数Agent默认读 agents.md）。AI在干活前会先读这份System Prompt，从中了解在这个项目里该怎么运行、什么允许、什么不允许。

System Prompt是AI模型在执行任务前接收的「系统级指令」，它定义了AI的行为规范、角色设定和执行边界。可以把它理解为给AI设定的「人设」和「工作守则」。一个完整的System Prompt通常包括：身份定位（你是什么角色）、能力范围（能做什么不能做什么）、输出格式要求、以及特定场景下的处理原则。它的优先级高于用户的具体指令——就像公司章程高于具体工作安排。这意味着如果System Prompt规定「输出不超过500字」，即使用户要求「写一篇详细的3000字报告」，AI也应该遵守System Prompt的限制（当然，具体行为取决于模型的实现和指令冲突解决策略）。System Prompt是「Prompt Engineering（提示工程）」这一新兴领域的核心组成部分，已经成为企业级AI应用开发中最重要的环节之一。

AI在干活前会先读几个规矩

这里有一个重要的分层概念：Agent运行时通常会读多层System Prompt——

全局层：在所有项目、所有对话里都生效；
项目层：只在当前项目下生效。

多层System Prompt机制让我们可以设置全局通用规则（比如「永远用中文回复」「每次修改文件前先备份」），同时为不同项目定制专属规则（比如「这个项目里代码必须加详细注释」「PPT风格偏商务简洁」）。这种分层设计借鉴了软件工程中的「配置继承」模式——全局配置提供默认值，项目配置可以覆盖或扩展全局设定。我们创建的 agents.md 属于项目层，只在当前项目生效。换个项目、规矩不同，就要在新项目下另建一份。AI最终读到的，是全局规则加上各项目自身规则的汇总。当规则发生冲突时，通常项目层优先——就像地方法规在不违反上位法的前提下优先适用。

每个人、每个行业做PPT的方式不同，你完全可以把自己的具体要求填进这份文档，让AI照做。例如：「所有数据图表必须标注数据来源」「每页PPT文字不超过50个字」「配色使用公司品牌VI色」等——越具体，AI的输出就越接近你的预期。

第三步：撰写项目说明文档（project.md）

接下来是项目背景说明，推荐用 project.md 承载。

写这份文档的思路，就像你要把一份工作交接给另一个同事——他需要知道：项目背景、当前状态、以及最终交付标准。这种思维方式在项目管理领域有一个成熟的对应物：项目章程（Project Charter）。在PMP（Project Management Professional）体系中，项目章程是正式授权项目存在的文档，包含项目目标、范围、主要利益相关者、约束条件和交付标准。project.md本质上就是一份轻量化的项目章程，只不过「项目团队」变成了你和AI。以年终汇报为例，可以写入这些信息：

当前岗位与项目背景
受众：直属领导是部门总监
汇报场景：面向整个team汇报
语气要求：坚定
重点：突出今年花时间最多的两三个项目
交付标准：最终PPT要达到什么样子

这里需要特别强调：你必须对「什么样的交付物才算满意」有非常清晰的要求。 这在软件工程中被称为「验收标准」（Acceptance Criteria），是判断一个需求是否完成的客观依据。好的验收标准应该是可量化、可验证的——比如「PPT不超过15页」「每个项目至少包含一张数据图表」「关键成果用数字而非形容词描述」，而不是模糊的「做得漂亮一点」。你要自己想清楚——拿到手的这份PPT长什么样你才会满意——这个标准要提前定义好，否则AI无从评估自己是否完成得不错。明确的验收标准不仅帮助AI对齐输出，也帮助你自己在审核时有据可循，避免陷入无休止的「再改改」循环。

第四步：整理资料与进度记录

最后是资料和进度管理，用几个文件夹分工：

创建资料整理文件夹

inbox 文件夹：放AI要用的所有原始素材——数据、图片、记录、邮件等，凡是AI能读到、能提升汇报质量的信息都往这里放。
output 文件夹：放每个阶段、每个版本输出的最终产物。

inbox/output的文件夹结构借鉴了软件工程中的**「管道模式」（Pipeline Pattern）**：原始数据从一端进入（inbox），经过AI处理后从另一端输出（output），数据流向是单向且可追溯的。这种设计的好处是职责清晰——inbox只负责存放输入素材，output只负责存放产出物，避免了中间草稿、临时文件和最终成品混在一起导致的版本混乱。如果项目更复杂，还可以增加一个 drafts 或 working 文件夹存放中间过程文件，但对于大多数任务，inbox + output两级结构已经足够清晰。

对于跨越多天的长任务，如何让AI（和自己）记住「上次做到哪了」？有两个办法：

看Git记录：Git里本就有每次增删文件的记录；
建 CHANGELOG.md：更直观地记录「几月几号改了什么、输出了什么版本」，方便定期回顾。

CHANGELOG（变更日志）是软件工程中记录项目演进历史的标准文档，通常以Markdown格式编写。它的核心作用是用人类可读的语言，按时间倒序记录「每个版本做了什么改动」。相比Git commit记录的技术细节（changed 3 files, +127 -45 lines），CHANGELOG关注的是业务层面的变化：「增加了什么功能」「修复了什么问题」「改进了什么体验」。在AI Agent项目中，CHANGELOG承担双重角色：一是让AI理解项目进展脉络（「上周我们完成了数据清洗，这周要做可视化」），二是方便人类快速回顾关键节点（「三天前那版PPT结构更好，回退到那个版本」）。标准的CHANGELOG遵循「Keep a Changelog」规范和语义化版本号（Semantic Versioning），用 ## [版本号] - 日期 作为标题，下分 Added（新增）、Changed（变更）、Fixed（修复）、Removed（移除）等类别。这种结构化的记录方式，比散乱的便签或脑中记忆可靠得多——特别是当项目周期拉长到数周时，没有CHANGELOG你几乎一定会忘记中间的迭代细节。

还有一个必须养成的习惯：每次阶段性编辑、交付、验收之后，都要提交一次Git记录。 只有提交后，才能明确知道当前项目进行到哪一步。操作很简单——直接对AI说「帮我提交当前修改，并在CHANGELOG里增加相应记录」，AI就会自动完成Git commit和日志更新。这个操作只需要一句话，但它带来的项目可追溯性是无价的。养成每次阶段性交付都更新CHANGELOG的习惯，相当于给项目建立了一条清晰的记忆线索——不仅AI能据此恢复上下文，你自己也能在任何时候快速回忆起项目全貌。

总结：一套可复用的AI Agent项目启动模板

把整个启动阶段归纳起来，其实就是四件事：

定规则：把执行要求写进 agents.md
说背景：把项目背景、受众、交付指标写进 project.md
理资料：把AI需要的素材整理进 inbox
记进度：用Git + CHANGELOG.md 追踪版本，产物迭代进 output

这套方法的价值不在于「做年终总结」，而在于它提供了一个通用的破冰框架：当你面对任何一件想交给AI的复杂工作时，都可以先按「派活人」的思路，把规矩、背景、资料、进度这四样东西准备好，再让Agent跑起来。无论是写市场分析报告、制作产品方案、整理技术文档、还是策划活动方案，这四步启动流程都完全适用——变化的只是每个文件的具体内容，框架本身是稳定的。

本质上，这是把程序员成熟的工程化协作方法，迁移到了每个人的日常工作中。软件工程经过数十年的实践，已经沉淀出一套管理复杂度、协调多方协作、确保可追溯性的方法论。而AI Agent的出现，让这套方法论第一次对非技术人员产生了直接价值——因为你现在确实在「管理」一个（AI）团队成员。学会「统筹项目」而非「亲自干活」，或许才是普通人用好AI Agent真正的第一步。