技能介绍

它解决什么问题

临床团队提需求时，最常见的一句话是「做个 X」——X 可能是 eCRF 数据录入、入排审核、医学写作、方案审查或偏离分类。这类话有三个坑：一是需求不等于问题，没人回现场翻译过「到底哪儿卡住了」；二是上来就讨论 AI，没人先判断该不该用 AI，很多事用固定规则或流程简化就解决了；三是即便该用 AI，也直接跳到交互细节，中间缺了「产品骨架」这一层——交互和文案是品味活，骨架却是能被驳回的工程决策。

它怎么工作

整个流程分三步，到框住骨架为止：

定义问题：把需求放回现场，走翻译、评估、定位、验因、收题五步，最终收窄到「最咬人的那一刀」，产出一张问题定义卡（业务问题、本轮范围、明确不做、验收标准）。
AI 适用性闸口：先过数据关三问——去标识够不够、是否对具名个体做决定、机密是否在科学 IP；再把需求粗拆成子任务逐段判断：能简化流程？能规则化覆盖？只剩「规则化不了、要靠甄别」的段落才交给 AI。判为非 AI 时止步，只给更简单的方向。
框设计骨架：按输出形态定任务类型（提取核对 / 判定分类 / 创作生成 / 检索匹配排序 / 预测评分异常），按风险定档。核心是恒定骨架 对齐 → 分路 → 定责 → 守界 → 交付，外加评测贯穿与治理托底。产出四层设计地图：故事主线、产品核心能力、五动作决策、评测治理轨。

注意点

不碰实现：不写代码、不调模型、不接 API、不写提示词。
红线不妥协：医学与科学性判断一律留给有资质者；影响受试者安全或合规上报的场景，漏报远比误报危险，默认走更严一侧；进入临床产物的数值必须有出处与单位核对。
拿不准就停：遇到高影响的判断点，带 1–3 个选项和倾向去问业务，而不是蒙一个答案往下走。