需求单上只写“给客户页加一个状态筛选”，AI 却顺手改了接口、表格字段和一段权限判断。代码跑得通，评审时才发现它理解的“状态”不是业务说的状态。这类偏差不是生成速度问题，而是工程上下文没有被固定下来。

偏差发生在写代码之前

mattpocock/skills 的价值，不是再给 Claude Code 或 Codex 加一个万能命令，而是把“聊需求、写 PRD、拆 issue、实现、复查”变成一条可回溯的链路。它能让 Agent 少猜一点，不能保证模糊需求自动变清楚。失败场景是只丢一句“按最佳实践做”，Agent 会把自己的默认判断当成你的判断。

先把共识写进上下文

遇到不确定需求，第一步适合用 grill-with-docs。它会一边追问，一边把术语、边界和关键决定沉淀成项目上下文。这样后面再写 PRD 时，不必靠上一轮对话的零散记忆拼答案。

这一步能减少“同一个词多种理解”的问题，不能替团队做取舍。比如“归档客户”到底是隐藏、只读还是解除分配，仍要由人确认。失败场景是所有问题都答成“都行”，上下文文件会变长，但真正的决策仍然空着。

再把上下文压成 PRD

to-prd 的定位更像整理器：它读取当前对话和代码库理解，把已经谈清楚的内容变成 PRD，并强调不要重新访谈用户。顺序很关键，先追问再写 PRD；如果前面没解决分歧，PRD 只是把含糊话换成正式格式。

把大需求拆成可验收切片

PRD 之后再进入 to-issues、tdd 或 implement，才比较像工程工作流。to-issues 负责把需求拆成垂直切片，tdd 负责先用测试描述预期行为，implement 再动代码，code-review 回头检查实现有没有偏题。

这条链路能把“AI 写错需求”拆成几个可发现的节点：术语没对齐、PRD 没写边界、issue 太大、测试没覆盖验收标准。它不能替代人工评审。失败场景是 issue 写得很漂亮，但没有成功标准，最后仍只能凭感觉判断代码对不对。

适合重任务，不适合小改动

如果只是改一个文案或补一个样式类，完整链路会显得重；如果是权限、、数据流、多人协作功能，这套流程更值得开。一个简单判断是：需求讲不清会不会返工超过半天？会，就先走工作流；不会，直接改完再检查更省事。

用 mattpocock/skills 的重点，是让 Agent 在每一步留下可验证的中间产物。代码当然还会错，但错在哪里会更早暴露：不是等到最后看一堆 diff，而是在共识、PRD、issue 和测试里逐层拦住。