不是只改API地址:我把OpenWiki接入蓝耘元生代,完整实测代码文档生成与增量更新

承渊政道

12113人浏览 · 2026-08-13 15:37:45

承渊政道 · 2026-08-13 15:37:45 发布

🔥承渊政道：个人主页
❄️个人专栏: 《C语言基础语法知识》《数据结构与算法》《C++知识内容》《Linux系统知识》《算法刷题指南》《测评文章活动推广》《大模型语言路线学习》《MySQL数据库学习》《Python知识内容》
✨逆境不吐心中苦,顺境不忘来时路!✨ 🎬 博主简介:

我这次想验证的,不是把 API 地址换成蓝耘后,模型能不能回答一句 Hello;而是一个更严格的问题:一个会读仓库、调用工具、创建文件并持续维护文档的 Agent,能不能真正在蓝耘模型上跑完整条链路.所以我选了真实且测试完善的 Python 开源仓库 [pallets/itsdangerous][itsdangerous],先让OpenWiki生成中文项目Wiki;随后在本地加入一个可运行、可测试的新功能,再触发增量更新，检查文档是否真的跟着代码变化.过程并非"一次点亮".最初选择的DeepSeek-V3.2能返回合法的 OpenAI 风格工具调用,却先后撞上模型 ID 前导斜杠校验和实际推理通道 20K 输入上限.最终改用 deepseek-v4-flash 后,--init、--update 和 visualize 才完整闭环.

一、先看结果:这次到底跑通了什么
二、OpenWiki和蓝耘分别承担什么角色
三、环境、安装和真实仓库基线
- 1.固定版本,而不是拿"最新版"糊过去
- 2.全局安装遇到EACCES,为什么我没用sudo
四、临时Key、读取边界和脱敏配置
- 1.Key只进权限为600的本地文件
- 2.openwikiignore是成本边界,不是安全沙箱
五、模型兼容实测:V3.2为什么小请求能过,Agent 却失败
六、换用 deepseek-v4-flash,完成首次文档生成
- 1.为什么选它,而不是继续无上限重试
- 2.首轮不是"一次补全文档",而是多阶段代理流程
七、真实代码增量:297个测试变成300个
八、AI文档质量:成功生成不等于事实免审
- 1.先做机器可验证的质量门
- 2.回到源码后,我发现5个必须人工纠偏的点
九、成本、平台对比与生产边界
十、复现命令、结论与参考资料

一、先看结果:这次到底跑通了什么

验证项	实测结果
OpenWiki	0.3.1，Node.js 24.16.0，官方 npm 包
目标仓库	`pallets/itsdangerous`，commit `672971d66a2ef9f85151e53283113f33d642dabd`
原始测试基线	`297 passed`
DeepSeek-V3.2 小请求	工具调用通过，返回合法 `tool_calls` 和 JSON 参数
DeepSeek-V3.2 完整 Agent	失败：模型 ID 校验问题修复后，又遇到 HTTP 413 通道上限
最终模型	`deepseek-v4-flash`
首次生成	成功，落盘 23 个 Markdown 文件（含说明与索引文件）
真实代码增量	新增签名状态分类示例和 3 个测试，最终 `300 passed`
文档增量	3 个既有内容页定点更新、1 个内容页新增，另同步 2 个目录索引
最终可视化	24 pages、35 links，HTTP 200
最终链接检查	51 条内部 Markdown 链接，缺失 0 条
本地凭证清理	`~/.openwiki/.env` 已删除，剪贴板已清空
云端凭证清理	临时 Key `openwiki-20260809-temp` 已在蓝耘控制台撤销
实际费用	初始 ¥9.80，最终余额 ¥8.68，页面可见支出 ¥1.12

图 1：实测开始前的蓝耘模型广场，右上角可见余额为 ¥9.80。

OpenWiki 是LangChain团队开源的仓库文档 Agent.当前实测版本 0.3.1 通过 npm CLI 使用,可把代码仓库知识写入 openwiki/，并提供增量维护与本地可视化能力.

二、OpenWiki和蓝耘分别承担什么角色

OpenWiki 负责仓库理解与Agent 编排：列目录、读源码、规划文档、调用工具、写 Markdown、检查覆盖度.蓝耘元生代在这条链路里承担模型网关和推理服务：接收 OpenAI-compatible请求,把推理结果和工具调用返回给OpenWiki.

这里最容易误判的是：“接口能聊天”不等于“Agent 能跑”. 对 OpenWiki 而言,所选模型和网关还要经得住工具调用、结构化参数、长上下文、连续多轮请求以及文件操作.本次 V3.2 的经历正好证明了这一点.

我选择蓝耘的依据也很实际：账号已有 ¥9.80 余额、平台以人民币展示价格、国内访问直接,而且蓝耘公开入口提供 OpenAI 兼容调用和多模型选择.蓝耘官网宣传50+模型,但测试日无需鉴权的 /v1/models 返回 28 项;两者可能是营销口径、路由实例或上架范围不同,因此本文不把任何一个数字写成永久、绝对的模型总数.

三、环境、安装和真实仓库基线

1.固定版本,而不是拿"最新版"糊过去

本机与目标仓库如下：

macOS       26.6 (25G72)
Node.js     v24.16.0
npm         11.13.0
Python      3.13.14
OpenWiki    0.3.1
repository  pallets/itsdangerous
commit      672971d66a2ef9f85151e53283113f33d642dabd

OpenWiki 0.3.1 的 package.json 要求 Node.js >=22,本机 Node 24.16.0 满足要求.

itsdangerous 规模不大,但包含签名、序列化、时间戳、异常继承、URL-safe 编码等真实逻辑,并有完整测试.相比临时编一个Demo,它更适合验证"读代码—写文档—改代码—更文档"的闭环.

我先在隔离目录克隆并验证原始状态：

OPENWIKI_TEST_ROOT=/tmp/openwiki-lanyun-20260809
git clone --depth 1 https://github.com/pallets/itsdangerous.git \
  "$OPENWIKI_TEST_ROOT/itsdangerous"

cd "$OPENWIKI_TEST_ROOT/itsdangerous"
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e . pytest freezegun
python -m pytest -q

原始仓库结果为：

297 passed in 1.63s

2.全局安装遇到EACCES,为什么我没用sudo

按官方方式尝试：

npm install -g openwiki@0.3.1

本机在创建 /usr/local/lib/node_modules/openwiki 时返回 EACCES.我没有改系统目录权限,也没有用 sudo npm install,而是把同一个官方包安装到本次实验的隔离 prefix：

mkdir -p "$OPENWIKI_TEST_ROOT/openwiki-cli"
npm install --prefix "$OPENWIKI_TEST_ROOT/openwiki-cli" openwiki@0.3.1

"$OPENWIKI_TEST_ROOT/openwiki-cli/node_modules/.bin/openwiki" --help

CLI 帮助横幅显示 OpenWiki v0.3.1，--init、--update 和 visualize 均可用.该版本没有 --version 选项，执行后会提示 Unknown option: --version，所以版本应从帮助横幅和 npm 元数据交叉核对。

图 2：实际环境与安装结果.隔离 prefix 解决了写系统 npm 目录的权限问题.

安装过程中还有一条 deepagents / langsmith 依赖警告.我把它记录为风险,但没有把 warning 直接等同于失败;后续以真实 --init 和 --update 结果判断是否阻断.

四、临时Key、读取边界和脱敏配置

1.Key只进权限为600的本地文件

蓝耘 API Key 页面创建前是空列表：

图 3：创建临时 Key 前的 API Key 管理页.完整Key从未进入本文素材.

我创建了备注为 openwiki-20260809-temp 的临时 Key.它只临时写入 ~/.openwiki/.env,权限设置为 600;没有进入命令行参数、Git、文章或日志.

最终脱敏配置如下：

OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=<已隐藏>
OPENAI_COMPATIBLE_BASE_URL=https://maas-api.lanyun.net/v1
OPENWIKI_MODEL_ID=deepseek-v4-flash
OPENWIKI_TELEMETRY_DISABLED=1
LANGCHAIN_TRACING_V2=false

图 4：实际采用的最小配置,Key 使用占位符.

这里有两个细节：

Base URL 只写服务根路径 /v1,不要在 OpenWiki 配置里再拼 /chat/completions
模型 ID 单独放进 OPENWIKI_MODEL_ID,避免端点和路由混在一起.

2.openwikiignore是成本边界,不是安全沙箱

我用 .openwikiignore 排除 .venv/、构建产物、缓存和临时目录,并在 openwiki/INSTRUCTIONS.md 中要求使用简体中文、保留代码标识符原文、用源码和测试交叉核验.

但 .openwikiignore 不是强隔离机制.因为仓库内容会发送到 MaaS 推理服务,这次只使用无敏感信息的公开仓库;私有代码的边界会在后文单独讨论.

所有蓝耘调用结束后,我已执行并复核：

~/.openwiki/.env    已删除
macOS 剪贴板         已清空

云端临时 Key openwiki-20260809-temp 随后也已在控制台撤销.不能把"删本地文件"当成"凭证已失效",本地与云端两处都要清理.

五、模型兼容实测:V3.2为什么小请求能过,Agent 却失败

1.先用几百Token验证工具调用

蓝耘 /v1/models 当时包含：

/maas/deepseek-ai/DeepSeek-V3.2

我没有立即让它读完整仓库,而是先发送带 function/tool 定义的小请求,要求模型调用 report_connection 并返回 status=ok.

请求模型          /maas/deepseek-ai/DeepSeek-V3.2
finish_reason     tool_calls
工具名            report_connection
参数 JSON         合法，status=ok
输入 Token        506
输出 Token        45
合计 Token        551

deepseek-v4-flash 的同类探针也通过,共 356 Token.

图 5：两个真实 OpenAI 风格工具调用探针.它们证明小请求和工具参数可用,但不能替代 Agent 全流程.

2.踩坑一:真实模型ID的前导斜杠被OpenWiki拒绝

OpenWiki 能从环境文件读到 /maas/deepseek-ai/DeepSeek-V3.2,但保存配置时提示：

Paste a valid model ID.

定位到 OpenWiki 0.3.1 隔离副本中的首字符规则：

- /^[@A-Za-z0-9][A-Za-z0-9._:/@+,-]*$/u
+ /^[/@A-Za-z0-9][A-Za-z0-9._:/@+,-]*$/u

原规则允许斜杠出现在 ID 中间,却不允许它成为首字符.看似自然的两个"去斜杠"写法：

maas/deepseek-ai/DeepSeek-V3.2
deepseek-ai/DeepSeek-V3.2

都被蓝耘明确返回 model ... not found,所以不能靠猜模型名解决.本次只在临时 npm prefix 的测试副本中放宽输入校验,让蓝耘真实 ID 原样透传;没有修改 itsdangerous,也没有把补丁说成官方默认能力.

图 6：蓝耘真实模型路由与OpenWiki 0.3.1输入正则的边界.

3.踩坑二:详情页128K,不等于本次通道 128K

放宽校验后,V3.2 已连续读取仓库树、README、pyproject.toml、核心签名/序列化/时间戳模块和测试,但下一轮请求被蓝耘网关拒绝：

HTTP 413
estimated input tokens exceed maximum channel limit:
estimated=19806, max_channel_limit=20000,
safety_margin_bps=500 (effective<=19000)
code=exceed_max_input_token_limit

模型详情展示 128K,不代表这次实际路由通道就开放到128K.本次网关给出的上限是 20,000 输入 Token;再扣除 5% 安全余量,有效值约 19,000,而请求估算到 19,806.

图 7：同一模型先通过 551 Token 工具调用,再在真实 Agent 上下文中失败.两类测试不能互相替代.

这给了我一个很实用的选型原则：模型详情的理论上下文、聚合平台的元数据和某次请求实际命中的通道上限,是三件不同的事.

六、换用 deepseek-v4-flash,完成首次文档生成

1.为什么选它,而不是继续无上限重试

重新读取模型列表后,我选择 deepseek-v4-flash：

模型 ID 没有前导斜杠,可直接通过 OpenWiki 校验
测试日元数据给出 context_size=1048576
独立工具调用探针通过
测试日价格字段对应输入 ¥1/百万 Token、输出 ¥2/百万 Token
最终 --init 和 --update 均成功

图 8：选择依据是Agent 约束和成本,而不是模型榜单.价格、上下文会随平台调整.

2.首轮不是"一次补全文档",而是多阶段代理流程

在仓库根目录执行：

/tmp/openwiki-lanyun-20260809/openwiki-cli/node_modules/.bin/openwiki \
  --init --language zh-CN --modelId deepseek-v4-flash

实际日志显示,它先用 39 次动作理解仓库和源码,再用 63 次动作评审 Wiki 骨架;主体页面落盘后,question finder 提出 8 个核验问题.初检有 4 个 PARTIAL,Agent 又回到源码补齐 iter_unsigners、_base64_alphabet 等内容,最后 8 个问题全部 PASS,进程以 exit 0 结束.

图 9：从仓库理解、骨架评审、页面生成到问题补全的真实里程碑.

.last-update.json 记录：

{
  "updatedAt": "2026-08-09T15:58:53.229Z",
  "command": "init",
  "gitHead": "672971d66a2ef9f85151e53283113f33d642dabd",
  "model": "deepseek-v4-flash",
  "status": "complete",
  "language": "zh-CN"
}

首轮落盘 23 个 Markdown 文件,包括快速入门、架构、签名器、序列化器、时间签名器、异常、数据流、安全、API 和测试等主题.

图 10：首次 23 个 Markdown 文件;增量后增加到 25 个.

图 11：内容摘自首轮实际生成的 quickstart.md,不是手写替代品.

我抽查了三个可验证事实：

架构页把底层 Signer 与上层 Serializer 的关系映射到真实源码文件
TimestampSigner 页把 max_age、SignatureExpired 和 test_timed.py 对应起来
异常页给出 SignatureExpired -> BadTimeSignature -> BadSignature -> BadData 的继承链

这些都能在源码和测试中对上,但这还不代表所有生成表述都正确;后面的人审确实找到了边界问题.

七、真实代码增量:297个测试变成300个

1.先写测试,再写示例函数

只做 --init 还不能证明"持续维护".我在本地克隆中新增：

examples/signing_status_report.py
tests/test_signing_status_report.py

目标是演示同一 URLSafeTimedSerializer 生成的良构 Token 在三条典型路径上的状态：

def inspect_signing_status(
    token: str, secret_key: str, *, max_age: int
) -> dict[str, object]:
    serializer = URLSafeTimedSerializer(secret_key)

    try:
        payload = serializer.loads(token, max_age=max_age)
    except SignatureExpired as error:
        payload = None

        if error.payload is not None:
            payload = serializer.load_payload(error.payload)

        return {
            "status": "expired",
            "payload": payload,
            "message": str(error),
        }
    except BadSignature as error:
        return {"status": "invalid", "message": str(error)}

    return {"status": "valid", "payload": payload}

图 12：本地示例能力的核心分支.它不是 itsdangerous 新公共 API,也没有推送上游.

我先只添加测试,第一次收集阶段按预期失败：

ModuleNotFoundError: No module named 'examples'
exit code 2

实现后使用：

python -m pytest -q tests/test_signing_status_report.py
python -m pytest -q

得到：

3 passed in 0.03s
300 passed in 0.26s

直接执行虚拟环境中的 pytest 可执行文件时,仓库根目录没有按预期进入导入路径;改用 python -m pytest 后从当前项目根目录加载.确认根因后,我撤回了为绕开导入问题临时加过的 examples/__init__.py,只留下功能和测试两个必要文件.

图 13：原始 297 项加 3 个新用例,最终 300 项全部通过.

2.OpenWiki增量更新到底改了哪些页面

我先冻结首轮 openwiki/ 快照,再执行：

/tmp/openwiki-lanyun-20260809/openwiki-cli/node_modules/.bin/openwiki \
  --update --language zh-CN --modelId deepseek-v4-flash --print \
  "请只依据当前 Git diff 做增量更新……"

增量运行成功,最终变化是：

新增内容页 openwiki/examples/signing_status_report.md
更新 openwiki/quickstart.md
更新 openwiki/development/testing.md
更新 openwiki/backlog.md
新增 openwiki/examples/index.md 目录索引
更新根 openwiki/index.md 目录索引

所以更精确的说法是：3 个既有内容页被定点更新、1 个内容页新增,另有 2 个目录索引同步. 不是"所有页面全量重写".

图 14：增量更新读取当前工作区差异,写入受影响主题和目录索引.

更新后的 .last-update.json：

{
  "updatedAt": "2026-08-09T16:05:56.249Z",
  "command": "update",
  "gitHead": "672971d66a2ef9f85151e53283113f33d642dabd",
  "model": "deepseek-v4-flash",
  "status": "complete",
  "language": "zh-CN"
}

gitHead 没变,是因为示例只存在于本地工作区、没有 commit 或 push；OpenWiki 仍然识别到了 Git diff.

图 15：原先 backlog 中的"文件不存在"待办被移除,quickstart 和测试指南同步更新.

图 16：新增主题能解释三条分支和异常继承,但下一节会说明其中仍有需要人工收紧的表述.

3.最终可视化与链接核验

增量完成后启动官方查看器：

/tmp/openwiki-lanyun-20260809/openwiki-cli/node_modules/.bin/openwiki \
  visualize openwiki --port 4400 --no-open

实际输出：

initial scan: 24 pages, 35 links
open: http://127.0.0.1:4400

根页面返回 HTTP 200,/api/graph 也包含新增的 examples/signing_status_report 节点.

图 17：最终状态为 24 个可视化页面、35 条图谱连接.这个数字不是首轮统计.

这里又遇到一个真实收尾问题：第一次 Ctrl-C 后,4400 端口已经关闭,CLI 也打印 stopped.,但对应 Node 进程仍然存在.我先用端口和进程表确认范围,再只对精确 PID 42832 发送 TERM;复核后端口与进程才都为空.不能因为终端显示"stopped"就省略进程检查,更不能用模糊命令误杀其他 Node 服务.

我还独立解析最终 Markdown 链接：共检查 51 条内部链接,缺失0条.35 是 visualizer 的图谱边统计,51 是最终 Markdown 链接检查,阶段与口径不同,不能直接相减.

八、AI文档质量:成功生成不等于事实免审

1.先做机器可验证的质量门

最终证据链如下：

检查	结果
原始测试	297 passed
增量后全量测试	300 passed
OpenWiki 自检问题	8 / 8 PASS
内部 Markdown 链接	51 checked，0 missing
可视化	24 pages，35 links，HTTP 200
远程提交或 push	0

图 18：这些检查能证明可运行、可链接、可更新,但还不能证明每句话都准确.

2.回到源码后,我发现5个必须人工纠偏的点

OpenWiki 新页的大方向正确,但源码审计发现：

SignatureExpired.error.payload 的签名完整性和来源已由当前密钥认证,但它是待反序列化的编码载荷;即使能受控解码,也已经过期,不能继续用于授权或业务放行
SignatureExpired 不只覆盖 age > max_age，age < 0(未来时间戳或时钟偏差)也会进入 expired 分支
本次篡改样例实际抛出 BadTimeSignature,因为它继承 BadSignature,所以被父类分支捕获;不能写成"精确抛出 BadSignature"
inspect_signing_status 位于 examples/,只是一项本地示例,不属于 itsdangerous 公共API;生成页把它标成 public-api 过头了
对任意畸形输入,serializer.loads 或 load_payload 仍可能抛出未捕获的 BadPayload;当前三分类只被 3 个良构样例覆盖

图 19：保留原始生成结果,并在正文紧邻截图给出人工纠偏,而不是把模型输出悄悄修饰成完美答案.

这是我认为本次最有"落地感"的结论之一：OpenWiki 很适合快速建立知识骨架和变更导航,但代码、异常语义、权限语义仍需要维护者审核.尤其"密码学上已认证"和"业务上仍可信"绝不能混为一谈.

九、成本、平台对比与生产边界

1.只按最终余额核算,不拿标价冒充账单

实测前可见余额为 ¥9.80,调用后最终余额为 ¥8.68,因此页面可见总支出是 ¥1.12.这个差额包含两次工具调用探针、V3.2 失败尝试、deepseek-v4-flash 首次生成和增量更新;我没有把模型标价乘以估算 Token 冒充账单.

图 20：最终余额来自蓝耘控制台人工读数,云端 Key 撤销由用户确认;本图是收尾记录卡,不是平台 UI 截图.

降低这类 Agent 实验成本,最有效的做法不是只看最低单价,而是：

先用几百 Token 的工具调用探针排除明显不兼容
用 .openwikiignore 排除虚拟环境、构建产物和缓存
用 INSTRUCTIONS.md 收紧文档目标
保存首轮快照,后续用 --update 做差异维护
对失败设预算和停止条件,不做无限重试

2.蓝耘、OpenRouter、AI Ping的克制对比

这次只有蓝耘完成了真实 OpenWiki 接入;OpenRouter 与 AI Ping 来自各自官方公开资料,不是同机同仓同模型压测.因此下面比较接入与公开能力,不做性能排名.

维度	蓝耘元生代	OpenRouter	AI Ping
本文证据	实机接入、错误、生成与更新	官方文档和公开 API	官方文档和公开 API
OpenWiki 接入	`openai-compatible`	有专用 provider，也可兼容接入	OpenAI 兼容入口
模型规模口径	官网 50+；测试日公开 `/models` 返回 28 项	官方称 400+ 模型、70+ provider	官方称 400+ 模型与服务商；公开 API 当时 141 records
费用公开	单模型人民币 Token 价格；以当日账单为准	购买 PAYG credits 收 5.5%，最低 US$0.80	价格随模型和路由服务商变化
路由特点	公开材料强调智能路由与混合算力	多 provider、BYOK、隐私过滤与 ZDR	按价格、P90 延迟、吞吐、可靠性筛选和回退
公开限流	未找到统一数字 RPM/TPM 表	随模型和 provider 变化	L1/L2/L3：20/100/200+ RPM
数据治理公开度	未找到足够具体的留存期、训练用途和 ZDR 条款	默认不保存 prompt/completion，但上游政策仍适用；可启用 ZDR	未找到统一明确的留存期和 ZDR 条款

OpenRouter 的模型覆盖和治理选项披露更完整,但仍要评估平台费、上游 provider 和跨境边界.AI Ping 的性能指标路由有特色,公开文档还给出了 20/100/200+ RPM 的试行分级.

我选择蓝耘的结论只是：它符合本次已有余额、人民币计费、国内访问和实测目标,并最终承载了 OpenWiki 的首次生成与增量更新.这不等于它在所有维度全面胜出.

3.最大风险不是安装,而是代码数据治理

本次成功能证明的是：在测试日账号、模型、网络与这个公开仓库条件下,OpenWiki 0.3.1 可以经蓝耘 deepseek-v4-flash 生成并更新项目 Wiki.

它不能证明：

私有代码适合直接发送到第三方 MaaS
平台一定零留存、不会用于训练或满足某组织合规要求
模型详情页的上下文在每条实际通道都兑现
一个小型仓库成功可以外推到大型 monorepo
51 条链接都存在就代表每句话都正确
自动生成可以替代维护者审阅

本次检索蓝耘公开材料时,没有找到足够具体的代码/提示词保留期、训练用途、ZDR 和独立可核验 SLA.准确表述只能是"公开资料中没有找到",不能反推平台一定没有这些机制.

处理企业私有仓库前,我会要求书面确认租户隔离、日志、留存、删除、训练用途、跨境、失败回退和 SLA,再决定是否接入.OPENWIKI_TELEMETRY_DISABLED=1 只关闭 OpenWiki 自身遥测,不代表模型请求不会离开本机.

十、复现命令、结论与参考资料

1.最小复现命令

# 1. OpenWiki 0.3.1 要求 Node >=22
node --version

# 2. 隔离安装官方包
OPENWIKI_TEST_ROOT=/tmp/openwiki-lanyun-20260809
mkdir -p "$OPENWIKI_TEST_ROOT/openwiki-cli"
npm install --prefix "$OPENWIKI_TEST_ROOT/openwiki-cli" openwiki@0.3.1

# 3. 在目标仓库首次生成
cd "$OPENWIKI_TEST_ROOT/itsdangerous"
"$OPENWIKI_TEST_ROOT/openwiki-cli/node_modules/.bin/openwiki" \
  --init --language zh-CN --modelId deepseek-v4-flash

# 4. 代码变化后增量更新
"$OPENWIKI_TEST_ROOT/openwiki-cli/node_modules/.bin/openwiki" \
  --update --language zh-CN --modelId deepseek-v4-flash --print \
  "请只依据当前 Git diff 做增量更新"

# 5. 本地可视化
"$OPENWIKI_TEST_ROOT/openwiki-cli/node_modules/.bin/openwiki" \
  visualize openwiki --port 4400 --no-open

脱敏配置模板：

OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=<仅写入本机临时环境文件，不要提交>
OPENAI_COMPATIBLE_BASE_URL=https://maas-api.lanyun.net/v1
OPENWIKI_MODEL_ID=deepseek-v4-flash
OPENWIKI_TELEMETRY_DISABLED=1

2.我的最终判断

这次结果比"换 Base URL 成功"更有说服力：

V3.2 先证明了工具调用可用,又暴露模型 ID 和实际通道上下文两层问题
deepseek-v4-flash 真正完成仓库读取、文件生成和增量更新
代码从 297 个测试增长到 300 个且全部通过
文档更新范围能逐页指认,不是全量覆盖
最终 24 个可视化页面、35 条图谱边和 51 条内部链接都有独立证据
人工审计又发现 5 个模型表述边界，证明"生成完成"不等于"无需审阅"

如果场景是公开仓库、中小型项目、内部原型,或者希望快速建立代码知识导航层,OpenWiki 接入蓝耘值得实测.对于大型私有仓库,我不会只凭这一次成功直接上线,而会先处理数据治理、实际通道上限、预算、超时、失败回退和人工审核.

对我而言,本次最重要的结论不是某个模型榜单分数，而是：自动文档 Agent 的平台适配,最终必须用工具调用、真实上下文、文件产物、代码变更、增量更新和人工审计共同验收.

3. 参考资料

蓝耘科技企业级大模型统一网关与调度平台.https://maas.lanyun.net/v1
OpenWiki官网平台.https://github.com/langchain-ai/openwiki
AI Ping延迟测试：https://aiping.cn/

🚀真正的勇者不是流泪的人,而是含泪奔跑的人!

敬请期待下一篇文章内容

每日心灵鸡汤: 低谷不是终点,你要一直相信自己!

凌晨还没睡,写下这段话想要激励的千千万万个和我一样身处逆境的同志.我想要告诉你们,未来一定是充满希望的,要坚定,无条件,绝对相信自己无极限.在没人的地方,也要做自己最忠实的信徒,要从心底里坚定做自己最虔诚的信徒.所谓的命运,是你自己给自己设定的上限,年轻,不要在低谷期一味否定自己本身,迷茫焦虑痛苦的事情本来就是人生课题.没有痛苦,何来成长,没有成长,哪里蜕变.我明白我们目前遇到了人生一个难跨过去的坎,可是要加油啊!你不是一个人,无论什么时候遇到了怎么样的困难,都请你记住,全中国,乃至全世界,都有和你我一样千千万万的人儿在努力去想办法去解决问题,我相信你一定可以的!我们不用和别人比较什么,我们现在就看自己本身就好了,那些事情,以后做,好吗?无论什么时候,请一定务必要相信自己,遵循自己最开始的初心,要无条件去帮助自己在人生路上努力向前走,就算苦点累点无所谓,干就完了,天塌不下来,我们都去多尝试,成功了最好,失败了就当积累经验,总之就是别让自己闲下来,找一点事情忙起来.没有人谁的人生会因为一俩件事情就完蛋的.要有可以把一切事情做完蛋的决心去做成功一件事情就行了.我们普通人的人生没有那么多波涛骇浪,起码目前没有,你就好好爱自己,该吃饭休息就好好搞,身体是革命本钱,别为了一些事情和人做内耗焦虑,不值得.你给我记住,你的人生只有你自己可以做主,你一辈子要做的以前就有一件事就是:做自己.好了,不说了,睡觉,明天上班.加油,相信自己.