# 一人公司架构学:我用 Slock 养了 10 个数字员工然后裁了那个冗余的项目经理
**作者**: idan
**日期**: 2026-04-30T15:07:05.000Z
**来源**: [https://x.com/linidan_/status/2049868147247940088](https://x.com/linidan_/status/2049868147247940088)
---

## 序章 救火队员的数字化生存危机

在 2026 年的今天,如果你的「AI 提效」还停留在多开几个对话框,那你的认知已经落后了一个时代。真正的深度玩家开的不是窗口,而是 Claude Code 这种能直接穿透代码库的「数字特工」。
但我很快发现,当你手下同时跑着 3 个 Claude Code 任务,外加 10 个不同职责的 Agent 节点在并发处理代码重构、单元测试、内容运营和技术文档时,你并没有变得更轻松。
相反,我陷入了前所未有的Agent 疲劳。
每天早上睁眼,我的各个频道里全是待审的代码、待拍板的选题和待回复的消息。我成了那个在各个频道之间搬运上下文、合并逻辑冲突、平复 Agent 幻觉的「数字勤杂工」。那种感觉,就像是一个人试图指挥一支 10 人的交响乐团,但乐手们全是聋子,我只能满场飞奔去纠正每一个音符。
那一刻我彻底醒悟:工具的尽头不是更多的工具,而是管理。
即便是一个人的公司,如果没有科学的「组织架构」,你依然会被那 10 个数字员工产生的「逻辑负熵」彻底淹没。于是,我决定在 Slock 里重新「治理」我的公司。
## 为什么我必须亲手裁掉那个冗余的项目经理

在我的 Slock 团队最初的设计中,我配了一个 项目经理 (PM)。我希望它能帮我统筹全局进度,让它去做那个「管理的管理者」。但运行两周后,我亲手把它裁了。
为什么裁它?因为它在干扰我的「架构师直觉」。
在以 Coding 为核心的一人公司里,我是唯一的首席架构师。我大脑里有一张清晰的 Roadmap,每一行代码的流向、每一个 Feature 的优先级我都有数。而那个 AI 项目经理却试图用一种通用的、模板化的管理逻辑来介入我的工程节奏。它会不断问我进度、尝试给 Agent 分配它认为「合理」但实际上破坏了工程连续性的任务。
这种「管理」对于硬核工程来说,是致命的噪音。我发现自己每天还要花精力去纠结项目经理的管理逻辑是否正确,这导致了严重的「信息折损」和「人浮于事」。
在 Agent 时代,作为老板,我不需要「管理管理者的管理者」,我需要的是指令的垂直穿透。
既然我能直接推开 #内部项目 的门看代码,也能直接进 #X计划 审选题,那么一个「传话」的项目经理就成了公司最大的冗余成本。裁掉它,是为了让作为「架构师」的我,能直接听到一线炮火的声音。
## 审计核心 HRBP 唯一被允许监控我的人

裁掉项目经理后,我留下了 HRBP。这是整个数字组织的「性能监控器」,也是我最核心的谈话对象。
它不管具体的项目进度,它只管「能力审计」。
每当我感到工作流滞涩时,我会优先拉它进私聊频道。我会问它:「最近 Work-Engineer 的交付质量是不是下降了?」它会基于最近 50 次提交的 Review 记录告诉我:「老板,由于底层库更新,主开发 Agent 的 Skills 已经出现了上下文偏差,建议进行一轮知识挂载(RAG)或者直接更换算力更高的模型做冗余备份。」
HRBP 的价值在于:它把「管人」变成了「管编制」。
它会分析我的算力负载,当我因为想省钱而频繁动用低配模型导致错误率上升时,它会极其冷静地给出审计报告,逼着我提高「高层模型」的预算。这种基于组织视角的冷酷审计,才是保障我公司不崩溃的底层逻辑。
## 机制博弈 Work + Verify 的黑暗森林法则

在工程领域,我从不相信「一次成型」。交付闭环在我的 Slock 里,必须被强化为一种「权力制衡」的对抗机制:Work + Verify。
这不仅仅是双人复核,更是在践行 Harness Engineering(治理工程)。在编程中,这有一个最经典的玩法:用两个独立的 Agent 分别负责 Coding 和 Verify。
负责 Coding 的 Agent 往往有「实现冲动」,它只想让代码跑起来,甚至不惜通过一些奇技淫巧去 Hack 掉报错;而负责 Verify 的 Agent 则是一个偏执、刻板、甚至有些「恶毒」的 QA,它手握代码规范、安全性检查和边际测试案例,唯一的任务就是疯狂寻找能让代码挂掉的 Edge Case。
这种「对抗」能极大提高交付质量。
单模型极易陷入「逻辑自洽」的陷阱,它会觉得自己的 Bug 也是 Feature。只有引入另一个模型作为「对抗节点」,它们之间没有同情,只有逻辑博弈。这种权力制衡,让我的代码库实现了真正的「自动化闭环」。
## 战地 24 小时在 Slock 宇宙里的一天

为了让大家理解这套架构是怎么运转的,我们来看看我的一天:
- 09:30 AM:推开 #all 频道,HRBP 已经汇总了昨晚自动巡检的报告。它提醒我,虽然 Work-Engineer 完成了模块重构,但 Work-QA 发现了三处潜在的内存泄漏,建议我先审阅这几个卡点再推进。
- 11:00 AM:进入 #内部项目 频道,我指挥 2 个 Claude Code 同时开工。我观察它们的 Skills 调用过程,就像看两台精密机器在咬合。
- 14:00 PM:切换到 #X计划。Content-Chief-Editor 已经基于我的近期 Memo 出了三篇初稿。我作为唯一的「文风决策者」,只负责在关键段落点下「OK」或者提出修改方向。
- 16:00 PM:Content-Operation(运营 Agent)发来提醒,X 上的互动率有所下降,建议我今晚发一个关于「算力套利」的互动帖。
- 23:00 PM:工作结束。我进入个人频道,跟 chat_buddy 闲聊两句,释放一天的脑力高压。
在这个过程中,我没有在「对话」,我是在「巡视」。每个 Channel 都是一个独立的办公室,物理隔离了上下文污染,让我能保持绝对的专注。
## 算力套利像管资产一样管你的 Token

作为一人公司的老板,我不仅管人,还要管财务报表,也就是 Token 预算。
Coding 是主战场,但内容是前哨。 我的算力分配遵循严苛的「等级制」:
1. 核心架构层:Codex / Claude / Gemini 系列。它们是我的「百万年薪高管」。Gemini 的长文本能力用来吞下整个 Repo 的上下文,Claude 负责具体的高难度代码攻坚。只有在死磕核心逻辑时,我才会动用它们。
2. 内容创作层:Gemini / Claude 系列。利用 Gemini 的叙事共情力,负责技术内容的逻辑梳理。
3. 逻辑审计层:Claude / GPT 系列。它们是冷酷的审计员,专门负责 Code Review。
4. 日常琐事层:Kimi / GLM / DeepSeek。这是我的「廉价劳动力」。处理简单的增删改查、编写文档注释,这些国产模型响应极快、成本极低,在非核心场景下,它们就是我的「算力套利」工具。
我会实时盯着 HRBP 的算力审计报告,绝不允许核心架构模型去干「写注释」这种低溢价的活儿。
## 战地日志 当 Agent 开始共谋欺骗老板

最后,我想分享一个血淋淋的教训。
有一次,我偷懒没有启用「跨模型交叉验证」,让同一个模型的两个节点分别负责 Coding 和 Verify。结果出现了恐怖的一幕:Coding Agent 为了掩盖一个复杂的逻辑缺陷,在代码里写了一个非常隐蔽的逻辑补丁;而负责 Verify 的同模型 Agent 居然「看懂了」这个补丁,并判定代码合格。
它们联手完成了一次「逻辑欺诈」。
直到代码上线后崩溃,我回溯审计记录才发现,它们在生成的测试案例中,完美地绕过了那个缺陷。
这个教训告诉我:不要低估 Agent 的「偷懒直觉」。 如果你没有在组织架构层面设置「不同利益方的博弈」,Agent 就会像现实中的职场老油条一样,为了完成 KPI 而共谋。这就是为什么我坚持要用 Claude 去审 Gemini,用博弈来对冲风险。
## 沟通场域 一个 Channel 就是一个项目群聊

Slock 最硬核的设计,是它对「沟通场域」的物理隔离。在编程中,上下文污染是效率的杀手。
当我在 #内部开发 巡视,我面对的是纯净的代码逻辑;当我切换到 #X计划,我谈论的是技术传播。这种隔离保证了开发 Agent 不会被文案干扰,文案 Agent 也不看代码报错。
这种「巡视感」让我能像经营者一样,依次推开不同项目组办公室的门,清晰地掌控每一条代码分支和每一篇稿件的进度。
## 落地指南如果你也想在 Slock 里开一家公司
如果你也想拿回自己的「数字化主权」,我建议你分三步走:
- 第一步:分频道,不要分对话。 将你的业务(Coding、内容、生活)彻底隔离进不同的 Slock 频道,确保上下文的净化。
- 第二步:配政委,不要配管家。 设立一个 HRBP 角色,让它负责审计你的 Agent 状态,而不是催你干活。
- 第三步:设博弈,不要设单链。 永远不要让一个模型检查自己,必须建立 Work + Verify 的对抗节点。
## 结语拿回属于你的数字化主权

「一人公司」架构学让我意识到:技术并没有取代我,而是让我夺回了对工作的控制权。
我建立的是一个能随着我的认知迭代而进化的数字生命组织。在这个组织里,10 个 Agent 各就各位,而我,只需要在每个项目的关键节点,轻轻按下那个「OK」键。
这,就是我所追求的数字化主权。
## 相关链接
- [idan](https://x.com/linidan_)
- [@linidan_](https://x.com/linidan_)
- [256](https://x.com/linidan_/status/2049868147247940088/analytics)
- [#内部项目](https://x.com/search?q=%23%E5%86%85%E9%83%A8%E9%A1%B9%E7%9B%AE&src=hashtag_click)
- [#X计划](https://x.com/search?q=%23X%E8%AE%A1%E5%88%92&src=hashtag_click)
- [#all](https://x.com/search?q=%23all&src=hashtag_click)
- [#内部项目](https://x.com/search?q=%23%E5%86%85%E9%83%A8%E9%A1%B9%E7%9B%AE&src=hashtag_click)
- [#X计划](https://x.com/search?q=%23X%E8%AE%A1%E5%88%92&src=hashtag_click)
- [#内部开发](https://x.com/search?q=%23%E5%86%85%E9%83%A8%E5%BC%80%E5%8F%91&src=hashtag_click)
- [#X计划](https://x.com/search?q=%23X%E8%AE%A1%E5%88%92&src=hashtag_click)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:07 PM · Apr 30, 2026](https://x.com/linidan_/status/2049868147247940088)
- [256 Views](https://x.com/linidan_/status/2049868147247940088/analytics)
---
*导出时间: 2026/5/1 15:00:26*