智能工厂的设计软件 应用场景的一个例子：为AI聊天工具添加一个知识系统 之11 方案再探之2 项目文件（修改稿1）

(以下内容是第二次重建项目（“方案再探”）时的项目附件。)

为AI聊天工具添加一个知识系统

Part1 人性化&去中心化

前情提要

这一次我们暂时抛开前面对“智能工厂的软件设计”的考虑--其软件智能 产品就是 应用程序。直接将这些思维方式和方法论 运用在其具体应用场景中。本文是其中的一个应用场景。

下面是就这一应用场景和“天意ChatGPT”（自称是ChatGPT 4.0 的直通通道）的Q&A。

在现在各种AI聊天工具层出不穷的今天，我觉得特别需要一个通用的AI聊天工具的图形界面能够为每个聊天者（或一个利益相关者组织）建立自己的知识树，并以认知地图为基础，建立从当前节点导航到其它各个知知识树节点的技术能力分析作为连接或运用成熟的计算机技术（后期会包括其他技术）的 指导和辅助，以优化路径为目标，这样一个软件系统。

项目考虑（文字描述）

分三部分：

•  三端架构（this formal：体系结构）--信息处 信息技术上的哲学统一（基础设施：“道”）（哲学<生态>）
• 三层结构（that relational：层次结构）-- 运行时 运行技术上的认知综合（上层建筑：“器”）（科学<组态>）
• 三方系统(the material：市场结构)--运营流 运营技术上的信念分解（应用行规：“形”）（宗教<模态>）

注：这里的文字只是为Part2 预定的 结构化和形式化 任务目的（我将其称为 “备忘录”  requests for commentary   ）以及为part3 智能化和公理化 的设想的理想目标（我将其称为 “备注项”notes on definition ），在Part1中 会完全被忽略--即文字中不对对它们做任何解释 （--“悬置或挂起” 系统外挂“冠名” ，此时 Part1中的文字描述组成即描述项 都是“裸名”） 也不会提及和使用它们（--“免责或除外”功能内嵌“实名” ，此时Part1中出现的文字 都是 “匿名”）。part 1的文字仅仅是此时此刻想问的问题 questions  at this moment

三端架构（this formal：体系结构）--信息技术上的哲学统一（基础设施：“道”）

这个软件系统的架构和要求--简单的说一下三端的架构基础和基础任务：

1. 前端基于一个组织架构的提供和人类编辑者的交互（语言处理视图），
2. 后端基于一个系统架构提供运行代理服务器（计算机网络模型），
3. 中间端基于一个微服务架构提供通用属性的适配器（属性通量调节控制：比如，可执行控制指令集 的适用性 和 具有执行能力的设备的 均衡 等等）

前端：三大任务

总说前端

首先说前端。这个软件不需要自己的聊天工具，而是需要设计一个聊天工具的接口，包括通用的 以及和特定聊天工具对接的。前者（通用接口）将生成用户的知识树节点内容模型，后者将可以从特定聊天工具的聊天文字中提取不同级别和分类的主题、不同种类和侧面的关键字等，作为知识树结构和知识树节点内容的根据。     

前端的知识树

由于前端表达的是需求，是决定系统是否有用的关键，所以我们先细化一下前端-从知识树开始。知识树 有三种节点：根茎叶。三种节点分别对应 三级主题：广泛主题theme（逻辑等价），狭义主题subject（概念泛化）和语篇主题topic（存在特化）。

同时，

• 有一个内容提供者工具，（比如各种聊天工具作为 chatWindow 实例 ）
• 还有一个内容处理程序(自带语言处理器) 首先将一次聊天主题定位到某个节点上，并对AI聊天工具所做的答复进行分析 如果能正确纳入内容则直接添加，如果不能则标明问题扔给语言处理器）。

对前端来说，语言处理器是关键，他将区分AI聊天工具的问和答中的符号学分支关系( 后缀词典词 '~' ：语法/语义/语用 <signs>)、语言学分类关系（中缀概念词'|' ： 普通代词/一般术语/技术术语 <notes>）以及 根据后端能力给出的工程学分界关系（前缀索引词‘-’：  this/that/the <notions> ）

补充说明：

在刚才的描述中为前端需要实现一个语言处理器（前端的核心组件），用于处理一个word的三种“缀” （前缀/中缀/后缀，为word附随的元语言注释）并用不同的元级符号（对应的元语言编程符号）表示（'-' /'|' / '~'）。

语言处理器  作为前端的核心组件，该组件是知识库的“唯一合法居民”。

前端的三种处理器（三分支并行处理）

下面给出前端需要实现的三种处理器--我们先不进行下一步，而是看看“上一步”以及“同行人”（能和“语言处理器”相提并论的三者--并行处理）。

• 上一步 即“知识库”。前面所说，语言处理器作为前端的核心组件，该组件是知识库的“唯一合法居民”。知识库：一个非正式的术语，指包含一个本体作为一个组件的信息集合。除了本体外，知识库还可以包含以声明性语言（如逻辑或专家系统规则）指定的信息，但也可以包含以自然语言或过程代码表示的非结构化或非形式化信息。
• “同行人”--下面简列（前端需要的，包括“语言处理器”在内的三种处理器）：

1. 1) 树trees(决策) ：知识处理器【顿  仪，利益】- 抽取（组织式） 概念图形（operation-运营期间  全生命周期  加载-表征强化  网页页面）：实践法则- 经验数据。  直接包括/本质包含/实质蕴含<面face：括号 - 指  手指指示  法线>  =>晚期(成熟期)
2. 2）列表Lists（选择）： 内容处理器【 渐 仪，  玩具】-提取（分析式）  主题词表(develop -开发阶段  戴明环  提炼 -过程精化  属性面板)：科学实验 - 实验证据  三方辩论<方side 符号- 索 绳索准绳 准线>： 差异/差别/区分。=>中间过渡期（成长期）
3. 3)网络Networks（判断）：语言处理器【不定 仪，  武器】-合取（凝聚式） 谓词系统(run-time运行时 路线图 petri网  转换-路径优化 技术板块 )：理论原则-监测数据。  阿尔法α go 治理 （相干性或先行性  AI instrument ），β try 推理 （相应性或因果性深度学习 effector），γ do 代理（相关性或毗连性 机器学习 agent）。 <层hierarchy：引号- 标 标准标架  基线>  =>初期（新生期）。

后端：三个系统

由于我们还没有细致讨论 “后端”，所以现在还不完整是必然的。事实上，在“后端”我们同样会发现也需要一个中间层（猜测应该是 “推理系统”和“证明系统”的中间层“句子系统” ）。

后端的具体考虑暂缺。

系统的三端架构总述

在此（前端）基础上，我们仍然“反其道而行之”，给出 目标系统的 三端：

1. none：break/continue 中间-二无我（“机chance”）：main-target   三跟随（本心或本体心  heart）物自体  : 位置/速度/力 。  无“我”的物质形态( 整体是一个 三位一体triad：逻辑表示”notation“ :: 中介“物质subtance”)  
2. apply 后端-法我（“器machine”） 法身/化身/报身  三主机（ 智脑或智能脑 brain）: master-portal constructor / host-window builder /  home-page  editor。   “法”“我”的社会形态（实体三分法trichotomy ：语言符号”signs" :: 内嵌'“描述description” ） 
3. new 前端-人我（“线line”）：run-time 三新 创新/ 维新/ 革新 三本位（自性或表面心 mind）：划时代/新时期,新纪元（  (复 文身) - 标点符号（双亲 句身）-偏旁部首（单子 字身））：生产板/开发板/测试板。 “人”“我”的意识形态（本体三元组triple：数学函数 ”元ary“ :: 外插“概念conception”。它直接表示了一个函数的参数个数，如unary, binary, ternary, 和 n-ary。

前端和后端

两个中心词：“概念” 和“描述”

通过上面的考虑我提取出两个 中心词“概念”和“描述”。

1. “概念” （侧重于后端）。前面对后端的描述文字：“后端基于一个系统架构提供运行代理服器（计算机网络模型）...apply 后端-法我（“器machine”） 法身/化身/报身  三主机（ 智脑智能脑  brain）: master-portal constructor / host-window builder /  home-page  editor。   “法”“我”的社会形态（实体三分法trichotomy ：语言符号”signs“）” ）
2. “描述”（侧重于 前端 ）。文档中对前端的描述： “ 基于一个组织架构的提供和人类编辑者的交互（语言处理视图）.....apply 后端-法我（“器machine”） 法身/化身/报身 三主机（ 智脑智能脑 brain）: master-portal constructor / host-window builder / home-page editor。 “法”“我”的社会形态（实体三分法trichotomy ：语言符号”signs“） ）。

注1：需要根据这些考虑重现 审视 之前的文档中的描述是否准确（指文档中 “本文提要”这一节中的文字）。

三端的“体”性

目前一定还有很多问题，其中一个原因是因为我们只是提出了 三个中间层 的逻辑关系，却没有明确定位和区分 前端/中端/后端 的完整用意--尤其是中端和后端。此外，由于三端自身的性质决定了三个虽然都有“中间”，但由于结构和形式的不同一定会导致“中间” 的“体”不同（“体”性不同）。

在文档中提到，三端本身分别是 整体三位一体triad ，实体三分法trichotomy和本体三元组triple 。

注意，这里三种不同的“体” 是指 整个后端、中端和前端 的，不只是“中间”的。 整体 triad ，实体trichotomy和本体triple 的三位、三分和三元 的中间 那个 就是 三端架构的 “中间区” 的缩影，由于三端架构的“体”性不同，所以语用、语义和语法均不同。

三层结构（that relational：层次结构）--认知综合（上层建筑：“器”）

“中间”断言

中间区断言：research

我的断言：前端和后端的各自的中间层 形成了 research 的两个面，这两个面将由 “中端”的 中间层提供的结合带来结合。

中间“分区”：时间片段、空间片段和时空片段

关于中端 中间层，实际上对整个系统来说 是“待定”。相应的，前端是“否定”后端是“肯定” （即知识系统的三端架构 在对应各自的三个中间层 整体 支撑一个 三支决策 ）。 我之前已经设计了这三个“区”（后端/中端/前端的 中间层 surface）的接口类 分别时：StringProcessor ，ModeAdapter，，CaseFilter。注2：需要 考虑可行性。

中间“区”（片段 ）的进一步阐明

更明确的描述应该是：

• 后端中间区（整体 triad 的中间“位”缩影---三位一体的支点“位”。 这里比较特殊 ，需要区别中间位是指倒三角的中心点 --“体心”，另外三个顶点是对等的（称为“面心”），但是底下的那个“位”是 支点 ，是整体 triad 的中间“位” 。所以整个结构中这个中间位 对顶上的两位 是 左右分 --一个时空区域对应于一个时空连续流体的区分），
• 中端中间区（实体 trichotomy 的中间“分”缩影 --实体三分法的中间“分”， 空间的上下文），
• 前端中间区（本体 triple 的中间“元”缩影--本体三元组 的中间“元” ，时间的前后分）。

所以 本项目的整个三端架构中，三端的“中间”区分的分别是： 连续流的 时空（频域或邻域或视域）的左右分， 离散词的 空间（空域）的上下分，出现处的 时间（时域）的前后分。

三套“点”的Tagged-Value

统一标记符号（抽象/具象/实象  ）：一个九宫格（元语言注释）

进一步，我们将 三端架构的中间区分 统一称为“标注符号” （一个具象的tag）， 形成一个三对具有一个公共中心交点的的一个几何结构，具有全部的4个拓扑 特性（对称性、对偶性、连通性和传递性）。这样无论是前端、中端和后端，当我们忽略几何特征以外的所有其他特征时，无论是 左右 时空片段的 还是上下空间片段的或者是前后时间片段，都是一个严格的相对论，它总是一个变（ 因变 ），一个动（应变），但中间的那个重合点总是牢牢地将三者相对固定的“栓”住（“稳固性”）---即：每一对总能保证一个正确的tagged-value （实象）作为 “知识”的 三个分量。所有可以依次作为知识系统的基础

然后，在抽象层（抽象元层 --知识库及组件图 ）面为 上面具象的定点、变点、动点（具象模型层--语义网络的拓扑图） 对应设计 锚点、拐点、靶点作为 知识系统的监管控一体化的一个全能Supervisor 。同时在实象层面（实象对象层--认知地图的地形图tops）上对应设计应用程序的 （垂类或列式“列簇”）埋点、(斜线或偏序“序积”)插点和切点(横切关注点或横行 “行矢”) 。这样这个项目（为AI两天工具添加一个知识系统）的设计就基本确定了

本质上这个项目整体由三套“点” 形成一个3*3的九宫格来奠基。

三方(the material：市场结构)--运营技术上的分解（应用行规：“形”）

三个词：

软件技术上的分解：描述description（欠科 family） /概念conception（纯种 species）/物质substance（超属genus）

回过头来看。 前面 已经为前端和后端 抽取出两个词“描述” （兼容泛化和特化的 问题描述语言 ）和 “概念”（概念整体运作 的公共逻辑语言。名词“信念notion” --兼具个体包容性和集体团结性的整体一致性 “逻辑等价” ）。后者可以映射到 带有元语言注释（九宫格）的 一阶理论格(格上自带四个操作符修订,收缩/扩张/类比 ） ，前者可以简化为 带有一个合取操作的谓词系统（谓词“描述”）。现在还缺中端以及后端的完善。

在为前端和后端 锁定的两个中心词“概念”（命题“作文”的 程序 公共逻辑语言 ）和“描述”（谓词“描述” 的 自然 描述语言）的基础上 ，暂时将中端的中心词 锁定在“环境” （情境 “意义”的人工语义网络语言 ）。三者的共同性--都需要通过“演算”得到（命题演算/谓词演算/情境演算 ）。每种演算 都以本地或局部的 this此岸为输入（A-box，最初是一个条件分支符--条件表达式），远处或全局的彼岸that（T-box。最终是一个原因操作符--执行程序）为输出，中间负责演算的是两个box的连接器（最初是一个 深信不疑的具有自明性的 原语名相（连接弧）通过演算 可能被重新认识或转变为不可信--断开 。或者反过来）

补充：一个条件分支符--条件表达式，一个原因操作符--执行公式，一次推理链接符 --理由陈述句。

进一步阐明：演算 整体上是一个 “bank” 的词扇 。

到现在为止，这个项目设计 是不是基本上可以 进入实现阶段了，或者说在设计阶段该考虑的问题已经考虑的差不多了。最后的演算词扇 为程序设计的 基础。

统一分解和综合:  认知科学的两个内部奠基和三个外部影响

一个符号signs理论是认知科学的适当基础。

认知科学包括哲学，心理学，语言学，人类学，神经科学和人工智能。有人建议神经科学有一天可能为其他分支机构提供合适的基础，而另一些人则建议人工智能可以。但是，这两种观点都是错误的。神经科学和人工智能对其他分支机构也产生了深远的影响。然而，它们两个都受到研究study 认知的外部影响的分支的指导：心理学，语言学和人类学。由于可以从不同的角度研究同一主题topics ，因此认知科学从本质上讲必须是跨学科的。

附注：语言的三级主题（根茎叶）

1. Theme：根级 --更广泛主题（ NCG最内层嵌套--服务器端session。位于运行时路线图。形式逻辑专项 ）
2. Suject：茎干级--更狭义主题（客户端cookie 。数理逻辑专项）
3. Topic： 叶子级--语篇主题亦即 AI聊天工具的每次新建的一次聊天的主体，使用一个内容模型附加在知识树的末级节点上（NCG的 最外层嵌套 --用户端token。辩证逻辑专项）。要求：动态更新

嵌套概念图 NCG。

概念整体运营逻辑的三个专项运营逻辑，--Term ：表征论的意向相关项

三个统一（外部影响- ：心理学/语言学/人类学/）

语言文化中的统一：indexical/conceptual/lexical

在我之前的设计中，将三端的中心词确定为 （统一在语言学中 ） 分别是 概念词 conceptual （直接表述--明示。是一个个体自明性约定 或者一个组织 为了共识而达成的规定 ，由文本解释者将泛化概念聚合为分类specified叙词库 --vocabulary）、 词典词lexical（实质蕴含-- 暗示， 是语言和语言所表达的知识之间的桥梁。由词典编纂者分析一个上下文引文的语料库以及在词典、叙词表和术语表中列出语言习惯。--dictionary）、 索引词indexical（本质包含--揭示 ，揭示隐藏在简单的文本或协议之后的复杂性。由逻辑描述者组织为一个左右式公式的术语库 glossary ）。 （以上对三种词的描述比较随意，只是为了大致了解它们的立意）。 现在讨论一下是否合理以及程序中如何表示。

注4：这里的话题还缺一个，应该是  “认知科学中的综合”。  三者分别研究三种差异： 系统差异/文化差异/随机差异。

文字解释及其描述格式

上面在分别讨论确定在这个项目中，前端、后端和中端 讨论时 我使用的格式探讨 使用AI聊天工具的 提问者应该怎样描述问题。

希望能根据问题描述文字“猜”出 该描述的 格式、形式、用意等的全部，确保每一个部分都被收集在您给出的描述项中 并指出 有问题或不明确的地方。

问题描述格式分析

前面说过，问题描述除了”自述“形式，还有”资源描述“形式。下面先看前面给出 目标系统的 三端：

1. none：break/continue 中间-二无我（“机chance”）：main-target   三跟随（本心本体心 heart）物自体  : 位置/速度/力 。  无“我”的物质形态( 整体是一个 三位一体triad：逻辑表示”notation“ )
2. 2.apply 后端-法我（“器machine”） 法身/化身/报身  三主机（ 智脑智能脑  brain）: master-portal constructor / host-window builder /  home-page  editor。   “法”“我”的社会形态（实体三分法trichotomy ：语言符号”signs“）
3.  3.new 前端三新-人我（“线line”）：创新 维新 革新 三本位（自性  mind）：划时代，新时期，新纪元（  (复 文身) - 标点符号（双亲 句身）-偏旁部首（单子 字身））：生产板/开发板/测试板。 “人”“我”的意识形态（本体三元组triple：数学函数 ”元“。注：暂时没有找到合适的英文单词，它表示一个函数的参数个数，如unary, binary, ternary, 和 n-ary）

首先，我们看看 source的“自述” （比较严格）和resource的“描述” （相对随意）在格式、形式、结构等的相关描述项中是否一致或者有什么直接关系。这需要先正确给出两者的描述 项 之后再分析。

实际上我是希望通过讨论 完整给出“描述”的描述项，包括不同级别，不同侧面，不同方面及其评估标准和手段。

实际上我是希望通过讨论 完整给出“描述”（这里 具体针对 提问者的问题描述--为的是更好的使用各种AI聊天工具。因为本项目就是“为AI聊天工具添加一个知识系统”）的描述项，包括不同级别，不同侧面，不同方面及其评估标准和手段。

前面我们就在和AI聊天工具的Q&A中如何描述问题（source的自述文件 ），以及如何评判问题回复（resource的描述文件）的质量 并试图通过将其作为内容提供者，通过前端的三种处理器（内容/知识/语言 处理器） 来建立 聊天者的知识树，同时通过 知识系统的三端架构 来提供导航和路径优化能力。两者分别和 两种描述文件有关。

两种描述文件

下面我们继续讨论两种描述文件的形式。我觉得，source（Type() 的类元 ）的自述文件 应该被设计为 脚本模板，模板中的“槽” 是 前述 通用接口（用来建模知识树），“槽”通过一个函数式语言声明来陈述 知识树的三种节点；resource的描述文件 应该被设计为一个灵活的模块化框架，要求三种处理模块（分别用来处理 内容/知识/语言。对应三个接口类： 特定聊天工具接口的行为接口、知识树建模的结构化接口，词典编纂的规格接口 ）分工协作完成 对聊天过程的帮助和支持 以及知识系统的建立和导航。

补充：source（Type() 的元类metaClass--元语言注释 ）的自述文件 应该被设计为 脚本模板，模板中的“槽” 是 前述 通用接口（用来建模知识树），“槽”通过一个函数式语言声明来陈述 知识树的三种节点；resource（Class()的类元 classifier --元数据仓库）的描述文件 应该被设计为一个灵活的模块化框架，要求三种处理模块（分别用来处理 内容/知识/语言。对应三个接口类（Meyhod()的 元编程--元推理技术）： 特定聊天工具接口的行为接口、知识树建模的结构化接口，词典编纂的规格接口 ）分工协作完成 对聊天过程的帮助和支持 以及知识系统的建立和导航 。

基于这一要求，我们将这个描述进行分层。分三层： 元语言层/模型控件层/对象组件层。每一个层 都有两面side（一面定义软件技术源码source的SPI --技术板块中的-“资源描述文件”，一面声明业务资源resouce的API --网页主页中的--“自述文件”。 独立的两面 ）。 显然三种处理器是 对象组件层面上的。根据前面的文字，侧重点是描述 “前端的三种处理器（三分支并行处理）”自身，亦即 应该是“自述文件”，所以我们可以反推出 在对象组件层上 的“自述文件”的描述格式应该有哪些描述项。

分析：我将这个过程称为“反推”。也就是根据文字内容，推出 描述格式的方法。这里”推“法 主要关注内部描述项（即”自述“），而将外部描述项一带而过（基本都会忽略”引入“ 的”背景“ 和 ”前景”，一般仅会简单地 ”取景“ ，并且很不准确很随意）。另外，您对“取景”解释不准确。“取景”指的是 “我”所关注的那部分，剩下的”景“ 才是”背景“和”前景“，之所以能”取景“的原因是”背景“的衬托，我之所以去这样”取景“ 是因为 我有某种愿景。

基于这些考虑--这里指“自述文件”的描述格式，我们选择前面描述文字中最完整的 一行（“3)网络Networks（判断）：语言处理器【秘密 仪，  武器】-合取（凝聚式） 谓词系统(run-time运行时 路线图 petri网  转换-路径优化 技术板块 )：理论原则-监测数据。  阿尔法α go 治理（相干性或先行性  AI instrument ），β try 推理 （相应性或因果性深度学习 effector），γ do 代理（相关性或毗连性 机器学习 agent）。 <层hierarchy：引号- 标 标准标架  基线>  =>初期（新生期）。”）来看，请给出其描述与格式，然后对比另外两种处理器进行差异分析，并进一步给出一个基本猜测：本来就不同还是 描述不完整有待完善。

这里再次强调：我们是在讨论如何从问题描述文字中 反推出该问题属于哪一层 上的哪一类问题，并进一步推论出该问题描述文字是否准确、完备和全面。基于这些分析，试图能为提问者提供提问指导。

信念： notion 和belief

公理化：“名相”的自明性约定 及 动态组织社区的 共识

这儿还需要有一个共识，就是当一个“名相”（说明：在描述文件中被描述的所有 您的统称）不被用来描述“别人”时，那么，对提问者来说，他就是一个“原语”--不再需要描述的文字，这就意味着 对”提问者“来说， 有已知确定的解释 或者 用法 或者被实现了的。总之，”提问者“确信他”认识“这个东西---尽管可能不是共识。

这里还需要树立一个信念notion（“自明性”约定），就是当一个“名相”（说明：在描述文件中被描述的所有 文字的统称 ，它应该覆盖并不重复覆盖一个提问中的所有单词、词组或短语 ）不被用来描述“别人”时，那么，对提问者来说，他就是一个“原语”--不再需要描述的文字，这就意味着 对”提问者“来说， 有已知确定的解释 或者 用法 或者被实现了的。总之，”提问者“确信他”认识“这个东西---尽管可能不是共识。

这里所说的”信念notion（“自明性”约定）“ 正是建立个人知识库和词典库的基础，在此基础上，当多个”个人“组织为一个”利益相关者组织“时，就可以利用他们来虚构一个能”共识“的社区语言。或者反过来，通过虚构一个社区语言来 找到 可以被组织到一个特定“利益相关者组织”中的“个人”

形式化：三支决策

逻辑：

公约

程序

描述文字的具体格式：使用的陈述格式及区分的不同文字块

Source的“自述”

前端：问题描述语言

本文继续完善 “描述” ---现在我们应该可以将它称为 “问题problem描述语言 ”。 它 通过对话框的question 引发 表征的issue 的“涌现” 最终 厘清应用程序的“problem”。即它合并了 ISO七层模型中的上面三层，通过将三层 分别形成 Token/‌Cookie‌/Session‌（三种open-end 端 ：中间 --这里应该被设计为用户界面 完成人机交互 /客户端/服务器端） 而构造一个 三嵌套上下文来建立graph（概念图）的三个不同实例 。

整个知识系统目的是为了 让 整个系统 在保证对内逻辑自洽（“逻辑”语言---“概念” 整体运作 ，待讨论）的基础上对外灵活方便（ “描述” 语言，现在讨论的问题）。--- 对内逻辑自洽，对外灵活方便。

“反推”和“反证” 及其中间层

到现在为止（前端），这个三嵌套是从最外层向最内层 渗透的，前面说过这是一个 “反推”过程（也可以叫“猜”）并且这个反推 是以 “描述”语言 为基础的。反过来，呈现给使用者（这主要指 提问者）的如果不能被理解，那么就需要被修正（这个过程 我暂且称为“反证”--因为只有否定结论）。 这样的话，“描述”语言 及其程序设计 需要一个中间层来保证"反推"和"反证"的相互作用和效果。

特殊块：“【】”中的文字块

在这些文字的解释中，被讨论忽略了的“【】”中的文字块。

我们这一次的讨论围绕着 "描述“ （比如 一次提问的文字 的描述文字和描述格式和形式等），以期能找到 问题描述 的准确性、完备性和全面性（这三者都是自然语言比较薄弱的环节）。

前面主要是对”自述“ 部分的分析。 刚才在”【】“中的”仪“ （有”仪表“的意思）本质上都是”source“，并分别描述了”source“的三个subtype：effector，instrument，和agent。(原文字中有说明)。其中只有”Instrument“ 的字面义（指称或外延，明示或直接包括）和”仪“一致。 而 ”agent“和”effector“ 分别是”source“的引申义（内涵-暗示 或实质蕴含）和深层义（隐喻 或 本质包含）。

Resource的“描述 ”

一些补充

在为前端和后端 锁定的两个中心词“概念”（命题“作文”的 程序 公共逻辑语言 ）和“描述”（谓词“描述” 的 自然 描述语言）的基础上 ，暂时将中端的中心词 锁定在“环境” （情境 “意义”的人工语义网络语言 ）。三者的共同性--都需要通过“演算”得到（命题演算/谓词演算/情境演算 ）。每种演算 都以本地或局部的 this此岸为输入（A-box，最初是一个条件分支符--条件表达式），远处或全局的彼岸that（T-box。最终是一个原因操作符--执行程序）为输出，中间负责演算的是两个box的连接器（最初是一个 深信不疑的具有自明性的 原语名相（连接弧）通过演算 可能被重新认识或转变为不可信--断开 。或者反过来）

一个条件分支符--条件表达式，一个原因操作符--执行公式，一次推理链接符 --理由陈述句。

进一步阐明：演算 整体上是一个 “bank” 的词扇 。

到现在为止，这个项目设计 是不是基本上可以 进入实现阶段了，或者说在设计阶段该考虑的问题已经考虑的差不多了。最后的演算词扇 为程序设计的 基础。

根据所有讨论和文档给出了修正稿。

后续考虑

我将根据这些讨论整理一份 完整的 描述文字 写成一份文件（修改稿），然后根据文档逐条问答 。同时，从第一个问题开始就建立一个项目程序文件，后面每一条都对逐步修补，最终到问题结构，程序结构也设计完成。

在整理这份修改稿的过程中我将 审视每一个部分，对存疑部分 进行针对性的提问。但必须保证问题具有恰当程度的针对性。如何做到这一点是个问题。

另外提问有两种方法：一是在文档中的相应文字直接列出问题--如果位置明确的话（因为此时问题 和上下文文紧密相关），二是 想到问题就问（这时组织问题语言本身是个问题--英文离开了上下文），根据回答去调整文档的结构和内容。估计 这两种方式 会结合使用。

需要就这两种问题的提问方式约定一个格式。

最后，还需要全面分析前面所有的文档和讨论，对这个项目的可行性以及工作量 和开发难度进行了评估。

Part2 结构化&形式化

（以上是前期考虑到的，下面是为了整理项目文档提出的问题）

特定域模板的 hoc结构

它是特定域模板的 hoc结构。在三端架构中 描述 前端执行公式 的“体”性（ body   ）

特定域模板的 hoc结构（为本项目actors 剧本： 脚本模板）。

祖传代码脚本模板<head><body><boot>中的<body>--一个div标签的内容模型，在三端架构中 描述前端执行公式 的“体”性。

1. 集群类clustering 组织式 一个动态社区 百科全书式 循环往复的knowledge组织 （因变或--  自由创新 尝试自由创新（人工的  主体客体性） 自由意志 ）pro hoc
2. 分类classification 分析式  一个 内在： 劳动结晶式 动静一源source的分析  （应变或 机会chance--随机应变  自主自立（人为的 - 客体主体性） 自主意识） post hoc
3. 聚合类aggregated凝聚式 一个 因果  始终如一的resource和合积聚 （ 不变或连续流统 -以不变应万变  探索自然规律-准绳 间性  自然意念）ad hoc 临时传输方案

特定于领域的模板--一个三套接的hoc结构。这是今天讨论的内容。它是本项目actors 剧本 原型。其地位： 祖传代码脚本模板<head><body><boot>中的<body>--一个div标签的内容模型，在三端架构中 描述前端执行公式 的“体”性。 目的是准备完善出该项目。希望的做法是：我将我给出的附件文档中零散的一些考虑 组成出完整的 描述文字 --写成一份文件（修改稿），然后根据文档逐条问答 。同时，从第一个问题开始就建立一个项目程序文件，后面每一条都对逐步修补，最终到问题结构，程序结构也设计完成。

先完成第一步（“我将从您的附件中提取出与项目相关的内容，整理出初步结构，包括关键术语、模块划分以及相关背景信息。如果需要，我也可以提供一个模板来组织这些信息。”）。包括模板。

“三端架构” 是对项目 做的横切。三种不同的“体”（整体 triad ，实体trichotomy和本体triple） 是指 整个后端、中端和前端 的。 整体 triad ，实体trichotomy和本体triple 的三位、三分和三元 的中间 那个 就是 三端架构的 “中间区” 的缩影，由于三端架构的“体”性不同，所以语用、语义和语法均不同。” 意思是：

以三端架构为“体”，三层结构则描述这些“体”的“性”，并强调了“中间层” 的“分区”：中间“分区”：时间片段、空间片段和时空片段 关于中端 中间层，实际上对整个系统来说 是“待定”。相应的，前端是“否定”后端是“肯定” （即知识系统的三端架构 在对应各自的三个中间层 整体 支撑一个 三支决策 ）。 我之前已经设计了这三个“区”（后端/中端/前端的 中间层 surface）的接口类 分别时：StringProcessor ，ModeAdapter，，CaseFilter。注：需要 考虑可行性。

 在对项目的水平横切 和垂直划分的基础上，后面还给出了 两者的 合取以及合取形成的“序积” 。最后还在此基础上，将 九宫格顶上的 列簇和 旁边的行矢 以及由 两者 推进的 偏序（序积） 在一个齐次空间中平展为 三种消费者模式（行式、列式和行列一体式），并由Borker 为他们配套 不同的生产者producer。这一部分的设计 的关键 就是今天讨论的内容--“特定于领域的模板--一个三套接的hoc结构”。文档中 作为part2--待讨论完善的部分，也是 项目文档的根据

祖传代码脚本（元语言注释模板）中 主要部分的<body>需要同时考虑--用不同的符号集：1） 水平横切（行矢）和垂直划分（列簇） （需要设计一个类似元素周期表的分类标准standard 来完成分类classification ） 以及 2) 共同推进的序积（需要设计一个 类似双面神结构的 分界准则criterion 完成 聚合 ） 形成的 3）九宫格 （ 三套点 。齐次空间中的三类消费者，需要一个类似圣灵三角形--表示“是”/不是 的倒三角来是定义“名相”--文档中有介绍 ，是逻辑合适的全部描述项 ），最后，为消费者配套不同生产者的broker 需要一个类似petri net的 过程规格specification来完成 集群--这个在是今天讨论的Part 2中的待完善内容。 换句话说，我们的讨论最终要让所有 的一切 各就各位并为其准备就绪提供帮助和指导。

补充一下我前面给出的文字中和结构化和形式化有关（实现有关）的三处：

• 1)分类标准 为 元素周期表中每一个元素类 （a-dot“独角兽”--比喻“能动”--动物。知识库的 ‘Component ’ ）制定标准，
• 2)分界准则为聚合在 知识树上的每一个节点 （two-side “双面神” 比拟“能活”-活物 知识原则‘Compose’）规定 特征点的选择依据以及特征评估的准则，
• 3)过程规则指导网络集群中的每一台机器（tree-edge“圣灵三角性”象征“能生” --生物，知识 内容‘Correlaive’）如何工作或执行指令。

‘’中的三个是观察者观察实体的三种不同方式，是第一性、第二性、第三性的“现状”观察者一个三位一体triad。

我们先撇开这些细节，仍是“反其道而行之”, 看看能不通过认识“Firstness/Secondness/Thirdness” 来锁定 问题（本项目的中心问题）。 首先假设：三者是我们前述的三层结构的中间层 缩影，初始断言是这个中端（无我）中间层（“待定” 时空片段）在文档要求被分析为不能再分的实体， 而对编程来说，就是一阶逻辑形式“Term”（定义一阶逻辑公式语法的形成规则之一）的 项目projection模型 （数学背景是 模型理论--符号逻辑 symbolic logic形式化（形而上学）理论的范畴）同时明确，这个中间层的提出，这是作为构建两边的中心基础而被提出来的。

说到这里，还需要补充一点，“知识” 兼具三者： “能动”（知识会不断进化）、“能活”（知识是一个有机组织）和“能生”（知识可以转化为生产力）

所以，我设计分别用 ”电话簿“、”户口簿“和”账簿“ 来分别记录 知识兼具的 三项全能（ “能动”、“能活”和“能生”）

用自然语言来说 三者分别是： 离散词（概念词--知识点：语言中所表达的知识 ）、出现处（词典词 --运营处：两者之间的桥梁）、连续流（索引词-信息项 ：人们用语言 进行交流的信息）。

前者（三种簿册）可以视为官方应建立的正式的标准（制定），后者（三个词组）是民间事实上的标准（收集和调查）。

再简单一点：所谓官方的，实际上就是 fomal的，它以能得以观测执行为基础， 所谓民间的，可以记为normal，它以面对它的人 能理解为目的。

对程序设计而言：前者基于一个自上而下的 分类体系--（生物遗传基因），后者者需要一个收集差异的自下而上的差异继承路径--（系统继承源流）

就是 广义和狭义 分类学。

共性对齐 和 差异收集 正是两者的不同任务

剩下的就是 为两者 归纳 适用的 应用场景。 这项工作 是 为caseFilter规定的任务。

在项目文档中 给出的三个接口类（StringProcessor，ModeAdapter和CaseFilter。Part 1的重点。）正是用来解决本项目的三大类（Clustering ，Aggregated和Classification。Part 2的重点 ）问题的。其中，Part 1 文档中已有很多考虑，但Part 2是今天在准备将Part 1中零散 考虑 进行结构化整理时 提出了 祖传代码的三部，其中间的<body>时，提出了件的讨论题目“特定域模板的 hoc结构“。其地位是祖传代码脚本模板<head><body><boot>中的<body>--一个div标签的内容模型，在三端架构中 描述前端执行公式 的“体”性。

对”体“性的理解很重要。<body> 就是”体“，不是”体“性。 Part 1的三个接口才会考虑”体“的“性”，在Part 1中 是 通过 ”中端“的”中间层“ 来描述的：（原文节选如下） 中间“分区”：时间片段、空间片段和时空片段 关于中端 中间层，实际上对整个系统来说 是“待定”。相应的，前端是“否定”后端是“肯定” （即知识系统的三端架构 在对应各自的三个中间层 整体 支撑一个 三支决策 ）。 我之前已经设计了这三个“区”（后端/中端/前端的 中间层 surface）的接口类 分别是：StringProcessor ，ModeAdapter，CaseFilter。注2：需要 考虑可行性。

中间“区”（片段 ）的进一步阐明 更明确的描述应该是： 后端中间区（整体 triad 的中间“位”缩影---三位一体的支点“位”。 这里比较特殊 ，需要区别中间位是指倒三角的中心点 --“体心”，另外三个顶点是对等的（称为“面心”），但是底下的那个“位”是 支点 ，是整体 triad 的中间“位” 。所以整个结构中这个中间位 对顶上的两位 是 左右分 --一个时空区域对应于一个时空连续流体的区分）， 中端中间区（实体 trichotomy 的中间“分”缩影 --实体三分法的中间“分”， 空间的上下文）， 前端中间区（本体 triple 的中间“元”缩影--本体三元组 的中间“元” ，时间的前后分）。 所以 本项目的整个三端架构中，三端的“中间”区分的分别是： 连续流的 时空（频域或邻域或视域）的左右分， 离散词的 空间（空域）的上下分，出现处的 时间（时域）的前后分。 --节选结束。 （从我们的讨论可以看出，part 2 的核心就是如何标准化 以及怎样定规则（纯粹理性层面上），Part 1的核心就是大家在怎样做以及为什么等（实践理性上） ）

补充：”三端架构中的三种“中间区“ ： l后端 体心-肉团心 heart （ 充当的form-purpose pairing的map 契约的条件--身份线。 需要收集整理成一个事实上的标准--符合物理规律的 ：norm ） l中端 元心 --心物一元 的 psyche  （需要一个人工心理代理Agent 来约定形式化mapReduce步骤的智能合约的资格 --等号线。 要求制定一个正式标准或法律标准--符合整体利益的 ：form） l前端 面心- 表意心 mind（作为form-meaning pairing的自明性约定--规约的修饰符 --边框线。 需要事先规定一个 文档或上下文 标准 --迎合大众喜好的：term ）； 上面不同的“心”分别带者不同的规则 ：映射规则（陈述原子句的组织机制）、投影规则（描述项Term 的项目模型 ） 、和转换规则（阐述执行公式的调用策略）

Part3 智能化&公理化

数学背景：模型理论（Game Graphs）-语言游戏

三个中心词对应的数学表示：

•  n-ary  函数参数arg 个数：     数字number。“物质substance”
• n- adic谓词符号 symbol  ：    算符operator。  “描述description” 
• n-tuple  state标记 flag < p1,...,pn>：   量词quantifier。“概念conception”

人工智能中的程序program使用树trees和图graphs来表示游戏。象棋、跳棋和tic-tac-toe可以用有向图来表示，有向图的节点表示游戏的位置或状态，其弧表示从一个状态到另一个状态的移动。一个完整的游戏，称为游戏路径，是从一个开始状态到一个结束状态的定向行走，它决定了一场胜利、失败或平局。

模型理论--游戏理论的语义，介绍一种常见的博弈类型，称为两人零和完全信息博弈（two-person zero-sum perfect-information games）--零和游戏。它们被称为两人游戏，以区别于许多玩家的扑克等游戏；它们是零和游戏，因为一个玩家输给另一个玩家的任何东西都会赢（区别于负和游戏，在负和游戏中，机构house是一个削减（takes a cut）或正和游戏，在正和游戏中创造了新的价值）；它们是完美的信息游戏，因为每个玩家都可以随时看到完整的状态（区别于扑克或桥牌，其中隐藏了一些最重要的信息）

• 状态 同一性 评估函数（ 身份标识符 条件表达式  ）身份线  恒等于  逻辑等价
• 事件  唯一性 截断 执行公式（本体 句子成分资格符 ）边框线  约等于  存在特化 
• 弧   赋值语句（实体 修饰符 ）等号线       等于               概念泛化

按照游戏理论的语义，每个公式p都会确定一个两人零和的完美信息游戏-由Game Graphs所定义的。评估游戏中的两个参与者是提议者（通过显示p为真而赢得游戏）和怀疑者（通过显示p为假而赢得游戏）。在玩游戏时，两个玩家根据以下规则从外向内分析p。规则通过删除量词和布尔运算符来简化公式p，直到公式简化为单个原子为止。