转写说明

本文基于已校验的公开原文进行结构化转写与事实梳理，非原文转载。 转写保留可核验的技术事实，并将工程建议与来源观点明确分开。

核心结论

这套方法论最核心的洞察不是"怎么用AI写更多代码"，而是"怎么在AI产出大量代码之后还能保证质量"。这两件事的难度不在同一个量级。

Lauren Tan的实践数据是每月交付1000至2000个PR，但她在文中强调了一个关键判断：600多个重构PR才是真实的基础设施。那晚自动合并的20个PR，只是输出。这意味着大量前期投入用于建立让agent无法违规的架构边界，而非单纯追求代码生成速度。

业界交叉验证表明，AI代码review在代码风格、简单逻辑错误检测上与人类持平，但对架构问题的覆盖率仅约13%，且在长期可维护性方面的表现持续下降。多模型review可以辅助风格统一和明显错误检测，但不能替代人类的架构判断。

能力机制

这套系统的架构基础称为Dune，核心设计判断是"Agent喜欢走捷径，所以让最短路径就是正确路径"。具体实现包括：Feature共置（一个功能的状态、组件、逻辑放在同一目录）、清晰的进程边界、依赖图CI检查（机械阻止跨层跨进程import）、危险模式lint禁用（让错误模式编译报错而非规范提醒）。

验证是整个系统的基础设施。验证的定义是驱动真实应用、执行真实流程、检查真实产物、给出可视证据。不同类型变更对应不同验证方式：CLI变更跑真实命令、UI变更在运行应用里走流程、解析器变更重放已保存输入、性能变更前后对比profile数据。

pstack提供了一套工具集用于设计阶段：/how追踪系统当前行为并回答“这个系统现在是怎么工作的”；/why挖掘历史决策追溯设计理由；/arena让N个subagent并行尝试同一设计任务，由跨模型评审agent打分后合并优点；/interrogate把同一份diff发给不同模型家族的reviewer，分类为必须修/值得考虑/记录/驳回四类。

Indirect Prompt是最常用的技巧：不直接告诉agent要做什么，而是先让agent读相关材料用自己的话复述问题，把理解验证前置到成本最低的环节。

23条工程原则用于"steering"而非背诵。当发现agent在做不对的事时，用原则名称精准纠正而非重新解释。其中核心原则包括Laziness Protocol（优先删除，做最小变更）、Subtract Before You Add（先去掉死重）、Attack the Premise（修复失败时质疑共享前提）；架构原则包括Model the Domain（把业务规则编码进结构）、Boundary Discipline（在边界处验证）、Type System Discipline（让非法状态在类型层面不可表示）；验证原则包括Prove It Works（验证真实产物而非代理指标）、Fix Root Causes（先重现追溯根因）、Test Behavior Not Implementation（以用户调用方式测试）。

Overnight Run是整套系统的最终形态，前提是所有基础都已打好。关键不是信任而是结构化合约：提供完成条件而非时间限制、使用fresh worktree物理隔离、预设"不要问我"的权限、设置"如果卡住写清原因"的逃生舱。每次迭代的循环是检查完成条件、做最小合理变更、对真实产物验证、有进展则提交并记录一行决策日志、无进展则丢弃变更并换方向。

快速开始

当前就能落地的做法优先级最高的是机械约束，包括配置lint规则直接封掉危险模式、在CI中加入依赖图检查强制跨层检查、在目录结构层面做物理隔离、让类型系统承担更多验证工作。这些不需要AI技术，对AI和人类都有效。

建立Feature Map是验证技能的核心。结构是每个功能目录下放置文件，包含Launch（如何启动到该功能入口）、Drive（驱动该功能的命令或操作序列）、Evidence（什么结果证明功能正常）、Cleanup（验证后需要清理的状态）四个固定部分。这需要持续维护，pstack提供/maintain-verification-skill用于审计。

原子PR规范要求每个PR只做一件事，可以被独立验证和回滚。这是一切后续自动化的基础。

Indirect Prompt可以直接采用：遇到问题时先让agent读相关材料用自己的话复述，复述有偏差说明理解错误，在写代码之前纠正而非等代码完成后发现方向错误。

如果开始尝试Overnight Run，提供结构化合约模板应包含以下要素：明确完成条件（每次迭代可自动检查pass/fail的明确状态）、使用fresh worktree（物理隔离不与本地其他工作冲突）、预设对常见权限问题的回答、逃生舱（卡住时停下来写清原因而非继续消耗时间）。避免使用"工作N小时"作为完成条件，这给的是时间而非可验证状态。

适用边界

根据来源中的实证数据，以下场景当前不适合直接尝试：

让agent自主做架构决策的方案不可行。研究数据显示LLM对架构问题的漏检率高达87%，且长期可维护性覆盖率持续下降。架构决策需要深度理解业务上下文和演进方向，这部分必须由人负责。

完全无人值守的新功能开发存在风险。Feature Map会随代码演进腐化，当初定义的"功能正常的证据"可能不再准确。验证技能本身需要持续投入维护，不是一次性工作。

用多模型review替代人工架构评审不可取。AI review在风格统一和明显错误检测上有价值，但架构判断必须保留人工环节。

这套系统的三个前提条件不可少：负责人对架构和业务有极深理解、600多个重构PR建立的架构地基、把隐性工程判断显性化编码为agent可执行结构。缺少任何一个前提，系统效果会大打折扣。

核验清单

在引入这套方法前，应确认以下条件是否满足：

架构层是否已做足够的前期投入。如果没有600多个重构PR建立的清晰边界，agent的"最短路径"不会是"正确路径"，质量保证无从谈起。

是否愿意为验证技能分配持续资源。Feature Map会腐化，需要类似oncall轮值的持续维护投入，这是关键基础设施而非辅助工具。

团队是否有能力持续维护原则库。23条原则来自真实失败案例，需要随着代码库和业务演进不断更新新的问题模式和可能失效的旧原则。

是否准备好人在系统中承担架构判断和意图对齐的角色。AI生成代码速度已提升10倍，但人类做架构判断和意图对齐的速度没有同步提升。瓶颈已经从"写代码"转移到"定义问题和判断方向"。

来源与核验

  • 原始文章
  • 页面事实以原始来源及其引用的官方资料为准；版本、星标和模型能力会随时间变化。
  • AI Stack 不公开抓取到的全文快照，只发布独立转写与来源入口。

站内链接

相关文章