企业官网建设流程全解析

1. 几十页 Word 排版为什么总在返工

写方案的人大概都有这种体验：内容两小时写完，格式调了一下午。一级标题用了几种字号自己都记不清，正文有的首行缩进 2 字符、有的用空格顶出来，页眉页码从第三章开始突然消失，图片一会儿居中一会儿左对齐。最要命的是领导说「把二级标题统一改成小四加粗」，你改完发现目录页码全乱了，又得从头刷一遍。

问题的根子不在手速，而在于 Word 的格式是「散落」的：字体信息藏在每个 run 里，段落间距藏在 paragraph 属性里，页眉页脚又是另一个 section 对象。你手动改，本质上是在几百个对象上重复同一个动作，只要漏掉一个，视觉上就露馅。几十页文档里这种漏网点位轻松上百，人眼根本盯不过来。

我试过用 Word 自带的「样式」功能，理论上改一次样式全局生效，但现实是很多人写文档时压根没用样式，全是手动加粗放大，样式面板里一堆「正文」「正文 2」「正文 3」根本对不上号。这时候你需要的是一个能读懂文档结构、按规则批量重刷的工具，而不是更快的格式刷。

Claude Code 的 Skill 机制刚好适合干这件事。它允许你把一套处理逻辑固化成可复用的技能，下次换一份文档，输入技能名加文件路径就能跑。配合 TaoToken 提供的模型调用能力，整个流程可以做到「上传文档 → 说一句要求 → 等两分钟 → 拿回排好版的文档」。这篇就按这个思路，从零把 word-style 这个技能搭出来，覆盖标题层级、段落缩进、页眉页脚统一这些高频场景，最后给你一套能直接复制运行的配置和验证命令。

2. TaoToken 接入 Claude Code 的前置准备

在写 Skill 之前，得先让 Claude Code 能稳定调用模型。Claude Code 本身是个命令行 Agent，它需要后端模型服务来理解你的指令、生成处理脚本。TaoToken 在这里扮演的就是模型接入层，你通过它拿到 API Key 和 Base URL，填进 Claude Code 的配置里，后面所有 Skill 调用都走这条链路。

先明确三件套，这是后面所有配置的基础：

获取 Key 的入口在控制台，登录后进 API Keys 页面新建一个，复制出来存好，页面关掉就看不全了。这一步别偷懒，Key 泄露等于别人用你的额度。

拿到 Key 之后，Claude Code 的配置方式取决于你用的是哪种接入形态。如果你用的是 Claude Code 原生命令行，配置写在~/.claude/settings.json；如果你用 CC Switch 这类多配置切换工具，那就在它的配置面板里填；如果你走的是 Codex 风格的auth.json，字段名会略有不同。下面给一份通用的 settings 片段，路径和字段名按你本地实际情况对齐：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key粘贴在这里", "ANTHROPIC_MODEL": "你的ModelID" } }

注意ANTHROPIC_BASE_URL后面不要带/v1之类的后缀，TaoToken 的 API 入口就是https://taotoken.net/api，多写反而会 404。填完之后在终端里跑一次claude命令，能正常进入交互界面就说明链路通了。如果报 401，先检查 Key 有没有复制完整、有没有多余空格；如果报连接失败，检查 Base URL 拼写。

这一步做完，你手里就有了一个能对话、能执行本地命令的 Claude Code 环境。接下来才是重点：把「Word 排版」这件事拆成 Skill 能理解的规则。

3. word-style 技能目录结构与可复制配置

Skill 的本质是一个带说明文件的文件夹，Claude Code 读到这个文件夹就知道「遇到这类任务该按什么流程走」。word-style 的目录结构建议这样组织：

word-style/ ├── SKILL.md ├── rules/ │ └── word-style.json └── scripts/ └── apply_style.py

SKILL.md是技能说明书，告诉 Claude Code 这个技能干什么、什么时候触发、依赖哪些文件。rules/word-style.json是格式规则本体，所有字号、缩进、间距都写在这里，改规则不用动代码。scripts/apply_style.py是实际执行格式刷新的脚本，用 python-docx 操作文档对象。

先看规则文件，这是你后续调格式最常改的地方：

{ "heading1": { "font": "黑体", "size": 16, "bold": true, "space_before": 12, "space_after": 6, "alignment": "left" }, "heading2": { "font": "黑体", "size": 14, "bold": true, "space_before": 10, "space_after": 4, "alignment": "left" }, "body": { "font": "宋体", "size": 12, "first_line_indent": 2, "line_spacing": 1.5, "space_after": 0 }, "header": { "text": "项目方案", "font": "宋体", "size": 9, "alignment": "center" }, "footer": { "page_number": true, "font": "宋体", "size": 9, "alignment": "center" } }

first_line_indent单位是字符，2 就是首行缩进 2 字符，比用厘米更符合中文排版习惯。line_spacing用倍数，1.5 就是 1.5 倍行距。页眉页脚单独成块，page_number为 true 时脚本会自动插入页码字段。

然后是SKILL.md，内容要写得让模型能准确判断触发时机：

# word-style ## 用途 对 Word 文档执行统一排版，覆盖标题层级、正文缩进、页眉页脚。 ## 触发条件 用户提到「word-style」「Word 排版」「统一格式」「刷格式」时启用。 ## 执行步骤 1. 读取 rules/word-style.json 获取格式规则 2. 运行 scripts/apply_style.py，传入文档路径 3. 脚本自动备份原文件为 xxx_backup.docx 4. 输出处理报告，列出修改的段落数和标题数 ## 依赖 python-docx

apply_style.py的核心逻辑是遍历文档的 paragraphs，根据段落样式名判断它属于 heading1、heading2 还是 body，然后套用对应规则。这里有个坑：很多人写文档时标题并不是用「标题 1」样式，而是手动加粗放大。脚本里要加一层启发式判断，比如字号大于 14 且加粗的段落，按 heading1 处理。这部分逻辑我放在脚本里，你可以按自己文档的实际情况调阈值。

配置写完后，用 skill-creator 把这个文件夹注册成 Claude Code 能识别的技能。skill-creator 本身也是一个技能，调用它的时候把 word-style 的路径传进去，它会读取 SKILL.md 并生成索引。注册成功后，你在 Claude Code 里输入word-style就能看到这个技能被激活。

4. 一键运行与格式前后对比验证

技能注册好之后，实际使用就三步。第一步，把要处理的 Word 文档放到一个固定目录，比如~/docs/input/。第二步，在 Claude Code 里输入指令：

word-style 处理 ~/docs/input/方案v3.docx

第三步，等脚本跑完。处理几十页文档大概需要一到两分钟，主要时间花在遍历段落和写入格式上。脚本跑完会在同目录生成方案v3_backup.docx和方案v3_styled.docx，原文件不动，方便你对比。

验证格式有没有刷对，别靠肉眼翻页，用命令提取关键属性对比。下面这段 Python 可以打印出文档里所有标题的字号和缩进：

from docx import Document doc = Document("方案v3_styled.docx") for i, p in enumerate(doc.paragraphs): if p.style.name.startswith("Heading") or (p.runs and p.runs[0].bold and p.runs[0].font.size and p.runs[0].font.size.pt > 14): size = p.runs[0].font.size.pt if p.runs and p.runs[0].font.size else "继承" indent = p.paragraph_format.first_line_indent print(f"[{i}] {p.text[:20]} | 字号={size} | 缩进={indent}")

跑一遍处理前的文档，再跑一遍处理后的，对比输出。正常情况下，处理前你会看到字号五花八门、缩进有的是 None 有的是具体值；处理后所有 heading1 应该统一成 16 号，heading2 统一 14 号，正文缩进统一为 2 字符对应的 EMU 值。

页眉页脚的验证稍微麻烦一点，因为它们在 section 对象里，不在 paragraphs 里。用这段代码检查：

from docx import Document doc = Document("方案v3_styled.docx") for s in doc.sections: header_text = "".join(p.text for p in s.header.paragraphs) footer_text = "".join(p.text for p in s.footer.paragraphs) print(f"页眉: {header_text} | 页脚: {footer_text}")

如果页脚显示为空但你在 Word 里能看到页码，别慌，页码是字段对象，python-docx 读出来是空的，打开 Word 看实际渲染效果就行。

实测下来，一份 40 页、原本格式混乱的方案，从输入指令到拿回排好版的文档，全程不到 3 分钟。其中脚本执行约 90 秒，剩下是模型理解指令和生成报告的时间。对比手动调格式动辄半小时起步，这个效率提升是实打实的。

5. 常见报错排查：401、local proxy failed 与 OAuth

接入和运行过程中最容易卡在几个固定报错上，这里按真实遇到的顺序列出来。

401 Unauthorized：这个基本是 Key 的问题。先确认ANTHROPIC_API_KEY填的是 TaoToken 控制台生成的 Key，不是其他平台的。然后检查 Key 有没有过期，控制台里能看到有效期。还有一种情况是 Key 复制时带了换行或空格，用echo $ANTHROPIC_API_KEY | wc -c看字符数对不对。

local proxy failed：这个报错通常出现在你本地配了代理但代理没起来，或者 Base URL 写成了https://taotoken.net/api/v1这种带多余路径的形式。先检查ANTHROPIC_BASE_URL是不是干净的https://taotoken.net/api，然后确认本地没有残留的代理环境变量干扰。如果你用的是 CC Switch，检查它有没有把配置写进正确的 profile。

Error reading choices / 返回体解析失败：这个多半是 Model ID 填错了。不同模型返回的 JSON 结构不一样，Claude Code 按 Anthropic 格式解析，如果你填了一个不兼容的 Model ID，返回体对不上就会报这个。回控制台确认 Model ID 拼写，别自己猜。

OAuth 相关报错：如果你用的是 Codex 风格的auth.json，里面可能有 OAuth 字段残留。Claude Code 走的是 API Key 模式，不需要 OAuth。把auth.json里 OAuth 相关的字段删掉，只保留 Base URL、Key、Model 三件套。CC Switch 用户注意检查切换配置时有没有把旧平台的 OAuth token 带过来。

脚本报 ModuleNotFoundError: No module named 'docx'：这是 python-docx 没装。跑pip install python-docx就行。注意包名是python-docx，但 import 的时候写import docx，这俩不一样，别装错了。

处理完文档打不开或提示损坏：大概率是脚本写入时把某个 XML 节点搞坏了。先看备份文件能不能打开，能打开就说明原文件没问题。然后检查脚本里有没有对paragraph_format的属性赋了非法值，比如缩进传了字符串。所有数值属性都应该是整数或浮点数。

排查顺序建议从外到内：先确认 API 链路通（能对话），再确认技能注册成功（输入技能名有反应），最后确认脚本能单独跑（不通过 Claude Code 直接python apply_style.py）。这样能把问题范围快速缩小到某一层。

6. 把排版技能沉淀成可复用资产

word-style 这个技能搭好之后，它的价值不在于处理了某一份文档，而在于你以后每份文档都能用。新文档来了，改一下rules/word-style.json里的字号规则，或者直接在 Claude Code 里说「把 heading2 改成 13 号」，让它更新技能配置，下次就生效。

如果你经常处理同类文档，比如周报、方案、标书，可以给每类文档建一个规则文件，共用同一个apply_style.py。技能目录里放多个 json，SKILL.md 里说明按文档类型选哪个规则。这样一套脚本能覆盖你所有排版场景。

再往上一层，你可以把这个技能和 Coding Plan 结合起来用。Coding Plan 适合长期、高频的编码和 Agent 任务，如果你每天都要处理文档、跑脚本、调规则，用 Plan 比按次调用更划算。模型对话入口适合临时验证某个模型对中文排版指令的理解效果，接入文档里有完整的参数说明。

最后留一个实用技巧：处理重要文档前，先拿一份副本跑一遍，确认格式符合预期再处理正式版。脚本虽然会自动备份，但备份文件和你手动另存的副本是两回事，多一层保险不亏。另外，规则文件建议用 git 管起来，每次调整字号缩进都提交一次，哪天改乱了能回滚。这套流程跑顺之后，几十页 Word 的排版确实就是输入一行指令、等两分钟的事。