方法：先判断采购类型（关键物料 vs 临时采购 vs 长期合作），不同场景用不同权重
证据：查询该供应商近12个月交付数据、延期次数、影响金额
案例：上次类似情况怎么处理的？当时为什么那么选？结果如何？
边界：不可抗力导致的延期不扣分；临时采购单次延期待遇不同
一句话说清三篇的关系：
① 内容架构告诉你要建什么 —— 4类骨干 + 6层体验 + 3岗位Checklist
② 判断资产告诉你知识库要升维成什么 —— 方法→证据→案例→边界
③ Loop Engineering 告诉你怎么让机器替你自己跑验证闭环
① 内容架构告诉你要建什么 —— 4类骨干 + 6层体验 + 3岗位Checklist
② 判断资产告诉你知识库要升维成什么 —— 方法→证据→案例→边界
③ Loop Engineering 告诉你怎么让机器替你自己跑验证闭环
一、博海现状诊断
8
Hermes Profile
project / employees / admin / business / creative / finance / ops / yanxue
5
核心业务系统
ERP / Wiki / CMS / 维修管理 / 学习平台
2
内容层次现状
处于第1~2层（文档库→结构化），暂未进入第3~4层（判断资产）
| Profile | 当前角色 | 缺什么内容层 | 优先级 |
|---|---|---|---|
| wecom-project | 项目BOT | 缺少明确的判断规则（什么情况升级、什么标准算完成） | 中 |
| wecom-employees | 员工回调BOT | 员工自助知识库（help层） | 高 |
| wecom-finance | 财务BOT | 制度版本管理、审批判断规则 | 高 |
| wecom-ops | 运维BOT | status 可用性公告 | 中 |
| wecom-admin | 管理BOT | 权限与治理层 | 未来 |
| 其余3个 | 业务/创意/研学 | 专业领域知识结构化 | 未来 |
二、六层体验架构 → 博海对照
| 层 | 标准内容 | 博海现状 | 下一步 |
|---|---|---|---|
| 1 门脸层 | www / brand | sxbh.ltd 官网 | ✅ 已有 |
| 2 自助认知层 | help / blog / community | Wiki 系统（待结构化为 AI 可读） | 需加工 |
| 3 产品应用层 | app / chat / platform | 5 个业务系统 + 8 个 Hermes BOT | ✅ 已有 |
| 4 开发者集成层 | api / docs / developers | Hermes API（8650/8660 port） | ✅ 已有，可文档化 |
| 5 信任韧性层 | status / trust / privacy | 无对外状态页 | 新建议 |
| 6 身份商业化层 | auth / admin / pay | 企业内部权限体系 | 内部已有 |
◆ ◆ ◆
三、三阶段落地路线图
🚀 Phase 1：MVP 骨干建设（1-2 周）
目标：完成 4 类骨干内容的最小闭环，让每个 BOT 有「判断规则」可循。
具体动作：
判断资产起步：挑一个高频场景（如「报销审批」），把 方法→证据→案例→边界 四步写成一条判断链，注入对应 BOT 的 memory。
具体动作：
| 谁做 | 做什么 | 产出 |
|---|---|---|
| 项目BOT | 接收 Loop Engineering skill，配置 builder/checker 循环 | 项目代码自动验证闭环 |
| 运维BOT | 通过 cronjob + Hermes gateway 实现 status 可用性公告 | 系统状态自动播报 |
| 研学 | 为 wecom-finance、wecom-employees 注入判断规则模板 | 审批 / 员工问答有据可依 |
判断资产起步：挑一个高频场景（如「报销审批」），把 方法→证据→案例→边界 四步写成一条判断链，注入对应 BOT 的 memory。
📅 1-2 周 · 投入：低
📈 Phase 2：成长期扩展（1-2 月）
目标：构建完整的判断资产 + 内容体验架构，8个 BOT 各司其职。
具体动作：
· 内容统一：Wiki/CMS 内容按六层架构重新分类（品牌 / 自助 / 产品 / API / 信任 / 权限）
· 判断资产沉淀：为每个业务场景（采购审批、项目验收、供应商评估）撰写判断链，存入对应 BOT skill
· 跨站一致性：品牌口径、价格、SLA 等关键数据统一来源，各 BOT 从同一源读取
· Loop Engineering 推广：从项目代码扩展到运维脚本检查、配置验证
具体动作：
· 内容统一：Wiki/CMS 内容按六层架构重新分类（品牌 / 自助 / 产品 / API / 信任 / 权限）
· 判断资产沉淀：为每个业务场景（采购审批、项目验收、供应商评估）撰写判断链，存入对应 BOT skill
· 跨站一致性：品牌口径、价格、SLA 等关键数据统一来源，各 BOT 从同一源读取
· Loop Engineering 推广：从项目代码扩展到运维脚本检查、配置验证
📅 1-2 月 · 投入：中
🏆 Phase 3：成熟期自治（季度目标）
目标：BOT 间自主协作，知识资产自动沉淀，人为干预降到最低。
具体动作：
· 全站内容季度过期巡检（skill 自动化）
· 新增业务场景自动触发"判断链"生成流程
· 多 BOT 协作时自动识别边界（什么场景升级给人、什么场景自决）
· 对外：sxbh.ltd 建立 trust / status 页，客户/供应商可公开访问
具体动作：
· 全站内容季度过期巡检（skill 自动化）
· 新增业务场景自动触发"判断链"生成流程
· 多 BOT 协作时自动识别边界（什么场景升级给人、什么场景自决）
· 对外：sxbh.ltd 建立 trust / status 页，客户/供应商可公开访问
📅 季度目标 · 投入：高
◆ ◆ ◆
四、判断资产实战：一条判断链的写法
📝 以「供应商延期要不要降级」为例
每条判断链写成 Markdown，存放在对应 BOT 的 skills/ 或 memory 中。BOT 遇到该场景时自动加载判断链，按序推理，结果落入日志供复盘。
博海判断资产库/
├── 采购与供应商/
│ ├── 供应商评估判断链.md
│ ├── 价格异常审批判断链.md
│ └── 紧急采购边界规则.md
├── 项目与交付/
│ ├── 项目延期处理判断链.md
│ ├── 范围变更评估判断链.md
│ └── 验收标准判断链.md
├── 财务与报销/
│ ├── 差旅标准判断链.md
│ ├── 超预算审批判断链.md
│ └── → 从这里开始，写第一条
└── 员工与人事/
├── 请假审批判断链.md
└── 转正评估判断链.md
◆ ◆ ◆
五、博海版本的「最少必要建设」
1
第一条判断链
从「报销审批」或「项目延期」开始，写满 方法→证据→案例→边界
1
第一个 Loop
项目BOT 已部署 Loop Engineering，选一个仓库跑一轮
4
个内容层对齐
门脸/自助/产品/API 四层已有基础，信任层（status）是新缺口
💡 研学的建议
明天就能做的事：让项目BOT跑一次 Loop Engineering，验证 builder/checker 循环。
这周能做的事：写第一条判断链（从报销审批开始），注入 finance BOT 的 memory。
这个月能做的事：帮运维BOT 配一个 status 页面，自动播报 Hermes gateway 状态。
这周能做的事：写第一条判断链（从报销审批开始），注入 finance BOT 的 memory。
这个月能做的事：帮运维BOT 配一个 status 页面，自动播报 Hermes gateway 状态。