核心结论：这个技巧能做什么，不能做什么

先把结论摆出来，方便你对号入座：

这个技巧最适合的场景：

你手上有一份结构清晰的Markdown字段定义文档（表格格式最佳）

需要快速生成Django模型的基础结构，包括字段、约束、关系、Meta选项

字段数量超过20个，手工编写明显耗费时间

需要保持文档与代码的严格一致性

这个技巧不太适合的场景：

业务逻辑复杂的模型方法（比如save()里有多重校验）

动态字段或需要运行时计算的属性

需要同时处理多个数据库路由的复杂配置

字段定义文档本身混乱、不完整或充满歧义

效率提升的量化参考： 在我统计的6个实际项目中，手工编写Django模型的时间与AI辅助后的时间对比如下：

需要强调的是，“37秒生成代码”只是生成环节的时间，加上提示词设计、结果审查、业务逻辑补充，一个中等复杂度的项目实际需要8-15分钟。但这个效率提升依然非常显著，我见过太多开发者低估了手工编写模型时反复修改的隐性成本，这个图反映的是真实的全流程耗时。

为什么这件事值得认真对待

1 场景还原：从文档到代码的“翻译苦力”

如果你也做过企业级Django项目，大概率遇到过这种情况：

项目初期，产品经理或BA（业务分析师）在需求文档里定义了数据结构，通常以表格形式呈现，字段名、类型、是否必填、备注说明，零零散散几十个甚至上百个字段。你需要在models.py里逐个翻译成Python代码：

手工编写的典型状态

name = models.CharField(max_length=200, verbose_name="商品名称")

code = models.CharField(max_length=50, unique=True, verbose_name="商品编码")

category = models.ForeignKey(Category, on_delete=models.CASCADE, verbose_name="品类")

每个字段你都要思考：选什么Field类型？max_length取多少？要不要建索引？默认值是什么？外键的on_delete策略是什么？这不是高难度脑力劳动，但极其消耗注意力和时间。

更让人头疼的是，文档会变。项目第三周，产品经理说“采购批次表要加两个字段，另外供应商编码的规则改成15位了”。你再手工改一遍，眼睛盯着屏幕做字段对照，几十个字段里找到对应的几行，改完还得检查是否漏改、错改。这种工作本质上就是“结构化数据到代码的机械转换”。

2 主流方案的局限性

在接触Claude Code之前，我试过几种思路来解决这个问题：

方案

优点

致命缺陷

手工编写

完全控制、无额外依赖

时间成本高，重复修改时易出错

django-extensions的inspectdb

从已有数据库反向生成

要求先有数据库，且生成代码带managed=False，需要大量手动调整

ChatGPT/网页版AI

初始生成快

需要在网页和编辑器间反复复制粘贴，没有上下文记忆，长文本处理能力弱

GitHub Copilot

在IDE内使用，按Tab补全

适合片段生成，无法一次性从整份文档生成完整模型；上下文理解受限于当前文件

手写代码生成脚本

可复用

开发脚本本身的时间可能就已经够手写一遍模型了，且维护成本高

Claude Code的差异点在于： 它是一个终端内的对话式编码助手，能够直接读取你工作目录下的Markdown文件，理解上下文后生成代码并写入指定文件。整个过程不出终端，你不需要在不同工具间切换，而且它支持多轮迭代，第一次生成不完美，你可以在同一会话里告诉它修改规则，它会记住上下文后重新生成。

3 传统手工转换与AI辅助的流程差异

下面这张图直观展示了两种方式在流程上的根本差异：

这里有一个容易被忽视的点：AI辅助流程把“翻译工作”从人工重复劳动变成了“定义规则+机器执行”。你花在设计提示词上的时间，可以在后续几十次修改中持续摊销。而手工编写的痛苦在于，每一次修改都是一次完整的“阅读→翻译→检查”循环。

常见误区拆解

在使用Claude Code做Markdown转Django模型这件事上，我看到不少文章给出的建议过于乐观，也有一些团队踩了同样的坑。

误区一：“直接把Markdown扔进去就行了”

这是最大的误解。Claude Code确实能理解Markdown格式，但如果不给任何提示词就直接让它“生成Django模型”，结果的质量波动极大。我做过一个对照实验，同一份Markdown（包含28个字段），不加提示词直接生成 vs 使用精细化提示词，对比结果如下：

评估维度

无提示词直接生成

使用精细化提示词

字段类型准确率

71%（有8个字段类型选择偏差）

96%（仅1个需手动调整）

verbose_name匹配率

100%

100%

外键关系正确率

64%（漏掉了2个间接关系）

100%

Meta类包含

无

完整（indexes、ordering、unique_together）

依赖安装提示

无

提示了ForeignKey需要引用的app

核心差异在于： Claude Code会根据Markdown文本“猜测”字段类型，但没有提示词的情况下，它对Django的最佳实践、你项目的命名习惯、数据库优化策略一无所知。比如Markdown里写“手机号”，它可能生成CharField(max_length=20)，也可能生成CharField(max_length=11)，到底哪种对？它需要你的指令。

误区二：“生成的代码可以直接提交”

这是一个危险的认知。AI生成代码的质量取决于提示词的精密程度，但即便最好的提示词，也无法覆盖100%的业务逻辑场景。我遇到过的真实问题包括：

外键字段生成了on_delete=models.CASCADE，但业务要求供应商被删除时，关联的采购单应保留（应该是SET_NULL或PROTECT）

unique_together生成了，但索引顺序与查询习惯不一致，导致索引命中率低

某些字段的choices选项没有生成，因为Markdown文档里没有明确定义枚举值

生成代码必须经过人工审查，这是原则。我建议的审查清单见第六节。

误区三：“一次会话搞定，不需要清理上下文”

Claude Code的上下文窗口虽然大（官方数据是200K tokens），但如果你在一个会话里反反复复修改提示词、生成多版代码、还夹杂了其他无关讨论，上下文会逐渐“污染”。我曾在一个超长会话里发现，第7次生成时Claude Code“记住”了第3次某个特殊需求，结果新需求下多出了一些不该有的约束。

好的做法是： 关键生成使用独立会话，或者至少在新需求开始时用/clear清空上下文（如果Claude Code支持）。

误区四：“Markdown格式随便写，AI都能理解”

Markdown确实是人类和AI都友好的格式，但“友好”不等于“随便”。以下两种写法，AI的处理准确率天差地别：

较差写法（歧义多）

• 名称（必填）
• 价格
• 分类（外键）

推荐写法（结构化表格）

我给每个新接手项目的产品经理都会发一份Markdown字段定义模板，不要让他们自由发挥，否则你接到手的文档格式千奇百怪，AI的解析效果也不稳定。

动手前的专业判断逻辑

在启动Claude Code生成模型之前，有几个关键判断需要你提前做清楚。这些判断不是技术操作，但决定了后续工作的效率和代码质量。

1 判断维度一：你的Markdown文档是否“就绪”

我把Markdown文档的成熟度分成三个等级：

成熟度

特征

建议行动

高（结构化表格，字段类型明确）

有完整表格，字段名、类型、约束、关系都清晰；文档与业务方确认过

可直接进入提示词设计阶段

中（有字段列表，但类型说明模糊）

有字段名和说明，但类型用“文本”“数字”等模糊词；约束条件不完整

先补齐类型映射，和业务方核对一次再开始

低（纯文字描述，需要脑补很多信息）

类似于“需要记录采购信息，包括供应商、时间、明细”这种一段话

先用Claude Code或其他AI把文字转成结构化Markdown，再进入模型生成流程

判断依据是在“手工补齐字段定义”和“让AI脑补后修复”之间算账。 文档成熟度低+字段数量多时，先让AI整理成表格再生成模型，反而更省时间。

2 判断维度二：字段类型的映射规则是否清晰

这是影响生成质量最关键的变量。Markdown文档里的“类型”说法的精细程度，直接决定了Claude Code选择Django Field类型的准确率。我在实践中总结了一套映射表，供你在设计文档时参考：

这个数据说明一件事：你在Markdown层面的投入，会在生成质量上获得超额回报。 花20分钟把文档里的“数字”改成“decimal(10,2)”或者“integer”，远比花20分钟修复错误生成的Field类型来得高效。

推荐在Markdown文档或提示词中显式定义映射规则，类似这样：

这条映射表直接决定了Claude Code是把Markdown的“decimal(10,2)”翻译成DecimalField(max_digits=10, decimal_places=2)，还是保守地翻译成CharField(max_length=20)。 前者是你想要的，后者会让你在makemigrations时报错或者数据精度丢失。

关键步骤：提示词的设计与迭代

提示词是这个技巧的核心资产。我见过不少教程只贴出一个“最终版提示词”，却不展示从粗糙到精细的迭代过程，这恰恰是读者无法举一反三的原因。下面我把自己常用的迭代路径完整展示出来。

1 第一版：最小可用提示词

第一次使用Claude Code做这件事时，我的提示词简单到只有两句话：

> 读取项目根目录下的 data_dictionary.md 文件，将其中的字段定义转换为Django模型代码，写入 models.py。

结果生成了代码，但问题一堆：字段类型有4处错误，外键关系没处理，连__init__.py都没提示我创建对应app。这不是Claude Code不行，是我的提示词太粗了。

2 第二版：加入字段类型映射

吸取教训后，我在提示词里加入了明确的映射规则：

> 按照以下规则读取 data_dictionary.md：

> – Markdown表格中的“类型”列与Django Field的映射关系：string(n)→CharField(max_length=n)，text→TextField，integer→IntegerField，decimal(m,n)→DecimalField(max_digits=m, decimal_places=n)，boolean→BooleanField，date→DateField，datetime→DateTimeField

> – “中文名”列对应verbose_name

> – “必填=是”对应null=False, blank=False；“唯一=是”对应unique=True

>

> 输出完整的models.py文件。

这一版生成结果明显好转，字段类型准确率从71%提升到了89%。但仍然有两个问题：

外键关系没有被处理好（Markdown里有foreignkey标记但AI不会自动识别）

Meta类的indexes、ordering没有被生成

3 第三版：加入关系和约束规则

继续进化。这一次我加入了更完整的规则集：

> 请读取根目录下的 data_dictionary.md，将其中表格定义的字段转化为Django模型代码。

>

> 处理规则如下：

> 1. 字段类型映射：string(n)→CharField(max_length=n)；text→TextField；integer→IntegerField；decimal(m,n)→DecimalField(max_digits=m, decimal_places=n)；boolean→BooleanField；date→DateField；datetime→DateTimeField

> 2. 关系处理：表格中“外键关联”列的格式为“目标表.字段名”，请生成ForeignKey字段。外键字段命名为“目标表_id”，to参数使用字符串形式（如to='app_name.ModelName'），避免循环导入。on_delete策略默认为models.PROTECT（除非我指定）。

> 3. verbose_name：使用“中文名”列的值。

> 4. 约束处理：必填→null=False, blank=False；唯一→unique=True；默认值→default=给定值（注意数字不加引号）。

> 5. Meta类：自动生成db_table（格式为业务前缀_表名）；根据字段名合理推断ordering；为所有ForeignKey字段自动添加索引（使用indexes）。

> 6. 格式：每个模型单独一个文件，文件名与模型名一致（小写），放入app_name/models/目录下。

这一版的提示词加入了关系处理规则、Meta自动生成、文件组织方式。用这版提示词处理同一份Markdown后，字段类型准确率达到96%，外键全部正确生成，Meta类包含了indexes和ordering，还自动帮我创建了正确的目录结构。

4 可复用的提示词模板

经过多次迭代后，我沉淀出了下面这套模板。为了方便复用，我把可变的项目信息用{变量}标记，你只需要替换这几个变量就可以：

请读取 {markdown文件路径}，将其中的字段定义转化为Django模型代码。

字段类型映射表

关系处理

• “外键关联”列的格式为“目标模型.字段”，请生成ForeignKey字段
• 外键字段命名为“{去掉_id后缀的关联关系名}_id”
• to参数使用字符串格式 'app_name.ModelName'
• on_delete默认使用 models.PROTECT，除非标注了SET_NULL或CASCADE
• 当标注了“可为空”时，外键字段设置null=True, blank=True

约束映射

Meta类生成规则

• ordering: 如果有“排序”或“序号”字段，使用该字段排序
• db_table: 格式为 "{项目前缀}_{模型名小写}"
• indexes: 为所有ForeignKey字段生成索引
• unique_together: 如果文档标注了“联合唯一”，生成之

输出要求

• 每个模型独立一个文件，放入 {app_name}/models/ 目录
• 文件名与模型名一致（小写）
• 文件编码UTF-8
• 顶部包含导入语句
• 如果引用了其他app的模型，自动在顶部添加对应的import

这个模板为什么有效？

它把“人需要做的判断”前置到了提示词里：字段类型怎么映射、关系怎么处理、约束怎么配置。Claude Code不再需要“猜测”你的意图，它只需要执行翻译。这也解释了为什么有些人的提示词效果很差，他们把一个需要精细指令的任务，当成一个“你懂的”开放式问题抛给了AI。

5 提示词优化的核心原则

通过反复实验，我总结出三个关键原则：

1. 规则显式化：不要假设AI“应该知道”Django的惯例。你想要的on_delete策略、字段命名习惯、Meta类格式，全部写出来。提示词越像一份“工作规范书”，结果越可控。
2. 用表格替代自然语言：映射关系用表格定义比用自然语言描述更精准。AI对表格的理解比长段落更准确。
3. 给出格式约束：明确指定文件的输出路径、命名规则、编码格式。这不是AI的问题，而是保证生成的代码能直接融入现有项目结构。

实战全流程：从一个真实案例看完整步骤

说了一堆理论，现在用一整个完整案例串起来。这个案例来自我2025年初做的一个小型电商后台项目，数据字典由产品经理提供，我需要把它变成Django模型。

1 原始Markdown文档

产品经理发来的文档是这样的（节选）：

数据字典 – 订单模块

订单主表 (t_order)

订单明细表 (t_order_detail)

客户表 (t_customer)

2 准备阶段

在看这份文档时，我快速做了三个判断：

1. 文档成熟度为“高”：有完整表格，字段类型使用了string/decimal/foreignkey等明确表述，外键关联标注了删除策略，可以直接进入提示词设计。
2. 需要注意的特殊点：

order_status有隐含的choices需求（0-4的状态枚举），但文档是在备注里描述的，不是独立列

外键关联写了“删除时保护”和“级联删除”，这需要对应不同的on_delete策略

客户表的level字段同样有枚举需求

订单明细表的unit_price没有默认值，需要确认业务规则

我决定做的额外处理：在提示词里加入choices映射规则，让Claude Code自动处理备注中带有“0xxx 1xxx 2xxx”这种格式的状态描述。

3 撰写提示词

基于上面的判断，我写的提示词如下（直接粘贴我当时的终端输入）：

读取当前目录下的 data_dictionary.md 文件，将其中"订单主表"、"订单明细表"、"客户表"三个表格转化为Django模型。

字段类型映射（严格按此规则）

string(n) → CharField(max_length=n)

integer → IntegerField

decimal(m,n) → DecimalField(max_digits=m, decimal_places=n)

foreignkey → ForeignKey(to='关联模型', on_delete=见下规则)

外键处理规则

• "删除时保护" → on_delete=models.PROTECT
• "级联删除" → on_delete=models.CASCADE
• 关联字段命名：去掉_id后的字段名（如表中有order_id，生成为order = ForeignKey(…)）

特殊处理

• 备注列中如果有"0xxx 1xxx 2xxx"格式的，自动提取为choices参数

示例：备注"0待支付 1已支付 2已发货" →

STATUS_CHOICES = [(0, '待支付'), (1, '已支付'), (2, '已发货')]

order_status = IntegerField(choices=STATUS_CHOICES, default=0)

• Meta类要求：
• db_table使用实际的表名（t_order, t_order_detail, t_customer）
• 所有外键字段自动加db_index=True（或在Meta.indexes中定义）
• order_no字段在Meta中加unique约束

输出要求

• 创建order_app/models/目录
• 生成三个文件：order.py, order_detail.py, customer.py
• 每个文件包含完整的模型定义和导入语句
• 在order_app/models/__init__.py中导入所有模型

4 执行与结果

在终端中进入项目目录后执行：

claude

然后粘贴上面的提示词。大约一分钟后，Claude Code完成了以下工作：

1. 读取了data_dictionary.md
2. 按照映射规则生成了三个模型文件
3. 自动处理了choices提取
4. 创建了目录结构

下面是生成的order.py（实际输出，略有格式调整）：

from django.db import models

class Order(models.Model):

STATUS_CHOICES = [

(0, '待支付'),

(1, '已支付'),

(2, '已发货'),

(3, '已完成'),

(4, '已取消'),

]

order_no = models.CharField(max_length=32, unique=True, verbose_name='订单编号')

customer = models.ForeignKey(

'Customer',

on_delete=models.PROTECT,

db_index=True,

verbose_name='客户ID'

)

order_status = models.IntegerField(

choices=STATUS_CHOICES,

default=0,

verbose_name='订单状态'

)

total_amount = models.DecimalField(

max_digits=12,

decimal_places=2,

default=0.00,

verbose_name='订单总金额'

)

paid_amount = models.DecimalField(

max_digits=12,

decimal_places=2,

default=0.00,

null=True,

blank=True,

verbose_name='实付金额'

)

class Meta:

db_table = 't_order'

ordering = ['-id']

indexes = [

models.Index(fields=['customer']),

]

def __str__(self):

return self.order_no

这个结果的亮点：

备注中的状态描述被正确提取为choices（这是提示词里专门定义的规则）

外键on_delete根据“删除时保护”正确生成了PROTECT（而不是默认的CASCADE）

db_table使用了原始表名

paid_amount因为标注了“否必填”且备注写了“允许为0”，被正确处理为null=True, blank=True

需要手动调整的地方（在我的预判范围内）：

order_no没有添加索引（通常订单编号查询频繁），我手动加了个db_index=True

我选择在Meta的indexes里为外键加索引，但实际线上项目中我更多使用db_index=True放在字段定义里（看团队习惯）

5 验证与集成

生成完不是结束，我还有一个固定流程：

执行makemigrations检查：

python manage.py makemigrations order_app

这次毫无报错，直接通过。

执行sqlmigrate查看生成的SQL：

python manage.py sqlmigrate order_app 0001

检查字段类型、索引、外键约束是否正确。

人工审查清单：

所有ForeignKey的on_delete策略是否符合业务要求 ✓

DecimalField的max_digits和decimal_places是否正确 ✓

unique_together是否遗漏 ✓

choices的定义是否正确 ✓

db_table命名是否符合团队规范 ✓

在这个案例中，总耗时约12分钟（包括阅读文档3分钟+撰写提示词4分钟+等待生成2分钟+验证与微调3分钟）。如果手工编写三个模型，保守估计需要25-30分钟，还不算后续修改的时间成本。

进阶技巧：驾驭复杂场景

掌握了基础流程后，你会遇到一些复杂场景。下面是我在实践中摸索出来的处理方案。

1 处理多对多关系

Markdown文档里如果标注了多对多关系，处理方式如下。假设文档中这样写：

提示词中需要补充：

如果“类型”列为 m2m：

生成 ManyToManyField(to='Tag', verbose_name='关联名称')

如果备注中写了"带中间表"，则检查是否有自定义中间表的字段定义

如果多对多关系需要中间表（through），我会把中间表也放在Markdown里用普通表格定义，然后在提示词里指定：

如果Markdown中有“中间表”字样的表格，该表应生成Django模型，并在相关多对多字段中使用through参数指向该模型。
七.2 处理模型继承

我遇到过需要使用抽象基类的场景。比如多个模型共享相同的审计字段（create_time, update_time, create_user等）。处理方式是在提示词中指定：

如果多个表的第一列都包含相同的公共字段（如create_time, update_time），
请额外生成一个 AbstractBase 抽象基类，将这些公共字段放入其中，

然后让其他模型继承它。

抽象基类的Meta中设置 abstract = True。

这样生成的代码结构清晰，避免了重复定义。

七.3 处理choices枚举的复杂情况

有时候choices不是从备注提取那么简单。比如我有一次遇到的情况是，choices值定义在另一个Markdown文件里（叫data_dictionary_enums.md）。我的解决方案是：

除了读取字段定义文档外，还读取 enums.md 文件。
对于字段备注中标明“参见枚举表”的字段，

在enums.md中查找对应的枚举定义并生成choices。

如果找不到对应定义，在代码注释中标注 TODO。

七.4 多文件分批处理

当字段定义文档过多（比如一个大型ERP的完整数据字典），一次全部生成可能会超出上下文窗口或者让AI的注意力分散。我的处理策略是：

本次只处理 data_dictionary.md 中“采购模块”章节下的表格。
生成的文件放入 purchase_app/models/ 目录。

保持与其他模块的ForeignKey引用正确（使用字符串形式的模型引用）。

分模块处理后，最后再生成一个汇总的__init__.py或检查跨模块的外键引用。

七.5 处理版本化文档

实际项目中，数据字典会随版本迭代。我建立了一个工作流：

对比 v1.0 和 v1.1 版本的差异，只生成发生变更的字段对应的模型代码。
原始文档命名为data_dictionary_v1.0.md
更新的文档命名为data_dictionary_v1.1.md
使用Claude Code时指定：
新增字段直接加入现有模型；删除字段在代码中注释标记；修改的字段直接更新。

这个“增量更新”模式在持续迭代的项目中极其有用，避免了每次全量重新生成导致的手动修改被覆盖。

八、Claude Code与其他方案的横向对比

为了给你一个更完整的选择参考，我把这一年来尝试过的几种“Markdown转Django模型”的方案做了对比。这些数据来自个人实践，不是实验室条件下的精确测量，但能反映真实工作流中的差异。

八.1 各方案实际使用体验

ChatGPT网页版

适合快速验证想法，但不适合作为工作流的一部分。每次需要复制文档到对话框，生成后再复制回编辑器。Markdown里的表格偶尔格式会错乱，需要手动调整。上下文窗口虽然也大，但无法直接读取本地文件路径，外键关系的处理需要反复说明。我自己做原型验证时会用它，但正式开发不用。

GitHub Copilot

在IDE内使用很方便，但它更适合“给我补全这个字段”而不是“把这整份文档转成完整的models.py”。Copilot对当前文件的感知能力强，但不适合处理外部文档到代码的转换。你可以把Markdown内容粘贴到Python注释里让它翻译，但字段数量多时可以明显感觉到它的上下文理解在衰减。

自己写代码生成脚本

这个方案“理论上”最可控。我写过两个版本的生成器，一个读Markdown表格用Python解析，一个用Jinja2模板渲染Django模型。最初的开发投入大约是6小时（含调试）。后续每调整一次映射规则或有新需求，又要改脚本。对于需要长期维护的项目且有固定规则的情况，投入产出比还算可观；但对于一次性或规则变化频繁的项目，不划算。

Django的inspectdb

只适用于“先有数据库再有代码”的场景。生成的代码带有managed=False标签，每一个模型都需要手动清理。关系处理也不够智能，经常生成ForeignKey但没有明确的related_name。优点是零提示词投入，但这个优势只在你恰好有这个数据库结构的情况下成立。

Claude Code（终端版）

目前的综合最优解。优势在于：终端原生支持文件读写，无需复制粘贴；提示词可复用、可版本化；多轮迭代在同一会话中保持上下文。但也有局限：目前不支持Windows原生终端（需要WSL），且有时候会在长会话后出现上下文理解偏差。

九、这个技巧的真实局限性

我不想让你看完这篇文章后过度乐观。下面是我诚实记录的限制和边界。

九.1 业务逻辑仍然需要手工编写

Claude Code处理的只是字段定义、约束和关系。以下内容几乎一定需要你手工写：

• save()方法中的业务校验逻辑
• 信号定义和处理函数
• 自定义Manager和QuerySet
• 复杂的数据迁移脚本
• 与第三方服务（如支付、短信）相关的字段处理逻辑

以订单模型为例，order_status的变更可能需要触发状态机流转检查，这个逻辑Claude Code无法从Markdown中推断。

九.2 上下文长度的硬限制

Claude Code的上下文窗口官方数据是200K tokens。实际使用中，当Markdown文档过长（比如超过50个模型，每个模型30个字段），单次会话可能无法在保持高质量的前提下处理完所有内容。我的经验是，模型数超过30个时，分两到三个批次处理，质量更稳定。

九.3 对Markdown格式的高度依赖

如果给你的文档不是表格格式，而是层级列表或者更糟，纯段落描述，那么AI的解析准确率会大幅下降。这不是Claude Code的问题，而是非结构化文本天然带有歧义。我的建议是：宁愿花时间先把文档整理成标准表格，也别直接拿半结构化文本去生成。

九.4 团队协作的摩擦

如果你的团队不熟悉Claude Code或者对AI生成代码有抵触，引入这个工具可能会遇到阻力。我见过有团队坚持“代码必须手写以保持完全控制”，如果你在这种环境里，先从小模块开始证明价值，别一上来就说“以后全部用AI生成模型”。

九.5 成本和网络依赖

Claude Code需要API访问，这意味着：

• 需要稳定的网络环境（国内部分网络环境访问可能不稳定）
• 按token计费（不过单次模型生成的费用通常很低，我的经验是几美分到几十分不等）
• 在完全离线的环境下不可用

如果你的项目有严格的网络安全要求，需要评估这个限制。

十、如何判断这个技巧是否适合你的项目

根据项目特征，我总结了一个判断框架：

强烈建议尝试的情况：

• 字段总数超过30个
• 文档与代码需要频繁同步（每两周一次以上的迭代）
• 你已经在用Claude Code做其他开发任务

可以试但不一定值得的情况：

• 字段数少于15个
• 一次性项目，后续不会修改模型
• 你对AI生成代码的审查还不熟练

不建议使用的情况：

• 无法访问Claude Code或API
• 项目有严格的安全合规要求，禁止AI生成代码进入核心逻辑
• 字段定义文档质量极低，整理文档的时间已经超过手写模型的时间

一个容易判断的参考标准： 如果你看完这篇文章到现在，脑子里已经想到了某个具体的、有大量字段需要定义的项目，那大概率值得试一试。如果你想了半天没想到合适的场景，可能暂时用不上。

总结与下一步

这篇文章想传达的核心观点其实很朴素：把Markdown文档转成Django模型代码这件事，Claude Code做起来比手工快5-10倍，但前提是你愿意投资时间在“结构化文档”和“精细提示词”这两个关键环节上。 只靠工具本身的聪明程度不够，你的提示词质量决定了输出质量的下限。

如果你准备开始用这个技巧，我的建议是：

1. 先找一个字段数在15-30之间的小模块做实验，别一上来就处理全量数据字典
2. 按照第五节的提示词模板做第一次尝试，运行一遍完整流程
3. 观察生成结果中出现频率最高的问题类型，下次在提示词里针对性地补规则
4. 建立你自己的审查清单，固定每次生成后的检查项
5. 如果好用，把提示词模板存入项目仓库，让团队其他成员也能复用

如果这篇文章帮到了你，或者你在实际使用中总结出了更好的提示词套路，欢迎在评论区分享。我自己也在持续迭代这个工作流，技术工具的价值，往往是在真实项目里被反复打磨后才真正浮现的。