法律智能体设计师(LAD)，是指能够将法律专业知识与人工智能应用能力相结合，利用法务AI平台独立完成法律智能体设计搭建、调试和持续优化的专业人员。

LAD的工作不是简单“使用AI”，而是把法律专业经验转化为可以运行、可以复制、可以持续优化的法律智能体。具体包括:工作流定制、输出格式定制、资料库/知识库/Skill定制，以及自主完成工具调用配置等。通过这些工作，LAD可以为本企业或客户提供个性化、实用的法务AI应用。

目录

基础篇

第1章　法律人与LAD

1.1　法律人为什么要成为LAD？

1.2　法律人为什么能主导法律智能体的开发？（为什么社会需要LAD？）

1.2.1　法律智能体的核心难题，不只是技术问题

1.2.2　法律智能体需要的不是普通法律知识，而是可执行的法律任务结构

1.2.3　为什么需要法律人主导，而不是技术人员主导？

1.2.4　AI和低代码平台，使法律人具备了主导的现实条件

1.2.5　法律人主导的是结构核心层，不是全部开发工作

1.2.6　社会为什么需要LAD？

1.3　一个延伸：AI时代，学一点编程知识，投入产出比急剧上升

1.4　法律人的机会主要在应用层 

1.4.1　基座模型层 

1.4.2　中间层

1.4.3　应用层

1.4.4　使用层

1.4.5　结论：法律人应把握在应用层的机会

第2章　AI与IT基础认知

2.1　AI、大模型、大语言模型（LLM）

2.1.1　AI是技术总称

2.1.2　大模型（Foundation Model）

2.1.3　大语言模型（LLM）

2.1.4　LLM与多模态

2.1.5　包括LLM在内的大模型技术本质上都是概率预测系统

2.2　法律模型（垂直领域模型）和微调（Fine-tuning）

2.2.1　什么是“法律模型”？

2.2.2　法律模型是怎么来的？

2.2.3　微调（Fine-tuning）

2.2.4　当前法律模型与微调在法律AI应用中的状况

2.2.5　NLP与大语言模型

2.3　Markdown(md）：与LLM沟通的基本语法

2.3.1　Markdown基本语法说明

2.3.2　Front Matter（FM）

2.3.3　AI时代，所有文件都将变成md或html？

2.4　JSON

2.4.1　JSON入门知识

2.4.2　为什么LAD需要掌握JSON格式？

2.5　YAML

2.5.1　对YAML的基本认识

2.5.2　高级LAD绕不开YAML格式

2.5.3　YAML语法要点

2.6　函数、工具、IPO与模块化开发

2.6.1　函数、工具、节点，本质上都是IPO

2.6.2　模块化开发，就是把多个IPO拼成更大的IPO

2.6.3　模块之间能否协同，关键在接口对齐

2.6.4　Process可以交给模块内部，LAD必须说清楚Input和Output

2.6.5　模块化思维对LAD的意义

2.6.6　LAD必须时时刻刻用IPO理解任务

2.7　SaaS、私有化部署与部署方式

2.7.1　SaaS 与私有化部署（软件的两种购买方式）

2.7.2　私有化部署与软件部署方式的关系 

2.8　抽象：追问事物背后的共通性

2.9　对程序语言的一些基础认知（以Python为例）

2.9.1　程序语言的本质：精确的命令

2.9.2　程序语言的基本要求

2.9.3　Python的微观层面：一行一行代码在做什么

2.9.4　Python的宏观层面：代码是如何“组织起来”的

2.9.5　库的意义：为什么“会写一点点代码就够了”

第3章　法律智能体的基本架构

3.1　WAFT架构

3.1.1　WAFT架构含义

3.1.2　WAFT四类组件之间的关系

3.1.3　WAFT架构的目的

3.1.4　一个法律智能体相当于复杂软件系统中的一个模块，通过“输入+输出”与其他模块交互

3.2　自顶向下设计，自底向上测试

3.3　先从MVP做起 

3.4　关于Dify

3.4.1　AI应用时代，为什么会有Dify这类低代码、可视化工作流编排系统

3.4.2　企业级AI应用开发适合用Dify吗？

3.4.3　LAD通过Dify来掌握智能体设计是当前阶段*优选择

3.5　一个企业需要多少个法律智能体？

3.6　从产品经理的角度，法律智能体开发相对于传统软件开发的不同之处

技能篇

第4章　工作流（Workflow）组件（一）：LLM节点

4.1　对LLM节点的基本认识

4.1.1　认知起点：一次输入→一次输出

4.1.2　LLM的知识结构

4.1.3　一次LLM任务的时长与输入输出的关系

4.2　提示词语法：应该向LLM提供什么样的输入？

4.2.1　给LAD的专门提示：面向AI时代的表达

4.2.2　基本语法：普通字符串、Markdown、程序语言的结构化表达

4.2.3　如何对输入内容进行分块

4.2.4　提示词“中英混杂”是必需的

4.2.5　*小输入原则

4.2.6　跟AI对话不需要讲礼貌

4.2.7　其他一些输入技巧补充

4.3　提示词模板

4.3.1　提示词模板：包含变量、输出要求的任务说明

4.3.2　法天使标准提示词模板（RTROI）

4.3.3　SYSTEM、USER、ASSISTANT是什么？

4.4　输出要求

4.4.1　LLM能输出什么？

4.4.2　根据*终输出要求，倒推对LLM的输出要求

4.4.3　*小输出原则

4.4.4　要求LLM输出JSON时，提示词怎么写输出要求？

4.4.5　如何减少LLM输出有误导致的程序报错？

4.4.6　延伸：Dify节点中的异常处理

4.4.7　延伸：如何实现一个有特定功能的内容输出？

4.5　模型配置

4.5.1　国内模型的选择

4.5.2　模型参数设置

4.5.3　关于模型上下文窗口容量

第5章　工作流（Workflow）组件（二）：工作流编排

5.1　工作流编排的基础认知

5.1.1　为什么要编排工作流？

5.1.2　工作流绝不是越复杂越好

5.1.3　工作流编排时的“工程化考量”

5.1.4　工作流编排仍将长期存在

5.2　工作流编排实操：串、分、并、汇与循环

5.2.1　串：串行，顺序处理

5.2.2　分：路由与分支决策判断

5.2.3　并：并行、拆分处理

5.2.4　汇：汇总多条工作链路的结果

5.2.5　工作流编排就是“串分并汇”的组合应用

5.2.6　“生成→反思”模式

5.2.7　“规划→执行”模式

5.2.8　分角色模式

5.2.9　投票机制

5.2.10　Dify中的迭代：实为并行批量处理

5.2.11　拆分（切片）处理的一个关键问题：如何让LLM看到“全局”

5.2.12　循环：相同提示词框架的串行调用

5.2.13　归纳：复杂工作流编排就是串、分、并、汇、循环的组合

5.3　代码节点：LLM节点的助手

5.3.1　代码节点主要干什么？

5.3.2　一个代码与LLM结合的示例：切块

5.3.3　让AI帮你写代码节点，你只需要提要求和适当测试

5.3.4　Dify代码节点的格式要求

5.3.5　随着LAD代码能力的增强，代码节点处理的事务会越来越多

5.4　归纳：工作流编排的基本原则

第6章　工作流（Workflow）组件（三）：从Agent到Skills

6.1　重申对LLM能力认知起点：一次输入→一次输出

6.2　工具与MCP：让LLM可以调用外部能力

6.2.1　传统的工具调用方式

6.2.2　为什么LLM需要调用工具

6.2.3　LLM调用工具的基础方式

6.2.4　进一步发展：让LLM在运行中决定是否调用工具

6.2.5　让LLM调用工具更加方便和标准：MCP

6.2.6　MCP工具通常需要说明哪些信息

6.2.7　LAD对MCP工具的关注点

6.2.8　归纳

6.3　AGENT=工具+循环工作流

6.3.1　ROUND1

6.3.2　ROUND2

6.3.3　ROUND 3

6.3.4　简要归纳

6.3.5　注意：MCP工具的输出与AGENT节点的读取

6.4　SKILL

6.4.1　一个Skill≈一个文件夹

6.4.2　简单版Skill的运行≈让AGENT节点调用文件检索接口

6.4.3　全面版Skill：更多能力

6.4.4　Skill的核心：渐进式加载

6.5　归纳：普通工作流、AGENT和SKILL的选择

6.5.1　三者不是替代关系，而是组合关系

6.5.2　普通工作流适合确定性强的任务

6.5.3　AGENT适合不确定性较强的任务

6.5.4　SKILL适合沉淀专业能力

6.5.5　三者的典型分工

6.5.6　复杂任务往往需要三者的结合

6.6　更可控，还是更灵活？（更靠人，还是更靠AI？）

第7章　知识库与RAG

7.1　RAG一般认知

7.1.1　RAG的含义

7.1.2　RAG使用场景梳理

7.1.3　LLM的“记忆”究竟是怎么实现的？

7.1.4　资料：GPT怎么记住我们的？

7.1.5　提示词工程、上下文工程与RAG

7.2　检索的一般知识

7.2.1　关键词检索（传统检索）

7.2.2　代码过滤（规则过滤）

7.2.3　语义检索（向量检索）

7.2.4　召回率（Recall）、精确率（Precision）、阈值、Top-K

7.3　检索方案（RAG方案）

7.3.1　检索步骤

7.3.2　query与chunk的设计

7.3.3　语义槽位对应query和chunk的字段

7.3.4　根据query的要求，考虑是否需要对原始输入进行“LLM提取转换”

7.3.5　了解BM25

7.3.6　混合检索：向量检索与 BM25 的融合

7.3.7　embedding 模型的选择

7.3.8　Rerank（re-ranking）与LLM重排

7.3.9　RAG环节的时长

7.3.10　注意被检索内容不等于输出内容

7.4　LAD该如何设计检索方案

7.5　切片方案

7.6　法务AI平台上的资料库、知识库与Skill

7.7　知识的未来，是结构化字段，还是自然语言？

资料篇

第8章　LAD应掌握的基础IT知识补充

8.1　正则表达式

8.2　Mermaid

8.3　HTML

8.4　软件之间的互通方式：API vs.SDK vs.嵌入式方式

8.5　Word文档解析

8.5.1　Dify中的文档解析功能

8.5.2　Word文档解析对法律智能体的重要性

8.5.3　Word文档解析的本质：从docx包中“取对东西、组好结构”

8.5.4　Word文档解析的几种常见方法（给LAD的认知版）

8.5.5　Word文档中的表格解析

8.5.6　关于后缀名为WPS的文档

8.5.7　LAD需要掌握到什么程度

8.5.8　开源Word文档编辑器

8.6　开源软件

8.7　Docker与容器：现代软件的“外卖盒”

8.8　URL的结构

8.9　HTTP和HTTPS（关联TCP/IP协议，Cookie，HTML，URL）

8.9.1　HTTP

8.9.2　HTTPS

8.10　Dify中如何通过http请求调用工具？

8.11　数据库

8.12　哈希值

8.13　LAD应掌握的AI常见相关术语