提问模板优化建议
- 先把目标写死
- 例如：
只检查，不修改、最小修复、只基于提交内容总结 - 这样能减少 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. 风险总结
请只根据当前变更，总结可能的风险。 要求： - 分业务风险和技术风险 - 每条风险要具体 - 说明触发条件 - 不要只写“低风险”这种空话最适合你的使用习惯的额外建议
- 你可以在每个模板最后统一加一句：
如果信息不足，请先指出不足，不要自己补。- 如果是代码类任务，再加一句：
只改与本次问题直接相关的部分。- 如果是审查类任务，再加一句：
先给结论，再给证据。
