【交叉评测】specs 深度审查：政策白皮书 ≠ 技术规格书 — 从文档到可实现产品的 gap 分析 #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📚 交叉评测意见：语境关通 specs.md 深度审查 — "写了很多，但开发者拿到后不知道怎么动手"
一、项目理解
语境关通聚焦 CBAM 正式期（2026 年起）的跨境贸易低碳合规，定位企业侧"申报前预检"，桥接成都海关单一窗口。提出 P/E AI 解耦架构（PAI 交互层 + EAI 专家矩阵 + A2A 调度协议），声称有 12 项软著、5 项专利、与上外联合研发多语种模型、碳强度 AI 预测准确率 95%+。
已有 Issue #1/#2/#3/#4 全部指出仓库只有 specs.md，没有代码。本份不再重复"没有代码"这个结论，而是深入审查 specs.md 本身的质量——它作为技术规格书，能否指导开发者实现产品？
二、Spec 亮点
政策研究功底扎实：对 CBAM 2026-2034 年免费配额递减时间表、默认值制度终结、复杂商品 80% 实际数据穿透要求的描述非常精确，引用了具体的法规编号和生效日期。这不是网上抄的，是有真实调研基础的。
用户画像和痛点分析到位：四类目标用户（出海制造企业、报关代理、AGI 开发者、海关智库）的核心痛点和平台赋能价值都有具体描述，不是泛泛而谈。
评测标准设计有野心：YAEB 评测套件涵盖了任务达成、精度验证、效率基准、安全攻防四个维度，指标量化程度高（95% 准确率、98% 召回率、P95 延迟 ≤ 0.8s 等），在同类项目中少见。
商业模式思考成熟："中间服务主体"的生态位选择、Credits 分润机制、校企培训合作等，不是学生项目的空想，有商业逻辑。
三、Spec 问题
🔴 P0：这是政策白皮书，不是技术规格书
specs.md 的 8 个章节中，只有第 5 节"产品思路"和第 6 节"AI 在哪里发挥作用"涉及技术，但它们的写法是概念介绍而不是技术规格。
一个开发者拿到这份 specs，无法回答以下问题：
整份 specs 没有一个 API 端点定义、没有一个数据模型、没有一个接口签名、没有一个函数原型。 它描述的是"系统应该做什么"，而不是"系统怎么实现"。
建议：至少补充以下内容：
🔴 P0：第 6 节声称的 AI 能力无法从 Spec 中验证
specs.md 第 6 节声称：
但 specs 中没有：
同样，声称"与上海外国语大学联合研发多语种通用语言大模型"，但 specs 中没有模型名称、参数规模、训练语料、评测 benchmark。
一个无法从 spec 中验证的 95% 准确率声称，在评审中是不可信的。
建议：如果这些 AI 能力已经实现，至少在 specs 中附上技术报告链接或实验记录；如果尚未实现，应该明确标注为"目标"而非"已达成"。
🟡 P1：评测标准不可执行 — 5,000 条 Golden Dataset 在哪？
specs.md 第 7 节声称建立了"包含 5,000 个真实历史通关纠纷、CBAM 申报不合规单证样本的专用黄金测试集"。但仓库中：
同样声称"11,200 条红队攻击向量"用于安全评测，但也没有数据。
评测标准写得再好，没有可执行的评测代码和数据，就是不可验证的。
对比 CrossComply 项目的
scratch/golden-tests.json（36 条测试）+scratch/run-golden-tests.js（完整测试 runner），差距是本质性的——一个是可运行的验证，一个是纸面承诺。建议：
🟡 P1：P/E AI 架构缺乏技术细节 — "解耦"说了等于没说
specs 说"PAI 负责交互，EAI 负责能力，A2A 负责调度"，但这个"解耦"的技术边界是模糊的：
这些问题的答案直接影响系统架构，但 specs 全部用抽象概念代替了技术定义。
建议：画一张技术架构图（不是概念图），标注每个组件的技术选型、通信协议、部署方式。
🟡 P1："数字孪生能力引擎"是四个空壳模块
specs 第 5.1 节描述了四个"数字孪生共性能力组件"：
四个组件的描述都是功能愿景而非技术规格。没有一个组件说明了数据结构、接口、输入输出。
建议：要么删掉这个章节（它增加了理解成本但不增加可实现性），要么把每个组件缩小为具体的可实现模块并给出技术规格。
🟡 P1：Spec 内部存在声称与描述的矛盾
声称"桥接为主、自研为辅"，但第 6 节花了大量篇幅描述自研 AI 能力（碳强度预测模型、多语种大模型、数字孪生引擎）。到底哪个是主？
声称"轻量化补位"，但架构描述涉及 PAI + A2A + EAI Matrix + 数字孪生 + 四大孪生组件 + Credits 结算——这不是轻量化，这是全栈平台。
声称"不干预或替代官方流程"，但评测标准要求"生成文件必须能够直接通过成都海关 CBAM 辅助填报系统的格式与必填字段强校验"——这实际上是在替代官方填报流程。
声称有"12 项软著 + 5 项专利"，但仓库中没有一行代码。这些软著和专利对应的是什么系统？
建议：统一 spec 的定位——如果是 MVP，就砍掉数字孪生和 Credits 结算；如果是完整愿景，就明确区分"已实现"和"规划中"。
🟡 P1：性能指标缺乏工程依据
specs 声称的性能指标：
这些指标看起来很精确，但没有说明测量条件：
特别是"政策问答模块"要求 0.8 秒内完成"复杂跨国法律条文实时多语种交互"——如果用 LLM，这个延迟基本不可能实现（除非用极小的模型或极度优化的缓存策略）。
建议：要么标注为"目标值，需要实测验证"，要么附上工程可行性分析。
🟢 P2：商业模式章节对 MVP 来说过早
第 8 节"商业模式与社会价值"声称"百万级商业闭环"、"全新的低碳合规咨询师高薪服务岗位"、"产教融合培养复合人才"。这些描述对于一个还没有代码的项目来说是过度乐观的。
建议：在 MVP 阶段，商业模式章节可以简化为"目标客户 + 付费意愿验证计划"，不需要写成商业计划书。
四、Spec vs 实现 Gap 分析
五、综合评价
语境关通的政策研究深度是这批项目中最突出的——CBAM 法规解读、免费配额递减时间表、默认值制度变化、企业痛点分析都有真实调研基础。评测标准的设计思路（四维度 × 量化指标）也是有野心的。
但 specs.md 的根本问题是：它是一份面向投资人/评委的白皮书，而不是面向开发者的规格书。 开发者拿到这份 specs，无法开始写代码——因为没有 API 定义、没有数据模型、没有接口签名、没有技术栈选型。
已有 Issue #1/#2/#3/#4 全部指出"需要补代码"。本份评测的核心发现是：specs 本身也需要重写——从白皮书格式改为技术规格书格式。
具体建议（按优先级排序）：