新加坡：内部产品团队与外部工程队伍

客户已有产品团队时，是否还需要外部工程？新加坡 Pair 展示一种内部建设方式，NCS 的队伍计划则提供服务商组织能力的对照。两者不能拼成一项已经完成的客户项目，但有助于判断应当怎样分工。

从原型走向长期产品

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

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

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

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

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

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

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

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

当服务商建设自己的现场队伍

新加坡服务商NCS提供了另一种组织对照。2026年10月29日，公司宣布成立AI Mission Centre，称已有100名智能化前沿部署工程师（iFDE），计划通过内部转岗培训和外部招聘，在两年内将队伍扩大到300人以上。⁶ 这是公司自报的当前人数与未来目标，不能把扩编目标算成已经到岗的人，也不能据此计算客户收益。

同一公告列出与樟宜机场集团、新加坡心理卫生学院及Life3 Biotech签订的三项合作备忘录，方向包括跑道监测、医疗照护和生物制造。备忘录证明各方提出合作，并不证明这些项目已全部投入运行或都由iFDE实施。⁶ 它们仍能引出一个与Pair不同的选择：客户已有产品与业务人员时，外部团队需要事先说明自己补哪一段工程、业务专家如何参与，以及之后谁负责维护。中心和队伍的规模，不能代替这份项目分工。

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

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

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