我的 AI Coding 日常工作流
从 2025 年底开始，我大部分时间用 Cursor 写代码。不是「完全交给 AI」，而是固定了一套工作流。下面是我这几个月稳定在用、且确实省时间的做法。
开任务之前：先自己说清三件事
在输入任何 prompt 之前，我会在脑子里（或草稿里）回答：
- 改什么： 具体文件或模块，避免「优化一下项目」
- 不能动什么： 例如「不要改首页切换逻辑」「不要加 npm 依赖」
- 怎么算完成： 例如「build 通过」「点击 Blog 能跳转」「移动端能滚动」
这三件事写进 prompt，返工率会明显下降。AI 最怕的不是难题，是模糊目标。
我的默认分工
| 我做 | AI 做 |
|---|---|
| 架构决策、任务拆分、验收 | 样板代码、样式细节、文档初稿 |
| 安全/隐私相关配置 | 重复性 CRUD、JSON 数据填充 |
| 复杂 bug 的最终判断 | 根据报错日志提出假设和 patch |
| 提交前的 git diff 通读 | 按我的要求改指定文件，不擅自 git commit |
三轮检查（固定执行）
每次 AI 说「做完了」，我会按顺序做：
- 构建检查：
npm run build或对应 task，看 exit code 和产物路径 - 浏览器检查： 不只看「页面能打开」，要点击导航、滚动、切换分类、移动端宽度各测一遍
- Diff 检查： 扫有没有改到不该改的文件（比如顺手改了 config、dist、无关样式）
很多「AI 说完成了」的问题，第一轮 build 就能抓到；交互 bug 在第二轮；「顺手多改」在第三轮。
会话怎么管理
一个功能一块上下文，别在一个会话里从「加博客」聊到「修 Spring Boot」。会话太长，AI 会忘记早期约束，开始重复犯已修复的错。
我的习惯：
- 新功能 → 新会话，开头贴上设计文档或相关文件
- 修 bug → 带上报错信息 + 相关文件 + 复现步骤
- 大范围重构 → 先让 AI 出计划，我确认后再让它按 task 执行
Agent 模式和 Chat 模式怎么选
- Chat / 普通 Agent： 改 1～3 个文件、逻辑清晰时用。我会明确列出文件路径
- 需要探索仓库时： 让 AI 先搜索再改，但限制范围（「只在 src/blog 下找」），避免全仓库乱改
- 绝不让 AI 直接 commit： 除非我明确要求。提交前我要看 diff
什么时候不用 AI
- 一行就能改完的 typo——自己改更快
- 涉及密钥、token、生产配置——手动
- 我完全没读过的核心模块要大改——先自己读代码，再让 AI 辅助
- AI 连续两次修同一个 bug 失败——停下来自己 debug，把结论喂回去
一周典型的节奏
周一到周四：小步迭代，每天 1～2 个可验证 task。周五：整理 diff、补文档、把 AI 生成的草稿改成自己的话（比如博客正文）。
这套流程不炫，但稳定。AI 的价值不是「少思考」，而是把思考花在刀刃上，重复劳动交给它。
工作流的价值，在于每次都知道下一步该验证什么。