diff --git a/llms-full.txt b/llms-full.txt
index b11a69a..15972ab 100644
--- a/llms-full.txt
+++ b/llms-full.txt
@@ -1399,13 +1399,7 @@ requestParams为请求参数列表，response为返回结构，requestParams中
    TOC自动生成的类和方法会带有@AutoGenerated注解，注解中有2个属性:locked为boolean类型，如果locked=true，则代表该文件或方法不建议修改;uuid为String类型，表示该类或方法的唯一标识，如果uuid中包含|字符，则说明该uuid为特殊格式，由不同类型的数据拼装而成(见**[3.2 设计元素到代码的映射规则及修改建议]**中每种设计元素的代码说明）。
 
 ### 4. TOCO 最佳实践
-#### 4.1 设计分析结果应用(Design analysis results application):
-    在TOCO中，设计分析(transferToPlanAgent工具)的结果按照用户的要求或需求的复杂度分为2种，你需要分辨流程分析的结果类型，然后根据不同类型做出不同的后续工具调用规划:
--   1.**细节设计分析**：针对简单或短流程需求，会直接进行读写方案、接口等分析、代码编写等结果。此时需要根据工具规划后续的调用。
--   2.**流程拆解设计分析**：针对复杂需求，不会直接分析细节的设计元素，而是根据内聚、解耦、复用等原则，参考**流程服务（Function_Flow)**对业务需求拆解为多个短流程并返回结果。后续需要针对整体的API的定义、流程服务定义、**所有**流程节点中涉及的**所有**DTO、VO、读写方案、RPC等来进行对应的工具调用。注意此时**必须**调用createFunctionFlow工具来创建流程服务。
-#### 4.2 为所有的写场景都创建写方案(Create WritePlan For All Write Scenarios):
-    通常在分析业务需求时，需要分析出**所有**写数据的场景，并按照**聚合维度**进行分组，然后针对每个写场景**都需要**创建对应的写方案，不能有遗漏。写方案可以按需根据聚合进行合并。
-#### 4.3 接口参数类型和返回值选择(Interface Parameter & Return Type Definition):
+#### 4.1 接口参数类型和返回值选择(Interface Parameter & Return Type Definition):
     在做TOCO接口(API、RPC)设计时，通常会先判断接口的主要功能是读数据库或写数据库，并分析相关的读写方案以及对应的QTO和BTO。如果是读场景，则参数会**优先使**用相关的QTO；如果是写场景，则参数会**优先**使用相关的BTO，如果BTO和QTO无法满足要求，则可以再增加基本类型或Enum、EO等类型参数。参数类型选择时必须遵循以下要求：a.DTO、VO不能作为参数类型；b.QTO、BTO不能作为返回值类型。
     **重要说明：** 
     - 本章节描述的是参数选择的**优先级原则**，不是绝对限制