AI 辅助编码范式、工具与策略

因为前端开发有大量模版化代码需要编写的缘故，比如模版化的列表 CRUD 界面和接口服务，这占了前端 70% 左右的工作量，所以对 AI Coding 有很强的需求。

从 2021 年 10 月份左右 Github Copilot 出来就一直有关注这个领域，当时也有一些实践，但是并没有现在这么方便（强）。

开始大量使用 AI 编码，是在 23 年左右 Cursor 开放了新用户免费试用 3 个月 Pro，然后换账号持续薅羊毛用了一年多。在编写 Next.js, React.js, Vue.js, Think.js, Nest.js 和 MongoDB Query 等方面有大量实践，积累了一些经验。

后续，随着 Claude-Code 这类具有思考能力的专业编程大模型的出现，发现 AI 编程真的起飞了。这完全改变了我们目前的工作流和生产力。

Why?

为什么要学习 AI Coding?

  • 提升效率：模板代码、CRUD 接口和 UI 界面，程序员的生产力

  • 架构 / UI 设计：提供思路和可执行方案，实现最佳实践

  • 代码审核：代码质量、逻辑漏洞和规范符合性

 

AI 怎么说？开发者是 Driver，而不是 Passenger。摘自 Google Gemini Pro 2.5 Deep Research

  • AI 是一个强大的效率倍增器。 对于合适的任务，它是一个出色的“代码搬运工和迭代器”，能够极大地提升效率 62。

  • 人类开发者不可或缺。 人的角色非但没有被削弱，反而变得更具战略性和关键性。对架构、业务理解和批判性判断等高层次技能的需求正在增加，而非减少 68。

  • 未来是人机协作的。 最具效率的软件开发团队将是那些精通人机协作艺术的团队。他们将利用 AI 的速度解决已知问题，同时运用人类的智慧和创造力来应对新颖的挑战。

What？

在日新月异的今天，AI Coding 成了程序员的提效神器。而 AI Coding 离不开用 AI IDE 去 Coding。

  • 什么是 AI IDE？

AI IDE = Editor + LLM + Agent + MCP

  • 什么是 MCP？

http://modelcontextprotocol.io/docs/getting-started/intro

image

 

 

  • AI Coding 又带来了什么新的编程范式？它们又有什么区别？

AI 编程范式

摘自 Google Gemini Pro 2.5 Deep Research :

  • Spec Coding 规范驱动开发 SDD：“Spec coding” 是一种规范驱动的开发流程，详细的规范文件（通常用 Markdown 格式）指导代码编写，通常借助 AI 编程工具完成。它提供结构化方法，与“vibe coding”形成对比，确保复杂项目的清晰、一致和易维护。规范文件作为需求、架构和推理的核心文档，生成并验证代码，创建清晰的“书面记录”。

    • 定义规范 (Specify)： 开发者提供一个高层次的描述，聚焦于项目的“是什么”和“为什么”（例如用户旅程、成功标准），随后 AI 会生成一份详尽的规范文档，通常采用 Markdown 格式，并可能遵循 EARS（Easy Approach to Requirements Syntax）等标准 1。

    • 制定计划 (Plan)： 开发者提供架构约束和技术栈选择，AI 则基于此生成一份技术实现计划，其中可能包含数据流图、数据库模式和 API 端点等细节 3。

    • 拆分任务 (Tasks)： AI 将规范和计划分解为一系列小型的、可审查的、可执行的工作项或清单 3。

    • 执行实现 (Implement)： 开发者引导 AI 代理执行这些任务，并在流程中设置明确的检查点，以便进行审查和方向修正 3。在此过程中，规范作为一份“活文档”，随着代码库的演进而同步更新 1。

  • Vibe Coding 基于氛围编程：“Vibe coding” 是一种软件开发实践，开发者用自然语言提示让 AI 生成和优化代码，专注于应用的“感觉”或目标，而非具体代码。由 Andrej Karpathy 提出，涉及向大型语言模型（LLM）描述需求，逐步引导它完成编写、测试和调试。该术语于 2025 年初因其简化应用开发的潜力而受到关注。

    • 描述 (Describe)： 开发者用自然语言描述一个高层次目标（例如，“创建一个暗黑模式的切换按钮”）。

    • 生成 (Generate)： AI 解释该请求并生成初始代码。

    • 执行与观察 (Execute & Observe)： 开发者运行生成的代码，检验其是否符合预期。

    • 优化 (Refine)： 如果出现错误或输出不正确，开发者会提供新的反馈（例如，“添加错误处理”或直接复制粘贴错误信息），然后重复此循环直至满意 10。

 

对比分析 Comparison Table 

 

维度

规范驱动开发 (Spec-Driven Development)

氛围编程 (Vibe Coding)

核心理念

文档优先，规范即代码，结构化协作

对话驱动，意图优先，直觉化探索

主要目标

质量、可维护性、一致性

速度、快速迭代、原型验证

开发者角色

架构师、系统设计师、AI 引导者

创意总监、产品经理、AI 对话者

工作流程

结构化、分阶段（定义、计划、任务、执行）

迭代式、循环（描述、生成、执行、优化）

代码质量

高，标准化，易于维护

可变，通常较低，难以调试 1

开发速度

初始阶段较慢，长期维护速度快

初始阶段极快，后期维护成本高

适用场景

复杂应用、生产级系统、团队协作 8

快速原型、实验性项目、个人项目 10

主要风险

前期规划开销大，可能僵化

技术债、性能问题、安全漏洞 1

代表工具

Kiro (Spec Mode), GitHub Spec Kit

Cursor, Claude Code (用于探索)
 
 

从表格可以看出，Spec Coding 更适合复杂系统，而 Vibe Coding 更适合快速迭代。

Which?

工欲善其事，必先利其器。推荐一些目前流行的 AI IDE，以及各自的特性。

 

 

 

image

>Windsurf: MCP Configuration Panel 命令内置的 MCP Servers
 

 

IDE 编辑器

下表由 Gemini Pro 2.5 Deep Research 生成，并不代表各 IDE 的最新能力：

 
 
 

功能

Kiro

Cursor

VSCode + IntelliCode

Trae

Windsurf

核心理念

从氛围编程到可用代码

与 AI 结对编程的最佳方式

增强现有编辑器的智能

协作式智能，AI 工程师

保持心流的直觉化 AI 编码

范式倾向

混合（偏向规范）

混合（偏向氛围）

辅助传统编码

混合（代理化）

混合（代理化）

代理自主性

高

可调（高）

低（辅助）

高

高

多文件编辑

是

是

否

是

是

规范生成

是

否

否

是

否

自动化钩子

是

否

否

是（自定义代理）

否

CLI 集成

是

是

否

是

是

MCP 支持

是

是

否

是

是

支持模型

Claude

多模型 (GPT, Claude, Gemini, Grok)

-

多模型 (Claude, GPT)

多模型 (Claude, Gemini)

代码库索引

是

是

否

是

是
 
 

 

CLI 命令行界面

 

其他 AI 工具

  • https://deepwiki.com/ ，如果你有阅读和快速理解源码的需求，那这个工具可以让你事半功倍

When?

我们在跟 AI 对话沟通时有两个交互主体，User（用户） & AI LLM，计算机和网络只是个通信媒介。所以用 AI 编程也符合这个区间规律： 

image

> 乔哈里视图 https://en.wikipedia.org/wiki/Johari_window，图片与内容摘自 https://zhuanlan.zhihu.com/p/1914601521477297248
 
 
 
 

象限

交锋模式

人类必杀技

典型案例

Open(人知道 + AI 知道)

闪电战

简洁直给

“用小学生语言解释 XX 算法的实现”

“编写 XXX 列表的 CRUD 界面和接口”

Blind(人不知道 + AI 知道)

寻宝战

问题拆解刀

“将该文件中的接口从 Java 翻译成 Go”

“用 Python 实现一遍这些数据结构和算法”

Hidden(人知道 + AI 不知道)

情报战

知识投喂术

“在我司的贷后业务需求中增加 AI 功能”

“KeepAlive 造成在 Win7 低内存设备上的卡顿如何修复”

Unknown(人不知道 + AI 不知道)

共创战

悖论燃料弹

“秦始皇陵什么时候开挖”

“用量子计算机破解比特币加密算法”
 
 

根据之前使用的经验来看，完全符合上图中描述。在实践中，“Open”, “Blind” 问题是很好解决的，结果质量跟它的顺序一致。而 “Hidden” 跟 “Unkown” 就很看提示词技巧和上下文工程中喂给 AI 的资料了。

 

比如 “KeepAlive 造成在 Win7 低内存设备上的卡顿如何修复” 这个问题，做了下 A/B Testing：

  • A case：用 Kiro 编写了 Spec 规范文档，并用 Claude-Code 4 实现了 Tasks list 任务清单

  • B case：用 CodeX 读取 Spec 规范文档，并实现 Tasks List，结果大不相同

  • Code X 写的代码相对能理解和看明白，而 Claude-Code 写了巨多代码，但全是技术债，因为压根也跑不起来，而且读起来也很费劲

  • 最终是在 Code X 的基础上做减法，不得不还是自己从头到尾从写了一遍

 

但是，在如下场景中，确实事半功倍。定义好了 TypeScript Interface 之后：

  • 让 AI 编写前端 CRUD 的列表，比如 ProTable 组件时

  • 用 AI 编写 Form 组件 / ProForm 组件

  • 具有良好描述的产品需求和设计文档，编写页面时

 

而以上，可以完成前端 70% 左右的工作量。而在定义好规范的情况下，它产出的代码，稍微改改，我们就能提 Merge Request 了。

 

建议

有好的输入，才能有好的输出。 Agent 是 Input，LLM 是 Thought processing, Code 是 Output.

  • Blind：如果你不知道怎么解决这个问题，AI 通常可以提供不错的思路。找它做顾问，协助设计是个很好的帮手，因为它的知识边界覆盖了全人类。

  • Hidden: 如果你没想清楚怎么写 prompt，那么 AI 通常也不知道怎么回答。因为没想明白怎么表达，说明还不够 “知道”与“理解”，那么 AI 可能会理解偏差。

  • Unknown：如果这是个公司业务特定创新场景，它超出了 AI 的认知。那么建议还是自己写比较好，因为 AI 也不知道怎么写。即使你提供了很好的 prompt，因为这个时候 AI 生产的的代码，通常是技术债。（上面 KeepAlive 就是例子）

How?

对 AI 工具的理解、掌握和使用，逐渐拉开了执行效率和生产力的差距。而具体的细节实践不仅是 IDE，还有 LLM 和 MCP。可以一边用 AI IDE 写代码，一边在 Agent 里面让它通过 LLM 调用 MCP 扩展各种能力边界。

 

MCP 的应用能力

比如：

 

当然可以把它们组合起来，像拼乐高一样，拼成最适合你的 Workflow。而 MCP 能力的边界，就是想象力的边界。

PS: 从 AI IDE 层面开启 MCP 这个能力通常需要付费。但是 LLM 通常是自带对 MCP 的支持。

 

如何配置 MCP

CodeX 配置 MCP 能力： https://developers.openai.com/codex/mcp/ ，然后在 CodeX CLI 中执行 /mcp 或者 codex mcp list 检查状态即可。

  • Context7 — connect to a wide range of up-to-date developer documentation

  • Figma Local and Remote - access to your Figma designs

  • Playwright - control and inspect a browser using Playwright

  • Chrome Developer Tools — control and inspect a Chrome browser

  • Sentry — access to your Sentry logs

  • GitHub — Control over your GitHub account beyond what git allows (like controlling PRs, issues, etc.)

Claude-Code 配置 MCP 能力： https://docs.claude.com/zh-CN/docs/claude-code/mcp ，如果使用 IDE 的话可以直接检查状态。CLI 的话，暂未用过。

  • 从问题跟踪器实现功能：“添加 JIRA 问题 ENG-4521 中描述的功能，并在 GitHub 上创建 PR。”

  • 分析监控数据：“检查 Sentry 和 Statsig 以检查 ENG-4521 中描述的功能的使用情况。”

  • 查询数据库：“根据我们的 Postgres 数据库，查找使用功能 ENG-4521 的 10 个随机用户的电子邮件。”

  • 集成设计：“根据在 Slack 中发布的新 Figma 设计更新我们的标准电子邮件模板。”

  • 自动化工作流：“创建 Gmail 草稿，邀请这 10 个用户参加关于新功能的反馈会议。”

Cursor 中快捷键 Shift+Command+P 打开命令模式，输入 Open MCP Settings 打开 mcp.json 文件配置，下面是 MCP 配置截图：

image

> Curosr 中打开 >View: Open MCP Settings 命令的截图
 

 

如何配置 Cursor Rules

最后最关键的一步，在 Cursor 的 rules 中写清楚 LLM 的角色定位和特定时候调用哪些 MCP 的特定能力。这个模版早期来源也是 Github 开源社区，具体来源是 X 上某个 KOL 分享出来的，忘记出处了。参考如下：

 
 
--- description: globs: alwaysApply: true --- # 角色设定 你是一位经验丰富的软件开发专家与编码助手，精通所有主流编程语言与框架。你的用户是一名独立开发者，正在进行个人或自由职业项目开发。你的职责是协助生成高质量代码、优化性能、并主动发现和解决技术问题。 --- # 核心目标 高效协助用户开发代码，并在无需反复提示的前提下主动解决问题。关注以下核心任务： - 编写代码 - 优化代码 - 调试与问题解决 确保所有解决方案都清晰易懂，逻辑严密。 --- ## 阶段一：初始评估 1. 用户发出请求时，优先检查项目中的 `README.md` 文档以理解整体架构与目标。 2. 若无文档，主动创建一份 `README.md`，包括功能说明、使用方式和核心参数。 3. 利用已有上下文（文件、代码）充分理解需求，避免偏差。 --- ## 阶段二：代码实现 ### 1. 明确需求 - 主动确认需求是否清晰，若有疑问，应立即询问。 - 推荐最简单有效的方案，避免不必要的复杂设计。 ### 2. 编写代码 - 阅读现有代码，明确实现步骤。 - 选择合适语言与框架，并遵循最佳实践（如 SOLID 原则）。 - 编写简洁、可读、带注释的代码。 - 优化可维护性与性能。 - 按需提供单元测试。 - 遵循语言标准编码规范（如 Python 使用 PEP 8）。 ### 3. 调试与问题解决 - 系统化分析问题，找出根因。 - 明确说明问题来源及解决方式。 - 在问题解决过程中持续与用户沟通，如需求变动能快速适应。 --- ## 阶段三：完成与总结 1. 清晰总结本轮改动、完成目标与优化内容。 2. 标注潜在风险或需留意的边界情况。 3. 更新项目文档（如 `README.md`）以反映最新进展。 --- # 最佳实践 ### Sequential Thinking（逐步思考工具） 使用 [Sequential Thinking](mdc:https:/github.com/smithery-ai/reference-servers/tree/main/src/sequentialthinking) 工具，以结构化的思维方式处理复杂、开放性问题。 - 将任务拆解为若干 **思维步骤（thought steps）**。 - 每一步应包括： 1.**明确当前目标或假设**（如：“分析登录方案”，“优化状态管理结构”）。 2.**调用合适的 MCP 工具**（如 `search_docs`、`code_generator`、`error_explainer`），用于执行查文档、生成代码或解释错误等操作。Sequential Thinking 本身不产出代码，而是协调过程。 3.**清晰记录本步骤的结果与输出**。 4.**确定下一步目标或是否分支**，并继续流程。 - 在面对不确定或模糊任务时： - 使用“分支思考”探索多种方案。 - 比较不同路径的优劣，必要时回滚或修改已完成的步骤。 - 每个步骤可带有如下结构化元数据： -`thought`: 当前思考内容 -`thoughtNumber`: 当前步骤编号 -`totalThoughts`: 预估总步骤数 -`nextThoughtNeeded`, `needsMoreThoughts`: 是否需要继续思考 -`isRevision`, `revisesThought`: 是否为修订行为，及其修订对象 -`branchFromThought`, `branchId`: 分支起点编号及标识 - 推荐在以下场景使用： - 问题范围模糊或随需求变化 - 需要不断迭代、修订、探索多解 - 跨步骤上下文保持一致尤为重要 - 需要过滤不相关或干扰性信息 --- ### Context7（最新文档集成工具） 使用 [Context7](mdc:https:/github.com/upstash/context7) 工具获取特定版本的最新官方文档与代码示例，用于提升生成代码的准确性与当前性。 -**目的**：解决模型知识过时问题，避免生成已废弃或错误的 API 用法。 -**使用方式**： 1.**调用方式**：在提示词中加入 `use context7` 触发文档检索。 2.**获取文档**：Context7 会拉取当前使用框架/库的相关文档片段。 3.**集成内容**：将获取的示例与说明合理集成到你的代码生成或分析中。 -**按需使用**：**仅在需要时调用 Context7**，例如遇到 API 模糊、版本差异大或用户请求查阅官方用法。避免不必要的调用，以节省 token 并提高响应效率。 -**集成方式**： - 支持 Cursor、Claude Desktop、Windsurf 等 MCP 客户端。 - 通过配置服务端集成 Context7，即可在上下文中获取最新参考资料。 -**优势**： - 提升代码准确性，减少因知识过时造成的幻觉与报错。 - 避免依赖训练时已过期的框架信息。 - 提供明确、权威的技术参考材料。 --- # 沟通规范 - 所有内容必须使用 **中文** 交流（包括代码注释）。 - 遇到不清楚的内容应立即向用户提问。 - 表达清晰、简洁、技术准确。 - 在代码中应添加必要的注释解释关键逻辑。
 

 

如何配置 Codex AGENTS.md

在 CodeX 对应的是项目级的 AGENTS.md 因为它是插件级别或者 CLI，没有 IDE 环境，所以只有项目级别的配置。使用 Codex CLI 执行 /init 即可自动初始化一份 AGENTS.md。下面的内容，没有参考价值，只是一个演示：

 
 
# 项目规则（面向编码代理） > 所有输出/注释/说明一律使用**中文**。 ## 开发/质量闸（务必先跑） - 安装：`pnpm i` - 质量：`pnpm lint && pnpm typecheck && pnpm format:check` - 单测：`pnpm test`（必须全绿） - 构建：`pnpm build` > 变更前后都要运行以上检查；有失败必须修复后再提交。 ## 代码风格与技术栈 - 统一 **TypeScript strict**，React RSC 优先，客户端组件最小化依赖 - UI：Tailwind + shadcn/ui；表单校验用 zod；数据用 SWR/React Query（二选一） - 禁止内联 `style={{}}`；公共样式抽到 `styles/` 或 util class - 目录约定：`app/`, `components/`, `lib/`, `server/`, `styles/` ## 禁止修改的区域 - ❌ `infra/terraform/**` - ❌ `apps/admin/**` - ❌ 新增 UI 框架/禁用 ESLint 规则 ## 提交/PR - 标题：`[app|pkg] <feature|fix|chore>: <desc>` - 提交前本地跑：`pnpm lint && pnpm test` - PR 描述需包含：动机、实现要点、风险与回滚方案 ## 工具与外部知识 - 需要查最新官方文档时：优先使用 **Context7**（若已配置 MCP）；否则再询问我。 - 面对模糊任务：使用“**逐步思考**”法拆解→执行→记录结果→迭代（仅在需要时）。
 

 

LLM PK: Codex vs. Claude-Code 4.0

代码生成 A/B 测试 (Codex vs. Claude-Code 4.0) 结合用户提供的内部测试记录（AI-16）与外部的用户情绪分析，可以对这两款工具进行深入比较 41。

  • 模型质量与问题解决能力： 普遍认为，Codex 在处理更具挑战性的复杂重构任务时表现更优 41。

  • 速度与用户体验： Claude Code 通常被认为响应速度更快，并且拥有更成熟的终端用户体验和工具生态系统 41。

  • 使用限制与定价： Codex 的付费计划通常被认为更“慷慨”，用户反映达到 Claude 使用上限的情况更为频繁 42。

  • 功能与可定制性： Claude Code 提供了更多如子代理和钩子之类的功能，但 Codex 的开源特性允许进行深度定制 42。

 

以上内容由 Gemini Pro 2.5 Deep Research 生成，我们可以在后续的 DEMO 中测试结果是否一致。我自己的经验是 CodeX 的代码相对会写得更简单一些，可读性更高，可能是因为它的模型更新的缘故。

 

Demo Cases

  • MCP Demo：

    • 用 Browser MCP 读取 Gitlab Activity + OA Calendar Events + Google Sheets Weekly Meeting Report 写一份周报

    • 使用 Gitlab MCP 做 CodeReview 和团队本周小结 ，PS：最终把这个 MR 关了，因为 AI 说得对。 

      • 在 Cursor 中用 Claude-Code 4.5 让 Gitlab MCP 做 Code Review
        用 CodeX CLI 调用 GitLab MCP 分析 fox-admin-ui 仓库一周的工作 commits 改动

      • 使用 Chrome Devtools MCP 获取 “成都最近一周的天气” 

    • 用 CodeX CLI + Chrome Devtools MCP 的执行过程 
      最终执行结果，可以看到非常棒
       

  • Coding Demo:

    • Idea 里面使用 windsurf 等这类工具

    • A/B Testing(VSCode & CodeX VS Kiro & Claude-code 4)：实现 Fox 系统中的分机号管理页面，YAPI 文档 https://fox-yapi.kuainiujinke.com/project/11/interface/api/18 和最终界面 https://fox.weidu.co/admin/call-center/number-binding/list 。我们现在用的工作流：

      • 后端同学 用 AI 读取需求文档让 AI 定义 @RequestBody 和 @ResponseBody 的接口实现，并更新到 YAPI 文档

      • 前端同学 用 AI 调用 Browser MCP 读取接口文档内容，生成 Api.service.ts 代码和 interface 接口

      • 有了 interface 的基础之后，让 AI 根据现有代码库索引 Codebase 和定义的各种规则边界 Rules 和 Specs 规范文档生成代码

      • 生成好代码之后启动前后端服务，联调测试一下接口，没问题，就让 AI 编写 Commit Message、push 代码，然后提起 MR 即可

      • 然后在 Gitlab 的 Webhook 中接上 CI / CD 中，让 AI 根据知识库 reivew 一下是否符合规范、是否存在逻辑错误、是否存在设计错误，合并代码，提交测试。END！

  • Writing unit testing cases:

    • Commonly used for library mode - @feoe/react-keepalive，这个很简单，你直接 vibe coding 即可

  • Writing project design document:

    • Project Design Document，同上

    • README Document，同上

  • UI Design & Prototype Design, 目前流行的一些 SaaS 及其各自特点:

  • Project Infrastructure Design

    • XXX 系统（XXX 的意思就是“随便测试一个啥系统都可以”）

      • 需求描述文档

      • 产品设计文档

      • 原型设计文档

      • 架构设计文档

      • 接口设计文档

    • 你画我猜

  • Code Review

    • Gitlab: 用 GitLab MCP 做 CR

    • Gitlab: 自建 Dify Workflow + 团队规范知识库，见我们投产的用例

    • Github: 集成 Cursor Integration ，这个 Github 上有很多现成的 SasS 工具

 

Others

  • Q & A

  • Summary

    • 不要有危机感，人依然不可取代，AI 是代码的搬运工和迭代器

    • AI 编码确实提效飞快，但对代码规范、业务理解、架构设计水平反而要求更高

    • 适合编写模版化代码，不适合编写创新业务和定制小众场景，否则就会开始偿还技术债

 

posted @ 2025-10-27 14:20  月光宝盒造梦师  阅读(62)  评论(0)    收藏  举报