内容概览
这场访谈追问一个核心问题：当 AI 能持续生成海量代码时，工程团队应该追求最大产量，还是长期可控的软件质量？Dex 将 RAG、记忆、代理历史等概念还原为上下文工程——有意识地选择、排序和压缩输入模型的令牌，以突破应用的质量上限。他进一步区分上下文窗口的“聪明区”与“愚笨区”，主张通过频繁、主动的压缩，让复杂任务在较短的新会话中继续。对于循环工程，他认可测试、静态检查和 CI 所形成的自动反馈，却反对让代理无限扩张代码规模、完全取代人工审查；其团队曾运行无人值守的软件工厂，数月后因代码难以理解和修改而关闭。更稳妥的路径是采用小型慢循环，每次只修复少量问题并提交可审查的变更。访谈最终把“token harder”与“token smarter”对立起来：真正的杠杆不来自令牌利用率，而来自前置研究、设计检查点、纵向实施计划和人的架构判断，使团队在加速交付的同时维持可维护性。
更多内容
核心概念
访谈中用于理解 AI 编程系统的关键术语。
- 上下文工程：把 RAG、记忆、代理历史和结构化输出还原为令牌输入问题，并通过选择、排序、压缩和分配输入来提高模型输出质量。
- Harness engineering：围绕编码代理的集成点和运行环境进行优化，包括命令、MCP、技能、代码库组织与开发环境，以提高每轮执行的质量下限。
- 聪明区与愚笨区：上下文前部通常更可靠；随着信息、指令和历史不断累积，模型的注意与遵循能力可能下降，进入性能退化区域。
- 循环工程：用测试、编译、静态检查或性能指标等反馈机制，让代理反复尝试并验证自己的工作。
- 全黑软件工厂：从任务输入到代码生成、审查、部署和问题修复均由自动化系统处理，基本没有人工介入或代码阅读。
- 软件工厂：围绕工作来源、编码、测试、验证、集成、部署和用户反馈建立的系统化生产流程；AI 的变化主要是用代理替换或增强其中部分执行节点。
关键对照
不同 AI 工程策略在目标、控制方式和长期结果上的差异。
- Token harder 优化令牌和代理的利用率；token smarter 优化端到端交付价值、可维护性和人的判断杠杆。
- 全黑工厂能快速产生大量代码，但会失去系统理解；有人参与的代理工厂在研究、设计和审查节点保留控制，速度较低但更可持续。
- 巨型循环一次生成难以审查的大规模变更；慢循环每次只修复少量问题并提交小型 PR，可逐步扩大范围。
- 水平计划按数据库、服务、API、前端依次建设，往往到最后才能整体测试；纵向切片先建立可见、可验证的薄路径，再逐步接入真实数据和业务逻辑。
- 永久规格试图与代码长期同步，容易形成双重真相源；临时任务工件只服务于当前研究、设计和实施，代码继续充当长期事实依据。
实践经验
从实际建厂、编码代理使用和产品开发中提炼出的做法。
- 先用能力最强的模型验证问题是否能解决、用户是否需要，再在请求规模足够大时优化模型组合、成本和延迟。
- 长任务应把代码现状、产品意图和设计决定压缩成独立工件，并在新的上下文窗口中继续。
- 每次只建设一个小而封闭的自动循环，先验证它确实改善系统，再增加反馈机制或扩大处理范围。
- 在实施前投入人工设计与规划，可以缩小结果的不确定范围，减少 PR 阶段的大规模返工。
- 让代理按可独立验证的纵向切片实施，优于一次完成数据库、服务、API 和前端的整层改造。
- 经典的软件工程能力仍然重要，尤其是重构、接口设计、模块边界和长期可维护性判断。
风险与边界
扩大代理自主权时最容易被短期产出掩盖的问题。
- 停止阅读代码后，代理生成量可能很快超过团队重新理解系统的能力，并在三至六个月后暴露严重维护问题。
- 测试通过只能证明当前可观察行为，不能证明代码三个月后仍易于修改，也难以捕捉架构债。
- 过长上下文会混入冲突指令、错误推理和失败轨迹，使代理开始采取越来越极端的修复方式。
- 让规格与代码长期并存会形成两个真相源，任何一方变化都可能导致漂移和误导。
- 将支持工单、监控告警和产品需求直接接入无人审查的代理循环，会让错误以更高速度进入生产。
- 以令牌使用率、提交量或代理并发数作为主要目标，会局部优化工厂节点，却不一定增加稳定的用户价值。