织信开发日志 17：织信 Skill 的目的，是把平台能力交给 AI Agent

织信开发日志 17：织信 Skill 的目的，是把平台能力交给 AI Agent

如果只把 Skill 理解成“更长的提示词”，方向就偏了。

提示词主要解决的是表达问题：让 AI 怎么回答、用什么语气、按什么结构输出。

织信 Skill 要解决的不是表达。

它的目的更直接：把织信平台里已经存在的能力，整理成 AI Agent 可以理解、可以调用、可以受控执行的能力清单。

换句话说，不是让 AI 更会描述织信，而是让 AI 能真正调用织信做事。

平台能力本来就在那里

织信不是从 AI 开始才有能力的。

应用、表单、数据表、字段、视图、流程、自动化、脚本、权限、页面，这些能力本来就存在。

过去，这些能力主要是给人用的。

人进入后台，理解页面，点击按钮，配置字段，保存发布。

AI Agent 不一样。

它不能靠“看起来差不多”去点一个按钮，也不能凭感觉猜一个字段 ID。

如果要让 AI Agent 真正进入开发过程，就必须把这些平台能力变成它能调用的方法。

比如：

• 查询当前应用有哪些对象；
• 创建一张业务表；
• 给表增加字段；
• 读取已有字段结构；
• 生成页面配置；
• 配置自动化动作；
• 调用服务端脚本；
• 检查权限和发布状态。

这些不是写作技巧。

这是平台能力的开放方式。

Skill 是 AI Agent 和织信之间的操作协议

我现在更愿意把 Skill 看成一种操作协议。

它告诉 AI Agent 三件事。

第一，织信有哪些能力可以被调用。

第二，每个能力应该怎么调用，参数是什么，返回什么。

第三，调用这些能力时有哪些边界，比如哪些动作只读，哪些动作会修改系统，哪些动作需要先确认。

这和提示词完全不同。

提示词可以告诉 AI：

“你是一个低代码专家。”

但 Skill 要告诉 AI：

“如果要创建字段，先查询表结构；字段类型必须来自平台支持的类型；如果字段已存在，不要重复创建；如果动作会影响现有数据，先说明风险。”

前者让 AI 像是在懂。

后者让 AI 真的能做。

暴露能力，不等于放开权限

这里有一个很容易误解的地方。

把织信能力暴露给 AI Agent 调用，不是把系统交给 AI 随便改。

企业应用里，真正重要的不是“AI 能调用多少能力”，而是“AI 在什么条件下调用这些能力”。

一个好的 Skill，应该把边界写清楚。

比如查询类能力可以直接执行。

创建类能力要检查现有结构。

修改类能力要说明影响范围。

删除、覆盖、发布这类动作，需要更严格的确认。

这不是保守。

这是让 AI Agent 能进入真实业务系统的前提。

没有边界，AI 越能干，风险越大。

有了边界，AI 才能从“会生成内容”变成“能参与工程”。

AI Agent 不能靠猜

很多 AI 生成应用的演示，看起来很顺。

输入一句话，几秒钟后生成表、页面、按钮、数据。

但真正做企业系统时，困难不在第一眼好不好看。

困难在它有没有和真实平台状态对齐。

字段是否已经存在。

字段类型是否正确。

表之间的关联是否合理。

页面引用的对象是否真实存在。

自动化动作有没有拿到正确参数。

权限会不会挡住后续操作。

这些问题，靠提示词压不住。

必须靠 Skill 把“先查询，再操作”的路径固定下来。

AI Agent 每做一步，都应该知道自己基于什么状态、调用什么能力、改变了什么结果。

这就是织信 Skill 系列真正想讲的东西。

不是 AI 写了一段漂亮方案。

而是 AI 能不能基于织信的真实能力，完成一次可靠的系统操作。

https://github.com/informat365/informat-skills

织信 Skill 的核心价值，不是让 AI 说得更像产品经理，也不是让 AI 写出更漂亮的需求文档。

它的价值是把织信的平台能力变成 AI Agent 可调用的工具集。

表、字段、页面、流程、自动化、脚本、权限，这些能力一旦被清晰地暴露出来，AI Agent 才有机会从“建议者”变成“操作者”。

提示词决定 AI 怎么表达。

Skill 决定 AI 能调用什么、怎么调用、在什么边界内调用。

这也是我觉得 Skill 值得单独写一组文章的原因。

因为它不是提示词工程。

它是把一个真实业务平台接入 AI Agent 的工程入口。