超越提示-响应循环：基于 LLM 的编程新范式

AI 编程中的“刹车”挑战

传统的 LLM 编程工作流以重复的提示-响应循环为特征，这经常会中断开发者的心流状态。这种“停止-等待-审查-提示”的循环会产生认知摩擦，使开发者更像是一个手动编排者而非创造者，导致每隔几分钟就会有一种突然“刹车”的感觉。

为了消除对手动干预的持续需求，开发者正在构建“harnesses”（框架）——即围绕 LLM 的封装层，能够自主处理代码的记账、执行和验证。

某些开发者正在实现“workboxes”，即在沙盒（例如使用 e2b）中为每个功能创建隔离的工作树。这种方法允许开发者输入一个提示，自动创建分支和 PR，并启动一个编程会话，最终生成一个用于手动测试的公开 HTTPS 端点。这使开发者的角色从逐行编写代码转变为进行高层级的审批和迭代提示。

高级配置涉及在带有独立电子邮件和账户的 macOS VMs 中运行 LLM。在这些配置中，任务通过 Linear 等项目管理工具分配；AI 实现任务并提交 PR 进行审查。这使得人类开发者能够专注于故事编写和代码审查，而不是紧跟 AI 的每一个动作。

人们越来越达成共识：AI 生成代码的质量更多地取决于规格说明（specification）的精度，而非模型本身的能力。

开发者正在采用一种称为“grilling”或“wayfinding”的过程，即在编写任何代码之前，利用 LLM 严谨地挑战规格说明，以提取问题并消除意图歧义。一个理想的规格说明被定义为具有：

新的工具正在涌现，它们将规格说明作为主要接口。一些开发者使用 Kanban 风格的 CLI 工具，工作在工单描述和生成的计划中进行，然后由智能体实现。其他人则使用简单的 tasks.md 文件来分组实现步骤，从而允许他们为项目的不干扰部分启动多个并行的聊天会话，以保持动力。

除了完全的自主性，开发者还在尝试不同的方式与 LLM 交互，以更好地符合人类的认知模式。

一种实验性方法放弃了完全的自主性，转而采用结对编程伙伴模型。该系统利用不同的“driver”（驾驶员）和“navigator”（领航员）模式，允许开发者在编写代码和指导 AI 之间快速切换，模拟传统的真人结对编程动态。

一些开发者通过有意限制 AI 的使用来维持其心流状态。这包括使用空白编辑器进行初始实现以保持“编程的乐趣”，并且仅在处理特定细节或卡壳时调用 LLM。其他人则将用于低级辅助的自动补全工具（如 GitHub Copilot）与用于高层级架构变更的独立提示工具结合使用。

经验丰富的用户正在识别特定的技术杠杆来提高 LLM 在编程中的性能：

技能胜过智能体 (Skills over Agents): 有一种观点认为“技能”（关于如何与专有系统或自定义程序进行交互的具体指令）比智能体更强大。虽然智能体可以保留上下文，但技能可以增加实际能力。
上下文管理 (Context Management): 一些开发者避免使用长期记忆或钩子，以防止“上下文腐烂”，而是倾向于创建 markdown 文件作为记忆，模型仅在需要时才通过 grep 进行检索（渐进式披露）。
受限环境 (Constrained Environments): 正在进行“on-rails”开发的实验，即限制 LLM 使用非常固定的库、数据库和架构，以确保输出更具可控性且生成速度更快。