prompt 技巧
n5321 | 2026年1月29日 23:28
反客为主！ 所以不如让LLM教你怎么prompt！比如以下principles：
最开始是：
vibe coding build app的时候很烦的一个点是到了后面，他就开始有点脱缰，失去方向感！
他生成一个前端，总体上还不错，但是有更改和升级的空间，提了要求以后，有些事错误的方向，你要求他restore，但是过了一两次之后，他有冒出来。简直神烦！
按google 内部人的台词是进一步，退两步！他給了个图。
用他的原话是：
• You try to fix a small bug.
• The AI suggests a change that seems reasonable.
• This fix breaks something else.
• You ask AI to fix the new issue.
• This creates two more problems.
• Rinse and repeat.
建立“上下文检查点”（Checkpointing）控制这个就是一个很有价值的技巧！
由于对话历史很长，模型偶尔会遗忘你中间手动改动的细节。专业意见： 每隔 5-10 轮对话，要求它做一个总结。“请总结我们目前代码的核心架构，以及你理解的我做过的手动微调。”价值： 如果它总结错了，你立刻纠正；如果总结对了，这个总结会成为新的强化记忆点。
另外要给版本的问题是你写了一个很眼睛的prompt file！把方方面面的要求都包括进去了，希望他思考10分钟，然后开始生成代码。但是选错了快速轻便的model，10秒中以后他就給了你一个极其简单完全不合要求的prototype，选择一个更高端的model，并且更改temperature就很有意义了！
在 AI Studio 或一些 IDE 插件里会有 Temperature：
想让它严谨（遵循你的代码）： 0.1 - 0.3 它会更像“死板但可靠的工程师”
想让它创新（寻找 bug 或重构）： 0.7 - 0.9 它会更像“架构师/创意顾问”
专业建议：
写生产代码：低温
找思路/找 bug：高温
做方案对比：中温 0.4 - 0.6
1. 建立“任务边界”（Scope Locking）
由于大模型的默认倾向是“帮你多做一点”，它会自然地扩展需求、顺手重构、甚至改动你没授权的文件。
专业意见： 每次提问前，用一句话明确本轮“只做什么、不做什么”。
“本轮只修复登录失败，不要改数据库结构，不要重构代码。”
价值： 你会明显发现 AI 的输出变得更像“可靠工程师”，而不是“创意写手”。
推荐模板：
本轮目标：{一句话}
只做：{A,B,C}
不做：{X,Y,Z}
输出格式：{diff / code / json}
2. 采用“两段式输出”（Plan → Execute）
很多 AI 输出看似正确，但落地时经常踩坑：漏文件、改错层、忘记兼容、测试没覆盖。
专业意见： 强制它先给 PLAN，再给 EXECUTE。
“先输出计划：修改哪些文件、步骤、风险点；确认后再输出代码。”
价值： 你会获得一个“可审计”的改动过程，尤其适合多人协作或长期项目。
推荐模板：
PLAN（步骤 + 文件清单 + 风险 + 回滚）
EXECUTE（代码/patch）
3. 使用“补丁交付”（Patch Mode）
AI 最常见的危险行为之一：直接输出整文件，导致你无法判断它改了哪里、为什么改。
专业意见： 要求它只用 diff / patch 输出。
“只输出 unified diff，不要输出整文件。”
价值： 你可以像 code review 一样审查 AI 修改，安全感大幅提升。
4. 建立“假设清单”（Assumption Dump）
大模型非常擅长“合理脑补”。它会把不确定的信息当成事实，然后推导出一整套错误结论。
专业意见： 每次需求或架构问题，让它先列出假设。
“在回答前，请列出你依赖的关键假设（如框架版本、数据库类型、部署方式）。”
价值： 你能快速发现 AI 的理解偏差，避免它在错误前提下写出一堆代码。
5. 强制“边界条件枚举”（Edge-case Enumeration）
AI 会倾向于覆盖“正常用户”，但真实系统经常死在边界条件：空值、超长文本、NaN、权限缺失、并发冲突。
专业意见： 让它在每个方案里附带 edge cases。
“请列出至少 8 个边界条件，并说明你将如何处理。”
价值： 这是把 AI 输出从“demo水平”提升到“生产级”的关键动作。
6. 引入“验收标准”（Acceptance Criteria）
AI 生成的功能常常“看起来完成了”，但你无法客观判断它到底有没有满足需求。
专业意见： 用 Given/When/Then 来定义验收标准（像写 user story）。
“请为这个功能写验收标准，包含权限、错误提示、日志要求。”
价值： 你等于给 AI 装上了“质量边界”，它会更少输出伪完成。
7. 建立“上下文唯一事实源”（Single Source of Truth）
对话越长，模型越容易“记忆漂移”：它会把早期版本当成最新状态，或者忘记你中间手动改过的关键逻辑。
专业意见： 每轮把关键事实放在一个 SYNC 块里，并声明它是唯一事实。
“以下 SYNC 内容为唯一事实源，任何冲突以此为准。”
价值： 这相当于给模型提供“最新版本的项目说明书”。
8. 引入“停线规则”（Stop-the-line）
有些操作属于高风险区：比如改 migrations、改鉴权、改租户隔离逻辑、删字段。
专业意见： 提前规定：遇到这些情况必须先停下来问你。
“涉及 DB schema / auth / 权限 / 迁移，必须先征得确认。”
价值：
