Sync: Labs-FinTecAI Knowledge Refactor Operating Plan
日期：2026-05-13 来源项目 / 材料：治理仓库与知识库重构反馈 提交人 / 责任人：Labs-FinTecAI Admin 当前状态：Ready
1. 触发背景
团队成员在阅读和实践治理仓库、知识库、项目文档和 FinClaw 相关材料时暴露出系统性问题：当前仓库能沉淀正式事实源和边界，但不总能让不同角色低上下文地判断“我现在该读什么、该做什么、该交给谁、怎样验收”。
本计划启动一次仓库级重构优化，但不把重构理解为全仓库逐字重写。目标是用可分批、可恢复、可验证的方式改善知识库结构、入口、文档角色、Controller 交接和约束下推。
2. 核心约束
- 覆盖整个治理仓库和知识库，但不进行全量深读。
- 每批只处理一个可验收问题，不把多个项目正文重写混进同一批。
- 先做轻量 inventory，再决定哪些文档需要深读、重写、重链、降级或不动。
- 不为了重构而重构；只有当问题影响读者进入、Controller 接手、事实源一致性、工程承接、约束下推或验收闭环时才改。
- Admin 会话处理生态级结构和公共入口；项目级正文、PRD、schema、case、UI、工程输入由各项目 Controller 承接。
- 每轮都必须产出压缩控制物，避免后续会话重新读取整个仓库。
3. Skill 工具栈
| Skill | 当前状态 | 本次定位 | 使用边界 |
|---|---|---|---|
site-architecture | 已安装到 .agents/skills/site-architecture/ | 知识库 IA、入口、层级、导航、路径和内部链接设计 | 改造成治理知识库 IA 使用，不按营销站点目标决定事实层级 |
doc-coauthoring | 本地存在于 /Users/mlabs/Programs/anthropics/skills/skills/doc-coauthoring/SKILL.md | 正式治理、产品、知识库文档的结构化重写 | 只能在文档角色、读者、目的和上位事实明确后使用 |
internal-comms | 本地存在于 /Users/mlabs/Programs/anthropics/skills/skills/internal-comms/SKILL.md | sync、handoff、3P update、FAQ、阶段状态和变更说明 | 只记录协作与变更，不替代正式事实源或产品定义 |
本批同时将 .agents/ 与 skills-lock.json 纳入 tooling scope 校验，避免项目级 Skill 安装产物在后续验证中被误报为越界。
4. 执行模型
4.1 Admin lane
Labs-FinTecAI Admin 负责：
- 全仓库轻量 inventory；
- 文档角色 taxonomy；
- 入口、导航、manifest、portal 暴露面；
- Controller handoff 模板；
- 文档生命周期；
- 跨项目约束迁移规则；
- 公共入口与发布闭环。
Admin 不负责：
- 替项目 Controller 判断项目内容；
- 逐字改写所有项目文档；
- 替工程仓库写接口、代码或测试；
- 把临时过程材料提升为 canonical 入口。
4.2 Project Controller lane
各项目 Controller 负责：
- 项目级事实源整理；
- 项目 quickstart、PRD、MVP、design packet、engineering input；
- 将项目约束下推到 schema、case、UI、prompt contract、task packet 和验收矩阵；
- 将稳定变更通过 sync / escalation 回写给 Admin。
5. 分批计划
| 批次 | 目标 | 主 Skill | 输出 | 深读上限 |
|---|---|---|---|---|
| Batch 0 | 启动控制面和工具栈 | internal-comms + site-architecture | 本计划、启动审计、Admin checkpoint | 入口文档和协议文档，不深读项目正文 |
| Batch 1 | 全仓库轻量 inventory | site-architecture | Document Inventory：路径、角色、状态、owner layer、动作建议 | 只读标题、状态、用途、链接和元信息 |
| Batch 2 | 目标知识架构 | site-architecture | 目标层级、导航、角色化入口、链接策略、孤立文档处理 | 只深读冲突入口和阻塞点 |
| Batch 3 | Canonical 文档重构计划 | doc-coauthoring | 核心文档 audience / purpose / reader action / acceptance | 每轮 1 到 3 份核心文档 |
| Batch 4 | 约束迁移规则 | doc-coauthoring | Constraint Migration Table 和项目分发包模板 | 不进入项目实现细节 |
| Batch 5 | 项目 Controller 分发 | internal-comms | 各项目 Controller Refactor Packet | 每个项目单独会话执行 |
| Batch 6 | 验证与发布闭环 | internal-comms | 3P update、closeout、验证证据 | 只读本批变更和入口面 |
6. 文档动作判定
| 条件 | 动作 |
|---|---|
| 正式入口或 canonical fact source | 深读，必要时重写 |
| 入口文档但读者任务不清 | 重构 |
| 与上位事实源冲突 | 重构、降级或发 escalation |
| Controller 必须继承但缺 handoff | 补 handoff 或模板 |
| 证据层 / 参考层已被正确引用 | 不重写，只标记角色 |
| 旧过程材料已被吸收 | 降级、归档或移出正式入口 |
| 孤立页面但有证据价值 | 补链接或降为 evidence |
| 只有风格问题，无真实阻塞 | 不动 |
7. 上下文控制规则
- 每批开始前只读取本批入口和上轮压缩产物。
- 每批结束必须产出一份短 checkpoint 或 sync，写清完成、未完成、下一步和禁止扩展范围。
- Document Inventory 只保存摘要字段，不复制正文。
- 项目细节不进入 Admin 长上下文；只进入项目 Controller packet。
- 任何会话不得以“覆盖全仓库”为理由读取全部长文档正文。
8. 第一批完成定义
Batch 0 完成需满足：
site-architecture已安装并记录；- 本 operating plan 已形成；
- 第一份知识架构启动审计已形成；
- Admin checkpoint 登记本批范围；
- 未修改项目正文；
git diff --check通过；docs-manifest.json可解析。
9. 是否需要转 escalation
当前不需要转 escalation。本计划是治理重构执行入口，不是要求修改生态事实或项目边界的正式裁决。
10. 吸收状态
待 FinTec AI admin 会话复核。复核后可作为后续 Batch 1 的启动依据。