claude code 生成 API 接口文档的完整流程记录

别急着打开 Claude Code 就把整个项目扔进去。如果你跟我一样，曾天真地认为 AI 可以一键生成完美的 API 文档，那么结果基本是：第一次生成的文档看起来像模像样，一旦你仔细看参数类型、状态码、业务描述，就会发现一堆幻觉数据、拼凑的错误码、以及完全脱离业务场景的示例值。

我在过去三个月里，用 Claude Code 为两个后端项目生成了累计超过 200 个接口的文档，踩过的坑足够写出一本小册子。这篇文章不是告诉你"AI 多好用"的推广软文，而是一次完整的流程记录，包括那些几乎没人讲的失败案例、Prompt 调校过程、批量生成时的上下文衰减问题，以及最终如何建立一套人机协同的文档生成标准。

读完这篇文章，你能得到的不是一段 Prompt 模板，而是一套可以立即用在生产项目里的完整工作流。

一、先给你一个核心结论：AI 生成 API 文档的"80% 定律"

在我完成的所有 API 文档生成任务里，有一个反复出现的规律，我把它称为"80% 定律"：

Claude Code 可以在极短时间内完成 80% 的模板化文档工作，但剩下 20% 的关键业务描述、安全注释和边界条件处理，必须由人来主导。如果你试图用 AI 覆盖那 20%，最终的修正成本会超过从零手写。

具体到数据上：

这个数据来自我自己的项目记录，不是凭空编造。我在 2025 年 Q1 到 Q2 期间，记录了两个项目的文档生成准确率。第一个项目是电商后台管理系统，41 个接口，平均复杂度中等；第二个项目是数据中台的 API 网关层，163 个接口，从简单到极复杂都有。

核心洞察：复杂度和 AI 生成准确率呈非线性负相关。 当接口的业务逻辑超过一定阈值（比如需要理解"订单状态流转"或"多角色权限映射"），AI 的理解能力会急剧下降。这不是 Claude Code 的问题，而是大语言模型在处理需要深度业务上下文时的通病。

这意味着什么？不要抱着"让 AI 替代人工写文档"的期待去用 Claude Code，而应该抱着"AI 负责模板，我负责灵魂"的心态。 这个定位清晰之后，你才能设计出合理的流程。

二、我为什么会开始用 Claude Code 生成 API 文档

说到动机，可能和大多数后端开发的痛点一样。2025 年春节后，我们团队接了一个紧急项目：两周内要把一个旧电商系统的核心接口重构并迁移到新的微服务架构上。40 多个接口，80% 是遗留代码，原文档要么缺失要么是 2019 年的版本。

我当时面临的状况是：

• 旧的 Swagger 文档中，大约 30% 的接口参数和实际代码对不上
• 有 12 个接口完全没有任何文档记录，只在代码注释里有零散说明
• 产品经理要求新版本上线前必须提供"面向第三方开发者的标准化 API 文档"
• 团队只有 3 个人，其中 1 个是实习生

如果纯手写，按照我过去的速度：一个中等复杂度的接口，从读代码、理逻辑、写参数描述、补示例、校格式，平均需要 45-90 分钟。41 个接口就是 30-60 小时的工作量。在两周内完成重构加文档几乎不可能。

我之前用过其他 AI 工具生成过零散的代码注释和简单文档，效果参差不齐，经常出现"看着都对，一测就错"的情况。但 Claude Code 在处理长上下文代码分析方面的表现让我想试一把。我决定拿出一整天时间来测试：如果效果好就全面采用，如果不行就老实手写。

测试结果让我既兴奋又头疼。兴奋的是，一个简单的用户信息查询接口，从我把代码贴进去到生成合格的 Markdown 文档，只用了不到 8 分钟。头疼的是，一个包含多角色权限判断的订单操作接口，Claude Code 第一次生成的文档把"管理员"和"商家"的权限完全搞混了。

三、准备工作：在打开 Claude Code 之前必须搞定的三件事

经历过最初几次惨痛的失败后，我总结出一个铁律：生成质量不是从 Prompt 开始的，而是从代码结构和文档规范开始的。

3.1 代码规范性直接影响生成准确率，最高可差 3 倍

我用两个接口做过严格对照实验。两个接口的业务复杂度基本一致，都是商品模块的 CRUD 操作：

• 接口 A：代码里有清晰的 Pydantic 模型定义、完整的类型注解（Type Hints）、每个函数都有 docstring 注释
• 接口 B：代码能跑，但使用了原生 dict 代替 Pydantic、没有类型注解、注释只有零星几行

我把两个接口的代码分别输入 Claude Code，使用完全相同的 Prompt，然后对比生成结果：

结论非常明确：如果你打算用 AI 批量生成文档，先花时间把代码里的类型注解和 docstring 补齐，这笔投资的回报率极高。

具体标准：

• Python 项目：使用 Pydantic 或 dataclass 定义所有请求/响应模型；函数必须添加类型注解；每个 API 处理函数的 docstring 至少包含一句话的功能描述
• TypeScript/Node.js 项目：使用 interface 或 type 定义参数结构；JSDoc 注释覆盖所有接口处理函数

我在第二个数据中台项目上验证了这个规律。那个项目一开始接入了一个第三方服务的代码，注释率不到 10%。我花了两天时间补齐了核心接口的类型定义和注释，结果后续的文档生成效率提升了近一倍，修正时间从每个接口平均 15 分钟降到 7 分钟。

3.2 定义文档标准格式，不是所有项目都适合用 Markdown

这是另一个常见误区。很多教程会教你"用 Claude 生成 Markdown 格式的 API 文档就好"。但实际情况是，文档格式必须和团队的协作工具链挂钩，随便选一个格式会让后续维护成本翻倍。

我经历过三种不同的文档需求场景：

我第一次做电商项目时，想着 Markdown 最通用就让 Claude 生成了 .md 文件。结果产品经理问："能不能导入到 YApi 里？我想在线调试。"我不得不又花了一整天把 41 个 Markdown 文档手动转换成 OpenAPI 格式。这个教训值 6000 块钱（按我的日薪算）。

在写 Prompt 之前，先确定你最终要交付的格式标准。 OpenAPI 3.0 是目前兼容性最好的选择。Claude Code 对 OpenAPI 格式的支持很好，只要你在 Prompt 里说明需要"符合 OpenAPI 3.0 规范的 JSON/YAML"，它生成的结构基本可以直接使用。

3.3 代码分块策略：一次喂太多代码，AI 的准确率会断崖式下降

Claude Code 的上下文窗口虽然很大（官方宣称支持超长上下文），但在实际使用中我发现：当单次输入的代码超过约 800-1000 行（或 token 数超过一定阈值），生成文档的准确率会出现明显的边际下降，尤其在处理中间部分和末尾部分的业务逻辑时。

我在数据中台项目上做过测试：

• 一次输入 1 个接口的完整代码（约 200 行）：准确率约 88%
• 一次输入 3 个相关接口的代码（约 600 行）：准确率约 82%
• 一次输入 8 个接口的代码（约 1500 行）：准确率降到约 68%，且中间几个接口的描述明显更粗糙

所以，不要图省事一次性把整个模块的代码全扔进去。合理的做法是按功能模块拆分，每次最多处理 3-5 个紧密关联的接口。 对于复杂的接口（如订单全流程处理），建议每个接口单独处理。

四、实战流程：从一个订单管理接口的生成全过程说起

下面是我记录的一个完整案例：为电商后台的"订单退款处理接口"生成文档。这个接口不简单也不复杂，属于中等偏上复杂度，能很好地展示标准流程。

4.1 第一步：准备输入材料

我不会直接把整个 .py 文件复制粘贴到 Claude Code。我先做了几件事：

1. 找到接口对应的路由注册代码和视图函数
2. 确保函数有完整的类型注解（这个项目我提前规范过，所以这步很快）
3. 查看相关的 Pydantic 模型定义，确保它们也在输入上下文中
4. 准备一份简短的业务背景说明（用注释写在代码前面）

最终的输入结构是这样的：

# 业务背景：这是订单退款接口，用户发起退款申请后由系统审核
关键业务规则：

仅"已支付"或"已发货"状态的订单可退款

退款金额不能超过实际支付金额

需要验证操作人权限（仅管理员或该订单所属商家）

退款成功后触发库存回退和账务流水

#

需要生成的文档格式：OpenAPI 3.0 JSON

请标注出所有异常状态码和对应的业务含义

[这里粘贴完整的代码：

Pydantic Request/Response 模型

路由函数及其装饰器

涉及的工具函数和状态枚举]

注意那个业务背景说明的重要性。 早期我没加这段时，Claude 经常在状态码描述里写"参数错误"这种模糊表述，因为 AI 根本不知道实际业务规则是什么。加上业务规则后，它能生成"400：订单状态不符合退款条件，仅已支付或已发货状态可退款"这种精确描述。

4.2 第二步：第一轮生成与格式化检查

第一轮 Prompt 我通常这样写：

> 请为以下代码生成符合 OpenAPI 3.0 规范的 API 文档（JSON 格式）。

> 要求：

> 1. 从代码的类型注解和 Pydantic 模型中提取参数类型、必填/选填

> 2. 根据提供的业务规则生成准确的状态码描述

> 3. 为每个字段生成合理的示例值（不要编造不存在的业务数据）

> 4. 如果有权限校验，在 description 中明确标注

> 5. 生成的 JSON 必须是可直接导入 Swagger Editor 的标准格式

第一轮生成结束后，我会立即用三个快速检查来评估质量：

检查 1：参数类型的准确性。 我会随机抽 3-5 个字段，对照代码中的类型定义看是否完全匹配。这是最容易出问题的地方，尤其当代码使用了 Union 类型或泛型时。

检查 2：状态码的完整性。 我会看接口函数里所有的 HTTPException 或 abort 调用是否都被映射到了文档里。经常漏掉的是 403 权限拒绝和 429 限流。

检查 3：示例值是否合理。 这个检查容易被忽略但非常重要。Claude 有时会编造看起来很真但完全不符合业务逻辑的示例值。比如退款金额写"99.99"但实际系统里退款只支持整数。这种情况如果不及时修正，对接方看到文档后会产生大量误解。

4.3 第三步：两轮精细调校，我踩过的三个典型坑

经过第一轮检查后，我通常会进行两轮针对性修正。以下是我反复遇到的三个问题以及解决思路。

坑 1：权限逻辑描述不完整

Claude 能从代码中读到 requires_role 这样的装饰器，但很难自动理解"这个接口允许管理员操作本人权限范围内的商家数据"这种多层级权限关系。第一版生成的文档通常是模糊的"需要管理员权限"，这在实际对接中会出大问题。

解决思路： 不能在 Prompt 里只写"请生成权限描述"，必须在输入材料里显式写出权限矩阵的逻辑规则。我的做法是写一段类似这样的注释：

# 权限规则说明：
系统管理员可操作所有商家的退款

商家管理员仅可操作自己的订单

普通客服可查看但不可执行退款（只有 POST 需要鉴权，GET 不需要）

</li></ol><p>加入这种精确描述后，Claude 生成的文档就能区分不同接口方法的权限要求了。</p>

坑 2：嵌套模型的字段展开不完整

当一个 Request Body 里包含了多层嵌套的 Pydantic 模型时（比如 OrderRefundRequest 里面嵌套了 RefundItem 列表，RefundItem 又嵌套了 ProductInfo），Claude 有时候会只展开到第一层，深层字段被合并成一个笼统的 object 类型。

解决思路： 在 Prompt 里加一句明确指令："请递归展开所有嵌套模型，直到所有字段都是基础类型或枚举值。不要省略任何层级。" 同时，如果嵌套层级超过 3 层，建议分步生成，先让 Claude 生成外层结构，再逐层级补全。

坑 3：Markdown/OpenAPI 格式混用导致编辑器报错

这是新手最容易踩的坑。有时你让 Claude 生成 OpenAPI 格式，但它会在描述字段里混入 Markdown 语法（比如用 粗体 或换行符），导致 Swagger Editor 解析报错或显示乱码。

解决思路： 在 Prompt 里加入这一条："description 字段使用纯文本，不使用 Markdown 语法。需要换行的地方使用 \n，需要强调的地方使用大写或引号。" 这个问题看起来小，但当你批量生成 50 个接口后发现每个都要手动去修格式时，会非常崩溃。

4.4 第四步：引入自动化校验脚本

纯靠人工检查是不现实的，尤其是当你面对几十上百个接口时。我在第二个项目里开发了一套简单的校验脚本，集成在 CI 流程里自动运行。

校验脚本主要做三件事：

1. 格式校验：用 swagger-parser 检查生成的 OpenAPI JSON 是否符合标准规范
2. 字段覆盖率检查：对比代码中的 Pydantic 模型字段和文档中声明的字段，标记缺失或多余的字段
3. 状态码一致性检查：扫描代码中所有 HTTP 异常抛出点，和文档中的 responses 做比对

这套脚本在数据中台项目中帮我发现了 132 个遗漏字段和 47 个状态码缺失。没有自动化校验，单靠肉眼，这些错误有一半以上会被遗漏到交付阶段。

五、批量生成策略：当你有 50+ 个接口时该怎么操作

单个接口的流程相对可控，真正考验人的是规模化生产。第二个项目有 163 个接口，我需要一个系统化的方法。

5.1 按模块分批次，不是一次性全扔进去

我的实践经验是这样的：每批次处理 3-5 个接口，每个批次之间保留上下文延续。

具体操作：

1. 先把所有接口按功能模块分组（比如"用户模块"包含 8 个接口，"订单模块"包含 15 个接口）
2. 同一模块的接口在同一对话会话中处理，因为它们的模型定义和业务规则通常是共享的
3. 不同模块之间开启新的会话，避免上下文污染

这个方法的好处是：Claude 在处理同一模块的后续接口时，已经在前面的对话中"理解"了这个模块的通用结构，生成质量会更稳定。

5.2 建立模板化的输入格式，不要每次都重新写 Prompt

这是我在处理到第 30 个接口左右时意识到的问题：每个接口都临时写 Prompt，不仅浪费时间，而且前后不一致。后来我建立了一个标准输入模板：

## 接口信息
接口路径：[从路由装饰器提取]

HTTP 方法：[GET/POST/PUT/DELETE]

功能简述：[一句话描述]

业务规则

[列出该接口特有的业务规则]

代码

[粘贴完整代码，包含依赖的 Pydantic 模型]

输出要求

使用 OpenAPI 3.0 JSON 格式，遵循项目统一规范：

Path、Parameters、Request Body、Responses 结构完整

所有字段必须有 example 值

所有状态码必须有业务含义描述

嵌套模型递归展开至基础类型

有了这个模板后，我从准备输入到拿到初版文档的时间从平均 15 分钟压缩到 6-8 分钟。

5.3 并发效率陷阱：为什么我不建议同时开多个会话

有人可能会想：我开 5 个 Claude Code 会话，每个处理一批，速度不是快 5 倍吗？

理论上成立，但实际有几个问题：

1. 质量一致性差：不同会话对相同业务术语的理解可能不一致。比如"订单状态"在不同会话里可能被描述为"order_status"或"orderState"，导致最终文档风格割裂
2. 上下文复用率低：同模块接口如果在同一会话中处理，Claude 能复用已理解的模型结构，准确率高，修正也少。并发则失去了这个优势
3. 后期合并成本高：当多个会话生成的文档需要合并成一个完整的 OpenAPI 文件时，去重、合并冲突、统一风格的时间可能抵消并发带来的速度提升

我的做法是：串行处理同一模块，但可以先做流程设计。 比如上午集中处理用户模块，下午集中处理订单模块。这样能保持对话上下文的延续性，同时争取到整体效率。

六、人机协同的"质量门"：AI 干完活后必须由人把关的四大关键点

不管 Claude Code 的表现多么惊艳，有四个环节我一定亲自检查，从不信任 AI 的自动结果。这是我的"质量四道门"。

第一道门：敏感信息泄露检查

这个是我最重视，也最容易出问题的地方。AI 在处理代码时可能会无意中将代码注释、测试用例或错误日志中的测试数据当作示例值写入文档。

我遇到过的一个真实案例：Claude 在生成文档时，把代码里注释掉的一段测试用的手机号和身份证号作为了接口的字段示例值。幸好在上线前被我发现并替换成了明显的占位符。如果这个泄露到外部文档，轻则被客户质疑，重则可能违反数据保护法规。

解决思路：

• 在 Prompt 中加入"生成示例值时使用明显的占位格式（如 phone: '13800138000'，id_card: '110101199001011234'），不要使用代码中出现的任何实际值"
• 生成后人工检查所有示例字段，尤其关注字符串类型的字段
• 在 CI 脚本里加入正则匹配，扫描是否出现符合手机号、身份证号、银行卡号格式的字符串

第二道门：状态码与业务场景的完整映射

这个问题的根源在于：AI 能准确识别代码中的 HTTPException 抛出，但无法自动理解"哪些没写在代码里但业务上可能出现的状态"。

比如一个退款接口，代码里只显式抛出了 400 和 403，但实际还可能返回：

• 409：并发冲突（同一订单被同时操作）
• 422：金额校验失败（代码里可能在业务层校验，不在路由层）
• 429：频率限制（通常在网关层，不在接口代码里）

解决思路： 我建立了一份项目级的"通用状态码清单"，每次生成完文档后对着清单人工补全可能的额外状态码。这份清单包括：

• 400/401/403/404/405：HTTP 标准错误，基本每个接口都可能有
• 409：所有写操作接口都应考虑
• 422：所有涉及参数校验的接口都应考虑
• 429：所有对外接口
• 500/502/503：所有接口的兜底状态

第三道门：业务描述与代码逻辑的一致性

这个环节无法自动化，必须有熟悉业务逻辑的开发者亲自读一遍关键接口的描述。我通常用"反向测试法"：拿着文档里描述的业务规则，在脑子里模拟一遍操作流程，看会不会出现逻辑矛盾。

例如文档写"退款成功后自动触发库存回退"，我就想：如果退款是部分退款呢？如果商品已经过了退货周期呢？这些分支逻辑是不是也在描述中体现了？如果没体现，我就需要手动补充。

第四道门：多版本文档的一致性

当你的 API 有多个版本（如 v1、v2），或者同一个接口在重构前后有变化时，文档很容易出现"v1 的某个规则被错误地复制到了 v2"的情况。这在 AI 批量生成时尤其常见，因为不同版本的代码可能结构相似，Claude 可能混用上下文。

解决思路： 不要同时生成 v1 和 v2 的文档。先完成一个版本并全部检查通过，再在新的对话中生成另一个版本。并且在生成 v2 时明确告诉 Claude："这是一个全新版本的接口文档，不要参考 v1 的任何定义。"

七、不同项目阶段的文档策略选择：不是一个方法吃遍天

根据我的经历，不同项目状态下的文档策略应该完全不同。我把它总结为四个象限：

7.1 新项目：文档先行，代码同步

这可能是最理想但最少人实践的方式。如果你正在开一个新项目，建议在设计阶段就用 OpenAPI 规范描述接口，然后用 Claude 辅助从规范生成代码骨架参考，最后人工实现具体逻辑。

7.2 遗留项目补文档：做好"花一半时间在检查上"的心理准备

这是我做的最多的场景。坦率地说，给遗留代码补文档的流程中，大约 40%-50% 的时间花在修正 AI 输出上，不是花在生成上。如果你的代码注释率低、类型不明确，这个比例会更高。

建议：给这类项目留下充足的时间预算。我当时的经验值是：每个中等复杂度接口预留 25-30 分钟（生成 8 分钟 + 检查修正 15-20 分钟）。

7.3 快速原型：降低标准，能看就行

如果是内部使用的临时接口，不需要完美。这种情况下我直接让 Claude 生成精简版 Markdown，只包含路径、参数、返回值和状态码，不做详细业务描述。这种文档 5 分钟一个，内部传阅足够用。

八、工具链集成：别让生成的文档变成一纸静态文件

文档生成只是第一步，如果它不能融入团队的开发和测试流程，很快又会变成过时的废纸。

8.1 导入 YApi 的正确方式

YApi 支持直接导入 OpenAPI 3.0 的 JSON 文件，但不是所有字段都能完美映射。我遇到过的兼容性问题：

• YApi 对 enum 的处理和标准 OpenAPI 有差异，需要在导入后手动调整
• YApi 不支持 OpenAPI 的 $ref 引用，导入前需要把引用全部展开
• 自定义扩展字段（x- 开头的字段）导入后可能丢失

所以在用 Claude 生成时，如果目标平台是 YApi，我会在 Prompt 里注明"不要使用 $ref 引用，所有模型内联展开"。

8.2 Swagger UI 的部署建议

我现在通常把生成的 OpenAPI JSON 文件和项目代码放在同一个仓库里，配置 CI 自动部署到内部的 Swagger UI 服务。每次代码合并到主分支时，自动触发一次文档重新生成和部署。

这里有个关键细节：文档和代码的版本必须严格绑定。 我们在 OpenAPI 文件的 info.version 字段里填写 Git 的 tag 号，这样出了问题时能精确追溯。

8.3 配合 Postman 的自动化测试

生成的 OpenAPI 文件可以一键导入到 Postman 作为 Collection，然后配合 Postman 的测试脚本做接口冒烟测试。我通常把那些 Claude 生成的字段 example 值直接用作测试的请求参数初始值，前提是你已经过第四道门检查，确保示例值安全且合理。

九、成本评估：用 AI 生成文档到底省了多少

很多人只谈效率提升的倍数，但不说清楚实际的钱和时间，我觉得这种数据没有参考价值。所以我把自己的实际成本写出来。

数据中台项目，163 个接口：

• 如果纯手写：预估约 180-220 小时（按我个人的平均速度）
• 使用 Claude Code 辅助：
• 前期代码规范整理：16 小时（一次性投资）
• 生成文档总耗时（含 Prompt 准备 + 生成 + 修正）：约 52 小时
• 工具脚本开发（校验 + 合并 + 部署）：约 8 小时
• 总计：约 76 小时

实际节省时间：约 100-140 小时，效率提升约 2.4-2.9 倍。

这个倍数可能比一些营销文章说的"10 倍提升"要低，但我觉得这是更真实的数字。而且这笔账还没算上"因为文档写得太差导致第三方对接反复沟通"的隐性成本。那些在早期不愿意投入时间把文档做好的人，最终会在对接阶段付出更大的代价。

十、写在最后：我们对 AI 文档工具的期待错了吗？

做了这么多接口文档的生成和修正之后，我一直在思考一个问题：为什么我们总对 AI 生成文档感到"还不够好"？是不是我们对它的定位本身就错了？

我发现很多开发者（包括早期的我）对 AI 文档工具的期待是这样的：输入代码 → 输出完美文档 → 一键部署，全流程无人工干预。

但这显然不符合现实。更合理的期待应该是：AI 负责机械性的、重复的、模板化的那部分工作，人类保留对业务语义的最终解释权。

如果重新定位，Claude Code 在我眼里不是一个"文档生成器"，而是一个"效率放大器"。它在以下方面确实有不可替代的价值：

• 把一个需要 45 分钟的繁琐参数列表整理工作缩短到 5 分钟
• 自动保持 JSON/YAML 格式的语法正确性
• 能从一个 Pydantic 模型里提取出 30 个字段而不遗漏（人手动做容易漏）

而在这些方面，不要对它抱有不切实际的幻想：

• 它不会理解"为什么订单取消有时候要收费，有时候不收费"
• 它不会知道"这个字段虽然代码里定义为可选，但业务上 99% 的情况下都要传"
• 它不会判断"这个示例值虽然看起来合理，但包含了真实用户的手机号，绝对不能用在外部文档里"

所以，下一步你应该怎么做？

如果你现在就要开始用 Claude Code 生成接口文档，我的建议是：

1. 先不要着急问"Prompt 怎么写"，先去检查你的代码：类型注解完整吗？有 docstring 吗？如果代码本身是乱的，AI 只会生成一篇看起来很专业但错误百出的文档。
2. 建立你自己的"Prompt 模板库"和"校验清单"：每做一个项目，把好用的 Prompt 和踩过的坑都记录下来。我的模板库里现在有 6 种不同场景的 Prompt，每次有新项目只需要微调。
3. 接受"40% 的时间花在检查上"这个事实：不要觉得这是 AI 的问题，这是人机协同的常态。与其抱怨 AI 不够智能，不如建好你的自动化校验脚本，让机器帮你做它能做的检查，把精力留给必须人来做的业务判断。
4. 文档好不好的标准不在生成时，在使用时：最终检验文档质量的不是它看起来多么工整，而是第三方开发者在对接时提了多少问题。收集这些反馈，反向优化你的 Prompt 和代码注释习惯。

我越来越相信：在代码即文档的实践里，工具只是手段，真正决定文档质量的永远是写代码的人和审查文档的人。Claude Code 帮你解决了 80% 的工作量，但那 20% 才是区分"可用文档"和"优秀文档"的关键。

如果你也正在用 AI 工具辅助写文档，或者踩过不同的坑，欢迎分享你的实际经历。我把我在两个项目中沉淀下来的核心 Prompt 模板和校验脚本整理了一下，有需要的可以拿去直接用，省得从头再走一遍弯路。