织信开发日志 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 的工程入口。