工具笔记
让 AI 写更新接口：从允许修改的字段出发
给能修改的字段明确名单。
资料核验2026.11.12 · TypeScript · 建议开启 strict 模式
数据库里的用户记录有昵称、头像和角色。助手把更新输入写成 Partial<User>，看上去很省事，却把角色也放进了允许的类型里。对外部接口，能改哪些字段本身就是规则。
让助手从这一步开始
把用户表中昵称、头像、角色三列交给助手，明确只允许外部修改前两列。要求它同时给出 TS 输入类型、运行时提取逻辑和数据库写入字段，说明未传与显式清空的约定。
先选允许项，再让它们可选
可以用 Pick 选出昵称和头像，再用 Partial 表达两项都可以不传。服务端从输入中验证并提取这两项，写入时也使用明确字段。运行时过来的额外属性仍然需要按约定拒绝或忽略。
同时测试只改昵称、两项全不传、传入角色三种情况。决定空更新是成功的无操作还是客户端错误，并把它写进接口约定。
如果某个字段支持显式清空，还要区分未传与传 null。可选和可清空是两个决定。
把问题变成可重跑的样例
以 {"nickname":"小林","role":"admin"} 为输入。按接口约定可拒绝整份请求，或只接受昵称，但之后回读角色必须与修改前一致。另测头像设为 null 与不传头像，两者是否等价由产品定义。
核对这几项输出
- 只传昵称能成功。
- 空对象按 API 约定处理。
- 额外角色字段不能改变存储值。
- 显式 null 只在产品允许清空时通过。
怎么判断改动能不能收
只改 TypeScript 类型并不能拦外部 HTTP 请求。看实际更新对象有没有直接展开整份输入，再用测试客户端提交额外字段核验。数据库回读的值比响应里的成功提示更有说服力。
同时让助手查看解析层、业务层与 ORM 更新调用。哪怕请求类型正确，如果后续对原始对象做展开，也可能把额外字段带回去。最终通过数据库回读或明确记录更新语句核实角色没有变化。
这个类型明确列出源码可用的字段。解析外部 JSON 时仍需验证并构造新的更新对象。
type User = { nickname: string; avatar: string | null; role: string };
type ProfilePatch = Partial<Pick<User, 'nickname' | 'avatar'>>;
