AI助手完成编程

这门课的主题很明确：用 AI 助手去啃一个真实的后端业务系统——HIS 门诊管理系统，重点不在"AI 能写代码"这个结论，而在"提示词怎么组织，才能让 AI 写出能用的业务代码"。它适合已经会写 CRUD、但对着一堆业务规则不知道如何向模型描述清楚的开发者。

技术栈与项目落点

课程选的是 HIS（医院信息系统）里的门诊管理模块，这个选型很有讲究。医生管理、科室管理、门诊挂号这三块业务，恰好覆盖了后端开发里三种不同类型的复杂度：医生管理偏基础数据维护，字段多、约束多、增删改查的边界条件碎；科室管理涉及层级关系和排班资源的关联；门诊挂号则是典型的高并发、有状态、有事务的流程型业务，还要处理号源扣减、重复挂号、退号回滚这些现实问题。

换句话说，这不是拿一个 TodoList 演示提示词，而是拿一个业务规则足够密集的场景来压测"提示词工程"到底能做到什么程度。你在课程里看到的提示词写法，是会跟具体的实体设计、接口契约、异常分支绑在一起的，而不是泛泛的"你是一个资深 Java 工程师"。

提示词工程的工程化视角

市面上讲 Prompt 的内容大多停留在单轮对话的技巧层面，这门课的切入角度更接近工程实践：把提示词当成需求规格说明的一部分来写。针对不同业务场景，提示词的颗粒度、上下文组织方式、约束表达方式都不一样。

• 基础数据类业务，重点在于把字段规则、校验逻辑、命名约定提前约束清楚，减少返工；
• 流程类业务，重点在于把状态流转和事务边界描述成模型能理解的分步指令；
• 涉及多表关联或跨模块调用的部分，重点在于控制上下文的信息密度，避免模型在长上下文里丢约束。

这些差异是课程真正想传递的东西。你学完之后应该能自己判断：面对一个新的业务模块，提示词该拆成几段、每段放什么、哪些约束必须显式写死、哪些可以留给模型发挥。

结构安排与自学路径

内容按"先概念后实战"的顺序推进，前半段建立提示词的基本认知和写法规范，后半段进入 HIS 项目的具体模块开发。这个顺序对自学者是友好的：如果你跳过基础直接看实战，很容易变成照抄提示词而不知道每一句为什么这么写。

建议的用法是边看边动手。每完成一个业务模块，先不看课程里的提示词，自己试着写一版，跑出来的代码再跟课程版本对照，差异点往往就是你对业务约束理解不到位的地方。配套的章节笔记适合在两个节点用：一个是每学完两三个小节做一次小结，把这一段的提示词模式归纳出来；另一个是临到面试或复盘时快速过一遍。

可复用的部分在哪

这门课真正能带走的东西有两类。一类是提示词的模板结构——针对增删改查、状态流转、批量操作、异常处理这些高频场景，形成你自己的一套起手式，下次换个业务系统仍然能用。另一类是让 AI 参与开发的工作流：怎么拆任务、怎么给上下文、怎么验证输出、什么时候该放弃让模型自己推断而改为显式指定。

演示的 HIS 系统本身不必照搬，把它当成一个规模合适、业务真实的练手靶子即可。学完后找一套自己的业务场景独立复现一遍，写进作品集，比单纯收藏这套资料更有价值。