构建要宽泛，发布要精简
Build Wide, Ship Narrow
传统工程流程要求我们在动笔前先规划好所有边界，但这往往让我们在信息最少时做出最关键的决策。随着AI让代码生成和分支拆解变得极其廉价，我改变了策略：先设计，然后在一个分支上“宽泛构建”，直到功能完整并经过演示验证，最后再将其拆解为多个“精简”的PR进行发布。这种方法将构建时的探索自由与发布时的审查严谨分离开来，既利用了AI的效率，又保留了人工审查对架构判断的核心价值。
在动手构建之前，你是在猜测：哪些部分是可分离的，每个部分的复杂度如何，第三步是否会迫使你重新思考第一步。
HN 评论区
30- smashed
这有点难理解。所以我的理解是，这个理念是在没有限制的情况下快速迭代，也就是“快速行动，打破常规”（构建要宽泛）。
展示工作成果，持续调整。别担心改动量，也别在意提交记录是否漂亮。你可以自由探索，按需产生尽可能多的改动。
然后用 AI 代理来清理历史，生成一套整洁的变更集，以便用更传统的方式发布，即小而干净的提交。
这确实是个有趣的想法。AI 代理不仅能生成大量代码，还能用来清理 Git 历史记录。
不过，我觉得重度 LLM 用户其实并不太在意整洁的 Git 历史或变更集？也许只有当项目或现有工作流强制要求时，你才会多做这些步骤，但我真没怎么见过有人这么做。
你真的会去审查这些细小的变更吗？到目前为止，我看到的代理生成的例子都很糟糕。到处都是无关紧要的随意改动。大多是无害或可接受的，但不够聚焦。
- moezd
最近看到很多人引用 Pascal 的话，比如“抱歉，我没时间把它写得更短”。
在代码库中制造大量改动从来都不值得炫耀。代码行数（LoC）一直是个糟糕的进度衡量标准，然而现代框架、流行工具和杂乱无章的业务逻辑几乎都在强迫你尽可能多地写出代码。软件工程本不该如此啰嗦。
- bluegatty
有点让人困惑，但有一个类似的变体做法：创建大量实验性分支，但根本不合并它们。
AI 能从那些走到死胡同的分支中学习，这真的很神奇。
我觉得你没必要在真实产品上进行疯狂的迭代，只需在临时空间里做，然后“合并经验教训，而非代码”。
这种“前期设计”的理念从未奏效，因为它固化了太多错误的假设。
实验性工作能帮你理清这些问题。
一旦理清了，就把它们扔掉，然后让 AI 基于这些草稿工作来规划。
杂乱的部分就留在临时空间里，那本来就是它的用途。
最关键的是：这几乎零成本。
AI 的强大之处不在于“抠细节和修小 bug”，而在于它能释放海量的实验分支，在这些分支中它无需担心 PR 或代码审查。
一旦所有问题都理顺了，通往解决方案的路径实际上就相对清晰了——这时就可以“规划好”并直接执行。