新加坡：客户已有产品团队时，外部工程补在哪里

如果客户自己已经有产品团队，外部工程师进入之后，第一件事就不该是重新搭一套同样的团队。新加坡 Pair 的材料适合从这个问题读起：内部建设能力已经存在时，外部技术究竟补在哪里？

一个月的原型，怎样走向长期产品

新加坡 Pair 的团队回顾，把起点放在 2023 年 1 月：Open Government Products 这个政府数字产品团队，由五人小组做出 Word 文档插件，随后逐渐发展为聊天界面。当前产品页列出共享政策助手、批量处理反馈和文书初稿等用途。¹²

OGP 对自身的说明，不只是一张组织图。它把团队定位为公共利益做产品的实验开发组织，公开强调从真实用户的问题出发、给专业人员决策空间，并通过跨职能协作完成工作。³ 这可以解释其机构选择，不应被改写为“新加坡人天然善于执行”。

2026年6月更新的建设方法页进一步说明，每年1月的 Hack for Public Good 会让团队接触用户、做原型、收集反馈。之后不只有“继续做大”一条路：项目可以得到专门团队继续建设，可以并入已有产品，可以有限发布，也可以记录所得后结束。有限发布意味着没有正式资源保障，更新可能有限，产品也可能关闭。⁴

这里体现的工作理念是把探索与长期承诺分开。能展示一个原型，说明某种办法值得继续了解；是否值得长期占用产品和维护人员，还要另作决定。把小工具并入已有产品，也可能比成立一支新团队更有价值。

数据可以进入到哪里，谁仍要检查答案

Pair 署2023年4月27日的服务条款，把允许处理的资料等级、使用者核查输出的责任和访问控制写进同一安排。它还区分了两件容易混淆的事：模型提供者不储存请求内容，并不等于政府产品自身不能为监督记录消息。⁵ 此处读的是该版本条款所设计的责任，不能用旧模型名单重建2026年的全部运行架构，也不能把一份条款当作安全测试。

对部署团队，这个区分很实际。采购方说“资料不留存”时，必须追问指哪一方、哪一类内容、哪一段处理过程。业务人员得到一个可使用的工具，也不意味着输出已经替他们完成事实核查。

Pair 因而提供了一种相似的现场产品建设方式，而不是一份外部 FDE 采购证明。产品团队持续建设公共组件，使用机构提供具体任务与反馈；模型供应商提供能力，但不会因此自动成为每项政府工作的责任人。

外部能力应填补一个已确认的缺口

依据这些材料，本书建议外部团队先确认三个问题：现有工具能否完成任务，机构人员能否配置与核查，剩余困难是否真要修改软件。如果政策助手已有可用组件，工作可能是补材料与测试；如果困难在不能处理的资料等级，增加提示词技巧并不能消除边界。

长期维护也应在开工时说清。一个内部团队能快速试做，不等于它承诺长期接管所有新需求。对准备引入这种安排的客户，最重要的交付物之一，是本次工作会进入哪条后续路径，以及谁为那条路径安排资源。