企业官网建设流程全解析

先说一件我每天打开电脑后必做的事：不是看行情，而是调出一个本地网页，上面列着今天值得跟进的几条公开融资线索、三个项目的DD文件进度，以及一条“昨天的会议纪要第一稿已生成”的提醒。这个页面，是我用 vibe coding 的方式，给自己这个金融一级市场从业者做的 workOS。半年前我还只会写 Excel 公式，打死我也想不到，自己能动手做出一个工作操作系统。

如果你也是一级市场从业者，PE/VC、投行IBD、FA都算；或者你只是被表格、文档和聊天记录反复折磨的职场人，这篇文章值得看完。我会把整套东西从需求拆解、架构设计到具体模块的提示词和代码片段，再到实测效果和踩坑记录，尽量完整地讲一遍。它不是那种要部署到云端、要给整个团队用的重型系统，它只有一个用户，就是我自己。

1. 先把需求立起来：一级市场工作的“隐性成本”

1.1 工作清单背后的真实耗时点

一级市场的工作链条看起来清晰：项目开发、立项、尽职调查、投资决策、投后管理。但落到每天的动作上，其实是一堆极其琐碎的事。

我给自己做过一次为期两周的时间记录，每天高频动作基本是这几类：早上一轮公开融资信息的翻阅，把零散快讯和公告里的公司、轮次、金额记到表格里；白天不停接收别人发来的BP、审计报告、业务合同，然后另存为、重命名、塞进对应项目文件夹；下午要把各类PDF里的关键数字搬进Excel，把聊天和会议里的要点整理成纪要；晚上下班前要把当天新增的材料归档，顺手把一周的工作流水写成周报。

真正让我疲惫的不是某一次判断，而是“搬运”。同一个信息从PDF到Excel、从聊天记录到会议纪要、从网盘文件夹到项目目录，每个环节都要人肉对齐。一次搬运也就一两分钟，但乘以几十次，每天两三个小时就这样填进去了。

1.2 通用工具为什么差一口气

市面上不是没有效率工具。数据终端很强大，但它的边界很清楚：只能看，不能自动进入我的项目逻辑；项目管理软件把任务、负责人、截止日期定义得清清楚楚，但一级市场的信息偏偏先散落在文档和聊天里，后来才变成任务；企业网盘解决了存储问题，却没有解决检索和字段抽取问题。

还有个绕不开的点：一级市场的项目信息高度敏感。很多材料我连公司内部网盘都不是很想传，更不要说丢到某个云端协同平台上。所以通用工具对我来说有两个系统性缺陷，一是字段僵化，二是数据边界不可控。我需要的东西，本质上是一个能把我自己的文件、我自己的信息流、我自己判断习惯整合到一起的本地工作台。

1.3 vibe coding：不是编码氛围，是“人机结对”

先说清楚我理解的 vibe coding，不是“随缘写代码”，也不是指望AI闭着眼睛生成一个惊天巨作。它更像人机结对：我把需求用自然语言讲清楚，AI负责把代码写出来，我负责跑、验证、继续提修改意见。写的时候可以很随性，可以不懂底层细节，但需求定义和结果校验必须牢牢握在自己手里。

这个模式特别适合做个人 workOS。原因很简单：需求只有自己最清楚，不想等IT排期，不会被软件厂商的标准流程绑架。每一周只需要花几个晚上，就能把最烦的一个环节变成脚本，做着做着，工具就长成了自己想要的样子。如果你之前觉得“编程”是个遥不可及的事情，vibe coding 确实把门槛从“你要会写代码”降到了“你要会描述问题”。

2. 方案取舍：本地优先、模块化、判断点留给人

2.1 整体架构一句话

我给这套 workOS 定的架构很朴素：一个本地数据库作为数据层，一组处理脚本作为逻辑层，一个本地网页作为展示和交互层。所有数据都睡在我的电脑里，不依赖任何云端服务。

2.2 技术选型对比

这套选型最大的特点是：哪里最省事就选哪里。我不需要所谓的“可扩展架构”，因为不会有一百个人同时访问我的本地仪表盘。我只需要“坏了能快速修、改起来不心疼、迁移就是拷走一个文件夹”。

2.3 数据、安全与边界

做金融的人对数据边界天然敏感，我给自己定了几条铁规矩：

• 只处理我本地的文件和公开渠道能合法获得的材料；
• 凡是涉及非公开项目信息的文本，默认不进任何第三方在线AI服务；
• 需要做字段抽取时，优先用本地部署的模型；偶尔用线上模型时，必须先做脱敏处理，把公司名、人名、金额替换成代号；
• 每周做一次整库备份，备份丢到单独移动硬盘里。

有人会觉得这样太麻烦，但我的经验是，麻烦一点反而安全。一旦养成随手把材料丢给在线工具的习惯，总有一天会在不合时宜的场景下翻车。数据边界这事，宁可用前多花两分钟，不要事后追悔。

3. 核心模块拆解：从sourcing雷达到会议纪要

3.1 模块A：项目sourcing雷达

一级市场的项目线索经常藏在公开披露的融资消息、行业日报、官网公告里。以前我的做法是看到一条存一条，隔几天整理一次，经常漏东西。

现在的流程是：把日常订阅的公开信息统一扔进一个“待解析”文件夹，脚本每隔一段时间扫描一次新文件，然后用AI按固定模板提取字段，写进线索表。表里的字段包括：公司名称、业务标签、日期、轮次、金额、相关方、信息来源、一句话判断。

提示词我用的很朴素：

你是一名早期投资分析助理。下面是一条从公开渠道获得的融资快讯原文。 请提取：公司名称、业务标签（3个以内）、新闻日期、轮次、金额、相关投资方。 输出为一个表格行，不要补充原文没有的信息。 原文： {raw_text}

这个模块帮我解决的不只是“收集”，更是“归档”。信息一旦结构化，后续按行业、轮次筛选就非常顺手。在这里要特别强调一点：AI 解析出错时宁可留空，绝不能编造。一级市场的数据容错率很低，一个金额错了，轻则闹笑话，重则影响判断。

3.2 模块B：BP材料库与检索

做一级市场几年下来，BP、年报、审计报告、协议扫描件攒了几千份。以前的痛点是网盘搜索不灵，找一个几个月前的材料经常要层层点开文件夹，甚至凭记忆猜命名。

我做了两件事。第一件，一键清洗文件名，把非法字符、多余前缀去掉；第二件，给每份材料生成一条元数据记录，包括路径、修改时间、大小，再让AI根据文件名和正文首页生成三到五个标签，存进本地数据库。

材料入库后，套用数据库自带的全文检索能力，做一个本地搜索框。现在找一份材料就是几秒的事。

这里放一段我留着备用的文件名清洗脚本，逻辑很简单，但对“网盘狗”来说很救命：

from pathlib import Path def sanitize(name: str) -> str: for ch in '<>:"/\\|?*': name = name.replace(ch, "_") return name.strip() for p in Path(r"D:\bp_lib").rglob("*"): if p.is_file() and p.suffix.lower() in (".pdf", ".pptx", ".docx"): new_name = sanitize(p.stem) + p.suffix if new_name != p.name: p.rename(p.with_name(new_name))

这个模块做出来后，我的体会是：搜索能力本身就是效率。材料再多，只要能被一秒调出来，就等于全部在手边。

3.3 模块C：DD半自动流水线

尽调阶段是文件最多、版本更新最频繁的时候。协议、审计报告、股权结构图、访谈纪要，每个项目一套，每天可能都会进来新版本。

我按项目建了一套固定的目录结构：01_协议、02_财务、03_业务、04_人员、05_原始资料。脚本做的是“半自动归类”：扫描新文件后，根据文件名里的关键词给出建议路径，我确认后移过去。这一步我坚持不搞全自动，因为文件放错位置比放慢一点更可怕。

更有价值的是字段抽取。比如从一份审计报告里，让AI按模板提取：报告期、审计意见类型、营业收入、净利润、经营性现金流、或有事项、异常科目，并标注每一条信息所在的页码。输出直接进Excel核对表，我只需要做最后的复核。

提示词里的关键是加一条约束：

只提取以下字段，并标注出处页码。如果原文没有，写“未披露”，禁止推测。

这套流水线的意义在于，把“抄写员”的工作交给脚本，把“判断”留给我。AI负责把材料里七零八落的数字找出来，我只负责看哪些数字不对劲。

3.4 模块D：周报和会议纪要第一稿生成器

写周报是很多一级市场从业者每周最痛苦的事，原因不是没活可写，而是真到周五想不起来这一周具体做了啥。

我的解决思路是“流水账 + 模板化”。日常维护一个Markdown文件，每天顺手追加三五行流水记录，一句话交代一件事。到周五，脚本把这周的记录提取出来，让AI按照固定结构生成周报草稿：

根据下面的一周流水账，整理成周报草稿。 要求：分三块：本周推进的项目、遇到的阻塞、下周计划。 不要添加没有提到的内容。 {week_notes}

会议纪要也是一个套路。手机录音转文字之后，原始文本丢给AI，按“议题、结论、待办”三个部分输出初稿。原来做一份纪要四十分钟打底，现在五分钟改改就能发出去。

这背后的逻辑是：AI不负责替你开脑洞，只负责把你已经有的零散材料整理成骨架。人做的事是增删和润色，活少了一大半，质量还不容易变形。

3.5 统一入口：仪表盘串起所有模块

模块做多了以后，我意识到不能让工具变成新的信息孤岛。于是加了一个最小可行的本地仪表盘：打开就是四个卡片，sourcing线索、BP库搜索、DD项目进度、本周流水账，外加一个提醒区域。每天早上一分钟扫完，今天该跟进什么都清楚了。

这个入口的设计原则是“少做选择”。界面上不堆功能按钮，只放每天最高频的动作，搜索框全局可用。仪表盘的价值不在于好看，在于让人一进来就知道今天最重要的事是什么。

4. vibe coding实战：从一句需求到一个能用的工具

4.1 先圈定最小闭环

第一次动手，我没有规划什么宏大蓝图，选了一个最不起眼但每周都痛的需求：BP批量重命名和归档。我给自己三个判断标准：是否每周都要重复，规则是否清楚，做错了能不能重来。重命名这事，只要动手前先备份，错了也能恢复，最适合练手。

那个晚上我让AI写了一百多行脚本，来回改了四轮，花了大概一个半小时。当第一个脚本跑通，看到几十个文件名被秒级理整齐的时候，我的感受不是“我会写代码了”，而是“工具离我原来这么近”。

4.2 把需求翻译成AI听得懂的话

vibe coding 的核心功夫在描述需求。我总结出一个三段式提示词：

你是[角色]。我的输入是[描述输入格式]。 请输出[描述输出格式]。 约束：1.[具体约束]；2.[不做什么]。

角色先行很重要。让AI扮演“投行资料管理员”，和直接让它“帮我处理文件”，输出稳定度完全不一样。约束要具体，尤其是“不要编造”“不要解释”“只输出标签”这类否定式指令，能省掉大量返工。

4.3 遇到报错就把报错本身丢给它

我第一次跑脚本，控制台里刷刷刷一片红。当时第一反应是慌，后来发现最简单的办法就是复制完整报错，丢给AI，加一句话：“这是什么错误？怎么改？”

我的经验是，一次只丢一个问题。别在同一轮对话里同时说“这个功能怎么加、那个报错怎么解、这里能不能改成另一种方案”，AI很可能改着改着把你上一版能用的逻辑也弄坏了。还有一个习惯值得养成：即使看不懂每行代码，也要搞清楚这个脚本的入口在哪、输入放哪、输出到哪。这是你作为使用者的底线。

4.4 三行版本管理

vibe coding 改代码改得快，坏也坏得快。AI给你输出新版，你直接覆盖老文件，回头发现新版本有问题，老版本已经找不回来了。我踩过这个坑之后，老老实实用起了版本管理，但全程只用了三个命令：

git init git add . git commit -m "保存当前可用版本"

每次大改动之前先提交一次，改坏了就回滚。这套操作不需要理解深浅，把它当成“存档-读档”就行。对非开发者来说，这个习惯比任何编程技巧都重要。

4.5 节奏：从周末实验到日常依赖

我的时间线大概是：第一周做出整理脚本，第二周加了搜索页面，第一个月做出 sourcing 雷达和 DD 流水线，第三个月把所有模块接入仪表盘。整个过程没什么惊心动魄的里程碑，就是一周一个模块地迭代。

vibe coding 最舒服的一点是，你不需要一开始规划得大而全。今天解决一个小问题，明天再解决一个小问题，过一个月回头一看，你已经拥有了一套自己的系统。

5. 实测三个月：数据、避坑与常见问题

5.1 效果对比

我自己做了个粗略统计：

合在一起，每天能省出约一个半小时。这些时间我没有拿来刷手机，而是用来做更深入的访谈和项目复盘。工具省下来的时间，只有投到“判断”上才是真的赚。

5.2 我踩过的五个坑

• 坑一：一次性让AI生成整套模块的全量代码。结果字段名频繁“幻觉”，改起来比重写还痛苦。教训：拆小步，每步验证输出。
• 坑二：采集脚本依赖的网页版式变了，脚本连续三天没吐出新线索，我居然没发觉。教训：给每天要跑的任务加一个健康检查，当天产出为0就发提醒。
• 坑三：改脚本没先提交版本。一个可用版本被不可用版本覆盖，找不回。教训：动手前先 commit。
• 坑四：试图把所有环节都自动化，包括自动生成项目判断摘要。AI写出来的摘要看着通顺，但缺了我在沟通过程中捕捉到的关键上下文。教训：判断类工作必须保留人工环节。
• 坑五：有一次贪方便，把整理中的项目材料直接丢给在线AI处理。事后意识到这触碰了数据边界。教训：未公开的项目材料，一律只走本地处理流程。

5.3 常见问题速查

6. 这套workOS还能怎么长

跑顺了基础模块以后，我还在陆续往里加东西。一个计划是投后跟踪提醒，把被投企业定期提交的财务数据整理成更新提醒，不是自动判断，而是自动提醒“该看一眼了”；一个是个人知识库，把过去项目里积累的行业判断、谈判经验沉淀成可检索的笔记；还有一个想法是把周报流水自动转成月度汇报材料的骨架。

这些扩展都有一个共同原则：自动化负责提醒和整理，判断永远留给我。工具做得再好，也只是副驾驶，方向盘得握在自己手里。

最后说一点个人感受。这套 workOS 给我最大的收获不是省了多少时间，而是它逼着我把自己的工作流程彻底整理了一遍。很多重复动作的背后，其实是固定的判断框架。当你把这些框架表格化、系统化，你反而会发现自己对项目的理解更清楚了。

如果你也想尝试，我的建议就一句话：挑一个每周最让你烦躁的重复动作，让AI陪你做一个只给你自己用的工具。可以从给文件重命名开始，可以从整理一周流水开始，甚至可以从把一份会议纪要变成模板开始。希望你也早点拥有一套属于自己的 workOS。