20 个章节 · 支持关键词组合搜索
知识、技能与项目上下文
实践 / 建议知识、技能、项目上下文各放哪里
先确定唯一维护源，再讨论目录
| 内容与变化原因 | 唯一维护位置 | 使用方式与边界 |
|---|---|---|
| 公司规范、稳定业务语义、跨仓领域知识、审定手册 | ai-wiki | 按适用范围检索；引用稳定 ID、状态和版本 |
| 可复用步骤、工具调用合同、技能测试、运行协议 | 对应能力源工程 | fs-ai-hub 登记并发布，TeamAI 分发固定版本 |
| 模型/客户端适配、角色资源订阅、流程包目录 | fs-ai-hub | 沿用命名空间、角色、Project、CODEOWNERS；不复制所有工程源码 |
| 分支相关实现、启动命令、代码导航、项目例外、测试 | 业务仓的 AGENTS、ai-context、docs 与代码 | 与代码同 MR 更新；wiki-bot 汇聚可读快照 |
| 当前需求、范围、验收合同与交付摘要 | GitLab Issue 正文与备注 | 公司研发任务 SSOT；关联 Multica，阶段摘要回写 |
| 执行状态、阶段交接、重试、详细讨论 | Multica Issue 与 topic reply | 保存过程与证据指针，固定关联 GitLab 合同 |
| 原始日志、诊断事实、报告、运行记录 | 受控证据存储和 CI 制品 | 任务内引用 URI/digest，避免把群聊和客户日志全量沉淀为知识 |
例如“自定义对象字段权限的业务含义”应进 ai-wiki；“本分支权限校验类的位置”留 AppFramework； “按权限规则补回归测试的操作方法”成为技能；“本次某租户问题的日志”留证据存储。 同一主题可以有四种不同资产，按变化原因归属后，用稳定 ID 互相引用。
udobj 融合采用维护权迁移
已盘点 118 个 Markdown：7 个 playbooks、70 个 business-domain、9 个 architecture、 18 个 engineering、7 个 testing、3 个 incident、4 个根文件。 全部缺 frontmatter，另有 3 个空页或标题页；五张能力卡和五份接口契约已有可保留的标识。
以本项目现行 domains/<GitLab group>/<repo> 规范为准，迁移主体落到
domains/udobj/udobj-knowledge-base/，团队导航聚合相关仓；不另造一个与现有规范竞争的顶层域目录。
公司通用规范归并到现有规范入口，团队差异注明 scope，实施细节保留项目源。
obj.*、uipaas.*、api.*、AC-* 等 ID 延续，便于能力、接口、验收跨仓关联。
建议按下面顺序开迁移 MR；旧仓归档是验收完成后的收尾动作。
- 冻结迁移清单，逐页登记旧路径、新路径、维护责任、来源、是否有效、待核验原因。
- 处理空页、重复页、过期规则；未确认内容保留明确状态，不为了目录整齐编造正文。
- 补齐符合本库 OKF 约束的元数据，维护旧 ID/链接映射；正文在目标库接受评审。
- 在 wiki-bot 明确人工策展区与生成区；验证重新聚合不会覆盖人工页或移除必要元数据。
- 切换 AppFramework 的
.scripts/kb-path.sh等入口到AI_WIKI_ROOT(S)， 同时核验 SFA、metadata、相关 Skill 和检索消费者。 - 用代表性问题复验检索、原文、接口/能力 ID、内部链接和版本提示；保存迁移报告。
- 目标库成为唯一维护源，旧库仅留迁移公告和可访问映射；停止原写入/发布链，再按团队流程归档。
归档前验收以“读者与 Agent 已能在新库完成原来的任务”为准。 如果试点失败，按迁移清单回退消费者；正式切换后避免两个仓同时维护正文。 详细分类和目录对照保留在附录，迁移本身尚未执行。
OKF 必须贯通源文件、发布页和检索结果
已核对 wiki-bot 渲染链有部分维护责任、status/type 元数据未完整保留的问题；
fs-ai-hub 当前 OKF 检查又排除了 docs/ai-wiki。
因此“源文档写了状态”不能证明 Agent 检索时看得见状态，公司级 OKF 门禁也不能宣称已经统一生效。
建议保留原 schema，并补一条往返验收：源文件 → 发布页 → 搜索结果 → Agent 引用， 逐段检查稳定 ID、适用范围、来源 revision、生成/人工属性、审定状态和复核时间。 知识冲突或快照过期时返回差异与来源，涉及关键行为时回核代码/维护者，不静默选一个答案。
检索入口建议按任务携带公司、团队、业务项目、仓库、技术栈及当前 revision 的 scope。 规范类答案优先给适用且已审定的权威正文，代码行为类答案优先核对目标版本实现； 不能把一条高相关但已过期的 wiki 快照当作当前事实。 wiki-bot 记录源 SHA、生成时间和变更失效状态，检索返回这些字段及引用片段。 无适用结果时明确知识缺口，由责任人补充，不从其他团队相似规则推定强制要求。 权限筛选应在检索/存储侧执行；能订阅某 Skill 不代表能读取所有团队资料。
已有多源知识萃取：代码、问题、需求和反馈共同供给
用户确认：公司使用 repo-wiki 从代码萃取知识，同时从 TAPD Bug 库、故障复盘、 需求 Wiki、用户反馈等来源萃取知识，并定期增量更新。 因此当前需要加强的是不同来源的语义、更新一致性和知识如何进入验证闭环。 本轮没有重新运行这些采集作业，也未核验其全量覆盖率与增量延迟。
| 来源 | 主要回答什么 | 保留的边界 | 建议沉淀的验证资产 |
|---|---|---|---|
| 代码 → repo-wiki | 某个 revision 的实现、接口、依赖和约束 | 当前实现可能有缺陷；代码事实不自动成为业务规范 | 模块导航、接口契约线索、已有测试与验证缺口 |
| TAPD Bug 库 | 症状、触发条件、影响、处理与修复历史 | 未确认/重复/无法复现/已关闭有不同含义；关闭不单独证明根因正确 | 缺陷分类、可复现样例、关联修复与回归用例 |
| 故障复盘 | 经过确认的机制、影响、处置与改进 | 区分当时版本、环境与后续纠正，保留反证和未知 | 失败模式、故障注入、巡检规则、恢复演练 |
| 需求 Wiki | 业务意图、规则、历史决策与验收预期 | 区分已实施、未实施、变更和废弃；不能直接等同当前线上行为 | 审定 验收标准、业务不变量、用户旅程 |
| 用户反馈 | 真实痛点、体验、使用情境和异常线索 | 主观评价与客观缺陷分开；反馈需要归因和核验 | 探索性测试主题、候选需求、体验评测样例 |
TAPD 在这里作为知识与历史问题来源，与 GitLab Issue 作为当前研发任务 SSOT 的职责不同。 某条反馈进入正式开发后，建立或关联 GitLab Issue，详细执行过程进入 Multica； 原始来源链接继续保留，避免重新抄写形成多个无法对齐的任务。
增量更新需要处理修订、撤回和依赖失效
当前 repo-wiki 技能声明按 Git Diff 与页面 consumedSources 做页面级增量，
单仓知识正文和控制面在 .wiki 同根；它不直接承担跨仓或 TAPD 等通用数据采集。
外围采集/聚合链处理其他来源并保留其身份，必要时以外部参考方式参与单仓知识生成。
一个实际边界值得注意：仓内已消费参考可纳入 Git diff 失效链； 仓外 reference 在该技能中只记录根级指纹，变化只告警，不自动使页面失效。 因此外部需求或 Bug 内容更新后，宿主采集/调度必须明确哪些知识页需要重生成， 不能假定 repo-wiki 已自动传播所有外部变化。
建议沿用现有控制面，补齐以下贯通能力，不再维护一套与之竞争的更新账本：
- 每类来源保留稳定 ID、版本/更新时间、内容摘要、状态、访问范围与可追溯链接。
- 每次萃取记录输入范围、采集窗口、处理检查点、失败/遗漏及萃取器版本； 区分源内容未变化与本轮采集失败，失败不标记为“已更新”。
- 基于来源到页面/结论的依赖定位受影响内容，涵盖编辑、删除、撤回、归档和权限变化； 必要时标 stale/retracted 并从默认有效结果中撤出，保留受控历史。
- 同一问题跨反馈、Bug、复盘和修复提交出现时建立关联，不能仅按文本相似就删掉不同事件。
- 增量写入通过后再推进对应检查点；任务重跑按来源与版本幂等处理，定期对账发现漏采。
- 检索索引和引用状态随正文更新；在途 Agent 继续引用已锁定的任务知识快照， 重要规则纠正、风险信息或失效结论则触发显式影响评估与重读。
周期性增量可继续作为基础；高影响规则、严重故障结论和来源权限撤回应有更快的更新/撤回通道。
更新频率按来源变化速度与风险确定，不要求所有仓每次全量重建。
既有 curated 人工页和 ai-wiki 的 preserved 边界要保留，生成流程不能覆盖人工审定内容。
从知识增长走到验证能力增长
推荐链路为：新来源事实 → 候选结论 → 核验/适用范围 → 回归或评测样例 → 必要的规则/技能变更 → 灰度验证 → 运行反馈。 正常的源码事实增量通过确定性检查后可按既定策略自动发布； 改变业务语义、强制规范、权限边界或跨团队适用范围的结论，由对应责任人裁决。 人不需要逐条审批所有增量，但要持续抽查萃取质量、过期传播和重要结论。
例如：Bug 记录提示权限字段泄漏，先确认触发条件和修复提交，把可复现回归留在业务仓； 经确认的错误模式进入 ai-wiki；在适用范围内补技能负向样例或静态规则； 诸葛巡检/回放按新版本验收。不能仅把 Bug 摘要收进知识库就认为已防止复发。 这是建议的转化剧本，不代表本轮已执行该具体案例。
知识治理指标应包括来源覆盖、采集与索引延迟、过期/冲突率、引用可追溯率、抽样答案正确性， 以及已确认问题转成有效回归/技能评测的比例和复发情况。 文章数量、更新次数、检索命中率只提供辅助信息；重复或过时知识命中更多可能反而放大错误。
本节依据： 迁移分类附录、fs-ai-hub OKF；源与消费者盘点范围见证据索引 L4/L5。