IT智能服务台项目目录审计报告

审计对象:D://资料//03-项目开发//wecom_it_smart_desk;只读扫描,未移动、重命名或删除任何文件。

扫描时间:2026-08-09 08:25:34

文件数29,548
目录数3,698
重复组(含非依赖目录)300
10MB以上大文件12

一、结论摘要

该目录已从单一应用仓库演变为“源码 + 多环境部署 + 历史归档 + 调试工作区 + 构建产物 + WorkBuddy 运行数据”的混合工作区。主要问题不是单个文件,而是版本边界、事实源、敏感信息和可再生产物没有彻底分离。不建议直接批量删除;应先冻结基线、完成分类和凭据轮换,再按批次治理。

  1. 最高优先级:凭据轮换与历史/备份扫描。
  2. 第二优先级:统一 src 运行时源,隔离根目录遗留前端树与 dist/归档/临时目录。
  3. 第三优先级:建立单一生产配置、状态看板和质量门禁。

二、问题与优化建议

等级问题证据与影响建议
P0凭据与敏感信息暴露在版本目录中发现硬编码数据库/Redis/Neo4j密码或部署凭据迹象;例如 docker-compose.yml、deploy-server/docker-compose.yml、archives/add_full.py、archives/add_neo4j.py。即使文件被忽略,也可能存在 Git 历史或备份副本。立即轮换已出现过的密码/令牌;用 secrets/env 文件或 Vault 注入;对 Git 历史和 archives/.backup 做凭据扫描,确认未被远端保存。
P0工作树与版本边界失控git status 显示大量已修改/未跟踪内容,包含源码、PRD、部署脚本、dist 版本目录、归档包和临时修复脚本;当前目录同时存在根目录旧 frontend-* 与 src/frontend-* 两套代码。冻结当前工作树并先生成基线清单;明确 src 为唯一运行时源;按“源码/文档/部署/临时/备份”分区,分批提交,禁止直接 git add -A。
P1构建产物与历史备份混入项目目录扫描到 29,548 个文件、3,698 个目录;src 约 752 MB、neo4j5_chunks 约 300 MB、.backup 约 164 MB、archives 约 162 MB;多个 dist_*、zip、tar.gz、part、截图目录。将构建产物、部署包、备份和运行数据迁移到仓库外对象存储/制品库;仓库只保留可复现构建输入与小型示例。清理动作需另行确认,当前未执行任何删除。
P1重复文件与重复前端树检测到大量 SHA-256 相同文件组(其中 1,314 组含非 node_modules 路径),包括 tools 下重复资源、frontend-h5 多个 dist 版本与备份/归档副本。先按“运行必需/回滚必需/历史留档/可再生”四类标注,再用 manifest + hash 去重;不要直接删除根目录 frontend-*,先核对其未提交修改与 src 版本差异。
P1文档状态与实现状态可能失配README 最后更新为 2026-06-03,仍写“AI 回复未集成”等旧状态;而当前记忆/源码治理已推进到 2026-08-09,另有架构图、情况报告、看板 HTML/Markdown、PRD 和评审材料多套并存。建立单一权威状态源;README 仅保留入口与快速开始,项目状态、风险、发布记录分别由看板/变更日志维护,并在 CI 中检查文档日期与版本号。
P1部署配置存在多份事实源根 docker-compose.yml、docker-compose.dev.yml、deploy-server/docker-compose.yml、docker-compose.split.yml 和多批 deploy-* 脚本并存;配置中还存在默认密码、不同 worker/端口/挂载方式,容易造成“本地验证通过、生产路径不同”。区分 local/dev/staging/prod 配置;生产 compose 只保留一份模板,部署脚本只做参数化渲染;加入 compose config、nginx -t、健康检查和回滚演练的发布门禁。
P1自动化测试与类型债务README 声明 pytest/Vitest 未完善;项目记忆记录坐席前端全仓 vue-tsc 存量错误约 105 处,虽未落在本次审批改动文件。建立分层质量门禁:后端单测/集成测、前端 vue-tsc、关键 E2E;先允许存量基线,禁止新增错误,再按模块偿还。
P2文件命名与编码污染根目录出现以 Markdown 粗体标记、特殊字符或乱码编码生成的零字节文件,如“**REQ编号**:”及其乱码变体;说明某些脚本/导出链路将文档文本错误地转成了文件名。禁止从 Markdown 内容生成未清洗文件名;统一 UTF-8、路径安全字符白名单;增加零字节异常文件和非法命名检查。
P2临时调试与运维脚本散落根目录、archives、deploy-staging、deploy-temp、jumpserver-webcli、.workbuddy/tmp 中有大量一次性修复、上传、诊断、命令记录。将可复用脚本归入 scripts/并加入口/参数/说明;一次性脚本放到仓库外;部署命令记录改为不可含密钥的 runbook。

三、目录体量重点

位置约占体量判断
src717.1 MB重点治理:源码树/依赖/备份/制品混合
neo4j5_chunks300.0 MB重点治理:源码树/依赖/备份/制品混合
.backup163.7 MB重点治理:源码树/依赖/备份/制品混合
archives161.8 MB重点治理:源码树/依赖/备份/制品混合
frontend-h5101.9 MB重点治理:源码树/依赖/备份/制品混合
deploy-temp48.6 MB纳入分类清单
test-screenshots28.4 MB纳入分类清单
docs24.8 MB纳入分类清单
packages23.9 MB纳入分类清单
chat_export22.9 MB纳入分类清单
deploy-staging-ki22.3 MB纳入分类清单
backend14.7 MB纳入分类清单
frontend-admin11.4 MB纳入分类清单
.workbuddy5.2 MB纳入分类清单
frontend-agent3.5 MB纳入分类清单

说明:目录大小按根目录第一层前缀聚合;未将扫描结果中的运行时依赖误判为业务源码。

四、建议的目标目录边界

src/                 # 唯一运行时源码(后端、前端)
docs/                # 当前有效产品/技术/测试/运维文档
scripts/             # 可复用、参数化、可审计脚本
nginx/               # 当前有效配置模板
tests/               # 自动化测试
ops/                 # 经评审的运维入口(可选)
.artifacts/          # 不入仓,或迁移到制品库
archive-external/    # 不入工作树,进入外部归档

根目录不再放部署包、dist 版本、数据库分片、截图批次和一次性修复脚本。根目录保留 README、变更日志、贡献指南、许可证和少量构建配置。

五、实施路线图

  1. 0—1天:冻结工作树;导出 Git status 和文件 manifest;轮换已暴露凭据;确认 Gitea 远端历史是否含敏感信息。
  2. 1—3天:建立 src 唯一源声明;将根目录旧 frontend-*、dist_*、deploy-temp、archives、压缩包标注为“待迁移”;生产 compose 和 nginx 配置确定唯一事实源。
  3. 1周:文档按产品/技术/测试/运维/项目管理分层,README 改为导航;清理乱码零字节文件;为状态看板、发布记录和风险表建立更新责任。
  4. 2—4周:接入 CI:secret scan、compose config、Python lint/type、vue-tsc 增量门禁、后端关键接口测试、构建产物完整性检查。

六、审计边界与风险提示