核心认知¶
一个订单不是一个「大项目」，而是一组标准单元的组合。
拆解时不要一上来思考「我要怎么开发这个项目」，先问一个问题：**这个需求里面，有哪些是我们已经做过的单元？**做过的是复用，没做过的是本单要新增的——这张区分表决定了工作量、风险和报价。
第一步：理解客户的业务意图¶
客户原文往往很大且很模糊——很大很模糊的需求一定要先分解，而分解需要理解客户的业务意图：分解的依据不是需求的文字，是文字背后的意图。意图不清楚，链条拆得再机械也会拆错方向。
动手拆之前先回答三个问题：客户拿这些数据去干什么？给谁看？看了做什么决定？答案一句话写进拆解文档的第一行，后面每一层链条都服务于它。业务意图哪里来——评审会与需求八问（见「一个订单怎么开始」）。
机械拆解法¶
把业务需求沿固定链条过一遍，每一层问同一句话：这一层要做什么？做没做过？
业务需求
↓
数据来源
↓
采集
↓
解析
↓
清洗
↓
去重
↓
结构化
↓
精炼
↓
存储
↓
更新
↓
通知案例订单拆完：
业务需求：跟踪 300 个网站的新文章
↓
数据来源：300 个 URL 清单
采集： 每日抓取（爬虫单元）
解析： 抽取标题、作者、时间、正文
清洗： 去除广告、脚本、乱码
去重： 多站点转载同文的判定
结构化： 转为固定字段表
存储： CSV + 数据库
更新： 每日定时任务链条里没做过的一项要单独标注：案例中「转载去重规则」客户有特殊口径，标为本单新增项，进入风险评估——新增项是估算偏差的主要来源，藏不住。
**第二个例子：全球法规情报中心。**客户原文：重点覆盖 FDA、EU MDR / IVDR、NMPA 等十余个市场，监控新法规、Guidance、MDCG 文件、法规修订、标准变化、产品分类变化、注册政策变化，法规结论优先官方来源。
业务意图先立住：法规一变客户就知道，且结论可信——客户要的不是一堆法规链接，是「变化 + 影响 + 可信出处」。然后走同一条链条：
业务需求：全球法规变化监控
↓
业务意图：法规一变就知道，结论可信（官方来源优先）
↓
数据来源：FDA、EUR-Lex、NMPA、CMDE 等官方渠道清单
采集： 各渠道法规、指南、标准页面定期抓取
解析： 识别新增与修订
清洗： 去除无关公告与重复转载
结构化： 法规条目 + 生效日期 + 适用市场
精炼： 按客户产品线标注影响
存储： 情报库
更新： 持续监控
通知： 变化即时推送爬虫与法规情报两种完全不同的需求，走的是同一条链条——这就是链条的价值：换需求不换方法。
标准单元卡片¶
每个单元有一张卡片，新订单直接拼装。爬虫单元示例：
单元：网页采集（爬虫）
输入： 网站 URL 清单
输出： 结构化网页数据
参数： 网站数量、抓取频率、字段清单、历史时间范围
常见问题：robots 协议、登录墙、验证码、动态网页、网站改版
验收： 抓取成功率、字段完整率、更新频率达成没有卡片的单元，做完第一次就要补建卡片——这是「沉淀」的最小动作（详见最后一章）。
制定执行任务¶
拆完单元，把每个单元落成执行任务。一张任务单必须写全五项：
输入：拿到什么才能开工（清单、样例、参数）
输出：交付什么（文件、表、接口）
参数：数量、频率、范围
验收标准：怎么判断这个任务做完了（必须能算出数字）
负责人：谁执行、谁检查
判断规则：五项写不全，说明拆解没完成——回到单元卡片补齐，不许带着模糊任务进执行。执行阶段的所有返工，追溯回去几乎都是任务单缺项。