AI Coding 的一些技巧

原则是：AI 负责起草，我负责验证、重构和最终负责。

1. AI 辅助开发

① 平时怎么用 AI 写代码

分场景用：

• 写样板代码：CRUD、表单校验、工具函数，直接让 AI 生成，省时间
• 写测试：让 AI 根据函数生成单测，我再补边界用例
• 读代码：把陌生代码丢给 AI，让它解释逻辑、画流程图
• 查 API：不熟的库，让 AI 给用法示例，但我一定去官方文档核对
• 重构：让 AI 提重构建议，我判断哪些合理

不用 AI 的场景：

• 核心业务逻辑（怕它编）
• 安全相关代码（怕它引入漏洞）
• 性能敏感代码（怕它写出低效实现）

② prompt 怎么写

我的 prompt 结构：

【背景】项目是 React + TS，用 Vite
【任务】写一个防抖 hook
【约束】支持立即执行选项，TS 类型完整，不引第三方库
【输出】只要代码，不要解释

关键点：

• 给上下文：技术栈、版本、已有代码风格
• 给约束：不能用什么、必须满足什么
• 给例子：贴一段现有代码，让 AI 对齐风格
• 分步问：复杂任务拆成多轮，别一次问完

③ 如何控制 AI 输出质量

• 小步验证：让它一次只做一件事，做完我跑一遍
• 要求它给测试：让它顺手写单测，我跑通才算过
• 让它自我 review：生成完再问“这段代码有什么潜在问题”
• 交叉验证：关键逻辑换一个模型再问一遍，对比结果
• 人工兜底：AI 的输出，我逐行过一遍才合并

---

2. Debug 场景

① AI 生成代码有 bug 怎么定位

我的流程：

1. 先复现：确认 bug 稳定复现，缩小范围
2. 二分定位：把 AI 生成的代码分成几块，逐块注释掉，找到出问题的那块
3. 对比预期：把出错代码 + 报错信息 + 预期行为丢给 AI，让它解释
4. 自己读：AI 解释完，我自己再读一遍，确认它说的对不对
5. 最小化：把 bug 抽成一个最小可复现例子，再修

关键：要先自己定位到具体哪一行。

② 如何验证 AI 输出正确性

• 单测：让 AI 写单测，但我要补边界用例（空值、极值、异常）
• 类型检查：TS 项目跑 tsc，类型不对直接暴露
• Lint：跑 ESLint，风格和潜在问题一起查
• 手动跑：关键路径手动点一遍
• Code Review：自己逐行读，重点看边界和异常处理

③ 如何避免 AI 引入隐性 bug

AI 最容易引入的隐性 bug：

• 边界没处理：空数组、null、undefined
• 异步没处理：忘了 await、Promise 没 catch
• 闭包陷阱：循环里用 var
• 类型不对：隐式 any、类型断言滥用
• 安全漏洞：XSS、SQL 注入、硬编码密钥

我的做法：

• 重点 review 这几类
• 让 AI 自己列“这段代码可能的问题”
• 关键路径加断言和日志
• 上线前跑一遍集成测试

---

3. 工程化

① 如何让 AI 参与 CI/CD

可以做的：

• PR 自动 review：接 GitHub Actions，PR 提交时让 AI 跑一遍，评论潜在问题
• 自动生成 commit message：根据 diff 生成规范 commit
• 自动补单测：新代码没测试时，AI 生成初版单测，人工补边界
• 自动查安全：AI 扫依赖和代码，提示已知漏洞
• 自动写 changelog：根据 PR 生成发布说明

注意：AI 只做“建议”，不直接改代码、不直接合并。最终决定权在人。

② 如何做自动 code review

我的方案：

1. 接 CI：PR 提交时触发
2. AI 扫 diff：只 review 改动的部分，不扫全量
3. 按规则输出：
   • 潜在 bug
   • 性能问题
   • 安全问题
   • 风格不一致
4. 分级：分“必须改”和“建议改”，避免噪音
5. 人工确认：AI 的评论只是参考，最终由 reviewer 决定

关键：AI review 是“辅助”，不是“替代”。它能发现低级问题，但业务逻辑、架构设计还得靠人。

---

总结：

我用 AI 的原则是：AI 起草，我兜底。

开发时，样板代码、测试、文档交给 AI，核心逻辑自己写。prompt 给足上下文和约束，小步验证。

Debug 时，先自己定位到具体位置，再让 AI 解释和提建议，不直接让它改。验证靠单测、类型检查、lint 和人工 review。

工程化上，让 AI 参与 PR review、生成 commit、补单测，但只做建议，不直接改代码。最终合并权在人。

核心：AI 提效，但质量和安全由我负责。