第 3 章 · 问题 1：为什么不能直接让 Code “做个好看的网页”
候选人信息、业务规则和页面选择混在一句话里，Code 只能边猜边做。怎样让 Work、Design、Code 各接对一棒？
知识库的原型实战把流程分得很清楚：Work 先把需求和事实做扎实；Design 先给多版可讨论方案；选定后 Code 才创建可运行文件。
01按“下一步要交什么”选择模式
模式接力判断1 / 6
“把已核验的候选人事实整理成页面内容和限制。”
先看下一棒究竟要交内容、方案还是真实文件。
02先由 Work 写一张别人不用猜的交接单
WORK · 招聘工作台交接单
请读取已验收的候选人总表-复核后.xlsx、招聘漏斗分析.xlsx、招聘周会一页报告.md、面试与补资料行动表.xlsx，以及 05_提取与安全规则.md，创建 01_Work成品/三模式交接单.md。
交接单必须写清：目标用户和使用场景；已确认事实；仍待确认字段；页面必须展示的模块；允许的筛选和演示交互；不能出现的结论；不能修改的上游文件；Design 要交什么；Code 要交什么；各自怎样验收。
禁止展示完整手机号和邮箱，演示页面只用脱敏联系方式；不能出现“已录用”等材料不支持的结论；按钮不得真的发送消息。完成后重新打开交接单，列出仍需人工决定的 3–5 项。
03交接单要把“事实、决定、表现形式”分开
Work 已确认候选人、状态、缺失和来源
→Design 决定信息层级、布局、三版方案
→Code 实现真实文件、交互、响应式与测试
例如“李娜没有填写薪资”是事实；“把缺失薪资用黄色标签显示”是设计选择；“点击筛选后只显示待补资料的人”是 Code 要实现和测试的交互。
知识库依据《由需求直接生成原型图》与《从 UI 到可交付前端原型》↗课程沿用原文 Work → Design → Code 的角色分工，并把“需求输入、页面层级、交付清单、验收清单”写进交接单。
最后验收