前段时间我把自己的日常工作流整个重构了一遍，用“vibe coding”的方式给自己搭了一套真正能用的金融一级市场 workos。先说清楚，这里的“workos”不是指某个特定商业产品，而是指一套围绕“我”这个从业者日常高频动作组织的个人工作系统：项目漏斗、会议纪要、尽调记录、被投跟踪、行业研究、提醒日历，全部收口到一个入口里，不再让微信、Excel、飞书、邮件各自为政。这套东西不复杂，但对我每天的工作节奏改变很大，这篇文章想把从需求拆解、技术选型到落地踩坑的完整过程分享出来，尤其是对正在考虑自建内部工具的一级市场从业者，应该有一些直接可复用的思路。
1. 为什么是一级市场，为什么是 workos
先说说背景。一级市场的日常工作，表面上是看项目、开会、写纪要、约谈创始人，实际上是一个持续被碎片信息打断的过程。今天下午三点还坐在办公室里读 BP，晚上九点可能已经在高铁上改投委会材料。项目状态从初次接触到立项、尽调、投决、交割，它会推进，也会回退，甚至搁置半年后又被重新拎起来。信息散落在邮箱附件、本地PDF、共享网盘、聊天记录和笔记本里，真正到了要写备忘录或者向团队同步的时候，往往需要花大量时间翻找原资料。这种感觉就像是每天都在收集拼图碎片，但从来没有一张完整的桌子来放它们。
二级市场的从业者有很多现成的信息工具，行情软件、数据终端、量化平台，一整套都是工业化标准。但一级市场不同，项目的非标准化程度太高，每家机构的投委会决策逻辑、每个基金的被投企业跟踪节奏、每个合伙人在意的问题都不一样。市面上的通用 CRM 更多是为销售团队设计的，字段是线索、商机、客户、合同，而一级市场真正要记的是一个项目的成立逻辑、竞争格局、估值预期、竞品协议条款、尽调发现的瑕疵、管理层的状态。这些东西塞进标准字段里会特别别扭，自由度也不够。与其去迁就一个并不完全匹配的工具，不如用 vibe coding 的方式，给自己搭一套贴合工作习惯的私有化系统。
vibe coding 这个词，本质上描述的是一种不完全按照传统软件工程流程走的编码方式：不先做几十页需求文档，不追求完美的架构分层，而是顺着自己对一个场景的整体感觉，借助 AI 辅助快速生成代码，把骨架先立起来，再在实际使用中不断修正。放在内部工具和个人生产力工具这个场景里，再合适不过。它不需要通过严苛的内部安全评审，不需要给整个团队做培训，只要能解决我自己的核心痛点，哪怕界面糙一点、菜单乱一点，都完全可接受。你甚至可以把它当成一个永远可以改的数字笔记本，今天觉得少了一个字段，就补一个字段，明天觉得某个流程不顺，就顺手改掉。
很多人会问，这种自己搭的东西靠不靠谱、值不值得花时间。我的看法是，它本质上更像是在给自己做一套定制的信息管理操作系统，价值取决于你对工作流的理解是否到位，而不取决于代码写得是否优雅。这也是为什么我觉得“vibe coding + 个人 workos”天生就是一对：一级市场的工作流太个性，每一个从业者关注的行业、阶段、关键信息都不一样，只有自己最清楚自己要什么。与其等待一款万能工具来拯救，不如自己上手先解决 80% 的问题。
2. 先拆工作流：一级市场从业者的“隐性待办”都在哪
动手写代码之前，我做的事是先画一张自己的工作流地图。很多人搭个人系统失败，不是技术不行，而是根本没理清自己日常要处理哪些类型的任务，导致工具搭出来之后，根本没有真实需求喂进去。把工作流拆清楚，是整个项目里最重要的一步，也是 vibe coding 能真正落地的关键。
2.1 项目漏斗不是一张表，而是一条会回流的信息河
一级市场的项目漏斗，和软件行业常见的销售漏斗最大的不同，是它并不总是一个从宽到窄的单向流程。一个项目可能在一个月前还处于非常初级的接触阶段，因为某个大机构领投了新一轮，突然进入重点跟进状态；也可能因为行业政策变化而暂时搁置，过了半年又重新启动。所以状态字段必须设计成可以随意回退和重新改动的字符串，而不是一串固定的布尔值。
除了状态，项目信息源也非常散。有朋友推荐的，有 FA 推过来的，有自己在某个行业会议上聊出来的，有跟踪了很长时间的老团队终于准备融资的。这些信息源直接影响你对项目的判断优先级。而真正到了尽调阶段，需要跟踪的就不只是创始人和融资额度了，还有财务数据、法律结构、老股东情况、员工期权池，这些信息在漏斗表里不一定放得下，但它们都围绕同一个项目实体展开，所以在数据结构上，项目应当作为一个核心对象，后续所有会议、文档、任务都挂在它下面。
我实操下来，一个理想的项目表至少要包含这些维度：项目名称、行业标签、所处赛道、轮次、估值区间、项目来源、牵头同事、投资人、FA联系人、当前状态、下次跟进时间、关键决策点。下次跟进时间是整个系统里最容易触发提醒的字段，也是让系统“活”起来的关键。
2.2 会议纪要与尽调记录：最值钱但最难检索
一级市场从业者的记忆，大部分分散在会议记录和电话纪要里。和创始人的第一次交流，和财务总监的尽调访谈，和某位产业方聊到的行业变化，这些内容价值极高，但又极难检索。传统的做法是放一个文件夹，按日期命名，存成 Word 或 PDF，时间一长就沉底了。真正到了需要用的时候，你只记得大概某个月前聊过一个做边缘计算的公司，但具体是哪位同事提了关键技术风险，却怎么也想不起来。
这就是为什么我在这次的 workos 里，把会议纪要放在一个非常核心的位置。每个会议纪要不只是一份归档文档，它可以被拆成三个层次：原文记录、结构化摘要、待办事项。原文记录可以是录音转写的原始文本，结构化摘要是由模型生成的“谁说了什么、讨论了什么、什么结论”，待办事项则是从会议内容中抽取出的可执行动作，比如“与创始人约下一次管理层访谈”“补充三年财务预测模型”“向投委会汇报最新竞品情况”。
更重要的是，这些纪要必须能被检索。普通的全文搜索只能命中关键词，比如输入“那个做边缘计算的公司”，传统检索很难有结果，但如果有向量检索能力，相似语义的内容也能被找出来。这意味着我再也不用靠记忆去考古，系统可以直接从历史的会议文本中把相关片段捞出来。
2.3 被投跟踪与行业研究：碎片知识的集中营
一级市场的项目成交只是开始，投后跟踪其实是更长期、更琐碎的工作。每个月都有被投企业的财务快报要收，每个季度有董事会材料要跟进，有些被投正在准备新一轮融资，需要帮忙对接 FA 或意向机构。以前我习惯把这些事情记在备忘录里，后来又觉得应该放进日历，但拿铁制的日历本质上无法承载“这个项目和上个月数据对比”这种关联信息。我对被投跟踪模块的需求很直接：每个被投企业一张独立卡片，下面挂着最近财务数据、关键里程碑、融资进度、联系人信息、下次重要日期。
行业研究这部分则更像一个个人知识库。我平时会读很多研报、路演材料、行业论坛的速记，这些内容如果只是存进文件夹，基本就是死的。更好的方式是把每份文档做成一个知识点，打上行业标签，让系统自动生成摘要，并且与相关项目产生关联。比如我在看某只基金的被投企业时，系统可以直接显示该企业所在的行业赛道里，我保存过的研究笔记和市场趋势判断，这样看问题会更连贯。
这些工作流的共同点是：不是一次性的任务，而是持续发生的、需要反复访问和更新的信息流。所以，这套 workos 的核心不是做一个好看的 Dashboard，而是把散落在各处的工作记录变成可关联、可检索、可提醒的持久化数据。
3. 核心模块如何设计：字段、状态与数据结构先行
把工作流拆完之后，再回到技术上，最重要的设计不是代码，而是数据模型。vibe coding 最大的便利是你可以快速生成一堆页面和接口，但数据结构的质量会决定你这个系统未来三个月用起来是顺畅还是别扭。我在这里强烈建议任何准备自建的人，先花时间把核心业务对象和它们之间的关系理清楚，不要一上来就开始写页面。
3.1 项目主表设计：用状态机代替一堆复选框
一级市场项目的主要数据载体是项目表，每个项目需要有唯一 ID、名称、行业标签、阶段标签、当前状态、项目估值、本轮融资目标、创始人信息、其他关键人对信息等字段。这里特别要提醒一点，项目状态一定要用单个字符串字段，不要用“是否已过立项会” “是否已完成尽调”之类的多个布尔值。因为一个被投项目可能同时处于“已立项、暂停中、等待同业复核”的复合状态，用多个布尔值会造成无穷无尽的组合问题。
另外，项目表上一定要留下“历史状态轨迹”。这个轨迹可以是一个简单的 JSON 字段，记录每次状态变更的时间和前一个状态，也可以在单独建一张状态流转表。为什么它重要？因为一级市场项目的推进不是线性的，一个项目搁置原因、重新启动原因、在哪个环节卡住，本身就有信息价值。有了状态轨迹，你回顾一个项目的生命周期时就能看出团队执行的节奏，这在写复盘报告时尤其有用。
格式上，我用的是 PostgreSQL 里的 JSONB 字段来存项目标签和状态轨迹。如果你不熟悉数据库，完全可以用 SQLite，也一样。关键点是你要保证后续可以按标签筛选、按行业分组、按项目状态统计。
3.2 会议纪要、文档、任务如何关联
大多数自建工具失败，是因为把每个功能模块做成了一堆孤岛。项目表、会议表、文档表、任务表之间如果没有外键关联，那你实际上只是在用一堆 Excel 拼一个界面。我的做法是建立一个统一的“实体-关系”模式：项目表是主对象，会议纪要表和文档表都带有 project_id 外键，任务表同时带有 project_id 和 meeting_id 两个外键，这样一条任务既能归到某个项目，也能追溯到是哪次会议提出的。
除了官方的关系字段，我还留了一个通用的“标签表”。比如某份行业研究报告可能同时被三个标签引用，这份报告不直接属于某个项目，但通过标签可以检索到相关赛道。这种设计极大地提高了信息利用率，让我在做新项目判断时，可以快速把历史研究资料拉起来。
3.3 可视化与提醒字段：让系统主动找你
数据只是在后台存着并不够。如果每次都需要打开系统手动查一遍哪里有新东西，那这套系统的价值就打折扣了。我的目标是把被动翻找变成主动推送。所以，数据模型里必须有明确的提醒字段：项目的 next_follow_up_at、被投公司的 board_meeting_date、任务的 due_date。这些时间字段统一汇入系统的定时任务引擎，每天固定时间扫描一次，然后通过 webhook 推到飞书机器人或邮件里。
可视化的部分，我并没有做特别复杂的 BI 看板。真正有用的其实只有两三个视图：按项目状态分组的漏斗视图、按行业标签聚合的项目组合视图、按未来两周到期事项刷新的“今日/本周”视图。把自己的仪表盘做成一天只需要打开看三次的样子，而不是一天要维护五个图表的大屏，这才是个人 workos 应有的样子。
4. 从零开始搭：vibe coding 实操记录
整体方案确定之后，就可以开始真正动手了。这一节把从零到能用的过程梳理成五个阶段，每个阶段都附上我实测下来的配置和思路。顺便强调一句，vibe coding 不是说完全让 AI 替你写，而是你要把需求拆得非常清晰，然后让 AI 帮你把重复的技术部分快速补完，你自己专注在业务逻辑和体验上。
4.1 第一步：圈定 MVP 范围，砍掉所有花哨功能
我见过很多做个人系统的朋友，一开始都想做一个完美产品，比如要支持多人协作、要支持移动端离线、要设计高颜值 UI，结果做了两周还没有一个能用的页面出来。MVP 的黄金法则是只保留每天必须用的三个核心动作：记录项目、写会议纪要、查看今日待办。如果你连“记录项目”这个动作都还没做顺，就先别想着做 Dashboard 大屏。
在这个阶段我给自己的约束是：第一，不做复杂的用户权限管理，系统就只有我自己用；第二，不做移动端原生 App，先做响应式网页，手机浏览器也能凑合用；第三，不做复杂的数据报表，只保留最核心的漏斗计数。这样约束完之后，整个系统可以在一到两个周末就成型。
4.2 第二步：技术选型与私域部署取舍
技术选型上，我的思路永远是先考虑数据安全，再考虑开发效率。一级市场的数据极度敏感，尽调材料、投资条款、财务数据如果泄露出去，会带来严重后果。所以我优先考虑的是本地或私有化环境部署，而不是随便把纪要直接丢给某个公有云的大模型处理。
我比较推荐的组合是：PostgreSQL 或 SQLite 做基础存储，选择一个开源的低代码前端框架来搭界面，事件定时器用简单脚本跑，纪要转写和摘要用私有化部署的模型或本地模型进行。如果你对技术比较熟悉，也可以用 React + FastAPI 的组合，自由度更高，但开发成本会略高。我自己最后用的是低代码前端 + PostgreSQL + 定时脚本的架构，在满足功能的前提下减少了很多不必要的工程复杂度。
需要特别注意的就是模型调用。如果你手头有一块图形卡或者条件允许使用本地开源模型，那纪要转写和摘要可以完全在本地完成。但如果你依赖云端大模型接口，也要严格选择对企业数据安全有承诺的服务，并且在使用时尽量脱敏。我是把会议录音的转写放在本地做的，只有脱敏后的摘要文本才会上传给云端接口，最大程度降低了数据暴露风险。
4.3 第三步：搭建数据库与核心页面
数据库是整个系统最先落地的部分。我建了四张核心表：projects、meetings、documents、tasks，外加一个 tags 关联表。可以用一段简单的建表 SQL 把骨架搭起来：
CREATE TABLE projects ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, industry_tags TEXT[] DEFAULT '{}', stage VARCHAR(50), status VARCHAR(50), round VARCHAR(50), valuation_range VARCHAR(100), next_follow_up_at TIMESTAMP, status_history JSONB DEFAULT '[]', created_at TIMESTAMP DEFAULT now() ); CREATE TABLE meetings ( id SERIAL PRIMARY KEY, project_id INTEGER REFERENCES projects(id) ON DELETE CASCADE, title VARCHAR(255), happened_at TIMESTAMP, raw_text TEXT, structured_summary JSONB, source_file VARCHAR(500) ); CREATE TABLE tasks ( id SERIAL PRIMARY KEY, project_id INTEGER REFERENCES projects(id) ON DELETE CASCADE, meeting_id INTEGER REFERENCES meetings(id) ON DELETE SET NULL, content TEXT, due_date TIMESTAMP, done BOOLEAN DEFAULT false );这里项目表里留了 status_history，用 JSONB 存状态流转记录；meetings 表有原文和结构化摘要两个字段；tasks 表同时挂项目和会议，方便追溯。字段不用一次设计到完美，后续随时可以加，但核心的关联关系最好在第一天就理顺。
前端方面，如果你用低代码平台类似 Appsmith 或 Budibase，可以直接在可视化界面上绑定表字段，做列表页、详情页和表单页，都不需要写太多手写代码。核心就是要有三个页面：项目列表页（带状态筛选和漏斗计数）、项目详情页（展示项目基本信息以及挂靠的会议、文档、任务）、快速记录页（新建项目或会议纪要）。我自己实测下来，最省时的做法就是先把这三个页面跑通，再把好看但非必要的外壳放在后面。
4.4 第四步：纪要转写与 AI 摘要接入
会议纪要是这套系统里最需要 AI 赋能的部分。传统的做法是人写纪要，非常耗时。现在有了 whisper 这类本地转写工具，加上大语言模型辅助抽取结构化信息，效率提升非常明显。
现场的流程是这样的：先用录音笔或手机录下访谈音频，然后导入本地转写脚本生成逐字稿，再把逐字稿提交给本地模型生成结构化摘要。摘要我设计成固定格式：核心主题、关键人物观点、决策与结论、风险点、待办事项、相关资料链接。模型在发挥自由度之前必须遵循这个模板，否则后面的检索和质量控制都会失控。
一段我常用的摘要提示词供参考：
你是投资机构的投研助理。请把下面的会议转写文本整理成结构化纪要： 1. 会议主题 2. 参会人及其主要观点 3. 达成的共识/结论 4. 提到的风险与疑问 5. 下一步待办事项（标注负责人） 要求：保留原话中的关键数字和名称，不要额外补充你没有看到的信息，不确定的内容标为[待确认]。摘要生成之后，raw_text 始终保留原稿，structured_summary 里存结构化结果，系统界面上优先显示摘要，需要核对细节时再回到原文。这个“原文 + 摘要”双轨设计非常重要，它能同时满足快速浏览和事实追溯两个需求。
4.5 第五步：日历同步与自动提醒
自动提醒是整个系统里最体现“workos”感的部分。如果把系统比作一个数字助手，那么它主动告诉我该干什么，比我主动去翻日历更符合工作习惯。
我实现提醒的方式很简单：一个定时脚本，每天早晨九点扫描 projects 表里的 next_follow_up_at、tasks 表里的 due_date、被投公司的 board_meeting_date，把未来三天内到期的项目整理成一条消息，推送到企业 IM 的机器人。触发逻辑完全可以按自己的节奏来，比如每周一发送“本周重点跟进项目清单”，重要项目到期提前两天提醒，被投公司财报日提前一周提醒。这个模块的技术难度不高，但它是整套系统在全天候使用中体验提升最大的一个模块。
5. 用着用着才发现的问题：常见坑与排查清单
任何自建系统，落地后都会遇到一系列真实使用才会暴露的问题。下面这些坑我全都踩过，挑几个有代表性的展开讲。
5.1 数据敏感性与私有化部署的边界
一级市场从业者每天处理的信息很多都是非公开的，比如未上市公司的财务数据、融资计划、尽调瑕疵等。把这些数据放进没有安全保障的在线协同工具里，心里无论如何都过不去。我自己的方案是尽量把基础数据库放在本地或公司内网环境的服务器里，只有脱敏后的摘要会通过受控接口与外部模型交互。如果是纯个人使用，一台旧电脑或云主机上的加密磁盘分区也能胜任数据存储角色，关键是不安全通道不经过。
这个原则必须在项目开始前就确定，而不是开发到一半才想。因为如果一开始就把数据架构设计成云端依赖型，最后要改成本地化部署往往需要重构，代价非常大。建议先梳理数据分类，什么能进云端、什么必须留在本地，然后按这个边界设计系统。
5.2 状态字段设计与项目回退的坑
我最初的项目状态设计用了多列布尔字段，增加到第十几个字段之后彻底混乱。后来我把所有状态改成一个单一的 status 字符串，并增加 status_history 记录每次变更，整个跟踪逻辑瞬间清爽了很多。这个教训值得单独写出来：项目状态一定要用有限状态集合，而不是一堆零散的勾选项。
一个比较稳妥的状态设计可以参考：初步接触、详细交流、立项会待反馈、尽调进行中、投决会评审、内部通过、主动放弃、暂时搁置、被投后跟踪。这些状态之间有合法流转关系，比如“暂时搁置”可以回到“详细交流”，但不能直接跳到“被投后跟踪”。如果你有精力，可以用一个简单的状态机来约束流转；没有精力时，至少也保证状态是可枚举的字符串。
5.3 摘要幻觉与原文存档缺一不可
AI 摘要最危险的错误不是格式不对，而是模型凭常识“脑补”出原会议里根本没有提到的内容。防范方式只有一条：摘要必须要能一键跳回原文，绝对不能在系统里只保留摘要而不留原文。每次生成摘要时，我都建议模型先定位到原文本的引句范围，重要数字和事实必须引用原文片段，无法确认的内容要在摘要里标为占位符。这个机制是防止 AI 制造虚假记忆的最后一道开关。
5.4 提示词与调试技巧
vibe coding 环境下，提示词是你的核心生产力工具。但它的输出不稳定，第一次生成的摘要可能很泛，第二次可能过度细致，第三次可能直接丢失关键风险点。我的方法是把模板提示词写进一个代码文件里，作为常量保存，改动时直接编辑，而不是在界面上今天改这里明天改那里。调优时也要保留不同版本的提示词，便于 A/B 对比哪版效果更好。
针对结构化摘要，我一般会在提示词里加上“输出为 JSON”的约束，然后在代码层面对 JSON 做校验，防止模型返回残缺结构导致页面渲染异常。这个逻辑对小白用户来说可能有点偏技术，但对长期使用帮助很大。
5.5 常见问题速查表
| 问题 | 可能原因 | 排查思路 | 解决方案 |
|---|---|---|---|
| 项目列表页打不开 | 数据库连接失败 | 检查 PostgreSQL 进程是否在运行，端口是否监听 | 在系统启动脚本里加入数据库健康检查 |
| 会议纪要上传后一直转圈 | 音频转写耗时太长 | 检查转写脚本日志，确认是否卡在模型加载 | 把转写任务放到队列或后台异步执行，不要阻塞前端 |
| AI 摘要素材跑偏 | 提示词约束不够 | 查看原始转写文本是否混乱，模型版本是否过旧 | 强化提示词里的“不要补充你没有看到的信息”，必要时换模型版本 |
| 自动提醒没有推送 | webhook 配置出错或时间表达式不对 | 先测一条测试消息，再查定时脚本的 cron 是否匹配时区 | 在提醒脚本里增加日志，捕捉异常并推送排队失败信息 |
| 历史项目状态对不上 | 早期数据是手工录的，状态不一致 | 按状态轨迹字段反查历史流转记录 | 写一个一次性脚本，根据历史字段统一修正状态值 |
| 敏感纪要出现在云端检索结果里 | 脱敏流程未覆盖所有字段 | 检查向量化之前是否先做脱敏替换 | 在同步流程里增加一道脱敏函数，过滤公司名、人名和金额 |
这套速查表其实是我平时维护系统时最常用的东西。因为自建系统最大的问题不是功能缺失，而是故障发生时你没有任何官方文档可查。培养自己的排查习惯，把每一次故障和处理方法都记录下来，三个月后你会收获一份属于自己的运维手册。
我个人在实际操作中的体会是，vibe coding 搭个人 workos 这件事，最重要的产出不是一个工程精美的软件，而是逼着你自己把工作流里真正重要的环节想清楚。当你开始问自己“我为什么需要在下个周五之前完成这个项目的记载”“这个纪要到底要存多少层信息”，你对日常工作的理解已经在发生变化了。这套系统到目前还在迭代，最近我在尝试更进一步，把历史纪要的向量检索做成“输入一句话找到相关段落”的形式，另外也在考虑能否低成本接入更多工程化提示词模板。如果你也经常被一级市场的碎片信息困扰，强烈建议你花一个周末，从最核心的项目表开始，迭代出属于自己的一版 workos。
