过去一年我用 AI 编码助手做了不少"重复但需要判断"的活：批量改文案、迁移旧脚本、补单元测试、写 SQL 助手。把这些经验沉淀下来之后，工作流的形状慢慢稳定下来——本文分享目前跑得最顺的一套轻量实践。

把 AI 当成"懂上下文的同事"

最浪费时间的用法是把 AI 当万能搜索框：丢一个问题进去，对答案惊喜或失望。实际上更有效的用法是先告诉它"你是谁、你在哪个项目里、约束是什么"，再让它做事。我会写一段固定的"项目说明"，每次新会话开头粘进去：

1
2
3
4

你是一个资深后端工程师，正在协助维护一个 Go 微服务项目。
- 代码风格：gofmt + 项目内 lint 规则。
- 测试要求：所有非工具方法都要覆盖 happy path 和 1 个边界 case。
- 改动影响范围必须先列出，再贴出代码。

这一段不长，但对回答质量的提升非常明显：模型知道"先讲思路再贴代码"，而不是一上来就吐一堆片段。

提示词的三个层次

我把提示词分成三层，按场景切换：

  1. 直接问题：API 怎么用、某个错误码怎么排查——一句话就能问完。
  2. 模板化任务：补一个单元测试、把一段代码翻译到另一个语言——我会维护一组 Markdown 模板，每条模板只填空就好。
  3. 半开放协作：重构一段旧代码、写一个内部工具——这时我会附上相关文件、跑得起来的最小复现脚本，并明确"先列改动点，等我确认再贴 patch"。

第三种情况最容易失控，所以我会坚持"两轮回复原则"：第一轮只让 AI 写思路，验证完方向再让它真正动代码。

复用检查清单

每次和 AI 协作结束，我都会在文档末尾补一段"今天学到的"：

  • 这个需求里有没有以前重复踩过的坑？
  • 有没有可以抽出来的脚本 / Make 目标？
  • 提示词模板要不要再迭代一条规则？

举个例子：第一次让 AI 改 SQL，它每次都忘了贴 DDL；第二次我直接在模板里写"先贴 schema，再贴查询"，问题就消失了。这种小迭代累积起来，省下来的时间远超预期。

踩过的坑

  • 过度抽象：让 AI 一步到位写"可扩展的通用框架"，结果产出一堆空接口。原则是先做能跑的简单版，再让 AI 帮忙重构。
  • 幻觉依赖：AI 经常编造不存在的 API。用法是让它先输出"我假设这些 API 存在"，再由我对照真实文档核对。
  • 忽视测试：让它补测试时，它倾向只覆盖 happy path。我把"happy + 边界"写进提示词模板，才显著改善。

写在最后

AI 编码助手最有价值的不是"替你写代码"，而是"在你已经想清楚的前提下，加速中间那段最无聊的工作"。把它当成一个有耐心但需要明确上下文的同事，效率提升会稳定很多。

相关

顺带一提:深夜跑 Agent 的活,吵的是自己——机械键盘怎么选里静音轴那节就是给这种场景准备的。