别再做万能 AI：用 Codex 组建 AI 员工团队，让 Discord 成为工作入口

先说结论：不要再做一个万能 AI

把 AI 接入工作时，很多人会先做一个“什么都能干”的超级助手：看日程、回邮件、提醒任务、整理照片台账、清理图纸、登记客户、生成报价，还要查询销售数据。

这种设计往往早期惊艳、后期失控。业务越多，规则越容易互相干扰，回答越容易变长，责任边界越容易模糊，原本稳定的功能也会变得难以维护。

更稳妥的方式，是把 AI 当成一家公司：由主秘书负责接待和分派，再让不同的专业代理分别负责日程、邮件、文件、客户和销售。Discord 同时承接入口、审批、通知、文件与日志。

本文将从问题、架构、业务手册、结构化输出、审批、Discord 运维、服务层和落地顺序几个方面，整理一套可逐步实现的 AI 员工团队方案。

一、万能 AI 为什么会失控

问题不只是提示词太长，更是上下文混线。

日程助手需要遵守“今天和明天按 Asia/Tokyo 解释”；邮件代理需要“只返回完成的邮件正文”；照片台账代理需要“一次只询问下一张照片”。这些规则单独看都合理，但全部塞进一个巨大提示词后，模型要不断判断当前应该优先哪一套规则。

另一个问题是修改范围不可控。只想修复照片台账时，却必须在总提示词里找相关段落，还要担心影响日程和邮件。很多 AI 项目不是能力不足，而是责任边界没有拆开。

因此，设计时应该先回答：谁接收请求、谁负责分派、哪些操作只读、哪些操作必须审批、成果物放在哪里、哪类经验归哪个员工。

二、把 AI 设计成一个小型组织

团队中心是主秘书，负责读取自然语言请求、判断任务类型、选择专业代理、合并结果并管理审批边界。

可以逐步增加这些专业代理：

日程代理：读取日历、检查冲突，整理创建或修改建议。

邮件代理：生成可直接复制的回复正文，但不直接发送。

任务代理：检查到期任务，并控制提醒频率。

照片台账代理：按顺序收集图片，把图片写入模板并返回文件。

文件代理：处理图纸、报销单、客户 CSV 和报价单。

销售代理：查询数据并生成结构化摘要。

每个代理都要定义“能做什么、必须遵守什么、绝对不能做什么”。例如，日程代理可以读取当前日历，但创建和修改日程必须进入审批队列；邮件代理可以生成正文，但不能伪装成已经发送。

主秘书负责入口和调度，专业代理只承担边界清晰的工作。

三、角色定义与业务手册要分开

角色注册表描述“这个员工是谁”；SKILL.md 描述“这个员工具体怎么工作”。两者分开后，新增员工就变成局部扩展，而不是修改巨型提示词。

SKILL.md 则承载判断流程、确认方式、输出格式和禁止事项。例如：

业务手册适合写流程和边界，外部 API、文件操作和状态保存交给代码。

四、让 AI 返回业务结果，而不是一段自然语言

如果 AI 只返回自然语言，Discord 很难可靠显示审批按钮、记录工作日志或保存经验。建议固定业务结果结构：

reply 是用户看到的内容。

approvalRequests 是需要用户确认的外部操作。

agentActivity 是内部工作日志。

learnedMemory 是写入对应员工记忆的候选规则。

outputFiles 是待发送到成果物频道的文件。

主提示词还应该明确禁止模型谎称完成外部操作：

结构化返回让 AI 从聊天回复者变成业务系统的一部分。

五、审批是进入真实业务的安全阀

邮件发送、日程创建、任务完成、外部发布、文件删除、客户导入和报价导入，都可能带来真实影响。它们不应该由模型直接执行，而要经过：AI 提议、用户确认、代码执行并记录结果。

审批请求先保存，再在 Discord 中显示按钮；用户确认后，才交给具体服务执行。这样能把“模型判断”和“系统副作用”隔开。

六、为什么 Discord 适合作为工作入口

Discord 同时提供消息入口、文件附件、频道分组、移动端通知、审批按钮、成果物发送和工作日志。用户可以直接说“查看今天的安排”，也可以用命令调用某个专业员工。

同一个入口可以承接普通请求、审批、附件、日志和成果物。

七、工作室、成果物和记忆要分开

建议按职责划分工作室频道：日程、任务、邮件、图纸、照片台账、报销、客户、报价、销售和成果物。

普通回复回到用户频道。

内部工作日志进入对应工作室。

审批请求留在原请求附近。

记忆也要按员工隔离。邮件代理学到的写作偏好，不应该影响照片台账；照片台账的收集顺序，也不应该污染日程代理。

定时任务也要控制频率：任务通知代理每轮只发送一条到期任务，巡检和重复通知由代码控制，AI 只负责自然语言解释。

日志、成果物和员工记忆都应该有明确归属，避免再次形成上下文混线。

八、把重复执行的处理交给服务层

AI 可以决定“现在应该问什么”和“下一步是什么”，但不适合直接承担 Excel、CSV、文件保存和异常处理。照片台账服务层负责复制模板、写入图片、保存文件和返回路径；AI 负责提示用户下一步上传什么。

同样的原则适用于日程读取：日期解析、排序和 API 访问由代码完成，AI 负责摘要。定型处理不必每次调用 LLM，这既更快，也更容易测试。

九、邮件代理与定型任务要有专门规则

邮件代理的目标是返回一封可以直接复制的邮件：reply 只放正文，不加入“以下是回复”等前置语，不混入解释或额外标题；实际发送必须进入审批流程。

对于“查看今天日程”“查看明天任务”这类固定请求，可以先由代码识别并直接调用 API，再让 AI 负责摘要。模糊需求整理、确认、总结和措辞适合交给 AI；时间计算、排序、API 访问和状态保存适合交给代码。

十、账户边界与成果物目录不能省略

个人 BOT 和业务 BOT 最好分开，工作日历和个人日历也不要共用令牌或状态文件：

成果物按类型和案件分目录：

账户、状态文件和成果物目录分开，才能避免“生成了但找不到”或“通知发错地方”。

十一、最小可用版本：先做三名员工

第一版只需要：

主秘书：接收请求、分派任务、合并结果。

日程代理：先只做读取和查询。

邮件代理：只生成正文，不发送邮件。

之后按风险从低到高扩展：先稳定日历读取，再加入审批后的写入操作，最后增加 Excel、CSV 和其他成果物生成。

新增员工的流程应当固定：加入注册表、编写 SKILL.md、补充服务层、增加审批动作、确定成果物目录，并建立独立记忆。

十二、最容易踩中的五个坑

把所有规则塞进一个巨大提示词，导致上下文混线。

让 AI 直接执行外部操作，没有审批和日志。

一次发送过多任务通知，让用户关闭入口。

只生成文件，不规定保存位置和版本关系。

SKILL.md 只写“认真、清晰、友好”，没有具体边界。

具体规则比抽象形容词更有效：一次只问一张照片、邮件只返回完成正文、日程写入必须审批、通知每轮只发一条。AI 依靠清晰边界和可检查条件保持稳定。

十三、推荐的实施顺序

建立 Discord BOT 和基础消息入口。

完成主秘书和角色注册表。

固定 JSON 返回结构并写解析器。

加入对话记忆和员工独立记忆。

实现日程读取代理。

实现邮件正文代理。

加入审批服务和 Discord 审批按钮。

分离工作室频道与成果物频道。

增加照片台账、图纸、CSV 等成果物代理。

最后加入定时通知和更复杂的自动化。

结语：AI 的下一步不是更万能，而是更像一个团队

这套设计的核心不是让模型拥有更多能力，而是让每种能力拥有清晰责任：主秘书负责入口和整合，专业代理负责具体工作，SKILL.md 负责业务手册，服务层负责可重复的实际处理，审批负责拦住外部影响，Discord 负责日常协作，员工记忆负责局部成长。

当 AI 不再是一个“什么都回答”的聊天窗口，而是一个会接收任务、选择负责人、在危险处停下、留下日志并交付成果物的团队，才真正开始进入日常业务。

最好的起点不是一次做完所有员工，而是先把骨架搭好，再根据真实工作中的小摩擦持续更新对应手册。