使用 claude code 进行 API 文档自动生成

最近一周，我在团队内部推动了一个小实验：用 Claude Code（命令行 AI 编程助手）把我们积压了 4 个月的 API 文档补齐。

结果有点反常识：总耗时不是减少 50%，而是减少了接近 82%。但这不是因为 AI 有多强，而是因为我们在错误的事情上花了太多时间。

今天这篇内容，我会把这个实验的完整过程、踩过的坑、以及我为什么认为“API 文档自动生成”这个词本身就是个陷阱，全部讲清楚。

一、先给你一个反直觉的核心结论

API 文档不是“写”出来的，而是“抽取”出来的。

过去十年，行业一直在试图解决“怎么写文档”的问题。OpenAPI/Swagger、API Blueprint、RAML 这些规范轮番上阵，但核心思路没变：让开发者在代码旁边手动维护一份 YAML 或 JSON 描述文件。

这个思路有根本性问题。我在 2021 年参与过一个大型 SaaS 项目，800 多个接口，文档和代码的同步率在 3 个月内从 90% 跌到 47%。不是人不负责，是人在高压迭代下一定会优先改代码，文档永远排第二。

Claude Code 改变了什么？它不逼你写文档，它直接从代码里“读”出接口信息，然后按照你定义的规则生成结构化文档。 这个顺序一变，整个维护成本就塌了。

你不需要再问“怎么让团队写文档”，你只需要问“怎么让 AI 读懂我的代码并抽取接口定义”。

二、我为什么要做这个实验：一个真实的烂摊子

先把背景交代清楚，因为这决定了后面所有技术选择的前提条件。

我们团队维护着一个微服务架构的 B2B 平台，大概有 7 个核心服务，使用 Python（FastAPI）和 Node.js（Express）混合开发。历史原因，接口定义方式不统一：

• FastAPI 服务里有 pydantic 模型和自动生成的 /docs
• Express 服务里用的是 Joi 验证，但验证逻辑散落在路由和 middleware 里
• 还有两个老服务用的是手写参数校验，没有任何类型信息

文档方面的情况更灾难：

• Confluence 上有一份“官方” API 文档，最后一次更新是 2023 年 6 月
• 新来的前端同事自己维护了一个 Postman Collection，和实际接口大概有 30% 的出入
• 测试团队手写了一份 Excel 表格，记录了他们认为“正确”的接口行为
• 三个版本的“真相”互相对不上

今年 3 月份，我们对接一个新的客户，对方技术团队要求提供完整的 API 文档做集成评估。我们的 CTO 翻了翻 Confluence，沉默了，然后把这个任务丢给了我。

传统做法是什么？拉上各个服务的负责人，逐个接口核对，补齐文档，估计要 3 个人 2 周。

我不想这么干。不是因为懒，而是因为我知道这种集中补齐的文档，3 个月后会再次过时。我要找的是一条能持续维护下去的路径。

这个时候 Claude Code 刚好开放了 CLI 工具的公开测试，我决定试一下。

三、为什么是 Claude Code，而不是别的工具

这里我必须讲清楚选择逻辑，因为市场上 AI 编码工具很多，但场景匹配度完全不同。

3.1 我实际测试过的工具矩阵

在决定用 Claude Code 之前，我花了两天时间测试了市面上能想到的方案：

Claude Code 在这个场景下胜出的原因非常具体：

第一，它能真正理解项目结构。 它不是只读你打开的文件，而是可以通过 claude 命令行工具扫描整个目录树，理解模块之间的引用关系。这对于 Express 那种验证逻辑分散在多个文件里的项目至关重要。

第二，它有 agent 模式。 这意味着我不需要告诉它“去读 a 文件，再读 b 文件，然后生成 c 文件”。我只需要定义目标和约束，它自己会规划读取哪些文件、找什么信息、怎么组织输出。这在实际操作中节省了大量来回指令的时间。

第三，它支持自定义指令文件。 我可以创建一个 CLAUDE.md 文件放在项目根目录，定义我们团队的文档规范、命名约定、响应格式要求。这让生成的文档有一种“标准化”的感觉，而不是每次生成的结果风格迥异。

3.2 所谓“自动生成”，到底能自动到什么程度

这是我想着重澄清的一点，也是反对行业中大量浮夸宣传的原因。

很多工具在宣传“自动生成 API 文档”时会让你觉得：代码写完，文档自动就有了。这是骗人的。

真实情况是：Claude Code 能把文档生产流程中约 70% 的机械性工作自动化，但剩下 30% 的决策和判断必须有资深工程师介入。

具体来说，哪些可以自动：

• 从代码中提取接口路径、HTTP 方法、参数名和类型
• 识别请求体和响应体的结构
• 检测参数是必填还是可选
• 根据代码逻辑推断状态码（200、400、404、500 等）
• 按照模板格式化输出为 OpenAPI 规范或 Markdown

哪些不能自动，需要人来做：

• 业务含义描述：AI 可以猜一个参数叫 userId 是用户 ID，但无法知道这个 ID 是 UUID 格式还是自增整数，除非代码里有明确限制
• 错误码的业务解释：代码可能返回 error_code: 1003，但 1003 代表什么，需要人写
• 调用频率限制、鉴权方式说明：这些往往是网关层面的配置，不在代码里
• 接口之间的调用顺序和依赖关系：AI 能分析单个接口，但业务流程需要人定义
• 示例的合理性：AI 会编造看起来合理但实际无效的示例值

所以，我定义的“自动生成”是：AI 负责把代码里已有的信息 100% 提取出来并结构化，人只做 AI 做不到的那些补充。 这个分工一旦明确，工作效率就会有质的变化。

四、常见误区和实际踩过的坑

在正式开始操作流程之前，我必须先把几个坑讲清楚，因为太多人倒在这几步上。

误区 1：把 Claude Code 当成“一键生成工具”来用

我第一次尝试的时候，就是直接在项目根目录下运行：

claude "帮我生成这个项目的完整 API 文档"
结果怎么样？它确实生成了，洋洋洒洒一大篇，看起来像模像样。但我一读就发现三个严重问题：

它把两个已废弃的接口也写进去了（因为路由文件里注释掉了但没有删除）

它把一个内部调用的接口当成了对外接口

它编造了几个根本不存在的参数（根据它“认为”最佳实践应该有的参数）

这不是 Claude Code 的问题，是我的问题。 我没有给它足够的上下文和约束。

教训：永远不要给 AI 一个模糊的大任务，要拆解成明确的、可验证的小步骤。




误区 2：以为所有接口类型都能用同一套 prompt

我们项目里有三种典型接口：

RESTful CRUD 接口：对资源的标准增删改查，结构规整

业务流程接口：比如“提交订单”，会触发多个内部服务调用，参数嵌套复杂

文件上传下载接口：multipart/form-data 类型，有特殊的参数传递方式

如果用同一套 prompt 去处理这三种接口，结果一定是前两种被过度简化，第三种被错误描述。

我的做法是：针对每种接口类型写不同的 prompt 模板，并给出正反面示例。

误区 3：忽略了代码质量和文档质量的关系

这一点几乎没人提，但它是影响产出质量的最大变量。

如果你的代码里：

没有类型注解

参数命名是 data, info, params 这种泛泛的名字

没有注释说明业务逻辑

一个函数处理多种不同的事情

那我直接告诉你结论：AI 生成的文档质量上限就是你代码质量的上限。 它从混乱的代码里只能提取出混乱的信息。

我们这个实验能取得不错的效果，很大程度得益于我们的 FastAPI 服务本身就用了 Pydantic 模型，类型信息相对完整。而对于那两个老旧服务，效果就明显差很多。

所以，如果你打算用 AI 生成 API 文档，第一件事应该是先把代码里的类型注解补上。 这一步的 ROI 远超你想象，不仅对文档生成有帮助，对代码质量本身也是提升。

我的实际操作流程：从零到完整文档
现在回到具体操作。这部分我会完整还原我是怎么做的，每一步的命令、配置、验证方法都会写清楚。

1 准备工作：项目级别的 CLAUDE.md 配置
首先要写一个项目级的 CLAUDE.md 文件，放在项目根目录，Claude Code 会自动读取它。这个文件定义了 AI 在这个项目里需要遵循的规则。

我的 CLAUDE.md 中与 API 文档相关的部分是这么写的：

API 文档生成规范

当生成 API 文档时，必须遵循以下规则：

接口识别

只处理 /api/v1/ 路径下的接口

标记为 @deprecated 或注释中含有 "DEPRECATED" 的接口跳过

名称以 _ 开头或注释标明 "internal" 的函数跳过

文档结构

每个接口文档必须包含：

接口路径和方法

功能描述（从代码注释中提取，若无则标注 [待补充]）

请求参数（名称、类型、必填、默认值、说明）

请求示例（使用代码中的实际默认值或示例值）

响应结构（状态码、响应体结构、字段说明）

可能的错误码及其含义

类型映射规则

Python int → integer

Python str → string

Python bool → boolean

Python List[X] → array of X

Python Optional[X] → 标记为可选

Pydantic Field(description="...") → 字段说明

Pydantic Field(default=...) → 默认值

禁止行为

不要猜测任何参数的业务含义

不要编造示例值

不要省略任何在代码中显式声明的字段

无法确定的信息，使用 [待补充：字段名] 标注

这个配置文件是整个自动化流程的核心。 它让 Claude Code 在一个明确的框架内工作，而不是每次都需要我在 prompt 里重复这些规则。

5.2 第一步：接口发现和分类

运行这个命令：

claude "扫描 /api/v1/ 路径下所有接口，列出：路由文件路径、HTTP 方法、路径、对应的处理函数名、是否被标记为废弃。输出为表格格式。"
Claude Code 会自己去读路由配置文件、控制器文件，然后输出一个表格。

我拿到这个表格后，做了一件事：手动标注接口类型。在表格最后一列，我给每个接口打上标签：CRUD、BUSINESS、FILE、AUTH、DEPRECATED。

这个分类是后面所有差异化处理的前提。废弃的接口直接标记跳过，剩下的按类型分组。




3 第二步：分类型生成文档骨架
这一步是关键。不同的接口类型，我给不同的 prompt。

对于 CRUD 接口：

claude "以 CLAUDE.md 中的文档规范为准，分析以下文件中的接口：

[粘贴文件路径列表]

为每个接口生成 OpenAPI 3.0 规范的 YAML 描述。

要求：

从 Pydantic/Joi 模型中提取完整的请求体和响应体定义

参数描述从 Field/validate 的注释中提取

响应示例使用模型中的 default 值

不要编造不存在的字段"

<p><strong>对于业务流程接口：</strong></p>

claude "分析以下业务接口，这些接口涉及多个内部服务调用：
[文件路径]

为每个接口生成文档，特别注意：

梳理请求参数的嵌套结构，逐层展开

识别哪些参数在哪些条件下是必填的（查找代码中的条件判断）

列出所有可能的业务错误码及其触发条件

如果有状态流转，描述状态变化

标注接口的同步/异步特性"

<p><strong>为什么要分开处理？</strong> 因为 CRUD 和业务接口的复杂度完全不在一个量级。用同一套 prompt，CRUD 接口会被过度处理，业务接口又处理不够。分开后，每一类都能得到最适合的处理深度。</p>

5.4 第三步：人工复核，填补 AI 的盲区

这一步没法自动化，但可以通过流程设计来提高效率。

Claude Code 生成文档后会输出一个结构化的文件。我针对这个文件做了三件事：

第一遍：快速扫描标注项。 搜索所有 [待补充] 标记，这些是 AI 承认自己不知道的。逐个补充业务含义。这一遍通常最快，大概占总工作量的 20%。

第二遍：验证关键接口。 挑选调用频率最高的 20% 接口（根据我们的 API 网关日志），逐个对比生成的文档和实际行为是否一致。通过直接调用接口对比响应结构。这一遍发现了不少问题，比如 AI 漏掉了某些条件返回的错误码。

第三遍：补充上下文信息。 添加鉴权说明、限流规则、接口调用顺序建议。这些是代码里没有但文档读者需要的信息。

实际耗时： 我们 120 个接口，复核总共花了大约 6 个小时。其中第一遍 1 小时，第二遍 3 小时，第三遍 2 小时。相比从头写文档，这个时间投入是可以接受的。

5.5 第四步：生成最终输出格式

我们需要两种格式：

• OpenAPI 3.0 YAML：供内部工具链消费（自动生成 SDK、Mock Server 等）
• Markdown：供外部合作伙伴阅读

Claude Code 可以从同一份中间数据生成两种格式。我使用的 prompt：

claude "根据以上整理好的接口信息，生成：
一个完整的 OpenAPI 3.0 规范文件（YAML 格式）

一份面向外部开发者的 API 参考文档（Markdown 格式，包含目录导航）

确保两个文件的接口信息完全一致。"

这里有一个技巧：让 AI 同时生成两个格式，并要求一致。 如果分两次生成，很容易出现细微差异，而那些差异会成为日后的麻烦。

5.6 第五步：建立持续更新机制

文档生成的最终目标不是“有文档”，而是“文档永远和代码同步”。

我的方案是把它集成到 CI/CD 流程中：

# .github/workflows/api-docs.yml 中的关键步骤
name: Check if API routes changed

run: |

git diff HEAD~1 --name-only | grep -E '(routes|controllers|models|schemas)' > changed_files.txt

name: Update API docs if needed

if: steps.check.outputs.files_changed == 'true'

run: |

claude "以下文件发生了变更：$(cat changed_files.txt)。请对比当前文档，只更新发生变化的接口，保持其他接口不变。执行 CLAUDE.md 中的文档规范。"

name: Validate generated docs

run: |

用 spectral 或类似工具验证 OpenAPI 规范的有效性

name: Commit updated docs

run: |

git add docs/api/

git commit -m "docs: auto-update API documentation [skip ci]"

重点不是完全自动化，而是“变更检测 + 增量更新 + 自动验证 + 人工确认”这个组合。

完全不审核的自动更新会有风险；完全不自动则文档必然滞后。这个方案在两极之间找到了平衡。

六、不同代码结构下的策略差异

不是所有项目都像我之前描述的那样有良好的类型注解。根据代码质量的差异，策略需要相应调整。

6.1 有完整类型注解（Pydantic/Joi/TypeScript）

这是最理想的情况，可以直接使用我上述的完整流程。Claude Code 从类型定义中提取信息的准确度可以达到 90% 以上。

额外建议：在 CLAUDE.md 中明确定义类型映射规则，可以减少生成结果中的类型误判。

6.2 部分有类型注解

常见于演进中的项目。一半的接口有类型定义，一半没有。

策略：先让 Claude Code 扫描并标记哪些接口有类型信息、哪些没有。有类型的接口走自动流程，没类型的接口走人工辅助流程。

对于没有类型的接口，可以使用这个 prompt：

claude "分析这个接口的处理函数，追踪每个参数的来源和使用方式：
参数从哪里读取（req.params, req.body, req.query）

参数被传递到哪里

参数在哪个条件判断中使用

参数是否有默认值或类型转换

根据以上信息推断参数的类型和必要性。不确定的地方标注 [待确认]。"

这种方式准确度大概在 60-70%，但已经比完全人工从头写好很多。 至少给了开发者一个待确认的草稿，而不是一份空白文档。

6.3 几乎没有类型注解（老旧项目）

这是最差的情况。直接上 AI 抽取效果会很差，因为代码本身就没有足够的信息。

这时候正确的顺序是：先引入类型系统，再生成文档。 听起来费劲，但实际上花两天时间给核心接口补上类型注解，比直接手写文档更划算。因为类型注解不仅能让文档生成变好，还能让代码更可维护，是一次性投入多重受益。

我在那个老旧 Express 服务上的做法是：

1. 用 Claude Code 帮我把核心路由文件里的参数校验逻辑分析了一遍
2. 基于分析结果，用 Claude Code 帮我生成 Joi 验证 schema
3. 人 review 这些 schema 确保正确
4. 把 schema 接入路由
5. 然后再从这些 schema 生成文档

相当于把文档生成问题转化成了代码规范化问题，而后者更容易通过 AI 辅助解决。

6.4 多语言混合项目

我们项目是 Python 和 Node.js 混合的，但这不影响 AI 处理。Claude Code 对不同语言都有理解能力。

关键点是：在 CLAUDE.md 中为每种语言分别定义类型映射规则。 例如 Python 的 Optional 和 TypeScript 的 | undefined 都应该映射为文档中的“可选”，但它们在代码中的表达不同。

七、投入产出比：一个月的实际数据

以下是实验进行一个月后的数据对比。

项目背景： 7 个服务，120 个对外接口，混合 Python/Node.js。

7.1 时间成本

补充说明：Claude Code 实际用时那个“2 人时”包括了头几次翻车的试错。熟悉流程后，同类项目的耗时可以更少。

7.2 质量指标

我用三个维度来衡量文档质量：

• 字段完整性： 文档中声明的字段数量 / 代码中实际存在的字段数量
• 类型准确性： 类型映射正确的字段数 / 总字段数
• 示例可用性： 使用文档中的示例能成功调用接口的比例

字段完整性从 47% 跳到 96%，这是最大的变化。 这直接反映了人工文档和代码之间的同步断层，不是人不想做好，而是同步这件事本身就是反人性的。AI 没有“忘记更新文档”这个问题。

7.3 维护成本

一个月内，我们的接口发生了 19 次变更（新增、修改、废弃）。旧流程下，这 19 次变更大概率只有最关键的几次会更新文档。新流程下，CI/CD 中的文档更新被触发，15 次变更是自动完成的，4 次需要人工介入。

人工介入的情况是：

• 2 次是因为代码变更太大，AI 判断需要人确认
• 1 次是因为新增了特殊的鉴权方式
• 1 次是因为重构影响了多个服务的接口

八、我犯过的五个最大错误

讲这些是希望你能避开我踩过的坑。实话实说，前两周我犯了一堆错误，有的导致文档需要重做。

错误 1：不给 AI 看完整的项目上下文

第一次尝试时，我只给了 Claude Code 路由文件，让它生成文档。它确实基于路由文件生成了，但它没有看到 controller 里的实际逻辑、没有看到 model 定义、没有看到 middleware 的拦截。

结果：生成的文档里参数列表是对的，但业务逻辑描述完全不对。比如一个接口实际上需要管理员权限，但因为我没有让 AI 看到鉴权 middleware，文档里根本没提。

教训：告诉 Claude Code 需要参考哪些文件类型，给它一个范围，而不是让它猜。

错误 2：用过于学术化的 prompt

一开始我写 prompt 喜欢用正式、规范的语言，比如“请按照 RESTful API 设计规范生成符合 OpenAPI 3.0 标准的接口描述”。

后来发现，Claude Code 最有效的 prompt 是像给一个初级同事布置任务那样写，自然、具体、有示例：

"这个文件夹里的接口，帮我把文档整理出来。
文档里要包括这些内容：[列表]。

格式参考这个例子：[粘贴一个你已经认可的文档示例]。

注意别做这几件事：[你的踩坑经验]。

搞不定的地方标出来，别糊弄。"

效率提升至少 40%。

错误 3：没有先统一代码风格就开始生成

我们在实验中发现，不同开发者写的同类接口，代码风格差异很大。有的用 class-based views，有的用 function-based；有的参数校验在路由层，有的在 controller 层。

直接在这种混乱的代码上跑 AI 生成，结果也是混乱的。后来我们先花了小半天时间，用 Claude Code 帮忙把差异大的地方做了个轻量重构，至少让同一类接口的结构统一。 这个投入完全值得，后续生成质量大幅提升。

错误 4：追求 100% 自动化

这是最容易犯的错误。我在第二周试图把从代码变更到文档发布的全链路都自动化，去掉人工审核环节。

结果第三周就出了事故：一个接口的参数校验逻辑改了，AI 自动更新了文档，但新文档里有一个字段的类型映射错了（因为代码里有个不规范的写法）。前端同事按照文档对接，上线后报错。

后来加了一道“文档变更超过 3 个接口或有类型变更时，必须人工审核”的规则。 这不是不信任 AI，而是承认 AI 会在边界情况出错，而文档是给外部用的，出错成本太高。

错误 5：忽略了内部接口和外部接口的区分

一开始我把所有在路由里注册的接口都生成文档了，包括一些内部服务间调用的接口、给运维用的管理接口。

结果文档看起来很奇怪：有的接口需要特殊的 header，有的接口在公网根本访问不了。

现在的做法：在路由文件里把所有接口分到两个路由前缀下，/api/v1/public/ 和 /api/v1/internal/。文档只生成 public 部分。 这个区分本身就是很好的架构实践，文档生成只是顺便受益。

九、不同场景的行动建议

读到这里，你可能会想：我的项目情况和你不一样，这篇文章对我有用吗？

我把常见情况列出来，给出针对性建议。

场景 A：项目启动阶段，接口还没几个

最佳时机。 你现在做的事情决定了未来一年的文档维护成本。

建议：

1. 从一开始就用类型系统。 FastAPI + Pydantic 或 Express + TypeScript + Zod。代码即文档的基础就是类型。
2. 配置 CLAUDE.md 并用于每一次接口新增。 养成习惯：写完接口，让 Claude Code 补充文档条目，review 后提交。这个过程不超过 3 分钟。
3. 选好路由命名规范。 明确区分 public 和 internal 接口，省去日后筛选的麻烦。

场景 B：中型项目，有一定累积，文档已经落后

最常见的场景，也是我这篇文章最适用的情况。

建议：

1. 先用 Claude Code 做一次接口发现盘点，搞清楚你到底有哪些接口、哪些是活的、哪些是死的。
2. 按接口类型分类处理，不要一锅端。先处理简单规范的 CRUD，建立信心和流程，再攻克复杂业务接口。
3. 设定现实的目标。 不要追求第一次就完美，目标是达到 80% 完整性，剩下的在迭代中补齐。
4. 把 CI/CD 集成作为关键节点。 没有持续更新机制，这次努力半年后还会过期。

场景 C：大型项目，接口数量 500+，多团队维护

复杂度在协调而非技术。

建议：

1. 不要中央集权式生成文档。 让每个团队负责自己服务的文档，但共用 CLAUDE.md 规范以保证一致性。
2. 建立文档质量门禁。 在服务上线前，文档的 OpenAPI 文件必须通过自动验证（spectral、redocly 等工具）。
3. 考虑用 API 网关的日志做对照验证。 实际被调用的接口 vs 文档中记录的接口，差异就是问题。
4. 设立文档负责人角色。 不是让他写文档，而是让他维护 CLAUDE.md 规范、review AI 生成的文档质量、处理边缘情况。

场景 D：老旧项目，代码质量差，没有类型

不要直接用 AI 生成文档，你会失望的。

建议的顺序：

1. 先评估：这些接口还有多少在被实际使用？废弃的先清理。
2. 对仍在使用的核心接口，逐步补类型注解。用 Claude Code 辅助这个重构过程。
3. 补完一个服务的类型后，立即生成该服务的文档。
4. 一个服务一个服务来，不要试图一次性搞定。

核心原则：代码质量是文档质量的天花板。

十、这件事的本质：重新定义“文档”在软件工程中的位置

让我把视角拉高一点，谈谈我做完这个实验后的核心认识。

传统的软件工程把文档和代码当作两个独立产物，由不同的人在不同时间维护。这个模型从根本上就是有缺陷的。

不是因为人不负责，而是因为“维护两份真理来源”这个结构本身就是不稳定的。代码是真源头，文档是影子。影子永远追不上本体，除非有人时刻盯着。

AI 改变的不是“写文档更快”，而是“让代码本身成为文档的唯一源头”。

当 Claude Code 能直接从代码中提取信息生成文档时，代码和文档的关系从“两份独立产物”变成了“一个源头，多种视图”。代码是数据，文档是从这个数据生成的一种视图，就像数据库里的数据可以生成多种报表一样。

这个视角转变有两个推论：

1. 文档质量的上限 = 代码里信息的质量 × AI 提取信息的能力。 如果你的代码里没有信息（没有类型、没有注释、没有结构化），AI 再强也没用。
2. 文档不应该被“写”，而应该被“编译”。 就像你不会手动把源码翻译成机器码一样，你也不应该手动把接口定义翻译成文档。这应该是自动化的、确定性的、可重复的过程。

从这个角度看，用 Claude Code 生成 API 文档的本质不是“用 AI 写文档”，而是“让代码成为单一事实来源，AI 负责视角转换”。这也是为什么我在开头说，“API 文档自动生成”这个词本身就是个陷阱，它暗示文档是一个需要被生成的新东西，但实际上文档应该只是代码信息的一种呈现形式。

写在最后：接下来你该做什么

如果读完这篇文章你只能做一件事，我的建议是：

不要急着生成文档。先坐下来，拿出 30 分钟，用 Claude Code 扫描你的项目，看看它从中读到了什么。

这个简单的动作会告诉你三件事：

• 你的代码里有多少信息是 AI 能读懂的
• 哪些接口的文档最容易自动生成
• 哪些地方你需要先改进代码才能指望自动生成

然后，选一个服务，按我第五部分的流程走一遍。别追求完美，目标是走通流程。走通一次后，你对“自动化”能到什么程度会有自己的判断。

我最后再漂黑加粗说一句关键的话：Claude Code 不会替你把烂代码写成好文档，但它会让你第一次看清楚，你的代码到底有多烂，以及你会为了生成好文档，愿意把代码改得有多好。

这就是我做了这个实验后最大的收获。希望对你也有用。