面试被问"你在内部有哪些 AI coding 提效工作"——只答"用了 Copilot"是最弱的回答。真正值钱的是：具体怎么用、量化结果、以及你设计的工作流。
这篇文章把我的实战拆成可复制的全链路。
六个场景，按 ROI 排序
不是所有编码环节都值得交给 AI。按投入产出比排：
- 代码生成 —— 模板代码 / CRUD / 配置文件，提效 3-5x
- 单元测试生成 —— 覆盖率从 40% → 80%+，省下大量机械劳动
- Code Review —— 自动查常见问题（安全 / 性能 / 命名），压缩人工 review 时间
- 文档生成 —— API 文档 / CHANGELOG / README，提效 5-10x
- 调试辅助 —— 贴报错自动给修复建议
- Onboarding —— 新人用 AI 快速理解陌生代码库
注意排序：文档和单测的 ROI 往往最高，因为它们最机械、最不依赖创造性，却最容易被人类拖延。
三层落地：个人 / 团队 / CI
提效不是装个插件就结束，要分层次铺开：
- 个人层：Cursor / Claude Code 日常编码，把重复活交给模型
- 团队层：内部 AI coding 工具 + 共享 prompt 库，把个人经验变成团队资产
- CI/CD 层：自动测试生成、自动 code review，每次 PR 触发
关键认知：不要让 AI 只在你本地跑。把它沉到 CI，才能从"个人快一点"变成"团队不出低级错"。
Vibe Coding 的正确姿势
Vibe Coding = 用 AI 快速写代码、不逐行审查、靠测试验证。它有用，但有边界：
- 适合：原型验证 / 内部工具 / 个人项目 / 一次性脚本
- 不适合：安全关键 / 金融 / 医疗等出错的代价过高的场景
- 成功指标：跑通测试 > 开发速度 > 迭代次数（测试通过才是真的跑通）
我自己的经验：vibe 出来的代码，先让它过测试，再谈可读性。没测试的 vibe 代码等于没交付。
上线即责任：把评测思维迁移到生成代码
这一点最容易被人忽略。给 skill / 工具上线前我会走一套评测流程，AI 生成的代码也该同理：
- 开发自测 —— 本地跑 10-20 个典型 case，覆盖正常 / 边界 / 异常
- 自动化测试 —— CI 跑全量测试集，每次提交触发
- 灰度发布 —— 先小流量，看完成率 / 延迟 / 错误率
- 人工 Review —— 人走查输出质量，重点盯安全和幻觉
- 回滚方案 —— 一键关闭，有回滚才有底气上线
AI 生成的代码也是"上线即责任"：生成的代码也要有回滚和监控，不是生成完就免责。
我的真实案例：博客发布全链路
把上面的思路落到我自己最熟的流程——写博客。一篇博客从选题到上线：
- 调研：Tavily / 搜索提炼问题分类
- 写作：AI 辅助起草，人把控观点和结构
- 构建：
hugo --minify生成静态站 - 发布：
git push到 GitHub Pages - 验证：
curl线上状态码 200 确认
AI 在写作、构建、验证三段都参与，整体提效明显。但观点和事实准确性始终由人兜底——这是 vibe 和负责任交付的分界线。
量化表达模板
被问"提效多少"时，别给模糊词。用这个句式：
X 任务原本 Y 小时，引入 AI 后 W 小时，提效约 N 倍。
准备 2-3 个具体案例，比说"提效很多"有力十倍。体现的不是"AI 帮我写代码"，而是**“我如何设计工作流让 AI 发挥最大价值”**——这才是面试官想听的。
小结
AI Coding 提效不是"装个 Copilot"，是一条生成 → 测试 → Review → 文档 → 监控的全链路。
把高 ROI 的环节（单测、文档）先自动化，把 AI 沉到 CI 而不是留在本地，给生成的代码也配上回滚和验证——提效才从"个人感觉快了"变成"团队真的少出错"。