智慧合同项目 · 合同管理系统 AI 能力赋能
这里有四面。第一面是用起来什么样——合同审核与起草的完整主链路；
另外三面是让它持续可用的那套内部基座：知识怎么进来、效果怎么度量、坏了怎么被发现和修。
我方认为本项目的工作量与风险主要落在后三面，而它们通常在方案里只是几句形容词——
所以这里把它们也做成可以指着看的东西。
另有一张技术可行性验证单列一节：它不是界面示意，而是把文档同版本比对的算法真的写出来跑给人看；
以及一张工程实物：随方案交付的编排定义文件本身，解析成可以逐节点展开的只读画布。
每一面都是独立页面，可单独打开、单独投屏。数据全部为合成样例。
这一张与上面四面不是一类东西：四面演示是脚本化的（点到哪一步出哪一步， 稳定、可离线、不跑真逻辑）；这一张里没有任何脚本化的结果，换一份文件进去结论就跟着变。 它对应的是本项目里最硬的一段自研工作。
这一张与上面两组又不是一类：四面演示是脚本化的、技术可行性验证跑的是真算法但输入仍是合成样例； 这一张画的是我方随方案交付的那份编排定义，页面上的每一个节点、每一条配置、每一段提示词 都是从定义文件里解析出来的，没有一个字是为演示编的。
方案讲解现场以录屏为主、LIVE 为可选加演；界面呈现另有一份高保真静态原型走廊。
它是一件方案演示工具，不是本项目的交付物，也不代表本项目已完成的工作量。 它要降低的是客户方的需求返工风险：需求在文字上达成一致、等实现出来才发现双方理解不同， 是信息化项目最常见的返工来源。把分歧提前到原型阶段，改的是原型，不是已经开发完的功能。
为什么有四面而不是一面。 一个能点的界面只回答了「用起来什么样」。 真正决定这类项目成败的是后面三件事——知识库的输入质量、效果的度量口径、 上线后出了问题多久能被发现。它们在方案里通常只是形容词，所以我方把它们也做成了可以指着看的东西。
为什么还单列一张「技术可行性验证」。 上面四面是脚本化演示，它们回答的是 「做出来长什么样」，回答不了「这段自研工作我方到底做不做得出来」。文档同版本比对 是本项目里最硬的一段自研工作，所以我方把它真的写出来跑给人看——那一页里没有脚本， 换一份文件进去结论就跟着变。
原型不等于实现。 不接生产数据、不接原厂接口层、不含权限校验与审计留痕， 其中数据均为示意。风险分类编码（R01–R13）与三级风险等级来自技术方案随方案交付的 《合同风险分类词表》，条款样例编号来自同批交付的《合同条款评估样例库（初版）》—— 演示与评估体系共用同一套编码，不各造一套。