使用 AI 开发助手开发 JitAI 元素
AI 开发助手是 JitAI IDE 内置的元素开发 Agent。它面向开发者，不是普通业务聊天助手；它绑定应用源码空间，能够围绕当前应用中的模型、服务、页面、Agent、Skill、门户、事件、任务和数据库连接等元素，完成“理解需求、查询现有元素、拆解元素矩阵、生成源码变更、差异审阅、构建刷新、验证返修”的开发闭环。
开发者仍然负责确认业务规则、审阅代码差异和验证运行结果。AI 开发助手的价值，是把大量重复的元素搭建、规范查阅、源码生成和构建刷新工作收敛到 IDE 内部，让开发从“手工查规范、手工拼目录、手工写样板代码”变成“用自然语言驱动、按元素审阅、按构建结果迭代”。
它和普通 AI 助手有什么不同
| 对比项 | 普通 AI 聊天助手 | JitAI AI 开发助手 |
|---|---|---|
| 工作对象 | 文本建议、代码片段或解释 | 当前应用中的 JitAI 元素源码 |
| 上下文来源 | 用户临时粘贴的内容 | IDE 当前元素、应用元素清单、源码空间和元素规范 |
| 开发方式 | 一次性生成代码，开发者自行落地 | 先拆元素矩阵，再逐个元素生成标准变更集 |
| 变更控制 | 容易直接给出片段 | 默认差异预览，确认后再应用到源码 |
| 平台规范 | 依赖模型记忆 | 按元素类型读取对应开发规范，必须完整覆盖 |
| 后续动作 | 通常停在代码生成 | 可继续构建元素、刷新 IDE，并按反馈返修 |
这意味着 AI 开发助手不是“帮你想代码”，而是把 JitAI 元素开发流程放进一个可审阅、可构建、可迭代的生产级工作流里。
核心组成
AI 开发助手由几个关键机制组成：
- 开发 Agent：内置
JitAI 元素开发助手，接收用户需求和当前打开元素上下文。 - 应用源码空间：通过
/src/...虚拟路径访问当前应用源码，开发者不需要关心底层物理路径。 - 开发模型配置：每个应用可以独立指定开发助手使用的大模型服务，便于不同项目按开发复杂度、成本和合规要求选择模型。
- 元素查询能力：在处理多元素需求前，会查询当前应用已有实例元素，避免凭空创建或重复建设。
- 开发规范按需读取：根据元素类型读取模型、服务、页面、Agent、Skill、函数、配置类元素和数据库连接等开发规范。
- 标准源码变更集：所有源码变更以统一结构输出，包含文件路径、创建/修改动作、完整内容或局部修改、依赖、构建目标和自检结果。
- 差异审阅机制：默认先提交差异预览；只有开发者明确要求跳过审阅时，才直接应用变更。
- 构建和刷新能力：变更采纳后，可继续构建元素、构建应用并刷新 IDE 中的元素状态。
这些机制共同保证开发助手能进入真实项目，而不是只停留在生成示例代码。
能开发哪些元素
AI 开发助手面向 JitAI 应用元素开发，常见能力包括：
| 元素类型 | 典型任务 |
|---|---|
| 数据模型 | 创建模型、补充字段、设计 dataTitle、索引、关联关系和公开模型函数 |
| 服务函数 | 创建业务服务、声明公开函数、实现查询、统计、校验和业务编排逻辑 |
| 页面 | 创建或修改 React 全代码页面，处理页面声明、渲染、页面逻辑、样式和组件拆分 |
| Agent | 创建或修改 Agent 配置、提示词、工具、Skill、文件空间、知识库和运行边界 |
| Skill | 创建可复用 Skill，沉淀任务流程、约束、参考资料和验收标准 |
| 函数代码块 | 为页面、服务或模型补充前端 TypeScript 函数、后端 Python 方法或模型类方法 |
| 门户 / 事件 / 任务 | 创建门户菜单、模型事件、定时任务、日期字段任务等配置类元素 |
| 数据库连接 | 辅助创建 MySQL、Oracle、PostgreSQL、SQL Server、SQLite、达梦等数据库连接配置 |
如果一个需求涉及多个元素，开发助手不会把所有代码混在一起生成，而是先形成元素矩阵，再按依赖顺序逐个处理。
推荐开发流程
建议按下面方式与开发助手协作：
- 说明业务目标：先用业务语言说明要解决什么问题。
- 形成元素矩阵：对于模块级需求，让开发助手列出模型、服务、页面、Agent、Skill、门户、事件或任务等元素清单。
- 确认当前元素任务：一次只处理一个元素，明确 fullName、类型、动作、依赖和风险点。
- 读取规范和上下文：开发助手根据元素类型读取对应开发规范、当前源码、同类示例和依赖元素详情。
- 生成源码变更集：输出标准源码变更集，而不是零散代码片段。
- 审阅差异：先查看新增文件、修改位置、关键逻辑、字段、参数和权限边界。
- 应用变更：确认后把采纳的变更落到源码。
- 构建刷新：构建当前元素或应用，刷新 IDE 元素状态。
- 运行验证并返修：根据页面展示、函数执行、Agent 运行或构建报错继续调整。
例如：
我要做一个售后工单管理功能。请先列出需要创建或修改的模型、服务函数、页面、Agent 和 Skill，不要直接改代码。
确认元素矩阵后，再让开发助手逐个处理：
先处理工单模型。字段包括客户、问题类型、优先级、状态、处理人、创建时间和最后跟进时间。生成前先说明字段设计和索引建议。
多元素需求：先拆元素矩阵
当需求描述的是完整业务模块、流程自动化、页面加后端能力、Agent 加 Skill，或包含多个对象、动作、角色时，开发助手会先拆出元素矩阵。
元素矩阵通常包含：
| 列 | 说明 |
|---|---|
| 元素类型 | 模型、服务、页面、Agent、Skill、门户、事件或任务 |
| fullName | 已有元素使用真实 fullName，新元素给出拟定 fullName |
| 标题 / 职责 | 该元素承担的业务职责 |
| 状态 | 已存在或拟新增 |
| 动作 | 新增、扩展、修复、复用不改或暂不处理 |
| 依赖 | 依赖哪些模型、服务、页面、Agent、Skill 或配置 |
| 主要改动 | 字段、函数、页面交互、Prompt、Skill 规则等 |
| 风险点 | 覆盖已有逻辑、兼容性、数据影响、依赖不明确等 |
多元素开发必须按依赖顺序推进：通常先模型和底层服务，再页面、Agent、Skill、门户、事件和任务。任意时刻只处理一个当前元素，避免跨元素改动混在一起无法审阅。
开发规范完整读取和源码生成约束
JitAI 元素有明确的目录结构、配置文件、入口文件、数据类型和运行规则。AI 开发助手在生成源码前，会按元素类型读取对应开发规范，并输出读取凭证。
读取凭证用于证明本次开发所需的开发规范已完整读取，通常包含：
{
"path": "references/page.md",
"required": true,
"status": "complete",
"coverage": "1-EOF",
"lastSection": "文件结尾",
"appliedRules": ["模型字段配置通过 Jit.models[fullName]?.fieldList 获取"]
}
关键规则：
- 必读开发规范没有完整读取前，不生成源码变更集。
- 开发规范与通用框架经验或模型记忆冲突时，以本次读取到的开发规范为准。
- 不能臆造 API、组件、模型字段、函数签名、导入路径、目录结构或配置项。
- 修改已有文件时优先使用局部 edits；直接给完整内容时，必须保留仍然需要存在的上下文代码。
- 页面开发会额外检查字段渲染、模型字段配置和模型
query调用等平台规则。
这套约束让 AI 生成的不是“看起来像代码”的片段，而是符合 JitAI 元素规范、可审阅、可构建的源码变更。
差异预览和变更应用
AI 开发助手默认通过差异预览提交源码变更。开发者应先审阅：
- 新增或修改了哪些文件。
- 是否只处理了当前元素任务。
- 字段名、函数参数、返回值和页面绑定是否符合预期。
- 是否误改了无关元素或公共基础能力。
- 是否涉及数据删除、批量更新、权限、外部接口或高风险业务动作。
只有在你明确表示“跳过代码审查”“不用 diff 审查”或“直接应用”时，开发助手才应直接应用变更。日常开发建议保留差异审阅，尤其是涉及数据结构、权限边界、业务状态流转和外部系统调用的需求。
如果你在差异审阅中提出调整意见，开发助手会基于反馈重新生成当前元素的源码变更集，再次提交审阅。
构建、刷新和验收
变更被采纳后，开发助手可以继续执行构建和刷新：
- 构建元素：适合只修改单个模型、服务、页面、Agent、Skill 或配置类元素。
- 构建应用：适合修改依赖声明、跨元素依赖或应用级配置。
- 刷新元素：让 IDE 重新加载元素，确保可视化编辑器和运行态看到最新内容。
构建完成后，还需要按元素类型验证：
| 元素类型 | 验证重点 |
|---|---|
| 模型 | 字段、标题字段、索引、关联关系、数据库和公开函数声明 |
| 服务 | 参数、返回值、异常处理、依赖模型调用和副作用范围 |
| 页面 | 组件展示、字段渲染、事件绑定、表单提交、数据刷新和权限表现 |
| Agent | 模型、提示词、工具、Skill、文件空间、知识库、预置问题和运行边界 |
| Skill | 触发场景、流程、约束、参考资料和验收标准是否清楚 |
| 事件 / 任务 | 触发条件、执行函数、副作用范围和失败处理 |
构建或验收失败时，不应跳到下一个元素；应先分析并返修当前元素，再重新走差异审阅、应用、构建和验证。
提问方式示例
清晰的开发请求能明显提高结果质量。
| 目标 | 示例 |
|---|---|
| 先拆模块 | 我要做客户跟进管理，请先列出模型、服务、页面和 Agent 的元素矩阵，不要直接改代码。 |
| 修改当前元素 | 当前页面的表格增加“客户等级”列，并支持按客户等级筛选。 |
| 新建模型和页面 | 创建客户回访记录模型，字段包括客户、回访时间、回访方式、回访结论，并生成列表页和编辑页。 |
| 修复服务函数 | 检查当前服务函数为什么保存订单时报错，保留现有业务逻辑，只修复参数和空值处理。 |
| 扩展 Agent | 给当前 Agent 增加订单知识库，并补充提示词：涉及订单政策时先查知识库。 |
| 创建 Skill | 基于客户订单模型创建问数 Skill，覆盖订单明细查询、按客户统计和金额 TopN。 |
| 构建验证 | 应用差异后构建当前元素，并说明构建结果和还需要我验证的页面或函数。 |
不建议一开始就提出“帮我做完整 CRM”这类过大的请求。更好的方式是先让开发助手拆模块，再按元素逐步推进。
首次使用前配置开发模型
AI 开发助手需要单独指定开发模型。该配置按应用保存，便于不同项目选择不同的大模型服务，也便于团队统一管理和后续调整。
当前 IDE 中有两处和开发模型配置相关：
- 开发助手面板的“立即配置”入口：打开开发助手时，会读取应用环境变量
developerLLMName和developerLLMConfig。如果没有配置，界面会提示立即配置，选择大模型后保存到应用环境变量。 - “应用环境变量”页面：在“应用开发环境变量”区域，可以通过大模型选择器配置开发模型。该配置会记录所选大模型服务、模型名称和模型参数。
选择模型时，界面会检查模型是否支持工具调用。开发助手需要模型具备 tool calling / Function Calling 能力，否则会影响元素查询、开发规范读取、差异预览、变更应用、构建刷新等动作。
配置建议：
- 选择代码生成能力稳定的模型。
- 确认模型支持 tool calling / Function Calling。
- 将 API Key 等敏感信息保存在模型服务配置或环境变量中，不要写入对话内容。
- 不建议手工拼写环境变量值；优先通过开发助手弹窗或应用环境变量页面选择模型并保存。
- 如果模型经常输出不完整代码，优先降低随机性参数，并选择更稳定的代码模型。
开发模型配置完成后，同一应用后续会复用该配置。如果更换开发模型，应重新保存应用环境变量，并重新打开或刷新开发助手。
使用边界和注意事项
- AI 开发助手面向开发者使用，不应开放给普通业务用户作为日常业务 Agent。
- 普通业务 Agent 不应绑定源码工作空间，也不应具备修改应用源码的能力。
- 生成的变更需要开发者审阅，尤其是数据模型、权限、删除操作、外部接口和批量更新逻辑。
- 开发助手不会默认创建、更新或删除业务数据；涉及业务数据写入时，需要明确需求和风险边界。
- 不应要求开发助手删除文件、批量重命名目录或覆盖关键元素，除非你已经明确确认。
- 新增第三方依赖时，应让开发助手说明依赖用途，并把依赖声明文件纳入源码变更集。
- 如果结果偏离目标，直接指出“只保留某部分，撤回某部分，重新生成差异”。
AI 开发助手适合提升 JitAI 元素开发效率，但它不能替代开发者对业务规则、权限边界、数据影响和上线质量的判断。