Flagship Product · V6.8
InfluenceOS
我把散落在飞书、Excel、浏览器与聊天里的达人运营，连接成一条可复核的 Campaign 工作流。
InfluenceOS 面向海外 Creator Marketing 运营与 Campaign 负责人，以 Campaign Operations 和 AI Creator Discovery 连接 Brief、研究、申请、匹配、Shortlist、建联准备与效果反馈。
AI 提供草稿、策略和建议，系统保存状态与证据，运营批准关键决策。它不是 Creator CRM，也不是 Autonomous Agent。
Business Context
团队缺少的不是另一张表，而是一层持续的 Campaign 运营上下文。
达人记录、项目名单、搜索结果、沟通进度和合作结果分别停留在飞书、Excel、浏览器、聊天和运营人员的记忆中。每次进入新 Campaign，团队都要重新理解 Brief、重建候选上下文，并再次解释为什么选择某位 Creator。
核心用户
海外 Creator Marketing 运营
Campaign 项目负责人
达人招募与合作跟进人员
需要继续使用飞书、但希望减少重复解释的运营团队
数据库只能回答『记录了谁』，无法持续回答『为什么选择、属于哪个 Campaign、是否已联系、合作后表现如何』。产品机会因此从存储达人，转向建立飞书与表格之上的 Campaign Operating Layer。
Original Workflow
原流程有很多工具，却没有连续上下文。
Client Brief 由运营人工理解，再通过浏览器搜索 Creator，把链接与判断复制到 Excel 或飞书；Shortlist、建联进度和合作结果继续留在聊天和个人笔记中。
每一步都有工具，但没有连续上下文
- Client Brief
- 人工理解
- 浏览器搜索
- Spreadsheet Notes
- 人工评估
- 聊天跟进
- 分散记录
同一 Campaign 中的受控运营闭环
- Campaign Brief
- AI Project Builder
- Creator Requirement
- Supervised Research
- Candidate Pool
- Creator Intelligence
- Explainable Matching
- Shortlist
- Outreach Draft
- Performance Feedback
Problem Discovery
真正的问题不是没有数据，而是关系、判断和状态无法进入下一步。
- 01
有达人记录，但没有 Campaign 上下文
数据库不能单独回答为什么选择、属于哪个项目、是否联系，以及合作后表现如何。
- 02
长期达人资产与项目申请人不是同一种对象
Creator Intake 建立长期资产，Project Application 只服务一次 Campaign；混用会污染数据和飞书同步边界。
- 03
推荐如果不可解释，就无法建立信任
Creator fit 包含内容、受众、品牌风险和主观判断，运营和客户不能只依赖一个分数。
- 04
Discovery 扩大范围，也同时制造噪音
公开搜索会返回群组、帖子、品牌页面和重复候选，来源与判断依据也容易随项目散失。
- 05
自动化必须服从业务确认和平台边界
候选导入、Shortlist、飞书写入、Outreach 和 Performance Judgement 都会产生真实后果。
Product Decisions
每次扩展能力前，先决定 AI 可以做什么、不能越过什么。
关键不是让 AI 执行更多动作，而是决定哪些判断可以被辅助、哪些状态必须被保留、哪些真实业务动作仍需由运营批准。
为什么是 Campaign Operating System，而不是数据库或表单？
- 背景
- 飞书表、Creator Database 和报名表都能保存局部数据，但无法维持 Brief、发现来源、选择理由、Shortlist 与执行状态之间的关系。
- 决策
- 选择在现有工具之上建立 Campaign Operating Layer，让 Project 成为上下文根节点，而不是继续扩展单张表。
- 取舍
- 系统需要维护更多对象与状态，但研究、判断和执行可以进入同一条工作流。
- 结果
- 运营可以围绕同一个 Campaign 追踪从需求到复盘的完整路径。
为什么分开 Creator Intake 与 Project Application？
- 背景
- 可选方案包括全部进入同一库、所有申请同步飞书，或按生命周期分离。长期 Intake 回答『是否成为长期资产』，项目报名只回答『是否参与这次 Campaign』。
- 决策
- 使用独立路由、数据表、审核路径和飞书边界；项目申请不会自动进入长期达人库。
- 取舍
- 增加两套入口和显式对象转换，但避免资产污染与错误同步。
- 结果
- 一次性申请不会污染长期资产，审核责任和数据归属更加清楚。
为什么是 Editable AI Draft，而不是自动创建？
- 背景
- 规则表单要求从空白填写，AI 直接创建又会放大 Brief 缺字段和模糊表达带来的错误。
- 决策
- Project Builder、Creator Strategy、Requirement 和 Search Plan 都先生成可编辑 Draft。
- 取舍
- 保留运营确认步骤，但避免从空白开始，也阻止未经确认的信息自动落库。
- 结果
- AI 减少重复解释，业务事实仍由人负责。
为什么是 Explainable Matching，而不是黑箱排名？
- 背景
- 纯分数、规则筛选和搜索排名都无法解释主观适配与风险，运营和客户需要理解推荐依据。
- 决策
- 同时呈现权重拆解、Confidence、Strengths、Weaknesses 和推荐理由。
- 取舍
- 输出比单一排名更复杂，也需要持续维护可读性。
- 结果
- 匹配从黑盒分数变成可以复核和讨论的决策支持。
为什么采用 Supervised Discovery 与 Explicit Research Memory？
- 背景
- 无限抓取和自动导入看似扩大召回，却会带来搜索噪声、平台限制、来源丢失与正式数据污染。
- 决策
- AI 生成 Strategy 与 Research Plan，运营批准每轮搜索；系统保存 Provenance，只有显式确认的候选和研究结论才能进入运营数据。
- 取舍
- 不追求无人值守，但保留来源、审核边界和可复用研究上下文。
- 结果
- Discovery 从一次性搜索变成可批准、可诊断、可积累的研究流程。
为什么坚持 HITL 与 Draft-only Outreach？
- 背景
- 自动选择和发送可以减少步骤，却会直接影响真实资产、客户判断与外部关系。
- 决策
- AI 辅助理解和生成，系统组织状态；最终选择、写入、发送和 Performance Judgement 由运营完成。
- 取舍
- 自动化程度受限，但保留责任、审计和异常恢复空间。
- 结果
- 自动化降低解释与整理成本，没有替代业务判断。
Unified Evolution Timeline
从 V1 到 V6.8，每次升级都由一个真实运营断点触发。
- V1
Operations Foundation & Creator Intake
- 真实问题
- 达人记录、项目关系和日常跟进缺少统一入口，运营只能在多个文件中维持状态。
- 产品决策
- 先建立 Creator、Project、Workspace 与受控 Intake，不急着加入 AI 或自动发现。
- 新能力
- Creator Database、Projects、Workspace、Creator Intake 与审批后同步。
- 结果
- 长期达人和项目第一次进入同一套可追踪的运营结构。
- V2.0–V2.3
Project Application + AI Project Builder
- 真实问题
- 长期达人与 Campaign Applicant 被混用，运营还要反复把 Client Brief 转成项目字段和报名内容。
- 产品决策
- 先分离两种业务对象，再让 AI 生成可编辑 Draft，而不是直接创建最终项目。
- 新能力
- 项目专属申请池、Public Application Link、Applicants Dashboard 与 AI Project Builder。
- 结果
- 一次性申请不再污染长期资产，项目搭建也从空白填写转为人工确认草稿。
- V2.4–V3.3
Intelligence, Explainable Matching & Execution
- 真实问题
- 原始达人字段不足以支持判断，只有分数的推荐也无法获得运营和客户信任。
- 产品决策
- 先建立 Creator Intelligence，再把匹配做成带理由、风险和不确定性的决策支持，并连接执行状态。
- 新能力
- Creator Intelligence、Explainable Matching、Shortlist、Workspace 与 Outreach Draft。
- 结果
- 达人评估从黑箱排名进入可复核、可跟进的 Campaign 工作流。
- V3.5–V4.6
Discovery Engine to Explicit Import
- 真实问题
- 团队需要研究新 Creator，但公开搜索带来噪声，自动导入还会污染正式达人资产。
- 产品决策
- 采用受控研究、Candidate Provenance、Human Review 和 Explicit Import，而不是无限抓取。
- 新能力
- Research Session、Candidate Pool、Provenance、Review 与显式导入边界。
- 结果
- Discovery 从一次性搜索变成可批准、可诊断、不会自动污染长期数据的研究流程。
- V5.0
Performance Feedback
- 真实问题
- 系统能解释谁看起来合适，却无法记录合作后的真实表现。
- 产品决策
- 先从人工录入的真实 Campaign 指标建立反馈，不提前承诺自动回传或自动学习。
- 新能力
- Performance Records、Creator History、Project Summary 与 AI Performance Analysis。
- 结果
- 产品获得复盘入口，但当前匹配排序尚未自动使用这些结果。
- V5.1–V6.2
Strategy, Research Loop & Memory
- 真实问题
- 单次搜索无法沉淀策略，下一次 Campaign 仍要重新解释需求并从头研究。
- 产品决策
- 把 Creator Strategy、Research Plan、逐轮批准和显式 Research Memory 连接起来。
- 新能力
- Creator Strategy、Multi-query Research、Round Evaluation、Provenance 与 Explicit Memory。
- 结果
- 经过运营确认的研究结论可以进入下一轮策略，而不是随项目结束而散失。
- V6.3–V6.8
Operator Workflow Simplification
- 真实问题
- 能力增加后，运营入口、状态和下一步动作变得复杂。
- 产品决策
- 围绕项目上下文、下一步行动、人工审批和研究诊断重新组织体验。
- 新能力
- Operator Home、简化入口、研究诊断、清晰 Review Boundary 与 Discovery UX。
- 结果
- V6.8 将复杂能力收束为更容易理解和操作的受控工作流。
AI Creator Discovery Engine
找到候选只是开始，真正的问题是如何把搜索噪音变成可复核的达人决策。
AI Creator Discovery Engine 将 Campaign 目标转成可审核的研究策略：运营批准每轮搜索，系统组织候选与 Provenance，再通过 Creator Intelligence 和 Explainable Matching 支持人工 Shortlist。
- 01Campaign Brief
明确 Campaign 目标、受众、交付要求与业务限制。
- 02Creator Strategy
将 Campaign 目标转化为 Creator 研究方向。
- 03Creator Requirement
把显式需求、推断信息和缺失条件整理成可确认的筛选标准。
- 04Research Plan
生成可执行、可编辑、可审核的多 Query 搜索计划。
- 05Approved Search Round
由运营确认本轮范围后，系统才执行受控研究。
- 06Candidate Pool
对候选去重，并保存 Creator、来源与 Provenance。
- 07Creator Intelligence
帮助理解内容风格、受众特征、合作偏好与潜在风险。
- 08Explainable Matching
解释推荐理由、置信度与不足，而不是只输出排名。
- 09Human Review
由运营接受或放弃分析，并确认导入与最终合作判断。
- 10Shortlist
把经过批准的候选转成可跟进的项目运营记录。
AI 扩展研究能力，系统组织候选与证据；运营批准 Search Round、导入与 Shortlist。系统不会自动选择 Creator，也不会自动发送 Outreach。
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，把新达人研究转成可复核决策。
- 01Campaign Brief
- 02Creator Strategy
- 03Creator Requirement
- 04Supervised Research
- 05Candidate Pool
- 06Creator Intelligence
- 07Explainable Matching
- 08Shortlist
- 09Project Workspace
- 10Outreach Draft
- 11Performance Feedback
架构
技术选择服务于业务边界，而不是先于业务故事。
运营体验层
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
Human-in-the-loop
AI 提议，系统组织，人做最终批准。
这个领域同时存在信息不完整、主观适配、平台安全与外部沟通风险。AI 适合减少解释和起草工作，系统负责保存关系与状态，人负责业务事实和不可逆动作。
提出可复核建议
- 生成 Project / Strategy Draft
- 总结 Creator Intelligence
- 推荐并解释 Matching
- 起草 Outreach
- 分析 Research 与 Performance
组织上下文与边界
- 维持 Project 与对象关系
- 区分 Intake、Applicant、Candidate
- 保留来源与状态
- 控制写入、去重与审核入口
批准真实业务动作
- 确认 Brief 与策略
- 批准每轮 Research
- 选择、导入与 Shortlist
- 发送 Outreach
- 录入并判断 Performance
产品证据
先理解工作流，再查看已经实现的界面证据。
当前公开证据包含 5 张 V6.8 脱敏演示截图。未在安全公开环境复现的 Matching、Shortlist 与 Performance 界面不伪造；截图不包含客户、真实达人或登录态。
Impact
先证明流程、边界与决策透明度，再继续验证生产结果。
当前可确认的价值，是把 Campaign Operations 与 Creator Discovery 组织成一条受控工作流：状态可以延续，候选来源和选择理由可以复核，长期达人、项目申请人与研究候选保持正确边界。量化数据来自较早的特定验证场景，不代表 V6.8 全系统生产表现。
飞书、Excel、浏览器与聊天分别保存片段
Project Workspace 持续保留同一 Campaign 上下文
运营每次重新解释 Brief 与候选理由
AI Draft 与 Explainable Matching 提供可复核起点
每个 Campaign 重新搜索，策略、来源与判断依据随项目散失
Strategy、Provenance 与 Research Memory 形成可复用的 Creator Research Asset
候选、申请人与长期达人容易混用
三类对象按生命周期分离并通过显式动作转换
当前产品价值：Brief、Research、Matching、Shortlist、Workspace、Outreach Draft 与 Performance 进入同一 Campaign 上下文。
当前产品价值：长期 Creator、Campaign Applicant 与 Research Candidate 按生命周期分离，关键写入保持显式确认。
当前产品价值：搜索策略、候选来源与判断依据可以被追踪，经过确认的 Research Memory 可为后续 Campaign 提供上下文。
- 126 位
- 早期 V1 飞书同步验证形成的 Creator 记录不代表当前活跃用户、Campaign 数或 V6.8 生产规模
- 61 → 20 → 9
- 早期 Timekettle 特定场景：候选链接、重点审核、值得联系仅对应当时的 Discovery / Lead Review 验证
- 2.5–3.5h → 20–35min
- 该特定场景记录的人工流程与系统辅助流程为早期估算，不是 V6.8 端到端生产 SLA
- 约 75%–85%
- 该早期场景文档记录的预计时间节省不外推到其他 Campaign，也不替代未来生产指标
当前测量边界
尚未验证：当前没有可靠的 V6.8 生产活跃、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 指标由运营人工录入。
尚无可靠的 V6.8 生产活跃、留存、转化或完整端到端节省数据。