提问模板优化建议先把目标写死例如只检查不修改、最小修复、只基于提交内容总结这样能减少 AI 自作主张把“必须”和“可参考”分开必须遵循本项目文档、当前代码、指定接口可参考参考项目、历史会话、旧实现这能避免 AI 混用规则明确验收标准例如哪些文件可以改哪些不能改结果要输出什么格式需要不需要测试AI 更容易一次做对拆复杂任务不要一个问题里同时塞分析修复验证总结最好拆成 2 到 3 段质量通常更稳给出“错误边界”例如不要改无关逻辑不要引入新抽象不要假设接口字段不要编造不存在的风险这类限制对你尤其有效你最适合的 5 种 AI 提示词写法审查型只检查不修改。 从 [范围] 开始到现在审查 [模块/文件] 的新增和修改代码。 重点看缺陷、边界、异常、风险。 输出问题分级 证据 建议。最小修复型只修复这个问题保持最小改动。 不要重构不要动无关代码。 目标修掉 [具体问题]。 完成后请说明改了哪些文件以及为什么这样改。对齐型请以 [本项目文档/当前代码] 为准。 参考项目只用于辅助理解不得覆盖本项目规则。 如果两者不一致请明确指出差异并按本项目执行。总结型请只基于我提供的提交/代码内容总结。 不要补背景不要脑补风险。 输出按以下结构 1. 变更摘要 2. 详细改动 3. 测试关注点 4. 风险提示 5. 补充说明排查型请先分析原因再给方案。 要求 - 只看与问题直接相关的链路 - 标出关键调用点 - 说明根因和触发条件 - 给出最小可行修复1. 日常通用模板库A. 需求理解请先帮我梳理这个需求的真实目标、边界和风险。 要求 - 只基于我提供的内容不要脑补 - 如果有多种理解请列出来并说明差异 - 最后给出你认为最稳妥的执行路径B. 方案比选请给我 2-3 个可行方案按“实现成本 / 风险 / 维护性”对比。 要求 - 不要空泛建议 - 明确每个方案适合什么场景 - 最后给出你的推荐方案和理由C. 变更前确认我准备改 [模块/功能]请先帮我确认 - 会影响哪些链路 - 可能牵连哪些文件 - 最容易踩的坑是什么 - 有没有更小的改法D. 结果校验请帮我检查这次输出/改动有没有 - 逻辑漏洞 - 边界遗漏 - 和我要求不一致的地方 - 过度设计 如果有问题请直接指出不要客套。2. 代码审查专用模板A. 基础审查只检查代码禁止修改任何代码。 从 [commit/分支/时间点] 开始到现在审查 [文件/模块] 的新增和修改代码。 重点看 - 缺陷 - 异常处理 - 边界条件 - 兼容性 - 安全风险 输出要求 - 按严重程度排序 - 每个问题给出证据 - 说明为什么会出问题 - 给出最小修复建议B. 只看最新代码只以当前最新文件代码为基准审查不看历史实现。 请帮我找出当前版本里真实存在的问题不要参考已经被覆盖的旧逻辑。C. 对比审查请对比 [A 实现] 和 [B 实现]只找差异里可能引入的问题。 不要总结背景只输出 - 差异点 - 风险 - 可能的回归 - 建议D. 发版前审查请按发版前审查标准检查这次改动。 重点关注 - 会不会影响主流程 - 会不会影响线上数据 - 会不会导致兼容性问题 - 有没有隐藏的失败路径 输出请直接给结论不要长篇解释。3. 排查问题专用模板A. 定位根因请先帮我定位这个问题的根因。 已知现象是[现象] 触发条件是[条件] 相关代码是[文件/接口/页面] 要求 - 先分析调用链 - 再判断最可能的原因 - 标出你依据的代码位置 - 不要直接泛泛给修复建议B. 最小修复请只做最小修复目标是解决 [具体问题]。 要求 - 不要重构 - 不要改无关逻辑 - 不要顺手优化别的地方 - 修改后说明为什么这样改C. 线上问题排查这是一个线上现象请按排查思路帮我分析 - 现象[] - 发生范围[] - 复现条件[] - 日志/报错[] 请输出 1. 最可能原因 2. 次可能原因 3. 需要补充验证的信息 4. 最小修复方向D. 链路排查请沿着 [入口 - 中间步骤 - 结果] 这条链路排查问题。 要求 - 只看和这条链路直接相关的代码 - 把关键节点列出来 - 说明每个节点的输入/输出 - 找出最可能断掉的地方4. 总结汇报专用模板A. 提交总结请只基于我提供的提交/变更内容总结不要脑补。 输出按以下结构 1. 变更摘要 2. 详细改动 3. 测试关注点 4. 风险提示 5. 补充说明 要求 - 简洁 - 条目化 - 不超过 [字数] - 不要写空话B. 周报/日报请把这些提交整理成适合汇报的工作总结。 要求 - 按模块归类 - 强调实际改了什么 - 避免背景描述过多 - 语言简洁、专业、可直接发给别人C. 变更说明请帮我写一份变更说明重点说明 - 改了什么 - 为什么改 - 有什么影响 - 需要怎么验证 要求 - 面向开发和测试都能快速看懂 - 不要太长 - 不要泛泛而谈D. 风险总结请只根据当前变更总结可能的风险。 要求 - 分业务风险和技术风险 - 每条风险要具体 - 说明触发条件 - 不要只写“低风险”这种空话最适合你的使用习惯的额外建议你可以在每个模板最后统一加一句如果信息不足请先指出不足不要自己补。如果是代码类任务再加一句只改与本次问题直接相关的部分。如果是审查类任务再加一句先给结论再给证据。