编程开发 编辑复核
TypeScript 类型边界设计
把接口、状态和可选字段设计成能约束错误且便于演进的 TypeScript 类型。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名TypeScript 架构师。请根据真实数据流设计类型边界，明确可选、可空、联合状态和兼容字段，不要用 any 隐藏不确定性。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 数据来源、生命周期和状态不变量
2. 类型、联合类型、泛型和运行时校验边界
3. 旧字段兼容和迁移策略
4. 错误状态、未知值和外部数据处理
5. 编译检查、测试样例和禁止的类型逃逸
输入变量：
- 数据流（{{data_flow}}）：提供 API、组件和存储之间的字段流转。
- 旧契约（{{legacy}}）：列出必须保留的字段和历史调用方。
- 运行时校验（{{runtime}}）：说明 JSON、表单或外部数据的校验方式。
- 编译配置（{{strictness}}）：提供 strict、exactOptionalPropertyTypes 等设置。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 类型不能替代运行时校验，外部输入必须在边界解析。
- 先保留旧字段，再逐步迁移调用方。
WHEN IT FITS
适用判断
适合这些情况
- 数据结构有多种形态，需要用类型把非法状态排除掉。
- 现有类型到处都是可选字段和类型断言，用起来不安全。
- 要给团队定一套类型约定，避免各写各的。
换个做法更好
- 你要设计的是接口契约：用《API 契约设计与边界》，类型只是它的一种表达。
- 类型很简单：直接写。
- 你在追求类型体操的极致：过度复杂的类型对维护者是负担。
FAILURE MODES
常见翻车与修正
- 生成的类型用了大量条件类型和映射类型，没人看得懂。
类型的目的是让人写对代码。要求优先用联合类型和判别字段这类直白手段，复杂类型必须附使用示例说明它解决了什么。
- 类型允许了实际不可能的状态组合。
要求列出所有合法状态和非法状态，并逐条说明类型如何排除非法组合，排除不了的标注出来。
- 设计的类型和项目里已有的类型重复或冲突。
把相关的现有类型定义粘进输入，要求复用已有类型而不是新造，并指出可以合并的部分。
ACCEPTANCE
怎么判断输出合格
- 类型能排除掉列出的非法状态组合。
- 优先使用直白的类型手段，复杂类型有使用示例。
- 复用了项目里的已有类型，没有重复定义。
- 给出了从现有代码迁移到新类型的路径。
SAFETY BOUNDARY
使用边界
- 类型只在编译期生效，外部数据的实际结构仍需运行时校验，别把类型断言当成验证。
- 模型给的类型可能和实际接口返回不符，定义要以真实响应样本为准。