最近重读了 Simon Willison 的《Here’s how I use LLMs to help me write code》，这篇文章很务实：不神化模型，也不妖魔化模型，而是给出一套可落地的编码协作方式。

我把核心内容做了提炼，并补上我自己的执行版清单。

1. 先把预期设对：LLM 是“高效率助手”，不是“自动交付器”

文章里最重要的一点是：

LLM 更像一个自信过头但速度极快的结对助手。

它会犯错，甚至会“非常不像人类地犯错”（比如幻觉不存在的 API）。 但只要你把它放在正确角色，它能大幅缩短实现时间。

我的做法是：

• 把 LLM 当“实现加速器”，不当“决策替代者”
• 架构、边界、验收标准仍由人类负责
• 关键路径必须人工验证

2. 上下文决定上限：Context is king

这篇文章反复强调上下文管理，这点我完全认同。

实践上我会这样做：

• 新任务前先喂最小必要上下文（相关文件、约束、样例）
• 对话发散后及时开新会话，避免上下文污染
• 先让模型做“简化版本”，跑通后再迭代复杂版本

一句话：不是 prompt 越长越好，而是上下文越精准越好。

3. 从“开放式提问”切到“指令式执行”

文章提到一个关键切换：

• 前期探索：让模型给选项（库、方案、权衡）
• 进入生产：像带实习生一样给明确指令

我现在常用模板是：

1. 先让它列 2~3 个方案 + 各自风险
2. 我选定方案后，给明确函数签名/接口契约
3. 让它补测试，再一起修到通过

这样比“请帮我实现 XXX”稳定很多。

4. 测试不能外包：你必须验证它写的代码

这篇文章最硬核的一句可以直接当团队规则：

你不能把“验证代码是否可用”外包给模型。

所以我的最低要求是：

• 单测必须跑
• 关键路径必须手测
• 失败日志必须回喂模型复盘

模型可以帮你快，但“可交付责任”永远在人类手里。

5. 让它反复改：第一次输出只是草稿

很多人觉得 LLM 不好用，本质是把第一版输出当最终版。

更高效的方式是：

• 明确指出不满意点（结构、命名、性能、可读性）
• 要求重构而不是重写
• 每轮只改一个维度，避免目标飘移

我自己的体感是：第二到第四轮通常才是可合并版本。

6. 实操清单（我在用的简版）

每次让 LLM 写代码前，我会按这个顺序走：

1. 写清目标与验收条件（可测试）
2. 提供最小上下文（相关代码/约束）
3. 先要方案，再选方案
4. 指令式生成实现 + 测试
5. 本地执行验证
6. 失败回喂，迭代修复
7. 人工审查后再提交

这套流程不花哨，但非常稳定。

结语

这篇文章的价值不在“某个神 prompt”，而在工程思路：

• 先把角色边界画清楚
• 再把上下文和验证闭环做扎实

LLM 不会自动让你变成更强工程师， 但一套好的协作流程，会把你原有的工程能力放大得非常明显。

原文参考：

• Simon Willison: https://simonwillison.net/2025/Mar/11/using-llms-for-code/