淘天物流以分层目录和索引路由组织研发知识

淘天物流团队面对多业务域、多应用、多模块的复杂后端，先把 knowledge/ 设计成完整知识资产目录而非应用文档集合：main/ 沉淀跨应用跨系统的通用知识（核心术语、跨应用流程、通用状态定义、全局技术约束）；applications/ 按应用组织，每个应用含总览 md、INDEX.md 导航与 domain/product（主干能力）、domain/solution（按业务身份/业务线写差异与历史兼容）、domain/base（API、消息、模型、Repository、表与字段语义等高频索引）、tech/（研发规范、架构约束、框架用法、异常处理、MQ 与调度任务等）；另有 candidate/（候选知识）、personal/（个人经验）、template/（模板）与 INDEX.md、README.md、KNOWLEDGE-RULES.md、ROUTING.md 约束目录与路由规则。AI 读取路径被明确规定为：应用职责→product 主干能力→solution 差异逻辑→base 接口/消息/模型/Repository→tech 研发规范→回到当前代码确认，先读索引再按需读具体文件，避免整目录全读。 团队把流程落地分三阶段，第一阶段用 Coding Agent CLI + skills + Markdown 模板把“需求分析→应用拆解→实现校验→知识回补”跑通，这套流程内部叫 RD（research development），本质是一组 skills、命令协议与 md 文档，不和某一个 Coding Agent 强绑定，只要其他 Agent 能读 requirement、analysis、implementation-check、continue-prompt 即可接续。全流程命令为 /rd:verify-prd（前置保证 PRD 合格）→/rd:work（路由命令，按输入与上下文自动引导下一步）→/rd:clarify→/rd:analyze→/rd:decompose（生成 by 应用的 requirement）→/rd:verify-requirement→应用仓库开发→/rd:apply→/rd:validate（requirement 与代码 diff 对账）→/rd:code-review→/rd:release-plan→发布→知识回补。三层资产分别为命令协议层（.agents/commands、.agents/skills）、知识资产层（knowledge/）与 RD 过程资产层（rd/requirements/{requirementId}/），过程产物在设计上支持跨会话执行，解决上下文压缩导致漂移。 团队在 PRD 验证、需求澄清、方案设计、发布计划等关键节点设人机协同 review 点，人只在高价值位置介入确认“校验前置还是后置”“状态从哪个 feature 取”“是否兼容历史服务”“开关默认值”“是否需要灰度回滚”等最易造成返工与事故的业务事实。真实案例（上游服务商新回告状态触发差异调整，需在主流程入口做六项前置校验并事件驱动异步调用订正流程，应用名与字段已脱敏）两轮对比：第一轮用 Coding Agent CLI 最高能力档，AI 自己 review 出 7 个待确认点，但关键校验被放到相对靠后位置、无法前置阻断服务商回传，代码采纳率约 75%（人工估计）；第二轮把“两阶段异步架构”“六项前置校验在 xxxProcess 中执行”等关键约束明确写进 requirement 与方案输入，并补充历史业务身份兼容、运单状态取数等人工 review 意见，中断 3 次（问题澄清 1 次、Review 调整 2 次），代码采纳率 95% 以上。团队明确不追求 100% 全 AI：剩下简单问题手改更经济；度量上不只看生成代码行数，而是看 PRD 阶段 open item、requirement 拦截项、validate 的 diff 不一致、代码采纳率、人工中断发生在哪些阶段、以及需求结束后回补了多少稳定知识。