GPT88 / API Docs
ব্লগে ফিরে যান

Herdr 实战：从零搭建 AI 一人公司，真正要沉淀的是知识库

AI 工作流2026-10-1012 মিনিট পড়ুনHerdrAI 一人公司Claude CodeCodexAgent 工作流

本文依据翔宇工作流的视频及其配套文章整理。公开证据包括视频标题、频道 RSS 的发布时间、视频描述、章节和配套文章；本次没有取得可下载的公开字幕，因此本文是结构化总结，不是逐字稿。视频中出现的产品、命令、模型和界面会随版本变化，实际操作应以对应项目的当前文档为准。

视频提出的目标很具体：从一个空文件夹开始，搭出一家由 AI 员工协作的一人公司。老板只需要把目标交给总经理，总经理写任务卡并分发给内容、增长、视频等岗位；岗位缺人时，再临时请帮手查资料；结果回来后由人确认，才写回正式文件。

这套方法真正有价值的地方，不是把“公司”画成一张漂亮的 Agent 架构图，而是把长期会复用的工作方法放回自己的文件夹。模型和命令行工具可以更换，办公室可以升级，知识库、规则、工作记录和验收标准才是个人真正拥有的运营资产。

先理解三层结构

视频把一人公司拆成三个互相配合的部分：员工、办公室和知识库。它们的边界清楚，系统才不会变成一堆互相调用却没人知道状态的终端窗口。

员工：命令行工具加模型

一位“员工”不是单独的模型，也不是一个角色提示词，而是命令行 Agent 工具与背后模型的组合。命令行工具负责读文件、运行命令、修改代码、打开浏览器和保存产出；模型负责理解目标、规划步骤和生成判断。

这样的组合可以替换。今天使用 Claude Code，明天换成 Codex 或其他兼容工具，公司的岗位手册和知识库不应该因此重写。模型是租来的执行能力，工作方法应该留在自己的项目里。

办公室：把多个终端放到同一套运行表面

Herdr 在视频里扮演“办公室”：把多个命令行会话放进同一个工作区，让使用者能看到不同窗口的状态、输出和交接关系。后台服务、用户界面和员工识别是三个不同层次：界面关掉，不一定意味着后台任务也结束；页面之间的可见关系，也不等于任务已经完成。

这使多 Agent 协作多了一层可观察性。总经理可以知道内容经理是在工作、等待输入，还是已经交付；临时帮手完成后也应该留下文件或报告，而不是只在聊天窗口里说一句“完成了”。

知识库：公司的根目录

知识库是这套方法的核心。每个命令行 Agent 都从某个目录启动，那个目录就是它能看到的工作上下文。目录为空时，员工每次都会重新猜测公司是谁、做什么、对谁负责，以及哪些文件可以修改。

配套文章用几个简单问题组织知识库：

问题内容示例目录
我是谁主理人、品牌、偏好和价值观主理人/、品牌/
我做什么业务资料、成品和商业信息业务/、商业/
我怎么做工具说明、最佳实践、Skill 和研究资料工具/、研究/
谁来做固定岗位、岗位手册和工作记录角色/
守什么规矩全公司的协作规则和权限边界AGENTS.md
做到哪了任务卡、草稿和进度驾驶舱/任务/

目录名不是标准答案。它的作用是让新员工拿到任何文件时，都能凭直觉判断应该放在哪里、是否可以修改，以及下一步要向谁汇报。

一套可落地的目录

可以从下面的最小结构开始，不必一开始就建立完整的“数字公司”：

company/
├── AGENTS.md                 # 全公司规则、权限和验收标准
├── 主理人/                   # 背景、偏好、决策风格
├── 品牌/                     # 定位、受众、对外资料
├── 业务/                     # 产品资料、内容和交付物
├── 工具/
│   ├── 最佳实践/             # 工具使用方法和踩坑记录
│   ├── 技能/                 # 每个 Skill 只保留一份实体
│   └── 账号说明/             # 只放非敏感配置，不放密钥
├── 研究/                     # 已核验的资料和结论
├── 角色/
│   ├── gm/                   # 总经理手册与工作记录
│   ├── content/              # 内容经理手册与工作记录
│   └── growth/               # 增长经理手册与工作记录
├── 驾驶舱/
│   └── 任务/                 # 任务卡、草稿、状态
└── 收件箱/                   # 暂时没有归档位置的材料

目录的重点不在中文名称，而在每个目录都要有自己的说明文件：放什么、不放什么、如何命名、谁有权修改、完成后留下什么证据。根目录的 AGENTS.md 规定全局规则，子目录的说明文件再补充局部规则。

Skill 也应该只保留一份实体。不同命令行工具可能从不同路径读取 Skill，可以用软链接把同一个 Skill 挂到各自的发现目录。这样改一次就能保持版本一致，避免 Claude、Codex 或其他工具各自使用略有差异的副本。

五步搭建路径

视频配套文章把完整流程拆成五段提示词。把它抽象成工程步骤，大致如下。

第一步：先建知识库

先创建根目录、目录说明和最基本的公司资料。不要先请一堆员工，再让它们共同猜测文件该怎么放。知识库至少要包含：

  • 主理人的背景、偏好和决策风格；
  • 品牌定位、受众和对外表达；
  • 当前业务、产品和已有产出；
  • 工具、Skill、研究资料和工作记录的归档规则；
  • 允许直接修改的文件与必须先请示的正式文件。

第一版可以很小。能让员工正确找到一个业务文件、写出一张任务卡，就已经比空目录有价值。

第二步：写公司的总规矩

总规矩负责解决协作中的高频歧义，例如：先写计划再动手、先查看目标岗位是否空闲、正式文件修改前先请示、密码和权限弹窗交给老板、以产出文件而不是聊天消息作为验收依据。

这些规则不应该写成泛泛的“认真完成任务”，而应写成可观察的动作和停止条件。例如：

## 修改正式文件

1. 先把拟修改文件、原因和预计影响写进任务卡。
2. 只读检查相关目录，不自行扩大范围。
3. 等老板确认后再写入正式文件。
4. 提交路径、变更摘要和验证结果。

规则越接近具体动作，越容易被岗位手册引用，也越容易在回放任务时检查。

第三步：建立固定岗位

固定岗位是长期存在的上下文和职责边界。视频示例包含总经理、内容经理、增长经理和视频经理。岗位手册至少要写清：

  1. 负责什么结果；
  2. 可以读取和修改哪些目录；
  3. 接到任务后先检查什么；
  4. 需要向谁交接；
  5. 交付时要留下哪些文件和证据。

固定岗位不等于完全自主。它只是让每次任务不必从零解释职责。涉及正式资料、外部发布、账号权限或不可逆操作时，仍需要明确的人审节点。

第四步：按需请临时帮手

临时帮手适合处理范围清楚、生命周期短的工作，例如同时查几组资料、比较几个方案或对一篇草稿做独立审阅。它们应有明确的名字、输入、输出和关闭条件，完成后把结果写入任务卡或研究目录，再关闭会话。

临时帮手的价值有两个：不会长期占用固定岗位的上下文，也可以按任务选择更适合的工具或模型。但并行不等于可以同时修改同一份正式文件。并发任务应优先产出独立报告，最后由负责人合并并验收。

第五步：用一项真实任务验证

视频用“官网文章没有流量”作为示例：总经理拆任务，内容经理请临时帮手查资料，增长经理审阅，最后汇总给老板。这个例子说明了任务卡比一句“帮我优化 SEO”更重要。

一张可用的任务卡至少包含：

# 任务：检查文章流量问题

## 目标
找出影响文章被发现和被点击的主要问题，提出可验证的修改建议。

## 材料
- 目标文章路径
- 已有数据或截图
- 不可修改的文件

## 协作
- 总经理：拆解任务并汇总
- 内容经理：检查结构和搜索意图
- 增长经理：审阅建议和优先级

## 产出
- 研究报告
- 建议清单
- 待老板确认的改动

## 完成条件
- 每条建议都有依据
- 未经确认不修改正式文件
- 报告写回指定目录

任务卡让每个岗位知道自己为何被请来、应该交付什么，以及什么时候算完成。它也是人审和失败恢复的共同入口。

为什么知识库比“万能 Agent”更重要

1. 运营方法可以迁移

如果模型、命令行工具或供应商更换，知识库仍然保留公司的业务资料、写作风格、角色分工和质量标准。员工是可替换的执行层，文件夹里的运营体系才是长期资产。

2. 上下文可以复用

每次会话重新解释品牌定位、目录规则和发布流程，会消耗时间，也容易漏掉关键约束。把稳定事实和重复流程写进文件后，员工在新任务开始时先读规定的入口，就能减少重复提示词。

3. 协作可以留下证据

聊天消息很难成为长期的审计记录。任务卡、研究报告、工作记录和提交记录则可以被复查、比较和回滚。以文件为中心，才能知道某个结论从哪里来、谁审阅过、下一步是什么。

4. Skill 可以成为真正的模块

视频把 Skill 放在“工具”目录里，和最佳实践、研究资料分开。一个 Skill 不只是提示词，而是带有触发条件、输入、步骤、脚本、参考资料和验收标准的一套做事方法。把 Skill 作为单独资产维护，岗位可以复用同一套流程，也更容易在真实任务中逐步改进。

这套系统的边界

AI 一人公司仍然需要人负责方向、权限和最终判断。至少要守住下面几条边界：

  • 不把 API 密钥、Cookie、浏览器数据或个人文件放进普通知识库；
  • 工具说明可以写安装方式和非敏感配置，但凭证应由受控的运行环境管理；
  • 并行岗位只修改各自的临时产出，不直接争抢同一份正式文件；
  • 外部发布、付费操作、账号权限、生产数据和删除动作都设置人工确认；
  • 对外部资料保留来源、时间和核验状态，不因为一个 Agent 的总结就当成事实；
  • 后台会话是否仍在运行，要以运行状态和产出文件检查，不以界面是否打开判断。

把多个 Agent 放进一个办公室不会自动解决权限、错误传播、上下文污染或成本控制问题。可观察性只是基础设施，真正的可靠性来自目录边界、版本控制、验收标准和停止条件。

一份最小验收清单

完成第一版后，可以用下面的问题判断系统是否能工作：

  1. 新员工能否在不看聊天历史的情况下找到公司规则和任务入口？
  2. 每个固定岗位是否都有清晰的输入、输出和权限范围？
  3. 临时帮手结束后，结果是否写进了指定文件，而不是只留在会话里？
  4. 任务卡是否包含完成条件、失败处理和人工确认点？
  5. Skill 是否只保留一个实体，多个工具读取的是同一版本？
  6. 正式文件、凭证和外部发布是否有独立的审批边界？
  7. 运行几次真实任务后，能否从工作记录中找出返工和漏检的原因？
  8. 更换模型或命令行工具后，公司的核心流程是否仍然可用？

如果这些问题还答不上来，继续增加岗位数量通常只会扩大混乱。先让一个岗位、一项 Skill 和一张任务卡稳定运行，再逐步扩展。

结语：把公司留在文件夹里

“AI 一人公司”最容易被误解成让一群 Agent 代替老板做所有事情。视频更值得借鉴的部分，是把它看成一套可复用的工作系统：员工负责执行，Herdr 提供可观察的运行表面，知识库保存公司的长期记忆，任务卡负责交接，老板负责方向、权限和最终验收。

真正属于个人的不是某个模型，也不是某个界面，而是那些经过真实任务验证的目录结构、岗位手册、Skill、工作记录和质量标准。先从一个每周重复且结果可检查的流程开始，把它写进文件夹，再让 Agent 按这套规则工作，才是更稳的起点。

来源与核验