企业官网建设流程全解析

icm-architect是一款 Claude skill，它能把任何流程、想法或问题"设计"成一个ICM 工作区（Interpretable Context Methodology，可解释上下文方法论）——用文件夹结构当 Agent 架构，或者把一个现有的文件夹、仓库改造成这样的结构。对新手来说，最难的不是让 AI 干活，而是让它"知道该读什么、写到哪去"。icm-architect 给出的答案是 10 条不变量（invariants）：任何工作区，无论形态如何，都必须遵守这 10 条法则。本文带你逐条读懂它。📐

先搞懂：为什么"文件夹"可以当架构？

传统做法是写一套"编排代码"（orchestration code）来调度多个 Agent；ICM 的思路则反过来——把编排写进目录结构里：

• 编号文件夹负责排顺序（01_做完了才轮到02_）
• 层级结构负责圈定上下文（当前步骤只读自己需要的文件）
• 纯 Markdown 文件负责记录状态（进度就"看得见"）

官方用了一个很形象的比喻：工作区是一座图书馆，路由文件是目录卡——小而稳定，指向一切、几乎不存内容；一个"图书管理员"（单一模型）走进大楼，问题决定它走向哪个书架。这就是 README.md 中描述的核心理念。

10条黄金不变量逐条拆解 🎯

以下 10 条全部来自 SKILL.md 的 "The invariants" 章节。构建或改造工作区时，每一条都要强制执行。

法则 1：一个文件夹，只做一件事

每个文件夹要么完成一个步骤，要么存放一类东西，并在自己内部放一个文件说明自己的用途。结构本身就是文档——不需要另开一个 wiki。

法则 2：小而稳定的入口文件

根目录放一个CLAUDE.md（或其他 Agent 的AGENTS.md），只回答三个问题："我在哪？一切都在哪？任务 X 该去哪找？"——除此之外什么都不写。目标60 行以内。它只负责"路由"，绝不存内容。可直接参考模板 assets/templates/CLAUDE.md。

法则 3：编号即顺序

用01_、02_……表示流程顺序。重命名文件夹 = 重排流水线，这正是编号的妙处。想调整步骤先后？改名就行，不用改任何代码。

法则 4：每个工作文件夹都有显式"合同"

每个工作文件夹放一份CONTEXT.md，四段式写清：

这份"阶段合同"的完整模板见 assets/templates/stage-CONTEXT.md。

法则 5：工厂与产品分开存放

参考材料（规则、文风、schema、模板——每次运行都不变的）和工作产物（输出、草稿——每次运行都新的）必须在结构上分开。"工厂"只配置一次，"产品"是每次运行吐出来的东西。详见 references/core.md 的"Configure the factory, not the product"原则。

法则 6：每个输出都是"可编辑面"

中间产物必须是普通人能打开、修改、保存的纯文本文件。在有人读完上一个输出之前，流程不得往下走——这是 ICM 工作区里最核心的一条人工门禁。

法则 7：只加载当前步骤需要的东西

执行某一步的 Agent 只读它的合同、参考材料和输入，不读整个工作区。每步的健康区间是2000–8000 tokens。对比之下，把所有东西塞进一个大 prompt 通常要 30k–50k tokens，其中大部分与当前步骤无关。

法则 8：纯文本、可链接、可查询

统一用Markdown + YAML frontmatter：链接（[[wikilinks]]或相对路径）让文件成为一张图，frontmatter 标签让它可被查询。记住"一条事实只住一个地方"——链接永远好过复制。

法则 9：文件系统就是状态机

"当前状态"靠扫描输出文件夹里存在什么就能推导出来；自动生成的索引（文件地图、日志）由脚本重建，绝不手工编辑——手改的索引一定会漂移。

法则 10：靠"复制"来新建

新的工作单元 =复制一个模板文件夹，而不是面对空白页。模板统一放在_templates/或_system/文件夹里。模板本身，就是 schema。

选对形态：5种骨架，一套法则 🏗️

10 条不变量之下，icm-architect 提供 5 种经过实战检验的形态（详见 references/forms.md）：

它们可以自由组合、互相嵌套——因为不变量在每一层都递归成立。选形态前先问一个问题：重复的工作单元是什么？

验收标准：冷启动"行走测试"（Walk Test）🚶

工作区建好后怎么验证？让一个没有任何记忆的 Agent 冷启动走一遍：

1. 打开根目录，能否在入口文件 + 最多两次读取内回答"我在哪、当前任务去哪"？
2. 任选一个阶段，它的合同是否写明了精确的输入路径、任务、输出和人工检查项？
3. 能否仅凭扫描output/文件夹就说出流水线进度？
4. 有没有路由文件偷装了内容？有没有事实在两个地方各存了一份？
5. 入口文件 + 一份合同 + 输入，是否落在 2k–8k tokens 区间？

哪一步失败，就修结构——不是多解释，而是移动或拆分文件，直到"走"得通为止。

快速上手：安装与常用触发词 ⚡

Claude Code：把整个文件夹复制到~/.claude/skills/icm-architect/（或项目内的.claude/skills/icm-architect/），然后对 Claude 说：

• "ICM this" / "structure this for agents"
• "build me a workspace for X"

Claude 应用：上传打包好的icm-architect.skill（Settings → Capabilities）。

两种工作模式一句话区分：Build（从零描述的流程搭建）与Restructure（审计现有文件夹、把每个文件归类为 catalog / contract / factory / product / dead 五类，给出迁移地图、批准后再迁移）。所有可复制的起步模板都在 assets/templates/ 里。

新手避坑清单 ⚠️

• 别过度设计：爬升阶梯是"聊天 → 保存的 prompt/skill → 文件夹 + 单 Agent"，只有当下一级真的被自动化且反复发生时才往上走。
• 知道 ICM 的边界：实时多 Agent 协作、高并发多用户、流程中途自动分支，这些确实需要框架代码。ICM 服务的是顺序执行、人工审核、可重复的工作——也就是大多数知识工作。
• 警惕的腐化模式：两份手工维护的入口文件、schema 强制使用的命名与真实文件脱节、手改生成的索引、"模式"被自上而下宣布（同一形状在三个独立地方出现，才叫结构）。

写在最后

10 条不变量看起来是规则，本质是一套可解释性契约：任何时刻打开任何一个文件夹，你都能看清系统处于什么状态；任何新来的协作方，只需从上到下读完 CONTEXT 文件就能理解整条流水线。这正是 SKILL.md 的开头所承诺的——

"文件夹做编排，一个 Agent 在正确的时刻读正确的文件，就能顶替一个多 Agent 框架。"

把它贴在屏幕边上，你的下一个 Agent 工作区就有了骨架。✅