2026/5/15大约 3 分钟
与 AI 结对写代码时，流程比单条「神提示」更重要：把目标讲清楚、上下文给足、改动拆小、用测试与审阅兜底。下文以通用原则为主；使用 Cursor 时各模式具体怎么选，见 Cursor 使用完全指南。
目标与原则
- 你是负责人：AI 是加速器，不是作者；合并进主干的代码仍应由你理解并背书。
- 可验证：每个迭代尽量对应可运行的结果（命令、单测、页面操作），避免「一大坨 diff 却不知好坏」。
- 可回滚：习惯分支与小步提交，必要时一条
git revert能救命。
需求怎么拆
- 一句话目标：用户能做什么 / 接口长什么样 / 非目标是什么（不做哪些事）。
- 约束：技术栈版本、需兼容的浏览器/Node、是否禁止引入新依赖、风格（ESLint/Prettier）等。
- 验收：列出 2～5 条「怎样算做完」——可手动点的流程，或要跑的命令（如
pnpm test）。 - 分块交付：先打通最小闭环，再补边缘情况与重构；不要一次要求「把整个系统做完」。
何时用什么方式协作（与 Cursor 对照）
复杂任务建议：先想清楚再动手。Cursor 里 Plan / Ask / Agent / Debug 的分工与权限，见 Cursor 使用完全指南 中的对比表与推荐流程。
抽象到工具无关的说法：
- 只问不争改：读不懂的模块、概念澄清、方案对比 —— 适合低权限/只读对话。
- 先出蓝图：多文件影响、取舍点多 —— 先要可审阅的步骤清单或设计说明，再进入批量改代码。
- 批量改代码：已确认步骤与小范围 —— 再交给高权限自动修改，并准备好随时撤销。
- 有报错再给证据：堆栈、请求日志、复现步骤比「它坏了」有效得多。
小步提交与验证
每完成一小块就：
- 跑你信任的检查：类型检查、lint、相关测试或本地手动点一遍。
- 提交说明写给人看：标题说「为什么」，正文可写「改了什么文件、注意点」。
- 不攒巨型提交：难以审阅的 PR 也更容易藏 bug。
若 AI 改了配置、依赖或 CI 脚本，把它当作「高风险改动」，单独提交并亲自 diff。
审阅 diff 时重点看什么
- 行为是否变了语义：尤其是条件分支、边界值、异步顺序、错误处理。
- 是否引入无效或危险代码：死代码、
any滥用、凭空调用外部接口、密钥硬编码等。 - 是否动到不该动的文件：无关格式化全军覆没时，优先让 AI 收窄范围重做。
- 测试是否跟得上：新逻辑若没有测试或手工验收步骤，默认视为未完成。
安全与仓库习惯
- 在单独分支上让 AI 大展身手；主分支保持可发布状态。
- 不要把密钥、Cookie、生产 URL、内网地址粘贴进对话；用占位符描述问题即可。
- 对自动生成的迁移脚本、批量重命名，本地先跑通再推。
延伸阅读
- 如何把需求写进提示里、常用模板与上下文约定：提示模式备忘。