企业官网建设流程全解析

1. 一张架构图，三种角色围观：多角色评审的真实摩擦点

多角色评审里最尴尬的不是图画得丑，而是同一张图被三拨人用三种方式误读。开发看的是模块边界和依赖方向，运维看的是部署单元、网关、健康检查和影响面，安全看的是信任边界、鉴权点和数据流向。结果就是：评审会上大家对着同一张静态截图，开发在讲“这个 service 拆得对不对”，运维在问“挂了这个下游会炸哪些”，安全在追“这条链路到底有没有过鉴权”。三十分钟过去，图没改，问题也没收敛。

这篇的处理方式是：把角色视角对比这件事交给 Archify 的视图着色与链路能力，把模型侧的调用统一收敛到 TaoToken（官网入口）。整条链路的产出是三个可以双击打开的 HTML：开发着色版、运维着色版、安全着色版，外加上一次重构的 Before / Delta / After 对照。图不再是一张“看完就丢”的截图，而是一份能搜节点、能追链路、能跟着代码重生成的评审材料。

这篇文章不写“架构图有多重要”“AI 让一切变简单”这种泛泛之谈，只做两件事：第一，把 TaoToken 填进 Claude Code（以及 Codex）的设置里，让 Agent 侧跑通；第二，用 Archify 把三种角色的着色差异、模型参数和导出产物完整跑一遍，给出可复制的配置和评审清单。

开头先把边界说清楚：Archify 是 MIT 协议开源的 AI Agent 技能（Agent Skill），装在 Claude Code / Cursor 这类环境里用，本文讨论的是它在多角色评审场景下的具体用法；TaoToken 提供的是模型接入侧的统一 Base URL 与 Key，两者是上下游关系，不是替代关系。

2. 先把 Key 拿到手：TaoToken 的接入前准备

在动 Archify 之前，先解决“Agent 用哪个模型、从哪个入口调用”的问题。这一步没打通，后面不管画什么图都会卡在认证或者 base url 上。

第一步是拿 Key。进入 TaoToken 官网，登录后在控制台创建 API Key，占位符统一记作YOUR_API_KEY。Key 只显示一次，建议直接落到本地密码管理器里，不要贴在聊天窗口里传。

第二步是确认 Base URL。整套配置里唯一需要填的地址是：

https://taotoken.net/api

这个地址在下面 Claude Code 的ANTHROPIC_BASE_URL、Codex 的base_url、以及 CC Switch 的地址栏里都填同一个值。写错成.../v1或者带斜杠结尾，都会造成 404 或者鉴权失败，所以建议直接复制，不要手敲。

第三步是确认模型名。模型列表会更新，具体名字以控制台的模型页面为准。本文用YOUR_MODEL_NAME作为占位符，实际使用时替换成你要用的那个。对于架构图这种“读代码 + 结构化输出 + 长上下文推理”的任务，建议选上下文窗口和推理能力都比较稳的模型，不要用最小的快模型去跑全仓库扫描，否则 IR 往往生成到一半就开始丢字段。

还有一个容易被忽略的点：如果团队里有人既用 Claude Code 又用 Codex，Key 可以共用，但环境变量命名和配置文件位置不一样，混用会出问题，下一节具体说。

3. 把 TaoToken 填进 Claude Code：settings.json 与 ANTHROPIC_* 双写法

Claude Code 的配置有两套常见写法：一套是环境变量，一套是settings.json。两种都可以用，环境变量适合临时切换，settings.json适合把配置固化下来给团队复用。

3.1 settings.json 写法

在用户目录下的配置文件中写入：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "YOUR_MODEL_NAME", "ANTHROPIC_SMALL_FAST_MODEL": "YOUR_FAST_MODEL_NAME" } }

几个字段的用途分别是：ANTHROPIC_BASE_URL决定请求发到哪里；ANTHROPIC_AUTH_TOKEN是鉴权凭据；ANTHROPIC_MODEL是主模型；ANTHROPIC_SMALL_FAST_MODEL用于一些轻量任务（比如摘要、标题生成），可以填一个便宜快速的模型，能明显压住成本。

写完之后重启 Claude Code，让它重新读取配置。判断是否生效的最简单方式是问一个需要真实模型响应的问题，如果报的是 401 或者连接错误，大概率是 Key 或地址写错了；如果模型自称的身份不对，说明模型名没替换成实际值。

3.2 环境变量写法

不想改配置文件的话，可以在 shell 启动脚本里导出：

export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY" export ANTHROPIC_MODEL="YOUR_MODEL_NAME"

这种写法的好处是改起来快，坏处是换终端就没了。做多角色评审这种需要反复跑的任务，建议还是固化到settings.json，避免每次评审前先折腾一遍环境。

3.3 一个常见的错配

很多人会把ANTHROPIC_*这一组变量复制到 Codex 的配置里，然后发现完全不生效。原因很简单：Codex 读的是config.toml，不认这套环境变量。这是两套独立的接入协议，不要互相套用。

4. Codex 走 config.toml，CC Switch 管三件套

如果团队里有人用 Codex，配置方式要单独走一遍。

4.1 Codex 的 config.toml

在 Codex 的配置文件中写入：

model_provider = "taotoken" model = "YOUR_MODEL_NAME" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"

然后在环境里导出对应的 Key：

export TAOTOKEN_API_KEY="YOUR_API_KEY"

这里再次强调：Codex 用的是env_key指向的自定义变量名，不要写ANTHROPIC_AUTH_TOKEN；Claude Code 用的是ANTHROPIC_*前缀。两边字段不要交叉。

4.2 CC Switch 三件套

如果团队用 CC Switch 这类配置切换工具来管理多套环境，本质上就是三件套：

三件套填完之后，切换配置就不需要手工改文件了。建议把“评审专用”单独存成一个配置档，里面锁一个上下文较长、推理较稳的模型，避免评审时误切到便宜的小模型，导致 Archify 生成的 IR 缺字段。

4.3 配置完成后的自检

在正式跑 Archify 之前，先在 Claude Code 或 Codex 里做一次最小自检：让它读一个项目里的文件并总结内容。如果能正常返回，说明 Key、Base URL、模型三件套都通了；如果返回超时，先检查网络出口和地址拼写，再检查 Key 是否被禁用。

配置通过之后，再进入 Archify 的安装和角色视角部分。

5. 装上 Archify：让 Claude Code 能读懂代码再画图

配置通了以后，安装 Archify：

npx skills add tt-a1i/archify -g

安装完成后，在 Claude Code 或 Cursor 里直接用自然语言提需求即可。多角色评审场景下，建议不要一句“帮我画个架构图”就完事，而是把角色诉求写进指令里，例如：

读取当前仓库，生成一份架构图 IR。 要求： 1. 节点必须能对应到真实文件路径； 2. 标注出鉴权相关的模块与调用边； 3. 预留开发 / 运维 / 安全三种角色着色方案。

Archify 的工作方式和“让模型直接吐 Mermaid”最大的区别在于它的两段式流程：先由 Agent 生成一份类型化的 JSON 中间表示（IR），再由引擎做原子化验证，检查节点与边是否能对应到真实代码位置，通过后才确定性编译成 HTML/SVG。验证不通过时，Agent 拿到的是一份逐条可修复的诊断清单，改完再验，直到通过为止。

这一点对多角色评审来说非常关键。因为评审会上最怕的不是图不好看，而是有人指出“这个服务根本不存在”或者“这条调用链早就删了”。有验证机制兜底，图上的节点和边才敢拿来做影响面分析。

安装完成后的第一次生成，建议选一个中等规模的仓库，不要一上来就扫整个单体。先跑通流程，再逐步扩大范围。

6. 角色视角对比怎么落地：开发、运维、安全三种着色

这一节是全文的核心：同一个系统，三种角色看到的是三张着色和侧重都不同的图。

6.1 开发视角

开发视角关心的是：模块边界在哪里、依赖方向是否合理、分层有没有被破坏、改动一个模块会牵连到哪些同层组件。

在 Archify 的交互里，这一视角下可以配合节点搜索和上下游可达性追踪使用。举个例子：评审时有人提出“把用户服务里的鉴权逻辑抽出去”，开发者可以立刻点中鉴权相关节点，查看它的上游调用方和下游依赖，判断这次抽取会影响到哪些模块。

着色上，开发视角通常会突出分层结构和模块归属，弱化部署细节。这样做的目的是让讨论聚焦在代码结构上，而不是被一堆实例名带偏。

6.2 运维视角

运维视角关心的是：这个系统怎么部署、有哪些进程和实例、入口在哪、挂了哪个组件会连带影响哪些服务。

这个视角下最有用的是可达性追踪和路由探测。指定入口节点和目标节点，把中间经过的调用路径亮出来，回答“这次故障会蔓延到哪一层”这个问题。相比在脑子里脑补拓扑，把路径画出来给所有人看，沟通成本会低很多。

着色上，运维视角会强化入口、网关、部署边界，弱化代码级别的模块划分。同一张图，切到这个视角就变成了一张“事故影响面示意图”。

6.3 安全视角

安全视角关心的是：信任边界在哪、哪些调用跨过了边界、鉴权点覆盖了哪些路径、数据流向是否合规。

在多角色评审里，安全视角往往是信息差最大的一个。开发觉得“这个接口当然鉴权了”，运维觉得“网络层已经隔离了”，安全要的是图上能明确标出每一条跨边界的边。用 Archify 的节点关联能力，把鉴权模块对应的文件路径亮出来，讨论就从“我觉得”变成“这里有一条边，对应这个文件”。

着色上，安全视角会突出跨信任域的调用边和鉴权节点，弱化与安全无关的业务模块。

6.4 三种视角的切换价值

三种视角不是为了好看，而是为了让同一份 IR 在不同评审阶段服务不同问题。评审开始用开发视角对齐模块结构，讨论到部署和故障蔓延时切运维视角，讨论到合规和权限时切安全视角。整个过程不需要重新画图，也不需要重新生成 IR，只是换一个渲染侧重。

这就是“角色视角对比交给 Archify”的实际含义：把视图切换的成本降到接近零，让评审从“各说各的”变成“对着同一份数据说”。

7. 可复现产出：模型设置、视角切换与导出 HTML 对照

多角色评审要能复现，关键在于把“用哪个模型、切了哪些视角、导出了什么”写清楚。

7.1 模型设置记录

在评审材料里附一段配置快照，格式如下：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "YOUR_MODEL_NAME" } }

注意不要把真实 Key 写进任何会外发的文档，用占位符代替，实际值只保留在本地配置里。

7.2 视角切换的最小操作序列

一次完整的多角色评审可以按这个顺序跑：

1. 生成 Base 视图，确认节点和边都能对应到代码位置；
2. 切到开发视角，导出dev-view.html；
3. 切到运维视角，导出ops-view.html；
4. 切到安全视角，导出sec-view.html；
5. 如果这次评审涉及重构，再额外生成 Before / Delta / After 三张视图。

导出物是自包含单文件 HTML，双击就能打开，不依赖任何运行时。链接里还能带上视图状态，发给同事时对方打开看到的视角和你一致，不用再口头解释“你点一下那个节点”。

7.3 评审现场怎么用

把三份 HTML 放在同一台机器的三个标签页里。讨论到模块拆分，切到开发视图；讨论到故障影响面，切到运维视图；讨论到权限和信任边界，切到安全视图。重构评审时把 Delta 视图投到大屏上，直接看这次变更动了哪些链路。

如果现场需要贴到文档或者群里，Archify 还能导出 PNG、SVG、WebM 以及标准分享卡片。日常配图用静态导出就够，正式评审建议保留 HTML，因为可交互的版本能现场回答“这条路能不能走通”。

8. 和另外两条赛道比一比：Archify 的位置在哪

在 Agent 绘图这条新赛道上，除了 Archify，还有两个常被拿来对比的工具。

一个是 fireworks-tech-graph，MIT 协议，同样是 Agent Skill，中英文自然语言输入，产出发布级 SVG 和高清 PNG，有七种视觉风格、覆盖十四种 UML 图，还内置了 RAG、Multi-Agent、Tool Call 这类 AI 领域模板。它的强项是一张可以直接发布的漂亮静态图，短板是输出不可交互、不读代码库、拓扑不做验证。

另一个是岚叔动态架构图，走手绘动画路线，一份 JSON 描述产出黑底手绘风 GIF，附带 PNG 和可编辑源文件，还自带帧差校验。它的强项是视觉冲击力和传播性，短板是视觉系统较窄，同样不读代码库、不做验证。

三者其实是三种取向：fireworks 追求“一张能发的图”，岚叔追求“一张能刷屏的图”，Archify 追求“一份能探索、能验证、能进评审的系统图谱”。日常写教程配图，前者够用；要在评审会上对着代码较真，Archify 的验证机制和角色视角才有不可替代性。三条赛道甚至可以组合使用：评审用 Archify，对外宣传用另外两个。

需要提前说清楚的局限也有几个。第一，Archify 必须依附在 AI 编程工具里使用，没有独立网页版，不习惯用 Agent 的同事需要先适应。第二，图不会自动更新，代码改了要重新生成一遍，官方还没有内置 CI 自动刷新方案。第三，极端复杂的系统自动布局仍可能需要人工微调，它毕竟不是 draw.io 那种手动画布。第四，项目还比较年轻，Schema 和接口可能随版本变化，生产环境使用建议锁版本。

9. 收尾：把评审从“一张图”升级成“一条流水线”

多角色评审的痛点从来不是“没人画图”，而是“画出来的图没法回答三种角色的问题”。把 TaoToken 填进 Claude Code 和 Codex 的设置里，解决的是 Agent 侧的模型接入；把 Archify 装上并利用它的角色视角和验证机制，解决的是图与代码对不上的问题。两者拼起来，才是一条能跑通的多角色评审流水线。

配置路径再捋一遍：先在 TaoToken 官网 拿到 Key，把 Base URL 设为https://taotoken.net/api，Claude Code 写ANTHROPIC_*，Codex 写config.toml，CC Switch 管好三件套。然后安装 Archify，对 Agent 说出你的评审需求，按开发、运维、安全三个视角分别导出 HTML，重构场景再补一组 Before / Delta / After。

如果你还没决定用哪个模型跑这套流程，可以先去 模型对话 里实测一轮，确认长上下文和结构化输出稳定之后，再进到 Coding Plan 看额度方案。准备好之后，到 API Keys 创建 Key，配置方法对照 Claude Code 文档 一步步填就行。

架构图不该是一张固定的图片。它应该能被搜索、能被追溯、能按角色切换视角，也能在代码变化之后重新生成。把这条链路跑通之后，评审会上的争论会少很多，因为大家看的是同一份能对得上代码的图。