Appearance
金融风控系统创建实录
一份 Excel 功能清单，怎样通过 Codex 和织信 Informat Skill 变成真正的应用？本文以金融风控管理系统为例，按照读需求、做设计、建模型、配流程与看板、开发脚本、发布、准备数据、独立测试的顺序，展示用户如何下达任务、Codex 如何调用 Skill，以及每一步在织信中形成什么结果。
这里展示的不是 Codex 单独生成一套网页代码，而是它读取织信技能提供的规则与接口，直接在织信平台创建数据表、字段、关联、工作流、仪表盘和脚本，再由平台提供运行界面。
先看创建结果
图1看什么： 顶部已经出现“产品与入池、交易与持仓、风险管理、OA管理”等导航；产品信息页具备创建、导入、导出、筛选和列表。这些界面来自织信应用配置，不是另写的一套前端页面。
| 实际产物 | 本案例结果 |
|---|---|
| 应用 | 金融风控管理系统，应用ID为 sokxosrao8s5v |
| 数据模型 | 17张表、260个业务字段、20个关联记录字段、9个查找列表 |
| 工作台 | 1个仪表盘、8张卡片 |
| 流程与入口 | 共用1个工作流模块和1个管理模块，5个停用流程模板及配套发起自动化 |
| 业务角色 | 9个初始业务角色，尚未分配实际成员 |
| 脚本 | 5个分层脚本文件，包括计算服务、平台适配及构建辅助 |
| 发布 | 已发布UAT测试基线，版本 1.0、构建号 2 |
| 测试数据 | 10张表共22条合成记录，批次 QA_20261013_A |
截图与状态说明
本文截图均为2026-10-13首次发布后、导入测试数据前的真实运行页，保留了当时的空表和零计数，不是效果图，也不是导入后的验收截图。22条数据的准备、关联回读和后台计数已另行验证，详见测试数据最佳实践。
本案例交付到哪一步
本案例已打通“需求到UAT应用”的建设链路，但不是完整金融业务验收。流程仍停用；评级权重、实际审批人员、记录授权、行情和交易接口等仍待确定，交易原子入账、并发额度占用和外部同步尚未形成业务闭环。后文分别说明“已生成配置”“已计算验证”“已发布”“已测试”，不把它们混为完成。
Codex与Skill各做什么
Skill可以包含 SKILL.md 指令、参考文档和可执行脚本。Codex根据任务选择并读取技能，再按其中约定完成工作，而不是仅凭模型记忆猜平台参数。技能机制参见OpenAI官方说明。
| 层次 | 负责什么 | 本案例中的具体动作 |
|---|---|---|
| Codex | 理解需求、拆解任务、组织执行、检查结果 | 从Excel提取对象与规则，安排研发和测试角色，编写配置参数与服务 |
informat-designer | 约束项目交付过程与设计方法 | 先设计后实施，基础模型与关联分批建设，记录范围、证据和待办 |
informat | 提供真实平台方法、参数定义和调用入口 | 查询应用，创建表，保存流程与看板，部署脚本，自检和发布 |
| 浏览器测试 | 验证用户实际能看到和操作的结果 | 使用 ego-browser 打开已发布应用，检查导航、表单、筛选、看板和流程入口 |
一次典型执行是： 用户提出业务要求，Codex读取对应能力文档和方法参数，查询当前应用，构造参数并调用平台，最后回读真实对象检查是否保存正确。后续引用的表、字段、流程ID都从返回结果取得，不自行编造。
不必让用户手写全部接口
下面的自然语言指令说明用户怎样和Codex协作；方法名和参数片段解释其背后的执行过程，不要求用户逐条敲命令。指令均为依据本案例整理的复用模板，不是原始对话的逐字截图。
第一步：准备技能与需求输入
准备什么
本案例使用已经加载的 informat-designer、informat，以及《金融风控管理系统-功能清单.xlsx》。文件包含“功能清单、入池单、下单风控审核表、看板页面”四个工作表。
环境使用UAT，服务地址和API凭证通过运行环境提供。Codex先检查 INFORMAT_HOST 与 INFORMAT_AGENT_TOKEN 是否设置，只检查非空，不输出密钥；不把凭证写进示例、Git或截图。
给Codex的任务
text
请使用 informat-designer 和 informat Skill，
根据附件《金融风控管理系统-功能清单.xlsx》创建织信金融风控管理系统。
先读取全部工作表，整理业务模块、角色、核心规则与验收条件，
输出设计蓝图让我确认后再创建。
缺失的评级权重、汇率、实际审批人和外部接口不能自行编造。
创建研发工程师和测试工程师两个AI角色，
持续记录创建过程、真实平台结果和截图，形成可复现的案例。Codex做什么
Codex只读解析Excel，将需求分为产品入池、交易与持仓、风险管理、看板和OA等模块；识别额度、评级有效期、审批节点等规则，并把缺少的参数单独记录。
这个阶段的产物是需求与设计基线，不是直接宣称系统已经建成。评级算法等未确定，不妨碍先创建必要模型，但不能生成虚假的正式评级或成交结果。
第二步：确认蓝图与工程师分工
给Codex的任务
text
按已经确认的蓝图推进建设。
研发工程师负责模型、表单、流程、看板、脚本、自测及UAT发布。
测试工程师根据原始需求独立验证，记录问题并在修复发布后回归。
测试工程师只测试已发布运行页，不需要进入应用设计器。
任何不兼容改动必须先让我手工确认。本案例最终形成四组导航和17张业务表：
| 导航分组 | 业务表 |
|---|---|
| 产品与入池 | 产品信息、入池申请 |
| 交易与持仓 | 投资账户、下单风控审核、交易记录、持仓明细、资金流水 |
| 风险管理 | 额度设置、风控指标与规则、风险评级记录、风控预警事件、风控处置记录 |
| OA管理 | 请假管理、招聘计划、投档与面试、入职登记、报销管理 |
Codex使用 _plan_set 登记实施目标，随后把实际对象与计划对照，检查有无漏建。目标数量是防遗漏工具，不是功能验收标准。
| 工作包 | 研发侧 | 独立测试侧 |
|---|---|---|
| 模型与界面 | 查询现状，串行创建并回读 | 对照Excel检查缺字段、关系和场景 |
| 业务服务 | 实现计算、适配和日志，自测 | 独立复跑断言，检查边界与异常 |
| 发布与运行页 | 自检、审阅差异、发布UAT | 只从已发布应用验证业务入口 |
| 测试数据 | 准备可追踪的合成样本 | 检查关联、筛选和预期值，不把样本状态当审批事实 |
两个AI工程师可以并行分析或编辑互不重叠的本地文件，但平台结构写入由负责人统一串行执行，避免同时保存模块树造成覆盖。
第三步：调用Skill创建应用和基础表
用户要求与平台调用的对应关系
| 用户想要什么 | Codex调用什么 | 调用后检查什么 |
|---|---|---|
| 创建金融风控应用 | 先 _company_app_list，再 _company_app_create | 是否重名、返回的应用ID、名称与标识 |
| 创建四组业务导航 | _create_module_group | 分组是否进入应用导航 |
| 创建产品、账户等表 | _create_table_module | 表是否挂入应用，字段类型、必填和选项是否正确 |
| 确认实际结构 | _query_table_list_designer、_query_table_define_designer | 取得实际表与字段，供下一步关联引用 |
本次应用标识为 com.informat.financial.risk。创建时采用 _company_app_create 参数定义允许的 name、appDefineId、icon 等属性；得到真实 appId 后，后续应用级操作都明确指向它。
字段不是随意生成的文本框
例如，“产品名称”使用 SingleText，“资产品种”使用 ListSelect，“评级有效期”使用 Date，“附件”使用 Attachment。Codex为每种类型生成对应的配置，下面是资产品种字段的参数节选，不是完整建表请求：
json
{
"id": "assetCategory",
"name": "资产品种",
"type": "ListSelect",
"icon": "checkbox-circle",
"displayWidth": 25,
"listSelectSetting": {
"nullable": false,
"multiple": false,
"optionList": [
{ "id": "fixedIncome", "name": "固收类资产", "color": "#5B8FF9" },
{ "id": "equity", "name": "股票型资产", "color": "#57CA8C" },
{ "id": "derivative", "name": "衍生品资产", "color": "#FAAD14" },
{ "id": "crypto", "name": "虚拟货币", "color": "#E86452" },
{ "id": "custom", "name": "定制型产品", "color": "#945FB9" }
]
}
}这里的 id 是稳定选项编码，name 是显示名称。不是把前端常见的 label/value 对象直接交给平台。Codex先读取当前方法的schema，再生成这类参数。
图2看什么： 产品名称、代码和资产品种、币种有必填标记；文本、下拉、复选框分别对应不同字段类型。截图是滚动后的基础信息区域，说明字段已生成，不代表首屏顺序已经优化；当前表单顺序问题仍在缺陷台账中。
这一步采用基础表与普通字段先建的策略。产品、账户等对象全部存在并回读后，才进入跨表关系配置。
第四步：把独立表连成业务系统
给Codex的任务
text
请基于刚刚回读的真实结构，建立产品、入池申请、下单、交易、持仓和风险事件的关联。
子记录用关联记录字段选择产品或账户，
产品详情用查找列表展示该产品自己的申请、交易、评级和事件。
设置展示列与筛选条件，不允许显示其他产品的全部记录。Codex通过 _edit_table_field 增加关系字段，并重新查询所属表，更新后续使用的结构。
| 业务关系 | 织信配置 | 用户得到什么 |
|---|---|---|
| 一条下单属于一个产品 | orderApplication.productId，类型 RelationRecord | 在下单表单中选择产品 |
| 一条持仓属于一个账户 | position.investmentAccountId，类型 RelationRecord | 按账户组织持仓 |
| 一个产品对应多条评级记录 | 产品上的 LookupList | 在产品详情直接查看评级历史 |
| 一个事件对应多条处置记录 | 事件上的 LookupList | 查看处理与复核资料 |
查找列表不是简单地把另一张表嵌进来。产品查看交易时，需要将子表的 productId 限定为当前主记录ID。参数片段如下，字段标识必须来自前一步回读：
json
{
"tableId": "trade",
"filter": {
"conditionList": [
{ "fieldId": "productId", "opt": "eq", "var": true, "value": "${record.id}" }
]
}
}
图3看什么： 产品表单已经包含入池申请、交易记录、评级历史等子列表和业务列。这张新建表单截图证明列表入口已生成，不证明已有数据的过滤正确；本案例关联ID还经过后台回读检查，非空列表的浏览器验证仍需单独执行。
本轮共建立20个关联记录字段、9个查找列表。平台摘要可能使用业务key，完整Define使用内部ID，因此Codex还核对了目标表、显示字段、列名和过滤引用，没有直接把输入参数当作保存结果。
第五步：生成流程、角色和操作入口
给Codex的任务
text
请为入池、下单风控、风险处置、请假和报销配置流程模板。
共用应用级工作流模块，绑定对应表的发起入口。
同时建立业务角色的初始权限。
审批人和业务条件尚未确认的流程保持停用，不允许自动放行。Codex使用当前Skill中的 _bpmn_* 方法创建流程节点和连线，保存流程定义；再创建配套自动化，将 OutputBpmnProcess 步骤绑定到真实表、流程与发起按钮。流程不是只画几个节点，还需要审批人、表单、同意/拒绝分支和状态契约。
本案例按研究员、基金经理、交易员、风控专员等职责建立9个业务角色。它们是模块级权限基线，尚未分配成员；记录隔离与敏感字段访问不能仅靠表单只读代替。
图4看什么： 用户能从顶部进入工作流，查看任务、流程和草稿等运行入口。这里不是流程设计图；5个模板仍停用，截图不代表发起和审批已验证。
本次没有采集设计器中的流程画布截图，因此本文不以示意图冒充实际BPMN设计。流程节点配置与停用状态的证据保留在 projects/financial-risk/evidence/final-processes.json。
第六步：让数据形成可用的工作台
给Codex的任务
text
请创建金融风控工作台，绑定已存在的真实业务表。
首行展示待审核入池、待审核下单、未关闭风险事件和评级过期产品数量；
第二行展示风险事件状态分布与产品资产品种分布；
底部展示风险事件明细和持仓明细。
缺少行情、汇率和成本依据时，不要生成虚假的收益指标。Codex调用 _create_dashboard_module 创建仪表盘，再分别使用 _save_dashboard_number_card、_save_dashboard_prochart_card、_save_dashboard_record_card 保存卡片。
| 区域 | 布局与类型 | 数据来源和用途 |
|---|---|---|
| 第一行 | 4张 Number，每张6列 | 按申请和事件状态、评级日期筛选后计数 |
| 第二行 | 16列和8列的 ProChart | 风险事件按状态分组，产品按资产品种分组 |
| 第三行 | 2张12列的 Record | 展示风险事件、持仓与估值状态明细 |
图5看什么： 从“表和字段”进一步生成数字指标、统计图和明细，不需要另建一个独立看板网站。截图为导入前状态，零计数和空图不代表真实风险为零；本轮还记录了空图提示不足的问题。
图6看什么： 顶部“风险管理”把相关业务模块放在一起，事件表提供检测时间、检测值、阈值快照、币种与状态等列。导航、表格和看板都服务于同一套模型，而不是互不关联的展示页面。
第七步：复杂逻辑交给脚本，计算结果留证据
低代码配置负责表、表单和流程等通用能力；额度比较和有效交易数量等计算，需要明确的业务服务。本案例研发采用工具层、服务层和平台适配入口，service不写SQL，每个函数说明用途、参数、返回和异常，关键动作记录可追踪日志。
Codex使用 _save_informat_script 保存脚本，通过 _execute_informat_script_designer 在真实引擎中验证，再核对业务日志。本案例纯服务接收合成快照，未直接完成正式交易写入。
| 验证场景 | 平台实际结果 |
|---|---|
| 有效评级、同币种、4,999,999.99 USD | 未超限 pass |
| 5,000,000 USD，等于上限 | pass |
| 5,000,000.01 USD，超过上限 | approvalRequired |
| 币种不一致、评级过期或非法R6 | dataMissing |
| 买入100、卖出40 | 数量60 |
| 相同ID与内容重放 | 数量仍为60 |
| 超卖或同ID内容冲突 | rejected |
Node测试12项通过，真实GraalVM直调12个场景通过，并取得12次业务计算日志。字符串十进制与BigInt用于纯计算，宿主Java Map/List通过平台适配转换。
这里的 pass 不是“审批通过”，计算出数量也不是“已成交入账”。数据库精度、来源交易幂等、并发卖单、快照冻结等仍需真实业务入口联调。
第八步：研发先发布，再准备数据交付测试
推荐交付顺序是发布、准备数据、业务测试。本案例实际先做了发布后的空态冒烟，随后按用户要求补入22条数据；导入后的非空页面与业务验证尚未执行，不能把前一轮截图当作后一轮测试结果。
发布到UAT
text
请由研发工程师审阅本批全部待发布项，执行发布前检查。
确认目标为金融风控管理系统的UAT环境，按已授权范围发布测试基线。
回读实际发布版本后，再交给测试工程师从运行页测试。Codex读取发布方法schema后，查询历史发布次数和待发布项，重新执行 _app_check_setting。本次回读334个待发布定义，检查结果为空，然后通过 _app_publish 发布，返回 finish。
以下是研发实际回读结果的摘录，不是模拟响应：
json
{
"releaseVersion": "1.0",
"build": 2,
"publishCount": 1,
"draftCount": 0
}20个已发布模块排除构建号和更新时间等审计元数据后，业务配置与发布前基线一致。研发刷新运行页确认入口可见，才把地址和版本交给测试工程师。
准备可追踪的测试数据
text
请在已发布UAT加入带QA批次前缀的合成数据，
覆盖产品、账户、额度边界、评级有效期和风险事件状态。
按真实父子ID关联，写入后回读，重复执行不能重复新增。
不要执行真实交易、审批或通知，记录台账和清理边界。研发通过已发布表查询和 _table_record_batch_insert 串行准备22条记录，覆盖10张表。每条回读验证输入及关联，独立测试侧复核22个唯一ID和30处关联；完整重跑新增0条、复用22条。
本批后台查询得到待审核入池2、待审核下单2、未关闭事件2、过期评级产品1。这些是合成样本的对账基准，尚未补拍非空看板截图。人工状态没有对应真实审批实例，静态持仓不是成交生成。详细做法见测试数据最佳实践。
测试工程师只测运行页
发布后，测试工程师使用 ego-browser 访问UAT应用，没有进入设计器、修改角色或执行发布。
| 发布后实际测试 | 结果与边界 |
|---|---|
| 产品、投资账户、交易记录、风险事件、请假管理 | 5张业务表的运行入口和空表可访问 |
| 产品筛选、重置、新建与取消 | 已实际操作；未保存业务记录 |
| 8张工作台组件 | 页面可见，导入前空态已记录 |
| 工作流和流程数据入口 | 可访问；没有发起审批实例 |
| 完整金融业务、其他12表、多角色隔离 | 尚未完成验收 |
本轮发现3项可用性问题：产品新建首屏被关联空表占据、图表空态提示不足、无可用流程时选择框没有原因说明。它们进入研发缺陷台账，不能在没有修复和回归证据时标为关闭。完整截图与复现步骤见浏览器测试实录。
实施中遇到的问题与处理
问题是帮助读者理解实施边界的补充，不是整个创建案例的主线。
| 问题 | 本案例怎样处理 | 复用要点 |
|---|---|---|
| 初次认证失败 | 使用与UAT匹配的有效凭证后重新查询 | 服务地址与凭证匹配，不把密钥写进文档 |
| 停用流程查询列表为空 | 用完整Define找到已建对象，复用真实ID | 空列表不等于不存在，不能盲目重建 |
| 写入后内部ID不同 | 重新读取目标表和字段，再建立依赖 | 以保存结果为准，不以提交参数代替回读 |
| 发布前就开始浏览器测试 | 调整为研发先发布、测试再验证运行页 | 设计器权限不是业务测试的前置条件 |
| 日期偏移输入与保存时刻不符 | 停止写入，核对已保存记录，统一合成基准后恢复 | 比较时间戳与业务时区，异常不盲目重发 |
部分设计器工具缺项使用了限定本应用和当前操作者的构建辅助协议。它不对普通业务成员开放，也不是跨环境可直接照搬的通用接口；这里不要求读者绕过Skill或权限来复现。
读者怎样复用这套方法
复用的不是本案例的17张表或固定ID，而是**让Codex持续执行“读规则、查现状、生成配置、调用Skill、回读验证、发布后测试”**的工作方式。
- 给出真实需求文件、目标环境和关键业务规则，明确不能编造的参数。
- 指定
informat-designer与informat，让Codex先给蓝图和本批范围。 - 先建基础模型，再配置关系、流程入口、看板及必要脚本，每一步回读。
- 研发完成自测与检查后发布UAT，交付实际版本及合成测试数据。
- 测试工程师在运行页独立验证；研发修复并重新发布，测试再回归。
- 为每阶段保留真实产物、截图和已知限制，而不是只保留“创建成功”的一句话。
| 想深入了解 | 查看资料 |
|---|---|
| 总体方法与角色任务模板 | 案例总览 |
| 模型和脚本实施约束 | 研发实施手册 |
| 全业务用例与验收要求 | 测试验证手册 |
| 真实运行页操作与截图 | 浏览器测试实录 |
| 数据批次、重复执行、失败恢复与清理 | 测试数据最佳实践 |
项目证据位于 projects/financial-risk/：model.mjs 与建设脚本记录实施来源，evidence/calls.jsonl 保存调用与回读，publish-result.json 记录发布版本，test-data-manifest.json 保存22条合成记录的真实ID，browser-qa.md 保存实际浏览器测试结论。
复现不等于整批重跑
本案例建设脚本针对已经确认的单一UAT应用，不是可直接覆盖任意环境的安装包。先读取 progress.md，查询最新结构和已有数据，再决定增量步骤；不兼容变更由用户手工确认。不要复制本案例内部ID、重新创建整套对象，或把历史截图当作当前环境状态。