AI时代重构你的开发工作流：Prompt、Rules与Test的“三角关系”

前端王壮壮
68 阅读8分钟

大家好，今天不聊什么新框架，也不聊性能优化黑科技。聊聊最近让我很“头大”但又有点“真香”的一个话题：怎么把 AI（ChatGPT/Claude/Copilot）真正塞进前端的工作流里，而不是只把它当个查文档的工具。

这事儿的起因特别俗：我想偷懒。

image.png

最近项目紧，大部分功能我都简单梳理后, 直接给它一个 Prompt，让它吐给我一段代码，看着像模像样，跑起来全是 Bug。要么是边界条件没处理，要么是类型定义乱七八糟。

那一刻我意识到：AI 就像个实习生，甚至是个只会死记硬背的实习生。你不给它立规矩（Rules），不给它做考核（Test），它给你的产出就是一堆能跑但不可用的“垃圾”。

于是我折腾出了一套属于我自己的“三步工作法”，核心就是这四个词：Prompt、Rules、Test。

1. Prompt 不是许愿，是“技术方案评审”

以前我写 Prompt 特别像求神拜佛：“大神，帮我写个登录按钮，要好看点，最好有点动画。”
这种许愿式 Prompt，AI 回给你的通常是一堆华丽但没用的废话，真要集成到项目里，你还得花两小时给它擦屁股。

后来我发现，你得把 AI 当成那个“只会死记硬背但手速极快的实习生” 。你不给他讲清楚接口怎么传、异常怎么捕，他就敢给你写个只有 Happy Path（理想路径）的代码，一跑就崩。

现在我的 Prompt 已经进化成了“微型技术文档”，甚至带点“防御性编程”的味道：

举个更真实的例子：
以前我只会说：“写个请求用户列表的 Hook。”
现在我会这么写（甚至更啰嗦）：

“你现在是一个有 5 年经验的 React 专家。请写一个 useUserList Hook。

核心逻辑：

  1. 依赖 page 和 pageSize 两个状态，page 变化时重新请求。
  2. 请求函数使用 axios，URL 是 /api/users。

必须处理的边界情况（这里才是重点） ：

  1. 竞态条件（Race Condition） ： 如果我在第 1 页还没回来时，快速点到了第 2 页，必须保证只渲染第 2 页的数据（提示：用 CancelToken 或者 AbortController，你自己选，但必须写）。
  2. 组件卸载时： 如果请求还在飞，组件突然被销毁了（比如切换路由），绝对不许调用 setState，否则就报内存泄漏警告（提示：用 isMounted 标志位或者直接忽略）。
  3. 空状态： 接口返回 null 或者 undefined 时，不要让页面崩掉，默认转成空数组。”

image.png

这里的“坑”和“道” ：

  • 你得比 AI 更懂坑： 你看，我上面提到的“竞态条件”和“内存泄漏”。如果你自己平时写代码不注意这些，你根本想不起来在 Prompt 里加这一条。AI 默认是不会主动给你写这些“防御代码”的，因为它觉得“能跑就行”。
  • 倒逼你理清逻辑： 有时候我写着写着 Prompt 发现卡住了——“哎？这个逻辑如果是 A 情况怎么办？”。这时候我会停下来先自己想清楚，再补全给 AI。所以写 Prompt 的过程，其实是强迫我自己先把技术方案想透的过程。  AI 只是帮我把想好的方案翻译成代码而已。
  • 不要假设 AI 有常识： 别指望它知道你们公司的 request 封装里错误码是 500 还是 200，也别指望它知道你们项目用的是 Zustand 还是 Redux。这些上下文（Context），必须像喂饭一样，一勺一勺喂给它。 e f 总结一下：
    现在的 Prompt 对我来说，不再是“询问”，而是 “命令” 。
    我不再问“能不能帮我...”，而是说“请严格按照以下规范执行...”。
    这活儿干久了，你会发现：Prompt 写得越细，后面改代码的时间越少。因为最贵的不是打字，是 Debug。

image.png

2. Rules：给 AI 套上“紧箍咒”

这是我觉得最重要的一环，甚至比 Prompt 还重要。

AI 有个毛病，它就像个刚毕业还没被社会毒打过的文艺青年，喜欢炫技，或者用一些听都没听过的冷门库。但在前端工程化里， “不统一”就是原罪。

如果你不管它，它敢在一个项目里给你混着用 Tailwind、Styled-Components 和 Less。到时候代码库就是一锅粥，后人（也就是你自己）看一次想打人一次。

所以我建立了一套本地的 Rules（规则库） 。我不把它当文档，我把它当 “代码审查机器人” 。

我的“人机对抗”流程图

与其说是规则，不如说是我在本地维护的一个 Pre-check 脚本（或者是 ChatGPT 的 System Prompt 置顶条）。每次 AI 吐代码之前，必须先过这道“闸机”：

image.png

那些“反人类”的细节控制

光说不练假把式，给你们看几条我 Rules 里真正“卡脖子”的死规定：

1. 禁止“发明创造”

Rule: “严禁使用 react-window 以外的虚拟滚动库，禁止自己手写 scroll 事件监听，因为之前的项目里自己写的全是 Bug。”
原因: AI 特别喜欢推荐那种 npm 周下载量只有 50 的“新轮子”，虽然原理很酷，但出了问题全网搜不到 StackOverflow 答案。

2. 命名强制对齐

Rule: “所有 API 请求函数必须以 use 开头（比如 useFetchUser），且必须返回 { data, loading, error } 三元组。不许返回 { result, isLoading, err } 这种千奇百怪的命名。”
原因: 这一点最坑。如果不强制，AI 能给你写出十种不同的命名风格，最后你的项目里得写十套 if (loading || isLoading || fetching) 的判断，这才是真正的“技术债务”。

3. 甚至包括“废话”

Rule: “注释里不许写 // 这里是变量 这种废话，但必须给复杂的正则表达式写清楚业务含义。另外，所有的 console.log 必须在交付前删除，如果让我看到一行 console.log，这次生成的代码全部作废。”

真实的感受：从“艺术家”到“流水线工人”

有了这套 Rules，最大的变化是什么？

AI 变“笨”了，但也变“好用”了。

以前它像个艺术家，给你画一幅毕加索，你得猜半天这是啥。
现在它像个被拴在流水线上的工人，动作机械、枯燥，甚至有点死板。
但在前端团队协作里，我们需要的不是艺术家，是一百个能写出一模一样代码风格的“工具人”。

当我把 Rules 喂给它之后，它生成的代码，我甚至不用看文件名，光看代码风格就知道是“我们组”写的。这种确定性，才是工程化最需要的东西。

3. Test：不是为了测 AI，是为了测“我自己”

这一步是最反直觉的。

以前我觉得，AI 写的代码我肉眼 Review 一下就行了。后来发现，肉眼是会疲劳的，尤其是面对那种嵌套了五层的 useEffect。

现在我的流程变了：AI 写完代码 -> 我立刻写测试用例（Unit Test）。

如果我写测试用例时发现：“哎？这个函数怎么传参这么别扭？”，那 90% 是 AI 的逻辑有问题，或者是我的 Prompt 没描述清楚。

举个例子，AI 写了个格式化金额的函数 formatMoney。
我不用肉眼看它的正则表达式对不对，我直接写三个 Test Case：

  1. 输入 1000，期望 "1,000"
  2. 输入 null，期望 "0"（这里 AI 经常忘处理 null）
  3. 输入 1234567.89，期望 "1,234,567.89"

Test 变成了一种“逆向的 Prompt 优化”。  如果测试跑不通，说明我的需求（Prompt）或者规则（Rules）有漏洞。

4. 前端角色的转变：从“搬砖”到“验收”

这一套流程跑下来，我发现前端开发的味道变了。

以前我们是纯粹的 Coder：从零开始敲键盘，把逻辑翻译成代码。
现在我们更像是 Architect + QA：

  • 我们定义 Rules（架构规范）；
  • 我们设计 Prompt（需求输入）；
  • 我们编写 Test（质量验收）。

AI 负责填肉，我们负责骨架和灵魂。

写在最后

这套《Prompt、Rules、Test》的组合拳，目前也不是百分百完美。
有时候 AI 还是会写出那种“看起来完全正确，但运行起来就是报错”的鬼代码。这时候还是得靠我们自己扎实的基础去 Debug。

但我觉得这是个趋势。不要把 AI 当成神，把它当成一个记性很好、手速很快、但偶尔会偷奸耍滑的助理。

你要做的，就是立好规矩（Rules），盯着测试（Test），然后用精准的语言（Prompt）去驱动它。

与其担心被 AI 取代，不如先学会怎么“使唤”它。毕竟，能把 AI 调教好的前端，本身就得是个好前端。

以上就是我的一些野路子分享，希望能给大家省点头发。

avatar
文章
阅读
粉丝