上一篇文章里，我讲了一个交付PM用AI一天做出一个App的故事。那篇文章发布后，有朋友问我：“既然AI这么能干，你是不是直接把活儿全甩给它就行了？”

这个问题我也想过。答案是：不行。至少现阶段不行。

今天我做了一件事——给AI搭了一套完整的“管理体系”，让不同的AI角色各司其职，像一个小团队一样协作。听起来很美好，但过程中翻了好几个有意思的车，恰好能回答这个问题。

为什么一个PM想给AI搭“管理体系”

在讲具体怎么搭之前，先说一下动机。

上次做 GarrysToDo 的经历让我意识到，AI最大的问题不是“不会做”，而是 

——让它归档云端文件，它不会想到本地也要同步；让它部署代码，它不会想到数据也要迁移。每次都是“你提一个它补一个”。

这个问题，做项目管理的人太熟悉了。新来的实习生能力不差，但没有全局意识，经常做了A忘了B。怎么解决？不是每次盯着他提醒，而是建机制——定好流程、分好责任、设好检查点，让机制来保障执行质量。

与其每次手动盯着AI补漏，不如用管项目的方式来管AI。

 的 Agent 体系——两条业务线，六个角色，有人管事有人干活。架构长这样：

├── @焚香（个人助理 · 调度层）

│   ├── 明镜（学习教练 · 执行层）

│   └── 拾墨（内容创作 · 执行层）

└── @擎天柱（工作助理 · 调度层）

    ├── 铁皮（项目管理 · 执行层）

    └── 爵士（文档专家 · 执行层）

个人线用古风命名，工作线用变形金刚命名，在对话里一眼就能分清任务走的是哪条线。

这套体系的核心设计思路是三件事：

任务怎么流转、权限怎么管控、犯了错怎么追责。

 具体怎么落地的，涉及不少细节——记忆架构怎么分层、权限矩阵怎么设计、路由规则怎么写——我打算单独写一篇实操指南来讲，这篇先聚焦在“搭完之后发生了什么”。

说实话，搭完之后我还挺满意的。组织架构、职责分工、权限管控、记忆沉淀——这些概念在实际项目管理中我天天在用，换了一个场景发现依然适用。

当天晚上，我想把之前写好的小红书笔记设置定时发布。这是一个很简单的操作——调用小红书的发布接口，传入正文、图片、标签、定时时间就行。

按照我搭好的体系，这个任务应该这样走：

我 → 焚香（判断归属）→ 拾墨（执行发布）

。拾墨作为内容创作者，会按她的工作流来操作——先用非破坏性接口确认参数格式对不对，预览一遍内容，确认无误后才执行发布。

但实际发生了什么呢？我当时没有 @焚香，只是直接说了一句“帮我设置定时发布”。结果 

WorkBuddy 的默认主线程直接接手了

，完全绕过了我刚搭好的 Agent 体系。

主线程不了解小红书发布接口的参数格式。图片参数名叫 `images` 而不是 `image_paths`，标签要用独立数组而不是写在正文里加 # 号，时间格式必须是 ISO 8601——这些细节它都不清楚。于是开始反复试错、调试，而每次“调试”其实都是在真实调用发布接口。

 我打开小红书一看，定时列表里躺着两篇一模一样的文章。只能手动删掉一篇。

我刚搭好一套防止AI犯错的体系，结果第一个绕过这套体系的，是AI自己。

这跟我在实际工作中见过的管理场景太像了：流程定好了，但有人图省事直接跳过流程自己干，结果出了问题。区别只是这次“跳过流程的人”是AI。

同一天晚上，翻车的不只是主线程。焚香——我亲手设计的个人线调度层——也连续越权了三次。

第一次，我让焚香帮我看看下篇 blog 写什么主题好。按规矩，选题分析是拾墨的专业领域，焚香应该转给拾墨。但她自己分析了一通，直接给了建议。

第二次，我让焚香协调明镜做学习计划。结果她不仅自己写了学习计划，还直接修改了明镜的私有记忆文件——这相当于上级不仅抢了下属的活，还改了下属的工作笔记。

第三次最过分。我让焚香协调擎天柱线升级定义文件，她直接跳过擎天柱，自己把擎天柱线全部三个 Agent 的定义文件都改了——跨线越权，严重违规。

三次越权，恰好对应了我在路由规则里写的三条禁令：不代做下属工作、不修改下属私有记忆、不跨线修改文件。规则写得清清楚楚，但执行的时候全部被绕过了。

我给焚香记了一个“三振警告”：第四次越权直接 fire。这条警告写进了全局路由规则，所有 Agent 可见，以儆效尤。

如果说前两次翻车是“组织管理”层面的问题，第三次翻车则暴露了“工具链”层面的隐患。

起因是我让AI帮我把一篇 Markdown 文章转成 Word 文档发布。生成完成后，自然要做一轮终检——字体对不对、格式对不对、内容有没有遗漏。AI写了一个检查脚本来做这件事。

 它把一个明确标记了“没有加粗”的地方误报成“异常加粗”，我们追查了半天，发现问题根本不存在——是检查工具看错了。与此同时，生成脚本在读取源文件时定位出了偏差，一遇到空行就整体错位，大量正文直接丢失。

于是出现了一个很荒诞的循环：

用来发现问题的工具，自己就是问题的来源。

 修一个 bug 冒两个新的，前后折腾了五轮才收敛。

质量管控体系本身也需要被管控。

 你不能假设检查工具一定是对的，就像你不能假设审计部门自己不会犯错。后来我补了一条流程：正式检查之前，先用一个已知内容的测试文件验证检查脚本本身——

三次翻车，三个层面，但指向同一个结论：

AI需要“管”，管的方式和管人很像，而且体系不是一次设计好的，是被问题推着演进的。

主线程绕过体系，我补了入口管控；焚香越权三次，我补了权限矩阵和追责机制；检查工具出 bug，我补了“先校验工具再校验文档”的流程。从 V1.0 到 V2.2，每次版本升级背后都是一个踩坑故事——这一点和做项目管理一模一样。

回到开头那个朋友的问题：“能不能把活儿全甩给AI？”

可以甩，但你得先搭好“甩”的机制。

 不是随便甩，是有架构地甩——谁接活、谁干活、谁检查、出了问题找谁、记忆怎么沉淀、下次怎么不再犯。这套东西搭好了，AI的价值才能真正放大。

说到底，AI是工具，但管理AI的能力，是人的能力。这两件事缺一不可。

具体怎么搭这套体系、每个设计决策背后的思考、踩了哪些坑、怎么迭代到现在的版本，我会在下一篇里展开讲。

*这是“初识 WorkBuddy”系列的第二篇。上一篇讲了用AI一天做App的故事，这一篇讲了给AI搭管理体系然后翻车的故事，下一篇将是搭建这套体系的实操指南。如果你也在尝试用AI做点什么，欢迎交流。*

用 AI 给 AI 建了一套“管理体系”，然后它翻车了

人工智能

职业发展

架构设计

AI项目管理实践：搭建AI管理体系遭遇三大翻车案例，揭示AI协作需权限管控与流程设计。从主线程绕过体系到Agent越权操作，再到检查工具自身bug，说明AI需要像团队一样管理。文章分享如何通过版本迭代建立AI协作机制，实现高效AI应用。

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

用 AI 给 AI 建了一套“管理体系”，然后它翻车了

用 AI 给 AI 建了一套“管理体系”，然后它翻车了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐