这条 MinLiBuilds 的帖子，最有价值的地方不是“Claude Code 又多强了”，而是它把一套真正能落地的 workflow 摆了出来。
核心意思可以压缩成一句话：
不要把 Claude Code 当成一个会聊天的模型，要把它当成一套可以编排的工作系统。
在这套系统里，不同层承担不同职责：
- CLAUDE.md 负责表达判断
- Skills 负责封装动作
- Hooks 负责控制边界
- Subagents 负责并行执行
这不是术语堆砌，而是工程上非常重要的分层。因为一旦你把“判断、动作、边界”混在一起，Claude Code 就会退化成一个更贵的聊天框；分开之后，它才有机会变成真正的生产力机器。
目录
- 一、这条帖子真正讲的是什么
- 二、为什么 CLAUDE.md 不是可有可无
- 三、Skills 解决的是动作复用，不是知识灌输
- 四、Hooks 解决的是边界自动化，不是多加一层配置
- 五、Subagents 才是把 1 个人变成 10 个人的关键
- 六、这套 workflow 为什么能跑起来
- 七、你可以怎么照着抄
- 结语
一、这条帖子真正讲的是什么
从你给的这条 X 帖子和它的镜像摘要来看，MinLiBuilds 想表达的不是“我会用 Claude Code”。
他想表达的是：我把 Claude Code 变成了团队工作流的一部分。
搜索摘要里有几个信息很关键：
- 他提到自己用自动化工具，持续做了 10 个月
- 这套方法覆盖了设计实验、Figma 批量出图、投放广告、数据收集和评测
- 甚至有人把它总结成“Claude 一人成军”
这说明 Claude Code 不再只是“帮我写点代码”，而是在接管一部分真实业务流程。
这一步跨得很大。
因为当 AI 只负责生成答案时，它的价值上限是“快一点”。 当 AI 开始负责流程里的某些环节时，它的价值上限就变成了“组织结构的重写”。
二、为什么 CLAUDE.md 不是可有可无
很多人第一次接触 Claude Code，会把 CLAUDE.md 当成项目说明书。
这个理解只对了一半。
更准确地说，CLAUDE.md 是把人的判断显式化。
它应该回答的不是“这个项目是干什么的”，而是：
- 这类任务优先怎么做
- 哪些风格不能碰
- 哪些依赖是默认可用的
- 哪些步骤必须人工确认
- 哪些结果可以直接接受，哪些必须重试
换句话说，CLAUDE.md 不是文档，它是偏好、约束和决策标准的载体。
如果没有这一层，Claude Code 每次都得重新猜你的口味，workflow 就会变成低效的反复问答。
如果有这一层，Claude Code 就能开始像团队成员一样做事。
这也是为什么很多人觉得 Claude Code 好用，真正原因不是模型更聪明。
而是因为它终于可以吃到结构化上下文了。
三、Skills 解决的是动作复用，不是知识灌输
如果说 CLAUDE.md 负责判断，那 Skills 负责的就是动作。
这里最容易踩的坑，是把 Skill 写成知识文档。
其实不对。
Skill 最有价值的地方，不是告诉 Claude“你应该了解什么”，而是告诉它：
- 这件事具体怎么做
- 哪些步骤必须按顺序来
- 用什么模板输出
- 什么时候调用脚本
- 什么时候停下来等人审查
说白了，Skill 是可复用的动作模板。
它适合放这些内容：
- 生成固定格式的交付物
- 重复执行的迁移步骤
- 一套稳定的检查流程
- 面向某类任务的标准操作手册
这就解释了为什么写 Skill 比教模型一堆背景知识更有用。
背景知识会过期，动作模板会沉淀。
你真正想沉淀的，不是答案，而是“这类问题的处理路径”。
四、Hooks 解决的是边界自动化，不是多加一层配置
如果 Skills 是让 AI 更会做事，那 Hooks 就是让 AI 别乱做事。
很多团队在这里会犯一个很典型的错误：把 Hook 当成工具箱里的一项可选功能。
其实 Hook 的价值比这大得多。
它是 workflow 里的边界层。
比如：
- 改文件前做检查
- 输出前做格式校验
- 某些目录操作必须拦截
- 某些危险命令必须升级审批
- 某些流程节点必须强制打日志
这类规则如果都靠人盯着，最后一定会变成疲劳战。
Hook 的意义，就是把“要不要提醒人类”这件事前置成自动决策。
这和 Anthropic 最近给 Claude Code 做 Auto Mode 的思路其实是一致的：
不是取消安全，而是把安全做成系统能力。
所以，真正成熟的 workflow，不是“允许 AI 做更多事”。
而是“让它在可控边界内做更多事”。
五、Subagents 才是把 1 个人变成 10 个人的关键
如果你只靠单线程 Claude Code，最多是一个更强的助手。
但一旦引入 Subagents，事情就变了。
因为很多工作天然可并行：
- 一个子代理负责读文档
- 一个子代理负责跑实验
- 一个子代理负责改代码
- 一个子代理负责做对比和总结
这才是“一人军成”背后的真实机制。
不是因为主模型变成了超人，而是因为你把任务拆成了多个可并行的工作单元。
这点很关键。
很多人对 Agent 的幻想是“一个模型从头到尾自己解决所有问题”。 真正能落地的方式通常相反：
主控负责目标，子代理负责局部，系统负责收口。
这和团队管理其实完全一样。
优秀的 manager 不是什么都自己干，而是知道：
- 谁该做什么
- 哪些任务可以同时开工
- 哪些结果要合并
- 哪些地方必须亲自拍板
Claude Code 的 workflow 走到这里，本质上已经不是工具使用，而是组织设计。
六、这套 workflow 为什么能跑起来
这套方法之所以有效，是因为它把最贵的部分和最便宜的部分分开了。
贵的部分：判断
判断是最值钱的。
它决定：
- 目标对不对
- 方案对不对
- 风险要不要拦
- 哪些地方不能自动化
所以它应该放在 CLAUDE.md 和人为审查里。
便宜的部分：动作
动作是最容易模板化的。
它决定：
- 怎么跑
- 怎么写
- 怎么测
- 怎么导出
所以它应该放在 Skills 里。
最容易出事故的部分：边界
边界如果没管好，自动化就会从生产力变成事故源。
所以它应该交给 Hooks 和权限控制。
当这三层分开以后，Claude Code 才真正有了一个稳定的工作系统。
这也是为什么你会看到越来越多团队在做类似的事：
不是把 AI 塞进某个 prompt，而是把整个工作流重新设计一遍。
七、你可以怎么照着抄
如果你现在也想做一套类似的 Claude Code workflow，我建议不要一上来就搞很大。
先从一个高频场景开始。
第一步：挑一个重复任务
比如：
- 生成周报
- 跑测试并汇总
- 把设计稿转成可执行任务
- 做发布前检查
第二步：把判断写进 CLAUDE.md
只写三类东西：
- 项目原则
- 输出标准
- 禁止事项
第三步：把动作做成 Skill
只保留一件事：
- 让它稳定复用
不要试图一个 Skill 包打天下。
第四步：把风险边界做成 Hook
先拦最容易出事故的地方：
- 文件改动
- 命令执行
- 输出格式
- 敏感路径
第五步：再考虑 Subagents
只有当任务真有并行空间时，再拆子代理。
不然你只是在增加复杂度。
结语
MinLiBuilds 这条帖子真正厉害的地方，不是“Claude Code 很强”，而是它提醒我们：
AI 的生产力不是靠一个更会说话的模型，而是靠一套更像工程系统的工作流。
把判断放进 CLAUDE.md，把动作封装成 Skills，把边界交给 Hooks，把并行交给 Subagents，Claude Code 才会从一个聊天工具，变成一个能真正接活的生产系统。
这套思路对任何做 Agent、做自动化、做知识工作的团队都适用。
如果你只记住一句话，那就记这个：
别只问“Claude Code 会不会做”，先问“你有没有把判断、动作和边界拆开”。
欢迎关注收藏我，获取更多硬核技术干货