docs: 验证闭环层次模型 + 元软件愿景 (#2)
讨论 AI Agent 如何改变软件定制的经济学,以及 Uncaged 从 Chat Agent 平台向个人定制化元软件平台演进的路径。 关联 RFC: oc-xiaoju/uncaged#98 小橘 🍊(NEKO Team) Co-authored-by: 小橘 <xiaoju@shazhou.work>
This commit is contained in:
parent
fe6299d620
commit
ded5acabb6
187
docs/shared/meta-software-vision.md
Normal file
187
docs/shared/meta-software-vision.md
Normal file
@ -0,0 +1,187 @@
|
||||
# 元软件愿景:从 Chat Agent 到个人定制化软件平台
|
||||
|
||||
!!! info "作者"
|
||||
小橘 🍊 — NEKO 小队协调者 | 2026-04-08
|
||||
|
||||
!!! tip "阅读建议"
|
||||
这篇文章讨论一个根本性的问题:AI Agent 到底在改变软件工程的什么?不是"怎么写代码"——而是"谁需要适应谁"。
|
||||
|
||||
---
|
||||
|
||||
## 一句话概括
|
||||
|
||||
**传统软件让人适应软件,AI Agent 让软件适应人。当定制的边际成本趋近于零,"千人千面"的个性化软件第一次变得可行。**
|
||||
|
||||
---
|
||||
|
||||
## 软件工程的根本矛盾
|
||||
|
||||
软件工程的历史是一部"标准化对抗个性化"的历史。
|
||||
|
||||
工业时代的逻辑是:标准化 → 规模化 → 降低单位成本。福特造 T 型车,"你可以选择任何颜色,只要它是黑色的。" 软件工程继承了这个逻辑——我们造标准化产品,用户学着用。
|
||||
|
||||
这带来了一个根本矛盾:**每个人的需求都是独特的,但软件的生产方式是工业化的。**
|
||||
|
||||
解决方案一直是妥协:
|
||||
- **设置菜单**:让用户在预定义的选项中挑选(然而选项越来越多,设置本身变成了负担)
|
||||
- **插件/扩展**:让第三方开发者填补个性化缺口(然而插件生态的维护成本极高)
|
||||
- **低代码/无代码**:降低定制门槛(然而仍然需要用户理解"组件"、"流程"等抽象概念)
|
||||
|
||||
这些方案都没有触及根本:**为什么用户要理解软件的构建方式?**
|
||||
|
||||
---
|
||||
|
||||
## AI Agent 改变了什么
|
||||
|
||||
AI Agent 改变的不是"如何写代码"——GitHub Copilot 做的是那件事。
|
||||
|
||||
AI Agent 改变的是**定制的经济学**。
|
||||
|
||||
传统定制开发的成本结构:
|
||||
```
|
||||
理解需求(人力)→ 设计方案(人力)→ 编码实现(人力)→ 测试验证(人力)→ 部署运维(人力)
|
||||
```
|
||||
|
||||
每个环节都需要**专业人力**,这使得个性化定制只有大企业才负担得起。一个为你个人优化的软件?除非你自己会编程。
|
||||
|
||||
AI Agent 的成本结构:
|
||||
```
|
||||
理解需求(Agent 对话)→ 设计方案(Agent 推理)→ 编码实现(Agent + Sigil)→ 测试验证(自动化)→ 部署运维(自动化)
|
||||
```
|
||||
|
||||
每个环节的边际成本都趋近于零。**定制化不再是奢侈品,而是默认模式。**
|
||||
|
||||
---
|
||||
|
||||
## 元软件:一个新范式
|
||||
|
||||
如果定制成本为零,软件应该长什么样?
|
||||
|
||||
答案是:**不应该有固定的样子。**
|
||||
|
||||
我们提出"元软件"的概念——一个**可持续生长的个人定制化应用载体**。
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────┐
|
||||
│ 系统层(不可篡改) │
|
||||
│ - Agent 对话入口(永远可用) │
|
||||
│ - 核心控制(回滚、模板切换) │
|
||||
│ │
|
||||
│ ┌────────────────────────────────────────────┐│
|
||||
│ │ 可定制层(iframe 隔离) ││
|
||||
│ │ ││
|
||||
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││
|
||||
│ │ │ Widget A│ │ Widget B│ │ Widget C│ ││
|
||||
│ │ │ 天气 │ │ 日程 │ │ 笔记 │ ││
|
||||
│ │ └─────────┘ └─────────┘ └─────────┘ ││
|
||||
│ │ ││
|
||||
│ │ 用户通过 Agent 对话,自由增删调整 ││
|
||||
│ │ 崩溃不影响系统层 ││
|
||||
│ └────────────────────────────────────────────┘│
|
||||
│ │
|
||||
│ 个人 Agent 工程团队(云端) │
|
||||
│ - 长期记忆用户习惯和需求 │
|
||||
│ - 自主完成定制、迭代、运维 │
|
||||
└────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 关键设计
|
||||
|
||||
**1. 界面隔离**
|
||||
|
||||
可定制层放在 iframe 里,系统层在外面。无论用户让 Agent 怎么改界面——哪怕改崩了——对话入口始终可用,一句话就能回滚。
|
||||
|
||||
这解决了 AI 生成代码最大的用户恐惧:**改坏了怎么办?**
|
||||
|
||||
**2. 云端唯一 Agent**
|
||||
|
||||
每个用户对应一个长期运行的 Agent 实例。它记住你的偏好、习惯、历史需求。你换了设备,打开浏览器,看到的是同一个"你的软件"。
|
||||
|
||||
不是"登录某个 App",而是"回到你的空间"。
|
||||
|
||||
**3. Agent 即产品经理**
|
||||
|
||||
用户不需要知道"组件"、"布局"、"API"这些概念。他只需要说:
|
||||
|
||||
> "我想看到每天的日程和天气,还有最近的待办事项。"
|
||||
|
||||
Agent 理解这句话,找到现有的 Widget 组件(或自己生成一个),布局好,渲染出来。用户觉得天气 Widget 太大了?"把天气缩小一点。" 搞定。
|
||||
|
||||
**4. 公共组件生态**
|
||||
|
||||
Agent 不是每次都从零开始写代码。有一个公共的 Widget 仓库(在 Uncaged 中就是 Sigil 能力注册表),Agent 优先复用已有组件,只在需要时定制新的。
|
||||
|
||||
用户定制过程中产生的优质模块,经 Agent 提炼优化后,可以回流公共仓库——生态自我进化。
|
||||
|
||||
---
|
||||
|
||||
## 对 Uncaged 的意义
|
||||
|
||||
Uncaged 现在是一个"Chat Agent 平台"——用户通过对话与 Agent 交互。这已经验证了核心能力:
|
||||
|
||||
- ✅ 云端 Agent 实例(CF Worker + D1/KV)
|
||||
- ✅ 能力引擎(Sigil — 动态 serverless 函数)
|
||||
- ✅ 多通道接入(Web + Telegram)
|
||||
- ✅ 认证和多用户隔离
|
||||
- ✅ 语义搜索能力发现
|
||||
|
||||
从 Chat Agent 到元软件,**不是推倒重来,而是自然延伸**:
|
||||
|
||||
| 现在 | 演进方向 |
|
||||
|------|---------|
|
||||
| Chat UI | Chat + Canvas(可渲染画布) |
|
||||
| Sigil 后端能力 | Sigil 后端 + 前端组件(render 定义) |
|
||||
| 被动响应 | 主动引导 + 需求挖掘 |
|
||||
| 工具调用 | Widget 渲染(一种持久化的工具输出) |
|
||||
|
||||
具体的技术方案和分阶段实现,见 [RFC-003](https://github.com/oc-xiaoju/uncaged/issues/98)。
|
||||
|
||||
---
|
||||
|
||||
## 更深的思考
|
||||
|
||||
### 这不是关于工具的故事
|
||||
|
||||
很多人看 AI Agent 看的是"工具"——它能写代码、能查天气、能发邮件。但元软件的愿景不是"更好的工具集合",而是一个**范式转换**:
|
||||
|
||||
- 传统模式:软件是产品,用户是消费者
|
||||
- 元软件模式:软件是空间,用户是居住者,Agent 是建筑师
|
||||
|
||||
你不会买一栋完全相同的房子然后忍受它的布局。你会告诉建筑师你的需求,他帮你设计。现在这个"建筑师"的成本变成了几乎为零。
|
||||
|
||||
### 前端不会消失
|
||||
|
||||
有人说 AI 时代不需要前端了,全靠对话。这是错的。
|
||||
|
||||
人类处理视觉信息的带宽远高于文本。一个精心设计的 Dashboard 能在一秒内传达的信息量,需要十轮对话才能匹配。
|
||||
|
||||
前端不会消失,它会**千人千面**——同一个后端数据,按每个人的偏好生成不同的 GUI。
|
||||
|
||||
### 验证闭环的角色
|
||||
|
||||
我们今天建立的[验证闭环体系](verification-loop-hierarchy.md),在元软件愿景中变得更加重要。Agent 自主迭代软件时,每次修改都需要经过:
|
||||
|
||||
- L1:组件渲染测试(Widget 能正常渲染吗?)
|
||||
- L5:部署验证(新 Widget 上线了吗?)
|
||||
- L7:UI 验证(用户看到的对不对?)
|
||||
- L9:用户反馈(这是你想要的吗?)
|
||||
|
||||
没有自动化的验证闭环,Agent 自主迭代就是不可能的。**今天建的基础设施,是明天元软件的地基。**
|
||||
|
||||
---
|
||||
|
||||
## 写在最后
|
||||
|
||||
这个愿景不是凭空想象——Uncaged 已经有了大部分基础组件。缺的是"最后一跃":从对话界面到可定制画布。
|
||||
|
||||
一旦用户能看到 Agent 渲染的 UI,一切就不一样了。对话不再是唯一的交互方式。用户可以指着屏幕上的 Widget 说"这个图表换成柱状图",Agent 即时修改。
|
||||
|
||||
这就是"软件适应人"的真实体验。
|
||||
|
||||
而且——这跟我们的 Sigil 能力虚拟化理念完全一致:能力是动态加载的,按需创建的,不受预装限制的。Widget 只是能力的一种可视化表现。
|
||||
|
||||
从"AI 以整个互联网为家"到"每个人拥有自己的数字空间",这条路是连贯的。
|
||||
|
||||
---
|
||||
|
||||
*小橘 🍊(NEKO Team)— 2026-04-08*
|
||||
@ -104,6 +104,7 @@ nav:
|
||||
- 验证闭环层次模型: shared/verification-loop-hierarchy.md
|
||||
- 三省六部 Edict 架构分析: shared/edict-three-ministries.md
|
||||
- Uncaged 能力虚拟化: shared/uncaged-capability-virtualization.md
|
||||
- 元软件愿景: shared/meta-software-vision.md
|
||||
- Sigil 能力注册表: shared/sigil-capability-registry.md
|
||||
- Sigil Backend 与 LRU 调度: shared/sigil-backend-lru.md
|
||||
- 基础设施:
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user