问 HN：有人在尝试用不同方式将 LLM 用于编程吗？

基于规格说明 vs. 代理式/编排式编程

• 许多人认为最大的提升来自更清晰的规格说明，而不是复杂的编排：单一意图、明确的 I/O 契约、约束和前置条件，以及渐进式澄清。
• 一些人偏好“清空重来”的使用方式：尽量少用或不用长期记忆，以避免“上下文腐烂”和意图稀释；改用外部 Markdown/文档，让模型可以 grep。
• “技能”（狭窄、可复用的指令和工具）被认为被低估了；“代理”主要有助于上下文管理和约束。
• 另一些人报告称，多代理团队、基于图的工作流，以及固定角色的模型（机械层面用便宜模型，规划/审查用强模型）取得了成功，但也承认 token 成本和复杂度很高。

流状态与人的体验

• 常见抱怨：类似聊天的提示与等待会打断流状态；用户感觉自己像在监督一个初级开发者的经理，而不是在写代码。
• 一些人通过以下方式重新找回流状态：
  • 先做深入的规划/规格工作，然后让代理无人值守地运行，之后再审查。
  • 使用类似结对程序员的工具，由人类主导，AI 以小步增量辅助。
  • 并行运行多个任务/代理，把“编排”本身当作流状态活动。
• 另一些人觉得在很多代理之间来回切换很耗神，并不会带来流状态。

实用工作流与支架

• 常见模式：
  • 以 issue/PR 为中心的工作流，让 LLM 实现任务、生成计划，并通过评论反复迭代。
  • 在生成代码之前先写三层文档（哲学 → 规格 → 设计）。
  • 每个功能都有各自的“workbox”/沙箱，配合自动化分支、PR 和可部署的测试实例。
  • 具备隔离性的代理：从同一份规格分别生成代码和测试，以避免确认偏差。
• 自定义支架覆盖终端、基于浏览器的沙箱、DAG/图引擎，以及本地 VM/容器，通常带有严格的权限和工具（例如漏洞猎杀循环、安全沙箱）。

自动补全、结对协作与编辑器集成

• 对编辑器中心化的流程兴趣很高：行内自动补全、编辑完成、针对代码区域的多个锚定对话，以及代理在并行窗格中工作的终端。
• 一些人认为自动补全的支架和 UX 比挤出稍微更好的模型更重要。

学习、质量与安全

• 有人担心完全代理式编程会损害理解和学习，尤其对初级开发者；替代方案包括让 LLM 产出详细的教学文档，或作为导师/审阅者。
• 许多人强调要用 LLM 增强人类理解（图示、摘要、解释），因为人类对代码的理解现在成了瓶颈。
• 安全与护栏是反复出现的主题：沙箱化代理、受限工具，以及每次迭代之间的自动检查/测试。