认识创始人

Kyle Castor谈以基点衡量的价值创造

Kyle Castor，创始人兼首席架构师 • 61秒 • 字幕 • 由工作室肖像生成的AI主持人

文字稿

00:00致身在拉斯维加斯的私募股权基金和运营合伙人：您的投后价值创造不应被困在四十页的幻灯片里。

00:11在DataOngoing，我们严格以EBITDA基点来衡量工作成果。两小时的高管投入可换来数百小时的自动化工作，并由我们的100x时间台账予以证明。

00:24第一，在注入资金之前，用48至72小时的AI技术尽职调查评估为技术债务定价。第二，将21天的多主体结账压缩至3天。第三，从车间到总账的自动化数据采集，直接进入NetSuite。

00:44我们以14天冲刺交付可运行的代码。如果未在生产环境中运行，该里程碑不收费。请访问DataOngoing.ai预约私人咨询会议。

  1. 我们的工作方式 →
  2. 查看100x台账 →
  3. The productized offers →
  4. 基点冲刺 →

简报中的每个数字均连同其来源类别发布在本网站上；章节链接指向这些页面。

预约战略沟通会阅读完整简介

机器翻译（审校中）。以英文版为准。

首页 / 工作流设计
工作流设计

来自已交付项目的工作流设计

以下每个设计都是我们已构建并运行的工作流：工作经过的各阶段、每个阶段发生的事项，以及由人员审批的节点。这些设计根据实际工作图重新绘制，因此客户以原型形式呈现，数据保留在所链接的案例研究和台账行中，并标明来源类别。可按领域或设计所属的项目阶段筛选。

这些设计基于项目的四个阶段。发现阶段评估系统；构建阶段在两周冲刺内将代码投入生产；部署阶段在不中断运营的情况下上线；信任阶段是审批关卡、审计轨迹和对账，使审计师能够追溯每条记录。

发现在访谈任何人之前先读取系统。
构建在2周冲刺内将代码投入生产。
部署在不中断运营的情况下上线。
信任审批关卡、审计轨迹，以及精确到分的对账。

10个设计

  1. 单据录入：从纸质单据到已过账的物料收货单
  2. 受管控的AI智能体：可自由读取，写入必须经人工
  3. 上下文数据包：任何模型调用之前的预检查询
  4. 双模型共识：在提出草稿之前先进行独立解读
  5. 语音录入：一通电话最终生成已排程的工单
  6. 单一入口点：为每次交易保存提供一个受管控的路由器
  7. 技术尽职调查评估：遥测优先，访谈置后
  8. 实时切换：从装卸月台到总账，全程批次可追溯
  9. 设计变更门户与基于承运商扫描的开票
  10. 收入主线：HubSpot、Stripe与NetSuite对账精确到分
领域
阶段

01 / 10AI智能体构建建模的复合案例

单据录入：从纸质单据到已过账的物料收货单

运行场景：制造和分销企业的收货月台与应付账款岗位；带有炉号或批次号的装箱单、承运商运单、供应商发票

送货单或供应商账单以PDF、扫描件或手机照片的形式到达。视觉模型读取内容，SuiteQL匹配供应商、零件和未结采购订单行，智能体据此提出带批次子记录的物料收货单或供应商账单。由人工批准；无需任何人重新录入炉号。

从纸质单据到已过账的物料收货单：单据录入流程 扫描件由模型读取；总账由人员写入。每个提取字段都附有来源页面和置信度分数。

  1. 01采集

    1. 装箱单、提单或供应商账单通过电子邮件、扫描仪或手机照片送达
    2. 文件进入录入队列，并附有发件人和时间戳
    3. 按内容哈希与已有文档进行重复检查

  2. 02提取

    1. 视觉OCR对多页PDF和照片进行规范化处理
    2. 表头、行项目、数量、炉号或批次号、到期日期
    3. 每个字段均有置信度；低置信度字段会被标记，绝不猜测

  3. 03在NetSuite中匹配

    1. SuiteQL匹配：供应商名称对应实体ID
    2. 通过别名历史将供应商料号对应到物料
    3. 为三方匹配提取未结采购订单行

  4. 04提议

    1. 带批次子记录的物料收货单或供应商账单草稿
    2. 对照采购订单计算行差异
    3. 证据包：来源页面、提取值、匹配记录

  5. 05审批与过账

    1. 与采购订单完全匹配的单据进入队列，一键审批
    2. 存在差异的单据保持待处理，PDF与草稿并排显示
    3. NetSuite以审批人的角色写入记录

控制点

  1. 没有指定审批人，任何单据都不会过账。审批只需一次点击，手工录入不再需要。
  2. 每份草稿均带幂等键，文件重复发送时不会生成第二张收据。
  3. 字段级置信度和来源页面引用使每一行在事后均可审计。
02 / 10AI智能体构建建模的复合案例

受管控的AI智能体：可自由读取，写入必须经人工

运行场景：多子公司服务控股公司；企业托管服务与复杂物流

中央路由器将工作分派给专业智能体，每个智能体仅通过正式的Model Context Protocol工具执行操作：参数化的只读SuiteQL、记录结构和草稿提案。读取返回实时数据行。写入则停在审核弹窗，由主管批准后NetSuite才提交记录。

Aissistor编排：可自由读取，仅通过人员写入模型是综合分析与异常检测的工具，从不是事实来源，也从不直接操作总账。

  1. 01输入

    1. 经OCR处理的供应商PDF账单
    2. 来自CFO的自然语言提问
    3. 定时执行的夜间诊断

  2. 02中央路由器

    1. 代理调度器与状态机
    2. 来自企业知识库的上下文

  3. 03专业智能体

    1. 应付账款匹配智能体
    2. 总账毛利流失检测器
    3. SuiteQL取证审计器

  4. 04受治理的MCP工具

    1. execute_suiteql，只读
    2. get_record_schema
    3. propose_transaction_draft

  5. 05生产总账

    1. 读取返回实时SuiteQL数据行
    2. 草稿止于人工审批弹窗
    3. 获批草稿提交至ACID总账

控制点

  1. 基于角色的令牌，以及审计人员可检查的读写边界；不使用爬虫，不共用数据库驱动。
  2. 工作单元回答中的每个数字均可追溯到一条并非由其生成的SuiteQL数据行。
  3. 工作单元可在五千张采购订单中找出十四张重复发票；但无法为其中任何一张过账贷项。
03 / 10AI智能体构建建模的复合案例

上下文数据包：任何模型调用之前的预检查询

运行位置：任何涉及主体、币种或税务的AI智能体：应付账款匹配、利润流失检测、针对总账的财务问答

商用模型在ERP内部会失效：要求它们在很长的上下文中记住内部ID、税务关联和汇率时，就会出错。本设计从不要求模型这样做。先由代码运行查询，再把一个小型的结构化实时数据行包交给模型，用于眼前的这一项任务。

上下文数据包：由代码组装，由模型推理 模型从不接触数据库结构。它看到的是为当前任务组装的一个小型实时数据行包，包中的每个值都标明其来源行。

  1. 01触发

    1. 一份收到的单据、一个来自财务的问题，或夜间诊断
    2. 路由器对任务分类并选定工作单元
    3. 工作单元所需的上下文是预先声明的，而不是临时拼凑的

  2. 02预检SuiteQL

    1. 参数化的只读查询，仅取所需的行
    2. 主体、未结采购订单行、币种、税务关联、物料别名
    3. 结果在本次运行内缓存；循环中不使用已保存的搜索

  3. 03上下文数据包

    1. 带有记录内部ID的紧凑结构化数据包
    2. 个人数据在离开租户之前被遮蔽
    3. 每个值都标注其所属的表和行

  4. 04模型推理

    1. 模型仅基于数据包进行推理
    2. 输出中的每个数字都可追溯到数据包中的某一行
    3. 未知信息以问题形式返回，而不是猜测

  5. 05记忆

    1. 已解析的别名和决定写入知识库
    2. 下一次运行从修正后的映射开始
    3. 人工的修正会成为工作单元遵循的规则

控制点

  1. 数据包构建器持有只读、按角色限定范围的凭证；无法写入。
  2. 遮蔽和行标注在调用模型之前由代码完成，因此模型不会看到任何它不需要的姓名。
  3. 数据包连同提示词哈希一并记录，因此任何答案都可以重放和核查。
04 / 10AI智能体信任建模的复合案例

双模型共识：在提出草稿之前先进行独立解读

运行位置：应付账款，以及模型的读取结果会成为总账分录的任何录入环节：供应商账单、贷项通知单、合同条款

一个模型对发票的读取只是一种意见。由代码对照采购订单比较的两次独立读取才是证据。仅当两次读取一致且与NetSuite相符时，该关卡才会提出草稿；任何分歧都会成为例外，并将两次读取结果并列呈现，且任何一个模型都没有通往总账的路径。

共识关卡：两次读取、一次确定性比较、一次人工审批 两个模型在看不到彼此输出的情况下读取同一份单据；由代码对照采购订单进行比较；分歧会成为例外，绝不会成为过账。

  1. 01独立提取

    1. 模型A提取表头、明细行、数量和批次序列号
    2. 模型B提取同一份单据，看不到A的结果
    3. 两者均按同一结构返回结构化输出

  2. 02确定性比较

    1. 代码逐行比较A和B
    2. 合计金额根据明细行重新计算，而不是从页面读取
    3. 付款条款、重复发票号和税码均对照NetSuite进行核查

  3. 03结果

    1. 金额精确到分且与采购订单匹配：提出草稿
    2. 任何分歧：生成例外，并将两次读取结果并列呈现
    3. 任何一个模型都没有通往总账的路径

  4. 04人工审批

    1. 审批人可以看到草稿、证据和差异
    2. 一次点击即批准；一次点击即退回
    3. 记录以审批人的角色保存

  5. 05审计轨迹

    1. 提示词哈希值和模型版本记录在系统备注中
    2. 两次读数均随单据保留
    3. 审批戳记和时间戳记录在交易上

控制点

  1. 一致性由设有固定容差的代码判定，而非由第三个模型判定。
  2. 使完全匹配的单据进入一键审批队列的容差，是由财务总监负责的设置。
  3. 模型供应商可以互换；关卡是设计本身，而非某一特定模型。
05 / 10AI智能体部署建模的复合案例

语音录入：一通电话最终生成已排程的工单

适用场景：来电多在非工作时间到达的现场服务和安装类企业；本网站上的多语言智能体采用同样的模式

来电者接通的是对话式智能体，而非语音信箱。智能体会说明自身身份，记录客户、站点、问题和紧急程度，通过只读调用在 NetSuite 中核对账户和排期，并起草一张带有预留时段的服务订单。调度员负责放行；异常情况连同通话记录转交专人处理。

语音受理：从第一声铃响到调度员的队列 对话为实时语音。所需的每项事实均通过只读调用从 NetSuite 获取，最终决定权仍在调度员手中。

  1. 01来电

    1. 呼入电话，包括非工作时间
    2. 告知来电者对方是 AI 智能体，并记录其同意
    3. 识别语言；智能体以该语言应答

  2. 02对话

    1. 流式语音转文字及文字转语音
    2. 记录意图和事实：客户、站点、问题、紧急程度
    3. 未知信息通过询问获得，而非假设

  3. 03只读查询

    1. 通过电话、姓名和地址在 NetSuite 中匹配客户和站点
    2. 合同或保修状态、未结订单、上次到访
    3. 根据排期查询技术人员的可用时间

  4. 04提议

    1. 依据所记录的事实起草服务订单
    2. 拟定时段为预留，而非已预订
    3. 向来电者复述确认

  5. 05确认与交接

    1. 向来电者发送短信或电子邮件确认
    2. 调度员查看队列并放行时段
    3. 异常情况和回电连同通话记录转交专人处理

控制点

  1. 通话以披露和同意开始；通话记录随订单保留。
  2. 对话期间对 NetSuite 的每次调用均为读取。写入是调度员的操作。
  3. 预留，不预订：时段保留待审核，因此两名来电者不会占用同一时段。
06 / 10NetSuite ERP构建建模的复合案例

单一入口点：为每次交易保存提供一个受管控的路由器

适用场景：每次保存都会触发一组用户事件脚本的 NetSuite 账户：分销、制造、订阅计费

同一记录类型上的十几个脚本按无人指定的顺序运行，每个脚本都在用户线程上加载搜索，保存因此卡死或冲突。单一入口点以一个类型化路由器取代这一堆脚本：同步处理仅为内存中的校验，所有繁重工作都在保存之后通过幂等队列运行。

单一入口点：一个路由器、内存中校验、保存之后的队列 每次保存都通过一个类型化路由器进入。同步处理是基于缓存数据的校验；GL分配、信用检查和分发在保存之后运行。

  1. 01记录事件

    1. 从界面、RESTlet、CSV 导入或 EDI 保存的销售订单、物料收货单或发票
    2. 每种记录类型一个部署，取代这组用户事件脚本
    3. 捕获的上下文：角色、来源、记录状态

  2. 02路由器

    1. 按记录类型和事件进行类型化分发
    2. 确定性的规则顺序，在代码中声明
    3. 每条规则配一个功能开关，以便安全上线

  3. 03内存内校验

    1. 规则基于缓存的参考数据进行评估
    2. 记录保存流程中不使用已保存搜索或记录加载
    3. 尽早拒绝，并给出明确的提示信息

  4. 04队列

    1. GL分配、信用检查、EDI分发和通知均进入队列
    2. 每个作业配一个幂等键；重试是安全的
    3. Map/Reduce工作进程在保留治理余量的前提下清空队列

  5. 05总账与遥测

    1. 在已发布的复盘中，保存操作的返回时间远低于1秒
    2. 随着同步工作的移除，记录锁冲突随之消失
    3. 记录每条规则的耗时，用于速度基准测试

控制点

  1. 规则集中在一处阅读，审计人员可以看到一次保存的全部副作用。
  2. 同步代码不得调用搜索；如有调用，部署检查（lint）将失败。
  3. 队列作业具备幂等性且可重放。失败的作业会被重试，绝不会重复执行。
07 / 10NetSuite ERP调研建模的复合案例

技术尽职调查评估：遥测优先，访谈置后

适用场景：基于NetSuite的私募股权收购标的和新收购的被投企业；也是每个DataOngoing项目的第一步

传统的调研要用数周时间访谈人员，最后交付一份演示文稿。本设计直接读取系统：只读角色，通过SuiteQL查询执行日志、脚本、搜索、角色和集成，并生成依赖关系图，发现项按风险敞口排序。评估报告在获得访问权限后48-72小时内提交，费用计入第一个冲刺。

尽职调查评估：从只读角色到排序的路线图 先读取系统，再访谈人员。从获得访问权限到提交评估报告为48-72小时，每项发现都注明其来源数据行。

  1. 01访问

    1. 由标的公司的管理员授予只读角色
    2. 商定范围：脚本、搜索、角色、集成、交易量
    3. 没有研讨会，没有访谈日程

  2. 02提取

    1. 通过SuiteQL查询脚本部署、执行日志和治理用量
    2. 已保存搜索、工作流、自定义记录及其所有者
    3. 角色和权限按0-4的角色风险指数（Role Risk Index）评分

  3. 03分析

    1. 热点路径：保存记录时触发的脚本及其耗时
    2. 锁冲突、N+1搜索、未建索引的条件
    3. 集成和中间件，及其故障模式

  4. 04架构图

    1. 从记录类型到脚本再到集成的依赖关系图
    2. 发现项按美元风险敞口和修复工作量排序
    3. 明确说明评估无法看到的内容

  5. 05评估报告说明

    1. 书面报告，以及与交易团队的评估说明会
    2. 固定价格的冲刺路线图
    3. 评估费用全额计入第一个冲刺

控制点

  1. 只读访问；尽职调查期间，目标系统中的任何内容均不会改变。
  2. 每项发现均注明其来源的日志行、脚本ID或角色。
  3. 报告会说明哪些内容无法观察到，因此不会因缺乏信息而推断出任何发现。
08 / 10NetSuite ERP部署建模的复合案例

实时切换：从装卸月台到总账，全程批次可追溯

运行场景：$70M的西海岸易腐食品与饮料分销商；冷链食品及易腐饮料分销

实物入库与会计处理解耦。扫描枪将数据提交至幂等的暂存 RESTlet，并在1秒内完成释放；Map/Reduce 工作进程绑定批次和有效期，计提到岸成本，并将该SKU释放至拣货波次。从旧平台的迁移以幂等的增量数据导入方式跨班次交接完成。

从装卸月台到总账：暂存收货架构实物入库与会计对账解耦。扫描枪在1秒内即被释放；总账处理在其后运行。

  1. 01入库收货

    1. 装卸月台上的冷藏卡车
    2. 移动RF扫描托盘标签
    3. 采集供应商、SKU、批次、有效期、重量

  2. 02暂存引擎

    1. 幂等 RESTlet 暂存队列
    2. 原子子记录校验
    3. 有效：800 ms 内生成暂存物料收货单
    4. 出现差异：转入QA隔离库位暂存

  3. 03异步批次与总账引擎

    1. Map/Reduce 分配流水线
    2. 将批次号绑定到先进先出的库存子记录
    3. 计提预估运费到岸成本
    4. 将SKU释放至拣货打包波次

  4. 04受管控的财务核心

    1. 借记库存资产，按批次核算
    2. 贷记到岸成本清算计提
    3. 实际承运商账单到达后与对应批次匹配

控制点

  1. 重试的扫描枪会更新同一条暂存记录；不会生成第二个托盘。
  2. 批次和有效期子记录在实物录入的当下即完成校验，此时仍可更正。
  3. 出现差异时转入隔离库位暂存，而不阻塞装卸月台。
09 / 10NetSuite ERP构建建模的复合案例

设计变更门户与基于承运商扫描的开票

运行场景：$90M的工程过滤和暖通空调系统制造商；工业设备和工程过滤制造

设计变更是一项商业事件。Suitelet 记录该变更，锁定生产工单，按物料成本重新定价，并等待项目经理批准，然后在一笔交易中更新销售订单和工单。开具发票也成为一项事件：承运商扫描触发发票的核验、过账和发送。

订单到发票：之前与之后承运商扫描提单的那一刻，开具发票所需的信息就已存在。引擎直接使用这些信息；无需任何人重新录入。

  1. 01之前：14个工作日

    1. 车间发运设备
    2. 纸质随货单与设备一同打包
    3. 设计变更记录在共享电子表格中
    4. 在 NetSuite 中人工审核账单
    5. 12-14个工作日后才生成发票

  2. 02之后：不到2分钟

    1. ShipStation 承运商扫描
    2. 履约Webhook接入NetSuite
    3. 配对引擎校验里程碑和DCR审批
    4. 生成发票并过账至总账
    5. 向客户发送电子发票

控制点

  1. 已记录的变更会锁定下游生产工单，直至该变更获批或被撤回。
  2. 销售订单、工单和发票通过程序关联，审计人员无需电子表格即可追溯任一行项目。
  3. 发票只有在履约、审批和条款经作业校验后才会过账，而非由文员校验。
10 / 10NetSuite ERP信任建模的复合案例

收入主线：HubSpot、Stripe与NetSuite对账精确到分

运行场景：高增长B2B SaaS与订阅制业务；b2b软件及科技赋能服务

商务条款在CRM中一次性录入。成交的商机会自动创建客户、销售订单和Stripe订阅；每笔付款Webhook将总额、净额和手续费作为一笔分录过账；ASC 606安排在商机成交时创建。每个载荷都按Stripe事件ID生成哈希，因此重试不会重复过账。

收入主线：一笔商机，五次交接，无需重复录入 商务条款在CRM中一次性录入，并由代码转换为会计分录，包括支付网关手续费。

  1. 01HubSpot

    1. 商机标记为成交
    2. 载荷：条款、产品、席位

  2. 02NetSuite开通

    1. 校验税号、币种、子公司
    2. 创建客户和销售订单
    3. 创建Stripe客户和订阅计划

  3. 03Stripe

    1. 刷卡扣款或发送发票
    2. Webhook：invoice.payment_succeeded，含总额、手续费和交易编号

  4. 04结算引擎

    1. 按净存入金额借记Stripe清算科目
    2. 借记支付处理手续费费用
    3. 按总额贷记应收账款

  5. 05收入引擎

    1. 创建收入安排和公允价值分摊
    2. 过账月度递延收入日记账

控制点

  1. 网关手续费在数据接入时拆分，因此银行存款到账当日即可精确到分匹配。
  2. 按事件ID对Webhook去重：重复请求向Stripe返回成功，且不过账。
  3. 销售代表不负责维护税码或汇率；向会计规则的转换由代码完成。

建模的复合案例：每个设计均取自已交付的工作，客户以典型案例形式呈现。数据见所链接的案例研究和100x时间台账，均标注来源类别。设计的构建与计费方式：我们的工作方式。

常见问题

这些是项目中的实际图表吗？

这些图表经过重绘。实际工作图表包含客户名称、员工姓名和账户详情，因此架构以原生泳道图发布，客户以典型案例形式呈现。其中的阶段、交接和审批节点均为实际运行的节点。

AI设计会自行写入NetSuite吗？

不会。此处所有AI设计均通过受控的只读工具读取数据并提出草稿。由指定人员审批，NetSuite在该人员的角色下写入记录。审批只需一次点击，但这一点击由人完成。

数据在哪里？

见所链接的案例研究和100x时间台账，均标注来源类别。图表本身不包含这些页面已发布内容之外的数据。

这些设计能否适配我们的技术栈？

这正是2周冲刺的用途。自获得访问权限起48-72小时的评估会显示哪种设计适合，以及它能带来哪些变化；冲刺将其以代码形式交付到生产环境，评估费用全额抵扣首个冲刺。

直接与架构师沟通，而非销售人员

面向 NetSuite 的 Aissistor 技术：将企业所支付的五个角色吸收到一个受管控的盒子中，建模成本降低 20-80%，现有团队转岗而非替换，每项成果均在100x时间台账中公布并标明来源类别。阅读台账。

预约战略沟通会   运行五角色计算器

The direct email and phone number are shared in the receipt of a verified request.