【S1W3 交叉评测】PC4OPC 项目反馈（更新版） #2

New issue

Open

opened 2026-05-24 07:55:06 +08:00 by JunjieCai · 0 comments

JunjieCai commented

2026-05-24 07:55:06 +08:00

1. 项目理解

我理解 OPC4OPC 是一个面向 1-10 人早期创业公司的 AI 合规助手，核心定位是把“合
规审查”嵌入飞书工作流，而不是让创业者事后再去查法规或咨询律师。当前仓库展示的
是 Node.js + Express 的飞书机器人服务：通过 Webhook 接收消息，先用关键词做低
成本过滤，再用 DeepSeek 做意图判断、Skill 路由和专项合规审查，已覆盖广告合
规、劳动合规、商业贿赂/廉洁合规三类场景。

2. 项目亮点

场景选择贴近早创团队真实风险：广告极限词、劳动合同条款、采购回扣/商业贿赂都
是小团队容易忽视但后果明确的高频问题。
产品入口选择合理：飞书机器人比独立后台更符合“嵌入工作流”的定位，私聊主动审
查和群聊轻提示两种模式也能平衡可用性和打扰程度。
技术链路已有初步闭环：仓库包含 index.js、DEPLOY.md、test.js、
package.json，并说明了飞书 Webhook、DeepSeek API、Railway 部署和本地运行方
式。
Skill 拆分清晰：广告、劳动、反商业贿赂分别有独立 prompt，输出格式强调风险等
级、法规条款、原因和可执行建议。
Specs 中明确 AI 输出是风险提示与信息辅助，不替代正式法律意见，这一点对
LegalTech 产品很关键。

3. 当前不足或不清楚的地方

README 中的仓库结构仍提到 OPC4OPC_AdCompliance_Skill.md，但当前实际文件是
OPC4OPC_AdCompliance_Skill_v2.md，文档与文件名不一致。
package.json 的 npm test 仍是默认占位命令，但 README/DEPLOY 建议运行
node test.js 验证 15/15，建议接入正式测试脚本。
test.js 的部分用例依赖真实 DeepSeek API，没有 API Key 时无法完成自动化验
证。
当前代码没有明显处理飞书事件签名或来源校验，公开 Webhook 可能被伪造请求刷接
口成本。
AI 返回解析较脆弱：aiIntentFilter 直接 JSON.parse 模型输出，模型返回额
外解释或空响应时可能导致监听失效。
广告场景演示最完整，劳动和商业贿赂建议补充同等级输入样例、输出截图或录屏。

4. 建议补充的内容

修正文档一致性：更新 README 的仓库结构、clone 地址大小写、Skill 文件名。
把 node test.js 接入 package.json，例如 "test": "node test.js"，并拆
分 test:rules 与 test:ai。
增加 .env.example，列出 FEISHU_APP_ID、FEISHU_APP_SECRET、
DEEPSEEK_API_KEY、PORT。
给劳动合规、商业贿赂合规各补 2-3 个真实 demo 样例。
增加基础安全与成本控制：飞书签名校验、请求频率限制、消息去重 Set 的清理策
略、DeepSeek 调用失败时的用户侧提示。
对合规输出增加“证据置信度/需人工确认”字段，避免用户把 AI 提示直接当作最终法
律意见。

5. 综合评价

从当前仓库来看，OPC4OPC 已经不是单纯概念项目，而是有明确入口、可部署服务、专
项 Skills 和初步测试脚本的智能体 demo。方向选择、工作流入口和合规责任边界都比
较清楚，适合半决赛阶段展示“AI 能在真实业务节点中触发价值”。

下一轮最值得优先补强的是可验证性和工程完整性：让 npm install && npm test 有
稳定结果，让三类场景都有可复现 demo，并补上 Webhook 安全校验与异常处理。

### 1. 项目理解我理解 OPC4OPC 是一个面向 1-10 人早期创业公司的 AI 合规助手，核心定位是把“合规审查”嵌入飞书工作流，而不是让创业者事后再去查法规或咨询律师。当前仓库展示的是 Node.js + Express 的飞书机器人服务：通过 Webhook 接收消息，先用关键词做低成本过滤，再用 DeepSeek 做意图判断、Skill 路由和专项合规审查，已覆盖广告合规、劳动合规、商业贿赂/廉洁合规三类场景。 ### 2. 项目亮点 - 场景选择贴近早创团队真实风险：广告极限词、劳动合同条款、采购回扣/商业贿赂都是小团队容易忽视但后果明确的高频问题。 - 产品入口选择合理：飞书机器人比独立后台更符合“嵌入工作流”的定位，私聊主动审查和群聊轻提示两种模式也能平衡可用性和打扰程度。 - 技术链路已有初步闭环：仓库包含 `index.js`、`DEPLOY.md`、`test.js`、 `package.json`，并说明了飞书 Webhook、DeepSeek API、Railway 部署和本地运行方式。 - Skill 拆分清晰：广告、劳动、反商业贿赂分别有独立 prompt，输出格式强调风险等级、法规条款、原因和可执行建议。 - Specs 中明确 AI 输出是风险提示与信息辅助，不替代正式法律意见，这一点对 LegalTech 产品很关键。 ### 3. 当前不足或不清楚的地方 - README 中的仓库结构仍提到 `OPC4OPC_AdCompliance_Skill.md`，但当前实际文件是 `OPC4OPC_AdCompliance_Skill_v2.md`，文档与文件名不一致。 - `package.json` 的 `npm test` 仍是默认占位命令，但 README/DEPLOY 建议运行 `node test.js` 验证 15/15，建议接入正式测试脚本。 - `test.js` 的部分用例依赖真实 DeepSeek API，没有 API Key 时无法完成自动化验证。 - 当前代码没有明显处理飞书事件签名或来源校验，公开 Webhook 可能被伪造请求刷接口成本。 - AI 返回解析较脆弱：`aiIntentFilter` 直接 `JSON.parse` 模型输出，模型返回额外解释或空响应时可能导致监听失效。 - 广告场景演示最完整，劳动和商业贿赂建议补充同等级输入样例、输出截图或录屏。 ### 4. 建议补充的内容 - 修正文档一致性：更新 README 的仓库结构、clone 地址大小写、Skill 文件名。 - 把 `node test.js` 接入 `package.json`，例如 `"test": "node test.js"`，并拆分 `test:rules` 与 `test:ai`。 - 增加 `.env.example`，列出 `FEISHU_APP_ID`、`FEISHU_APP_SECRET`、 `DEEPSEEK_API_KEY`、`PORT`。 - 给劳动合规、商业贿赂合规各补 2-3 个真实 demo 样例。 - 增加基础安全与成本控制：飞书签名校验、请求频率限制、消息去重 Set 的清理策略、DeepSeek 调用失败时的用户侧提示。 - 对合规输出增加“证据置信度/需人工确认”字段，避免用户把 AI 提示直接当作最终法律意见。 ### 5. 综合评价从当前仓库来看，OPC4OPC 已经不是单纯概念项目，而是有明确入口、可部署服务、专项 Skills 和初步测试脚本的智能体 demo。方向选择、工作流入口和合规责任边界都比较清楚，适合半决赛阶段展示“AI 能在真实业务节点中触发价值”。下一轮最值得优先补强的是可验证性和工程完整性：让 `npm install && npm test` 有稳定结果，让三类场景都有可复现 demo，并补上 Webhook 安全校验与异常处理。

JunjieCai changed title from ~~PC4OPC 项目反馈（更新版）~~ to 【S1W3 交叉评测】PC4OPC 项目反馈（更新版）

2026-05-24 08:06:39 +08:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

xinqing/opc4opc#2

No description provided.

Rows
Columns