|
|
@@ -1,175 +0,0 @@
|
|
|
-# 为「陕西局系统 / 非通防业务」单独建一套项目骨架 — 必要性分析
|
|
|
-
|
|
|
-*写给不写代码的人看。全文没有技术术语，出现的每个数字都可以在代码库里复核。*
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 一、结论
|
|
|
-
|
|
|
-**建议单独建一套，并且不要从零开始——直接以已经建好的 `vent_deep_agent_2.0` 骨架为起点。**
|
|
|
-
|
|
|
-三句话概括理由：
|
|
|
-
|
|
|
-1. **现有的 1.5 不是"能装各种业务的平台"，它是一套"通防专用系统"。** 数字上很清楚：它的工具代码里 85% 是通防专用的，接口里有点击解读、报告、Excel 这类只有通防用得上的东西。想在上面长出通防之外的新业务，等于在一个已经装满通风专业的房间里再塞一个新部门——东西用不上，但占地方、还得一起搬家。
|
|
|
-2. **"单独建"最难的那部分钱已经花掉了。** 一套新系统里最贵、最容易出事的通用地基（对话、历史记录、中断恢复、用量计费、定时任务、日志追踪）已经在 2.0 骨架里做完了，而且这六个部分里**没有一处通防业务的痕迹**，是干净的通用底座。
|
|
|
-3. **真正的成本不在"拆"，而在"对接陕西局的接口"。** 这块工作无论拆不拆都要做，而且它才是新项目的主要工作量。把"拆不拆"和"对接工作量"混在一起讨论，会得出错误的结论。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 二、先看两组数字
|
|
|
-
|
|
|
-### 1.5 是什么状态
|
|
|
-
|
|
|
-| 项目 | 数量 |
|
|
|
-|---|---|
|
|
|
-| Python 代码总量 | 62,391 行（229 个文件） |
|
|
|
-| 前端界面 | 单个文件 228 KB / 4,888 行 |
|
|
|
-| 工具代码 | 17,509 行，其中**通防专用 14,861 行（85%）** |
|
|
|
-| 业务技能 | 21 个，其中**通防专用 16 个（76%）** |
|
|
|
-| 测试代码 | 27,238 行（占全仓 44%） |
|
|
|
-| 对外接口 | 31 个 |
|
|
|
-
|
|
|
-注意最后两行。"测试代码占全仓 44%"意味着这套系统的稳定是靠**大量针对通防业务的验收测试**顶住的——这些测试对新业务一条都用不上。而外面包着一层"通用外壳"的 31 个接口里，混着点击解读、报告生成、Excel 转换这些通防专用端点。
|
|
|
-
|
|
|
-再看耦合程度（这是判断"能不能在上面加东西"的关键）：
|
|
|
-
|
|
|
-| 层面 | 含通防业务内容的文件比例 |
|
|
|
-|---|---|
|
|
|
-| 接口层（api/） | **12 / 20 = 60%** |
|
|
|
-| 智能体组装层 | 2 / 11 |
|
|
|
-| 计费 / 调度 / 日志追踪 | **0 / 13 = 0%** |
|
|
|
-
|
|
|
-**接口层被业务渗透了六成**——这说明 1.5 早就不是"通用框架 + 业务插件"的结构了，而是通防业务长进了骨架里。只有计费、调度、日志这三块是干净的。
|
|
|
-
|
|
|
-### 2.0 骨架是什么状态
|
|
|
-
|
|
|
-| 项目 | 数量 | 对比 1.5 |
|
|
|
-|---|---|---|
|
|
|
-| Python 代码 | 7,407 行 | 1.5 的 **12%** |
|
|
|
-| 测试代码 | 1,638 行 | 1.5 的 **6%** |
|
|
|
-| 对外接口 | 31 个 | 与 1.5 相同 |
|
|
|
-| 六个通用层里的通防术语 | **0 处** | — |
|
|
|
-
|
|
|
-有意思的是接口数量：**1.5 是 31 个，2.0 也是 31 个**，但性质完全不同——1.5 的 31 个里混着通防专用端点，2.0 的 31 个全部是通用能力（会话管理、历史记录、中断恢复、用量计费、定时任务、模型配置）。
|
|
|
-
|
|
|
-用同样的接口数量，2.0 做的是纯地基。
|
|
|
-
|
|
|
-> 唯一的例外：2.0 的工具目录里出现过 8 次通防词汇，全部集中在一个**演示用的检索工具**的示例数据里（我拿"矿井通风"当样例内容）。那是测试用的假数据，不是业务耦合，删掉不影响任何功能。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 三、如果坚持"在 1.5 上改"，会是什么局面
|
|
|
-
|
|
|
-这不是"多花点时间"的问题，是三类具体的麻烦：
|
|
|
-
|
|
|
-**第一类：新业务的开发和测试，要在一整套通防环境里进行。**
|
|
|
-新项目的每一次改动，都要跑一遍 1.5 那 27,000 行测试里跟通防有关的部分，否则不知道有没有碰坏老系统。反过来，通防的日常维护也可能碰坏新业务。两边的风险互相传染。
|
|
|
-
|
|
|
-**第二类：发版被绑死。**
|
|
|
-1.5 现在服务的是通防管控平台，是**已经在跑的存量系统**。新业务必然要快速试错、频繁改动。一旦两套东西在一个代码库里，"新业务急着上线"和"老系统不能动"这两个要求会天天打架——最后通常是老系统被迫接受新业务带来的风险，或者新业务被迫等老系统的发版窗口。
|
|
|
-
|
|
|
-**第三类：数据边界会糊掉。**
|
|
|
-陕西局的数据和通防管控平台的数据如果进同一个库、同一套账号体系，将来出问题（谁看了谁的数据、谁的责任）时说不清。这对交付验收和合同责任是实质风险，不是洁癖。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 四、"单独建一套"要额外付什么
|
|
|
-
|
|
|
-必须诚实列出来，否则这个分析没有说服力：
|
|
|
-
|
|
|
-| 代价 | 实际情况 |
|
|
|
-|---|---|
|
|
|
-| 通用地基要不要重做 | **不用**。2.0 骨架里已建成（对话、历史、中断、计费、调度、日志，共 7,407 行 + 1,638 行测试） |
|
|
|
-| 登录鉴权 | **两边都还没有**。1.5 用的是外部系统的身份校验，2.0 骨架目前完全没做鉴权——这是新项目**必须补**的一块，且和拆不拆无关 |
|
|
|
-| 运维成本 | 要维护两套部署、两套数据库、两套日志。这是真实成本，规模取决于团队人数 |
|
|
|
-| bug 修两遍 | 只有**确实两边都用的**通用代码会面临这个。目前这块很小（计费/调度/日志），且可以通过"改一处、同步另一处"的方式管理 |
|
|
|
-| 人员分散 | 取决于团队规模。人少于 3 人时，同时维护两套会明显吃力 |
|
|
|
-
|
|
|
-关键点：**"单独建"的代价主要是"运维与人员"，不是"重新开发"。** 因为最难的部分已经做完了。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 五、三种做法摆在一起比
|
|
|
-
|
|
|
-| | 做法 A：在 1.5 上加 | 做法 B：以 2.0 骨架另起一套 | 做法 C：完全从零重写 |
|
|
|
-|---|---|---|---|
|
|
|
-| 新的通用地基 | 不用做 | 不用做 | 要做（等于重复 2.0 的活） |
|
|
|
-| 新业务代码 | 要做 | 要做 | 要做 |
|
|
|
-| 对接陕西局接口 | 要做 | 要做 | 要做 |
|
|
|
-| 对存量通防系统的影响 | **高**（同库同版，改动会互相牵连） | **无**（完全隔离） | 无 |
|
|
|
-| 数据边界 | 混在一起 | 天然分开 | 天然分开 |
|
|
|
-| 发版节奏 | 被绑死 | 各自独立 | 各自独立 |
|
|
|
-| 额外运维负担 | 最低 | 中（多一套） | 中 |
|
|
|
-| 交付风险 | 高（动老系统） | 低 | 中（重复劳动+周期长） |
|
|
|
-
|
|
|
-**做法 C 明显不划算**：2.0 骨架已经把从零重写该做的事做完了，再重写一遍只是多花时间。
|
|
|
-
|
|
|
-真正要选的是 A 和 B。而 A 的"省一套运维"换来的是"存量系统跟着承担风险"，这笔账在**新业务是通防之外的产品线**时通常不划算。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 六、推荐做法：B，并且立刻能开始
|
|
|
-
|
|
|
-推荐 **做法 B**，理由是三个事实叠加：
|
|
|
-
|
|
|
-1. 新业务是**通防之外的产品线**（不是给通防加功能），两边在业务上没有共享逻辑，硬放一起得不到任何复用收益。
|
|
|
-2. 通用地基**已经建好且已验证**（149 项自动化测试 + 51 项端到端检查全通过），不需要重新投入。
|
|
|
-3. 陕西局的数据与通防平台的数据**本来就该分开**，这不是技术偏好，是责任边界。
|
|
|
-
|
|
|
-具体怎么落地：
|
|
|
-
|
|
|
-**直接拿过来用（不用改）**：2.0 骨架的全部通用代码与测试、部署方式、模型接入方式、日志与追踪。
|
|
|
-**必须分开（不能共用）**：数据库、部署实例、账号体系、前端页面、业务技能与工具。
|
|
|
-**需要补做（新项目必做项）**：登录鉴权（两边都缺）、陕西局的接口对接、新业务的数据表设计、新业务的技能手册、新业务界面。
|
|
|
-**待你决定**：用量计费是合并统计还是各算各的；日志要不要汇总到一处。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 七、这个判断依赖哪些我还不掌握的信息
|
|
|
-
|
|
|
-上面所有分析都基于**代码事实**，但有一个前提是我假设的、没有依据的——请核对：
|
|
|
-
|
|
|
-1. **我假设"非通防管控平台业务"是一条与通防业务没有共享逻辑的新产品线。** 如果它其实和通防有大量共用计算或共用数据，那共用代码的收益会上升，结论可能变成"部分共用、但数据分开"。
|
|
|
-2. **我完全不了解陕西局系统是什么**：它的性质（政府监管系统？企业侧系统？）、由谁主导、和现有通防管控平台是什么关系（替代？并行？上下级？）。如果陕西局系统将来要**取代**现有的通防平台，那讨论就不该是"另起一套"，而是"怎么平稳迁移"——那是完全不同的一份分析。
|
|
|
-3. **我不知道交付时间要求和团队人数。** 人少于 3 人时，同时维护两套的代价会明显超过隔离带来的收益，那时做法 A 反而更现实。
|
|
|
-4. **我不知道商务与合同边界**：如果陕西局是独立合同、独立验收，拆分几乎是必然要求；如果是同一合同的延伸，则要权衡。
|
|
|
-
|
|
|
-**这四条里，第 1 条和第 4 条最关键。** 建议先确认这两条，再定拆不拆。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 八、真正的工作量在哪里
|
|
|
-
|
|
|
-把"拆"和"对接"分开看，你会看到成本分布完全不同：
|
|
|
-
|
|
|
-| 工作项 | 大致性质 | 能否现在估 |
|
|
|
-|---|---|---|
|
|
|
-| 通用骨架 | **已完成** | — |
|
|
|
-| 登录鉴权 | 中等 | 能（两边都缺，是明确的一块） |
|
|
|
-| 新业务前端界面 | 中等 | 能（2.0 的 444 行测试页可作为起点，但业务界面要重做） |
|
|
|
-| 新业务的数据表设计 | 取决于业务复杂度 | 需要新业务的需求清单 |
|
|
|
-| **对接陕西局的接口** | **可能是最大一块** | **需要接口清单才能估** |
|
|
|
-| 新业务的技能手册与工具 | 逐项累加 | 需要新业务的功能清单 |
|
|
|
-
|
|
|
-**要估工期，我需要的材料是**：陕西局提供的接口文档（或接口清单），以及新业务要做哪几件事的说明。有这两样，上面每一行都能给出区间估计；没有的话，任何具体天数都是编的。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 九、需要提前防的三个风险
|
|
|
-
|
|
|
-**风险一：把"拆"当成目的。**
|
|
|
-拆是为了让两条产品线各自跑得快、互不牵连。如果拆完之后两边还要频繁同步改动，那拆的收益就没了。**防范**：明确哪些是共享的（目前只有计费/调度/日志），并为这几块定一个"改一边要同步另一边"的规矩。
|
|
|
-
|
|
|
-**风险二：鉴权被当成"以后再说"。**
|
|
|
-2.0 骨架目前没有鉴权——任何人都能自称身份，用量计费和会话归属都建立在这个自称上。**当前只适合内网或开发环境。** 新项目一旦对陕西局开放，鉴权是上线前的硬门槛，不能拖到后面补。
|
|
|
-
|
|
|
-**风险三：新业务的规模被低估。**
|
|
|
-"对接几个接口"听起来简单，但每个接口背后通常跟着数据清洗、异常处理、字段对不上的协商。**防范**：先拿陕西局接口清单做一次逐条评估，再谈工期。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 十、一句话总结
|
|
|
-
|
|
|
-**这不是"要不要多花一笔钱重建"的问题——地基已经建好了。这是"新业务要不要和存量系统绑在一起"的问题。** 从业务边界、数据责任、发版节奏三方面看，都不该绑。建议以已建成的 2.0 骨架为起点另起一套，并把主要精力放在陕西局接口对接上。
|
|
|
-
|
|
|
-需要我先确认的只有两件事：**新业务与通防是否有共用逻辑**，以及**陕西局是独立合同还是现有合同的延伸**。
|
deep_agent