LEGACY SYSTEM AI STUDIO
HyCortex ／ 既有系统 AI 工坊
大型既有系统在维护与改造中形成的判断，我们把它沉淀为组织的资产，再让 AI 正确地用起来。
把既有的仓库、设计文档、操作手册、报表与过往的对话收进来，转成代码图谱、LLM Wiki、技能与对话记忆 —— 每一类都带有版本、公开范围与装备对象。
只需把既有的接入地址指向代理，Claude Code、Codex 等编码 AI 在会话开始时就已装备好这些资产；协议不变，也不必额外开发插件。
知识只存放在人身上造成的维护困境
卡住维护的不是技术栈。经济产业省在 2018 年的《DXレポート》中提出过“2025 年悬崖”：既有系统老化与复杂化，2025 年以后每年可能造成最多 12 万亿日元的经济损失。即便系统做了更新换代，这道悬崖也只是换个形式留下来。现场同时面临以下四种问题。
红线、例外处理与过往故障的来龙去脉，代码里没有，设计文档里也没有；记在脑子里的那个人一离职或调岗，这些就跟着消失，留下的人只能把同样的调查再做一遍。
几十万行到几百万行代码里，改哪里会牵动哪里，看不出来。本以为是照搬现状，判断一旦出错，就会演变成质量事故。
签约与验收看的是设计文档，实现却一路往前走。条目编号与实现对不上，到最后谁也说不清哪一边才是现行版本。
命名、红线与报表格式，各个项目都不一样。操作步骤始终跟着人走，因此每换一次负责人，就得从头学一遍。
资产先行配备、再在日常作业中不断更新的流程
为了不让第一项工作变成“把这个项目重学一遍”，我们先备齐所需的资产，再进入作业。作业中弄清楚的事，当场回流到资产里。
收录完成之后，代码图谱与 LLM Wiki 即可异步投入使用，不必等三条通道全部就绪。
关卡上由人来看内容；判定不宜公开的就不装备，因此不会自动对全员开放。
没有记忆的循环，只是把同样的调查做得更快而已。回流这一步，是整条流程的关键。
使下一次改造得以承接上一次调查的机制
01 里的四件事，原因都是同一个：知识只存放在人身上。把它挪到资产上之后，交接不必从零开始，调查不必通读全文，现有的工具也不必更换。
对话记忆把偏好、事实、决定与红线分层保存，不依赖聊天记录。因此换一个会话、换一个负责人，都能从同一套前提接着往下做。
像“旧认证模块手机端还在用”这一类前提，哪份资料上都没有写，以往只能靠口头转述。资深人员脑子里的那些红线，不会再随着离职或调岗一起消失。
代码图谱把符号、调用关系与影响路径作为代码的结构保存下来。指定改动起点之后，工具会逐层回溯，把从那里能到达的位置全部列出来，再分成要处理、要确认、无影响三类返回。
几十万行到几百万行，人不必通读。图谱同时保存每个文件的摘要，因此哪怕是第一次接触的模块，也能先弄清它到底在做什么。
这不是给全员换一套 IDE 的方案。只需把既有的接入地址指向代理，Claude Code、Codex 等在会话开始时就已装备好技能、Wiki、图谱与记忆。协议不变，因此也不必额外开发插件。
不打开编码 AI 的人，另有一个入口：控制台上的聊天应用。调查、运维、评审与协力公司，都用同一份 Wiki 与同一份图谱作依据提问。入口有两个，但成果都回流到技能与记忆里，知识不会因此分成两套。
四类资产 —— 各自结构化了什么，又因此能做什么
资产不是存起来的文件。它带有版本、公开范围与装备对象，按归属人与状态管理，需要时可以撤下。
资产的管理、分组、权限与装备配置，都在部署于客户自有环境的控制台上统一完成。
调用 LLM 只发生在抽取、摘要与回答的时候；系统并不是按“把代码全文持续外发”来设计的。
公开范围按资产逐份划定，分本人、团队、限定与 Agent 四档。每一份都带有归属人、版本与状态，撤下之后，已装备的副本同步失效。
编码 AI 本身不是我们做的。本方案不去替换它，而是作为底座把资产装备上去；回答的品质取决于客户所用的模型。
收录进来的资产不会自动对全员开放。中间要插入一道人工确认再装备的手续，这部分工时省不掉。
做过定量评价的，是已落地 4 个现场中的 2 个。其余 2 个现场仍在调查与成果物编写的日常业务中持续使用，但没有做测量。
现场A 的数字是整条工序的效果，现场B 的数字是与编码 AI 单体相比的差值，口径不同，不可相加。“独立上手所需的时间”是主观感受，不是测量值。
4 个现场的落地，以及其中 2 个现场的实测效果
已落地 4 个现场，其中 2 个已完成定量评价。下面逐项对照：按整条工序测出的效果，与只同编码 AI 单体相比测出的效果 —— 两者口径不同，分开来看。
现场A —— 大型套件运维，测的是整条工序
| 领域与指标 | 导入前 → 导入后 | 效果 |
|---|---|---|
| 规格调查 —— 现行规格的调查时间 | 10H／件 → 6H／件 | 缩短 40% |
| 代码品质 —— 评审指摘密度（CDI） | 5.78 件／KL → 3.89 件／KL | 改善 32% |
| 生产率 —— 详细设计文档编写至实现完成 | 0.55 KL／人月 → 0.72 KL／人月 | 提升 30% |
| 返工 —— 指摘处理时间（CD） | 12.75H／KL → 7.5H／KL | 减少 41% |
| 上手 —— 独立上手所需的时间 | 1 年以上 → 3 个月 | 主观感受 |
运行十几年的大型套件运维现场（VB.NET／C#，约 12,000 KL）的实测值（截至 2026 年 8 月）。调查时间取 5 件的平均。只有“独立上手所需的时间”不是测量值，而是负责人的主观感受，资料中也是这样注明的。KL 指 1,000 行，CDI 指评审指摘密度，CD 指指摘处理时间。
现场B —— Java 的大型既有系统，对比的是编码 AI 单体
| 作业 | 效果 |
|---|---|
| 构建项目专用技能 | 2 个月 → 3 周 |
| 使用专用技能编写代码 | 约 1.5 倍（提升 50%） |
| 使用专用技能编写测试规格书 | 缩短 30% |
| 向编码 AI 单次提问的 Token 量 | 减少 35% |
| 依赖关系的调查时间 | 缩短 50% |
在 250 万行以上的 Java 既有系统上，把本方案接到第三方的编码 AI 上，与 AI 单体的状态做对比得到的实测值（截至 2026 年 8 月）。上面的现场A 测的是整条工序的效果，口径不同，请不要相加。
落地的规模
NEXT
咨询请联络相关负责人。
只要指定一个对象，我们就会展示对应的成果物及验证报告。
可以直接查看实际系统的输出，判断这套方式是否有效。
只需告知选定哪一个对象，即可开始。