用途：Products 层的目标是一张“可治理的业务地图”，而非罗列全部功能名。数量过多会让地图失效，建议收敛到 ≤ 6；无法收敛时必须写明原因与治理建议入口。使用时先宣布正在使用该技能从代码事实反推业务模块并收敛数量。
主要能力与线索优先级（从强到弱）：1）数据主责，哪个模块主写哪些核心对象，来自 contracts/data/；2）对外能力边界，哪些 API 是稳定承诺，来自 contracts/api/；3）组织边界，Owner/团队负责的模块群；4）运行边界，独立部署、扩缩容、SLO（如存在）。
输出文件：.aisdlc/project/products/index.md（可选但推荐），以及 .aisdlc/project/products/{module}.md（每个业务模块一页）。index.md 建议字段含 product_module、owner、key_components、key_data_ownership、key_contracts、status；{module}.md 包含业务边界 In/Out、承载组件入口、数据主责入口、对外能力入口、关键术语入口。
收敛策略（≤ 6 的做法）：先按数据主责聚类，再用对外能力校正边界；优先合并仅被内部调用、没有数据主责、没有稳定对外契约的碎片模块；保留跨团队接口多、数据主责清晰、对外承诺稳定的业务模块为一级。
无法收敛时允许 > 6，但必须在 products/index.md 顶部写明不可收敛原因与治理入口，常见可接受原因包括合规隔离/数据隔离硬要求、数据主责天然分裂且短期不可合并、组织边界强约束。需给出治理建议入口，例如 ADR、迁移路线或组织对齐会议纪要链接，不留空洞 TODO。
红旗清单：把产品层写成功能清单大全；业务模块数量持续膨胀且无收敛策略；products 页复制组件页或契约页细节，应只保留链接入口。出现任一条应停止并纠正。
限制与缺失：资料未提供具体运行命令、安装方式、收费与平台信息，相关细节暂未提供。