这周最有启发的变化，是一些“值得不值得自己做”的边界正在移动。过去为少数业务人员开发一页定制报表，很容易被排进没有尽头的需求队列；现在生成界面的成本下降，需求本身可以成为开发的起点。David Lequin 团队的经历为这种变化提供了实例：他们保留数据仓库、约两千个 dbt 数据模型和身份认证，把更自由的布局放到这些设施上。用户增长表明定制页面有吸引力，至于数字是否更可靠、总费用是否更低，还需要另外的记录。
10 月 18 日至 21 日的成本观察强调：省下调用费以后，仍要按最终完成的任务比较。24 日的 BI 案例已经把已有基础设施纳入判断。本周把 TorchTPU 的优化过程一起读，进一步看到复用具有不同层次：既可以复用权限和数据定义，也可以复用模型接口，再重写执行方式。这里应该修正的是评价起点。不能只在产物出现后追问“有没有隐形成本”，还应在开始前判断哪些已有工作使这次定制成为可能。
BI 案例中，页面通过查看者身份查询数据，沿用原有权限；但团队仍要隔离生成页面的脚本、约束通信与令牌，并由人确认发布。权限回答谁能读取数据，沙箱约束代码能做什么，指标定义则回答收入或活跃用户究竟怎样计算。三者分属不同问题。评论者 alexkbuilds 曾做过类似系统，他最难解决的是让每个人都看见正确数字，同时也认可用户能自由描述自己要的页面。保留这两个判断，才能说明定制能力的价值和它实际需要的基础。
TorchTPU 的例子让“复用”更不容易被误读成零改动。熟悉的 PyTorch 定义保留下来，计算与通信却需要重新组织。把通信放进可编译的图，才能安排重叠；融合损失计算先节省显存，扩批后才转为吞吐。这条因果链说明，性能有时来自重新划分共同执行的工作，而不是某一个算子突然更快。已有接口降低了尝试门槛，专门的执行设计决定能取得多少收益。
Flint-interactive 提供了第三个可以借用的边界：让作者描述选中了哪些数据、哪些图需要更新，再把事件到状态变化的重复逻辑交给共享算子。布局仍可各不相同，同一国家在多张图中的对应关系却不必每页重新实现。它尚未证明总体维护成本降低，但提出了一个有用的问题：用户需要改变的部分，和团队反复调试的部分，能否分开？这比要求所有页面统一，或让每页完全从头生成，更贴近实际工作。
因此，对一个准备采用生成式工具的团队，我会先看已有的可靠资产：数据口径是否稳定，权限能否沿用，性能基线是否可重跑，交互关系是否可描述。再挑展示需求变化多、底层承诺变化少的一小类任务，比较首次交付和后续修改各花了多少人力。如果时间主要耗在澄清指标，继续加快写页面未必解决瓶颈；若重复工作集中在布局与联动，共享执行层就可能释放新的需求。
这个方法是从几种不同工程实践中归纳的待验证建议，本期没有运行比较实验。它也不意味着要先建一个大平台：原始案例本来就利用了已存在的设施，重新建设是否合算需要单独算账。下次应优先找新增页面的边际工时、底座持续维护、错误数字与后续修改的共同记录。只有把这些分开，才既看得见生成能力带来的自由，也不会把已经付过的建设成本误写成消失。
这周最有启发的变化，是一些“值得不值得自己做”的边界正在移动。过去为少数业务人员开发一页定制报表，很容易被排进没有尽头的需求队列；现在生成界面的成本下降，需求本身可以成为开发的起点。David Lequin 团队的经历为这种变化提供了实例：他们保留数据仓库、约两千个 dbt 数据模型和身份认证，把更自由的布局放到这些设施上。用户增长表明定制页面有吸引力，至于数字是否更可靠、总费用是否更低，还需要另外的记录。
信息来源：Google Developers · TorchTitan 优化说明