返回板块

G04 WorkBuddy应用技术标准

前言

目次

前言

1 第一篇 目的与底层逻辑

1.1 范围与目的

1.1.1 适用范围

1.1.2 本标准解决什么问题（用途与目的）

1.1.3 编制目的

1.2 总体方法论与底层逻辑

1.2.1 总体方法论

1.2.2 底层逻辑

1.2.3 认知入口

1.2.4 规范性引用文件

1.2.5 术语与定义

1.2.6 规范性要求等级说明（RFC 2119）

2 第二篇 WorkBuddy 能力体系与逻辑结构

2.1 能力体系

2.1.1 四大能力模块总览

2.1.2 任务执行能力

2.1.3 插件能力

2.1.4 技能能力

2.1.5 专家能力

2.2 协同逻辑结构

2.2.1 三者协同框架

2.2.2 协同应用示例

2.3 全生命周期模型

3 第三篇 具体应用方法论：量产专利多模型协作

3.1 应用总则与路线选择

3.1.1 应用总则

3.1.2 路线体系

3.1.3 决策路由

3.2 规则条目（R1–R13）

3.2.1 规则五要素

3.2.2 能力使用规则（R1–R5）

3.2.3 应用方法论规则（R6–R13）

3.3 模型路由与编排

3.3.1 四阶段流水线

3.3.2 模型路由表

3.4 各路线与方案操作要点

3.4.1 路线 A（Coze / Dify，零代码）

3.4.2 路线 B（WorkBuddy 侧）

3.4.3 路线 C（安装软件）

3.4.4 方案②（API 程序化，开发向）

3.5 量产工程化

3.6 质量闸门与排错

3.6.1 四道质量闸

3.6.2 量产必踩的坑

3.7 判定标准与合规检查清单

3.7.1 判定标准（量化锚点）

3.7.2 合规检查清单（含责任人与复核频率）

3.8 命名落盘与交付合规

4 第四篇 监督、文档管理与版本历史

4.1 监督与违规处置

4.2 文档管理与版本历史

4.2.1 修订记录

4.2.2 审批记录

4.2.3 标准评审机制

4.2.4 定稿校核结论

附录 A

A.1 规则条目速查表

附录 B

B.1 端点与模型速查（2026-08-30 核验）

附录 C

C.1 工具链与规范索引

附录 D

D.1 决策路由表

附录 E

E.1 排错速查表

本标准依据 GB/T 1.1-2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。

版本：V1.3.0 ｜ 编制日期：2026-09-02 ｜ 状态：正式基准（已发布）· 全域强制

适用范围：利衡辨体系内 WorkBuddy 平台的应用治理——覆盖四大能力模块（任务执行 / 插件 / 技能 / 专家）的使用规范，以及以「量产专利多模型协作」为代表的规模化应用方法论

权威关系：本文与 MEMORY.md（含 §〇 区域路由与四盘同步架构）、S01–S11、《全域文件工作流规则技术标准》V2.2.0、《全域文件命名规则技术标准》V1.1.0 一致、互为备份；冲突时以 MEMORY.md 为最终权威

上位关系：本文为《全域文件工作流规则技术标准》V2.2.0（Q/WB-WF-2026-002）的下位应用标准，居五层认知框架 L3 规则层（应用侧）；命名、落盘、四件套等治理底座条款以《全域文件命名规则技术标准》V1.1.0 与《四件套强制交付物断言技术标准》V1.0.0 为准

成文基准（强制）：本文的成文逻辑与格式体例遵循《MASTER RULE · 技术标准成文规范》V1.0.0（STD-A/B/C/D/E/F/G/H/Z 共 72 条）。成文格式类问题以该母规则为唯一基准；业务领域内容以本文为准

合并来源（V1.0.0 首版）：本文由《WorkBuddy 说明作文》（能力模块篇）与《量产专利完整手册 · 专业版 V1.1》（应用方法论篇）两份文档合并、统一术语与编号层级、按本文体例重写而成；两份源文档内容均完整纳入，未作删减

· 标准编号：Q/WB-APP-2026-001（暂定，待正式发布时确认）

· 文档版本：V1.3.0 ｜ 生效日期：2026-09-02 ｜ 编制：全域文件治理工作组 & 技术标准委员会

· V1.3.0 升级说明（排版修订）：本次为排版升级——依据技术标准排版助手 V1.7.0 国标引擎落实 4 条最新格式要求（①表格单元格左右边距 0.05cm、表格统一中部左对齐；②图片周边留白 ≤1mm；③正文段落首行缩进 2 字符；④每页页脚显示「第X页共Y页」）；正文条款、规则（R1–R13）及两份源文档内容均保持不变。

· V1.2.0 升级说明（补图修订）：本次为补图修订——依据技术标准排版助手 V1.6.0 国标引擎补入两类必备可视化认知入口图（逻辑思维简图 + 生命周期逻辑结构图），闭合母规则 STD-C-011（P1 阻断级）对技术标准类文档的强制要求；正文条款、规则（R1–R13）及两份源文档内容均保持不变。

· V1.1.0 升级说明（排版修订）：本次为排版升级——依据技术标准排版助手 V1.5.2 国标引擎（GB/T 1.1 版式）重排版，补全静态目次，标题编号由「四篇内编号」升级为 GB 章条连续编号（四篇对应第 1~4 章），表题改由引擎自动编号；正文条款、规则（R1–R13）及两份源文档内容均保持不变。

· V1.0.0 首版说明：本标准以《全域文件工作流规则技术标准》V2.2.0 的四篇式结构与行文逻辑为成文模板，将 WorkBuddy 平台的能力体系（任务执行、插件、技能、专家四大模块及其协同）固化为第二篇「能力体系与逻辑结构」，将以「量产专利多模型协作」为代表的规模化应用方法论（路线选择、模型路由、Key 安全、量产工程化、质量闸门、命名落盘与四件套交付合规）固化为第三篇「具体应用方法论」。能力使用规则编为 R1–R5，应用方法论规则编为 R6–R13，共 13 条，均按「规则五要素」（触发条件 / 执行动作 / 责任人·角色 / 例外处理 / 校验方式）落写，确保可被工具链自动校验。

1 第一篇 目的与底层逻辑

1.1 范围与目的

1.1.1 适用范围

本标准规定了利衡辨体系内 WorkBuddy 平台的应用治理规则，覆盖四大能力模块（任务执行 / 插件 / 技能 / 专家）的规范使用，以及规模化应用（以「量产专利多模型协作」为代表）的路线选择、模型路由、工程化与交付合规全流程。

· 对象范围：WorkBuddy 平台四大能力模块及其协同；规模化应用中的外部模型（DeepSeek / Kimi / 豆包 Seedream / 通义千问 / 智谱 GLM 等）与编排平台（扣子 Coze / Dify / n8n / LangChain）。

· 流程范围：需求描述 → 能力调用 → 路线选择 → 模型路由 → 批量产出 → 质量校验 → 命名落盘 → 四件套交付。

· 角色范围：应用发起人、流水线维护人、模型 Key 保管人、质量复核人、档案管理员。

· 系统范围：WorkBuddy 平台（任务执行 / 插件 / 技能 / 专家 / 自动化）、各模型平台控制台、各编排平台。

排除范围：纯个人即时问答、一次性临时尝试（未纳入规模化交付流程的）不纳入本标准第三篇管控；自纳入规模化交付（批量产出、定时自动化、跨模型编排）起适用本标准第三篇。「纳入规模化交付」的判定：由发起人将产出按 R12 规范命名并纳入治理目录即视为纳入，判定责任人为应用发起人。

1.1.2 本标准解决什么问题（用途与目的）

本标准解决的核心问题：把分散在「能力怎么用」与「应用怎么规模化落地」两端的零散经验，收敛为一套可识别、可执行、可校验的统一规则体系，使 WorkBuddy 从「单点能力」到「规模化交付」的每一步都有规则可依、有角色可追、有闸门可验。治理的失效模式与本版治理条款对照：

表1-1 失效模式与本版治理条款对照

失效模式	表现	本版治理条款
指令模糊	需求描述笼统，任务执行产出偏差大	R1 + 2.1.2
工具盲装	社区技能未经安全审查直接安装	R3（skill-vetter 审查）+ 2.1.4
模块定位不清	插件 / 技能 / 专家混为一谈，协同低效	R5 + 2.2
路线错配	能用成熟 skill 却自建流水线，成本失控	R6 + 3.1.3
模型漂移	模型名 / 端点过期，跑批前未核对	R9 + 附录 B
密钥泄露	API Key 硬编码进脚本 / 仓库 / 群	R8 + 3.4
批量失控	无限流、无重试、无断点，跑一半全挂	R10 + 3.5
质量无闸	产出无结构 / 雷同 / 新颖性校验	R11 + 3.6
落盘不合规	文件名无时间戳、直落工作区根	R12 + 3.8
交付不齐	docx/xlsx 交付物缺治理四件套	R13 + 3.8

1.1.3 编制目的

（1）统一能力认知：把任务执行、插件、技能、专家四大模块的定位、边界与协同关系收敛为一份可被全员调用的统一标准，杜绝「工具装了一堆、不知道怎么组合」的碎片化困境。

（2）固化应用方法论：把已验证的「量产专利多模型协作」路线选择、模型路由、工程化与交付合规方法固化为可复用的规则条目。

（3）可执行可校验：每条规则以 5 字段结构落写，确保任何一条规则都能被脚本 / 工具自动校验。

（4）对齐治理底座：命名、落盘、四件套等条款与《全域文件命名规则技术标准》V1.1.0 及全域工具链硬闸门严格对齐，杜绝「写出来却无法合规落地」。

1.2 总体方法论与底层逻辑

1.2.1 总体方法论

本标准遵循「能力做认知入口，规则做应用底座」的成文逻辑，四条方法论支柱：

· 能力做认知入口：先建立四大能力模块的全局认知，让使用者在 30 秒内理解「插件是手、技能是脑、专家是人格」的定位。

· 规则做应用底座：每条应用规则必须有可被统计、可被审计的量化锚点，不允许「按惯例」「原则上」等无量化锚点描述。

· 协同优于堆砌：价值不在于单一模块的功能，而在于任务执行、插件、技能、专家的组合协同。

· 不丢治理严谨性：规模化应用不替代治理，每条规则配套可自动校验的判定标准与闸门。

1.2.2 底层逻辑

WorkBuddy 应用的底层逻辑是「能力 → 协同 → 规则 → 闸门 → 反馈」的五阶闭环：

· 能力：四大能力模块（任务执行 / 插件 / 技能 / 专家）各司其职，落字为据；

· 协同：模块之间以「手 / 脑 / 人格 / 行动力」框架组合，形成完整工作流；

· 规则：所有应用动作必须先有规则条目（R1–R13）；

· 闸门：规则输出作为应用流程入口 / 出口的硬闸门，不合规即拦截（命名闸、四件套闸、区域闸）；

· 反馈：闸门触发的每一次拦截 / 告警回流到规则库与版本清单，形成持续迭代的反馈环。

规则即代码（实现层）：每条规则等价于一段可执行代码，由触发条件、输入参数、执行动作、返回值、异常分支五要素构成。本标准要求规则「可被编码」，但标准正文本身不嵌入具体脚本名——具体实现以附录 C 工具链清单为准，二者解耦演进。

1.2.3 认知入口

本标准的认知入口为第二篇「WorkBuddy 能力体系与逻辑结构」：四大能力模块（任务执行 / 插件 / 技能 / 专家）构成能力层，三者协同框架（手 / 脑 / 人格 / 行动力）构成协同层，层间依赖为「能力支撑协同、协同反哺能力」。建议读者在通读第三篇应用方法论前，先通读第二篇建立全局认知。

图1-1 WorkBuddy 应用逻辑思维简图

注：本图回答「为什么这样组织」——自顶向下的分层认知框架与层间依赖关系

1.2.4 规范性引用文件

下列文件对于本标准的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本标准；凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本标准。

· 《全域文件工作流规则技术标准》V2.2.0（Q/WB-WF-2026-002，上位治理框架）

· 《全域文件命名规则技术标准》V1.1.0（N1，命名底座）

· 《全域文件排版规则技术标准》V1.0.2（排版基线）

· 《四件套强制交付物断言技术标准》V1.0.0（交付合规深检）

· 《MASTER RULE · 技术标准成文规范》V1.0.0（成文母规则）

· GB/T 1.1-2020 标准化工作导则 第1部分：标准化文件的结构和起草规则

· S01–S11 全域 SOP

· WorkBuddy 全域长期记忆（MEMORY.md，含 §〇 区域路由与四盘同步架构）

1.2.5 术语与定义

表1-2 术语与定义

术语	定义
WorkBuddy	利衡辨体系内把工作落到实处的 AI 助手，通过任务执行、插件、技能、专家四大模块协同带来整体效率跃升
任务执行	WorkBuddy 根据需求描述自动拆解步骤、逐步执行、交付成果的能力，是其区别于聊天式 AI 的核心行动力
插件	基于 MCP 协议运行、扩展 AI 操作能力边界的工具，安装后后台静默待命、按需自动调用
技能（skill）	给 AI 注入专业知识、扩展其知识深度的能力单元，与插件「扩展能力边界」本质不同
专家	拥有名字、专业领域与工作风格的专业角色，以垂直领域顾问视角回答问题
三者协同	「插件是手、技能是脑、专家是人格」的组合框架，配合任务执行（行动力）构成完整工作流
模型路由	把一项应用任务拆成多个串行阶段，每个阶段路由到最擅长模型的编排方式
流水线	上游文本产出作为下游输入、由调度脚本 / 节点引擎用变量串联的串行处理链
API Key	调用外部模型的凭证，sk- 开头；须走环境变量 / 密钥管理，禁止硬编码
端点（base_url）	模型服务的网址，每个平台不同；图像接口与对话接口不共用端点
量产	「一次写几十上百篇」的规模化、无人值守产出场景
四道质量闸	结构完整 / 文本雷同 / 规范查新 / 交付合规四道质量校验门
交底书	方法类发明专利技术交底书，含权项、说明书、附图、结构图四段
治理四件套（Class B）	技术规范要求 Word / 摘要 Word / 变更履历 Excel / 版本清单 Excel 四件治理文件，缺一不可

1.2.6 规范性要求等级说明（RFC 2119）

表1-3 规范性要求等级（RFC 2119）

关键词	英文	含义
必须 / MUST	MUST	强制性要求，违反即为不合规
应 / SHOULD	SHOULD	推荐性要求，在特定情况下可偏离，但需记录理由
宜 / RECOMMENDED	RECOMMENDED	建议性要求，优先采用但非强制，不采用时宜说明原因
可 / MAY	MAY	允许的选项，不构成强制；仅表示许可，表示能力时用「能够」
禁止 / MUST NOT	MUST NOT	严格禁止的行为

所有条款若未特别标注，均视为「必须」级别。若条款使用「应」「宜」「可」等词，则按上表执行。

2 第二篇 WorkBuddy 能力体系与逻辑结构

2.1 能力体系

2.1.1 四大能力模块总览

表2-1 四大能力模块认知框架

模块	定位（协同角色）	核心职责	关键产物
任务执行	行动力	拆解需求、逐步执行、交付成果	落盘成果（图表 / 报告 / 文件）
插件	手	基于 MCP 操作外部系统与服务	外部能力调用结果
技能	脑	注入专业知识，提升处理准确性与效率	知识增强的产出
专家	人格	以垂直领域顾问视角回答专业问题	专业咨询意见

注：四大模块并非相互替代，而是「行动力 + 手 + 脑 + 人格」的互补协同；模块定位是2.2.1的认知基础。

2.1.2 任务执行能力

WorkBuddy 最核心的差异化能力是任务执行：使用者只需在输入框里尽可能详细地描述需求，它便会自动拆解步骤、一步步执行，最后把成果交到使用者手上。例如「把这份 Excel 销售数据整理成图表，存到桌面报告文件夹」，WorkBuddy 会分析数据结构、生成柱状图和折线图，再把文件保存到指定位置。

关键原则：说得越细，做得越准。 模糊的指令如「帮我整理一下文件」，不如「把 Downloads 里所有 PDF 移到 D:/资料/PDFs，按文件名日期重命名」来得高效。这种真正能动手完成的能力，让 AI 从建议者变成了执行者。

2.1.3 插件能力

如果说任务执行是 WorkBuddy 的「行动力」，那么插件就是它的「工具手」。插件基于 MCP 协议运行，安装后会在后台静默待命；当使用者发出需求，AI 会自动判断是否需要调用插件。例如安装「微信公众号搜索插件」可搜索公众号文章、安装「腾讯地图插件」可查路线、安装「文件系统插件」可操作本地文件夹。使用时直接提需求即可，不必特意说「用某某插件」，AI 会自己判断和调用。插件扩展的是 AI 的能力边界，让它长出真正的手脚。

2.1.4 技能能力

技能与插件很像，但本质不同：插件扩展的是 AI 的能力边界，技能扩展的是 AI 的知识深度——技能是给 AI 注入专业知识，让它懂得怎么做得更好。WorkBuddy 自带上百个预设技能，开箱即用；使用者也可访问官方技能市场 skillhub.tencent.com 或社区市场 clawhub.ai，复制安装指令后在「技能」面板粘贴安装。

安全警示（必须）：安装社区技能前务必先用 skill-vetter 做安全审查，因为技能本质上是代码，来路不明的技能可能存在安全风险。

2.1.5 专家能力

如果说技能和插件都是「工具」，专家则更像「人」。每一位专家都有自己的名字、专业领域和工作风格。WorkBuddy 目前上线了 12 大领域、141 位专家，全部按企业真实职能分工设计，涵盖营销运营、内容创作、市场分析、产品经理、用户研究等方向。使用时，只需在任务页面顶部找到「专家」入口，按领域浏览并召唤需要的专家，然后在对话框里告诉它你的需求。专家模式的核心优势在于：它不是通用 AI 在泛泛而谈，而是懂行的人在认真回答你的专业问题。

2.2 协同逻辑结构

2.2.1 三者协同框架

很多人安装了一堆工具，但不知道怎么组合。WorkBuddy 给出一个简单的理解框架：

表2-2 三者协同框架

协同角色	对应模块	作用
手	插件	让 AI 能操作外部系统
脑	技能	让 AI 懂得怎么做得更好
人格	专家	让 AI 以专业视角来回答问题
行动力	任务执行	把需求拆解并真正落地执行

核心结论：WorkBuddy 最大的价值不是单一功能的强大，而是各模块协同之后的整体效率提升——把聊天式 AI 升级为能听需求、调工具、用知识、扮角色的执行型工作伙伴。

2.2.2 协同应用示例

以一个内容博主的需求为例：「每周自动收集行业动态并发布」。第一步，安装微信公众号搜索插件、网页浏览插件，让 AI 能搜集内容（手）；第二步，启用 summarize 技能快速总结、humanizer 技能优化文笔（脑）；第三步，召唤「内容创作专家 Kai」，让他以专业内容人的视角把信息组织成高质量推文（人格）；第四步，把整套流程设置成每周一自动触发，结果推送到企业微信（行动力）。这就是 WorkBuddy 各模块协同之后的完整工作流。

2.3 全生命周期模型

WorkBuddy 应用的规模化交付遵循八阶段生命周期（对应第一篇「范围与目的」的流程范围）：需求描述 → 能力调用 → 路线选择 → 模型路由 → 批量产出 → 质量校验 → 命名落盘 → 四件套交付。每个阶段以「触发条件 / 责任人 / 校验方式」三要素落写，末节点经回退 / 例外通道回并校验节点，形成闭环治理。

图2-1 WorkBuddy 规模化应用生命周期逻辑结构图

注：本图回答「每一步做什么」——各阶段触发条件、责任人、校验方式与例外回路

3 第三篇 具体应用方法论：量产专利多模型协作

3.1 应用总则与路线选择

3.1.1 应用总则

（1）成熟 skill 优先于自建流水线：能用成熟 skill（如「利衡辨_电池专利助手」）覆盖的场景，优先用 skill，不自建流水线。

（2）路线匹配场景：先选对路线再动手，避免「偶尔写一篇却搭了整套 API」或「要量产却用手动复制粘贴」。

（3）Key 安全优先：任何外部模型调用，Key 一律走环境变量 / 密钥管理。

（4）可校验优于可读：产出须能被量化校验（结构完整 / 雷同 / 新颖 / 交付合规）。

（5）可追溯优于一次性：所有动作必须留痕、落盘合规、配套四件套。

3.1.2 路线体系

量产专利多模型协作存在三种方案与六条路线，统一收编如下：

表3-1 路线体系总览

方案	路线	形态	是否需要写代码	是否真·自动串联	适合人群
① 手动编排	—	复制粘贴	否	偶尔写、零代码
② API 程序化	路线 C（n8n / LangChain）+ 开发脚本	代码控制	是（Python 为主）	是	开发者、批量产出
③ 编排平台 / 智能体	路线 A（Coze / Dify）、路线 B（WorkBuddy 侧）、n8n	节点引擎	否（画工作流）	是	非程序员、常跑固定流程

· 路线 A：扣子 Coze / Dify，纯网页零安装，拖拽搭工作流；

· 路线 B：WorkBuddy 侧，含 B+（直接用专利助手 skill，推荐）、B-1（自建自动化流水线）、B-2（接 MCP 真调外部模型，进阶）；

· 路线 C：本地安装软件（n8n / LangChain），导入现成工作流 / 脚本运行。

3.1.3 决策路由

表3-2 路线决策路由表

你的情况	走哪条	理由
在利衡辨体系内、要合规交付	路线 B+（专利助手 skill）	自带两步耦合检测与 13 维校验，产出天然合规
只想偶尔写 1–2 篇、不想装任何东西	路线 B+ 或路线 A（Coze）	零安装，分钟级出稿
要定时自动跑、主题批量轮换	路线 B-1（自建自动化）	一次配置，按 rrule 触发
要可视化搭、可导出 JSON 复用	路线 C（n8n）	文件可移植
开发者、一次产几十上百篇	路线 C（API 程序化）	成本最低、可控性最高

核心原则：能用成熟 skill 就不要自建流水线；自建流水线只在 skill 覆盖不到（如跨模型 A/B 对比、大规模并发）时才值得。

3.2 规则条目（R1–R13）

3.2.1 规则五要素

表3-3 规则五要素

字段	含义	写法要求
触发条件	什么情况下该规则被触发	用「当/如果」开头，描述可观测事件
执行动作	规则触发后具体做什么	用动词开头，给出可被脚本调用的具体动作
责任人/角色	谁负责执行	给出具体角色名（不写「相关部门」）
例外处理	什么情况可豁免或走特殊通道	给出例外触发条件 + 回退路径
校验方式	如何验证规则被正确执行	给出可被工具链自动校验的指标或方法

3.2.2 能力使用规则（R1–R5）

表3-4 能力使用规则（R1–R5）

编号	触发条件	执行动作	责任人/角色	例外处理	校验方式
R1	发起任务执行	尽可能详细描述需求（目标 + 范围 + 输出格式 + 落盘位置），由 WorkBuddy 拆解执行	应用发起人	需求本身动态演化时，可分轮次补充细化	产出与需求描述逐项比对，偏差项 0 未说明
R2	使用插件能力	直接提需求，由 AI 自动判断并调用对应 MCP 插件，无需显式指定插件名	应用发起人	需指定插件时可显式点名，AI 优先采用	调用日志记录插件名与触发时机，100% 留痕
R3	安装社区技能（skillhub / clawhub）	先过 skill-vetter 安全审查，确认无风险后再粘贴安装	应用发起人 + 技能审查人	官方内置技能（WorkBuddy 自带）可跳过审查	安装记录含审查结论，无审查即阻断安装
R4	召唤专家	从「专家」入口按领域浏览并召唤，在对话框中说明需求	应用发起人	需求跨领域时召唤多专家协同	召唤记录含专家名与领域，与需求领域匹配
R5	多模块组合使用	按「插件=手 / 技能=脑 / 专家=人格 / 任务执行=行动力」框架组合	应用发起人	单一模块可满足时不强制组合	组合方案与「手/脑/人格/行动力」框架映射完整

3.2.3 应用方法论规则（R6–R13）

表3-5 应用方法论规则（R6–R13）

编号	触发条件	执行动作	责任人/角色	例外处理	校验方式
R6	启动规模化应用（量产 / 定时 / 跨模型）	先按决策路由选对路线；能用成熟 skill 优先用 skill	应用发起人	skill 覆盖不到的（跨模型 A/B、大规模并发）才自建流水线	路线选择与决策路由表匹配，偏离须书面说明
R7	编排多模型流水线	把任务拆为 4 个串行阶段（逻辑权项 / 说明书润色 / 附图 / 结构图），上游产出喂下游	流水线维护人	无需附图 / 结构图时可减阶段	阶段数与产出结构一致，缺段即告警
R8	使用外部模型 API	Key 一律写入环境变量 / 密钥管理，禁止硬编码进脚本 / 仓库 / 群	模型 Key 保管人	无（Key 泄露即泄密，不设豁免）	代码扫描无 sk- 明文，命中即阻断
R9	跑批 / 发布前	核对各平台 /v1/models 与端点版本（国内外端点不通用、图像独立端点）	流水线维护人	首次接入新平台可先小样本验证	模型名与端点命中附录 B 速查表，过期即告警
R10	批量产出	批量 + 并发（控 max_workers）+ 重试退避 + 断点续跑，先小批量测通再放大	流水线维护人	单篇产出可跳过并发与断点	失败主题落 failed.txt，重试退避与并发上限可查
R11	产出交付前	过四道质量闸（结构完整 / 文本雷同 / 规范查新 / 交付合规）	质量复核人	附图精度不达标时 Mermaid 转矢量 + 人工核标号	四闸判据逐项通过，未通过即打回
R12	产出落盘	先建时间戳任务夹（<标题>_<YYYY-MM-DD_HHMM>/产出	素材/），禁止直落工作区根	应用发起人 + 档案管理员	无（错名 / 直落根一律被门禁拒绝）
R13	docx/xlsx 交付物产出	配套治理四件套（技术规范要求 / 摘要 / 变更履历 / 版本清单）同目录齐出	应用发起人	无（缺一件即判定未交付）	四件套齐全校验退出码 0，缺件即阻断

与既有规则关系：R12 引用《全域文件命名规则技术标准》V1.1.0 与 S01/S02；R13 引用《四件套强制交付物断言技术标准》V1.0.0；R6–R10 为本文新增应用方法论规则。

3.3 模型路由与编排

3.3.1 四阶段流水线

把「写一篇专利交底书」拆成 4 个串行阶段，每个阶段路由到最擅长的模型；上游文本产出作为下游输入，全程由调度脚本用变量传递，无需人工搬运：

· stage1 逻辑与权项 [DeepSeek / 智谱 GLM] → 输出技术问题 / 方案 / 效果 + 独立权项 + 从属权项；

· stage2 说明书润色 [Kimi / 通义千问] → 输入 = stage1 文本，输出通顺书面语说明书（摘要 / 背景 / 实施方式）；

· stage3 附图 [豆包 Seedream / 即梦] → 输入 = stage2 技术方案，输出附图提示词 + 图；

· stage4 结构图 [通义千问 / DeepSeek] → 输出方法流程图 + 系统架构图（Mermaid 矢量可编辑）。

3.3.2 模型路由表

表3-6 模型路由表（推荐，可替换）

阶段	推荐模型	用途	接口特点
1 逻辑 / 权项	deepseek-v4-pro（备选 智谱 GLM）	严密法理层级、权利要求	OpenAI 兼容、成本低、推理强
2 说明书润色	kimi-k3（备选 通义千问）	中文书面语、术语准确	OpenAI 兼容，注意国内外端点不通用
3 附图 / 文生图	豆包 Seedream（火山方舟）	概念示意图提示词 + 出图	图像专用端点，非对话端点
4 结构图	qwen-plus / deepseek-v4-flash	输出 Mermaid 矢量代码	OpenAI 兼容

说明：以上为 2026-08 官方公开信息，模型名与端点随时可能更新；接口均走 OpenAI 兼容协议，换模型只需改 base_url / model / api_key 三处。完整端点与申请入口见附录 B。

3.4 各路线与方案操作要点

3.4.1 路线 A（Coze / Dify，零代码）

· Coze：浏览器打开 coze.cn → 新建工作流 → 依次放节点（开始 → 逻辑权项[DeepSeek] → 中文润色[Kimi] → 附图[豆包] → 结构图[通义] → 结束拼交底书）→ 节点间用变量串联（如 {{start.topic}}、{{节点名.data}}）→ 试运行 → 发布为 Bot，一句话触发。

· Dify：先在「模型供应商」接入各平台 Key → 按节点清单搭 6 节点（开始 / DeepSeek 逻辑 / Kimi 润色 / 豆包附图[HTTP 节点] / Qwen 结构图 / 回复汇总）→ 豆包附图走 HTTP 请求 POST 独立图像端点。

· 模型下拉缺失：Coze 商店无 DeepSeek 时，用「插件」搜索或用「代码」节点（Python）调用接口；先用平台自带模型跑通再换。

3.4.2 路线 B（WorkBuddy 侧）

· B+（推荐）：直接用「利衡辨_电池专利助手」skill，产出带两步耦合检测 + 13 维校验的技术交底书 + 校验报告 + 权利要求书，天然满足命名与四件套规范；

· B-1（自建自动化）：新建自动化「专利多模型写作流水线」，提示词按四道工序（逻辑权项 / 说明书润色 / 附图规划 / Mermaid 结构图）依次衔接，rrule 设每周一 09:00 或手动触发；

· B-2（进阶）：接 MCP 真调 DeepSeek / Kimi / 豆包 / 通义，四道工序改为依次调用四个 MCP 工具（需填 Key）。

3.4.3 路线 C（安装软件）

· n8n：装 Node.js → npm install -g n8n → 启动（localhost:5678）→ Import from File 导入现成 JSON → 填 Key → Execute Workflow 一键跑；

· LangChain：装 Python（Add python.exe to PATH）→ pip install 依赖 → set 环境变量填 4 把 Key → python 脚本运行，依次调 4 个模型产出交底书草稿。

3.4.4 方案②（API 程序化，开发向）

用官方 openai 库统一封装各模型（均 OpenAI 兼容），每个 stage 是独立函数、返回文本，由 main 依次串联；图像走 images.generate（需火山方舟 Endpoint ID）。核心调度脚本与完整可运行单文件见源手册，本文不重复粘贴（正文不嵌具体脚本，符合成文母规则 STD-F-005）。

3.5 量产工程化

· 批量输入：主题列成 topics.csv（一列 topic），或从现有专利 PDF/DOCX 批量提取；

· 并发 + 重试 + 限流：ThreadPoolExecutor 控 max_workers（注意各平台 RPM 上限），tenacity 重试退避；

· 断点续跑：以已产出文件名集合比对待跑清单，只跑未完成的；

· 成本与日志：每次调用累计 token 与费用；DeepSeek / GLM 类极便宜（约 ¥1 / 百万 token 量级），量产百篇成本通常个位数到几十元；豆包文生图按张计费；失败主题写 failed.txt 便于人工兜底。

3.6 质量闸门与排错

3.6.1 四道质量闸

表3-7 四道质量闸

闸次	校验内容	判据	不通过处置
闸一 结构完整	每篇含「权项 / 说明书 / 附图 / 结构图」四段	缺段即告警	重跑该段
闸二 文本雷同	simhash / 余弦相似度比对历史产出	雷同超阈值	打回重写
闸三 规范与查新	权项首句「一种……」且含「其特征在于」；与现有专利比对新颖性	正则抽查 + 检索比对 + 异源双模校核	人工复核后改写
闸四 交付合规	命名、任务夹、四件套齐全（R12/R13）	门禁校验通过	补件后重新落盘

附图精度（必须）：文生图只做概念图，真正的方法流程图 / 架构图必须用 Mermaid（矢量、零错乱）；专利局不认 AI 生图当正式附图，正式提交前 Mermaid 转矢量 + 人工核标号。

3.6.2 量产必踩的坑

· Key 安全：永远走环境变量 / 密钥管理，禁止把 sk- 写进仓库或贴群

· 模型名漂移：跑批前先调 /v1/models 核对

· 端点双轨：Kimi 国内外端点 Key 不通用，跨端点必 401

· 接口差异：图像与对话不共用端点，版本统一 v3

· 限流 429：加重试退避 + 控并发

· 超时：单篇设 socket timeout（如 60s）

· 中文乱码：文件统一 UTF-8，Windows 控制台 chcp 65001

· 输出不稳定：让模型「只输出 JSON / 只输出 Mermaid 代码」再解析

· 成本失控：先小批量（3–5 篇）测通再放大

· 落盘不合规：文件名无时间戳、直落工作区根、缺四件套，都会被门禁拦下（R12/R13）。完整排错速查见附录 E。

3.7 判定标准与合规检查清单

3.7.1 判定标准（量化锚点）

表3-8 判定标准（量化锚点）

维度	指标	合格阈值	校验周期
路线选择	路线与决策路由匹配率	100%	每次应用启动
模型路由	阶段完整度（四段缺段率）	0%	每批产出
Key 安全	代码 sk- 明文命中	0	每次提交
命名合规	命名不合规率	0%	实时（落盘闸门）
交付合规	四件套齐全率	100%	每次交付
质量闸	四道闸通过率	100%	每批产出
批量稳定	失败重试后成功率	≥ 95%	每批产出

3.7.2 合规检查清单（含责任人与复核频率）

表3-9 合规检查清单（含责任人与复核频率）

检查项	责任人	复核频率
社区技能安装前过 skill-vetter 审查（R3）	应用发起人 / 技能审查人	每次安装
路线选择匹配决策路由（R6）	应用发起人	每次应用启动
API Key 走环境变量、无明文（R8）	模型 Key 保管人	每次提交
跑批前核对模型名与端点（R9）	流水线维护人	每次跑批前
批量产出重试 / 并发 / 断点齐备（R10）	流水线维护人	每批产出
四道质量闸逐项通过（R11）	质量复核人	每批产出
命名合规、落盘进任务夹（R12）	应用发起人	实时
四件套齐全（R13）	应用发起人	每次交付

3.8 命名落盘与交付合规

本节条款与《全域文件命名规则技术标准》V1.1.0、S01/S02、《四件套强制交付物断言技术标准》V1.0.0 严格对齐，为规模化应用「写出来之后合规落地」的最后一道底座。

（1）时间戳：统一格式 YYYY-MM-DD_HHMM（下划线 + 分钟），文件夹与文档同格式。

（2）业务交付物（Class A）命名：<主题>_<时间戳>.docx，例：全固态电池气体检测_专利交底书_2026-08-30_2334.docx。

（3）治理四件套（Class B）命名：<主题>_<时间戳>_<类型>.docx|xlsx，类型固定为「技术规范要求 / 摘要 / 变更履历 / 版本清单」。

（4）先建任务夹：<短标题>_<时间戳>/产出|素材/，禁止直落工作区根（R12）。

（5）区域路由：批量产交底书属「交付发布」性质，落发布盘任务夹；训练 / 升版 / 迭代落训练盘；技术标准双模校核落校核盘。

（6）四件套齐出：技术规范要求 Word、摘要 Word、变更履历 Excel、版本清单 Excel 缺一不可，与业务交付物同目录齐出。

4 第四篇 监督、文档管理与版本历史

4.1 监督与违规处置

全域文件治理工作组负责本标准的监督执行：

（1）违规记录与整改：违规事件须逐件记录（违规类型 / 责任人 / 发现渠道 / 整改期限），并限期整改；重大违规（如 Key 明文泄露、社区技能未审查即安装、落盘不合规强行交付、缺四件套）上报管理层。

（2）分级处置：连续两个复核周期同一检查项不达标，触发专项整改并复核；整改不力的，暂停相关角色的文件操作权限。

（3）考核联动：监督结果按3.7.2复核频率纳入考核；判定标准各维度连续达标情况纳入年度评审输入。

（4）成文合规监督：未按《技术标准成文自检清单》执行自检即发布，或 P1 阻断项未闭环仍发布，视为重大违规，按本条第（1）项记录并上报。

4.2 文档管理与版本历史

4.2.1 修订记录

表4-1 修订记录

版本	修订日期	修订人	修订内容
V1.3.0	2026-09-02	全域文件治理工作组 & 技术标准委员会	排版修订：依据技术标准排版助手 V1.7.0 落实 4 条格式要求（表格单元格边距 0.05cm+中部左对齐、图片留白 ≤1mm、正文首行缩进 2 字符、页脚第X页共Y页）；正文条款与规则内容不变
V1.2.0	2026-09-02	全域文件治理工作组 & 技术标准委员会	补图修订：补入逻辑思维简图（第一篇认知入口）与生命周期逻辑结构图（第二篇全生命周期模型）两类必备可视化认知入口图，闭合母规则 STD-C-011（P1）；正文条款与规则内容不变
V1.1.0	2026-09-02	全域文件治理工作组 & 技术标准委员会	排版修订：补全静态目次，按 GB/T 1.1 国标版式重排版，标题编号升级为章条连续编号（四篇→第1~4章），表题改由引擎自动编号；正文条款与规则内容不变
V1.0.0	2026-09-02	全域文件治理工作组 & 技术标准委员会	首版发布：合并《WorkBuddy 说明作文》与《量产专利完整手册 · 专业版 V1.1》，按《全域文件工作流规则技术标准》V2.2.0 四篇式结构重写为「WorkBuddy 应用技术标准」，含四大能力模块认知框架、三者协同框架与 13 条应用规则（R1–R13）

4.2.2 审批记录

表4-2 审批记录

角色	姓名	签字	日期
编制	全域文件治理工作组 & 技术标准委员会		2026-09-02
审核	（待定）		须于发布前完成
批准	（待定）		须于发布前完成

4.2.3 标准评审机制

本标准至少每年评审一次，由全域文件治理工作组发起，征集各业务部门与职能部门意见后形成修订草案（必须）。评审内容包括：标准适用性、技术更新（模型名 / 端点 / 平台能力变化）、合规变化、缺陷修复、成文规范符合性等（必须）。评审结果应记录于修订记录中（必须）。

4.2.4 定稿校核结论

本标准 V1.0.0 由两份源文档合并重写而成，V1.1.0 为排版修订（补目次 + 国标版式重排版，内容不变），四篇式结构与行文逻辑严格对齐《全域文件工作流规则技术标准》V2.2.0，术语、格式与编号层级已统一，源文档内容均完整纳入、未作删减。标准编号（Q/WB-APP-2026-001 暂定）确认与审批签字为发布前的行政流程，须于正式发布前完成闭环。任何后续变更须遵循4.2.3评审机制。

附录 A

A.1 规则条目速查表

表 A.1 规则条目速查表

分组	编号	规则要点	闸门机制
能力使用	R1	需求描述详尽	产出与需求逐项比对
能力使用	R2	插件自动调用	调用日志留痕
能力使用	R3	社区技能先审查	skill-vetter 安全审查
能力使用	R4	按领域召唤专家	召唤记录匹配
能力使用	R5	手/脑/人格/行动力协同	组合框架映射
应用方法论	R6	路线选择（skill 优先）	决策路由匹配
应用方法论	R7	四阶段模型路由	缺段即告警
应用方法论	R8	Key 走环境变量	代码 sk- 明文扫描
应用方法论	R9	跑批前核对模型 / 端点	附录 B 速查表命中
应用方法论	R10	批量 / 并发 / 断点	failed.txt + 重试可查
应用方法论	R11	四道质量闸	四闸判据逐项通过
应用方法论	R12	时间戳任务夹落盘	落盘路径归属硬闸
应用方法论	R13	四件套齐出	四件套齐全校验

附录 B

B.1 端点与模型速查（2026-08-30 核验）

表 B.1 端点与模型速查

用途	端点	模型示例	备注
逻辑 / 权项	https://api.deepseek.com	deepseek-v4-pro	官方 OpenAI 兼容
逻辑 / 权项（备选）	https://open.bigmodel.cn/api/paas/v4	GLM 系列	以 /v1/models 为准
中文润色	https://api.moonshot.cn/v1	kimi-k3 / kimi-k2.6	国内 Key 专用
中文润色（国际）	https://api.moonshot.ai/v1	kimi-k3	国际 Key 专用
结构图	https://dashscope.aliyuncs.com/compatible-mode/v1	qwen-plus	兼容模式端点
文生图	https://ark.cn-beijing.volces.com/api/v3/images/generations	doubao-seedream 系列	需 Endpoint ID

核验说明：上表依据各平台官方公开文档于 2026-08-30 核对。模型名迭代频繁，跑批前必查 /v1/models；本表仅为起点，不替代官方实时文档。

附录 C

C.1 工具链与规范索引

表 C.1 工具链与规范索引

名称	作用	位置
全域文件命名规则 V1.1.0	命名权威	specs/范式/N1_全域文件命名规则范式.md
全域文件工作流规则 V2.2.0	上位治理框架	specs/范式/W1_全域文件工作流规则范式.md
全域文件排版规则 V1.0.2	排版基线	specs/标准库/
四件套强制交付物断言 V1.0.0	交付合规深检	specs/标准库/
交付物工具链	命名校验 / 四件套 / 区域路由	~/.workbuddy/_tools/
专利助手 skill	交底书撰写与校验	~/.workbuddy/skills/（利衡辨_电池专利助手）
受管 Python venv	python-docx / openpyxl	~/.workbuddy/binaries/python/envs/default/

附录 D

D.1 决策路由表

路线决策路由见3.1.3（表3-2），本附录不重复。

附录 E

E.1 排错速查表

表 E.1 排错速查表

现象	大概率原因	怎么办
节点取不到上游内容	变量引用名写错或连错线	检查连线；Coze 用 {{节点名.data}}，n8n 用 $('节点名').item.json...
401 / 鉴权失败	Key 填错 / 跨端点用 Key	回查 Key；Kimi 核对国内 / 国际端点
404 / 接口不存在	端点版本写错（v2/v3 混用）	统一 api/v3，图像走 images/generations
model not found	模型名已升级下线	调 /v1/models 核对，用附录 B 最新名
429 / 请求太频繁	调太快被限流	等几分钟；加退避重试、控并发
跑很久没反应	没设超时 / 网络慢	单节点设 60–120 秒超时
中文变乱码	文件 / 终端编码问题	文件 UTF-8；Windows 终端 chcp 65001
豆包不出图	用了对话网址调图像	图像用独立端点，建好推理接入点
模型下拉没有目标模型	平台未接入	用自带模型跑通，或插件 / 代码节点调 API
脚本一运行就报错	Python 没勾 PATH / 依赖没装	确认 python --version 有输出、pip install 成功
AI 生图标号错乱	用文生图当正式附图	正式附图改用 Mermaid 转矢量 + 人工核标号
文件存不进去	文件名无时间戳 / 落在工作区根	先建任务夹再落盘（R12）