---
title: "AI 编程提效，谁来判断该做页面还是做模板 | 行开心的颠倒世界"
description: "AI 编程能把单个活动页写得很快，却可能推迟“改做模板”的判断。以淘宝活动页从手写到模板化为例，讲清怎样让 AI 识别共性、算清总成本，再用新需求验证方案。"
canonical: "https://xingkaixin.me/posts/ai-engineering-total-cost/"
language: "zh-CN"
---

# AI 编程提效，谁来判断该做页面还是做模板

AI 编程能把单个活动页写得很快，却可能推迟“改做模板”的判断。以淘宝活动页从手写到模板化为例，讲清怎样让 AI 识别共性、算清总成本，再用新需求验证方案。

2026年10月19日·1,320 字·4 分钟

[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[软件工程](https://xingkaixin.me/tags/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/)[Agent](https://xingkaixin.me/tags/Agent/)

![AI 编程提效，谁来判断该做页面还是做模板](https://xingkaixin.me/cover/ai-engineering-total-cost.webp)

前几天看到一张讨论截图。作者回忆淘宝早期的大促活动页：最开始全靠前端手写，一次双十一做到头，也就上百个页面。后来改成模板搭建，页面交给运营配置，数量到了万级；再后来按商品和类目规则自动生成，过了十万。

这组数字我没能找到原帖核实，只能当作者的回忆来读。让我停下来的，是中间那次转折：需求成批涌来时，团队没有继续加人逐页写，而是先停下来做了一套模板系统。

如果同样的需求交给今天的 AI，它默认会沿着原路径逐页生成代码。原来一天写一个页面，现在十几分钟一个。但 100 个页面还是 100 份独立的代码，后面还有 100 次联调、100 次修改、100 次线上排错。

单次生成变便宜，还会推迟这次转折。全靠手写的时候，做到第 5 个页面，工程师已经烦得受不了，会主动去想模板化。有了 AI，再生成一页几乎没有阻力，很容易一路堆出几十个页面，等到要改一处公共样式时，才发现要改几十遍。

![同一处页面修改，需要在多份独立活动页中重复完成](https://xingkaixin.me/posts/images/ai-engineering-total-cost/ai-engineering-total-cost-01.webp)

模板改变的是后续任务本身。在模板覆盖的范围里，新增页面成了运营的配置工作。工程师先花时间处理共性，后面大量重复实现就不再进研发流程。

**能把页面写快，与能判断此时该做一套模板系统，是两种不同的能力。**

AI 帮忙查资料、整理需求、写技术方案，这些环节变快了，团队照样可能在老路上重复。要问的是：面对一批看似独立的任务，AI 能不能发现其中可以收敛的共性，提出更合适的做法，并算清楚换做法是否划算。

在对话框里打出“建议做模板化系统”，不算具备这种能力。

模板收敛哪些共性、放开哪些差异，要到真实业务里找边界。有些页面只换商品和文案，有些连交互和布局都不一样。如果把所有差异都做成配置项，配置后台本身会变得难用，成了另一份维护负担。

投入时机也要算。几次临时促销，手写或让 AI 逐页生成更划算；需求高频出现、核心逻辑足够稳定，共用模板才站得住。模板系统有研发和维护成本，还要长期处理各种例外。

这些取舍做错了，AI 只会更快地交付一套没人愿意用的平台。代码多了，生产方式没变，团队还多了一份长期要还的架构债。

如果是人拍板决定做模板，再让 AI 写代码，那只说明 AI 降低了重构的执行门槛，判断还是人做的。只有 AI 面对没整理过的原始需求，能自己识别共性、给出合适的边界，落地后确实减少了重复工作，才能说它参与了这个判断。

想让 Agent 参与这个判断，先得改变交代任务的方式。“照这个样式，再做一页”和“这些反复出现的页面需求，怎样完成更合适”，留给它的判断空间完全不同。前一句只让它执行，后一句才让它参与方案权衡。

放开判断，就要给足依据。已有页面、最近几次修改记录、未来需求大概多久出现一次、日常维护的人懂不懂技术，都要放进上下文。缺了这些，它不知道重复会持续多久，也不知道运营能不能自己配，只能凭不完整的信息选方案。

然后让它比较三条路：继续逐页生成、抽几个公共组件复用、搭一套完整的模板系统。每条路的建设成本、后续能省掉的重复工作，都要按整个生命周期算：模板省下的编码时间，要覆盖系统建设、旧页面迁移和长期维护。一个共享组件能解决的问题，就不要扩成平台。

方案没验证之前，不让它把整套系统做全。先挑一组有代表性的页面，故意混进几个差异很大的，用最小可运行的版本检验共性抽得准不准。

再拿一批没参与设计的新需求来试：新增页面还要不要频繁改底层代码？运营能不能自己走完配置？遇到适配不了的例外，能不能干净地退回手工定制，而不是继续加配置项？这些结果，比方案文档里写的“高内聚、易扩展”可信。

![用新的页面需求检查模板边界，保留无法适配的例外](https://xingkaixin.me/posts/images/ai-engineering-total-cost/ai-engineering-total-cost-02.webp)

下一次面对成批的重复需求，我会先让 AI 回答三个问题：哪些工作值得收敛，依据是什么，出现什么情况说明做模板不划算。然后拿几条真实需求去试它的方案，再决定是继续逐页交付，还是花时间做模板。

## 版权声明

作者

XingKaiXin

标题

AI 编程提效，谁来判断该做页面还是做模板

发布时间

2026年10月19日

文章链接

[https://xingkaixin.me/posts/ai-engineering-total-cost/](https://xingkaixin.me/posts/ai-engineering-total-cost/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

XingKaiXin