别只盯上下文了：Claude Code 的软件工厂思路
公众号名称：极客BIM设计工坊
作者名称：朗朗晴空
发布时间：2026-05-26 00:09
#ClaudeCode #Agent #软件工厂
Rahul 这篇 X 长文最有价值的地方，不是又列了一套 Claude Code 技巧，而是把问题往前推了一步：当上下文已经能被管理，下一步要管理的是任务、架构、验收和产出节奏。
7
个角色
3
个检查点
1
条生产线
小白先看懂：这东西到底在解决什么
普通人看 Claude Code，容易把它理解成“会写代码的聊天窗口”。你提出需求，它生成代码；报错了，你把错误贴回去；它再修。刚开始很爽，像突然多了一个很快的同事。
但做过稍复杂功能的人会很快遇到天花板：同一个逻辑出现在三个地方；两周前定过的约定被忘掉；新功能把旧功能撞坏；测试补得很浅；最后你花在盯 Claude、纠错、擦屁股上的时间，接近过去自己写代码的时间。
Rahul 把这个问题叫做从 vibe coding 走向 software factory。我更愿意把它翻译成一个更直接的判断：AI 编程的核心矛盾，正在从“模型懂不懂上下文”，转向“开发流程有没有被重新设计”。
第一层问题：上下文不干净，代码就会漂
过去半年，很多 Claude Code 讨论都围绕上下文展开：怎么写 CLAUDE.md，怎么记录项目约定，怎么让模型记住测试命令，怎么避免每次开新会话都从零解释。
这个方向没错。Anthropic 文档也明确说，CLAUDE.md 是项目、个人或组织的持久说明文件，会在每个 session 开始时被读取。它适合放构建命令、代码约定、项目结构、团队规则。
但上下文只能解决“别忘事”。它不能自动解决“谁来拆需求”“谁来定接口”“谁来验收”“错了以后由谁返工”。很多人把上下文文件越写越长，最后得到的只是一个更会背项目背景的 Claude，而不是一条能稳定交付的生产线。
关键判断 上下文管理解决的是记忆质量，软件工厂解决的是交付质量。前者让 Agent 知道“现在在哪”，后者决定“下一步谁做、做到什么程度、怎么验”。
第二层问题：一个会话承担了太多角色
原文里最扎心的一段，是说你让 Claude Code “build this feature” 时，其实在要求同一个会话同时扮演产品分析师、架构师、后端工程师、前端工程师、测试工程师和代码评审员。
人类工程团队不会这样工作。真实团队会先澄清用户问题，再写规格，再做架构，再分端实现，再测试，再评审。把这些工序压进一个长会话里，错误就会悄悄传染：需求理解错了，数据库模型跟着错；模型错了，API 跟着错；API 错了，前端再围着错接口做补丁。
所以 7 个 Agent 的重点不在数量，而在责任边界。每个角色只接收必要输入，只使用必要工具，只产出下一道工序需要的东西。
● Researcher：先读代码，找相关文件、已有模式、风险点，不写代码。
● Story Writer：把模糊想法转成用户故事、验收标准、边界和待确认问题。
● Spec Writer：把故事转成技术 brief，明确数据模型、API、前端、测试和风险。
● Backend / Frontend Builder：分别实现自己的范围，不跨边界乱改。
● Test Verifier / Validator：一个从用户故事验证行为，一个从实现结果找缺口。
Software Factory 的本质：工序化，而不是堆 Agent
如果只照抄“7 个 Agent”，很容易做成另一种形式主义：文件夹里塞满角色设定，但每个角色都在做差不多的事。真正有效的是工序化：每一步都有输入、动作、输出、验收条件。
原文给的链路很清楚：先研究代码，再写用户故事；人类确认故事；再写技术 brief；人类确认 brief；后端和前端按范围实现；Verifier 写验收测试；Validator 最后按严重程度报告缺口；修完再验；最后人类看 PR。
▸ 输入：每个 Agent 只拿自己需要的材料，避免噪音污染判断。
▸ 权限：研究者只读，构建者可写，验收者尽量不改实现。
▸ 产出：故事、brief、代码、测试报告、验证报告都能被下一步消费。
普通 AI 编程：一个长会话里完成需求、设计、实现、测试和补丁。速度快，但错误会沿上下文扩散。
软件工厂：把开发拆成可交接的工序。速度未必来自单次生成，而来自返工减少、并行增加、验收更早。
Subagent 的真正价值：决定什么不该进入上下文
Anthropic 对 subagent 的定义里，有一个很关键的点：每个 subagent 都运行在自己的 context window 里，可以有自定义 system prompt、特定工具访问和独立权限。这就把“上下文管理”推进到“上下文隔离”。
过去我们总在问：还要给 Claude 什么信息？软件工厂要反过来问：哪些信息不该给这个 Agent？Validator 不应该被 Builder 的自我解释影响；Frontend Builder 不应该临时发明后端接口；Researcher 不应该顺手改文件。边界越清楚，产出越像工程结果，而不是聊天结果。
Hooks、Skills、Worktrees：让它接入工程生命周期
Claude Code 的有趣之处，不只在模型会写代码，而在它开始接近一个工程运行环境。hooks 可以在生命周期节点自动执行 shell、HTTP 或 prompt；skills 可以把可复用能力封装起来；worktrees 可以隔离并行 session；CLAUDE.md 和规则文件承担长期约束。
Rahul 的 GitHub power setup 也沿着这个方向组织：hooks、skills、agents、safety rails、automation，再加上 Discuss、Plan、Execute、Verify 的轻量流程，以及 STATE.md、CONTEXT.md、LESSONS.md 这类上下文协议。它背后的思路很朴素：少赌一次生成，多设计一个可复用流程。
FIX别把软件工厂做成角色扮演
Agent 多不代表流程强：没有清晰输入、输出和权限，七个 Agent 只是七段 prompt。
自动化多不代表风险低：真正该保留的，是需求确认、规格确认、合并前确认这几个检查点。
开发者的新能力：从会提问，变成会组织产出
这件事对开发者的要求其实更高了。过去拼的是谁会写更漂亮的 prompt，谁知道更多上下文技巧。下一阶段拼的是谁能把任务拆清楚，把接口定义清楚，把验收条件写清楚，把失败经验沉淀到规则里。
换句话说，Claude Code 的重点不只在 Code。真正影响效率的，是 Code 之前的需求收敛、架构判断，以及 Code 之后的测试、验收、回流。一个人加七个 Agent 能不能变成团队，不取决于“七”这个数字，取决于它们之间有没有工序和接口。
旧能力
写 prompt、贴报错、让模型补代码、人工反复盯结果。
新能力
定义角色、拆任务、设权限、做验收、沉淀流程。
普通团队怎么从最小版本开始
不用一上来搭 7 个 Agent。更稳妥的起点，是三份文件加三个角色。
▸ 三份文件：CLAUDE.md 放长期规则，STATE.md 放当前状态，LESSONS.md 放反复踩过的坑。
▸ 三个角色：Planner 只拆任务，Builder 只实现，Validator 只验收。
▸ 三个检查点：确认用户故事，确认技术 brief，合并前确认测试和验证报告。
如果这个最小版本跑顺，再扩展后端、前端、测试、安全等专门角色。软件工厂不是一次性搭出来的，它应该在真实项目里被调试出来。
当上下文可以被管理之后，真正稀缺的是架构能力。
最后的判断
这篇长文提醒我们的，不是“再多装几个 Agent”，也不是“让 Claude 替你睡觉时写完全部功能”。真正值得带走的是工作重心的转移：别只问如何把上下文塞得更满，要问如何让任务更清楚、角色更干净、产出更可验收。
未来拉开差距的，很可能不是谁更会催模型干活，而是谁更会设计一条能稳定交付的软件生产线。人不会从流程里消失，但会从每一步操作员，移动到关键节点的判断者。
SOURCES
Rahul, How to Build a Software Factory with Claude Code That Ships Features While You Sleep — https://x.com/sairahul1/status/2058832033628241931
Anthropic Claude Code Docs, Create custom subagents — https://code.claude.com/docs/en/sub-agents
Anthropic Claude Code Docs, Store instructions and memories — https://code.claude.com/docs/en/memory
Anthropic Claude Code Docs, Skills / Hooks / Worktrees — https://code.claude.com/docs/en/skills
rahul-nexailabs/claude-code-power-setup — https://github.com/rahul-nexailabs/claude-code-power-setup
原创 朗朗晴空 极客BIM设计工坊
作者提示: 内容由AI生成
内容效果不满意？点此反馈