我们如何用 Claude Code 搭建了一个 AI 项目经理
Claude Code 用于非技术工作将在 2026 年席卷全球。以下是我们如何为咨询业务搭建内部项目经理 Claudie 的过程。这个过程也很好地展示了我作为应用 AI 工程师的角色。
我的角色
我是 @every 的应用 AI 工程师。我的工作是把我们从客户项目、行业动态和内部实验中学到的所有 AI 知识——转化为可扩展的系统。课程、自动化、框架。我把客户在需求沟通中给出的洞察转化为课程内容，供设计师打磨成最终交付给客户的材料。当销售、规划或交付环节出现重复性任务时，我会搭建自动化、编写文档并培训内部团队使用。
我搭建过最高价值的内部自动化系统，就是我接下来要讲的这个。
我们需要自动化什么
Every Consulting 完全基于 Google Sheets 运行。每个客户都有一个详细的仪表盘——每个表格最多 12 个数据表——追踪人员、团队、会议、交付物、反馈和待办事项。让这些表格保持准确和实时更新，实际上是一个全职人员的工作量。
@NataliaZarina，我们的咨询负责人，是在 20 多项其他工作之外还要做这件事。她管理客户关系、跑销售、对项目范围和交付做最终决策——同时还要手动更新仪表盘、交叉核对邮件和日历事件、确保一切最新。这本来是两个人的活儿，她一个人干两份。
所以我自动化了第二个人。
第 1 步：撰写岗位描述
我做的第一件事是让 Natalia 写一份岗位描述。不是给 AI Agent 写的——而是给人类写的。我让她想象自己正在招聘一个项目经理：她希望这个人做什么、具备哪些素质、什么指标能表明他们胜任这个角色，以及一份真实 JD 里该有的所有内容。
（见图 1）
拿到这份岗位描述后，我开始思考如何把它转化为 Agent 工作流。这种框架——把它当作招聘一个真人来看待——最终指导了我们所有的架构决策。后面会详细说。
第 0 步：搭建工具
在开始任何 Agent 工作之前，我们需要让 Claude Code 能够访问我们的 Google Workspace。咨询业务的所有数据都在这里——Gmail、Calendar、Drive、Sheets。
Google 并没有为他们的 Workspace 工具提供官方的 MCP 服务器。但这里有个大多数人都不知道的事：MCP 本质上只是 API 上的一层封装。如果你有某个东西的 API，你基本上就有了它的 MCP。我使用了 Claude Code 的 MCP Builder 技能——我给它提供了 Google Workspace API，让它为我搭建一个 MCP 服务器，它就照做了。
确认 Claude Code 能与 Google Sheets 配合后，最大的不确定因素就解决了，我们知道它能完成我们所需要的工作。
第 1 版：斜杠命令
接下来是上下文工程。我们首先尝试创建了一组斜杠命令——简单的指令，告诉 Claude 对每项工作做什么。
这本质上是把斜杠命令当作文本展开器来用，但效果不好。失败的关键原因在于：使用 MCP 工具读取数据源并填充表格，在上下文方面代价太高。等到 Agent 能够读取数据源并理解需求时，它的上下文窗口已经不够用了。我们都知道这对质量意味着什么——质量急剧下降。
所以这条路走不通。
第 2 版：编排器与子 Agent
也正是在这个时候，Anthropic 发布了新的 Tasks 功能。我们决定采用新架构：让主 Claude 作为子 Agent 的编排器，创建多个任务，每个任务由一个子 Agent 处理。
但这又遇到了另一个意料之外的问题。当主 Claude 同时启动 10 个或更多子 Agent 时，它的上下文窗口会被淹没。每个子 Agent 会返回一份详细报告，这么多报告同时发给编排器，会直接撑爆它的上下文窗口。
举个例子，我们最初的几个任务会启动数据调查 Agent，它们查看原始数据源，根据特定来源（如 Gmail 或 Calendar）生成一份关于某客户在特定时间段内发生了什么事的详细报告。这些子 Agent 的输出需要被后续所有子 Agent 读取——最多达 35 个。如果让主编排器在子 Agent 之间传递所有必要信息，信号丢失几乎是必然的。
解决方案：共享文件夹
所以我们做了一处小改动。我们让每个子 Agent 将最终报告输出到一个临时文件夹，并告诉编排器去哪里找。现在主 Claude 按需读取报告，下游的子 Agent 也能直接读取前面阶段的报告。
这彻底解决了问题。同时也改善了子 Agent 之间的沟通，因为它们可以直接读取彼此的完整输出，无需编排器做摘要或转述。
（见图 2）
第 3 版：从技能到手册
编排工作跑通后，我最初为每项具体工作创建了独立的技能——gather-gmail、gather-calendar、check-accuracy、check-formatting 等等，总共 11 个技能。每个子 Agent 读取自己需要的技能，获取任务所需的所有上下文。
这样是能工作，但很难看。这些技能非常具体、狭窄，给系统带来了各种脆弱性。更别提连人类都不容易阅读和维护了。
这时候，职位描述的思路又回来了。我们最初的做法，就像在招一个真人。我们给这个"员工"写了一份职位描述。那么，当你真的招到一个人之后，你会怎么做？你会给他们一本入职手册——一份涵盖了你们团队做事方式的文档，告诉他们用这本手册来完成工作的一切方面。
所以我们就是这么做的。我们构建了一个单一的项目管理技能，整个手册按章节组织：
• 基础 —— 我们是谁、团队构成、我们的工具和数据源、何时升级问题、数据准确性标准
• 日常运营 —— 如何从所有数据源收集数据
• 客户仪表盘 —— 仪表盘的结构、主仪表盘追踪的内容、如何运行质量检查
• 新客户 —— 如何从零开始接入新客户并设置他们的仪表盘
现在，当一个子 Agent 启动时，它会先阅读基础章节（就像新员工一样），然后阅读与其具体任务相关的章节。这本手册取代了十一个零散技能，变成了一个统一的真相源。
最终架构如下：见截图4。
这种体验像什么
这是我两周以来做过最令人振奋的工作，而且各种感觉交织在一起。
和 @NataliaZarina 合作是最重要的一环。我们连续打了好几个小时电话，各自在电脑上运行 Claude Code 会话，互相交换输入。她有品味——她知道仪表盘该长什么样、数据该包含什么、对我们客户来说什么才算质量。我有 AI 工程能力。一起做这件事真的让人兴奋。
然后是速度。两周内我们经历了三次主要架构迭代。一切变化都那么快。而最令人激动的是，我们有多拼命地驱动 Claude Code。我使用 Claude Code 写代码已经好几个月了，但以前从没这么拼过。过去这两周，我 consistently 用完了使用限制。事实上，我和 Natalia 好几天都同时用完了终极最大套餐的合并使用量。当你消耗那么多 AI 推理资源时，你可以想象事情推进得多快。那真的太他妈激动人心了。
这也是一个完全新颖的问题。应用 AI 工程作为一个学科仍然很新，而这是我对它的思考方式第一次发生真正的大转变。
为什么是现在，为什么是 2026
这就是我开头为什么说"Claude Code 用于非技术工作将在 2026 年席卷世界"的原因。
我们意识到，如果你让 Claude Code 能访问你作为非技术人员使用的工具，并且投入精力构建一个覆盖你实际使用这些工具方式的工作流，那就足够了。非技术工作就是这么回事。
之前没人这么做，是因为我们把 Claude Code 用到了极限。换成之前的 AI 版本或之前的 Claude Code 版本根本不可能。我们 literally 用的是最新功能和最新模型。它需要推理并理解底层工具及操作方法，同时具备规划和上下文管理能力——这些能力六个月前还不存在。
但现在它们存在了。而且现在才一月。
让这一切成为可能的每一块堆栈都是全新的：
• MCP Builder 技能 —— 我通过让 Claude Code 使用 Google Workspace API 构建了我们自己的 Google Workspace MCP 服务器。这在 Anthropic 于 2025 年 10 月 16 日发布 MCP Builder 之前是不可能的。
• Opus 4.5 —— 它的推理和规划能力让整个编排成为可能。Agent 需要理解复杂的表格结构、弄清楚数据该放到哪里，并协调几十个子 Agent。发布于 2025 年 11 月 24 日。
• Tasks 功能 —— 通过 Tasks 进行子 Agent 编排才让版本 2 和版本 3 成为可能。该功能于 2026 年 1 月 23 日发布。
这就是为什么我说"Claude Code 用于非技术工作将在 2026 年席卷世界"。积木刚到手。
评论区作者自回复：
更多细节我会很快在 @every 上分享 - 在此订阅
@BChris91 这报告真酷！我感觉被印证了😂
@kelvongx 没错！只需要在你的指令里用这些魔法词，就能像我们一样做 Agent 编排：
"使用任务工具追踪并完成这个任务。我希望你先制定一个全面的任务列表，并为每个任务添加通用型 Agent。添加阻塞项"
@K1ngArtes 无需写代码。只用 Claude Code 和它的功能就行。