--- title: "我与AI结对编程：如何从\"跑起来\"到\"能上线\"" date: 2025-08-26 description: "深度解析 AI 结对编程实现从“跑起来”到“能上线”的质变路径。以货币管理模块改造为背景，分享了利用截图与 API 契约进行“精准投喂”、通过 .cursorrules 固化规范、采用 Todo 驱动“小步快跑”及引入生产就绪度评审等策略。探讨如何将 AI 效能与人类质量防线结合，产出高内聚、低耦合且易维护的高质量代码，助力提升复杂业务下的工程交付水平。" canonical_url: "https://yijinlee.com/articles/article-14" tags: - "AI 结对编程" - Cursor - .cursorrules - Vue3 - "Clean Code" topic: "AI 外骨骼" --- 嘿，大家好 AI，这个词在过去一年里，无疑是科技圈最闪亮的那颗星。我们不再讨论它"会不会来"，而是"它已经来了，我们该如何驾驭它？"作为一个在一线摸爬滚打多年的开发者，我亲身体验了 AI 从一个略显笨拙的"工具"蜕变为一个不可或缺的"队友"的过程。但这里面有个巨大的鸿沟：AI 能让代码"跑起来"不难，但要让它生成"能上线、高质量、易维护"的代码，并且和现有系统无缝衔接，这可就得讲究点策略了。 最近，我们团队在处理"货币排序管理"以及"添加展示币种"这两个核心模块时，就与 AI 进行了一场深度结对编程。我发现，这远不是简单的"给个提示词，等它出活儿"那么粗暴。这更像是一场精心编排的探戈，每一步都需要舞伴间的心领神会，以及对流程和规则的严格遵守。今天，我想和大家分享的，就是我们如何通过一系列实践，将 AI 的协作效率与代码质量推向了一个新高度，最终交付了让人放心、能够迅速投入生产的代码。 --- ### 第一章：精准投喂，构建 AI 的"数字心智"——让它理解你想要的，而不是它猜测的 你有没有过这样的经历？你描述了一个需求，AI 洋洋洒洒地写了一堆代码，结果发现和你的期望南辕北辙。这就像你对一个新来的实习生说："帮我把这个功能做了"，然后他就按自己的理解一通乱来。问题出在哪里？出在你没有提供足够清晰、无歧义的"用户手册"。 在和 AI 协作的过程中，我总结出的第一点，也是最关键的一点：把需求描述成"AI 能理解"的语言，而不是"人能理解"的模糊概念。 "秀"出来，别光"说"：截图、接口文档、期望布局，一个都不能少。 当我需要 AI 在"货币排序管理"页新增关键词搜索、调整模块位置、增加"国家名称"列时，我没有用一大段文字去描述。我的做法是： - UI 截图 + 期望布局图：直接在截图上圈出搜索框位置、新列位置，并用箭头指示搜索模块要"挪到彭博汇率下方"。 - 接口说明：明确给出接口 `fetchCountryList` 的 URL、入参（`pageSize`、`countryName`、`channel`）和出参结构。 - 涉及文件列表：直接告诉它 `add.vue`、`index.vue` 是主要战场。 这就像给 AI 提供了一份带有详细标注的设计稿和一份完整的 API 契约，它的"数字心智"就能同时在视觉和数据两个维度上构建起对需求的完整理解。你不再需要事后纠结"是不是这里没说清楚"，因为信息是如此具象化，它能直接对齐实现，大大减少了返工率。 提前立"规矩"：.cursorrules 是 AI 的"行为准则"。 让 AI 写出符合团队规范的代码，而不是每次都手动修改格式、补充注释，这简直是解放生产力的关键。我们团队有明确的编码规范：Vue3、SOLID 原则、Clean Code、中文注释，并且要求"充分走读代码、小幅度改动、不删功能"。 我把这些要求固化在 `.cursorrules` 文件里。这意味着，AI 从它"睁开眼睛"看我的第一个提示词开始，就已经被"植入"了这些行为准则。它会主动先阅读 ListTable、request、API 等文件，理解现有逻辑，然后才动手修改。这种"先读后改"的习惯，最大限度地避免了 AI 大刀阔斧、破坏性地改动现有代码，也保证了它写出的每一行代码都带有我们团队的风格烙印，减少了后期 Code Review 的负担。 --- ### 第二章：化繁为简，与 AI 携手穿越代码丛林——用任务列表掌控节奏，用事实说话 AI 的强大在于它的生成能力，但生成不等于思考。我们人类的角色，就是为它提供清晰的思考路径和校验机制。 "小步快跑"的艺术：用 Todo 列表拆解任务，逐个击破。 面对一个复杂需求，即使 AI 能力再强，我也不会让它"一口吃个胖子"。我习惯性地把任务拆解成可验证的、独立的步骤。比如，在"添加展示币种"弹窗的改造中，我把它拆成了： 1. 弹窗列表改为表格（含序号、国家、货币码、货币名称）。 2. 增加"货币列表"标题与刷新功能。 3. 单选/多选确认时，在接口中增加 `countryName` 参数。 4. （后续发现的）国家名称为空时，用 `fetchCountryMapping` 映射表补全。 这种方式的好处在于，每一步都可以单独验证。就像是给 AI 布置了一系列"支线任务"，它完成一个，我就能立即验证并纠正，确保方向正确。这种渐进式的开发流程，极大地降低了单次修改的风险，也让我能清晰地掌握项目的进展。 事实胜于雄辩：出现问题时，用证据说话。 AI 不是神，它也会"犯错"，比如出现"表格暂无数据"或"国家名称列为空"的情况。这时候，最忌讳的是盲目地让 AI 重写接口或者瞎改前端逻辑。 我的做法是：直接甩出 Network 响应截图。 - 当发现表格没数据，我提供截图，AI 一看，哦，原来是接口响应结构和前端预期不符，可能接口返回的是 `body.data.rows`，而前端在读 `body.data`。它就会主动做响应解析兼容。 - 当发现国家名称列为空，截图一亮，AI 就会明白，接口 `fetchCountryList` 本身就不返回 `countryName` 字段！这时候，它的思考路径就明确了：需要引入一个独立的 `loadCountryNameMap` 函数，用 `fetchCountryMapping` 接口获取映射表，再用 `enrichListWithCountryName` 函数在前端进行数据补全。 这种"基于事实的纠偏"方式，让 AI 能够像一个经验丰富的侦探一样，通过"物证"精准定位问题，然后给出最合理、最少侵入性的解决方案，而不是在那里"猜谜语"。 --- ### 第三章：精雕细琢，将代码打磨成生产级艺术品——质量保障的最后一道防线 代码能跑通，离生产还有十万八千里。高质量的代码，意味着健壮性、可维护性、边界处理，以及对未来变化的适应性。这是 AI 最容易"偷懒"的地方，也是人类开发者必须站岗的最后一道防线。 "外科手术式"改动：单一职责与最小改动原则。 在"添加展示币种"的场景中，我明确要求 AI： - 搜索与列表请求在页面内完成，国家名称补全逻辑独立成 `loadCountryNameMap` 和 `enrichListWithCountryName`，不污染通用组件。 - API 层仅仅新增 `fetchCurrencyMapping`，并保留原有 `fetchCurrencyByChannel`，避免删除功能。 这就像是在一台精密仪器上做修改，只动手术刀应该碰到的地方，避免"牵一发而动全身"。AI 在这样的指导下，产出的代码自然更加高内聚、低耦合，易于理解和维护。 生产就绪度评审：超越"功能实现"的思考。 当我感觉 AI 已经完成了所有功能点时，我不会直接让它提交代码。我会额外给它一个提示："请多维度评审此代码能否上生产环境？" AI 在这样的提示下，会像一个经验老道的 Code Reviewer 一样，主动发现并修复： - 重复提交问题：在确认按钮上增加 loading 状态防抖。 - 接口失败提示：对接口请求做 try...catch，并在失败时给出用户友好提示。 - 状态清理：在弹窗关闭时，主动清空表格选中状态，避免数据残留。 - 潜在风险：提醒直接修改 ref 入参可能带来的副作用。 这种"让 AI 自己找茬"的机制，是确保代码达到生产标准的临门一脚。它迫使 AI 不仅思考"如何实现"，更要思考"如何健壮、如何安全、如何友好"。 "为什么"比"是什么"更重要：注释是代码的灵魂。 高质量的代码，离不开清晰的注释。但我要求的不是那种"这是一个变量"的废话文学，而是解释"为什么这么做"。 - "为什么 `fetchCountryList` 不返回 `countryName`，需要用 `fetchCountryMapping` 做映射补全？" - "为什么响应需要兼容 `body.data` 和顶层 `rows` 两种结构？" AI 会把这些"为什么"清晰地写进注释里。这不仅方便了未来的维护者（甚至包括未来的我自己），也让代码本身成为了一份自解释的文档。 --- ### 总结：AI 不是替代，而是强大的延伸 经过这些项目的磨砺，我深刻认识到：AI 不是来取代我们的，它是来延伸我们的。 它是一个极其高效、不知疲倦的助手，但它缺乏人类的直觉、对业务场景的深刻理解、以及对代码质量的终极判断。 我们与 AI 的协作，更像是一场高度协同的舞蹈： - 我们是舞者，AI 是舞伴。 我们负责编排舞步，规划方向，提供节奏。 - 我们提供清晰的"动作指令"（需求、规则）。 - 我们通过"眼神交流"（截图、网络响应）进行实时纠偏。 - 我们共同"排练"（小步迭代），确保每个动作都精准无误。 - 最后，我们进行"正式演出前的总彩排"（生产就绪度评审），确保万无一失。 通过这种"需求一次给全、问题带上下文、规则前置固化、验收有依据"的协作模式，我们不仅极大地提升了开发效率，更重要的是，在保持代码可读性、可维护性与高质量的前提下，有效控制了改动范围，降低了回归风险。 未来，AI 将成为我们不可或缺的编程伙伴。掌握如何与它高效、高质量地协作，将是我们每个开发者必备的核心竞争力。让我们拥抱这个时代，与 AI 一同创造更美好的代码世界吧！ ## 参考文章：相关链接 - [GitHub · Copilot research / productivity](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)（权威引文）— 结对编程提效的可引用实证，对照「跑起来 → 能上线」。 - [Cursor · Features overview](https://docs.cursor.com/chat/overview)（官方文档）— Chat / Composer 能力边界，界定人机分工。 - [系统化提示工程：如何驯服 Cursor AI 提升开发效率？](https://yijinlee.com/articles/article-1)（站内深度）— 结对之前先把提示工程底座钉牢。 - [全栈开发实战复盘：30分钟搞定评论系统，效率提升44倍](https://yijinlee.com/articles/article-28)（站内深度）— 结对编程在全栈交付上的量化复盘。