一、目标 / 场景
我接手了公司内部「视***台」的前端迭代工作。这是一个跑了几年的老项目：页面多、公共组件多、文档基本没跟上，前任留下的代码注释也少。日常需求是持续加新页面、调数据看板、修线上问题。
最头疼的不是写新代码，而是理解成本——改一个看板之前，得先搞清楚这个模块的数据流从哪来、状态放在哪、公共组件能不能复用。以前这些全靠全局搜索 + 顺着 import 一层层点，半天就过去了，改完还总担心牵一发动全身。
这次的目标很明确：用 TraeCode 把「读懂老项目」和「小步迭代」这两件事的效率打下来。
二、身份 / 为什么重要
我是团队的前端开发，负责上述平台的迭代维护。对我们这种"存量项目重于新建项目"的团队来说，AI 编程工具的价值不在从零生成一个炫酷 demo——那一年碰不到几次——而在于能不能在别人写的几千个文件里快速找到该改的地方、生成符合团队风格的代码、改完自己验证一遍。
这部分提效是实打实的：需求排期不变的前提下，省下来的理解时间就是能多做一个需求的时间。
三、使用过程 / 技巧
第 1 步：先让 Agent 把项目"讲"给我听。
导入项目后第一件事不是改代码，而是让 Agent 结合 #引用 梳理整个工程：路由结构、状态管理方案、公共组件清单、请求封装在哪。它输出的项目导读我稍作修改后直接放进了仓库，顺便解决了"下一个人接手怎么办"的问题。
第 2 步：把团队规范写进 Rules。
命名风格、组件拆分粒度、样式写法、提交信息格式，这些以前靠口口相传的东西，我花十几分钟写进了项目规则。效果立竿见影：后面生成的代码风格基本不用返工，也不会出现"一个页面三种写 CSS 的方式"。
第 3 步：日常迭代，分大小两条路。
- 单文件小改动：直接用 CUE 超级补全，顺着写，它对上下文的预测很准，尤其是"照着隔壁页面的样子再写一个"这种需求；
- 跨文件改动：丢给 Agent，但我会先要方案再放行——让它列出打算改哪些文件、有没有风险点，确认无误再执行，最后逐条看 diff。
第 4 步：改完让它自己验证。
构建命令和 lint 直接交给 Agent 在终端里跑，报错原文丢回去，大部分小问题它能自己修掉，不需要我来回复制粘贴。
第 5 步：接上 MCP 查接口文档。
把接口文档查询配成 MCP 工具后，Agent 写请求层之前会自己去查字段定义，我不用再当"人肉接口文档翻译器"。
几条实用技巧
- 规则先行：Rules 花十分钟，省后面每天十分钟；
- 任务拆小：一次让 Agent 干一件事，成功率远高于"一次全做完"；
- 先方案后放行：跨文件改动前一定要先看它的执行计划；
- 锁定上下文：用 #引用 明确告诉它相关文件，比"你自己找"稳得多；
- 保留人工审查：涉及权限、数据展示的逻辑，提交前自己一定过一遍。
四、结果 / 建议
用了两周下来的直观感受：老项目的上手周期比预期缩短了大半，原本"理解模块 + 动手改"两天的活，现在基本一天内能交付；常规迭代的改动质量也更稳定，因为验证环节是自动跑的。
给同样要接手老项目的同学三点建议：
- 先梳理，再提效——别急着让 AI 写代码，先花半天让它帮你把项目结构摸清楚，这是回报率最高的一步；
- 把 TraeCode 当"有人把关的结对"，而不是无人值守的自动机，方案确认和 diff 审查不能省；
- 规则和 MCP 值得投入——前者决定代码风格上限，后者决定它获取信息的真实程度。
以上就是我这两周的实战记录，欢迎评论区交流老项目 + AI 编程的玩法。