[{"content":"一开始我只是想给 Telegram bot 配一个 webhook。Cloudflare Worker 天然有 HTTPS endpoint，写一个 POST /telegram，再用 Telegram setWebhook 绑定过去，事情就结束了。\n但 Telegram 只是其中一个入口。更完整的形态应该是一个 Cloudflare-native webhook gateway：外部系统把事件打进来，Worker 验签、标准化、入库、排队，再按规则发到 Telegram、ntfy、Discord、Slack、邮件或其他 webhook。\n我不想为了这件事维护一套 n8n、Node-RED 或 Windmill。那些平台很强，但对个人博客、自动化和小型系统通知来说偏重。Cloudflare Worker 更适合做薄入口，D1、KV、Queues、Cron Triggers 补上状态、限流、重试和清理。\n最终形态 这个 gateway 最后应该长这样：\nGitHub / Cloudflare / Stripe / Uptime Kuma / RSS / Custom Form / Telegram ↓ Ingress Adapter ↓ Signature Verification + Rate Limit + Dedup ↓ Normalized Event ↓ D1 Event Store ↓ Queue Fanout ↓ Telegram / ntfy / Discord / Slack / Teams / Email / Generic Webhook 核心模型只有四个：\ninbox：一个事件入口，比如 github-build、cloudflare-alert、contact-form event：一次收到的 webhook，包含 raw payload 和标准化后的字段 channel：一个通知出口，比如 telegram-main、ntfy-phone、discord-ops route：把 inbox、条件和 channel 连接起来 这几个模型够支撑大部分个人自动化。入口负责接收事件，事件负责留下记录，通道负责发消息，路由负责决定发到哪里。实现时尽量让每一层都薄，不要把验签、格式化、投递和存储揉在一个函数里。\n输入通道 输入通道要覆盖两类：机器事件和人发命令。\n机器事件走 /hooks/:slug：\nPOST /hooks/github-build POST /hooks/cloudflare-alert POST /hooks/contact-form POST /hooks/uptime POST /hooks/payment POST /hooks/custom 每个 slug 对应一个 inbox。inbox 里配置验签方式、payload 解析器、默认等级、路由规则和保留时间。\nTelegram 走单独入口：\nPOST /telegram 这个入口接 Telegram bot update。它不只是 echo 消息，而是 gateway 的管理入口。比如：\n/status 查看 gateway 状态 /recent errors 看最近失败事件 /retry \u0026lt;event_id\u0026gt; 重发某个事件 /mute github-build 1h 临时静音某个 inbox /test telegram-main 测试某个 channel /routes 查看当前路由 这样 Telegram 既是通知通道，也是轻量运维界面。个人项目里，这比再做一个 Web UI 更实用。\n输出通道 输出通道不要写死在业务逻辑里，应该做成 adapter。\nchannels/ telegram.ts ntfy.ts discord.ts slack.ts teams.ts email.ts webhook.ts 每个 adapter 做同一件事：把内部事件转成目标通道需要的请求。\nNormalizedEvent + ChannelConfig → method / url / headers / body Telegram 适合主通知和交互，ntfy 适合轻量 push，Discord/Slack/Teams 适合团队频道，email 适合需要留档的通知，generic webhook 适合接下游系统。\ngeneric webhook output 要谨慎。它允许系统向任意 URL 发请求，必须做 SSRF 防护，不能请求 localhost、内网 IP、link-local 地址和云厂商 metadata endpoint。\n事件格式 内部事件格式要稳定。入口可以越来越多，但系统内部只认一种事件。\ntype NormalizedEvent = { id: string inbox: string source: string title: string body: string level: \u0026#39;info\u0026#39; | \u0026#39;warning\u0026#39; | \u0026#39;error\u0026#39; | \u0026#39;critical\u0026#39; status: \u0026#39;received\u0026#39; | \u0026#39;queued\u0026#39; | \u0026#39;delivered\u0026#39; | \u0026#39;failed\u0026#39; url?: string fingerprint?: string rawPayloadRef?: string receivedAt: string } fingerprint 用来去重。GitHub workflow、Cloudflare alert、Uptime Kuma outage 这类事件经常会重试，没有去重就容易刷屏。\nrawPayloadRef 可以为空。如果 payload 很大，再把原始数据放到 R2，D1 只存引用。多数个人场景直接把裁剪后的 raw JSON 存 D1 就够了。\n数据模型 D1 负责存配置和事件历史。\ninboxes id slug name source_type verification_type secret_ref retention_days enabled channels id name type config_json enabled routes id inbox_id channel_id level_filter keyword_filter enabled events id inbox_id source title body level status fingerprint raw_payload received_at delivery_attempts id event_id channel_id status status_code error_message attempted_at 这几张表够用了。事件出了问题，可以查它有没有进来、进来后有没有入队、发到了哪些 channel、失败原因是什么。\n队列和重试 Webhook 入口不能被下游通知服务拖住。入口收到事件后应该完成这几件事：验签、限流、去重、标准化、入库、投递到 Queue，然后返回。\n真正的发送放到 Queue consumer 里：\nQueue message → load event → match routes → dispatch channels → write delivery_attempts → retry or dead letter 重试要按通道记录。Telegram 失败不应该影响 ntfy，Slack 失败不应该让整个事件变成未知状态。\n需要一个 dead-letter queue。重试多次仍失败的消息进 DLQ，再发一条高优先级 Telegram 通知：哪个 event、哪个 channel、失败了几次、最后一次错误是什么。\n路由规则 route 不要做成复杂规则引擎，但要有几个基本条件：\n按 inbox 路由 按 level 路由 按关键字路由 按时间窗口静音 按 channel enabled 状态过滤 比如：\ngithub-build + error → Telegram + ntfy cloudflare-alert + warning → Telegram contact-form → Telegram + email uptime + critical → Telegram + ntfy + Discord 这里最容易过度设计。不要急着做表达式语言，也不要做可视化 workflow。D1 里的几列配置足够覆盖大部分个人自动化。\n安全边界 这个系统是公开入口，安全边界比功能更重要。\n每个输入通道都要有自己的校验方式：\nTelegram：X-Telegram-Bot-Api-Secret-Token GitHub：X-Hub-Signature-256 Stripe：Stripe-Signature Custom webhook：X-Webhook-Secret Contact form：Turnstile + rate limit Cloudflare notification：独立 secret 不要所有入口共用一个 secret。泄露一个，不应该拖垮全部入口。\n敏感配置只能放 Cloudflare secrets 或 D1 加密字段里，API 返回时必须 redaction：\n123456789:AA...redacted https://hooks.slack.com/services/...redacted re_...redacted Telegram 消息如果使用 parse_mode: HTML，用户输入必须 escape。表单字段、GitHub commit message、外部 webhook body 都不能直接拼进 HTML。\n公开 inbox 要做 payload size limit。过大的 payload 直接拒绝，或者写入 R2 后只保留引用。否则一个公开 webhook 很容易被打成日志和存储垃圾桶。\n限流和去重 KV 很适合做短期状态。\nrate_limit:{inbox}:{ip} dedup:{inbox}:{fingerprint} mute:{inbox} 限流按 inbox 和 IP 做，contact form 这种公开入口还要叠 Turnstile。去重按 fingerprint 做，TTL 可以设成几分钟到几小时。\nTelegram 管理命令也要限制 user id。只有白名单用户可以执行 /retry、/mute、/routes 这类命令。\nconst allowedUserIds = new Set([123456789]) 不要只依赖“没人知道 bot 名字”。\n观测和运维 最终版本至少要有这些接口：\nGET /health GET /v1/events?inbox=\u0026amp;status=\u0026amp;level= GET /v1/events/:id POST /v1/events/:id/retry GET /v1/channels POST /v1/channels/:id/test GET /v1/routes PATCH /v1/routes/:id 这些接口用 X-API-Key 保护。最终版本里，API key 应该带 scopes，比如 events:read、events:retry、channels:write、routes:write 和 admin。\nTelegram bot 里也要有对应的轻量命令。平时我不会打开后台看 dashboard，但 Telegram 收到失败通知后，可以直接 /retry \u0026lt;event_id\u0026gt;，这才是个人工具的舒服形态。\nCloudflare 组件怎么用 最终版本会用到这些 Cloudflare 组件：\n组件 用途 Workers HTTP 入口、Telegram bot、API、Queue consumer D1 inbox、channel、route、event、delivery attempt KV 限流、去重、静音状态、短期缓存 Queues 多通道 fanout、失败重试、DLQ Cron Triggers 清理过期事件、发送每日摘要、检查死信队列 R2 大 payload、附件、长期原始事件，可选 Turnstile 公开表单入口防 bot，可选 这套东西仍然是 Cloudflare-native，不需要 VPS，也不用维护常驻进程。\n配置方式 我更倾向把敏感值放 secret，把动态配置放 D1。\nCloudflare secrets：\nADMIN_API_KEY TELEGRAM_BOT_TOKEN TELEGRAM_WEBHOOK_SECRET GITHUB_WEBHOOK_SECRET STRIPE_WEBHOOK_SECRET NTFY_TOKEN RESEND_API_KEY D1 里存 channel config，但 API 读取时做脱敏。\n{ \u0026#34;name\u0026#34;: \u0026#34;telegram-main\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;telegram\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;chat_id\u0026#34;: \u0026#34;123456789\u0026#34;, \u0026#34;parse_mode\u0026#34;: \u0026#34;plain\u0026#34; } } Telegram bot token 不应该出现在 D1 config 里。所有 Telegram channel 共用 Worker secret 里的 TELEGRAM_BOT_TOKEN，channel 只存 chat id 和格式化偏好。\n最后 这不是一个 Telegram bot 教程，也不是一个 n8n 替代品。它更像一个放在 Cloudflare 边缘上的个人事件总线。\n最后版本应该具备这些能力：\n多入口：Telegram、GitHub、Cloudflare、Stripe、Uptime、表单、自定义 webhook 多出口：Telegram、ntfy、Discord、Slack、Teams、email、generic webhook 事件历史：D1 存 event 和 delivery attempts 可靠投递：Queue fanout、按通道重试、dead-letter queue 安全边界：独立验签、限流、去重、SSRF 防护、secret redaction 管理入口：HTTP API + Telegram bot commands 运维能力：health check、失败查询、重发、静音、每日摘要 这才是我想要的形态：不用维护服务器，不依赖重型 workflow 平台，又能把个人系统里的事件统一。Telegram 是入口和控制台，ntfy 是备用推送，D1 留下历史，Queue 保证投递，Cron 负责清理和摘要。复杂度没有消失，但都落在 Cloudflare 已经提供的组件里。\n","permalink":"http://foxden.vault2049.xyz/tech/cloudflare-worker-telegram-bot-webhook/","summary":"\u003cp\u003e一开始我只是想给 Telegram bot 配一个 webhook。Cloudflare Worker 天然有 HTTPS endpoint，写一个 \u003ccode\u003ePOST /telegram\u003c/code\u003e，再用 Telegram \u003ccode\u003esetWebhook\u003c/code\u003e 绑定过去，事情就结束了。\u003c/p\u003e\n\u003cp\u003e但 Telegram 只是其中一个入口。更完整的形态应该是一个 Cloudflare-native webhook gateway：外部系统把事件打进来，Worker 验签、标准化、入库、排队，再按规则发到 Telegram、ntfy、Discord、Slack、邮件或其他 webhook。\u003c/p\u003e\n\u003cp\u003e我不想为了这件事维护一套 n8n、Node-RED 或 Windmill。那些平台很强，但对个人博客、自动化和小型系统通知来说偏重。Cloudflare Worker 更适合做薄入口，D1、KV、Queues、Cron Triggers 补上状态、限流、重试和清理。\u003c/p\u003e\n\u003ch2 id=\"最终形态\"\u003e最终形态\u003c/h2\u003e\n\u003cp\u003e这个 gateway 最后应该长这样：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eGitHub / Cloudflare / Stripe / Uptime Kuma / RSS / Custom Form / Telegram\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eIngress Adapter\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eSignature Verification + Rate Limit + Dedup\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eNormalized Event\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eD1 Event Store\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eQueue Fanout\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTelegram / ntfy / Discord / Slack / Teams / Email / Generic Webhook\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e核心模型只有四个：\u003c/p\u003e","title":"用 Cloudflare Worker 搭一个轻量 Webhook Gateway"},{"content":"很多企业现在已经过了“要不要用 AI”的阶段，真正的问题变成了：怎么让 AI 从一个局部工具，变成组织持续复利的一部分。\nAnthropic 这份《Building AI agents for the enterprise》讲的核心不是某个产品功能，而是企业落地 AI agents 时的一条分水岭：\n一边是把 AI 当成聊天框。员工问一句，它答一句；某个团队做一个 demo，短期看起来很酷，但很难进入真实生产流程。\n另一边是把 AI 当成可以理解上下文、调用工具、执行多步骤任务的工作系统。它不只是回答问题，而是能参与员工工作、流程自动化和产品能力建设。\n这篇文章我会从技术落地视角拆一下：企业为什么需要 agents，应该先改什么，怎么设计试点，以及哪些坑最容易让 AI 项目停在 demo 阶段。\n1. Chatbot 和 Agent 的差别，不是界面，而是责任边界 很多企业的第一步都是上一个 chatbot：接 FAQ、查文档、总结会议、写邮件。\n这当然有价值，但 chatbot 的工作方式通常是单轮的：用户提出问题，模型返回答案。它不负责拆解任务，也不负责调用系统，更不负责把结果落到某个业务流程里。\nAgent 的边界更大。它需要能做几件事：\n理解目标，而不是只理解一句 prompt 拆成多个步骤 在步骤之间保留状态 调用内部工具和数据源 根据中间结果调整路径 产出可以交付、审计、复用的结果 比如销售场景里，一个 chatbot 可以回答“这家公司是做什么的”。一个 agent 应该能从 CRM、会议记录、历史邮件、竞品库里拉数据，生成一份客户拜访 briefing，并标出风险、机会和下一步建议。\n这就是差别。chatbot 是问答界面，agent 是工作流执行层。\n2. 企业 AI 的第一件事：给模型组织上下文 通用模型默认不知道你的公司怎么工作。\n它不知道销售团队怎么定义有效商机，不知道法务团队对合同条款的风险分级，不知道财务团队的科目口径，不知道市场团队的品牌语气。没有这些上下文，AI 只能产出“看起来还行”的通用内容，最后仍然需要人重新改一遍。\n企业真正的效率来自把组织知识编码进去：\n组织标准 ├─ 术语表 ├─ 品牌语气 ├─ 合规要求 ├─ 审批流程 ├─ 报表口径 ├─ 风险框架 └─ 工具连接方式 这个动作比选模型更重要。两个团队用同一个模型，结果差异可能非常大，原因不是模型能力不同，而是上下文质量不同。\nAnthropic 文档里举了几个典型例子：\n销售团队连接 CRM、会议记录和客户研究工具，自动生成 call prep 财务团队连接数据仓库，按公司口径生成 reconciliation report 法务团队按内部风险框架审合同，标出偏离标准条款的部分 市场团队按品牌规范生成 campaign brief，并拉取历史表现数据 这些场景的共同点是：AI 没有被当成一个孤立工具，而是被放进了组织已有的知识、数据和流程里。\n3. 从员工、流程、产品三个层面看落地路径 企业做 AI agents，不能只盯着“节省多少工时”。更好的拆法是看三层：员工、流程、产品。\n员工：让专家能力扩散 第一层是让员工变强。\n这里的重点不是让 AI 替代专业判断，而是把重复、密集、低杠杆的信息处理交给 AI。财务分析师少花时间从多个系统拉数据，多花时间解释数据背后的含义；市场同学少花时间重做竞品分析，多花时间判断定位和策略。\n最好的信号是：非技术员工不需要理解底层系统，也能完成过去必须依赖专家或数据团队的工作。\nL\u0026rsquo;Oreal 的案例很典型。他们搭了一个基于 Claude 的内部多 agent 平台，让员工用自然语言查询数据，再由系统路由到 15 个以上的专门 agent，生成答案和可视化。结果是每月 44,000 用户、每天 15,000 活跃用户， conversational analytics 准确率达到 99.9%。\n这里真正被产品化的不是“聊天”，而是数据团队过去积累的查询能力、指标理解和业务解释能力。\n流程：把专家复核变成系统反馈 第二层是流程加速。\n企业流程通常慢，不是因为人不努力，而是因为信息量大、责任重、容错率低。监管文件、合同审查、客户支持、临床研究报告，都是典型场景。\nAI 进入这些流程后，关键不是“一次生成完美结果”，而是让专家复核可以反哺系统。每一次专家修正、批准、拒绝，都应该成为下一次执行的上下文。\n这样系统才有复利：\n第一次执行：AI 生成初稿，人类大量修改 第二次执行：AI 复用批准模板和修正记录，人类少改一点 第 N 次执行：AI 已经吸收大部分组织标准，人类主要做判断 Lyft 的客户支持案例就是这个方向。他们用 Claude 做 support assistant，让系统根据客户具体情况调查和处理问题，必要时再把 AI 生成的摘要交给人工客服。结果是支持解决时间降低超过 87%，决策准确率提升超过 30%。\n这个数字背后的关键不是“回复更快”，而是 agent 能进入支持流程，查上下文、判断情况、把复杂 case 路由给人。\n产品：把 AI 变成新的能力层 第三层是产品转型。\n这一步和前两层不一样。员工和流程更多是降本增效，产品层则可能带来新收入、新市场和新的切换成本。\n企业在这里的优势不是“我也接了一个模型 API”，而是组合能力：\n自有数据 客户信任 领域知识 合规能力 现有系统集成 分发渠道 AI 是能力放大器，壁垒来自 AI 周围的东西。\nRakuten 的案例很有代表性。他们有 70 多个业务，一开始自己搭 agentic infrastructure，包括持久计算、记忆和存储。后来采用 Claude Managed Agents，把执行层交出去，让工程资源回到差异化体验上。结果是专门 agent 可以在一周内上线，重大产品发布从每季度一次变成每两周一次，pilot 中关键错误下降 97%。\n这里有个很重要的工程判断：不是所有底层能力都值得自己维护。如果 agent 执行层消耗了大量工程时间，产品团队可能还没做出差异化体验，就先被基础设施拖慢。\n4. 信任边界决定 AI 产品能不能上线 企业 AI 项目最容易低估的一件事，是信任边界。\n在金融、医疗、法务这类场景里，问题通常不是“模型能不能做”，而是“数据能不能这样流动”。客户数据能不能离开安全边界，谁可以访问，日志怎么审计，合规团队能不能复盘，这些问题决定产品能不能上线。\n很多 AI demo 看起来很好，但一进入安全审查就卡住。原因是架构一开始没有把信任边界当成第一约束。\n更合理的顺序应该是：\n先定义信任边界 再定义可访问数据 再定义工具权限 再设计 agent 工作流 最后优化体验和效率 如果反过来，先做一个功能完整的 demo，再补权限、审计和数据隔离，通常会很痛苦。\n这也是企业 agent 和个人效率工具最大的差异。个人工具可以追求灵活，企业 agent 必须默认可治理、可审计、可撤销。\n5. Plugins 和 Skills 的本质：把最佳实践产品化 Anthropic 在文档里提到 Claude Cowork、plugins、skills 和 MCP。把产品名放一边，背后的模式更值得关注。\n企业需要一种机制，把某个团队的工作方法打包成可复用能力。\n一个法律团队的 plugin 不只是连上合同库，它应该包含：\n合同模板 风险条款清单 审批路径 常见让步策略 内部术语 输出格式 可调用工具 一个销售团队的 plugin 也不只是连上 CRM，它应该包含销售阶段定义、客户分层规则、竞品资料、call prep 模板和后续跟进标准。\n这类配置一旦可复用，组织知识就不再只存在于资深员工脑子里。新员工、跨区域团队、相邻职能都可以直接继承同一套实践。\n从工程角度看，plugins 和 skills 解决的是“组织知识的部署问题”：\n隐性经验 → 显性流程 → 可执行工作流 → 可复用组织能力 如果没有这层封装，每个团队都会各自写 prompt、各自接工具、各自调流程，最后形成新的 shadow AI sprawl。\n6. 一个更稳的企业试点框架 企业 AI 试点不要一开始就追求全公司铺开。更稳的方式是选一个高痛点、可衡量、上下文明确的场景。\n第一阶段：定义成功标准 先找 2 到 3 个团队，每个团队只选一个具体流程。\n不要写“提升生产力”这种目标，要写能验收的指标：\n销售 call prep 时间减少 50% 合同初审从 5 天缩短到 1 天 文档初稿质量达到最终稿的 80% 客服解决时间降低 60% 数据分析请求从提交工单变成自然语言自助查询 指标越具体，试点越不容易变成主观争论。\n第二阶段：做 champion pilot 第二阶段让 2 到 3 个 champion team 在真实生产流程里使用，而不是 sandbox demo。\n这里要同时看两类数据：\n定量指标：使用频率、节省时间、错误率、返工次数、处理周期 定性反馈：员工在哪些场景觉得“这东西真的懂我”，又在哪些场景觉得不可信 很多有价值的发现来自定性反馈。比如用户不一定说“节省了 30 分钟”，但会说“我现在敢直接拿它生成的第一版去开会”。这往往比单纯节省时间更说明问题。\n第三阶段：把能力治理起来 试点成功后再扩展到更多团队。\n这一步要补齐治理层：\nplugin marketplace 权限控制 审批流程 使用日志 成本控制 输出审计 数据访问边界 版本管理 治理不是大公司病，而是规模化前提。没有治理，AI 工具会像 SaaS 一样在组织里野蛮生长：每个团队都有自己的工具、prompt、账号和数据出口，最后安全、成本和标准全部失控。\n7. 技术团队应该优先建设什么 如果从技术团队视角落地，我会把优先级排成这样：\n第一，连接真实系统 Agent 不能只读静态文档。它要能连接 CRM、数据仓库、工单系统、文档库、审批系统和内部搜索。\n没有工具调用，agent 只能猜。有了工具调用，它才可能基于实时数据工作。\n第二，做最小权限 每个 agent 只拿完成任务所需的权限。能只读就不要写，能读单个系统就不要读全域数据，能人工确认就不要自动执行高风险动作。\n权限设计要比 prompt 设计更早。\n第三，沉淀可复用上下文 不要让每个用户从零写 prompt。把高频任务的上下文、模板、检查清单和输出格式固化到 skills 或 plugins 里。\n这一步决定了 agent 是个人技巧，还是组织能力。\n第四，建立评估集 没有 eval，企业 AI 项目很难持续改进。\n评估集可以从真实历史任务里来：合同样本、客服 case、销售 briefing、数据查询问题、报告初稿。每次更新模型、工具或 prompt，都跑一遍评估。\n第五，让人类反馈回流 专家的修改不应该只停在文档里。哪些地方被改、为什么改、什么输出被批准，都应该能进入知识库或评估流程。\n这才是复利的来源。\n8. 最容易失败的几种做法 第一种失败，是从“全公司 AI 战略”开始，而不是从一个具体流程开始。战略太大，指标太虚，最后没人能说清楚到底成没成功。\n第二种失败，是只做聊天入口，不接内部系统。这样 AI 永远停留在写作助手层面，无法进入真实流程。\n第三种失败，是忽视治理。早期为了快，随便接数据、随便给权限、没有审计，后期一进入合规和安全评审就推倒重来。\n第四种失败，是把专家从流程里拿掉。企业 agent 最好的状态不是无人驾驶，而是让专家从重复劳动里解放出来，集中处理判断、例外和责任。\n第五种失败，是不做复用。每个团队都自己摸索 prompt，短期看很自由，长期看会制造新的知识孤岛。\n结语 企业 AI agents 的落地，本质上不是“买一个更聪明的聊天机器人”。\n它更像一次组织操作系统升级：把上下文、工具、权限、流程、评估和治理放在一起，让 AI 真正进入工作方式，而不是停在演示窗口里。\n最好的起点不需要很大。选一个痛点清楚、指标明确、数据可访问、专家愿意参与的流程，把它做深。只要这个流程能把组织知识沉淀下来，第二个流程就会更快，第三个流程会更稳。\nAI 的复利不是来自一次惊艳 demo，而是来自每一次被编码、复用和改进的组织经验。\n","permalink":"http://foxden.vault2049.xyz/tech/enterprise-ai-agents/","summary":"\u003cp\u003e很多企业现在已经过了“要不要用 AI”的阶段，真正的问题变成了：怎么让 AI 从一个局部工具，变成组织持续复利的一部分。\u003c/p\u003e\n\u003cp\u003eAnthropic 这份《Building AI agents for the enterprise》讲的核心不是某个产品功能，而是企业落地 AI agents 时的一条分水岭：\u003c/p\u003e\n\u003cp\u003e一边是把 AI 当成聊天框。员工问一句，它答一句；某个团队做一个 demo，短期看起来很酷，但很难进入真实生产流程。\u003c/p\u003e\n\u003cp\u003e另一边是把 AI 当成可以理解上下文、调用工具、执行多步骤任务的工作系统。它不只是回答问题，而是能参与员工工作、流程自动化和产品能力建设。\u003c/p\u003e\n\u003cp\u003e这篇文章我会从技术落地视角拆一下：企业为什么需要 agents，应该先改什么，怎么设计试点，以及哪些坑最容易让 AI 项目停在 demo 阶段。\u003c/p\u003e\n\u003ch2 id=\"1-chatbot-和-agent-的差别不是界面而是责任边界\"\u003e1. Chatbot 和 Agent 的差别，不是界面，而是责任边界\u003c/h2\u003e\n\u003cp\u003e很多企业的第一步都是上一个 chatbot：接 FAQ、查文档、总结会议、写邮件。\u003c/p\u003e\n\u003cp\u003e这当然有价值，但 chatbot 的工作方式通常是单轮的：用户提出问题，模型返回答案。它不负责拆解任务，也不负责调用系统，更不负责把结果落到某个业务流程里。\u003c/p\u003e\n\u003cp\u003eAgent 的边界更大。它需要能做几件事：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e理解目标，而不是只理解一句 prompt\u003c/li\u003e\n\u003cli\u003e拆成多个步骤\u003c/li\u003e\n\u003cli\u003e在步骤之间保留状态\u003c/li\u003e\n\u003cli\u003e调用内部工具和数据源\u003c/li\u003e\n\u003cli\u003e根据中间结果调整路径\u003c/li\u003e\n\u003cli\u003e产出可以交付、审计、复用的结果\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e比如销售场景里，一个 chatbot 可以回答“这家公司是做什么的”。一个 agent 应该能从 CRM、会议记录、历史邮件、竞品库里拉数据，生成一份客户拜访 briefing，并标出风险、机会和下一步建议。\u003c/p\u003e\n\u003cp\u003e这就是差别。chatbot 是问答界面，agent 是工作流执行层。\u003c/p\u003e\n\u003ch2 id=\"2-企业-ai-的第一件事给模型组织上下文\"\u003e2. 企业 AI 的第一件事：给模型组织上下文\u003c/h2\u003e\n\u003cp\u003e通用模型默认不知道你的公司怎么工作。\u003c/p\u003e\n\u003cp\u003e它不知道销售团队怎么定义有效商机，不知道法务团队对合同条款的风险分级，不知道财务团队的科目口径，不知道市场团队的品牌语气。没有这些上下文，AI 只能产出“看起来还行”的通用内容，最后仍然需要人重新改一遍。\u003c/p\u003e\n\u003cp\u003e企业真正的效率来自把组织知识编码进去：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e组织标准\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 术语表\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 品牌语气\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 合规要求\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 审批流程\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 报表口径\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ├─ 风险框架\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  └─ 工具连接方式\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e这个动作比选模型更重要。两个团队用同一个模型，结果差异可能非常大，原因不是模型能力不同，而是上下文质量不同。\u003c/p\u003e","title":"企业 AI Agents 落地指南：从试点到组织能力"},{"content":"Anthropic 最近发了一篇 The Founder\u0026rsquo;s Playbook，讲 AI-native startup 怎么从想法走到规模化。\n它最有意思的地方，不是说创业者现在可以少招几个人，也不是说 Claude Code 能帮你写一个 MVP。更关键的是，AI 把 founder 的工作重心往前推了一层：过去很多事要亲手做，现在更像是在设计一套能被 AI 放大的工作流。\n这不代表 founder 可以退到后面，当一个发号施令的人。恰好相反，判断力变得更贵了。你要知道什么问题值得验证，什么产品应该砍掉，什么用户反馈是真的，什么增长只是新鲜感。\n如果把创业拆成四个阶段，Idea、MVP、Launch、Scale，每一阶段都有一件不能外包给 AI 的事。\n1. Idea：先验证问题，不要先写产品 很多早期项目死得很快，不是因为产品做不出来，而是因为一开始就验证错了东西。\n有了 AI 以后，写 landing page、生成竞品分析、画用户画像、起草 pitch deck 都变得很快。快本身是好事，但它也会让人更容易跳过最难受的部分：直接去问真实客户，这个问题到底痛不痛。\nIdea 阶段最该验证的不是“这个点子听起来酷不酷”，而是三件事：\n谁现在真的有这个问题； 他们今天怎么解决； 他们有没有强到愿意付钱或换流程的动机。 Claude 在这里很适合做准备工作。比如把一个行业拆成不同客户群，整理常见竞品，生成访谈问题，帮你把十几段访谈记录归类。它能让你更快进入客户语境，不用从空白页开始。\n但它不能替你判断客户有没有撒谎。\n很多人在访谈里会说“这个很有意思”“如果有我会用”，这些话听起来像正反馈，实际含金量很低。更有用的问题往往是：你上次什么时候遇到这个问题？当时花了多少钱或多少时间？如果明天就有一个解决方案，你愿意从哪个预算里付？\nIdea 阶段可以用 AI 加速研究，但不要用 AI 代替现实摩擦。没有客户证据的漂亮总结，只是更好看的幻觉。\n2. MVP：能交付，但不要变成一次性代码堆 AI 对 MVP 的影响最直接。过去一个非技术 founder 可能要先找技术合伙人，或者花钱外包一个粗糙版本。现在用 Claude Code、Cursor、Replit 这类工具，很多人可以自己把第一版产品搭出来。\n这件事很重要，因为它降低了试错成本。你不必一开始就组一个完整团队，也不必在还没验证需求时烧掉太多钱。\n但 MVP 能跑，不等于它能继续长。\nAI 写代码最容易带来的问题是：你一开始速度很快，后面越来越慢。功能堆上去了，文件越来越长，状态散在各处，错误处理靠运气，测试没有补，安全边界也没想清楚。到某个节点，你会发现产品不是不能继续写，而是每改一处都担心炸掉另一处。\n所以 MVP 阶段的重点不是追求架构完美，而是保留几个基本约束：\nscope 要小，只做验证核心假设需要的功能； 数据模型要清楚，不要为了赶进度乱塞字段； 登录、支付、权限、用户数据这些边界要认真处理； 关键路径要有测试，至少保证主要流程不会随手改坏； 让 AI 每次改动都解释涉及哪些文件、怎么验证。 如果用 Claude Code 做 MVP，我会先让它生成一个很短的实现计划，再开始写代码。计划里只要写清楚三件事：改哪些文件、先做哪个最小切片、最后跑什么命令验证。\n这一步看起来慢，其实是在防止 MVP 变成一次性项目。早期产品可以粗糙，但不能混乱到自己都接不住。\n3. Launch：区分新鲜感和真实需求 产品上线以后，最危险的不是没人看，而是有一点热闹就误以为自己找到了 PMF。\nAI 产品尤其容易遇到这个问题。用户会因为新鲜感来试，会因为截图好玩转发，会因为“这个东西居然能做”而给你一堆正反馈。但这些信号不一定能变成留存、付费和稳定使用。\nLaunch 阶段要提前定义什么叫有效 traction。\n比如：\n用户是否在没有提醒的情况下回来； 是否有人愿意付费，而不是只愿意试用； 用户是否把它接进自己的固定流程； 是否有人在你没要求时主动推荐； 关键功能是否被反复使用，而不是只被体验一次。 Claude 在这个阶段可以帮很多忙。它可以整理用户反馈，归类 bug 和 feature request，分析访谈记录，起草 onboarding 文案，生成不同版本的 landing page，也可以帮你把用户行为数据整理成每周报告。\n但 founder 要自己决定看哪些指标。\n如果你只看注册数，可能会被一次传播骗到；只看访问量，可能会忽略用户其实没有完成核心动作；只看收入，早期又可能因为样本太小而误判。Launch 阶段最该盯的是用户行为有没有形成重复。\n一个产品第一次被使用，说明它有吸引力。第二次、第三次被主动使用，才说明它可能真的进入了某个工作流。\n4. Scale：把 founder 的重复劳动系统化 很多早期团队一提 scale，就想到招人。招销售、招运营、招客服、招工程师，把 founder 手里的活分出去。\n但 AI-native startup 更适合先问另一个问题：哪些事情不是非得加人，而是应该先变成流程？\n早期 founder 会重复做很多事：回复客户问题，整理销售线索，手动看数据，写周报，跟进试用用户，检查订单异常，给投资人更新进展。这些事短期看都不大，但加起来会吃掉大量注意力。\nScale 阶段的重点，是把这些重复动作拆成半自动系统。\n比如：\n每天自动汇总用户反馈，按紧急度分类； 把销售通话记录整理成 CRM 更新和 next step； 每周生成一份产品指标变化说明； 客服先由 AI 起草回复，人再审核敏感问题； 对异常订单、退款、投诉做自动标记； 把 founder 常写的投资人 update 做成固定模板。 这些流程不一定一开始就全自动。很多时候，人审一遍反而更稳。关键是 founder 不再从零开始处理每一件事，而是让 AI 先完成收集、归类、起草、检查，再把需要判断的部分交回来。\n这和单纯“提高效率”不太一样。它改变的是组织形态。过去一个早期团队需要靠人数堆执行，现在可以先靠流程放大少数人的判断。\n当然，不能自动化的部分也很清楚：战略取舍、重要客户关系、价值观冲突、融资节奏、产品方向。这些事如果交给 AI，通常不是省时间，而是在逃避责任。\n5. Founder 的工作变了，但没有变轻 AI-native startup 容易给人一种错觉：创业会变简单。\n实际更像是门槛下降了，竞争密度上升了。以前做不出来的人，现在能做出来；以前要一个团队才能试的方向，现在一个人也能试。结果是同一个想法会被更多人更快做出来，差异不再只来自执行速度。\nFounder 真正要练的，是把模糊问题变成可验证任务的能力。\nIdea 阶段，你要把直觉变成客户问题；MVP 阶段，你要把客户问题变成最小产品；Launch 阶段，你要把市场反馈变成可判断的指标；Scale 阶段，你要把重复劳动变成流程。\nAI 可以帮你写、查、画、算、整理、生成，但它不知道你愿意承担什么风险，也不知道你到底要服务哪一类人。它能把执行半径放大，不能替你决定往哪走。\n对创业者来说，AI 最好的用法不是把自己从公司里拿掉，而是把自己从重复劳动里拿出来，留在那些必须由人负责的地方：判断、取舍、承诺和承担后果。\n","permalink":"http://foxden.vault2049.xyz/life/ai-native-startup-playbook/","summary":"\u003cp\u003eAnthropic 最近发了一篇 The Founder\u0026rsquo;s Playbook，讲 AI-native startup 怎么从想法走到规模化。\u003c/p\u003e\n\u003cp\u003e它最有意思的地方，不是说创业者现在可以少招几个人，也不是说 Claude Code 能帮你写一个 MVP。更关键的是，AI 把 founder 的工作重心往前推了一层：过去很多事要亲手做，现在更像是在设计一套能被 AI 放大的工作流。\u003c/p\u003e\n\u003cp\u003e这不代表 founder 可以退到后面，当一个发号施令的人。恰好相反，判断力变得更贵了。你要知道什么问题值得验证，什么产品应该砍掉，什么用户反馈是真的，什么增长只是新鲜感。\u003c/p\u003e\n\u003cp\u003e如果把创业拆成四个阶段，Idea、MVP、Launch、Scale，每一阶段都有一件不能外包给 AI 的事。\u003c/p\u003e\n\u003ch2 id=\"1-idea先验证问题不要先写产品\"\u003e1. Idea：先验证问题，不要先写产品\u003c/h2\u003e\n\u003cp\u003e很多早期项目死得很快，不是因为产品做不出来，而是因为一开始就验证错了东西。\u003c/p\u003e\n\u003cp\u003e有了 AI 以后，写 landing page、生成竞品分析、画用户画像、起草 pitch deck 都变得很快。快本身是好事，但它也会让人更容易跳过最难受的部分：直接去问真实客户，这个问题到底痛不痛。\u003c/p\u003e\n\u003cp\u003eIdea 阶段最该验证的不是“这个点子听起来酷不酷”，而是三件事：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e谁现在真的有这个问题；\u003c/li\u003e\n\u003cli\u003e他们今天怎么解决；\u003c/li\u003e\n\u003cli\u003e他们有没有强到愿意付钱或换流程的动机。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eClaude 在这里很适合做准备工作。比如把一个行业拆成不同客户群，整理常见竞品，生成访谈问题，帮你把十几段访谈记录归类。它能让你更快进入客户语境，不用从空白页开始。\u003c/p\u003e\n\u003cp\u003e但它不能替你判断客户有没有撒谎。\u003c/p\u003e\n\u003cp\u003e很多人在访谈里会说“这个很有意思”“如果有我会用”，这些话听起来像正反馈，实际含金量很低。更有用的问题往往是：你上次什么时候遇到这个问题？当时花了多少钱或多少时间？如果明天就有一个解决方案，你愿意从哪个预算里付？\u003c/p\u003e\n\u003cp\u003eIdea 阶段可以用 AI 加速研究，但不要用 AI 代替现实摩擦。没有客户证据的漂亮总结，只是更好看的幻觉。\u003c/p\u003e\n\u003ch2 id=\"2-mvp能交付但不要变成一次性代码堆\"\u003e2. MVP：能交付，但不要变成一次性代码堆\u003c/h2\u003e\n\u003cp\u003eAI 对 MVP 的影响最直接。过去一个非技术 founder 可能要先找技术合伙人，或者花钱外包一个粗糙版本。现在用 Claude Code、Cursor、Replit 这类工具，很多人可以自己把第一版产品搭出来。\u003c/p\u003e\n\u003cp\u003e这件事很重要，因为它降低了试错成本。你不必一开始就组一个完整团队，也不必在还没验证需求时烧掉太多钱。\u003c/p\u003e\n\u003cp\u003e但 MVP 能跑，不等于它能继续长。\u003c/p\u003e\n\u003cp\u003eAI 写代码最容易带来的问题是：你一开始速度很快，后面越来越慢。功能堆上去了，文件越来越长，状态散在各处，错误处理靠运气，测试没有补，安全边界也没想清楚。到某个节点，你会发现产品不是不能继续写，而是每改一处都担心炸掉另一处。\u003c/p\u003e\n\u003cp\u003e所以 MVP 阶段的重点不是追求架构完美，而是保留几个基本约束：\u003c/p\u003e","title":"AI Native 创业者手册：从想法到规模化"},{"content":"Anthropic 最近发了一篇文章，讲 Claude Code 怎么在大代码库里工作。它里面最有用的点不是某个 prompt 技巧，而是一个更工程化的判断：Claude Code 在大仓库里好不好用，很大程度取决于仓库本身有没有被整理成 agent 能导航的环境。\nClaude Code 不是先把整个仓库做成一个中心化索引，再从索引里召回答案。它更像一个坐在你电脑前的开发者，会读文件、搜关键词、看目录、跟引用、跑命令。这个模式的好处是它看到的是本地最新代码，不太会被过期索引误导；坏处是你不能只丢一句“帮我改一下支付逻辑”，然后指望它在几十万行代码里自己精准落点。\n在大代码库里用 Claude Code，重点是减少它的无效探索。\n从相关目录启动 如果是 monorepo，不要每次都从仓库根目录启动。改某个服务，就先进入那个服务目录；改某个 package，就从 package 目录启动。\nClaude Code 仍然可以向上读取父级 CLAUDE.md，但它的第一视角会更接近当前任务。搜索范围变小，读到的文件更相关，后面跑测试、lint、build 也更容易收窄。\n可以把日常入口做成 alias：\nalias c-api=\u0026#39;cd ~/repo/apps/api \u0026amp;\u0026amp; claude\u0026#39; alias c-web=\u0026#39;cd ~/repo/apps/web \u0026amp;\u0026amp; claude\u0026#39; alias c-worker=\u0026#39;cd ~/repo/services/worker \u0026amp;\u0026amp; claude\u0026#39; 这种小动作比写一大段 prompt 更稳定。\n写分层 CLAUDE.md 根目录的 CLAUDE.md 只放全局信息：系统大概怎么分层、关键目录负责什么、通用代码规范、绝对不能踩的坑。\n不要把它写成百科全书。根文件每次都会进上下文，越长越容易把真正有用的信息挤掉。\n更适合的结构是分层：\nrepo/ CLAUDE.md # 全局架构、通用约定、关键禁忌 apps/web/CLAUDE.md # 前端启动、测试、路由、组件约定 apps/api/CLAUDE.md # API 测试、数据库迁移、错误处理约定 services/worker/CLAUDE.md # 队列、重试、部署前检查 子目录里的 CLAUDE.md 要写具体命令，比如：\n## 常用命令 - 单测：`pnpm test --filter @repo/api` - 类型检查：`pnpm typecheck --filter @repo/api` - 本地服务：`pnpm dev --filter @repo/api` ## 修改数据库相关代码时 - 先看 `migrations/README.md` - 新 migration 必须有 rollback - 不要在请求路径里做全表扫描 这类信息比“请认真修改代码”有用得多。Claude Code 不缺认真，缺的是当前仓库的入口、边界和验证方式。\n让测试命令可以局部运行 大仓库里最容易浪费时间的是全量验证。小改动如果每次都跑完整 CI，本地反馈会慢到不可用。\n可以给每个子项目写清楚最小验证命令：\n## 验证范围 改 `src/billing/**` 时： 1. `pnpm test billing` 2. `pnpm typecheck --filter @repo/api` 3. 如果改了 invoice 生成逻辑，再跑 `pnpm test:e2e invoice` 这不是为了偷懒，而是为了让 Claude Code 有明确的反馈循环。它改完代码后能马上跑一组小检查，发现问题再修；最后需要合并前，再跑完整检查。\n如果仓库没有局部测试命令，可以先补这个。对大代码库来说，这往往比多写十条 prompt 更有价值。\n把噪音排出去 Claude Code 会按需读文件，但它也可能被生成物、构建产物、第三方代码和大日志带偏。\n建议团队统一排除这些内容：\npublic/ dist/ build/ coverage/ *.log generated/ vendor/ 如果某些生成文件必须保留在仓库里，也可以在相关 CLAUDE.md 里写清楚：\n`src/generated/**` 是自动生成代码，不要手改。需要修改类型时，改 `schema/` 后重新生成。 这条规则很适合放进 hook 或权限配置里。能用自动化约束的地方，不要只靠自然语言提醒。\n用 hooks 处理确定性的事 Hooks 适合做格式化、lint、阻止危险命令、动态加载上下文这类确定性工作。\n比如每次编辑 TypeScript 文件后自动跑 formatter，或者在提交前检查是否改了不该改的生成目录。Claude Code 可以遵守规则，但稳定性最高的方式仍然是把规则变成脚本。\n适合放 hook 的事情有几类：\n保存后自动 format 修改数据库 migration 后提示跑对应检查 阻止直接编辑生成文件 阻止提交 .env、密钥、临时日志 任务结束时提醒是否需要更新局部 CLAUDE.md Hook 的价值不是“让 Claude 更聪明”，而是把团队已经确定的规则固定下来。\n把专门流程放进 skills CLAUDE.md 适合放长期有效的项目知识，skills 适合放按任务触发的流程。\n比如安全审查、发布检查、文档更新、数据库 migration review，这些流程不应该常驻在根 CLAUDE.md。它们平时用不到，只有相关任务出现时才需要加载。\n一个简单判断是：\n每次会话都该知道的，放 CLAUDE.md 只有某类任务才需要的，做成 skill 可以自动执行的，不写进 prompt，交给 hook 需要连接外部系统的，再考虑 MCP 这样上下文不会越堆越厚，后面维护起来也更清楚。\nLSP 比纯 grep 更适合大仓库 在小项目里，grep 通常够用。到了大仓库，handler、Service、getConfig 这种名字可能出现几百次，纯文本搜索很容易噪音爆炸。\nLSP 能提供更接近 IDE 的导航能力，比如 go to definition、find references、区分同名符号。对 C、C++、Java、C# 这类大型工程尤其有用。\n但 LSP 不是默认就能工作。你需要确认语言服务器装好了，项目能被它正确识别，必要时还要配置编译数据库或 workspace。这里值得花时间，因为它会直接影响 Claude Code 找代码的质量。\n用 subagents 做探索，不要一边探索一边改 大改动前，可以让 subagent 先做只读探索：\n请只读分析 billing 模块： 1. 找到 invoice 生成入口 2. 梳理主要调用链 3. 标出测试文件 4. 不要修改代码，只返回文件路径和结论 主会话拿到结果后，再决定改哪里。这样能把“摸地图”和“动手术”分开，主上下文也不会被大量无关搜索结果塞满。\n这个习惯在遗留系统里很有用。先让 subagent 画出局部地图，再让主 agent 基于地图做小范围修改。\nMCP 不要太早上 MCP 很适合接内部文档、工单系统、监控平台、代码搜索服务和内部 API。但如果仓库本身还没有清晰的 CLAUDE.md、局部测试命令、ignore 规则和基础导航，上 MCP 只会让可访问的信息更多，问题不一定更少。\n更稳的顺序是：\n先让 Claude Code 能在本地仓库里找对文件 再让它能跑对局部验证命令 然后把重复流程沉淀成 hooks 和 skills 最后再接 MCP，把外部系统引进来 先把本地闭环打通，再扩展外部能力。\n配置也要定期删 Claude Code 的配置不是写完就结束。模型能力会变，工具能力也会变，以前为了补短板写下的规则，过几个月可能变成束缚。\n比较好的节奏是三到六个月回看一次：\n根 CLAUDE.md 有没有变成杂物间 子目录命令是否还准确 hooks 是否还在解决真实问题 skills 有没有重复或过时 权限规则是不是太宽或太窄 以前的 workaround 是否已经不需要了 大代码库里的 Claude Code 配置，最后会变成一种 DevEx 基础设施。有人维护，它会越来越顺；没人维护，它就会慢慢变成另一套过期文档。\n我的实践顺序 如果要从零开始整理一个大仓库，我会按这个顺序做：\n在根目录写一份短的 CLAUDE.md，只放架构、目录说明、全局禁忌。 给最常改的两个子目录补局部 CLAUDE.md，写清测试、lint、build 命令。 把生成物、构建产物、日志和第三方代码排除掉。 确认局部测试可以独立跑，不行就先补命令。 给高频任务做 skills，比如 code review、release check、migration check。 把格式化、安全检查、禁止编辑生成物这些规则交给 hooks。 给主要语言配好 LSP。 遇到大范围陌生模块时，先派 subagent 做只读探索。 等本地流程稳定后，再接 MCP。 每隔几个月删掉过时配置。 Claude Code 在大代码库里的关键不是一次性给它更多上下文，而是让它每一步都能拿到刚好够用、并且足够准确的上下文。仓库越大，这件事越重要。\n","permalink":"http://foxden.vault2049.xyz/tech/claude-code-large-codebases/","summary":"\u003cp\u003eAnthropic 最近发了一篇文章，讲 Claude Code 怎么在大代码库里工作。它里面最有用的点不是某个 prompt 技巧，而是一个更工程化的判断：Claude Code 在大仓库里好不好用，很大程度取决于仓库本身有没有被整理成 agent 能导航的环境。\u003c/p\u003e\n\u003cp\u003eClaude Code 不是先把整个仓库做成一个中心化索引，再从索引里召回答案。它更像一个坐在你电脑前的开发者，会读文件、搜关键词、看目录、跟引用、跑命令。这个模式的好处是它看到的是本地最新代码，不太会被过期索引误导；坏处是你不能只丢一句“帮我改一下支付逻辑”，然后指望它在几十万行代码里自己精准落点。\u003c/p\u003e\n\u003cp\u003e在大代码库里用 Claude Code，重点是减少它的无效探索。\u003c/p\u003e\n\u003ch2 id=\"从相关目录启动\"\u003e从相关目录启动\u003c/h2\u003e\n\u003cp\u003e如果是 monorepo，不要每次都从仓库根目录启动。改某个服务，就先进入那个服务目录；改某个 package，就从 package 目录启动。\u003c/p\u003e\n\u003cp\u003eClaude Code 仍然可以向上读取父级 \u003ccode\u003eCLAUDE.md\u003c/code\u003e，但它的第一视角会更接近当前任务。搜索范围变小，读到的文件更相关，后面跑测试、lint、build 也更容易收窄。\u003c/p\u003e\n\u003cp\u003e可以把日常入口做成 alias：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ealias c-api\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#39;cd ~/repo/apps/api \u0026amp;\u0026amp; claude\u0026#39;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ealias c-web\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#39;cd ~/repo/apps/web \u0026amp;\u0026amp; claude\u0026#39;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ealias c-worker\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#39;cd ~/repo/services/worker \u0026amp;\u0026amp; claude\u0026#39;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e这种小动作比写一大段 prompt 更稳定。\u003c/p\u003e\n\u003ch2 id=\"写分层-claudemd\"\u003e写分层 CLAUDE.md\u003c/h2\u003e\n\u003cp\u003e根目录的 \u003ccode\u003eCLAUDE.md\u003c/code\u003e 只放全局信息：系统大概怎么分层、关键目录负责什么、通用代码规范、绝对不能踩的坑。\u003c/p\u003e\n\u003cp\u003e不要把它写成百科全书。根文件每次都会进上下文，越长越容易把真正有用的信息挤掉。\u003c/p\u003e\n\u003cp\u003e更适合的结构是分层：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  CLAUDE.md                    # 全局架构、通用约定、关键禁忌\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  apps/web/CLAUDE.md            # 前端启动、测试、路由、组件约定\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  apps/api/CLAUDE.md            # API 测试、数据库迁移、错误处理约定\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  services/worker/CLAUDE.md     # 队列、重试、部署前检查\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e子目录里的 \u003ccode\u003eCLAUDE.md\u003c/code\u003e 要写具体命令，比如：\u003c/p\u003e","title":"让 Claude Code 读懂大代码库"},{"content":"Claude for Financial Services 是 Anthropic 提供的一套金融行业 Claude Agent、Skill 和插件参考库。它面向的不是某一个单点任务，而是金融团队每天都会遇到的材料整理、模型搭建、分析初稿和检查流程。\n它适合经常和 Excel、PDF、财报、电话会 transcript、PPT 模板、市场数据、内部资料打交道的人。比如投行、企业融资、PE、二级研究、资管、财富管理、基金运营、财务运营，以及 onboarding / KYC 支持团队。\n这类工作的共同点是输入材料多、格式要求高、人工重复步骤多。Claude 在这里承担的是起草和整理角色：先把资料读进去，按金融工作流生成一版可审核的输出，再交给专业人员判断、修改和批准。\n适用谁 如果你经常需要产出 pitch book、估值模型、研究笔记、IC memo、对账说明或 KYC 审查结果，这个项目就比较对口。\n投行和 PE 团队可以用它处理 pitch、估值、交易材料和投资备忘录；二级研究和资管团队可以用它整理财报、电话会、filings 和模型更新；基金运营和财务团队可以用它辅助对账、月结和 LP statement 审核；KYC 或 onboarding 团队可以用它做文件检查和缺口整理。\n它不要求所有人都写代码。个人试用时，可以把它当作 Claude Code 或 Cowork 插件来用；企业落地时，也可以把同一套 Agent 接到内部系统、数据源和审批流里。\n能做什么 项目里有两类能力。\n一类是完整 Agent，适合跑一段端到端工作流。比如从公司资料出发生成 pitch deck 草稿，或者从财报和电话会出发起草 earnings note。\n另一类是垂直插件和 slash command，适合处理更具体的任务，比如 /comps、/dcf、/lbo、/earnings、/ic-memo。这些命令更像是金融分析里的单项工具，用的时候给它材料和目标，它按对应方法产出初稿。\n可以重点看四个代表 Agent。\nPitch Agent Pitch Agent 适合投行、PE 和企业融资团队准备 pitch 材料。\n它可以基于公司资料、财务数据、行业信息和模板，辅助完成可比公司分析、precedent transactions、LBO、估值区间和 pitch deck 草稿。对 deal team 来说，它更像一个能先把材料铺好的分析师助手，最终版本仍然需要 banker 或项目组审核。\nEarnings Reviewer Earnings Reviewer 适合二级研究和资管团队。\n它可以读取财报、filings 和 earnings call transcript，提取收入、利润率、guidance、管理层表述和关键 KPI 变化，辅助更新模型并起草 earnings note。它适合做第一版整理，把事实、变化和初步观点放到同一个框架里，但不应该直接替代投资结论。\nGL Reconciler GL Reconciler 面向基金运营和财务运营团队。\n它可以帮助查找总账对账差异，追踪 break 的可能原因，整理 reconciliation 结果和待处理项。它的价值在于减少人工查表和解释差异的时间，最后的入账、调整和审批还是要走原有财务流程。\nKYC Screener KYC Screener 面向 onboarding、运营和合规支持团队。\n它可以解析开户文件，根据规则检查缺失项、异常点和需要补充的信息，生成给人工复核的 gap list。它可以做前置筛查和材料整理，但不能直接批准客户准入。\n边界在哪里 金融场景里边界很重要。这个项目不应该被当成自动交易、投资建议、风控审批、会计入账或 KYC 最终批准系统。\nREADME 里也明确说，所有输出都应该进入 human sign-off 流程。Claude 可以帮你起草、整理、检查和建模，专业判断、合规责任和对外发布仍然在人手里。\n个人怎么试用 个人或小团队试用时，可以先把它作为 Claude Code 插件安装。\nclaude plugin marketplace add anthropics/claude-for-financial-services claude plugin install financial-analysis@claude-for-financial-services 然后按任务使用命令：\n/comps 帮我基于这些公司做可比公司分析 /dcf 基于这份财务预测做 DCF 估值框架 /earnings 分析这份财报电话会 transcript，起草 earnings note 如果你做投行材料，可以再装 investment-banking；如果做二级研究，可以装 equity-research；如果想跑完整流程，可以安装对应 Agent，比如 pitch-agent、market-researcher、gl-reconciler。\n企业怎么落地 企业落地时，重点不是命令行，而是把这些 Agent 接进自己的工作流。\n项目提供了 Managed Agents API 的模板，可以部署到内部投研平台、财务运营系统、KYC onboarding 系统，或者 Excel / PowerPoint 环境里。MCP connectors 则负责连接 Morningstar、FactSet、S\u0026amp;P Global、LSEG、PitchBook、Egnyte 等外部数据或文档系统，不过通常需要企业订阅和权限配置。\n如果只是想体验，先从 financial-analysis 开始就够了；如果已经有明确业务场景，再安装对应 vertical plugin 或 Agent。这个项目最值得看的地方，是它把金融行业里重复、耗时、格式化强的工作，拆成了 Claude 可以执行、也便于人工审核的工作流。\n","permalink":"http://foxden.vault2049.xyz/tech/claude-for-financial-services/","summary":"\u003cp\u003e\u003ccode\u003eClaude for Financial Services\u003c/code\u003e 是 Anthropic 提供的一套金融行业 Claude Agent、Skill 和插件参考库。它面向的不是某一个单点任务，而是金融团队每天都会遇到的材料整理、模型搭建、分析初稿和检查流程。\u003c/p\u003e\n\u003cp\u003e它适合经常和 Excel、PDF、财报、电话会 transcript、PPT 模板、市场数据、内部资料打交道的人。比如投行、企业融资、PE、二级研究、资管、财富管理、基金运营、财务运营，以及 onboarding / KYC 支持团队。\u003c/p\u003e\n\u003cp\u003e这类工作的共同点是输入材料多、格式要求高、人工重复步骤多。Claude 在这里承担的是起草和整理角色：先把资料读进去，按金融工作流生成一版可审核的输出，再交给专业人员判断、修改和批准。\u003c/p\u003e\n\u003ch2 id=\"适用谁\"\u003e适用谁\u003c/h2\u003e\n\u003cp\u003e如果你经常需要产出 pitch book、估值模型、研究笔记、IC memo、对账说明或 KYC 审查结果，这个项目就比较对口。\u003c/p\u003e\n\u003cp\u003e投行和 PE 团队可以用它处理 pitch、估值、交易材料和投资备忘录；二级研究和资管团队可以用它整理财报、电话会、filings 和模型更新；基金运营和财务团队可以用它辅助对账、月结和 LP statement 审核；KYC 或 onboarding 团队可以用它做文件检查和缺口整理。\u003c/p\u003e\n\u003cp\u003e它不要求所有人都写代码。个人试用时，可以把它当作 Claude Code 或 Cowork 插件来用；企业落地时，也可以把同一套 Agent 接到内部系统、数据源和审批流里。\u003c/p\u003e\n\u003ch2 id=\"能做什么\"\u003e能做什么\u003c/h2\u003e\n\u003cp\u003e项目里有两类能力。\u003c/p\u003e\n\u003cp\u003e一类是完整 Agent，适合跑一段端到端工作流。比如从公司资料出发生成 pitch deck 草稿，或者从财报和电话会出发起草 earnings note。\u003c/p\u003e\n\u003cp\u003e另一类是垂直插件和 slash command，适合处理更具体的任务，比如 \u003ccode\u003e/comps\u003c/code\u003e、\u003ccode\u003e/dcf\u003c/code\u003e、\u003ccode\u003e/lbo\u003c/code\u003e、\u003ccode\u003e/earnings\u003c/code\u003e、\u003ccode\u003e/ic-memo\u003c/code\u003e。这些命令更像是金融分析里的单项工具，用的时候给它材料和目标，它按对应方法产出初稿。\u003c/p\u003e\n\u003cp\u003e可以重点看四个代表 Agent。\u003c/p\u003e\n\u003ch2 id=\"pitch-agent\"\u003ePitch Agent\u003c/h2\u003e\n\u003cp\u003ePitch Agent 适合投行、PE 和企业融资团队准备 pitch 材料。\u003c/p\u003e\n\u003cp\u003e它可以基于公司资料、财务数据、行业信息和模板，辅助完成可比公司分析、precedent transactions、LBO、估值区间和 pitch deck 草稿。对 deal team 来说，它更像一个能先把材料铺好的分析师助手，最终版本仍然需要 banker 或项目组审核。\u003c/p\u003e","title":"Claude for Financial Services"},{"content":"最近翻了一遍 Polymarket 的官方文档，发现它比很多人想象里简单，也比看上去复杂。\n简单的地方在于，用户做的事就是买一张 Yes 或 No 的票，判断某件事会不会发生。复杂的地方在于，它把新闻事件、市场定价、链上结算、订单簿、做市激励这些东西全揉在了一起。\n不少人第一次看到 Polymarket，会把它理解成一个链上投注平台。这个说法不算完全错，但会漏掉更重要的一层：它其实是一个把概率明码标价的市场。\n比如一个问题叫“某候选人会不会赢得选举”，Yes 的价格是 0.63，意思不是平台告诉你他有 63% 的胜率，而是市场上愿意买和愿意卖的人，最后把价格交易到了这个位置。价格不是预言，是人们拿真钱表达出来的判断。\n普通人要理解 Polymarket，可以先别从区块链、合约、Oracle 这些词开始。先把它想成一个菜市场。\n一个摊位只卖一道判断题：这件事会不会发生。摊位上有两种票，Yes 和 No。你觉得会发生，就买 Yes；觉得不会发生，就买 No。最后结果出来，猜对的票每张换 1 美元，猜错的票变成 0。\n这套东西叫预测市场。\n预测市场好玩的地方是，它不问你嘴上怎么说，只看你愿意用多少钱表达自己的判断。很多人在社交媒体上会喊得很大声，但 Polymarket 会把这种声音压成一个数字：0.23、0.58、0.91。数字不一定对，但它很诚实地反映了当下市场里的钱站在哪边。\n1. Market 是一道题，Event 是一组题 每个问题背后都有两层结构，一个叫 Event，一个叫 Market。\nEvent 可以理解成一个专题页，比如“2024 美国总统大选”。Market 是里面的一道具体问题，比如“Trump 会赢吗”“Harris 会赢吗”“Other 会赢吗”。如果一个 Event 只有一道题，那 Event 和 Market 看起来差不多；如果一个 Event 下面有多个候选项，它就变成了一组相关市场。\n这点在多结果事件里很重要。二选一的问题很好懂，比如“比特币会不会在某天前到 15 万美元”。多结果问题就麻烦一些，比如“谁会赢选举”。每个候选人都可以拆成一个 Yes/No 市场，但最后只能有一个人赢。\nPolymarket 文档里把这种多结果场景叫 negative risk。这个名字不太适合普通读者，可以先记成互斥多选题。\n比如有三个选项：Trump、Harris、Other。你买了 Other 的 No，本质上是在说 Other 不会赢，那就等于 Trump 或 Harris 会赢。在负风险市场里，一个选项的 No 可以转换成其他所有选项的 Yes。这样做的意义是省资金，不用为了表达同一个判断重复买很多票。\n这里有个坑是 Other。很多人看到 Other 会觉得它只是其他人，但在增强版负风险市场里，Other 的含义可能会随着新候选人、新占位项的确认而变化。文档里也提醒，普通用户最好优先交易已经明确命名的选项，少碰含义会变化的 Other。\n2. 价格不是答案，而是市场当前愿意付的钱 价格是 Polymarket 最容易被误读的地方。\nYes 价格 0.70，不代表你买了之后一定有 70% 概率赚钱。它只代表市场当前愿意用 70 美分买一张最终可能值 1 美元的票。你买入之后，后面还有几种情况：价格涨了，你可以提前卖掉；价格跌了，你可以认亏退出；一直拿到开奖，最后要么变 1 美元，要么变 0。\n这和股票还有点不一样。股票再跌也未必归零，Polymarket 的结果票到最后就是二元结算。对了拿 1，错了拿 0。中间价格再怎么变，最后都会被结果拉回去。\n所以 Polymarket 的核心不是低买高卖这么简单，而是你要判断两件事：市场给出的概率是不是偏了，以及这个偏差能不能在结果出来前或结果出来时兑现。\n3. 订单簿决定你真正买到什么价格 交易靠订单簿完成。\n订单簿就是一张报价表，上面有买方愿意出的价格，也有卖方愿意接受的价格。最高买价叫 bid，最低卖价叫 ask，中间的差距叫 spread。\n比如 Yes 的最高买价是 0.34，最低卖价是 0.40，页面上可能显示中间价 0.37。但你真的要马上买，通常要付 0.40；你马上卖，通常只能拿 0.34。看价格时只盯页面显示的概率，很容易忽略这 6 美分的差价。\n差价小，说明这个市场流动性好，进出都比较顺。差价大，说明你一买一卖就先亏一截。很多新手看对方向也不赚钱，问题就出在这里：方向判断没错，但买得太贵，卖得太急，spread 和手续费把利润吃掉了。\nPolymarket 的订单类型文档写得很交易所化，普通用户记几个就够了。\nGTC 是一直挂着，直到成交或取消。你说 0.40 才买 Yes，没人卖就一直等。\nGTD 是挂到某个时间为止。比如比赛开始前有效，过了时间自动取消。\nFOK 是要么全部成交，要么直接取消。你要买 100 张，市场只能给你 80 张，那就一张都不买。\nFAK 是能成交多少算多少，剩下取消。你要买 100 张，市场只能给你 80 张，那就先买 80 张，剩下 20 张不要了。\n文档里还有 post-only，这个主要给做市商用。意思是这张单只能挂在订单簿上，不能一进去就成交。如果会马上成交，系统就拒绝它。它的目的很简单：保证自己是提供报价的人，而不是吃掉别人报价的人。\n4. Maker 是摆摊的人，Taker 是直接买的人 这就引出 Maker 和 Taker。\nMaker 是摆摊的人，挂出买价和卖价，等别人来成交。Taker 是来买菜的人，看到现成报价直接成交。市场需要 Maker，因为没有人摆摊，普通用户就没法顺畅买卖；Maker 也不是做慈善，他赚的是买卖价差，或者平台给的返佣和流动性奖励。\nPolymarket 给做市商的文档里，重点一直围绕一件事：让市场更深、更窄、更稳定。\n更深，是订单簿上有足够数量。你买 100 张、1000 张都不至于把价格打飞。\n更窄，是买卖价差小。别人进出市场的成本低。\n更稳定，是有人持续挂单，不是一有波动报价全撤。\n做市听起来像稳定赚钱，其实风险不小。最典型的错误是 crossed market，也就是买价比卖价还高。比如你挂 0.45 买，又挂 0.43 卖，每成交一轮都在高买低卖。文档里专门提醒做市商要检查报价，原因就在这里。\n为了让做市商愿意长期摆摊，Polymarket 有两类激励。\n一类是 maker rebates，做市返佣。某些市场会向 Taker 收手续费，然后把一部分手续费按比例返给提供流动性的 Maker。返佣每天用 USDC 发，累计不到 1 美元不支付。\n另一类是 liquidity rewards，流动性奖励。它不只看你有没有成交，还看你是不是持续挂了有用的单。离中间价越近、数量越够、买卖两边越平衡，越容易拿到奖励。文档里的公式很长，普通人不用记，理解成平台奖励价格公道、货量稳定的摊位就行。\n5. 手续费比很多人想得更细 手续费这块也值得单独看。\nPolymarket 不是所有市场都收费。文档明确写了，地缘政治和世界事件市场不收 Polymarket 手续费，USDC 存取也没有 Polymarket 手续费，但 Coinbase、MoonPay 这类中间服务可能自己收费。\n有手续费的市场，通常只收 Taker，不收 Maker。也就是主动吃别人报价的人付费，挂单提供流动性的人不付。\n手续费公式里有个 p × (1 - p)，p 是价格。这个公式带来的结果是，价格在 0.50 附近手续费最高，越接近 0 或 1，手续费越低。0.30 和 0.70 的手续费大致对称。这个设计也合理，因为 50% 附近交易价值和不确定性最高，市场活动通常也最多。\n这对普通用户的影响很直接：不要只看方向，也要看入场方式。你是主动吃单，还是挂单等别人来成交；你交易的市场有没有手续费；你的利润空间能不能覆盖 spread 和手续费，这些都会影响最后结果。\n6. 最后怎么开奖，比标题更重要 再看结算。\nPolymarket 上每张 Yes 或 No 票，本质上是链上的结果 token。每个市场有两个结果 token，Yes 和 No。结果出来后，赢的 token 每张换 1 美元，输的 token 归零。\n平台用 UMA 的 optimistic oracle 来做结果判定。简单说，有人提出结果，如果没人反对，大约两小时后确认；如果有人争议，会进入辩论和投票流程，可能拖到四到六天。\n这里最重要的不是 oracle 这个词，而是 resolution rules。\n很多人交易时只看标题，这是很危险的。标题只是给你一个大概问题，真正决定怎么开奖的是规则。规则会写清楚看哪个来源、到什么时候截止、特殊情况怎么算、出现歧义怎么办。\n比如标题写“某人会不会参加竞选”，规则可能要求以官方登记为准，也可能要求以某个网站公布为准。你以为的“参加”和规则里的“参加”不是一回事，最后结果就可能和直觉相反。\n7. 它也可以只是一个信息产品 Polymarket 最适合普通人看的，不一定是赚钱机会，而是信息密度。\n传统新闻告诉你发生了什么，评论区告诉你大家怎么吵，Polymarket 多给了一个维度：市场愿意为某种判断付多少钱。一个事件价格从 0.20 涨到 0.65，背后往往对应着信息更新、资金迁移和群体预期变化。\n这也是它最像信息产品的地方。你可以不交易，只把它当成实时概率面板看。选举、体育、加密货币、宏观数据、公司事件，都可以被折成一条价格曲线。曲线不一定比专家准，但它比单条新闻更连续，也比社交媒体情绪更可量化。\n如果真要上手交易，节奏可以慢一点。\n先找一个自己真的看得懂的市场，不要一上来碰规则复杂的多结果事件。看标题之后，先读 resolution rules，再看 Yes 和 No 的价格，看订单簿深度和买卖价差，最后再看有没有手续费。决定买之前，先问自己一个很具体的问题：如果我错了，最多亏多少；如果我对了，收益是不是值得承担这个风险。\n买完之后也不一定要等开奖。Polymarket 的票可以提前卖。如果你 0.40 买入 Yes，后来价格涨到 0.70，卖掉就已经锁定 0.30 的利润。很多事件越接近结果，价格波动越大，提前退出反而比等最后一刻舒服。\n更进阶的人会研究做市、负风险转换、跨市场价差、规则歧义和信息速度。普通人没必要一开始就碰这些。Polymarket 的门槛不在注册和下单，而在你是否真的理解自己买的那张票到底代表什么。\n写在最后 我现在看 Polymarket，会把它分成三层。\n第一层是普通预测市场，买 Yes 或 No，表达对事件的判断。\n第二层是交易市场，价格、订单簿、spread、手续费和流动性决定你实际能不能赚到钱。\n第三层是信息市场，价格变化本身就是一种信号，它把新闻、分歧和资金预期压成了一串数字。\n多数人从第一层开始就够了，先看懂一个问题怎么从 0.50 走到 0.80，再看它最后怎么开奖。看多了之后，你会慢慢知道哪些市场只是热闹，哪些市场真的在吸收信息。\nPolymarket 最值得学的地方，不是它让人可以押注新闻，而是它把模糊判断变成了可交易的价格。以前你说“我觉得大概率会发生”，这句话没有成本。现在你要为这个大概率付 0.70，或者只愿意付 0.45，判断就变得清楚了。\n这篇只是介绍 Polymarket 的机制，不构成任何投资建议。预测市场的结果票到期后可能归零，交易前最好先确认自己看懂了规则、价格、流动性和最坏情况。\n","permalink":"http://foxden.vault2049.xyz/life/polymarket-intro/","summary":"\u003cp\u003e最近翻了一遍 Polymarket 的官方文档，发现它比很多人想象里简单，也比看上去复杂。\u003c/p\u003e\n\u003cp\u003e简单的地方在于，用户做的事就是买一张 Yes 或 No 的票，判断某件事会不会发生。复杂的地方在于，它把新闻事件、市场定价、链上结算、订单簿、做市激励这些东西全揉在了一起。\u003c/p\u003e\n\u003cp\u003e不少人第一次看到 Polymarket，会把它理解成一个链上投注平台。这个说法不算完全错，但会漏掉更重要的一层：它其实是一个把概率明码标价的市场。\u003c/p\u003e\n\u003cp\u003e比如一个问题叫“某候选人会不会赢得选举”，Yes 的价格是 0.63，意思不是平台告诉你他有 63% 的胜率，而是市场上愿意买和愿意卖的人，最后把价格交易到了这个位置。价格不是预言，是人们拿真钱表达出来的判断。\u003c/p\u003e\n\u003cp\u003e普通人要理解 Polymarket，可以先别从区块链、合约、Oracle 这些词开始。先把它想成一个菜市场。\u003c/p\u003e\n\u003cp\u003e一个摊位只卖一道判断题：这件事会不会发生。摊位上有两种票，Yes 和 No。你觉得会发生，就买 Yes；觉得不会发生，就买 No。最后结果出来，猜对的票每张换 1 美元，猜错的票变成 0。\u003c/p\u003e\n\u003cp\u003e这套东西叫预测市场。\u003c/p\u003e\n\u003cp\u003e预测市场好玩的地方是，它不问你嘴上怎么说，只看你愿意用多少钱表达自己的判断。很多人在社交媒体上会喊得很大声，但 Polymarket 会把这种声音压成一个数字：0.23、0.58、0.91。数字不一定对，但它很诚实地反映了当下市场里的钱站在哪边。\u003c/p\u003e\n\u003ch2 id=\"1-market-是一道题event-是一组题\"\u003e1. Market 是一道题，Event 是一组题\u003c/h2\u003e\n\u003cp\u003e每个问题背后都有两层结构，一个叫 Event，一个叫 Market。\u003c/p\u003e\n\u003cp\u003eEvent 可以理解成一个专题页，比如“2024 美国总统大选”。Market 是里面的一道具体问题，比如“Trump 会赢吗”“Harris 会赢吗”“Other 会赢吗”。如果一个 Event 只有一道题，那 Event 和 Market 看起来差不多；如果一个 Event 下面有多个候选项，它就变成了一组相关市场。\u003c/p\u003e\n\u003cp\u003e这点在多结果事件里很重要。二选一的问题很好懂，比如“比特币会不会在某天前到 15 万美元”。多结果问题就麻烦一些，比如“谁会赢选举”。每个候选人都可以拆成一个 Yes/No 市场，但最后只能有一个人赢。\u003c/p\u003e\n\u003cp\u003ePolymarket 文档里把这种多结果场景叫 negative risk。这个名字不太适合普通读者，可以先记成互斥多选题。\u003c/p\u003e\n\u003cp\u003e比如有三个选项：Trump、Harris、Other。你买了 Other 的 No，本质上是在说 Other 不会赢，那就等于 Trump 或 Harris 会赢。在负风险市场里，一个选项的 No 可以转换成其他所有选项的 Yes。这样做的意义是省资金，不用为了表达同一个判断重复买很多票。\u003c/p\u003e","title":"你不知道的 Polymarket：预测市场、概率定价与普通人的上手方式"},{"content":"你不知道的 Agent：原理、架构与工程实 原文链接 \u0026lt;https://x.com/HiTw93/status/2034627967926825175\u0026gt; 一个 Agent 系统怎么才能跑得稳 Agent 的最小运行原理 Workflow 和 Agent 的区别 控制流的几种常见模式 Harness、验证和执行边界 上下文工程与压缩缓存 工具设计 记忆与长任务续跑 多 Agent 协作 评测、追踪和安全 用具体系统把这些原则落地 你不知道的 Claude Code：架构、治理与工程实践 原文链接 \u0026lt;https://x.com/HiTw93/status/2032091246588518683\u0026gt; 怎么把Claude真正用进日常开发，而不是只把它当成一个会写代码的聊天工具 Claude Code 的六层结构与核心循环 上下文为什么会乱，以及该怎么治理 Plan Mode、Compact、HANDOFF 这些机制怎么配合使用 Skills 应该怎么写，描述符、正文和 supporting files 怎么分工 Tools 和 Hooks 应该怎么设计，哪些能力该交给哪一层 Subagents 的真正价值是什么，什么时候该用，什么时候不该用 Prompt Caching 怎样影响系统架构、工具顺序和模型切换 验证体系、命令体系和常用工作流怎么搭 CLAUDE.md 应该写什么，不该写什么 最后回到项目实践，给出一套可落地的工程布局 你不知道的 AI Coding：非技术人的上手、场景与实战 原文链接 \u0026lt;https://x.com/HiTw93/status/2048230976447557787\u0026gt; 非技术同学怎么把 Claude Code 真正用起来，而不是停在对话框 AI 终端并不是程序员专属，关键是先跨过第一步 非技术同学也需要懂一点框架、Git、报错和代码结构 Claude Code 更像通用 Agent，写代码只是最早的入口 最适合交给 AI 的，是目标清楚、结果好验收的任务 从 software for one 开始，先做只服务自己的小工具 需求要写具体：问题、范围、异常、验收标准都要落到数字和场景 复杂任务先用 Plan Mode，确认方案后再让它执行 改代码前用 Git 留检查点，排错时先找根因再动手 CLAUDE.md、Skill、Memory 是把个人习惯沉淀成工作流的关键 截图、拆小任务、重启对话和安全边界，是新手最容易忽略的基本功 ","permalink":"http://foxden.vault2049.xyz/tech/tw93-%E6%96%87%E7%AB%A0%E7%B2%BE%E9%80%89/","summary":"\u003ch2 id=\"你不知道的-agent原理架构与工程实\"\u003e你不知道的 Agent：原理、架构与工程实\u003c/h2\u003e\n\u003ch3 id=\"原文链接-httpsxcomhitw93status2034627967926825175\"\u003e原文链接 \u003ccode\u003e\u0026lt;https://x.com/HiTw93/status/2034627967926825175\u0026gt;\u003c/code\u003e\u003c/h3\u003e\n\u003ch3 id=\"一个-agent-系统怎么才能跑得稳\"\u003e一个 Agent 系统怎么才能跑得稳\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003eAgent 的最小运行原理\u003c/li\u003e\n\u003cli\u003eWorkflow 和 Agent 的区别\u003c/li\u003e\n\u003cli\u003e控制流的几种常见模式\u003c/li\u003e\n\u003cli\u003eHarness、验证和执行边界\u003c/li\u003e\n\u003cli\u003e上下文工程与压缩缓存\u003c/li\u003e\n\u003cli\u003e工具设计\u003c/li\u003e\n\u003cli\u003e记忆与长任务续跑\u003c/li\u003e\n\u003cli\u003e多 Agent 协作\u003c/li\u003e\n\u003cli\u003e评测、追踪和安全\u003c/li\u003e\n\u003cli\u003e用具体系统把这些原则落地\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"你不知道的-claude-code架构治理与工程实践\"\u003e你不知道的 Claude Code：架构、治理与工程实践\u003c/h2\u003e\n\u003ch3 id=\"原文链接-httpsxcomhitw93status2032091246588518683\"\u003e原文链接 \u003ccode\u003e\u0026lt;https://x.com/HiTw93/status/2032091246588518683\u0026gt;\u003c/code\u003e\u003c/h3\u003e\n\u003ch3 id=\"怎么把claude真正用进日常开发而不是只把它当成一个会写代码的聊天工具\"\u003e怎么把Claude真正用进日常开发，而不是只把它当成一个会写代码的聊天工具\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003eClaude Code 的六层结构与核心循环\u003c/li\u003e\n\u003cli\u003e上下文为什么会乱，以及该怎么治理\u003c/li\u003e\n\u003cli\u003ePlan Mode、Compact、HANDOFF 这些机制怎么配合使用\u003c/li\u003e\n\u003cli\u003eSkills 应该怎么写，描述符、正文和 supporting files 怎么分工\u003c/li\u003e\n\u003cli\u003eTools 和 Hooks 应该怎么设计，哪些能力该交给哪一层\u003c/li\u003e\n\u003cli\u003eSubagents 的真正价值是什么，什么时候该用，什么时候不该用\u003c/li\u003e\n\u003cli\u003ePrompt Caching 怎样影响系统架构、工具顺序和模型切换\u003c/li\u003e\n\u003cli\u003e验证体系、命令体系和常用工作流怎么搭\u003c/li\u003e\n\u003cli\u003eCLAUDE.md 应该写什么，不该写什么\u003c/li\u003e\n\u003cli\u003e最后回到项目实践，给出一套可落地的工程布局\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"你不知道的-ai-coding非技术人的上手场景与实战\"\u003e你不知道的 AI Coding：非技术人的上手、场景与实战\u003c/h2\u003e\n\u003ch3 id=\"原文链接-httpsxcomhitw93status2048230976447557787\"\u003e原文链接 \u003ccode\u003e\u0026lt;https://x.com/HiTw93/status/2048230976447557787\u0026gt;\u003c/code\u003e\u003c/h3\u003e\n\u003ch3 id=\"非技术同学怎么把-claude-code-真正用起来而不是停在对话框-ai\"\u003e非技术同学怎么把 Claude Code 真正用起来，而不是停在对话框 AI\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e终端并不是程序员专属，关键是先跨过第一步\u003c/li\u003e\n\u003cli\u003e非技术同学也需要懂一点框架、Git、报错和代码结构\u003c/li\u003e\n\u003cli\u003eClaude Code 更像通用 Agent，写代码只是最早的入口\u003c/li\u003e\n\u003cli\u003e最适合交给 AI 的，是目标清楚、结果好验收的任务\u003c/li\u003e\n\u003cli\u003e从 software for one 开始，先做只服务自己的小工具\u003c/li\u003e\n\u003cli\u003e需求要写具体：问题、范围、异常、验收标准都要落到数字和场景\u003c/li\u003e\n\u003cli\u003e复杂任务先用 Plan Mode，确认方案后再让它执行\u003c/li\u003e\n\u003cli\u003e改代码前用 Git 留检查点，排错时先找根因再动手\u003c/li\u003e\n\u003cli\u003eCLAUDE.md、Skill、Memory 是把个人习惯沉淀成工作流的关键\u003c/li\u003e\n\u003cli\u003e截图、拆小任务、重启对话和安全边界，是新手最容易忽略的基本功\u003c/li\u003e\n\u003c/ol\u003e","title":"Tw93：AI Coding、Agent 与 Claude Code 文章摘选"},{"content":"很多人看段永平，最先看到的是那个结果：两百万美元进场，后来变成两百亿美元，像是一个几乎不可复制的传奇。于是很容易把这种结果归因于眼光、定力，或者某种近乎玄学的判断力。\n但如果把视角再拉开一点，会发现他真正厉害的地方，未必只是会买股票，而是他站的位置，本来就和普通投资者不一样。\n这篇想聊的，不是“如何复制段永平”，而是从他的案例里，拆出几件常被忽略、但更接近底层的事。比如，投资里的心态到底从哪里来，技术指标为什么越来越像安慰剂，“长期持有”为什么常常被讲得过于简单，以及很多人以为自己“拥有”的东西，法律上未必真是那么回事。\n1. 所谓好心态，往往不是修出来的，而是垫出来的 投资圈很爱讲“平常心”。听上去像一种修养，好像只要见得多、悟得深，就能在市场大跌时面不改色。\n但现实通常没那么玄。很多时候，一个人能不能保持冷静，不取决于性格，而取决于他的处境。\n2002 年段永平买入网易时，公司正处在退市边缘，这笔交易后来被当成经典案例反复提起。可如果回到当时去看，他敢出手，不只是因为判断准，也因为那时他的实业基础已经很稳了。步步高体系带来的现金流，让这两百万美元更像一笔高波动的配置，而不是一场押上身家的豪赌。\n这件事放在今天看，启发其实很直接：很多人口中的“心态”，本质上是财务结构的一部分。你有稳定现金流，有足够安全垫，亏损就只是亏损；你没有这些，市场波动很容易直接变成生活压力。房贷、家庭开支、职业不确定性，都会透过账户余额传导到情绪上。\n所以，心态并不总是一个心理问题。很多时候，它首先是一个资产负债表问题。真正的从容，往往不是练出来的，而是因为你输得起。\n2. 技术指标没有消失，但它越来越不像“答案” 不少散户入市，最先接触的是 K 线、MACD、KDJ 这些工具。它们看起来清晰、直观，也给人一种“市场是可以被读懂的”感觉。\n问题不在于这些东西完全没用，而在于很多人把它们用错了位置。\n如果把投资理解成一套判断企业和价格关系的过程，那么技术指标更像仪表盘，而不是导航系统。它能告诉你速度、波动、情绪，能帮助你感知市场短期在发生什么，但它并不能替代对企业本身的理解，更不能告诉你这条路最后通向哪里。\n本杰明·格雷厄姆有个很有名的比喻：价值是人，价格是狗。狗会跑得很快，有时候冲到前面，有时候落在后面，但绳子最终还是拴在人身上。这个比喻今天依然有效。\n如果一定要给技术分析留一个位置，我更愿意把它放在三个问题上：\n价格离价值大概偏了多远； 企业的长期方向是向上还是向下； 市场情绪现在更接近贪婪，还是更接近恐慌。 把它当成观察工具可以，但把它当成制胜公式，可能就有点高估它了。尤其在今天，信息、算力和交易速度早已不是一个散户能轻易追平的东西。很多图形一旦被所有人都看见，往往也就没那么有用了。\n3. “永远不卖”听起来坚定，实际常常过于简化 价值投资被讲得最动人的一句话，大概就是“买入并长期持有”。这句话当然有它成立的一面，但如果把它理解成对任何股票都死守到底，就容易把原则听成口号。\n现实里的大资金，通常没有嘴上说得那么简单。\n一方面，机构需要持续管理规模，需要市场始终保持参与热情；另一方面，大资金退出一个仓位，本身就需要流动性。说得直白一点，很多时候，真正的大资金想走，也需要有人接。\n还有一个很少被明说的原因：承认判断变化，甚至承认自己看错了，从来不是件轻松的事。对有影响力的人来说，这不只是交易决策，还关系到外部形象、市场解读，甚至后续连锁反应。所以很多人会选择安静地调整，而不是高调地改口。\n巴菲特当年减持中石油，就是一个典型例子。他并不是一边高喊“永远不卖”，一边突然情绪化离场，而是在规则允许的空间里，尽量平稳地完成退出。\n这其实提醒我们一件很重要的事：长期主义更应该对应的是方法和标准，不是某个具体代码。企业护城河变了，原先的判断失效了，或者出现了更好的机会，卖出本来就是投资的一部分。把“长期持有”理解成永不修正，反而容易把投资做成信仰。\n4. 你以为自己买的是公司，很多时候买到的只是结构 很多普通投资者会天然觉得，买股票就是买公司的一部分。这在很多市场里大体成立，但一旦落到中概股、VIE 这些具体结构上，事情就没那么简单了。\n像阿里、腾讯这类中概资产，海外投资者通常并不是直接持有中国境内运营实体的股权，而是持有开曼等地的壳公司权益，再通过一套协议安排，把收益权和控制关系间接连接起来。这套结构大家都很熟，它也确实运转了很多年，但它和“直接拥有公司股权”并不是一回事。\n问题不一定天天发生，可一旦发生，往往就不是小事。2011 年支付宝股权调整，就是很多人后来反复提起的例子。那次事件至少说明了一点：当法律结构、监管边界和商业利益发生冲突时，纸面上的安排未必总能像你想象得那样稳定。\n所以，买这类资产时，不能只看业务、用户、利润，还得看自己到底持有什么。你持有的，可能不是那家公司的“身体”，而更像是一套对它收益拥有索取权的安排。平时它看起来和股权差不多，但在关键时刻，两者未必等价。\n这不是说这类资产不能投，而是说，风险不能只按财务报表来理解。法律结构本身，也应该进入估值。\n5. 真正有用的，常常不是更复杂的招式，而是更重的框架 武侠小说里讲“重剑无锋，大巧不工”，意思不是招式越少越好，而是当一个人的内力、判断和节奏感足够稳定时，反而不需要太多花哨动作。\n投资也有点像这样。\n市场价格不会长期停在一个“刚刚好”的位置，它总是在情绪推动下左右摆动，时而过热，时而过冷。与其追着这些摆动跑，不如先看大的方向，再等小的回摆。\n如果一定要把这个思路说得更具体一点，大概就是两层：先看长期趋势，再等短期波动。长期趋势决定这是不是一门值得长期站着的生意，短期波动决定你是不是有更舒服的价格进去。\n均线也好，趋势也好，在这里并不是神秘工具，而是一种帮你看清节奏的简化框架。它没有那么性感，但有时正因为简单，反而更能约束动作。\n投资里最难的部分，很多时候不是“看懂”，而是“等到”。明知是好公司，却忍不住在情绪最热的时候追进去；明知价格已经偏离很多，却总觉得它还能再涨一点。这种时候，简单的方法未必显得聪明，但往往更有用。\n写在最后 如果把这几件事放在一起看，会发现一个很朴素的结论：投资从来不只是选股票，它更像是在处理自己和风险、价格、法律结构、现金流之间的关系。\n段永平的案例之所以值得看，未必是因为它足够传奇，而是因为它把很多平时被忽略的前提放大了。比如，心态背后其实有财务基础，长期持有背后其实有退出判断，所谓“拥有”背后其实有法律边界。\n说到底，真正重要的也许不是你能不能找到下一只十倍股，而是你有没有能力分清，什么是公司本身，什么只是市场情绪；什么是长期逻辑，什么只是短期叙事；什么是你真的持有，什么只是你以为自己持有。\n对投资者来说，最基本也最宝贵的自由，始终还是那件事：当逻辑变了，你有权离开。\n","permalink":"http://foxden.vault2049.xyz/life/duan-yongping-investing/","summary":"\u003cp\u003e很多人看段永平，最先看到的是那个结果：两百万美元进场，后来变成两百亿美元，像是一个几乎不可复制的传奇。于是很容易把这种结果归因于眼光、定力，或者某种近乎玄学的判断力。\u003c/p\u003e\n\u003cp\u003e但如果把视角再拉开一点，会发现他真正厉害的地方，未必只是会买股票，而是他站的位置，本来就和普通投资者不一样。\u003c/p\u003e\n\u003cp\u003e这篇想聊的，不是“如何复制段永平”，而是从他的案例里，拆出几件常被忽略、但更接近底层的事。比如，投资里的心态到底从哪里来，技术指标为什么越来越像安慰剂，“长期持有”为什么常常被讲得过于简单，以及很多人以为自己“拥有”的东西，法律上未必真是那么回事。\u003c/p\u003e\n\u003ch2 id=\"1-所谓好心态往往不是修出来的而是垫出来的\"\u003e1. 所谓好心态，往往不是修出来的，而是垫出来的\u003c/h2\u003e\n\u003cp\u003e投资圈很爱讲“平常心”。听上去像一种修养，好像只要见得多、悟得深，就能在市场大跌时面不改色。\u003c/p\u003e\n\u003cp\u003e但现实通常没那么玄。很多时候，一个人能不能保持冷静，不取决于性格，而取决于他的处境。\u003c/p\u003e\n\u003cp\u003e2002 年段永平买入网易时，公司正处在退市边缘，这笔交易后来被当成经典案例反复提起。可如果回到当时去看，他敢出手，不只是因为判断准，也因为那时他的实业基础已经很稳了。步步高体系带来的现金流，让这两百万美元更像一笔高波动的配置，而不是一场押上身家的豪赌。\u003c/p\u003e\n\u003cp\u003e这件事放在今天看，启发其实很直接：很多人口中的“心态”，本质上是财务结构的一部分。你有稳定现金流，有足够安全垫，亏损就只是亏损；你没有这些，市场波动很容易直接变成生活压力。房贷、家庭开支、职业不确定性，都会透过账户余额传导到情绪上。\u003c/p\u003e\n\u003cp\u003e所以，心态并不总是一个心理问题。很多时候，它首先是一个资产负债表问题。真正的从容，往往不是练出来的，而是因为你输得起。\u003c/p\u003e\n\u003ch2 id=\"2-技术指标没有消失但它越来越不像答案\"\u003e2. 技术指标没有消失，但它越来越不像“答案”\u003c/h2\u003e\n\u003cp\u003e不少散户入市，最先接触的是 K 线、MACD、KDJ 这些工具。它们看起来清晰、直观，也给人一种“市场是可以被读懂的”感觉。\u003c/p\u003e\n\u003cp\u003e问题不在于这些东西完全没用，而在于很多人把它们用错了位置。\u003c/p\u003e\n\u003cp\u003e如果把投资理解成一套判断企业和价格关系的过程，那么技术指标更像仪表盘，而不是导航系统。它能告诉你速度、波动、情绪，能帮助你感知市场短期在发生什么，但它并不能替代对企业本身的理解，更不能告诉你这条路最后通向哪里。\u003c/p\u003e\n\u003cp\u003e本杰明·格雷厄姆有个很有名的比喻：价值是人，价格是狗。狗会跑得很快，有时候冲到前面，有时候落在后面，但绳子最终还是拴在人身上。这个比喻今天依然有效。\u003c/p\u003e\n\u003cp\u003e如果一定要给技术分析留一个位置，我更愿意把它放在三个问题上：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e价格离价值大概偏了多远；\u003c/li\u003e\n\u003cli\u003e企业的长期方向是向上还是向下；\u003c/li\u003e\n\u003cli\u003e市场情绪现在更接近贪婪，还是更接近恐慌。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e把它当成观察工具可以，但把它当成制胜公式，可能就有点高估它了。尤其在今天，信息、算力和交易速度早已不是一个散户能轻易追平的东西。很多图形一旦被所有人都看见，往往也就没那么有用了。\u003c/p\u003e\n\u003ch2 id=\"3-永远不卖听起来坚定实际常常过于简化\"\u003e3. “永远不卖”听起来坚定，实际常常过于简化\u003c/h2\u003e\n\u003cp\u003e价值投资被讲得最动人的一句话，大概就是“买入并长期持有”。这句话当然有它成立的一面，但如果把它理解成对任何股票都死守到底，就容易把原则听成口号。\u003c/p\u003e\n\u003cp\u003e现实里的大资金，通常没有嘴上说得那么简单。\u003c/p\u003e\n\u003cp\u003e一方面，机构需要持续管理规模，需要市场始终保持参与热情；另一方面，大资金退出一个仓位，本身就需要流动性。说得直白一点，很多时候，真正的大资金想走，也需要有人接。\u003c/p\u003e\n\u003cp\u003e还有一个很少被明说的原因：承认判断变化，甚至承认自己看错了，从来不是件轻松的事。对有影响力的人来说，这不只是交易决策，还关系到外部形象、市场解读，甚至后续连锁反应。所以很多人会选择安静地调整，而不是高调地改口。\u003c/p\u003e\n\u003cp\u003e巴菲特当年减持中石油，就是一个典型例子。他并不是一边高喊“永远不卖”，一边突然情绪化离场，而是在规则允许的空间里，尽量平稳地完成退出。\u003c/p\u003e\n\u003cp\u003e这其实提醒我们一件很重要的事：长期主义更应该对应的是方法和标准，不是某个具体代码。企业护城河变了，原先的判断失效了，或者出现了更好的机会，卖出本来就是投资的一部分。把“长期持有”理解成永不修正，反而容易把投资做成信仰。\u003c/p\u003e\n\u003ch2 id=\"4-你以为自己买的是公司很多时候买到的只是结构\"\u003e4. 你以为自己买的是公司，很多时候买到的只是结构\u003c/h2\u003e\n\u003cp\u003e很多普通投资者会天然觉得，买股票就是买公司的一部分。这在很多市场里大体成立，但一旦落到中概股、VIE 这些具体结构上，事情就没那么简单了。\u003c/p\u003e\n\u003cp\u003e像阿里、腾讯这类中概资产，海外投资者通常并不是直接持有中国境内运营实体的股权，而是持有开曼等地的壳公司权益，再通过一套协议安排，把收益权和控制关系间接连接起来。这套结构大家都很熟，它也确实运转了很多年，但它和“直接拥有公司股权”并不是一回事。\u003c/p\u003e\n\u003cp\u003e问题不一定天天发生，可一旦发生，往往就不是小事。2011 年支付宝股权调整，就是很多人后来反复提起的例子。那次事件至少说明了一点：当法律结构、监管边界和商业利益发生冲突时，纸面上的安排未必总能像你想象得那样稳定。\u003c/p\u003e\n\u003cp\u003e所以，买这类资产时，不能只看业务、用户、利润，还得看自己到底持有什么。你持有的，可能不是那家公司的“身体”，而更像是一套对它收益拥有索取权的安排。平时它看起来和股权差不多，但在关键时刻，两者未必等价。\u003c/p\u003e\n\u003cp\u003e这不是说这类资产不能投，而是说，风险不能只按财务报表来理解。法律结构本身，也应该进入估值。\u003c/p\u003e\n\u003ch2 id=\"5-真正有用的常常不是更复杂的招式而是更重的框架\"\u003e5. 真正有用的，常常不是更复杂的招式，而是更重的框架\u003c/h2\u003e\n\u003cp\u003e武侠小说里讲“重剑无锋，大巧不工”，意思不是招式越少越好，而是当一个人的内力、判断和节奏感足够稳定时，反而不需要太多花哨动作。\u003c/p\u003e\n\u003cp\u003e投资也有点像这样。\u003c/p\u003e\n\u003cp\u003e市场价格不会长期停在一个“刚刚好”的位置，它总是在情绪推动下左右摆动，时而过热，时而过冷。与其追着这些摆动跑，不如先看大的方向，再等小的回摆。\u003c/p\u003e\n\u003cp\u003e如果一定要把这个思路说得更具体一点，大概就是两层：先看长期趋势，再等短期波动。长期趋势决定这是不是一门值得长期站着的生意，短期波动决定你是不是有更舒服的价格进去。\u003c/p\u003e\n\u003cp\u003e均线也好，趋势也好，在这里并不是神秘工具，而是一种帮你看清节奏的简化框架。它没有那么性感，但有时正因为简单，反而更能约束动作。\u003c/p\u003e\n\u003cp\u003e投资里最难的部分，很多时候不是“看懂”，而是“等到”。明知是好公司，却忍不住在情绪最热的时候追进去；明知价格已经偏离很多，却总觉得它还能再涨一点。这种时候，简单的方法未必显得聪明，但往往更有用。\u003c/p\u003e\n\u003ch2 id=\"写在最后\"\u003e写在最后\u003c/h2\u003e\n\u003cp\u003e如果把这几件事放在一起看，会发现一个很朴素的结论：投资从来不只是选股票，它更像是在处理自己和风险、价格、法律结构、现金流之间的关系。\u003c/p\u003e\n\u003cp\u003e段永平的案例之所以值得看，未必是因为它足够传奇，而是因为它把很多平时被忽略的前提放大了。比如，心态背后其实有财务基础，长期持有背后其实有退出判断，所谓“拥有”背后其实有法律边界。\u003c/p\u003e\n\u003cp\u003e说到底，真正重要的也许不是你能不能找到下一只十倍股，而是你有没有能力分清，什么是公司本身，什么只是市场情绪；什么是长期逻辑，什么只是短期叙事；什么是你真的持有，什么只是你以为自己持有。\u003c/p\u003e\n\u003cp\u003e对投资者来说，最基本也最宝贵的自由，始终还是那件事：当逻辑变了，你有权离开。\u003c/p\u003e","title":"聊聊段永平，也聊聊投资里的几个误区"},{"content":"日常用 Claude Code / Codex时，我会先配几条 alias，跳过频繁的权限确认。\n配置 alias ccd=\u0026#34;claude --dangerously-skip-permissions\u0026#34; alias codex=\u0026#34;codex --ask-for-approval never --sandbox danger-full-access\u0026#34; ","permalink":"http://foxden.vault2049.xyz/tech/claude-code-aliases/","summary":"\u003cp\u003e日常用 Claude Code / Codex时，我会先配几条 alias，跳过频繁的权限确认。\u003c/p\u003e\n\u003ch2 id=\"配置\"\u003e配置\u003c/h2\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ealias ccd\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;claude --dangerously-skip-permissions\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ealias codex\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;codex --ask-for-approval never --sandbox danger-full-access\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e","title":"Claude Code：我在用的几个 alias"},{"content":"andrej-karpathy-skills Andrej Karpathy 曾是 OpenAI 早期成员，也在 Tesla 负责过 AI 相关工作，对大模型和工程实践都有很深的理解。这个 skill 很像是把他对 AI 编码的思考，整理成一套更可复用的行为规则：先理解问题，再动手修改；优先选择简单方案，避免过度设计；只改真正需要改的部分，尽量减少对现有系统的扰动。\nGitHub：https://github.com/forrestchang/andrej-karpathy-skills\neverything-claude-code 这个仓库把自己定义为一个面向 Claude Code、Codex、Cursor、OpenCode 等工具的“agent harness performance optimization system”，覆盖 skills、memory、security、hooks、rules 和 research-first development, 将这些能力整合成一个完整的系统。\n作者本人长期在 Claude Code 和自动化系统方向实践，这套配置是作者真实开发中持续打磨出来的一套 AI coding workflow。\n总结：非常全面，如果在做开发时不知道装什么，那就选择这个吧。个人会觉得有些heavy了，会选择Manual Installation，挑一些我自己用到的部份。\nGitHub：https://github.com/affaan-m/everything-claude-code\nsuperpowers Superpowers 不是单个 skill，更像是一套给 coding agent 用的软件开发方法论。它从 agent 启动时就开始接管流程：先确认你到底要做什么，再把需求拆成可读的设计说明；设计确认后，继续拆成足够细的执行计划；真正写代码时，用 TDD、代码评审、验证和分支收尾约束 agent，不让它凭感觉一路改下去。\n它的核心价值不是多装几个命令，而是让 coding agent 形成固定工作流。比如新功能先 brainstorming，再 writing-plans；实现阶段走 test-driven-development；复杂任务交给 subagent-driven-development 或 executing-plans；做完后用 requesting-code-review 和 verification-before-completion 检查，最后用 finishing-a-development-branch 收尾。\nGitHub：https://github.com/obra/superpowers\n基础流程 brainstorming：需求还不清楚时用，先确认目标、边界、取舍和备选方案。 using-git-worktrees：方案确认后用，给任务开独立 worktree，避免污染当前工作区。 writing-plans：把已确认的方案拆成具体任务，每一步要有文件路径、操作说明和验证方式。 subagent-driven-development：按计划派发子 agent 执行任务，适合步骤多、上下文容易混乱的开发。 executing-plans：按计划分批执行，适合需要人工检查点的任务。 test-driven-development：实现功能或修 bug 前用，强制走 red、green、refactor。 requesting-code-review：阶段完成后用，先 review 再继续推进。 finishing-a-development-branch：整条开发分支完成后用，做最终验证、合并或 PR 决策、清理 worktree。 Skills Library 分类 Testing\ntest-driven-development：写实现前先写失败测试，避免 agent 先写一堆没有验证的代码。 Debugging\nsystematic-debugging：遇到报错、失败测试、异常行为时用，按现象、模式、假设、验证的顺序查根因。 verification-before-completion：准备说完成前用，要求拿证据证明问题真的修好，而不是只看起来修好。 Collaboration\nbrainstorming：把模糊想法整理成可执行方案。 writing-plans：把方案写成任务计划。 executing-plans：按计划执行，保留人工检查点。 dispatching-parallel-agents：多个独立任务可以并行时用，减少串行等待。 subagent-driven-development：让子 agent 按任务推进，并做规格符合性和代码质量两轮检查。 requesting-code-review：请求代码评审，按严重程度处理问题。 receiving-code-review：收到 review 意见后用，先理解问题，再决定是否修改。 using-git-worktrees：为并行开发创建隔离分支。 finishing-a-development-branch：开发分支收尾，确认测试、合并、PR 或丢弃策略。 Meta\nusing-superpowers：介绍 Superpowers 的技能系统，强调相关 skill 必须先调用。 writing-skills：创建或修改 skill 时用，保证新 skill 可测试、可复用、能跨 coding agent 工作。 常用命令 /brainstorming 我想给博客加站内搜索，先把方案讲清楚 /writing-plans 基于刚才确认的方案，拆成可执行步骤 /using-git-worktrees 给这个功能开一个独立 worktree /test-driven-development 为这个功能先写失败测试 /systematic-debugging 首页构建时报 RSS 错，先查根因 /dispatching-parallel-agents 这几个互不依赖的检查并行跑 /subagent-driven-development 按计划派发子任务实现 /executing-plans 按计划执行，阶段之间停下来让我确认 /requesting-code-review review 当前改动 /receiving-code-review 处理刚才的 review 意见 /verification-before-completion 确认这个问题是不是真的修好了 /finishing-a-development-branch 当前分支做最终收尾 /writing-skills 帮我写一个新的 skill workflow /requesting-code-review 描述你的 GOAL，请仔细审核这份代码 /systematic-debugging 找到问题的根因，尝试定位到具体代码。思考解决方案，再列出改进plan，写完后交给subagent再次检查，直到合格为止 mattpocock/skills Matt Pocock 是 Total TypeScript 的作者，这个仓库整理的是他自己每天在用的 Claude skills。现在 README 的定位更明确了：这些 skills 不是为了 vibe coding，而是把真实工程里的基本功拆成小而可组合的流程，方便你按项目需要改造。\n它和 GSD、BMAD、Spec-Kit 这类更重的流程不太一样。Matt 的思路不是让一套框架接管全部开发过程，而是把常见失败模式拆开处理：需求没对齐，就 grilling；术语混乱，就沉淀共享语言；代码跑不通，就补反馈环；代码变成泥球，就重新看模块边界。\nGitHub：https://github.com/mattpocock/skills\nEngineering setup-matt-pocock-skills：每个项目先跑一次，用来配置 issue tracker、triage labels、文档保存位置和领域文档布局。现在不少工程类 skills 都会依赖这份配置。 grill-with-docs：带文档沉淀的需求拷问。它会基于现有 domain model 追问方案，同时更新 CONTEXT.md 和 ADR。适合业务术语多、决策容易散在对话里的项目。 to-prd：把当前对话上下文整理成 PRD，并提交成 GitHub issue。它不再做长访谈，更像是把已经聊清楚的内容正式落文档。 to-issues：把 PRD、计划或规格拆成能独立领取的 issues。重点还是纵向切片，每个 issue 都应该能单独验证。 triage：用一套 triage role 状态机处理 issues。新版不再叫 triage-issue，更偏 issue 流转和分工管理。 tdd：按 red、green、refactor 节奏开发功能或修 bug。它强调一次一个 vertical slice，不鼓励一次性写一大堆测试。 diagnose：诊断 bug 和性能问题的流程，顺序是复现、最小化、假设、插桩、修复、补回归测试。这个比直接让 agent 猜原因稳很多。 zoom-out：让 agent 从局部代码里退出来，先解释模块关系、调用路径和系统背景。适合接手陌生代码，或者发现 agent 钻进局部细节出不来时用。 improve-codebase-architecture：寻找可以加深的模块边界，结合 CONTEXT.md 和 ADR 判断哪些接口该收窄。适合定期处理 agent 写代码带来的复杂度膨胀。 prototype：做一次性原型，用来验证状态流、业务逻辑或 UI 方向。它明确把原型当成临时设计工具，不是直接拿来进主线。 Productivity grill-me：不涉及代码时用的需求拷问。它会持续追问你的计划，直到关键分支和取舍都讲清楚。 caveman：极简沟通模式，去掉客套和解释，只保留技术信息。适合上下文吃紧，或者你只想要结论的时候用。 write-a-skill：创建新的 Claude skill。它会要求写清楚触发场景、目录结构、脚本需求，以及哪些内容该拆到 reference 文件里。 Misc / Personal git-guardrails-claude-code：给 Claude Code 配 hooks，阻止 git push、git reset --hard、git clean 这类危险命令。适合想给 agent 加本地安全护栏的时候用。 setup-pre-commit：配置 Husky、lint-staged、Prettier、typecheck 和 tests。适合项目还没有提交前检查机制的时候用。 migrate-to-shoehorn：把测试文件里的 as 类型断言迁移到 @total-typescript/shoehorn。它只适合 TypeScript 测试代码。 scaffold-exercises：创建课程练习目录、题目、答案和讲解文件，更贴 Matt 自己的课程工作流。 edit-article 和 obsidian-vault：放在 personal 目录下，明显偏作者个人使用习惯。除非你的写作流程和 Obsidian vault 结构接近，否则不需要优先装。 已经 deprecated 的几个 design-an-interface、request-refactor-plan、qa、ubiquitous-language 已经移到 deprecated 目录。旧文章里我原本把它们当成主力技能，现在看应该降级处理。接口设计和领域语言这两块并没有消失，而是被并进了 grill-with-docs、tdd、improve-codebase-architecture 这些更完整的流程里。\n我会优先装的几个 日常开发里，最值得先装的是 setup-matt-pocock-skills、grill-with-docs、tdd、diagnose、to-prd、to-issues、zoom-out 和 improve-codebase-architecture。这几个覆盖了需求澄清、文档沉淀、测试驱动、问题诊断、任务拆分、陌生代码理解和架构收敛。\n如果项目里 issue 流量比较大，再加 triage。如果经常需要验证设计方向，可以加 prototype。本地安全和提交质量这块，可以按需装 git-guardrails-claude-code 和 setup-pre-commit。\n","permalink":"http://foxden.vault2049.xyz/tech/skills/","summary":"\u003ch2 id=\"andrej-karpathy-skills\"\u003eandrej-karpathy-skills\u003c/h2\u003e\n\u003cp\u003eAndrej Karpathy 曾是 OpenAI 早期成员，也在 Tesla 负责过 AI 相关工作，对大模型和工程实践都有很深的理解。这个 skill 很像是把他对 AI 编码的思考，整理成一套更可复用的行为规则：先理解问题，再动手修改；优先选择简单方案，避免过度设计；只改真正需要改的部分，尽量减少对现有系统的扰动。\u003c/p\u003e\n\u003cp\u003eGitHub：\u003ccode\u003ehttps://github.com/forrestchang/andrej-karpathy-skills\u003c/code\u003e\u003c/p\u003e\n\u003ch2 id=\"everything-claude-code\"\u003eeverything-claude-code\u003c/h2\u003e\n\u003cp\u003e这个仓库把自己定义为一个面向 Claude Code、Codex、Cursor、OpenCode 等工具的“agent harness performance optimization system”，覆盖 skills、memory、security、hooks、rules 和 research-first development, 将这些能力整合成一个完整的系统。\u003c/p\u003e\n\u003cp\u003e作者本人长期在 Claude Code 和自动化系统方向实践，这套配置是作者真实开发中持续打磨出来的一套 AI coding workflow。\u003c/p\u003e\n\u003cp\u003e总结：非常全面，如果在做开发时不知道装什么，那就选择这个吧。个人会觉得有些heavy了，会选择Manual Installation，挑一些我自己用到的部份。\u003c/p\u003e\n\u003cp\u003eGitHub：\u003ccode\u003ehttps://github.com/affaan-m/everything-claude-code\u003c/code\u003e\u003c/p\u003e\n\u003ch2 id=\"superpowers\"\u003esuperpowers\u003c/h2\u003e\n\u003cp\u003eSuperpowers 不是单个 skill，更像是一套给 coding agent 用的软件开发方法论。它从 agent 启动时就开始接管流程：先确认你到底要做什么，再把需求拆成可读的设计说明；设计确认后，继续拆成足够细的执行计划；真正写代码时，用 TDD、代码评审、验证和分支收尾约束 agent，不让它凭感觉一路改下去。\u003c/p\u003e\n\u003cp\u003e它的核心价值不是多装几个命令，而是让 coding agent 形成固定工作流。比如新功能先 \u003ccode\u003ebrainstorming\u003c/code\u003e，再 \u003ccode\u003ewriting-plans\u003c/code\u003e；实现阶段走 \u003ccode\u003etest-driven-development\u003c/code\u003e；复杂任务交给 \u003ccode\u003esubagent-driven-development\u003c/code\u003e 或 \u003ccode\u003eexecuting-plans\u003c/code\u003e；做完后用 \u003ccode\u003erequesting-code-review\u003c/code\u003e 和 \u003ccode\u003everification-before-completion\u003c/code\u003e 检查，最后用 \u003ccode\u003efinishing-a-development-branch\u003c/code\u003e 收尾。\u003c/p\u003e\n\u003cp\u003eGitHub：\u003ccode\u003ehttps://github.com/obra/superpowers\u003c/code\u003e\u003c/p\u003e\n\u003ch3 id=\"基础流程\"\u003e基础流程\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003ebrainstorming\u003c/code\u003e：需求还不清楚时用，先确认目标、边界、取舍和备选方案。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eusing-git-worktrees\u003c/code\u003e：方案确认后用，给任务开独立 worktree，避免污染当前工作区。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ewriting-plans\u003c/code\u003e：把已确认的方案拆成具体任务，每一步要有文件路径、操作说明和验证方式。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esubagent-driven-development\u003c/code\u003e：按计划派发子 agent 执行任务，适合步骤多、上下文容易混乱的开发。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eexecuting-plans\u003c/code\u003e：按计划分批执行，适合需要人工检查点的任务。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003etest-driven-development\u003c/code\u003e：实现功能或修 bug 前用，强制走 red、green、refactor。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003erequesting-code-review\u003c/code\u003e：阶段完成后用，先 review 再继续推进。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003efinishing-a-development-branch\u003c/code\u003e：整条开发分支完成后用，做最终验证、合并或 PR 决策、清理 worktree。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"skills-library-分类\"\u003eSkills Library 分类\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eTesting\u003c/strong\u003e\u003c/p\u003e","title":"Skills：最近常用的几个skill"},{"content":"Foxden 是我用来记录技术、生活和长期经验沉淀的地方。\n这里不会追求把一切都写成完整结论，更像是把那些最后真的留下来的东西慢慢整理清楚：一次判断、一套方法、一段阶段性的变化，或者一个以后还会再回来的问题。\n如果一篇文章能让我未来少踩一次坑，或者更清楚地看懂一段正在发生的变化，它就值得被写下来。\n","permalink":"http://foxden.vault2049.xyz/about/","summary":"\u003cp\u003eFoxden 是我用来记录技术、生活和长期经验沉淀的地方。\u003c/p\u003e\n\u003cp\u003e这里不会追求把一切都写成完整结论，更像是把那些最后真的留下来的东西慢慢整理清楚：一次判断、一套方法、一段阶段性的变化，或者一个以后还会再回来的问题。\u003c/p\u003e\n\u003cp\u003e如果一篇文章能让我未来少踩一次坑，或者更清楚地看懂一段正在发生的变化，它就值得被写下来。\u003c/p\u003e","title":"About"}]