AI 编程翻车？你的 Cursor 总在“瞎忙”？问题在你不会写“说明书”！​​

以"上下文管理"为核心，实现精准可控的 AI 驱动开发

近期参与 cursor 官方主办的线下交流会，多位专家分享了使用经验。其中大铭老师提出的观点和实操经验，对探索 AI 与人类职责边界有深刻启发，本文整理如下。

最近在技术圈里，有个现象特别有意思：博主们用 AI 工具一两句话就能做出一个应用，而我们真正开发时却处处碰壁。资深开发者大铭——大多数人在使用 AI 编程工具时，根本没搞清人与 AI 的职责边界，要以"上下文管理"为核心，实现精准可控的 AI 驱动开发。

为什么你的 Cursor 总在"瞎忙"？

大铭一针见血地指出："AI 就像牛马，想要它精准干活，就得给够说明书。"但现实中，我们往往给 AI 的指令就像在说："把桌上的东西放左边变漂亮"——连神仙都搞不定这种模糊需求。

博主们能轻松做出应用，是因为他们总是在"新马桶"（新项目）上演示。而现实中，90% 的工作都是在"屎山代码"上雕花。这时 AI 需要知道：

• 你用的技术栈版本（比如 Next.js 14 需要配合 React 18）
• 历史决策的原因
• 现有架构的限制条件
• 更加具体的方案和执行计划

更糟的是，即使模型支持 100 万 token 的上下文，有效部分通常只有 10 万左右。当调试信息挤占空间时，AI 就会"失忆"，导致反复返工——就像你聊了半小时需求，AI 突然忘了前面说啥，逼得你只能开新对话重来。

让 Cursor 变成靠谱"牛马"的四步法

大铭基于敏捷开发理念，总结出一套"人机协作生存指南"：

1. 用户故事定义目标：每次只聚焦一个小目标。比如"现阶段只实现 Google 登录，但要预留邮箱/手机号的扩展接口"。用 Markdown 记录背景、验收标准和技术约束。
2. 技术预研（RR 模式）：启动 Research & Review 的 Agent，分析现有代码库，识别技术风险（如 Ant Design 与 React 19 的兼容问题），讨论技术选型。铁律：此阶段只输出方案文档，禁止修改代码。
3. 固化执行路径：将讨论浓缩成可执行的 Plan 文件，标注关联的用户故事，明确技术决策（如"使用 SQLite 存储会话"），拆分成原子任务。"避免让 AI 带着模糊记忆干活——那是翻车的开始"
4. 隔离环境执行：新建会话窗口，载入 Plan 文档，要求 AI 复述任务后再开始编码。设定规则：遇到模糊点先自主查资料，仅当无法解决时才中断求助。

当大语言模型能吞下整个代码库时，这套方法还有用吗？

面对"如果未来模型支持千万级上下文怎么办"的疑问，大铭指出本质：方法论的根基不在于流程，而在于职责划分。

• 人的核心价值：需求洞察、架构设计、关键决策（比如"为什么兼容性比性能更重要"）
• AI 的核心价值：高效执行、信息检索、方案建议

"即使 AI 能吞下整个代码库，仍然需要人类告诉它：'为什么要重构这部分'、'为什么兼容性比性能更重要'。"

给开发者的生存建议

现场有同学提问，随着 AI 编程工具的到来，程序员的下限降低了，但是资深程序员的门槛却越来越高，3-5 年程序员会被淘汰吗，大铭给出三个破局点：

1. 主动挑战硬骨头：即使 AI 能生成代码，也要亲手实现复杂模块（如高并发消息队列），培养架构思维。
2. 用开源项目当沙盘：拆解 10 万行以上的开源项目，用 AI 辅助学习设计决策。比如："为什么 Redis 在这里比 MySQL 更合适？如何验证？"
3. 深度参与真实需求：靠近用户场景，理解技术决策的业务代价。大铭举了个真实案例：新浪微博每小时 20 万条新内容，如何让 3000 万粉丝在 10 秒内看到明星的最新动态？"这跟需求无关，跟美无关，是你技术上必须要解决的问题。"

个人感悟

听完大铭的分享，我最大的感触是：工具永远在变，但协作的本质从未改变。AI 时代，程序员的价值不在于写代码的速度，而在于：

1. 精准定义问题的能力：能否把一个模糊的业务需求，拆解成 AI 可执行的明确指令？
2. 架构决策的权衡能力：当 AI 给出多个方案时，能否基于业务场景做出最优选择？
3. 技术深度的积累：虽然 AI 能帮你写代码，但遇到复杂问题时，还得靠你的经验判断。

就像大铭说的："程序员的分层不是看会不会写代码，而是看能否用技术解决人类的真实困境。"在这个 AI 越来越强的时代，或许我们最该培养的，是那种"即使 AI 能搞定，但我还是要亲手试试"的好奇心和钻研精神。