这一篇的相关度很高，而且高得很具体：你手上那个"工厂跑起来了，但 agent 产出拿不出可核验证据"的老大难，Jia Wu 用 17 分钟给了一套可以照抄的量法。下面按项目分。
🏢 Holdwell ERP：把"agent 产出可观测、可验证"这块补上
① 两次测量法——改造之前量一次，完全铺开之后再量一次
- 怎么做的：这是全片最能抄的一句。他讲交付周期压缩 82% 的时候，方法就摆在原话里——"你把引入 Devin 之前和引入 Devin 之后测的每一个指标都拿出来对比，就能看得很清楚。"注意这里没有任何花招：不是拿 agent 跑了多少 session 说事，不是算省了多少人天，就是同一个团队、同一套指标、前后各测一次，差值即战果。他还特意加了一个时间限定——要等到"被部署进去并且在客户环境里被完全激活"之后再测，没铺满就测，测的是噪音。
- 你可以怎么做：你的 PRD 工厂现在缺的正是这个"前"。下一次任何一个 PM 拿这套流程跑需求之前，先做一次 30 分钟的基线快照：把这个小组原本就在跑的三五个数字记下来——一个需求从立项到发布平均多少天、一个迭代能收多少张单、评审后返工几次、跨线对齐平均卡几天。写下日期、范围、参与人，存成一个文件，然后才允许 agent 进场。等跑满一个完整迭代（不是跑了两周就急着汇报）再测同样几个数。这份"前"的快照只有在事前才测得到，事后永远补不回来——你要的"agent 产出可核验"，第一块证据就是这张快照。
② 只用对方本来就在测的指标，不另发明一套
- 怎么做的：他讲 82% 那段有个容易被略过的细节——他用的是客户自己信奉的敏捷那套语言："那你显然有 ticket、有 sprint、有要做的东西。"他没有发明一个叫"agent 效能指数"的新东西，而是直接踩在客户已经认账的口径上。这一步是可信度的来源：新指标永远可以被质疑成"你自己定义的"，旧指标不行。
- 你可以怎么做：给试点选指标的时候，先去看研发和业务侧现在的周会上到底盯哪几个数，直接用那几个，哪怕它们不完美、不好看。别端出一套只有你的 PRD 工厂才有的新词。一个反向自检：如果这个数字在你介入之前公司里没人在看，那它就不适合当试点的证据。
③ 他替听众把质疑先说了——你也应该
- 怎么做的：讲完"三个月交付了相当于增加 150% 人头的产能"之后，他立刻自己扮演质疑者："等等，这看着不就是 token maxing 吗？你只是给了我一个叫『工程小时』的指标，你不过是跑了一大堆 session 而已。我们怎么知道这些 session 是真实的、有意义的、有价值的？"然后才抛出周期压缩和 PR 数量两条更硬的证据。这是一个非常成熟的汇报结构：先承认你最软的那个指标软在哪，再用更硬的补上。
- 你可以怎么做：写试点复盘的时候，把"这份数据最容易被怎么打"直接写进材料的第二页，自己打自己一次，再给出补强证据。你现在的复盘更接近"只报好消息"，而领导层不信的恰恰是这种没有自我质疑痕迹的材料。顺带把指标分两类标出来：跑了多少次、生成了多少字这类是"活动量"，交付周期、返工次数、上线缺陷这类才是"结果"——他全片的论证，就是从活动量一路爬到结果。
④ 试点该挑什么活：挑那些本来就在烂着的
- 怎么做的：他们进客户之后专挑几类下手——待建的 backlog、需要做的修复整改、"永远发不出去的积压代码、没人写的测试、需要自动分诊的告警"。这几类活有个共同点：它们本来就在那儿烂着，谁都知道它烂，所以做掉了之后不需要解释价值。
- 你可以怎么做：选试点范围时，优先挑"大家都承认没人管、且一直没做"的那一块——比如某个历史模块的需求文档全是口口相传、某条业务线的验收标准从来没成文、某类客诉一直没人做归因。这类事一旦被做掉，证据是自明的；反过来，如果你把试点押在一块本来就有人做得不错的地方，即使 agent 提升了 30%，也会被解释成"那本来就是小王干得好"。
⑤ 让一个 PM 快 10 倍，还是让 8 个人的 PM 团队快 10 倍
- 怎么做的：他给出的核心分水岭是——"你可以让工程师快 10 倍，这没问题，这依然有价值。但你能不能让一个组织快 10 倍——包括公司里每一个人，不管技术岗还是非技术岗？"他把只做单点的 CLI、IDE 归为做不到这件事的一类。对应的数据是那条"内部阶跃 / 外部抛物线"：自己团队用是一次台阶，整个企业铺开才是加速度。
- 你可以怎么做：你的 PRD 工厂现在基本是"让你一个人快很多"。下一步的证据要往组织维度挪一格：找一个不是你、也不特别爱折腾 AI 的同事，让他用同一套流程跑一次需求，测他的前后差。一个人快 10 倍是个人能力，第二个人也快起来才叫资产——而且这恰恰是把它从"彭宇新的私人工具"推成团队标配所必需的那份证据。
🧪 一人公司（onehuman_company）：这期直接是一颗"验证体"子弹
① "token maxing"是个绝好的靶子概念
- 怎么做的：他给行业里一种普遍做法起了个特别锋利的名字——token maxing，并且交代了它的历史成因："大概一两年前，deployed engineer 干活的目标或者说 KPI，就是把 token 用量最大化……那真是个完美的时代，不用操心预算，一切都有人补贴。"补贴退潮，这个指标就穿帮了。给一个含糊的坏习惯起名字，是让观点被记住最省力的办法。
- 你可以怎么做：这条能直接进你的"AI 员工管理成本账"支柱。选题就叫"我发现自己也在 token maxing"——把你在 drizzle tech / 造 App 链路上真实的用量账翻出来，看哪几次跑批其实只是让你感觉良好、没有产出可交付物。注意过弹药库闸门：光复述他这个词是不成立的（删掉你的判断和实测之后还成立），必须配上你自己的数——比如某一周的实际花费、其中多少落成了能发出去的东西。
② 他的"三级证据"结构可以整套借去做产能账
- 怎么做的：他证明价值的路径是三层：先给活动量（session 数 → 推算工程小时 → 其中有多少是真正有产出的工程小时），再给速度（交付周期压缩约 82%），最后给硬产出（原始 PR 数量翻近一倍）。层层递进，每一层都在回应上一层的软肋。
- 你可以怎么做：你那个"产能账三选一没答"的坑，可以用这个结构填。做一篇"我的 AI 员工到底产出了什么"的复盘：第一层——这个月 agent 跑了多少次；第二层——从想法到发布的平均天数，用 agent 前后各是多少；第三层——实际发出去的成品数量。三层摆在一起，读者自己会算账，你不用下结论。这种"自己拆自己台"的写法，比任何"AI 提效 10 倍"的标题都更像 build in public。
③ "谁解决 ROI 度量，谁就是 5 万亿市值的公司"是一句可以吃很久的观点
- 怎么做的：一个正在卖 agent 的人当众说：ROI 怎么量"非常模糊"，"这是个尚未被解决的问题"。这是全片最反常识的一句——难点不在模型能力，在证明这钱花得值。
- 你可以怎么做：这句适合做你的"观点短评"支柱，配上你自己的立场：作为一个真的在用 AI 干活的 PM，你比大多数评论者更有资格说"我也量不出来，我试过什么、失败在哪"。标题和封面前置，正文只讲你量 ROI 的两次失败尝试——这比转述大厂案例更有可抄物。
🤖 app_incubator：缺的那一环是"该做什么"，不是"做得快不快"
怎么做的：Jia Wu 描述自己一天的构成是"四五个小时的客户电话，再加四五个小时真正动手敲键盘"，而那半天会的唯一目的是搞清楚"对这家企业来说，哪些战略性举措的杠杆最高"——先定方向，再配 agent；顺序反了就是 token maxing。配完之后他们的目标是"把自己从这份工作里自动化掉"：agent 要能响应特定告警、特定事件自己跑起来，而不是人守着手动触发。
你可以怎么做：你的 7-Agent 链路现在从"接到一个想法"开始，也就是默认方向已经定了。把"该做什么"这一环显式做成第一个 agent 的职责：让它在动工前必须输出"这件事的杠杆在哪、不做会怎样、成功长什么样"，答不出来就不许往下传。另外那句"把自己自动化掉"对到你另一个痛点——关键环节的检查点不该靠你记得去点一下，应该由事件触发（提交即触发、产出即触发），否则它永远是个建议而不是关卡。
怎么做的（另一点）：他说"写代码这件事基本上已经是个被解决的问题了"，真正的问题"从来不是把代码写得更快，那通常只占问题的 20%"，剩下 80% 是怎么测、怎么 review、怎么部署、怎么在企业范围内长期维护。
你可以怎么做：把这句原样套到你的造 App 链路上自查一遍——你的 9+1 个 agent 里，有几个在解决那 20%（写出来），有几个在解决那 80%（测出来、发出去、后面还能改）？如果答案严重偏向前者，那么链路再顺，交付体感也不会变好。这条同样适用于 PRD 工厂：把 PRD 写得又快又全，可能也只是那 20%。
📈 StockHelp / 你的价值投资实践：一堂"怎么读厂商自报数字"的课
① 全片的数字全是厂商自报口径——这正是练手材料
- 怎么做的：150% 人头、82% 周期压缩、PR 翻近一倍、每周 10 倍工程人力，全部由卖方披露，无第三方审计，案例还做了匿名化。而他自己给出的可信度依据只有一条：用客户原本就在用的指标做前后对比。至于"完全激活"这个前置条件有多苛刻、多少客户到不了这一步，全片没说——这恰恰是评估这类叙事时最该追问的地方。
- 你可以怎么做：这套追问可以固定成你看 AI 相关持仓时的一张小清单——这家公司拿"活动量"说话还是拿"结果"说话？（token 消耗、调用次数、活跃席位是活动量；客户的交付周期、人力节省、续费率才是结果。）**它披露的是最好的那几个客户，还是分布？成立的前置条件是什么？**同一张清单也能用来读管理层电话会：凡是只报活动量的增长故事，都该按一档折扣看。
② 单点工具 vs 组织级结果，是一条护城河判断
- 怎么做的：他把竞品归类为"只是一个 CLI、或者只是一个 IDE"的单点工具，并断言它们做不到"让一个组织快 10 倍"。同时给了 FDE 模式的终局逻辑——"谁在组织内部把 Devin 部署起来，谁就能拿出全场无可匹敌的结果"，也就是把买方个人的职业利益和产品绑在一起。
- 你可以怎么做：这是一条可以直接用在选股上的判断框架：卖工具的公司和卖组织级结果的公司，切换成本天差地别。前者用户换一个 CLI 是一天的事；后者一旦嵌进对方的流程、指标、人事晋升里，就很难拔。你在看任何 AI 应用层公司时，都可以问一句"它的用户离开它，需要重新配置的是一个习惯，还是一整套流程"。顺带记住那句 COBOL / JCL 的洞察——最难看、最没人愿意学的遗留技术栈，恰恰是最不容易被通用工具吃掉的生意，这是找"卓越生意"时一个反直觉的方向。
🔍 更深三角度
该反着用：他有的资源你一样都没有——每天四五小时客户电话、驻场三个月、把一个人派到巴西住 10 个月。**别去学这套"深度陪伴"，那是烧人力换信任的打法，你一个人扛正职加多个副业，学它必翻车。**你要抄的是这套里最便宜的那一件：两次测量。同样地，他能等三个月才出结论，你的试点等不起——正确的反用是把"完全激活"的门槛主动调小（选一个两周内就能百分百铺满的小范围），而不是把观察期硬拉到三个月。他是把范围做大来撑起数字，你要把范围做小来抢到证据。
和你现在做法冲突：两处张力值得你自己掂量。第一，他说写代码只占问题的 20%，真正的难题在测、评审、部署、维护——如果这个结构成立，那么你 PRD 工厂里投入最多的"把文档写得更快更全"，可能也只是产品交付链条上的那 20%，而你的真痛点（评审意见回炉、跨线对齐、agent 产出没人核验）恰好落在那 80% 里，目前得到的工程投入却少得多。第二，他反复强调"让一个组织快 10 倍才算数、单点工具不算"，而你现在的处境是连一个小范围的可核验证据都还没攒出来——按他的次序，先追组织级铺开是本末倒置；但按你的现实，公司可能根本不给你先小后大的时间。这两件事怎么排，不替你下结论。
对你的镜子：他当众承认"ROI 怎么量是个尚未被解决的问题，谁把它解决了谁就是 5 万亿市值的公司"。**换句话说，你那个"agent 产出拿不出可核验证据"的痛点，不是你能力不行——那是全行业都还没解开的题。**你一直把它当成自己的执行短板在自责，其实它更像一块无人认领的高地：在 Holdwell 内部把它解掉，你产出的不是一份汇报材料，而是一个别人复制不了的稀缺能力。另一面镜子在招人那段——Cognition 明确从产品经理背景招 FDE，理由是"如果软件工程的成本正在趋近于零，你就真的得知道怎么设计一个说得通的产品"。你担心的"PM 会不会被 AI 取代"，在他的模型里是反过来的：代码越便宜，判断力越贵。这正好是你手上那张牌。
🧭 所以呢
可迁移思维模型
- 【耐用】两次测量法：任何改造，动手前先量一次、完全铺开后再量一次，差值才是你的功劳；用对方本来就在用的指标，不另发明。这条跟 AI 无关，十年后照样成立，且适用于你所有项目——包括家居号改版、包括第二大脑的摄入流程。
- 【耐用】活动量指标 ≠ 结果指标：跑了多少次、烧了多少 token、写了多少字是活动量；周期缩短、返工减少、真发出去几件才是结果。凡是只肯拿活动量说话的叙事（无论是厂商、同事，还是你自己的周报），都该打折看。
- 【耐用】先承认自己最软的那个数据，再给更硬的补上——这是让人信你的最短路径，比多给三张图有用。
- 【会过期】"写代码已经是被解决的问题、只占 20%"：这是 2026 年这个模型代际的判断。两年后那 80%（测试、评审、部署）也可能被吃掉，这条要定期复核，别当成永恒结构。
- 【会过期】"单点 CLI / IDE 做不到组织级 10 倍"：这更像竞争站位的话术，会随产品形态迅速变化，当结论用有风险。
判断更新：你以前多半默认"试点做完了自然能看出效果"。这一篇给的是反面——效果不是看出来的，是量出来的，而且必须在事前就埋好那一次测量。基线是唯一一种过期不候的证据：今天不测，一个月后花再多力气也补不回来。
这周一个赌注：挑一个即将开跑的小试点，在它启动之前做一张"基线快照"——三个数（平均交付周期、每迭代完成量、评审返工次数）、一个日期、一个范围、一句"如果这三个数没变，这次试点就算没用"。半小时的事，但它决定了一个月后你手上有没有证据。别扩大范围、别加第四个数、别等条件成熟。