Appearance
6.8 场景 Playbook·代码与技术
写代码、调 bug、做技术方案——这是工程师用 AI 最高频的场景。这节给三类的提示模板和注意点。和 4.7 AI 编程工作流 互补：那节讲整体流程，这节抠提示词本身。
代码生成
模板：
你是{语言/框架}工程师。实现一个{功能}。
上下文：
- 技术栈：{React + TS / Node + Express ...}
- 复用已有：{src/utils/xxx 的某函数 / 某接口}
- 代码风格：{见下面范例}
要求：
- 输入：{数据结构}；输出：{数据结构}
- 加错误处理和类型；不要引入新依赖
- 只输出代码，不要解释
风格参考：
```{贴一小段你们现有代码}```注意点：
- 给足上下文：技术栈、要复用的现有函数/接口、约定——不给它就自己脑补一套（6.1 缩小范围）
- 贴一段现有代码当风格范例：比"按我们的规范"有效一百倍（6.3）
- 明确输入输出结构和边界
- 复杂功能先让它给方案再写（4.7 先计划后执行），别一口气生成一大坨
❌ "帮我写个登录功能" → 它脑补技术栈、风格、存储方式，多半不是你要的 ✅ 给技术栈 + 复用项 + 输入输出 + 风格范例
代码调试
模板：
下面的代码报错了，帮我定位并修复。
代码：
```{完整相关代码}```
完整报错：
```{原样贴报错栈，不要转述}```
复现步骤：{怎么触发的}
请：
1. 先解释为什么会报这个错（病因）
2. 再给最小改动的修复
3. 不要顺手改无关的地方注意点：
- 原样贴完整报错栈，别自己转述（"它说有个错误"）——具体报错是模型修对的关键（4.8 错误恢复）
- 让它先解释病因再改（CoT，6.3）：直接改容易治标不治本
- 要求最小改动：否则它常顺手"重构"一堆无关代码，引入新问题
- 给复现步骤和相关上下文，别只贴一行报错
技术方案 / 架构推理
模板：
我要解决{问题}。约束：{规模 / 团队技术栈 / 时间 / 已有系统}。
请：
1. 先说这类问题的通用思路/原则（先退一步）
2. 给 2-3 个可行方案，各列优缺点和适用场景
3. 结合我的约束，推荐一个并说明理由注意点：
- Step-back 很有用（6.3）：先让它讲一般原则，再落到你的场景，方案更有章法
- 给真实约束（规模、团队、遗留系统）：没有约束它只会给教科书答案
- 让它列权衡而不是只给一个"标准答案"——技术决策本就没有唯一解
- ⚠️ 方案里的具体数据/库特性可能有幻觉，关键处要自己核实（0.3）
用对模型
代码和技术推理任务，模型选择很影响效果（1.7）：
样板代码、简单补全、改格式 → 普通模型（快、便宜）
复杂算法、棘手 bug、架构权衡 → 推理模型（更准，值得多花）💡 用推理模型时，别再硬塞"请一步步思考"（它自带），直接把问题和约束说清楚即可。
🛠️ 实战练习：调试提示对比
找一个你最近遇到的真实 bug：
- A 版：只贴一行"它报错了 + 一小段代码"，让 AI 修
- B 版：按本节模板——完整报错栈 + 完整相关代码 + 复现步骤 + "先解释病因再最小改动"
- 对比两版：哪版定位准、改动干净、没顺手乱改
期望结果：你会清楚体会到"给完整报错 + 让它先解释病因 + 限制最小改动"这几条，对调试质量的巨大差别。
📌 关键结论
- 代码生成：给足上下文（技术栈/复用项/输入输出）+ 贴现有代码当风格范例 + 复杂的先方案后实现
- 代码调试：原样贴完整报错栈 + 让它先解释病因再改 + 限制最小改动、别乱重构
- 技术方案：step-back 先讲原则 + 给真实约束 + 让它列权衡，关键数据自己核实
- 简单代码用普通模型，复杂算法/调试/架构用推理模型（且别再硬塞 CoT）