第 30 章 一人公司系统性框架
前五章(第 24-29 章)给了你零件:Agent 骨架、安全审查、内容工作流、接单脚手架。本章是把零件装成整机的图纸——一个人怎么用 Claude Code 把个人能力放大为可复用的产品、工程、运营系统,并且不把自己累死。
30.1 结论:一人公司 = 编排者 × 可复用系统
一句话结论:一人公司不是"一个人干所有人的活",而是"一个人编排 AI 能力,把个人判断沉淀为可复用系统"。成败不取决于你多能干,而取决于两个乘数:
杠杆率 = 你能编排的 AI 能力数量 × 每个能力被复用的次数- 第一项靠 Claude Code:它能写代码、跑测试、做调研、审安全、产内容——你每多编排一类,杠杆多一档。
- 第二项靠系统化:把一次性动作沉淀成 CLAUDE.md / MEMORY / Skill / Workflow,让下次零成本复用。
核心思维转变是从执行者到编排者。执行者问"这活怎么干",编排者问"这活该交给哪个能力、怎么沉淀成下次能复用的资产"。第 06 章那句"你做架构决策和关键审查,Claude 做实现和探索",在一人公司语境下升级为:你做产品决策与商业判断,CC 做实现、探索与复用沉淀。
能力分工的边界要划清,否则你会把不该外包的东西也外包:
| 人负责 | CC 负责 |
|---|---|
| 需求洞察、产品决策、用户反馈 | 代码生成、测试、文档 |
| 商业模式、定价、渠道 | API 集成、数据处理 |
| 审美判断、战略方向 | 代码审查、安全扫描 |
| 红线决策(见 30.7) | 自动化一切重复 |
这张表不是分工建议,是分工红线。左边那列一旦外包给 CC,你就从一人公司退化成了"AI 的产品经理"——而 AI 没有商业判断力,它会把没人要的功能做得很精致。
30.2 能力矩阵:四象限与 CC 的角色
一人公司要同时跑四件事:产品、工程、运营、内容。四象限缺任何一项都会跛脚——有产品没运营卖不出去,有运营没产品留不住人。CC 在每象限的角色不同,用错模式就低效。
人负责判断 ←────────────→ CC 负责执行
┌──────────────────────┬──────────────────────┐
│ 产品(调研/定义) │ 工程(开发/审查) │
│ CC = 调研放大器 │ CC = 全栈执行者 │
├──────────────────────┼──────────────────────┤
│ 内容(写作/发布) │ 运营(部署/维护) │
│ CC = 生产流水线 │ CC = 自动化运维 │
└──────────────────────┴──────────────────────┘产品象限:调研与定义
CC 在这里的角色是调研放大器——把一个人的调研带宽放大十倍。具体打法:
/deep-research(Bundled Workflow)扇出多路搜索 + 对抗验证 + 引用报告,做市场调研、竞品分析、技术选型。比一个人 Google 三天深得多。- Plan Mode(第 07 章)做产品定义:只读分析需求,产出方案待批,不直接动手写代码。
- 并行 Subagents(第 19 章)同时调研多个方向:一个查竞品定价、一个查技术可行性、一个查用户痛点,主上下文只收结论。
关键约束:调研结论必须人审。CC 会把"看起来合理"当事实,商业决策不能只听它——它能给证据,取舍还是你做。
工程象限:开发与审查
这是 CC 最成熟的象限,也是本书第二、三部分主体。一人公司场景下,工程杠杆点在:
- 全栈开发:第 10 章的模式,一个会话内完成前后端 + 数据库。
- 代码审查:
/code-review(Bundled Skill)审查 diff,/security-review(Bundled Skill)扫安全。一人公司没有同事 review,这两个 skill 就是你的"第二个人"。 - 重构与修 Bug:第 09 章的可执行闭环——限定范围 → 改 → 跑验证 → 读失败 → 自我修正。
弱代码起点的人(比如通信工程背景、没系统学过软件工程),工程象限的策略不是"补成全栈工程师",而是用 CC 补工程能力,自己只做架构决策。第 06 章四个支点(CLAUDE.md 提供上下文、权限规则、验证命令、Git 审查)就是给弱代码起点的人设计的——你不需要会写每一行代码,但必须会看 diff、会定验收标准、会跑验证。
运营象限:部署与维护
一人公司最容易死在运营——产品上线,半夜服务挂了,一个人爬起来救。CC 在运营的角色是自动化运维:
- 部署:Docker + CI/CD,部署脚本本身可以让 CC 写,但生产环境的 push 必须人按(红线边界,见 30.7)。
- 监控:
/loop(Bundled Skill)定时轮询健康端点,异常时通知。 - 备份与迁移:第 31 章的主题。环境可重建是底线——一次硬盘故障或换 Mac 不能让公司停摆。
- 成本控制:第 32 章的主题。token 是运营成本的大头,多模型策略 + 缓存 + 预算管理是控本三件套。
内容象限:写作与发布
内容是一人公司的获客杠杆——你没有销售团队,内容就是销售。第 28 章已经给了内容生产工作流的完整打法,这里只强调与系统性框架的关联:
- CC 把内容生产从"一周一篇"变成"一天一篇":调研 → 大纲 → 初稿 → 审校 → 发布,每步都能自动化。
- 但选题与观点必须人定。CC 能把文章写流畅,但写不出只有你能给出的洞察。把 CC 当打字机,不当思想源。
- 发布环节可以接 hooks 自动化:文章写完 → 生成 frontmatter → 推送到静态站 → 触发索引。见第 14 章 Hooks 系统。
30.3 实战路径:接单 → 工作流 → Agent 产品的递进
四象限是空间维度,实战路径是时间维度。一个人怎么从零走到 Agent 产品?分三阶段,每阶段一次跃迁,复用次数 ×10。
阶段 1: 接单(第 29 章) 卖时间,1 次 / 客户
↓ 把重复接单沉淀为工作流
阶段 2: 工作流产品化(第 28 章) 卖结果,N 次 / 工作流
↓ 把工作流封装为可复制产品
阶段 3: Agent 产品(第 24 章) 卖产品,N × 客户阶段 1:接单——卖时间换现金流,验证工程能力
第 29 章的接单脚手架(web-studio/)是这阶段的落地。核心目的不是赚大钱,是三件事:
- 现金流:先活下来,才有资格谈产品化。
- 工程能力验证:用 CC 能不能独立交付一个客户网站?能,则你的编排能力过关;不能,则回去补第 06-13 章。
- 需求收集:接单是最好的用户调研。客户反复要的功能,就是产品的方向。
这阶段的陷阱是永远停在接单——接单卖时间,时间有上限。一旦流程跑顺,立刻进阶段 2。
阶段 2:工作流产品化——把重复沉淀为可复用资产
当你发现接单时有 60% 的工作是重复的(搭脚手架、做 SEO、写文案、生成表单),就该把这部分沉淀成工作流。第 28 章的内容生产工作流、第 16 章的 Skills 自定义命令,都是这阶段的工具。
跃迁的关键指标:单位时间产出从"1 次"变成"N 次"。一个内容工作流跑一次产出一篇文章,跑 N 次产出 N 篇,你的边际成本趋近于零。
陷阱是工作流不通用:每个客户还要手动改参数,等于把"写代码"换成"改配置"。真正产品化是参数化到客户自助跑——已半只脚迈进阶段 3。
阶段 3:Agent 产品——可复制销售
把工作流封装成产品,让用户自己跑,你只收钱和反馈。第 24 章的 Agent 产品骨架就是这阶段的起点——三模块(工具系统 / 安全红线 / 规划循环)是任何 Agent 产品的最小骨架。
跃迁的关键指标:复用次数从"N 次(你跑)"变成"N × 客户(用户跑)"。你的边际成本从"趋近于零"变成"就是零"——这是 SaaS 模式的本质。
准备进阶段 3 的三个信号:
- 工作流跑顺,参数化高,客户能自助。
- 从接单收集到足够多"用户反复要"的需求。
- 读过第 24 章骨架,能搭起 MVP 最小闭环(步骤 1-4)。
信号没全亮就硬上,大概率做出没人要的东西(见 30.7)。
30.4 产品方向:应用层 Agent 赛道
选什么赛道做产品,是一人公司最大的战略决策。结论:应用层 Agent 赛道,是弱代码起点 + CC 加持下的最优解。
为什么是应用层
底层模型层 ── OpenAI / Anthropic / Google ← 一人公司进不去(算力+数据壁垒)
框架层 ── LangChain / SDK / 各家 Agent 框架 ← 开源已占满,差异化难
应用层 ── 解决具体狭窄痛点的 Agent 产品 ← 窗口期 + 弱代码可入底层和框架层已经被大厂和开源社区占满,一人公司进去就是炮灰。应用层的窗口期在于:大厂做通用,你做具体。大厂不会为"高校选课系统排课优化"这种狭窄场景单独做产品,但这类场景真实存在、有人付费、CC 能帮你实现。
应用层的另一个优势是弱代码起点可入。你不需要从零训模型、不需要懂 Transformer 内部,只需要会用 CC 编排现成的 API + 工具。第 24 章骨架的存在,让"应用层第一版怎么搭"有了现成答案。
四个高杠杆方向
| 方向 | 卖什么 | 杠杆点 | 一人公司适配度 |
|---|---|---|---|
| SaaS 微产品 | 解决狭窄痛点的订阅服务 | 狭窄 = 大厂不看,真实 = 有人付费 | 高 |
| API 服务 | 卖能力(封装好的 Agent 接口) | 一次开发,多端调用 | 中(需运维) |
| 内容产品 | 知识变现(课程/模板/报告) | 一次生产,无限复制 | 高 |
| 自动化代理 | 替用户跑重复流程的 Agent | 卖结果不卖时间 | 中(需场景验证) |
四方向可组合(如"内容产品 + 自动化代理"= 内容生产 Agent 卖给创作者),但一次只做一个方向,全做等于全不做(见 30.7)。
与第 24 章骨架的呼应
第 24 章的 Agent 产品骨架,是应用层赛道的产品化起点。它的价值在于把"做 Agent 产品"从"发明新架构"降级为"拼三个已验证模块":
- 工具系统(模块 A)← 第 15 章 MCP / 第 16 章 Skills 的自建版
- 安全红线(模块 B)← 第 05 章权限模型的产品化复刻
- 规划循环(模块 C)← 第 07 章 Plan Mode 的可实现抽象
骨架的 MVP 最小闭环(步骤 1-4:定装载策略 → 实现 5 工具 → 粘安全段 → 实现沙箱)是一人公司做应用层产品的第一版标准答案。别重新发明轮子——先把骨架跑起来,再根据真实失败模式迭代。
30.5 Claude Code 使用模式:三种模式
一人公司用 CC,会自然演化出三种使用模式。区分模式的意义在于:不同模式用不同的会话设计、不同的工具组合、不同的成本结构。混着用就低效。
模式一:产品构建(对话式开发 → 并行 Agent → 迭代优化)
这是工程象限的主模式。流程:
1. 对话式开发:Plan Mode 定方案 → acceptEdits 执行 → /verify 验证
2. 复杂任务:Subagents 并行(第 19 章)+ worktree 隔离
3. 迭代优化:/code-review → /security-review → /simplify → git diff 审查关键纪律:每步都带验证命令。第 06 章的可执行闭环不是建议,是这模式的生存法则——没有验证命令,CC 会停在"我已经修改好了",你接不下去了。
成本控制:这模式 token 消耗大,用 Opus 做架构决策与困难 bug、Sonnet 做常规实现、Haiku 做批量简单任务(见第 32 章)。
模式二:产品调研(深度研究 + 并行验证)
这是产品象限的主模式。流程:
1. /deep-research 扇出搜索 + 对抗验证 + 引用报告
2. 并行 Subagents 分头调研(竞品 / 技术 / 用户)
3. 主上下文汇总 → Plan Mode 产出产品定义关键纪律:事实必须核实。CC 会把"看起来合理"当事实,调研结论里的数字、CVE、产品特性都要回原始来源核对。第 06 章命令真实性表(区分内置 / bundled / 自定义)在这里尤其重要——别把某个自定义 skill 的输出当官方事实。
工具陷阱:WebSearch 与 web-search-prime MCP 共用配额池,一旦 429 两者同时失效。调研密集期要有备选方案(webReader 或本地缓存)。
模式三:自动化工作流(hooks + loop + Subagents + Workflows)
这是运营与内容象限的主模式。把重复动作变成无人值守的流水线:
hooks(事件触发)── /loop(定时)── Workflows(JS 脚本编排)
└─ Subagents(并行执行)- hooks(第 14 章):文件保存时自动跑 lint、commit 前自动跑测试——事件驱动,零人工。
/loop(Bundled Skill):定时轮询,适合监控、定时发布、定期备份。- Workflows(第 20 章):JS 脚本编排 pipeline/parallel,适合确定性大批量任务(如批量生成内容、批量审查代码)。
- Subagents(第 19 章):并行委派,适合可拆分的探索任务。
关键纪律:工作流必须先跑通一次再自动化。别一上来就写 hooks,先把流程手动跑顺,确认每步的输入输出,再沉淀成自动化。否则你自动化的是一个有 bug 的流程,出错时连根因都找不到。
30.6 运营系统:三根支柱
四象限是业务,运营系统是让业务能持续跑的地基。三根支柱缺一不可。
支柱一:备份与迁移(第 31 章)
环境可重建是底线。一人公司没有 IT 部门帮你恢复,一次硬盘故障、一次误删、一次换 Mac,如果环境不能快速重建,公司直接停摆。第 31 章给全量方案:
- 代码与配置:Git + 远程仓库。
- Claude 环境:
.claude.json(只合并 mcpServers)、CLAUDE.md、MEMORY、Skills、自定义命令——全部纳入备份。 - 凭据:新机重登,绝不把密钥进备份文件。
- 工作产物:项目目录、会话导出(见
export_conversations_md.py)。
验证闭环:备份不算数,能恢复才算数。定期在干净环境跑恢复演练确认可用。
支柱二:成本策略(第 32 章)
token 是一人公司的核心运营成本。无控本,产品做得再好也不赚钱。三件套:
- 多模型分工:Opus 做决策、Sonnet 做实现、Haiku 做批量——用第 32 章的模型选型表。
- 缓存与压缩:prompt caching(第 99 章附录)、
/compact手动压缩、Plan Mode 减少无效探索。 - 预算管理:第 24 章 C.1 的
create_goal带token_budget——产品里也要给 Agent 设预算,接近上限时升级询问,而不是无脑烧到 context 满。
监控:用 /cost 看单会话消耗、/context 看上下文占用。某类任务 token 异常高就是优化信号——换模型、优化 prompt 或拆任务。
支柱三:知识沉淀(MEMORY + CLAUDE.md + 文档)
这是最容易被忽视、杠杆最大的一根支柱。你每次解决一个难题,如果不沉淀,下次还要重新解决——这就是没复用,杠杆率为 1。
三层沉淀:
| 层 | 载体 | 沉淀什么 | 加载时机 |
|---|---|---|---|
| 项目级 | CLAUDE.md | 技术栈、命令、规范、架构约束 | 每次启动自动加载 |
| 跨会话 | MEMORY | 经验、决策、踩坑、工作流 | auto memory 自动关联 |
| 可复用资产 | Skill / Workflow / 骨架文档 | 可执行的复用单元 | 按需调用 |
CLAUDE.md 是项目宪法(第 04 章)。MEMORY 是跨会话经验库——每解决一个非平凡问题就沉淀一条(如某 API 的限流规则、某库的版本陷阱)。Skill / Workflow 是可执行复用——把重复流程封装成 /your-skill,一行命令复跑。
知识沉淀的纪律:做完即沉淀,不要攒着。攒到"以后整理"等于不整理。每次解决完一个非平凡问题,花 30 秒让 CC 写进 MEMORY,复用次数就 +1,杠杆率就涨一档。
30.7 失败边界
框架再好,用错也死。三种最常见的死法:
死法一:什么都想做,导致失焦
一人公司最大的诱惑是"这个也能做、那个也能做"。四象限都想做、四个产品方向都想试、三个阶段想跳着走。结果是什么都做了一半,什么都没做成。
对抗策略:一次只做一个方向、一个产品、一个阶段。四象限可同时跑(业务维度非时间维度),但产品方向单选、阶段按序。判断标准:砍掉它公司会不会死?不会就砍。能让你活下来的只有一个东西,找到它,All in。
死法二:把 CC 当万能药,忽视商业判断
CC 工程能力很强,但它没有商业判断力。把产品方向、定价、渠道、用户取舍都交给 CC,你会得到一个"技术上完美但没人要"的产品。
典型症状:功能精致但用户不知道解决什么问题。根因是把"能做"当"该做"——CC 能实现任何功能,但"该不该做"是商业判断,只有人能做。
对抗策略:产品决策走"CC 给证据 → 人做判断"的流程,绝不反过来。第 06 章那句"你做架构决策和关键审查",在商业层面升级为"你做产品决策与商业判断"。CC 是放大器,放大的是你的判断,不是替代你的判断。
死法三:产品与市场脱节
这是阶段 3 的专属死法。Agent 产品做出来了,但没人买单。根因是跳过了阶段 1 的需求收集,直接从"我觉得这个好"做产品。
对抗策略:严格走三阶段递进(30.3)。阶段 1 记录客户反复要什么;阶段 2 验证参数化;阶段 3 产品定义来自前两阶段真实需求。没走过前两阶段不要直接做产品——那是练手项目,不是产品。
红线边界:不可让渡的决策
即便在 auto-accept 模式下,以下决策必须人按,不可委托 CC(呼应 CLAUDE.md 红线):
- 破坏性修改:删文件/目录、改 Git 历史。
- 凭据安全:
.env、密钥、Token、CI/CD 配置。 - 数据安全:数据库 Schema 变更、数据迁移。
- 风险命令:
git push、rebase、reset --hard、强制推送。 - 公开发布:
npm publish、部署到生产、发布文章。
这些红线在运营系统里是硬约束:hooks 可自动化 lint,但绝不能自动化 push;Workflow 可批量审查代码,但绝不能自动合并。第 05 章 deny 列表是执行层,CLAUDE.md 红线声明是 prompt 层——两层叠加(见第 24 章 B.1)。
30.8 与本书其他章的关系
本章是第六部分产品化篇的枢纽,串联前后章节:
- 第 24 章 Agent 产品骨架 ← 30.3 阶段 3 的起点。骨架是应用层产品的第一版标准答案,本章讲"为什么走应用层、什么时候走"。
- 第 28 章 内容生产工作流 ← 30.3 阶段 2 的落地。工作流产品化的具体案例。
- 第 29 章 接单开发网站 ← 30.3 阶段 1 的落地。接单脚手架与现金流验证。
- 第 31 章 备份与迁移 ← 30.6 支柱一。环境可重建的工程实现。
- 第 32 章 多模型与成本策略 ← 30.6 支柱二。token 控本的具体打法。
- 第 06 章核心心智模型 ← 本章的哲学基础。"你做决策,Claude 做执行"在一人公司语境下升级为"你做商业判断,CC 做实现与复用沉淀"。
- 第 05 章权限模型 ← 30.7 红线边界的执行层。
deny列表是运营系统里不可让渡决策的硬约束。
全书串联:第 06 章心智模型 → 第 05/07 章工程纪律 → 第 19-24 章 Agent 能力 → 第 25-29 章实战经验 → 本章装成整机 → 第 31-32 章运维手册。
30.9 核心心法
一人公司用 CC 建立系统性框架,核心不是"会用更多功能",而是"让每个能力被复用更多次"。浓缩成一句:
你做产品决策与商业判断,CC 做实现、探索与复用沉淀。每次解决一个难题,立刻沉淀成可复用资产——这就是杠杆率的增长。
执行清单(每周自检):
- [ ] 这周解决的问题,有没有沉淀进 MEMORY / CLAUDE.md / Skill?
- [ ] 当前在哪个阶段(接单 / 工作流 / 产品)?有没有偷偷想跳阶段?
- [ ] 四象限里,哪一象限是当前瓶颈?其余是否在最小维护?
- [ ] 成本可控吗?
/cost与/context有没有异常? - [ ] 备份能恢复吗?上次恢复演练是什么时候?
- [ ] 有没有把商业判断外包给 CC?
这六个问题答得上来,系统性框架就在运转。答不上来,就是某个齿轮在空转——回到对应小节修。
上一章:第 29 章 接单开发网站
下一章:第 31 章 备份与迁移