企业官网建设流程全解析

每天早晨被几十个红色未读标记唤醒，公众号、行业站点、GitHub 热榜、竞品公告，全部刷完一小时就没了，而真正和你业务相关的可能只有两三条。长期做内容和技术跟踪的人，对这种“信息过载但有效信息稀缺”的状态应该都不陌生。

我受够了之后，直接用 Coze 智能体平台搭了一个纯自动化的 AI 情报助手：定时抓取我关心的信源内容，用大模型把低价值内容过滤掉，把值得看的部分整理成结构化简报直接推到工作群。全程不写后端代码、不用自己维护服务器，更不需要每天手动打开任何 App 去刷一遍。整个项目从零搭建到跑通，关键步骤很清晰，今天把这套方案从头到尾拆开讲，包含设计思路、具体配置、完整工作流步骤，以及我实际跑了一两个月之后踩到的坑和排查方法。

这套方案适合谁？做内容选题的编辑和自媒体、需要盯竞品动态的产品和运营、想低成本体验 AI Agent 的开发者，都适用。你不一定懂代码，但最好对“输入 — 处理 — 输出”的基本逻辑有个概念。准备好了，就从设计思路开始。

1. 项目整体设计与思路拆解

1.1 为什么是 Coze，而不是从零写一套爬虫服务

我在动手前认真对比过几条技术路线。第一条是自己写爬虫加调度任务，用 Python 加 APScheduler 或者 GitHub Actions，再调大模型 API 做摘要，最后通过机器人 Webhook 推送到群里。这条路技术上完全通，以前我确实这么干过，但维护成本不低：网站改版要跟着改选择器、服务器到期要迁移、API Key 要安全管理，目标只是“看情报”，不是“练爬虫”，为这点事养一套系统不太划算。

第二条就是 Coze 这类 AI 智能体平台。它最核心的吸引力不是“低代码”这个概念，而是把情报助手需要的几块基础设施都集成好了：定时触发、插件商店里的 RSS 采集和网页解析能力、大模型节点的自由调度、知识库和数据库，以及现成的 Webhook 推送节点。换句话说，它把“从零到一”变成了“把积木插好”。

选 Coze 还有一个很实际的理由：迭代速度快。我在搭的过程中对信源和提示词的调整非常频繁，传统开发模式改一次要重新部署，Coze 里就是改节点再发布的事。你不需要理解 Docker、反向代理、数据库连接池这些概念，把精力全部放在“什么样的情报值得推送”上，这才是这个项目的真正核心。

当然它也有边界。如果单日采集量级到几十万条、需要深度定制爬虫或部署在自己内网，那就不要硬套 Coze，这些场景它并不擅长。但对个人和中小团队的情报跟踪场景，Coze 的综合效率确实是最高的。

1.2 情报助手的流水线架构，像一个自动化的编辑部

整个系统我习惯拆成六层来看，每一层在 Coze 里都有对应的实现方式：

• 触发层：定时触发器，相当于编辑部每天早上的晨会闹钟。
• 采集层：通过插件或 HTTP 请求节点抓取目标信源的标题、链接、摘要。
• 清洗层：用 Code 节点做 URL 去重、字段格式整理，相当于记者把素材按统一格式填入稿件模板。
• 增强层：可选，把抓取到的内容在知识库里做一次背景检索，补充相关历史信息。
• 生成层：大模型节点，按预设提示词完成筛选、摘要、优先级排序和输出格式化。
• 投递层：把最终结果通过 Webhook 推送到飞书、钉钉、企业微信或 Telegram 群。

这套分层的设计思路很重要。很多人第一次搭情报助手，容易把“抓取”和“生成”混在一个节点里，结果后面想调整推送格式，发现明明只是改个输出，却要动整个流程。分层之后，每一层只干一件事，调整某一层不会牵连其他层，排查问题也更简单——推送没到就先查投递层，内容质量差就只改提示词。

这里我想多提一句：情报系统不建议把完整网页内容全部保存下来，应该只提取“标题+来源+摘要+链接+发布时间”这几个字段。原因很直接：一是大模型按长文本处理，成本随内容长度上升；二是保存历史数据涉及版权合规问题；三是大多数场景下，读者真正需要的是“知道发生什么”和“决定要不要点开原文”，摘要加链接已经足够。

1.3 第一版控制范围，先跑通再谈扩展

搭建初期有个很容易犯的错误：想一次性把所有功能都做出来，多信源、多格式、自动去重、对话查询、定期报告，全部塞进第一版。结果就是工作流节点越来越多，测试时根本分不清是哪一个环节出的问题。

我自己建议的第一版范围：固定 3 到 5 个高质量信源，每天定时跑一次工作流，生成一份当日情报简报并推送到群，仅此而已。目的是先把“定时触发—采集—清洗—生成—推送”这条完整链路跑通。链路是骨架，内容质量是血肉，骨架没问题了，再往上加对话查询、导出报告、更多信源这些功能。

2. 环境准备与核心组件配置

2.1 注册账号与团队空间的选择

Coze 的入口是 coze.cn 或对应国际版站点，注册流程不复杂，手机号或邮箱验证即可。进入控制台后，第一件事是创建空间。这里要注意：空间分个人空间和团队空间，建议直接创建团队空间再开始搭项目。

原因有几个。团队空间在成员协作、资源隔离和权限管理上更规范，就算你只是一个人用，后续想把项目分享给同事一起维护，团队空间可以直接加成员，比个人空间灵活得多。另一个原因是团队空间内的资源（如插件配置、知识库、数据库）在项目间复用更自然，我早期在个人空间搭过一版，后来切换团队空间重新整理了一遍，浪费了不少时间。

创建项目时，平台会要求选择一个底模型，这一步不用想太多，按 Coze 当前提供的可用模型选一个主流款即可。物理部署在哪个区域、用哪个模型厂商，这些后续都能在节点里调整，不影响整体架构。

2.2 插件选型：采集层的关键拼图

情报助手能不能抓到你想要的信息，核心在插件选型上。Coze 插件商店里的插件数量不少，而且不同时期有变化，我按功能分了几类，你在搭建时按需选取：

• RSS 类插件：适合抓取博客、技术媒体、部分新闻站的 RSS 输出。稳定、结构清晰，是我的第一选择。
• 搜索类插件：按关键词抓取搜索结果，适合竞品情报和品牌监控，能覆盖没有 RSS 的站点。
• 网页解析类插件：输入 URL 直接抓取正文内容，适合目标信源非常明确的场景。
• 通用 HTTP 请求插件：类似代码里的 requests 客户端，可以对接公开 API，灵活性最高，但需要自己解析返回结果。

实际使用中我遇到的普遍情况是：插件商店不一定能精确匹配你想抓的站点。这时候不用死磕插件，Coze 工作流里本身就支持 Code 节点，可以写少量 JavaScript 代码，用内置的 HTTP 能力直接向接口发请求，然后把格式化后的数据传给下游节点。学会用 Code 节点做兜底，采集层就基本不会被卡住。

还要提醒一句：插件在真正执行前，最好先做一次单节点测试。我在配置 RSS 插件时就遇到过某个信源返回超时、某个字段解析为空的情况，单节点调试可以快速定位到底是指令问题还是信源问题。

2.3 定时触发器：早报的“闹钟”怎么设

Coze 的定时触发器支持按 Cron 表达式设定执行周期，也支持简单的间隔执行。我用的是每日早上固定时间跑一次，对应的 Cron 表达式类似0 1 * * *这种。

这里有个必须注意的细节：Cron 里的时间到底是 UTC 还是北京时间，不同区域的平台处理逻辑不一样。如果你发现触发器设的是早上九点，实际执行却在下午五点，十有八九是时区差问题。稳妥的做法是：设定好之后先看平台给出的“下次执行时间”预览，确认执行时间符合预期，再等待触发验证。

除了每日一次，还可以设计按工作日触发的表达式，比如只跑周一到周五。如果情报的时效性要求高，比如监控某个竞品官网公告，可以缩短到每小时一次。但频率越高，触发次数和资源消耗也越高，建议根据实际需求设置，不要一味求快——对多数信息源，一天一次已经够用，过于频繁反而会让群里推送变成噪音。

2.4 变量和数据库：去重与记忆的基础设施

情报系统最容易被人忽视的是“去重”问题。定时任务每次执行，都会把信源当前的文章列表拉一遍，如果不做去重，同一个链接会被推送很多次，群里的体验会非常差。

Coze 提供了两种能力来处理这类状态：变量（Variable）和数据库（Database）。变量的粒度更轻，适合保存“上一次已经处理过的 URL 列表”这种短期状态；数据库适合保存完整的文章历史记录，后面做检索和对话查询时很有用。

我第一版采用的做法是：用变量存一个数组，记录最近一周处理过的 URL。每次工作流启动后，先把当前拉到的文章列表和这个数组做对比，已经存在就跳过，只对新增内容做后续处理，最后把新增的 URL 追加进数组并清理过期记录。逻辑不复杂，但能真正解决重复推送的问题，这个节点建议放在采集层之后、大模型处理之前。

3. 核心工作流搭建：从空项目到第一份情报简报

3.1 场景设定：先选定一个你愿意长期看的方向

为了演示，我以“每日 AI 技术情报”为例。信源我选了这么几个：InfoQ 中文站的 RSS、GitHub Trending 的公开 API、某个行业媒体邮件订阅的 RSS 转地址，以及内部知识库中的竞品技术文档页面。选择标准是“内容质量稳定 + 有结构化出口”，这两个条件至少要满足一个，否则后续解析会非常痛苦。

如果你做的是专利相关工作，可以把信源替换为专利检索平台的公开检索结果页或 RSS；如果你关注竞品动态，可以换成竞品官网公告页、官方公众号的 RSS 化服务。信源可以随行业变化，关键是你得清楚“目标信息长什么样”，这样才能在后面写提示词时定义好什么该留、什么该丢。

3.2 分步搭建工作流，按“输入-处理-输出”串起来

在 Coze 控制台新建工作流后，默认会有一个“开始节点”。我往里添加的第一个节点是插件节点，选择 RSS 插件，填入信源地址。这里建议把需要订阅的信源并列配置成多个采集节点，而不是理想化地“一个节点抓所有”。

采集节点拿到原始数据后，接一个 Code 节点做字段统一和 URL 去重。Code 节点的作用很关键，它把不同信源的字段名（比如有的叫 title，有的叫 name）统一成title、url、summary、source、published_at这几个字段，再和变量里保存的历史 URL 做比对，输出一份过滤后的待处理列表。

我写的一个轻量去重逻辑模板大致是这个思路：

async function main({ historyUrls, newItems }) { const seen = new Set(historyUrls || []); const unique = []; for (const item of newItems) { if (!item.url || seen.has(item.url)) continue; seen.add(item.url); unique.push(item); } return { uniqueItems: unique, latestSeen: Array.from(seen).slice(-200) }; }

这段 JavaScript 的作用是：用 Set 记录已出现过的 URL，遍历新文章列表，过滤掉重复项，最后返回新的去重列表和更新后的历史数组。注意我做了slice(-200)限制长度，避免变量无限膨胀。

清洗后的数据流转到下一个节点：如果只需要做简报，可以直接接大模型节点；如果希望后续能对话查询，建议同时把结构化数据写入数据库表，字段就是上面统一的五个字段。

3.3 提示词是灵魂，模板可以直接抄

大模型节点是整条流水线的大脑，提示词写得好不好，直接决定推送内容质量。第一版我写过很多泛泛的提示词，比如“请总结以下内容”，结果模型把每篇文章都总结了一遍，群里的消息又臭又长，根本没人点开。后来改成了强约束的结构化输出，效果好很多。

我现在的模板大致是：

你是一名资深情报分析师。请从给定的文章列表中，筛选出与目标领域强相关且对决策有参考价值的内容。 筛选规则： - 排除纯产品介绍、软文、与目标领域无关的泛行业内容。 - 优先保留：新技术发布、开源项目重大更新、行业报告、竞品动态、重要论文或专利公开。 - 如果一篇文章信息量低，直接丢弃，宁缺毋滥。 输出要求： - 用中文输出，格式为 Markdown 有序列表。 - 每条包含：标题、来源、一句话摘要（不超过50字）、为什么值得关注（不超过40字）、原文链接。 - 输出前按重要性从高到低排序，最多输出8条。 - 如果过滤后没有值得关注的内容，只输出“今日暂无重点情报”。

这段提示词的关键在于“筛选规则 + 输出要求 + 兜底输出”。筛选规则帮模型建立判断标准，输出要求保证结果结构稳定，兜底输出让空结果也能正常展示，避免推送一条空消息。

大模型节点里还有几个参数值得调整。模型选择方面，我倾向于在成本和效果之间取平衡，选平台提供的默认或主流型号即可；temperature 建议调低，放到 0.2 左右，因为情报整理属于客观筛选任务，不是创意写作，随机性越低越好。部分平台支持输出格式预设，可以选 JSON 或 Markdown，选了之后模型会更严格地按格式来。

3.4 推送节点：把简报送进工作群

生成结果后，最后一步是推送。Coze 里可以添加一个 Webhook 节点，把你的群机器人地址填进去，把上游生成的内容作为请求体的文本字段发送。

不同平台的群机器人配置方式不太一样，但核心步骤大同小异：在群里添加自定义机器人，拿到 Webhook 地址；如果平台要求加签，把签名密钥填到节点配置里。第一次配置后，建议先用一个极简的测试文本“这是一条测试消息”跑通节点，确认消息能出现在群里，再去接真实的数据流。这样做的好处是，一旦最终推送有问题，你至少能确认是内容生成的问题还是 Webhook 配置的问题。

全部节点串联起来后，保存并发布工作流。发布前记得设置好定时触发器，我设的是每天早上九点执行一次。发布之后不要干等，手动点一次“试运行”按钮，完整跑一遍流程，然后打开运行日志看每一步的输出：插件有没有返回数据、Code 节点是否正常过滤、大模型输出是否符合格式、Webhook 有没有报错。第一次调试几乎不可能一次通过，但日志会非常清楚地告诉你是哪一步出了问题。

4. 进阶：让情报助手真正“可对话、可复用”

4.1 从“单向推送”升级成“可追问的 Agent”

定时推送解决的是“每天按时给你一份简报”的需求。但情报工作中难免有临时追问：某个事件具体什么背景？上周有没有相关报道？这个功能靠静态推送是满足不了的，需要把助手升级成一个真正的智能体，也就是 Coze 里的 Bot。

创建 Bot 时，关键是把前面搭好的工作流、知识库和数据库关联进去。这样 Bot 既拥有定时推送的能力，又能在对话场景下直接查历史数据。在 Bot 的人设和回复逻辑里，我会明确告诉模型：这是一位情报助手，回答时必须基于已采集的数据，不能凭空编造；如果用户问的事情没有采集过，直接说明“数据库里没有相关记录”，而不是硬编一个答案。

这一步其实是很多 AI Agent 项目容易踩坑的地方：模型看到陌生问题，倾向于用通用知识来“圆场”，结果就产生幻觉信息。轻量的对抗方法就是在提示词里先声明“数据边界”：你能知道什么、不能知道什么，判断不了就说不确定。

4.2 用对话流实现动态查询

如果要支持“按关键词查历史情报”，可以再创建一个对话流。对话流和工作流最大的差别是：工作流适合批量、定时执行；对话流适合由用户输入触发，按需返回结果。

举个实际的例子：用户在群里问“最近三天有没有关于大模型推理优化的文章”。对话流的处理过程是：先从用户输入中提取“最近三天”和“大模型推理优化”这两个关键参数，用参数去数据库表里查询，筛选发布时间在时间范围内、且标题或摘要中包含关键词的记录，最后把查询结果交给大模型，整理成一段精炼的回答返回给用户。

数据库查询这一步看起来很复杂，但在 Coze 里其实就是添加一个数据库查询节点，配置好表名和过滤条件就行。整体上对话流让助手具备了“主动服务”的能力，而不是每天早上机械地推一条消息。

4.3 输出 Markdown 文件，再转 Word，变成周报素材

不少用户搜索过“markdown转word工作流coze”，这背后其实是一个很实在的需求：情报汇总之后，最终要落到文档里，周报、月报、专利交底材料，都需要 Word 格式。

Coze 工作流可以在生成内容后，通过文件处理或文档转换插件把 Markdown 转为 Word。我的做法是：在大模型节点输出结果时，除了推送群消息，同时把简报保存为 Markdown 文本内容，然后在文件处理节点里指定输出格式为 Word，生成.docx文件，再通过插件发送到指定位置或直接作为消息附件推送到群里。

这里有个细节：生成的文件名最好带上日期，比如AI情报简报-2026-01-16.docx，不然每次都被同名文件覆盖。文件存放如果需要长期保留，建议关联到云盘或数据库的文件字段，不要只存在运行记录里，否则时间一长就会不好找。

4.4 情报源怎么持续优化

信息源是整个系统的输入质量源头。只配一次信源就一劳永逸是不现实的，持续优化是个常态。我自己的维护节奏是一个月过一次信源清单：跑了一个月发现某个源从没产出过一条有效推送，就换掉；发现某个源被频繁点击率高，就考虑把它放到优先采集的位置。

不同行业适合的情报源形态也不一样。做技术趋势跟踪，可以关注 arXiv 的公开接口和 GitHub Trending；做竞品分析，更依赖官网公告和招聘页面（招聘信息的变动往往能反映产品方向调整）；做行业观察，可以接行业媒体和协会网站的 RSS。如果你是做专利辅助工作，还可以把公开专利检索平台的 URL 模板接进来，每次运行按关键词组合生成检索地址，再把结果页的关键字段抽取出来入库。

另外要注意采集频率的确定性。部分网站有反爬策略和 robots 协议限制，用 RSS 通常最稳妥，因为它本身就是站点愿意提供的内容分发方式。如果某个站点只能用网页解析，建议降低抓取频率，控制抓取深度，只取列表页而不是深挖每篇正文，这样对你的信誉和对方的服务器压力都好。

5. 常见问题与排查技巧实录

5.1 定时任务不执行或者时间不对

这是最常遇到也最让人头疼的问题。排查思路分两步：先看 Cron 表达式，再看时区设定。你可以先在平台给出的“下次执行时间”处确认，比如你心里预期是北京时间早上九点，如果预览显示的是凌晨一点，那基本就是时区差。解决办法是按平台要求的时区重写表达式，绝大多数情况下，克制的做法是换算成 UTC 或用平台 UI 里自带的时间选择器，不要自己凭感觉写 Cron。

还有一种可能：任务确实执行了，但运行日志里报错，只是你没收到推送。所以排查时一定要打开执行记录，看工作流到底有没有被触发，触发后第一步有没有执行成功。信息可能滞后，但日志不会撒谎。

5.2 插件抓取不到内容或者返回空

定位方法很简单：单独运行采集节点，看返回里有没有数据、报错信息是什么。实际中常见的原因有三种：目标站点改版导致解析规则失效；站点有登录或反爬限制，公开抓取拿不到完整内容；目标站点内容靠 JavaScript 动态渲染，普通 HTTP 请求拿不到渲染后的页面。

应对方式按优先级排列：优先看看这个站点有没有提供 RSS，有就直接换 RSS；没有 RSS，就看有没有公开 API，比如很多平台的数据接口是半公开的，直接请求 JSON 比解析 HTML 稳定得多；都没有，再考虑用搜索插件按域名搜，间接获取最新页面链接。真要解析动态页面，也可以在 Code 节点手动配置带 UA 的请求头试试，但成功率取决于对方站点的防护强度。

5.3 重复推送刷屏，群里全是同样的链接

这是没做去重或去重逻辑失效导致的。检查顺序：先看变量里有没有正确初始化和写入；再看删重逻辑是否放在所有采集节点合并之后、大模型处理之前。失败的原因大概率是：第一次调试时没有初始化 Time 节点，或者把去重逻辑放在大模型节点后面——模型已经生成了内容，再过滤也无济于事。

另外注意，去重变量本身有容量上限。如果保存的历史 URL 太多，超过了变量限制，超出部分会被丢弃，等于旧链接会再次被当作新链接处理。所以我在前面模板里加了slice(-200)，就是控制历史记录在合理的窗口期内，既足够完成短周期去重，又不会撑爆变量。

5.4 大模型输出格式不稳定，时而是表格，时而是大段文字

输出的稳定性直接取决于提示词的约束力度和模型的 temperature 参数。我遇到过两种情况：一是提示词里没有明确指定输出结构，结果模型自由发挥；二是 temperature 默认值偏高，模型在每次生成时都出现微小差别，累积起来格式就乱了。

解决方案是三层加固：提示词里给出明确的输出格式示例，比如“输出必须是一个 Markdown 有序列表，每条包含标题、来源、摘要、链接四个字段”；在模型节点里把响应格式预设调整为 JSON 或 Markdown；最后把 temperature 降到 0.2 附近。如果这样还不稳，就在大模型节点之后再接一个 Code 节点，用正则或简单字符串处理再校正一遍。

5.5 推送没到达群里，或者频繁被限流

推送没到，多数是 Webhook 配置问题：地址填错、加签方式不对、消息内容体格式和平台要求不匹配。先单独跑一次测试，再跟着运行日志看实际请求的响应内容。如果地址和签名都没问题，那就可能是同一条消息被频繁触发，触发了群机器人的频率限制。群里推送建议合并成一条消息发出去，而不是一个标题发一条，既清爽又不容易被系统拦截。

5.6 别忘了合规底线

这一点非常重要。自动采集虽然省事，但你要注意尊重目标网站的数据获取规则。优先用 RSS 和公开 API 这些站点主动提供的方式，抓取频率控制好，不要对目标服务器造成压力。内容分发时，简报里给出摘要和原文链接，不直接搬运全文。涉及未公开数据、个人隐私、受版权保护内容，不要碰，也不要用于商业违法违规用途。自动化只是工具，使用工具的责任还是在自己手上。

我在实际搭建和使用的这两个月里，最大的体会是：不要一开始就追求大而全。第一版哪怕只盯一个信源、每天推一份三到五条内容的简报，能坚持读下来，也比那种全自动但没人看的“信息轰炸”强得多。后来我甚至把推送分成了两段：早上九点一份核心速报，下午四点一份“值得深读”的链接合集，群里点开率反而高了不少。

提示词方面也别指望一次写到位。我前后改了七八版，每一次改动都是因为实际推送给我的内容里出现了“毫无价值的推荐”和“错过的重点”。花在搭结构上的时间其实很少，真正花时间的是教会模型“什么值得看”——这才是这套系统的灵魂所在。

最后再分享一个小经验：所有自动化工具都会有偶尔失灵的时候，不要完全把判断力外包给模型。定时任务跑出来，你要快速扫一眼，觉得当天内容不对劲就立刻看运行日志。情报系统的价值不是输出多少字，而是命中多少真正重要的东西，这一点，模型负责过滤，你负责做最终决策。