一、写这个工具的起因
每个开过会、跟过项目的人应该都经历过这个场景：
会议结束，纪要发到群里，任务表在协作文档里更新了一版，群聊里还有人随手补一句「这个我来盯」。信息是全的，但散落在三种完全不同的格式里。一周之后开跟进会，没人说得清三个最基本的问题——
谁、在什么时候、要完成什么？
具体有多散？拿我造的演示材料（星辰科技产品研发周会，人物公司均为虚构）举例：
纪要正文写：「决议 2.1：增加支付链路熔断阈值，由李思远负责，10月12日前上线」——责任人、时间、动作都藏在一句自然语言里；
任务表里同一件事是另一行，但责任人栏只写了「李」，截止日格式还是
10-12；群聊记录里有人口头认领：「熔断阈值我算了一下，按当前QPS峰值设成800比较稳……最晚10月9日提申请」——这话纪要里根本没记。
人工对齐这三份材料，要开着三个窗口一行行找。漏掉一条，轻则跟进度的人当场尴尬，重则上线那天直接爆。这才是会后最真实的痛点：承诺发生在三种格式里，跟进却往往只看其中一份。
所以这个工具的定位很克制——它不替你开会、不替你录单、不替代项目管理系统，只回答一个问题：这几份材料里的行动项，能不能自动归成一本台账，每条还能点回原文。
二、作品介绍
会议行动追踪台，一个单文件 HTML 的 Web 应用，参加 TextIn「文档觉醒」AI 应用创新赛赛道一（实用价值赛道）。
把会议纪要 PDF + 任务表 PDF + 群聊记录 PDF一起拖进页面，工具逐份调用 TextIn xParse 解析，然后：
三个来源各抽一遍行动项——纪要抽「决议 + 责任人 + 截止日」，任务表读表格网格，群聊识别口头认领；
跨源归并——三处来源指同一件事的合并成一条，证据全部保留（
meeting-minutes.pdf p.1 / task-board.pdf p.1这样的溯源标注挂在每条右侧）；时效与风险评估——按截止日算临期/逾期，叠加任务表的高危标记和依赖阻塞，每条风险都带成因；
页面产出——行动项清单（可按状态/风险过滤）、责任人负荷排行、风险与遗留面板、KPI 总览。
实测内置示例一轮跑完：14 条行动项、7 位责任人、3 条高风险、11 条风险提示，全部从 3 份 PDF 自动归集，零人工录入。
三、搭建过程
3.1 技术选型：为什么是「单文件 HTML + xParse」
我想清楚了两条边界：
数据不出浏览器。会议纪要是敏感材料，所以解析请求从浏览器直发
api.textin.com，不经任何中间服务器，解析完即从内存释放；零部署成本。没有后端、没有框架、没有 CDN 依赖，HTML 文件拖进浏览器就能跑，评审拿到文件双击就能看。
文档解析这层完全没有自研的必要——纪要是版式文档、任务表是表格、群聊记录是仿聊天气泡的排版，自己写规则解析等于给自己挖坑。xParse 一次接口全吃下，这正是「xParse 结合度」评分想看到的使用方式：把解析交给引擎，把业务逻辑留给自己。
3.2 核心接口调用
同步接口，FormData 直传，请求头带凭证：
POST https://api.textin.com/api/v1/xparse/parse/sync x-ti-app-id: <App ID> x-ti-secret-code: <Secret Code> Content-Type: multipart/form-data file: 待解析的 PDF config: {"capabilities":{"include_table_structure":true,"title_tree":true, "include_hierarchy":true,"include_inline_objects":true}}四个 capability 开关都打开，其中include_table_structure是任务表场景的命根子——打开后表格以table_structure.cells[]返回，每个单元格带row、col、coordinates，这是「单元格级溯源」能力的来源。
密钥管理做了双层：XPARSE_KEY常量内置演示凭据，页面加载时内置值优先；面板填写的那份（存 localStorage）作回落。这样评审打开就能解析真实文件，换账号也不用改代码结构。
3.3 三种来源的抽取策略
这是整个工具业务逻辑最重的部分，三种格式三套打法：
会议纪要（自然语言）。正则为主：责任人抓由/负责/责任人[:：]前缀后面的人名（还要剥掉「负责修订」「工程师」这类职务后缀，「不变」「待定」直接丢弃）；日期抓\d{1,2}月\d{1,2}日(前)?和2026-10-12两种写法。另外配了一个「陈述句过滤器」——句子里出现「提示|说明|认为|原因是|由于|提醒」这类词的，是背景陈述不是派活，不抽，否则风险描述会被当成行动项。
任务表（结构化表格）。从 xParse 返回的 markdown 里取<table>还原成二维网格，按表头文字语义匹配列：「任务/事项」列、「责任人/负责」列、「截止/期限」列、「依赖/前置」列、「状态/进展」列、「风险/等级」列——按表头找，不按位置取，换一种版式的任务表也能读。取到的每条行动项记录文件名 + 页码 + 行号，页面上就是那个紫色的溯源标签。
群聊记录（对话流）。识别认领句式（第一人称 + 动词 + 时间承诺），归到说话人名下。这块最难的是判断「这句话算不算任务」：纯技术讨论（「按当前QPS峰值设成800比较稳」）不算，「最晚10月9日提申请」才算。
3.4 跨源归并：最值钱的一步
三处来源抽完只是半成品。真正的价值在归并：纪要里的「决议 2.1」、任务表里的 T-03、群聊里的口头承诺，指向的是同一件事，必须合成一条行动项、保留全部证据。
判据是加权重合度：语义关键词重合 + 责任人一致 + 时间相近。归并后每条行动项的右侧会列出它所有的证据来源，演示时点开「值班响应流程修订」这条，能看到纪要和任务表两处出处——这正是人工整理最容易漏的「纪要没写、群里说了」。
3.5 一个踩坑：数字清洗
和上个作品（单据勾稽台）同一个坑：解析结果里日期偶尔被拆成「10 月12 日前」。直接喂给日期正则全错位。所以清洗必须放在取数之前：去空格、去数字中间的逗号、统一日期写法。教训记住了：任何解析结果都不要直接信任，先归一再参与计算。
另外时效计算固定以会议日 2026-10-05 为基准，而不是Date.now()——不然演示效果随打开时间漂移，下周打开全是「已逾期 3 天」，很尴尬。
四、使用体验
实际用下来的感受分三点：
上传很顺。三份 PDF 拖进同一个区域即可，没有顺序要求，每份单独调接口、各自显示进度。解析失败的文件按错误码给中文提示（40307 显示为「今日免费额度已用完，明天 00:00 自动恢复」，用户看不到原始错误码）。
溯源是安全感来源。AI 抽取难免有误，页脚也老实写了「关键行动项请以原始纪要为准」。但每条行动项都能点回原文——文件名、页码、表格行列坐标都在，核对成本极低，这让「自动抽取」从「不敢信」变成了「快速抽查」。
风险面板是真正每天会看的东西。14 条行动项平铺是没人看的，但「3 条高风险 + 成因」（「4 天后到期，尚未开始且临近截止」「任务表标记为高风险，依赖 T-03」）一眼就知道今天该催谁。
五、效果展示
内置示例（星辰科技产品研发周会，3 份材料）载入后：
✓ 会议纪要.pdf → 决议行动项 + 责任人 + 截止日 ✓ 任务表.pdf → 表格逐行，含状态/风险/依赖列 ✓ 群聊记录.pdf → 口头认领 + 时间承诺 KPI：14 行动项 · 7 责任人 · 3 高风险 · 0 已逾期 · 6 条 7 天内到期 · 2 条有依赖
两个最有说服力的瞬间：
决议 2.1（纪要）与群聊承诺归并成同一条——演示时把这条单独点开，两个来源的证据并列（下图 T-05 行右侧同时挂着
meeting-minutes.pdf和task-board.pdf两个标签），比说什么都有力；风险成因链——「设计资源冲突应对方案」这条：4 天后到期 + 尚未开始 + 前置依赖 T-03，三条原因叠出来一个红色高风险，直接回答「明天站会先聊什么」。
六、在线体验与说明
在线地址：会议行动追踪台 · TextIn xParse （已内置演示密钥，打开即可解析真实文件；不想消耗额度就点「载入内置示例」，效果完整）
素材为虚构演示材料（星辰科技产品研发周会），不含真实业务数据
#TextIn 、#AI数据层基础设施；
