Layer 2详解:AI是我的技术合伙人,我只出产品思路

上周三凌晨1点，我需要一个新功能。

具体点说：把QClaw知乎专家的选题库里那些"已经用过"的选题自动去重，避免下周重复撞题。

市面上没有这个东西。让谁做？没人做。

我打开Trae，跟AI说了大概五分钟需求，两个多小时后，一个能用的小工具跑起来了。凌晨3点我把它接进QClaw的工作流，睡觉。

这不是特例。过去半年，我给自己造了三个工具——HotNews热点监测平台、红书智营、智能知识管理系统。它们每天在我这里默默运转，喂养着Layer 1的数字员工和Layer 3的写作专家。

关键是：我不会写代码。

不是"会一点"、不是"看得懂但写不出"，是真的不会。

但我以前的工作是产品经理。我会拆需求、会画流程、会写PRD、会判断产品逻辑。

这一层就是关于这件事：产品经理终于不用等开发了。📎

产品经理终于不用等开发了

先讲清楚为什么Layer 2和前两层不一样。

Layer 1的AI是数字员工——你派任务，它执行。

Layer 3的AI是专家助理——你用功能，它产出。

Layer 2的AI是技术合伙人——你出产品思路，它出代码。

差别不是修辞。心态完全不同。

派任务是上下级关系，你说、它做。用功能是使用关系，你有目标、它是工具。而合伙人是并肩关系——你出的是想法、逻辑、需求边界；它出的是代码、依赖、报错处理。你俩各干各的擅长的事，凑在一起才是一个完整的开发团队。

我以前的工作模式是这样的：我出PRD，交给开发同学，等两到四周，产品上线，改一版，再等两周。这中间"等"的过程是最痛苦的——想法明明是活的、市场是变的、需求是有窗口的，但等的过程中每天都在退化。等产品终于上线时，往往已经错过最好的时机。

现在没有这个"两周"了。想法产生的那一刻，就是产品开始成型的那一刻。

这是Layer 2带给我最大的爽感——闭环的速度。

一个PRD写完，两小时后就能看到能跑的东西；不满意，改一句话，二十分钟后是新的版本。以前一个产品迭代的周期是月，现在是小时。这不是"效率提升"，这是"节奏根本变了"。

为什么Layer 1、3搞定后还必须自己造工具

Layer 3结尾我说过——工具买不起、买到的功能不够，就算够，大概率还要上云。

具体到我这几个真实场景，你就能感受到这个坑有多深：

我需要一个热点监控——市面上有，但要么是通用推荐流（噪音大、不是我要的领域）、要么是给企业用的收费产品（月费四位数、我用不起），要么是免费但要把我的领域偏好和筛选规则喂给它（不干）

我需要监控自己和对标账号的数据——市面上有小红书数据SaaS，但都在云上，我的账号数据、对标名单、判断标准，全在他们手里

我需要一个能自动归档我文档的系统——市面上有Notion AI、飞书妙记、印象笔记升级版，都不错，但我的文档是客户机密、可研报告、未发布小说，云端AI你放心吗？

答案都指向同一个结论：只能自己造。

而自己造，在过去意味着招开发、意味着几万到几十万预算、意味着几个月的等待。

对一人公司来说，这三条哪一条都不成立。所以Layer 2的意义就是用AI把"造工具"这件事从"外包给别人"变成"自己就能做"。

我造的三个工具

先给一张全图，方便你看清楚每个工具在整个体系里的位置：

1、HotNews热点监测 ──→ 我自己 + Layer 3的QClaw知乎专家 + Layer 1的小财

2、红书智营 ──→ Layer 1的COO盖茨（→ 制定运营策略给我）

3、智能知识管理系统 ──→ 全公司（Layer 4雏形）

注意关键：Layer 2造的工具不是给我自己"玩"的，是给Layer 1的员工和Layer 3的专家"用"的。四层架构第一次真正闭环，就是从Layer 2开始。

工具一：HotNews热点监测平台

为什么造：

Layer 1的小财每天要出财经早报，Layer 3的QClaw知乎专家每周要挑2个科技类选题——这两个岗位都需要"新鲜、精选、按领域分类"的热点数据。

我一开始是手动刷。每天早上半小时刷微博热搜、百度热搜、财新、36氪……刷两个月我就受不了了。"每天花半小时给自己当人肉爬虫"这件事，就是Layer 2应该介入的信号。

架构：云端采集 + 本地分析

这是我最想讲的一个设计点。

云端：一台便宜的服务器，每5分钟扫一次微博热搜、百度热搜等公开热榜，写进数据库

本地：每天定时把数据库拉下来，按"国内外/科技/金融"三个领域分类，用我的选题偏好和过滤规则筛掉噪音，产出一份精选清单

为什么这么切？

公开热榜是公开数据，云端跑天经地义——服务器24小时不间断、稳定、省电、每月几十块钱。

但"我关心什么、我用什么标准筛选、我怎么判断这个热点值不值得写"——这些是我的判断资产，必须留在本地。

这跟Layer 3那篇讲的完全一样：不是所有东西都要一刀切"全本地"或"全上云"，边界的划法本身就是设计。

一句话总结：数据源可以云，判断规则必须本地。这条我打算写到项目Wiki的第一页。

服务谁：

我自己

：早上一睁眼刷一眼当天精选热点清单，5分钟掌握三个领域动态

QClaw的知乎专家

：科技热点自动进选题池，每周挑2个开写

小财

：财经热点自动接入财经早报的信息源

产品经理视角的收获：

这个工具让我最有成就感的不是它跑起来了，是它同时喂养了Layer 1和Layer 3。以前作为产品经理，我们讲"一个产品服务多个用户角色"是常识；但一个人公司里，"角色"是我自己的AI员工和专家——这是我第一次真切感受到"我在给我的公司做产品"，而不是"给自己搭工具"。

工具二：红书智营

为什么造：

Layer 3里说过，我的小红书是行业报告号，不是种草号。行业报告号要什么？必须盯着行业里其他人在写什么、什么话题在涨、什么形式在火。

自己每天翻账号看数据？开玩笑，做不了几天。用小红书官方创作者中心？只能看自己的账号，看不了别人。用第三方SaaS？上云 + 每月几百 + 我的账号数据和对标名单全在他们手里。

再一次，只能自己造。

功能：

监控我自己账号的数据（阅读、互动、涨粉曲线、内容表现分档）

监控几十个圈定对标账号的数据（哪些内容在涨、哪些扑街）

每周一次分析报告：本周热的行业话题、热的内容形式、我的哪些内容跑赢或跑输、下周建议方向

关键设计——它的输出不给我，直接给盖茨：

这是Layer 2和Layer 1联动最紧密的一个案例。

红书智营每周产出的分析报告不是给我看的，是直接进入COO盖茨的工作流。盖茨拿到报告后做两件事：

调整下周的内容排期（哪些话题优先、哪些延后）

给我提运营建议（涨的形式怎么用、扑的原因怎么改）

我只在最后一步做拍板——盖茨给建议，我说"按这个来"或"这个不行"。

整条链是这样的：

1、红书智营（Layer 2工具）→ 盖茨COO（Layer 1员工）→ 运营决策 → 我拍板 → QClaw专家（Layer 3）执行

2、这才是四层架构真正的样子——不是四层各干各的，是四层之间有明确的数据流和决策流。

以前作为产品经理，我最爱说"数据驱动运营"。以前这句话是口号，因为数据在BI手里、运营在市场部手里、决策在老板手里，中间一堆流转和会议。现在这句话是每天8点自动执行的一个脚本。

工具三：智能知识管理系统

为什么造：

造前两个工具的过程中，我发现自己被文档淹了。

HotNews每天产出精选清单、红书智营每周产出分析报告、QClaw的知乎草稿在积累、番茄小说的短故事草稿在积累、公文专家写的可研报告和报价单在积累、我从客户那儿收到的资料在积累、我自己写的行业素材笔记在积累……

传统的文件夹分类完全hold不住。原因是：同一份材料可能同时属于"客户档案""行业素材""可研报告参考"——文件夹是单一归属的，我的知识是多线交叉的。

我找一份三周前用过的行业数据？靠记忆。回忆不起来就找不回来。这时候文档本身在，但对我等于不存在。

功能：

我把文档扔进指定文件夹，系统自动读取

AI打多维度标签：主题、类型、涉及客户、涉及项目、时间、重要度

建立多维索引，任何一份材料都能从多个维度找到

我按需查询："找出所有涉及XX客户的、去年下半年的、和可研有关的材料"

关键点——它服务全公司：

前两个工具都有明确的"服务对象"（HotNews服务QClaw和小财，红书智营服务盖茨）。但这个工具不一样——它服务所有员工、所有专家，甚至服务我自己。

它开始扮演一个新角色：公司记忆。

也就是说，它其实已经超出了Layer 2的定位——它是Layer 4的雏形。这一点我会在文章结尾展开。

三个工具的共同特征：

本地为主、云端只做工具人

（HotNews的云端采集除外，那也是纯搬运数据，不做判断）

不追求通用，只追求"我这个业务能用"

（没有多用户、没有权限管理、没有企业级功能）

每一个都跟Layer 1或Layer 3有明确接口

（不是孤立的玩具）

代码量都不大

（去掉过度设计以后，每个项目都在几MB到几十MB量级）

产品经理造工具的方法论

这不是给零基础小白的AI编程教程——那种教程网上一搜一大把。这是给"会提需求但不会写代码"的人的方法。

我总结出四条最管用的：

一、从需求出发，不是从技术出发

不会写代码的人开始造工具，最容易犯的错是"先问技术"——"用什么框架好？用Python还是Node.js？要不要用React？"

别问。

你要问的是："实现这个功能最简单的做法是什么？"

技术选型交给AI。它比你懂哪种方案在你的场景下最省事。产品经理的价值不在这里——你的价值在把需求拆清楚。

比如我造HotNews时的初始需求就一句话："每天早上给我一份分了三个领域的精选热点清单，数据源是微博和百度热搜。"

我没告诉AI用什么数据库、什么框架、什么部署方式。它给出的第一版方案是SQLite + Python脚本 + 定时任务，简单到爆。这就是最合适的方案。

二、AI是技术翻译，不是产品经理

你说："我想要一个每天把小红书行业报告类账号数据抓下来的东西。"

AI帮你翻译：抓什么账号、抓什么字段、多久抓一次、存哪里、以什么形式输出、有没有反爬风险……

它翻译得很好。但它不能替你做产品决策。

比如AI会问你："要不要加评论抓取？要不要做用户画像分析？"这些是产品决策，你必须自己回答。你答"要"，工具就复杂一分；答"不要"，工具就简单一分。

我踩过的最惨的坑（下一节详说），就是让AI替我做产品决策。它每次都建议"再加一个功能会更好"——技术上是对的，产品上是灾难。

三、写PRD式的Prompt

一句话需求"帮我做个热点监控" → AI只能猜。

结构化需求 → AI能做：

数据源：微博热搜、百度热搜（每天前50）

抓取频率：每5分钟

存储：SQLite本地数据库

分类：国内外、科技、金融三个领域

筛选规则：（我给的关键词白名单+黑名单）

输出形式：每天早上7:00生成Markdown文件到指定文件夹

给谁用：我自己+两个AI员工（提供API接口给它们查询）

成功标准：一周内我实际使用它的天数≥5天

这就是一份PRD。

你写PRD的能力在这一步就是核心竞争力。产品经理天生具备这个能力——你已经赢在起跑线上了，只是过去没意识到。

四、看错误，但不解错误

代码写完必然会报错。这是99.9%的情况。

传统开发是自己去debug——读堆栈、查文档、试各种可能。这个流程对你来说不可能。

新流程是：把报错原文完整复制回去，让AI解释和修复。

你的任务变成两件事：

看懂错误在描述什么问题

（这个产品经理都能做——我们不是不理解逻辑，只是不会写代码）

判断AI给的修复方案合不合理

（能不能解决问题、有没有副作用）

我造这三个工具，大概90%的报错都是这套"复制→AI解释→改→再跑"的循环。整个过程我一行代码没动过。

产品经理的debug能力其实不弱——我们只是不擅长"写代码解决"，但"理解问题、判断方案"从来是我们的日常。

我踩过的两个大坑

讲两个印象最深的坑，都是被真金白银浪费时间之后学到的。

坑一：过度设计

第一次造HotNews的时候，产品经理的老毛病犯了。

我按传统产品/系统架构的思路，跟AI来来回回讨论了一整天，设计出这么一套东西：

前端：Vue 3 + Element Plus，做个漂亮的仪表盘

后端：FastAPI，暴露RESTful接口

数据库：PostgreSQL主库 + Redis缓存

反向代理：Nginx

部署：Docker Compose，一键起服务

日志：结构化日志 + 归档

监控：健康检查 + 告警邮件

Trae配合我把这一整套跑出来了。整个项目文件夹七点几个G。

跑起来那一刻我人是懵的——我只是想每天看一眼精选热点，不是要开放一个API给一万个用户用。

一个用户（我）、一个使用场景（早上刷一眼）、数据只有几KB——为它准备了一套支持一万人访问的架构。

后来我把它彻底砍了。前端删了，直接输出到本地Markdown文件；后端只留数据抓取和入库脚本；Redis删了、Nginx删了、Docker删了、监控删了。

最后整个项目不到20MB，功能一模一样。

教训：

产品经理的老毛病是"想全"、"想扩展"、"想有一天用户上来了怎么办"。以前这些想法没错，因为有开发同学扛着你的野心；现在自己造，"想全"就是自己给自己挖坑——你要维护它、你要debug它、你要每次改一个功能都担心影响另一个。

一人公司的工具需要的是三个词：能用、够用、别烦。

能用：核心功能能跑

够用：解决我这一个人的这一个场景

别烦：不需要我天天维护

可维护性大于扩展性，简洁大于优雅。

坑二：需求边界失控

红书智营是被我造废过一次的。

第一版需求很清楚：监控账号数据。

做完之后，AI给我建议："要不要加个内容分析模块？"——我想想觉得有道理，加。

加完发现小红书官方接口能拿到评论数据："要不要顺便做个评论管理？"——我想想觉得有道理，加。

评论管理做完："要不要做个自动回复？"——加。

自动回复做完："要不要做个发文自动排期？"——加。

三个月后我回头看：一个功能能干的活，被我扩成了一个"小红书全家桶"。

结果就是每个功能都做得半吊子。全家桶自己都不想打开——界面复杂、维护累、每次改一个功能都要担心影响另一个功能、一个bug要花一天定位。

最痛的是——我发现自己现在连"就想看看数据"的欲望都没了。工具变复杂之后，用它的心理成本反而超过了不用它。

后来我推翻重来。新版红书智营只做一件事：给盖茨提供每周数据分析。发文、回复、评论管理这些全砍掉——那些事情我自己+QClaw手动做完全能应付。

教训：

一个工具只做一件事。想加新功能？造新工具，工具之间通过数据流打通，不要塞进一个系统里。

以前产品经理最爱说的"业务闭环"，在一人公司这里其实是个陷阱。

大公司做"闭环"是因为有资源支撑一个大系统。一个人公司做"闭环"，最后是自己被闭进坑里。闭环应该是通过多个小工具的组合实现的，不是通过一个大系统实现的。

小工具组合起来的闭环——出问题就换那一个小工具，其他部分不受影响。大系统的闭环——任何一处出问题，整个系统都晃。

Unix哲学在一个人公司这里比在大厂更适用：do one thing and do it well。

三条核心理念

一、产品思维 > 技术能力

这是Layer 2最反直觉的一点，也是最重要的一点。

很多人以为"造工具"的门槛是代码能力。错。

代码AI能帮你写、能帮你调、能帮你部署。它写代码的能力已经超过大部分中级开发。真正的门槛是产品能力：

能不能把一句模糊的需求拆成清晰的功能列表

能不能判断哪些该做、哪些不该做、哪些应该砍

能不能找到最简版本的实现路径

能不能识别"这个功能是伪需求"

代码AI能替你做，产品判断AI替不了你。

从这个角度说，产品经理是所有职业里最适合被AI放大的——你的核心技能AI帮不了你，你的短板AI能补齐。

二、工具服务业务，不是相反

我的三个工具，每一个都是Layer 1或Layer 3已经出现明确瓶颈才动手造的。

HotNews造出来之前，我手动刷了两个月热榜

红书智营造出来之前，盖茨每周跟我抱怨"数据不足我给不出建议"

智能知识管理造出来之前，我的文档已经乱到自己都找不到东西

没有痛点就不要造工具。这条听起来是废话，但很多人（包括我一开始）会陷入"造工具的爽感"——觉得造出来一个东西很有成就感，管它有没有用。

造完没人用（包括自己不用），就是给未来的自己挖的维护坑。

三、云+本地是设计，不是站队

HotNews的架构已经说明了这一点：云端采集 + 本地分析。

不是"全本地才安全"，也不是"全上云才高效"。边界的划法本身就是设计——什么数据可以云、什么必须本地、在哪一层切开，这些判断远比"要不要用云"这个问题重要。

我给自己定的边界原则是：

公开的、不涉及判断的数据→ 云端（省事）

我的偏好、判断、素材、客户资料→ 本地（守身家）

一人公司的技术架构不需要跟大公司比复杂度，需要跟自己的业务哲学对齐。你的哲学是什么，架构就长成什么样。

结尾

到Layer 2这里，你会发现四层架构第一次真正串起来了。

Layer 1的员工做管理、做决策

Layer 3的专家做执行、做产出

Layer 2的工具把Layer 1和Layer 3喂饱，让它们不用等你手工投喂

我自己

在最上层拍板

看起来很完整了？还差一层。

你可能已经隐隐察觉到一个问题：这么多员工、这么多专家、这么多工具，每天产生这么多的东西——

HotNews的历史热点、红书智营的周报、盖茨的策略建议、QClaw的选题库、番茄小说的短故事草稿、公文专家的可研报告存档、客户档案、行业素材、我自己的判断和偏好……

它们的"记忆"存在哪儿？

如果散落在各个工具里、散落在几十个文件夹里、散落在我的脑子里——你的一人公司会永远是一个"当下能跑"但"没有过去、没有沉淀"的东西。今天造的工具三个月后你自己都忘了它是干嘛的；上个季度的客户资料要用的时候找不着；两年前得出的关键判断，今天已经想不起来当时为什么这么想。

没有记忆的公司，是没有真正积累的。

这就是Layer 4要解决的问题——数据基座层，一人公司的组织记忆。

我造的智能知识管理系统，只是Layer 4的一个雏形。真正的Layer 4不止于文档归档，它是把所有工具、所有员工、所有专家的产出都归拢在一起，变成一个可以被反复调用的"公司大脑"。

下一篇，我们聊Layer 4——iMa、Obsidian、以及"一个人怎么让自己的公司拥有记忆"。

先剧透一句：没有Layer 4，前面三层都是短期的表演；有了Layer 4，一人公司才真正开始积累。