「AI PR 描述模板」这种开发任务，AI 很容易显得很能干。它能马上给代码，甚至解释得头头是道。但真正让我放心的，从来不是回答，而是后面的 diff 和测试。
我会让 Claude、Cursor、GitHub Copilot 各站一段：先读现有代码，再补局部实现，再看风险。「PR 描述模板」不能只靠一段生成结果，项目里的命名、测试和旧约定都要进来。
这句听起来不够漂亮，但挺有用。「PR 描述模板」 先留一点笨拙，后面的人才知道该从哪里改。
先读仓库脾气
做「PR 描述模板」之前，我会先找三处相似实现。这个动作有点慢，但能让 AI 少写那种“看起来正确、风格完全不贴项目”的代码。
如果「PR 描述模板」只剩一句“帮我做一下”，我会先停住。需求越短，越要补上下文。
把不能碰的地方写清楚
我会先准备一页纸，写清现有实现、文件范围、测试命令和边界条件。不用写成正式文档，能让同事看懂就行。对「PR 描述模板」来说，这页纸比一段很长的提示词更重要。
真要写提示词，我不会追求漂亮。我会直接告诉 AI：基于这些材料，给一版可讨论的中间稿；没有证据的别补；不确定的单列。放在「PR 描述模板」里，这样更容易改。
我会把模板压到能扫一眼的程度，别让 reviewer 先读一篇小作文：
背景: "为什么改"
改动: ["文件范围", "关键行为"]
测试: ["npm test", "手动复核点"]
风险: ["回滚方式", "未覆盖项"]
助手不要包办
工具分工不用漂亮，但要说得过去。围绕「PR 描述模板」，我宁愿每个工具只做一件小事。Claude 更适合读长上下文、审查方案和整理迁移风险。它不是来替你点“通过”的，是帮你把遗漏摊出来。Cursor 适合项目级阅读和跨文件修改。前提是文件范围、验收条件和测试命令先写清楚。GitHub Copilot 适合贴着编辑器补函数、样板代码和测试片段。它适合小步补，不适合替你定方案。这样看起来慢一点，可交接时会少很多含糊话。
我不太相信一次就能把「PR 描述模板」设计完整。先让工具做中间版本，人来删、改、确认，再把有效部分留下。
测试是最后一句话
复核「PR 描述模板」时，我不会只看它顺不顺。我要看 diff、测试、命名、复用和无关文件改动。有一项说不清，就先别把它当成完成。
还有个容易忽略的小坑：别在文章里写死 Claude、Cursor、GitHub Copilot 的实时价格、套餐额度或地区可用性。这些东西变得太快。写清它们在「PR 描述模板」里的位置，就够了。
可以先拿「PR 描述模板」里的一个小改动试。限制文件范围，写清验收命令，改完马上跑测试。它如果连小 diff 都解释不清，就别让它继续扩大范围。
我还会在 PR 描述模板 旁边写一行：别让 AI 帮你省掉读代码的时间。它可以少写样板，可以提醒遗漏，但项目里的旧约定、测试习惯和命名方式，还是要自己看一遍。看过之后再让它动手，结果会稳很多。
到这里就可以先停。不是说「PR 描述模板」已经完美，而是它有了一条能被看见、能被改、也能被别人接住的小路径。
