项目介绍：AI 原生领域建模与 API 设计平台
提取词
- S｜背景：业务讨论易发散 ｜ 业务约定难沉淀 ｜ 模型与工程实现脱节
- T｜职责：企业运营合约建模 ｜ 双层循环 Harness ｜ 模型到 AI Coding 交付输入
- A1｜业务建模：参与方与权责 ｜ 履约流程 ｜ 请求、确认与凭证 ｜ 异常责任及数据变化
- A2｜工程交付：业务模型 ｜ RESTful API ｜ OpenAPI ｜ 请求与预期结果测试数据
- A3｜过程控制：外层 PDCA ｜ 内层 Steering Loop ｜ 增量修改 ｜ 结构校验与人工审核
- R｜结果：业务与研发沿一致模型核对 ｜ 建模产物进入前后端开发与 AI Coding 验证循环
项目介绍
这个项目是一套桌面端 AI 原生领域建模与 API 设计平台，解决业务讨论容易发散、业务约定难以沉淀，以及模型与工程实现脱节的问题。我负责建模方法、双层循环 Harness 和平台核心能力，并推动不绑定具体语言与框架的建模产物进入不同技术栈的前后端开发与 AI Coding 工作流。
业务建模从企业运营合约出发，先梳理参与方、权责、履约流程和异常责任，再沿履约时间线追溯请求、确认与凭证，识别每一步带来的数据变化。AI 负责按这条主线持续追问，人提供真实约定并审核业务含义，最终将讨论沉淀为可共同核对的对象、关系和规则。
确认后的业务模型继续映射为资源、URI、角色、HTTP 方法和业务场景，形成 RESTful API 设计；平台据此生成 OpenAPI 文档，以及包含请求与预期结果的静态测试数据。这些产物以业务语义和契约为稳定边界，剥离具体语言与框架细节，既支撑不同技术栈的前后端实现，也为 AI Coding 提供可迁移的结构化上下文和验证依据。
为了让 AI 多轮工作可控，我使用外层 PDCA 管理范围、审核和阶段接续，以内层 Steering Loop 组织前馈、行动、反馈与调整。平台采用 Electron、React 和 React Flow 承载建模过程，通过 Pi SDK 驱动 AI 增量修改本地模型文件；生成阶段检查结构与格式，业务含义由人审核，每轮结束后重读完整模型并刷新图谱。
业务、产品和研发已持续使用这套流程，从企业运营合约出发核对业务规则，并把业务模型、API 和测试数据作为后续实现与验收的共同依据。
简历描述
AI 原生领域建模与 API 设计平台
- 技术栈：Electron、React、React Flow、Pi SDK、OpenAPI、Nx + pnpm
- 项目简介：设计并实现桌面端 AI 原生领域建模与 API 设计平台，以企业运营合约为起点，在业务方那里逐条确认谁承诺了什么、做没做到要拿什么证明——有金钱往来的看权责与凭证，没有金钱往来的看 KPI 目标与实际——梳理参与方、权责、履约流程及异常责任带来的数据变化，沉淀业务模型、RESTful API 与测试数据；以业务语义和契约剥离语言、框架细节，为不同技术栈的 AI Coding 提供可迁移的结构化上下文和验证依据。
- 工作内容与成果：
- 运营合约建模：围绕参与方权责组织履约请求、确认与凭证，沿履约时间线追溯业务依据并检查异常责任及其数据变化，将业务讨论沉淀为对象、关系与规则。
- AI Coding 交付输入：将确认后的业务模型映射为资源、URI、角色、HTTP 方法和业务场景，设计 RESTful API，派生 OpenAPI 文档及包含请求与预期结果的静态测试数据，为前端对接和后端 API 开发提供上下文与验收依据。
- 双层循环 Harness：使用外层 PDCA 管理范围、审核与阶段接续，以内层 Steering Loop 组织前馈、行动、反馈和调整；以模型、API 和测试数据作为 AI Coding 的输入与检查依据，将验证结果反馈到后续修订。
- 桌面端增量建模：使用 Electron、React、React Flow 与 Pi SDK 承载建模过程，驱动 AI 增量修改本地模型文件，执行阶段检查，并在每轮结束后重读完整模型和刷新图谱。
可能追问
为什么从权责关系开始建模？怎样让业务讨论收敛？
问题提示：共同入口 ｜ 真实约定 ｜ 主要履约 ｜ 请求与确认 ｜ 凭证来源 ｜ 异常责任 ｜ 范围核对。
过去我们进行建模和需求理解的时候，使用的是头脑风暴的方式，每个人的切入点不同，收敛方式也不同，最终构建的模型有很大差异，而且很难在团队中达成共识。问题不是信息有没有收集完整，而是缺少一个共同遵循的分析主线。
借此，我从企业财务和经营视角出发，把企业运营合约作为建模的共同起点：先明确参与方约定了什么，再沿着各方的权利和义务，逐步追问如何履行、又如何证明已经履行。这样讨论就有了可以共同核对的依据，而不必先从各自输入的功能或者技术方案出发。
以我们网上购物为例，我们之所以能拿到商品，是因为我们和商家之间通过订单构建了一份约定，拿到商品是我们的权利，而发货是商家的义务。同样的，收款是商家的权利，付款是我们的义务。这样不管是什么部门，入职多久，都可以沿着同一条主线理解业务。
明确权责以后，还需要回答：凭什么提出要求，又凭什么确认对方已经完成？因此，AI 会继续追问：订单的价格从哪里来，用什么凭证证明商家已经发货，又用什么凭证证明买家付了款。
我们再回到真实业务中，发现，发货需要物流单作为凭证，付款需要支付单作为凭证。继续追溯，物流单来自顺丰、中通等第三方物流系统，支付单来自微信、支付宝等支付平台。这也让我们识别出商家与物流服务、买家与支付平台之间各自的合同关系。但是在当前订单上下文中，我们只需要明确这些凭证的来源和作用，不必把外部系统的细节全部展开。
到这里，我们梳理的是合约正常履行的情况。接下来，AI 会围绕同一组权责继续追问异常：如果商家要求在规定时间内付款，而买家没有付款，这个订单如何处理？可能是超时取消；如果是特殊的预订单，那么商家就有权不退预付款。
反过来，如果商家没有按时发货，买家可以按约定申请退款。此时要求退款是买家的权利，按照要求退款是商家的义务。如果商家仍然拒绝退款，后续就可能进入法律程序，由法院根据合约约定和履约执行情况进行裁定。此时，处理已经超出当前业务系统的范围，就可以让 AI 在这条路径上停止追问。
说到底，业务逻辑是非常理性的：就是多赚钱少花钱，规避法律风险，提供合规审计。因此，业务中的约定和履约凭证，并不是为了建模临时编出来的，而是企业运营过程中本来就需要的依据。我们让 AI 围绕这些依据追问，及时回到同一份约定和凭证上核对，而不是争论各自设想的流程。
采用这种方式后，我们对需求的讨论，从两个小时难以收敛的会议，变成了任何一位参与者都可以负责推进的渐进式流程：先从自己掌握的真实约定出发，在 AI 的引导下逐步梳理权责、履约凭证和异常处理；遇到不清楚的问题，再向相关业务方确认，并继续完善模型。
有了共同确认的领域模型，我们再据此设计 RESTful API，以及包含请求与预期结果的测试数据，把已经澄清的业务约定转化为前端对接和后端 API 实现的 AI Coding 上下文与验收依据，以支撑 Agent Harness 的稳定执行。
案例：CRM 电话销售管理
提取词：讨论发散 ｜ KPI 约定 ｜ 双方职责 ｜ 执行凭证 ｜ 正常与异常 ｜ 范围边界 ｜ 渐进建模 ｜ 工程交付。
做 CRM 电话销售管理的需求分析时，如果直接从“系统需要哪些功能”开始讨论，每个人的切入点很容易不同：管理者关注目标完成情况，销售关注客户跟进，研发关注页面、字段和统计报表。即使收集了很多需求，也可能因为缺少共同的分析主线，得到不同的模型。
所以，我会从企业经营和内部管理视角出发，把管理者与销售之间的 KPI 约定作为建模的共同起点：先明确双方约定了什么，再追问谁负责执行、如何检查，以及用什么证明目标已经完成。这样，讨论就有了可以共同核对的依据，而不必先从各自熟悉的功能或技术方案出发。
以电话销售为例，管理者和销售会约定一个周期内需要联系客户多少次，其中电话、邮件分别有什么要求。这份绩效约定明确了目标和周期：销售按约完成客户联系并提供执行记录，管理者依据约定核对进度和结果。无论是什么部门、入职多久，都可以沿着这条主线理解业务。
明确约定以后，还需要回答：凭什么提出要求，又凭什么确认已经完成？因此，AI 会继续追问：目标由谁提出、由谁确认？联系次数按拨打电话计算，还是按有效沟通计算？同一客户重复联系怎样统计？这些问题决定了目标的含义，以及什么样的执行结果才算完成。
我们再回到真实业务中，就需要找到能够证明执行情况的通话、邮件或客户跟进记录。继续追溯，还要明确记录来自哪里、何时发生、关联哪个客户，以及应该计入哪个目标。这样，“实际完成了多少”就不再是一个直接填写的数字，而是可以根据约定规则，从执行凭证中核对出来的结果。
如果通话记录来自电话系统，邮件记录来自邮件系统，那么在当前绩效管理范围内，只需要明确这些记录的来源和证明作用，不必把电话拨号、邮件发送等外部系统的内部细节全部展开。周会、月会中的进度检查，则可以理解为依据这些凭证，对目标完成情况进行核对和确认。
到这里，我们梳理的是正常执行和检查的过程。接下来，AI 会围绕同一份约定继续追问异常：记录缺失或不符合计入规则时怎样处理？检查时联系次数不足，是周期内尚未完成，还是周期结束后没有达标？如果已经到期，双方是否约定了补充跟进、调整计划或其他后续处理？
如果约定要求补充跟进，就继续明确由谁负责、什么时候完成，以及用什么记录确认。后续是否还有新的处理责任，也要回到真实管理约定中核对。当处理已经转入独立的人事或劳动争议流程，超出当前 CRM 的职责范围时，就明确衔接所需的约定和执行证据，在这条路径上停止展开。
这背后的经营逻辑也很明确：企业通过设定目标、检查实际执行来管理成本和效率。因此，绩效约定和执行记录，并不是为了建模临时编出来的，而是日常管理、结果核对和责任追溯必然需要的依据。即使参与者最初理解不同，也可以回到同一份约定和凭证上核对，而不是争论各自设想的流程。
采用这种方式，建模就不必依赖所有人同时参加一次集中会议，而可以由任何一位参与者负责推进：先从自己掌握的 KPI 约定出发，在 AI 的引导下逐步梳理目标、执行凭证和异常处理；遇到不清楚的问题，再向相关业务方确认，并继续完善模型。
有了共同确认的领域模型，我们再据此设计 RESTful API，以及包含请求与预期结果的测试数据，把已经澄清的业务约定转化为前端对接和后端 API 实现的 AI Coding 上下文与验收依据，以支撑 Agent Harness 的稳定执行。
难点一：怎样让 AI 多轮增量建模可控？
提取词：外层 PDCA ｜ 内层 Steering Loop ｜ 结构检查与业务审核 ｜ 增量文件 ｜ 轮次结束后刷新。
业务约定会在讨论中逐步清楚，模型需要持续完善。这里要分开两个问题：当前该处理什么，以及这次修改怎样做对。
外层用 PDCA 循环管理范围和阶段：Plan 明确本轮问题与交付结果，DO 则由另一层操纵循环负责，Check 核对结果，Act 决定继续、修订还是返回人类澄清。
操控循环（Steering Loop） 控制一次修改：前馈 Feedforward 读取当前模型、来源和方法约束；⾏动 Action 基于前馈增量修改模型对象文件；反馈 feedback 进行结构与格式校验；调整（Steer）根据反馈修订看是对格式进行自我纠正，还是遇到业务分歧交回外层。
为了方便人类审阅与交互以及模型进入版本管理，我开发了基于 Pi SDK 驱动 AI 修改本地文件的桌面可视化系统，每轮执行结束后全量刷新 React Flow 图谱。
难点二：怎样把业务模型转成可验收的 API 契约？
提取词：操作在模型中的落点 ｜ URI 表达对象与关系 ｜ 角色、方法与场景 ｜ 分布式超媒体 ｜ 业务流程覆盖。
我采用的是模型驱动的 API 设计，真正关注的是这一次操作会给模型带来什么数据和变化关系，再确定资源和操作方式。
以 CRM 电话销售作为接口设计示例，管理者登记月度客户联系目标，是在一份绩效协议下新增一个目标；销售登记实际发生的客户联系，则是在相应目标下新增联系记录。模型决定资源结构，业务场景决定允许哪些操作。 因此，可以从绩效协议出发，沿“协议 → 月度目标 → 联系记录”的聚合关系组织 URI，区分协议集合、某份协议、其下的目标集合和某个目标。客户档案属于独立领域，通过引用关联到联系记录，业务规则仍由领域对象及其关联承载。
有了这些资源定位，再把角色、HTTP 方法、URI 和业务场景放在同一张表中，与业务方确认哪些组合需要对外提供。比如管理者登记月度目标、销售登记联系记录可以用 POST，读取协议或目标用 GET；修改、删除是否成立，则要根据实际约定判断。领域模型中存在一个对象，并不意味着要为它机械地开放全部 CRUD，系统内部自动完成的过程也不直接等同于对外接口。
客户端还需要知道怎样从当前资源找到关联能力，所以资源表示要包含分布式超媒体链接，用 href 给出地址、rel 说明关系。集合可以提供常用信息，需要详情时再跟随实例的 self 链接，主 URI 也作为资源身份与缓存设计的依据。这样，客户端按服务端给出的关系按需消费，不必自行拼出全部访问路径。
这些 API 是否够用，要重新放回管理者和销售的业务流程中检查：管理者能否在协议下登记目标，销售能否向相应目标登记联系记录，以及能否按约定周期和渠道核对完成情况。记录数量不足时应保持未完成，周期外记录是否排除、记录与目标归属是否匹配，也要作为验收场景检查。发现缺口就回到资源、关系或规则核对，再由平台的 API 设计流程生成 OpenAPI 文档和包含请求、预期结果的静态测试向量，由运行环境装配并执行验证。
资源契约也把业务能力与部署方式分开。设计上优先从企业运营合约的上下文考虑封装，只有履约项确实需要独立弹性边界时才进一步拆分；模型关系和对外语义保持一致时，内部编排与部署可以继续演进。