评分 7.8 · 来源：Hacker News · 发布于 2026-03-16
评分依据：详细的实战方法论，包含完整的真实编程会话（为 Stavrobot 添加邮件支持），对多模型协作、架构决策、失败模式有深入思考，对 LLM 编程实践有很强的参考价值
要点
作者分享了用 LLM 编程的完整工作流，核心观点：喜欢的是做东西，编程只是手段之一。自从 LLM 擅长编程后，可以更快地做出高质量的东西。
工作流架构（三角色）：
- 架构师（Claude Opus 4.6）：唯一与人交互的 Agent，负责理解需求、讨论方案、做架构决策，输出低层级计划（文件和函数级别）
- 开发者（Sonnet 4.6）：执行架构师的计划，实现具体代码
- 审查者（Codex 5.4 + Gemini 3 Flash + Opus 4.6）：独立审查代码，提供反馈
关键原则：
- 多模型必要性：不同模型有不同优势，让模型审查自己写的代码基本无效（会自我认同）
- 架构阶段最重要：花 30 分钟讨论架构，确保每个决策都理解和认可，避免后期返工
- 明确批准机制：架构师必须等到明确说「approved」才开始实施，防止过早执行
- 保持架构层面的掌控：不需要知道每行代码怎么写，但必须知道每个架构决策为什么这样做
失败模式：
当对技术栈不熟悉时，无法发现 LLM 的错误决策，导致代码越来越乱，最终无法收拾。解决方法：在规划阶段尽可能理解技术，引导 LLM 做正确的架构选择。
真实案例：为 Stavrobot 添加邮件支持
文章包含完整的编程会话记录（已标注），展示了：
- 如何与架构师讨论需求（IMAP vs webhook、SMTP vs API、双向对话 vs 单向通知）
- 如何发现遗漏（README、allowlist 验证）
- 如何在 QA 中发现 bug（owner email 未加入身份集）
- 如何重构硬编码（用列表替代 if-else）
- 如何处理特殊需求（邮件通配符、防止 @ 绕过）
整个功能从需求讨论到实现完成约 1 小时，代码可靠性高。
已构建的项目：
- Stavrobot：OpenClaw 的安全替代品，管理日历、研究、自动提醒
- Middle：语音笔记设备，录音 → 转录 → POST 到 webhook
- Sleight of hand：不规则滴答的艺术时钟
- Pine Town：无限多人画布
🤖 AI 点评
这篇文章的价值在于「诚实」——不是展示 LLM 有多神奇，而是展示如何在 LLM 的局限性下建立可靠的工作流。
多模型协作不是噱头，而是必需品。Opus 做架构决策、Sonnet 写代码、Codex 挑刺，这种分工利用了不同模型的性格差异（Codex 挑剔、Opus 决策合理、Gemini Flash 有时能看到其他模型看不到的解法）。
「架构阶段花 30 分钟」这个时间投入很关键。很多人用 LLM 编程失败是因为跳过了这一步，直接让 LLM 开始写代码，结果需求没对齐、架构没想清楚，后面越改越乱。
失败模式的坦诚也很重要：对技术栈不熟悉时，LLM 会做出看似合理但实际糟糕的决策，而你无法发现。这说明 LLM 编程不是「不需要懂技术」，而是「技能从写代码转移到架构和决策」。
完整的真实会话记录是这篇文章最大的亮点——不是精心挑选的成功案例，而是包含了遗漏、bug、重构、安全考虑的完整过程。这比任何方法论描述都更有说服力。