Daily Productive Sharing 1362 - Addy Osmani's LLM Coding Workflow
One helpful tip per day:)
Addy Osmani 分享了他这一年多的 AI coding 实践，有很好的借鉴意义：
- 然而，将大语言模型（LLM）用于编程并不是按个按钮就能搞定的魔法体验——它“困难且不直观”，想要得到优秀结果需要学习新的工作模式。
- 应该把 LLM 当作一个能力很强的初级结对程序员：它需要指导、上下文和监督。
- 在我的工作流中，以及在很多人的实践里，第一步是和 AI 一起头脑风暴出一份详细的规格说明，然后在写任何实际代码之前，先列出一个逐步执行的计划。
- 对于一个新项目，我会先描述想法，并让 LLM 反复向我提问，直到我们把需求和边界情况都梳理清楚。
- 最终，我们会把这些内容整理成一份完整的 spec.md，其中包含需求、架构决策、数据模型，甚至测试策略。
- 接着，我把这份规格说明交给一个具备推理能力的模型，并提示它生成项目计划：将实现拆分为逻辑清晰、可消化的小任务或里程碑。
- 我通常会对这个计划反复迭代——修改它、让 AI 进行批评或优化——直到它连贯且完整。只有到这一步，我才开始写代码。
- 这是一个很多人容易跳过的步骤，但有经验的 LLM 开发者现在都把扎实的规格说明和计划视为整个工作流的基石。
- 相比之下，我们会把项目拆分为一系列迭代步骤或工单，并一次只解决一个。
- 解决问题的关键在于：停下来，往回退一步，把问题拆分成更小的部分。
- 我经常会生成一个结构化的 “prompt plan” 文件，里面包含针对每个任务的一系列提示词，这样像 Cursor 这样的工具就可以按顺序逐条执行。
- 核心要点是避免跨度过大的跳跃。通过小循环反复迭代，我们能大幅降低灾难性错误的概率，并且可以快速修正方向。
- LLM 的效果只取决于你提供的上下文质量——要把相关的代码、文档和约束直接展示给它。
- 在处理一个代码库时，我会确保向 AI 提供它表现良好所需的全部信息。
- LLM 是字面主义者——它们会严格执行指令，所以要给出详尽、具备上下文的指示。
- 通过主动提供上下文和指导，我们可以最大限度地减少幻觉和跑偏的建议，得到真正符合项目需求的代码。
- 当我使用 Claude 或 Copilot 这样的智能体来实现功能时，通常会把前面步骤中的计划或待办清单一并提供给它，让它清楚确切的执行顺序。
- 与其放任自动化，我更倾向于一种受监督的使用方式：我会让它生成甚至运行代码，但会密切关注每一步，一旦发现不对劲就立即介入。
- 我也尝试过这种“大规模并行”的方法；它在快速推进大量工作方面确实很有效，但同时也非常消耗心力，需要同时监控多个 AI 线程。
- 在大多数情况下，我只会同时使用一个主智能体，最多再加一个用于审查（后文会提到）。
