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

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

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

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

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

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

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

• 资料不再是自己看，而要放到AI能读到的地方。 有些资料受限于工具和环境（比如邮箱邮件、聊天记录），AI读不到，我们得想办法把它们导出、整理到一个AI能访问的文件夹里。这里涉及到MCP（Model Context Protocol）协议的应用——MCP是一种标准化协议，用于让AI模型能够安全、结构化地访问外部数据源和工具。它定义了AI Agent如何连接文件系统、数据库、API等资源的规范接口。通过MCP，我们可以让AI读取本地文件、访问云端服务或调用第三方工具，而不需要每次都手动复制粘贴内容。这个协议的核心价值在于标准化——就像USB接口统一了设备连接方式，MCP让不同的AI工具能以相同方式访问各类资源，大大降低了配置复杂度。

• 资料要收集得足够齐备，且逻辑要串得起来。 自己做的时候可以「想起来了临时补」，但交给AI，如果资料不全，它要么跳过、要么会「编」出一些数据——而这些编造往往在最后审核时难以发现。

• 必须明确告诉AI最终输出给谁看、要突出什么。 这些以前都是隐性知识，藏在我们脑子里；现在需要另一个角色来完成输出，就必须把它们显性地写出来。

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

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

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

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

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

演示工具选用的是程序员最常用的免费编辑器 VS Code。VS Code（Visual Studio Code）是微软开发的开源代码编辑器，但它的价值早已超越纯编程场景。它提供的「项目文件树+编辑区+终端」三栏布局，天然契合AI Agent的工作模式：左侧文件树让你掌控项目全局结构，中间编辑区用于查看和修改文件内容，底部终端则是与AI Agent交互的命令行界面。更重要的是，VS Code支持丰富的扩展生态——你可以安装Markdown预览、PDF查看、甚至直接集成AI对话窗口。它的设计哲学是「一切皆文件、一切可编辑」，这恰好匹配了AI Agent处理任务的方式：读取文件、分析内容、生成输出、写回文件。

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

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

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

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

原因在于，大语言模型是靠文字记录来「寻找记忆」的。如果你在不告诉AI的前提下改动了路径或文件名，它就找不到之前关于这个文件的相关记录，从而产生信息差。所以就算要改，也要让AI去帮你改路径、移动或重命名，让这个动作进入它的记录。

文件夹建好后，引入AI Agent。演示用的是一个开源、精简、运行极快的Agent工具，配合本地部署在Mac Studio上的通义千问开源模型运行。通义千问是阿里云推出的大语言模型系列，其开源版本可以部署在本地设备上运行，无需联网或上传数据到云端。相比GPT-4、Claude等闭源商业模型，本地部署的开源模型有三大优势：第一是数据隐私，所有处理都在本地完成，公司机密、个人文件不会离开你的设备；第二是成本可控，无需按Token付费，适合大量文档处理任务；第三是响应速度，在高性能硬件（如Mac Studio）上，本地模型的推理速度可以媲美甚至超过云端API。处理私人文件时用本地开源模型，隐私更有保障。

启动Agent后，第一件事是初始化Git仓库。Git是分布式版本控制系统，最初为软件开发设计，但其核心价值——「追踪每一次改动的完整历史」——对AI协作同样关键。在AI Agent场景下，Git解决了三个痛点：第一，它记录了「谁在什么时间改了什么」，当AI产生错误输出时，你可以精确回退到上一个正确版本；第二，它让AI能「看到」项目的演进轨迹，理解当前状态是如何一步步形成的；第三，当多个AI Agent或人机协作时，Git的分支机制可以让不同思路并行试验而不互相干扰。commit（提交）操作就像游戏存档点，每次阶段性完成都应该提交一次，确保有清晰的回溯路径。这相当于给整个项目文件夹装上了一个「带时间线的另存为」。

紧接着让AI创建一个 .gitignore 文件。.gitignore是Git的配置文件，用于指定哪些文件或文件夹不应该被版本控制追踪。为什么需要它？因为项目中并非所有文件都有追踪价值：临时文件（如.DS_Store、Thumbs.db）、编译产物、大型媒体素材、敏感信息（密码、密钥）等，既占用仓库空间，又会干扰版本历史的可读性。在这个项目中，我们让AI忽略掉MP4、AVI等音视频素材和系统临时文件——否则大量无关文件提交进去，Git仓库可能就没法用了。正确配置.gitignore可以让Git仓库保持轻量、聚焦于真正重要的文本和配置文件，同时避免因文件过大导致仓库损坏或操作缓慢。

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

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

别急着做PPT，先写规矩。

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

System Prompt是AI模型在执行任务前接收的「系统级指令」，它定义了AI的行为规范、角色设定和执行边界。可以把它理解为给AI设定的「人设」和「工作守则」。一个完整的System Prompt通常包括：身份定位（你是什么角色）、能力范围（能做什么不能做什么）、输出格式要求、以及特定场景下的处理原则。它的优先级高于用户的具体指令——就像公司章程高于具体工作安排。

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

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

多层System Prompt机制让我们可以设置全局通用规则（比如「永远用中文回复」），同时为不同项目定制专属规则（比如「这个项目里代码必须加详细注释」）。我们创建的 agents.md 属于项目层，只在当前项目生效。换个项目、规矩不同，就要在新项目下另建一份。AI最终读到的，是全局规则加上各项目自身规则的汇总。

每个人、每个行业做PPT的方式不同，你完全可以把自己的具体要求填进这份文档，让AI照做。

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

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

写这份文档的思路，就像你要把一份工作交接给另一个同事——他需要知道：项目背景、当前状态、以及最终交付标准。以年终汇报为例，可以写入这些信息：

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

这里需要特别强调：你必须对「什么样的交付物才算满意」有非常清晰的要求。 你要自己想清楚——拿到手的这份PPT长什么样你才会满意——这个标准要提前定义好，否则AI无从评估自己是否完成得不错。

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

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

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

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

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

CHANGELOG（变更日志）是软件工程中记录项目演进历史的标准文档，通常以Markdown格式编写。它的核心作用是用人类可读的语言，按时间倒序记录「每个版本做了什么改动」。相比Git commit记录的技术细节（changed 3 files, +127 -45 lines），CHANGELOG关注的是业务层面的变化：「增加了什么功能」「修复了什么问题」「改进了什么体验」。在AI Agent项目中，CHANGELOG承担双重角色：一是让AI理解项目进展脉络（「上周我们完成了数据清洗，这周要做可视化」），二是方便人类快速回顾关键节点（「三天前那版PPT结构更好，回退到那个版本」）。

还有一个必须养成的习惯：每次阶段性编辑、交付、验收之后，都要提交一次Git记录。 只有提交后，才能明确知道当前项目进行到哪一步。操作很简单——直接对AI说「帮我提交当前修改，并在CHANGELOG里增加相应记录」，AI就会自动完成Git commit和日志更新。养成每次阶段性交付都更新CHANGELOG的习惯，相当于给项目建立了一条清晰的记忆线索。

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

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

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

这套方法的价值不在于「做年终总结」，而在于它提供了一个通用的破冰框架：当你面对任何一件想交给AI的复杂工作时，都可以先按「派活人」的思路，把规矩、背景、资料、进度这四样东西准备好，再让Agent跑起来。

本质上，这是把程序员成熟的工程化协作方法，迁移到了每个人的日常工作中。学会「统筹项目」而非「亲自干活」，或许才是普通人用好AI Agent真正的第一步。