使用 Loom 知识库完成大模型价格雷达通知能力开发

前言

研发协作里有个反复出现的隐性成本：每次让 AI 介入开发，都得把项目背景、业务口径、代码规范、运行方式重新交代一遍——漏一条边界，就可能跑偏一整段实现。这篇记录的，是一次真实的产品研发交接 Demo：产品经理把需求资料沉淀进 Loom 项目知识库，研发只向织灵ADE·产品经理Yuen 递了一句简短任务，Loom 便基于项目 Wiki 与 GitLab 仓库继承完整上下文，独立完成大模型价格雷达的飞书群通知能力开发、首页状态摘要优化与全流程验证。

没有逐条复制需求，也没有反复口述边界——知识库把"重复解释"变成"可复用资产"后，研发交接能省下多少环节，往下看便知。

场景概述

一句话痛点：研发任务往往不只是"改代码"，还依赖大量项目背景、业务口径、代码规范、运行方式和验收标准。如果这些信息只散落在聊天记录、文档和个人经验里，每次让 AI 开发都要重新解释一遍，容易漏掉关键边界。

Loom 解法：先把大模型价格雷达项目相关的需求纪要、飞书群通知需求、页面优化草图、价格更新流程、代码规范、运行说明、测试说明等资料沉淀到项目 Wiki / 团队知识中。随后只给 Loom 一个简短研发任务，Loom 就能结合知识库和 GitLab Repo，继承项目上下文并完成飞书通知能力、首页状态摘要优化和验证说明。

预期效果：知识库把"每次都要重复解释的项目上下文"变成可复用资产，让 Loom 从一开始就知道业务口径、代码边界和验收方式；最终不仅完成了功能开发，也形成了可验证、可复现、可交付的研发结果。

场景背景

角色：产品经理 / 研发协作人员

业务对象：大模型价格雷达

任务：基于已有项目资料，为大模型价格雷达增加飞书群通知能力，并优化首页状态摘要，同时给出实现说明和验证方式。

难点：

• 需求细节分散在需求纪要、Markdown、流程图、页面草图、示例数据和代码文件中；
• 异常场景需要区分价格变化、抓取异常、数据陈旧、无变化无异常；

知识库资料准备

这个场景是一次真实的产品研发交接：产品经理完成需求设计后，将 PRD、页面草图、流程图和示例数据上传到项目 Wiki。研发不需要再把需求逐条复制到 Prompt 中，只需向 Loom 提交一个简短的开发任务，Loom 就可以从项目 Wiki 获取产品经理沉淀的需求资料，同时结合 GitLab Repo 中的现有代码和项目说明完成开发。

项目 Wiki 中原本已有的项目资料以及一些与本次需求不相关的噪声文件：

• 项目背景
• 数据口径说明
• 现有系统说明
• 运行与发布说明
• 代码规范
• 集成测试开发说明
• 验收说明

本次由产品经理新增上传的需求资料：

• 飞书群通知需求（PRD）
• 页面优化草图
• 飞书通知流程图
• 示例通知内容
• 示例数据和 webhook payload

Loom 接到任务后，自动将"原有项目代码仓库的资料"和"本次新增需求"结合起来，形成完整的开发依据。知识库中的资料共同约束了以下实现方向：

• 保持静态站点形态，不新增复杂后台；
• 通知脚本独立，不侵入抓取器；
• 支持 dry-run 和 send 两种模式；
• webhook、密钥、站点 URL 均从环境变量读取；
• 无变化无异常时不打扰群；
• 报告输出到 reports/，不写入 data/；
• 首页状态摘要需要展示更新时间、价格单位、抓取状态和异常数量。

使用 Loom 的完整流程

1打开项目页面，将文件导入项目资料的 Raw 文件夹中

在 Loom 项目中之前已经连接 GitLab 仓库：

• 仓库：zhangyy/llmprice4codatech
• 分支：main
• 资料目录：team-wiki / Raw 文件夹

导入后，Loom 可以同时读取代码仓库和项目资料。

2点击「更新Wiki」按钮，进行Wiki的更新

3给 Loom 一个任务，不额外描述项目细节

本次使用的ADE：产品经理 · Yuen，在 "个人设置-ADE管理-我的ADE" 中将ADE与项目"大模型服务价格抓取"进行关联。并在该ADE里面新建WorkSpace，进入到Chat界面，启用专家模式并输入任务Prompt。

任务 Prompt：

为大模型价格雷达增加飞书群通知能力，并顺手优化首页状态摘要。不要新增复杂后台，完成后给出实现说明和验证方式。

这个 Prompt 中没有展开具体的细节，具体口径来自ADE自己去检索项目 Wiki 中的内容。

4观察 Loom 的开发过程

i. Loom 先进行上下文收集：

• 读取项目目录结构；
• 读取 README、package.json、前端代码、数据文件和 GitHub Actions；
• 查询个人知识库、团队知识、企业知识库；
• 读取团队 Wiki 中的通知需求、项目说明、验收标准等资料。

ii. Loom 对多层知识进行了相关性筛选并总结：

本次专家模式会同时检索个人知识库、企业知识库、项目 Wiki 和代码仓库。个人知识库和企业知识库中已经沉淀了其他产品、需求和业务资料，并非空知识库；项目 Wiki 中也包含项目背景、部署说明、通用开发规范等大量内容，其中只有一部分与本次飞书通知需求直接相关。

Loom 在完成检索后，没有将所有资料不加区分地纳入开发方案，而是根据当前任务进行了相关性判断：

• 识别出个人知识库和企业知识库中暂时没有与本次任务直接相关的资料；
• 从项目 Wiki 中定位到飞书通知需求、通知配置、通知示例、验收标准和运行发布说明；
• 从代码仓库中定位到价格更新脚本、历史价格数据、抓取日志、首页渲染逻辑和自动化工作流；
• 将与本次需求无关的其他知识作为背景信息保留，没有错误地用于功能设计。

这说明专家模式并不是简单地"把所有知识都塞进上下文"，而是能够在多层知识和项目噪声中识别与当前任务直接相关的内容，再据此形成开发计划。

iii. 之后便开始制定开发计划:

iv. 任务完成：

任务完成后自动进行测试最终进行交付。

5查看代码和页面变化

Loom 完成的主要改动：

• 新增 scripts/send-lark-notice.mjs
• 检测价格变化；
• 检测抓取异常；
• 检测数据陈旧；
• 支持 --dry-run 和 --send；
• 报告输出到 reports/。
• 新增 .env.example
• 使用占位符；
• 不写真实 webhook 或密钥。
• 修改 package.json
• 增加 notify:lark 命令。
• 修改首页相关文件
• index.html
• src/app.js
• styles.css
• 更新 GitHub Actions
• 在价格更新和数据校验后增加飞书通知步骤。
• 更新 README
• 补充飞书通知能力、运行方式和验证方式。

6运行验证

Loom 执行了项目规范中要求的以下验证：

npm run validate

结果：Data OK: 88 models, 9 providers, 39 aliases, 117 prices.

执行 dry-run：

npm run notify:lark -- --dry-run

结果：

• 成功生成飞书通知预览；
• 未真实发送；
• 检测到 7 项价格变化；
• 检测到数据陈旧提醒；
• 报告保存到 reports/。

执行 send 安全检查：

npm run notify:lark -- --send

在未配置 LARK_WEBHOOK_URL 时，正确报错并退出，不会误发。

本地页面验证：

python3 -m http.server 4174

页面验证结果：

• 首页状态摘要展示 6 项统计指标；
• 右上角"飞书通知"按钮可展开设置面板；
• 页面正常加载数据。

7生成交付说明

成功生成交付说明，并按照项目资料中交付说明描述的，包含：

• 实现了哪些功能；
• 修改了哪些文件；
• 参考了哪些知识库资料；
• 如何运行和验证；
• 如何配置真实飞书群通知；
• 有哪些边界和风险。

结果对比

对比项	改造前	改造后
价格变化感知	用户主动打开页面查看	价格变化可生成飞书群通知
抓取异常感知	依赖人工检查日志	抓取异常可进入通知预览
数据陈旧	不容易发现	超过阈值后生成提醒
首页摘要	信息较少	展示供应商数、模型数、价格记录数、需复核数等
通知安全	无通知能力	webhook 和密钥来自环境变量
验证方式	手工查看为主	validate、dry-run、send 安全检查、本地页面验证

关键产物

• 飞书通知脚本：scripts/send-lark-notice.mjs
• 环境变量示例：.env.example
• 通知报告目录：reports/
• 首页状态摘要：index.html、src/app.js、styles.css
• 自动化流程：.github/workflows/update-prices.yml
• 文档说明：README.md

本次 Demo 体现的 Loom 能力

1. 知识库驱动任务执行

Loom 没有只依赖用户的一句话 Prompt，而是先查询项目资料和团队 Wiki，再基于资料形成计划。

2. 继承业务口径和边界

Loom 实现中体现了知识库中的约束：

• 不新增复杂后台；
• 使用飞书群通知，不做邮件；
• dry-run 默认不发送；
• 无变化无异常时不打扰群；
• webhook 和密钥不写入代码；
• 报告输出到 reports/，不污染 data/。

3. 结合代码仓库完成研发任务

Loom 读取了现有项目结构，并基于当前静态站点形态完成改造，而不是重新搭建一套系统。

4. 支持异常判断和交付说明

Loom 不只写代码，也给出了验证方式、安全检查和后续配置真实飞书群通知的方法。

5. 结果可验证

最终结果可以通过以下方式验证：

• 代码 diff；
• 本地页面；
• dry-run 通知预览；
• reports/ 报告；
• 数据校验命令；
• send 模式安全检查。

关键收获

知识库的价值是让 AI 在真实研发任务中继承项目背景、业务口径、代码规范、安全要求和验收方式。对于涉及多份需求文档、流程图、示例数据和现有代码的复杂任务，知识库能够把这些分散信息转化为稳定、可复用的项目上下文，减少产品经理和研发人员反复解释需求的成本。

本次 Demo 中，用户只提供了一个相对简短的开发任务，Loom 便能够主动读取项目 Wiki 和 GitLab Repo，理解现有静态站点结构，识别飞书通知、dry-run、环境变量、安全边界和首页状态摘要等要求，并据此完成开发计划、代码修改、运行验证和交付说明。

这说明，当项目资料得到持续沉淀后，知识库可以从"资料存储工具"进一步变成研发协作基础设施。它不仅帮助 AI 更准确地完成任务，也让需求依据、实现过程和验收结果都有迹可循，从而提升研发交接效率，降低信息遗漏风险，并使最终产出具备可审阅、可验证和可复现的交付质量。

这次 Demo 表面上是给一个静态站点加了飞书通知，更值得关注的是它背后的判断：当项目资料被持续沉淀，知识库会从"资料存储工具"进化成研发协作基础设施。需求依据、实现过程、验收结果都有迹可循，研发交接不必再依赖口口相传，信息遗漏风险被结构化压低，最终产出可审阅、可验证、可复现。这正是可达智灵作为工程级 AI 原生研发平台想要交付的能力底座——让数字机器人真正读懂项目，而不是每次从零猜起。