两种用法，效果差一个量级
把大模型当答案机器：贴一句报错、抄回一段代码、能跑就提交。把大模型当结对伙伴：先讲清目标与约束，给出真实上下文，要求它说明思路，最后你来验证。前者短期省时间、长期埋雷；后者能把一次生成沉淀成可复用的经验。
四步流程
- 说清目标与约束：语言与版本、框架、不能改动的模块、性能或合规要求，先写清楚再提问；
- 提供真实上下文：完整报错、相关代码片段、数据结构或接口定义，而不是一句「帮我写个函数」；
- 要求方案与依据：先要「可能原因 + 验证步骤」，再要具体改动，能显著减少编造；
- 你来验证：跑测试、读 diff、检查边界条件。模型负责候选方案，判断权始终在你手里。
可直接复用的提示词模板
角色：熟悉 Node 20 与 PostgreSQL 的后端工程师
任务：定位下面查询变慢的原因，并给出 2 个可选方案
上下文：
- 表结构：orders(id, user_id, status, created_at)，约 800 万行
- 现有查询：SELECT ... WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20
- 现网现象：p95 从 40ms 涨到 900ms
约束：不新增中间件，不改表结构
输出：先用 3 行说明可能原因，再给方案，每个方案标注代价与回滚方式四个高频错误
- 只贴报错不贴代码：模型只能猜，给出的修改往往对不上真实结构；
- 让它一次性重写大文件：diff 巨大难以审阅，应拆成小步改动逐步验证；
- 不看 diff 直接提交：AI 生成的代码同样会有空指针、越界与并发问题；
- 把密钥与客户数据贴进对话框：除非明确是企业内部且允许外发的环境，否则一律脱敏后再问。
适合与不适合交给它的任务
| 任务 | 交给 AI | 注意 |
|---|---|---|
| 解释报错、定位可能原因 | 很合适 | 要求它一并给出验证步骤 |
| 写样板代码、正则、测试用例骨架 | 很合适 | 生成后必须实跑验证 |
| 方案对比与权衡 | 合适 | 让它列出代价、风险与回滚方式 |
| 涉及密钥、结算、权限的最终实现 | 谨慎 | 人工复核 + 测试覆盖，不直接上线 |
| 依赖最新信息的结论 | 不适合 | 以官方文档与实际验证为准 |
与本站工具的配合
让它输出结构化结果时，用 JSON 工具验证是否合法；需要确认生成文件与原文是否一致时，用哈希工具比对；讨论流程与架构时，先用白板把结论画出来，再落到代码。
动手试试：JSON 格式化与校验、哈希计算、白板绘图
把协作拆成可重复的循环
- 先由人写清任务边界：把要改动的位置、允许的改动范围与验收标准先写下来，再让助手参与。边界模糊时生成结果往往超出预期，评审成本反而更高。
- 小步提交：每完成一小块就让助手停下并由你验证，不要一次性生成几百行再统一检查。小步提交让问题在最初几行就被发现。
- 让助手先解释再实现：要求它先说明打算怎么改、会影响哪些调用方，你确认思路后再写代码。这一步能拦掉大量方向性错误。
- 把验证外包给工具：格式检查、类型检查与测试交给自动化流水线，人只关注行为正确性与设计合理性，避免把注意力浪费在可机器判断的问题上。
- 定期复盘提示方式：把效果好的提示与上下文组织方式记录下来并复用，让协作效率随时间提升，而不是每次从零开始。
归根结底，助手擅长的是快速给出候选方案，人擅长的是判断方案是否合适。把这两件事分开，协作效率才会真正提高。