AI赋能：我与AI结对编程，如何从"跑起来"到"能上线"

嘿，大家好

AI，这个词在过去一年里，无疑是科技圈最闪亮的那颗星。我们不再讨论它"会不会来"，而是"它已经来了，我们该如何驾驭它？"作为一个在一线摸爬滚打多年的开发者，我亲身体验了 AI 从一个略显笨拙的"工具"蜕变为一个不可或缺的"队友"的过程。但这里面有个巨大的鸿沟：AI 能让代码"跑起来"不难，但要让它生成"能上线、高质量、易维护"的代码，并且和现有系统无缝衔接，这可就得讲究点策略了。

最近，我们团队在处理"货币排序管理"以及"添加展示币种"这两个核心模块时，就与 AI 进行了一场深度结对编程。我发现，这远不是简单的"给个提示词，等它出活儿"那么粗暴。这更像是一场精心编排的探戈，每一步都需要舞伴间的心领神会，以及对流程和规则的严格遵守。今天，我想和大家分享的，就是我们如何通过一系列实践，将 AI 的协作效率与代码质量推向了一个新高度，最终交付了让人放心、能够迅速投入生产的代码。

---

你有没有过这样的经历？你描述了一个需求，AI 洋洋洒洒地写了一堆代码，结果发现和你的期望南辕北辙。这就像你对一个新来的实习生说："帮我把这个功能做了"，然后他就按自己的理解一通乱来。问题出在哪里？出在你没有提供足够清晰、无歧义的"用户手册"。

在和 AI 协作的过程中，我总结出的第一点，也是最关键的一点：把需求描述成"AI 能理解"的语言，而不是"人能理解"的模糊概念。

"秀"出来，别光"说"：截图、接口文档、期望布局，一个都不能少。

当我需要 AI 在"货币排序管理"页新增关键词搜索、调整模块位置、增加"国家名称"列时，我没有用一大段文字去描述。我的做法是：

• UI 截图 + 期望布局图：直接在截图上圈出搜索框位置、新列位置，并用箭头指示搜索模块要"挪到彭博汇率下方"。
• 接口说明：明确给出接口 queryPageList 的 URL、入参（pageSize: 800 这样的固定值、countryName、channel）和出参结构。
• 涉及文件列表：直接告诉它 add.vue、index.vue 是主要战场。

这就像给 AI 提供了一份带有详细标注的设计稿和一份完整的 API 契约，它的"数字心智"就能同时在视觉和数据两个维度上构建起对需求的完整理解。你不再需要事后纠结"是不是这里没说清楚"，因为信息是如此具象化，它能直接对齐实现，大大减少了返工率。

提前立"规矩"：.cursorrules 是 AI 的"行为准则"。

让 AI 写出符合团队规范的代码，而不是每次都手动修改格式、补充注释，这简直是解放生产力的关键。我们团队有明确的编码规范：Vue3、SOLID 原则、Clean Code、中文注释，并且要求"充分走读代码、小幅度改动、不删功能"。

我把这些要求固化在 .cursorrules 文件里。这意味着，AI 从它"睁开眼睛"看我的第一个提示词开始，就已经被"植入"了这些行为准则。它会主动先阅读 ListTable、request、API 等文件，理解现有逻辑，然后才动手修改。这种"先读后改"的习惯，最大限度地避免了 AI 大刀阔斧、破坏性地改动现有代码，也保证了它写出的每一行代码都带有我们团队的风格烙印，减少了后期 Code Review 的负担。

---

AI 的强大在于它的生成能力，但生成不等于思考。我们人类的角色，就是为它提供清晰的思考路径和校验机制。

"小步快跑"的艺术：用 Todo 列表拆解任务，逐个击破。

面对一个复杂需求，即使 AI 能力再强，我也不会让它"一口吃个胖子"。我习惯性地把任务拆解成可验证的、独立的步骤。比如，在"添加展示币种"弹窗的改造中，我把它拆成了：

1. 弹窗列表改为表格（含序号、国家、货币码、货币名称）。
2. 增加"货币列表"标题与刷新功能。
3. 单选/多选确认时，在接口中增加 countryName 参数。
4. （后续发现的）国家名称为空时，用 queryMidCountry 映射表补全。

这种方式的好处在于，每一步都可以单独验证。就像是给 AI 布置了一系列"支线任务"，它完成一个，我就能立即验证并纠正，确保方向正确。这种渐进式的开发流程，极大地降低了单次修改的风险，也让我能清晰地掌握项目的进展。

事实胜于雄辩：出现问题时，用证据说话。

AI 不是神，它也会"犯错"，比如出现"表格暂无数据"或"国家名称列为空"的情况。这时候，最忌讳的是盲目地让 AI 重写接口或者瞎改前端逻辑。

我的做法是：直接甩出 Network 响应截图。

• 当发现表格没数据，我提供截图，AI 一看，哦，原来是接口响应结构和前端预期不符，可能接口返回的是 body.data.rows，而前端在读 body.data。它就会主动做响应解析兼容。
• 当发现国家名称列为空，截图一亮，AI 就会明白，接口 queryPageList 本身就不返回 countryName 字段！这时候，它的思考路径就明确了：需要引入一个独立的 loadCountryNameMap 函数，用 queryMidCountry 接口获取映射表，再用 enrichListWithCountryName 函数在前端进行数据补全。

这种"基于事实的纠偏"方式，让 AI 能够像一个经验丰富的侦探一样，通过"物证"精准定位问题，然后给出最合理、最少侵入性的解决方案，而不是在那里"猜谜语"。

---

代码能跑通，离生产还有十万八千里。高质量的代码，意味着健壮性、可维护性、边界处理，以及对未来变化的适应性。这是 AI 最容易"偷懒"的地方，也是人类开发者必须站岗的最后一道防线。

"外科手术式"改动：单一职责与最小改动原则。

在"添加展示币种"的场景中，我明确要求 AI：

• 搜索与列表请求在页面内完成，国家名称补全逻辑独立成 loadCountryNameMap 和 enrichListWithCountryName，不污染通用组件。
• API 层仅仅新增 queryCurrencyPageList，并保留原有 queryCurrencyByChannel，避免删除功能。

这就像是在一台精密仪器上做修改，只动手术刀应该碰到的地方，避免"牵一发而动全身"。AI 在这样的指导下，产出的代码自然更加高内聚、低耦合，易于理解和维护。

生产就绪度评审：超越"功能实现"的思考。

当我感觉 AI 已经完成了所有功能点时，我不会直接让它提交代码。我会额外给它一个提示："请多维度评审此代码能否上生产环境？"

AI 在这样的提示下，会像一个经验老道的 Code Reviewer 一样，主动发现并修复：

• 重复提交问题：在确认按钮上增加 loading 状态防抖。
• 接口失败提示：对接口请求做 try...catch，并在失败时给出用户友好提示。
• 状态清理：在弹窗关闭时，主动清空表格选中状态，避免数据残留。
• 潜在风险：提醒直接修改 ref 入参可能带来的副作用。

这种"让 AI 自己找茬"的机制，是确保代码达到生产标准的临门一脚。它迫使 AI 不仅思考"如何实现"，更要思考"如何健壮、如何安全、如何友好"。

"为什么"比"是什么"更重要：注释是代码的灵魂。

高质量的代码，离不开清晰的注释。但我要求的不是那种"这是一个变量"的废话文学，而是解释"为什么这么做"。

• "为什么 queryPageList 不返回 countryName，需要用 queryMidCountry 做映射补全？"
• "为什么响应需要兼容 body.data 和顶层 rows 两种结构？"

AI 会把这些"为什么"清晰地写进注释里。这不仅方便了未来的维护者（甚至包括未来的我自己），也让代码本身成为了一份自解释的文档。

---

经过这些项目的磨砺，我深刻认识到：AI 不是来取代我们的，它是来延伸我们的。 它是一个极其高效、不知疲倦的助手，但它缺乏人类的直觉、对业务场景的深刻理解、以及对代码质量的终极判断。

我们与 AI 的协作，更像是一场高度协同的舞蹈：

• 我们是舞者，AI 是舞伴。 我们负责编排舞步，规划方向，提供节奏。
• 我们提供清晰的"动作指令"（需求、规则）。
• 我们通过"眼神交流"（截图、网络响应）进行实时纠偏。
• 我们共同"排练"（小步迭代），确保每个动作都精准无误。
• 最后，我们进行"正式演出前的总彩排"（生产就绪度评审），确保万无一失。

通过这种"需求一次给全、问题带上下文、规则前置固化、验收有依据"的协作模式，我们不仅极大地提升了开发效率，更重要的是，在保持代码可读性、可维护性与高质量的前提下，有效控制了改动范围，降低了回归风险。

未来，AI 将成为我们不可或缺的编程伙伴。掌握如何与它高效、高质量地协作，将是我们每个开发者必备的核心竞争力。让我们拥抱这个时代，与 AI 一同创造更美好的代码世界吧！