AI 编程助手在今年已成为改变游戏规则的存在，但要高效驾驭它们，仍需深厚的技能与结构化的方法。 这些工具极大地拓展了 LLM 在真实编程场景中的边界，包括我在内的许多开发者都已全面拥抱这一变革。
在 Anthropic，工程师们对 Claude Code 的依赖程度极高，以至于目前 Claude Code 约 90% 的代码都是由它自己编写的。然而，利用 LLM 编程并非“一键式”的魔法体验——它往往显得“困难且反直觉”，想要获得卓越的结果，必须学习新的模式。批判性思维依然是核心。经过一年的项目实践，我总结出了一套与许多资深开发者不谋而合的工作流：将 LLM 视为一个强大的结对程序员，它需要清晰的指令、充足的上下文和严密的监督，而非让其进行自主决策。
在本文中，我将分享2026 年，我如何利用 AI 进行规划、编码与协作，并提炼出我个人及社区集体学习中的最佳实践。这是一种更严谨的**“AI 辅助工程（AI-assisted engineering）”**方法——在积极利用 AI 的同时，始终对产出的软件质量保持高度的责任感。
不要只是向 LLM 抛出愿望——先定义问题，再规划方案。
一个常见的误区是带着模糊的提示词（Prompt）直接进入代码生成阶段。在我的工作流中，第一步是与 AI 共同头脑风暴出一份详细的技术规格说明（Specification），然后在编写任何实际代码之前，勾勒出分步实施计划。
对于一个新项目，我会先描述构思，并要求 LLM 反复向我提问，直到我们理清了所有需求和边缘情况。最后，我们将这些内容汇编成一份详尽的 spec.md 文件，其中包含功能需求、架构决策、数据模型，甚至测试策略。这份规格说明是后续开发的基石。
接下来，我会将这份规格说明输入给具备推理能力的模型，并提示它生成项目计划：将实现过程拆解为逻辑清晰、粒度适中的任务或里程碑。AI 实际上是在帮我完成一份微型的“设计文档”或项目计划。我会不断迭代这个计划——进行编辑，并要求 AI 对其进行评判或完善——直到它逻辑自洽且完整。
只有在此时，我才会开始编码。 这种前期投入看似缓慢，但回报巨大。正如 Les Orchard 所言，这就像是**“15 分钟内的瀑布流开发”**——一个快速且结构化的规划阶段，能让后续的编码过程变得异常顺滑。
拥有清晰的规格说明和计划，意味着当我们开启代码生成时，人类和 LLM 都明确知道我们要构建什么以及为什么要这么构建。简而言之，规划先行能强制你与 AI 达成共识，避免无效的迭代。这是许多人倾向于跳过的步骤，但经验丰富的 LLM 开发者现在都将其视为工作流的灵魂。
