最近“vibe coding”这个词在圈子里越来越常被提起，我也赶了一波潮流——不过不是拿它做网页或者小游戏，而是给自己搭了一套“工作操作系统”。这套系统服务的对象不是互联网产品经理，而是像我这样的一级市场从业者。一句话概括：我把平时散落在聊天记录、邮件、会议纪要、行业数据库里的信息，连同项目推进流程和重复性文档产出，全部收敛到了一套自己的工具里，用AI辅助代码的方式快速迭代出来，跑了三个月，确实称得上“改变了工作方式”。

这篇文章我想从动机、选型、搭建过程到翻车现场，完整记录一遍这套系统的前世今生。如果你也在做股权投资、融资顾问这类工作，每天被信息流和流程性事务淹没，或者你自己也想试试用vibe coding给工作流做一次重构，这篇内容应该能给你一些可以直接落地的经验。

1. 先说说我为什么会想要一套“一级市场工作OS”

1.1 一级市场工作的真实信息流长什么样

一级市场从业者的日常工作，表面上看是“看项目、写报告、开会”，但拆开来看，信息处理量其实非常吓人。项目源信息可能来自FA推送、行业活动上换来的名片、朋友转介绍；行业研究要看研报、扒数据库、跟踪企业动态；项目推进过程里还有尽调资料清单、会议纪要、投决材料；投后管理阶段又要定期跟踪企业运营数据、董事会材料、回购条款触发情况。

这些信息散落在五六个不同的地方：微信聊天记录、企业邮箱、本地方档、团队共享盘、知识库平台、第三方数据终端。每一处的信息都只有一部分，但它们其实都指向同一个项目实体。过去我最头疼的就是“把信息拼回去”这个动作——同一个项目在聊天记录里叫简称，在邮件里是全名，在表格里是编号，每换一个场景就要重新对一次。

1.2 重复劳动真正消耗的不是时间，是注意力

做一个简单的估算。假设一个从业者同时跟进30个项目，每天新增的行业资讯、项目动态、内部讨论加起来上百条。过去我每周一上午基本都在做同一件事：从头到尾翻一遍聊天记录和邮件，把上周的关键信息抄到项目跟踪表里，再手动更新周报。这个动作单次可能只要一两个小时，但持续一整年，累积下来非常惊人。

更隐蔽的损耗是“切换成本”。上一秒还在看某个项目的尽调资料，下一秒又要切到邮箱去找另一家公司的对赌条款，大脑需要一个缓冲才能进入状态。频繁切换上下文带来的注意力碎片化，比多写两页PPT更让人疲惫。我意识到，工作量本身不见得减少多少，但“把这些信息聚合到一个入口、把流程推进自动化、把重复文档变成流水线产出”，这三个层面的优化能实打实改善工作体验。

1.3 我给“workOS”下的定义：一套三层的操作系统

“workOS”不是某一个软件，而是我给自己搭建的一套工作基础设施。参考电脑操作系统的逻辑——操作系统负责管理CPU、内存、磁盘这些硬件资源，并为上层应用提供统一接口——我把自己的“工作资源”也分层处理了。

第一层是信息聚合层：把邮件、消息、纪要、报告统一收进一个“收件箱”，用AI做摘要、打标签、关联项目。第二层是流程控制层：项目的生命周期阶段、待办事项、关键截止日期，全部用一个状态机管理起来，状态变化自动触发下一步动作。第三层是文档产出层：把高频重复的材料（投资备忘录初稿、会议纪要、周报）做成模板加数据填充的半自动流水线。

这三个层的共同点是：它们都不需要“创造力”，只需要“准确性和一致性”。而这两点恰恰是机器比人更擅长的。

2. 为什么这个活儿适合用vibe coding来做

2.1 vibe coding到底是个什么开发方式

“vibe coding”这个词形容的是一种AI辅助编程的状态：开发者用自然语言描述想要的界面或功能，让AI编程工具生成代码，遇到问题再把报错信息或预期效果丢回给AI，反复几个来回把功能调通。不同于传统开发，这里最重要的能力已经不是“从零写代码”，而是把需求拆解成AI能理解的指令、审查AI生成的代码是否符合预期。

我用了之后最直观的感受是：从“脑子里有想法”到“屏幕上跑起来”的周期被压缩到了极短。过去一个简单的内部工具，从画流程图到建模到写前后端，怎么也得一两周；现在用vibe coding的方式，复杂一点的三四天就能出一个可用版本，简单的小工具当天搞定。

2.2 四个方案对比下来，vibe coding是当前最优解

在决定使用vibe coding之前，我认真考虑过其他几条路，各有各的问题。

先看现成的SaaS工具。市面上确实有不少通用型的工作管理软件，知识库、项目管理、自动化流程都有，但通用产品的字段和流程是面向所有行业设计的。一级市场项目的阶段划分、尽调资料清单、投决材料模板这些高度垂直的逻辑，要么只能勉强用自定义字段凑合，要么根本表达不出来，最后用起来还是得手工补录。

再看低代码平台。低代码的优势是拖拽组件、配置流程，但对一个没有任何开发背景的人来说，学到能熟练搭建一套带数据库关系的内部系统，成本并不低。而且低代码平台在复杂字段关系、自定义逻辑上有自己的天花板，遇到不支持的场景反而更痛苦。

外包开发这个选项也被我划掉了。内部工具的需求只有自己最清楚，外包沟通成本极高，需求变更一次就要等一轮排期，迭代速度根本跟不上业务变化。

最后是vibe coding。它不需要我成为专业程序员，只需要我能把业务逻辑说清楚、能看懂代码大致在干什么、能识别AI给出的结果是否合理。这正好匹配“一个懂业务的人自己动手做工具”的场景。而且后续需求变化，我随时可以自己改，不需要求人。

2.3 我的三条边界原则，让vibe coding不翻车

vibe coding确实强，但也不是没有风险。跑了三个月，我总结了三条必须守住的边界。

第一条，数据模型必须自己定，AI只负责写实现。数据库里每个表有哪些字段、项目状态怎么流转、什么字段关联什么项目，这些核心结构我自己先画清楚，再丢给AI去生成建表语句和接口代码。如果让AI从零设计整个数据结构，短期看很省事，但后面每次迭代都可能因为底层结构理解不一致而返工。

第二条，确定性的逻辑可以交给AI，判断性的规则自己写。比如“从这段话里提取项目名和日期”属于确定性逻辑，AI能做；“这个项目值不值得推进”属于判断性规则，绝不能让AI替我做。

第三条，提示词里不出现敏感信息。我把一些项目细节比如客户名称、具体金额、交易对手方信息剥离开再让AI处理文本，涉及内部数据的部分走站内逻辑而非外部接口。这条不仅是为了合规，也是防止自己的核心信息源被外部模型拿去。

3. 三个核心模块的搭建实录

3.1 信息入口：把五个来源收进一个“统一收件箱”

这套系统的第一个模块，是把所有项目相关信息都收进一个统一的收件箱。目前接了四个来源：邮件、即时通讯工具里转发给机器人助理的消息、会议纪要手动粘贴上传、指定目录里的研报PDF。

整个流程是：信息进入统一的数据库→后台定时任务读取新数据→AI模型做摘要和结构化提取→打上项目名、来源、类型、紧急度等标签→存入待处理列表。我在数据库里设计了一张叫“inbox_items”的表，核心字段大致是这样的：

最花功夫的是AI提取环节的提示词。我试过好几个版本，最终确定了一套比较稳妥的提示词结构：

你是项目信息提取助手。只做事实提取，不做判断。 请从给定文本中提取： 1. 可能关联的项目名称或代号 2. 文本中提到的重要日期和金额 3. 核心动作（如推进/暂停/延后/风险提示） 4. 一句话摘要 规则：如果文本中没有提到某个字段，输出"未提及"，不要推测。

这个提示词里“只做事实提取，不做判断”和“未提及”两条规则，解决了后面我要讲的“AI幻觉”问题的一半。每个从收件箱被标记为“需要跟进”的条目，都必须由人处理完后点一下“确认归档”，这套人工确认闭环保证了关键信息不会因为AI出错而失真。

3.2 流程中枢：把所有项目的生命周期变成一条可见的管道

信息收敛之后，第二个模块是把项目的推进过程变成一条清晰可见的管道。我定义了一套统一的阶段划分：项目源、初步接触、立项、尽调、投决、交割、投后。每个阶段之间允许的流转方向是固定的，比如“初步接触”只能流向“立项”或“放弃”，“尽调”只能流向“投决”或“暂停”，这种设计杜绝了项目状态乱跳的情况。

光有状态还不够，我在这套流程中枢上做了几个自动化动作。第一个是阶段字段模板：项目进入尽调阶段时，系统自动在项目档案中生成一个“尽调资料清单”，包含工商底档、财务报告、业务合同、法律诉讼记录等项目，每个条目都是一个可勾选的待办项。第二个是截止日期提醒：项目任务表里每项任务都可以设置截止日，到期前三天、前一天的早上，系统自动在即时通讯工具里推送提醒给负责人。第三个是自动周报生成：每周五下午，系统从项目表中聚合本周新增项目、推进项目、暂停项目和下周待办，生成一份周报初稿，我只需要人工补充判断性结论就可以发出。

举个例子描述一下闭环的样子：某个项目从“初步接触”推进到“立项”，我只需要在系统里做一次状态变更。系统会自动执行三个动作：给项目档案挂上立项阶段需要补充的字段（预计投资金额、轮次、行业分类、团队背景等）；给负责这个项目的同事生成一条待办，告知需要补充立项材料；在周报模板里把该项目标记为“本周新立项”。整个过程不需要我分别去更新表格、发送通知、修改周报，全部由流程中枢一次性完成。

3.3 文档引擎：把“从零写”变成“从初稿改”

一级市场工作中大量的文档产出其实是高度重复的。投资备忘录的结构大致固定，会议纪要有固定的模板格式，周报更是每周都要做。这些文件消耗的时间非常多，但真正有信息量的部分往往只占一小段，剩下的都是格式和已有信息的重新编排。

文档引擎的核心是模板加数据填充。我花了一些时间把几类高频文档拆解成了结构化的模板：每份文档定义好章节、每节对应哪个字段、哪一段可以由AI补写。比如一份投资备忘录初稿，框架大概是这样：

• 项目概况：从项目档案自动取（项目名、行业、轮次、融资额）
• 行业背景：AI基于项目标签检索已入库的行业研究笔记生成初稿
• 团队信息：从项目档案团队字段取
• 财务数据：从项目财务录入表取关键指标，生成表格
• 交易条款：从尽调阶段填写的条款清单取

实际操作时，我在模板里留好了变量占位符，生成文档时系统把项目档案的字段自动填进去，AI只负责写“行业背景”这一类需要上下文组织的段落。一份4页左右的投资备忘录初稿，过去我手动写需要半天，现在从选择项目到生成初稿，大概20分钟能出一版，我再花半小时深挖细节、校正数字，整体节省将近半天的时间。

会议纪要的自动化更简单一些。我把会议录音转写文本丢进系统，AI按照“背景、讨论要点、结论、待办事项、负责人”的结构输出初稿，我只需要确认一遍内容，修正遗漏点，整个过程从一小时压缩到十分钟。

4. 跑了三个月之后：真实收益和翻车现场

4.1 量化下来，每周大概省出五到六小时

这套系统用了三个月，最直观的收益是时间。信息聚合层帮我省掉了每天早上的“翻聊天记录”时间，每天大约省半小时；周报自动化省掉每周至少一小时；文档初稿生成省掉每周大约两到三小时；定时提醒减少了我因为遗忘而额外处理事务的时间。综合算下来，一周大约能省出五到六个小时，这在我这个忙碌强度下已经很可观了。

但比时间更重要的是“不遗漏”。过去人工整理信息，经常出现某个项目在群里聊过一轮，之后没人主动跟进就悄悄沉底的情况。现在所有信息进来都会被AI打上项目标签，出现在对应项目档案的新动态列表里。有一次系统自动周报发现某个项目已经两周没有任何进展记录，提示我主动去问了一下，结果发现对接人那边确实出了状况，及时做了止损处理。

4.2 翻车案例一：AI把“暂缓推进”理解成了“重点推进”

三个月的使用过程里也实打实翻过车，第一个大坑来自AI摘要的“判断越权”。当时有一份会议纪要，里面提到某项目“暂缓推进，等待竞争对手下一轮融资动向再决定”。AI生成的摘要直接把“暂缓推进”理解成了“重点推进，持续关注竞争动向”，还标了高紧急度，差点让团队对项目重新投入资源。

根因是提示词里没有限制“只做事实提取，不做判断”。“暂缓”和“重点”是两个方向完全不同的词，但模型只按语义相关性输出，没有站在业务背景里判断。修复方式就是在提示词里加了硬性规则，并且要求所有高紧急度的标定为“置信度高”才可以通过——如果AI判断紧急度是high，但提取出的原文中没有明确的“风险”“截止日期”之类的字眼，就必须进人工确认列表。

4.3 翻车案例二：字段映射错乱，把“估值区间”写成了“上轮融资额”

第二个坑发生在文档引擎。有一次生成投资备忘录初稿，发现资金条款部分把“估值区间”填成了“上轮融资额”。查了一圈原因：项目档案表里“上轮融资额”字段在更新模板时被移了位置，文档引擎的字段映射表还是旧的，AI填充时按旧映射抽了错误的数据。

这暴露了一个系统性问题：字段变更没有同步到消费端。我后来给所有字段变更加了一道流程——改字段之后，必须触发一次“样例文档生成”用来做回归测试，检查AI填充出来的文档是否合理。其实就是一个非常简单的人工抽检动作，但能避免大部分低级错误。

4.4 翻车案例三：定时任务半夜挂掉，早上起来一片静默

第三个问题是基础设施层面的。有一段时间系统里所有定时任务都在同一台机器上跑，某天数据库连接池被一个异常任务占满，后续任务全部排队失败。因为任务失败没有告警机制，我第二天早上打开系统才发现所有自动化都没跑，当天的项目动态和提醒全部静默。

修复方案做了两件事：一是给所有定时任务加了重试逻辑，二是给失败任务加了告警通知，任务挂了第一时间能收到消息。现在偶尔还会遇到个别任务失败的情况，但基本都能在半小时内发现并补跑，不再出现整个系统集体失聪的情况。

4.5 从翻车里沉淀出来的三条规则

这三个翻车案例都没造成不可挽回的损失，但给我积累了一套“防错设计”的思路。第一，AI输出必须限定在事实提取范围内，判断必须经过置信度校验；第二，字段变更必须做回归测试，文档引擎要定期抽检生成样例；第三，基础设施层面必须保证可见性，失败必须能及时发现。这套教训沉淀下来，比我在网上看一百篇vibe coding教程都更有用。

5. 这套系统的边界在哪里，以及我下一步想做的事

5.1 判断、人情和谈判，这三样我坚决不交给AI

系统虽然帮我处理了大量信息，但有几件事我越来越明确地坚持留给人脑。第一是投资判断——一个项目值不值得看、以什么估值进去、什么条款必须守，这些核心决策不是我写几条规则就能表达清楚的。第二是人情世故——一级市场是一个高度依赖关系的行业，和合作方之间的信任建立、信息交换分寸，这不是数据库能承载的。第三是谈判策略——什么时候该施压、什么时候该让步，这种动态博弈的能力，机器暂时给不了。

我的原则是：系统负责“确保不遗漏、不错乱、不拖延”，但所有直接影响决策质量的部分，必须由人来完成。AI帮我省出来的时间，恰恰应该投入到这些更高价值的判断中去。

5.2 数据安全是一条红线，怎么强调都不过分

做这个系统时，我对数据边界做了很明确的设计。敏感字段（客户名称、交易金额、条款细节）存在本地数据库中，AI处理文本时先做字段级脱敏再调用外部接口，返回结果再重新映射回本地。团队共享的部分走了内部网络，个人使用的分析场景用单独的隔离环境。对外部模型的能力调用，我坚持“最小化暴露原则”：“能不分发的字段绝不分发，能脱敏再做的操作绝不直接传原文”。这套系统目前只服务于我个人的工作流，如果未来要推到团队使用，数据权限、审计日志这些基础设施还要再上一级。

5.3 下一步：从“个人工具”走向“团队基础设施”

这套workOS现在还处于“个人生产力工具”的阶段，但下一步我准备往团队复用方向迭代。第一个想补的模块是投后监测：企业回传的经营数据、财务报表，目前还在靠人工录入，我想把文件解析和异常指标波动提醒也自动化。第二个是会议自动生成议程：开会前根据项目当前阶段和待办事项自动生成会议议题，把“开会没主题、开完没结论”的通病治一治。

如果是在一个更成熟的团队里做，这套东西的想象空间还更大。项目团队成员各自主管的项目可以通过一条条智能消息同步给所有人，管理层想要周报，系统自动生成；决策会上要什么材料，系统自动从项目档案里提取拼装。一级市场的工作本质是信息处理加决策，把前者压缩到底，人才能把更多精力集中在后者上。

最后说一个小建议：如果你也想给自己的行业工作流搭一套类似的东西，不要上来就设计一个庞大完美的系统，先找一个你每周都要花两小时以上的重复动作，把它自动化，跑通之后再考虑扩展。我这套系统就是从“周一自动整理上一周动态”这一个需求起步的，后面逐渐长成了现在的样子。工具的价值不在于功能多，而在于它推进了哪些本来会被拖延的事情。