Flagship Product

V8.0 · 持续迭代

InfluenceOS

InfluenceOS 面向海外 Creator Marketing 运营与 Campaign 负责人，以 Campaign Operations 和 AI Creator Discovery 连接 Brief、研究、申请、匹配、Shortlist、建联准备与效果反馈。

查看产品证据查看产品决策
运营首页以项目、研究候选、待筛选和 Shortlist 为主线的运营总览。画面使用完全虚构的演示 Campaign。

Public evidence · V6.8 脱敏演示当前产品版本为 V8.0，公开截图不伪装成当前界面。

Product
AI-assisted Creator Campaign Operating System
Role
产品负责人 / AI 产品设计 / 全栈原型实现
Access
受控访问
Verified
2026.08.03

Executive Summary

先看业务问题、产品解法与 AI 边界。

01

Problem

运营上下文被工具切碎

数据库只能回答『记录了谁』，无法持续回答『为什么选择、属于哪个 Campaign、是否已联系、合作后表现如何』。产品机会因此从存储达人，转向建立飞书与表格之上的 Campaign Operating Layer。

02

Solution

建立 Campaign Operating Layer

AI-assisted Creator Campaign Operating System：用 Campaign Operations 与 AI Creator Discovery 连接从 Brief 到复盘的受控工作流。

03

AI Boundary

AI 提议，运营批准

AI 提供草稿、策略和建议，系统保存状态与证据，运营批准关键决策。它不是 Creator CRM，也不是 Autonomous Agent。

Business Context

团队缺少的不是另一张表，而是一层持续的 Campaign 运营上下文。

达人数据、搜索结果和沟通记录都存在，但分散在不同工具中。团队每次进入新 Campaign，都要重新理解 Brief、重建候选上下文并解释选择理由。

谁在使用
海外 Creator Marketing 运营 · Campaign 项目负责人 · 达人招募与合作跟进人员 · 需要继续使用飞书、但希望减少重复解释的运营团队
信息散落在哪
飞书 · Excel · 浏览器搜索 · 聊天记录 · 人工笔记
真正的断点
每个 Campaign 都要重新理解 Brief、重建候选上下文并解释选择理由
改造前 · 分散人工流程

每一步都有工具，但没有连续上下文

信息留在工具里，判断留在人脑里。

  1. 01Client Brief
  2. 02人工理解
  3. 03浏览器搜索
  4. 04Spreadsheet Notes
  5. 05人工评估
  6. 06聊天跟进
  7. 07分散记录
改造后 · 当前受控流程

同一 Campaign 中的受控运营闭环

研究、选择与执行状态持续留在同一 Campaign。

  1. 01Campaign Brief
  2. 02AI Project Builder
  3. 03Creator Requirement
  4. 04Supervised Research
  5. 05Candidate Pool
  6. 06Creator Intelligence
  7. 07Explainable Matching
  8. 08Shortlist
  9. 09Outreach Draft
  10. 10Performance Feedback

Problem Discovery

我把五个零散问题，收敛成三项产品设计任务。

  1. 01

    Campaign 上下文没有沉淀

    发现达人记录存在，但选择理由、所属项目、联系状态与合作结果彼此断开。

    我做的产品决策以 Project 为上下文根节点，让研究、匹配、Shortlist 和执行状态留在同一条路径里。

  2. 02

    业务对象与判断边界混在一起

    发现长期达人、项目申请人与研究候选不是同一种对象；黑箱分数也无法承担合作判断。

    我做的产品决策分离 Intake、Application 与 Candidate，并用 Explainable Matching 呈现理由、优势与风险。

  3. 03

    发现能力扩大后，噪声与风险也扩大

    发现公开搜索带来重复候选、来源丢失和平台边界；自动导入或发送会产生真实业务后果。

    我做的产品决策采用 Supervised Discovery、Candidate Pool 与 HITL，所有关键写入和外部动作保留人工批准。

Product Decisions

每次扩展能力前，先决定 AI 可以做什么、不能越过什么。

关键不是让 AI 执行更多动作，而是决定哪些判断可以被辅助、哪些状态必须被保留、哪些真实业务动作仍需由运营批准。

01

为什么是 Campaign Operating System，而不是数据库或表单？

Context
飞书表、Creator Database 和报名表都能保存局部数据，但无法维持 Brief、发现来源、选择理由、Shortlist 与执行状态之间的关系。
Decision
选择在现有工具之上建立 Campaign Operating Layer，让 Project 成为上下文根节点，而不是继续扩展单张表。
Trade-off
系统需要维护更多对象与状态，但研究、判断和执行可以进入同一条工作流。
Result
运营可以围绕同一个 Campaign 追踪从需求到复盘的完整路径。
02

为什么分开 Creator Intake 与 Project Application？

Context
可选方案包括全部进入同一库、所有申请同步飞书，或按生命周期分离。长期 Intake 回答『是否成为长期资产』，项目报名只回答『是否参与这次 Campaign』。
Decision
使用独立路由、数据表、审核路径和飞书边界；项目申请不会自动进入长期达人库。
Trade-off
增加两套入口和显式对象转换，但避免资产污染与错误同步。
Result
一次性申请不会污染长期资产，审核责任和数据归属更加清楚。
03

为什么是 Editable AI Draft，而不是自动创建？

Context
规则表单要求从空白填写，AI 直接创建又会放大 Brief 缺字段和模糊表达带来的错误。
Decision
Project Builder、Creator Strategy、Requirement 和 Search Plan 都先生成可编辑 Draft。
Trade-off
保留运营确认步骤，但避免从空白开始，也阻止未经确认的信息自动落库。
Result
AI 减少重复解释，业务事实仍由人负责。
04

为什么是 Explainable Matching，而不是黑箱排名？

Context
纯分数、规则筛选和搜索排名都无法解释主观适配与风险，运营和客户需要理解推荐依据。
Decision
同时呈现权重拆解、Confidence、Strengths、Weaknesses 和推荐理由。
Trade-off
输出比单一排名更复杂，也需要持续维护可读性。
Result
匹配从黑盒分数变成可以复核和讨论的决策支持。
05

为什么采用 Supervised Discovery 与 Explicit Research Memory？

Context
无限抓取和自动导入看似扩大召回，却会带来搜索噪声、平台限制、来源丢失与正式数据污染。
Decision
AI 生成 Strategy 与 Research Plan，运营批准每轮搜索；系统保存 Provenance，只有显式确认的候选和研究结论才能进入运营数据。
Trade-off
不追求无人值守，但保留来源、审核边界和可复用研究上下文。
Result
Discovery 从一次性搜索变成可批准、可诊断、可积累的研究流程。
06

为什么坚持 HITL 与 Draft-only Outreach？

Context
自动选择和发送可以减少步骤，却会直接影响真实资产、客户判断与外部关系。
Decision
AI 辅助理解和生成，系统组织状态；最终选择、写入、发送和 Performance Judgement 由运营完成。
Trade-off
自动化程度受限，但保留责任、审计和异常恢复空间。
Result
自动化降低解释与整理成本，没有替代业务判断。

Unified Evolution Timeline

从 V1 到 V8.0，每次升级都由一个真实运营断点触发。

  1. V1

    Operations Foundation & Creator Intake

    Problem
    达人记录、项目关系和日常跟进缺少统一入口，运营只能在多个文件中维持状态。
    Decision
    先建立 Creator、Project、Workspace 与受控 Intake，不急着加入 AI 或自动发现。
    Capability
    Creator Database、Projects、Workspace、Creator Intake 与审批后同步。
    Result
    长期达人和项目第一次进入同一套可追踪的运营结构。
  2. V2.0–V2.3

    Project Application + AI Project Builder

    Problem
    长期达人与 Campaign Applicant 被混用，运营还要反复把 Client Brief 转成项目字段和报名内容。
    Decision
    先分离两种业务对象，再让 AI 生成可编辑 Draft，而不是直接创建最终项目。
    Capability
    项目专属申请池、Public Application Link、Applicants Dashboard 与 AI Project Builder。
    Result
    一次性申请不再污染长期资产，项目搭建也从空白填写转为人工确认草稿。
  3. V2.4–V3.3

    Intelligence, Explainable Matching & Execution

    Problem
    原始达人字段不足以支持判断，只有分数的推荐也无法获得运营和客户信任。
    Decision
    先建立 Creator Intelligence，再把匹配做成带理由、风险和不确定性的决策支持，并连接执行状态。
    Capability
    Creator Intelligence、Explainable Matching、Shortlist、Workspace 与 Outreach Draft。
    Result
    达人评估从黑箱排名进入可复核、可跟进的 Campaign 工作流。
  4. V3.5–V4.6

    Discovery Engine to Explicit Import

    Problem
    团队需要研究新 Creator，但公开搜索带来噪声，自动导入还会污染正式达人资产。
    Decision
    采用受控研究、Candidate Provenance、Human Review 和 Explicit Import，而不是无限抓取。
    Capability
    Research Session、Candidate Pool、Provenance、Review 与显式导入边界。
    Result
    Discovery 从一次性搜索变成可批准、可诊断、不会自动污染长期数据的研究流程。
  5. V5.0

    Performance Feedback

    Problem
    系统能解释谁看起来合适，却无法记录合作后的真实表现。
    Decision
    先从人工录入的真实 Campaign 指标建立反馈，不提前承诺自动回传或自动学习。
    Capability
    Performance Records、Creator History、Project Summary 与 AI Performance Analysis。
    Result
    产品获得复盘入口，但当前匹配排序尚未自动使用这些结果。
  6. V5.1–V6.2

    Strategy, Research Loop & Memory

    Problem
    单次搜索无法沉淀策略，下一次 Campaign 仍要重新解释需求并从头研究。
    Decision
    把 Creator Strategy、Research Plan、逐轮批准和显式 Research Memory 连接起来。
    Capability
    Creator Strategy、Multi-query Research、Round Evaluation、Provenance 与 Explicit Memory。
    Result
    经过运营确认的研究结论可以进入下一轮策略，而不是随项目结束而散失。
  7. V6.3–V6.8

    Operator Workflow Simplification

    Problem
    能力增加后，运营入口、状态和下一步动作变得复杂。
    Decision
    围绕项目上下文、下一步行动、人工审批和研究诊断重新组织体验。
    Capability
    Operator Home、简化入口、研究诊断、清晰 Review Boundary 与 Discovery UX。
    Result
    V6.8 将复杂能力收束为更容易理解和操作的受控工作流。
  8. V6.9–V7.5

    Supervised Research Agent & Discovery Quality

    Problem
    多轮研究已经可执行，但运营仍要手动判断下一步搜索方向，召回扩大后也更容易混入重复、低相关和非 Creator 结果。
    Decision
    让 Agent 只提出有上限、可解释的研究动作，由运营批准后执行；同时用 Recall-first 策略扩大候选，再通过质量检查恢复精度。
    Capability
    Bounded Research Agent、Action Feedback、Research Memory、Search Matrix、Query Quality 与 Candidate Qualification。
    Result
    研究从固定流程升级为可提出下一步建议的受监督循环，但搜索、导入和 Shortlist 仍不自动执行。
  9. V7.6–V8.0

    Creator Search Intelligence

    Problem
    Campaign Brief 使用业务语言，而 Creator 在 Instagram 资料和内容中使用身份、场景与市场语言；直接照抄 Brief 容易产生低平台适配的 Query。
    Decision
    在执行前增加受控搜索语义层，把 Business、Creator 与 Scenario Vocabulary 分开，并标注 Core、Adjacent、Exploration 与 Platform Fit。
    Capability
    Creator-facing Vocabulary、Market Adaptation、Query Platform Fit、Expansion Rationale 与 Search Performance Feedback。
    Result
    V8.0 让 Search Plan 更贴近 Creator 的公开表达，并把每条 Query 的结果质量沉淀为后续研究证据，而不是自动训练或改写策略。

AI Creator Discovery Engine

找到候选只是开始，真正的问题是如何把搜索噪音变成可复核的达人决策。

AI Creator Discovery Engine 将 Campaign 目标转成可审核的研究策略：运营批准每轮搜索，系统组织候选与 Provenance，再通过 Creator Intelligence 和 Explainable Matching 支持人工 Shortlist。

  1. 01
    Campaign Brief

    明确 Campaign 目标、受众、交付要求与业务限制。

  2. 02
    Creator Strategy

    将 Campaign 目标转化为 Creator 研究方向。

  3. 03
    Creator Requirement

    把显式需求、推断信息和缺失条件整理成可确认的筛选标准。

  4. 04
    Research Plan

    生成可执行、可编辑、可审核的多 Query 搜索计划。

  5. 05
    Approved Search Round

    由运营确认本轮范围后，系统才执行受控研究。

  6. 06
    Candidate Pool

    对候选去重，并保存 Creator、来源与 Provenance。

  7. 07
    Creator Intelligence

    帮助理解内容风格、受众特征、合作偏好与潜在风险。

  8. 08
    Explainable Matching

    解释推荐理由、置信度与不足，而不是只输出排名。

  9. 09
    Human Review

    由运营接受或放弃分析，并确认导入与最终合作判断。

  10. 10
    Shortlist

    把经过批准的候选转成可跟进的项目运营记录。

Current Solution

Campaign Operations 与 AI Creator Discovery，共同完成从 Brief 到复盘的受控闭环。

InfluenceOS 面向海外 Creator Marketing 运营与 Campaign 负责人。它在飞书、表格和外部研究之上连接项目执行与新达人发现，用 AI 辅助解释和决策，但把关键写入、选择与外部动作保留给运营。

双核心能力

Campaign Operations System：负责 Project Builder、Applications、Shortlist、Workspace、Outreach 与 Performance，把项目从 Brief 推进到执行和复盘。

AI Creator Discovery Engine：负责 Creator Strategy、Research Plan、Candidate Pool、Creator Intelligence、Explainable Matching 与 Human Review，把新达人研究转成可复核决策。

  1. 01
    Campaign Brief
  2. 02
    Creator Strategy
  3. 03
    Research Plan
  4. 04
    Candidate Pool
  5. 05
    Creator Intelligence
  6. 06
    Explainable Matching
  7. 07
    Human Review
  8. 08
    Shortlist

架构

技术选择服务于业务边界，而不是先于业务故事。

运营体验层

Next.js Project Workspace 把 Brief、研究、Shortlist、Outreach 与 Performance 保持在同一 Campaign 上下文中。

Next.js App Router / React / TypeScript

Project-centered operator workspace

持久运营状态

Supabase 保存生产所需的持久状态；飞书继续承担公司达人资产协同；SQLite 只作为本地原型与兼容层。

Supabase-first operational state

Feishu enhancement boundary

SQLite local fallback

AI 决策支持层

DeepSeek 负责结构化解释、草稿和建议，结果先进入可编辑或可接受状态，无法使用时明确标注 fallback。

Project / Strategy / Intelligence drafts

Explainable Matching / Performance analysis

受控研究层

Playwright 与 provider/connector 分层只执行运营批准的研究动作，候选需审核和显式导入后才进入长期运营数据。

Bounded Playwright sessions

Candidate Pool / provenance / explicit import

Next.js 15React 19TypeScriptSupabaseSQLiteDeepSeekPlaywrightFeishu APICSV ExportVercel

Human-in-the-loop

AI 提议，系统组织，人做最终批准。

AI suggests. System structures. Human approves.

这个领域同时存在信息不完整、主观适配、平台安全与外部沟通风险。AI 适合减少解释和起草工作，系统负责保存关系与状态，人负责业务事实和不可逆动作。

AI

提出可复核建议

  • 生成 Project / Strategy Draft
  • 总结 Creator Intelligence
  • 推荐并解释 Matching
  • 起草 Outreach
  • 分析 Research 与 Performance
System

组织上下文与边界

  • 维持 Project 与对象关系
  • 区分 Intake、Applicant、Candidate
  • 保留来源与状态
  • 控制写入、去重与审核入口
Human

批准真实业务动作

  • 确认 Brief 与策略
  • 批准每轮 Research
  • 选择、导入与 Shortlist
  • 发送 Outreach
  • 录入并判断 Performance

产品证据

每张截图都对应一个已经实现、可以被验证的产品判断。

案例内容已按 V8.0 代码、文档与 Git 历史校准；当前公开媒体仍是 5 张 V6.8 脱敏演示截图，不伪装成 V8.0 界面。未在安全公开环境复现的 Matching、Shortlist 与 Performance 界面不伪造；截图不包含客户、真实达人或登录态。

运营首页以项目、研究候选、待筛选和 Shortlist 为主线的运营总览。画面使用完全虚构的演示 Campaign。V6.8 · 脱敏演示
AI Project Builder 可编辑草稿Client Brief 生成可编辑 Project Fields 与 Application Settings，创建前由运营确认。V6.8 · 脱敏演示
受控达人研究四步研究工作流先确认项目目标，再进入可编辑的搜索方案、分轮研究与候选池审核。V6.8 · 脱敏演示
项目公开申请入口每个 Campaign 拥有独立公开申请入口与问题配置，申请记录不自动进入长期达人资产。V6.8 · 脱敏演示
长期 Creator Intake长期合作达人入口与 Project Application 分开建模，避免一次性申请污染长期资产。V6.8 · 脱敏演示

Impact

先证明流程、边界与决策透明度，再继续验证生产结果。

当前可确认的价值，是把 Campaign Operations 与 Creator Discovery 组织成一条受控工作流：状态可以延续，候选来源和选择理由可以复核，长期达人、项目申请人与研究候选保持正确边界。V8.0 进一步把 AI Creator Research 连接到可审核的搜索语义、研究建议与反馈证据，使产品向 AI-assisted Creator Operations System 演进。量化数据来自较早的特定验证场景，不代表 V8.0 全系统生产表现。

Before

飞书、Excel、浏览器与聊天分别保存片段

After

Project Workspace 持续保留同一 Campaign 上下文

Before

运营每次重新解释 Brief 与候选理由

After

AI Draft 与 Explainable Matching 提供可复核起点

Before

每个 Campaign 重新搜索，策略、来源与判断依据随项目散失

After

Strategy、Provenance 与 Research Memory 形成可复用的 Creator Research Asset

Before

候选、申请人与长期达人容易混用

After

三类对象按生命周期分离并通过显式动作转换

当前产品价值：Brief、Research、Matching、Shortlist、Workspace、Outreach Draft 与 Performance 进入同一 Campaign 上下文。

当前产品价值：长期 Creator、Campaign Applicant 与 Research Candidate 按生命周期分离，关键写入保持显式确认。

当前产品价值：搜索策略、候选来源与判断依据可以被追踪，经过确认的 Research Memory 可为后续 Campaign 提供上下文。

126 位
早期 V1 飞书同步验证形成的 Creator 记录不代表当前活跃用户、Campaign 数或 V8.0 生产规模
61 → 20 → 9
早期 Timekettle 特定场景：候选链接、重点审核、值得联系仅对应当时的 Discovery / Lead Review 验证
2.5–3.5h → 20–35min
该特定场景记录的人工流程与系统辅助流程为早期估算，不是 V8.0 端到端生产 SLA
约 75%–85%
该早期场景文档记录的预计时间节省不外推到其他 Campaign，也不替代未来生产指标

当前测量边界

尚未验证：当前没有可靠的 V8.0 生产活跃、Creator 转化、Campaign 成功率或端到端节省时间指标。

Reflection

下一步不是继续堆模块，而是验证反馈闭环是否改变下一轮决策。

当前限制

InfluenceOS 不是 Autonomous Agent；关键保存、批准、导入、Shortlist 和发送动作均需要运营确认。

Production 不提供稳定的 Playwright live Instagram Discovery；真实搜索依赖受控本地登录会话。

Google 与 YouTube 目前仍是 provider foundation / mock，不是完整 live connector。

Candidate Pool 与活跃 Research Session 主要是会话状态；只有显式保存的 Research Memory 进入 Supabase。

Outreach 只生成草稿，不自动发送；Performance 指标由运营人工录入。

尚无可靠的 V8.0 生产活跃、留存、转化或完整端到端节省数据。

反思：AI 产品的价值不在于让模型执行更多动作，而在于把模糊判断转化为可审核的结构，并让状态进入下一步。

反思：工作流应先于 Agent：没有清晰对象、状态和责任边界，自动化只会更快地放大错误。

反思：可解释匹配与受控研究的共同价值，是让运营在关键业务节点继续拥有决定权。

下一步：用真实 Campaign 验证 Research Memory 是否减少重复研究、Explainable Matching 是否改善决策沟通。

下一步：验证 Performance Feedback 是否真正影响下一轮 Strategy 与 Matching，而不是继续堆叠模块。