前几天看到一张讨论截图。作者回忆淘宝早期的大促活动页：最开始全靠前端手写，一次双十一做到头，也就上百个页面。后来改成模板搭建，页面交给运营配置，数量到了万级；再后来按商品和类目规则自动生成，过了十万。
这组数字我没能找到原帖核实，只能当作者的回忆来读。让我停下来的，是中间那次转折：需求成批涌来时，团队没有继续加人逐页写，而是先停下来做了一套模板系统。
如果同样的需求交给今天的 AI，它默认会沿着原路径逐页生成代码。原来一天写一个页面，现在十几分钟一个。但 100 个页面还是 100 份独立的代码，后面还有 100 次联调、100 次修改、100 次线上排错。
单次生成变便宜，还会推迟这次转折。全靠手写的时候，做到第 5 个页面，工程师已经烦得受不了，会主动去想模板化。有了 AI，再生成一页几乎没有阻力，很容易一路堆出几十个页面，等到要改一处公共样式时，才发现要改几十遍。
模板改变的是后续任务本身。在模板覆盖的范围里，新增页面成了运营的配置工作。工程师先花时间处理共性，后面大量重复实现就不再进研发流程。
能把页面写快，与能判断此时该做一套模板系统，是两种不同的能力。
AI 帮忙查资料、整理需求、写技术方案，这些环节变快了，团队照样可能在老路上重复。要问的是：面对一批看似独立的任务，AI 能不能发现其中可以收敛的共性，提出更合适的做法，并算清楚换做法是否划算。
在对话框里打出“建议做模板化系统”，不算具备这种能力。
模板收敛哪些共性、放开哪些差异，要到真实业务里找边界。有些页面只换商品和文案，有些连交互和布局都不一样。如果把所有差异都做成配置项，配置后台本身会变得难用，成了另一份维护负担。
投入时机也要算。几次临时促销，手写或让 AI 逐页生成更划算；需求高频出现、核心逻辑足够稳定，共用模板才站得住。模板系统有研发和维护成本，还要长期处理各种例外。
这些取舍做错了，AI 只会更快地交付一套没人愿意用的平台。代码多了，生产方式没变，团队还多了一份长期要还的架构债。
如果是人拍板决定做模板，再让 AI 写代码，那只说明 AI 降低了重构的执行门槛，判断还是人做的。只有 AI 面对没整理过的原始需求，能自己识别共性、给出合适的边界，落地后确实减少了重复工作，才能说它参与了这个判断。
想让 Agent 参与这个判断，先得改变交代任务的方式。“照这个样式，再做一页”和“这些反复出现的页面需求，怎样完成更合适”，留给它的判断空间完全不同。前一句只让它执行，后一句才让它参与方案权衡。
放开判断，就要给足依据。已有页面、最近几次修改记录、未来需求大概多久出现一次、日常维护的人懂不懂技术，都要放进上下文。缺了这些，它不知道重复会持续多久，也不知道运营能不能自己配，只能凭不完整的信息选方案。
然后让它比较三条路：继续逐页生成、抽几个公共组件复用、搭一套完整的模板系统。每条路的建设成本、后续能省掉的重复工作，都要按整个生命周期算：模板省下的编码时间，要覆盖系统建设、旧页面迁移和长期维护。一个共享组件能解决的问题，就不要扩成平台。
方案没验证之前，不让它把整套系统做全。先挑一组有代表性的页面，故意混进几个差异很大的，用最小可运行的版本检验共性抽得准不准。
再拿一批没参与设计的新需求来试：新增页面还要不要频繁改底层代码？运营能不能自己走完配置？遇到适配不了的例外，能不能干净地退回手工定制，而不是继续加配置项？这些结果，比方案文档里写的“高内聚、易扩展”可信。
下一次面对成批的重复需求，我会先让 AI 回答三个问题：哪些工作值得收敛，依据是什么，出现什么情况说明做模板不划算。然后拿几条真实需求去试它的方案，再决定是继续逐页交付，还是花时间做模板。