企业官网建设流程全解析

昨天飞书CLI在GitHub上开源，朋友圈里好几个朋友都在转。我用了一个下午加一个晚上，把飞书CLI和Claude Code搭在一起，把公众号写作这件事从头到尾自动化了一遍。以前一篇技术博客从定题到成稿要折腾三小时，现在从选题库里挑题、拉素材、让AI起草初稿、脚本整理格式、同步到飞书云文档，最后粘进公众号后台，整套流程压缩到一小时以内。今天这篇就完整复盘一下我的工具选择、每个环节的实操细节，以及踩过的坑。

这套方案适合谁？主要是那些要稳定产出公众号文章，又不想整天在两个软件之间来回复制粘贴的人。不管你是技术博主还是做行业分析的运营，只要写作流程里牵扯到选题管理、素材沉淀、格式转换、文档协同，这套“飞书CLI + Claude Code”的组合都能大幅减少重复劳动。如果你暂时不写公众号，只看思路也能get到一套做内容自动化的通用框架。

1. 飞书CLI开源：它到底解决了什么问题

1.1 飞书CLI是什么，为什么值得关注

很多人第一次听到“飞书CLI”会以为它是飞书客户端的命令行版本，其实完全不是一回事。飞书开放平台提供了一整套HTTP API，可以在程序里操作云文档、多维表格、消息、审批流这些资源，但这些API要自己拼接请求、维护Token、处理分页，用起来很麻烦。开源的飞书CLI等于把这些API封装成了终端命令，安装之后，在终端里敲几条命令就能完成创建多维表格、更新记录、创建云文档、导入Markdown文件这些操作，写脚本、做自动化都非常顺手。

这次“开源”的意义，比单纯多了一个工具要大得多。以前飞书生态的自动化，大多靠开发者自己读API文档、写一次性脚本，加上一些社区维护的第三方包，更新不及时，出了问题也没人管。官方把CLI开源出来，等于把自动化能力底座开放了，你能直接看源码，搞清楚Token是怎么处理的、请求是怎么重试的，遇到不满足的场景甚至可以提PR改逻辑。对内容创作者来说，这意味着那些重复性的整理、搬运、同步工作，终于可以放心交给脚本了，而不是每次都在心里嘀咕“这个第三方工具会不会哪天跑路”。

1.2 为什么选“飞书CLI + Claude Code”这个组合

我做这套方案的时候，其实也考虑过直接用飞书网页端加浏览器插件，或者干脆全用Notion一类的工具。但仔细拆了一遍公众号写作的痛点之后，发现“飞书CLI + Claude Code”这个组合刚好打在核心问题上。

公众号写作最繁琐的有三层。第一层是素材的收集和沉淀，灵感一来，今天记在微信收藏，明天粘到手机备忘录，后天又拍了一张截图，到真要写的时候翻遍各个App都找不齐。第二层是成稿过程中的反复修改，改标题、调逻辑、补例子，每一次改动都要在文档里来回折腾。第三层是格式和平台适配，写好的Markdown要变成公众号后台能用的格式，图片要处理，代码块要调样式，这些活重复性极高。

飞书CLI解决第一层和第三层。多维表格天然适合做选题库和素材池，云文档适合写作过程中的协作确认，脚本能做格式转换和同步这些第二层之外的体力活。Claude Code解决第二层。它不是只能写代码的编程助手，让它根据素材起草初稿、扩写段落、换语气、起标题，效果都不错，而且可以通过Skill和配置文件约定公众号的写作规范，输出稳定度比每次重新描述需求强得多。两者一配合，整个流程就从“人追着工具跑”变成了“脚本推着内容走”。

2. Claude Code 环境准备与基础配置

2.1 安装Claude Code：推荐npm方式与验证步骤

如果你对Node.js不陌生，直接用npm全局安装是最省事的。终端执行：

npm install -g @anthropic-ai/claude-code

装完之后敲claude --version，能正常输出版本号就说明安装成功。首次使用直接运行claude，它会进入一个交互式终端，并引导你完成OAuth登录授权。我用的是浏览器授权方式，页面里点一下同意，终端环境就自动保存了凭证，之后在同一台机器上使用不需要反复登录。

这个环节有两个小坑值得提前说。第一，claude这个命令有可能和你机器上其他程序重名，装完发现命令不对，先执行which claude看路径，确认指向的是预期安装目录。第二，npm全局安装的版本如果太旧，启动时可能会提示升级，直接跑一遍npm update -g @anthropic-ai/claude-code就好。另外，如果你平时主力编辑器是 VS Code，也可以直接在它的终端里跑claude，这样AI生成的内容和项目文件在同一窗口，上下文切换成本会小很多。

2.2 模型接入：默认官方API与兼容端点切换

Claude Code默认调用Anthropic官方接口，需要有对应的账号和登录态。如果你暂时不方便走官方通道，它支持通过环境变量切换API端点。这种方式在社区里已经验证过很多次，我自己的环境里也跑了一段时间，稳定性够用。还是以目前很多人在用的DeepSeek兼容端点为例：

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKEN=sk-你的DeepSeek密钥

配置完启动claude，请求就会发到对应端点去。除了DeepSeek，其他兼容Anthropic协议的网关服务也是同样的玩法，只需要改掉ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN两个变量。

切换端点之后有几件事必须提醒。不同模型的能力边界差异很大，写代码和写文章的水平不一定均衡，建议开始正式写作前先让它生成一篇短文看看语感。如果某个请求一直超时或报错，先检查环境变量在当前Shell会话里有没有生效，我遇到过好几次改完.bashrc但没source，导致新终端一直用旧配置的情况。还有，不要把密钥硬编码进项目文件然后提交到Git仓库，用环境变量或者系统的密钥管理工具，避免泄露。

2.3 Skill机制：把公众号写作规范“教”给Claude Code

Claude Code有一个很强大的能力：Skill。你可以把它理解为一组预设操作流程，当对话任务触发对应场景时，Claude Code会自动加载这个Skill，并按照里面写好的规则执行。公众号写作规范很固定，标题怎么起、段落多长、能不能用表格、代码块怎么展示，这些都能沉淀成一个Skill，一劳永逸。

Skill默认存放在用户目录下的.claude/skills文件夹里，每个Skill是一个独立目录，目录里放一个SKILL.md文件。我配置的公众号写作Skill长这样：

~/.claude/skills/ └── wechat-article/ ├── SKILL.md └── style-guide.md

SKILL.md的头部用YAML写技能的元信息，正文写执行流程，示例：

--- name: wechat-article description: 当用户需要撰写、润色或排版微信公众号文章时，使用此技能 --- 1. 先根据讨论结果确定文章的核心观点和主要结构 2. 使用 style-guide.md 中的风格规范约束全文表达 3. 正文使用 Markdown 格式输出，每个三级标题下分3到5个段落 4. 段落长度控制在4到6行，避免大段堆砌 5. 关键专业术语首次出现时用加粗标注

实际体验下来，有了Skill之后输出质量的稳定度提升非常明显。没配Skill之前，每次都要把写作规范完整描述一遍，而且它写着写着容易跑偏。配好之后，你只需要说“开始写一篇关于XXX的文章”，后续所有输出都会自动套用规范，省下的心力和时间非常可观。

3. 用 Claude Code 打通公众号写作全流程：六个环节实操

3.1 整体流程设计：从选题到发布，让脚本接管搬运工

动手之前，我先把公众号写作的完整流程拆了一遍，最后分成六个环节：选题登记、素材收集、正文起草、格式整理、文档协同、发布准备。每个环节都有明确的工具和输出物，环节之间靠脚本和命令衔接。

第一环是选题登记，用多维表格做选题库，把所有灵感集中记录在一个地方。第二环是素材收集，同样用多维表格的字段把相关链接、摘要、图片统一管理。第三环是正文起草，Claude Code在本地项目目录里根据素材生成初稿。第四环是格式整理，脚本把Markdown里的图片路径、标题层级、代码块标注全部规范化。第五环是文档协同，通过飞书CLI把文章同步到云文档，方便手机阅读和发给同事确认。第六环是发布准备，将最终内容转成公众号后台能接受的格式，人工检查后发布。

这个流程里最核心的思想是：让擅长思考的负责思考，让擅长搬运的负责搬运。Claude Code负责内容生成和初步校对，飞书CLI负责数据读写和文档同步，两边各管一摊，中间用本地脚本串起来，人就只需要在每个环节之间做判断和决策。

3.2 用多维表格搭建选题库：字段设计与命令实操

飞书多维表格本质上是一个轻量数据库，比Excel灵活，又比专门的数据库简单，做选题库再合适不过。我用飞书CLI建了一张选题管理表，字段设计如下：

实际操作时，先用CLI登录飞书账号：

feishu auth login --app-id <你的App ID> --app-secret <你的App Secret>

登录成功后创建一个新的多维表格：

feishu bitable create --name "公众号选题库" --folder "写作空间"

执行完，CLI会返回表格的app_token和默认数据表的table_id，这两个ID后面所有读写操作都离不开，建议记录到本地配置文件里。接着按字段设计建列，每个字段对应一条更新命令，把类型参数传进去即可。

跑通这一个环节之后，选题登记这件事就从“打开网页点半天”变成了“终端一条命令搞定”。更进一步，配合Claude Code你甚至可以直接说“帮我把这条灵感录进选题库”，它会自动拼好命令并执行，真正做到了只动嘴不动手。

3.3 起草正文：配置CLAUDE.md与提示词模板

素材备好之后，进入核心的正文起草阶段。为了让Claude Code生成的内容贴合公众号风格，我在每个写作项目目录下放一个CLAUDE.md配置文件，相当于给AI一份本次写作的背景简报。比如这次技术文章的项目配置：

# 项目背景 面向公众号读者，主题是自动化公众号写作流程。 # 输出要求 - 使用 Markdown 格式 - 标题层级清晰，段落短小 - 多写实操细节，少写空泛总结 - 每节至少一个实际命令或步骤 - 禁止“随着...的发展”这类AI套话

配置好之后启动Claude Code，我用一套固定提示词模板开始任务：

请基于选题库中的素材，为公众号写一篇技术文章。 主题：彻底讲清楚飞书CLI开源的用途，以及如何用Claude Code自动化公众号写作。 要求：先列大纲，我确认后再生成全文。

它会先把大纲列出来，我确认逻辑没跑偏，再让它逐段展开。这里我的习惯是不要让它一口气输出全部内容，而是分段生成，一节一节来。分段生成的好处很多：每段风格更容易把控，中途调整方向成本低，而且不容易触发API限流。Claude Code有上下文记忆能力，你在对话中提过的修改要求，后续生成会自动延续，这在长文写作里很省心。

草稿生成之后，我通常还会让它自己检查一遍，看有没有重复表述、段落是否过长、标题是否覆盖核心观点。整个写稿过程都在终端里进行，不用来回切浏览器，注意力集中了很多。

3.4 Markdown整理与飞书云文档同步：脚本自动化

草稿出来之后，有一件事很多人都会忽略，就是格式整理。Claude Code输出的Markdown结构清晰，但直接贴到飞书或者公众号后台，图片链接、代码块、列表的兼容性经常出问题。我写了一个简单的Node.js脚本专门做三个处理：把本地图片路径替换成图床地址，确保标题层级不跳级，给所有代码块标注语言类型。

const fs = require('fs'); const content = fs.readFileSync('article.md', 'utf8'); // 1. 替换图片路径为图床地址 // 2. 规范化heading层级 // 3. 确保代码块语言标注完整 const formatted = content .replace(/!\[(.*?)\]\(\.\/assets\/(.*?)\)/g, '![$1](https://cdn.example.com/blog/$2)') .replace(/^###### /gm, '### ') .replace(/```([a-z]*)\n/g, (m, lang) => '```' + (lang || 'text') + '\n'); fs.writeFileSync('article-formatted.md', formatted);

看起来简单，但省掉的手工调整量很大。格式整理完，再用飞书CLI把文章导入云文档：

feishu doc import --title "《飞书CLI + Claude Code打通公众号写作全流程》" \ --file ./article-formatted.md \ --type markdown \ --folder "写作空间"

导入完成后CLI会返回一个文档链接。把这个链接发给同事，对方在飞书里直接看、直接评论，比之前发文件、截图来回沟通高效太多。我以前用网页端手动粘贴Markdown再慢慢调样式，现在这一步基本是秒级完成。

3.5 发布准备：从草稿箱到公众号后台

公众号后台本身有开放接口可以把内容导入草稿箱，但个人开发者的权限申请流程偏长，所以我最后的发布走的是“半自动”路线：飞书云文档解决协作确认，最终粘贴动作留在公众号后台完成。虽然是手动粘贴，但Claude Code在其中起了一个关键作用：把最终确认好的Markdown转成适合公众号后台的排版格式。

我在Skill里追加了一个转换规则，Claude Code会按照规则处理标题加粗、引用块样式、列表格式，转换完的内容粘贴到公众号后台的“新建图文素材”页面，基本不需要再调整。预览一遍，确认样式没问题，点发布就行。

整套流程跑完，我的体感是：真实的工作量集中在“读懂素材”和“构思逻辑”上，搬运和格式调整几乎全被脚本和AI消化掉了。以前写一篇带代码块的技术文章，光在格式上折腾的时间就够写几百字正文了，现在这部分完全不需要操心。

4. 实操中的常见问题与排查技巧

4.1 飞书CLI接入时最容易踩的三个坑

权限配置不全是最常见的问题。飞书开放平台的每个应用都要配置API权限，也就是Scope，CLI调用哪个接口就需要对应的权限。我第一次创建多维表格时报权限错误，原因就是应用只开通了“查看文档”权限，没开“创建多维表格”。排查方法是看报错信息里给出的Scope名称，去开发者后台补上权限，等生效之后再重试。

Token类型混用是第二个高频坑。飞书CLI登录时会区分租户身份和用户身份，租户Token适合操作应用自身资源，用户Token代表真实用户身份，能访问个人空间里的文档。纯自动化脚本建议用租户Token，涉及个人文档和协作功能时用用户Token，两者分开配置。混在一起容易出现“明明有权限却报401”的诡异问题。

多维表格字段类型写错也很常见。CLI建表时字段类型传的是字符串常量，比如TEXT、SINGLE、MULTIPLE，大小写不对就直接失败。这个问题看起来初级，但确实容易发生，尤其是有数据库经验的人容易习惯性写成数据库字段类型。出错时对照官方文档里的枚举值检查一遍就能解决。

4.2 Claude Code日常使用中的几个问题

对话历史保存方面，Claude Code默认会在本地保留对话记录，但换机器或重装系统后历史不会自动同步。我现在的做法是把工作目录纳入Git管理，重要写作会话结束后提交一次，需要回顾时翻Git历史就行。如果你有长期跟踪某个系列文章的习惯，这个方式很实用。

环境变量不生效是另一个高频问题。配置了ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN，但启动后还是走的默认端点，多半是当前Shell会话没有加载最新配置。改完.bashrc或.zshrc后执行source ~/.zshrc，或直接新开一个终端窗口，问题基本就解决了。

API限流与配额也是必须面对的。官方API的限流策略比较严格，短时间请求过多会触发限流提示。我的经验是长文写作不要一次生成整个章节，分段生成既不容易触发限流，输出质量也更高。用第三方兼容端点时同样要留意服务商的速率限制，批量任务之间加一点延时，降低并发。某次深夜赶稿我就撞上过配额限制，当时提前备好了另一个API密钥，切换之后才没耽误事。

4.3 提升文章质量的三个独家技巧

第一，给Claude Code建一个“金句库”。把自己过去写得最好的开头、结尾、过渡句整理成一个文本文件，放在项目目录里，让它生成内容时参考这些句子的节奏和语感。这种做法会让AI模仿你个人的表达习惯，而不是生成一种放之四海而皆准的“AI普通话”。

第二，把写作任务拆细。别让它一口气写三千字，而是“先写标题和摘要”“再写第一部分”“再写第二部分”，每个环节单独确认。这样它不会写到一半跑偏，你也每步都能及时纠正方向，长文质量比一次性生成高很多。

第三，让Claude Code先反问你。正式写正文之前，让它基于主题提两三个关于目标读者、文章风格、内容侧重的问题，你回答完它再动手。这个方法看起来多了一步，但效果出奇地好。因为它多了一个理解意图的环节，生成的内容跟你的预期差距会明显缩小，返工率大幅下降。

就像我在配置文档里写的，真正的写作能力还是你自己的判断力和审美。工具能帮你把格式整理到完美，把初稿生成到七八十分，但最后那二十分的关键决策，比如结构怎么调整、例子怎么取舍、结尾怎么收，还是需要你亲自把关。这套流程跑了一个多月，我的体会是：花时间把流程拆细、把工具配置好，远比每次临时拼凑命令更值得。飞书CLI开源之后，能玩的自动化场景远不止公众号写作，定时把多维表格数据推送到群聊、自动归档过期文档、把外部表单信息同步到知识库，这些我都在陆续尝试。如果你想做类似的自动化，我建议先挑一个最小场景跑通，比如就先建一张选题表，跑顺之后再往里加环节，迭代着来反而比一次性搭大而全的系统更稳。