From d898965f1c8bb8d7b5daa0085cd9a390f3f23eb0 Mon Sep 17 00:00:00 2001
From: xiongxiao <kevisual@xiongxiao.me>
Date: Sat, 21 Mar 2026 23:04:55 +0800
Subject: [PATCH] =?UTF-8?q?=E6=B7=BB=E5=8A=A0=20XYZ=20=E6=B3=95=E5=88=99?=
 =?UTF-8?q?=E6=96=87=E6=A1=A3=EF=BC=8C=E6=A6=82=E8=BF=B0=E5=90=8E=E7=AB=AF?=
 =?UTF-8?q?=E9=80=BB=E8=BE=91=E5=BC=80=E5=8F=91=E7=9A=84=E6=8C=87=E5=AF=BC?=
 =?UTF-8?q?=E5=8E=9F=E5=88=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 src/content/docs/xyz/index.md | 78 +++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)
 create mode 100644 src/content/docs/xyz/index.md

diff --git a/src/content/docs/xyz/index.md b/src/content/docs/xyz/index.md
new file mode 100644
index 0000000..766e190
--- /dev/null
+++ b/src/content/docs/xyz/index.md
@@ -0,0 +1,78 @@
+---
+title: XYZ 法则
+description: 现代应用开发 XYZ 法则。
+---
+## XYZ 法则
+
+这里关于后端逻辑开发部分的内容，总结，对现状开发程序的一些总结和思考，提出了 XYZ 法则，来指导后端逻辑开发。
+
+从 MCP 和 SKILL 的部分设计解析来看，XYZ 法则是什么？我为什么会提出这个法则？
+
+### 什么是 XYZ 法则？
+
+每一个程序的开发都可以看成是一个函数，输入是需求，输出是代码。这个函数的实现就是后端逻辑开发，很多的函数的组合成了一个大的系统。
+
+程序系统存在一个入口，而找到对应的这个函数，这个**定位**的过程，就是我需要讲的 XYZ 法则。
+
+函数在一个*二维空间中，x，y 轴就是函数的空间坐标*，z 暂时不需要，更期望 z 为时间类定位，现在不需要那么复杂度，二维空间就足够了。
+
+而我对 XYZ 法则，更喜欢叫 pkTime 法则（path，key，time），path 就是路径，key 就是函数的名字，time 就是时间维度的定位(time现状不需要）。三个合一，叫 Route，所有 Route 合并为 Router 系统。
+
+用分子原子的概念来说，函数就是一个原子，函数的组合成了一个分子，分子又组合成了一个更大的系统。每一个函数都有自己的空间坐标，路径和名字，这样就可以很清晰的去定位到这个函数。
+
+### 之前的 web 后端开发过程
+
+用简单一句话来说，就是 api 访问过程，而强调 rest 风格，就是让人更加简单易懂。现在 ai 的场景下，这整套逻辑已经变掉了，整个模式变为了 ai 模式，api 就是不应该存在的模式了。
+
+我来举个例子，之前的 rest api, `GET /user/info`。用 x, y 定位表达，就是 x 为 user，y 为 info。其他的任何的 method 去掉，所有的任何的参数聚合成对应的单个 `args` 的参数。
+
+用pkTime 来写这个函数，伪代码如下：
+
+```ts
+const route = new Route({
+  path: 'user',
+  key: 'info',
+  run: (ctx: { args: any }) => {
+    // 这里是函数的实现逻辑
+  },
+})
+```
+
+### 从 XYZ 法则的角度来看 ai 模式
+
+从 MCP 出来的之前，我就一直一直在想 xyz，一个函数，丢掉以前的 api 的历史包袱。在正常的运行过程当中，args 是入口参数，x 和 y 是函数的空间坐标。
+
+然后现在可以对他增加一些内容，description和 metadata。  
+- 描述是对这个函数的描述，可以观测到这个函数的功能是什么
+- metadata 是对这个函数的元信息，包含函数的属性、标签等信息，然后把实际需要的入参和出参都放在这里面。
+
+现在回到 MCP，就有一个优点了，XYZ 的的代码超容易转到实际的 MCP去使用，而我当初觉得 MCP 不好，正是因为他的设计模式还是基于一维模式，如果多个MCP，就得需要拆分，也就等同我设计的这中二维模式了。
+
+而我觉得 MCP 好的地方，在于他对以前的 api 风格，和我一样，添加了对函数的描述和 metadata 的设计，能够很清晰的去描述这个函数是什么，输入输出是什么，metadata是什么，这些都是非常好的设计。
+
+**MCP** 现在偏向于企业级应用开发，而不适合通用性，而后来 SKILL 出来了，这个 SKILL 属于通用性比较高，而且适合任何人去使用。
+
+#### SKILL为什么更通用？
+
+SKILL 的通用基于自然语言表达，AI 通过 cli，或者脚本去运行，实现轻便，容易上手，易于修改，适合任何人去使用。
+
+每一个 SKILL，具有的特定描述，特定的规则去定义，而他的规则是这种。
+
+1. `skills/{SKILL_NAME}/SKILL.md` 文件格式
+2. md 文档中包含了这个 SKILL 的 name 和 description 描述，输入输出参数的定义，以及一些使用的示例。
+
+`opencode`，`claudecode`，`openclaw` 这类工具，读取这些 md 文件，就可以把这些 SKILL 进行注册，进行调用。
+
+关注这几个开源库，`opencode` 和 `claudecode` 的支持全局 `skills`，然后又支持对应具体项目的 `skills`。而 `openclaw` 目前也推崇多 agent 的模式。而他们这是就是在解决一个问题。
+
+如果一个人的 `skills` 太多，几千个，几万个，怎么去管理，他们的最优解决方案是把这些 `skills` 分包和分层，项目级别，全局级别。从不同纬度去管理这些 `skills`。从 xyz 法则角度来说，xyz 就是根本上去解决这个问题的。
+
+XYZ 法则定义的函数，正因为空间坐标体系，对于坐标点的函数的定义附加 `metadata` 的 `description`，而这些东西是直接可以替代 `skills` 的。所以用 XYZ 进行开发应用来说，他能够直接转化为 SKILL 的模式的，甚至是 MCP 的模式的，因为设计模式上是兼容的。
+
+#### XYZ优点
+
+xyz 的优点就是他是一个函数的空间坐标体系，能够很清晰的去定位到这个函数，能够很清晰的去管理这个函数，能够很清晰的去调用这个函数。
+
+1. 他很容易被观测，可以很容易被可视化，轻松查看到这个函数的功能是什么，输入输出是什么，metadata是什么。然后容易启动
+2. 这只是一个法则，而这法则可以通用到其他地点，浏览器前端，后端，cli 应用，ai 相关的 mcp 和 skills，甚至是一些其他的应用开发的场景。只要是函数的开发，都可以用这个法则去指导。
+3. 通用在其他领域，比如文件存储，文章存储，`date/key` 模式都是属于 xyz 法则模式。