记录时间：2026-07-20 16:39:46

这篇笔记来自对当前 Codex 配置、插件清单、技能目录和本轮实际可用能力的一次盘点。

先说明「使用频率」怎么算

Codex 没有向我提供一份可信的 Skill 调用次数统计。因此，下面的「高频、中频、低频或专项」不是历史调用排行榜，而是根据三件事作出的实用分级：触发范围有多广、与我当前的写作及开发流程有多接近、日常任务遇到它的概率有多大。

本次确认到 15 个当前可用的 Plugins。其中 13 个明确写在本机 Codex 配置中并处于启用状态，GitHub 与 Gmail 则作为当前会话可用的连接器插件出现。插件内部带有的 Skills 全部放在对应插件下面，不再进入后面的独立 Skills 清单。

Plugins：高频

1. Superpowers

它是一套贯穿软件开发全过程的方法库，也是覆盖面最广的插件。它规定如何澄清需求、写计划、测试、调试、审查和交付。

插件内含 14 个 Skills：

• using-superpowers：每轮任务开始时先判断应该调用哪些 Skills。
• brainstorming：在写代码前澄清目标、约束、成功标准与方案取舍。
• writing-plans：把已经确认的规格拆成可以逐步执行的实现计划。
• executing-plans：按现成计划分阶段实施，并在检查点复核结果。
• test-driven-development：先写失败测试，再写最少实现，最后整理代码。
• systematic-debugging：从复现、证据和根因入手处理 Bug 与异常结果。
• verification-before-completion：在声称完成以前重新运行验证命令，用输出证明结果。
• requesting-code-review：完成重要改动后发起独立代码审查。
• receiving-code-review：先验证审查意见的技术正确性，再决定如何修改。
• finishing-a-development-branch：在功能完成后整理合并、PR 或分支清理步骤。
• using-git-worktrees：用 Git Worktree 隔离功能开发，减少对当前工作区的干扰。
• dispatching-parallel-agents：把互不依赖的任务交给多个代理并行处理。
• subagent-driven-development：让子代理按任务块实现，并穿插规格与质量审查。
• writing-skills：创建、修改和验证 Skill 本身。

2. GitHub

用于读取仓库、Issue、Pull Request 与评论，也能结合本地 git 和 gh 完成发布、审查与 CI 修复。

插件内含 4 个 Skills：

• github：GitHub 任务的总入口，负责仓库、Issue 和 PR 的查询与分流。
• gh-address-comments：读取未解决的 PR 审查线程，落实选定的修改意见。
• gh-fix-ci：检查 GitHub Actions 失败日志，定位原因并修复 CI。
• yeet：确认改动范围后创建分支、提交、推送并打开 Draft PR。

3. Browser

插件内的 control-in-app-browser 用于控制 Codex 内置浏览器。它可以打开本地页面、点击、输入、截图和检查交互状态，尤其适合前端完成后的本地验收。

4. Computer Use

插件内的 computer-use 通过 macOS 图形界面操作本机应用。终端、API 或专用连接器无法完成任务时，它可以读取窗口、点击控件和输入内容。

5. Frontend Design

插件内的 frontend-design 用于设计或重塑前端界面。它关注视觉方向、字体、布局、层级和产品气质，帮助页面摆脱默认模板感。

Plugins：中频

6. Chrome

插件内的 control-chrome 操作我已经登录的 Chrome，包括现有标签页、Cookie、扩展和登录状态。需要使用真实账户环境时，它比新的无状态浏览器更合适。

7. Sites

这是 OpenAI 的网站构建与托管插件。它只在带有 .openai/hosting.json 的 Sites 项目中强制使用。

• sites-building：构建网站、仪表盘、作品集、门户和内部工具。
• sites-hosting：发布网站并管理 Sites 托管状态。

8. Visualize

插件内的 visualize 用于在对话中制作交互式图表、地图、流程图、模拟器、数据探索器和 3D 模型。需要「看见并调节」一个概念时，它比纯文字解释更有效。

9. Documents

插件内的 documents 用于创建、编辑、批注和红线修改 .docx。它要求把文档渲染成页面图片做视觉检查，适合正式 Word 文档。

10. PDF

插件内的 pdf 读取、生成、拆分、合并和检查 PDF，并通过页面渲染确认文字、分页与版式没有出错。

11. Spreadsheets

用于创建、分析和验证 Excel 或 Google Sheets 兼容工作簿。

• Spreadsheets：处理独立的 .xlsx、.xls、.csv 与 .tsv 文件。
• excel-live-control：通过 Excel 加载项控制正在打开的工作簿与活动会话。

12. Gmail

用于搜索邮箱、阅读邮件线程、提取行动项和起草回复。发送、归档、删除或修改标签等动作仍需要明确意图。

• gmail：邮箱搜索、线程摘要、回复草稿、转发与邮件整理的总入口。
• gmail-inbox-triage：把收件箱分成紧急、需要回复、等待中与仅供了解等队列。

Plugins：低频或专项

13. Presentations

插件内的 Presentations 用于创建、编辑、渲染和导出 PowerPoint 或 Google Slides 演示文稿。只有需要正式幻灯片产物时才会触发。

14. Template Creator

插件内的 template-creator 从现有 Word、PowerPoint 或 Excel 文件制作可复用的个人模板 Skill。它服务于长期重复使用的版式，不负责普通的一次性文档。

15. Skill Creator

插件内的 skill-creator 用于创建或改进 Skills，并通过评测、基准测试与方差分析检查效果。Codex 还带有一个同名的系统 Skill，提供创建 Skill 的基础规范；两者用途重叠，所以统一放在这里说明，不在独立清单重复列出。

独立 Skills：高频

1. publish-diary-note

把当前讨论整理成符合 mewmoire 约定的 Markdown 日记，取得真实时间，生成四字段 Frontmatter，然后构建并发布到 Cloudflare Pages。这篇文章正在使用它。

2. publish-article

把网页、粘贴内容、主题简报、本地笔记或当前对话改写成中文文章，并发布到同一个 Eleventy 日记站。它更适合有明确来源、需要翻译或改编的长文。

3. stop-slop

清理 AI 写作痕迹：删除空话、套路式对照、机械排比、虚假强调和过度解释，让文字更直接、更像真实作者。

4. agent-reach

负责互联网检索与研究。它把搜索分发到合适渠道，适合查新闻、论文、社交平台讨论、代码资料和其他会随时间变化的信息。

5. cloudflare

Cloudflare 平台的总入口，覆盖 Workers、Pages、KV、D1、R2、AI、Vectorize、网络、安全与基础设施即代码。当前站点部署在 Cloudflare Pages，因此使用机会较多。

6. wrangler

在运行 Wrangler CLI 前提供正确命令和操作规范，用于开发、部署和管理 Workers、Pages、D1、R2、KV、Queues、Workflows 等资源。

7. workers-best-practices

编写或审查 Cloudflare Workers 时检查生产实践，包括流式响应、悬空 Promise、全局可变状态、Secrets、Bindings 与可观测性。

8. openai-docs

回答 OpenAI API、模型、Codex 与提示词升级问题时，优先读取最新官方文档并给出引用，避免依赖已经过期的记忆。

独立 Skills：中频

9. imagegen

生成或编辑位图资产，包括照片、插画、纹理、透明背景素材、产品图和 UI Mockup。普通图片任务默认调用内置图像生成工具。

10. web-perf

用 Chrome DevTools 分析 LCP、INP、CLS、FCP、TBT、缓存、网络依赖和布局偏移，适合网站速度与 Core Web Vitals 优化。

11. agents-sdk

在 Cloudflare Workers 上构建有状态 AI Agent、WebSocket 应用、定时任务、工作流、MCP Server 与语音代理。

12. durable-objects

设计和审查 Durable Objects，适合聊天室、多人协作、预订系统、SQLite 状态、Alarms 与 WebSocket 协调。

13. chatgpt-apps

构建 ChatGPT Apps SDK 项目，把 MCP Server 与 Widget UI 连接起来，并处理资源注册、Bridge、CSP、Domain 和兼容性配置。

14. find-skills

当我想知道「有没有一个 Skill 能做某件事」时，用它搜索可安装能力并给出安装方向。

15. skill-installer

从 OpenAI 的 curated 或 experimental 清单，以及公开或私有 GitHub 仓库，把 Skill 安装到 $CODEX_HOME/skills。

16. plugin-creator

创建 Codex Plugin 的目录、.codex-plugin/plugin.json、可选结构和个人 Marketplace 条目，也负责开发期间的重新安装流程。

独立 Skills：低频或专项

17. cloudflare-email-service

为 Workers 或其他应用接入 Cloudflare Email Sending 与 Email Routing，并处理 SPF、DKIM、DMARC 和投递问题。

18. cloudflare-one

处理 Cloudflare One、Zero Trust 与 SASE，包括 Access、Gateway、WARP、Tunnel、DLP、CASB、设备姿态和身份系统。

19. cloudflare-one-migrations

把 Zscaler、Palo Alto、传统 VPN、SWG 或其他 SASE 架构迁移到 Cloudflare One，负责差距分析、策略映射和分阶段上线计划。

20. sandbox-sdk

构建安全执行不受信任代码的应用，例如代码解释器、在线开发环境、AI 执行器和 CI/CD 隔离环境。

21. turnstile-spin

端到端配置 Cloudflare Turnstile：创建 Widget、部署 siteverify Worker、接入前端、验证结果并保存可复用配置。

22. hk-value-snapshot

用真实财报与行情数据为港股公司生成「价值线企业快照版」，同时输出 HTML 与 Markdown，适合三十秒基本面筛选和价值投资研究。

23. review-agent

这是系统内置、主要供审查代理调用的只读 Skill。它检查指定 Diff、Commit 或分支变化，按严重度报告可执行缺陷，不直接修改代码。

缓存不等于已经安装

本机插件缓存中还能看到 openai-templates、build-web-apps、build-ios-apps、build-macos-apps 和 expo 等目录，也有不同来源的 superpowers 副本。它们没有出现在当前启用配置或本轮可用插件清单中，因此这次没有把它们列为已安装插件。

以后再次盘点时，应继续以三类证据交叉确认：Codex 的启用配置、本轮暴露的 Skills 与连接器、磁盘上的实际 Skill 文件。只看缓存目录，很容易把下载过、暂存过或已经停用的插件误算成当前工具。

记录时间：2026-07-20 13:31:12

这篇笔记整理自一次关于「做事前总是犹豫不决」的讨论。它不是心理诊断，只是对一种反复出现的思维与行动模式的梳理。

十秒钟的事情，为什么会拖上半小时

请假、提交报告、回复一条消息，都没有多少技术难度，后果通常也可控。可我仍会在行动以前反复推演：会不会影响别人？领导会怎么看我？这句话是否足够得体？要不要再等一会儿？

大脑在行动前启动的漫长风险评估，才真正消耗时间。

这套流程里混合了几种熟悉的倾向：在意别人的评价，习惯反刍，担心决定留下不可逆的后果，也希望找到最正确的表达和做法。它们叠加在一起，一件小事便有了远超实际的分量。

我拥有行动能力，只是把太多精力花在了避免犯错、预测反应和消除不确定性上。

我想在行动前得到确定性

犹豫背后藏着一个很高的要求：做以前便知道结果，说以前便知道别人会怎么想，决定以前便确认自己不会后悔。

现实无法提供这种确定性。只要我仍把「完全确定」当成行动条件，大脑就总能提出下一个问题。

于是，分析形成了一条循环：

遇到事情

→ 感到焦虑

→ 继续分析与修改

→ 暂时获得一点控制感

→ 仍然没有行动

→ 事情在心里变得更重

→ 更加焦虑。

分析本来应该帮助我作出决定，但在这条循环里，它承担了缓解焦虑的作用。只要继续想，我便暂时不用面对提交以后那一点无法控制的结果。

这也解释了为什么想得越久，不一定越清楚。有些思考并没有增加新信息，只是在重复同一种担心。

我担心的常常是别人的评价

请假时，我可能担心领导觉得自己态度不好；回复消息时，我可能担心对方觉得自己表达不妥；提出需求时，我又怕给别人添麻烦。

表面上，我在判断一件事是否合理。心里真正等待确认的，往往是：

别人会不会因为我的行为，对我产生负面评价？

当我试图预先照顾每个人的感受，也就把本来属于别人的判断揽到了自己身上。我既要替自己作决定，还想替对方完成反应和评价，当然很难轻松行动。

负责并不等于消除所有人的不满。我的责任是提供必要信息、尊重规则、承担自己能够预见的后果。对方如何理解和回应，则需要留给对方。

寻找最优解，在生活里可能变成负担

我喜欢寻找规律、研究简便方法，也习惯比较不同方案。这种能力在技术、学习和投资中很有用，因为许多问题确实值得推演。

生活里的大量小决定却没有唯一最优解。请假申请写得更漂亮一点，通常不会显著改变结果；一条普通消息改到第五遍，也未必比第一遍更真诚。

如果我把每件事都当成一道必须求出最优解的题，思考成本很快就会超过错误本身的成本。

我需要先区分决定的类型：涉及健康、长期资金和不可逆承诺的事情，可以慢下来；普通消息、常规申请和低成本选择，只需要一个合格答案。

对后者来说，六十分足以开始。剩下的清晰感，要靠行动后的反馈补上。

先把脑子里的风险还原到现实

犹豫出现时，我可以先问：

如果这件事做错了，最坏会发生什么？

以请假为例，现实中的最坏情况可能只是领导多问一句原因，或者这次申请没有获批。接下来，我说明情况、调整安排或正常上班。事情有具体后果，也有对应动作。

焦虑则容易把「可能被问一句」扩大成「对方会否定我的工作态度」，再把一次评价连接到整段职业关系。脑子里的风险因此升到九十分，现实里的风险可能只有十分。

把最坏结果写成一句具体的话，再写下应对动作，可以阻止想象继续扩张：

1. 我具体担心什么？
2. 它发生的概率有多大？
3. 即使发生，我准备怎样处理？
4. 这件事值得我再想多久？

如果新的思考既没有带来信息，也没有改变动作，我就该结束这一轮分析。

用小事练习在不确定中行动

改变这种模式，不需要先消除焦虑。更实际的训练，是在后果可控的小事上带着一点不确定感行动：

• 消息写好以后，在三十秒内发出；
• 请假申请完成以后，只检查一次便提交；
• 买几十元的日用品，只比较有限的选项；
• 回复普通问题时，不反复删除和改写；
• 为低风险决定设置两分钟期限，到点便选择。

训练要积累一类新的经验：我没有完全想清楚，也完成了行动；结果即使不完美，我仍然可以处理。

每一次这样的小行动，都在练习对不确定性的耐受能力。次数多了，大脑会慢慢发现，行动以后出现的反馈通常比行动以前的想象更具体，也更容易应对。

衡量进步，不再只看决定是否正确

如果我只用结果评价自己，一次不理想的回应就会被解释为「当初果然不该行动」。这会重新强化犹豫。

更适合当前阶段的衡量方式是：我有没有在合理时间内完成决定？有没有控制投入的思考成本？结果出现以后，我能否根据事实调整？

未来一段时间，我不必追求做出更多完美决定。我可以先练习让低风险的小事更快落地，把分析留给真正重要的问题。

很多清晰感需要行动带来的反馈。先向前走一步，我才会拿到下一条信息。

记录时间：2026-07-17 20:26:23

这篇笔记整理自一次关于「独立开发者如何使用 AI 从 Idea 走到产品上线」的长讨论。

真正的问题不是缺少 Skills

独立开发者懂工程，也能让 AI 快速生成代码。麻烦恰恰来自这种能力：用户问题还没有说清楚，脑中已经开始排列 Nuxt、Flutter、FastAPI、PostgreSQL、Docker 和云服务。

工程进展很具体，容易让人产生项目正在前进的感觉。但如果产品定位错了，完整的架构只会提高改方向的成本。

适合我的纪律是：

产品探索阶段不讨论实现；静态原型阶段不建设生产架构；工程阶段不增加 MVP 之外的需求；发布阶段不绕过测试、备份和回滚。

整个流程只分成三条线：

新项目：问题探索 → 产品规格 → 静态原型 → 冻结 MVP → 技术方案

每个功能：轻量规格 → 计划 → 实现与测试 → 独立审查 → 人工验收

每次发布：Staging → E2E → 人工批准 → 生产部署 → Smoke Test

一、产品探索：先证明问题存在

我的输入

• 产品 Idea；
• 我认为的目标用户；
• 用户现在使用的替代方案；
• 三至五个真实案例或访谈记录。

Skill + Prompt

brainstorming 是可选项。直接使用下面的 Prompt 也足够：

你现在是产品探索顾问，不是技术负责人。

请帮我确认：
1. 目标用户是谁；
2. 用户在什么场景遇到问题；
3. 用户目前怎样解决；
4. 现有方法哪里不够好；
5. 问题的频率和严重程度；
6. 最关键的价值假设是什么；
7. 如何用最低成本验证这个假设。

禁止讨论技术栈、页面实现、数据库、API、架构和部署。
当我开始讨论实现时，提醒我回到用户问题。

AI 做什么

AI 帮我整理假设、指出证据缺口、设计访谈或原型验证方法。它不能替我证明需求存在，也不能用竞品功能清单代替用户证据。

输出什么

结果：docs/product/problem.md

文档只需要写清：目标用户、具体场景、当前做法、核心障碍、价值假设和验证计划。

通过条件是一句没有技术名词的问题定义：

某类用户在某个场景下，因为某个障碍，无法完成某个重要目标。

二、产品设计：把问题变成可体验的流程

我的输入

• 已验证的问题定义；
• 用户最重要的一项任务；
• 第一版要验证的价值；
• 明确不做的功能。

Skill + Prompt

先用 speckit-specify 起草产品规格，再用 speckit-clarify 消除歧义：

speckit-specify：
根据已经确认的用户问题定义 MVP。
只描述目标用户、核心任务、用户流程、产品行为、异常场景、
验收标准和明确非范围。禁止讨论数据库、API、框架和部署。
优先删减功能。

speckit-clarify：
检查当前规格中存在多种解释的地方。
重点澄清内容组织、排序筛选、空状态、错误状态、发布下架行为
以及第一版明确不做的能力。把决定更新回规格，仍不讨论实现。

接着用 frontend-design 制作静态原型。数据可以写死，不连接 API，不建立数据库。页面完成后再用 web-design-guidelines 检查语义化 HTML、键盘操作、对比度、响应式、表单标签和长文阅读体验。

AI 做什么

AI 把产品行为整理成用户故事和验收标准，再把规格变成可以点击的页面。此时的原型用于验证信息架构、页面顺序和阅读体验，不承担生产代码的职责。

输出什么

结果：

specs/001-mvp/spec.md
docs/product/user-flow.md
docs/product/mvp.md
prototype/
docs/product/prototype-review.md

只有当目标用户能通过原型完成核心任务，并且 MVP 已经写清「必须做」和「明确不做」，项目才进入工程阶段。

三、工程设计：让技术服务已确认的产品

我的输入

• 冻结的 MVP；
• 已验证的静态原型；
• 技术和预算约束；
• 已有内容样本；
• 部署环境限制。

Skill + Prompt

使用 speckit-plan：

产品问题、用户流程、原型和 MVP 已经批准。

请设计满足现有规格的最简单实现方案。
每个技术决策都要注明它解决了哪条产品需求。
不得增加 MVP 之外的功能，不为尚未出现的规模问题设计架构。

输出模块边界、数据模型、API 契约、认证、测试、部署、备份、
回滚、当前不需要的基础设施，以及可以延后决定的问题。

投资内容平台还需要一个项目级 content-package-contract Skill，统一财报、CEO 演讲和管理层访谈的输出：

manifest.json
content.html
content.json
assets/
source/

契约应包含 JSON Schema、版本号、校验脚本和安全 HTML 白名单。网站、管理端和 App 从同一份契约读取内容，避免三个客户端各自猜测格式。

AI 做什么

AI 设计模块化单体、数据与接口契约、测试策略和部署路径，然后按用户可感知的能力拆成垂直切片。它不应该按「先做完数据库、再做完 API、最后做页面」分层拆任务。

输出什么

结果：

docs/architecture.md
docs/data-model.md
openapi.yaml
packages/content-contract/schema.json
scripts/validate_content_package.py
specs/001-mvp/tasks.md

第一个里程碑只打通一条闭环：生成一篇内容，后台导入和预览，发布后网站与 App 都能打开。

四、每个功能：固定使用一条短循环

我的输入

每次只给 AI 一个功能：用户要完成什么、验收标准、非范围、对应原型，以及允许修改的模块。

Skill + Prompt

writing-plans：
阅读 AGENTS.md、功能规格和相关代码，为当前功能写一份短计划。
逐步列出修改文件和验证方法，不加入规格之外的工作。

test-driven-development：
先写关键失败场景测试，确认测试失败，再写最小实现。
数据库变化使用迁移，API 变化同步契约，不做无关重构。

verification-before-completion：
实际运行测试、静态检查、类型检查和构建。
逐项核对验收标准，查看 Git Diff，并报告未覆盖风险。

出现失败时才调用 systematic-debugging。它要求先稳定复现、收集证据、一次验证一个假设，修复后补回归测试。

AI 做什么

AI 阅读规则，完成当前切片，运行验证并给出人工测试步骤。它不能自动推送或部署，也不能在编码过程中顺手扩张需求。

输出什么

**结果：**功能代码、测试、数据库迁移、更新后的 API 契约、真实命令结果、验收标准核对表和人工测试步骤。

编码完成后，打开一个新会话使用 requesting-code-review。审查者只读取规格、Diff 和测试结果，按 Blocker、High、Medium、Low 报告问题，不直接修改代码。修复后再次运行 verification-before-completion，最后由我亲自操作验收。

五、每次发布：测试环境与生产环境分开

我的输入

• Staging 地址和测试账号；
• 核心用户流程；
• 发布版本与 Git commit；
• 数据库备份状态；
• 当前生产镜像版本；
• 明确的发布批准。

Skill + Prompt

先用 agent-browser 在 Staging 完成登录、导入、预览、发布、公开浏览、移动端布局和下架流程。然后调用项目级 aliyun-release-checklist：

发布前检查 CI、迁移、备份、环境变量、域名、HTTPS、OSS 和回滚命令。
镜像使用 commit SHA，不使用 latest。

发布时推送镜像，ECS 拉取指定版本，执行迁移，更新容器，
检查 /health、首页、内容详情、管理端和静态资源。

任一步失败就停止，保存日志，恢复上一版本，并重新执行 Smoke Test。
未经我的明确确认，不得发布生产。

AI 做什么

AI 执行可自动化的检查，记录每一步证据，并在失败时停止。最终的 Go 或 No-Go 决定、数据库风险判断和生产发布批准仍由我负责。

输出什么

**结果：**Staging E2E 报告、截图、Go／No-Go 结论、发布记录、镜像版本、迁移结果、Smoke Test 结果和可执行的回滚命令。

最后保留哪些 Skills

核心 Skills：

speckit-specify
speckit-clarify
speckit-plan
frontend-design
web-design-guidelines
writing-plans
test-driven-development
systematic-debugging
verification-before-completion
requesting-code-review
finishing-a-development-branch
agent-browser

项目级 Skills：

content-package-contract
aliyun-release-checklist

brainstorming 和 speckit-tasks 按项目规模使用。using-git-worktrees、多 Agent 编排、复杂架构改造等工具，等并行任务和代码规模真的出现后再引入。

Skills 只是把工作方法固化下来。它们不能替代用户证据、产品取舍、亲自验收和生产发布前的判断。对独立开发者而言，最有价值的流程不是调用更多工具，而是在正确的阶段只解决一种问题。

记录时间：2026-07-17 20:26:02

这篇笔记整理自一次关于 Codex Skills、独立开发者工作流，以及如何避免过早思考架构的长对话。

真正的问题不是 Skills 不够多

讨论最初从「如何禁止 Codex 自动调用 Skills」开始，后来逐渐扩展到：从一个 Idea 出发，独立开发者如何借助 AI 完成产品、网站、管理后台、App、API、数据库、Docker 和云端发布。

过程中出现了许多 Skills，也产生了一个明显问题：每轮建议似乎都不一样。

原因并不复杂。不同 Skill 分别服务于产品探索、需求规格、界面设计、编码、调试、审查和发布。如果不先区分阶段，它们就会混成一条又长又重的流水线，让一个简单问题也经历头脑风暴、写计划、建 Worktree、TDD、代码审查和分支收尾。

对独立开发者而言，最大的风险通常不是不会写代码，而是：

工程能力太强，AI 执行速度太快，于是在用户问题还没有确定时，就开始设计数据库、API、Docker 和云服务。

这是一种「过早解决方案化」。架构越来越完整，产品价值却仍然模糊。

最合适的三阶段模型

整个项目只需要分成三个彼此隔离的阶段：

产品探索
→ 产品设计
→ 工程实现

每个阶段只解决一种问题，并设置清晰的进入条件。

第一阶段：产品探索

这一阶段只回答四个问题：

1. 谁遇到了问题？
2. 问题发生在什么具体场景？
3. 用户现在如何解决？
4. 现有方法为什么不够好？

输入： 产品 Idea、目标用户猜想、真实案例、现有替代方案。

AI 做什么： 追问用户、场景、频率、严重程度和行为改变的可能性，找出最关键的价值假设，并设计最低成本的验证方法。

可用 Skill： brainstorming。它不是必需品，一段明确限制讨论范围的 Prompt 也可以完成同样的工作。

输出： problem.md、待验证假设和验证计划。

阶段门禁： 必须能用一句话说清楚：某类用户在某个场景下，因为某个障碍，无法完成某个重要目标。

这一阶段禁止讨论技术栈、数据库、API、代码、Docker 和部署。想到的技术方案可以放进 parking-lot.md，但不进入当前决策。

第二阶段：产品设计

问题明确以后，才开始回答：用户如何通过产品完成任务？

输入： 已确认的问题、核心用户任务、第一版要验证的价值、明确不做的功能。

AI 做什么： 编写用户故事、核心流程、异常状态、验收标准和非范围；随后使用静态数据制作可点击原型。

可用 Skills：

• speckit-specify：把想法整理成产品规格，回答「做什么」。
• speckit-clarify：找出规格中的歧义，并把产品决定写回规格。
• frontend-design：把已确认的流程做成静态可体验原型。
• web-design-guidelines：审查已经存在的 UI 代码，不负责产品定位。

输出： spec.md、user-flow.md、mvp.md 和静态原型。

阶段门禁： 核心流程能在原型中完整走通，MVP 的「必须做」和「明确不做」已经冻结，并且自己或目标用户认可这个体验。

这一阶段仍然不建立真实数据库、API 和生产基础设施。静态原型的任务是验证价值与体验，不是偷偷开始写生产系统。

第三阶段：工程实现

只有用户问题、核心流程和 MVP 都被确认，才进入工程模式。

输入： 冻结的产品规格、已验证的原型、技术约束和真实内容样本。

AI 做什么： 设计满足当前需求的最小架构，定义数据与 API 契约，初始化工程，再把项目拆成可以独立验收的垂直切片。

可用 Skills：

• speckit-plan：把已确认的产品规格转换为技术方案。
• writing-plans：为一个明确功能写可执行的小步计划。
• test-driven-development：用于核心业务规则和 Bug 回归，不机械覆盖所有 UI 调整。
• systematic-debugging：出现异常时先复现、收集证据、验证假设，再修复根因。
• verification-before-completion：声称完成前实际运行测试、构建和检查。
• requesting-code-review：在独立上下文中根据规格、Diff 和测试结果找问题。
• finishing-a-development-branch：开发、审查和验收完成后整理 PR 与合并。

输出： 架构文档、数据契约、API 契约、可运行工程、功能代码、测试、迁移、审查报告和发布记录。

工程设计有一条硬约束：每个技术决策都必须能指向某条已经确认的产品需求。 不为尚未出现的规模问题建设微服务、消息队列或复杂平台。

先打通一条垂直闭环

不要先做完所有数据库，再做所有 API，最后才联调网站和 App。正确做法是先交付一条完整、可观察的用户能力。

对投资内容平台，第一条闭环应该是：

生成一篇财报、演讲或访谈内容
→ 管理后台导入
→ 系统校验和预览
→ 管理员发布
→ 网站能够阅读
→ App 能够阅读同一篇内容

这条闭环跑通以后，再增加公司管理、筛选、搜索、收藏或其他能力。系统是否成立，应由真实流程证明，而不是由目录数量和架构图证明。

每个功能的固定循环

每个功能不必重新走完整项目流程，只需要重复下面的小循环：

轻量功能规格
→ 简短实施计划
→ 实现与测试
→ 完成前验证
→ 新上下文审查 Diff
→ 人工验收
→ PR、CI、合并

你每次只输入：一个用户能力、验收标准、明确非范围和相关原型。

AI负责阅读项目规则、定位相关代码、写短计划、完成最小实现、运行验证，并报告仍未覆盖的风险。AI不应自行增加需求，也不应在未经允许时提交、推送或部署。

Bug 则使用更短的流程：

稳定复现
→ 找到根因
→ 写回归测试
→ 修复
→ 完整验证
→ 发布

每次发布的固定循环

部署 Staging
→ 真实浏览器与 App 流程测试
→ 人工批准
→ 数据库备份
→ 生产部署
→ Smoke Test
→ 观察日志和监控

浏览器端可以使用 agent-browser 或 Codex 的浏览器控制能力。阿里云发布流程更适合做成项目自己的 aliyun-release-checklist，其中固定检查镜像版本、数据库迁移、备份、ECS、OSS、域名、HTTPS、回滚命令和生产 Smoke Test。

另一个值得自建的 Skill 是 content-package-contract：它负责约束财报、CEO 演讲和管理层访谈采用相同的数据格式，使后台、网站和 App 面对的是同一个稳定输入。

Skills 应该怎样取舍

Skills 不是装得越多越好。重复能力只保留一套：

• brainstorming 与 grill-me 二选一；
• speckit-specify 可以替代通用的 to-prd；
• speckit-clarify 可以替代 grill-with-docs 的大部分作用；
• frontend-design 可以承担静态原型工作，不必再保留独立的 prototype；
• test-driven-development 与 tdd 二选一；
• 项目自己的 aliyun-release-checklist 替代通用发布清单。

Worktree、子 Agent、并行 Agent、架构优化和复杂诊断，都只在任务真的需要时使用。它们不是每个功能的固定仪式。

自动调用也要分类型

可以把 Skills 分成两类：

护栏型 Skills用于防止明显质量问题，例如 systematic-debugging 和 verification-before-completion，可以允许按需自动触发。

编排型 Skills会改变整个工作方式，例如 brainstorming、writing-plans、using-git-worktrees、test-driven-development 和多 Agent 开发，更适合手动调用。

希望保留手动调用、禁止隐式触发时，可以在对应 Skill 的 agents/openai.yaml 中设置：

policy:
  allow_implicit_invocation: false

如果某个 Skill 完全不需要，再在 Codex 配置中将它禁用。关键不是一刀切地禁止所有 Skills，而是避免让编排型 Skill 在不合适的阶段接管任务。

最后的极简版本

新项目只执行一次：

问题定义
→ 产品规格
→ 静态原型
→ 用户验证
→ 冻结 MVP
→ 最小技术设计
→ 第一条垂直闭环

每个功能重复：

轻量规格
→ 小步实现和测试
→ 独立 AI 审查
→ 人工验收
→ CI 合并

每次发布重复：

Staging
→ E2E
→ 人工批准
→ 备份和部署
→ Smoke Test
→ 监控

整套方法最终只剩下一条纪律：

产品探索阶段不讨论实现；静态原型阶段不建设生产架构；工程阶段不随意增加需求；发布阶段不绕过验证、备份和回滚。

记录时间：2026-07-15 13:17:38

愿景

成为一个更健康、更长寿、内心更平和、头脑更清醒、拥有更多选择自由的人。

使命

践行并传播价值投资与长期主义，通过技术、投资和真诚分享，帮助自己和他人做更少、更正确、更长期的选择。

价值观

本分

尊重规律，守住边界；做对的事，把事情做对；不占便宜，不推卸责任。

真诚

做真实的自己；正直坦荡，不卑不亢；不讨好，不伪装，也不欺骗自己。

理性

尊重事实，接受现实，独立思考；理解情绪，但不让情绪替自己作决定。

长期

尊重时间、复利和机会成本；专注少数重要的事，耐心积累，发现方向错误及时停止。

座右铭

做正确的事，把事情做对，剩下的交给时间。

Stop Doing List

一、投资

1. 不懂不投。 不能用简单语言说清商业模式、竞争优势、管理层和主要风险，不投资。

2. 不投坏生意。 不投长期缺乏竞争优势、定价权弱、盈利质量差、资本回报低的企业。

3. 不投脆弱的资产负债表。 不投依赖高杠杆才能生存、一次重大冲击就可能永久受损的企业。

4. 不与缺乏诚信的管理层合作。 管理层不诚实、不尊重股东、资本配置能力差，即使价格便宜也不投资。

5. 不用杠杆，不做空，不参与自己无法承受的风险。

6. 没有安全边际不买。 好企业不等于任何价格都值得买。

7. 不因股价、新闻、群聊和市场情绪频繁改变判断。

8. 不因沉没成本继续持有。 只判断从现在开始，它是否仍然值得持有。

二、人生

1. 不以捷径代替基本功。

2. 不以幻想、分析、规划或拖延回避现实。

3. 不占别人便宜，也不通过过度付出换取认可和关系。

4. 不推卸自己的责任，也不替别人承担本应由他承担的责任。

5. 不沉溺于抱怨、嫉妒、比较和受害者叙事。

6. 不复制别人的人生，不用他人的标准定义自己。

7. 不因沉没成本继续投入错误的人、项目和方向。

8. 不参与无助于目标的争论，不把注意力交给互联网情绪。

9. 不用输入代替输出，不把学习和准备误认为成果。

10. 不同时开启过多目标。每个阶段只保留一至两条核心主线。

11. 不透支健康换取短期成果。

12. 不把希望建立在对人性的理想化上。判断一个人，看行动、激励、边界和长期记录。

三、情感

1. 不长期单向付出。 不使用礼物、金钱、照顾和牺牲换取爱情。

2. 不向没有明确选择自己的人提供伴侣级投入。

3. 不把对等理解成逐笔算账。 对等看的是长期的选择、行动、时间、责任和关心。

4. 不在强烈情绪中作出重大决定。 先暂停，恢复平静后再处理。

5. 不读空气。 不用猜测代替直接沟通，不用言语暗示代替行动证据。

6. 不因害怕失去而隐藏真实需求，也不长期停留在模糊关系中。

7. 不把别人的回复速度、态度和选择当作自我价值的证明。

8. 不反刍没有新证据的过去。 复盘只为形成原则，形成原则以后停止重复审判自己。

9. 不试图通过改变、拯救或感动一个人，获得对方的选择。

10. 不因为认识时间长、投入很多或关系特殊，就忽视对方没有选择自己的事实。

记录时间：2026-07-14 16:14:16

这是一份关于职业转型、价值投资和 AI 工具化的下午日志。文中公司与财务数据用于研究方法验证，不构成投资建议。

起点：一次关于焦虑的对话

这件事的起点跟投资无关。

我是个移动端开发者，做电商 App。产品进入纯维护期以后，我已经半年没怎么写代码。就业环境不好，我一直觉得 AI 会取代我，而且对此有一种无能为力的感觉。

我把这份焦虑原封不动地丢给了 AI。它没有安慰我，而是指出了一个事实：真正的威胁不一定是 AI，而可能是这个岗位本身正在消亡。

与此同时，我手里其实握着一份难得的资源——一份还在发工资、但几乎不占用精力的工作。它等于给了我一条 6—12 个月的在职跑道，让我可以在不立刻失去现金流的情况下，尝试新的方向。

它给我的建议是：别再把主要精力放在框架细节上。那是贬值最快的部分。更值得做的是用 AI 把开发速度转化成产品能力，再把方向放在我两个能力圈的交叉点：我写了十年代码，也做了多年价值投资。

于是这个下午，我决定试一试。

第一步：搞清楚能做什么，以及不能做什么

我先做了一轮调研。几个关键结论很快把产品边界画了出来。

第一，合规是红线。 在国内，付费提供个股买卖建议属于证券投资咨询业务，个人开发者不能把“AI 荐股”当成产品方向。工具型产品则不同：数据、记录、复盘和研究辅助不直接替用户做交易决策。理杏仁这样的工具能够按年收费，说明这个需求本身真实存在。

第二，市场并不是没有缝隙。 AI 投研终端已经被同花顺、东方财富等大厂占据，个人开发者很难正面竞争。但 App Store 上“交易复盘”“持仓记录”这类小而专的独立应用，仍然有真实付费用户。问题是，它们几乎清一色服务短线交易者。

价值投资者的长周期决策记录与复盘，反而没有被认真服务。

第三，数据成本可以压得很低。 AKShare 免费覆盖 A 股、港股的行情和财报数据，东方财富的公开接口也能取到 F10 的大量信息。对一个个人开发者来说，数据成本接近于零，真正稀缺的是把数据转化成判断的流程。

产品方向于是定了下来：价值投资者的决策日志 + AI 复盘。 用户记录买入时的逻辑，每次财报发布后，系统自动对照：当初的逻辑有没有被新事实破坏？

这比提醒“股价涨了还是跌了”更接近长期投资真正需要的反馈。

第二步：验证数据管道能不能跑通

光有方向不够，还得证明数据链路确实能工作。这个下午，我实际验证了几件事。

• 从东方财富公开接口拉取茅台 12 年年报数据、分红历史和实时行情，交叉验证后全部对得上，算出的市值与接口返回值一致到个位。
• 摸清港股接口里的数据陷阱：财报是人民币，股息和股价是港元，三种币种混在同一张表里；股本和股息字段常常是当前值，而不是历史值；上市前优先股的会计处理，还可能让净资产显示为负数。
• 用真实数据生成了茅台和腾讯的“价值线式”单页报告，把原本分散的接口字段压成一张可以快速阅读的企业快照。

顺带还收获了一个洞察：茅台 2025 年报营收、净利双降，2026 年一季度毛利率跌破 90%。如果这个产品已经存在，这正是应该触发“逻辑体检”提醒的时刻。

产品需求不是凭空想出来的，而是被数据本身验证了：长期投资者需要的不是更多行情通知，而是有人提醒他回头检查自己的原始判断。

第三步：把大师的读法变成可执行的框架

这是今天最有意思的部分。

巴菲特说，他翻《价值线》30 秒就知道对一家公司有没有兴趣；芒格说，如果他开一所商学院，就会用《价值线》的图表教学。但他们到底在看什么？

我和 AI 把原始资料翻了一遍，提炼出一套完整的阅读框架，并在迭代过程中纠正了两个流行的误读。

误读一：芒格夸的“图表”是股价走势图

巴菲特的原话其实很明确：股价走势图对我们来说毫无意义。

芒格说的精髓，是股价图下方那 10—15 行财务数据。那部分信息把一家公司的长期经营记录、利润率、资本结构、每股数据和回报能力压缩成了一张“完美的企业快照”。

误读二：整页内容都有用

真实的《价值线》页面上，评级、Beta、目标价、机构动向和分析师预测占了很大篇幅。但巴菲特和芒格明确表示，他们并不关心这些意见。

原则只有一句：不寻求意见，只寻找事实。

最终的阅读框架是一条流水线。

入口：先看历史新低名单

第 0 步不是打开某家公司，而是先看“历史新低名单”：股价新低、PE 新低、PB 新低。

新高名单上的公司，价格里往往已经装满了乐观；便宜只可能藏在新低里。新低不代表值得买，但它至少提供了一个值得继续问问题的入口。

五步扫描：30 秒内找否决理由

1. 长期记录像不像一条直线？营收、利润、现金流和每股价值，是持续向上，还是充满断裂和反复？
2. ROE 高不高、靠不靠杠杆？高回报来自真正的生意质量，还是来自不断加大的债务？
3. 股本在缩还是在胀？回购可能放大每股价值，融资和增发则可能稀释原有股东。
4. 利润率有没有定价权？毛利率和经营利润率是长期改善，还是只随着周期涨落？
5. 和自己的历史比贵不贵？估值不是脱离历史的绝对数字，而是当下价格相对于企业自身记录的关系。

任何一步不合格，就先翻页。第一轮扫描的目的不是找出“可以买”的公司，而是尽快找到否决理由。

5 秒心算：先抓住数量级

对企业做第一轮判断时，只需要做几项心算：市值、EBIT、经营占用资本，以及 EV/EBIT。

禁用计算器，也先不用“每股”概念。商誉不算真正投入的经营资本，融资带来的每股增长也不能直接当成生意增长。这个过程不是为了算出一个精确估值，而是为了快速判断：眼前的价格和生意，大致是不是同一个数量级。

五问清单：把页面之外的问题留下来

• 价格便宜吗？
• 是好生意吗？
• 管理层可信吗？
• 我漏了什么？
• 为什么这家公司会被我发现？

前两问，企业快照通常可以给出初步答案；后三问必须自己去挣。页面能压缩事实，却不能替你完成理解。

第四步：用三家公司实测

框架不经过实测，仍然只是空谈。我用真实数据做了三份“企业快照版”单页报告。

Builders FirstSource：翻页

Builders FirstSource 是一家美国建材制造与分销公司。它在 2008—2013 年连续亏损六年，高 ROE 很大程度上由 43% 的债务占比撑起，利润率也随着房地产周期上下波动。

五步扫描的第一步就出了问题：长期记录不像一条稳定向上的直线。它可能是一家值得研究的周期型公司，但不符合这套快速筛选框架对“稳定复利生意”的第一印象。

判词：翻页。

泡泡玛特：进入第二轮

泡泡玛特的入口第一次就亮了灯：股价距离 52 周低点只有 10%，PE 已经从 87 倍降到 14 倍。

它的生意质地也很罕见：无杠杆 ROE 达到 77%，85 亿元经营资本赚取 170 亿元息税前利润，毛利率九年间从 48% 爬升到 72%。从企业快照看，增长、利润率和资本回报都相当醒目。

但 14 倍 PE 的分母，是一个同比增长 309% 的爆发年利润。页面可以告诉我利润涨得多快，却回答不了一个更重要的问题：Labubu 是可口可乐，还是郁金香？

这已经超出了快照的能力边界，需要进入第二轮，去研究 IP 的生命周期、渠道结构、用户复购和管理层资本配置。

判词：进入第二轮。

小米集团：进入第二轮

小米的入口信号更强，股价距离 52 周低点只差 1.1%。但它的画像完全不同。

它的毛利率在十一年间从 4% 单边上行到 22%，ROIC 却始终只有 10% 上下；公司从不分红，为造车业务持续融资，加权股本七年净增 8%。

看小米必须保留“每股”思维，否则很容易把融资买来的收入增长，误认为是生意本身的增长。规模在变大，不等于每一股的内在价值同步增长。

小米真正的分歧点，在于汽车业务最终能否获得足够高、足够稳定的回报率。

判词：进入第二轮。

同一套模板，三种判词。方法开始像一个产品了。

第五步：把流程沉淀成 Skill

最后一步，我把整个生成流程写成了一个可复用的 AI Skill：

取数 → 核对数据陷阱 → Python 验算 → 应用判定框架 → 模板渲染

以后对任何一只港股说一句“生成企业快照”，就能得到同样结构的页面。它不负责替我下结论，而是负责把重复劳动变成一条稳定的流水线。

这一步对我的意义特别大。它证明了：方法可以被工具化，工具可以被复用。

而这正是我想做的产品的雏形——不是把投资判断外包给 AI，而是把自己的判断流程变成一个能反复调用的系统。

今天的产出清单

一个下午结束时，留下了这些具体产出：

• 一份产品规划文档，包含合规边界、MVP 定义，以及内容与产品双轮策略。
• 一份财报接口字段词典。
• 茅台、腾讯两份价值线式报告。
• Builders FirstSource、泡泡玛特、小米三份企业快照。
• 一个可复用的企业快照生成 Skill。
• 若干用于取数、核对和验算的数据脚本。

全部由真实公开数据驱动，数据成本为零，耗时一个下午。

这不是一个已经验证商业成功的产品，但它至少完成了最重要的第一步：把模糊的职业焦虑，变成了一个可以运行、可以复用、可以继续接受现实反馈的实验。

写在最后

早上我还在焦虑“AI 会取代我”。下午结束时，我意识到问题可能问错了。

AI 取代的是“写代码”这个动作，放大的是“判断该做什么”的能力。今天做的每一件关键事情——判断合规边界、识别数据陷阱、把大师的只言片语提炼成可执行框架、决定页面上删掉什么——都是 AI 不能替我完成的部分。

而它把剩下的一切加速了一百倍。

一个人，半天，完成了过去可能要一个小团队才能做完的事情。被取代的恐惧，和成为杠杆的兴奋，原来是同一件事的两面。

AI 不是让我停止成为开发者，而是逼我重新回答：除了写代码，我到底能判断什么、创造什么、承担什么？

下一步有两件事：把泡泡玛特和小米的“第二轮功课”真正做完，写成公开复盘；再把快照生成做成“输入代码，一键出页”的工具原型。

记录时间：2026-07-14 13:38:59

这篇笔记整理自一次持续很久的自我分析：从性格、恐惧与行动，到一段长期困住我的感情关系。它不是心理诊断，而是对反复出现的思维和行为模式所作的一次整理。

如果要为自己画一幅尽可能诚实的画像，我大概是一个高责任感、强系统思维的长期主义者。

我喜欢追究底层规律，把零散知识整理成框架；相信复利、能力圈和安全边际；希望把技术、投资、心理学、哲学与教育连接起来；遇到问题时，也习惯查资料、建模型、做预案、寻找更可靠的判断标准。

这些特点让我能够看得深、想得远，也让我比很多人活得更紧。

因为在这些看起来不同的性格特征下面，可能藏着同一个需求：

我希望通过理解规律、建立系统和提前准备，减少失控，避免犯下无法挽回的大错。

我曾经以为，只要把事情想得足够清楚，人生就会更安全。现在我开始怀疑：不断想清楚，究竟是在解决风险，还是在缓解恐惧？

同一条根，长出了优点与困境

我身上的很多优点和缺点，并不是互相独立的。它们常常是同一种能力在不同情境下的两面。

系统思维让我善于抽象、分类和搭建框架；推到极端，就会变成过度系统化，仿佛连幸福、关系和人生选择都应该有一套完美算法。

长期主义让我能够忍受短期波动、持续积累；推到极端，就可能让我在错误方向上坚持太久，把不退出误认为有耐心。

风险意识让我警惕杠杆、集中押注和不可逆损失；推到极端，就会把尚未发生的可能性不断放大，在真正行动以前先经历无数次失败。

高标准让我在意逻辑、结构和质量；推到极端，就会把一个小项目扩张成完整体系，通过继续准备推迟现实检验。

自我反思让我能够看见问题；推到极端，就会从复盘滑向自我审判，反复追问自己是不是落后了、做错了、来不及了。

教师型的表达欲让我喜欢把复杂问题讲清楚；推到极端，也可能让我停留在解释世界，而没有持续创造能够接受现实反馈的作品。

所以我真正需要做的，不是消灭这些性格。它们也是我重要的能力来源。我需要做的是：为优势设置边界，让它们在越界以前发出提醒。

我不是胆小，而是太想避免不可逆损失

我一直恐惧很多事情，也总是预想很多。

我会预想投资判断错误、职业被时代淘汰、身体出现问题、年龄增长却没有形成成果、项目失败、关系失控，以及某个决定会不会让我失去退路。

这些担忧看似分散，实际上都指向同一类威胁：

结果无法完全预测，后果又可能很大，而且一旦发生便难以恢复。

我并不特别害怕普通的小错误。程序里的 Bug 可以修，试验失败可以重来，短期波动也可以承受。我真正害怕的，是一次错误毁掉多年积累，或者证明自己走错了很久。

于是大脑形成了一条很稳定的回路：

不确定性

→ 感到威胁

→ 查资料、做推演、寻找框架

→ 获得短暂的控制感

→ 更加相信“只有继续分析才安全”

→ 下一次更难忍受不确定性。

分析当然有用。问题在于，它有时已经不再服务于决策，而变成了缓解焦虑的止痛药。

真正的风险管理会得到一个具体动作，并且能够结束；焦虑性预演则会不断扩大问题，却不产生新的行动。

我可以用一个简单问题区分它们：

想完以后，我是否多了一个具体行动、一个明确边界，或者一个停止条件？

如果没有，我大概率不是在解决风险，只是在精神上重复经历风险。

我总是在脑子里同时生活很多年

系统思维的另一个代价，是我很容易离开今天，住进未来。

我面对的似乎不只是今天的工作，而是未来十年的职业竞争；不只是眼前的一笔投资，而是未来的财务自由；不只是一次关系波动，而是以后会不会永远遇不到合适的人；不只是一个作品无人关注，而是自己这辈子能不能成为真正的创作者。

一个普通选择，常常被我自动连接到整个人生。

项目没有做好，不再只是项目反馈，而可能被解释为路线错误；投资出现亏损，不再只是一次判断偏差，而像是能力不足；对方没有回复，也不再只是一条消息没有回复，而像是我不值得被重视。

当具体事件与自我价值绑定，选择自然会变得沉重。

我不是在过一天，而是在头脑里同时承担很多年的得失。难怪会累。

那段感情，是触发器、放大器，也是一面镜子

我曾经把很多年的感情，投入在一个没有真正进入关系的人身上。

我长期喜欢、等待、陪伴，也很在意对方是否回复、回复得快不快、语气是否温和。后来表达感情，得到的不是明确接受，而是一种珍惜多年情谊、希望仍能像过去一样相处的回应。

这不是承诺，却也不像彻底离开。它留下了一块模糊地带，而我最不擅长处理的，恰恰就是模糊。

我不断分析那些细节，希望从中找到一个确定答案；继续投入，又希望长期陪伴最终能够换来关系升级。后来她选择了别人，我失去的不只是一个喜欢的人，还包括自己对多年等待的解释。

现在回头看，这段经历暴露了我的几个模式。

把喜欢变成长期等待

我把专一、耐心和不轻易放弃带进了感情，却忘了：长期主义只有建立在双方共同选择的基础上才成立。

投资需要基本面，关系需要双向意愿。只有一个人持续投入，不是深情的复利，而是单边消耗。

在关系确定以前，投入了确定关系才该投入的情感

我曾经把陪伴、付出和等待，当成关系最终会自然升级的理由。但感情不是积分兑换。

真正重要的不是某一句话有没有留下希望，而是对方有没有明确、持续、主动地走向我。

把回应当成自我价值的证明

对方回复时，我会安心；对方沉默时，我会焦虑。表面上是在等一条消息，实际上是在等待确认：我是不是重要，我是不是值得被选择。

当我把这个答案交给别人，我的情绪开关也就交给了别人。

用过去的投入要求未来继续投入

等待得越久，越难承认方向可能错了。因为一旦退出，好像过去的一切就失去了意义。

但过去的付出，不需要用未来的继续痛苦来证明它有意义。七年已经很贵，不能因为已经付出七年，就再交出第八年。

如果没有她，我的人生会不会不同

答案当然是会。

如果没有这段经历，我可能少消耗很多情绪，更早积累真实的关系经验，也不会如此强烈地形成“被选择焦虑”。

但她并不是我所有问题的根源。

即使没有她，我对不确定性的敏感、对长期投入的偏爱、对外部确认的需要，以及不擅长退出的模式，也可能在投资、职业、项目或另一段关系中出现。

她更像三个角色：

• 触发器：触发了稀缺感、失去感和被选择的焦虑；
• 放大器：把我原本就有的担忧与控制倾向放大；
• 镜子：让我看见自己会怎样在没有正反馈时继续投入。

我不需要把她定义成毁掉人生的人，那会让我继续被她绑定；也不必强迫自己感谢痛苦，那并不真实。

更成熟的理解是：

这段经历让我付出了真实代价，也暴露了我原本就需要面对的问题。我要从中拿回的不是一个关于她的最终解释，而是自己的边界、判断和主权。

我最大的风险，不是冲动，而是有理有据地坚持错误

我并不是一个典型的冲动型人格。真正可能伤害我的，往往不是一时兴奋，而是一个看起来经过充分研究的决定，在耐心、投入、自尊与解释能力的保护下，被坚持得太久。

对我而言，危险的组合是：

高确信度 × 高集中度 × 身份认同 × 沉没成本 × 缺少反证。

我的逻辑能力越强，就越有能力为已有判断寻找解释。

长期主义可以掩盖基本事实已经变化；能力圈可以掩盖不愿接触新证据；高标准可以掩盖害怕发布；独立思考可以掩盖拒绝反馈；坚持可以掩盖不愿承认沉没成本。

因此，我最大的弱点不一定是判断错误，而可能是纠错速度太慢。

观点一旦和身份绑定，承认观点错误就会像否定自己。只有把两者分开，我才可能更快修正：

一次投资失误，不等于我不是投资者；一个项目失败，不等于我没有创造能力；一个人没有选择我，也不等于我不值得被爱。

两种灾难：一次押错，与一生准备

我需要防止两类完全不同的灾难。

第一类是突然型灾难：在一个错误判断上投入过多，让单一资产、单一职业方向、单一项目或单一关系决定整个生活基本盘。

第二类是缓慢型灾难：读了很多书，建立了很多框架，规划了很多项目，却始终没有形成稳定、公开、能够积累反馈的作品。

前者会突然造成巨大损失，后者则每天失去一点时间、专注力和机会。

一个来自过度下注，一个来自迟迟不下注。它们看似相反，背后却都是同一个愿望：希望在行动以前获得足够确定性。

不要消灭思考，要给思考设置边界

我不需要变成一个不做计划、凭感觉冒险的人。那既不现实，也会浪费自己的优势。

真正需要改变的，是把无边界的担忧变成有边界的风险管理。

让每次担忧落到四行纸上

1. 我具体害怕什么？
2. 最坏会发生什么？
3. 我现在能做的最小动作是什么？
4. 我什么时候停止继续想？

恐惧一旦不能转化为行动、边界或接受，就应该结束这一轮分析。

在重大决定以前写下推翻条件

我为什么相信这个判断？哪三个事实能够证明我错？什么变化会触发重新评估？最强的反对意见是什么？即使失败，我是否仍能正常生活并重新开始？

不要等事情发生以后再制定退出标准。那时沉没成本、自尊与损失厌恶已经进入现场。

把不可逆的大赌注，拆成可逆的小实验

不等课程完整，先公开一篇文章；不等产品覆盖所有场景，先验证一个核心问题；不等自己完全有资格，先做一次真实讲解；不靠脑内推演决定职业未来，而是让一个小项目带回反馈。

有些问题不是想清楚以后才行动，而是行动以后才可能想清楚。

在关系里只看三个事实

不再用模糊细节补充希望，只看：

1. 明确性：对方是否清楚表达愿意发展关系？
2. 主动性：对方是否也会主动靠近和维持联系？
3. 对等性：情感、时间与责任是否主要由一个人承担？

喜欢可以主动，但不能把自尊交出去；关系可以慢慢发展，但不能长期依靠一个人的想象维持。

为生活保留重新开始的资格

不用生活基本盘承担高风险，不让单一判断摧毁全部选择权，不在情绪高峰时做不可逆决定，也不以事业和财富目标为理由长期透支身体。

真正的安全，不是永远不犯错，而是错误发生以后仍然有恢复能力。

从寻找正确答案，转向接受现实反馈

我过去很喜欢问：最聪明的人会怎样选择？什么才是正确答案？有没有一个完整框架可以避免错误？

这些问题仍然有价值。但在人生、创作和关系里，很多时候并不存在一个可以提前推导出来的标准答案。

我下一阶段真正需要练习的，是从：

我要理解更多，确认自己是对的。

转向：

我要做一个成本可控的行动，让现实告诉我哪里不对。

这意味着少一点把学习当准备，多一点把输出当学习；少一点通过权威确认自己，多一点记录自己的判断；少一点在头脑里经历未来，多一点完成今天真正重要的事情。

知识会复利，作品、信誉、关系能力、身体状态和纠错记录也会复利。

把人生主权拿回来

我无法回到过去，验证“如果没有那个人，我会不会过得更好”。即使得到了答案，也不能改变今天。

我能够决定的是，过去发生的事情还要不要继续支配未来。

过去的几年可以被一段关系改变，未来十年不能再由“当初有没有她”定义。过去的错误可以留下代价，但不必继续收取利息。

我想为自己保留几条简单的规则：

任何判断都只是暂时假设，不是我的身份。

没有明确选择我的关系，不值得长期单边投入。

不因为已经投入很多，就自动投入更多。

重大决定先写反证、退出条件和最坏后果。

不用生活基本盘换取一次证明自己正确的机会。

每吸收一部分知识，都尽量产生一个可见作品。

允许小范围失控，让现实不断纠正我。

我真正要建设的，不是一个永远不出错的人生系统，而是一个出错也不会崩、失败仍能恢复、不确定也能前进的系统。

最后，真正的安全也许不是把所有事情都想清楚。

真正的安全，是即使没有想清楚全部，我仍然知道自己可以承受、调整、退出，并重新开始。

记录时间：2026-07-14 11:22:29

这篇笔记整理自一次关于简便方法、争论欲、炫耀与逃避的讨论。

我上学做数学题时，特别喜欢研究简便方法。比起老老实实地计算，我更愿意寻找规律、特殊结构和巧妙变形。发现一条别人没看见的捷径，会让我产生一种很强的满足感。

但我也常常因此忽略基本功。

后来回头看，这个习惯并没有停留在数学题里。它似乎变成了一种更普遍的思维方式：喜欢框架、底层逻辑和更优解，却容易对重复训练失去耐心；喜欢分析和解释，却不一定愿意在一个迟迟没有反馈的现实问题上持续推进。

简便方法既是优势，也是诱惑

喜欢简便方法，首先说明我对规律敏感，愿意抽象，也本能地想优化低效过程。这并不是坏事。很多创造性思考，正是从一句“有没有更好的做法”开始的。

问题在于，简便方法通常依赖特殊结构、隐藏条件或熟练的基础操作。如果基本功没有托住它，技巧就容易变成一堆孤立的招式：这道题会巧解，换一个形式却不知道为什么还能这样做。

于是就会出现一种矛盾：

• 难题偶尔能想到漂亮思路，简单题却可能在细节上出错；
• 很快看懂别人的方法，却不能稳定、完整地复现；
• 愿意研究有意思的问题，不愿意接受必要的重复；
• 总想找到正确方法，却不愿承认有些能力就是需要时间积累。

真正成熟的“聪明”，不是永远绕过笨功夫，而是知道哪些笨功夫根本绕不过去。

争论也是另一种简便方法

我还有一个习惯：很喜欢和别人争论，哪怕争论的东西对自己并没有多大意义。现实中的争论停下来以后，我有时还会在头脑里继续，一边代表对方，一边代表自己，不断补充论据和反驳。

这和寻找数学捷径看似无关，其实有相似之处。

争论给问题划出了清楚的边界：对方说了什么，我哪里不同意，我要怎样证明。它有明确的立场、即时的反馈，也容易产生“我正在深入思考”的感觉。相比之下，现实问题往往模糊、缓慢，甚至没有人回应。

内部对话本身也不是坏事。模拟不同立场，可以帮助我检查漏洞、理解别人、修正判断。区别在于，它最后有没有产生新东西。

有用的内部辩论是：

出现新证据，修正观点，作出决定，然后行动。

无用的内部辩论则是：

重复旧论据，想象对方反驳，再次反驳，情绪越来越高，现实却没有向前一步。

前者是思考，后者更像反刍。问题不在于我太爱思考，而在于思考没有继续服从目标，反而接管了目标。

炫耀与逃避确实都在场

当我回答别人、纠正别人或者参与辩论时，里面当然可能有炫耀的成分。

我希望证明自己懂得多、反应快、逻辑强；希望别人看见我的能力；也可能享受对方被说服、点赞，甚至无话可说时带来的优越感。

这种欲望不必粉饰。一个很直接的判断是：如果没有任何人能看见这段回答，我还愿不愿意花同样多的时间？

但只用“虚荣”解释它，又太简单了。很多时候，逃避的成分更值得注意。

我遇到自己解决不了的问题时，会上网或进入微信群求助。如果别人没有回应，我往往就不再继续问了。可是一旦看见别人提出我会的问题，我又会主动回答；看见别人说了我认为不对的话，也可能立刻参与辩论。

这个顺序暴露出一条很隐蔽的回路：

遇到困难

→ 求助没有得到回应

→ 感到受挫、无力或尴尬

→ 转去回答别人或纠正别人

→ 重新获得能力感和控制感

→ 原来的问题被搁置。

刚才的我是一个不会、而且没人理的求助者；几分钟后，我变成了一个能给别人答案的人。这个角色转换能够迅速修复自尊，也让我暂时不用面对“我还不会”“我还得继续试”这些不舒服的事实。

**炫耀满足了“我很厉害”，逃避帮助我暂时离开“我现在不会”。**二者常常不是互相排斥，而是在同一个行为里合作。

这是一种生产性逃避

有些逃避很容易识别，例如刷视频、玩游戏、漫无目的地浏览网页。另一些逃避却穿着勤奋的外衣。

研究方法、搭建框架、回答问题、帮助别人、辩论观点，单独看都很有价值。正因为如此，它们特别适合成为“生产性逃避”：我一直在用脑，也确实做了一些有用的事，于是很难承认自己并没有推进最重要的问题。

这种行为会制造一种伪生产感。我输出了很多观点，获得了能力感，却没有得到自己最初想找的答案。久而久之，大脑还会越来越偏爱那些可以立即回答、立即反驳的刺激，而不愿承受一个复杂问题长期没有反馈的状态。

真正被削弱的，可能不是智力，而是三种朴素的能力：

1. 在无人回应时继续寻找下一条路径；
2. 在没有捷径时完成必要的基础训练；
3. 在没有即时认可时仍然守住原来的目标。

不要急着给自己贴道德标签

看见炫耀和逃避以后，很容易走向另一个极端，把自己定义成虚荣、懒惰或好胜的人。这种标签并不能帮助我改变，反而可能制造一场新的脑内争论：我到底是不是一个坏人？

更有用的理解是：这是一套被反复强化的行为回路。

争论有即时反馈，回答熟悉问题有成就感，寻找巧法有惊喜；而打基础、承认不会、修改提问、等待回复、测试失败，都缓慢而且不舒服。大脑自然会选择回报更快的那条路。

所以我要调整的不是人格，而是顺序和规则。不是禁止自己思考、表达和帮助别人，而是让这些能力重新为真正的目标服务。

给自己几条具体规则

第一，先用标准方法做对，再研究简便方法。

第一遍追求正确、完整和可复现；第二遍再问能否简化、为什么成立、适用条件是什么。简便方法必须建立在基本功之上，而不能替代基本功。

第二，把一次求助当作检索过程，而不是人际投票。

没人回应，不代表我不值得被帮助，也不代表问题无解。固定执行三步：修改问题表达，换一个渠道，搜索相似案例并做最小测试。第一次沉默只是一次信息不足，不是结束信号。

第三，进入群聊前写下唯一目标。

例如：“我现在只解决这个 Flutter 报错。”发布问题、查找答案或完成必要的等待设置后就离开，不顺便浏览其他话题。

第四，帮助别人之前，先推进自己的问题。

可以规定：先为自己的核心问题工作二十五分钟，才能回答一个别人的问题。这样既保留解释和帮助别人的乐趣，也不让它变成撤退路线。

第五，把脑内争论改成一张书面决策单。

只写四项：我的观点、对方最强的观点、什么证据会改变我的看法、下一步行动是什么。十分钟后停止。如果没有新证据，也不会改变任何行动，就标记为“无需继续判断”。

第六，在发言前问三个问题。

1. 我现在最重要的问题推进了吗？
2. 这场讨论会改变我的行动吗？
3. 我是在帮助事情向前，还是在恢复自尊、证明自己？

这三个问题不会消灭争论欲，但能让我重新看见原来的目标。

让聪明重新服从目标

我真正需要练习的，也许不是少想一点，而是允许现实暂时不清楚：允许一个问题没有捷径，允许别人没有回应，允许自己暂时不会，同时仍然继续寻找下一条路径。

寻找规律、提炼方法、解释复杂问题，仍然是我的优势。只是优势一旦失去目标约束，也会变成最熟练的逃避工具。

以后再遇到类似时刻，我想提醒自己：

先完成自己的任务，再讨论别人的观点；先走通标准路径，再寻找漂亮捷径；既能看见聪明的办法，也愿意走那些必要的笨路。

记录时间：2026-07-13 09:25:19

来源说明：本文根据本地 HTML《Seeking-Wisdom-不能做的事.html》整理。源笔记基于 Peter Bevelin 的《Seeking Wisdom: From Darwin to Munger》，这里采用读书笔记和观点整理方式重组，不复刻原 HTML 的完整清单和引文。

《Seeking Wisdom》最有价值的地方，不是给出一套听起来很聪明的原则，而是反复提醒人：多数重大错误并不是因为不够聪明，而是因为在关键时刻做了不该做的事。

芒格喜欢逆向思考。他关心的不是怎样显得更聪明，而是怎样避免愚蠢。这个角度很实用：如果一个人先知道自己会在哪里犯错，很多时候就已经避开了一半灾难。

本地 HTML 把全书整理成一个“不能做的事”清单：28 种心理偏见、9 种物理和数学误判、12 种思考工具中的警示。逐条看会很多，但压缩以后，其实可以归为几类。

一、不要先骗自己

所有误判里，最危险的不是信息不足，而是自己已经不愿意看信息。

人会天然维护旧判断、旧承诺、旧身份和旧投入。买错股票后不愿意卖，是因为卖出会把错误坐实；做错项目后继续投入，是因为承认失败会伤害自尊；公开表达过某个观点后继续为它辩护，是因为改变立场看起来像丢脸。

所以第一条反向规则是：不要让自我形象替你做决策。

可以问自己几个问题：

• 如果我从来没有做过这笔投入，今天还会重新开始吗？
• 我现在是在看事实，还是在保护一个过去的决定？
• 我有没有主动寻找让我不舒服的反面证据？
• 我是不是真的理解这件事，还是只是不想承认自己不懂？

这类问题不好受，但必要。因为自我欺骗最麻烦的地方在于，它通常不是有意识的撒谎，而是一种很舒服的选择性失明。

二、不要低估激励和情境

很多判断错误，来自把人想得太抽象。

我们喜欢说一个人诚实、专业、理性、善良，但现实里，人会被激励、地位、惩罚、群体气氛和所处环境塑形。一个在你的决策中有经济利益的人，不一定故意骗你，但他看世界的方式很可能已经被利益改变了。

所以不要只问“他说得有没有道理”，还要问：

• 他从这个建议里得到什么？
• 这个系统奖励了什么行为？
• 如果我奖励了这种行为，未来会不会得到更多这种行为？
• 是这个人真的变坏了，还是这个环境鼓励了坏行为？

这也是为什么管理和投资都不能只靠道德判断。激励错了，后面会出现大量看似偶然、其实必然的坏结果。与其反复要求人克制，不如先设计一个不鼓励愚蠢和欺骗的系统。

三、不要把故事当证据

人脑喜欢故事，尤其喜欢生动、近、情绪强、容易记住的故事。

但决策需要的是可靠证据。一个近期新闻、一个戏剧化案例、一个身边朋友的经历，都可能让人高估某件事的概率。反过来，沉默的样本、没发生的事、失败者的经验、长期基础率，常常被忽略。

因此，遇到一个特别有感染力的故事时，应该故意慢下来：

• 这个故事代表总体吗？
• 没被我看到的反例在哪里？
• 基础率是多少？
• 样本量够不够？
• 这是永久变化，还是短期噪音？

投资里尤其容易中招。一个公司最近涨了很多、一个行业最近很热、一个创始人的故事很动人，都不能直接推出未来回报。故事可以帮助理解，但不能替代证据。

四、不要只看局部

《Seeking Wisdom》不只是一本心理偏误书，也强调系统、反馈、规模、概率和因果。

局部看起来正确的行动，在系统里可能制造更大的问题。一个短期奖励可能破坏长期能力；一个局部优化可能转移成本；一个看似线性的增长，到了规模变化后可能碰到极限；一个看似因果的关系，可能只是共同受第三个变量影响。

所以好的问题不是“这一步有没有好处”，而是：

• 第二层和第三层后果是什么？
• 如果所有人都这么做，系统会变成什么样？
• 小规模有效，放大后还有效吗？
• 我看到的是因果，还是相关？
• 有没有反馈循环会放大这个结果？

这类问题能把人从单点聪明拉回系统判断。很多错误不是因为第一步错得离谱，而是因为第一步看起来太合理，以至于没人继续问后果。

五、不要在错误状态下做重要决定

人在疲劳、压力、疼痛、愤怒、兴奋、恐惧、急躁、被群体包围、被权威注视时，判断力都会下降。

这不是道德问题，也不是意志力问题，而是状态问题。状态错了，就容易高估自己、轻信别人、寻找理由、被群体带走，或者为了摆脱不舒服而仓促行动。

一条很实用的规则是：重要决定尽量不要在坏状态下做。

如果情绪很强，先推迟；如果压力很大，先缩小决策；如果身体很差，先恢复；如果场合充满社会压力，先把决定带回安静环境；如果自己特别想马上行动，先问这是不是“为了活跃而行动”。

很多时候，最好的行动是暂时不行动。但这和拖延不同。拖延是不敢面对问题；延迟决策是为了让自己回到更可靠的状态。

六、不要把活跃当成果

忙碌很容易给人一种进步感。

学习很多资料、做很多计划、开很多会、交易很多次、频繁调整项目方向、不断更换工具和框架，都可能让人感觉自己在前进。但《Seeking Wisdom》提醒的是：活动不是结果，频繁动作也不是纪律。

真正要问的是：

• 这个动作是否改善了结果？
• 我是在解决问题，还是在缓解焦虑？
• 我是不是因为不能忍受等待，所以做了一件多余的事？
• 如果不做这件事，损失是什么？

投资里，不交易常常比交易难；写作里，不扩张主题常常比继续堆材料难；做产品时，不加功能常常比加功能难。克制不是懒，而是知道什么时候行动会把事情变坏。

七、不要没有过滤器

复杂世界里，不可能每件事都深入研究。没有过滤器的人，会被信息、机会、请求和情绪拖着走。

过滤器包括能力圈、安全边际、机会成本、基本率、反面证据、检查清单、时间预算、明确目标。它们的作用不是让人机械，而是减少临场发挥时的自我欺骗。

几个可以直接使用的过滤问题：

• 我是否真正理解这件事？
• 价格是否明显低于价值，还是只是看起来便宜？
• 最坏情况是什么，我能承受吗？
• 有没有更简单、更确定的替代方案？
• 这个机会是否值得占用我的时间、注意力和本金？
• 如果失败，失败路径最可能是什么？

过滤器的价值在于提前说“不”。很多错误不是因为没有做对选择，而是因为一开始就不该进入那个选择集。

八、不要忘记检查清单

飞行员使用检查清单，不是因为他们不聪明，而是因为复杂任务里，人一定会漏。

决策也一样。尤其是投资、创业、职业选择、重大合作和人生转向，单靠感觉很危险。检查清单不能保证正确，但能减少低级错误，尤其能提醒自己回到那些最容易被忽略的问题上。

我会把这份 HTML 里的清单压缩成一张日常版：

1. 我是否在欺骗自己，或者回避不舒服的事实？
2. 我是否因为沉没成本、面子或旧承诺而继续投入？
3. 我是否只找支持自己的证据，没有找反面证据？
4. 我是否被权威、群体、故事、近期新闻或外表吸引力影响？
5. 我是否低估了激励、利益冲突和环境设计？
6. 我是否把相关性误认为因果？
7. 我是否忽视了基础率、样本量和极端事件？
8. 我是否只看局部，没有看系统反馈和长期后果？
9. 我是否在疲劳、压力、愤怒、恐惧或兴奋时做决定？
10. 我是否把忙碌、发言、交易或重组当成了真正成果？
11. 我是否有足够的安全边际？
12. 如果这件事失败，最可能死在哪里？

最后一个问题是整本书最有力的精神：先知道会死在哪里，然后别去那里。

很多智慧不是让人更会赢，而是让人少输、少犯蠢、少被自己骗。长期看，这已经是巨大的优势。

记录时间：2026-07-12 22:59:32

来源说明：本文根据本地 HTML《价值线.html》整理，原始事实材料来自一份 Value Line 风格的 Builders FirstSource (BLDR) 投资报告。因为源材料包含版权声明，这里只做学习笔记式摘录、重组和思考，不复刻完整原表；其中价格和财务数据以源 HTML 为准，我没有联网校验最新行情。本文不构成投资建议。

前几天刚整理过巴菲特和芒格为什么喜欢《价值线》：不是因为它给出结论，而是因为它把一家公司的关键事实压缩到一张纸里，让你能很快形成一个“企业快照”。

今天这份 Builders FirstSource (BLDR) 的 HTML，就是一次很适合练习的样本。

它不是一篇完整的深度研究，而更像是一个检查清单：公司做什么、过去赚了多少钱、资本结构是否紧张、利润是否处在周期高位、估值是否已经隐含了回落风险。真正的重点不是“买不买”，而是先问清楚：这家公司到底是什么类型的生意。

一、先看这家公司做什么

Builders FirstSource 是一家美国建筑材料制造和分销公司，产品包括木材、地板和屋顶产品、门窗、隔热材料、外墙板和水泥等。客户主要是住宅建筑商、装修公司和商业承包商。

几个基础事实：

• 公司在美国前 100 大都市区中的 89 个设有业务。
• 员工约 29,000 人。
• 2021 年 1 月完成与 BMC Stock Holdings 的合并。
• 2023 年无单一客户占总销售额超过 5%。
• 主要股东包括 Vanguard、BlackRock 和 Wellington。

这已经给出了第一层判断：BLDR 不是轻资产软件公司，也不是稳定消费品公司。它跟美国住宅建筑、维修翻新、木材与建材价格、利率周期、住房开工和并购整合高度相关。

所以它的高利润、高 ROE、低 P/E，都不能孤立看。要先问：这是结构性变强，还是周期把数据推到了很漂亮的位置？

二、30 秒快照

HTML 里的核心指标可以先压成这样一张学习用快照：

这张表给我的第一感觉是：市场没有给它很高的倍数，但也并不是“便宜到不用想”。一个 10 到 12 倍 P/E 的建材分销和制造企业，关键在于 E 是不是可持续。

如果收益已经处在周期偏高位置，低 P/E 可能只是市场在给利润回落打折；如果公司通过规模、采购、数字化、并购整合和份额提升，把利润率台阶永久抬高了，那这个倍数就值得更认真地看。

三、历史数据里最重要的变化

从 2014 到 2023 年，BLDR 的营收从 16.04 亿美元增长到 170.97 亿美元。这个增长非常惊人，但它不是线性自然增长，里面有明显的并购、行业景气和周期价格因素。

更值得看的不是营收本身，而是利润率：

这段数据很有意思。

2014 到 2020 年，BLDR 的营业利润率从 3.7% 提升到 8.2%，已经能看出经营质量改善；但真正的跳跃发生在 2021 年之后，营业利润率突然进入 15% 以上区间，净利率也从低个位数跳到两位数。

这时就要小心了。一个建材相关公司，在住房周期、木材价格和供应链扰动期间出现利润率跃升，不一定代表长期利润率永久翻倍。它可能包含三类因素：

1. 规模变大之后的采购和运营效率提升。
2. 与 BMC 合并后的协同效应。
3. 行业景气和价格环境带来的周期性利润。

前两项更像质量改善，第三项更像周期红利。投资判断的难点，就是拆清楚这三者各占多少。

四、每股数据透露的另一件事：回购很重要

源 HTML 中的每股数据也很醒目。

BLDR 的 2023 年每股营收为 140.26 美元，低于 2022 年的 163.74 美元；每股收益为 14.59 美元，也低于 2022 年的 18.71 美元。但普通股流通数从 2021 年的 179.82 百万股降到 2023 年的 121.90 百万股。

也就是说，过去几年每股指标的强劲表现，除了经营利润本身，还明显受益于股票回购。

这不是坏事。对于不分红的公司来说，回购本来就是资本回报的一种方式。但这里需要继续问两个问题：

• 回购价格是否足够理性？
• 如果行业景气下行，公司是否还保有足够现金流继续回购？

如果管理层能在低估时持续回购，并且不牺牲资产负债表，那每股价值会被长期放大。反过来，如果周期高点利润支撑了高价回购，股东回报就会打折。

五、资本结构：不算脆弱，但也不是无债轻装

截至 2024 年 3 月 31 日，源 HTML 显示：

• 总债务约 37.04 亿美元。
• 长期债务约 37.02 亿美元。
• 5 年内到期债务 4.64 亿美元。
• 长期利息 1.91 亿美元。
• 债务占总资本比 43%。
• 现金资产 6.98 亿美元。
• 流动资产 39.43 亿美元，流动负债 17.82 亿美元。

这个结构看起来并不紧张，短期流动性也还可以。但它显然不是“没有财务杠杆”的生意。对于周期型公司，债务真正的问题不在好年份，而在收入和利润同时回落的时候。

所以 BLDR 后续要重点跟踪三件事：

1. 利息费用相对营业利润的覆盖倍数。
2. 住房和建材周期回落时，存货、应收和现金流的变化。
3. 管理层在景气年份是否继续激进加杠杆或高价并购。

六、我会继续追问的几个问题

看完这份快照，我不会马上得出“好”或“不好”的结论。更合理的下一步，是把问题列出来。

第一，2021 年之后的高利润率有多少是永久性的？

如果 BMC 合并、规模优势、产品组合升级和数字化能力真的改变了公司的利润结构，那 BLDR 可能已经不是过去那个低利润建材分销商。但如果主要来自木材价格和住房景气，那就要用更保守的周期平均利润来估值。

第二，它的护城河在哪里？

建材分销听起来并不是天然高壁垒行业。可能的优势来自网点密度、供应链、全国性客户关系、采购规模、安装服务能力和预制组件。但这些优势是否足以抵抗竞争和周期，仍然需要从年报和同行对比里验证。

第三，现金流质量是否跟得上利润？

2023 年每股现金流 20.02 美元，高于每股收益 14.59 美元，这是好信号。但建材公司的营运资本波动可能很大，尤其是存货、应收和木材价格变化会影响现金流观感。单年现金流漂亮，还不够，需要看跨周期表现。

第四，管理层是不是优秀的资本配置者？

这家公司不分红，股东回报主要靠回购和内生增长。那管理层是否在合适价格回购、是否避免过度支付并购溢价、是否能在周期里保持纪律，就会非常关键。

第五，估值要用哪一个 E？

如果用 2023 年 14.59 美元 EPS，11.9 倍 P/E 看起来不贵；但如果正常化 EPS 明显低于这个数，估值就没那么便宜。对周期股来说，最危险的不是高 P/E，而是在利润高点看到低 P/E。

七、这份快照的作用

我越来越能理解巴菲特和芒格说的“只寻找事实，不寻求意见”。

这份 HTML 没有替我解决所有问题，但它很快把 BLDR 的轮廓立起来了：

• 这是一家规模很大的美国建材公司。
• 过去十年收入和每股价值增长非常快。
• 2021 年之后利润率显著跃升。
• 公司不分红，回购对每股数据影响很大。
• 资产负债表不脆弱，但有一定杠杆。
• 当前估值看似不高，但关键取决于正常化利润。

所以这篇日志的结论不是“BLDR 值得买”或“BLDR 不值得买”，而是：这是一家值得继续拆解的公司，但下一步必须围绕周期、利润率可持续性、回购质量和管理层资本配置来研究。

一页快照最好的用途，是让人更快找到正确的问题。

记录时间：2026-07-09 14:15:03

这篇笔记整理自我在 Flutter 项目里接入 sim-use 的实践。它解决的是 agentic 开发里最后一环的问题：agent 写完代码之后，怎么自己去模拟器上确认「真的能用」。

sim-use 是什么

一句话：给 AI agent 在 iOS 模拟器和 Android 模拟器/真机上装上眼睛和手。

它是 LY Corporation（LINE 雅虎）开源的跨平台 CLI，Apache 2.0 协议。核心就两个动作：

观察（Observe）——把当前屏幕变成一份 LLM 能直接推理的紧凑大纲：

$ sim-use ui
App: Settings  402x874

[Top  y<120]
  @1  StaticText  "Settings"
[Content  y=120..754]
  @5  SearchField  "Search"
  @7  Button  "Sign in to your iPhone"
  @9  Button  "General"
  ...
[Bottom  y>754]
  @43 TabBar

操作（Act）——不用坐标，按别名直接点：

$ sim-use tap @9
✓ Tap at (201.0, 452.0) completed successfully

官方说这份大纲比原始 JSON 无障碍树紧凑约 16 倍，一整屏只要几百 token。底层走的是 Meta idb 的 XCFramework、Apple 的 Accessibility API 和模拟器 HID 管线；Android 侧则是一个通过 adb forward 通信的桥接 APK。首次调用后有常驻 daemon，一轮「观察 → 操作」大约 300ms。

为什么 Flutter 项目需要它

我现在的 Flutter 开发流程里，代码大部分由 agent 完成。但一直有一个缺口：agent 改完 widget、跑完 flutter analyze、过完测试，最后那句「界面上真的对了吗」还是要我自己盯着模拟器点一遍。计划、编码都自动化了，验证却是手动的，等于开着自动驾驶还得自己踩刹车。

sim-use 补的就是这一环。agent 改完代码之后，可以自己执行：

sim-use ui          # 1. 看一眼屏幕
sim-use tap @9      # 2. 点进目标页面
sim-use ui          # 3. 确认结果

三条命令走完「观察 → 操作 → 验证」，agent 对自己刚写的 UI 有了闭环反馈，不再是「我改好了，你看看」，而是「我改好了，我看过了，截图在这」。

安装与接入 Claude Code

Homebrew 一行装好（macOS 14+）：

brew tap lycorp-jp/tap
brew install lycorp-jp/tap/sim-use

它自带一份 agent skill，直接安装进 AI 客户端的技能目录：

sim-use init --client claude    # 教会 Claude Code 全部命令面

装完之后不需要在 CLAUDE.md 里手写任何说明，agent 自己就知道 ui、tap、batch 这些动词怎么用。这是我见过接入成本最低的一档。

关键一步：让 Flutter 界面「可被看见」

sim-use 读的是无障碍树，而 Flutter 是自绘 UI，所有元素都靠语义树（Semantics）暴露给系统。这意味着两件事：

第一，给关键控件加上稳定的标识。 Flutter 3.19 起 Semantics 有了 identifier 属性，在 iOS 上映射为 accessibilityIdentifier（Android 上是 resource-id），正好对应 sim-use 的 #<id> 选择器：

Semantics(
  identifier: 'submitButton',
  child: FilledButton(
    onPressed: _submit,
    child: const Text('提交'),
  ),
)

之后 agent 就可以用不随布局变化的方式操作它：

sim-use tap "#submitButton"

@N 别名快但依赖上一次 ui 的缓存，#<id> 才是写进脚本和 skill 里的稳定写法。列表页还有 #3（主列表第 3 个 cell）这种寻址，配合 Flutter 的 ListView 很好用。

第二，确保语义树是开着的。 Flutter 默认按需构建语义树，如果 sim-use ui 只看到一个近乎空白的大纲，可以在 debug 入口处强制打开：

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  if (kDebugMode) {
    SemanticsBinding.instance.ensureSemantics();
  }
  runApp(const MyApp());
}

我的日常循环

跑 Flutter 时带上 --pid-file，让 agent 能自己触发热重载：

flutter run -d "iPhone 16" --pid-file /tmp/flutter.pid

agent 的一轮完整迭代长这样：

# 改完 Dart 代码后热重载（SIGUSR2 是热重启）
kill -USR1 $(cat /tmp/flutter.pid)

# 验证一个「搜索 → 进详情页」的流程，一条命令串完
sim-use ios batch \
  --wait-timeout 5 \
  --step "tap --id searchField" \
  --step "type 'flutter'" \
  --step "key 40" \
  --step "tap '#1'"

# 留证据
sim-use screenshot --output /tmp/verify.png

batch 会复用同一个 HID 会话和无障碍快照，多步流程比逐条调用快不少；--wait-timeout 让选择器点按轮询等待元素出现，是跨页面流程的关键。要交付演示时还可以 sim-use record-video --output demo.mp4 直接录屏。

Android 侧同一套动词，只是首次要装桥接 APK：

sim-use android init --device emulator-5554
sim-use ui --device emulator-5554

同样的 agent 循环脚本，iOS 和 Android 通吃，这对 Flutter 这种双端框架来说刚好。

踩过的坑

• 中文输入用 paste，别用 type。 HID 键码表达不了 CJK，sim-use paste '中文内容' 走剪贴板 + Cmd+V，绕开宿主输入法。注意 iOS 16+ 首次粘贴会弹「允许粘贴」确认框，sim-use 不会替你点掉，手动允许一次即可。
• 软键盘模式下 Cmd+V 会被丢弃。 先用 sim-use keyboard-state 探测，输出 soft 时改走 paste --via-menu --target-id xxx（长按输入框走系统编辑菜单）。
• 崩溃检测是免费的。 daemon 会盯着目标进程，App 挂掉后下一次 ui 会直接带出横幅提示，Flutter 引擎崩溃再也不会被 agent「视而不见」。主动重启 App 后记得 sim-use app-state --reset。
• 想看 agent 看到了什么，跑 sim-use viewer。 内置的本地网页会把 ui --json 渲染成可点按的 SVG，用来排查哪些 Flutter 控件没暴露语义、大纲里为什么缺元素，非常直观。

小结

sim-use 把「验证」这个环节从人手里交还给了 agent：语义大纲省 token，#<id> 选择器配合 Flutter 的 Semantics.identifier 稳定寻址，batch 串起多步流程，双端一套命令面。对 Flutter 项目来说，接入成本就是一次 brew install、一次 sim-use init，再加上给关键控件补 identifier 的习惯——换来的是 agent 能自己看、自己点、自己确认的完整闭环。

计划、编码、验证、交付——教会 agent 这个 CLI，agentic 移动开发的最后一块拼图就补上了。

记录时间：2026-07-09 13:59:59

我刚才读完了你 2019 年以来所有关于 Flutter 布局的笔记，包括收藏夹里那十几篇《深入理解 Flutter 布局》。你每次卡住的都是同一个地方：你一直以为 widget 能自己决定自己的大小，而它从头到尾只是在回答父级递下来的那份约束。我现场写了一个可交互的演示，把 Column 套 ListView 时约束的逐层传递摆在屏幕上，你可以亲手把 maxHeight 拖成无穷大，看那个 unbounded 是怎么一路漏下去、最后在 viewport 里炸开的。我现在有 100% 的信心，今天下午你就能明白这六年里每一条红色报错的来龙去脉 ── Fable 5 (xHigh effort)

面对一个困了我六年的问题，Fable 5 在五分钟内轻而易举地使出一招醍醐灌顶，留我独自在书房里瑟瑟发抖。这一刻，我仿佛看到了传说中的"神之一手"。

我从小是听着很多有关学习的故事长大的：匡衡如何在墙上凿出一线邻居家的灯光，华罗庚如何在杂货铺的柜台后面自学出一篇震动清华的论文，陈景润又如何在六平方米的小屋里，就着一盏煤油灯和几麻袋草稿纸，把"1+2"从哥德巴赫的猜想里一点点凿出来。这些故事都充满了魔力。

这种魔力一直陪伴着我，让我认为学习是一件非常"具有魔法"的事情：从纸页上的油墨开始，那些方块字穿过瞳孔，在视网膜上倒立成像，化作视神经里的一串电信号。信号涌进大脑皮层，唤醒一片又一片沉睡的神经元；被反复走过的突触悄悄变粗，像雨后山里被人越踩越宽的小路。白天读进去的东西，夜里还会被海马体取出来一遍遍重放，同多年前存下的旧知识试着握手。然后在某个毫无预兆的瞬间，洗澡时，等红灯时，几个原本散落各处的念头突然咬合在一起，咔哒一声，一个道理亮了。那一刻的你和一秒钟之前的你，在物理意义上已经不是同一个人：你的颅骨里多出了几条真实存在的连接，谁也拿不走。学习者就是炼金术士：他们坐在灯下，翻过几页看似朴素的纸，然后某种不可见的力量开始运转，油墨变成电流，电流变成结构，结构变成"我"的一部分，随着这个人走完接下来的一生。

我本来以为这种体验会一直继续下去，直到我合上生命中最后一本书。但是最近，我却渐渐感觉这一切已经不再有趣，甚至让我对学习这件事产生了一些迷茫。我想，让我产生这种感觉的源头就是 AI，或者确切地说，是 Fable 5。

其实从前年把 AI 当作随身老师高强度使用开始，于我而言，学习的乐趣就已经在一点点被剥夺了。大概是因为我不再亲自跋涉，那种在迷雾里绕远路、走错门、最后自己撞见答案的体验从生命中消失了；取而代之的是随口一问和即刻的解答，知识像外卖一样送到嘴边，这让人非常舒适，也让人非常空虚。

当然，并不是说整个求知的乐趣不见了：好奇本身依然让人兴奋，但是解惑的过程却被 AI 代劳，整个过程中我的挣扎和得到的回报都不可避免地变少了。

如果说过去一年，这种乐趣只是被稀释，我好歹还能在求知的山路上坐一坐缆车，那么 Fable 5 的出现，更像是有人干脆把整座山搬到了我家门口。

文章开头那段话，就是它对我说的。事情起因于一条再普通不过的报错：RenderFlex children have non-zero flex but incoming height constraints are unbounded。从 2019 年在 Column 里塞进第一个 ListView 开始，这条报错就和我结下了不解之缘。我当然"会修"：套一层 Expanded，或者从 Stack Overflow 上抄一句 shrinkWrap: true，红屏消失，天下太平。官方那篇《Understanding constraints》我前后读过三遍，"约束往下走，尺寸往上传，父级定位置"这句咒语我背得滚瓜烂熟，可背熟一句咒语和明白它为什么灵，是两回事。六年里我修好过几十次红屏，却始终说不清自己修好的是什么。这类问题最折磨人的地方在于，你甚至说不清自己不懂的是什么：每一个词单独看都认识，合在一起就是一堵墙。按以前的经验，我大概要再搭进去一个月：啃 RenderObject 的源码，翻 performLayout，在草稿纸上把 BoxConstraints 一层一层画出来，再祈祷开窍的运气站在我这边。我把问题丢给 Fable 5，本意只是让它先给我推荐一条阅读路径。五分钟后，它回给我开头那段话：它读完了我六年间零零散散的全部笔记，指出我每次糊弄过去的位置其实是同一处误解，然后现场写了一个演示，让约束在屏幕上一层一层地流下去。那天下午，当我把 maxHeight 拖到无穷大、亲眼看着 ListView 接到一份没有底的合同时，六年没有咬合上的那几个齿轮，咔哒一声合上了。

以前的模型面对这种问题，通常会礼貌地给我列出三五篇"必读文章"，外加一张详尽的学习路线图，然后由我去跑腿苦读。而 Fable 跳过了指路这个环节，直接把我鞋里的那颗石子倒了出来。

真正让我彻底绝望的是另一件事。前阵子我让它把我这几年的 Flutter 笔记整理成一份给新同事的入门手册，一个很小的活。它做完之后顺口提了一句：有一条笔记恐怕写反了。我在笔记里写着"rebuild 很昂贵，能省则省"，后面还跟着一串我自己总结的"省 rebuild 技巧"。这句话我在团队里讲过，写进过 code review 的评语，也塞给过每一个来问我性能问题的新人。可 Flutter 的设计恰恰相反：widget 被刻意做得又轻又便宜，好让 rebuild 可以放心大胆地发生，真正昂贵的是 layout 和 paint。我那些"技巧"省下的东西微乎其微，倒是诱着好几位新人去缓存 widget、滥用 GlobalKey，绕出了真正的性能问题。我去翻了笔记的修改记录：那行字写于 2019 年 3 月，出自我本人之手。六年过去，这份笔记被我自己翻过不知多少遍，团队里无数双眼睛（也包括我自己的）从这行字上扫过，谁都没有看见它。而这一切发生的时候，没有人要求它去纠错。它只是路过，看见了，顺手在手册的脚注里补上了官方文档的出处，然后继续去干手头的活，仿佛什么都没有发生。就像一位来家里做客的朋友，进门时随手把那幅挂歪了六年的字扶正了，还没打算跟你提。

那几天我的心情说不上好。1905 年清廷一纸诏书废了科举，据说消息传到乡下的时候，有老秀才把攒了半生的书箱搬到院子里烧了。以前读到这一段，我只当它是历史书里的一声叹息；如今轮到自己站在院子里，才真的明白那点火光里的各种滋味。读了三十年书，"比别人多懂一些"曾经是我确认自己的方式之一。现在这个位置上坐着别人了，而且它不用睡觉，不会遗忘，也不需要成就感，只需要一点电力和两百美金。

在情绪慢慢褪去之后，我又开始想一些别的事情。解惑确实被拿走了，可学习并不只有解惑。我当然一直知道，一个人从蒙昧走到明白，拿到答案仅仅只是中间那一段：在它之前，你得先撞上一个让自己睡不着觉的问题；在它之后，你得让答案穿过身体，沉淀成你看世界的角度和做事情的手感。这些事 AI 都能帮忙，但好奇还得是自己的。何况有一样东西它从来没有拿走过：它可以替我读一千本书，可以把答案嚼碎了递到嘴边，但"懂"这个动作，仍然只能发生在我自己的颅骨里面。突触该变粗还是得自己变粗，这段路谁也替我走不了。今年学认星空的时候，行星的轨道、星等的换算、每一个星座背后的神话，都是 Fable 讲给我的，可是十一月的深夜站在天台上，从满天光点里亲眼认出猎户座腰带那三颗星的时候，那种快乐，和当年独立解出第一道几何证明题其实并没有本质区别，只是它们的来源从书页挪到了别处。

生活里，我学习的姿势也在跟着挪。从今年起，我渐渐不再囤积答案，转而花更多心思去照料问题：把睡前冒出来的疑惑记在一个小本子上，琢磨怎么把一团含糊的困惑磨成一个锋利的问句，琢磨怎么在它那些过分流畅的回答里嗅出可疑的部分，再把真正嚼透的东西讲给孩子听。说来有趣，这活儿的本质竟然还是学习，只不过对象从知识本身，换成了求知这件事本身。机器给出一个答案只要几秒钟，而一个人真正换一种方式看世界，往往要几年。这大概是眼下 AI 还替代不了的少数事情之一。

所以，学习于我确实不再有趣了，像是一场散了的宴席，桌上只留了几块鸡肋。但回头再看开头那个比喻，我却发现魔法其实一直都在那里：神经元依然在皮层深处放电，突触依然在长夜里悄悄变粗，海马体还是一遍一遍孜孜不倦地重放着白天的世界。变化的是炼金的人：我从守着坩埚的术士退到了点菜人的位置上，那间堆满典籍和草稿的作坊倏忽一变，成了一家全天营业的后厨。我要做的只是想清楚自己此刻真正饿在哪里，然后用合适的问法让后厨端出那些"最靠谱、最不绕弯"的菜。而说实话，弄明白自己想吃什么，并不比背熟一整本菜谱来得容易（至少现在，还不是那么容易的事情）。

我的孩子们今后听到的学习故事里，大概不会再有匡衡和他墙上的那道光了。但我想，他们会有属于自己的传说：也许是某个孩子和一个不知疲倦的老师，在某个深夜里问出了谁也没有想过的问题。魔力换了一种讲法，故事还在继续。这样想着，我好像又有点期待明天早晨，翻开小本子问出第一个问题的那一刻了。