fec-source-driven-development

来源驱动开发

用途

在前端实现、评审和架构决策中优先依据项目内事实、官方文档和当前版本行为，避免沿用过时经验或未经验证的假设。

流程

1. 判断是否需要查源

   • 涉及框架新版本、路由、渲染模式、缓存、构建工具、浏览器 API、包发布格式、鉴权协议或公共接口时必须查源。
   • 涉及项目约定时先读本仓库 README、配置、模板、已有实现、测试和迁移记录。
   • 只是稳定语言语法或明显局部重构时，可使用项目现有模式作为事实来源。

2. 收集权威材料

   • 首选官方文档、规范、源码、release notes、migration guide、类型定义和项目内测试。
   • 第三方文章只能作为线索，不能作为最终依据。
   • 对快速变化的库记录包名、版本、文档日期或页面标题。
   • 当用户要求从本地知识库、项目资料库或 knowledge/ 目录回答问题时，先走本地知识检索，不使用网络搜索补事实。

3. 提炼决策

   • 写清当前版本推荐做法、弃用做法、限制条件和迁移注意事项。
   • 对多个可行方案说明选择理由、兼容性、维护成本和回退方式。
   • 若文档和项目现状冲突，优先解释冲突并给出渐进调整，不直接推翻已运行系统。
   • 对依赖升级、框架迁移和公共 API 变化，记录 release notes、migration guide、版本范围、破坏性变更和回滚方案。

4. 落到实现

   • 将外部行为隔离在适配层、配置层或小型工具函数中，避免在组件里散落版本假设。
   • 公共接口变化要保持命名、错误形状、默认值和兼容策略清晰。
   • 代码注释只记录非显而易见的来源约束，不粘贴大段文档。

5. 验证假设

   • 用类型检查、最小复现、单元测试、组件测试、E2E、构建或浏览器验证证明关键假设。
   • 如果无法验证，报告不确定性、风险范围和需要用户或团队确认的信息。

6. 留下轻量决策记录

   • 当结论会影响公共接口、依赖版本、目录规范或团队工作流时，补充 ADR/变更记录或交给文档同步流程。

本地知识检索

当用户指定本地知识库路径，或默认 knowledge/ 目录存在时，可用本流程回答资料库问题、抽取证据或辅助决策。

1. 定位根目录

   • 用户明确指定路径时使用该路径。
   • 否则检查当前项目下 knowledge/ 是否存在；不存在时说明未找到默认知识库并请求路径。
   • 不用文件 glob 判断目录是否存在。

2. 分层导航

   • 优先读取根目录和子目录中的 data_structure.md。
   • 根据目录说明选择最相关的少量分支，不一次性遍历整个知识库。
   • 记录候选文件、主题、时间/版本范围和为什么相关。

3. 渐进检索

   • Markdown、文本、日志：先用关键词搜索，再局部读取命中上下文。
   • PDF：处理前先确认可用工具和提取路线，优先提取到临时文本后再检索，避免把整份 PDF 打进上下文。
   • Excel：处理前先确认读取/分析路线，先看工作表、列名和少量样例，再按字段过滤或聚合。
   • 默认最多 5 轮关键词迭代；每轮根据已找到证据调整同义词、缩写和范围。

4. 回答与溯源

   • 先给结论，再列文件路径、章节、页码、工作表或行号附近作为依据。
   • 证据不足时说明查过哪些路径、缺什么信息，以及用户如何缩小范围。
   • 不把知识库外的网络信息混入答案，除非用户另行要求查外部来源。

事实源优先级

优先级	来源	用途
1	项目内配置、测试、已有实现	判断本仓库真实约定
2	官方文档、源码、类型定义	判断当前推荐行为
3	标准规范、浏览器兼容数据	判断平台能力和兼容边界
4	Issue、讨论、第三方文章	辅助排查，不能单独定案

约束

• 不凭记忆给版本敏感结论。
• 不把过时教程当作当前最佳实践。
• 不引用无法复核的来源作为关键依据。
• 不为追新而改动稳定项目约定；必须说明收益和迁移成本。
• 不在交付中复制长篇外部文档；只保留必要结论和链接或文件路径。
• 不把“查过文档”停留在口头；版本敏感决策需要能追溯到具体版本、路径或官方页面。

预期输出

输出来源清单、版本或项目事实、决策结论、实现影响、验证命令和未决风险。若修改代码，关键行为应有测试或构建验证支撑。