前言：接手老项目的“双重困境”
最近在项目开发中深度使用了 Cursor，遇到一个非常典型的痛点：如何在存量大型系统中真正提效？
这有别于从 0 到 1 的绿地开发，接手一个存量大型工程，我们往往面临“既要快速上手，又要保证质量”的双重挑战。在实际操作中，这很容易陷入一个两难局面：
- 全量投喂的尴尬： 如果让 AI 读取全部代码，Token 消耗巨大，经常撑爆上下文窗口。更糟糕的是，模型容易在海量细节中“迷失”，生成的代码往往逻辑自洽但脱离业务背景。
- 局部投喂的风险： 如果只给部分代码，AI 理解不够全面，容易遗漏跨系统的隐性约束（Implicit Constraints）。写出来的代码看似完美，上线后却发现破坏了现有的架构平衡。
- 人工梳理的疲惫： 如果靠人工逐文件梳理，这本身就是我们想通过 AI 解决的繁重工作。
这种**“既怕 AI 理解不足埋雷，又不想自己手工填坑”**的焦虑，是大多数开发者面对老项目时的真实写照。
经过一段时间的摸索，我发现破局的关键不在于让 Cursor 读多少代码，而在于引入“图（Diagram）”作为中间语言，将复杂系统的结构显式化。这一转变，彻底重构了我对“AI 辅助开发”的认知。
一、 初阶体验：从“读代码”到“降负载”
在探索“图驱动”之前，Cursor 在基础层面的表现已经证明了其价值。它的核心不在于“替我思考”，而在于极大地降低了认知负荷。
1.1 建立心智模型
在熟悉陌生模块时，Cursor 的体验明显优于传统 IDE。
- 自然语言交互： 可以直接询问“这个 Service 的核心职责是什么”、“异常处理链路是怎样的”。
- 即时总结： 它可以把散落在 10 个文件里的逻辑，总结成一段伪代码或流程描述。这省去了我们在 Tabs 之间反复跳转、脑补上下文的过程。
1.2 样板代码与局部重构
对于结构明确、逻辑封闭的代码，Cursor 性价比极高：
- 生成骨架： Controller / DTO / Converter 等样板代码，AI 可以秒出。
- 风格模仿： 只要给足上下文（Few-Shot Learning），它能很好地模仿现有的代码风格，减少了代码审查时的格式噪音。
- 批量修改： 比如“给所有 RPC 调用增加统一的错误码处理”，利用 Cursor 的多文件编辑（Composer）功能，可以实现“机器粗改 + 人工精修”的高效模式。
二、 进阶战法：图驱动开发 (Graph-Driven Development)
在大型系统中，我发现了一个极高杠杆的用法：用 Mermaid 图作为“人与 AI 的中间语言” 。
本质问题在于： 代码是“线性的、充满细节的”，而系统架构是“拓扑的、高度结构化的”。硬让 LLM 从线性细节里反推拓扑结构，效率极低且容易出错。图，就是系统的 X 光片。
场景 1：逆向工程——快速理解现状
当需要快速理解一个复杂的陌生模块时，尝试以下流程：
Step 1： 让 AI 扫描关键入口文件，生成架构图。
Prompt 模板：
“请基于当前选中的代码结构，生成一份 Mermaid 系统架构图。
要求：
- 展示各个 Service 之间的依赖关系；
- 标出对外 API 入口（Controller）；
- 标出外部中间件依赖（Redis, DB, MQ, FeignClient）；
- 用不同颜色区分核心业务域与支撑域。”
收益：
一张 Token 消耗仅 500 左右的图，能呈现出翻阅 5 个文件才能拼凑出的全貌。这张图不仅是你的理解工具，更可以沉淀在 Git 中，成为项目的“活文档”。
场景 2：正向设计——作为“规范的黏合剂”
在设计新功能（例如：集成一个新的 AI 搜索能力）时，图的作用更加关键。它能避免“开发写到一半发现设计有漏洞”的经典悲剧。
Step 1：绘制“集成全景图”
基于现有架构，先生成一张包含新模块的层级图。显式地回答：新接口在哪一层？调用谁？被谁调用？
Step 2：生成详细时序图
将需求转化为具体的交互流程。
Prompt 模板：
“我们要加入一个新的 [搜索增强模块]（如架构图所示）。
请画出完整的 Mermaid 时序图，展示：
- 从用户请求到最终返回的每一步；
- 各个模块间传递的数据结构（重点关注 Request/Response）；
- 缓存命中与失效的路径；
- 异常情况下的降级策略。”
Step 3：Review 与修正
Review 时序图比 Review 代码容易得多。你可能会发现：“这里漏了一个权限校验”、“缓存失效后没有回源逻辑”。在图上改，成本几乎为零。
Step 4：图生代码
确认图无误后，让 AI 严格照图施工。
Prompt 模板：
“请严格根据上面的时序图，生成：
SearchController的实现框架；- 调用下游服务的客户端代码；
- 对应的单元测试骨架。”
收益：
设计与代码完全对齐。因为它们同源（Source of Truth 都是那张图）。
场景 3：复杂业务编排实战（脱敏案例）
假设我们需要设计一个**“智能导购助手”**，涉及意图识别、大模型推理、商品检索、流式输出等环节。
1. 分阶段拆解：
不要试图让 AI 一次性生成所有逻辑。通过图，我们将需求拆解为“阶段 1：意图路由”和“阶段 2：深度推理”。
2. 细化编排流程（Prompt 示例）：
“请绘制
深度推理智能体的内部编排时序图：
- 调用 LLM 生成推荐理由；
- 并行调用
商品检索服务和营销规则引擎；- 聚合数据后，进行流式（Streaming）输出；
- 重点展示：前端如何分段接收‘思考过程’和‘最终结果’。”
3. 显性化流式交互：
通过时序图明确定义流式输出的 chunk 结构，避免前后端联调时的协议扯皮。
通过这种方式，我们将模糊的文字需求，转化为了清晰的参与者（Participants）和消息（Messages） ，将编码风险在设计阶段降到最低。
三、 祛魅与边界：AI 能做什么，不能做什么
经过实战检验，我们需要对工具的边界有清醒的认识。
3.1 真正有感的提升（Do's）
- 理解加速： 从“盲人摸象”变为“上帝视角”，上手陌生代码的速度显著提升。
- 样板消除： CRUD、DTO 转换、API 封装等重复性劳动，基本实现自动化。
- 设计落地： 解决了“文档是文档，代码是代码”的两张皮问题。
3.2 此时此刻无法替代的领域（Don'ts）
- 架构决策： 系统边界划分、技术选型、性能预算（Performance Budget），这些需要权衡组织架构和运维成本的决策，AI 只能提供参考，不能做决定。
- 隐性业务规则： 那些写在老代码角落里、甚至只存在于老员工口口相传中的“潜规则”，AI 很难一次推断正确。
- 高危路径： 涉及资金、核心风控、高并发锁的代码，必须由人进行逐行 Review。可以相信 AI 的手速，但不能迷信它的判断力。
四、 避坑指南
- 拒绝“一句话需求”： 上下文给太少，答案必飘。尽量采用“选中关键代码 + 补充文字约束”的方式。
- 慎用“重写整个类”： 直接让 AI 重构复杂逻辑容易丢细节。稳妥做法是：先让它解释逻辑，确认理解无误后，再分块重构。
- 风格对齐： 生成代码前，先喂给它一两个项目内的标准示例（One-Shot / Few-Shot），告诉它“就按这个风格写”。
- 图繁则乱： Mermaid 图不是为了炫技。一张图最好控制在 15-20 个节点以内，聚焦核心链路。太复杂的图反而会增加 LLM 的理解噪声。
结语
Cursor 这类工具的出现，并没有让程序员失业，而是改变了我们的角色。
在“图驱动开发”的模式下，我们更像是一个**“架构设计师”兼“翻译官”**：
- 我们将模糊的业务需求，翻译成结构化的图（Diagram） ；
- AI 将图翻译成具体的代码（Code） ；
- 我们再负责 Review 代码与图的一致性，以及最终的业务正确性。
它不是颠覆一切的银弹，但如果用法得当，它确实是应对存量大型系统的一把利器。建议大家在团队中尝试建立一套**“Prompt 模板 + Diagram as Code”**的工作流，这可能是比单纯“换个编辑器”更深远的提效路径。
