用 AI 智能体运营一家一人公司
过去六个月，我几乎完全依靠 AI 智能体，仅通过一个 git 仓库运营了一家一人公司。任务：过去六个月，我几乎完全依靠 AI 智能体，仅通过一个 git 仓库运营了一家一人公司。这不是“AI 帮我写邮件”，而是实际的业务运营：营销、销售、CRM、内容、外联，全部涵盖。我最初的目标不是构建框架，而是停止处理行政事务。但随着许多事情悄然运转，同样数量的事情也在我面前崩溃，一个粗略的框架便从中浮现出来。共 10 个部分。以下每个部分都包含哪些地方行得通，以及哪些地方出了问题，因为“哪里出了问题”才是我真正想读的部分。我发布它是为了让人挑毛病，如果你也在做同样的事情，请告诉我哪里错了。 1. 将整个公司放在 AI 能读取的地方（上下文即代码） 停止将 AI 接入十个 SaaS 标签页。它不擅长点击按钮，但擅长读写文件，所以将公司迁移到它已经运作良好的地方，即一个仓库中的纯文本文件。每个部门是一个文件夹。 行得通的地方：当 AI 能够以文本形式读写整个业务时，它从在十个浏览器标签页中毫无用处，变成了真正能运行事务。 出问题的地方：文件夹变得臃肿，回忆能力衰退（现在有个名字叫 context rot）。你需要按需加载上下文。不要将整个公司倒入窗口然后祈祷。 2. 路由大脑：一个根文件，部门作为带有剧本的文件夹每个文件夹包含一个纯英语剧本（一个 CLAUDE.md），说明你卖给谁、你的语气、规则以及它可以使用的工具。根文件路由工作：任务：“寻找潜在客户并给他们发邮件” | 根 CLAUDE.md（路由器） | 打开拥有该任务的剧本 v sales/CLAUDE.md + crm/CLAUDE.md（纯英语规则） | 智能体成为该部门负责人 | 执行工作 | 将结果写回仓库 | 下一个任务开始时拥有更多上下文，而不是零。 行得通的地方：对于大多数工作，一个通才智能体加上良好的剧本，胜过一群脆弱的专用机器人，且跨部门任务可以自行路由。 出问题的地方：单个通才智能体在真正复杂的并行多步骤工作中仍然会不堪重负。这是我唯一使用子智能体的地方，因为多智能体运行大约消耗 15 倍的 token，所以它必须值得。 3. 拥有触及核心工作流的工具，并将每个平台视为敌对我将内部付费的 SaaS 重建为小型应用，每个应用读取一个数据库和一个品牌套件。一个驱动真实浏览器会话的 LinkedIn 客户端。自己的 Instagram CLI。从终端访问 Google Workspace，以便智能体可以在工作流中预订会议或发送邮件。面向平台的那些工具以最艰难的方式教会了我最多。早期，一个智能体在社交平台上快速批量触发动作，结果账户被暂停。完全活该。因此，客户端现在在代码中有硬性每日上限（20 个连接，40 条私信，80 次个人资料查看），以人类节奏运行，并通过计算发送前后的消息元素数量来验证每次发送，因为撰写流程悄悄改变了两次，并且愉快地报告成功，但实际上什么都没发送。 行得通的地方：拥有工作流工具（每个会话，零集成税），租用基础设施（数据库、邮件、支付、托管、潜在客户数据）。上限在代码中，而不是在提示词中。永远不要相信平台自己的“成功”，在声称你做了任何事之前，检查 DOM 是否发生了变化。 出问题的地方：相信平台的话并快速行动。这两者都会让你被封锁或被欺骗。 4. 赋予它感官：夜间侦察兵，情报摘要器，入站监控器，信号采集这是人们跳过的部分，也是大部分魔法所在。公司通过几个常设流程感知世界：收件箱 ----\ CRM --------\ 排名 ----> SCOUT（夜间） --> 一份简报：什么在移动，什么需要你竞争对手-/ 信息流 ------/ HN / Instagram / X / 一个 FB 社区 --> 摘要器 --> 评分信号 + 想法 LinkedIn + FB 收件箱 --> 每小时监控器 --> 新回复？ --> 队列 + 手机提醒与；工具：custom-built or unnamed agent。人工角色：原始帖子描述人类角色如下：我在桌面或手机上进行审核。；局限：前提条件包括精通 Git、文件管理和自定义工具开发。约束：多智能体运行消耗约 15 倍 token；单智能体难以处理复杂的并行任务。风险：因自动化导致平台封禁；文件过大导致“上下文腐烂”。集成不确定性：平台 API/UI 会静默变更，需 DOM 验证。所有外发动作需人工批准。来源可靠性为次要（Reddit 帖子）。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
过去六个月，我几乎完全依靠 AI 智能体，仅通过一个 git 仓库运营了一家一人公司。
工作流程
过去六个月，我几乎完全依靠 AI 智能体，仅通过一个 git 仓库运营了一家一人公司。这不是“AI 帮我写邮件”，而是实际的业务运营：营销、销售、CRM、内容、外联，全部涵盖。我最初的目标不是构建框架，而是停止处理行政事务。但随着许多事情悄然运转，同样数量的事情也在我面前崩溃，一个粗略的框架便从中浮现出来。共 10 个部分。以下每个部分都包含哪些地方行得通，以及哪些地方出了问题，因为“哪里出了问题”才是我真正想读的部分。我发布它是为了让人挑毛病，如果你也在做同样的事情，请告诉我哪里错了。 1. 将整个公司放在 AI 能读取的地方（上下文即代码） 停止将 AI 接入十个 SaaS 标签页。它不擅长点击按钮，但擅长读写文件，所以将公司迁移到它已经运作良好的地方，即一个仓库中的纯文本文件。每个部门是一个文件夹。 行得通的地方：当 AI 能够以文本形式读写整个业务时，它从在十个浏览器标签页中毫无用处，变成了真正能运行事务。 出问题的地方：文件夹变得臃肿，回忆能力衰退（现在有个名字叫 context rot）。你需要按需加载上下文。不要将整个公司倒入窗口然后祈祷。 2. 路由大脑：一个根文件，部门作为带有剧本的文件夹每个文件夹包含一个纯英语剧本（一个 CLAUDE.md），说明你卖给谁、你的语气、规则以及它可以使用的工具。根文件路由工作：任务：“寻找潜在客户并给他们发邮件” | 根 CLAUDE.md（路由器） | 打开拥有该任务的剧本 v sales/CLAUDE.md + crm/CLAUDE.md（纯英语规则） | 智能体成为该部门负责人 | 执行工作 | 将结果写回仓库 | 下一个任务开始时拥有更多上下文，而不是零。 行得通的地方：对于大多数工作，一个通才智能体加上良好的剧本，胜过一群脆弱的专用机器人，且跨部门任务可以自行路由。 出问题的地方：单个通才智能体在真正复杂的并行多步骤工作中仍然会不堪重负。这是我唯一使用子智能体的地方，因为多智能体运行大约消耗 15 倍的 token，所以它必须值得。 3. 拥有触及核心工作流的工具，并将每个平台视为敌对我将内部付费的 SaaS 重建为小型应用，每个应用读取一个数据库和一个品牌套件。一个驱动真实浏览器会话的 LinkedIn 客户端。自己的 Instagram CLI。从终端访问 Google Workspace，以便智能体可以在工作流中预订会议或发送邮件。面向平台的那些工具以最艰难的方式教会了我最多。早期，一个智能体在社交平台上快速批量触发动作，结果账户被暂停。完全活该。因此，客户端现在在代码中有硬性每日上限（20 个连接，40 条私信，80 次个人资料查看），以人类节奏运行，并通过计算发送前后的消息元素数量来验证每次发送，因为撰写流程悄悄改变了两次，并且愉快地报告成功，但实际上什么都没发送。 行得通的地方：拥有工作流工具（每个会话，零集成税），租用基础设施（数据库、邮件、支付、托管、潜在客户数据）。上限在代码中，而不是在提示词中。永远不要相信平台自己的“成功”，在声称你做了任何事之前，检查 DOM 是否发生了变化。 出问题的地方：相信平台的话并快速行动。这两者都会让你被封锁或被欺骗。 4. 赋予它感官：夜间侦察兵，情报摘要器，入站监控器，信号采集这是人们跳过的部分，也是大部分魔法所在。公司通过几个常设流程感知世界：收件箱 ----\ CRM --------\ 排名 ----> SCOUT（夜间） --> 一份简报：什么在移动，什么需要你竞争对手-/ 信息流 ------/ HN / Instagram / X / 一个 FB 社区 --> 摘要器 --> 评分信号 + 想法 LinkedIn + FB 收件箱 --> 每小时监控器 --> 新回复？ --> 队列 + 手机提醒与
原文报告的结果
来源未报告任何可衡量的业务结果或指标。它描述了一种混合体验，部分操作成功，部分失败，从而形成了 10 部分框架。具体失败包括因快速自动化操作导致的账户暂停，以及因平台 UI 变更导致的静默发送失败。作者表示目标是停止处理行政事务，但未量化节省的时间或产生的收入。
人工角色
原始帖子描述人类角色如下：我在桌面或手机上进行审核。
局限
前提条件包括精通 Git、文件管理和自定义工具开发。约束：多智能体运行消耗约 15 倍 token；单智能体难以处理复杂的并行任务。风险：因自动化导致平台封禁；文件过大导致“上下文腐烂”。集成不确定性：平台 API/UI 会静默变更，需 DOM 验证。所有外发动作需人工批准。来源可靠性为次要（Reddit 帖子）。
试一试
我想在单一 Git 仓库中使用 AI 智能体设置一人公司自动化系统。 背景：[可替换输入：业务类型、目标受众、品牌语气]。 源文件：[可替换输入：现有 CRM 数据、邮件模板、社交媒体指南]。 目标用户：[可替换输入：客户细分]。 输出位置：[可替换输入：本地目录路径]。 步骤： 1. 创建根 CLAUDE.md 文件作为路由器，定义如何将任务分发到部门文件夹（销售、营销等）。 2. 创建部门文件夹及其各自的 CLAUDE.md 剧本，指定规则、工具和语气。 3. 实施“侦察兵”脚本，读取收件箱和信息流以生成每日简报。 4. 为 LinkedIn/Instagram/Email 构建自定义工具，设置硬性每日上限（如 20 个连接，40 条私信）和发送的 DOM 验证。 5. 试运行：处理一个样本潜在客户。在发送前向我展示起草的邮件和验证日志。 6. 等待我的明确确认后再执行任何实际发送或预订。 质量检查：确保按需加载上下文，而非全部倾倒。验证未超出平台限制。如果输入缺失，通过暂停并请求澄清来处理错误。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。