这不是一本”如何用 ChatGPT”的书

先把话说清楚：如果你想学怎么写 prompt、怎么让 AI 帮你起草邮件、怎么用 Copilot 补全代码——这本书不适合你。这本书不打算重复它们。

这本书讲的是另一件事：一个人如何用 AI agent 构建一支工程团队，然后用这支团队交付真实产品。

不是概念验证，不是 demo。是有 deadline 会砸、有用户会投诉、有 production bug 会半夜把你叫醒的真实工程项目。

如果你是一个有工程判断力、想探索个人杠杆极限的开发者——这本书是写给你的。

一个数据点

去年，我带了一个 7 人团队，花 8 周从零做了 Societas¹——一个 AI agent 协作平台。需求定义、架构设计、迭代测试、全球发布，一整条链路走下来，最终拿到 Satya 的 greenlight，作为微软官方产品面向全球上线。

接下来的几个月里，industry 持续飞速进展——模型能力在跳台阶，agent 框架层出不穷，一个人能做的事情的上限肉眼可见地在被重写。我一直在想一个问题：如果不是 7 个人，而是 1 个人加一支 AI agent 团队，能做到什么量级的事？

于是，2026 年 3 月，我一个人启动了 memex 和 OPC。7 天，消耗 9B token。下面是我阶段性的答案和思考。

这本书的边界

几件你应该知道的事情：

这是 N=1 的 field report，不是经过同行复制的方法论。 全书的核心经验来自一个人的有限几个项目。我没有对照组，没有其他人用同样方法复现了同样结果的证据。我尽力区分了”这是我观察到的”和”这是普遍规律”，但一个人的经验必然有盲区。

适用条件比我暗示的更窄。 OPC 模式对工程师的要求很高：你需要有架构级别的判断力、需要大块连续时间、需要做的是可以独立推进的软件项目。如果你的工作涉及跨团队协调、需要领域专家的密集参与、或者不是软件工程——这套方法需要大幅改造才可能适用，甚至可能不适用。

时效性警告。 本书写于 2026 年 3-4 月。关于 LLM 能力边界、token 定价、autonomous operation 时间尺度的所有具体判断，都是 time-bounded 的。如果你在 2027 年读到这本书，请把具体数据点当作历史快照，把思维框架当作可能仍然有效的结构。

“约束越好，自由越大”是一个有用的启发式，不是科学定律。 它在我的经验中反复成立，但我无法给出它不成立的边界条件。把它当作一个值得检验的假设，不是一个可以无条件信赖的公理。

一个 OPC 的工程日常

OPC——One Person Company。这个词在独立开发者圈子里不新鲜，但我赋予它的含义跟大多数人不一样。

传统 OPC 是”一个人做所有事”。本质上是一个全栈个体户。

我说的 OPC 是另一回事。一个人 + 一支硅基团队 (Silicon Team)。 你是 engineering manager，你手下有一支由 AI agent 组成的团队。你不写代码——你设计系统，让 agent 写代码。你不做 code review——你设计 review pipeline，让 agent 互相 review。

听起来很美好？实际操作中，90% 的时间你在做一件事：修理这支团队。

Agent 会犯错。不是偶尔犯错，是系统性地犯错。它会在格式上出问题（YAML frontmatter 少个字段）、在 routing 上走偏（走错 orchestrator 导致消息格式不兼容）、在 review 中放水（coordinator 信任 subagent 的报告而不自己验证）。

你的工作不是替它们修 bug。你的工作是设计约束系统——harness——让这类 bug 不可能发生。 Harness 就像给赛马的缰绳：不是为了限制它跑，而是让它跑在赛道上。从信任 AI 到约束 AI——这是 OPC 的核心心态转变，也是本书的核心论点：Harness-Native Engineering。

四条因果链

7 天之后回头看，核心 learning 就四条，而且它们是因果链——

掌握 harness engineering → 敢放手给 autonomous operation → 能 empower 一支多 agent 团队 → 时间尺度从 minutes 跃迁到 hours。

一句话说：约束越好，自由越大。 设计好闭环、给好约束、做好角色隔离，按下启动键，去睡觉。醒来检查结果。人的角色从操作者变成委派者，再变成系统设计者。

227 张卡片

这本书的素材来源很特殊——227 张 Zettelkasten 风格的知识卡片，积累于 2024 年 9 月到 2026 年 4 月之间，其中大部分来自 2026 年 3-4 月的密集开发期。

这些卡片来自多个渠道——开发过程中的 retro、Claude Code session 的 recap、以及 flomo 上积累的行业观察和阅读笔记。

这些卡片不是我计划要写的。它们是被逼出来的。

当你同时跑 4 个 agent session，每个 session 的上下文是隔离的，你在 session A 里踩过的坑，session B 完全不知道。你在凌晨三点发现某个 MCP tool 的 description 必须自闭环，第二天下午另一个 session 又在同一个地方栽了——同样的错误出现第二次，不可接受。 这种事只要发生一次，你就会建立 memory 系统。

所以我建了 memex。不是什么高级的 knowledge base 产品，就是 plain text + Markdown + git 同步的 CLI 工具。227 张卡片涵盖 agent 架构、测试策略、prompt 工程、DevOps 到前端踩坑的全链条。每一张都经过了用自己语言重新表述的过程——不是 copy-paste，是消化后的重写。有些来自具体的 bug 和失败，有些来自阅读和讨论后的提炼，但没有一张是原封不动搬来的。

这 227 张卡片就是这本书的全部素材来源。

书的结构

本书 7 章，三层递进：

基础层——第一章（协议层）讲 CLI 作为 protocol layer 如何解耦 memory 和 agent，以及三层分发模型的设计。这是地基。

方法层——第二章（Harness-Native Engineering）讲约束系统设计，mechanical gate（基于确定性规则而非 LLM 判断的质量关卡）如何替代概率性判断。第三章（多硅基协作）讲 agent routing、Spawn vs Delegate、多 agent 编排。第四章（自主运行）讲 OPC pipeline、iterative review、autonomous loop。

应用层——第五章（Agent 时代的商业逻辑）从工程视角转向商业视角，讲定位、叙事、投资论点。第六章（工程手札）是 17 个用血换来的具体教训。第七章（从记忆到书）是 meta-narrative——227 张卡片如何变成你手上这本书。

每一章都遵循同一个模式：原则 → 实现 → 教训 → 案例。

这本书本身就是证据

最后说一件事：这本书本身就是 AI + 人类协作的产物。

4 个 AI agent 并行写初稿，3 个不同角色（编辑、技术审稿人、读者）做独立 review，我负责架构决策、素材选择和最终判断。写作过程使用了与书中描述的完全相同的方法论——harness 约束初稿质量，multi-agent review 交叉验证，人类把关方向和深度。

如果这本书的方法论是对的，那它自己的生产过程应该能证明这一点。如果这本书写得烂，那说明方法论还不够好——至少在写作领域不够好。

这是我能给出的最诚实的 accountability。

读完这本书，你会拥有： 一套经过 227 张卡片验证的 harness 设计框架，一个可复制的多 agent 协作方法论，以及一种新的思维方式——不再问”AI 能做什么”，而是问”怎么构造结构让 AI 不可能做错”。

一个人，一支硅基团队，从这里开始。