一、我是谁 & 遇到什么问题
我是一名金融行业项目技术负责人，日常靠 AI 快速分析迭代项目。近期有项目准备推广，需要进一步确认功能是否已经达标、代码是否已经达标：
需要对 4 万行、29 个微服务的代码库做全量审计，纯人工 review 周期太长，传统 AI 关键词搜索又存在全局视野差、语义问题搜不到、批量审计易遗漏三大痛点，漏检率很高。
二、我用了 TraeWork 解决了这件事
模式勾选：
Code ☐ Work ☐ Design
核心用到了 Trae 的 子代理并行任务能力、MCP 工具扩展能力、代码库语义检索 和 长上下文汇总能力。原生检索缺少代码图谱能力，因此我在 Trae 中扩展安装了开源 MCP 工具 codebase-memory-mcp，补齐 AST 级依赖分析与调用链追踪能力，整套审计流程完全在 Trae 内闭环完成。
具体执行分三步：
-
分批规划：先让 AI 按业务重要性把 29 个服务划分为 P0-P3 四个批次，从核心业务模块到系统底层服务依次审计，每个批次独立闭环、独立修复，避免信息过载。
-
并行审计：每个批次启动 6 个只读类型的 search 子代理，每个子代理负责 4-5 个服务，从完整性、显性 BUG、业务逻辑、可用性四个维度逐方法排查。子代理拥有独立上下文，互不干扰，主代理仅负责结果汇总。
-
交叉核验：子代理输出初步结果后，主代理通过 MCP 代码图谱验证调用链真实性，同时对比前后端接口文件校验签名与类型漂移，两轮核验大幅降低误报率。
PS：为什么不用trae的审计mcp，请看：
三、我做出了什么
- 先让trae work安装，一句话：
帮我安装 MCP 工具，地址见：https://github.com/DeusData/codebase-memory-mcp
2.最终输出了完整的分级问题审计报告与代码清理方案：
提示词：
我想要对当前项目进行功能审计，有没有合适的方法，是直接开始审核，还是先找一些skils?
本地已有代码图谱MCP可用，请设计方案，目标是提高业务功能的完整性，每个功能是否存在BUG
或潜在BUG，逻辑是否严密，功能是否完整可用等。请解需求，设计方案。
-
共查出 153 项问题，其中 60% 以上是传统 grep + 人工审计会遗漏的深层问题，按严重程度分为 P0 严重问题 17 项、P1 功能问题 37 项、P2 逻辑问题 55 项、P3 可用性问题 44 项
-
代码质量层面清理 19 个死文件、14 个冗余函数 / 字段、2 个未使用依赖，抽取 1 个公共工具文件，修复 1 项架构问题
全程使用 Trae 免费版完成，总 Token 消耗不到 1000 万，MCP 工具开源免费且索引在本地运行，无额外云端费用。原本需要 3-5 天的人工审计工作量，大半天即可完成核心排查，同时规避了人工漏检带来的线上故障风险。
四、效果展示
内部软件，不便展示软件效果，看看过程路径吧。
-
分批审计规划图：29 个服务按业务优先级划分为 4 个批次，标注各批次服务范围与方法数量
-
问题分级统计结果：P0-P3 四级问题数量可视化统计，直观呈现风险分布
-
6 路并行子代理执行架构：展示主子代理分工、只读审计模式的设计逻辑
五、经验 & 技巧总结
-
审计与修复权限分离：审计阶段子代理统一使用 search 只读类型，仅做问题排查不修改代码；修复阶段再切换为可写类型。严格分离两个阶段，避免 AI 边查边改引入新的隐性问题。
-
不要等工具配好再开工：MCP 安装、代码库索引构建都需要时间，期间可以先用 Trae 内置检索能力出第一版审计报告，先解决 80% 的表层问题，工具就绪后再用图谱做深度复核，整体效率最高。
-
误报也要重点复核：图谱标记的可疑点，哪怕最终判定为误报，其标记的位置往往也是风险高发区。顺着误报点仔细排查代码，很容易发现被忽略的真实逻辑问题。
六、提示词参考
其实只要通俗的表达需求，效果就很不错：
-
审计规划指令：
帮我对当前代码库做全量审计规划，按业务重要性分成 P0-P3 四个批次，列出每个批次的服务范围、方法数量和优先级说明 -
子代理审计指令：
作为只读审计子代理，针对指定服务模块，从参数完整性、显性BUG、权限逻辑、可用性四个维度逐方法审计，输出问题清单并标注严重等级 -
图谱语义查询指令：
通过代码图谱查询：所有数据写操作中缺少权限校验的函数，列出函数名、所在文件路径和上游调用方列表