1. PRD 拆解不是翻译，是工程决策：为什么 90% 的 AI 辅助需求转化都卡在第一步
我见过三个团队把同一份 28 页的 SaaS PRD 交给不同 AI 工具处理。结果：一个输出了 47 条模糊任务（“优化用户体验”“增强安全性”）；一个生成了 132 行带注释的伪代码，但没一条能直接进 Jira；第三个干脆把 PRD 里“支持多租户”这句话，拆成了“创建数据库表”“写 SQL 连接池”“配置 Nginx 路由”三张卡片——而当时他们连技术栈都没定。
这不是 AI 不行，是 PRD 到任务清单之间根本不存在“翻译”这回事。它是一次完整的工程决策链：从商业意图 → 用户场景 → 系统边界 → 技术约束 → 可交付单元的逐层坍缩。Claude Code 在这件事上的价值，从来不是“更快地写错”，而是用结构化 prompt 强制你把隐含的工程判断显性化、可验证、可回溯。
我们团队在交付「客户成功平台（CSP）」SaaS 时，PRD 里有一条需求：“销售代表可在客户详情页一键发起工单，并自动关联该客户的最近 3 次互动记录”。人工拆解时，后端同学默认走 REST API + Redis 缓存，前端同学想着用 Vue3 Composition API 封装一个useCustomerInteractionHook。但 Claude Code 第一次输出的任务清单里，第 5 条写着：“【数据层】评估是否需引入事件溯源模式捕获客户互动快照，避免实时 JOIN 多张大表导致查询延迟 > 800ms”。——这个点，我们开了三次会才确认要上。
这就是结构化实践的核心：AI 不替你做决定，但它会把你忽略的决策点，用不可回避的方式怼到
