Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

第二大脑业务需求说明书

场景一:今天要不要接这个项目?

决策频率:每周多次。决策者:项目负责人。

业务映射

量潮的订单特征是"数千到一两万、几周结项、质量要求高"。接不接不是一个收入问题,是一个效率问题——团队只有几个人,每个项目都需要从零培养的人才去交付。接了一个低利润、高沟通成本的项目,等于占用了本该用在复购客户上的产能。

同时量潮有两条业务线(数据 + 教育)在跑产教融合循环。如果两类项目比例失衡,融合循环就会断掉——只做数据项目,教育侧的知识积累停滞,长期拿不到教育订单;反过来也一样。所以"接不接"的决策实际是在同时管理现金流、产能和知识结构三条线。

需求侧还有一层:获客困难,每一个项目机会都来之不易。放弃一个机会的心理成本很高,所以更容易"先接了再说"——然后产能过载,交付质量下降,反而伤害信誉。

当前做法

查表格看当前产能 → 问财务看现金流 → 翻聊天记录回忆客户背景 → 凭感觉拍板。

决策现场

项目面板只展示三样东西:

  1. 当前容量 — 团队同时能跑 N 个项目,现在跑了 M 个,还剩 N-M 个。满了直接告诉你"现在接不了",而不是弹一个空白的"新建项目"表单。

  2. 正在跑的项目 — 每个项目显示进度条、客户、金额。进度落后预期 20% 以上的,卡片左侧色条变红——不是硬阈值报警,是告诉你"这个项目需要你注意,接新项目前先想清楚"。

  3. 待承接的项目 — 每个待接项目只问三个问题:

    • 金额够不够覆盖团队一周的成本? → 绿/黄/红(量潮的订单利润薄,几千块的单子可能刚好 cover 一周人力)

    • 客户是回头客还是新客? → 显示复购次数(海外客户、高校客户、企业客户的复购率不同)

    • 项目类型(数据/教育)和当前产能缺口匹配吗? → 教育类积压时数据类优先,维持融合循环平衡

决策之后

点了"接",系统自动:在项目管道插入记录 → 锁定一个空闲成员 → 按项目类型增加知识积累值。不需要填表单,不需要切页面。决策摩擦约等于点一次确认。

替代路径

当系统积累了足够多的"接/不接"历史决策后,开始显示推荐置信度:“推荐「接」,匹配度 87%”。负责人可以采纳,也可以推翻。系统记录每次偏差来校准模型。直到连续三个月没有推翻过推荐——这个决策已经可以交给系统了。


场景二:这件事该找谁?

决策频率:每天多次。决策者:任何需要协作的人。

业务映射

量潮的人才几乎都是从零培养的。供给侧的现实是"高校教育体系落后保守,需要的人才都得自己带"。这就意味着:

加上团队的矩阵式组织架构(项目线 + 职能线),传统"查组织架构图"的方式完全失效——你需要的不是一个头衔,而是一个"现在有空、技能匹配、之前和这个客户打过交道"的人。

当前做法

在群里问"这个谁负责?" → 等有人回复 → 或者猜一个名字发过去 → 被转给另一个人。

决策现场

在任意知识对象(项目、客户、任务)的页面上,都有一个区域叫相关的人

不需要查组织架构图。不需要问人。

替代路径

当系统发现你总是指定同一个人处理某类问题时,自动提示:“需要把这类问题自动转给张三吗?” 接受后,相关请求直达对应的人。直到有一天,你不再需要去想"该找谁"——因为系统已经在你问之前就转过去了。


场景三:这个决策当时是怎么来的?

决策频率:每周几次(复盘/客户质疑/新人问起)。决策者:所有需要回溯上下文的人。

业务映射

量潮面临的核心问题是"如何把隐式的基于具体情境的经验提炼成显式的基于文本的经验"。这有两个驱动力:

一是制度建设的需要。从人治到法治的关键一步是"决策可回溯"——当一个新人问"为什么当时选了这个方案"时,答案不能是"老张说的"。

二是产教融合循环本身的高度耦合。一个教育项目的决策(比如调整课程内容)会影响数据项目的排期(因为讲师被调走了),影响实习生的培养计划(因为课程调整了教学节奏),影响客户的复购意愿(因为交付时间变了)。这些跨对象的因果链如果不能被记录和回溯,每次复盘就只能靠当事人回忆。

当前做法

翻聊天记录 → 翻邮件 → 翻文档 → 拼凑出一个大概。关键细节经常丢失。

决策现场

每条决策记录是一张卡片,而不是一行日志。卡片上只有四块:

  1. 在什么情境下做的 — 当时项目进度、财务状态、可选方案

  2. 谁参与了 — 参与人列表及每个人当时的输入

  3. 选了哪个方案 — 选了的方案和没选的理由

  4. 结果怎么样 — 事后回填的结论标签(正确/有偏差/错误)

替代路径

当系统积累到足够多的决策卡片后,开始做两件事:


场景四:这条信息该记吗?

决策频率:每天数十次。决策者:所有人。

业务映射

量潮面临的挑战之一是"显式化隐性经验"。团队协作中的大量信息是情境化的:和客户喝咖啡时聊到的需求变更、看到一篇论文想到的数据处理方法、实习生反馈的教学盲点。这些信息在被记录的当下是清晰的,但如果不立刻记下来,几小时后上下文就丢了。

同时,产教融合循环本身是一个信息密集型系统——数据项目的技术积累应该反哺教育项目的内容,教育项目的教学反馈应该指导数据项目的方法论。这个循环的前提是两边产生的信息能被对方看到。如果信息散落在各自的笔记和聊天记录里,融合就无从谈起。

最后,"如何确保新人会接受规范而不让规范流失"这个问题也依赖于信息的结构化沉淀——规范不能只存在于创始人的脑子里或一本 60 页的手册里,它应该出现在新人做决策的那一刻。

当前做法

记了 → 以后找不到。不记 → 需要时想不起来。最终选择:要么什么都记(信息过载),要么什么都不记(信息丢失)。

决策现场

系统不要求用户自己判断"该不该记"。用户只需要保持自然的工作状态——写日志、开会、回消息。系统自动:

用户不需要在任何时候停下来"整理"。整理是系统的事,不是人的事。

替代路径

系统开始预测你需要什么信息。在开会前推送相关项目的最新动态,在写日志时提示"上次这个客户的事后来怎么样了?要追一下吗?"——信息不是等人来找,而是主动出现在决策发生之前。


场景五:这个活干完了,然后呢?

决策频率:每个项目结束一次。决策者:项目负责人。

业务映射

量潮的两条业务线都需要通过项目沉淀可复用的资产。

数据业务:每个项目都会积累数据处理的经验(清洗规则、分析框架、行业知识),但大部分项目之间的做法是不互通的。下一个类似项目来了,从零开始摸索一遍——这对"效率敏感"的商业模式是致命的。

教育业务:浙理工的合作是一个标杆案例,证明了"企业-高校深度合作"的商业模式可行。但这个模式的可复制性取决于能不能从单一案例中抽象出可复用的方法论——而不是每次面对新学校时都从"老师好,我们公司是做什么的"开始。

标准化体系的建设正是在解决这个问题。每个项目结束时,系统能从执行过程中沉淀出流程资产,让下一个项目站在前一个的肩膀上。

当前做法

项目交付 → 写一份总结文档 → 存档 → 再也不看。下一个类似项目重新踩一遍同样的坑。

决策现场

项目结束后,系统问三个问题:

  1. 哪些做法可以复用? → 自动提取本次项目中效率最高的流程环节

  2. 哪些坑下次可以避免? → 自动提取延期、返工、沟通失误的关键节点

  3. 这产生了哪些新知识? → 自动统计项目中积累的文档、代码、决策记录

这些不需要手动填写,是在项目执行过程中自然沉淀的。负责人只需要确认和补充。

替代路径

当系统积累了足够多的项目结束后,新项目启动时自动注入相关经验:“上一个和这个类似的项目用了 10 周,其中数据清洗环节花了 3 周。如果这次复用上次的工具链,预计可以缩短到 2 周。”


这些场景覆盖了从接项目、找人、回溯决策、信息捕捉、到项目收尾的完整链条。每个场景的终点都是同一个方向:让系统逐步替代自己的判断,而非让系统帮自己记得更多。