Codex 双角色构建金融风控系统

案例目标

本案例展示如何让 Codex 同时使用 informat-designer 与 informat Skill，把一份金融风控功能清单推进为可实施、可测试、可交接的织信应用项目，并通过研发工程师与测试工程师两个 AI 角色协作控制交付质量。

informat-designer 管理需求、设计、分批实施、质量门禁和交接；informat 提供平台方法、参数定义与实际调用。平台状态以查询和运行证据为准，两个技能共同约束研发与测试过程。

输入材料为《金融风控管理系统-功能清单.xlsx》，包含“功能清单”“入池单”“下单风控审核表”“看板页面”四个工作表。目标覆盖产品入池、交易与持仓、风险评级、额度控制、下单审核、风险事件处置、数据看板、交易软件集成与清单中的 OA 管理。

案例证据边界

2026-10-13 用户确认开始创建后，已创建17张表、260个业务字段、8张看板卡片、5个停用审批流程、9个业务角色及相应脚本与入口。平台配置检查通过，12个计算场景在真实设计器引擎中通过。研发已发布UAT测试基线，版本1.0、构建号2，再交由独立测试工程师验证运行页。完整过程与遗留问题见金融风控系统创建实录。下文保留阶段方法与提示词，不代表全部业务功能已经验收或生产上线。

为什么采用双角色

金融风控的难点在于业务口径是否被准确执行。例如“0 万美元，单独请示”意味着例外审批，不能解释为不限额；“审批通过”也不能自动等同于“交易成交”。研发需要将这些规则落实为配置和服务，测试需要从输入、边界和结果独立判断是否正确。

角色	责任	必须提交的结果
项目负责人 AI	读取需求、确定范围、解决口径冲突、安排批次、整合文档	需求基线、决策记录、进度与最终交付状态
研发工程师 AI	查询平台现状、设计模型、实施表单与流程、编写服务、修复缺陷	实际对象 ID、变更内容、配置回读、联调证据
测试工程师 AI	根据原始需求独立设计测试、执行允许与拒绝路径、记录缺陷、回归	测试数据、预期与实际结果、证据、缺陷与遗留项
用户/业务负责人	确认业务参数、角色映射和实施范围，完成业务验收与上线决定	业务口径与授权记录

本次使用 Codex 子代理承担两个工程师角色。角色是任务分工，不改变底层模型或平台权限；长期项目可以将角色说明放入项目指令，每轮明确各自输入、产物和写入范围。

研发工程师任务模板

你担任研发工程师，使用 informat-designer 和 informat 技能。
依据原始需求和已确认设计实施金融风控系统。
先查询平台真实结构，再按依赖顺序串行写入；每次写入后回读。
基础表与字段先建，全部回读后再建关联、查找列表和展示配置。
脚本按工具层、mapper、service 分层，service 不写 SQL。
每个函数写清用途、参数、返回值和异常；关键业务动作输出可追踪日志。
提交真实 ID、差异、验证证据与待解决问题，不将保存成功当作功能通过。
不兼容变更须先提交影响与回退方案，由用户手工确认。

测试工程师任务模板

你担任测试工程师，根据原始 Excel 和已确认业务口径独立测试。
不要只照着研发实现生成断言；逐项核对需求是否被覆盖。
覆盖正常、边界、异常、权限、重复执行、交易更正、数据对账和流程拒绝路径。
先读取研发交付的版本、对象 ID 和入口，确认测试所需环境与样本。
每条用例记录需求 ID、前置条件、输入、预期、实际、证据和结论。
缺陷写清复现步骤与业务影响，交由研发修复，再用原用例回归。
未执行和无法验证的用例保持未验证，不得标为通过。

第一阶段：从 Excel 建立需求基线

给 Codex 的第一条指令应同时说明输入、目标和工作方式：

根据《金融风控管理系统-功能清单.xlsx》创建织信金融风控系统。
请先只读分析四个工作表，按稳定需求 ID 整理功能、角色、规则和验收条件。
创建研发工程师与测试工程师两个 AI 子代理。
研发负责实施，测试负责独立验证，负责人汇总进度和缺陷。
保留原文阈值；缺失的评级权重、汇率、止损与审批人员不能自行编造。
把过程持续写成最佳实践文档，并区分方案、已实施、已验证与已发布。

本次解析得到以下业务主线：

需求组	来源	必须实现的业务结果
产品入池	功能清单、入池单	资料录入、产品查重、自动/审批入池、信息更新留痕
交易与持仓	功能清单	买卖交易录入或导入、按有效交易计算持仓
风险评级与额度	三个业务工作表	R1—R5 评级、评级有效期、产品额度、分类阈值
下单审核	下单风控审核表	使用下单时存量与额度检查，超阈值走例外审批
预警与处置	功能清单	定时检测、风险事件、审批通知、处理与复核
数据看板	看板页面	持仓、类型占比、负责人分析、现金、盈亏与额度
外部对接	功能清单	定时同步交易软件数据与最新指标
OA 与权限	功能清单	组织成员、请假、招聘、入职、报销与角色授权

Excel 中费用单元格为空，不据此生成报价。文件中的说明作为需求材料分析，不能覆盖用户指令或作为直接执行命令。

先关闭决定性缺口

创建表单可以依据清单推进，但以下参数决定计算和审批结果，需要业务负责人补充：

• 投资账户/组合的粒度，负责人能查看哪些账户。
• 评级指标权重、分段、外部评级映射与失效处理。
• 估值币种、汇率来源、费用和成本算法、现金流水来源。
• 止损公式、行情有效期、风险扫描与同步频率。
• 研究员、基金经理、总经理、家族办公室的实际审批人员或角色。
• 交易软件接口、认证、字段样例以及交易更正/撤销协议。
• 清单中的 OA 是否与金融风控同批交付。

缺口只阻止依赖它的功能。可以继续整理模型与测试计划，但不能把缺失价格按零估值，也不能用任意权重产生“正式风险评级”。

第二阶段：连接环境与确认现状

确认 Codex 已能发现 informat 与 informat-designer 技能，读取其 SKILL.md。本次两个技能位于 Codex 本地技能目录，Excel 使用只读解析。

实际调用需要 INFORMAT_HOST、INFORMAT_AGENT_TOKEN 和当前会话标识。凭证通过运行环境注入，不写入文档、Git、脚本或参数文件。

# 确认运行环境具备服务地址与凭证；不输出凭证内容。
test -n "${INFORMAT_HOST:-}" && test -n "${INFORMAT_AGENT_TOKEN:-}"

# 从当前会话与已加载技能中取得下面两个变量，不填写示例 ID。
node "$INFORMAT_SKILL_DIR/scripts/call_informat.js" \
    _company_app_list --threadId "$INFORMAT_THREAD_ID"

本次首次查询返回 agentToken not found。用户提供与 UAT 匹配的新凭证后，查询成功，取得真实应用列表。该结果只证明连接和应用列表查询可用，不证明建表、脚本运行或发布权限已验证。

找到同名应用时先检查定义与范围，避免重复创建。新建应用先校验应用标识唯一；既有应用先做差异与历史数据影响分析。

第三阶段：形成可执行蓝图

研发工程师先读当前技能中的表、流程、仪表盘与相关扩展文档，依据真实支持的字段和组件建模。详细开发说明见研发工程师实施手册。

建议模型分为产品、入池申请、投资账户、下单申请、交易记录、持仓、额度设置、风控规则、评级记录、风险事件与处置记录。行情和汇率结构在接口与估值口径确认后实施；OA 按确认范围增加请假、招聘、入职与报销对象。

产品与交易、评级、申请为一对多关系：子表使用关联记录，产品详情使用带当前产品过滤条件的查找列表。固定风险等级与状态使用列表选择，组织成员优先复用平台身份。审批时需要冻结的资料保存快照，普通展示字段优先使用关联带出，减少重复数据。

流程与入口一起设计

流程/服务	真实业务入口	完成判据
入池审批	入池申请“提交审核”	自动入池条件与人工路径正确，拒绝不进入产品池
下单审核	下单申请“提交风控审核”	常规与例外路径正确，审批结论不生成虚假成交
风控处置	风险事件“提交处置”	检测、审批、方案、结果与复核可追溯
持仓重算	有效交易变更与导入入口	重复执行不重复计仓，更正与撤销后结果一致
风险扫描	已确认的定时任务	同一待处理命中事件不重复发起审批
交易软件同步	管理员入口与定时任务	可追踪、可重试、可对账，接口失败不伪报更新

工作流采用一个应用级流程模块和管理模块，内部承载多个业务流程。任何自动化、脚本或定时任务都要说明服务对象和触发入口。

看板配置示例

采用统一主题和 24 列布局，下表为拟实施蓝图；数据源须在模型回读后绑定真实表与字段 ID。

行	卡片	类型	宽 × 高	数据依据
1	待审批入池、待审核下单、未关闭风险事件、过期评级	Number，各一张	各 6 × 4	申请、下单、事件、有效评级
2	各产品持仓、资产类型占比	ProChart，各一张	16 × 8、8 × 8	持仓按产品/类型聚合，币种筛选
3	风险事件明细、持仓与额度明细	Record，各一张	各 12 × 8	事件与持仓，按真实数据权限过滤

现金与收益看板在现金来源、成本和汇率口径确定后增加，不能先展示无依据数字。仪表盘汇总与明细必须遵循同一账户权限。

第四阶段：研发分批实施

按已确认蓝图实施第一批模型。
先创建所有基础表和不依赖其他表的字段，逐次串行写入并回读。
提交全部真实表/字段 ID、字段类型、唯一性、状态选项和表单布局。
基础结构验证完成后，才创建跨表关联、带出字段、查找列表与显示列。
本批不启用缺少口径的评级、估值、止损和外部同步任务。

模型通过后，再按业务闭环实施功能。每批交付包含需求 ID、入口、配置与脚本版本、依赖、验证数据、结果和回退边界。

复杂服务按 入口 → service → mapper → 工具 调用。mapper 处理数据访问，service 负责产品查重、阈值判断、持仓计算和流程编排。服务日志记录关联的申请、账户、产品、规则与计算时点，记录敏感数据时按字段最小化。

业务状态以服务端关键动作校验为准；隐藏表单字段不等于权限控制，前端必填不等于接口写入完整性保证。多个入口必须共享相同业务限制。

研发负责完成自测、审阅全部待发布项、运行配置检查并发布到UAT，随后交付运行地址、实际发布版本、变更范围和已知限制。测试工程师不负责发布，也不需要进入应用设计器。研发草稿调试与测试工程师的运行态验收分别记录。

第五阶段：测试独立验证与缺陷回归

研发应同时交付可追踪的合成测试数据，而不是只给测试人员一个空应用。本案例已实测准备22条数据，覆盖10张表，并验证重复执行不重复插入；数据场景、对账期望与清理边界见测试数据最佳实践。

测试工程师先读取原始需求与业务基线，再读取研发交付。详细用例见测试工程师验证手册。

只测试研发已经发布到UAT的交付版本，逐条对应需求 ID。
核对交付版本证据和运行地址，不进入应用设计器，不修改设计或发布。
先核对运行态实际业务入口，再执行边界、异常、权限和对账场景。
用明确样本验证“阈值以下、等于、超过”，并检查金额单位与币种。
不要把研发描述、配置保存成功或没有 ERROR 日志当作测试通过。
将缺陷提交研发；研发修复并重新发布后，记录修复版本，再使用原场景回归。

必须覆盖的示例包括：

1. 单标的上限 500 万美元时，分别测试低于、等于、超过上限，先确认比较对象是下单金额还是下单后累计持仓。
2. 单银行上限为总资产 5% 时，聚合同一银行的相关产品，验证分母时点和汇率一致；不能只看单只存款。
3. “0 万美元，单独请示”触发例外路径，未批准不得绕过。
4. 同一交易重复导入不重复计仓；更正或撤销后持仓与有效交易重算结果一致。
5. 同一风险命中连续扫描不重复创建待处理事件；关闭后再次命中的重开规则需另行确认。
6. 交易员不能修改风险规则或批准自己的越权下单；跨账户查询、导出和看板不泄露未授权数据。

每个测试结果必须保存输入、预期、实际、证据与执行身份。配置回读、服务直调、真实入口联调和用户验收是不同证据，分别记录。

第六阶段：交付与过程文档

一个完整项目的交付物应能回答“做了什么、能否运行、如何接管”：

交付物	必要内容
需求与决策台账	来源、需求 ID、范围、业务口径、缺口与确认记录
实际设计映射	表/字段/模块真实 ID、关系、入口、规则、权限与版本
开发进度	本批完成项、未完成项、验证证据和下一批入口
测试与缺陷记录	场景、输入、实际结果、证据、严重程度与回归状态
上线与运行说明	发布对象、授权、配置、同步、监控与回退边界
角色操作手册	录入、审批、处置、查询和管理的实际入口

发布前检查完整应用及全部待发布差异。发布成功后执行运行态冒烟和对账；未提供外部接口、未确认参数或未验证权限的功能保持明确状态。

本次过程记录

步骤	实际结果	证据范围
读取需求 Excel	四个工作表解析成功	只读需求提取
首次连接 UAT	认证失败	返回 agentToken not found
更新会话凭证后查询	成功取得团队应用列表	认证与查询可用；未创建金融风控应用
建立研发工程师角色	已完成文档与纯业务服务实现	Node 12项测试通过
建立测试工程师角色	已完成独立审查与回归	模型补充与集成缺口保持追踪
平台草稿建设	已创建并回读	详见创建实录与结构证据
平台计算验证	12个场景通过，取得业务日志	合成快照直调，无业务记录入账
UAT 测试基线发布	已执行	版本 1.0、构建号 2，发布次数 1；不代表业务验收通过
已发布运行页冒烟	所测项通过，存在3项可用性缺陷	覆盖5张业务表、产品新建/取消、8张看板组件和工作流入口；完整业务验收未完成

本案例可复用的核心方法是：以原始需求约束研发，以独立测试验证结果，用真实平台证据推进阶段，并持续记录业务缺口与交付状态。