我的 AI 用法第二弹：WorkBuddy 是生产线，Cursor 是项目组

引子：上篇写了一种用法，这篇写另一种

半个月前我写过一篇《我用 WorkBuddy 的 159 天》，结论是我把 AI 用成了一条个人生产线——写脚本、搭管线、日更八篇公众号，买的是"下一篇更便宜"的复利。

那篇发布后，一直有人问：你天天念叨的 Cursor 呢？怎么不写？

今天补上，而且我故意把它写成第二弹——不是因为都是"AI 使用心得"，而是因为这两篇合起来，才照出一个我越来越确信的判断：AI 不是一种固定用法，而是看你拿它来"组织"什么。

上篇是"一个人 + 一条生产线"；这篇是"一个人 + 一支虚拟项目组"。同一个我，两种完全不同的打开方式。

一、先亮底账：369 次会话，九成砸在一个项目上

这次评估拉的是我本机 Cursor 的可检索会话，截止 2026-10-15，跨度约 3.5 个月（6 月底到 10 月中）。

【插图 01 · 01-arc.png】

数字如下：主会话 369 次、我发出的指令约 2,416 条（平均每个工单 6～7 轮来回）、协作信息量估算 800 万～1,300 万单位（中位约 790 万，注意这是本地反推、不是财务账单）。

但最说明问题的是这一条：93% 的会话落在同一个仓库——youjiayun-Employment，一个社会化用工的 Monorepo，344 场、约 2,244 条指令。

翻译成人话：在 Cursor 这儿，AI 从来不是"偶尔问问怎么写代码"，它是我交付一个复杂 B 端产品的主通道。

二、四个月，我的用法变了四次

报告把我这四个月切成四个阶段，我逐条认领。

阶段一是"入门"（6 月下旬到 7 月）：跑项目、小改页面、按 Markdown 标准协作写文档，还在 Demo 仓做列表页仿写练手。

阶段二是"Agent 交付"（8 月上旬）：V4.0 社会化用工密集交付，开始用 @ 引用 PRD 和目录。也是在这阶段，我撞上了所有 Agent 新手的经典坑——范围误伤、重复开窗、批量改码编译失败。

阶段三是"治理固化"（8 月中下旬）：这是真正的分水岭。我把流程固定成 Plan → Demo → Markdown 定稿 → 新会话冷启动改代码，并且把那些口头约束写进了 .cursor/rules/——范围铁律、遍历默认 scope、改码后自测编译、输出精简。8 月 10 到 13 日那次自评后，三条规则正式落地。

阶段四是"验收深化"（9 月到 10 月）：多端口评审、资金/状态/交付走查、5.0 对齐、Mock 反推表设计、SQL 入门。会话数降了，但单需求变重了。

按月看更清楚：6 月 10 场、7 月 133、8 月 137（峰值）、9 月 68、10 月 21。7–8 月合计约 270 场，对应 V4.0 冲刺；9 月起次数降、单票变重，像"治理与对齐"而不是"铺量改页面"。

三、评级：治理型高级用户，前 2–5%

报告给我的定位是"治理型高级用户"，综合约前 2–5%。但它真正想强调的，是那张分层定位表：

【插图 02 · 02-govern.png】

Tab / 简单问答——早已越过；多轮 Agent 改码——熟练；Plan、@、Rules、子代理——高级；文档驱动 + 规则治理 + 门禁——顶尖少数，约前 1–2% 维度；手写后端 / 测试 / CI——起步阶段。

最让我在意的不是那个百分位，而是它对我的"角色定性"：我是单人 + AI 团队，在交付一个复杂 B 端多端产品；不是传统的"工程师用 AI 提速写码"，而是"产品主导 + AI 实施 + 人做验收"。

这套打法里，我最得意的一招是：把踩过的坑，写成项目里的长期公约。报告列了 5 条 .mdc 规则文件——社会化用工 vs 新业态小程序禁改、遍历类默认社会化用工目录、改码后自测编译、输出只给结论……这些不是临时叮嘱，是写进仓库、每次新会话自动加载的"团队纪律"。

四、诚实短板：我的"黑盒"和"范围"

和上篇一样，这篇最想说的也不是长处，是短板——而且 Cursor 这边的短板，和 WorkBuddy 那边几乎是镜像互补的。

第一，工程读图是黑盒。页面和流程我能调通，但底层表结构、接口字段、并发幂等，我仍依赖 AI 反推；SQL 还在练习初期。换句话说：我会"验收界面"，还不太会"验收数据"。

第二，范围遍历是历史最高频的返工源。一句话"各端统一改一遍"，最容易多改、漏改、改错端。对策我已经写进规则：复杂需求第一句就写死"改哪些端、不改哪些端"。

第三，Token 效率在高峰期偏高。8 月峰值月 137 场，子代理和浏览器验证多，单位需求成本上去了。报告给的口径很对：盯"每需求纠正几轮"，而不是只盯工单次数。

【插图 03 · 03-mirror.png】

五、两弹合起来，我想说的那句话

把两篇摆在一起，结论就出来了。

WorkBuddy 那篇，我放大的是个人生产力——把 AI 用成可重复的生产线，产出内容。Cursor 这篇，我放大的是组织能力——把 AI 用成一支受流程约束的虚拟项目组，交付产品。一个偏"做东西给自己/给读者看"，一个偏"带队伍把业务落地"。

同一个我，两种用法，照出同一件事：你给 AI 流程，它就还你团队；你给 AI 约束，它就不乱改。

报告里有一句我特别认同的定性：我不是把 AI 当搜索引擎，而是当"受流程约束的外包产品 + 实施团队"，且会把协作规则沉淀下来。

至于第三弹写什么——我已经想好了：当 WorkBuddy 和 Cursor 在同一件事上"打架"时，我到底怎么选。比如一个需求既要在公众号讲清楚、又要在工程里落地，两个工具各自的边界在哪。

那篇，等我把停在第 95% 的那批东西收完尾，再写。