审 AI 写的 TypeScript 接口：用真实校验替掉 as

助手看到接口示例返回了 id 和 title，于是直接写了 as Article。第二天上游调整错误响应，页面却照常访问 title。类型断言不会替程序检查实际收到的值。

交给编码助手的任务

提供成功与错误响应各一份，要求助手把接口返回先当 unknown。只在网络边界校验非空对象、字段类型和业务允许值。交付一个明确的错误分支，能让页面区分上游失败与数据格式错误。

让边界负责确认字段

先把读出的值当成 unknown。检查它是非空对象，再确认 id 和 title 的类型，最后才组装内部 Article。遇到字段缺失时返回具体错误，方便区分服务出错和格式变化。

准备正常对象、缺字段对象和 null 三个输入。还要留一条字段存在但类型不对的样例，比如数字标题。这样能挡住只检查键名的半成品。

验证在网络入口做一次。业务代码随后只处理已经通过检查的数据，不需要到处重复猜字段。

先准备一个对照样例

提供 {"id":"42","title":"发布记录"}、{"id":"42","title":17} 与 null。前者输出内部对象，后两者走解析错误。再给一份接口错误对象，要求页面提示保留两种不同原因。

用这些结果验收

• 正常对象产生 Article。
• null、缺标题、数字标题分别失败。
• 上游额外字段按约定忽略或拒绝，不能悄悄进入内部模型。

审查时容易漏掉什么

用 tsc 通过只能证明代码满足类型规则。再用异常 JSON 走运行时验证，尤其是工具用断言消掉红线的地方。以后 API 增字段时，也只需在边界决定是否采纳。

为数组响应加一个混合样本，第一项有效、第二项无标题。产品可能拒绝整页，也可能忽略坏项并记录原因，先定预期再让助手实现。两种行为都必须明确，不能由数组遍历方法恰好决定。

这是支持对未知属性进行 in 收窄的 TypeScript 版本中的最小例子，项目还可以检查标题是否为空。

function parseArticle(value: unknown) {
  if (typeof value !== 'object' || value === null ||
      !('id' in value) || typeof value.id !== 'string' ||
      !('title' in value) || typeof value.title !== 'string') {
    throw new Error('文章字段不符合接口约定');
  }
  return { id: value.id, title: value.title };
}

资料来源

• TypeScript：类型收窄
• TypeScript：日常类型
• OpenAI Cookbook：让编码助手按可核验的开发流程工作