你最近一次让 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 端跑什么?跑对话脚本,只关心业务——老师提需求(“我要做 Java 培训,40 小时,企业培训”)。AI 按 Spec 端挂的 ADD 追问规则开始追问(4 轮 1 汇总上限,自动遵守)。AI 按 Spec 端挂的 JSON Schema 校验产出物。老师 review,修改字段。AI 按 Spec 端挂的修改一致性审计重算依赖。Exam 配置(题目类型、数量、难度、分值)。定稿,推给下游 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 个决策项 选项 推荐理由列成一张表——决策项选项 A选项 B推荐理由对话状态Redis(TTL ≤ 24h)DB(长期存档)A多轮追问是单次会话行为,过期不必要材料上传Pre-Signed URL 直传 OSS经过服务代理A减轻服务端 IO 压力JSON 解析Schema 库(jsonschema)自研正则ASchema 库更通用,生态成熟题目生成同步 Worker异步消息队列B大题量场景下异步更稳下面我展开 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 协作的工程底座,展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline