为什么我的 AI 创课助手不会写糊——SDD 把追问规范长期挂载、TDD 把每一个 JSON 字段都验证

你最近一次让 AI 帮你跑通 ToB 业务,是不是卡在一个诡异的地方——业务模型已经写得很全了,一份 9 字段 JSON 摆在桌面上,可你一上手做工程,AI 就开始给你"自由发挥"了。

你让它生成题目,它把题型搞错了。你让它校验 JSON,它把"prerequisites"的引用写漏了。你让它跑部署,它把不该有的依赖塞进生产环境。你跟它说不对,它点头,说"好的我改",下次还是错。

不是 AI 太笨。是工程模型没把业务锁死。

上一篇我们聊完业务心智——AI 把老师那句含糊的"我要做 Java 培训"剥成了一份 9 字段 JSON。你心里可能松了口气:"这事算落定了。"我说,没那么快。

业务模型有了,工程模型要重新起步。它不是"把 JSON 当输入,接着写代码",是——

业务模型有了,工程模型是把业务边界焊死、选择放开。

这一句你记下来。它是这一篇的底色,也是上一篇留下的钩子的正面回答。

锁死的是业务边界——DDD 划出的三个限界上下文、SDD 长期挂载的追问规范、TDD 卡死的校验红线。

放开的是 AI 的选择空间——怎么实现类、用什么具体库、怎么落地缓存、怎么序列化事件,这些"实现细节"AI 在边界内随便飞。

锁业务,不是不让 AI 动;放选择,不是让 AI 瞎飞。这两件事同时做,才是 AI 时代的工程秩序。

这一篇我们就来讲这一整套秩序怎么搭。我用一间"智能厨房"给你打比方——AI 创课助手就是这间厨房,DDD 是三工种分区、TDD 是试菜员、SDD 是墙上挂的菜谱表。三件套加在一起,就是这间按秩序搭好的厨房。

下面一段一段拆。

一、业务模型有了,工程模型是把业务边界焊死、选择放开

我们把"业务模型"和"工程模型"两个词先说清楚,免得后面混着讲。

业务模型——上一篇我们剥出来的那份 9 字段 JSON。它讲的是"这门课要讲什么、给谁讲、终点是什么、怎么排章节、知识点怎么依赖、配什么题"。它解决的是"业务上对不对"。

工程模型——这一篇要讲的。它讲的是"AI 拿到这份 JSON 之后,在工程上怎么跑得稳、跑得不糊"。它解决的是"工程上稳不稳"。

业务模型对,工程模型错——AI 跑出来的产品照样是糊的,老师一看不是自己想要的那个东西。

具体糊在哪儿?我列三个真实常见的糊法。

糊法一:题型跑偏。你 spec 写"examConfig.questionTypes 必须 ∈ {choice, fill, coding, essay, judge}“,AI 给你生成题目的时候,默认选了你没列过的"scenario”——这是 AI 的"自由发挥",它没意识到 spec 里没有这个枚举值。

糊法二:依赖断链。你 spec 写"kp-005 的 prerequisites 引用 kp-003",AI 在校验的时候没递归检查 kp-003 的 prerequisites 又引用了哪个 kp,导致章节依赖链断了一环,前端加载就报错。

糊法三:改了 JSON 没同步。老师中途把"4 周 40 小时"改成"6 周 60 小时",AI 只改了 totalHours 字段,没回溯所有 estimatedHours 加起来是不是等于 60——结果是骨架错位。

这三个糊法有一个共同点:业务边界没锁死,AI 在"实现细节"里自由发挥。

怎么焊?

三件套。

• DDD 锁业务边界——三限界上下文切清 course / question / media,每个上下文有自己的通用语言、自己的聚合根,AI 在边界内随便写,跨边界不行。
• SDD 焊技术规范——追问规则、JSON Schema、题型规则、难度规则、4 轮+1 汇总硬约束,长期挂在 AI 工作台上,AI 跑就完事,不用每次新会话重讲。
• TDD 焊审计红线——追问覆盖度、JSON 合法性、修改一致性,三道闸 CI/CD 流水线自动拦,AI 写错拦回、退回重做,无协商空间。

三件套合起来,落到一句金句——

业务模型有了,工程模型是把业务边界焊死、选择放开。

下面我们把"三件套怎么落到工程对话里"摆到桌面上——上一篇的第一轮对话是"业务边界",这一篇的第二轮对话是"技术方案"。

二、第二轮 AI 对话演示 —— 三件套怎么落到工程决策

上一篇我们走完了第一轮对话——AI 跟老师按 ADD 8 维度挨个追问 4 轮,出汇总确认,产出 9 字段 JSON 业务模型。这一篇我们要走的是第二轮对话——工程团队(我 + AI)敲定技术方案。

注意,这一轮对话不是老师参与了,是 FDE 自己跟 AI 谈。AI 这时候的角色变了——从"业务追问者"变成"工程方案共谋者"。

对话还原——

FDE:业务模型有了。9 字段 JSON,Java 社招新人 40 小时速成。下一步是把"AI 创课助手"做成可跑的 Agent 产品。我打算分三个限界上下文:course(主域)、question(支撑域)、media(支撑域)。你看合理吗?

AI:合理。course 是主域——课程结构管理、知识点编排、课时分配,这是产品的核心。question 是支撑域——题目配置管理、难度分级、分值分配,跟 course 是 customer-supplier 关系。media 是支撑域——上传材料、RAG 检索、引用关系维护,跟 course 是 published language 关系(事件订阅)。三个上下文之间通过 Feign 同步调用,Kafka 异步事件订阅,共享内核是布鲁姆动词表 + 知识点 ID 规范。

FDE:行。但有个担心——三个限界上下文是不是切得太早?course 现在只跑这一个场景,直接分三个会不会增加部署负担?

AI:会增加一点。但切完之后的好处大于成本——后面加新场景(比如 K12 课、中学课)的时候,question 和 media 可以复用,只换 course。这是一次切、多次受益。

FDE:拍板。三个限界上下文确认。

下一个决策——SDD 双端怎么挂。

FDE:Spec 端我打算把四类规则长期挂载——ADD 追问规则、JSON Schema 校验规则、题型规则、难度规则,加上 4 轮+1 汇总硬约束。Story 端只跑对话脚本(老师需求 → ADD 追问 → JSON → 审阅 → Exam 配置 → 定稿)。你看这套 Spec 挂法会不会束缚 AI 的灵活性?

AI:不会。Spec 端锁的是"不能做什么"(4 轮上限、题型 enum、JSON 必填字段、难度三档),放开的是"怎么做"(追问具体怎么问、AI 怎么措辞、用户怎么补答)。这是"锁边界、放自由度"的标准做法——Spec 端焊规矩,Story 端跑业务,AI 在两层之间自由发挥。

FDE:行。我还想加一条硬约束:题型枚举必须是 {choice, fill, coding, essay, judge} 这五个,不许出现"scenario"之类的自由发挥。这是老师最讨厌的——AI 出一堆奇形怪状的题型,题目生成 Agent 不认。

AI:明白。这条枚举值我会长期挂在 Spec 端 JSON Schema 校验里,任何题型不在 enum 范围内,JSON 合法性审计直接拦。

FDE:Spec 端挂载确认。

下一个决策——TDD 怎么把三道闸卡死。

FDE:TDD 我打算分三层:追问覆盖度审计 + JSON 合法性审计 + 修改一致性审计。这三层每层都有具体的 Given-When-Then 规则。你看这三层够不够用?

AI:够用。追问覆盖度审计——每一轮追问必须覆盖 ADD 8 维度至少一个,4 轮累计不能漏 5 个以上维度;JSON 合法性审计——必填字段、enum 范围、数值范围、引用完整性四道闸;修改一致性审计——用户改 JSON 后,关联的 prerequisites / examConfig / 学习目标必须重新校验。三层加起来基本覆盖上一篇那 9 字段 JSON 的全部失败模式。

FDE:行。我再补一条——测试通过率必须 100% 才能合并。CI/CD 流水线一票否决,不许手动覆盖。

AI:这条规矩就是"焊死的闸,不是装饰"。AI 写错直接退回,不让 AI 自己"判断一下"。

FDE:TDD 三层确认。

最后一个决策——工程化取舍,4 个决策项里有 1 个我想跟你商量。

FDE:对话状态、JSON 解析这两个我已定——对话状态走 Redis(TTL ≤ 24h),JSON 解析走 jsonschema 库。但题目生成这块,我有两个选项:A 同步 Worker、B 异步消息队列。你怎么看?

AI:看你场景。如果题目量小(每门课 5-20 题)、一次性生成,同步 Worker 更直接。如果题目量大(每门课 100+ 题)或者题目生成要跑大模型、需要异步排队重试,异步消息队列更稳。你的"AI 创课助手"现在一门课大概多少题?

FDE:起步阶段每门课 5-20 题,但后面 K12、大学场景会上 50-100 题。

AI:那建议选 B。异步队列起步成本高一点,但后面撑得住 100+ 题的场景;同步 Worker 撑到 30 题就开始撞超时。

FDE:拍板。题目生成走异步消息队列。

对话跑完。这一轮比上一篇那一轮长——对话 4 段,涉及 DDD 三限界划分、SDD Spec 端长期挂载、TDD 三层审计、工程化取舍四个主决策。

你可能也注意到了——这一轮对话和上一篇对话风格完全不一样。上一篇是 FDE + 老师 + AI 三方,这一篇是 FDE + AI 两方。AI 的角色从"业务追问者"变成了"工程方案共谋者",而 FDE 的角色从"业务翻译官"变成了"工程决策者"。

还有一件你可能也注意到了——这一轮对话,AI 严格按 Spec 端挂载的追问规则、JSON Schema 校验规则、题型规则、难度规则、4 轮+1 汇总硬约束跑,跑得一丝不苟。AI 不懂 ADD,但 AI 能把 ADD 跑得比人更稳。

这一句你记下来。菜谱表挂得越稳,AI 跑得越稳——Spec 端规矩焊死的回报,就在这一句话里。

下面我们把这四个主决策一个一个拆开讲。

三、DDD —— 三限界上下文切分,业务边界焊死在限界上

我们把"三限界上下文"这件事摆到桌面上。

上一篇我们说过,业务边界 = AI 边界。这句话在工程上怎么落地?落地成DDD 战略设计的三限界上下文——把整个"AI 创课助手"切成 course、question、media 三个圈,每个圈有自己的通用语言、聚合根、上下文映射关系。

course 限界上下文(主域)——课程结构本身。

• 聚合根:Course(课程) / Chapter(章) / Section(节) / KnowledgePoint(知识点)
• 通用语言:course / chapter / section / knowledgePoint / prerequisite / bloomLevel / estimatedHours / difficulty
• 责任:课程结构管理 + 知识点编排 + 课时分配 + 布鲁姆目标挂载
• 不做的事:不生成题目、不存材料(那是另外两个上下文)

question 限界上下文(支撑域)——题目配置与生成。

• 聚合根:ExamConfig(题目配置) / Question(题目)
• 通用语言:examConfig / questionType / difficulty / score / questionCount
• 责任:题目类型管理 + 难度分级 + 分值分配 + 题目生成与校验
• 不做的事:不管课程结构、不存材料

media 限界上下文(支撑域)——材料存储与检索。

• 聚合根:Material(材料) / Reference(引用关系)
• 通用语言:material / referenceId / ragContext / uploadTime
• 责任:上传材料存储 + RAG 检索 + 引用关系维护
• 不做的事:不管课程结构、不出题目

三个上下文之间怎么"打交道"?

• course ↔ question:Customer-Supplier 关系(course 是客户,question 是供应商)。课程定稿时,question 接收 course 的触发信号,出对应题型。
• course ↔ media:Published Language 关系(共享消息格式)。课程定稿时,course 发事件给 Kafka,media 订阅并同步材料引用。
• course ↔ course内部:同一个上下文内用通用语言沟通。
• 三仓 ↔ 共享内核:布鲁姆动词表 + 知识点 ID 规范 + prerequisites 字段——这套共享内核三个上下文都要遵守,不许私自扩展。

厨房比喻——三个工种分区。course 是切配工种,负责把原料(课程结构、知识点)按规范切好;question 是装盘工种,负责把切好的料装盘摆盘(出题);media 是仓储工种,负责把原料存好(上传材料)还能快速取出(RAG)。三个工种各自有台子、各自有刀具、各自有食材,不混领域语言,各管一段。

你可能想问:为什么不全塞一个上下文里?切三个不是很麻烦吗?

因为不切分,AI 越能干越糊。三个上下文混合在一起,通用语言就乱了——课程说的是"知识点",题目说的是"题型",材料说的是"上传文件",这三套语言被 AI 混着学,它就会写出"在知识点里塞题型枚举"这种错乱的实现。

切分之后,每个上下文有自己干净的领域。AI 在 course 限界内只能写 course 的话,在 question 限界内只能写 question 的话。业务边界 = 工程边界 = AI 边界——这句话落到 DDD 上,就是三限界上下文的清晰划分。

下面这张图把三限界上下文 + 上下文映射 + 共享内核画出来。

四、SDD 双端 —— 墙上挂菜谱表 + 服务员点菜单,规矩长期挂载 AI 才守得住

我们把"SDD 双端"摆到桌面上。

上一篇我们说过"4 轮追问 + 1 轮汇总硬约束是 Spec 端长期挂载的——AI 忘掉一次,下次还得听你的"。这一篇我们就把"Spec 端长期挂载"这件事工程化展开。

SDD 不是单次临时提示词,是双端架构——

• Story 端:工程师(本篇是 FDE)与业务(本篇是老师)的对话脚本。老师只聊业务需求,FDE 按 ADD 追问、AI 产出 JSON、老师 review、Exam 配置、定稿。
• Spec 端:AI 工作台前置打底,人长期沉淀。Spec 端不参与单次交付,它挂在 AI 工作台配置里,所有 Story 端对话都自动遵守。

Spec 端长期挂载什么?

挂四类规则——

第一类:ADD 追问规则。每一轮追问必须覆盖 ADD 8 维度(A 学员/A 目标/A 任务 + D 结构/D 内容/D 练习/D 反馈/D 难度)至少一个,4 轮累计不能漏 5 个以上维度,第 5 段必须是汇总确认。这套规则不靠 AI 自己悟,Spec 端直接挂——AI 跑就完事。

第二类:JSON Schema 校验规则。courseName / description / totalHours / scenario / targetAudience / bloomTaxonomy / structure / knowledgePoints / examConfig 九字段必填;scenario ∈ {enterprise, k12, university, other};contentType ∈ {text, exam, lab};difficulty ∈ {beginner, intermediate, advanced};totalHours > 0;estimatedHours > 0;score > 0;prerequisites 中的 id 必须存在 structure 里(非孤儿引用)。Schema 库走 jsonschema(行业成熟、生态全),Spec 端挂 Schema 文件,Story 端 AI 写出来的 JSON 必须过这道闸。

第三类:题型规则。questionTypes ∈ {choice, fill, coding, essay, judge}——五个枚举值,不许出现"scenario"“drag”"match"之类的自由发挥。这是上一节"AI 跑偏"那个糊法的正面治理。

第四类:难度规则。难度三档 beginner / intermediate / advanced,艾宾浩斯遗忘曲线调整建议——beginner 章节后必须有 intermediate 章节复习,intermediate 后必须有 advanced 章节强化。这条规则不是死规矩,是 Spec 端给的"软秩序",AI 在规则内自主决定每章难度比例。

第五类:4 轮+1 汇总硬约束。这是上一篇反复强调的——超过 4 轮追问,用户体验崩。这条 Spec 端直接焊死,AI 不许追问第五轮。追问规则不是 AI 学出来的,是 Spec 端长期挂载的——AI 忘掉一次,下次还得听你的。

这一句是这一节的金句——上一节只是埋钩子,这一节正面回答。

Story 端跑什么?

跑对话脚本,只关心业务——

1. 老师提需求(“我要做 Java 培训,40 小时,企业培训”)。
2. AI 按 Spec 端挂的 ADD 追问规则开始追问(4 轮 + 1 汇总上限,自动遵守)。
3. AI 按 Spec 端挂的 JSON Schema 校验产出物。
4. 老师 review,修改字段。
5. AI 按 Spec 端挂的修改一致性审计重算依赖。
6. Exam 配置(题目类型、数量、难度、分值)。
7. 定稿,推给下游 Agent。

这一圈跑下来,工程师(FDE)只聊业务,所有技术规范不再说第二遍。Spec 端挂了,Story 端跑就完事。

厨房比喻——墙上挂菜谱表。Spec 端是厨房四墙挂满的各种菜谱表:ADD 8 维度追问菜谱表、JSON Schema 9 字段校验菜谱表、题型规则菜谱表、难度规则菜谱表、4 轮+1 汇总硬约束菜谱表。这些菜谱表是新人进厨房必读的——AI 进工程(进厨房)前必须读完,后续做菜(对话)自动遵守。

Story 端是服务员点菜单——服务员(工程师)只听顾客(老师)说"我要一份 Java 培训",不涉及任何厨房技术细节。厨房(AI)看到菜单后自动按墙上菜谱表匹配做法。

下面这张图把 SDD 双端的双轨结构画出来。

五、TDD —— 三层测试护栏,AI 时代的 TDD 是焊死的闸,不是装饰

我们把"TDD 三层护栏"摆到桌面上。

这一节是这个工程范式里"最硬"的一层。DDD 锁业务边界,SDD 焊技术规范,但业务边界锁得再死、技术规范挂得再稳,AI 也可能写出"逻辑没错但实现糊"的代码——比如它把 “prerequisites” 引用了不存在的 kp,语法对、类型对、字段对,但引用断了。

这种事光靠 DDD/SDD 抓不出来。要靠 TDD 三层测试护栏自动拦——

第一层:追问覆盖度审计。

• 每一轮追问必须覆盖 ADD 8 维度至少一个。
• 4 轮累计不能漏 5 个以上维度。
• 第 5 段汇总确认前必须校验覆盖度。

具体怎么测?跑一个脚本,读 Spec 端挂的追问记录(每轮追问对应了哪几个维度),对照 ADD 8 维度表,数漏了几个。漏超过 5 个 → 测试失败 → AI 重跑追问。

这条审计把"AI 漏问关键维度"的事挡在 Story 端开始前。

第二层:JSON 合法性审计。

• 必填字段校验:courseName / description / totalHours / scenario / targetAudience 必须有值。
• enum 范围校验:scenario ∈ {enterprise, k12, university, other};contentType ∈ {text, exam, lab};difficulty ∈ {beginner, intermediate, advanced};questionTypes ∈ {choice, fill, coding, essay, judge}。
• 数值范围校验:totalHours > 0;estimatedHours > 0;score > 0。
• 引用完整性校验:prerequisites 中的每个 id 都必须在 structure 里能找到(非孤儿引用)。

具体怎么测?跑 jsonschema 库(行业成熟、社区大),把 Spec 端挂的 JSON Schema 文件和 AI 输出的 JSON 都喂给它,任一规则不过 → 测试失败 → AI 重写。

这条审计把"AI 字段填错、枚举跑偏、引用断链"的事挡在 JSON 入库前。

第三层:修改一致性审计。

• 用户改 JSON 后,关联的 prerequisites / examConfig / 学习目标必须重新校验。
• 删除章节时,该章节下所有 prerequisites 引用必须清除或重新指派。
• 改 totalHours 后,所有 estimatedHours 加起来必须等于或接近 totalHours(允许 5% 误差,因为有非学习时间的过渡)。

具体怎么测?跑一个 diff 脚本,读旧 JSON 和新 JSON,把所有字段的引用关系重算一遍。任一关联不一致 → 测试失败 → 提示用户重新审视修改。

这条审计把"改了字段没同步"的事挡在每次修改后。

三层加起来的工程价值——

JSON 字段错一个,整个课程结构就崩——TDD 是焊死的闸,不是装饰。

这一句你记下来。它是这一节的金句。

具体怎么落?三层都跑在 CI/CD 流水线上——任何修改推 PR 之前必须三道闸全过,任一不过直接拦截。覆盖率不达标、enum 跑偏、引用断链、改字段不同步,这些"AI 写糊"的失败模式被三道闸死死卡在 PR 合并之前。

厨房比喻——试菜员。每一份 JSON 出锅前,试菜员尝一口:覆盖度这道菜(追问有没有漏关键维度)、合法性这道菜(字段填全了没、enum 跑了没、引用断了没)、一致性这道菜(改了字段后关联同步了没)。三道菜都合格 → 盖 ✓ 章出菜;任一不合格 → 盖 ✗ 章退回重做。

试菜员不关心你怎么炒菜,只关心出锅的味道对不对。这就是 TDD 的定位——只测"业务规则 + 流程结果",不测"具体怎么实现"。

下面这张图把三道闸画出来。

六、工程化取舍 —— 4 个决策摆桌面上,选哪个不拍脑袋

我们把"工程化取舍"摆到桌面上。

三件套(DDD / SDD / TDD)是工程范式,但范式落到代码还要做 4 个具体决策——对话状态用什么存、材料怎么上传、JSON 怎么解析、题目怎么生成。这 4 个决策选错,工程跑起来会卡死。

我把这 4 个决策项 + 选项 + 推荐理由列成一张表——

下面我展开 3 个最具说服力的取舍。

取舍 1:JSON 解析——Schema 库 vs 自研正则。

这条最容易翻车。我一开始想自研正则——“JSON 必填字段校验嘛,正则几行写完”。但跑通发现三个问题:①正则表达 JSON 嵌套结构很痛苦,prerequisites 数组里嵌对象、对象里嵌数组,正则写出来像天书;②字段增减时正则要重写;③跨语言复用(以后给 Python 工程师对接)正则迁移成本高。

换成 jsonschema 库——JSON Schema 是行业标准规范(json-schema.org 维护,主流 draft 2020-12),社区 60M+ 周下载。Schema 文件独立维护,AI 产出的 JSON 喂给 Validator,任一规则不过直接报错。这条决策推荐 A。

取舍 2:对话状态——Redis TTL vs DB 长期存档。

这条是反直觉的。我一开始想"对话状态肯定要长期存档啊,老师下次来还能接着聊"。但跑通发现两个问题:①长期存档意味着隐私风险——老师跟 AI 聊的学员画像、课程目标全在 DB 里,合规要求高;②多轮追问是单次会话行为,老师下周一再来,业务场景可能完全变了,旧对话状态毫无价值。

换成 Redis TTL ≤ 24h——多轮追问跑完就过期,第二天来开新对话。隐私风险为零,DB 没冗余数据。这条决策推荐 A。

取舍 3:题目生成——同步 Worker vs 异步消息队列。

这条最具争议。我一开始想"题目生成又不复杂,同步 Worker 直接跑就行"。但跑到第三门课(综合考核出 5 道 coding 大题),发现 Worker 卡了——大题调用大模型单次耗时 30 秒,Worker 同步等 30 秒,前端超时。

换成异步消息队列(Kafka)——题目生成任务扔进队列,Worker 异步消费,前端轮询结果或 WebSocket 推送。这条决策推荐 B。但 B 不是绝对推荐——如果你这门课只出 5 道选择题,同步 Worker 就够了,别上消息队列增加复杂度。

这 4 个决策摆出来不是"标准答案",是"具体场景下的取舍"。FDE 的工程能力不是"会选 A"或"会选 B",是**“知道为什么这么选,知道换场景会怎么变”**。

工程化的真正价值不是复杂度,是复杂度可被消化——一次创建,多次复用。

这一句你记下来。它是这一节的金句。

七、写在最后 —— 这间智能厨房搭完了,资产还能沉淀下来

回到开头那个反直觉的判断——业务模型有了,工程模型是把业务边界焊死、选择放开。

这一篇给你看了一件事——怎么把"9 字段业务模型 JSON"落成"可跑的 Agent 产品"。这条路走通了:DDD 切三限界上下文(course 切配 / question 装盘 / media 仓储)、SDD 长期挂四类规则(ADD 追问 / JSON Schema / 题型 / 难度)+ 4 轮+1 汇总硬约束、TDD 三层护栏(追问覆盖度 / JSON 合法性 / 修改一致性)、工程化取舍 4 个决策。

DDD 锁业务赛道 / SDD 挂技术规范 / TDD 卡审计红线 / 留白区让 AI 飞——这四层加在一起,就是一间按秩序搭好的智能厨房。抽象方法论一旦落地为可复用工程骨架,AI 时代的工程师才算真正从"每次重复告知规范"里解放出来,把精力放在业务本身。

留白区在哪?留白区是题目具体怎么出——Spec 端挂的题干规范之内,AI 自由发挥。这是 34 篇没展开、留给后续实战去拆的钩子。

资产沉淀 —— 一次创建,多次复用

这一节就是价值复利段——上面这套方法论跑通之后,沉淀下来的不是"这一个项目",是可被后续多个项目复用的资产。

我把这套资产列出来——

资产 1:可复用的 ADD JSON Schema。任何课程(企业培训 / K12 / 大学 / 其他)都可套这个骨架。九字段(courseName / description / totalHours / scenario / targetAudience / bloomTaxonomy / structure / knowledgePoints / examConfig) + Schema 校验规则(必填 + enum + 数值范围 + 引用完整性)是一个通用模板。换场景只改 scenario 字段 + 模板字段,Schema 不用动。

资产 2:追问模板库(三场景)。企业培训 / K12 / 大学三个场景,每套追问模板不一样——企业培训模板主问"学员起点 + 时间预算 + 终点项目",K12 模板主问"年级 + 学期 + 升学目标",大学模板主问"专业 + 学分 + 毕设要求"。AI 按 Spec 端挂的场景自适应选模板。

资产 3:布鲁姆动词表(36 词)。remember / understand / apply / analyze / evaluate / create 六层每层 6 个标准动词(Define / List / Recall / Describe / Explain / Summarize / Execute / Use / Implement / Differentiate / Distinguish / Examine / Judge / Assess / Critique / Design / Construct / Develop / etc.)。这套动词表是共享内核,任何课程共享。

资产 4:真实课程实例(Java 社招 40h JSON)。上一篇我们跑通的那份"Java 社招新人 40 小时速成"完整 9 字段 JSON 骨架,可以直接复用到任何"Java 培训"业务——只改 targetAudience / structure / knowledgePoints / examConfig 字段,其它字段保持。

资产 5:TDD 自动化审计脚本。追问覆盖度审计 + JSON 合法性审计 + 修改一致性审计三套脚本,任何 ToB 业务可套。这套脚本与 1-4 资产联动——JSON Schema 改了,审计脚本自动跟着改;追问模板改了,审计脚本自动跟着改。

这 5 类资产加在一起,就是"AI 创课助手"项目从一次性交付变成可复用产品的关键。它也是专栏"价值复利、脱离时间换钱"立意的工程化呈现——做一次,沉淀下来,后面任何类似业务都能复用。

下面这张图把"一次创建、多次复用"画出来。

这一篇留给你的

读完这一篇,你能拿走三件事——

• DDD 三限界上下文切分法——course 切配 / question 装盘 / media 仓储,业务边界 = 工程边界 = AI 边界。下次接 ToB 业务,把这种切法直接套。
• SDD Spec 端长期挂载模板——ADD 追问规则 + JSON Schema + 题型规则 + 难度规则 + 4 轮+1 汇总硬约束,挂上去 AI 跑就稳。
• TDD 三层测试护栏脚本骨架——追问覆盖度 + JSON 合法性 + 修改一致性三道闸,CI/CD 流水线自动拦,AI 写错直接退回。

这三件事,是你能直接搬到下一个 ToB 项目里的工具。不是方法论——是工具。方法论再多,落到工具上才能用。

业务模型有了,工程模型有了。这间智能厨房搭完了。

行,这一篇就到这儿。

关于 ArchAIHarness

这篇文章是「看懂 AI 与智能体」专栏的一部分,由ArchAIHarness持续输出。

ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产,主张:

架构师定义秩序,AI 在秩序中生长。人立法,AI 执行,体系审计。

如果你也希望 AI 在明确的架构边界内协作,而不是在混沌中碰运气,欢迎到 GitHub 上看看我们在做什么:

• 组织主页:github.com/ArchAIHarness — 了解完整理念与资产全景
• 本专栏:zhuanlan-ai-and-agents— 所有文章的源码与发布记录
• 实践指南:docs— 架构哲学、工程方法和落地指南
• 开源工具:agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools
• 工程样例:framework— DDD + AI 协作的工程底座,展示如何在开发中融合 AI

Engineered by Architects · Empowered by AI · Audited by Discipline