给自己搭一个「AI 助理」开发流程

wuwj 收录于 AI 与开发者体验

2023-07-22 约 237 字预计阅读 2 分钟

2023 年对我来说有一个明显变化：

编辑器不再是一个「孤立工具」，而是被各种 AI 助手包围。

从简单的代码补全，到用大模型参与需求理解、方案推演、重构、写单测……
这篇文章就讲讲我是怎么给自己搭一套「AI 助理」开发流程的。

1. 先想清楚：希望 AI 在开发中帮我做什么？

我给自己列了一个清单：

样板代码生成：页面骨架、接口封装、组件模板；
复杂逻辑解释/重构：老代码梳理、新方案对比；
单测生成：尤其是工具函数、纯逻辑模块；
文档和注释：根据代码生成合适的注释、接口说明；
代码 Review 辅助：帮我发现一些潜在问题或改进点。

工具上则主要依赖：

编辑器内的代码补全（Copilot 类）；
Chat 类大模型（ChatGPT 等）；
自己整理的一些 Prompt 模板。

2. Prompt 模板：把「怎么问」提前想好

很快会发现：随便问一句「帮我优化这段代码」效果参差不齐。
于是我开始为不同场景整理固定 Prompt 模板。

2.1 重构模板

请作为资深前端工程师，帮我重构下面这段代码：

目标是提高可读性和可维护性，而不是追求最短写法；

如果有明显的边界情况，请指出并补上处理；

给出重构后的代码，并用要点列出你做了哪些调整和原因。

代码如下：
```ts
// code here
```

2.2 单测生成模板

帮我为下面这个纯函数生成单元测试用例：

使用 Jest 语法；

覆盖常见正常输入和几种边界情况；

简要说明每个测试用例要验证的点。

代码如下：
```ts
// code here
```

我会把这些模板存成 Snippet 或者存在笔记里，方便复用。

3. 编辑器内的 AI：使用边界和习惯

装上 Copilot 类插件之后，一开始很容易「啥都接」。
用了一段时间，我给自己定了几个使用习惯：

让它写样板，不让它写业务决策
- 例如：生成组件结构、接口调用骨架；
- 业务规则、金额计算、权限判断等还是自己写。
接受补全前，先用眼睛过一遍
- 就像在 Review 别人的代码，而不是自动点回车。
善用「用注释驱动生成」
```
// TODO: 根据后端返回的订单列表，按状态分组并排序
```
写完注释再停顿一下，让 AI 给实现建议，再按需修改。
遇到不明白的代码，直接让它解释
- 比如选中一段正则 / 算法，让 AI 用中文解释含义。

4. 把 AI 拉进「本地工具链」：Lint / 测试 / 脚本

除了编辑器内的代码补全，我也尝试让 AI 参与：

Lint 规则讨论
- 把「我们想要的编码规范」描述给大模型，让它帮忙生成 ESLint 规则配置草稿；
- 再由团队一起审阅、微调。
测试用例设计
- 对某个关键模块，先用自然语言描述期望行为；
- 让 AI 帮忙列出可能的测试维度（正常 / 边界 / 异常场景）；
- 再基于这些维度补写具体测试。
脚本生成
- 比如写一个解析日志的小脚本、一个批量改名脚本，把需求直接用中文写出来，让 AI 给 Node/TS 实现。

这些东西都不直接进线上逻辑，但在开发效率上帮助很大。

5. 与团队规范对齐：别让 AI 变成「风格污染源」

如果只有你一个人用 AI，问题不大；
一旦团队里多人开始用，很容易出现：

不同人生成的代码风格完全不同；
和既有项目规范不一致。

几条实践：

把项目的代码规范告诉 AI
- 例如：我们使用 Vue3 + <script setup> + Composition API；
- 把目录结构、状态管理方式、常用工具抽象一并给它。
生成代码后必须过 ESLint/Prettier
- 用工具兜底，让风格收敛。
Review 时允许指出「AI 味太重」
- 比如变量名过于抽象、过度封装、隐含逻辑不清楚；
- 鼓励作者自己重写或精简。

6. 让 AI 参与需求澄清与设计讨论

除了写代码，我也开始在更前面一环使用 AI：

需求澄清
- 把产品文档贴给 AI，让它帮忙总结关键功能点、边界情况；
- 甚至让它列出你应该向产品/后端继续追问的问题。
方案对比
- 描述两种前端实现方案，让 AI 帮忙对比优缺点：
  - 例如「用微前端 vs 单仓多项目」；
  - 「用配置驱动表单 vs 手写组件」。
生成技术方案初稿
- 你先写一个提纲，让 AI 帮你填充结构化内容（背景、目标、方案、风险点）；
- 再自己修改成团队风格。

这类工作本质上还是要自己做判断，但 AI 非常适合作为「思路激发器」。

7. 几个踩坑瞬间

盲目相信生成的代码
- 一开始图省事，把一大段生成的逻辑直接上了；
- 结果边界条件有坑，线上暴露问题。
- 教训：AI 写的代码必须像严格 Code Review 一样过一遍。
把项目上下文给少了
- AI 不知道你用了哪个状态管理、不知道既有工具函数；
- 生成的方案与项目风格完全不搭。
- 解决：每次提问之前，先给必要上下文（项目技术栈、相关文件片段）。
让 AI 写太长的文件
- 一次性生成几百行组件，阅读成本非常高；
- 更难自己掌控结构。
- 现在更倾向于：分模块、分步骤生成。

8. 小结：把 AI 当「开发环境的一部分」

搭完这套流程之后，我对「AI + 开发」这件事有几个新的认识：

它不是单点工具，而是可以贯穿 需求 → 设计 → 编码 → 测试 → 文档 的全链路；
最适合交给它的，是重复度高、结构清晰、容易验证对错的工作；
最不能丢给它不管的，是涉及业务核心逻辑、钱、权限、安全的部分。

如果你也想给自己搭一个「AI 助理」开发流程，可以从三步走：

装一个你顺手的代码补全工具；
整理几条适合自己常用场景的 Prompt 模板；
选择一个小模块，从需求→实现→单测，全程让 AI 参与一次。

用完一段时间，你大概率会发现：
不是 AI 取代了你，而是你有了一个新的超强外挂。

目录