织信开发日志 10：AI Agent Skill 不是提示词，而是平台操作协议

前面几篇写了表单、数据模型、权限、流程、插件、自动化和脚本。

这些底座写完，再看 AI，会清楚很多。

如果平台能力没有整理好，AI 很容易变成一个会聊天的入口：用户问一句，它回一段建议。看起来热闹，但进不了企业系统。

真正的问题是：

• 它怎么知道当前应用有哪些数据表？
• 它怎么知道字段、模块、流程的真实 ID？
• 它怎么创建记录、更新表单，而不是只输出文字？
• 它怎么避免瞎编参数、越过权限、改错数据？

所以 AI + 低代码的重点，不是提示词，而是平台操作协议。

Skill 不是一段大提示词

很多人一听 Skill，会理解成“给 AI 多塞一点背景知识”。

比如告诉它平台有表单、流程、自动化、脚本、权限。

这些信息有用，但远远不够。

智能体真正执行任务时，缺的是更具体的问题：

• 我现在能调用什么能力？
• 这个能力需要什么参数？
• 参数应该从哪里查？
• 哪些动作只是查询，哪些动作会修改系统？
• 哪些操作必须让用户确认？

ChatBot 更像回答器。

Agent 更像操作者。

操作者必须知道边界。

先查询，再操作

AI 操作低代码平台时，我最不放心的一类问题，是它会“补全不存在的信息”。

用户说：“帮我给客户表加一个客户等级字段。”

如果 AI 没有先查询当前应用，它可能会猜一个客户表 ID。

如果没有先查询字段列表，它可能重复创建已有字段。

如果没有读取页面结构，它可能把控件放到不合适的位置。

所以 Skill 里很重要的一条原则是：先拿上下文，再执行修改。

先查应用，再查模块，再查表和字段，最后才执行变更。

这和人类开发一样。改代码前要看工程结构，改数据库前要看表结构。AI 只是把过程自动化，但不能跳过过程。

方法越清楚，风险越可控

低代码平台不能只给 AI 一个笼统的“帮我修改应用”入口。

接口越粗，风险越大。

如果 AI 一次性做很多事，做错以后很难回溯。

更好的方式，是把平台能力拆成明确方法。每一步都有参数、返回值和执行结果。

比如创建应用，不应该只是“生成一个项目管理系统”。

它应该拆成更小的动作：理解需求、生成蓝图、创建数据表、补充字段、生成页面、配置视图、发布预览。

每一步都能看见，才能被确认、被中断、被追踪。

设计端能力要更谨慎

低代码平台有运行端，也有设计端。

运行端影响业务数据。

设计端影响系统结构。

AI 如果进入设计端，可以帮用户创建表、补字段、生成表单布局、配置自动化、写脚本草稿。

这很有价值，但风险也更高。

字段类型错了、关联关系错了、流程状态错了，影响的不是一条数据，而是一整块业务。

所以设计端动作要小步执行。

AI 可以建议，可以生成草稿，也可以调用明确方法完成局部操作，但关键动作必须可预览、可确认、可追踪。

权限不是一个开关

Skill 把平台能力交给智能体以后，权限就变成核心问题。

一个普通业务用户只能查看客户数据，AI 也不应该借着工具调用去修改客户数据。

一个实施人员可以改页面和字段，但没有发布权限，AI 也不能替他发布应用。

所以 AI 权限至少要看四层：

• 团队角色权限，决定用户最多能把哪些能力交给 AI；
• 当前会话模式，决定本次会话打开哪些能力；
• 用户原有业务权限，决定他本人能不能碰这些对象；
• 系统安全策略，负责拦截高风险动作和异常批量操作。

AI 应该是在替用户工作，而不是绕过用户权限工作。

AI Agent 在低代码平台里的核心不是聊天能力，而是操作能力。

操作能力的核心也不是模型本身，而是平台愿不愿意把自己的能力拆成清晰、稳定、可治理的方法。

Skill 做的就是这件事。

它让 AI 不只是“知道平台是什么”，而是知道“在权限范围内，下一步可以怎么做”。