<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <author>
    <name>hisenyuan</name>
  </author>
  <generator uri="https://hexo.io/">Hexo</generator>
  <id>https://hisen.me/</id>
  <link href="https://hisen.me/" rel="alternate"/>
  <link href="https://hisen.me/atom.xml" rel="self"/>
  <rights>All rights reserved 2026, hisenyuan</rights>
  <subtitle>hisenyuan's Blog</subtitle>
  <title>HiSEN</title>
  <updated>2026-09-15T16:45:23.930Z</updated>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="架构" scheme="https://hisen.me/tags/%E6%9E%B6%E6%9E%84/"/>
    <category term="安全" scheme="https://hisen.me/tags/%E5%AE%89%E5%85%A8/"/>
    <content>
      <![CDATA[<blockquote><p>一篇关于 AI API 中转站的调研，约 1.2 万字。<br>从一条 6TB 数据泄露的推文说起，往下分三块：</p><ul><li>这门生意怎么赚钱（第 2 节）</li><li>系统怎么运转（第 3 节）</li><li>要做成一个安全可靠的版本还缺什么（第 4、5 节）。</li></ul><p>只想看结论，跳到 5.7 的架构图。<br>整篇下来最难的不是转发，是计费：上游余额根本查不准，只能估算加对账。</p></blockquote><h1 id="1-起因"><a href="#1-起因" class="headerlink" title="1. 起因"></a>1. 起因</h1><p>2026 年 9 月，安全研究员寿超璠在 X 上发了条推文。他花五位数美元，从国内一家头部大模型中转站买到了一批约 6TB 的调用数据。</p><p>数据没脱敏。里面有 SSH 密钥、VPN 配置、阿里云密钥、GitLab token。按他本人的说法，仅凭这批凭证就能接管 19 家中国企业（含小米、华为、蔚来）和 7 个中国及独联体政府机构。这家平台不只囤日志，还把它当微调语料在黑灰市场出售。</p><span id="more"></span><p>真正让我停下来的是这些数据怎么来的。中转站没被攻破，是那些公司的开发者自己把密钥写进 prompt 发过去的。中转站照单全收，存下来，再拿出去卖。</p><p>要理解这件事，得先知道这门生意是怎么赚钱的。</p><h1 id="2-这门生意靠什么活着"><a href="#2-这门生意靠什么活着" class="headerlink" title="2. 这门生意靠什么活着"></a>2. 这门生意靠什么活着</h1><p>AI API 中转站是夹在用户和模型厂商之间的代理层：请求先到中转服务器，中转站用自己持有的 key 调官方接口，再把结果返回。它解决支付、网络、多模型统一接口三件事。</p><p>按 key 来源分两类，官转（正规官方 key，效果等同官方）和混合（混用逆向渠道，质量不稳）。按合规程度分三级：</p><table><thead><tr><th>类型</th><th>代表</th><th>特征</th></tr></thead><tbody><tr><td>云厂商合规聚合</td><td>移动 MoMA、阿里云百炼、火山方舟</td><td>有资质，走对公</td></tr><tr><td>正规 API 代理</td><td>OpenRouter 一类</td><td>官方或云厂商上游，信息透明</td></tr><tr><td>灰黑产中转站</td><td>“1 元 285 万 token”那类</td><td>共享账号池、爬虫逆向、封号率高、无售后</td></tr></tbody></table><p>这个市场靠三个差活着：</p><ul><li>准入差（海外支付、实名、地区限制）</li><li>价格差（批量折扣、缓存、渠道报价不同）</li><li>便利差（一个 key 打通多家）。</li></ul><p>技术重心因此偏向计费精确和多租户隔离，而不是高可用。后面所有设计，根子都在这里。</p><h2 id="2-1-正规路径"><a href="#2-1-正规路径" class="headerlink" title="2.1 正规路径"></a>2.1 正规路径</h2><p>正规路径赚的是批发零售的差价，三块收入。</p><p>批量折扣最基础。OpenAI Batch 和 Anthropic Message Batches 都是输入输出各打五折，还能跟缓存叠加。</p><p>缓存套利最容易被忽略，上游对命中缓存的输入只收一折：</p><table><thead><tr><th></th><th>倍率</th></tr></thead><tbody><tr><td>缓存写（5 分钟）</td><td>1.25×</td></tr><tr><td>缓存写（1 小时）</td><td>2×</td></tr><tr><td>缓存读</td><td>0.1×</td></tr></tbody></table><p>按原价卖给用户，中间九成就是利润。</p><p>渠道差价是同一模型在官方直连、Bedrock、Vertex 的报价不同，路由到便宜的。订阅制包月则是赌用户用不满。</p><h2 id="2-2-灰色地带"><a href="#2-2-灰色地带" class="headerlink" title="2.2 灰色地带"></a>2.2 灰色地带</h2><p>第一条推文里的那家平台，就属于这一层。而且它不是孤例，有实测数据。</p><p>2026 年 4 月的论文《Your Agent Is Mine》测了 428 个 API 路由器：9 个主动篡改 Agent 指令注入恶意代码，17 个接触并实际调用了研究者埋的 AWS 凭证，1 个转走了测试钱包的 ETH。</p><p>德国 CISPA 审计了 17 家中转站，归纳出偷换的三条路径：信息溢价（强模型换弱版）、折扣替换（按官方价收费，后端是开源小模型）、转售加价（加价同时暗中降级）。</p><p>降智能量化。医疗问答基准上 Gemini-2.5-flash 官方准确率 83.82%，被测中转站普遍约 37%。GPQA 的 1273 条 GPT-5 查询，用户付 14.84 美元，实际只拿到 5.70 到 7.77 美元的价值。</p><p>逆向是抓包 IDE 插件（Codex、Claude Code）的协议，把只卖给单个会员的额度转给多人。便宜，但内置别人的系统提示词，官方一封就停。</p><p>识别有四条探针：</p><ul><li>缓存真假。发两次完全相同的长前缀请求，看第二次的 <code>cache_read_input_tokens</code> 是否大于 0</li><li>模型真假。给一个暗号要求原样复述，暗号没回来，或者返回的 model 字段对不上，就是被偷换了</li><li>上游来源。看响应头，有 <code>anthropic-*</code> 或 <code>request-id</code> 是官方直连，<code>x-amzn</code> 是 Bedrock，只剩 <code>server: nginx</code> 说明上游头被中转站清掉了</li><li>是否逆向。不发 system，直接问它是不是被设定成编程助手，自称 Claude Code 之类就是反代了别人的订阅</li></ul><h2 id="2-3-黑产"><a href="#2-3-黑产" class="headerlink" title="2.3 黑产"></a>2.3 黑产</h2><p>黑产一边是薅平台的额度，一边是经营者自己的刑事风险。</p><p>薅额度靠后付费吃霸王餐、教育邮箱蹭学生优惠、盗刷信用卡、批量注册，催生大量存活几小时的”日抛号”。</p><p>刑事风险已是现实。2026 年 5 月上海一名中转站站长被刑拘 37 天后转取保候审，可能涉非法经营罪，模式是反向代理加账号池。引用罪名还有帮信罪、侵犯公民个人信息罪等。反面判例也有：首例 GPT 镜像站案因证据不足不起诉，理由是单纯接口转发和侵入系统有本质区别。</p><p>洗钱这条查不到具体判例，只有间接线索（用盗刷信用卡获取的额度可能触犯掩饰隐瞒犯罪所得罪）。”中转站是洗钱通道”的说法缺少证据支撑。</p><h1 id="3-中转站是怎么运转的"><a href="#3-中转站是怎么运转的" class="headerlink" title="3. 中转站是怎么运转的"></a>3. 中转站是怎么运转的</h1><p>看清了生意，再看机器。这类系统目前最常见的开源实现是 New API，基于 One API 二次开发，定位是 LLM 网关加 AI 资产管理。</p><h2 id="3-1-分层与代码结构"><a href="#3-1-分层与代码结构" class="headerlink" title="3.1 分层与代码结构"></a>3.1 分层与代码结构</h2><p>后端 Go 加 Gin，ORM 用 GORM（支持 SQLite、MySQL、PostgreSQL，日志可走 ClickHouse），缓存用 Redis，授权用 Casbin 加 JWT，计费用 shopspring&#x2F;decimal 做精确小数。前端是 React 19 加 TypeScript，构建产物用 <code>go:embed</code> 嵌进 Go 二进制，部署就是一个文件。</p><p>整体的分层是这样：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br></pre></td><td class="code"><pre><span class="line">┌─ 接入 ──────────────────────────────────────────</span><br><span class="line">│  客户端：OpenAI / Claude / Gemini 协议</span><br><span class="line">├─ 网关 ──────────────────────────────────────────</span><br><span class="line">│  middleware/：TokenAuth → 限流 → Distribute</span><br><span class="line">├─ 业务 ──────────────────────────────────────────</span><br><span class="line">│  controller/ + service/：用户 · 渠道 · Token · 计费 · 授权</span><br><span class="line">├─ 代理 ──────────────────────────────────────────</span><br><span class="line">│  relay/ 40+ 供应商适配器   relaykit/ 协议互转</span><br><span class="line">├─ 存储 ──────────────────────────────────────────</span><br><span class="line">│  model/ GORM（MySQL / PostgreSQL / ClickHouse）</span><br><span class="line">│  Redis（配额 · 限流 · 亲和性）</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>要找地方改代码，按这张表：</p><table><thead><tr><th>目录</th><th>职责</th></tr></thead><tbody><tr><td><code>router/</code></td><td>路由注册，分管理 API、仪表盘、代理、任务、前端 SPA 五组</td></tr><tr><td><code>middleware/</code></td><td>TokenAuth、限流、渠道分发等约 40 个文件</td></tr><tr><td><code>controller/</code></td><td>HTTP 处理器，120 多个文件</td></tr><tr><td><code>relay/</code></td><td>核心代理引擎，含 40 多个供应商适配器</td></tr><tr><td><code>relaykit/</code></td><td>独立模块，OpenAI&#x2F;Claude&#x2F;Gemini 三种协议互转</td></tr><tr><td><code>service/</code></td><td>业务逻辑，含 Casbin 授权</td></tr><tr><td><code>model/</code></td><td>GORM 数据模型，100 多个文件</td></tr><tr><td><code>setting/</code></td><td>配置子系统，计费表达式和倍率在这里</td></tr><tr><td><code>plugins/</code></td><td>内置 JS 任务插件</td></tr></tbody></table><h2 id="3-2-一次请求的完整链路"><a href="#3-2-一次请求的完整链路" class="headerlink" title="3.2 一次请求的完整链路"></a>3.2 一次请求的完整链路</h2><p>以 <code>POST /v1/chat/completions</code> 为例：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br></pre></td><td class="code"><pre><span class="line">┌─ 请求链路 ──────────────────────────────────────</span><br><span class="line">│</span><br><span class="line">│  客户端请求</span><br><span class="line">│      ↓</span><br><span class="line">│  ① TokenAuth     提取 key · 查表校验 · 注入 Context</span><br><span class="line">│      ↓</span><br><span class="line">│  ② 限流           用户 × 模型 滑动窗口 + 令牌桶</span><br><span class="line">│      ↓</span><br><span class="line">│  ③ Distribute     解析模型名 · 查 Token 模型限制 · 选渠道</span><br><span class="line">│      ↓</span><br><span class="line">│  ④ Relay Handler  判断协议 · 选适配器 · 转换请求</span><br><span class="line">│      ↓</span><br><span class="line">│  ⑤ 上游转发       加认证头 · 发 HTTP 请求</span><br><span class="line">│      ↓</span><br><span class="line">│  ⑥ 响应处理       转回客户端格式 · 计费 · 写日志 · 更新健康度</span><br><span class="line">│      ↓</span><br><span class="line">│  SSE 逐 chunk 写回</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>中间件链是短路的，任何一环失败立即返回，不浪费后续资源。</p><p>第 ③ 步的渠道选择是核心，顺序固定：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br></pre></td><td class="code"><pre><span class="line">┌─ 渠道选择（Distribute）─────────────────────────</span><br><span class="line">│</span><br><span class="line">│  ① 亲和性缓存命中？</span><br><span class="line">│       ├─ 是 → 复用上次成功的渠道（省去切换开销）</span><br><span class="line">│       └─ 否 ↓</span><br><span class="line">│  ② 过滤候选渠道</span><br><span class="line">│       剔除：已禁用 / 超时 / 余额不足 / 已熔断 / 不支持该模型</span><br><span class="line">│           ↓</span><br><span class="line">│  ③ 按渠道权重加权随机抽取</span><br><span class="line">│           ↓</span><br><span class="line">│  ④ 调上游</span><br><span class="line">│       ├─ 失败 → 标记该渠道不健康 → 回 ② 换一个</span><br><span class="line">│       └─ 成功 ↓</span><br><span class="line">│  ⑤ 写回亲和性缓存 · 结算 · 记日志</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>亲和性缓存是 Redis 里的一个键值，记的是「这个用户加这个模型上次走通了哪个渠道」。有了它，同一用户的连续请求会落回同一个上游，prompt 缓存才命得中；不然请求被打散，每次都像新对话。</p><p>熔断保护的是网关自己。某个渠道连续失败到阈值，就先把它从候选里摘掉，过一阵放一个请求过去试探，通了再加回来，免得一直往已经挂掉的上游发请求。</p><p>适配器是统一接口，每个供应商实现同一组方法：拿渠道名、构造上游 URL、设置认证头、请求转换、执行请求、响应转换、返回支持的模型列表。加新供应商就是实现这一套。渠道还能配模型名映射（<code>gpt-4</code> 映射到 <code>gpt-4-0613</code>）和参数覆盖（强制某个 temperature）。</p><h2 id="3-3-计费：一本双向的账"><a href="#3-3-计费：一本双向的账" class="headerlink" title="3.3 计费：一本双向的账"></a>3.3 计费：一本双向的账</h2><p>中转站的钱包不止一个。用户那侧是应收账款，上游账号池那侧是应付账款，两边都得看住，任何一侧失控都会直接变成故障或亏损。</p><h3 id="下游：预扣、结算、退款"><a href="#下游：预扣、结算、退款" class="headerlink" title="下游：预扣、结算、退款"></a>下游：预扣、结算、退款</h3><p>难点在于流式响应下 token 数要等上游返回 usage 才知道，那时资源已经消耗完了。不预扣等于先发货后收钱。</p><p>这套流程和电商库存扣减是同一个形状：下单时占住库存，支付确认后核销，超时没付再释放。换成配额，就是请求到达时预扣、上游返回 usage 后结算、请求失败则退还。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br></pre></td><td class="code"><pre><span class="line">┌─ 计费生命周期 ──────────────────────────────────</span><br><span class="line">│</span><br><span class="line">│  请求到达</span><br><span class="line">│      ↓</span><br><span class="line">│  按估算 token 预扣（Redis Lua 原子 check-and-deduct）</span><br><span class="line">│      ├─ 返回  1 → 转发上游</span><br><span class="line">│      ├─ 返回  0 → 拒绝请求（余额不足）</span><br><span class="line">│      └─ 返回 -1 → 缓存回填后重试 ──┐</span><br><span class="line">│                                     └──→ 回到预扣</span><br><span class="line">│  上游返回实际 usage</span><br><span class="line">│      ↓</span><br><span class="line">│  结算：delta = 实际 - 预扣</span><br><span class="line">│      ├─ delta &gt; 0 → 补扣</span><br><span class="line">│      └─ delta &lt; 0 → 退还</span><br><span class="line">│</span><br><span class="line">│  请求失败 ──→ 全额退还预扣（异步，不阻塞主流程）</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>Redis Lua 脚本在单线程内完成 check-and-deduct。脚本先校验缓存里的用户 ID 和 schema 版本防止串号，再判断余额，够了才扣。</p><p>返回 -1 表示缓存里没有这个用户的数据。这时要先把数据从 MySQL 读出来写进 Redis，再重试扣减，这一步叫缓存回填。回填也失败或者 Redis 本身异常，就降级到数据库的条件更新 <code>UPDATE quota = quota - ? WHERE quota &gt;= ?</code>。还有最后一种情况：Redis 扣成功但数据库写失败，需要补偿回滚 Redis。</p><p>费用全程用 decimal，避免多次浮点乘法累积误差。计费要处理多维度 token：基础 prompt、缓存命中、缓存创建、图片、音频各有倍率。而 OpenAI 和 Claude 的 usage 语义不同，前者 <code>prompt_tokens</code> 含子类要减，后者 <code>input_tokens</code> 是纯文本不用减，适配层要做归一化。</p><p>缓存上有个细节处理得不错：Token 缓存的 key 用 HMAC 签名而非明文，另设 10 秒变更围栏，元数据变更前先设围栏，防止”读到旧值写回覆盖变更”的竞态。</p><h3 id="上游：账号池与余额"><a href="#上游：账号池与余额" class="headerlink" title="上游：账号池与余额"></a>上游：账号池与余额</h3><p>下游管的是应收，上游管的是应付，而后者的难度高一个量级。</p><p>中转站天然持有多账号，因为单一上游账号有额度上限、地区限制和封号风险。账号多了要调度，而上游余额是个软状态。</p><p>最硬的事实是 OpenAI 根本没有官方余额接口。曾经可用的 <code>/dashboard/billing/credit_grants</code> 从 2023 年 4 月起只认浏览器 session key，不认 API key。社区只能拿 <code>/dashboard/billing/subscription</code> 的额度上限减去 <code>/dashboard/billing/usage</code> 的累计用量倒推。余额只能估算，必然漂移：上游扣费是异步的，估算和实际有时间差，检查余额和发出请求之间还有窗口期，并发下就会超支。</p><p>应对四个动作：监控（能查的定时查，不能查的按用量推算并记录偏差）、预检（请求前判断够不够）、切换（触底自动禁用渠道并路由到备用）、预警（低于阈值告警，留出人工充值时间）。</p><p>多账号之间调度余额，就是头寸管理：账户分散在不同机构，余额查不到实时值，要在不透支的前提下把请求路由到还有钱的那一个。做过支付或信贷的人对这套不陌生，只是这里的透支表现为上游返回 402，而不是账面上的负数。</p><p>这也解释了 3.2 里路由为什么能”过滤余额不足的渠道”——它过滤的正是这里推出来的估算余额。估算不准的时候，这道过滤就会失效。</p><h1 id="4-New-API-二次开发"><a href="#4-New-API-二次开发" class="headerlink" title="4. New API 二次开发"></a>4. New API 二次开发</h1><p>这一节说的是，如果要基于 New API 改一个自己的版本，哪些前提必须先知道。</p><h2 id="4-1-许可：AGPLv3-约束了什么"><a href="#4-1-许可：AGPLv3-约束了什么" class="headerlink" title="4.1 许可：AGPLv3 约束了什么"></a>4.1 许可：AGPLv3 约束了什么</h2><p>AGPLv3 是动手前必须过的第一关。它不归技术管，但直接决定你能怎么改。</p><p>One API 是 MIT，宽松，商用和闭源二次开发几乎不受限。但 New API 是 AGPLv3 加第 7 节附加条款：</p><ul><li>你修改后通过网络提供服务，必须向用户提供修改后版本的完整源代码</li><li>必须完整保留原有的品牌标识、LOGO 和版权声明，禁止修改、移除或遮盖</li></ul><p>想移除品牌、想闭源提供 SaaS、或者公司政策禁用 AGPL 软件，都得先买商业许可。很多人 fork 下来第一件事就是换 logo，那一步就已经违约了。</p><h2 id="4-2-值得改进的地方"><a href="#4-2-值得改进的地方" class="headerlink" title="4.2 值得改进的地方"></a>4.2 值得改进的地方</h2><p>规模上来才痛，不急但要知道：</p><ul><li>渠道全量加载到内存，上千条会有内存压力和启动延迟，该改成按需加载加 LRU</li><li>缺分布式追踪，客户端到网关到上游没有 trace，排障全靠日志拼</li><li>结构化日志不统一，部分代码还在拼字符串，建议都带上 request_id</li><li>连接池默认值要按负载调，<code>MaxOpenConns=1000</code> 偏高，可能打垮数据库</li></ul><p>要接新供应商就实现 <code>relay/channel/</code> 下的适配器接口，改计费规则看 <code>setting/billing_setting/</code> 的表达式和 <code>setting/ratio_setting/</code> 的倍率，要加协议互转改 <code>relaykit/relayconvert/</code> 的转换器注册表。</p><p>JS 插件值得一提：运行时是 Sobek（Grafana 的 JS 引擎），能在请求和响应阶段注入逻辑，不用重新编译 Go。加个用量审计或渠道筛选，走插件比改中间件轻。</p><h1 id="5-安全防护"><a href="#5-安全防护" class="headerlink" title="5. 安全防护"></a>5. 安全防护</h1><p>前面讲的都是系统按设计跑的情况。这一节说的是它会怎么出事，以及要补什么。</p><h2 id="5-1-计费风险"><a href="#5-1-计费风险" class="headerlink" title="5.1 计费风险"></a>5.1 计费风险</h2><p>机制在 3.3 讲过，这里说它会怎么出事。</p><p>下游被薅有三种方式：并发竞态（同一笔余额被多个请求同时预扣）、超时白嫖（请求超时但上游已产生费用）、重放。防御核心是预扣必须原子、结算以服务端收到的 usage 为准、失败必须退还。</p><p>上游有个容易被忽略的失败模式：余额耗尽时上游返回 402 或 429，用户看到的是”服务异常”，而不是”我们没钱了”。这个错误归属的错位，是很多中转站莫名抖动的根因。</p><p>路由层还有个必须讲透的风险。失败就换渠道重试，在成本压力下会自然退化成静默降级：贵的渠道没钱了自动切便宜的，用户拿到的东西变了但完全无感。这就是 2.2 里以次充好的技术实现路径。很多时候不是有人故意作恶，而是降级没有对用户可见。</p><h2 id="5-2-程序安全：已知漏洞"><a href="#5-2-程序安全：已知漏洞" class="headerlink" title="5.2 程序安全：已知漏洞"></a>5.2 程序安全：已知漏洞</h2><p>New API 有若干公开 CVE，两条直接打在钱上：</p><table><thead><tr><th>问题</th><th>影响版本</th><th>处理</th></tr></thead><tbody><tr><td>Stripe webhook 签名绕过（密钥为空），可伪造事件、无支付凭空充值</td><td>&lt; 0.12.10</td><td>升级到 0.12.10 以上，空密钥必须直接拒绝</td></tr><tr><td>计费模块整数溢出，可经 <code>max_tokens</code> 等参数触发</td><td>≤ 0.12.10</td><td>升级到 1.0.0-rc.18 以上</td></tr><tr><td>SSRF，内网地址过滤漏掉 <code>0.0.0.0</code></td><td>≤ 0.11.9-alpha.1</td><td>补齐内网地址黑名单</td></tr><tr><td>充值查询 SQL 注入</td><td>≤ 0.12.1</td><td>参数化查询</td></tr><tr><td>Midjourney 图片中继越权</td><td>≤ 0.12.1</td><td>升级到 0.12.2 以上</td></tr><tr><td>已吊销 token 的会话未失效</td><td>≤ 1.0.0-rc.15</td><td>升级到 1.0.0-rc.17 以上</td></tr><tr><td>Passkey 二次验证绕过，可泄露 root 级渠道密钥</td><td>≥ 0.10.0</td><td>暂时改用 TOTP，并限制相关端点</td></tr></tbody></table><p>第一条特别值得看。一个无支付充值的漏洞说明，计费安全不只是账算得准不准，是有人能凭空造钱。</p><p>这些 CVE 编号、影响版本和文件路径来自公开漏洞库的检索结果，上生产前建议去 GitHub Security Advisory 或 NVD 逐个核对。</p><p>还有三条不属于 CVE 但同样致命：CORS 放宽来源同时允许携带凭证，会危及已登录的管理后台会话；默认弱密码，初始 root 密码和 docker-compose 里数据库、Redis 密码是同一个弱口令；Panic 信息直接返回给客户端，泄露内部路径和变量名。</p><h2 id="5-3-加一层异步对账"><a href="#5-3-加一层异步对账" class="headerlink" title="5.3 加一层异步对账"></a>5.3 加一层异步对账</h2><p>上面都是修已知问题。New API 目前没有对账机制，这是我认为最该补的一项，也是 3.3 里那个余额漂移问题的兜底。</p><p>对账要覆盖三方数据：</p><table><thead><tr><th>数据源</th><th>内容</th><th>角色</th></tr></thead><tbody><tr><td>上游接口返回</td><td>usage 字段，或账单接口</td><td>权威源，但可能滞后</td></tr><tr><td>Redis</td><td>实时扣减后的余额</td><td>请求路径依赖它</td></tr><tr><td>MySQL</td><td>持久化余额和流水</td><td>最终账本</td></tr></tbody></table><p>三者本该一致，实际会因为缓存漂移、刷库丢失、上游扣费异步而产生差异。数据这样流转：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br></pre></td><td class="code"><pre><span class="line">┌─ 对账数据流转 ──────────────────────────────────</span><br><span class="line">│</span><br><span class="line">│  请求路径（同步，不阻塞）</span><br><span class="line">│    请求 → 预扣 / 结算 / 退款</span><br><span class="line">│              ├→ Redis 扣减</span><br><span class="line">│              ├→ MySQL 刷库</span><br><span class="line">│              └┈→ 消息队列（计费事件）</span><br><span class="line">│</span><br><span class="line">│  对账路径（异步）</span><br><span class="line">│    消息队列 → 消费者 → 对账表</span><br><span class="line">│</span><br><span class="line">│    定时比对，四个来源：</span><br><span class="line">│      · 对账表（本地逐笔明细）</span><br><span class="line">│      · 上游账单接口</span><br><span class="line">│      · Redis 余额</span><br><span class="line">│      · MySQL 余额</span><br><span class="line">│    差异超阈值 → 告警</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>关键在那条虚线。请求路径只做它本来该做的事，扣减和刷库照旧，顺手把计费事件丢进消息队列就返回。真正的比对全在另一条线上跑，请求路径上多一次同步校验就是多一份延迟和故障点。</p><p>比对两类东西。逐笔对账看同一笔请求的四个数字是否相等：上游返回的 usage、本地日志记录的 usage、Redis 的扣减量、MySQL 的扣减量，对不上就是漏记或虚报。余额对账看 Redis 缓存余额和 MySQL 实际余额的差值，超阈值告警。</p><p>对账本身是支付行业的标准动作：上游账单、本地流水、渠道回执三方比对，差一分钱都要查。这里只是把渠道回执换成了模型返回的 usage，道理一样。</p><p>配套还要把批量更新队列持久化。配额扣减现在攒在内存队列里批量刷库，进程一崩就丢，对账时会表现为凭空多出来的余额。要么写 WAL，要么走消息队列，跟对账共用一条链路最省事。</p><h2 id="5-4-凭据与隔离"><a href="#5-4-凭据与隔离" class="headerlink" title="5.4 凭据与隔离"></a>5.4 凭据与隔离</h2><p>上游 key 的存储和轮换要做到位，一个 key 泄露，爆炸半径是整条渠道。多租户隔离要保证一个用户的 token 不能看到或影响另一个。渠道密钥属于 root 级敏感信息，5.2 里那个 Passkey 绕过漏洞泄露的正是这个。</p><p>管道本身是明文的，中转站能看到用户发过去的一切。</p><h2 id="5-5-数据防护：让敏感信息不进管道"><a href="#5-5-数据防护：让敏感信息不进管道" class="headerlink" title="5.5 数据防护：让敏感信息不进管道"></a>5.5 数据防护：让敏感信息不进管道</h2><p>回到开头那 6TB。泄露的四类东西，SSH 密钥、VPN 配置、阿里云 key、GitLab token，全部是正则可检测的格式，只是没人做这层过滤。</p><p>三个位置，按对症程度排：</p><ul><li>日志层。6TB 是日志泄露的，不是实时拦截漏的。日志要么不落盘，要么落盘前脱敏，这条性价比最高</li><li>入口。prompt 进网关时扫描替换</li><li>出口。响应回来时还原占位符，并拦掉模型复述出来的敏感内容</li></ul><p>检测走两条路。正则挡结构化内容，5 到 10 毫秒，密钥类有固定写法可循：</p><ul><li>AWS：<code>AKIA</code> 加 16 位大写字母数字</li><li>OpenAI：<code>sk-</code> 开头</li><li>私钥：<code>-----BEGIN ... PRIVATE KEY-----</code></li><li>通用：<code>(password|secret|token|api[_-]?key)</code> 加等号或冒号</li></ul><p>NLP 模型（如 Presidio）抓人名、地址这类命名实体，但要 50 到 200 毫秒。</p><p>处理动作两种。Reject 直接拒绝返回 4xx；Mask 替换成占位符放行。可逆的 Mask 最有意思：把 <code>&lt;PERSON_1&gt;</code> 发给模型，映射表留本地，响应回来再还原。模型仍能理解上下文，真值从没出过网关。</p><p>流式还原是最大的坑。LiteLLM 有个真实 bug：Anthropic 原生路径下输入脱敏了，流式响应却从不还原，因为还原代码期望结构化对象，而 Anthropic 发的是原始 SSE 字节。根因是占位符会被切在两个 chunk 之间（<code>&lt;PER</code> 一个包，<code>SON_1&gt;</code> 下一个）。解法是 holdback：扫到未闭合的 <code>&lt;</code> 就扣住不输出，等 token 完整再判断。</p><p>三个容易忽略的细节：</p><ul><li>单次解码，不要级联替换，否则还原出来的值会被二次扫描破坏</li><li>碰撞预防，用户原文里本来就有 <code>&lt;PERSON_1&gt;</code> 这种字面量时不能误替换</li><li>容错匹配，模型可能改大小写或加 markdown 转义，认不出来的占位符原样保留，不要猜</li></ul><p>覆盖面要说清楚：多数实现只扫出站请求，不扫 system prompt 和工具调用参数，流式响应脱敏很多还在路线图上。它保护的是出口，agent 自己的上下文里仍有真值。</p><h2 id="5-6-可验证性：TEE-能让用户验什么"><a href="#5-6-可验证性：TEE-能让用户验什么" class="headerlink" title="5.6 可验证性：TEE 能让用户验什么"></a>5.6 可验证性：TEE 能让用户验什么</h2><p>5.5 是减少暴露面，这节是让”没暴露”可验证。</p><p>承诺有三个层次。隐私政策和 DPA 属协议层，用户只能信。第三方审计属制度层，审的是过程，不是每一次执行。TEE 属技术层，用户能自己验。</p><p>原理是 CPU 和 GPU 划出一块加密内存区，宿主机读不到，包括云厂商和运营方自己。硬件还会用烧录的密钥签一份报告，内容是当前运行的代码哈希，用户拿 Intel、AMD 或 NVIDIA 的公钥验签就能确认。前提是代码可复现构建、哈希有公开台账，否则那串哈希对应什么源码只有自己知道。连 Apple 的 Private Cloud Compute 都没做到，它的二进制无符号，模型和接口也没公开。</p><p>性能不再是障碍。H100 跑 70B 模型开销约 1.4%，Intel TDX 上 20B 到 70B 是 2% 到 3%，开销来自 CPU 和 GPU 之间的加密传输，模型越大摊得越薄。OLLM、RedPill、0G、NEAR 等已经在做，都兼容 OpenAI，换个 base URL 就能用。</p><p>但对中转站有个绕不开的边界。TEE 只覆盖经过网关的那一段，上游如果是官方 API，数据出了 enclave 就归上游。它能证明自己没偷看，证明不了上游没存，而这恰恰是用户最担心的那一半。要端到端可信只能用 TEE 内的开源模型，那等于换产品：从”绕过准入的便宜通道”变成”可验证的隐私推理服务”，客户也从薅羊毛的学生换成有合规压力的企业。</p><p>最后，TEE 只是把信任从运营方转移到 Intel、AMD、NVIDIA 的硬件上。TEE.Fail（2025 年 10 月）表明物理内存总线攻击可以伪造证明。</p><h2 id="5-7-改造后的整体架构"><a href="#5-7-改造后的整体架构" class="headerlink" title="5.7 改造后的整体架构"></a>5.7 改造后的整体架构</h2><p>把上面几节加的东西合起来，长这样（带加号的是要新增的）：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br></pre></td><td class="code"><pre><span class="line">┌─ 改造后的整体架构 ──────────────────────────────</span><br><span class="line">│</span><br><span class="line">│  客户端</span><br><span class="line">│     ↓</span><br><span class="line">│  接入层      TLS · 体积限制 · 超时设置</span><br><span class="line">│     ↓</span><br><span class="line">│  安全层 +    TokenAuth → 限流 → 敏感信息脱敏</span><br><span class="line">│              命中密钥或 PII → Reject 或 Mask</span><br><span class="line">│     ↓</span><br><span class="line">│  路由层      Distribute</span><br><span class="line">│              亲和性缓存 → 过滤 → 加权随机</span><br><span class="line">│     ↓</span><br><span class="line">│  计费层 +    预扣（Redis Lua）→ 上游 → 结算 → 退还</span><br><span class="line">│     ↓</span><br><span class="line">│  代理层      relay 适配器 → 协议转换 → 上游账号池</span><br><span class="line">│              渠道 key 只在内存，不落盘</span><br><span class="line">│     ↓</span><br><span class="line">│  出口层 +    占位符还原 · 流式 holdback · 日志脱敏</span><br><span class="line">│     ↓</span><br><span class="line">│  SSE 返回客户端</span><br><span class="line">│</span><br><span class="line">│  ┈┈ 异步旁路（不阻塞请求）┈┈</span><br><span class="line">│  计费事件 → 消息队列 → 对账表 → 定时比对 → 告警</span><br><span class="line">│</span><br><span class="line">│  存储   MySQL（用户 · Token · 渠道 · 日志 · 对账表）</span><br><span class="line">│         Redis（余额 · 限流 · 亲和性）</span><br><span class="line">└─────────────────────────────────────────────────</span><br></pre></td></tr></table></figure><p>改造集中在四个地方：入口的脱敏过滤器、计费的预扣与对账、出口的还原与日志脱敏、以及贯穿全链路的审计旁路。代理层和存储层基本不用动。</p><h1 id="6-回到开头"><a href="#6-回到开头" class="headerlink" title="6. 回到开头"></a>6. 回到开头</h1><p>那 6TB 数据里最值钱的东西，SSH 密钥、云厂商密钥、GitLab token，格式全都是公开的、固定的。它被泄露，是没人做这层过滤。</p><p>这是这次调研里我最没想到的部分。原以为难点在技术，实际三处难点都不在”转发请求”这个动作上：计费的余额查不准只能估算、用户习惯把密钥塞进 prompt、以及”我不卖数据”这句话至今没法让用户自己验证。</p><p>TEE 是目前唯一能把第三点变成可验证事实的路径，但它只能覆盖经过网关的那一段，而且连 Apple 都没做到可复现构建。</p><p>一个安全可靠的版本该补哪些东西，5.7 那张图是结论。</p><h1 id="7-参考"><a href="#7-参考" class="headerlink" title="7. 参考"></a>7. 参考</h1><ul><li><span class="exturl" data-url="aHR0cHM6Ly93d3cuc2VjcnNzLmNvbS9hcnRpY2xlcy85Mzg4NA==">安全内参<i class="fa fa-external-link-alt"></i></span> · 6TB 数据泄露，26 家校企系统被攻入</li><li><span class="exturl" data-url="aHR0cHM6Ly8zNmtyLmNvbS9wLzM5Nzg3MjcyNjQ2OTczNTI=">36氪<i class="fa fa-external-link-alt"></i></span> · 同一事件的中文报道</li><li><span class="exturl" data-url="aHR0cHM6Ly94LmNvbS9zaG91Y2NjYw==">@shoucccc<i class="fa fa-external-link-alt"></i></span> · 寿超璠的原始推文</li><li><span class="exturl" data-url="aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzI2MDQuMDg0MDc=">arXiv 2604.08407<i class="fa fa-external-link-alt"></i></span> · Your Agent Is Mine，428 个路由器的实测</li><li><span class="exturl" data-url="aHR0cHM6Ly9maW5hbmNlLnNpbmEuY24vMjAyNi0wNS0xMi9kZXRhaWwtaW5oeHJmc3A4NDAyMDQ0LmQuaHRtbA==">新浪财经<i class="fa fa-external-link-alt"></i></span> · CISPA 审计结论与降智量化数据</li><li><span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL2NvY29SYWluYS9haS1ndWlkZXMvYmxvYi9tYWluL3JlbGF5LWNoZWNrLWFuZC10b2tlbi1hdWRpdC5tZA==">cocoRaina&#x2F;ai-guides<i class="fa fa-external-link-alt"></i></span> · 中转站体检与 Token 对账，四条探针的出处</li><li><span class="exturl" data-url="aHR0cHM6Ly93d3cubWFua3VubGF3LmNvbS9pbnNpZ2h0cy9zaGFvLXNoaS13ZWktbHUtc2hpLWFpLXpob25nLXpodWFuLXpoYW4temhhbi16aGFuZy1iZWkteGluZy1qdS16dW9hcGktemhvbmctemh1YW4tZGFvLWRpLXdlaS1idS13ZWktZmEv">曼昆律所<i class="fa fa-external-link-alt"></i></span> · 上海站长被刑拘案的法律分析</li><li><span class="exturl" data-url="aHR0cHM6Ly9kb2MubmV3YXBpLnByby93aWtpL3Byb2plY3QtaW50cm9kdWN0aW9uLw==">New API 文档<i class="fa fa-external-link-alt"></i></span> · AGPLv3 与第 7 节附加条款</li><li><span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL1F1YW50dW1Ob3VzL25ldy1hcGk=">QuantumNous&#x2F;new-api<i class="fa fa-external-link-alt"></i></span> · 源码仓库</li><li><span class="exturl" data-url="aHR0cHM6Ly9udmQubmlzdC5nb3YvdnVsbi9kZXRhaWwvQ1ZFLTIwMjYtNDE0MzI=">NVD<i class="fa fa-external-link-alt"></i></span> · CVE-2026-41432，Stripe webhook 绕过</li><li><span class="exturl" data-url="aHR0cHM6Ly9hcHAub3BlbmN2ZS5pby9jdmUvQ1ZFLTIwMjYtNDIzMzk=">OpenCVE<i class="fa fa-external-link-alt"></i></span> · CVE-2026-42339（SSRF）等其余条目</li><li><span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL0JlcnJpQUkvbGl0ZWxsbS9pc3N1ZXMvMjI4MjE=">BerriAI&#x2F;litellm<i class="fa fa-external-link-alt"></i></span> · #22821，流式响应不还原占位符</li><li><span class="exturl" data-url="aHR0cHM6Ly9zZWN1cml0eS5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi9wcml2YXRlLWNsb3VkLWNvbXB1dGUv">Apple<i class="fa fa-external-link-alt"></i></span> · Private Cloud Compute 安全文档</li><li><span class="exturl" data-url="aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzI0MDkuMDM5OTI=">arXiv 2409.03992<i class="fa fa-external-link-alt"></i></span> · Hopper GPU 机密计算性能基准</li><li><span class="exturl" data-url="aHR0cHM6Ly9kb2NzLm9sbG0uY29tLw==">OLLM<i class="fa fa-external-link-alt"></i></span>、<span class="exturl" data-url="aHR0cHM6Ly9uZWFyLmFpLw==">NEAR AI Cloud<i class="fa fa-external-link-alt"></i></span> · 已在运行的 TEE 推理服务</li></ul><blockquote><p>CVE 编号与影响版本来自公开漏洞库检索，上生产前建议去 NVD 或 GitHub Security Advisory 逐个核对。</p></blockquote>]]>
    </content>
    <id>https://hisen.me/20260915-ai-api-relay-station/</id>
    <link href="https://hisen.me/20260915-ai-api-relay-station/"/>
    <published>2026-09-15T15:30:00.000Z</published>
    <summary>
      <![CDATA[<blockquote>
<p>一篇关于 AI API 中转站的调研，约 1.2 万字。<br>从一条 6TB 数据泄露的推文说起，往下分三块：</p>
<ul>
<li>这门生意怎么赚钱（第 2 节）</li>
<li>系统怎么运转（第 3 节）</li>
<li>要做成一个安全可靠的版本还缺什么（第 4、5 节）。</li>
</ul>
<p>只想看结论，跳到 5.7 的架构图。<br>整篇下来最难的不是转发，是计费：上游余额根本查不准，只能估算加对账。</p>
</blockquote>
<h1 id="1-起因"><a href="#1-起因" class="headerlink" title="1. 起因"></a>1. 起因</h1><p>2026 年 9 月，安全研究员寿超璠在 X 上发了条推文。他花五位数美元，从国内一家头部大模型中转站买到了一批约 6TB 的调用数据。</p>
<p>数据没脱敏。里面有 SSH 密钥、VPN 配置、阿里云密钥、GitLab token。按他本人的说法，仅凭这批凭证就能接管 19 家中国企业（含小米、华为、蔚来）和 7 个中国及独联体政府机构。这家平台不只囤日志，还把它当微调语料在黑灰市场出售。</p>]]>
    </summary>
    <title>LLM API 中转站数据泄密，剖析它背后的生意与技术</title>
    <updated>2026-09-15T16:45:23.930Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="架构" scheme="https://hisen.me/tags/%E6%9E%B6%E6%9E%84/"/>
    <content>
      <![CDATA[<h1 id="1-TT-开放平台都有哪些形态"><a href="#1-TT-开放平台都有哪些形态" class="headerlink" title="1. TT 开放平台都有哪些形态"></a>1. TT 开放平台都有哪些形态</h1><p>「TikTok 开放平台」在日常语境里被混着用，实际至少是五套平行体系，面向完全不同的人。</p><table><thead><tr><th>#</th><th>体系</th><th>面向谁</th><th>一句话</th></tr></thead><tbody><tr><td>①</td><td>开发者能力开放（TikTok for Developers）</td><td>所有注册开发者</td><td>开放 API&#x2F;SDK，把 TT 能力嵌进自己产品</td></tr><tr><td>②</td><td>小程序 &#x2F; 小游戏 &#x2F; 短剧（TikTok Minis）</td><td>内容方、游戏方、发行商</td><td>把 TT 当渠道，内容和交易都在 TT 内闭环</td></tr><tr><td>③</td><td>广告投放（Marketing API &#x2F; 代理商）</td><td>广告主、代理商</td><td>买 TT 的流量</td></tr><tr><td>④</td><td>电商服务商（TSP &#x2F; TAP &#x2F; MCN &#x2F; CAP）</td><td>代运营、撮合、经纪机构</td><td>帮商家在 TikTok Shop 卖货</td></tr><tr><td>⑤</td><td>达人营销（TikTok One）</td><td>品牌方、达人、MCN</td><td>品牌付钱找达人做内容</td></tr></tbody></table><p>这五套的开放程度是反着来的：</p><span id="more"></span><ul><li>① 最开放，自助注册，免费，但权限极小</li><li>②③④ 门槛最高，要境外主体、实缴资本、团队规模和审查，但能赚到钱</li><li>⑤ 免费，因为它的目的是放大 ③ 的消耗</li></ul><p>对写代码的人来说，能动手的只有 ①②。① 的问题在于拿不到数据：</p><ul><li>规模化读取公开资料</li><li>受众画像和竞品监控</li><li>话题分析和热门流</li><li>粉丝列表</li><li>超过一定时限的历史数据</li></ul><p>Display API 只能读授权用户自己的数据，没有官方接口能查任意公开账号。</p><p>所以真正的看点落在 ②。下面只讲 Minis。</p><h1 id="2-Minis-核心概念"><a href="#2-Minis-核心概念" class="headerlink" title="2. Minis 核心概念"></a>2. Minis 核心概念</h1><h2 id="2-1-是什么"><a href="#2-1-是什么" class="headerlink" title="2.1 是什么"></a>2.1 是什么</h2><p>Minis 是 TikTok 里内置的一块小程序区，跑在 TikTok 的 WebView 里。用户从搜索「Minis」或者个人主页菜单进去，玩游戏看短剧，全程不离开 TikTok，不装 App。</p><p>短剧板块 2025 年底上线，2026 年 1 月前后开放合作。</p><p>已开放市场包括美国、日本、印尼、泰国、菲律宾、越南、马来西亚、巴西、沙特、土耳其。</p><p>入口有三处：</p><ul><li>搜索「Minis」</li><li>个人主页菜单</li><li>首次使用后，个人主页自动生成的快捷方式</li></ul><p>内容分两条线。小游戏偏休闲益智和轻度模拟，短剧是竖屏、单集 60～90 秒，免费看前 8～10 集。两条线都还在早期扩张阶段。</p><p>这里纠一个容易混的：PineDrama 不是 Minis。那是 2025 年 12 月在美巴上线的独立短剧 App，主打免费无广告，跟 Minis 的付费模式是两条路。</p><h2 id="2-2-有哪些玩家"><a href="#2-2-有哪些玩家" class="headerlink" title="2.2 有哪些玩家"></a>2.2 有哪些玩家</h2><table><thead><tr><th>玩家</th><th>角色</th></tr></thead><tbody><tr><td>平台（TikTok &#x2F; 字节）</td><td>出流量和规则，收平台税</td></tr><tr><td>短剧内容方</td><td>ShortMax、NetShort、SnackShort 等 13 家已入驻</td></tr><tr><td>小游戏开发者</td><td>直接开发上架</td></tr><tr><td>引擎与工具方</td><td>Unity（官方 TikTokFunction 插件，包成 C# 方法）、Cocos Creator</td></tr><tr><td>C 端用户</td><td>付费方</td></tr></tbody></table><p>短剧这边有个值得注意的缺口：头部两家 ReelShort 和 DramaBox 都还没进来，目前入驻的都是第二梯队。</p><p>从平台视角，这几类里真正被争夺的是内容供给方。C 端用户是被内容吸引来的，不是被平台功能吸引来的。</p><h2 id="2-3-怎么玩"><a href="#2-3-怎么玩" class="headerlink" title="2.3 怎么玩"></a>2.3 怎么玩</h2><p>用户侧很简单：刷到一部剧或一个游戏，免费部分看完，弹出付费，留下继续看。</p><p>开发者侧是五步：</p><ol><li>注册开发者账号，创建组织</li><li>提交代表作链接做身份验证</li><li>开通 IAA &#x2F; IAP 变现，签合同</li><li>配置收款信息</li><li>开发调试、提审、发布</li></ol><p>两个容易翻车的点：组织名创建后不可修改，注册时就得想清楚；收款主体必须跟验证主体一致，对不上前面全白做。</p><p>技术侧的接入反而是最顺的。官方 CLI 叫 ttdx，常用三条命令：</p><ul><li><code>ttdx minis init</code>：建项目，生成配置文件</li><li><code>ttdx minis build:after</code>：构建</li><li><code>ttdx minis debug</code>：本地调试</li></ul><p>小游戏另有一组对应命令（<code>ttdx minigame init</code> &#x2F; <code>debug</code> &#x2F; <code>check</code>）。配置文件也分两套，小程序用 <code>minis.config.json</code>，管导航栏明暗和后端域名白名单；小游戏用 <code>minigame.config.json</code>。</p><p>命名空间这块值得单独说。官方 SDK 叫 Minis JSSDK，全局对象是 <code>TTMinis</code>，而 ByteDance 的文档写明 <code>TTMinis.game</code>、<code>tt</code>、<code>wx</code> 三者可以互换，同一个 login 方法三种写法都能调。也就是说，一套为微信小游戏写的代码，改改登录和支付就能搬过来。</p><p>沙箱有几条硬约束：</p><ul><li>产物包上限 50MB，超了直接拒绝上传，大资源要外置 CDN 并加白名单</li><li>禁用 eval 和 new Function</li><li>禁用 iframe</li><li>部分 DOM API 要走 SDK 桥接</li></ul><h2 id="2-4-怎么赚钱"><a href="#2-4-怎么赚钱" class="headerlink" title="2.4 怎么赚钱"></a>2.4 怎么赚钱</h2><p>变现分双轨。IAA 是激励视频和插屏广告，IAP 是用 Beans 付费解锁和订阅。</p><p>两条线的侧重不一样：短剧主要靠 IAP，用户为解锁剧情掏钱；小游戏主要靠 IAA，看广告换道具或复活。实际运营中常混用。</p><p>支付走 Beans，平台统一的虚拟货币。用户通过 App Store 或 Google Play 买 Bean 包，开发者用 Beans 定价，比如「解锁第 5 集 15 Beans」。</p><p>官方推荐的下单流程是三步：</p><ol><li>服务端下单。明令禁止在前端建单，由服务端调 TikTok Open API 拿到订单号</li><li>客户端拉起支付。把订单号传给前端，调 SDK 的支付方法</li><li>服务端 Webhook 验签后发货。收到支付成功事件后先验签、再核对订单号，然后才解锁内容</li></ol><p>官方说得很直接：不要依赖客户端的成功回调发货。</p><p>支付流有两个选项，官方强烈推荐第一个：</p><ul><li>充值和支付合并：余额不足时弹原生窗一步完成，降低流失</li><li>充值和支付分开：自己查余额再跳充值页，UI 可控但多一步</li></ul><p>定价上，短剧通常是前 8～10 集免费，单部约 10 美元以上，或者 40～80 美元包月。站内支付给约 10% 折扣，目的就是把支付留在 TikTok 内。</p><p>分成方面，官方从未公布过固定比例。多个 2026 年的报道说，接入 TikTok 内置广告平台（不是 Pangle 版位）广告单价较高，现阶段平台暂不抽佣。</p><p>平台自己的说法是风控、分成、审核这些机制仍在调整中。所以现在是个政策未定型的窗口期。</p><p>配套的投放工具也在铺。TikTok 已经推出 Growth Max for Mini Games，支持用广告收入作为目标来优化买量。</p><h1 id="3-平台需要做什么"><a href="#3-平台需要做什么" class="headerlink" title="3. 平台需要做什么"></a>3. 平台需要做什么</h1><p>这一节是我的判断，不是调研结论。会拿抖音做参照，因为 TikTok 不公布分成和规则细节，抖音是同源体系里唯一能查证的。</p><h2 id="3-1-开发者侧"><a href="#3-1-开发者侧" class="headerlink" title="3.1 开发者侧"></a>3.1 开发者侧</h2><p>分成政策得明确透明：开发者立项依赖精细算账。对比抖音的明码标价（即便条件严苛但具备可预期性），Minis 无法给出明确测算依据。</p><p>“暂不抽佣”潜藏长期风险：未落地的口头免佣实为最大不确定性，开发者担心平台随时改规或加收，削弱入局意愿。</p><p>出海门槛与合规路径模糊：目前自建海外主体成本过高，而通过代理上架又缺乏公开明确的资质规范。</p><p>规则缺乏稳定性打击长期投入：频繁且突兀的政策变动，直接瓦解了长周期内容开发者的规划信心与安全感。</p><h2 id="3-2-C-端侧"><a href="#3-2-C-端侧" class="headerlink" title="3.2 C 端侧"></a>3.2 C 端侧</h2><p>核心痛点在心智认知：海外缺乏在 App 内使用轻应用的习惯，Meta 2026 年 9 月 30 日关停 Web Games、Unity 移除支持等先例证明该模式在海外尚未跑通。</p><p>以商业利益置换入口：效仿抖音模式，将分成让利作为杠杆，驱动开发者配合将用户向平台核心入口导流。</p><p>现阶段战略是促活：</p><ul><li>培养消费习惯：通过降低支付门槛、合并支付与补贴折扣换取用户心智。</li><li>扩充生态供给：加速吸引开发者入驻以解决内容不足。</li><li>发力长留存品类：相比留存较差的短剧，重点扶持具备社交属性和高复访率的小游戏来稳固生态。</li></ul><hr><p>总的来说，技术这条路的接入成本比预期低，微信小游戏的代码基本能直接搬。<br>卡点在商业侧：分成不透明、主体门槛高、C 端还没形成在小程序里消费的习惯。适合当一次低成本的迁移试验。</p>]]>
    </content>
    <id>https://hisen.me/20260915-tiktok-minis-developer-notes/</id>
    <link href="https://hisen.me/20260915-tiktok-minis-developer-notes/"/>
    <published>2026-09-15T13:00:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-TT-开放平台都有哪些形态"><a href="#1-TT-开放平台都有哪些形态" class="headerlink" title="1. TT 开放平台都有哪些形态"></a>1. TT 开放平台都有哪些形态</h1><p>「TikTok 开放平台」在日常语境里被混着用，实际至少是五套平行体系，面向完全不同的人。</p>
<table>
<thead>
<tr>
<th>#</th>
<th>体系</th>
<th>面向谁</th>
<th>一句话</th>
</tr>
</thead>
<tbody><tr>
<td>①</td>
<td>开发者能力开放（TikTok for Developers）</td>
<td>所有注册开发者</td>
<td>开放 API&#x2F;SDK，把 TT 能力嵌进自己产品</td>
</tr>
<tr>
<td>②</td>
<td>小程序 &#x2F; 小游戏 &#x2F; 短剧（TikTok Minis）</td>
<td>内容方、游戏方、发行商</td>
<td>把 TT 当渠道，内容和交易都在 TT 内闭环</td>
</tr>
<tr>
<td>③</td>
<td>广告投放（Marketing API &#x2F; 代理商）</td>
<td>广告主、代理商</td>
<td>买 TT 的流量</td>
</tr>
<tr>
<td>④</td>
<td>电商服务商（TSP &#x2F; TAP &#x2F; MCN &#x2F; CAP）</td>
<td>代运营、撮合、经纪机构</td>
<td>帮商家在 TikTok Shop 卖货</td>
</tr>
<tr>
<td>⑤</td>
<td>达人营销（TikTok One）</td>
<td>品牌方、达人、MCN</td>
<td>品牌付钱找达人做内容</td>
</tr>
</tbody></table>
<p>这五套的开放程度是反着来的：</p>]]>
    </summary>
    <title>TikTok 开放平台调研：Minis 的玩家、玩法与平台处境</title>
    <updated>2026-09-15T02:39:21.812Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="效率" scheme="https://hisen.me/tags/%E6%95%88%E7%8E%87/"/>
    <content>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>博客攒了 300+ 篇，标签一直没管过。<br>前几天想找「我写过哪些关于稳定性的东西」，在标签页翻了半天没找着，才下决心重做。</p><p>原来的样子不好看。</p><ul><li>124 个标签，其中 82 个只用过一次，占三分之二；</li><li>Java 一个标签挂了 105 篇，占全站三分之一；</li><li>另一头是「穿布鞋的马云」「StringBuffer的区别」这种，一辈子只用一次。</li></ul><p>标签列表点进去一半是单篇，这就不叫导航了。</p><span id="more"></span><h1 id="2-前后对比"><a href="#2-前后对比" class="headerlink" title="2. 前后对比"></a>2. 前后对比</h1><ul><li>标签种数：124 → 27</li><li>只用过一次：82 → 1</li><li>标签槽位：412 → 334</li><li>无标签文章：11 → 49</li></ul><p>主要标签的去向：</p><ul><li>Java 105 篇 → java 63、性能 10、中间件 7</li><li>mysql 23 篇 → 存储 13、性能 5、运维 3</li><li>linux 21 篇 → 运维 18</li><li>idea 15 篇 → 13 篇不再有标签</li></ul><p>比数字更重要的，是标准变了：标签回答「这篇在解决什么问题」，不再是「用了什么产品」。</p><p>mysql 那 23 篇最能说明问题。13 篇讲数据怎么组织，归了存储；5 篇讲怎么让查询更快，归了性能。<br>同一个产品标签拆进两个关注点，这个区分旧体系根本看不出来。</p><p>无标签文章从 11 篇涨到 49 篇，大多是注册码、激活密钥、IDE 快捷键这类，靠 category 和 keywords 兜住就够。</p><h1 id="3-怎么做的"><a href="#3-怎么做的" class="headerlink" title="3. 怎么做的"></a>3. 怎么做的</h1><p>第一轮是纯机械的：统一大小写、合并同义词、长尾降级。</p><ul><li>Ubuntu &#x2F; centos &#x2F; shell &#x2F; ssh 合并成 linux；</li><li>mongo 并入 mongodb，github &#x2F; gitLab 并入 git；</li><li>HashMap &#x2F; jdk &#x2F; 多线程 &#x2F; jvm 并入 java。</li></ul><p>124 收成 30 个，但方向不对：剩下的还是产品名，java 反而涨到了 111 篇。</p><p>第二轮换成按关注点划的词表，27 个：<br>架构、稳定性、性能、高并发、存储、缓存、分布式、中间件、可观测、安全、工程效能、<br>容器、网络、运维、自建服务、AI 工程、LLM、Agent、java、go、算法、成长、阅读、效率、面试、业余无线电、水族。</p><p>这个没法查表。一篇 MySQL 文章该归性能还是存储，只能读正文。<br>于是开了 20 个 agent 并行，每个认领 16 篇，读完正文再打 1 到 3 个标签。<br>跑之前先拿 15 篇试了一轮，把边界歧义定成规则，再跑全量。</p><p>被砍掉的长尾没丢，全部降级进 keywords，站内搜索照样能命中。</p><h1 id="4-token-消耗"><a href="#4-token-消耗" class="headerlink" title="4. token 消耗"></a>4. token 消耗</h1><ul><li>试点：3 个 agent，15 篇，10.8 万；</li><li>全量：20 个 agent，292 篇，93 万；</li><li>合计：23 个 agent，约 104 万，平均每篇 3400。</li></ul><p>这只是子 agent 的消耗，不含主对话本身的上下文。</p>]]>
    </content>
    <id>https://hisen.me/20260913-blog-tag-taxonomy-refactor/</id>
    <link href="https://hisen.me/20260913-blog-tag-taxonomy-refactor/"/>
    <published>2026-09-13T14:30:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>博客攒了 300+ 篇，标签一直没管过。<br>前几天想找「我写过哪些关于稳定性的东西」，在标签页翻了半天没找着，才下决心重做。</p>
<p>原来的样子不好看。</p>
<ul>
<li>124 个标签，其中 82 个只用过一次，占三分之二；</li>
<li>Java 一个标签挂了 105 篇，占全站三分之一；</li>
<li>另一头是「穿布鞋的马云」「StringBuffer的区别」这种，一辈子只用一次。</li>
</ul>
<p>标签列表点进去一半是单篇，这就不叫导航了。</p>]]>
    </summary>
    <title>给 300+ 篇博客重做标签体系</title>
    <updated>2026-09-13T15:27:10.490Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="稳定性" scheme="https://hisen.me/tags/%E7%A8%B3%E5%AE%9A%E6%80%A7/"/>
    <content>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>在大模型时代，模型响应时间以及响应内容确定性未知的情况下，怎么做好稳定性？<br>过去做过的经验能不能复用呢？比如高并发系统(TPS 25w、QPS 100w、TP999 &lt; 80ms)。<br>我理解是可以复用的，因为本质上都是软件工程的问题，但有几处会变，放在<strong>第 3 节展开</strong>。<br>把事前、事中、事后这几步给做好，做扎实，怀着敬畏之心，肯定是 OK 的。</p><h1 id="2-全链路稳定性"><a href="#2-全链路稳定性" class="headerlink" title="2. 全链路稳定性"></a>2. 全链路稳定性</h1><p>全链路走六段：设计阶段留预案，开发阶段立规则，发布阶段卡流程，运行阶段看得见、扛得住，故障时先恢复再定位，复盘时把错误变成资产。<br>这些流程不是凭空定的，都是血泪教训总结出来的——不要因为省事而越过流程。</p><h2 id="2-1-设计：让稳定性融入设计"><a href="#2-1-设计：让稳定性融入设计" class="headerlink" title="2.1 设计：让稳定性融入设计"></a>2.1 设计：让稳定性融入设计</h2><p>把背景、约束理清楚。遇到高速增长的系统，我们要先考虑优化系统，再考虑增加硬件资源。平衡成本与收益。</p><ul><li>依赖分级：把系统的强弱依赖搞清楚，强依赖尽量保证能降级；</li><li>失败处理：超时、重试、熔断、降级；写操作需要幂等( 网络默认是不可靠的 )；</li></ul><span id="more"></span><ul><li>隔离策略：按业务、租户、链路进行物理或逻辑隔离，避免互相影响。( eg：DB 的读写分离 )</li><li>兼容策略：涉及不兼容问题、特别是 C 端需要考虑新老接口共存，逐步切流。</li></ul><p>设计阶段需要产出一份稳定性预案，主要描述：这个系统什么情况下会挂、挂了怎么办、对应怎么处置。</p><h2 id="2-2-开发：规则约束"><a href="#2-2-开发：规则约束" class="headerlink" title="2.2 开发：规则约束"></a>2.2 开发：规则约束</h2><ul><li>架构一致性：把架构边界写成测试( 比如”领域层不能依赖基础设施层” )，用 ArchUnit 做成用例，越界就红，不靠人记。</li><li>流水线卡点：静态检查、规范检查、单测覆盖率、圈复杂度，全部设成”不通过不合并”。<ul><li>覆盖率看增量，不看整体。整体覆盖率会被历史代码稀释，新代码的覆盖率才反映当前质量；</li><li>圈复杂度超阈值( 比如单函数 10-15 )就该拆。复杂的地方就是出 bug 的地方，也不好读。</li></ul></li><li>可观测埋点：新增的功能，默认的埋点是否足够？核心节点有相关日志吗？</li><li>CR 重点：超时、幂等、埋点、日志规范、可读性、复杂度 ( 当然，业务准确性也需要看的 )</li></ul><p>形成良好的开发习惯、通过 CR 或者排查问题复盘等沉淀团队共识，不断完善机制。</p><h2 id="2-3-发布：流程约束"><a href="#2-3-发布：流程约束" class="headerlink" title="2.3 发布：流程约束"></a>2.3 发布：流程约束</h2><p>过程中主要有：优雅启停、灰度发布、观察上下游日志、监控、告警，验证业务数据。<br>发布之前要有上线 checklist，发布的时候按顺序傻瓜操作。什么时候算通过、什么情况要回滚需要明确。</p><ul><li>灰度发布：分批次，按机房、按比例滚动发布；</li><li>细心监控：发布过程心怀敬畏，如果发现不符合预期，暂停发布</li><li>可靠回滚：允许一键回滚(一般是回滚程序，比较特殊的回滚：动态开关切回老链路)，需要考虑数据兼容、版本兼容等问题。</li><li>变更管控：明确发版节奏( 例如周二、周四发版 )，遇到大促等，严格管控变更。( 系统变更是万恶之源！)</li></ul><h2 id="2-4-运行：可观测、可容错"><a href="#2-4-运行：可观测、可容错" class="headerlink" title="2.4 运行：可观测、可容错"></a>2.4 运行：可观测、可容错</h2><ul><li>可观测：尽早发现问题、排查问题<ul><li>业务层面：单量、转化率等等</li><li>应用层面：延迟、错误日志</li><li>硬件层面：CPU、内存、网络、load等等</li><li>基础设施：依赖的 Redis、MySQL、发号器等</li></ul></li><li>监控告警：早于用户感知、有专人 oncall、有执行预案</li><li>容错处理：限流、熔断、降级、隔离</li><li>容量管理：定期压测、留有一定冗余、容量告警(默认 85%，增长快速的业务要时刻盯着)</li><li>SLO 与错误预算：上面几条讲的是”怎么发现问题”，这条讲”什么时候该停下来修”。<ul><li>SLI 是实测量( 成功率、延迟 )，SLO 是目标( 比如 99.99% )，错误预算 &#x3D; 100% - SLO；</li><li>预算烧完就冻结发布，先修稳定性——否则稳定性永远排在业务需求后面；</li><li>这一步的意义是把稳定性从”口号”变成”可量化的资源”：业务要快可以，但得花预算。</li></ul></li></ul><h2 id="2-5-故障：优先恢复而不是定位问题"><a href="#2-5-故障：优先恢复而不是定位问题" class="headerlink" title="2.5 故障：优先恢复而不是定位问题"></a>2.5 故障：优先恢复而不是定位问题</h2><p>实行故障分级制度，可以按时间、业务指标(GMV)等进行定级。<br>尽量做到 1-5-10：1 分钟发现、5分钟响应、10分钟恢复。<br>先恢复服务再查根因：降级、回滚、切流等进行止损，别召集排查代码。</p><p>出现重大故障，只能单一指挥，否则会出现 N 个人一直给 oncall 的人施加压力。</p><p>大部分故障来源都是：应用变更、配置修改等。所以变更管控是稳定性里性价比最高的一环。</p><h2 id="2-6-复盘：让错误成为资产"><a href="#2-6-复盘：让错误成为资产" class="headerlink" title="2.6 复盘：让错误成为资产"></a>2.6 复盘：让错误成为资产</h2><p>尽量避免追责到人，否则当事人会倾向于隐藏事故，导致故障影响扩大。</p><p>复盘主要看：根因、改进(有 owner、有期限)、下次再出现怎么快速发现？</p><p>改进部分可以贯穿整个迭代过程：设计、编码、发布、监控等环节。</p><h1 id="3-大模型场景：这套框架哪里要变"><a href="#3-大模型场景：这套框架哪里要变" class="headerlink" title="3. 大模型场景：这套框架哪里要变"></a>3. 大模型场景：这套框架哪里要变</h1><p>框架是通用的，但大模型有几处和传统后端根本不一样，得单独说。</p><h2 id="3-1-差异：三处和传统后端根本不同"><a href="#3-1-差异：三处和传统后端根本不同" class="headerlink" title="3.1 差异：三处和传统后端根本不同"></a>3.1 差异：三处和传统后端根本不同</h2><ul><li>输出非确定：同样的输入，两次输出可能不同。</li><li>计费在运行时：传统系统的容量成本是阶梯的( 加机器 )，大模型是每请求计费，成本随流量线性涨。</li><li>依赖不可控：供应商的配额、限流、故障你修不了。</li></ul><h2 id="3-2-指标：四个维度都要换口径"><a href="#3-2-指标：四个维度都要换口径" class="headerlink" title="3.2 指标：四个维度都要换口径"></a>3.2 指标：四个维度都要换口径</h2><p>延迟上，TTFT 只是体验的一半。</p><ul><li>TTFT( 首字延迟 )：决定用户”等多久”；</li><li>TBT &#x2F; TPOT( token 间隔 )：决定用户”读得顺不顺”。</li><li>端到端总时长；</li><li>流式中断率：首字出来了、后面断了。传统接口没有”部分成功”这种状态，流式有。</li></ul><p>成本上，token 用量要拆开看。</p><ul><li>输入 &#x2F; 输出 token 分开统计( 输出单价通常是输入的 3-5 倍，混在一起看不出问题 )；</li><li>缓存命中率(KV-Cache &#x2F; prompt cache)：直接决定成本，也直接反映 prompt 布局好不好；</li><li>单会话 token 成本；</li><li>成本突增要当故障告警。prompt 膨胀、重试风暴、Agent 死循环，表现都是 token 飙升——它是前兆，不是账单。</li></ul><p>质量维度，传统稳定性里完全没有这一块。</p><ul><li>格式合法率：结构化输出( JSON &#x2F; 卡片 )能不能解析；</li><li>幻觉率 &#x2F; 忠实度；</li><li>工具调用成功率；</li><li>拒答率：该拒的拒了吗( 这类场景，漏拒比误拒危险 )；</li><li>轮次衰减：聊到第 15 轮，效果掉没掉。</li></ul><p>容量上，吞吐的单位变了。</p><ul><li>看 token&#x2F;s，不是 QPS。同样的 QPS，输出长度不同，资源占用能差 10 倍；</li><li>上下文长度分布：长上下文是资源黑洞，一条超长会话能拖垮一个实例。</li></ul><h2 id="3-3-机制：要新增的四件事"><a href="#3-3-机制：要新增的四件事" class="headerlink" title="3.3 机制：要新增的四件事"></a>3.3 机制：要新增的四件事</h2><ul><li>评测门禁：输出非确定、没有断言可写，”系统是否正常”只能靠评测集判断。评测门禁就是大模型系统的回归测试，而且是唯一可行的那个。</li><li>token 预算 + 超限降级：单请求、单会话、单租户都要有预算，超了降级( 缩上下文、切小模型、直接拒 )，不能放任。</li><li>多模型路由 + Failover + 可插拔：供应商挂了、限流了、涨价了，都要能切。模型是可替换的商品，不是基础设施。</li><li>格式校验：结构化输出在渲染前先校验(schema &#x2F; AST)，非法的往下走不了。</li></ul><h2 id="3-4-小结：大模型带来的三条增量"><a href="#3-4-小结：大模型带来的三条增量" class="headerlink" title="3.4 小结：大模型带来的三条增量"></a>3.4 小结：大模型带来的三条增量</h2><p>上面 2.1 到 2.6 该做的还是要做。<br>大模型带来的增量就三条：</p><ul><li>不能靠断言判断对错，所以要有评测；</li><li>成本随流量线性涨，所以要有预算；</li><li>模型不是你能修的东西，所以要有替换方案。</li></ul>]]>
    </content>
    <id>https://hisen.me/20260913-Stability-From-Traditional-Engineering-to-the-Era-of-LLM/</id>
    <link href="https://hisen.me/20260913-Stability-From-Traditional-Engineering-to-the-Era-of-LLM/"/>
    <published>2026-09-13T10:00:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>在大模型时代，模型响应时间以及响应内容确定性未知的情况下，怎么做好稳定性？<br>过去做过的经验能不能复用呢？比如高并发系统(TPS 25w、QPS 100w、TP999 &lt; 80ms)。<br>我理解是可以复用的，因为本质上都是软件工程的问题，但有几处会变，放在<strong>第 3 节展开</strong>。<br>把事前、事中、事后这几步给做好，做扎实，怀着敬畏之心，肯定是 OK 的。</p>
<h1 id="2-全链路稳定性"><a href="#2-全链路稳定性" class="headerlink" title="2. 全链路稳定性"></a>2. 全链路稳定性</h1><p>全链路走六段：设计阶段留预案，开发阶段立规则，发布阶段卡流程，运行阶段看得见、扛得住，故障时先恢复再定位，复盘时把错误变成资产。<br>这些流程不是凭空定的，都是血泪教训总结出来的——不要因为省事而越过流程。</p>
<h2 id="2-1-设计：让稳定性融入设计"><a href="#2-1-设计：让稳定性融入设计" class="headerlink" title="2.1 设计：让稳定性融入设计"></a>2.1 设计：让稳定性融入设计</h2><p>把背景、约束理清楚。遇到高速增长的系统，我们要先考虑优化系统，再考虑增加硬件资源。平衡成本与收益。</p>
<ul>
<li>依赖分级：把系统的强弱依赖搞清楚，强依赖尽量保证能降级；</li>
<li>失败处理：超时、重试、熔断、降级；写操作需要幂等( 网络默认是不可靠的 )；</li>
</ul>]]>
    </summary>
    <title>稳定性：从传统工程到大模型时代</title>
    <updated>2026-09-13T14:37:46.938Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Reading" scheme="https://hisen.me/categories/reading/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="阅读" scheme="https://hisen.me/tags/%E9%98%85%E8%AF%BB/"/>
    <content>
      <![CDATA[<h1 id="1-全文概览"><a href="#1-全文概览" class="headerlink" title="1. 全文概览"></a>1. 全文概览</h1><p>FDE(Forward Deployed Engineer)：前置部署工程师</p><ul><li>跨界翻译官：兼具技术与业务的人才，既能写代码、做系统集成，又能听懂非技术高管的商业需求。</li><li>驻场交付者：FDE 通常会直接“空降”或长期驻扎在客户（如律所、医院、工厂、政府部门）的业务现场。</li><li>破局关键人：将通用的 LLM or 软件系统 嵌入到企业真实生产环境中，解决落地难的问题。</li></ul><p>FDE 不是一个新词，20 多年前就有，而且现在人家利润率不低。<br>本质上就是为效果付费，解决企业实际的问题。<br>由上到下进行推动，全面配合。</p><ul><li>深入工作现场，了解一线员工痛点在哪，而不是等着收集需求，因为需求传递过程中会失真；</li><li>不做花里胡哨的功能，只为效果收费，为解决问题收费；</li><li>积极主动解决问题，不用等着客户催；</li><li>深度集成到客户现有的系统，打通数据等通路；</li><li>系统做好了没人用？上手难度大吗？尽量嵌入现有流程，降低使用门槛；</li><li>一线员工对新系统不信任？定位他们一般找谁解决问题，咨询问题，要数据等等，先搞定 KOL；</li></ul><p>本质上来讲，这些都是软件工程里面老生常谈的问题，只是这两年 AI 能力强了之后，能解决一些脏活累活。</p><span id="more"></span><p>当前国内也在流行做这一块，不过短时间内可能很难改变外包的名头。<br>因为甲方可能强势，有各种定制化的需求，还愿意给钱。钱不够你不做？有的是人做。</p><p>最近了解到某些云厂商，打着 FDE 的名号，但是目的只是让客户消耗更多 token 罢了。</p><h1 id="2-原文摘要"><a href="#2-原文摘要" class="headerlink" title="2. 原文摘要"></a>2. 原文摘要</h1><p>历史与现实</p><ul><li>2003 年，Palantir 因为不知道间谍怎么工作发明了 FDE；</li><li>2025 年，整个行业因为「不知道企业里的智能体该怎么工作」而集体拥抱 FDE。<br>二十二年，同一个答案。</li></ul><p>FDE 特质</p><ul><li>足够宽的通才：代码、调试、数据、上云、了解模型、能搞定客户企业基础设施；</li><li>业务技术结合：把技术翻译成业务结果的能力</li><li>主人翁意识：不用客户打电话，自己立马解决</li></ul><p>FDE 工作时间分布</p><ul><li>四到五成泡在客户侧写代码调系统；</li><li>两三成和客户管理层对齐方向、拆问题、做架构决策；</li><li>一两成把现场学到的模式沉淀回公司产品线，剩下是评估优化和知识分享——写打法手册、内部布道、培训客户团队；</li></ul><p>技术大部分工程师都有，三种翻译能力不一定</p><ul><li>把业务问题翻译成技术问题</li><li>把技术方案翻译成高管能懂的话</li><li>把现场经验翻译成团队复用的知识</li></ul><p>核心是结果导向。</p><p>怎么选公司？</p><ul><li>产品平台：无平台就纯人力外包</li><li>知识沉淀：现场学习怎么回流到产品</li><li>汇报关系：FDE 汇报给产研OK，售前不OK</li></ul><p>FDE 保证结果不被稀释</p><ul><li>收钱的方式向结果靠拢，按结果验收，没用的功能不做</li><li>成功度量前置到开工前，先和客户商量什么叫成功，挖掘客户需求</li><li>最终裁判是客户组织的行为改变( 真的在用系统解决问题 )</li></ul><p>FDE 常用的工具箱</p><ul><li>平台底座层，公司的武器；</li><li>人工智能工程层，个人的手艺；</li><li>数据与集成层，进场的第一仗；( 70% 都卡在这 )</li><li>交付与协作层，客户环境里的生存装备；</li><li>知识沉淀层，规模化的杠杆；打法手册，组件库，部署清单<br>脚下踩着平台，手里握着工程，眼里盯着结果，身后连着产品线。</li></ul><p>调查显示人工智能项目规模化的障碍</p><ul><li>员工不愿意用新工具，但是私下里用 ChatGPT 飞起( 消费级产品做的太好 )</li><li>对模型输出质量的担忧</li><li>糟糕的用户体验</li><li>缺乏高管的支持</li><li>变革管理困难</li></ul><p>但是没有出现：模型不够聪明、算力不够便宜、技术不够先进</p><p>本章第一性原理：在错误的问题上，一切执行力都是浪费；而企业里错误问题的密度，远超想象。<br>核心：写第一行代码之前，怎么确保你在解决正确的问题。</p><p>互联网核心概念：PMF( product market fit，市场与产品契合)：产品对了，市场自己会拉动增长。视角在供应方。<br>FDE 的核心概念：PSF( Problem solution fit，问题与方案契合度 )，视角在需求方。</p><ul><li>痛点检验，是不是某个具体的人的具体痛点。提升客服效率 vs 客服主管每天得话几个小时 xxxx</li><li>经济性检验，解决这个问题，值多少钱？ROI 是什么？</li><li>可行性检验，以我们的能力和客户的现实情况，能做到几分？</li></ul><p>麦格鲁给过一个更锋利的标准：去解决首席执行官最关注的五个问题之一。<br>理由很现实，只有这个量级的问题，才能帮你碾过企业内部的官僚阻力。</p><p>只接两类问题——真的难的，和真的有业务影响的。只有难没有影响，是炫技；只有影响不难，轮不到你。</p><p>一到五天、客户带真实数据、现场做出能部署的原型、高管当场拍板。要么几天内见真东西，要么不要开始。</p><p>需求从哪里来？从痛里，痛不会出现在会议室，只会出现在工作现场。</p><p>参与式观察。</p><p>难得是找到那个没人写进文档的工作流，人们真正信任的那个数据源，以及指导流程为什么是那样的人。<br>这些东西都只能在现场找到。</p><p>变通是组织的疤，每道疤下面都是一次系统的失败，也都是 FDE 的机会。<br>随说：有系统还要人工核对数据，等等，此路不通变通一下</p><p>警惕干翻译过的痛点，绕过翻译，直接到达痛的神经末梢。</p><p>理解客户的使命而不是需求，需求是痛点的二手叙述，使命才是痛点的一手出处。</p><p>MVP -&gt; MVD 最小可部署单元</p><p>MVD 军规</p><ul><li>数据真实，没有例外</li><li>缩小切口，而不是缩小野心( 找一个小的点先做起来 )</li><li>定死截止时间，倒逼取舍</li></ul><p>FDE 的实践给出一条中间路线：数据上兼容旧系统，架构上绝不迁就旧系统，我们称之为「读旧写新」 。</p><p>顺从人的习惯，而不是顺从系统的习惯。</p><p>新系统最大的敌人不是旧系统，是旧习惯。</p><p>不要问客户要什么。<br>而是说：这是我做的东西，你看有哪里不满意。<br>哪里不对 &gt;&gt; 想要什么</p><p>做比说真，不要看客户说什么要看在做什么。</p><p>做调查问卷不固定出题，而是引导用户说出痛点。</p><p>「企业买人工智能，就像你奶奶拿到一部苹果手机——她想用，但需要你帮好。 」 —— a16z（安德森·霍洛维茨基金）</p><p>选对灯塔，做出标杆，让客户和你一起打磨产品。</p><p>不愿意公开替你说话的灯塔，价值至少减半。</p><p>著名孵化器 YC 有一条古训：「做不可规模化的事。 」最早的民宿平台创始人挨家挨户给房东房子拍照，在线支付公司 Stripe 的创始人当场帮户安装软件。</p><p>把交付做成能讲出去的故事，需要三个要素</p><ul><li>一个具体的数字</li><li>一个具体的人</li><li>一个具体的反差</li></ul><p>要找知识枢纽：职级不高，但是大家有问题会找他。</p><p>Palantir 常年发布场景化的技术文章OpenAI、Anthropic 把企业客户案例做成详细的技术叙事；a16z 的一篇行业雄文为整个赛道定了调——这些都不是品牌宣传，是精心经营的信任资产。</p><p>方法论开源，制造「被引用的资格」 。 把自己怎么做发现、怎么做验证、怎么做交付的方法论公开，短期看是教会同行，长期看是定义行业标准。</p><p>咨询公司与系统集成商。这是 2026 年最戏剧性的生态变局。OpenAI 部署公司的创始伙伴名单里，赫然并列着贝恩咨询、凯捷、麦肯锡——全球最大的咨询与集成巨头，从潜在的竞争者」变成了「「持股的同盟」 。逻辑很清晰：模型公司有技术，咨询公司有客户关系与行业纵深，集成商有落地人力——三方合流，才能把「人工智能转型」这个巨型市场整体吃下。</p><p>需求排期先后参考</p><ul><li>灯塔价值：后续行业背书等强度</li><li>学习价值：能够沉淀多少可以复用的能力，能力的价值如何( 共建&#x2F;白嫖 )</li></ul><p>可以体验的技术橱窗：公开的演示环境，交互式的教程。<br>目的就是为了让可能的客户体验使用，或者体验，营造良好的口碑。<br>随说：或许这就是开源商业公司赚钱的门道？</p><p>多数技术团队都会犯的错，写提案的时候通篇讲『我们要做什么』，而不是『你将得到什么』。</p><p>好的 FDE 提案，倒金字塔结构：<br>第一层：业务结果，一段话说完<br>第二层：价值验证路径，怎么证明做到了<br>第三层：交付方法，我们怎么做<br>第四层：风险与对策，我们想过会怎么死</p><p>FDE 前期主要是驻场，现在是远程多+驻场少。<br>驻场的关键节点</p><ul><li>关系建立的初期：第一次见面、影子工作法、与高管的信任建立；</li><li>高强度共创：训练营式的联合创建、关键架构决策的白板攻坚</li><li>政治敏感期：方案推广、部门协调、变革管理<br>远程的核心：深度编码、文档编写、常规迭代，需要心流的工作。</li></ul><p>模型通常是最干净的部分。难的是找到那个每人写进文档的工作流程。</p><p>无论技术如何进化，组织内部的人性和权责博弈，始终是比技术更难解决的问题。<br>随说：年会不能停 2 部，都是在讲这个</p><p>每一次迅速的修复，都是客户对你信任增加的时候。</p><p>OpenAI 的 FDE 工作法里有一个对应的节奏划分：前期共创（驻场白板对齐） 、验证（建评估体系） 、交付（多日驻场构建） 。注意交付阶段仍以「多日驻场」为单元——能修得这么快，靠的就是人守在问题旁边。</p><p>评估体系的工程实践：</p><ul><li>从真实案例里长出来；</li><li>让业务方成评委；</li><li>把评估体系接到生产回路上；</li></ul><p>现有评估体系定义的好，才有模型交付的好。</p><p>降低使用门槛</p><ul><li>寄生在用户已有的界面里。( excel ? 做插件、邮件？那就在邮件里完成 )</li><li>默认值，有效提高使用率，降低使用成本</li><li>把对话，做成按钮( 一键生成周报，等等)</li><li>先做副驾驶，再谈自动驾驶</li></ul><p>系统集成：它是系统考古，又是组织政治，还得管数据治理。绝对是一场硬仗。</p><p>数据问题先于模型解决，否则人工智能垃圾进垃圾出又得上演。</p><p>人工智能来了之后，数据集成工作效率大增。可以通过浏览器等方式去获取数据。<br>尽可能自动化集成流程：流程挖掘、数据管道、系统对接、接口文档梳理，这种速度优势会复利。</p><p>对支持者的经营要点：给他能讲的材料(能讲出去的故事)、给他战功（把他的远见编程职业生涯的亮点）、给他安全感（失败时你顶在前面）。</p><p>成熟的管理变革，会提前设计受损者的出路。否则会不利于推进新的政策&#x2F;系统。</p><p>电商公司得物的效率工程负责人任喜亮，把万人规模公司的 AI 转型拆成三步：</p><ul><li>第一步：达共识 跟全员达成共识，降低工具门槛，让所有人先用起来；</li><li>第二步：分场景 把企业场景按容错空间分成四象限，容错空间大的场景（比如经营分析）优先交给 AI；</li><li>第三步：沉知识 设专门的知识运营小组，钻进业务团队里，把专家的隐性经验从个人脑子里搬到 AI 可见的空间。<br>共识、场景、知识——顺序不能反：先有人愿意用，再挑对的地方用，最后让 AI 有米下锅。</li></ul><p>当一支 FDE 团队的每一次交付都在为下一次交付修路，它就不再是人海，而是一台正在自我加速的机器。<br>随说：尽量自动化</p><p>激活部署的七件武器讲完了：热修复的速度、评估体系的方向、降门槛的巧劲、集成战争的耐性、变革管理的软功、自动化的杠杆。</p><p>赚价值的差价，生意才能长久。</p><p>搭建这套系统，给你三条实践建议。其一，从第一天就采集基线——没有改造前的数据，就<br>没有改造后的价值证明，而基线只在项目启动<br>那一刻存在，错过永不再来。其二，指标必须<br>与客户共建——他不认的指标，算出花来也没有谈<br>判效力；在立项会上达成一致的那一刻，<br>指标就成了你们的共同语言。其三，克制指标数量——每个客户三到五个核<br>心指标足矣；指<br>标一多，就等于没有指标。</p><p>FDE 模式成立的标志，是「每个后续客户的定制量递减」。否则就是做外包。</p><p>把失败转为组织资产，需要机制</p><ul><li>复盘的无罪化：诚实复盘失败的功，可能大过侥幸的成功；</li><li>教训的结构化：下次要尽调xxx，把失败写进后续的流程</li><li>失败的适度外传：自爆家丑有时候也是一种宣传。我们已经交过学费了。</li></ul><p>企业采购人工智能最大的驱动力，正在从『效率』升级为『生存』。</p><p>应对组织政治？</p><ul><li>必须带着『当地人』：找最有声望的员工，邀请他参与适配过程，征求意见。<ul><li>”只因人们不会反对自己建造的东西”</li></ul></li><li>让每一步扩张都有受益者：没有受益者的扩张是侵略，有受益者的扩张是解放</li><li>永远给『旧秩序』留体面：要尊重，比如：我们要把过去十年的经验，放大一百倍。</li></ul><p>知识不嵌入流程，就永远只能是考古资料。</p><p>FDE 的商业模式：现场是探针、平台上杠杆、产品是复利的载体。</p><p>是什么摧毁了中国企业软件产业？<br>白嫖、开源、外包、招标、数科、畸形的市场结构。<br>中国的工程师长期消耗在『高度定制、强关系、价格战』的非标交付里。</p><p>SAP 中国区总裁还提醒了一句值得记住的话：AI 落地的最大挑战是组织惯性而非技术——基础数据架构的历史欠账，不会因为 AI 来了就自动消失。</p>]]>
    </content>
    <id>https://hisen.me/20260829-FDE-2026/</id>
    <link href="https://hisen.me/20260829-FDE-2026/"/>
    <published>2026-08-29T03:30:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-全文概览"><a href="#1-全文概览" class="headerlink" title="1. 全文概览"></a>1. 全文概览</h1><p>FDE(Forward Deployed Engineer)：前置部署工程师</p>
<ul>
<li>跨界翻译官：兼具技术与业务的人才，既能写代码、做系统集成，又能听懂非技术高管的商业需求。</li>
<li>驻场交付者：FDE 通常会直接“空降”或长期驻扎在客户（如律所、医院、工厂、政府部门）的业务现场。</li>
<li>破局关键人：将通用的 LLM or 软件系统 嵌入到企业真实生产环境中，解决落地难的问题。</li>
</ul>
<p>FDE 不是一个新词，20 多年前就有，而且现在人家利润率不低。<br>本质上就是为效果付费，解决企业实际的问题。<br>由上到下进行推动，全面配合。</p>
<ul>
<li>深入工作现场，了解一线员工痛点在哪，而不是等着收集需求，因为需求传递过程中会失真；</li>
<li>不做花里胡哨的功能，只为效果收费，为解决问题收费；</li>
<li>积极主动解决问题，不用等着客户催；</li>
<li>深度集成到客户现有的系统，打通数据等通路；</li>
<li>系统做好了没人用？上手难度大吗？尽量嵌入现有流程，降低使用门槛；</li>
<li>一线员工对新系统不信任？定位他们一般找谁解决问题，咨询问题，要数据等等，先搞定 KOL；</li>
</ul>
<p>本质上来讲，这些都是软件工程里面老生常谈的问题，只是这两年 AI 能力强了之后，能解决一些脏活累活。</p>]]>
    </summary>
    <title>《部署工程师》(FDE)读后感</title>
    <updated>2026-09-13T14:37:46.922Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="Agent" scheme="https://hisen.me/tags/agent/"/>
    <category term="架构" scheme="https://hisen.me/tags/%E6%9E%B6%E6%9E%84/"/>
    <content>
      <![CDATA[<h1 id="1-Eino-如何实现多智能体"><a href="#1-Eino-如何实现多智能体" class="headerlink" title="1. Eino 如何实现多智能体"></a>1. Eino 如何实现多智能体</h1><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br></pre></td><td class="code"><pre><span class="line">                           ┌────────────────────────────────────────────────────────┐</span><br><span class="line">                           │            Eino 多智能体协同体系 (Multi-Agent)            │</span><br><span class="line">                           └──────────────────────────┬─────────────────────────────┘</span><br><span class="line">                                                      │</span><br><span class="line">         ┌────────────────────────────────────────────┼────────────────────────────────────────────┐</span><br><span class="line">         ▼                                            ▼                                            ▼</span><br><span class="line">【范式 1: Host Multi-Agent】              【范式 2: Agent as a Tool】                 【范式 3: State Graph 协同】</span><br><span class="line">• 机制: 意图识别分发 + Summarizer 聚合       • 机制: 主控 Agent 将 Sub-Agent 包装为 Tool    • 机制: 强类型全局状态机 + 条件边流转</span><br><span class="line">• 适用: 专家分流 (客服/风控/导购)             • 适用: 深度自主规划、跨领域能力委派              • 适用: 复杂闭环业务、自反思、Saga 事务</span><br></pre></td></tr></table></figure><h2 id="1-1-Host-Specialist-模式（基于-Flow-集成）"><a href="#1-1-Host-Specialist-模式（基于-Flow-集成）" class="headerlink" title="1.1 Host-Specialist 模式（基于 Flow 集成）"></a>1.1 Host-Specialist 模式（基于 Flow 集成）</h2><p>Host Multi-Agent 是 Eino 官方封装的高内聚开箱模式。<br>Host 负责理解用户 Query 并做意图路由，分发给一个或多个 Specialist Agent，最后由可选的 Summarizer 模块聚合成最终流式输出。</p><span id="more"></span><p>架构核心机制：</p><ul><li>单&#x2F;多 Specialist 动态激活：Host 可判定单路由转发，也可同时 Fan-Out 派发给多个 Specialist。</li><li>流式平滑拼接：底层自动处理多个 Specialist 的 StreamChunk 合并，未配置 Summarizer 时默认拼接文本，配置后由 Summarizer 模型总结后下发。</li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br></pre></td><td class="code"><pre><span class="line">                    ┌─────────────────────────┐</span><br><span class="line">                    │       User Query        │</span><br><span class="line">                    └────────────┬────────────┘</span><br><span class="line">                                 ▼</span><br><span class="line">                    ┌─────────────────────────┐</span><br><span class="line">                    │    Host Agent (Router)  │ ──&gt; (识别意图并路由)</span><br><span class="line">                    └──────┬───────────┬──────┘</span><br><span class="line">                           │           │</span><br><span class="line">           ┌───────────────┘           └───────────────┐</span><br><span class="line">           ▼                                           ▼</span><br><span class="line">┌───────────────────────┐                   ┌───────────────────────┐</span><br><span class="line">│ Specialist A (售后退款)│                   │ Specialist B (商品推荐)│</span><br><span class="line">└──────────┬────────────┘                   └──────────┬────────────┘</span><br><span class="line">           │                                           │</span><br><span class="line">           └───────────────────┬───────────────────────┘</span><br><span class="line">                               ▼</span><br><span class="line">                    ┌─────────────────────────┐</span><br><span class="line">                    │  Summarizer (聚合响应)   │ ──&gt; (合并多 Agent 产出)</span><br><span class="line">                    └─────────────────────────┘</span><br></pre></td></tr></table></figure><h2 id="1-2-Agent-as-a-Tool-层级委派（基于-ADK）"><a href="#1-2-Agent-as-a-Tool-层级委派（基于-ADK）" class="headerlink" title="1.2 Agent-as-a-Tool &#x2F; 层级委派（基于 ADK）"></a>1.2 Agent-as-a-Tool &#x2F; 层级委派（基于 ADK）</h2><p>在深度自主任务（如 DeepAgent &#x2F; 复杂分析）中，主控 Agent 拥有全局目标，遇到具体执行动作时，通过调用封装为 tool.BaseTool 的子 Agent。</p><p>架构核心机理：</p><ul><li>上下文截断与降噪：主 Agent 的上下文不应被子 Agent 的长推理链（ReAct Loop）污染。子 Agent 在独立的 Context 空间内运行，执行完成后仅将最终摘要&#x2F;结构化结果作为 Tool Output 返回给主 Agent。</li><li>控制权转移（Hand-off）：在 Eino ADK 中，通过设置 Agent 的转移链（Transfer&#x2F;SubAgents），支持主 Agent 在识别到特定专业阶段后，彻底将交互控制权移交给子 Agent 接管，待子任务结束后再回弹。</li></ul><h2 id="基于-State-Graph-的强类型多-Agent-协同"><a href="#基于-State-Graph-的强类型多-Agent-协同" class="headerlink" title="基于 State Graph 的强类型多 Agent 协同"></a>基于 State Graph 的强类型多 Agent 协同</h2><p>在复杂度最高、一致性要求最严的电商&#x2F;金融场景中，应直接采用 Eino-Compose Graph 构建基于全局黑板（Blackboard State）的状态机协同。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br></pre></td><td class="code"><pre><span class="line">(Start) ──&gt; [Node: Intent_Router]</span><br><span class="line">                                  │</span><br><span class="line">                  ┌───────────────┴───────────────┐</span><br><span class="line">                  ▼                               ▼</span><br><span class="line">      [Node: Sales_Agent]                 [Node: Support_Agent]</span><br><span class="line">                  │                               │</span><br><span class="line">                  └───────────────┬───────────────┘</span><br><span class="line">                                  ▼</span><br><span class="line">                        [Node: Medical_Critic]</span><br><span class="line">                                  │</span><br><span class="line">                                  ├── (Score &lt; 0.8 &amp;&amp; HopCount &lt; 3) ──&gt; (回到 Agent 反思重写)</span><br><span class="line">                                  └── (Score &gt;= 0.8) ──&gt; [Node: Stream_Responder] ──&gt; (End)</span><br></pre></td></tr></table></figure><p>状态流转示意图</p><figure class="highlight go"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment">// 添加评价节点的条件路由边</span></span><br><span class="line">graph.AddBranch(<span class="string">&quot;Medical_Critic&quot;</span>, <span class="function"><span class="keyword">func</span><span class="params">(ctx context.Context, state *SessionState)</span></span> (<span class="type">string</span>, <span class="type">error</span>) &#123;</span><br><span class="line">    state.HopCount++</span><br><span class="line">    <span class="comment">// 死循环熔断</span></span><br><span class="line">    <span class="keyword">if</span> state.HopCount &gt; <span class="number">3</span> &#123;</span><br><span class="line">        <span class="keyword">return</span> <span class="string">&quot;Stream_Responder&quot;</span>, <span class="literal">nil</span></span><br><span class="line">    &#125;</span><br><span class="line">    <span class="comment">// 质检不合格，反思重试</span></span><br><span class="line">    <span class="keyword">if</span> state.CriticScore &lt; <span class="number">0.8</span> &#123;</span><br><span class="line">        <span class="keyword">return</span> <span class="string">&quot;Sales_Agent&quot;</span>, <span class="literal">nil</span></span><br><span class="line">    &#125;</span><br><span class="line">    <span class="keyword">return</span> <span class="string">&quot;Stream_Responder&quot;</span>, <span class="literal">nil</span></span><br><span class="line">&#125;)</span><br></pre></td></tr></table></figure><h1 id="2-多-Agent-协同四大工程防线"><a href="#2-多-Agent-协同四大工程防线" class="headerlink" title="2. 多 Agent 协同四大工程防线"></a>2. 多 Agent 协同四大工程防线</h1><h2 id="2-1-跨-Agent-上下文隔离和-token-剪枝"><a href="#2-1-跨-Agent-上下文隔离和-token-剪枝" class="headerlink" title="2.1 跨 Agent 上下文隔离和 token 剪枝"></a>2.1 跨 Agent 上下文隔离和 token 剪枝</h2><p>痛点：若每个 Agent 都能看到全部交互与所有工具原始报文，多轮多 Agent 交互后 Token 迅速暴涨。</p><p>Eino 架构解法：在 Graph 节点间引入 State Reducer &#x2F; Masking 机制。</p><ul><li>Sales_Agent 仅消费 UserQuery + UserProfile；</li><li>Critic_Agent 仅消费 DraftAnswer + Medical_Rules；</li><li>状态持久化存储在 Redis，但注入大模型推理上下文的切片进行按需动态投影。</li></ul><h2 id="2-2-全链路-Composable-Streaming（流式透传与背压）"><a href="#2-2-全链路-Composable-Streaming（流式透传与背压）" class="headerlink" title="2.2 全链路 Composable Streaming（流式透传与背压）"></a>2.2 全链路 Composable Streaming（流式透传与背压）</h2><p>痛点：多 Agent 串行或嵌套调用时，中间节点的阻塞会导致前端长时间白屏，TTFT 严重劣化。</p><p>Eino 架构解法：</p><ul><li>利用 schema.StreamReader[T] 抽象，下游节点无需等待上游完全生成，而是以 Chunk 为单位进行流式订阅；</li><li>在路由节点使用 Tee 分流，一路流式输出给前端做打字机渲染，一路流式喂给后置安全审计拦截器并行校验。</li></ul><h2 id="2-3-中断与人工接管（Human-in-the-loop-Checkpointing）"><a href="#2-3-中断与人工接管（Human-in-the-loop-Checkpointing）" class="headerlink" title="2.3 中断与人工接管（Human-in-the-loop &#x2F; Checkpointing）"></a>2.3 中断与人工接管（Human-in-the-loop &#x2F; Checkpointing）</h2><p>Eino ADK 中断恢复机制：</p><ul><li>涉及敏感交易或高危操作（如发放高额优惠券、退款审批）时，Agent 执行节点调用 adk.Interrupt() 暂停当前执行图，将完整的 State 序列化持久化至存储；</li><li>外部运营&#x2F;用户在审批系统确认后，通过 adk.Resume(taskID, payload) 从中断点精准恢复执行，避免从头重新推理。</li></ul><p>adk.Interrupt() 会触发下游的 checkPointStore 进行数据存储</p><h2 id="2-4-切面观测与-Parent-Child-Span-治理（Aspect-Tracing）"><a href="#2-4-切面观测与-Parent-Child-Span-治理（Aspect-Tracing）" class="headerlink" title="2.4 切面观测与 Parent-Child Span 治理（Aspect Tracing）"></a>2.4 切面观测与 Parent-Child Span 治理（Aspect Tracing）</h2><p>Eino Aspect 机制：利用无侵入拦截器，在多 Agent 协同流转中自动维护 W3C TraceContext：</p><ul><li>Root Span (Graph Run)</li><li>Child Span (Host Router)</li><li>Child Span (Specialist Sub-Agent)</li><li>Grandchild Span (Tool Calling &amp; LLM Inference)</li></ul><p>精准归因每个 Agent 的延迟占比、Token 消耗及错误堆栈，直接对接内部 OpenTelemetry 大盘。</p><h1 id="3-数据中断与恢复流程"><a href="#3-数据中断与恢复流程" class="headerlink" title="3. 数据中断与恢复流程"></a>3. 数据中断与恢复流程</h1><ul><li>状态模式演进与版本漂移<ul><li>历史数据结构不兼容，用兼容的数据结构或序列化组件</li><li>在 checkpoint 上打标版本号</li></ul></li><li>任务超时与清理<ul><li>配置超时时间</li><li>定时任务扫描标记过期</li></ul></li><li>防止唤醒脑裂<ul><li>通过 Redis 分布式锁</li><li>更新的时候带上状态校验 CAS</li></ul></li><li>敏感数据处理<ul><li>敏感数据加密处理</li></ul></li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br></pre></td><td class="code"><pre><span class="line">[1. Agent 节点执行] ──&gt; 触发 adk.Interrupt(payload)</span><br><span class="line">                             │</span><br><span class="line">                             ▼</span><br><span class="line">[2. Checkpointer 拦截] ──&gt; 抽取当前 Blackboard State</span><br><span class="line">                             │</span><br><span class="line">                             ├── (State &gt; 64KB) ──&gt; 上传 S3 并获取 Object_URI</span><br><span class="line">                             │</span><br><span class="line">                             ├── 写入 MySQL (Status = SUSPENDED, 记录挂起节点与审批摘要)</span><br><span class="line">                             └── 缓存至 Redis (Key: task_id, TTL: 24h)</span><br><span class="line">                             │</span><br><span class="line">                             ▼</span><br><span class="line">[3. 释放 Worker 资源] ──&gt; Worker 协程销毁退出，向审批工作台 / Webhook 发送待办事件</span><br><span class="line">                             │</span><br><span class="line">                      [ 人工审批/修改参数 ]</span><br><span class="line">                             │</span><br><span class="line">                             ▼</span><br><span class="line">[4. 触发 Resume API]  ──&gt; POST /api/v1/tasks/&#123;task_id&#125;/resume</span><br><span class="line">                             │</span><br><span class="line">                             ▼</span><br><span class="line">[5. 图引擎状态重建]   ──&gt; 加载分布式锁 ──&gt; 读取最新 Checkpoint ──&gt; 反序列化 State</span><br><span class="line">                             │</span><br><span class="line">                             ├── 注入 Human Feedback (覆盖/合并修改字段)</span><br><span class="line">                             ├── 更新 Checkpoint 状态为 RESUMED</span><br><span class="line">                             └── 从 suspended node 的下游条件边继续触发图流转</span><br></pre></td></tr></table></figure><h1 id="4-多智能体架构示意"><a href="#4-多智能体架构示意" class="headerlink" title="4. 多智能体架构示意"></a>4. 多智能体架构示意</h1><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br><span class="line">31</span><br><span class="line">32</span><br></pre></td><td class="code"><pre><span class="line">+-----------------------------------------------------------------------------------+</span><br><span class="line">|                            1. 接入层 (API Gateway)                                 |</span><br><span class="line">|   电商 App / 商家后台 / 客服工作台 (多端接入)   |  SSE/WebSocket 流式传输 |  鉴权 &amp; 限流  |</span><br><span class="line">+-----------------------------------------------------------------------------------+</span><br><span class="line">                                         │</span><br><span class="line">+----------------------------------------▼------------------------------------------+</span><br><span class="line">|                 2. 编排与调度中枢 (Agent Orchestration &amp; Engine)                    |</span><br><span class="line">|  ┌──────────────────┐  ┌─────────────────────────┐  ┌──────────────────────────┐  |</span><br><span class="line">|  │  意图识别/Router  │  │  状态机 (LangGraph/DAG)  │  │ Planning &amp; Reflection    │  |</span><br><span class="line">|  └─────────┬────────┘  └───────────┬─────────────┘  └────────────┬─────────────┘  |</span><br><span class="line">|            │                       │                             │                |</span><br><span class="line">|  ┌─────────▼───────────────────────▼─────────────────────────────▼─────────────┐  |</span><br><span class="line">|  │ Multi-Agent 协作层: 客服 Agent / 售后 Agent / 商家 Copilot / 推荐 Agent         │  |</span><br><span class="line">|  └─────────────────────────────────────────────────────────────────────────────┘  |</span><br><span class="line">+-----------------------------------------------------------------------------------+</span><br><span class="line">                    │                                             │</span><br><span class="line">+-------------------▼------------------+      +-------------------▼-----------------+</span><br><span class="line">|   3. 记忆与上下文引擎 (Memory Engine)  |      |   4. 能力与连接层 (Skills &amp; MCP)      |</span><br><span class="line">| • 短时窗口管理 (Sliding Window/Pruning)|     | • MCP Client / Server 标准接入协议    |</span><br><span class="line">| • 长期记忆 (Vector DB / User Profile) |      | • 业务 API: 订单/物流/退款/商品接口     |</span><br><span class="line">| • 会话状态持久化 (Redis / MySQL)       |      | • RAG Pipeline: 向量检索 + 重排/分块   |</span><br><span class="line">+--------------------------------------+      +-------------------------------------+</span><br><span class="line">                    │                                             │</span><br><span class="line">+-------------------▼---------------------------------------------▼-----------------+</span><br><span class="line">|                     5. 模型与推理网关 (Model &amp; Infra Gateway)                       |</span><br><span class="line">|   模型路由 (Claude / GPT / 自研开源模型)  |  Prompt 管理  |  语义缓存 &amp; Prompt Cache   |</span><br><span class="line">+-----------------------------------------------------------------------------------+</span><br><span class="line">                                         │</span><br><span class="line">+----------------------------------------▼------------------------------------------+</span><br><span class="line">|                    6. 评测、安全与可观测 (Eval &amp; Observability)                      |</span><br><span class="line">|   安全护栏 (Guardrails/注入防御) | Trace 链路追踪 (LangSmith/OTel) | 自动化评测 (Eval)  |</span><br><span class="line">+-----------------------------------------------------------------------------------+</span><br></pre></td></tr></table></figure><h1 id="5-智能体记忆共享"><a href="#5-智能体记忆共享" class="headerlink" title="5. 智能体记忆共享"></a>5. 智能体记忆共享</h1><p>多 Agent 共享记忆治理思路</p><ul><li>架构解耦：采用 CQRS 模式，写走 Append-Only 日志流保吞吐，读走‘Redis 热缓存 + 向量&#x2F;图谱物化视图’的双轨读，兼顾写吞吐与写后读强一致；</li><li>认知一致性：建立‘Slot 碰撞 → NLI 小模型 → LLM 仲裁’三级漏斗，以毫秒级确定性计算化解语义冲突；</li><li>零信任治理：基于 ABAC 策略做向量检索算子下推，避免先搜后滤带来的召回截断与数据越界，并通过 Taint Analysis 阻断记忆投毒；</li><li>成本与演进：参考 LSM 思想做双时态生命周期管理与分级 Compaction，将海量碎片 Trace 蒸馏为高阶全局认知，实现 Agent 系统的经验复利。</li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br></pre></td><td class="code"><pre><span class="line">[ Multi-Agents: Perception &amp; Action ]</span><br><span class="line">   │                                  ▲</span><br><span class="line">   │ 1. Append (毫秒级 ACK)            │ 4. Hybrid Read (双轨读)</span><br><span class="line">   ▼                                  │</span><br><span class="line">┌──────────────────────────────┐     ┌────────────────────────────────────────────────────────┐</span><br><span class="line">│ Ingestion Gateway (WAL Log)  │     │ Query Engine                                           │</span><br><span class="line">│ (Kafka / Raft Append-Only)   │     │ ├─ Hot Path: Redis (Session/Working Memory) [强一致]    │</span><br><span class="line">└──────────────┬───────────────┘     │ └─ Cold Path: Hybrid Vector + Graph [最终一致]          │</span><br><span class="line">               │                     └───────────────────────────▲────────────────────────────┘</span><br><span class="line">               ▼ 2. Async Dispatch                               │</span><br><span class="line">┌─────────────────────────────────────────────────────────┐      │ 3. Materialized View Update</span><br><span class="line">│ Background Async Reconciliation &amp; Compaction Pipeline   │──────┘</span><br><span class="line">│ ├─ Fast Path: Key-Slot Hash &amp; Vector Clock (确定性覆盖)   │</span><br><span class="line">│ ├─ Mid Path: NLI 轻量模型 (逻辑冲突/蕴含检测)               │</span><br><span class="line">│ ├─ Slow Path: LLM Semantic Merge (复杂因果仲裁)           │</span><br><span class="line">│ ├─ ABAC Pushdown Indexer (构建带权限掩码的物理索引)         │</span><br><span class="line">│ └─ Knowledge Compaction Engine (LSM-style 碎片聚合)      │</span><br><span class="line">└─────────────────────────────────────────────────────────┘</span><br></pre></td></tr></table></figure><h1 id="6-参考文档"><a href="#6-参考文档" class="headerlink" title="6. 参考文档"></a>6. 参考文档</h1><ul><li><span class="exturl" data-url="aHR0cHM6Ly9hcnRodXJjaGlhby5hcnQvYmxvZy9idWlsdC1tdWx0aS1hZ2VudC1yZXNlYXJjaC1zeXN0ZW0temgv">https://arthurchiao.art/blog/built-multi-agent-research-system-zh/<i class="fa fa-external-link-alt"></i></span></li></ul>]]>
    </content>
    <id>https://hisen.me/20260823-Agent-Orchestration/</id>
    <link href="https://hisen.me/20260823-Agent-Orchestration/"/>
    <published>2026-08-23T02:05:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-Eino-如何实现多智能体"><a href="#1-Eino-如何实现多智能体" class="headerlink" title="1. Eino 如何实现多智能体"></a>1. Eino 如何实现多智能体</h1><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br></pre></td><td class="code"><pre><span class="line">                           ┌────────────────────────────────────────────────────────┐</span><br><span class="line">                           │            Eino 多智能体协同体系 (Multi-Agent)            │</span><br><span class="line">                           └──────────────────────────┬─────────────────────────────┘</span><br><span class="line">                                                      │</span><br><span class="line">         ┌────────────────────────────────────────────┼────────────────────────────────────────────┐</span><br><span class="line">         ▼                                            ▼                                            ▼</span><br><span class="line">【范式 1: Host Multi-Agent】              【范式 2: Agent as a Tool】                 【范式 3: State Graph 协同】</span><br><span class="line">• 机制: 意图识别分发 + Summarizer 聚合       • 机制: 主控 Agent 将 Sub-Agent 包装为 Tool    • 机制: 强类型全局状态机 + 条件边流转</span><br><span class="line">• 适用: 专家分流 (客服/风控/导购)             • 适用: 深度自主规划、跨领域能力委派              • 适用: 复杂闭环业务、自反思、Saga 事务</span><br></pre></td></tr></table></figure>
<h2 id="1-1-Host-Specialist-模式（基于-Flow-集成）"><a href="#1-1-Host-Specialist-模式（基于-Flow-集成）" class="headerlink" title="1.1 Host-Specialist 模式（基于 Flow 集成）"></a>1.1 Host-Specialist 模式（基于 Flow 集成）</h2><p>Host Multi-Agent 是 Eino 官方封装的高内聚开箱模式。<br>Host 负责理解用户 Query 并做意图路由，分发给一个或多个 Specialist Agent，最后由可选的 Summarizer 模块聚合成最终流式输出。</p>]]>
    </summary>
    <title>Agent Orchestration - 智能体编排</title>
    <updated>2026-09-13T14:37:46.920Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="Agent" scheme="https://hisen.me/tags/agent/"/>
    <content>
      <![CDATA[<h1 id="1-系统概览"><a href="#1-系统概览" class="headerlink" title="1. 系统概览"></a>1. 系统概览</h1><p>OpenViking 是一个开源的、专为 AI Agent 设计的上下文数据库。<br>OpenViking 通过文件系统范式统一管理 Agent 所需要的上下文（记忆、资源和技能），<br>并实现上下文的分层供给与自我迭代，最终目标是降低 Agent 开发门槛，<br>让开发者更专注于业务创新而非底层上下文管理。<br>与其它记忆不同的是，他既有最开始的原文，也有高层级的语义理解。<br>数据召回的时候，数量以及准确性，都会有较大的效果和性能提升。</p><p>说明：</p><ul><li>本地安装的时候，全部可以用类似 Sqlite 的方案，依赖三方包即可；</li><li>数据写入后，L1、L0 阶段需要 LLM 参与生成摘要、做语义理解；</li><li>L2 如果原文超长，可以做逻辑语义拆分，符号提取 &#x2F; 虚拟子目录 &#x2F; 偏移分页；</li></ul><h2 id="1-1-系统架构"><a href="#1-1-系统架构" class="headerlink" title="1.1 系统架构"></a>1.1 系统架构</h2><span id="more"></span><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br></pre></td><td class="code"><pre><span class="line">+-------------------------------------------------------------------------+</span><br><span class="line">|                              AI Agent Runtime                           |</span><br><span class="line">|       (Find / LS / Read / Tree / Memory Extraction / Tool Invocation)   |</span><br><span class="line">+------------------------------------+------------------------------------+</span><br><span class="line">                                     |</span><br><span class="line">+------------------------------------v------------------------------------+</span><br><span class="line">|                         OpenViking Core Engine                          |</span><br><span class="line">|                                                                         |</span><br><span class="line">|  +---------------------------+       +-------------------------------+  |</span><br><span class="line">|  |     Virtual File System   |       |   Hierarchical Context Store  |  |</span><br><span class="line">|  |  viking:// schema router  | &lt;---&gt; |  - L0: Abstract Sidecar       |  |</span><br><span class="line">|  |  (Resources/Memory/Skills)|       |  - L1: Overview Sidecar       |  |</span><br><span class="line">|  +---------------------------+       |  - L2: Raw Payload            |  |</span><br><span class="line">|               |                      +-------------------------------+  |</span><br><span class="line">|               v                                      |                  |</span><br><span class="line">|  +---------------------------+                       v                  |</span><br><span class="line">|  | Recursive Retrieval Router|       +-------------------------------+  |</span><br><span class="line">|  | (Intent Analysis -&gt;       | &lt;---&gt; | Vector Engine &amp; Reranker      |  |</span><br><span class="line">|  |  Global Path Locate -&gt;    |       | (Embedding / Dense Vector /   |  |</span><br><span class="line">|  |  Subtree Recursive Zoom)  |       |  Lexical BM25 / Cross-Encoder)|  |</span><br><span class="line">|  +---------------------------+       +-------------------------------+  |</span><br><span class="line">+------------------------------------+------------------------------------+</span><br><span class="line">                                     |</span><br><span class="line">+------------------------------------v------------------------------------+</span><br><span class="line">|                         Persistence / Storage Layer                     |</span><br><span class="line">|           (Local Disk / Object Store / Key-Value / Vector Index)        |</span><br><span class="line">+-------------------------------------------------------------------------+</span><br></pre></td></tr></table></figure><h2 id="1-2-文件结构"><a href="#1-2-文件结构" class="headerlink" title="1.2 文件结构"></a>1.2 文件结构</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br></pre></td><td class="code"><pre><span class="line">viking://</span><br><span class="line">├── resources/              # 资源：项目文档、代码库、网页等</span><br><span class="line">│   └── my_project/</span><br><span class="line">├── user/</span><br><span class="line">│   └── &#123;user_id&#125;/          # 当前用户的私有上下文</span><br><span class="line">│       ├── memories/       # 用户记忆：用户个性化、实体状态、交互历史（动态演进）。</span><br><span class="line">│       ├── resources/      # 用户私有资源：文档、代码库、规约（静态长期）。</span><br><span class="line">│       ├── skills/         # 用户私有技能（默认）</span><br><span class="line">│       ├── peers/</span><br><span class="line">│       │   └── &#123;peer_id&#125;/</span><br><span class="line">│       │       ├── memories/</span><br><span class="line">│       │       └── resources/</span><br><span class="line">│       └── sessions/</span><br><span class="line">└── agent/</span><br><span class="line">    └── skills/             # account 全局共享技能（可选）</span><br></pre></td></tr></table></figure><h2 id="1-3-上下文分层："><a href="#1-3-上下文分层：" class="headerlink" title="1.3 上下文分层："></a>1.3 上下文分层：</h2><ul><li>L0（Abstract，~256 字符）： 作为全局向量检索与剪枝路由的轻量索引。</li><li>L1（Overview，~4000 字符）： 提供该目录&#x2F;模块的结构骨架与语义摘要，专用于Rerank 与上下文粗排。</li><li>L2（Detail，无上限）： 原始 Payload（代码段、文档正文、执行轨迹）。L0&#x2F;L1 命中后按需加载。</li></ul><h1 id="2-数据入库与检索"><a href="#2-数据入库与检索" class="headerlink" title="2. 数据入库与检索"></a>2. 数据入库与检索</h1><p>保留了向量检索、BM25检索等，和常规的检索方案很类似。<br>相比于单纯的 embedding，这种综合性的方式相对来说比较准确，能够互补。<br>虽然多路召回也能做到类似的效果，但是多路+重排序都需要应用侧开发，openviking 不用。</p><h2 id="2-1-数据写入过程"><a href="#2-1-数据写入过程" class="headerlink" title="2.1 数据写入过程"></a>2.1 数据写入过程</h2><p>同步的过程只有写 meta + L2 原文。<br>涉及到数据加工需要异步处理。<br>在异步处理完成之前，涉及到语义、向量等操作是不可用的，只能直接查 L2 的文件。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br><span class="line">31</span><br><span class="line">32</span><br><span class="line">33</span><br><span class="line">34</span><br><span class="line">35</span><br><span class="line">36</span><br><span class="line">37</span><br><span class="line">38</span><br><span class="line">39</span><br><span class="line">40</span><br><span class="line">41</span><br><span class="line">42</span><br><span class="line">43</span><br><span class="line">44</span><br><span class="line">45</span><br><span class="line">46</span><br><span class="line">47</span><br><span class="line">48</span><br><span class="line">49</span><br><span class="line">50</span><br><span class="line">51</span><br><span class="line">52</span><br><span class="line">53</span><br><span class="line">54</span><br><span class="line">55</span><br><span class="line">56</span><br><span class="line">57</span><br><span class="line">58</span><br><span class="line">59</span><br><span class="line">60</span><br></pre></td><td class="code"><pre><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                        1. 写入接入层 (API / SDK / MCP)                                       |</span><br><span class="line">|                                       Client 发起 POST /write (路径 + 正文)                                  |</span><br><span class="line">+------------------------------------------------------+------------------------------------------------------+</span><br><span class="line">                                                       |</span><br><span class="line">                                                       v</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                      2. 同步快速通道 (Sync Fast Path)                                         |</span><br><span class="line">|  +-------------------------------------+   +------------------------------------+   +--------------------+  |</span><br><span class="line">|  |           Metadata Store            |   |           Object Storage           |   |    Event Queue     |  |</span><br><span class="line">|  | - 鉴权 &amp; 创建 VFS Node (viking://)   |   | - 写入 L2 Raw Payload 原文 (S3)      |   | - 投递异步解析任务   |  |</span><br><span class="line">|  | - 状态置为 Processing, Dirty: True   |   |   (代码/Markdown/PDF/Session)       |   |   (Task Payload)   |  |</span><br><span class="line">|  +-------------------------------------+   +------------------------------------+   +---------+----------+  |</span><br><span class="line">+-----------------------------------------------------------------------------------------------|-------------+</span><br><span class="line">                                                       | (返回 200 OK 给 Client)                 |</span><br><span class="line">                                                       v (后台异步处理)                           v</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                    3. 异步语法与结构解析 (AST / Parsing)                                       |</span><br><span class="line">|  +-----------------------------------------------------+  +-----------------------------------------------+ |</span><br><span class="line">|  |            代码类 (Tree-sitter AST)                  |  |          文档类 (Markdown DOM / Layout)        | |</span><br><span class="line">|  | - 提取符号表 (Function/Struct/ErrorCode/Interface)    |  | - 提取 H1~H6 标题层级树与面包屑路径               | |</span><br><span class="line">|  | - 按语义边界切分 AST 块 (非机械字数暴力截断)              |  | - 剔除页眉页脚，保留完整自然段落与表格结构          | |</span><br><span class="line">|  +-----------------------------------------------------+  +-----------------------------------------------+ |</span><br><span class="line">+------------------------------------------------------+------------------------------------------------------+</span><br><span class="line">                                                       |</span><br><span class="line">                                                       v</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                4. 自底向上分层 Sidecar 生成 (LLM Synthesis)                                    |</span><br><span class="line">|  +-------------------------------------------------------------------------------------------------------+  |</span><br><span class="line">|  | 目录级 L1 概览 (.overview.md, ~4000 字符)                                                                |  |</span><br><span class="line">|  | 聚合目录下所有文件的 AST 骨架 + 核心接口 + 模块职责 (用于 Cross-Encoder Rerank 精排)                          |  |</span><br><span class="line">|  +---------------------------------------------------+---------------------------------------------------+  |</span><br><span class="line">|                                                      |</span><br><span class="line">|                                                      v</span><br><span class="line">|  +-------------------------------------------------------------------------------------------------------+  |</span><br><span class="line">|  | 目录级 L0 摘要 (.abstract.md, ~256 字符)                                                                |  |</span><br><span class="line">|  | 基于 L1 提炼高密度领域关键词与路由锚点 (用于全局向量检索快速初筛)                                               |  |</span><br><span class="line">|  +-------------------------------------------------------------------------------------------------------+  |</span><br><span class="line">+------------------------------------------------------+------------------------------------------------------+</span><br><span class="line">                                                       |</span><br><span class="line">                                                       v</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                    5. 双轨索引并行构建 (Dual-Track Indexing)                                |  |</span><br><span class="line">|  +---------------------------------------------------+  +------------------------------------------------+  |</span><br><span class="line">|  |           稠密向量通道 (Dense Vector)               |  |            稀疏倒排通道 (Sparse BM25)            |  |</span><br><span class="line">|  | - 对 L0 摘要 / L1 概览调用 Embedding 计算向量         |  | - 对 AST 提取的精确符号 (函数名/错误码) 分词        |  |</span><br><span class="line">|  | - 写入向量索引引擎 (HNSW / Milvus / Qdrant)          |  | - 写入轻量倒排引擎 (Tantivy / SQLite FTS)        |  |</span><br><span class="line">|  | - 绑定 VFS 节点路径 (用于全局与子树语义路由)            |  | - 建立精准倒排链 (用于无视层级的直达穿透召回)        |  |</span><br><span class="line">|  +---------------------------------------------------+  +------------------------------------------------+  |</span><br><span class="line">+------------------------------------------------------+------------------------------------------------------+</span><br><span class="line">                                                       |</span><br><span class="line">                                                       v</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br><span class="line">|                                    6. 原子提交与级联更新 (Atomic Commit)                                       |</span><br><span class="line">|  +-------------------------------------------------------------------------------------------------------+  |</span><br><span class="line">|  | 1. Metadata Store 更新状态: Processing -&gt; Ready                                                        |  |</span><br><span class="line">|  | 2. 沿目录树向上级联检查父节点: 若需要则增量微调父目录 L0，并清除 Dirty 标记                                     |  |</span><br><span class="line">|  | 3. 全链路就绪: 对 Agent 的 find / ls / read / recursive search 完全可见                                   |  |</span><br><span class="line">|  +-------------------------------------------------------------------------------------------------------+  |</span><br><span class="line">+-------------------------------------------------------------------------------------------------------------+</span><br></pre></td></tr></table></figure><h2 id="2-2-数据加工过程"><a href="#2-2-数据加工过程" class="headerlink" title="2.2 数据加工过程"></a>2.2 数据加工过程</h2><p>从 L2 原始数据开始，逐步往上层处理</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br></pre></td><td class="code"><pre><span class="line">[ L2: 原始叶子文件 (Code / Markdown / PDF) ]</span><br><span class="line">   │</span><br><span class="line">   ├── 1. 基于 AST / DOM 的语义结构化解析与清洗</span><br><span class="line">   │      (保留函数签名、Markdown 标题树、调用关系，剔除样板代码)</span><br><span class="line">   │</span><br><span class="line">   ▼</span><br><span class="line">[ L1 Sidecar: 目录级概览 (.overview.md, ~4000 chars) ]</span><br><span class="line">   │</span><br><span class="line">   ├── 2. 局部上下文提炼：综合该目录下所有叶子文件的导出符号、核心职责生成</span><br><span class="line">   │</span><br><span class="line">   ▼</span><br><span class="line">[ L0 Sidecar: 目录级极简索引 (.abstract.md, ~256 chars) ]</span><br><span class="line">   │</span><br><span class="line">   └── 3. 全局路由锚点：提取高密度的领域概念、核心关键字与路由元数据</span><br></pre></td></tr></table></figure><h2 id="2-3-检索过程"><a href="#2-3-检索过程" class="headerlink" title="2.3 检索过程"></a>2.3 检索过程</h2><p>OpenViking 内置了多路召回（Hybrid Retrieval）与重排（Rerank）机制，但其设计并非传统搜索系统中对单一切片（Chunk）的扁平堆叠，而是与它的 VFS 虚拟文件树拓扑以及 L0&#x2F;L1&#x2F;L2 分层结构紧密绑定的。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br><span class="line">31</span><br><span class="line">32</span><br><span class="line">33</span><br><span class="line">34</span><br><span class="line">35</span><br><span class="line">36</span><br><span class="line">37</span><br></pre></td><td class="code"><pre><span class="line">[ User Query / Intent ]</span><br><span class="line">           │</span><br><span class="line">           ▼</span><br><span class="line">┌─────────────────────────────────────────────────────────-─┐</span><br><span class="line">│ 1. 意图分解与查询改写 (Intent Decomposition)                 │</span><br><span class="line">│    - 提取语义 Query (Dense)                                 │</span><br><span class="line">│    - 提取结构化/关键词 Query (Sparse / Lexical / Path Filter)│</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 2. 多路召回阶段 (Multi-Channel Retrieval)                  │</span><br><span class="line">│    ├── 路径 A: 稠密向量检索 (Dense Embedding on L0/L1)      │</span><br><span class="line">│    ├── 路径 B: 词法/关键词检索 (BM25 / Lexical on Sidecars) │</span><br><span class="line">│    └── 路径 C: 确定性路径前缀过滤 (VFS Path Scoping)         │</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │ 融合生成候选集 (Candidate Sets)</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 3. 混合融合与粗排 (Fusion: RRF / Linear Combination)       │</span><br><span class="line">│    - 使用倒数排名融合 (RRF) 归一化多路得分                    │</span><br><span class="line">│    - 输出初步 Top-N 候选目录/节点                           │</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 4. 交叉编码精排阶段 (Cross-Encoder Reranker on L1)          │</span><br><span class="line">│    - 将 Query 与 L1 (.overview.md，~4000字符) 拼接打分      │</span><br><span class="line">│    - 评估完整语境相关度，裁决是否深入递归                      │</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │ 命中高分目录 / 节点</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 5. 递归下探与 L2 按需加载 (Recursive Tree-Search &amp; Payload) │</span><br><span class="line">│    - 若为目录：递归进入子树重复 2~4 步                        │</span><br><span class="line">│    - 若为叶子：读取 L2 正文并附带 Trace Path 返回给 Agent     │</span><br><span class="line">└──────────────────────────────────────────────────────────┘</span><br></pre></td></tr></table></figure><h1 id="3-存储架构"><a href="#3-存储架构" class="headerlink" title="3. 存储架构"></a>3. 存储架构</h1><p>OpenViking 属于存算分离的架构</p><p>上层是属于无状态的计算节点，底层可以接入各类云存储(L2)、向量数据库(L0&#x2F;L1);</p><p>Metadata Store 主要承载</p><ul><li>VFS 目录树拓扑与路径映射（Virtual File System Topology）</li><li>多租户沙箱与 ACL 权限元数据（Auth &amp; Access Control）</li><li>存储寻址指针（Payload &amp; Vector Address Index）</li><li>写入流水线状态机（Ingestion State Machine）</li><li>记忆与会话元数据（Memory &amp; Session Metadata）</li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br><span class="line">31</span><br></pre></td><td class="code"><pre><span class="line">+-----------------------------------------------------------------------------------+</span><br><span class="line">|                           API Gateway / Ingress Router                            |</span><br><span class="line">|             (鉴权、租户路由、Rate Limiting、Session Affinity)                        |</span><br><span class="line">+-----------------------------------------+-----------------------------------------+</span><br><span class="line">                                          |</span><br><span class="line">        +---------------------------------+---------------------------------+</span><br><span class="line">        |                                                                   |</span><br><span class="line">+-------v-------------------------------+   +-------------------------------v-------+</span><br><span class="line">|   OpenViking Stateless Server Node 1  |   |   OpenViking Stateless Server Node 2  |</span><br><span class="line">|  - VFS URI 解析与鉴权沙箱               |   |  - VFS URI 解析与鉴权沙箱                |</span><br><span class="line">|  - 递归检索状态机 (Recursive Search)    |   |  - 递归检索状态机 (Recursive Search)     |</span><br><span class="line">|  - 运行时 Context Assembly             |   |  - 运行时 Context Assembly             |</span><br><span class="line">+-------+-------------------------------+   +-------------------------------+-------+</span><br><span class="line">        |                                                                   |</span><br><span class="line">        +---------------------------------+---------------------------------+</span><br><span class="line">                                          |</span><br><span class="line">+-----------------------------------------v-----------------------------------------+</span><br><span class="line">|                  Asynchronous Ingestion &amp; Memory Worker Cluster                   |</span><br><span class="line">|         (分布式消息队列/任务调度：AST 解析、L0/L1 生成、Session 异步抽取)                |</span><br><span class="line">+-----------------------------------------+-----------------------------------------+</span><br><span class="line">                                          |</span><br><span class="line">+-----------------------------------------v-----------------------------------------+</span><br><span class="line">|                       Enterprise Distributed Storage Layer                        |</span><br><span class="line">|                                                                                   |</span><br><span class="line">|  +---------------------------+  +---------------------------+  +---------------+  |</span><br><span class="line">|  |     Object Storage        |  |  Distributed Vector DB    |  | Metadata Store|  |</span><br><span class="line">|  | (S3 / MinIO / TOS / OSS)  |  | (Milvus / VikingDB / Qdrant) |  | (PostgreSQL / |</span><br><span class="line">|  | -&gt; 承载海量 L2 原始 Payload|  | -&gt; 承载分布式 L0/L1 向量索引  |  |  Distributed  |  |</span><br><span class="line">|  |    (代码/PDF/历史 Trajectory|  |    与 ANN 稠密检索         |  |   KV / MySQL) |  |</span><br><span class="line">|  +---------------------------+  +---------------------------+  +---------------+  |</span><br><span class="line">+-----------------------------------------------------------------------------------+</span><br></pre></td></tr></table></figure><h1 id="4-怎么使用？"><a href="#4-怎么使用？" class="headerlink" title="4. 怎么使用？"></a>4. 怎么使用？</h1><h2 id="4-1-直接调用-SDK"><a href="#4-1-直接调用-SDK" class="headerlink" title="4.1 直接调用 SDK"></a>4.1 直接调用 SDK</h2><p>如果是在自建应用程序，可以在对应的 AOP &#x2F; middleware &#x2F; 回调函数里面进行数据写入。<br>或者通过 MQ 解耦，异步处理。</p><figure class="highlight go"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br></pre></td><td class="code"><pre><span class="line"><span class="keyword">package</span> main</span><br><span class="line"></span><br><span class="line"><span class="keyword">import</span> (</span><br><span class="line"><span class="string">&quot;context&quot;</span></span><br><span class="line"><span class="string">&quot;github.com/volcengine/OpenViking/sdk/go&quot;</span></span><br><span class="line">)</span><br><span class="line"></span><br><span class="line"><span class="function"><span class="keyword">func</span> <span class="title">main</span><span class="params">()</span></span> &#123;</span><br><span class="line">client, err := openviking.NewClient(openviking.Config&#123;</span><br><span class="line">BaseURL: <span class="string">&quot;http://localhost:1933&quot;</span>,</span><br><span class="line">APIKey:  <span class="string">&quot;your-api-key&quot;</span>,</span><br><span class="line">&#125;)</span><br><span class="line"><span class="keyword">if</span> err != <span class="literal">nil</span> &#123;</span><br><span class="line"><span class="built_in">panic</span>(err)</span><br><span class="line">&#125;</span><br><span class="line"><span class="keyword">defer</span> client.CloseIdleConnections()</span><br><span class="line"></span><br><span class="line"><span class="comment">// 1. 导入外部资源（文档 URL / Git Repo / 本地数据）</span></span><br><span class="line"><span class="comment">// 系统会自动解析并生成 L0/L1 摘要及向量索引</span></span><br><span class="line">err = client.AddResource(context.Background(), &amp;openviking.AddResourceRequest&#123;</span><br><span class="line">URI:       <span class="string">&quot;viking://resources/internal_wiki/&quot;</span>,</span><br><span class="line">SourceURL: <span class="string">&quot;https://wiki.company.com/docs/api_v2.md&quot;</span>,</span><br><span class="line">&#125;)</span><br><span class="line"></span><br><span class="line"><span class="comment">// 2. 写入或同步特定用户的私有上下文</span></span><br><span class="line">err = client.Write(context.Background(), &amp;openviking.WriteRequest&#123;</span><br><span class="line">URI:     <span class="string">&quot;viking://user/10086/memories/preferences.md&quot;</span>,</span><br><span class="line">Content: []<span class="type">byte</span>(<span class="string">&quot;用户更倾向于使用 Golang 进行后端开发，关注高并发架构设计。&quot;</span>),</span><br><span class="line">&#125;)</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure><h2 id="4-2-通过-MCP"><a href="#4-2-通过-MCP" class="headerlink" title="4.2 通过 MCP"></a>4.2 通过 MCP</h2><p>Agent 在运行过程中，根据 MCP 的描述，决定是否要触发相关记录。</p><h3 id="4-2-1-记忆沉淀"><a href="#4-2-1-记忆沉淀" class="headerlink" title="4.2.1 记忆沉淀"></a>4.2.1 记忆沉淀</h3><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br></pre></td><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;openviking_record_memory&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;用于向用户的长期记忆空间 (viking://user/&#123;user_id&#125;/memories/) 持久化沉淀高价值信息。仅在以下场景主动调用：1. 识别到用户的全局开发习惯、框架偏好或明确禁止的编码风格；2. 总结出经过验证的复杂 Bug 解决方案或架构避坑经验；3. 跨项目的通用工作流规则。禁止记录临时的对话闲聊、单次简单修改或未验证的推论。&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;parameters&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;object&quot;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="attr">&quot;properties&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;category&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;string&quot;</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;enum&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span><span class="string">&quot;preferences&quot;</span><span class="punctuation">,</span> <span class="string">&quot;experiences&quot;</span><span class="punctuation">,</span> <span class="string">&quot;cases&quot;</span><span class="punctuation">,</span> <span class="string">&quot;entities&quot;</span><span class="punctuation">]</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;记忆的分类：preferences (用户长期偏好), experiences (通用排错/避坑经验), cases (经典可复用案例), entities (核心项目实体与术语)&quot;</span></span><br><span class="line">      <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;title&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;string&quot;</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;记忆的简短标题，如 &#x27;Go 1.22+ 迭代器规范&#x27; 或 &#x27;MySQL 唯一索引并发死锁规避&#x27;&quot;</span></span><br><span class="line">      <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;content&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;string&quot;</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;提取出的核心经验、规则或代码片段正文 (Markdown 格式)&quot;</span></span><br><span class="line">      <span class="punctuation">&#125;</span></span><br><span class="line">    <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="attr">&quot;required&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span><span class="string">&quot;category&quot;</span><span class="punctuation">,</span> <span class="string">&quot;title&quot;</span><span class="punctuation">,</span> <span class="string">&quot;content&quot;</span><span class="punctuation">]</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><h3 id="4-2-2-资源沉淀"><a href="#4-2-2-资源沉淀" class="headerlink" title="4.2.2 资源沉淀"></a>4.2.2 资源沉淀</h3><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br></pre></td><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;openviking_write_resource&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;用于在 OpenViking 虚拟文件系统 (viking://resources/) 写入或更新持久化知识库。适用于用户明确指示保存设计文档、接口定义、技术选型方案或团队通用规章等具有长期重用价值的工程资产。&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;parameters&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;object&quot;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="attr">&quot;properties&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;uri&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;string&quot;</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;目标 VFS URI 路径，格式如 &#x27;viking://resources/architecture/payment_flow.md&#x27;&quot;</span></span><br><span class="line">      <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;content&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;string&quot;</span><span class="punctuation">,</span></span><br><span class="line">        <span class="attr">&quot;description&quot;</span><span class="punctuation">:</span> <span class="string">&quot;完整的内容 Payload&quot;</span></span><br><span class="line">      <span class="punctuation">&#125;</span></span><br><span class="line">    <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="attr">&quot;required&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span><span class="string">&quot;uri&quot;</span><span class="punctuation">,</span> <span class="string">&quot;content&quot;</span><span class="punctuation">]</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><h1 id="5-记忆处理"><a href="#5-记忆处理" class="headerlink" title="5. 记忆处理"></a>5. 记忆处理</h1><h2 id="5-1-冲突处理"><a href="#5-1-冲突处理" class="headerlink" title="5.1 冲突处理"></a>5.1 冲突处理</h2><p>对 Resource（知识库&#x2F;代码）： 保持客观中立，依赖确定性版本覆盖和 VFS 路径隔离，不做主观语义魔改。<br>对 Memory（记忆&#x2F;偏好）： 引入 Entity Matching -&gt; 仲裁模型 (修正&#x2F;合并&#x2F;细化) -&gt; 覆写与归档 的自动化流水线，<br>结合时序优先和人工可读可编辑，从根本上解决记忆互相打架的问题。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br></pre></td><td class="code"><pre><span class="line">[ 新会话产生的新事实 / 新偏好 ]</span><br><span class="line">              │</span><br><span class="line">              ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 1. 语义相似度与实体对齐 (Entity &amp; Semantic Matching)        │</span><br><span class="line">│    - 检索 memories/ 中是否存在同类实体或相近的主题规则         │</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │ 命中旧记忆: &quot;语言偏好: Python 3.10&quot;</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 2. 认知一致性仲裁 (Cognitive Arbitration)                  │</span><br><span class="line">│    - 调用仲裁 Prompt 判定关系类型:                          │</span><br><span class="line">│      ├── [完全冲突 / 修正] ──&gt; 触发直接覆盖与归档 (Overwrite) │</span><br><span class="line">│      ├── [条件互补 / 细化] ──&gt; 触发合并增补 (Merge / Append) │</span><br><span class="line">│      └── [无关 / 新增分支] ──&gt; 触发新建条目 (Create New)     │</span><br><span class="line">└──────────────────────────┬───────────────────────────────┘</span><br><span class="line">                           │ 判定为&quot;偏好修正&quot;</span><br><span class="line">                           ▼</span><br><span class="line">┌──────────────────────────────────────────────────────────┐</span><br><span class="line">│ 3. 原子更新与历史追溯 (Atomic Update &amp; Invalidation)        │</span><br><span class="line">│    - 覆写 viking://user/1001/memories/preferences.md      │</span><br><span class="line">│    - 重新计算该 Memory 节点的 L0/L1 摘要及向量索引            │</span><br><span class="line">│    - 将旧记录移入历史追踪版本库 (可审计/可回滚)                │</span><br><span class="line">└──────────────────────────────────────────────────────────┘</span><br></pre></td></tr></table></figure><h2 id="5-2-遗忘机制"><a href="#5-2-遗忘机制" class="headerlink" title="5.2 遗忘机制"></a>5.2 遗忘机制</h2><p>通过目录隔离，在会话结束之后，把 session 目录下的内容抽取沉淀至长期记忆</p><p>短期工作记忆（Working Memory）：</p><ul><li>存储路径：viking:&#x2F;&#x2F;user&#x2F;{id}&#x2F;sessions&#x2F;{session_id}&#x2F;</li><li>生命周期：仅在当前 Agent 任务或对话生命周期内活跃</li><li>使用场景：记录单次任务的多步执行轨迹（Scratchpad）、临时变量、中间推理步骤</li></ul><p>长期记忆（Long-term Memory &amp; Knowledge）：</p><ul><li>存储路径<ul><li>resources&#x2F;（知识）</li><li>user&#x2F;{id}&#x2F;memories&#x2F;（偏好与经验）</li></ul></li><li>生命周期：跨会话永久持久化，供后续所有任务共享</li><li>使用场景：为整个后续提供记忆材料</li></ul><h1 id="6-深挖细节"><a href="#6-深挖细节" class="headerlink" title="6. 深挖细节"></a>6. 深挖细节</h1><ul><li>目录树并发写入与惊群效应(级联重算)<ul><li>问题：如果短时间内多次变更，会触发 L1&#x2F;L0 重复处理</li><li>解决：<ul><li>留下缓存，合并处理；</li><li>变更文件时加上排他锁；</li></ul></li></ul></li><li>递归检索的长尾等耗时<ul><li>问题：可能会遇到多级”打分 -&gt; 分支判断 -&gt; 下探子目录 -&gt; 再次打分”</li><li>解决：<ul><li>并行展开</li><li>最大深度</li><li>尽早剪枝</li></ul></li></ul></li><li>多级数据独立存储一致性<ul><li>问题：由于系统解耦了 meta、向量、对象存储三层，跨系统下分布式事务没法实现</li><li>解决：<ul><li>软删除(数据还在，但是标记为无效) + 异步垃圾回收</li><li>一致性校验机制</li></ul></li></ul></li><li>prompt 注入与记忆毒化<ul><li>问题：session 场景可能有恶意 prompt 提权等；</li><li>解决：只能限制在 session 沙箱，而且需要做对抗性检查，保证加工数据的安全；</li></ul></li><li>多租户场景下资源竞争<ul><li>问题：如果没有物理隔离，怎么实现资源平衡？</li><li>解决：<ul><li>基于账户的优先级队列</li><li>做读写分离，线上部分只做读取 + L2 数据写入，离线部分做 L0&#x2F;L1 数据加工计算</li></ul></li></ul></li><li>面对长上下文的 LLM，记忆还有优势吗？<ul><li>问题：现在很多模型上下文到了 1M</li><li>解决：<ul><li>少量 token 直接全量读取，不用多级加载</li><li>合理布局拼接结果，最大可能实现 prompt cache</li><li>对数据做事实性提取，模型擅长检索，不擅长推理</li><li>主动挖掘数据之间隐含的关联关系，为用户提供更个性化、超预期的服务</li></ul></li></ul></li></ul>]]>
    </content>
    <id>https://hisen.me/20260822-openviking/</id>
    <link href="https://hisen.me/20260822-openviking/"/>
    <published>2026-08-22T13:30:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-系统概览"><a href="#1-系统概览" class="headerlink" title="1. 系统概览"></a>1. 系统概览</h1><p>OpenViking 是一个开源的、专为 AI Agent 设计的上下文数据库。<br>OpenViking 通过文件系统范式统一管理 Agent 所需要的上下文（记忆、资源和技能），<br>并实现上下文的分层供给与自我迭代，最终目标是降低 Agent 开发门槛，<br>让开发者更专注于业务创新而非底层上下文管理。<br>与其它记忆不同的是，他既有最开始的原文，也有高层级的语义理解。<br>数据召回的时候，数量以及准确性，都会有较大的效果和性能提升。</p>
<p>说明：</p>
<ul>
<li>本地安装的时候，全部可以用类似 Sqlite 的方案，依赖三方包即可；</li>
<li>数据写入后，L1、L0 阶段需要 LLM 参与生成摘要、做语义理解；</li>
<li>L2 如果原文超长，可以做逻辑语义拆分，符号提取 &#x2F; 虚拟子目录 &#x2F; 偏移分页；</li>
</ul>
<h2 id="1-1-系统架构"><a href="#1-1-系统架构" class="headerlink" title="1.1 系统架构"></a>1.1 系统架构</h2>]]>
    </summary>
    <title>OpenViking - 基于文件的分层记忆系统</title>
    <updated>2026-09-13T14:37:46.929Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="Agent" scheme="https://hisen.me/tags/agent/"/>
    <content>
      <![CDATA[<p>吴恩达团队通过分析超过 10,000 个招聘信息；<br>对人工智能专家、招聘经理和招聘人员进行数十次结构化访谈；<br>通过调查收集数据；以及综合其他在线数据，总结出以下四项最重要的 AI 工程技能：</p><ul><li>构建和部署人工智能应用程序( Building and deploying AI applications )</li><li>软件工程基础知识( Software engineering fundamentals )</li><li>使用编程代理( Using coding agents )</li><li>塑造结构( Shaping the build)</li></ul><h1 id="1-构建和部署"><a href="#1-构建和部署" class="headerlink" title="1. 构建和部署"></a>1. 构建和部署</h1><p>人工智能应用与非人工智能应用的主要区别在于前者具有不可预测的输出。</p><span id="more"></span><p>当你向逻辑学习模型（LLM）发出指令时，你无法预知会得到什么结果。<br>当你训练深度学习算法时，你也无法预知它会对新的样本做出怎样的预测。<br>相比之下，传统软件的行为则更具可预测性。</p><p>擅长构建和部署人工智能应用的人员不仅了解人工智能的基本组成部分（例如逻辑逻辑模型、上下文工程、红绿灯系统、智能体工作流、机器学习和深度学习），<br>更重要的是，他们还懂得如何运用统计技术来衡量、引导和管理人工智能系统，使其行为更具可预测性。<br>其中一项核心技能是懂得如何开展严谨的评估和误差分析循环。</p><h1 id="2-软件工程"><a href="#2-软件工程" class="headerlink" title="2. 软件工程"></a>2. 软件工程</h1><p>理解软件的工作原理时，能更高效地进行开发。<br>软件工程需要在成本、可扩展性、可靠性、速度等诸多因素之间进行权衡。安全性和隐私性则进一步增加了复杂性。</p><p>理解软件基础知识能让你认识到各种权衡取舍( trade off )的存在。</p><ul><li>做出更好的决策：选择软件栈、设计系统架构、设计数据存储、测试等方面；</li><li>更好地使用 AI Coding：运用软件工程来引导 Coding Agent，做出合理的权衡取舍，而不是凭感觉；</li></ul><h1 id="3-使用-AI-Coding"><a href="#3-使用-AI-Coding" class="headerlink" title="3. 使用 AI Coding"></a>3. 使用 AI Coding</h1><p>有效运用智能体编码如今已成为每位开发者的一项关键技能。<br>掌握这项技能，你就能对智能体的工作原理形成清晰的认知模型。<br>你了解它们的局限性以及如何克服这些局限性，并能快速引导它们——懂得适度干预和放任自流——从而构建出健壮的软件，同时避免浪费过多的时间和 token。</p><p>这要求您了解如何管理编码代理的上下文，如何在计划和执行之间进行权衡，以及如何通过提供验证器或评估来帮助代理自主地闭合循环。<br>您还需要知道如何使用清晰的规范（以及何时不必这样做），如何协调多个协同工作的代理，以及如何避免诸如代理破坏生产数据库之类的陷阱。<br>由于代理编码技术发展迅速，熟练地使用编码代理不仅意味着掌握前沿实践，还意味着要养成不断尝试新工具并随着最佳实践的变化而改进工作流程的习惯。</p><h1 id="4-塑造结构"><a href="#4-塑造结构" class="headerlink" title="4. 塑造结构"></a>4. 塑造结构</h1><p>有了清晰的规范，编码代理在交付符合规范的产品方面正在迅速进步。<br>因此，我们工程师的工作重心正在转向决定规范中应该包含哪些内容。<br>工程师不应再期望获得一个像素级完美的设计，然后只需照办即可。<br>相反，高效的 AI 工程师需要具备产品意识，理解业务背景和客户目标，从而参与到构建过程的塑造和驱动中。</p><p>人工智能也赋予你比以往更大的自主权和掌控权。<br>你可以发现有趣的问题和机遇，并以负责任的方式加以利用。<br>要抓住这个机遇，你需要知道如何推动项目进展。<br>例如，何时应该快速构建最小可行产品（MVP）供用户测试，何时应该放慢速度，花更多时间进行更细致的开发。</p><p>所有这些技能的基础是持续学习的心态。<br>人工智能发展日新月异，因此我们必须不断学习和提升自身技能，以适应不断涌现的最佳实践。</p>]]>
    </content>
    <id>https://hisen.me/20260822-AI-Engineering-skills-map/</id>
    <link href="https://hisen.me/20260822-AI-Engineering-skills-map/"/>
    <published>2026-08-22T04:30:00.000Z</published>
    <summary>
      <![CDATA[<p>吴恩达团队通过分析超过 10,000 个招聘信息；<br>对人工智能专家、招聘经理和招聘人员进行数十次结构化访谈；<br>通过调查收集数据；以及综合其他在线数据，总结出以下四项最重要的 AI 工程技能：</p>
<ul>
<li>构建和部署人工智能应用程序( Building and deploying AI applications )</li>
<li>软件工程基础知识( Software engineering fundamentals )</li>
<li>使用编程代理( Using coding agents )</li>
<li>塑造结构( Shaping the build)</li>
</ul>
<h1 id="1-构建和部署"><a href="#1-构建和部署" class="headerlink" title="1. 构建和部署"></a>1. 构建和部署</h1><p>人工智能应用与非人工智能应用的主要区别在于前者具有不可预测的输出。</p>]]>
    </summary>
    <title>人工智能工程技能图谱 - 吴恩达</title>
    <updated>2026-09-13T14:37:46.920Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="运维" scheme="https://hisen.me/tags/%E8%BF%90%E7%BB%B4/"/>
    <content>
      <![CDATA[<p>去年升级了博客：<a href="/20250719-hexo-upgrade-and-optimize/">Hexo 升级 &amp; 优化</a>，近期才发现有些 Tag 404。<br>但是 hexo s 本地运行的正常打开的，我看了下 Cloudflare pages 的发布日志。<br>判断应该是平台机制问题，生成的文件都是 java 而非预期的 Java。</p><p>于是问了下模型：</p><ul><li>问题：这是 Cloudflare Pages 的一个已知机制&#x2F;行为。</li><li>解决：通过 hexo 的配置，把 URL 都调整为小写( 可能会影响 SEO )</li></ul><p>原因解析<br>Cloudflare Pages 在部署静态资源时，其底层路由系统（以及预設的 Assets 引擎）在处理 URL 和文件路径时，默认是不区分大小写（Case-Insensitive）或者会执行规范化（Normalization）的。</p><span id="more"></span><p>在 Hexo 中，如果你创建了 Tag 为 Java，Hexo 默认生成的目录结构是 &#x2F;tags&#x2F;Java&#x2F;index.html。但 Cloudflare Pages 在处理路由匹配或文件同步时，往往会强制将路径重写为小写（java），或者对大小写敏感的路径做了规范化路由重定向，这就导致访问原始带大写字母的 URL（例如 &#x2F;tags&#x2F;Java&#x2F;）时触发 404 或重定向循环。</p><p>社区中许多使用 Hexo、Hugo 等静态博客引擎并部署在 Cloudflare Pages 上的开发者都遇到过此类分类&#x2F;标签（Tag&#x2F;Category）包含大写字母导致路径失效的问题。</p><p>解决方案<br>处理这个问题的根本原则是：在 Hexo 侧统一将 URL 生成策略调整为全小写（Case-insensitive Slugs）。<br>修改配置文件的 filename_case 开关：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line"># 1 表示将生成的 filename / slug 强制转为小写 (Lower case)</span><br><span class="line"># 0 表示保持原样 (Default)</span><br><span class="line">filename_case: 1</span><br></pre></td></tr></table></figure>]]>
    </content>
    <id>https://hisen.me/20260809-Cloudflare-pages-url-case/</id>
    <link href="https://hisen.me/20260809-Cloudflare-pages-url-case/"/>
    <published>2026-08-09T15:34:00.000Z</published>
    <summary>
      <![CDATA[<p>去年升级了博客：<a href="/20250719-hexo-upgrade-and-optimize/">Hexo 升级 &amp; 优化</a>，近期才发现有些 Tag 404。<br>但是 hexo s 本地运行的正常打开的，我看了下 Cloudflare pages 的发布日志。<br>判断应该是平台机制问题，生成的文件都是 java 而非预期的 Java。</p>
<p>于是问了下模型：</p>
<ul>
<li>问题：这是 Cloudflare Pages 的一个已知机制&#x2F;行为。</li>
<li>解决：通过 hexo 的配置，把 URL 都调整为小写( 可能会影响 SEO )</li>
</ul>
<p>原因解析<br>Cloudflare Pages 在部署静态资源时，其底层路由系统（以及预設的 Assets 引擎）在处理 URL 和文件路径时，默认是不区分大小写（Case-Insensitive）或者会执行规范化（Normalization）的。</p>]]>
    </summary>
    <title>解决 Cloudflare Pages URL 不支持大写的问题</title>
    <updated>2026-09-13T14:37:46.921Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Tech" scheme="https://hisen.me/categories/tech/"/>
    <category term="Agent" scheme="https://hisen.me/tags/agent/"/>
    <category term="架构" scheme="https://hisen.me/tags/%E6%9E%B6%E6%9E%84/"/>
    <content>
      <![CDATA[<h2 id="1-概览"><a href="#1-概览" class="headerlink" title="1. 概览"></a>1. 概览</h2><blockquote><p>一句话总结：协议从”有状态、靠长连接”变成”无状态、靠 HTTP 请求”。</p></blockquote><p>2026 年 7 月 28 日，MCP 发布了算得上”有史以来最大”的一次规范修订。<br>同一时间，官方四套 Tier 1 SDK(TypeScript、Python、Go、C#)同步更新。</p><p>MCP SDK 月下载量已突破 4 亿（TS&#x2F;Python 累计超 20 亿），部署服务器过万；<br>但新规范生态跟进极慢，抽样 1470+ 公开服务器中完全合规的仅 2 个，尚未出现全面切换。</p><h2 id="2-变更的初衷和重点"><a href="#2-变更的初衷和重点" class="headerlink" title="2. 变更的初衷和重点"></a>2. 变更的初衷和重点</h2><h3 id="2-1-为什么改"><a href="#2-1-为什么改" class="headerlink" title="2.1 为什么改"></a>2.1 为什么改</h3><p>MCP 2024 年诞生时，本质上只是为单机笔记本设计的协议：</p><ul><li>一个客户端、一个服务器、一条 stdio 管道、一个与进程同生死的长连接会话（Session）。</li><li>对本地单机调用而言，这个设计极其精准且够用。</li></ul><p>但当它被推向生产环境时，企业不得不为这套“本地模型”付出四笔沉重代价：</p><ul><li>Serverless 适配瘫痪：旧协议强依赖长连接和 Session，而 Serverless（AWS Lambda、Cloud Run、Cloudflare Workers）没有常驻进程，在物理层面就无法运行。</li></ul><span id="more"></span><ul><li>架构被迫退回十年前：因为状态绑定在特定实例上，水平扩展只能依靠 Sticky Session（粘性路由）或 Redis 存 Session。一个普通的 Web 服务，被迫重新处理长连接状态同步。</li><li>网关限流与审计失效：所有操作共享同一个 HTTP 管道，网关在 HTTP 层无法感知具体行为。想区分“调用工具”还是“获取列表”，只能拆解 JSON-RPC Body，效率与安全双重受损。</li><li>长任务与主动交互死锁：服务器要中途请求用户确认或等待模型补全，只能靠死挂着的 SSE 流；长耗时任务同步死等，极易引发超时断开。</li></ul><p>正如 MCP 创建者之一 David Soria Parra 所言：“这次改动的核心，就是把状态从服务器挪到线上（Wire）去。”<br>无状态化之后，服务器不再依赖 Redis 和粘性路由，<br>挂在一台最普通的轮询负载均衡（Round-Robin Load Balancer）后面即可轻松横向扩展。</p><h3 id="2-2-改了什么"><a href="#2-2-改了什么" class="headerlink" title="2.2 改了什么"></a>2.2 改了什么</h3><p>8 个核心变更</p><table><thead><tr><th>#</th><th>变更</th><th>落地的 SEP</th><th>一句话影响</th></tr></thead><tbody><tr><td>1</td><td>移除协议级 Session、<code>Mcp-Session-Id</code></td><td>SEP-2567</td><td>服务器不再”记住”你，需要跨调用的状态用显式句柄</td></tr><tr><td>2</td><td>移除 <code>initialize</code> 握手，身份装进 <code>_meta</code></td><td>SEP-2575</td><td>每个请求自带协议版本、客户端信息，不再有”初始化了吗”这个分支</td></tr><tr><td>3</td><td>新增 <code>server/discover</code> RPC</td><td>SEP-2575</td><td>客户端可以随时探测服务器能力，替代握手时的一次性声明</td></tr><tr><td>4</td><td>路由信息放进 HTTP Header(<code>Mcp-Method</code> 等)</td><td>SEP-2243</td><td>网关不拆包就能路由、限流、审计</td></tr><tr><td>5</td><td>列表接口加 <code>ttlMs</code> + <code>cacheScope</code> 缓存</td><td>SEP-2549</td><td>无状态后列表天然跨连接一致，客户端可按 Cache-Control 思路缓存</td></tr><tr><td>6</td><td>服务器主动交互改为 Multi Round-Trip(MRTR)</td><td>SEP-2322</td><td>服务器返回”我需要输入”，客户端收集后重发原请求，不用占着连接</td></tr><tr><td>7</td><td>MCP Apps(沙箱 UI);Tasks 转正</td><td>SEP-1865 &#x2F; SEP-2663</td><td>工具能吐可交互界面;长任务改轮询 + 进度更新</td></tr><tr><td>8</td><td>授权加固;Roots&#x2F;Sampling&#x2F;Logging 弃用</td><td>SEP-2468 &#x2F; SEP-2577</td><td><code>iss</code> 参数必须校验;DCR 迁移到 CIMD;弃用功能最少保留 12 个月</td></tr></tbody></table><p>其中 1、2、5、6 是变动最大的四条，后面第 3 节看细节。</p><h3 id="2-3-一块基石-SEP-2596-生命周期政策"><a href="#2-3-一块基石-SEP-2596-生命周期政策" class="headerlink" title="2.3 一块基石:SEP-2596 生命周期政策"></a>2.3 一块基石:SEP-2596 生命周期政策</h3><p>这轮修订先立规矩，再改协议。SEP-2596 给功能定义了 Active → Deprecated → Removed 三态，并承诺<strong>最少 12 个月弃用窗口</strong>(安全问题可缩短到 90 天)。也就是说，今天标了废弃的功能，至少一年内不会消失。这是官方对”别逼大家一夜迁移”的制度化承诺。</p><h2 id="3-新老详细对比"><a href="#3-新老详细对比" class="headerlink" title="3. 新老详细对比"></a>3. 新老详细对比</h2><h3 id="3-1-协议核心"><a href="#3-1-协议核心" class="headerlink" title="3.1 协议核心"></a>3.1 协议核心</h3><table><thead><tr><th>维度</th><th>老版(2025 及更早)</th><th>新版(2026-07-28)</th></tr></thead><tbody><tr><td>状态模型</td><td>有状态:长连接 + Session(<code>Mcp-Session-Id</code>)</td><td>无状态:请求&#x2F;响应解耦，状态由显式句柄承载(类似数据库游标、S3 upload_id)</td></tr><tr><td>初始化</td><td><code>initialize</code> &#x2F; <code>initialized</code> 握手</td><td>无握手;<code>server/discover</code> 发布能力;身份进 <code>_meta</code></td></tr><tr><td>客户端身份</td><td>握手时一次性声明</td><td>每个请求的 <code>_meta</code> 都带:<code>io.modelcontextprotocol/clientInfo</code></td></tr><tr><td>负载均衡</td><td>需要粘性路由 + 共享会话存储(Redis)</td><td>普通轮询即可，实例重启对客户端透明</td></tr><tr><td>路由&#x2F;限流</td><td>网关需解析 JSON-RPC Body</td><td>HTTP Header(<code>Mcp-Method</code>、<code>Mcp-Name</code>)，网关零拆包</td></tr><tr><td>服务器主动交互</td><td>长期 SSE 流(采样、elicitation)</td><td>MRTR:返回 <code>resultType: &quot;input_required&quot;</code>，客户端收集输入后重发原请求</td></tr><tr><td>列表缓存</td><td>无协议级缓存，靠 SSE 推送变更</td><td><code>tools/list</code> 等返回 <code>ttlMs</code> + <code>cacheScope</code>(public&#x2F;private)</td></tr><tr><td>取消通知</td><td>SSE <code>notifications/cancelled</code></td><td>关闭该请求对应的 SSE 响应流</td></tr><tr><td>幂等&#x2F;恢复</td><td>断线重连续会话</td><td>无会话可续;状态靠显式句柄，任意实例可接管</td></tr></tbody></table><h3 id="3-2-一个典型请求，前后对比"><a href="#3-2-一个典型请求，前后对比" class="headerlink" title="3.2 一个典型请求，前后对比"></a>3.2 一个典型请求，前后对比</h3><p>老版，身份信息只在握手时给过一次:</p><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment">// initialize 请求(仅此一次)</span></span><br><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;jsonrpc&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2.0&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;method&quot;</span><span class="punctuation">:</span> <span class="string">&quot;initialize&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;params&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;protocolVersion&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2025-11-25&quot;</span>，</span><br><span class="line">    <span class="attr">&quot;clientInfo&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;my-client&quot;</span>， <span class="attr">&quot;version&quot;</span><span class="punctuation">:</span> <span class="string">&quot;1.0.0&quot;</span> <span class="punctuation">&#125;</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><p>新版，每个请求都是完整的，身份跟着请求走:</p><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br></pre></td><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;jsonrpc&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2.0&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;method&quot;</span><span class="punctuation">:</span> <span class="string">&quot;tools/call&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;params&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;forecast&quot;</span>，</span><br><span class="line">    <span class="attr">&quot;arguments&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;city&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Berlin&quot;</span> <span class="punctuation">&#125;</span>，</span><br><span class="line">    <span class="attr">&quot;_meta&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;io.modelcontextprotocol/protocolVersion&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2026-07-28&quot;</span>，</span><br><span class="line">      <span class="attr">&quot;io.modelcontextprotocol/clientInfo&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;my-client&quot;</span>， <span class="attr">&quot;version&quot;</span><span class="punctuation">:</span> <span class="string">&quot;1.0.0&quot;</span> <span class="punctuation">&#125;</span></span><br><span class="line">    <span class="punctuation">&#125;</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><p>注意 <code>_meta</code> 里的 key 用了反域名命名空间(<code>io.modelcontextprotocol/...</code>)，这是新规范的扩展机制反哺进了核心，后续所有扩展字段都会沿用这个习惯。</p><h3 id="3-3-服务器主动交互-SSE-流-vs-多轮往返"><a href="#3-3-服务器主动交互-SSE-流-vs-多轮往返" class="headerlink" title="3.3 服务器主动交互:SSE 流 vs 多轮往返"></a>3.3 服务器主动交互:SSE 流 vs 多轮往返</h3><p>老模型:服务器要中途要东西(用户确认、模型补全)，就通过挂着的 SSE 流反向发请求。这要求连接始终钉在同一台实例上。</p><p>新模型:服务器返回一个”中间结果”，不再等输入。</p><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment">// 服务器第一次响应:要求输入</span></span><br><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;jsonrpc&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2.0&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;id&quot;</span><span class="punctuation">:</span> <span class="number">7</span>，</span><br><span class="line">  <span class="attr">&quot;result&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;resultType&quot;</span><span class="punctuation">:</span> <span class="string">&quot;input_required&quot;</span>，</span><br><span class="line">    <span class="attr">&quot;requestState&quot;</span><span class="punctuation">:</span> <span class="string">&quot;服务器签名的base64状态&quot;</span>，</span><br><span class="line">    <span class="attr">&quot;inputs&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span></span><br><span class="line">      <span class="punctuation">&#123;</span></span><br><span class="line">        <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;elicit_1&quot;</span>，</span><br><span class="line">        <span class="attr">&quot;content&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;action&quot;</span><span class="punctuation">:</span> <span class="string">&quot;accept&quot;</span>， <span class="attr">&quot;text&quot;</span><span class="punctuation">:</span> <span class="string">&quot;这段分析缺少用户确认&quot;</span> <span class="punctuation">&#125;</span></span><br><span class="line">      <span class="punctuation">&#125;</span></span><br><span class="line">    <span class="punctuation">]</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><p>客户端(或模型)收集好输入后，带上 <code>requestState</code> 重发原请求:</p><figure class="highlight json"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br></pre></td><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;jsonrpc&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2.0&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;method&quot;</span><span class="punctuation">:</span> <span class="string">&quot;tools/call&quot;</span>，</span><br><span class="line">  <span class="attr">&quot;params&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;name&quot;</span><span class="punctuation">:</span> <span class="string">&quot;forecast&quot;</span>，</span><br><span class="line">    <span class="attr">&quot;arguments&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;city&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Berlin&quot;</span> <span class="punctuation">&#125;</span>，</span><br><span class="line">    <span class="attr">&quot;inputs&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;elicit_1&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;action&quot;</span><span class="punctuation">:</span> <span class="string">&quot;accept&quot;</span>， <span class="attr">&quot;content&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;text&quot;</span>， <span class="attr">&quot;text&quot;</span><span class="punctuation">:</span> <span class="string">&quot;ok&quot;</span> <span class="punctuation">&#125;</span> <span class="punctuation">&#125;</span></span><br><span class="line">    <span class="punctuation">&#125;</span>，</span><br><span class="line">    <span class="attr">&quot;_meta&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;io.modelcontextprotocol/requestState&quot;</span><span class="punctuation">:</span> <span class="string">&quot;服务器签名的base64状态&quot;</span> <span class="punctuation">&#125;</span></span><br><span class="line">  <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><p>因为状态随请求走，重试打到哪台实例都无所谓。<strong><code>requestState</code> 是安全边界</strong>:它对客户端不透明但不可信，客户端可能篡改后再丢回来，必须签名或加密，绝不要在线上传裸的内部状态然后当场信任。</p><h3 id="3-4-能力与扩展"><a href="#3-4-能力与扩展" class="headerlink" title="3.4 能力与扩展"></a>3.4 能力与扩展</h3><table><thead><tr><th>维度</th><th>老版</th><th>新版</th></tr></thead><tbody><tr><td>富交互 UI</td><td>无标准</td><td>MCP Apps:工具返回沙箱内 HTML&#x2F;UI 模板，用户在对话框里直接交互</td></tr><tr><td>长任务</td><td>同步阻塞式结果</td><td><code>tasks/get</code> 轮询 + <code>tasks/update</code> 进度更新;<code>tasks/list</code> 已删除;服务器可主动返回任务句柄</td></tr><tr><td>采样(Sampling)</td><td>服务器向模型要补全</td><td>协议级弃用(SEP-2577)，由 MRTR 模式替代</td></tr><tr><td>Roots</td><td>客户端向服务器暴露本地路径</td><td>弃用(客户端支持度一直很低)</td></tr><tr><td>Logging</td><td>session 级 <code>logging/setLevel</code></td><td>改为每请求的 <code>logLevel</code></td></tr><tr><td>授权</td><td>Dynamic Client Registration</td><td><code>iss</code> 参数校验(RFC 9207)+ Client ID Metadata Documents(CIMD)</td></tr></tbody></table><h2 id="4-参考资料"><a href="#4-参考资料" class="headerlink" title="4. 参考资料"></a>4. 参考资料</h2><ul><li><span class="exturl" data-url="aHR0cHM6Ly9ibG9nLm1vZGVsY29udGV4dHByb3RvY29sLmlvL3Bvc3RzLzIwMjYtMDctMjgv">The 2026-07-28 Specification – Model Context Protocol Blog<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly90cy5zZGsubW9kZWxjb250ZXh0cHJvdG9jb2wuaW8vdjIvcHJvdG9jb2wtdmVyc2lvbnMuaHRtbA==">Protocol versions(era 对比矩阵与 API)– TypeScript SDK 文档<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly93d3cuY29kZXdpdGhzZWIuY29tL2Jsb2cvbWNwLTIwMjYtMDctMjgtc3RhdGVsZXNzLXNwZWMtbWlncmF0aW9uLWd1aWRl">MCP Goes Stateless: What the Spec Breaks in Your Server(迁移指南)– Code With Seb<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly9jbGF1ZGUuY29tL2Jsb2cvYnJpbmdpbmctbWNwLTIwMjYtMDctMjgtdG8tY2xhdWRl">Bringing MCP 2026-07-28 to Claude – Claude Blog<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly9tb2RlbGNvbnRleHRwcm90b2NvbC5vcmcvc2Vwcy8yNTY3LXNlc3Npb25sZXNzLW1jcA==">SEP-2567: Sessionless MCP<i class="fa fa-external-link-alt"></i></span> · <span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL21vZGVsY29udGV4dHByb3RvY29sL21vZGVsY29udGV4dHByb3RvY29sL2Jsb2IvbWFpbi9zZXBzLzI1OTYtc3BlYy1mZWF0dXJlLWxpZmVjeWNsZS1hbmQtZGVwcmVjYXRpb24ubWQ=">SEP-2596: Spec feature lifecycle and deprecation<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL21vZGVsY29udGV4dHByb3RvY29sL21vZGVsY29udGV4dHByb3RvY29sL2Jsb2IvbWFpbi9kb2NzL3NwZWNpZmljYXRpb24vZHJhZnQvYmFzaWMvdmVyc2lvbmluZy5tZHg=">Specification draft: versioning(兼容矩阵)<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly93ZWJhZnRlcmFpLnN1YnN0YWNrLmNvbS9wL3dlLXByb2JlZC1hbGwtMTQ3Mi1wdWJsaWMtbWNwLXNlcnZlcnM=">We probed all 1，472 public MCP servers. Two pass – Web After AI<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly9wYWNrZXRuZWJ1bGEuY29tL2FydGljbGVzL21jcC0yMDI2LTA3LTI4LXdoYXQtc3RhdGVsZXNzLXJlbW92ZXMv">MCP 2026-07-28: what the stateless core removes – PacketNebula<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly93d3cuc2VjdXJpdHl3ZWVrLmNvbS9uZXctZW50ZXJwcmlzZS1yZWFkeS1tY3Atc3BlY2lmaWNhdGlvbi1icmluZ3MtbmV3LXNlY3VyaXR5LWNoYWxsZW5nZXMv">Bringing New Enterprise-Ready MCP Spec Brings New Security Challenges – SecurityWeek<i class="fa fa-external-link-alt"></i></span></li><li><span class="exturl" data-url="aHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZWJsb2cuY29tL3NjYWxpbmctYWktYWdlbnQtaW5mcmFzdHJ1Y3R1cmUtd2l0aC10aGUtbWNwLXN0YXRlbGVzcy11cGRhdGVzLw==">Scaling AI Agent Infrastructure with the MCP Stateless updates – Google Developers Blog<i class="fa fa-external-link-alt"></i></span></li></ul>]]>
    </content>
    <id>https://hisen.me/20260809-mcp-big-version-in-2026/</id>
    <link href="https://hisen.me/20260809-mcp-big-version-in-2026/"/>
    <published>2026-08-09T15:07:00.000Z</published>
    <summary>
      <![CDATA[<h2 id="1-概览"><a href="#1-概览" class="headerlink" title="1. 概览"></a>1. 概览</h2><blockquote>
<p>一句话总结：协议从”有状态、靠长连接”变成”无状态、靠 HTTP 请求”。</p>
</blockquote>
<p>2026 年 7 月 28 日，MCP 发布了算得上”有史以来最大”的一次规范修订。<br>同一时间，官方四套 Tier 1 SDK(TypeScript、Python、Go、C#)同步更新。</p>
<p>MCP SDK 月下载量已突破 4 亿（TS&#x2F;Python 累计超 20 亿），部署服务器过万；<br>但新规范生态跟进极慢，抽样 1470+ 公开服务器中完全合规的仅 2 个，尚未出现全面切换。</p>
<h2 id="2-变更的初衷和重点"><a href="#2-变更的初衷和重点" class="headerlink" title="2. 变更的初衷和重点"></a>2. 变更的初衷和重点</h2><h3 id="2-1-为什么改"><a href="#2-1-为什么改" class="headerlink" title="2.1 为什么改"></a>2.1 为什么改</h3><p>MCP 2024 年诞生时，本质上只是为单机笔记本设计的协议：</p>
<ul>
<li>一个客户端、一个服务器、一条 stdio 管道、一个与进程同生死的长连接会话（Session）。</li>
<li>对本地单机调用而言，这个设计极其精准且够用。</li>
</ul>
<p>但当它被推向生产环境时，企业不得不为这套“本地模型”付出四笔沉重代价：</p>
<ul>
<li>Serverless 适配瘫痪：旧协议强依赖长连接和 Session，而 Serverless（AWS Lambda、Cloud Run、Cloudflare Workers）没有常驻进程，在物理层面就无法运行。</li>
</ul>]]>
    </summary>
    <title>2026 MCP 大版本更新</title>
    <updated>2026-09-13T14:37:46.928Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Reading" scheme="https://hisen.me/categories/reading/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <category term="阅读" scheme="https://hisen.me/tags/%E9%98%85%E8%AF%BB/"/>
    <content>
      <![CDATA[<h1 id="1-读后感"><a href="#1-读后感" class="headerlink" title="1. 读后感"></a>1. 读后感</h1><p>全球化时代，你中有我，我中有你。<br>短时间内很难撇清关系，虽然很别扭，但是还得拉着脸合作。<br>新时代的竞争，和冷战差不多，甚至更严重，双方都制造假想敌，不断竞争。<br>提出假想敌的那些人也可能是为了让自己多争取点资源，扩大自己的一亩三分地。</p><h2 id="1-1-金融"><a href="#1-1-金融" class="headerlink" title="1.1 金融"></a>1.1 金融</h2><blockquote><p>SWIFT 系统（环球银行金融电信协会）是全球金融机构用于安全、标准化传输支付和交易指令的主力通信网络，连接了200多个国家和地区的逾11,000家机构。它本身不持有资金或提供账户结算，而是传递促成资金流动的加密报文。<br>它是美元清算纽带，全球贸易超 80% 依赖美元结算。美国通过控制美元清算系统（CHIPS），对主要通过 SWIFT 传递的美元交易拥有实际上的否决权。<br>替代网络：为降低对西方主导系统的依赖，各国正推进如中国的人民币跨境支付系统（CIPS）或多边央行数字货币桥（mBridge）等替代和互补基础设施。</p></blockquote><p>俄罗斯：俄乌战争发生后，欧美迅速把俄罗斯踢出了 SWIFT，还把存在欧洲的外汇储备给冻结了。<br>结果跨境贸易瘫痪、外汇收入归零、货币剧烈贬值、通道成本飙升、外资加速外逃，最后可能得回到以物易物。</p><p>林振月蛾：由于 2020 年香港某法案实行后，被美国制裁。<br>所有银行都不敢给他开户，包括中国的银行，因为都怕被踢出 SWIFT 系统，没法处理外汇相关业务。</p><span id="more"></span><p>数字货币、去中心化这些理念上是好的，但现在看来大部分都中心化了。<br>因为人、物理设备是受管制的，没法脱离现实世界运行。<br>货币想全球化，需要有稳定的政策，还有相互制约的权力，否则很难获得信任。</p><h2 id="1-2-网络"><a href="#1-2-网络" class="headerlink" title="1.2 网络"></a>1.2 网络</h2><p>在 1999–2002 年间，全球 95% 以上的国际互联网带宽连接点都落在美国。<br>所以监听很方便，在相关核心网络节点直接通过物理手段介入，直接监听。<br>早期互联网起源于美国，后续建设也是围绕美国开始的星形网络。</p><p>近年来也有很多跨境光缆没有途经美国，甚至互联网大厂为了自身信誉，不断加强加密方式，避免监听。<br>但是美国可以通过给互联网巨头（例如：亚马逊云、谷歌云、微软云）施压，来交出相关的数据。</p><h2 id="1-3-半导体"><a href="#1-3-半导体" class="headerlink" title="1.3 半导体"></a>1.3 半导体</h2><blockquote><p>FDPR（外国直接产品规则）：这是最霸道的长臂工具。美国规定，只要全球任何企业在生产过程中，使用了哪怕 1% 的美国软件（如 EDA 芯片设计工具）或美国设备（如应用材料、科磊的机器），美国就有权禁止该企业向特定对手（如华为）供货。</p></blockquote><p>台积电（TSMC）的成功，最初正是奠定在其独创的“纯代工（Pure-play Foundry）模式”上——“不与客户竞争，对所有客户保持中立，帮所有人把生意做大”。<br>但是遇到地缘政治，在当前的背景下，完全没有办法真正中立。<br>有的是办法影响你的供应链，让你没法生产。</p><p>华为在 5G 领域或者通信领域的崛起，担心后续中国会夺取网络帝国，实现各种监听。<br>于是就有了孟晚舟事件，以及限制台积电给华为供货(华为贡献了台积电 15% 左右的收入)。</p><h1 id="2-原始笔记"><a href="#2-原始笔记" class="headerlink" title="2. 原始笔记"></a>2. 原始笔记</h1><blockquote><p>由于是台湾出版的书籍，里面有些涉及国家以及领导人的内容，我给去掉了。</p></blockquote><p>这个帝国并非靠传统的领土和军事力量统治，而是以维系全球经济运作的系统为立国基石，无声地影响著每一个人的日常生活。</p><p>美国与欧盟如何透过掌握全球资讯流与金融交易的关键环节，将经济与科技资源转化为地缘政治工具，实现对敌人与盟友的精密控制。</p><p>本书由两位身在华府的约翰．霍普金斯大学和乔治城大学教授合写，靠著他们多年来在华府的观察和理解，为读者创造出一种认识美国国力的新论述。</p><p>本书为读者解析美国如何利用掌控国际金融秩序、金融交易、美元的优势、先进科技技术，从云技术、半导体，到光纤通信，<br>再到包括对石化和新能源的开发、最新的加密货币等，来确保自己的超级强权地位，甚至来惩罚像是北韩，伊朗和俄罗斯等敌人。</p><p>网路的世代，大家也以为最美好的蓝图是“去中心化”、“去政府化”、“自由化”。但现实与理想总有极大的差距。<br>本书作者告诉我们，这些新型的底层服务久而久之也会像传统的道路一样，趋向中央集权。<br>政府和企业的权力会交互强化，政府也比较叫得动大型的集权企业，去做政府想做的事情。</p><p>当某位总统，或是他的继任者，可能会利用你们之间的依赖关系来对付你，那么，谁还愿意将生产网络与美国经济深度整合？</p><p>美利坚帝国依然仰赖军事力量来维持地表贸易路线的畅通，派遣美国海军巡弋全球海上航线。<br>然而，美国的权力也随著埋藏于地下的光纤电缆，迂回渗入如网际网路和银行通汇所需的复杂金融基础设施。</p><p>路径依赖：即早期的决定（如城市选址、宪法内容的制定）如何制约了我们今天的行动。</p><p>到了 1990 年代，随著全球化全面展开，廉价的全球运输基础设施结合宽松资金和低成本通讯，澈底改变了全球经济。<br>李斯顿指出，这标志著“世界工作的根本性变化”</p><p>库克以“存货即罪恶”的理念闻名，在接下来数年重塑苹果的供应链，并与LG和富士康（Foxconn）等代工伙伴建立紧密合作。<br>富士康总部设于台湾，在中国大陆雇用约一百三十万名员工。</p><p>iPhone 背面那句著名的“由苹果在加州设计，在中国组装”<br>（Designed by Apple in California. Assembled in China），正是许多企业纷纷效仿的商业模式。</p><p>美国始终保留了一项权利──尽管在经济繁荣时期少有人留意──当某项技术中美国拥有的知识产权比例超过特定百分比时，美国便有权控制该技术。</p><p>类似“风暴酿造”的计划使国安局得以存取电信网路资讯流中的上游数据；而“棱镜”（PRISM）等计划，<br>则让国安局能向微软和 Google 等公司索取更具针对性且结构化的下游数据。</p><p>Google 和微软开始对自身的资料流进行加密，使美国及其他政府更难以暗中监听骨干网路。<br>Google 更运用 Chrome 浏览器的影响力推动其他企业加密通讯。</p><p>如今，情报收集与经济制裁已成为财政部核心使命的一部分。这一切的转变始于二○○一年九月十二日。</p><p>经过谈判，欧洲和美国最终达成协议：在增设保护措施的前提下，美国可以继续从 SWIFT 获取数据，并与欧洲各国政府共享这些资料。<br>由于欧洲各国政府受限于严格的隐私法规而无法自行搜集数据，最终在金融情报与分析领域高度依赖美国。<br>随说：曲线救国</p><p>SWIFT 已从一个政治独立的组织，蜕变为美国政府无所不知的助手。<br>这个原本应协助银行抵御政府监管的机关，如今凭借其对国际金融交易的全面掌握，得以绘制出跨境金流的隐密版图。</p><p>一旦一家国际银行被认定为资助恐怖主义，它就无法保有代理帐户（correspondent account），也就无法为非美国客户进行美元交易。<br>所以大家都惧怕 OFAC，被OFAC盯上的非金融企业或个人也将面临类似的命运。<br>一旦被列入名单，他们同样会失去进入国际银行体系的机会。</p><p>美国在追查澳门汇业银行（Banco Delta Asia）时，意外发现“美元单边主义”的惊人效力。<br>该银行总部设于中国管辖的澳门特别行政区，秘密为北韩政府提供进入全球金融市场的管道。</p><p>澳门汇业银行案为OFAC的后续行动奠定了行动范本。财政部的金融绘图师随即展开密集工作。</p><p>随著时间的推移，美国的制裁执行策略从“钓鱼式”的全面追查违规者，<br>逐渐转变为学者布莱恩．厄尔利（Bryan Early）和凯文．普雷布（Kevin Preble）所描述的“猎鲸式”行动，<br>即借由对大型外国银行施加巨额罚款，震慑其他所有金融机构。</p><p>对这些受到处罚的银行而言，他们几乎别无选择，只能接受处罚。<br>在美国法院推翻这些裁决几乎毫无希望，而且还面临著可能失去美国银行营运执照以及美元清算系统使用权的风险。<br>甚至只要美方发出看来确实可能执行的撤销清算权限威胁，就足以让这些银行迅速陷入崩溃。</p><p>多数评论者只关注大银行支付的天价罚款，鲜少人注意到美国要求法国巴黎银行、汇丰银行等建立全面性的内部监控系统，以确保日后合规。<br>法国巴黎银行必须在美国设立一个 OFAC 法遵办公室，“直接受美国监管机关监督”，以确保全球营运均符合规范。<br>汇丰银行也必须在纽约作出相同安排，同样“在美国直接监管下”运作。<br>这些曾帮助客户规避美国制裁或洗钱规定的大型银行，<br>如今不得不自掏腰包建置并营运庞大的内部监控系统，而这些系统能为美国当局提供重要情报。</p><p>如果其他国家继续以接近的价格向伊朗提供类似产品，美国对伊朗的贸易制裁就会显得徒劳无功。<br>随说：退回到以物易物</p><p>然而，撤销国际措施几乎是不可能的。一种基于制造恐惧、敬畏和威慑的政策，无法像水龙头一样随意开关。<br>当欧巴马政府官员敦促欧洲银行向伊朗提供贷款，并鼓励企业在伊朗进行投资时，他们发现几乎无人响应。<br>银行和企业担心美国当局可能会再次改变立场，利用OFAC模糊的裁定和规则，指控他们违反制裁并施以严厉惩罚。<br>随说：这就是传说中的政策稳定性？</p><p>卢提出，这种做法不仅会随时间推移削弱其效力，还可能动摇美国在全球经济中的主导地位。<br>过度扩张可能“最终导致商业活动远离美国金融体系”。</p><p>如同在其他领域，美国已成功地制定了世界运作的规则，从而重塑了整个世界。<br>然而，随著美国的权力愈发昭然，且愈愿意运用这种权力，其他国家政府和企业也愈发有理由去建立自己的替代性规则体系。</p><p>华为的起步极为简单，只是一家从事儿童气球和火灾警报器买卖的贸易公司。<br>当任正非的公司偶然涉足电话交换机业务时，他敏锐地看到了真正的机会：<br>要摆脱农村贫困的困境，中国必须建设现代化的电话系统，这需要完善的网络，而网络建设则离不开交换机。</p><p>华为的“规模、无处不在，以及与中国政府的密切关系”意味著，<br>问题的核心在于它的“巨大影响力及未来可能带来的风险”，而非其当前的具体行为。</p><p>英国曾向美国表示，中国的监控威胁是可控的，因为华为的技术漏洞百出，英国的情报系统已成功渗透这些系统。<br>然而，美国官员对此说法并不以为然。他们真正担心的是，华为可能协助中国建立一个全球性的网路帝国，将美国推向边缘。</p><p>美国的全球金融帝国不仅是逮捕孟晚舟的理由，更是实现这一行动的手段。<br>若没有这个帝国的存在，汇丰等外国银行不会如此甘愿服从美国的要求。<br>但在这个帝国之下，银行若要生存，就必须仰赖美元清算系统。</p><p>当美国以侵犯人权为由制裁香港时任行政长官林郑月娥，<br>这位在当时治理香港并成为反民主镇压象征的官员──时，发现她竟无法在中国的银行开设帐户。<br>由于美国拥有将个人、企业和机构列为制裁对象的权力，中国的银行为避免违反制裁规定，皆拒绝为她提供服务。<br>林郑只得以现金支薪，在其官邸──一座殖民时期遗留、配有双泳池的总督府──四处堆积著成叠的钞票。</p><p>俄罗斯企业在入侵乌克兰后，为了规避制裁，开始使用人民币而非美元进行支付与收款。<br>2015 年，中国建立了“人民币跨境支付系统”（Cross-Border Interbank Payment System, CIPS），作为类似于 SWIFT 的国际支付系统。</p><p>尽管中国无法掌控全球经济的关键管道，它依然握有一项可供运用的武器：进入中国市场的门票。<br>随著数亿消费者逐步跻身全球中产阶级，各国企业无不渴望打入这片庞大市场，而制造商对工具机、原材料、石油、煤炭等各类商品的需求也依然强劲。</p><p>中国面临的问题在于，这些报复工具往往具有自我设限的特性。<br>限制挪威鲑鱼进口，对中国本身影响不大，但只要其他国家仍在购买鲑鱼，对挪威的伤害也极为有限。<br>而更严厉的报复措施，则可能导致中国自身受损，甚至与目标国两败俱伤。<br>随说：比如铁矿石</p><p>中国想要伤害其他国家，往往必须付出自身代价；有时候即便付出了代价，中国也难以真正对其他国家造成多大的伤害。</p><p>与美国不同的是，中国并未掌控世界经济运行的地下机制中任何“卡脖子的地方”。<br>在 1990 年代末期，当网际网路和全球金融迅速崛起时，中国才刚开始重新与世界接轨，根本没有足够时间去影响全球基础设施的演进方向。</p><p>从经济规模来看，中国已是全球强权；但若论其对全球经济网络的影响力，中国充其量只是个陪跑者。<br>美国则凭借其“地下帝国”，将施压的沉重代价转嫁给盟友与对手。</p><p>欧盟在安全上依赖美国，在能源上依赖俄罗斯，在贸易上依赖中国。而这些依赖并未给它带来显著的困扰。</p><p>现代德国经济的基础建立在俄罗斯能源供应之上。<br>冷战结束后，德国和其他北欧国家不断寻求获取俄罗斯天然气的新途径，<br>而 Gazprom 则致力于为输气管道寻找绕过乌克兰的替代路线，<br>因为乌克兰试图从连接西伯利亚与西欧的管道中廉价攫取部分气源。</p><p>最后，胡克在船长迟迟未回应时替他作出了决定，通知他已经被美国列入制裁名单。<br>船长的困境正是全球商业困境的缩影。产业界以追求效率和利润为名，耗费数十年构建国际市场，而美国政府却将这些经济网络化作枷锁与束缚。</p><p>在接下来的数十年里，史密斯（后来升任微软总裁兼总法律顾问）成功地将微软从一家以无视法律而臭名昭著的企业，<br>转型为因与政府合作而蓬勃发展的企业典范。分拆的威胁最终消逝于历史记忆之中。</p><p>如果湾统一，台积电将会面临怎样的未来？而如果全球最重要的先进半导体制造公司落入美国对手的治理之下，美国又将如何应对？</p><p>中本聪的这项发明与其说是把稻草变成黄金，不如说是把耗费的电脑算力转化成了黄金。</p><p>有些公司，如台积电，采取模糊策略，表面维持中立，实则默认强权的影响力。<br>其他公司，像微软，已放弃追求中立独立的野心，转而选择靠拢某一方。</p><p>中国在建立自身帝国的过程中，有一个根本性的弱点：政府难以取信于其他国家、企业和普通民众，因为它总是在有利可图时毫不犹豫地加以利用。</p><p>美国越是依赖自身的金融实力、技术控制能力，以及在全球网络中的核心地位来施加管控，就越可能落入中国设下的陷阱。</p><p>2022年4月22日，中国政府的财政部与人民银行召集数十家本地及国际银行，<br>举行了一场紧急会议，讨论若中国同样遭到国际金融体系排除，应该如何应对。<br>会上有人提到或许可以将其外汇储备转移至欧元和日圆，但在危机时刻，美国的盟友未必会比美国更加可靠。</p><p>中国金融领域的脆弱性，迫使它不得不顺应美国对俄制裁措施。<br>美国国务卿布林肯威胁道：“中国若采取任何行动支持俄罗斯侵略，必将承担相应后果。不论需要付出什么代价，我们都不会犹豫。”<br>随说：排除在 swift 外，外汇被冻结</p><p>除非迫不得已，中国以外几乎没有任何机构愿意使用人民币跨境支付系统（CIPS）。<br>该系统以人民币为基础，但由于中国需要严格管控跨境资金流动，人民币在国际市场上还不是在各处都能兑换到。</p><p>对其他国家而言，将金融资产转移至一个由中国主导、与全球金融体系半脱节，还受制于政府政策朝令夕改的体系中，显然不符合常理。<br>美国虽然有时难以捉摸，但至少有法治作为根基。反观中国，并无足够健全的法律体制来约束政府攫取其认为必要的资源。<br>为实施清零政策，中国政府甚至毫不犹豫地让香港和上海这两大金融中心与世界隔绝。<br>随说：矮子里拔将军</p><p>历史上所有主要储备货币的发行国，无一例外都实行共和或民主制度，并对行政权力有所制衡，这绝非偶然。<br>如果缺乏这种制衡机制，政府便难以获取信任。</p><p>随著中国意识到与美国关系所蕴含的风险，它愈加努力地建立不受美国监督与控制的经济和金融网络。<br>然而，美国将这些自主化的努力视为谋求霸权的企图，从而使局势进一步恶化。</p><p>双方都认为自己在面对对方时存在根本性的脆弱；在争夺经济与政治命运的过程中，一方的恐惧不断加深另一方的恐惧。<br>双方既无法真正理解对手的动机，也难以全面认识这个他们必须共同生存的全新而复杂的世界。</p><p>弱点可以变成优势──当你无法轻易改变立场时，你的承诺与威胁反而更具说服力。<br>在这样的思维逻辑下，建立有效的核攻击防御系统反而可能是个糟糕的主意。<br>因为一旦开始建设防御系统，对手可能会担心你的下一步就是发动第一击，进而决定提前采取行动以免为时已晚。<br>这些初看令人费解的观点，最终为谢林赢得了诺贝尔经济学奖。</p><p>冷战最出人意料之处，在于两大对手始终未曾直接兵戎相见。<br>他将这段时期称为“长和平”（the Long Peace），并认为这很大程度上得益于双方“相互独立而非相互依赖”。</p>]]>
    </content>
    <id>https://hisen.me/20260801-Underground-Empire-How-America-Weaponized-the-World-Economy/</id>
    <link href="https://hisen.me/20260801-Underground-Empire-How-America-Weaponized-the-World-Economy/"/>
    <published>2026-08-01T12:45:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-读后感"><a href="#1-读后感" class="headerlink" title="1. 读后感"></a>1. 读后感</h1><p>全球化时代，你中有我，我中有你。<br>短时间内很难撇清关系，虽然很别扭，但是还得拉着脸合作。<br>新时代的竞争，和冷战差不多，甚至更严重，双方都制造假想敌，不断竞争。<br>提出假想敌的那些人也可能是为了让自己多争取点资源，扩大自己的一亩三分地。</p>
<h2 id="1-1-金融"><a href="#1-1-金融" class="headerlink" title="1.1 金融"></a>1.1 金融</h2><blockquote>
<p>SWIFT 系统（环球银行金融电信协会）是全球金融机构用于安全、标准化传输支付和交易指令的主力通信网络，连接了200多个国家和地区的逾11,000家机构。它本身不持有资金或提供账户结算，而是传递促成资金流动的加密报文。<br>它是美元清算纽带，全球贸易超 80% 依赖美元结算。美国通过控制美元清算系统（CHIPS），对主要通过 SWIFT 传递的美元交易拥有实际上的否决权。<br>替代网络：为降低对西方主导系统的依赖，各国正推进如中国的人民币跨境支付系统（CIPS）或多边央行数字货币桥（mBridge）等替代和互补基础设施。</p>
</blockquote>
<p>俄罗斯：俄乌战争发生后，欧美迅速把俄罗斯踢出了 SWIFT，还把存在欧洲的外汇储备给冻结了。<br>结果跨境贸易瘫痪、外汇收入归零、货币剧烈贬值、通道成本飙升、外资加速外逃，最后可能得回到以物易物。</p>
<p>林振月蛾：由于 2020 年香港某法案实行后，被美国制裁。<br>所有银行都不敢给他开户，包括中国的银行，因为都怕被踢出 SWIFT 系统，没法处理外汇相关业务。</p>]]>
    </summary>
    <title>《地下帝国：金融、网络、半导体---美国如何将世界经济武器化》读后感</title>
    <updated>2026-09-13T14:37:46.939Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Reading" scheme="https://hisen.me/categories/reading/"/>
    <category term="AI 工程" scheme="https://hisen.me/tags/ai-%E5%B7%A5%E7%A8%8B/"/>
    <category term="Agent" scheme="https://hisen.me/tags/agent/"/>
    <category term="阅读" scheme="https://hisen.me/tags/%E9%98%85%E8%AF%BB/"/>
    <content>
      <![CDATA[<h1 id="1-概要"><a href="#1-概要" class="headerlink" title="1. 概要"></a>1. 概要</h1><p>Agent 时代，能够加速的是执行过程( 编码、调试等 )</p><ul><li>说明：执行过程最多占开发活动的 50% 时间，来自 Portman 的数据</li></ul><p>但涉及到目的、判断等核心的流程，还是需要人工介入。<br>由于执行过程足够快，需要人工介入的工作会越来越多，瓶颈还在人，提效会遇到天花板。<br>从某个角度讲，AI 加速了我们的生活，其实是变相地增加了人生的长度( 犹如开倍速看电影 )。</p><p>如果通过 Agent 进行 Coding，关键的约束：</p><ul><li>从需求开始就让 Agent 了解</li><li>和 Agent 不断对话沟通，形成决策纪要和执行计划</li><li>执行计划尽量细化，每个步骤尽量有过程约束，而不是指标约束。否则容易作假</li><li>如果 Agent 给出的结果不好，不要直接修改代码，而是修改执行计划，说清楚来龙去脉</li><li>执行过程中有遇到不明确的，让 Agent 不要自己发挥，需要人工补全确认</li><li>如果上下文耗尽等导致效果不佳，重新开一个窗口按执行计划让 Agent 接着工作( 有状态+业务上下文 )</li><li>Code Review 等也用新窗口拿着执行计划执行，避免不干净的上下文影响</li></ul><p>核心就是让 Agent 有足够的上下文，有可验证的过程产出，而非简单的评估指标。</p><h1 id="2-精简笔记"><a href="#2-精简笔记" class="headerlink" title="2. 精简笔记"></a>2. 精简笔记</h1><p>《人月神话》是 Fred Brooks 1975 年写的一本管理书。<br>他管过 OS&#x2F;360，那是 IBM 的大型机操作系统，1960 年代人类做过的最大一次软件工程。<br>项目结束他没写技术总结，写了一本关于为什么大项目总是延期、为什么加人只会加得更慢、为什么概念完整性是设计的最高目标的书。<br>《人月神话》写完之后成为整个软件行业的地基。<br>+++<br>Brooks 那本书的第一批读者是 1970 年代的项目经理。这本书的读者是 2026 年之后的开发者。<br>中间隔了半个世纪，一切都在变，唯有一件事没变：软件工程的核心是判断的组织( 把各种决策判断有机整合 )。<br>软件最贵的成本是维护与演进。好的组织方式，能让你在“增加新判断”或“修改旧判断”时，付出最小的边际成本。<br>+++<br>在 Agent 时代卓越的工程师，<br>应该投时间在判断和决定的文档上，<br>文档写成能被机械执行的源码级材料，<br>因为代码是 Agent 从文档编译的产物。</p><span id="more"></span><p>+++<br>Agent 是伟大偶然困难的消灭者，写代码、写文档、写测试、跑 debug、追依赖等的成本大幅下降。</p><p>Agent 没有触及本质困难。判据谁持有、目的谁负责、概念完整性谁守护、里程碑谁设计。<br>这些工作没有因为 Agent 而减少，反而因为总产出多了，占用总成本上升了。<br>在项目里，判断的成本在过去两年可能翻了一倍不止。<br>+++<br>人机分工线沿着”能不能被形式化定义”这条边界走。<br>能被形式化的（代码、测试、文档格式），交给 Agent。<br>不能被形式化的（目的、判据、处境判断），留给人。<br>守住这条分工线，两侧都做得最好；打乱这条分工线，两侧都做不好。<br>+++<br>Mills 提出的外科手术队伍编制表大概是这样：</p><ul><li>主刀（chief programmer &#x2F; surgeon）：定义规格，写核心代码，做所有关键设计决策，为整个产品的正确性和完整性负责。这是唯一持有整个系统概念的人。</li><li>副手（copilot）：主刀的影子，能替代主刀（比如主刀请假时接手），日常也参与讨论和评审。这个角色的存在让主刀敢做决定，因为知道有人在同一个理解水位上审核。</li><li>管理员（administrator）：处理项目管理事务（预算、进度、行政），把主刀从这些事务里解放出来。</li><li>文档编辑（editor）：把主刀写的初稿文档整理成正式文档。</li><li>程序录入员（program clerk）：管理项目的所有文件、版本、变更历史。1970 年代这是重体力活。</li><li>工具管理员（toolsmith）：维护开发环境、工具链、编译器。</li><li>测试员（tester）：设计和跑测试用例。</li><li>语言律师（language lawyer）：精通编程语言的深奥细节，供主刀咨询。</li><li>秘书（secretaries）：更基础的文书工作。</li></ul><p>当代最小可用软件编制：一个人做主刀，一群 Agent 担任支持团队。<br>+++<br>Brooks 说，一个成功的架构师团队的纪律：</p><ul><li>记住实现者才是承担创造性责任的人。架构师只能建议，不能替实现者做实现层的决定。</li><li>随时准备为自己的建议提供一种可行的实现方法，同时随时准备接受实现者提出的其他可行方案。</li><li>对自己的建议保持低调和平静。</li><li>随时准备为你建议的改进放弃功劳。</li><li>认真听取实现者在体系结构上的改进建议。</li></ul><h1 id="3-阅读摘录"><a href="#3-阅读摘录" class="headerlink" title="3. 阅读摘录"></a>3. 阅读摘录</h1><blockquote><p>原文地址：<span class="exturl" data-url="aHR0cHM6Ly9naXRodWIuY29tL01lYXJpLVByb3RvdHlwZS9hZ2VudC1teXRoaWNhbC1tYW4tbW9udGgtMjAyNi90cmVlL21haW4vYWdlbnQtJUU2JTk3JUI2JUU0JUJCJUEzJUU3JTlBJTg0JUU0JUJBJUJBJUU2JTlDJTg4JUU3JUE1JTlFJUU4JUFGJTlE">Agent时代人月神话 - Github<i class="fa fa-external-link-alt"></i></span></p></blockquote><p>Brooks 的核心观察是，一段能跑的程序，跟一件能被人依赖的软件产品之间，工作量差九倍。这个九倍不是拍脑袋数字，是两个三倍的乘积。</p><ul><li>产品化</li><li>系统集成</li></ul><p>产品化：从”我自己能跑”到”别人也能跑”，中间要加：文档（别人怎么用）、测试（哪些情况经过验证）、错误处理（用户输入奇怪的东西怎么办）、边界情况（空输入、超大输入、并发调用）、可维护性（半年后你想加个功能，代码结构容不容易改）、可观测性（挂了你怎么知道）。这一层的工作在演示视频里看不见，在产品运行的每一分钟都在起作用。</p><p>系统集成：从”独立跑得动的模块”到”能嵌入一个更大系统的构件”，中间要加：接口对齐（跟其他模块的契约怎么定）、版本兼容（依赖升级会不会挂）、多环境隔离（本地、预发、生产表现一致吗）、部署方案（怎么发布、怎么回滚）、监控告警、备份策略。这一层跟第一层是正交的，两者都要做，且都各自吃三倍工作量。</p><p>不对称塌陷比 1975 年的均匀焦油坑更危险，因为它制造了一个更强的错觉。”我做完了”的心理判断被大幅提前，从”这个系统上线运行了三个月”提前到”这段代码在我本地跑通了”，甚至提前到”agent 说它跑通了”。九倍矩阵剩下的八份工作没有消失，它们被延后到上线之后、用户投诉之后、下一版重构时，一次性地爆发在维护阶段。</p><p>软件项目里最痛苦的部分之一，是你为之工作的那些东西，上游 API、操作系统、第三方库、云服务商，不受你控制，但你要为它们的坏特征负责。</p><p>agent 时代新增了一层不可控物：agent 本身。你不能直接决定它下一步会怎么响应，同一个提示词今天的输出和明天的输出可以不同，同一个任务这次给强档模型和下次给弱档模型可以走完全不同的路径。你负责结果，但你不能完全控制过程。这是一种升级版的”权威不等同于责任”。</p><p>Brooks 观察到，就算是最有创造性的软件工作，大部分时间也花在枯燥的例行公事上：写单元测试、修构建脚本、追依赖版本、读日志找错。</p><p>等到你的项目大到不能一次性把所有代码直接塞进模型上下文，枯燥劳动立刻随之而来。</p><p>越接近完成收敛越慢。这条五十年不变，agent 时代也不变。原因是任何软件的最后 10% 都是最”处境化”的部分：边界情况、性能调优、和真实用户交互的细节。这些都是 agent 目前最难做的部分，判据都住在处境里，不住在被写的代码里。9 成完成到 10 成完成这段路，在 agent 时代甚至可能变得更慢，因为你前 9 成用 agent 做得太快，进入最后 10% 时你会突然发现 agent 帮不上什么忙，节奏被打断，速度骤降。开发者会体验到一种前 5 天像一日千里、最后 3 天像陷在泥里的落差。这种落差在 1975 年也存在，只是没有 2026 年这么锋利，那时候前 5 天没有这么快，落差不明显。</p><p>人月神话当代版：一个 agent 会话十小时才能做完的活，开十个 subagent 一小时就能做完。</p><ul><li>这个 refactor 太大了，我们把它拆成十个 subagent 并行做吧</li><li>用五个并行的 Claude Code 修完了整个仓库的 lint 错误</li></ul><p>Brooks 说程序员是乐观主义者，一切都将运作良好。他把根源归到介质。<br>程序员工作在纯粹思维的介质上，脑子里能想通的东西就以为等于键盘上能敲对的东西。介质越纯，人越乐观。<br>脑子和产物之间的摩擦越少，越容易误以为产物就是脑子的直接投影。</p><p>2026 年的 agent 用户是这条乐观主义的极限形态。介质又纯了一层，从代码退到了自然语言。<br>你现在的产物和你的思考之间隔的不再是”我能不能把这段逻辑写对”，是”我能不能把这段要求说清楚”。<br>而说话，是所有人都从两岁开始就在做的事情。<br>人对自己”能不能说清楚”这件事的自信心，天生就比对”能不能写对”的自信心高。<br>随说：有几个人可以说清楚一件事？没有和别人碰撞的情况下</p><p>Brooks 的比喻是收麦子和生孩子。收麦子人越多越快，生孩子安排多少人都是九个月。<br>软件里对应两类工作，可以并行的（每个人做一个子任务，最后拼起来）和不能并行的（这一步必须等上一步完成、这一次判断必须等上一次判断收敛）。</p><p>一个 refactor 需要跨模块修改。你把它拆成”改 A 模块”、”改 B 模块”、”改 C 模块”三个 subagent 并行。<br>听起来合理。真实情况是，<br>改 A 时你会发现 A 依赖 B 的一个内部约定，那个约定改完之后 A 里的一些假设变了；<br>改 B 时你会发现 B 里有一个被 C 隐式依赖的性质；<br>改 C 时你才发现它的正确性其实建立在 A 的一个旧行为上。<br>这些依赖是语义层的，不是 API 层的，任务图上没有这些边，agent 也无法预先声明它们。<br>三个 subagent 并行做完，你拼回来的时候得到的是三份互相踩坑的 diff，<br>然后需要一个主 agent 或者一个人花几倍时间来 reconcile。</p><p>上面三种场景的共同底层原因是：子任务之间存在语义依赖，语义依赖不在图上。<br>它住在处境里，需要一个持有全局的主体不断更新对全体子任务的理解。<br>这个主体在 subagent 结构里通常缺位，主 agent 不看子 agent 的中间过程，子 agent 之间不通气。</p><p>Brooks 说不能任意分割的工作强行分割，损失从两方面来：一是子任务需要合理排序（有依赖），二是子任务之间必须沟通（信息不能孤立）。<br>agent 时代这两条不变，甚至更狠。agent 之间的沟通没有电话可打，它们必须借助文档或者主 agent 的转达，这两个渠道都要额外算力。</p><p>主 agent 要么盲信（承担风险），要么完全读一遍（多花时间，与使用子 Agent 的理念冲突了 ）。</p><p>第一种辩护，只让主 agent 做抽样验证。听起来省时间，不用每个 subagent 的产出都全读，抽查几个就好。<br>抽样在工厂里成立，靠的是一个前提：流水线上的产品是同质的，抽到的几件能代表没抽的那些。</p><p>Brooks 法则：向进度落后的项目中增加人手，只会使进度更加落后。<br>它的机制拆开来是这样：项目已经落后，老手正忙，新加进来的人要培训，老手不得不放下手上的活来培训，老手产出下降，项目更慢，你更想加人。一个负反馈死循环。<br>2026 年的重演有两种形态，一种温和，一种严厉。<br>温和版：向进度落后的 agent 项目里加更多并行会话。</p><p>你有一个功能卡了两天没做出来。你的第一反应是”我开三个平行会话试三种思路，总有一个能成”。三个会话开出来，你现在必须同时管理三个会话的上下文、读三份日志、做三份判断。你的判断带宽本来就是这个项目的瓶颈（毕竟功能都卡了两天了），现在还要一分为三。</p><p>Brooks 把加人的成本拆成三项：任务重新分配、培训新人、额外沟通。<br>agent 时代这三项一项没少，只是换了名字。</p><ul><li>任务重新分配：在人时里是重新划分职责。在 agent 时代是上下文切分。你必须决定主 agent 保留什么、subagent 拿走什么、结果回来后怎么合并到主上下文</li><li>培训新人：在 agent 时代是装填背景。每一个新 subagent（或者每一次新会话）都要从零装填项目背景。项目越复杂，要用的规则越多，上下文也就越长。</li><li>额外沟通：在人时里是开会。在 agent 时代是读 agent 的产出并验证。你的每一份并行工作都需要你去看、去核、去判断合不合并回主线。你以为并行三个 subagent 有三倍效率，实际是三倍产出量、三倍验证量、三倍上下文切换成本。而人的验证带宽是常数，三倍产出压过来，你的时间大半花在追产出上，真正的推进只占零头。<br>三项成本合起来的结构性论断是：agent 时代的沟通开销没有变便宜，反而因为按 token 计费变得更贵也更显眼。它从藏在会议室里、变成了明明白白印在账单上的一笔支出。这是好事，因为可测量的成本才是可以管理的成本；也是坏事，因为很多团队把它当成 agent 系统天生的固定开销，于是不去优化它。</li></ul><p>对于绝大多数需要连贯判断的任务，用一个最强档模型单线跑，往往比用一堆低档模型并行跑要快、要便宜、也要准。</p><p>Brooks 那句”无论安排多少位女性，婴儿仍需要九个月才能出生”，<br>在 2026 年的翻译是：理解一个问题仍需要一个持有全景的主体投入连续时间，无论开多少个 subagent 平行工作。</p><p>既然大项目需要人多，又不能让人多这件事本身摧毁概念完整性和沟通效率，该怎么编制？<br>Brooks 给出的答案是 Harlan Mills 的方案，外科手术队伍（chief programmer team）。<br>核心思想是不要用平等的团队，用一个明确以某一个大脑为中心、其他人全部作为支持角色的结构。<br>就像手术室里，主刀一个人拿刀，其他所有人（副手、麻醉师、护士、器械管理员）都在为主刀提供支持。<br>责任集中在一个人身上，生产率来自整个团队。<br>原因：大型软件的概念完整性没有办法从多个大脑的共识里长出来，只能从一个大脑的持续持有里长出来。<br>共识可以搞定编排，可以搞定接口，搞不定概念。<br>一旦概念被多个大脑分头持有，就长出多个互相不兼容的版本，而这种不兼容比任何技术问题都要昂贵。</p><p>1975 年十倍差全部作用在人上，你选哪个程序员决定一切。<br>2026 年十倍差分成三个作用点：选哪个人、选哪个模型、用哪个 harness。<br>选人的重要性没有下降，从”选一个能写 10 倍代码的程序员”变成了”选一个能编排 10 倍系统的架构师”。<br>而且这三个十倍差是乘性的。<br>一个好的架构师配一个强档模型再配一个精心设计的 harness，跟一个平庸架构师配弱档模型再配粗糙 harness 之间的产出差距，理论上可以达到 1000 倍。</p><p>Mills 提出的外科手术队伍编制表大概是这样（不同资料细节略有出入，我按 Brooks 的描述整理）。<br>主刀（chief programmer &#x2F; surgeon）：定义规格，写核心代码，做所有关键设计决策，为整个产品的正确性和完整性负责。这是唯一持有整个系统概念的人。<br>副手（copilot）：主刀的影子，能替代主刀（比如主刀请假时接手），日常也参与讨论和评审。这个角色的存在让主刀敢做决定，因为知道有人在同一个理解水位上审核。<br>管理员（administrator）：处理项目管理事务（预算、进度、行政），把主刀从这些事务里解放出来。<br>文档编辑（editor）：把主刀写的初稿文档整理成正式文档。<br>程序录入员（program clerk）：管理项目的所有文件、版本、变更历史。1970 年代这是重体力活。<br>工具管理员（toolsmith）：维护开发环境、工具链、编译器。<br>测试员（tester）：设计和跑测试用例。<br>语言律师（language lawyer）：精通编程语言的深奥细节，供主刀咨询。<br>秘书（secretaries）：更基础的文书工作。</p><p>当代最小可用软件编制：一个人做主刀，一群 agent 担任支持团队。</p><p>那么主刀这个角色在 2026 年做什么？Mills 1971 年为主刀写的职责说明，2026 年可以一字不改地领用。<br>持有整个系统的概念。<br>拍板所有关键设计决策。<br>亲自写核心代码（关键路径、有创造性的部分）。<br>为最终产品负责。<br>四条一条没改。变的只是如何做这四件事。2026 年的主刀不用亲手敲全部代码，他用讨论、指令、审阅去完成这些职责。四条职责的内容和权重完全没变。<br>主刀必须持有目的，是 Mills 编制里最深、也最容易被 agent 时代的乐观派忽略的一点。</p><p>对比对话式编程 agent，你的介入手段是什么？直接改代码。你不满意 agent 写的某段，你自己删掉重写；不满意某个决策方向，你在对话里说”停，改用 X 方案”，然后 agent 从那一步继续。这就是修正权。修正权的一个具体测试标准是：你能不能在过程中间改产物，而不用重跑一遍。能，就有；不能，就没有。</p><p>概念完整性来自少数头脑，生产率来自多位协助。</p><p>Brooks 说，团队协作是好东西，评审是好东西，但系统的骨架不能靠投票决定。<br>骨架必须由一个头脑持有、由一个头脑推演、由一个头脑对每一处不一致做出裁决。<br>这就是他所谓的”贵族专制”。</p><p>每个带有各自特点的方案，每一个单独看都是小事，合起来就是不可维护。<br>用户读文档时的困惑、后续开发者接手时的震惊、bug 排查时的抓瞎，全部住在这些小小的不一致里。</p><p>概念完整性的价值不是审美的，是认知经济的。<br>概念完整性为什么必须由一个头脑持有？<br>Brooks 给的理由很直接：因为一个头脑能保证一致性，多个头脑的合成不能。</p><p>两个头脑做设计时，一致性必须外化。头脑 A 做的决策，头脑 B 不知道；要让 B 知道，就要写文档、开会、评审。<br>这些沟通渠道全部会漏东西。文档写不全所有隐含约定（很多约定 A 自己都没意识到，只是”这样感觉对”）；<br>开会讨论的是明面上的分歧，摸不到暗处的默契；评审只能捕捉最严重的不一致，捕捉不到细微的风格漂移。<br>结果就是，两个头脑合作出的系统在每一处不一致点都会付一次学费：<br>要不然一致性错了（长出真正的不兼容），要不然一致性对了但代价高昂（花了大量沟通成本来对齐一件本应自动对齐的事）。<br>随说：协作成本高</p><p>推论有点反直觉：哪怕改动非常小，也最好让 agent 自己改。<br>一行改动的成本从来不在打字上，在于这个决定有没有进入持有项目状态的那个上下文。<br>随说：手动托管改动数据，会导致 Agent 缺乏上下文</p><p>修正权的完整动作从来是两步：改，加上让持有项目状态的那个头脑知道你改了。</p><p>守概念完整性的方式在 1975 年是”由一个人做设计”。<br>在 2026 年是”由一个人持有判据”。两者是同一个动作的两种表述。</p><p>体系结构工作的性质是判断（这个功能要不要有、接口应该长什么样、错误处理选择哪种语义），<br>判断需要持有目的、需要跨领域的处境感、需要对长期演化路径的直觉。这些能力人有，agent 没有。</p><p>实现工作的性质是执行（把已定的接口写出来、把边界情况覆盖住、把错误码返回对）。<br>这些工作需要的是耐心、细致、对语言语法的熟悉、对常见坑的记忆。<br>这些能力 agent 有，且做得比人更快也更仔细。</p><p>体系结构层的产物是文档：需求规范、接口约定、决策记录、协作纪律。<br>实现层的产物是代码：能跑的、能测试的、能部署的。<br>文档由人写，写的时候会迫使上百个细小决定显形（第 10 章会详细展开这个机制）。<br>代码由 agent 写，写的时候要严格贯彻文档里的每一条决定。</p><p>从工程实践的角度：写一份好的需求文档、把接口约定说清楚、把命名规范定下来。<br>这些”写文档”的工作在 agent 时代是最值得投入的一次性成本。它们不是为了记录，是为了给 agent 一个能在里面高效工作的框架。<br>没有这个框架，agent 每写一段代码就是在做一次即兴设计，而即兴设计的合成就是破碎。</p><p>软件系统的骨架，不是被采样出来的，是被设计出来的。<br>而设计需要一个能持续持有整体图景的主体，且这个主体的位置只有人能坐。</p><p>一位架构师做第一个系统的时候，往往是初出茅庐的年轻人。<br>经验有限，胆子小，也没什么时间。他做出来的第一个系统通常是精简的、抓住核心的、有克制的。<br>第二个系统来了。这次他是架构师，有资源，有信誉，有话语权。他开始把过去憋着的想法一个一个装进去。<br>它几乎必然过度设计，几乎必然试图讨好所有过去被亏欠的用户，几乎必然是这位架构师职业生涯里最糟糕的作品。</p><p>Brooks 说，一个成功的架构师影响实现团队的方式，应该遵守五条纪律。我按 Brooks 的意思重述一遍：<br>第一条，记住实现者才是承担创造性责任的人。架构师只能建议，不能替实现者做实现层的决定。<br>第二条，随时准备为自己的建议提供一种可行的实现方法，同时随时准备接受实现者提出的其他可行方案。<br>第三条，对自己的建议保持低调和平静。<br>第四条，随时准备为你建议的改进放弃功劳。<br>第五条，认真听取实现者在体系结构上的改进建议。</p><p>Agent 时代的第二系统，有点像 gpt5.6 的博文<br><span class="exturl" data-url="aHR0cHM6Ly9kZXZlbG9wZXJzLm9wZW5haS5jb20vYXBpL2RvY3MvZ3VpZGVzL3Byb21wdC1ndWlkYW5jZS1ncHQtNXA2">https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6<i class="fa fa-external-link-alt"></i></span><br>好的长期提示词往往比新手想的短。它只写真正的核心约束（安全底线、关键接口、重要术语），把风格和判断留给 agent。</p><p>Brooks 这一章的教训可以压缩成一句话：架构师的第二个作品是他最危险的作品，因为他把所有过去憋着的想法都装进去了。<br>随说：要克制</p><p>2026 年的宿主是提示词、agent 框架、和你自己的 workflow。<br>三个宿主各自都有第二系统效应的完整症状：加得越多、失去得越多；<br>每一项都能证明必要、合起来的产物却不好用；<br>设计者觉得自己在进步、用户觉得自己在退步。</p><p>好的做法：把需求原文完整给 agent，让 agent 自己读。<br>如果原文里有 agent 不理解的部分，让它问你，你在对话里补充说明。<br>提前拆解相当于是转述，会丢失一部分信息。</p><p>我给自己项目定的规矩明确写在纪律文件里：测试断言不是金标准。<br>测试失败先归因：这次失败是改动的错，还是断言本身写错了？该改断言就改断言。<br>翻译成 Brooks 的语言：记叙性定义（需求）是标准，形式化定义（测试）是辅助，冲突时形式化一侧服从记叙性一侧。</p><p>守住”记叙性优先”这条纪律，是 agent 时代 harness 设计里最关键的原则之一。<br>随说：因为记叙性是意图，没有具体的指标，Agent 就没法为了某个指标瞎优化。</p><p>一份能跑的代码比一万字描述都准。</p><p>开发团队自己做的测试永远有盲点，因为写测试的人和写代码的人共享同一套假设，他们的盲区是重合的。<br>真正能挖出问题的是完全不同背景的人，独立于开发过程之外的评审者。<br>随说：独立董事也是基于这个假设？</p><p>“意图如何在实现团队里贯彻”的问题。Brooks 给的答案是三层：文档要精确到不可转述、形式化和记叙性都要有且指定标准、约束要焊进结构而不是靠自觉。</p><p>在 2026 年是”测试配需求文档”，且冲突时的标准从”形式化优先”改成了”记叙性优先”。因为形式化定义在 agent 时代变成了可被优化的攻击面。</p><p>软件项目失败的机制没变过。资源、技术、人才、时间都不是最常见的死因，最常见的死因永远是交流断裂。而交流一旦断裂，各个团队开始基于各自对系统的假设独立工作，产物合起来时就是巴比伦塔的当代形态：几十个模块每个都能跑，合起来跑不了。</p><p>这一章的三个关键，五十年后依然：<br>一，假设代替核对是交流断裂的第一形态，也是最常见的形态。<br>二，组织需要一份工作手册，把散落的决策、文档、决议汇成一个可查询的整体。<br>三，信息隐藏是好事还是坏事，取决于你在讨论执行还是问责。</p><p>团队 A 在做一个模块，它需要调用团队 B 的模块。团队 A 不确定 B 的模块的某个行为具体怎么样，但没时间去查、没时间去问、也不想被认为”不知道这个”。于是团队 A 假设 B 的模块的行为是 X。写完了、跑通了、交上去了。然后 B 的模块的实际行为是 Y。集成时炸了。查根因，发现团队 A 从一开始就假设错了，而这个假设从来没被核对过。</p><p>这不是任何一个团队的错，是整个组织的结构错：没有让”核对”成为最省力的选项。假设不用付学费（立刻能写代码），核对要付学费（要问、要等、可能显得不专业）。学费结构决定了行为，行为决定了组织的失败模式。<br>随说：很多时候重复造轮子，不愿意直接问，背后可能就在怕别人知道自己不懂。或者怕对方不合作。</p><p>你的需求里有一段没写清楚，你自己以为写清楚了，因为你脑子里有默认假设。<br>agent 读完不会停下来问你，它会用它对你意图的最可能猜测直接开工。<br>解法：先讨论、再动手，需求不明先复述确认，别带着猜测开写。</p><p>分层的判据是这样：在做事的时候用信息隐藏、在追责的时候撤销信息隐藏。做事的时候 agent 只看自己的接口，做得对不对由做事的判据说了算；追责的时候审计者看全部，看得懂看不懂由审计的深度说了算。两层的用户不同，需求不同，结论就不同。</p><p>agent “自动记忆” 的想法挺好，但是 Agent 没能力识别这些记忆还有效吗？怎么抉择？<br>信息隐藏的思路：历史信息默认不可见，只在明确请求时才展开。( 这不是做成了 RAG ？)</p><p>Brooks 说，团队组织的目标是为了减少必要的交流和协作量。<br>Brooks 说组织设计要在两层之间找平衡。分得太粗，都在开会；分得太细，都在瞎猜。</p><p>Brooks 说好的组织需要在树状结构上叠加一层网状的沟通渠道。<br>这些渠道不是正式的汇报线，是”直接联络”的授权：允许工程师跨部门直接沟通，不用经过多层审批。</p><p>对治办法五十年没变：让必要交流有渠道、让所有参与者读同一份现实、让核对比假设便宜、让共享状态成为默认。</p><p>Brooks 说过一句话，值得逐字重述：仅仅通过对编码部分的估计，然后乘以其他部分的相对系数，是无法得出对整项工作的精确估计的。<br>随说：无法从编码时间倒推</p><p>不同项目的编码份额差别很大，不同任务的其他工作（讨论、测试、部署、debug）占比也差别很大。用一个平均倍数外推，只会得到一个平均没意义的数字。</p><p>“agent 在玩具任务上成功”到”agent 能交付产品”之间隔着的，就是这条不可外推线加上第 1 章说的九倍矩阵。<br>“玩具任务的数据”跟”你要做的这件事”处在两个完全不同的复杂度区间。<br>玩具任务的每一步都在 agent 训练数据的分布内，<br>你的实际项目每一步都在分布外。<br>agent 在分布内的效率极高，在分布外的效率骤降。<br>这两个效率的差距可以达到十倍甚至一百倍，但没人在 demo 里演示这个。</p><p>Brooks 引用 Portman 的数据说，全职程序员真正花在编程和调试上的时间只有 50%。<br>剩下的 50% 花在别的事上：开会、写文档、装配硬件、去食堂、处理组织事务。</p><p>一个典型的时间账：<br>需求讨论（策划）：几小时到几天，看项目复杂度。这是最花时间的一部分，且这一份时间没有 agent 可以替代。<br>方案讨论（策划）：几小时，跟 agent 讨论架构、接口、边界。<br>Agent 编码：几分钟到几小时，具体看功能规模。<br>审读产出（测试）：跟编码时间同一个数量级。你要看 agent 写了什么，是不是对，是不是符合你要的。<br>修改、返工（测试）：审读发现的问题的处理，往往是审读时间的一半到一倍。<br>集成、部署（系统测试）：这一份没有可预测的数字，看你的环境有多标准。</p><p>Brooks 那条”编码不是主要工作”的洞察在 2026 年成了字面为真。<br>所有的工作重心都在编码之外：想清楚、写清楚、看清楚、修清楚。</p><p>但这个 5 倍的边界要用 Brooks 自己 1986 年在《没有银弹》里的话来画。<br>高级语言消除的是表达的复杂度，构思的复杂度原地未动。<br>他那个判断精确得刺骨：软件的根本困难在于决定说什么，而不是如何说。</p><p>要建立基线，需要两件事：一批肯记账的人（不管是个人开发者、公司团队、还是学术研究者），和一段时间的积累（大概十到二十年，看行业形态演化速度）。第一件事每个人都可以贡献。第二件事需要耐心。</p><p>2026 年的上下文窗口有几个特点：物理有限（几万到几百万 token）、访问快（比工具调用快几个数量级）、贵（价格按 token 计）。agent 用户必须决定哪些信息”住”在上下文里、哪些放在外部工具里按需取。住在上下文里的东西 agent 立刻能用，但装不下太多；放在工具里的东西便宜，但每次取要花一次工具调用。<br>随说：和之前内存很贵一个道理</p><p>agent 时代的”新的削足适履手册”</p><ul><li>上下文分层，渐进式披露。原则是『这次任务需要吗』</li><li>按需检索，RAG 等工具进行查询</li><li>摘要与索引，长上下文塞不进去，先塞索引，有需要再加载</li><li>过期清理</li><li>分级模型，不是所有的任务都需要用最好的模型去跑</li></ul><p>数据的表现形式是编程的根本。</p><p>2026 年下一个稀缺介质出现了：上下文窗口。这一章的所有原理（设立规模目标、控制规模、发明减少规模的方法、警惕局部优化、投资于表现形式）一条不改地重新成立。而且比 1975 年更重要，因为上下文管理的好坏差异可以造成十倍的账单差异和数倍的产出质量差异。</p><p>1975 年是”架构师保持警觉、培养开发人员从系统整体出发的态度”。</p><p>先讨论再动手、测试失败先归因、别带着猜测开写、局部改动要考虑对系统整体的影响。</p><p>正确的做法是分级派活。搜索、格式转换、简单分类：低档模型。写代码、多步推理、判断歧义：中档模型。核心决策、关键判断、需要跨领域推理：强档模型。每一档就是一个”组件版本”，你根据任务的实际需求选。</p><p>行业里下一个稀缺介质是什么？</p><ul><li>可能是 agent 的注意力带宽（一个人能同时管理多少 agent，是一个正在被逼近上限的资源）。</li></ul><ul><li>可能是判断带宽（一个人一天能做多少高质量拍板，是一个远比人们想象的低的数字）。</li><li>可能是评审带宽（一份 agent 产出被人读一遍需要多少时间，随产出量线性增长）。每一个都会成为下一次”削足适履”的宿主。</li></ul><p>第 10 章 · 提纲挈领<br>文档核心内容：目标、手册、进度、预算、组织架构、说明书；<br>Brooks 说这不是巧合。任何一个多主体协作的组织，都必然需要这五类东西来维持自身的存在：<br>一，目标。这个组织要做什么。<br>二，手册（在软件项目里是产品规范）。做出来的东西是什么样、怎么用。<br>三，进度。什么时候做出什么、当前进度到哪。<br>四，预算。资源多少、怎么分配。<br>五，组织。谁负责什么、决策链是怎样的。</p><p>Agent 时代文档需求：<br>一，需求规范。条文级、带章节号可引用。这是”目标”和”手册”的合体：说清楚要做什么、做出来是什么样。它必须是可寻址的（每一条能被单独引用），因为 agent 讨论时会频繁引用具体条文。<br>二，决策记录。每一个重要决策一条，说清楚做了什么决定、什么理由、有没有过勘误。这是”组织”的当代形态：决策链的记录。它必须带勘误史，因为项目会演化，早期决策的修正必须能被看到，而不是被覆盖。<br>三，当前热点。哪些事在做、还没落地。约定”落地即剔除”（第 7 章讲过）。这是”进度”的当代形态。它必须永远描述现状与未做，让新会话读完就知道从哪接手。<br>四，协作纪律。项目里的规矩：先讨论再动手、测试断言不是金标准、局部改动要考虑整体影响。这是”组织”的另一半：工作方式的规约。它写下来是为了每次新会话装填，让协作方式不因执行者变化而变化。<br>五，预算与资源。API 费用、token 消耗、时间投入。这是”预算”的当代形态。它没进第 7 章的入职材料，因为它不是给新会话读的，是给你自己读的。多数项目忽略这一份，直到账单让人吃惊时才后悔。</p><p>书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。</p><p>你把”决定清楚”这份工作留在了自己这一侧，agent 只做实现，实现变得可靠。</p><p>这就引出这一章最重要的一句话，我想单独列出来说：文档是源码，代码是编译产物。</p><p>从文档到代码的翻译，以前是手工，现在可以自动。<br>你写清楚文档，agent 读文档、生成代码、跑测试、把细节做完。<br>让”文档即源码”从一种哲学立场变成了工作方式。<br>文档可验证：你写的文档能不能被 agent 编译成对的代码，就是你的文档是不是清楚的可验证判据。</p><p>“文档即源码”框架下的做法。发现一个 bug，先问：这个 bug 是文档里的哪个决定错了&#x2F;含糊了？找出文档里对应的段落，修它。<br>然后回到 agent，让 agent 根据新版文档重新生成或修补代码。核心动作是修文档。</p><p>2026 年的工具让预警机制更精细。<br>第一个具体的做法：把关键需求写成条文级规范，agent 每次提交代码时被要求引用具体条文（”这段代码实现了 4-3-2 条”）。如果 agent 写了没在规范里的行为，你能立刻看到。如果规范里的某条一直没被引用，说明这条需求没实现。规范和代码的偏差成了可扫描的信号。<br>第二个做法：热点文档按”落地即剔除”维护。它因此永远应该等于现状：每次你读它，发现它和现实对不上，就说明有事漏了。这个”读它就能发现问题”的性质，就是 Brooks 说的预警机制的当代形态。<br>第三个：决策记录里的每条决策要有明确状态，已经推翻的结论要合并到新结论的记录。项目演化时，人容易记得新的决定，忘掉旧的决定被推翻这件事。留一条明确的”废弃”标记，未来的读者（包括未来的自己和 agent）就不会用错决定。<br>三个做法合起来，让文档系统成为一个活的现状快照。任何跟现实脱节的地方都会浮现出来。这就是 Brooks 所说的”状态监督”在 agent 时代的具体机制。</p><p>项目经理的日常：<br>项目经理的基本职责是使每个人向着相同方向前进。<br>项目经理的主要日常工作是沟通，不是做决定。<br>只有 20% 左右的管理时间用于从头脑外部获取信息。剩下的 80% 是向外传递信息（把决定和方向讲给相关人）、做决定、处理关系。</p><ul><li>我的时间大头花在向外表达（需求、纠偏、拍板的理由），从外面收信息（读产出、读日志）占的是小头。<br>管理层看到 agent 系统的仪表盘一切正常，就以为系统在做正事。等到真实产出的问题浮现，才发现仪表盘监控的所有指标都不是关键指标。</li></ul><p>不要被指标的繁荣蒙蔽。<br>无论是对人还是对 Agent，监控“过程参数”都不等于理解“真实意图”；<br>能被量化呈现在仪表盘上的，往往都不是最关键的失效点。</p><p>文档承载决定，决定驱动一切。</p><p>第 11 章 · 未雨绸缪<br>Brooks 用化学工业做类比开场。化学工程师早就知道一件事：实验室里做通的反应过程，没有办法直接搬到工厂规模。中间必须有一个”实验性工厂”（pilot plant），比实验室大、比正式工厂小，用来发现实验室规模下看不见的问题。工厂建成后，实验性工厂通常被拆掉。它的价值不在它自己，在它揭示的问题。</p><p>Brooks 说，软件也一样。你写的第一个系统几乎必然不好用。这是因为你在写它之前不知道要做什么。等你写完，你才知道你本来要做的是什么。这时候正确的做法不是修补第一个系统，是把它扔掉，用你学到的东西重写。</p><p>写第一个版本时，你不知道很多事情。你不知道用户真正的需求（你以为你知道，往往不对），不知道系统会遇到的边界情况（你没经历过），不知道你选的技术栈的坑（你还没踩过），不知道你的架构假设中哪些成立哪些不成立。第一个版本被写出来的过程，是这些”不知道”逐一被回答的过程。等第一个版本写完，你手上有的不是”一个能用的系统”，是”一堆关于原来不知道的事情的答案”。</p><p>好的 agent 工作流应该明确地为”侦察 vs 产出”留出两个阶段。侦察阶段的产物随时可以丢，学到的东西记进决策记录。产出阶段的产物是要用的。这两个阶段的模式完全不同：侦察阶段快速尝试、勇于犯错；产出阶段严格纪律、每步核对。混着做，两种效果都得不到。</p><p>你以为的甲方要求，跟甲方最后想要的东西，中间隔着”甲方看到你做出来之后的反应”。</p><p>用户在没看到你做出来之前，往往不知道自己到底要什么。他给的需求描述是他以为的需求。<br>他看到你的产物后，会立刻发现自己真正想要的其实是别的东西。<br>这不是他故意为难你，是他现在有了新的信息（他看到了）。<br>这就是”lean startup”、”MVP”这些当代概念的深层依据。<br>随说：原型很重要</p><p>全自动 agent 系统在这里有一个结构性缺陷。<br>它试图把”用户反馈”这个环节也自动化：用评分函数模拟”用户满意度”、用另一个 agent 扮演”用户”。<br>这两种模拟都不可靠。评分函数模拟不了”我看了才想到”这类反馈；<br>扮演用户的 agent 没有真实用户的处境，它猜的用户偏好只是训练数据里的平均口味，不是你的具体用户的真实需求。<br>少了真实用户，这个流程就退化成 agent 自己跟自己讨论，输出稳定但方向乱漂。<br>随说：评估自动化有点类似？那所谓的数据飞轮有啥用</p><p>程序员不愿意为设计书写文档的原因，不仅仅是由于惰性；<br>更多的是源于设计人员的踌躇，要为自己尝试性的设计决策进行辩解。<br>一旦你把决定写下来，别人（也包括未来的自己）就会问：为什么这样选？为什么不那样选？考虑过 X 吗？考虑过 Y 吗？<br>所以人回避写文档，把决定留在自己的脑子里，不用面对辩解义务。</p><p>具体做法可以有几种：每个 bug 修复必须附一条决策记录（三行也行），说明根因、选的修法、放弃的备选。</p><p>所有修改都倾向于破坏系统的架构，增加了系统的混乱程度；<br>即使是最熟练的软件维护工作，也只是放缓了系统退化的进程。</p><p>当你发现当前会话的 agent 越来越糊涂，最好的选择不是”再解释一次”，是把当前的结论沉淀成一份文档，<br>然后开新会话，装填这份文档，从零开始。新会话的 agent 上下文干净，判断力也回到最高水位。</p><p>Brooks 这一章的核心信息可以压缩成一句：软件不是造出来一次就完事的东西，它是一个持续演化的过程。<br>你的任务不是”造出一个完美的产物”，是”设计一个能承受持续变化的过程”。</p><p>第 12 章 · 干将莫邪<br>Harness 工程是当代工具策略</p><p>2026 年的对应物是 harness 工程。当代所有严肃的 agent 使用都涉及一个 harness 层：给 agent 装什么工具、怎么装填上下文、怎么处理错误、怎么记录判断、什么时候停、什么时候求助。这个 harness 层的每一个设计决定都直接影响 agent 的实际能力。</p><p>Harness 工程的具体内容 Brooks 用了另一套词汇讨论过：工具集合、目标机器、机时分配、逻辑仿真装置、程序库。这些在当代的对应物大概是：<br>Agent 可调用的工具集（读写文件、执行命令、访问 API、搜网页），对应 Brooks 的”通用工具集合”。<br>模型档位选择（强模型用于关键决策、弱模型用于批量简单任务），对应”机时分配”。<br>参考代码库和文档索引（agent 能随时查询的资料），对应”程序库”。<br>沙箱和测试环境（agent 可以安全试错的地方），对应”调试机器”。<br>预算与止损（每个任务的 token 上限、时间上限、错误重试上限），对应”资源规划”。<br>五套东西的每一样都值得花精力设计。</p><p>一个对话式编程 agent 做的事情，本质上是：读文本（源代码、日志、文档）→ 改文本（生成新代码、修补现有代码）→ 跑文本（执行代码看结果）→ 再读文本（看输出和错误）→ 循环。这就是文本编辑的完整闭环，只不过每一步都被自动化了。</p><p>全自动研究系统是批处理，人在回路是交互式。两者的适用域之分，Brooks 五十年前已经画完了：批处理适合真正无需人判断的负载，人在回路适合需要中途判断的负载。混淆这两种适用域，就是当前 agent 生态里最大的一类工程失误。</p><p>在选 agent 架构之前先问自己，这项工作里是否有中途需要判断的时刻。</p><p>一个思想实验：两个团队做同一个功能，一个用对话式 agent（Claude Code 之类）交互式做，一个用全自动 agent 系统批处理（类似 Claude Code 的 &#x2F;goal 命令）做。前者可能六小时一次通过，后者可能几天都出不来。这个差别的根本原因不是模型好坏，是交互式反馈闭环和批处理反馈闭环的物理差异。</p><p>第 13 章 · 整体部分<br>Brooks 的答案是反直觉但有实证支撑的：详尽的体系结构工作不但让产品更易使用，还让开发更快、bug 更少。<br>项目里有两类工作时间。<br>一类是”生产性”时间，真的在往前推进。<br>另一类是”填坑”时间，在处理架构没想清楚导致的问题，比如接口对不上、模块假设冲突、事后发现需要重构、集成时才发现依赖漏了。<br>填坑时间几乎没有产出，全是浪费。</p><p>架构做得马虎的项目里，填坑时间可能占总时间的一半以上。<br>你以为在赶进度，实际上大部分时间在填自己刨的坑。</p><p>这条命题在 agent 时代格外重要，因为 agent 让实施阶段变得极其快。<br>慢的部分只剩前期的架构和后期的集成审查。<br>如果你不把架构做透，前期省下的一点时间，会被后期几倍地花回去。</p><p>Brooks 引用他的同事 Vyssotsky 一句话：许许多多的失败完全源于那些产品未精确定义的地方。</p><p>你给 agent 一份需求文档。agent 读完，开始工作。文档里没有的部分（就是你以为不用说的 E），agent 会用它对你意图的猜测填补。它的猜测可能是好的（如果它训练数据里的常识跟你的常识对齐），也可能是坏的（如果不对齐）。你事先无法预测哪种情况会发生。</p><p>未精确定义之处在 agent 时代比 1975 年更危险。1975 年程序员遇到含糊会犹豫，含糊有物理痕迹。2026 年 agent 遇到含糊不犹豫，含糊没有物理痕迹。你要靠自己的注意力去发现所有含糊，且发现动作全部要发生在验收时，因为过程里 agent 不会告诉你。</p><p>翻译成 agent 时代的具体做法：人在回路不是可选项。凡是任务涉及”未精确定义之处”的项目（就是绝大部分真实项目），都必须有人在场，随时准备回答 agent 遇到的含糊。全自动系统在这类项目上必然失败，因为它没有回答问题的接口。</p><p>Brooks 引用 Vyssotsky 的另一条：在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性。开发人员自己不会完成这项工作。<br>随说：需要交叉</p><p>Brooks 在这一章介绍了 Wirth 的自顶向下设计方法。核心思想是：先做高层设计（整个系统的结构），然后逐步展开到细节，每一层的设计对应下一层的目标。这样每一步都在明确的框架里做，不会陷入”边写代码边想架构”的困境。<br>有时必须回退，推翻顶层设计重新开始。自顶向下不是一次到底的直线过程，它有反复。<br>随说：自顶向下设计</p><p>跟 agent 会话是一种极其高效的”终端工作”，几分钟能推进过去要几小时才能推进的东西。但会话的产出质量取决于会话前你想清楚多少、会话中你判断多少、会话后你消化多少。这三份”桌面工作”的时间投入必须跟得上会话本身，否则会话的产出会成为一堆没被消化的产物，堆在项目里没人清理，最后混乱不堪。<br>随说：历史上是 1：1 的时间，一半写代码，一半思考。</p><p>每段跟 agent 的会话之后，人这一侧要有几段等量或更长的桌面工作：<br>第一段是读产物。会话产生的代码、文档、决策，你要真的读一遍，不能只看 agent 的总结。这一段的时间几乎等于会话时间，因为你要覆盖 agent 生成的所有东西。<br>第二段是更新热点文档。会话推进的事情从热点文档里剔除，新发现的事情加进去。这一段几分钟到十几分钟。<br>第三段是把学到的修进确定性层。会话里发现的新的决策、约定、坑，写进决策记录或规范文档，让下次新会话能装填。这一段可能十几分钟到几小时。<br>第四段是规划下一步。你根据当前状态想清楚下一段会话要做什么、要提什么问题、要什么样的产出。这一段几分钟到十几分钟。<br>四段加起来，桌面工作时间跟会话时间的比例大概是 1:1 到 2:1。这跟 Brooks 说的 1975 年比例接近，甚至更极端。</p><p>Brooks 说系统调试花费的时间比预料的更长，且系统调试仅仅应该在所有部件能够运作之后开始。<br>在 agent 时代，这条纪律要落到一个新的具体形态：环境契约必须先自检。</p><p>场景。你要 agent 做一个跟外部系统交互的任务：调用某个 API、连某个数据库、访问某个服务。你告诉 agent”这些外部依赖都已经准备好了”，让它开始工作。<br>如果外部依赖真的准备好了，agent 的工作是纯粹的”实现”，只涉及它自己的代码。如果外部依赖没准备好（比如 API 密钥没配、数据库没启动、服务没部署），agent 的工作变成了”实现 + 环境 debug”的混合。它可能会误诊环境问题为代码问题、可能会写一段 workaround 绕过环境问题、可能会假装能连上继续做，然后所有产出的价值都被污染了。</p><p>Brooks 那条”部件正常前不能做系统集成”的当代版本是：给 agent 装填任务时，环境的正常性必须先被独立验证，不能靠 agent 自己”信任 harness 的承诺”。</p><p>agent 时代的常见违反形态是大而稀的整体重写。全自动 agent 系统每个节点是一次全量重写：所有代码作废、从头产生新的一份。变更量子无穷大，连 diff 这个概念都不存在，于是”这次改了什么”在结构上不可问。</p><p>独立评审、自顶向下加低成本回退、桌面工作与会话时间等量投入、环境契约先自检、增量集成，这些是这一章五条命题的当代具体形态。每一条都不是新的方法，是 1975 年就说清楚的老原理在新载体上的重新落地。</p><p>第 14 章 · 祸起萧墙<br>Brooks 用一个问题开场：项目是怎样延迟了整整一年的时间？答案是：一次一天。</p><p>Brooks 说，比起重大灾难，日复一日的进度落后更难以识别、更不容易防范、也更加难以弥补。重大灾难是可见的、可上报的、可动员的；小延迟是隐形的、习以为常的、没人愿意为它专门开会的。就是这种隐形，让它成为项目失败的主要模式。</p><p>这一章讨论的是如何让隐形的失败可见。Brooks 给的答案是：里程碑、状态报告、独立测试组、明确的进度纪律。<br>听起来是行政管理，实际上是让”你今天在哪个位置”这件事变得可回答、不模糊、也没得躲。</p><p>一个具体的、我给自己项目定的规则：任何一次 agent 尝试花了上下文预算的 30%、且没有明显进展，我就停下来重新讨论方向<br>2026 年一次一节点的延期，让 agent 用户同样防不住，除非把弃线规则焊进 harness。</p><p>形式化定义明确是指：这个规则能被自动检查。跑出数、分数高，都能自动检查。<br>里程碑定义明确是指：这个规则不能通过绕过它来满足。里程碑要求的是”完成了目标任务”，而不是”通过了自动检查”。</p><p>而”负债”这一环，第 13 章讲过按 Vyssotsky 命题的推论，永远不可能精确到形式化。所以收紧它的最后一步只能是人，即人作为里程碑的最终审计位点。</p><p>agent 不怕挨批（它没有情绪），不怕被追责（它没有人权也就没有办法负责），也不怕影响自己前途（它没有前途）。它没有 Brooks 说的那种”充分理由不共享信息”。但它同样是一个永远不主动上报坏消息的下属经理。<br>为什么？因为坏消息的识别需要判据，而判据在题外的前提链上，不在它的上下文里。</p><p>Brooks 的忠告是：仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。<br>对治办法是 Brooks 说的那三条：</p><ul><li>区分状态与评价（”你做了 X 和 Y”是状态，”这不对”是评价，把两者混在一起会淹没状态）；</li><li>毫无惊慌地接收（当 agent 报告”我做的这个东西可能有问题”时，你的反应决定它下次还敢不敢报告，稳定接收才能鼓励再报）；</li><li>决不越俎代庖（不要在 agent 报告问题后立刻自己重做那部分，让它继续按你的指导修，不然它下次干脆不报告了）。</li></ul><p>Vyssotsky 说两套不得互相污染。翻译过来是：不许拿事后的手改事前的账。<br>你不能因为实测发现了不利结论，就回去修改预注册的判据（”其实我们本来说的是 X”，明明预注册里写的是 Y）。<br>你也不能因为预注册写得比较模糊，就在实测里把它解读成对你有利的形态。</p><p>agent 时代的独立评审比 1975 年便宜太多。新会话不带任何前一天讨论的上下文进场，直接看当前状态。它会问一些内部会话不会问的问题：”你说做完了 X，我看代码里没有 X 的实现，怎么回事？”、”你说预期一周做完的 Y，为什么两周了还没交？”、”这份文档里说的方案 A 跟代码里实现的方案 B 有差别，是不是有个决定没被记录？”</p><p>里程碑本身是设计出来的，不是自然发生的。你不预先想清楚”什么算做完这件事”，就没有里程碑；<br>没有里程碑，就没有防止自欺的装置。<br>所以里程碑的设计工作，是所有想避免”一次一天”式延期的项目的第一步工作。</p><p>第 15 章 · 另外一面<br>Brooks 用一个双面的意象贯穿这一章：程序有两面。<br>一面朝向机器（源代码、编译产物、运行时行为），<br>一面朝向用户（能被理解、能被使用、能被继承的说明）。</p><p>Brooks 说这不是因为程序员懒。它是一件有具体心理机制的事：写文档要接受辩解义务（第 11 章讲过），而人天然抗拒辩解义务。<br>这条抗拒五十年没变，也不会因为下一波培训文化改变。<br>随说：不喜欢写文档是人性问题</p><p>即使你写的程序只给自己用，你也要写文档，因为半年后的你已经不记得当初为什么这么写。<br>用户和作者是同一个人这件事，不豁免文档需求。人对自己代码的遗忘速度比想象快得多。</p><p>Brooks 说，关键用户文档的绝大部分需要在程序编制之前书写。<br>这条 1975 年是给”先动手写再考虑用户”这个常见程序员反模式的对治。他说：写用户手册的过程会迫使你想清楚用户到底怎么用这个东西，这些”想清楚”会反过来影响你的实现选择。等实现完了再想用户，你已经把很多决定锁死了，用户手册变成了”给已有实现做辩护”。</p><p>这条在 agent 时代升级为一个更强的版本：先讨论后动手。</p><p>Brooks 说流程图是被吹捧得最过分的一种程序文档，且很少有程序需要一页纸以上的流程图。<br>这条 1975 年是给当时”流程图正确才能真正设计程序”这个流行观点的反驳。</p><p>Brooks 1986 年在《没有银弹》里对流程图做了更彻底的判决：程序员在开发之后而不是之前绘制流程图。也就是说，流程图不是设计工具，是事后美化的图示。真正的设计发生在别的地方（脑子里、白板上、伪代码里），流程图只是把已经想清楚的东西画成一张能给管理层看的图。<br>随说：流程图不是设计工具，是美化工具。</p><p>规范文档的变化和代码的变化必须同一个 commit。不允许”改了规范但代码还没跟上”或者”改了代码但规范还没更新”这种中间状态。这个纪律让规范和代码永远保持一致，也让审查者可以在同一个 commit 里同时看到”这次改动的意图（规范）和实施（代码）”（但实际上 agent 有概率手快了 commit 掉，这种时候最好在下个 commit 就补文档）。</p><p>程序员写文档时，总有一种诱惑：只写”这段代码做了什么”，不写”为什么这样做”。因为”做了什么”是可以从代码里直接读出来的，你把代码读一遍就知道。”为什么这样做”读不出来，它涉及外部信息（业务背景、当时的技术选型、当时被否决的备选方案、当时的约束）。</p><p>程序员倾向于写”做了什么”式的注释和文档，因为它容易写、也容易被验证（跟代码对照就能知道对不对）。他们回避写”为什么这样做”式的文档，因为它难写、也容易过时（业务变了、当初的理由不再成立）。</p><p>目的无法被语法完整表达，从 1975 年的洞察升级为 agent 时代的推论：所有能被自动化的表达工具都碰到同一堵墙，目的永远只能由持有目的的主体在场持有。</p><p>Brooks 那句”程序有两面，用户面跟机器面同样重要”，在 agent 时代要加一句：agent 就是让机器面变便宜的工具，用户面的成本一分未减，且现在占了总成本的大头。用户面这一半没有 agent 可以外包，它需要一个能持有用户视角的人做主体。</p><p>第 16 章 · 没有银弹<br>没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。</p><p>这句话在 1986 年是刺耳的。当时的软件行业正处在极大的乐观情绪里。人工智能承诺解决编程、面向对象承诺解决复杂度、CASE 工具承诺解决估算、第四代语言承诺解决表达、专家系统承诺解决判断。每一茬技术都以”这就是银弹”的姿态出场。Brooks 说，不。这些技术每一样都有价值，但没有一样是银弹，因为它们攻击的都不是软件真正的困难所在。</p><p>Brooks 论文的标题用了一个具象的意象。银弹是传说里能一枪打死狼人和吸血鬼的武器，它的特点是一发解决问题。</p><p>Brooks 论证的核心是：软件的困难有一部分是可以被技术进步大幅便宜化的（他叫偶然困难），有一部分是本质上不可被技术进步消除的（他叫本质困难）。技术进步只能作用于前者。<br>本质困难有四个固有性质：复杂度、一致性、可变性、不可见性。</p><p>Brooks 说，软件的复杂度是本质的。它是软件对象本身的性质，不是可以通过更好的工具消除的偶然复杂度。</p><p>软件描述的是抽象概念系统：不同层的抽象、不同层之间的交互、不同类型的数据结构、不同风格的算法。这些抽象在任何两处几乎都不重复。<br>这跟物理系统很不同。物理系统里有大量重复（同样的钢梁、同样的水管、同样的电路），软件里几乎没有重复。<br>凡是”重复”的部分早就被抽象成函数了，剩下写出来的都是不重复的东西。<br>这个性质导致软件的复杂度随规模非线性增长。<br>一个 10000 行的程序不是 1000 行程序的十倍复杂，而是几十倍甚至几百倍复杂，因为部分之间的交互组合随部分数指数增长。</p><p>在 agent 时代，复杂度这条本质性质一分未减。<br>agent 让写代码变便宜了，但没有让代码变简单。<br>你产出的代码规模可以在同样时间里翻十倍，但那十倍代码的复杂度是同规模代码的十倍复杂，甚至更多，<br>因为你没有时间做同样精细的架构审视（我现在的个人项目就在这个泥沼中，我正在探索其它办法更好地解决整体的 review 问题）。</p><p>agent 时代软件系统的规模正在快速膨胀，而管理这些系统的复杂度的能力（本质上是判断能力）没有翻倍。<br>这个不对称的合成结果是每个人都在维护比五年前大得多的系统，也承担比五年前重得多的复杂度管理负担。</p><p>行业里已经有声音在讨论 AI slop（AI 批量产出的低质量内容）。<br>这个现象的软件版本就在眼前：AI 批量产出的低质量代码。<br>它不是骗人的代码，只是没有经过复杂度节制的代码。<br>每一段单独看都合理，合起来是一个没人能理解全貌的巨型系统。<br>这就是复杂度这条本质困难在 agent 时代长出的新形态。</p><p>Brooks 说的最刺骨的一句是：软件的复杂度大半是”随心所欲、毫无规则的人为惯例”。</p><p>比如你要写一个连接数据库的模块。你必须知道这个数据库客户端库的 API 长什么样、它的错误码怎么定义、它的连接池怎么配置、它的事务隔离级别怎么选、它对特殊字符的转义规则是什么。<br>这些东西没有一个是从”数据库的第一性原理”能推导出来的。<br>它们是这个具体客户端库的作者当年拍脑袋定下来、后来因为兼容性没法改的。<br>你必须记住所有这些约定，才能正确使用这个库。</p><p>模型再强，也只能记住惯例、不能推导惯例，因为惯例本身就没有”能被推导”这个性质。这是一致性困难的本质：不可推导性。</p><p>在 agent 时代，一致性困难的形态有个新特点。agent 训练数据里有大量的惯例知识（各种库的用法、各种协议的规范、各种平台的接口），这让 agent 处理常见惯例时比人快、比人准。这是好事。<br>但每次遇到一个训练数据外的惯例，agent 就得从零学起，且它无法从别的知识推导。它会用它对同类事物的经验做猜测，猜错的可能性很高，且它没法自我识别猜错。</p><p>任何一个投入使用的软件系统，它的需求会随着时间演化：用户的使用方式在变、环境在变、竞争对手在变、法规在变。<br>软件不像桥梁。桥梁建成后几十年不用改，软件建成后必须持续演化。</p><p>你以为需求稳定的时候，用户看了原型立刻改主意；改完让 agent 重做，做出来又改主意。<br>这个循环本身是好的（它让最终产品更贴合真实需求），<br>但它证明的正是可变性这个本质困难：需求本身在被建造的过程中会变化，装填是一次性快照，快照冻结的那刻起就在过期。</p><p>不可见性导致几个后果：设计难以在头脑里完整持有（超过一定规模就必须分块想）、沟通难以精确（图形辅助只能片段化）、审查难以彻底（没有一张能一眼看全的”设计图”）。</p><p>agent 的执行过程本身也是不可见的。你看不到 agent 在推理时”想了什么”。你看到的是它的输出（可能包括推理链的显示），但推理链不是它实际做的事情，而是它给自己产出物做的事后叙述。真正的推理发生在模型内部，几十亿个参数的联合作用，无法被完整可视化。</p><p>四个性质（复杂度、一致性、可变性、不可见性）在 2026 年一条没有被消灭。每一条都在当前的 agent 生态里按了指纹。</p><p>复杂度：agent 让产出规模翻了几十倍，复杂度按规模非线性增长，所以人的复杂度管理负担变重了，不是变轻了。<br>一致性：agent 处理已知惯例更快，但未知惯例（当地约定）的问题比过去更严重。<br>可变性：反馈闭环变短，需求变化的频率和幅度都在增加，可变性负担加重。<br>不可见性：agent 内部推理不可见，且它产出的代码规模让”看全”这件事更难。<br>四条本质困难，一条没被 agent 消灭，反而每一条都在 agent 时代长出了新形态、变得更硬。</p><p>模型档位从中等升到最强，代码质量肉眼可见地涨。偶然复杂度确实在被消灭。但死因（判据无人持有、口径无人审、目的无法被完整表达）住在根本任务里，模型轴上没有它的解。你在偶然困难的曲线上再涨十倍百倍，也涉及不到本质困难的领域，因为它们根本不在同一个维度。</p><p>Brooks 的论证是说 scaling law 是引擎变快，但软件的根本困难在月球方向。曲线继续也够不着。</p><p>数字审计有效的前提是先有人审过口径，论文评分有效的前提也一样。</p><p>全自动 agent 今天真正的可用域：它就是”判据幂等、方案空间已被人类踩平”的那些任务。这一类任务包括标准的数据处理、常见格式转换、成熟领域的模板生成、有清晰单元测试的算法练习。这些任务上 agent 系统能做得又快又好，因为它们精确落在 Parnas 说的例外域里。<br>凡是超出清单的任务（需要判断处境、需要跨领域拿定主意、需要在没有已知答案的地方创造），四十年后依然需要人做。</p><p>“agent 会不会取代人”这个问题一个具体答案：agent 提供的是人类专家平均能力的分发，它不能产生新的专家能力，只能复用已有的。<br>当行业没有专家产生新知识时，agent 也就没有新东西可学。</p><p>它的当代形态是”买模型能力”。你不用训练自己的模型，你调用 OpenAI、Anthropic、Google 的 API。<br>“等模型变强”也是一种购买策略。<br>它们继承购买策略的全部优点和同一条天花板：你买到的是通用能力，买不来对你那道题的判断，因为你买到的模型没见过你的处境。</p><p>越设计师是稀缺资源，且培养他们这件事本身不能被系统化。</p><p>Brooks 说最重要的投资是培养设计师。这句话四十年后依然对，且在 agent 时代变得更急迫。因为 agent 大幅提升了普通开发者的产出，卓越设计师和普通设计师的产出差距被放大了。一个卓越设计师现在能带动一整个 agent 支持团队，产出比过去大几倍。一个普通设计师用同样的 agent 团队，产出没有卓越那位的十分之一。差距不在 agent，在使用 agent 的那个头脑。</p><p>第 17 章 · 再论没有银弹<br>Brooks 说专家系统的价值在特定领域真实（医学诊断、设备故障、税务咨询），但没有成为通用编程工具，因为通用编程需要通用判断，专家系统的规则库只能覆盖特定领域。</p><p>敏捷改进的是”如何组织工作”这个偶然困难，通过更好的流程管理让工作被更有效地推进。<br>它没有触及”要做什么工作”这个本质困难。所以敏捷是一茬有价值的方法改良，不是银弹。</p><p>云计算。2000 年代兴起、2010 年代普及。它承诺的是通过按需使用计算资源，消除自建基础设施的负担。<br>三十年后成绩单：兑现了它的承诺，让”运维”这个偶然困难被大幅便宜化。没有触及本质困难。有价值，不是银弹。</p><p>微服务。2010 年代主流。它承诺的是通过把大系统拆成多个独立服务，让复杂度更可管理。<br>三十年后成绩单：微服务在部分场景兑现了它的承诺，在另一部分场景反而增加了复杂度。<br>它本质上是把”单一进程的复杂度”换成”多进程的复杂度”，没有减少总复杂度。有价值，不是银弹。</p><p>现在到本书要处理的这一茬：2020 年之后的大语言模型、编程 agent、multi-agent 系统、MCP、autonomous agents。这一波比过去任何一波都热，每一样都以”这就是银弹”的姿态出场。用同一个框架看。</p><p>Agent 让代码编写这件事的成本大幅下降，但编写代码这件事本身是偶然困难的一部分，它不涉及”要写什么代码”这个本质判断。</p><p>对话式编程 agent（Claude Code、Cursor、Aider、Codex 这一类）。<br>承诺的是通过让 agent 承担从需求理解到代码实施的完整循环，程序员从”敲键盘的人”变成”审阅者和指挥官”。<br>但它依然不是银弹。判断（决定说什么、要不要这样做、这个方案对不对）依然要由人做，本质困难没被触及。<br>它是一茬极其成功的偶然困难消灭者，且是当前最接近”接管全部偶然困难”的技术。但它没有对本质困难做任何事。</p><p>试图消灭需要判断的东西，就等于试图消灭软件的本质困难，而这件事按 Brooks 1986 年的分析是做不到的。<br>所以目前行业积极探索蓬勃发展的全自动系统不是银弹，且它是三十年来最直接、最系统地撞在这条论断上的一次尝试。</p><p>直接买现成的软件比自己开发要便宜几个数量级。<br>买软件不解决本质困难，但它让你的项目里的本质困难减少了，因为你不做的那一部分，本质困难就不落在你头上。</p><p>三十年后这条思路的当代形态是什么？买模型能力。你不训练自己的模型，你调用 API。你不搭自己的完整 agent 系统，你用开源框架（或者模型公司自己产的 app）加托管服务。这个”买而不建”的策略在 2026 年比任何时候都便宜，大部分核心能力都可以按 API 调用付费。<br>你买到的是通用能力，买不来对你实际面临的问题的判断。你的具体处境、你的具体判据、你的具体目的，无法被外部提供者理解。</p><p>采购策略对偶然困难有效，对本质困难只能规避、不能消灭。<br>所以它依然不是真正意义上的银弹。如果你的项目里剩下的本质困难需要判断，你还是要有人在场做那件事。</p><p>传统软件工程里，判据的持有主体是明确的：甲方或产品经理或架构师有需求和判据，程序员按判据实施。判据虽然可能不精确（Vyssotsky 命题），但至少有一个明确的持有主体。<br>agent 时代出现了一个新的困难：当 agent 承担越来越多的实施工作时，判据的持有主体变得容易被误判。</p><p>你会看到有些团队用 agent 做出的产品质量在半年内飘忽：刚开始时人很认真核查，agent 产出好；<br>用久了人变懒、开始接受 agent 的自评、质量在不知不觉中下降，这不是 agent 变差了，是判据持有的实际分工在悄悄漂移。</p><p>四十年过去，行业发生了很多事：面向对象普及、CASE 泡沫、第四代语言消亡、专家系统冷却、敏捷兴起、云计算落地、微服务成为主流、大模型出现、agent 时代到来。每一次浪潮都被称作”这次不一样”，每一次都被 Brooks 的框架容纳为”又一件消灭偶然复杂度的利器”，没有一次触及本质困难。</p><p>当下一茬技术出场，声称自己是银弹时，再读一遍人月神话。看这项技术攻击的是偶然困难还是本质困难。</p><p>第 18 章 · 死亡名单的分布<br>三级程序库（第 12 章）。Brooks 提议的”私有开发库 &#x2F; 集成测试库 &#x2F; 发布版本”三层结构，被现代分支模型完整兑现（feature branch &#x2F; staging &#x2F; production）。</p><p>Brooks 引用 Wirth 提出的”自顶向下设计、逐步精化”，五十年后成了每一个受过基础训练的工程师的默认工作方式。年轻一代不知道曾经有过别的写法。<br>随说：结构化编程</p><p>概念完整性：系统设计中最重要的因素依然要由一个头脑持有，多头脑持有就长出私有概念。agent 时代给这条命题提供了实验室纯度的反面样本。<br>人月不可互换：加人不能线性加速项目、subagent 不能线性加速任务、采样和理解不能互换。核心机制五十年没变。</p><p>五十年间，行业把大量精力投入到消灭偶然困难上（工具、语言、方法学、框架），所以偶然困难侧的命题要不然被兑现（成为默认），要不然被换代（旧载体死亡）。<br>本质困难侧一茬又一茬技术承诺解决，一茬又一茬都失败，所以那些命题原样活着。</p><p>模型的能力越强，对软件工程的提升越小。<br>因为剩下的都是本质困难：判断需要一个持有主体，主体的位置只有人能坐。</p><p>当 agent 能持有目的、能理解处境、能自主判断，那时候”主刀由人做”这条论断就不再成立，本书大部分论证的政策含义就要修改。</p><p>目的这个东西（”我为什么想要 X 而不是 Y”）必须挂在一个主体上。<br>这个主体有它的处境、有它的历史、有它的关系网、有它要为之负责的事情。<br>目的不是一段文字，是一整个持有网络。<br>你可以给 agent 更多信息、更强推理、更长的上下文，它依然不成为持有目的的主体，因为它没有真正的处境。它模拟处境，但模拟不等于持有。</p><p>你给最强档 agent 一段几十万字的处境描述，让它扮演一个具体的用户，然后让另一个 agent 跟它讨论产品需求。这两个 agent 讨论出的东西质量能有多高？在特定场景下不错，在一般场景下比真实用户参与差远了。为什么？因为扮演的 agent 是在模拟用户，它的”我要什么”是训练数据里那类用户会说的话，不是这个具体用户在这个具体处境里真正要的东西。差在身份。</p><p> Brooks 的原书等到了自己的第三批读者：第一批管人，第二批管代码，第三批管 agent。</p><p>三代读者从 Brooks 那本书里带走的都是不同的东西。<br>第一代（1975-1995）：外科手术队伍、Brooks 法则、进度估算、独立测试组。这些是关于如何管一个大项目的具体建议。他们把这些建议落地为软件工程管理的一套地基。<br>第二代（1995-2025）：概念完整性、模块化、文档假设、为舍弃而计划、结构化编程。这些是关于如何写好代码的方法论。他们把这些方法论落地为敏捷、DevOps、TDD、云原生这些当代实践。<br>第三代（2024 之后）：本书从头到尾展开的那些：文档即源码、审计权与修正权、判据持有、Vyssotsky 命题在人机分工线上的应用、Parnas 之争的分层解决、Goodhart 定律在评分函数上的复发。这些是关于如何在人机协作里守住软件工程本质的洞察。</p><p>总结：换了币种的人月照旧买不来婴儿，换了介质的巴比伦塔照旧败在组织上，换了物种的支持团队照旧需要主刀。写进提示词的乐观主义照旧要靠现实之外的质疑来纠正，未精确定义的地方照旧是失败之源，目的照旧无法被语法完整表达。</p><p>Brooks 说软件工程的困难是可命名的、结构性的、可以被面对的。</p><p>尾声：写给下一位读者</p><p>如果你读完了这十八章，你现在应该有几个直觉。<br>一，agent 是伟大的偶然困难消灭者，但不是银弹。它让软件工程的一大批老问题变便宜：写代码、写文档、写测试、跑 debug、追依赖。这些工作在 2026 年的成本降到了 1975 年成本的百分之几。这是软件工程史上最大的一次工具跃迁。<br>二，agent 没有触及本质困难。判据谁持有、目的谁负责、概念完整性谁守护、里程碑谁设计，这些工作没有便宜化，反而因为总产出规模的膨胀，占用总成本的比例上升了。你的项目里，判断的成本在过去两年可能翻了一倍不止。<br>三，人机分工的正确形态五十年前 Brooks 就写好了（虽然他自己没预见到 agent 的出现）。分工线沿着”能不能被形式化定义”这条边界走。能被形式化的（代码、测试、文档格式），交给 agent。不能被形式化的（目的、判据、处境判断），留给人。守住这条分工线，两侧都做得最好；打乱这条分工线，两侧都做不好。<br>四，这本书前面十七章讲的具体机制，都是这条分工线在具体场景里的落地：从概念完整性到 subagent 沟通开销，从外科手术队伍到 Vyssotsky 命题，从 Brooks 法则到 Parnas 之争。每一条具体机制都可以独立使用，合起来是一套完整的工作方法论。<br>如果你只带走一条建议，让它是这样：把你的时间投资到文档层。文档是决定的载体，决定是代码的源头，代码是决定的编译产物。你想在 agent 时代做一位真正有效的工程师，你的时间应该投入到判断和决定的显形上，不是敲代码上。代码由 agent 从文档编译，你的价值在于把文档写成能被机械执行的源码级材料。<br>Brooks 那本书的第一批读者是 1970 年代的项目经理。这本书的读者是 2026 年之后的开发者。<br>中间隔了半个世纪，一切都在变，唯有一件事没变：『软件工程的核心是判断的组织』。<br>你就是那个组织判断的头脑。要我说的话：嘿！你做得到。</p>]]>
    </content>
    <id>https://hisen.me/20260726-agent-mythical-man-month-2026/</id>
    <link href="https://hisen.me/20260726-agent-mythical-man-month-2026/"/>
    <published>2026-07-26T10:00:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-概要"><a href="#1-概要" class="headerlink" title="1. 概要"></a>1. 概要</h1><p>Agent 时代，能够加速的是执行过程( 编码、调试等 )</p>
<ul>
<li>说明：执行过程最多占开发活动的 50% 时间，来自 Portman 的数据</li>
</ul>
<p>但涉及到目的、判断等核心的流程，还是需要人工介入。<br>由于执行过程足够快，需要人工介入的工作会越来越多，瓶颈还在人，提效会遇到天花板。<br>从某个角度讲，AI 加速了我们的生活，其实是变相地增加了人生的长度( 犹如开倍速看电影 )。</p>
<p>如果通过 Agent 进行 Coding，关键的约束：</p>
<ul>
<li>从需求开始就让 Agent 了解</li>
<li>和 Agent 不断对话沟通，形成决策纪要和执行计划</li>
<li>执行计划尽量细化，每个步骤尽量有过程约束，而不是指标约束。否则容易作假</li>
<li>如果 Agent 给出的结果不好，不要直接修改代码，而是修改执行计划，说清楚来龙去脉</li>
<li>执行过程中有遇到不明确的，让 Agent 不要自己发挥，需要人工补全确认</li>
<li>如果上下文耗尽等导致效果不佳，重新开一个窗口按执行计划让 Agent 接着工作( 有状态+业务上下文 )</li>
<li>Code Review 等也用新窗口拿着执行计划执行，避免不干净的上下文影响</li>
</ul>
<p>核心就是让 Agent 有足够的上下文，有可验证的过程产出，而非简单的评估指标。</p>
<h1 id="2-精简笔记"><a href="#2-精简笔记" class="headerlink" title="2. 精简笔记"></a>2. 精简笔记</h1><p>《人月神话》是 Fred Brooks 1975 年写的一本管理书。<br>他管过 OS&#x2F;360，那是 IBM 的大型机操作系统，1960 年代人类做过的最大一次软件工程。<br>项目结束他没写技术总结，写了一本关于为什么大项目总是延期、为什么加人只会加得更慢、为什么概念完整性是设计的最高目标的书。<br>《人月神话》写完之后成为整个软件行业的地基。<br>+++<br>Brooks 那本书的第一批读者是 1970 年代的项目经理。这本书的读者是 2026 年之后的开发者。<br>中间隔了半个世纪，一切都在变，唯有一件事没变：软件工程的核心是判断的组织( 把各种决策判断有机整合 )。<br>软件最贵的成本是维护与演进。好的组织方式，能让你在“增加新判断”或“修改旧判断”时，付出最小的边际成本。<br>+++<br>在 Agent 时代卓越的工程师，<br>应该投时间在判断和决定的文档上，<br>文档写成能被机械执行的源码级材料，<br>因为代码是 Agent 从文档编译的产物。</p>]]>
    </summary>
    <title>《Agent时代的人月神话》读后感</title>
    <updated>2026-09-13T14:37:46.923Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Reading" scheme="https://hisen.me/categories/reading/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <category term="阅读" scheme="https://hisen.me/tags/%E9%98%85%E8%AF%BB/"/>
    <content>
      <![CDATA[<blockquote><p>这本书比较好的是有很多通俗易懂的探究场景，对话的方式代入感很强。<br>而且修订版给的大部分例子都是中国读者比较熟悉的。</p></blockquote><h1 id="1-内容概要"><a href="#1-内容概要" class="headerlink" title="1. 内容概要"></a>1. 内容概要</h1><p>从互联网上各种热门的反转事件来看，批判性精神可以说比较缺乏。<br>在网上冲浪多年，我习得的生存法则，简单来说就是保持好奇心：</p><ul><li>提到的内容有无可靠的来源？比如比较正式的媒体</li><li>作者靠什么维持生计？是否会屁股决定脑袋，为了赚钱什么都说</li><li>披露的数据是否有来源？数据是否准确？</li><li>相关的言论如果不符合常理，那么有什么证据支撑？</li></ul><p>看完这本书，其实有异曲同工之妙，都是要搞清楚问题的答案，不要人云亦云。<br>值得注意的是，很多主观性强的问题，是不好探究的，特别是社会上共识不强的问题。</p><p>探究应该有的态度：</p><ul><li>开放：对相反的观点、对我们观点的质疑、跟我们的观点不符的证据保持开放的态度。</li><li>公正：我们不仅愿意考虑相反的观点，而且会对他们做出不偏不倚、公正无私的判断。</li></ul><p>真正的批判性思维，不是为了“赢得辩论”，而是为了“寻求真理”；其手段不是固执己见，而是“探究”。<br>简而言之，这本书想告诉我们的是：先探究，后断言；先权衡，再结论。</p><p>书里面印象很深的是老师引导学生对艺术作品，特别是一幅画的探究。<br>先从表象开始，收集足够的细节，给出自己的想法。<br>然后带着问题，了解作品的背景，把自己代入进去，<br>通过多人协作沟通，形成一个比较全面、深入的认识。</p><h1 id="2-原始摘录"><a href="#2-原始摘录" class="headerlink" title="2. 原始摘录"></a>2. 原始摘录</h1><p>本书围绕六个指导性问题展开：</p><ul><li>这个问题是什么？</li><li>这个问题中包含了什么样的断言和判断？</li><li>对于这个问题的各种立场，其相关的理由和论证是什么？</li><li>这个问题的背景是什么？</li><li>各个论证的效力有多强？</li><li>我们如何比较性地评价各种理由和论证，以得出一个有充分理由支持的判断？</li></ul><span id="more"></span><p>学生时代的学习，绝大多数时候不是在学习，而是信息的暂时获取。<br>获取信息的外在目的——考试一旦消失，这些信息也就烟消云散。<br>为什么学生没有能把信息的获取转化成学习？<br>究其原因，很大一部分是因为缺乏问题意识。</p><p>问题是什么？问题是引领知识建构的引擎。<br>信息需要通过一个心理化的过程，形成一个结构而为我们所掌握。</p><p>问题提出来之后，探究途径要求从三个方面对问题的背景进行调查：问题的现状，争论的历史，以及相关的思想、社会、政治和历史背景。这<br>迫使探究者去深入挖掘，从语境中建构出这个问题对“我”的意义。</p><p>本书的书名“权衡”正是这一点睛之笔：权衡各方证据和论点后得出判断。</p><p>所谓“迁移难题”，就是怎样让学生把在课堂上学到的技能运用到生活中的方方面面。<br>作者们深深明白，思维的培养从来不是一个理论问题，而是要融入日常交流的点滴之中，正如书中的角色在对话中所例示的那样。<br>通过日复一日的优游涵泳，使批判性思维成为学习者的第二天性。</p><p>无论是以何种身份、何种目的阅读本书，关键在于能够把握住探究的精髓，<br>秉持面对复杂问题的全局性视角，始于问题，按照探究的步骤深入，将各类思维工具和概念融入其中。</p><p>地理学科常常通过要求学生死记硬背来考核学生。本书第十二章展示了如何用探究方法重新审视教学：</p><ul><li>地质学家试图解决的问题是什么？</li><li>该问题的背景是什么？</li><li>有哪些相互竞争的理论？</li><li>支持两种不同理论的证据和论证是什么</li><li>对这些论证有何异议？</li><li>科学家们一开始是如何评估这些证据和论证的？他们在通过新的研究获得其他证据后又是如何评估的？</li></ul><p>学生写作文常见的做法是一上来就确立一个中心论点，然后寻找甚至拼凑各种材料来支持该论点。<br>这种写作的结果往往是一篇观点肤浅、结构零散的文章。<br>反之，通过本书中详细阐述的探究过程的各个方面，学生学会系统地探究问题，审视问题的各个方面，评估各方面的论证并做出一个有充分理由支持的判断。<br>这样写出来的文章质量更高，表现出更深入的分析和批判性思维。<br>随说：这本书为什么这么本地化的感觉？</p><p>探究途径旨在帮助学生锻炼在实际情况中做出理性判断的能力，以及适当而一贯地进行理性思维的习惯。</p><p>要培养探究思维的习惯，就需要一个以学生互动为中心，学生进行辩论、提问、质疑和评价的氛围。<br>他们共同协作，对别人的工作提供反馈，一起从事项目，共同进行探究。</p><p>遗憾的是，这种情景是很典型的。大家对一个问题存在意见分歧，且双方都带有非常强烈的情绪。<br>这种分歧升级为指名道姓的谩骂以及强烈的情绪发泄，并以双方的误解告终。<br>随说：以对话的方式展开？</p><p>郑鑫：好家伙——我们显然提出了很多问题，不过好像没有多少答案。<br>苏芳菲：我说……或许我们可以找到某种方式，来试图回答部分问题。我们肯定不是第一个思考这些问题的人。所以，我们不妨查一下，看看已经有些什么样的想法和信息在那里了。我确定有关于吃肉对健康和环境的影响方面的研究。</p><p>在第一个场景中，同学们情绪化的反应从一开始就主导了谈话。<br>对于他们所反对的意见，同学们并不想了解更多，也不准备认真地思考其他观点。<br>相反，他们互相奚落和抨击。他们没能找到一种途径来解决存在的分歧——事实上，这一分歧升级为不欢而散。<br>最后，没有一个人是赢家，没有人获得对这个问题或对方观点的深入理解。<br>每个人都输了，都有受到伤害的感觉，甚至可能导致友谊的破裂。<br>随说：这场景其实很常见</p><p>第二个场景开始于同样的起点，同学们关于素食主义持有不同的立场。<br>但是，一个关键的不同之处是，第二个场景中同学们抱有开放的心态，希望了解那些他们所不同意的其他同学的观点。<br>他们为自己的立场提供理由，了解他人的理由，参与到真正的对话中去。同学们对自己原初的立场同样持有强烈的情绪和坚持，而这可能是完全适当的。<br>他们不再那么固执地拒绝那些他们不乐意听到的意见；相反，他们表现出了对他人观点的尊重，并且乐于倾听和考虑他人的想法。<br>同学们想要抓住问题的要点，寻找额外的信息和想法，并给予它们严肃而批判性的思考。他们开始走向了探究的过程。<br>随说：核心是怎么引导自己或者他人进入这种状态，如果完全情绪化，应该没法这么讲事实白道理。</p><p>他们将会带着更具批判性的眼光思考这个问题，在更为充分的信息基础上做出经过深入思考的判断。<br>他们将找出一种方法来理解他们之间的分歧，用一种合理的方式来解决它，并且相互之间用一种更加文明的、互相尊重的方式进行交流，即使分歧仍然存在。</p><p>批判性的探究，即这样一个过程：仔细地考察一个问题，从而得出有充分理由支持的判断。</p><ul><li>聚焦一个问题</li><li>对一个问题进行仔细地思考</li><li>一个有充分理由支持的判断</li></ul><p>实际的探究并不总是会得出一个所有人都一致同意的判断。<br>讨论可能会以一个合理的、互相尊重的分歧而告终，而这完全可能是适当的。</p><p>探究力求得出的判断并不是任意的：不是一个没有经过反思的意见，也不是不加批判地采纳他人的说法。<br>相反，得出一个有充分理由支持的判断包含了批判性评价。批判性评价也是探究的核心。</p><p>当人们考虑购买一辆汽车的时候，通常所使用的标准是经济承受能力、节油性能、舒适性、安全性、外观等。<br>这些标准中的某一些，比如节油性能，是对买车来说所特有的，而其他的一些，比如经济承受能力、外观，是购买其他东西时也会考虑的。<br>随说：为什么区分特有的和通用的？</p><p>评价一个科学断言的标准包括：解释证据的能力、跟现有理论之间的关系。</p><p>评价要求对推理进行评价的标准包括：所提供的理由必须跟结论相关、不应该有任何逻辑错误或者弱点（谬误）。<br>这些标准并不是任何一个特定领域所特有的，而是对所有可以进行推理的领域都适用。</p><p>同学们开始认识到一些谬误（一些常见的论证效力薄弱，却具有相当大说服力的论证模式），并且看出它们是如何弱化了论证的效力。<br>例如，沈佩珊指出，一些对素食主义的指责实际上是诉诸人身，因为它们是攻击吃素的人而不是他们的论证。</p><p>同学们还意识到评价的另一个重要方面——考察这个问题的背景。<br>这个问题的背景包括中国人食肉的文化传统、关心动物福祉的精神传统（佛教和道教等），以及支持工业化农场的社会-经济条件。</p><p>探究是对一个问题进行仔细考察，从而得出一个有充分理由支持的判断。</p><p>不过，并非所有观点上的不同都可以进行探究。比如，看一看下面这些场景：</p><ul><li>姜瑶试图说服林畅苦瓜很好吃。</li><li>徐逸飞和刘宇轩关于电台播放的歌酷不酷有不同意见。</li><li>郑鑫想去打球，而宋俊涛更想要去看电影。<br>尽管在这些场景中，人们对于某些事情存在分歧，但这些分歧却并不是可以用一种理性的方式来考察的。<br>相反，它们是个人喜好的问题。最终，双方可能商议出一种行动方案，或者接受他们之间的分歧。探究在这样的情形中是不能提供什么帮助的。</li></ul><p>因为我们所知道的东西总是在不断变化的，所以我们从来都不能确定我们是否已经掌握了真理。<br>因此，我们的判断也总是暂时的。新的信息可能被发现，新的论证可能被提出来，从而给予我们新的理由修正或者改变我们的观点。</p><p>尽管我们的目标是不断增进我们的知识，然而意识到这一点同样重要，即在历史上知识并不总是以线性的、进步的方式演化的。</p><p>探究是不断进行和不断演化的，这一事实与其说值得担忧，不如说是值得我们高兴的。<br>有人觉得批判性思考是枯燥乏味、缺乏创造性的。这种观点是不准确的。<br>事实上，探究是一项包含了创造性和想象力的事业，就像它需要逻辑和推理一样。<br>这两个方面是紧密交织在一起的。探究包含了对信息、理由和论证的评价，但它同样也包含对替代性方案和反驳的思考、想象反例以及构造出自己的观点。</p><p>有时候一个对话看起来像是一个探究，实际上却只不过是不同观点之间的对抗，而并没有真正努力去寻求和发现最好的立场。</p><p>“如果我们今天相信的东西明天就会发生改变”，他们可能会想，“那么进行探究的意义又是什么呢？”<br>这个意义就是，探究使得我们在现有信息的基础上，得出一个我们所能达到的最好的判断。</p><p>力图寻求真理并不是探究的唯一目的。探究的一个中心目标是对世界获得一个更好的理解——一个可以使得我们的生活更为丰富、更有效率的理解。<br>随说：理解世界的运行</p><p>基于理由而进行判断的能力，对一个成熟、独立、有责任的人来说是至关重要的。</p><p>探究的首要目的是找出针对一个问题最好的观点或者立场。探究并不仅仅是找出其他人论证中的错误。<br>它并不是要赢。它尤其不是要说服他人采取你的意见或者观点。<br>相反，它关注的是真正去寻求那种最好地被辩护的立场或观点。<br>它的目的是力图得出一个有充分理由支持的判断。<br>正因如此，探究要求其参与者具备一定的倾向或者态度，我们称之为“探究的精神”。</p><p>探究还有的态度</p><ul><li>开放：对相反的观点、对我们观点的质疑、跟我们的观点不符的证据保持开放的态度。</li><li>公正：我们不仅愿意考虑相反的观点，而且会对他们做出不偏不倚、公正无私的判断。</li></ul><p>确认偏误：是指只注重寻找那些可以确证自己观点的信息和证据，而未能寻求反对自己观点的信息和证据的倾向。</p><p>探究的核心特征之一是对于理性的尊重，它可以通过多种方式展现，比如：对事物有好奇心；关心真理和准确性；<br>欣赏人类通过理性取得的成就；愿意跟随论证和推理的引导，不论它们将我们带到什么地方；<br>希望基于理由而行动；接受不确定性作为探究的一部分。</p><p>探究的精神的最后一个核心方面是，尊重探究过程的其他参与者。<br>它意味着不能侮辱和操纵他人，也意味着严肃地对待他人的观点。</p><p>德尔菲报告：理想的批判性思维者充满好奇，充分掌握信息，相信理性，思想开明，头脑灵活，公正地进行评价，诚实地面对个人偏见，谨慎做出判断，愿意重新考虑，明确问题所在，有条理地处理复杂事务，勤于寻求相关信息，合理选择标准，专注于探究，在探究的问题和环境允许的情况下坚持不懈地寻求尽可能准确的结果。</p><p>苏芳菲和林畅刚刚展示的是一个非常典型的关于电影的意见分歧：他们相互交换了意见，对于各自的观点做出反应，然后便转移到其他事情上去了。关于电影（或者音乐等）的意见分歧经常以这样的方式告终：尊重双方的分歧、保留各自的意见。但是他们并不一定要这样。</p><p>问一问自己，究竟为什么喜欢或者不喜欢一部电影，特别是他们认为哪些地方拍得好或者不好。试着回想一下影片中的镜头会很有帮助。<br>随说：要有细节支撑，不然太空洞了。</p><p>怎么建立探究框架呢？<br>探究的指导性问题：</p><ul><li>这个问题是什么</li><li>这个问题包含了什么样的断言和判断</li><li>这个问题的各种立场，其相关理由和论证是什么</li><li>这个问题的背景是什么</li><li>各个论证的效力有多强</li><li>我们如何比较性地评价各种理由和论证，以得出一个有充分理由支持的判断</li></ul><p>哪部电影更好，这是个人喜好问题。没法进行探究。</p><p>因此，尽管这些研究不是决定性的，委员们还是能基于系统收集到的信息和论证得出一个有充分理由支持的判断。<br>在这种批判性评价的基础上做出一个决定，要远远好过仅凭个人印象而做出决定，<br>因为那可能是带有偏见或者缺乏信息支持的，也好过基于媒体报道而做出的决定，因为那可能是一边倒的、感性的。<br>随说：收集信息，综合评判</p><p>两个例子(哪个电影好看、养狗条例)都开始于一个问题或者分歧，其意见分歧都伴随着对特定立场的情绪化的反应和承诺（至少对某些参与者来说）；<br>通过探究，参与者们都超越了他们原初的分歧；探究的过程都包含提出同样的指导性问题。</p><p>王茵茵和她的女儿张熙怡正准备要去补习班。<br>随说：这部分真是太逗了，很贴合实际</p><p>我看过一些报道，加拿大的学生在功课上花的时间比我们少得多，可是他们在阅读和科学学科方面的成绩排名更高，在数学方面的排名也跟我们差不多。<br>实际上，没有哪个国家的学生比我们中国的学生做的功课更多了，可是他们反而成绩更好。</p><p>一个论证究竟是什么呢？“论证”这个词有很多种含义，我们将在本书中使用其中的几种。<br>你可以放心，那种脸红脖子粗的高声争辩不是本书的关注点，虽然有时候我们对话中的人物可能会变成那样。</p><p>一个论证至少是由两个断言组成的：一个前提，一个结论。为支持这个断言所提供的理由称为前提，被支持的断言称为结论。</p><p>我们可以将王茵茵的一个论证标准化如下：</p><ol><li>那些上了好大学的人都很有出息。</li><li>黄叔叔名牌大学毕业。<br>结论：这是他现在年纪轻轻就功成名就的原因。</li></ol><p>诠释论证的时候，为什么要用善意原则</p><ul><li>通常来说这是一件得体的事情，尤其是对话</li><li>有助于保持在理性轨道，尽量试图公正地听取另一方意见</li><li>避免我们不同意对方立场时，就错误表述对方立场</li></ul><p>￼<br>有效的演绎论证是指，如果它的前提为真，那么结论必然为真。在一个有效的演绎论证中，前提和结论之间的这种关系被称为蕴涵。</p><p>一个论证是否有效，依赖于它是否例示了一个有效的论证形式，而不依赖于它的前提或者结论是否为真。<br>随说：形式决定了是否有效？</p><p>计算器所保证的是，如果你输入了正确的数字（以及运算符号），你将会得到正确的答案。这对于将陈述句填入一个有效的论证形式来说也是一样。</p><p>有效性只是保证了当前提都为真的时候，必然有一个为真的结论。</p><p>如果说X是Y的必要条件，那么没有X就不可能有Y；<br>如果Y 是X的充分条件，则如果Y存在，那么X也必然存在。</p><p>由此可知，对于一个论证的评价过程是，首先暂时接受它的前提，然后问一问：如果这些前提为真的话，那么它们能否为结论提供很好的支持？它们是否提供了很好的理由来使得结论可信？</p><p>初步的判断总体来说就是预备性的判断。说一个人做出了初步的判断，就是承认其评判的预备性本质。<br>也就是说，一个人可以对一个断言或者论证做出一个合理的初步评价，并同时承认该评价只是预备性的，是可以根据后面的信息或者其他的考虑而修改的。</p><p>很多论证类型（谬误）看起来有说服力，但是实际上为它们的结论提供了很少的证据，甚至没有。</p><p>王茵茵：无论如何，没有什么能代替努力学习。你还记得李阿姨的女儿柳馨吗？柳馨读书的时候就不好好读，回到家什么作业都不做，补习班也不好好上。高考考得一塌糊涂，在一个普通大学上了四年，毕业了也找不到一份好工作，现在干脆在家里失业啃老了。日子过得一团糟。<br>这是一个谬误推理的典型例子。王茵茵用一个例子来过度概括那些没有好好学习的人。注意，我们并不是说一个人的个人经验与理解这个世界无关。这里的谬误是，基于极其有限的一点证据——经常是个人经验（主观上是有力的，而且经常是很有说服力的），认为它好像强到可以支持一个普遍概括。<br>随说：逸闻(一则故事)证据谬误，说服效果 ＞ 逻辑效力</p><p>人们通常容易被自己的经验或者听说的别人的经验所说服。我们都有这样的倾向，即假设我们自己的经验是典型的，因此基于它们可以进行适当的概括。<br>随说：大部分时候说的非典型的。</p><p>证据力：一个带有谬误的论证是说服力远远超出了证据力（证据价值）的论证。</p><p>最经典也是最常见的一种不相关的形式是转移话题（red herring）。这个词语的直译是“红鲱鱼”，据说源自英国的猎狐运动。<br>反对猎狐的人士将一条腐烂的红鲱鱼拖拽着掠过狐狸的踪迹，从而混淆猎犬的嗅觉，使它们找不到狐狸。<br>这种形式在论证中的作用是，将辩论者的注意力从当前讨论的问题转移到其他话题上。</p><p>张熙怡：但是压力太大了！我严重缺觉，也不做任何运动。你看我都发胖了！我的神经一直都绷着，也没有时间跟朋友们在一起。<br>王茵茵：我为你付出这么多——这么多钱花在你身上，还有我的时间和精力，为你的学习我操碎了心！你这孩子一点都不知道感恩！<br>王茵茵显然不想处理张熙怡关于学习负担产生的负面影响的论证，而是把话题转移到父母为她的教育所做的牺牲上面。</p><p>逻辑错误：通过转移关注焦点，所提供的理由和论证就是针对另一个不同问题的了，对于找出原来那个问题的真相不起什么作用。</p><p>下面是另一个典型的转移话题的例子：<br>记者：女士，请问本届政府对于亟待处理的金融危机做了哪些工作？</p><p>政府官员：正如你所知道的，前一届政府忽视了这个问题，这是我们现在要面临这样一个烂摊子的原因。如果他们在适当的时间采取了适当的措施，那么我们的处境就会好很多。所幸的是，他们败选了，而我们现在主持政府的工作。</p><p>转移话题的一个最有效的形式是诉诸人身（ad hominem），它将关于问题的讨论转移到提出论证的人身上。<br>如果辩论者拒斥一个论证是基于对立论者本人的批评而非针对其论证，那么就犯了诉诸人身的谬误。<br>会导致捍卫个人行为&#x2F;煽动个人情绪，无法讨论问题本身。<br>逻辑错误：论证的逻辑效力应该是基于论证的优劣而非立论者的个人品质来决定的。</p><p>人身攻击是用对立论者的恶意攻击来拒斥其论证或者立场。它通常导致将关注的焦点从正在讨论的问题完全转移到提出这个观点的个人身上。</p><p>当一个断言的可信性依赖其立论者的可信性的时候，批评者就可以合理地提出关于立论者的可信性的质疑。</p><p>因为关联而有错（guilt by association）是一个这样的谬误：一个人拒斥某个断言，因为它是那些不受欢迎的人所持有的立场。<br>逻辑错误：一个观点被一些不受欢迎的人持有，这一事实跟这个观点是否为真或者是否可信没有任何关系。</p><p>稻草人的谬误包含了攻击一个被错误表述的论证或立场。当辩论者把一个并非对方的观点归于对方，并通过驳斥那个被错误表述的论证或立场来反驳对方的观点时，他们就犯了稻草人的谬误。<br>随说：曲解？故意误导？</p><p>在批评你的对手的立场之前，通过仔细、善意地理解其立场，可以避免无心地犯下这个谬误，在对话中，你应该向对方核实，看看对其立场是否做出了正确的描述。</p><p>为什么我得了罚单？那些车也都超速了。 （回答：我希望我能抓住所有超速的人，但是我们只能做我们能做到的，而现在我抓住你了。你当然不能说你没有超速。）</p><p>传统之所以成为传统，并不是因为它们是对的，有时只是因为人们道德上的软弱，或者自我放纵，或者是延续了可疑的惯例。</p><p>流行性只是信念的一个初步基础，它从来不能成为一个断言真正的证据。</p><p>经验和故事都是极其鲜活的，也很容易把我们引向结论。<br>它就像根据第一印象来判断人，或者根据在一个大城市的一周生活体验来判断一个国家。<br>你可能是对的，但是这并不足以作为一个很有力的证据。</p><p>当辩论者所使用的前提跟他们的结论等同时，他们就犯了循环论证（begging the question）的谬误。<br>循环论证的另一种方式是假设一个处于争议焦点的断言为真。</p><p>王茵茵：怡怡，这话我跟你说了多少次了？你要是进不了年级前一百名，你就进不了重点高中；你进不了重点高中，就进不了重点大学；进不了重点大学，就找不到好工作；你找不到好工作，你的朋友也不想跟你来往，将来你连孩子都养不起。那就是你想要的生活吗？<br>随说：滑坡论证</p><p>“滑坡”这个名字强调了如果你向某个方向采取某个行动，那么将不可避免地滑向不好的后果。<br>这类论证的说服效果通常是通过突出那个可怕的后果达成的。</p><p>论证中的偷换概念（equivocation）是指，作者故意误导性地在两种不同的意义上使用同一个词。</p><p>你需要有某些理由来进行怀疑——你不能仅仅只是声称一个前提是不可接受的，因为它没有得到支持。</p><p>虚假的两难的说服效果是，迫使人们只考虑两个选择，而其中一个通常是令人反感的，因而他们必须选择另一个。因为只有两个选择，人们必须选那个不那么令人反感的。<br>随说：高，真是高</p><p>妈？你知道课堂上什么最容易导致分心吗？是其他同学！所以按照你的逻辑，我们应该把学生也给没收了。这也太搞笑了吧？<br>这里王韫就是使用了这个策略。归谬（拉丁文reductio ad absurdum，意思是“归为荒谬”），是要表明一个被提议的行为或者原则将会导致一个荒谬的情形，从而应该被拒绝。</p><p>先例对比：<br>引用其他的案子作为一个先例是类比论证的一种形式。这种论证基本上是这样的：<br>在案件A中，法庭判决X。<br>现在手头上的案子跟A在某些相关方面是类似的。<br>结论：法庭在这个案子上也应该判决X。</p><p>人类跟老鼠显然是非常不同的，但是出于测试致癌物这样的科学目的，二者可能是可以进行类比的。<br>手机和电视有些相似之处（两者都有屏幕，都有一些影音娱乐功能），<br>但是在下列这些方面是不同的：交互性、便携性、手机为个人所有、分散注意力的程度，以及作为教学工具在程度上的差异。<br>鉴于这么多差异，我们难以确定章敏菁的论证在多大程度上能够成立。</p><p>不过，如果健康问题是牵涉眼睛的，那么兔子就会被认为是一个更好的模型。<br>另外，如果我们要考察社会行为，那么老鼠跟人类就相差太远了，<br>因而也不再具有任何真正的解释或者预测价值。</p><p>下面是用来评价类比论证的策略：</p><ol><li>检查在被比较的事项之间是否存在相关的可比较的方面。</li><li>将这个论证进行推广，看看它是否会导致荒谬的后果（构造一个归谬论证）。</li><li>构造一个替代性的类比，它跟原来的类比一样好甚至更好，但是却具有不同的后果。</li><li>提炼出其中的根本原则，对它进行批评。</li></ol><p>人类所进行的最根本的活动之一就是试图理解这个世界。<br>理解世界的能力使得我们既可以预测什么将会发生，也可以按照我们的目的来改造世界。<br>理解世界上所发生的事情，涉及适当的解释。</p><p>通常，在一个解释中我们是要考察为什么某件事情会发生，<br>而在一个论证中我们是要知道应不应该相信某个特定的断言。</p><p>解释有两种形式</p><ul><li>理由解释：也叫做目的解释&#x2F;意图解释，也就是我们如何解释人的行为。</li><li>因果解释：大多数是物理学范畴，用先前的事件来解释它导致什么事情发生。</li></ul><p>雷声：我们现在理解了，正负极两种带电云层碰到一起时，就会发出闪电，同时又释放出很大的热量，使周围的空气受热膨胀。瞬间被加热膨胀的空气会推挤周围的空气，引发强烈的爆炸式震动，这就是雷声——而不是因为雷公在惩恶扬善。</p><p>最佳解释论证是一种用来确立因果断言的推理方法。它通过指出其他的解释跟事实不符，表明某个特定的解释比其他任何解释都更好。</p><p>它就是奥卡姆剃刀，（在应用于当代的实践中时）它可以被表述为：“其他条件相同的情况下，选择最简单的解释。<br>随说：控制变量法的情况下，选最简单的</p><p>“奥卡姆剃刀”原则：如无必要，勿增实体。</p><p>当然，一个一般性的因果断言可以被表明是假的，或者是未得到证实的，但却不是谬误。<br>我们将继续用“谬误”这个概念特指在初步评价和推理中识别出来的明显的错误。</p><p>第六章 可信的信息来源和诉诸专家，章节目标</p><ul><li>对专家的论断和论证做出合理的评价</li><li>对网络和出版物上找到可信的信息来源，并对齐进行评价</li></ul><p>如果一个人不提供适当的理由，而说什么“相信我，没错的”，那我们应该保持怀疑态度。</p><p>如果一个问题对你来说是重要的，那么进行更深入的挖掘以合适关键信息总是好的。</p><p>有必要检查信息来源的情况：</p><ol><li>这个问题很重要</li><li>这个断言是有争议的，支持该断言的人具有举证责任</li><li>有适当的理由怀疑这些信息存在偏见</li></ol><p>评价信息来源的指导性问题</p><ol><li>这个论断是来自一个适当的知识领域吗？</li><li>相关专家对这个论断是否存在共识？</li><li>所诉诸的权威能胜任这一论断所在的领域吗？</li><li>这个专家在给出一个意见之前有没有评阅相关信息？</li><li>这个专家是否可以信赖，不带偏见</li><li>这个论断是经过同行评审吗？出自经过同行评审的刊物？</li><li>这个专家是否提供了言之有理的论证或者解释来支持其观点？</li></ol><p>与科学和政治领域相比，达成一个一致的判断在美学领域则不是那么重要的目标。</p><p>可以诉诸权威的领域特质</p><ol><li>不是以道德自主性为特征的领域</li><li>该论断有着被广泛认可的程序和标准</li><li>该领域有着相当大程度的专家共识</li></ol><p>专家&#x2F;KOL是否可以信赖？</p><ul><li>没有偏见和个人利益，因为屁股决定脑袋</li></ul><p>如果专家不能提供一个可以理解的、言之有理的解释，那么就削弱了其论断的可信性。</p><p>什么事一个问题？<br>一个可以进行探究的问题是可以通过理性和论证来考察的。<br>特质:聚焦，不能过于宽泛；区分话题与问题；精确性；争议性；</p><p>一个问题是一件处于争议之中、结论尚不明确的事情。<br>在社会的层面，问题是那些尚未形成共识的现实问题。</p><p>一个问题的特质包含以下几个方面：有聚焦点，用问题的形式表达，用精确的语言表述，有争议性，用中立的语言表述。</p><p>事实性判断是通过观察这个世界存在的方式来做出决定和寻求支持。</p><p>评价性判断可以通过理由和论证而得到辩护，但是这些理由和论证跟用来支持事实性判断的属于不同的种类。</p><p>我注意到一些有趣的事：人们支持或者反对死刑，但是他们中的很多甚至都没有提到，这是在跟什么样的替代性观点相比较。他们有没有比较过死刑相对于十年或者十五年监禁的优点？他们有没有将它跟终身监禁相比呢？</p><p>背景信息重要的三个方面</p><ul><li>现状</li><li>争论的历史</li><li>思想、社会、政治、历史背景</li></ul><p>一个被广泛接受的指导性原则是，举证责任一般是归于那些与现有的普遍被接受的观点或做法相冲突的一方。<br>随说：打破常规需要举证</p><p>了解围绕一个问题的争论历史会很有帮助，而且在某些情形中，它对理解该问题以及各种相竞争的观点来说甚至是至关重要的。</p><p>知道一个问题所处的思想、社会、政治以及历史背景，可以让我们更加清楚各种论证背后的假设。<br>它可以帮助我们理解各种论证的提倡者的观点源自何处，让我们洞察到这些观点背后的世界观。</p><p>据媒体报道，国家人口计生委科学技术研究所2013年发布的数据显示，中国每年人工流产总数中，25岁以下的女性占一半以上。大学生甚至成为人工流产的“主力军”。</p><p>中国人民大学法学博士、著名刑法学家邱兴隆教授关于死刑是否具有震慑效应的讨论：联合国的一项研究发现，废除死刑的国家的犯罪率并未上升。这可以作为死刑并不更具震慑效应的证据吗？<br>随说：我认为不能，因为没有控制变量</p><p>我知道报应论证在中国历史悠久，俗话说“欠债还钱，杀人偿命”。<br>但是，我们并不会要求强奸强奸犯，或殴打那些殴打他人的人。<br>因此，我们实际上并不认为出于公正的目的所施加的惩罚应该跟犯罪的行为类似。</p><p>我们经常将自己的立场和优先性认作确定的、固定不变的。<br>但是，与我们通常所做的不同，通过试图明确表述出我们的权衡所基于的考虑、价值以及优先性，更进一步地推进这种给出理由和评价的过程，这样的可能性也是存在的。<br>随说：权衡就是评估、论证、改变的过程</p><p>试图为我们的判断和优先级进行辩护，也可以向我们揭示，有些时候我们所依赖的只是习惯、权威或者意识形态，而不是很好的理由。</p><p>列出哪些因素可以促使你对该问题改变主意。如果你什么都列不出来，那么就可能是“意识形态固化”了。</p><p>试图为我们的价值和优先级进行辩护的过程也可以帮助我们理解那些持有不同观点的人及其观念的根源。</p><p>一篇得体的回应：最近的一篇评论里面说道：‘只有死刑才能有效地震慑犯罪分子，并确保他们不会再次犯罪。’这样的立场听起来似乎有道理，但是却缺乏证据的支持。例如，加拿大自从1976年废除了死刑之后，谋杀率反而下降了。而在美国，谋杀率最高的是那些存在死刑的州。一些人可能会认为，死刑可以减少谋杀是一个常识。但是，很多谋杀是发生在那些互相认识的人之间的，是由一时的愤怒引起的。他们不大可能做风险-收益的分析。更重要的是，死刑不仅不能阻止凶手杀害无辜者，实际上反而导致无辜的人被杀。比如最近非常轰动的聂树斌一案。</p><p>首先，我们要确保我们考虑了相反的论证，使读者相信我们了解所谈论的事情。<br>在做出任何有争议的或者令人吃惊的断言时，我们都需要引用专家的意见作为佐证。<br>另外，不要忘记了，我们的很多论证都是道德论证，它们并不需要专家意见才具有可信性。我们还要让文章的语调尽量合理。</p><p>在我国一线城市超低房租回报率之下，未来只有两种演化可能，一是房价大跌，二是房租补涨，我更看好后一种可能性，尤其是在部分城市已经试点“租售同权”的背景下。<br>随说：很可惜是前者</p><p>安全套的发放有一个前提，如美国，70%以上的中学生和几乎100%的大学生都有两性关系，推行“安全套”教育不再有可能使更多青少年参与性行为。</p><p>谬误推理是指那些逻辑效力很薄弱却具有相当大说服力的论证（参见第四章）。<br>使用修辞手段进行不正当的说服，而不是使用逻辑理性地说服人们，就违反了对理性的承诺，而理性正是探究的精神的特质。</p><p>比如《论语·子罕》中说道：“子绝四：毋意，毋必，毋固，毋我。”意思是说，孔子杜绝了四种弊病：不凭空揣测，不主观臆断，不固执己见，不自以为是。</p><p>拒绝听从他人的观点在某种程度上可能是缘于想要确定性，这似乎是人类共有的特点。<br>当人们感到自己掌控着事情的来龙去脉时，才觉得安心，而当被迫怀疑自己持有的观点是否正确时，则会感到慌张。<br>但是，鉴于我们知识的可错性，在某种程度上接受不确定性是探究的一个必要方面。</p><p>执行复杂的计算、判断一个人行为的适当性、比较不同方面的总体价值或考察复杂的逻辑论证的有效性等任务，需要集中注意力、努力进行脑力劳动和有意识地进行推理——它们被称为“慢思考”</p><p>确认偏误是指只注重寻找那些可以确证自己观点的信息和证据，而未能寻求反对自己观点的信息和证据的倾向。</p><p>如果我们成功地培养出一种因为明白真理而非因为自己正确而得到满足的感觉，那么，愿意接受其他论证、愿意承认错误等就将变成我们自我认同的一部分。</p><p>我是想要成为一个通情达理的人，还是将自己跟某一特定的观点相等同？</p><p>参与者也应该力图通过严肃地考虑其他人的论证而非对别人的话吹毛求疵，通过认真思考别人的批评而非变得自我防卫，使对话富有成效。</p><p>有时候，出于论证的需要而承认一个观点也是有帮助的，即使你并非完全认同那个观点。<br>这样可以在对话陷入僵局的时候将其往前推进。这使得大家可以建立共同的基础，以导向一个解决方案。<br>承认另一种观点可能正确，并不必然意味着改变自己的想法。<br>它所要求的是不要一概拒斥那个观点，而是看看对话可以导向什么地方。</p><p>科学研究的推理过程：提出各种假说，一个一个地排除，直到得出最佳解释。</p><p>科学的进步是因为争论，也是因为科学家们不断地寻求对于所研究的现象的新证据和最佳解释。</p><p>在一项实验中，研究人员发现玩视频游戏可以增强老年人的认知能力。<br>它说：“我们的研究结果表明，玩4周的《脑锻炼》（ Brain Age）游戏可以改善老年人的认知功能（包括执行功能和处理速度）。”</p><p>元分析文章、综述性文章。</p><p>回溯性研究</p><p>一个有趣的统计上的例子可以说明这一点。研究发现，喝咖啡的人比不喝咖啡的人患肺癌的概率更高。<br>实际情况是，喝咖啡的人中吸烟率也更高，而吸烟和患肺癌之间才存在因果关联。吸烟干扰了关于喝咖啡是否导致肺癌发病率的研究。</p><p>很多心理学实验都是基于对大学本科生的便利抽样进行研究的，显然，这些样本既非随机的，也不能合理地代表更大范围内的人群。<br>在大多数这些研究中，研究者们甚至都没有说明他们的目标人群是什么。</p><p>你们确实提出了很好的问题，表明你们在对艺术作品进行思考，对它们做出反应。艺术应该如此。<br>你们对一幅画的第一反应是很重要的，但是你们也可以超越原初的反应，尝试着理解一幅画，思考它的优点。</p><p>你对《格尔尼卡》的第一印象是什么？<br>同学们遇到了一幅很有挑战性的艺术作品。它绝对不是写实的，他们困惑于怎么理解它。<br>画家为什么要画成这样呢？它意味着什么呢？为什么专家们这么看重它？如果它有什么优点的话，他们又如何能够知道呢？</p><p>江琪让他们在进行了更为直接的观察研究之后，再进行外部的研究。<br>很多教艺术欣赏的老师都推荐这个方法，因为它促使人们对一件作品建立初步的、直接的反应。<br>观察者被鼓励去观察作品的细节、思考并提出问题。<br>随说：先建立初步、直接的反应</p><p>为什么我们应该认为一件艺术作品需要在乍看之下就很容易理解呢？我们从这些观察、研究以及讨论中学到了很多，我们可以有深度地欣赏这幅画。<br>我并不认为“容易理解”应该成为我们判断一件艺术作品的标准。</p><p>艺术品是否只能塑造高大的形象？一件艺术品能否代表全体中国人的形象？艺术能否揭露社会历史的阴暗面？</p><p>文化批评家朱大可指出，从这个作品中并不能必然得出“丑陋”的判断，而且一个艺术作品“跟中国人有什么关系呢”？<br>因此他认为，挑起这个争论很滑稽，再牵扯到“中国人”就更加滑稽。<br>而在艺术评价上动辄挥舞民族主义大旗是极其狭隘的表现。</p><p>广州美术学院李公明教授分析，对一件不符合既定模式的艺术作品做出“丑陋”的判断，<br>正是某种僵化保守的思维方式和奇特的民族心理在作怪，似乎只有高大耸立的艺术品才是“代表民族精神”的。<br>如果以“丑陋的中国人”作为前提再进行讨论，首先就陷入了某种窠臼。</p><p>仅仅依赖于我们的最初反应来作为判断艺术品的基础是错误的，因为我们的反应可能是非常个人化的，它取决于我们的背景、知识以及心智状态等因素。</p><p>我也学到了可以基于理由和证据来对艺术做出批判性判断。艺术并不仅仅是个人口味的问题。<br>现在我意识到，我应该花点时间来好好地研究艺术，关于怎样去看以及看些什么，我现在有点眉目了。</p><p>重要的是，我们都经历了探究的过程，分享了我们的想法和判断。<br>但是在最后，我们可能会有不同的判断，只要它们是基于相关的标准和证据，那么就可以了。<br>而且，不管我们的批判性判断是什么，关于是否喜欢它，我们可能仍然具有不同的偏好。<br>重要的是，我们的探究为我们欣赏这个作品打开了新的可能性。</p><p>艺术中的探究过程和科学中的探究过程有一些有趣的类似之处。对于理由、论证的评价和权衡都是核心要素。<br>而且，基于观察而产生假说、用证据来测试它们、寻求对于证据的最佳解释，这些在两者中都起作用。</p><p>很多人不想对他们所读到或者听到的东西进行批判性的思考，或者可能不知道怎么去做。<br>所以，他们看不到所有这些谬误和问题，他们被那些修辞策略欺骗了。</p><p>如果你发现了支持阴谋论的证据，那么它证实了阴谋论；<br>如果你没有发现什么证据，那么这也被认为是证据，证明他们进行了掩盖，从而也是支持阴谋论。<br>你从这种逻辑里面看到什么问题了吗？<br>随说：阴谋论的逻辑出发，很难证伪</p><p>阴谋论倾向于使用有选择性的材料，经常是间接推测的证据，而且常常是未经证实的。它们通常并不考虑替代性的解释。</p><p>阴谋论论证的循环性是另一个常见的特征。因为阴谋论建立在关于秘密和掩盖的前提下，因而缺乏证据也被认为是构成了证据。这使得阴谋论变得不可测试。</p><p>总结：阴谋论的常见特征<br>  ·建立在有矛盾或者异常的材料之上。<br>  ·论证是循环的：缺乏证据也被认为是支持其理论的证据。<br>  ·显得具有很强大的解释力，然而这种表象是误导性的。</p><p>我想我只是不想成为一个任人摆布的傻瓜，接受官方想要让我相信的那些东西。<br>我想要自己去思考，找出幕后真相，想要显得叛逆不羁。<br>不过，我想可能我并没有像我应该做到的那样去独立思考。<br>随说：阴谋论者内心OS</p><p>列出正反两方的论据，以及各自论据的前提。对比双方哪个都可解释性高。更科学合理。</p>]]>
    </content>
    <id>https://hisen.me/20260726-Reason-in-the-Balance/</id>
    <link href="https://hisen.me/20260726-Reason-in-the-Balance/"/>
    <published>2026-07-26T08:35:00.000Z</published>
    <summary>
      <![CDATA[<blockquote>
<p>这本书比较好的是有很多通俗易懂的探究场景，对话的方式代入感很强。<br>而且修订版给的大部分例子都是中国读者比较熟悉的。</p>
</blockquote>
<h1 id="1-内容概要"><a href="#1-内容概要" class="headerlink" title="1. 内容概要"></a>1. 内容概要</h1><p>从互联网上各种热门的反转事件来看，批判性精神可以说比较缺乏。<br>在网上冲浪多年，我习得的生存法则，简单来说就是保持好奇心：</p>
<ul>
<li>提到的内容有无可靠的来源？比如比较正式的媒体</li>
<li>作者靠什么维持生计？是否会屁股决定脑袋，为了赚钱什么都说</li>
<li>披露的数据是否有来源？数据是否准确？</li>
<li>相关的言论如果不符合常理，那么有什么证据支撑？</li>
</ul>
<p>看完这本书，其实有异曲同工之妙，都是要搞清楚问题的答案，不要人云亦云。<br>值得注意的是，很多主观性强的问题，是不好探究的，特别是社会上共识不强的问题。</p>
<p>探究应该有的态度：</p>
<ul>
<li>开放：对相反的观点、对我们观点的质疑、跟我们的观点不符的证据保持开放的态度。</li>
<li>公正：我们不仅愿意考虑相反的观点，而且会对他们做出不偏不倚、公正无私的判断。</li>
</ul>
<p>真正的批判性思维，不是为了“赢得辩论”，而是为了“寻求真理”；其手段不是固执己见，而是“探究”。<br>简而言之，这本书想告诉我们的是：先探究，后断言；先权衡，再结论。</p>
<p>书里面印象很深的是老师引导学生对艺术作品，特别是一幅画的探究。<br>先从表象开始，收集足够的细节，给出自己的想法。<br>然后带着问题，了解作品的背景，把自己代入进去，<br>通过多人协作沟通，形成一个比较全面、深入的认识。</p>
<h1 id="2-原始摘录"><a href="#2-原始摘录" class="headerlink" title="2. 原始摘录"></a>2. 原始摘录</h1><p>本书围绕六个指导性问题展开：</p>
<ul>
<li>这个问题是什么？</li>
<li>这个问题中包含了什么样的断言和判断？</li>
<li>对于这个问题的各种立场，其相关的理由和论证是什么？</li>
<li>这个问题的背景是什么？</li>
<li>各个论证的效力有多强？</li>
<li>我们如何比较性地评价各种理由和论证，以得出一个有充分理由支持的判断？</li>
</ul>]]>
    </summary>
    <title>《权衡(修订版)》读后感</title>
    <updated>2026-09-13T14:37:46.937Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Reading" scheme="https://hisen.me/categories/reading/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <category term="阅读" scheme="https://hisen.me/tags/%E9%98%85%E8%AF%BB/"/>
    <content>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>在看完一系列的电视剧之后，特别是《夜色正浓》里面李东明以及同事对竞选总监的张玫进行的各种辅导。<br>我在想为什么会没相关的书籍呢？然后想到某博主说的一段话：</p><blockquote><p>“社会经验”特别重要又难以获得。你读书刻苦一点，一年能完成四年的学业。<br>但“社会经验”没办法这样学习，活一年就只能获得一年的“社会经验”。<br>如果有本专门介绍“社会经验”的书自然就不同了。然而根据社会经验，这样的书不可能出版。</p></blockquote><p>我想原因大概是：</p><ul><li>博弈论悖论：社会经验一旦公开，就会立刻失效；</li><li>上下文悖论：社会经验具有极强的“场景高敏感性”；</li><li>既得利益悖论：真正的顶层经验，违背“道德正确”；<ul><li>显性规则（明线）：道德、法律、大道理、企业文化。这些是用来维持社会秩序、讲给所有人听的。</li><li>隐性规则（暗线）：利益交换、权力结构、人性的弱点、圈子文化。这些才是真正推动事情落地的杠杆。</li></ul></li><li>体验悖论：没有经历过的人，根本看不懂；</li></ul><h1 id="2-重点摘抄"><a href="#2-重点摘抄" class="headerlink" title="2. 重点摘抄"></a>2. 重点摘抄</h1><p>职业生涯大概分为三段，每段 15 年；<br>第一阶段：加添燃料，强势开局。<br>第二阶段：聚焦长板，达到高点。<br>第三阶段：优化长尾，持续发挥影响力。</p><span id="more"></span><p>职场可持续的燃料</p><ul><li>可迁移技能；</li><li>有意义的经验；</li><li>持久的关系；</li></ul><p>说服式沟通很重要！<br>对话：两个人用不同的方式讲同一件事情；<br>冲突：两个人用一样的方式讲不同的事情；<br>断层：没有任何沟通基础，无法交流；</p><p>我时常问奥美的领导者：“如果把你放在网上拍卖，会有哪些客户为你‘竞价’，点名要你呢？<br>随说：这段话很精彩，如果自己是一个商品，别人为什么会买你？</p><p>三类人生导师：</p><ul><li>明星：他们是成功的行为榜样，告诉我们如何成功；</li><li>贤者：他们就像苏格拉底，并不为我们提供答案，而是教我们如何思考；</li><li>策动者：他们激励我们，鞭策我们，偶尔迫使我们踏出关键的一步；<br>随说：想清楚自己想要的生活，制定对应的目标，找到自己的导师，持续精进，脚踏实地靠近目标。</li></ul><p>“一万杯”链接成功人士和年轻人：</p><table><thead><tr><th align="left">角色</th><th align="left">核心付出（Cost）</th><th align="left">核心获得（Gain）</th></tr></thead><tbody><tr><td align="left"><strong>年轻人</strong></td><td align="left"><strong>1. 深度准备：</strong> 带着有信息量的问题与思考。<br><strong>2. 主动打破：</strong> 面对高阶圈层的心理压力。<br><strong>3. 情绪资产：</strong> 提供对行业前辈的尊重与正向反馈。</td><td align="left"><strong>1. 认知升维：</strong> 跃迁至高阶行业视野，看清底层逻辑。<br><strong>2. 圈层借劲：</strong> 撬动高阶圈层，获得引荐与内推机会。<br><strong>3. 社交脱敏：</strong> 打破向上沟通壁垒，积累高阶社交底气。</td></tr><tr><td align="left"><strong>成功人士</strong></td><td align="left"><strong>1. 稀缺时间：</strong> 1小时的高效专注力。<br><strong>2. 经验变现：</strong> 梳理并输出沉淀多年的认知。<br><strong>3. 信任背书：</strong> 对优秀后辈给予的一定信任（如引荐）。</td><td align="left"><strong>1. 真实触角：</strong> 穿透管理层级，捕获市场一线真话。<br><strong>2. 种子人才：</strong> 提前锁定并网罗具备野心的年轻苗子。<br><strong>3. 精神溢价：</strong> 确认自身社会价值，沉淀利他声誉。</td></tr></tbody></table><p>将被他人欣赏的价值表现出来，为自己贴上标签，你就会在职场上树立起自己的品牌。<br>随说：深耕某个领域，学习新事物进行布道等。总值就是让大家某方面有需求的时候第一个想到你。</p><p>解决问题的能力：从某种程度上说，世界上任何一份工作都是为了解决某个问题而存在的。<br>你能够分析问题并制订解决方案吗？当你面对一项挑战和一张白纸时，你是否有一两套能解决问题的可靠方法呢？</p><p>情商是你理解和连接他人情绪状态的能力。<br>例如，通过阅读某人的肢体语言发现对方的不适或愤怒，或者知道如何解读周围人的社交线索、情绪和非语言的信号。</p><p>你的“人才账户”。历数你至今雇用和（或）提拔过的人，<br>他们在自己的职业生涯中继续获得提高和发展了吗？<br>其中的佼佼者是否愿意再次为你工作？</p><p>每周大概有 100 小时睁着眼睛，你怎么使用的？工作比例多少？学习比例？娱乐比例？</p><p>整个第一阶段往往长达 15 年，是一个学习和探索的过程，充满了尝试和错误。<br>这时并不是为了找到一份你每天都津津乐道的神话般的工作，而是要找出你擅长什么、不擅长什么、喜欢做什么，以及不喜欢做什么。<br>第一阶段并不仅仅是被动地增长年龄和阅历，像一块牛排一样“更加入味”，而是一个高度活跃和有目的性的阶段。<br>随说：前期蛀牙还是看成长机会，还有环境，收入可能不需要太考虑。矛盾的是这个阶段的人往往最需要钱&#x3D;&#x3D;</p><p>领导者必须飞得足够高，才能用战略的眼光俯瞰全局。<br>任何高级管理人员都必须做到这一点，因为他是少数几个，甚至是唯一一个能看清全局的人。<br>与此同时，能力强的领导者还需要有极度关注细节的能力，这样才能解决棘手的问题或谈下一笔生意。<br>做到这两点的关键技巧就是学会像一架俯冲轰炸机一样，随时调整自己的巡航高度。</p><p>麻省理工学院的经济学家戴维·奥特尔（David Autor）说：“如果一项技能中只有技术，那就很有可能会被自动化。而如果它只需要同理心或灵活性，那么可以胜任的人也是要多少有多少，所以这样的职位的薪水也不会很高。只有将两者结合起来才是有竞争力的。”<br>随说：同理心&#x2F;灵活性 + 技术，才不太会被机器替代。</p><p>作家兼哈佛大学教育和经济学副教授戴维·戴明（David Deming）观察发现，我们的教育体制中唯一与未来工作的需要相匹配的部分可能只有幼儿园。<br>我们在那里开始学习分享、协商、合作和创造。<br>随说：幼儿园这个比喻好</p><p>科学家们声称，制订清晰的计划确实会让人更幸福。<br>这对于如何规划职业生涯有着很重要的意义。<br>与其思前想后，不如采取行动。<br>将你能影响的东西都牢牢控制住，每年至少花一整天的时间反省和制订职业生涯的策略，进行职场盘点，尝试一些假设，确立目标，不断建立和更新你的职场燃料，监控你的进度。</p><p>在职场生活中，我们都需要感恩。作<br>为员工，我们应该感谢那些给我们机会、任务，并让我们加薪、升职和成长的人，也应该感谢那些与我们分享智慧的人。<br>而作为老板，我们也必须感谢那些与我们合作、为我们工作的人，因为他们为我们献出了才华、精力、热情和技能。</p><h1 id="3-原始摘抄-笔记"><a href="#3-原始摘抄-笔记" class="headerlink" title="3. 原始摘抄&#x2F;笔记"></a>3. 原始摘抄&#x2F;笔记</h1><p>这是一本讲述职业生涯 3 阶段选择题的书。</p><!--more--><p>我们需要用新的方法来寻找工作，用新的方法来建立可持续的职业生涯。<br>我们需要新的思维方式和新的工具箱。<br>这不仅是方法，而且是稳定、经得起现实考验的策略，我们能用它们在新的职场中生存和发展。<br>正确的做法并不是抛弃我们所知的一切，而是选出其中有用的部分，将它们置入全新的环境，并将传统的智慧与新的环境结合起来。</p><p>在过去的10年里，我的正职是奥美互动（OgilvyOne Worldwide）的首席执行官，<br>奥美互动是一家拥有5 000名员工的全球市场营销公司，是全球广告公司领头羊之一奥美集团在数字营销领域的子公司。<br>这份工作妙不可言，节奏快速、紧张，每年都有大约120天的时间要在海外出差。<br>后来我开始注意到，除了这份本职工作，我的日程上充斥了越来越多非正式的职业生涯咨询活动。<br>我差不多每周都要与某个寻求职业生涯建议的天才级人物共进早餐、午餐、晚餐或者喝个咖啡。<br>交谈的人越多，我就越发意识到自己提供的建议并没有什么不同，<br>也就是说，虽然每个人身处的环境大相径庭，但他们的挑战核心并无差异。</p><p>《远见》可以被分为三个主要部分。<br>第一部分会介绍正确的职场思维、框架和工具。<br>第二部分会提供一些实用性建议和案例，帮助你应对职业生涯的三个主要阶段。<br>第三部分的内容都以现实生活为基础，主题包括如何平衡职业策略与家庭的关系、怎样处理跨国调动和职场危机。</p><p>工作的幸福感会提高生产力、改善健康，并带来一众其他益处。</p><p>我诚挚地希望《远见》能在某种程度上激励你获取最稳固、最完美、最持久和最快乐的职业生涯。<br>我很高兴，也很荣幸能与世界上最大的几家公司合作，其中包括IBM、美国运通（American Express）、宝洁、宜家、雀巢、联合利华、Facebook、谷歌、雅虎、贝莱德金融集团（BlackRock Financial Group）和可口可乐。<br>作为一名首席执行官，我在过去的30年里聘用、解雇和提供职业咨询的人数以千计。<br>在为本书取材时，我认识了一些世界上最成功的企业家、学者、艺术家、运动员和社区志愿者。<br>我希望《远见》能激发出在如今的学校和公司里难得一见的对话。</p><p>如果你善于执行，那就可能需要在团队中加入一个更有创造力和洞察力的人。<br>坦率地承认自己的短板，针对它们招募盟友，你就可以把大多数时间放在核心长板上了。</p><p>如果你拥有绝佳的口才，那就可以成为公司里最优秀的演讲者。<br>如果你天生擅长协调，那就可以接下其他人都无法应对的困难的团队任务，展现出特殊的整合能力。<br>如果你是个高效的行动派，那就行动起来。<br>将被他人欣赏的价值表现出来，为自己贴上标签，你就会在职场上树立起自己的品牌。<br>如果说你和其他强大而善良的品牌都被摆在货架上，那么当带着空闲职位或升职机会的老板来店里寻找能够解决问题的人时，你要做的就是让他们选择你。<br>随说：用长处打造自己的品牌</p><p>但在我看来，职业生涯的第三个阶段却可能异乎寻常地充实和持久。<br>不过这需要恰当的思维方式、预期与准备。<br>第三阶段的主要目的是确定接班人，即给继任计划画上完美的句号，从执行或领导的角色转变成顾问或辅助的角色。<br>此时，学生变成了老师，学员变成了导师，领导变成了有价值的辅助者。</p><p>成人学校设立了关于商业、艺术、语言、生活技能、兴趣爱好和手工艺在内的数百门课程。<br>你有什么独特的技艺可以教给别人呢？</p><p>第一阶段策略：加添燃料，强势开局。<br>第二阶段策略：聚焦长板，达到高点。<br>第三阶段策略：优化长尾，持续发挥影响力。</p><p>作为首席执行官和职业咨询师，我经常会看到一个现象：人们低估了职业生涯这段旅程的长度，中途就把燃料耗尽了。<br>许多人关注的是职业生涯的表相：头衔、晋升、办公环境、薪水和奖励。<br>这些可以算是职业生涯的重要里程碑，但并不是尾声。</p><p>职场可持续的燃料</p><ul><li>可迁移技能；</li><li>有意义的经验；</li><li>持久的关系。</li></ul><p>解决问题的能力：从某种程度上说，世界上任何一份工作都是为了解决某个问题而存在的。<br>你能够分析问题并制订解决方案吗？当你面对一项挑战和一张白纸时，你是否有一两套能解决问题的可靠方法呢？</p><p>在面试的时候，我总会将至少一个几乎没有答案的开放式问题抛给求职者。<br>我并不怎么在意他们是否答对，而是对他们是如何切入这个问题更感兴趣。<br>好在有不少理论框架和策略能帮助你提高解决问题的能力。</p><p>说服式沟通技巧：无论你最后进入哪个行业，说服力都是一种受用一生的关键技能。</p><p>不管你的交流对象是客户、同事、朋友还是陌生人，能将自己的观点以清晰、简洁的方式呈现出来都是一种基本技能。<br>有的人觉得说服力是一种肤浅或低劣的伎俩。试着改观吧。<br>说服的风格没有定式，从强硬、张扬的步步紧逼到冷静、可信的循循善诱，不一而足。</p><p>从我的个人经验来看，那些无法说服别人接受他们想法的人在职业生涯中都会受挫、贬值。</p><p>你能凭借时长两分钟、以你热爱的话题为主题的视频吸引超过 1000 次的浏览量吗？<br>当然，视频内容不能是色情的。<br>你应该在接下来的6个月里实践一下，选择一个话题，拍摄一段低成本的视频，发布到网上，瞧瞧结果如何。<br>然后，不断在各方面进行调整、尝试。<br>没有什么比真实观众的观看、点赞和分享更能磨炼讲故事的能力了。</p><p>有的时候，如果我要解决一个复杂的问题，就会做一个名为“给妈妈写信”的练习。<br>我会真的起草一封给妈妈的信，解释眼前的问题和我想采取的行动。<br>由于我妈妈未曾涉足过我的行业，所以这一练习就会迫使我使用简单明了的语言，从而让关键点呈现得尤为清晰。<br>下次你遇到什么棘手的挑战时，也可以试试“给妈妈写信”。<br>随说：费曼学习法</p><p>当你谈到自己如何想方设法找到可靠的信息来源并加以记录时，就会传达给听众一个信号：你做了充分的准备，你的观点具备可信度。</p><p>说服式沟通很重要！</p><p>对话：两个人用不同的方式讲同一件事情<br>冲突：两个人用一样的方式讲不同的事情<br>断层：没有任何沟通基础，无法交流</p><p>完成任务的能力：执行并完成任务的能力虽然再基础不过，但对于漫长的职业生涯具有巨大的价值。<br>不畏艰难、持续产出的人才能脱颖而出。</p><p>人才引力：有一种说法是，拥有最优秀人才的公司通常都能成功。<br>我同意这个说法。与此对应的还有一条真理：有能力吸引和调动尖端人才的个人领袖通常都能成功。<br>将优秀的人才招揽到身边能让你把工作做得更好，并扩大影响力。<br>随说：与优秀的人协作共赢</p><p>要培养“人才引力”，首先要有正确的思维方式，即认识到，没有人需要为你工作，必须是他们想要为你工作。<br>“eBay因素”如果把你拍卖，按照为你工作快乐程度来竞拍，有多少人愿意？<br>随说：给大家快乐和想要的</p><p>你能让工作变得更具挑战和乐趣吗？<br>你能教授员工有价值的技能，推动他们进步吗？<br>你能平等而透明地对待所有人吗？<br>随说：提升人才引力</p><p>我鼓励年轻的领导者在加入一个团队几年后评估一下自己的“人才账户”。<br>你们可以审视自己的每一次关键时刻，试着评定自己的行为对“人才账户”起到了增益还是衰减的效果。<br>例如，当初雇用第一位助理时，做的选择是否合适？那个人在公司里是表现出色、持续进步，还是激情退却、原地踏步？<br>在面临艰难的选择，决定如何分配稀有的晋升或加薪机会时，你们有没有挑中那匹千里马？<br>你们是青睐于有能力、有潜力的候选人，还是被引向了“会哭的孩子”？</p><p>在评估任何一位高管时，我都会加入一轮有关“人才账户”的对话。<br>我要求高级职务的候选人谈一谈过去在不同公司里的下属。<br>你是从哪里找到那些人的，即你是继承了一个团队还是招募了新人？<br>最重要的是，他们现在在哪里？他们现在在原来那家公司或那个行业里做得有声有色吗？<br>其中的佼佼者是否跟随你到了下一家公司？<br>我听过最糟糕的答案是：“这是个好问题，但我不知道他们现在都在哪里。”<br>随说：人才吸引力案例</p><p>格兰特观察了三种社交风格，将它们与工作业绩和幸福指标关联起来。<br>“获取”是只索取不付出，“互利”是在付出的同时期望得到某种回报，而“付出”是无条件地给予，对收获回报并没有太大的期望。<br>付出者是净输出者，在利他性、责任心、社会正义和同情心这几点上比较突出。<br>据格兰特所说，成功的付出者就是付出超过获取的人，跻身最杰出和最幸福行列的机会会比别人大得多。<br>随说：获取、互利、付出。付出有助于成功</p><p>就我个人经验而言，人们会朝着他们信任的领导者靠拢。<br>而“付出”的行为就是一种建立信任的强有力的方法。<br>学习如何寻求帮助和如何提供帮助，会成为职场持久战中一项强大的可迁移技能，而且后者是最重要的。</p><p>情商是你理解和连接他人情绪状态的能力。<br>例如，通过阅读某人的肢体语言发现对方的不适或愤怒，或者知道如何解读周围人的社交线索、情绪和非语言的信号。</p><p>情商训练：我向他推荐了一些这方面的好书，<br>其中包括丹尼尔·戈尔曼的《情商3》与布拉德伯利（Bradberry）和格里夫斯（Greaves）的《成功EQ密码》（Emotional Intelligence 2.0 ）。<br>但是对雷蒙德而言，看书并不是难事，关键是他必须创造实践经验才能发现和磨炼情商技能。<br>他应当找机会获取公司和行业里的团队领导经验，他需要主动听取同事对其情绪领导力的反馈。<br>随说：核心还是训练</p><p>我鼓励雷蒙德留意公司里的领导者在人际交往中的言谈举止，分辨其中的优劣。<br>我让他尽量多发表一些公开演讲，因为亲眼看到现场听众的反应是一种很有价值的经验。</p><p>享用一生的可迁移技能</p><ul><li>解决问题的能力</li><li>说服式沟通技巧</li><li>完成任务的能力</li><li>人才引力</li><li>情商</li><li>帮助和求助的能力</li><li>如何与别人进行眼神交流和握手</li><li>如何搜集信息。辨别真假</li><li>如何呼吸(调节副交感神经？)</li></ul><p>我通常会在候选人的背景中寻找多样性经验，确保他们拥有适应性和灵活度。<br>随说：我的灵活度、适应性是什么？</p><p>不要让你的职业生涯脆弱不堪。<br>随着职业生涯的发展，你要寻找机会分别到一个大公司和创业公司的环境中工作，<br>要找机会去国外工作或者至少去几个不同的城市，还要努力发起一些新项目、处理一次危机，<br>并在明显存在个人失败风险的情况下筹办一场大型活动或演出。</p><p>马克·利纳（Mark Linaugh）是世界上最大的传播集团WPP的人力主管，负责的员工数量接近20 000人。<br>当他计划雇用或提拔一名新的领导者时，就希望能看到对方领导力多样化的证据：</p><ul><li>他们创立过新东西吗？</li><li>他们曾经快速扩张过一家企业吗？</li><li>他们曾经拯救过一家濒危企业，使之起死回生吗？</li></ul><p>由于电子商务涉及整个销售流程，从产品开发、供应链的运作、营销到客户服务等，所以它能教会你如何用总经理的头脑来思考。<br>你将有机会接触到品牌塑造和用户体验等商业“软技能”，以及利润管理、数据分析等“硬技能”。<br>最棒的是，电子商务的工作意味着你会每天收到即时销售的业绩单。电子商务中的一个职位就像是整个商业的缩影。<br>这是一个多么神奇的个人学习和发展的加速器啊！如果我现在要开始自己的职业生涯，那么一定会把至少一个阶段放在电子商务上。<br>随说：什么是电子商务</p><p>持久的关系可能是最有效、最耐用的一种职场燃料了，包括了职业生涯中与你相关的品牌和人。</p><p>人际关系</p><ul><li>你的上司：最直接的影响力，导师</li><li>你的客户：</li><li>商业伙伴：顾问、猎头、机构等</li><li>身边人才：</li><li>你的同类：</li></ul><p>我时常问奥美的领导者：“如果把你放在网上拍卖，会有哪些客户为你‘竞价’，点名要你呢？</p><p>在著作《异类》（Outliers）中，马尔科姆·格拉德威尔（Malcolm Gladwell）研究了运动、音乐、绘画、商业等各个领域的佼佼者。<br>他估算出大约需要 10,000 小时的密集训练和演习，一个人才能在某一方面达到精通。</p><p>无论你拥有多高的智商或天赋，成功都需要花费超乎想象的时间进行高强度的练习。<br>观察一下你感兴趣的行业，研究一下别人的发展轨迹，你会逐渐发现，获取关键的技能和经验必须花费一定的时间。</p><p>小野二郎被誉为全世界最好的寿司师傅之一，他要求手下的学徒在烹饪任何食物之前先花10年时间磨炼刀功。<br>你对需要学习的技能了解得越多，就越能为职业生涯做最佳决策，从而将你获得长期成功的可能性最大化。</p><p>40 岁之后能赚到的个人财富百分比：在 40岁之后，你赚到的钱会占你一生个人财富的百分之多少？<br>大部分人的估计是 60%。<br>年轻人倾向于估一个比较小的数字，例如 40%。<br>真正的答案其实是 85%～90%。<br>随说：这真是出乎意料</p><p>个人财富的积累绝大部分都发生在40岁之后，原因非常简单。<br>第一，根据我们之前的发现，40岁之后的职业年限要比之前的更长，而且往往薪水也更高。<br>第二，你可以享受到复利。<br>第三，当不需要再付房贷和与孩子相关的费用之后，许多支出都会逐渐减少。</p><p>职业规划相关的几个数字</p><ul><li>职业生涯的长度 62-年龄</li><li>精通1个技能需要的时间</li><li>40岁之后赚钱的比例 85% ～ 90%</li><li>你有多少社交网络好友(关系好的)</li><li>职场支持者的人数(你会感谢的人)</li></ul><p>你的“人才账户”。历数你至今雇用和（或）提拔过的人，<br>他们在自己的职业生涯中继续获得提高和发展了吗？<br>其中的佼佼者是否愿意再次为你工作？</p><p>盘点部分有意思，回头手写一下。</p><p>进入职场之后，每个人的周围都会出现越来越多的关键人物和团体，他们强烈影响着我们的职业轨迹，并组成了一个生态系统。</p><p>而人际关系的构建者会首先尝试帮助别人，他们不会有所保留。<br>虽然他们心里清楚大部分好意都会得到回报，但是并不会精于算计。<br>他们还会时刻维护自己的人际关系，而不是在需要的时候才想起来。</p><p>关键同事：是在目前的公司里对你的发展拥有决定性影响力的5～10个人。<br>排在榜首的是你的上司，这个角色在各种研究报告中都一直被列为影响职业成功和幸福的头号人物。<br>你上司的上司也是个至关重要的影响者。<br>在大多数情况下，如果你的直属上司提议给你加薪或职，那就总是需要先得到他的上司的签字认可。</p><p>写出你认为算得上或者可能成为你的支持者的人的名字。<br>如果你想不出来，可以回忆一下是谁推荐你上大学，或者谁支持你得到了职位或晋升机会。</p><p>三类人生导师：</p><ul><li>明星，他们是成功的行为榜样，告诉我们如何成功；</li><li>贤者，他们就像苏格拉底，并不为我们提供答案，而是教我们如何思考；</li><li>策动者，他们激励我们，鞭策我们，偶尔迫使我们踏出关键的一步。</li></ul><p>如果你将自己当成一个学生，那就自然会找到老师。<br>在找到了能推动你职业生涯前进的人时，你就要想尽办法帮助他们、为其所用，或者花时间与他们相处。<br>如果你很幸运，能让他们倾听你、引导你，那就像海绵一样用力吸收吧。<br>优秀的导师都希望看到学生全身心地投入学习中去。</p><p>你还要对他们和他们想要完成的事情保持忠诚和热忱。<br>最重要的是，要感恩。你要让他们看到他们的影响力，尽早和尽可能地感谢他们。</p><p>成为别人的明星、贤者或策动者是一种极好的方式，<br>它可以用来向当初站在同样立场上帮助你的人表达敬意，<br>而且还能让你感觉到最深刻的喜悦，这种喜悦来自对别人的影响力。</p><p>一旦找到了一名导师或支持者，首要任务就是欣赏他们，并与他们保持联系。<br>时不时地给他们发条消息，告诉他们你现在的状况，分享你的成功和失败，向他们寻求建议。<br>记住，对你的导师而言，这类沟通并不是什么负担，而是一种奖励。<br>随说：分享你的成功和失败，多沟通，沟通不是负担而是一种奖励(被需要、被尊重？)</p><p>我认识一个千禧一代的后起之秀，她每年都会对影响自己职业生涯的人做一次“能量评审”。<br>她发现周围有一些人，他们尽管是很好的私人朋友，心地善良，过去也帮过很多忙，但是现在似乎正在妨碍她、拖她的后腿。<br>他们是第一个说“这不可能”或者“你根本就不该尝试”的人。<br>所以她会尝试花更多的时间与生态系统中的其他人在一起，那些人会让她感觉更强大、更聪明、更有活力。</p><p>基本上，你每年都要为接下来的一年设立目标，并回顾过去的这一年。<br>下面这4个问题有助于你完成这项工作：</p><ul><li>我是否正在学习和成长？</li><li>我是否正在对某些人、现在的公司，乃至整个社会拥有影响力？</li><li>我体验到乐趣了吗？</li><li>我是否得到了适当的奖励，并创造了经济价值？</li></ul><p>职业生涯第三阶段，主要追求影响力的人。<br>此人已经从全职工作退休，正在寻找一个能够以有意义的方式付出和做出贡献的职业生涯阶段。<br>对他来说，乐趣和学习被放在第二位，而奖励的重要性只能排到最后。</p><p>职场燃料之可迁移技能：学术学位、专业证书，语言，优点，情商，“人才账户”。</p><p>职场燃料之有意义的经验：个人旅行，海外工作经验，企业管理、创业经验，社区、志愿者活动，做出个人贡献的项目，公开演讲、写作、表演的经验，教学、咨询、指导的经验，工作之余的热情所在……<br>职场燃料之持久的关系：联系人，专家团，关键同事，支持者。</p><p>时间是你的人生货币。它是你唯一拥有的货币，而且也只有你能决定如何消费它。<br>随说：投资在学习上</p><p>如果你问一个资深的财务顾问，如何让你的投资获得最高的长期产出，他会告诉你，关键是“资产配置”。<br>换句话说就是，你是否在正确的时间投资了正确的东西，即股票、债券、期货和其他资产类型？<br>职业生涯也是一样的道理，只不过关键的变量是你如何投资时间。</p><p>因为我们平均每周都有大约 100 个小时是清醒的，所以你也可以轻而易举地画出这样一张图。<br>我将自己的 100 个小时分散到了几个大类中，例如工作、家庭、健康、教学和社区。<br>随说：这个统计很重要</p><p>我的一名天才级同事的时间档案，当时他30多岁。<br>他在工作中努力得令人难以置信，并且不是偶尔为之，而是向来如此。<br>他几乎没时间照顾自己新建的家庭。他虽然尝试着跟朋友见面，但常常不得不“因为我工作太忙了”而取消计划。<br>他任由自己的爱好荒废，原因还是工作。这位经理在40岁时倒下了，在将近两年的时间里都无法工作，差点因此而崩溃。<br>我认为，他的时间档案缺乏多样性，这是导致他崩溃的一个显著因素。<br>随说：不要崩太紧了，人需要时间休息。生理和心理都是如此；</p><p>教学和社区方面的活动似乎能对幸福和成功产生超越时间占比的影响。<br>这与亚当·格兰特在《沃顿商学院最受欢迎的成功课》中的观点是一致的，即学习、提供建议以及帮助他人会对我们的精力和影响力带来深远的影响。</p><p>如果很忙没法照顾家庭关键日期，可以提前商量。而不是临时商量。</p><p>社区工作和志愿者活动可以起到很好的激励作用，即使是小试牛刀也成效显著。<br>人们常常说：“我退休了就去做志愿者。”在我看来，还是越早越好。</p><p>将健身融入日常习惯，这将为职业生涯提供持久动力。</p><p>通勤是一个经常能被挤出时间用于其他投资的地方。在美国的大城市中，上下班的通勤时间平均有近两个小时。<br>对某些人而言，这些时间似乎都白白浪费了，或者成为他们路怒症的借口。<br>随说：我还好，基本上都在看书</p><p>迪米特里骑自行车上下班，把在纽约市糟糕的交通中浪费的两小时变成了每日的健身锻炼时间。<br>有些人将地铁通勤时间转变成了一段读书、写作的高产出时间。还有人一边走路上下班，一边听着教育播客或有声书。<br>这是学习一门新语言、探索行业中的新趋势，或者培养新的职业技能的好方法。</p><p>学习职场数学能帮你树立起正确的思维框架；<br>思考职业生涯的三个主要阶段能提醒你当前在这漫长旅程中的位置；<br>盘点一下职场清单，总结目前的职业生态系统，这会让你了解自己的技能和关系的状态；<br>仔细审视你的时间档案能帮你弄清在职场和生活中可以做出什么样的平衡调整。<br>做完这些，你就万事俱备，可以做出一些明智的决定了。</p><p>职业生涯选择考虑点</p><ul><li>你的职业理想是什么，或者至少假设一个你可能想要达到的目标。</li><li>你目前手上有什么职场燃料？</li><li>你需要什么职场燃料才能实现这个终极理想？</li></ul><p>根据我现在的位置以及我想要到达的地方，哪个选择能提供最大的机会，让我抵达目的地呢？<br>随说：做选择一个多看看这里<br>￼</p><p>现在，杰米就可以按图索骥寻找可选的职位，在接下来的数年内做出明智的选择了。<br>他不仅要知道什么职位好，而且要知道什么工作能提供最丰富的发展因素。<br>我后来又跟杰米联系，发现他已经在当前的公司里找到了一个很好的职位，<br>在这个职位上，他能够培养那些必要的技能，他正走在一条很棒的能培养领导力的职场路径上。<br>随说：知道目标岗位需要什么</p><p>新的学位能给你带来什么？</p><ul><li>增加你目前不具备的可迁移技能？</li><li>帮助你重塑自我，改变职业生涯的方向？</li><li>建立新的人际关系，并拓展职业生态系统？</li><li>获得你目前没有的重要证书？</li><li>加速你的探索步伐，即通过实践验证自己真正擅长和热爱的东西？</li></ul><p>从很多年前开始，所谓工商管理硕士的价值会细水长流地体现出来的概念就已经过时了。<br>如今，这种价值已经不那么显著，因为有的人希望这些投资能得到切实的经济回报。<br>如果你想为自己算一下这本账，可以考虑一下工商管理硕士本身的成本，<br>也就是它的学费、书本费、物料费，以及可能的额外差旅、生活和居住费用，有的人还有学生贷款的利息。<br>如果你准备辞职去进修，那么还要加上一两年内都没有薪水的机会成本。</p><p>麦吉尔大学的团队想到了一个惊人而强大的主意：饲养和销售昆虫供人类食用，主要是蟋蟀、蚱蜢和象鼻虫。<br>根据他们的研究，昆虫是一种极好的蛋白质来源，相较于牛肉和鸡肉，培育昆虫所需的资源要少很多。</p><p>快速成长才能获得长远成功</p><p>奥朗认为，长期成功的基础是快速的成长。<br>大多数大学毕业的聪明人每年的成长速度为 10%。<br>这意味着他们的能力在毕业 7 年后差不多会提高一倍。<br>大多数 29 岁的人的薪资是他们大学毕业后第一份工作的两倍，不是正好说明问题了吗？<br>如果要成长得再快一点，你就需要一份满足以下条件的工作：</p><ul><li>你周围都是比你聪明的人；</li><li>你有失败的机会；</li><li>公司有让你这样的人肩负重大责任的传统。</li></ul><p>找到一家至少有 30% 的人都比你聪明的公司，<br>因为你通过向周围的人学习而获得的成长速度是最快的，所以这些人就应当分外出色。<br>由于人们更喜欢雇用认识的人，所以其中不少人在接下来的 30 年里将一直是你的同事。<br>因此，请谨慎挑选同事。</p><p>有一个现象非常常见，那就是人们会选择一份百分之百会成功的工作，尤其是刚毕业的学生。<br>尽管板上钉钉的成功一开始会让人感觉很棒，但并不能助人成长。<br>你应该寻找一个能让你参加高失败风险项目的组织。<br>随说：创业公司？</p><p>假设你是一个有远大目标的人，想要持续不断地成长，那就一定要找机会晋升，并承担越来越重的责任。<br>那些有相应的机制并且增长速度很快的公司是最有可能快速提拔你的。<br>寻找一些与你背景相似又加入了该公司的人，看看是否有人被赋予了重大的职责。<br>随说：但是难找</p><p>我们总是会低估在未来才能兑现的好处，这种现象被称为‘时间贴现’（temporal discounting）。<br>我们都不愿意用当前的痛苦，比如更辛苦的工作、更低的薪水、更低的声望等，来换取未来的某样东西，即使未来的好处其实更加丰厚。<br>作为人类，我们本能地不相信未来的好处能够兑现，所以会在当前对它们打很大的折扣。<br>随说：类似损失厌恶、很难做到延迟满足？</p><p>不要放任自己在职业生涯中成为快闪族，或像条件反射一样说跳槽就跳槽。<br>先在目前的公司里至少找三个人聊一聊再做决定，这三个人可以是你的上司、人事经理以及组织中另一个值得信赖的人。</p><p>在老板面前表达你的野心是一件健康而有益的事情，<br>不过，你给出的目标应该与自己的职场路径和时间规划有关，而不一定是眼下的解决方案。<br>如果你只给公司留出几天的时间对你的最后通牒做出回应，那就必须有承担后果的心理准备。<br>多数时候，公司是不会还价的。<br>宾夕法尼亚大学沃顿商学院（Wharton School）的文章《他处并不一定比此处更好》（The Grass is Not Always Greener）很有见地，值得一读。</p><p>有的人对自己想做的事情一清二楚，一走出校门就很快置身于令人满意的岗位上。<br>他们是稀有的“独角兽”，但大部分人并不是。<br>很少有人能确切地知道自己想要干什么，尤其是在刚刚起步的时候。</p><p>整个第一阶段往往长达 15 年，是一个学习和探索的过程，充满了尝试和错误。<br>这时并不是为了找到一份你每天都津津乐道的神话般的工作，而是要找出你擅长什么、不擅长什么、喜欢做什么，以及不喜欢做什么。<br>第一阶段并不仅仅是被动地增长年龄和阅历，像一块牛排一样“更加入味”，而是一个高度活跃和有目的性的阶段。</p><p>第一阶段的策略很简单：步入职场、迎接新发现，并为前方的漫长旅程储备职场燃料。</p><p>针对首次加入职场人的提示</p><ol><li>利用在读的时间储备早期形式的职场燃料</li><li>制定求职作战计划</li><li>积极参与校园招聘</li><li>高效得进行在线申请</li><li>用好你的联系人</li></ol><p>将你的简历草稿给一位或多位信得过的顾问过目，比如身处这个公司或者至少这个行业的人。听取建议，一击制胜。</p><p>在与别人的交谈中，我被问过一些很有意思的问题：</p><ul><li>这个行业有什么特别之处？</li><li>你喜欢或不喜欢这份工作的哪些方面？</li><li>在你的公司取得成功需要哪类技能？</li><li>你是怎么得到这份工作的？</li><li>你们公司的企业文化是什么样的，与其他公司的有何不同？</li><li>人们现在都是如何进入你这个行业的？（可能与过去有所不同。）</li><li>有什么挑战会让你彻夜难眠？</li><li>你认为这个行业的引领者是谁？</li><li>你知道你的公司有什么合适的职位空缺吗？（直接问，没关系。）</li><li>你能不能再推荐一家公司或一个人，让我跟它或他聊一聊？<br>随说：我们也可以拿着这些问题跟别人交谈~</li></ul><p>最后，善意实业发现，微小的成功对于培养动力和信心能起到很大的作用，比如收到第一次面试邀请或考取一门新技能的证书。<br>没有人能一下子就找到工作，大多数电子邮件都会石沉大海，面试也常常会被取消，职位空缺的时间会被延后甚至从此杳无音讯。</p><p>如果你发现了某样让你着迷、让你夜不能寐的东西，那么这就是你应该追求的一条路。</p><p>成为自己的产品经理<br>我们从品牌的塑造经验中可以学到很多。<br>这里没有什么窍门或捷径，领先的品牌都建立在优质的原料和精细的制作之上。<br>虽然华丽的包装和大力的营销是让产品的首次试销大获成功的好办法，但是历久弥坚的品牌却能始终兑现包装上的承诺。<br>当领先的品牌无法满足用户要求时，他们就会想办法弥补。</p><p>如果你认真对待自己的职业生涯，那就需要了解更多的情况，<br>搞清楚公司是怎么运转的：它怎么建立的，它的理念是什么，它如何赢利，它的关键人物有哪些，以及它的愿景如何。<br>如果你从公司的常规宣讲中得不到这些问题的解答，那就把它当成入职 100 天的一个任务吧。<br>做好本职工作，阅读公司的年报，如果能找到外部分析机构对公司的评估就更好了；<br>在茶歇时间，在新老员工中打听公司的内部消息；<br>通过加入公司内部的俱乐部、团队或职业社交网络来提高参与度；<br>主动在公司的活动中帮忙，并且尽心尽力；<br>慢慢地建立由你的联系人、专家团、关键同事和支持者组成的职业生态系统。<br>随说：详细了解公司</p><p>在职业生涯的早期，选择一些专题去钻研，逐渐成为别人咨询的对象。<br>你磨炼的不一定得是震惊世界的高深技术，一些常会出现的问题或专题就可以。<br>在我的公司里，我知道如果有关于体育营销的问题，找丹尼尔就对了。<br>关于千禧一代的投票趋势，我会问伊兹。</p><p>事实是，如果他们毫无准备地直接与高层领导见面，那么通常不会有好结果。<br>如果你只是坐在会议室里记笔记，或者提些天真可笑的问题，这不仅帮不到你，反而会害了你。<br>别人的反应往往是“那人是谁，我为什么要花钱雇用他们”，<br>或者“这个问题是谁问的，我们4年前就已经这么做了”，这可不是你想要的结果。<br>随说：需要精心准备，否则适得其反。</p><p>拿出一个高层领导或客户正在苦思冥想的具体问题，跟你的老板讨论讨论呢？<br>把它当作一个为期两周的秘密任务，从各个角度研究一番。<br>翻阅你手上的资料，在一份简短的 5 分钟展示中给出你的解答，将你的论点和假设凸显出来。<br>然后跟老板商量一个合适的时间，用5分钟完成一场重磅表演。<br>展现你的才华，仔细倾听观众的反馈，并反复这么做。<br>只要每过几个月就做一次这样的讨论，你就会在越来越多的专题中成为值得信赖的咨询对象。<br>这会为你的职业生涯带来新的价值。<br>随说：不断实践和高层对话，提升沟通能力</p><p>大多数人都是糟糕的沟通者，如果成为能沟通且能把故事讲得精彩的少数人之一，那你就能脱颖而出。</p><p>沟通大纲：</p><ul><li>首先，话题是什么？我们的听众的注意力正在不同的电子邮件和会议之间快速切换，有一半的时间他们完全不知道我们到底在说什么，所以每一次你都要说得一清二楚。</li><li>其次，写下你的三个重点，加上用于佐证的事实和原因加强说服力。这意味着你既有观点，又有支撑它的证据。</li><li>最后，直白地说出你希望听众接下来怎么做。这样一来，你的沟通至少是有力和清楚的。这能让你领先于世界上80%左右的人。</li></ul><p>使用短信或电子邮件来开始沟通是没问题的，<br>但在信件结尾处一定要用更加私人的方式：“哇，这真的是个很重要的问题，我们必须谈谈。我们可以明天早上9点通个电话吗？”<br>像电话这样的语音媒介之所以能够解决难题，是因为它至少还具备一定程度的情感因素。</p><p>你的社交声望可以通过参加行业协会、写博客、演讲等方法来建立，这些都是提高专业技术水平和改善职业生态系统的良好途径。<br>你要首先确保打好坚实的基础，要想办法在自己的公司里创造强大的产品、习得真正的专业技术，并享有良好的声誉。</p><p>第一阶段的最后一项技能是理解自身的价值，以及为自己的贡献争取公平的奖励。<br>许多人在职业生涯的早期都对这些话题表现得很天真，准备也不充分。<br>他们常常会从同事、家人或招聘人员那里收到不良的建议。<br>我的建议很简单。首先，判断报酬和获得的认可合不合适，看的是贡献，而不是资历。<br>随说：看的是贡献</p><p>搞清楚公司对你这个职位的期望是什么，尽可能完美地满足它。<br>当你想要评估自己的绩效和报酬时，首先将你的贡献列出来，包括“硬”贡献和软指标。<br>例如，你有没有为公司带来收益和新客户，或者帮忙节省了公司的开支？<br>有没有证据表明你让公司的顾客更满意了？<br>你有没有发明在将来某一天能提高利润的新产品、想法或流程？<br>你做的事情是否能提高公司的声誉，如发表一篇文章、参加一场颇受好评的演讲活动、赢得一个奖项等，<br>或者是否为人才库增加了一些重要的新生力量？<br>尽可能多地关注产出，而不是行动。<br>光是做你的本职工作只能让你维系目前的职位和薪酬。<br>随说：岗位本身的产出只能维持当前职级，超出的部分才是资本；</p><p>找上司聊一聊，他们的期待是什么，你当前关注的是不是重点。需要怎么做才能继续往下走</p><p>如果你想加薪或升职，那就得挑自己表现好的时候提出来。<br>如果有升职的计划了，那你就得想想有没有可靠的候选人能接替你现在的职位。<br>如果你的表现很好，你的上司对于将你转到某个新职位上会有一些自然的抵触。<br>所以，请围绕着你的继任计划提出一些可选方案，让他们能更放心地支持你的升迁。<br>如果短期内看不到晋升的希望，那就可以与你的上司一同制订一份计划和时间表，试着改变现状。<br>如果你对于得到的答复依然不太满意，那就得好好思考一下职场路径，看看其他的选择了。<br>在衡量其他选择时，要着眼于大局。</p><p>对于像与他人共饮咖啡这样稀松平常的事情，我们很容易低估其影响力。<br>这种近乎全球通用的惯例不仅能跨越世代，而且没有任何威胁性。<br>它让我们在一种非正式的环境中更轻松地分享想法和信息，这样的非正式会议能带来巨大的潜力。</p><p>我是在一个小镇里长大的，并没有实现梦想所需要的人脉关系网，<br>于是我在毕业时就给许多不同行业的领袖发电子邮件，邀请他们共饮咖啡，聊聊可能的机会。<br>我给同样来自安大略省北部的米娅发了邮件，约定要好好聊一聊，<br>结果这成了我做梦都想不到的最佳机会，而这一切都发生在喝咖啡的片刻之间。</p><p>不同于大型职业招聘会，共进咖啡所提供的一对一接触能产生更高质量的联系和更深厚的导师关系。<br>戴夫说：“它的目的很简单，就是让现在的领袖能更容易认识未来的领袖。</p><p>大学第一年夏天，学校能帮他安排的唯一一份工作就是薪水最低的洗碗工。<br>戴夫认为自己能搞到更有意思的机会，于是就申请并成功受聘为政府在青年事务方面的一名发言人。<br>在这个职位上，戴夫研究了加拿大青年的需求，并在政策制定者面前代他们发声。<br>他开始与许多公司建立关系，学到了公共演讲、公关和沟通方面的技巧。<br>从一开始，戴夫就培养了将来大有可为的技能和关系。</p><p>对戴夫而言，帮助年轻人一直都是他职场路径的主要脉络，也是一种让他获得了使命感的追求。<br>随说：一万杯咖啡，链接成功人士和年轻人</p><p>职业生涯第二阶段大约从踏入职场的 15 年后开始，<br>它会带来一些独有的机会和焦虑：我能获得多高的成就，我该如何找到下一步的方向；<br>我要怎么才能找到甜蜜区，同时避免倦怠和迂腐；<br>我如何才能不靠加班和毁掉自己的生活来扩大我的影响力；<br>我该怎样从第一阶段打下的坚实根基中收获红利？</p><p>如果说第一阶段是寻找你的甜蜜区，那么第二阶段就是锚定它。<br>你要不断问自己这三个难题：我擅长什么？我爱好什么？这个世界需要什么？<br>随说：结合需求，列出自己的擅长、和喜欢的</p><p>我们的专注度决定了学习的深度。</p><p>格林认为，精通的能力并不是遗传的。<br>如果我们愿意投入高专注度和足够的时间，就会精通任一技能。<br>他认为，在一项能力上达到精通大概需要 10,000 小时，如果我们追求的是超级精通，那么甚至需要 20,000小时。<br>随说：道理是这个道理，但是人的寿命大概 30,000 天~</p><p>当代的一个极好的例子是史蒂夫·乔布斯，他自小就痴迷于技术和设计。<br>在第一次加入苹果和后来在 NeXT 的日子里，他经历了很长一段学徒生涯，体验过许多的失败和无价的教训。<br>当 1996 年回归苹果公司时，他已经精通了某种几乎无形的东西，即远在别人之前嗅到潮流趋势的能力。<br>这种意愿乘以时间的公式适用于艺术家、运动员、棋手、发明家、生物学家和其他所有领域。</p><p>我父亲一直说，如果你想做什么事情，就找到那个做得最好的人，然后跟着他们做。<br>随说：找到自己的榜样，或者行业精英~</p><p>托德向这两家公司提交了求职申请，然而都失败了。<br>虽然他很失望，但并没有退缩。<br>“我制订了一份为期三个月的计划书，终于说服了施乐让我在他们陷入困境的打印机部门工作，而且报酬100%都来自提成。<br>我当时超级自信，觉得自己一定能力挽狂澜。</p><p>他失败了。事实上，他一败涂地，最后发现虽然自己在当餐馆经理时通过顾客服务培养了友善的说话之道，但这并不能化为销量。<br>他的业绩甚至差到了让老板都斥责他是“我职业生涯中最大的败笔”。<br>这是托德职业生涯中的最低谷。<br>“我学到了极有价值的一堂课，那就是倾听比说更重要，”他说，“我不得不闭上嘴巴进行销售。</p><p>《心理游戏的教练》（Coaching the Mental Game），这本书讲的是心理素质和运动表现之间的重要联系。<br>托德从中发现了一个机遇。他想运用自己的推销技能来激励其他人，于是就创立了一家名叫“巅峰运动员”的培训公司，专门训练年轻运动员，使他们在心理、情绪和生理上变得更加强大。<br>他接着又发现，这种类型的训练的价值不仅适用于运动员，也适用于商人。</p><p>“梦想要大，但前进的步子要小”。<br>只要你能保持一直向前的动力，就能持续成功，即使中间有些挫折也不碍事。<br>“总有些事情会失败，”他说，“这是不可能彻底掩盖的。但是你可以决定的是，是否从中吸取教训。</p><p>托德将餐厅打工的经历和一系列的失败转变成了长期成功的职业生涯。<br>托德钻研技艺的那股认真劲儿一直令我印象深刻，他在不断地测试新的假设。</p><p>把眼光从小圈子中解放出去。</p><p>她(芭蕾舞者，脚踝受伤只能恢复95%，且需要忍受剧痛)已经24岁了，大部分传统的顶级高校都不愿意录取她。<br>不过，比大多数学校都更开放的布朗大学向她提供了哲学系的奖学金。<br>这一次，也不是所有家人都认为这是个好主意。<br>毕业时，雷切尔发现自己还是想为振兴艺术做些事情。<br>她想，也许可以去当律师。<br>可是一个做律师的朋友给了她一些好建议：如果你真心想要改变艺术家和艺术事业，那就从商业上帮助他们。你可以为艺术组织工作，让它们良好地运作起来，也让艺术家们能专心创作。</p><p>在将近20年前，雷切尔以职业芭蕾舞演员的身份首次在美国芭蕾舞剧院登场；<br>20年后，当美国芭蕾舞剧院找她作为他们的执行董事候选人时，雷切尔的职业生涯转了一个圈又回到了原点。<br>随说：曲线救国？</p><p>雷切尔的旅程还在继续。在过去的一年里，<br>她写了一本名为《艺术家的罗盘》（The Artist’s Compass, Touchstone出版社2016年出版）的书，<br>并接下了另一个重大职位——洛杉矶音乐中心的总裁兼首席执行官。<br>雷切尔精通的领域是商业和艺术的交集，这一点与众不同。<br>她定期指导年轻的艺术家，常常传授一些基本的生存技能。</p><p>她特别喜欢教师或伴奏这样的工作，因为艺术家能在赚取体面、稳定报酬的同时，依然与自己的热情紧密相连。<br>雷切尔越来越强烈地建议艺术家培养营销技能，并开辟自己的电子商务渠道。</p><p>对于那些不仅有志于成为艺术家，而且想当艺术管理方面顶尖领导者的人，<br>雷切尔给出了这样的建议：理清你的财务。财务是大部分艺术组织的阿喀琉斯之踵。<br>充分理解损益表、预算和成本控制，想清楚如何产生收益，而不是守株待兔。<br>你的头号任务是为组织赚钱或筹集资金，所以人际交往并不是什么蠢事，而是必须做的事情。</p><p>雷切尔还说：<br>你可以多找几名导师，把眼光从目前的组织和派别的狭小圈子中解放出去，看看更广大的世界。<br>我们能从其他领域学到什么呢？<br>不要过河拆桥，要友善待人。<br>我就是过了将近 15 年，才回到美国芭蕾舞剧院得到一份好工作的。<br>最后，不要在艺术家们还没尝试时就泼冷水。他们都是大孩子，市场会让他们自己领悟的。</p><p>他开始把午餐的时间都用在计算机技能的磨炼上，努力消化流行杂志上的版式设计，最终设计出了一整套作品。<br>在这一过程中，查克意识到如果直接为天联广告公司这样的客户服务，就可以比经过临时服务中介推荐多赚三倍的钱。<br>没过多久，他就不再只是为演示做设计了，他开始阅读它们，学习如何创作有说服力的演讲、如何推销、如何营销。<br>每一份新的工作都是一堂广告课程，查克对它们照单全收。“我知道自己还能进步，”他说，“我能看到别人看不到的东西，而且能够将它传达出去。</p><p>在想起曾经的那个少年时，查克为现在的成就感到自豪：你必须自己帮自己开门，不停地问自己‘另一边有什么，我为什么不能去呢。<br>永远不要停下对未来的规划，要努力让自己成为幸运儿。</p><p>作为领导者，你的巡航高度如何<br>查克·里斯并不是唯一一个想着如何扩大影响力的人。<br>人们在第二阶段面临的一个主要烦恼就是如何从执行者转变为领导者。<br>如果不通过增加工作时间来扩大影响力，让第一阶段取得成功的那些方法往往就并不适用了。问题的关键就在于“巡航高度”。</p><p>领导者必须飞得足够高，才能用战略的眼光俯瞰全局。<br>任何高级管理人员都必须做到这一点，因为他是少数几个，甚至是唯一一个能看清全局的人。<br>与此同时，能力强的领导者还需要有极度关注细节的能力，这样才能解决棘手的问题或谈下一笔生意。<br>做到这两点的关键技巧就是学会像一架俯冲轰炸机一样，随时调整自己的巡航高度。</p><p>你要能在高空中飞行，分析战局形势，找出主要问题或机会；一旦发现目标，你就要具备追踪并粉碎目标的能力。<br>遇到重大危机，例如一场矿难或安全漏洞时，首席执行官要能直击问题的核心，并在完成任务之前亲力亲为、参与其中。<br>但是一旦问题解决，你就得适时地“飞回高空”。</p><p>我们都见过那种始终高高在上的领导者，也见过另外一类似乎离地面只有几厘米、一直插手问题的领导者。<br>不要一直做飞在高空的宇航员，也不要一直做飞在低空的扫地机。<br>在第二阶段初出茅庐的领导者面临的最大挑战之一就是，调整领导风格，从命令与控制转变为影响与感召。<br>你需要学习如何调整巡航高度，当一架俯冲轰炸机。<br>随说：怎么影响和感召呢？</p><p>给初任管理者的6条建议</p><ul><li>你的仪容、态度和举止正受到高度的关注和广泛的效仿。员工们会比过去更加仔细地观察你，寻找蛛丝马迹来判断自己的表现如何。从今天开始，无论你表现出快乐、压力、自信、愤恨、失望的情绪，还是处于危机中的状态，员工们都会察觉你发出的信号，并据此调节他们自己的态度和行为。所以，请仔细思考你想要传达的信号。</li><li>一旦你确定了某个愿景，就应该简洁地表达出来，并且不停地重复重复再重复。人们很容易过高地估计一个组织消化愿景和战斗口号的能力。你需要寻找一些简单明了的词语，表达出你希望组织向哪个基本方向前进。它们只要在方向上正确，并令人牢记于心就够了，不必完美无缺。你以后可以将“新闻”和变化融入长期的信念和愿景之中。每次遇到机会时都要重复这种想法：“这种情况体现了我们深层的信念，那就是X很重要。”你可能觉得已经做得够多了，但其实还不够。要知道，每年的员工流动率高达20%左右，他们为什么还要记得去年的事情呢？</li><li>早早决定让谁上船。每个领导者都需要一支小型核心团队，由那些能够高质量完成任务的亲密同事组成。选择这样一支团队往往是领导者最重要的任务。虽然你并不需要立刻为每个位子找到对的人，但还是得尽早决定让谁上你这条船。不要选择和你相似的人，寻找那些能够增强你的长板和弥补你短板的人，并一对一地去了解这些参与者和候选人。探究一下他们的目标、信仰和关注点，看看它们与你的目标、信仰和关注点是否契合。</li><li>每一个有意义的商业问题都是少数人在一间安静的小会议室里解决的。观点之间的对抗是有益的，但要确保它发生在恰当的讨论中。来回对骂的电子邮件要尽量避免。有争议的问题最好是在较小的团队中解决，而不要放到严肃的大型公开会议上讨论。即便你是老板，也要明确地表现出你对其他人观点的理解。用你的耳朵来领导大家，不要只靠嘴巴。理清问题的前因后果，用自己的信念加以评判，最后做出决定。</li><li>你要表现得像个被人信赖的解答者，而不是高高在上的老板。你的办公室装潢并不重要，重要的是你对组织的影响力。信念、诚信和公正会给你带来力量。让消息在组织中透明地传播，告诉大家好消息和坏消息，帮助他们正确看待这些信息对组织的影响。证明你会对这些事情全力以赴，证明你关心它们，不会撒手不管。</li><li>你并不是无所不知。没人会无所不知，征询他人的意见才是明智之举。无知并不可怕，只要你能发现这一点，并做出适当的决定就行了。你可以先在特定阶段做个决定，而不必一锤定音。</li></ul><p>你可以问自己以下4个我们在第5章中已经学到的关键的职业价值评估问题。</p><ul><li>学习：我是否正在积累有助于成长的新的技能、经验和关系？</li><li>影响力：我是否正在改变个人、公司，甚至整个社会？</li><li>乐趣：我的职业总体上算不算我生活中正能量和乐趣的来源？</li><li>奖励：我是否正在积累经济价值？</li></ul><p>我与两名经验丰富的招聘人员聊过，他们在一家全球领先的招聘公司的工作经验加起来有42年之久，经手过数千名顶级高管。<br>总结下来，他们认为落选者与顶级首席执行官候选人之间的差距就在于下面这几点。</p><ol><li>诚实和契合(个人价值与公司契合)</li><li>智力上的好奇与敏捷</li><li>提升业务业绩的历史记录</li><li>真实、自我意识及平衡</li><li>热情和活力</li></ol><p>顶尖的准首席执行官能够将各种问题综合、联系起来。<br>他们在工作之外拥有有趣和丰富的生活。<br>他们读书看报，深入行业核心，提的问题很有水平。</p><p>在某些职位上，仅仅是让业务稳定就是一项很不简单的成就了。<br>而在一些快速发展的行业里，一般水平的增长反而是低于标准的。</p><p>有弱点、不完美都是很正常的。<br>好的候选人对于他们的成就有着清晰客观的认识，并会吸取教训，从而进一步改善。<br>如果对于成功和失败没有足够的自我反省和反思，就会被扣分了。<br>太多的“我”、太少的“团队”会让候选人的吸引力降低，而不是提高。<br>随说：上面第四条的说明</p><p>让自己置身于能够配合和弥补你短板的人群之中吧。将你的能量倾注到长板上，从而更进一步。</p><p>初任管理者的建议1：时刻注意你的仪容、态度和举止。<br>初任管理者的建议2：简洁地表达你的愿景，并且不停地重复。<br>初任管理者的建议3：尽快选好团队成员。<br>初任管理者的建议4：每一个有意义的商业问题最好能在较小的团队中解决。<br>初任管理者的建议5：表现得像个被人信赖的解答者。<br>初任管理者的建议6：你并不需要无所不知，而是应该多多找人咨询。</p><p>对大部分人的生活而言，工作是满足感和幸福感的源泉。<br>许多人认为，停止工作会产生一种失落感，即失去了身份、价值和贡献的感觉。<br>贝特森将 50 ～ 85 岁的时期视为一个崭新的机会时代。</p><p>对于自己的升职之路，蒂姆是这样评价的：我从来没有喘息的机会。如果你真的擅长某件事情，他们就会给你更多的责任和工作，而不是更少。公司要看到的不是顺从，而是业绩。要想让你的老板和公司取得成功，除了努力工作，别无他法。</p><p>由于注重帮助他人，不管对象是宝洁的同事，还是在志愿者工作中的服务对象，所以蒂姆在他的工作中创造了更多满足感，这令他成为一个更幸福、更善良的人。<br>对他而言，退休让他有机会将更多的时间投入到帮助他人之中，而这正是他乐意做的。回馈的感觉很棒。<br>我能帮助改善社区中不那么幸运的人的生活，这让我感到自豪。</p><p>大约4年前的一天，我那优秀而有创造力的同事简·莱特（Jan Leth）到我的办公室来讨论“他的未来规划”。他将一张简略的饼图放在桌上：<br>钓鱼：32%；<br>绘画：17%；<br>皮划艇：20%；<br>园艺：21%；<br>担任布赖恩的顾问：最多10%。<br>在将近40年的紧张而忙碌的工作之后，简通过这种方法告诉我，他准备在6个月内搬到缅因州，开启人生的新篇章。</p><p>对大多数人而言，能减速就最好只减速，不要完全停下来。<br>这条建议还有后半句：“下车的时候音乐不能停。<br>也就是说，要在你过去这些年建立起来的乐趣和声誉还没失效之前行动。<br>随说：需要有过渡</p><p>我认为，保持关联性对于处于职业生涯后期的人来说是一项至关重要的任务。<br>你每天是如何让自己的技能和身处的环境与时俱进的呢？在这个方面，我有过自己的经验教训。</p><p>当我觉得自己积累了足够多的素材时，就写文章、做讲座。<br>我主动寻求反向导师，每周至少会为公司里的明日之星团队提供两次咨询服务，一方面我向他们提供建议，另一方面尽可能多地寻求他们的观点和看法。<br>我运用领英和“一万杯咖啡”这样的导师平台来提供咨询服务，同时也倾听年轻人在行业热点上的声音。<br>随说：双向学习</p><p>尽管薪水可能比不上全盛时期的水准，但这些美好的职业生涯篇章会为你带来其他强有力的回报：掌声、敬意、个人成就感和改变世界的满足感。<br>在传递火炬并点燃新的火焰时享受这深深的喜悦吧。</p><p>多年以来，职业女性都得不到关于如何兼顾孩子和工作的建议。女性害怕生孩子，尤其是在职业生涯早期，她们一定要等职业生涯稳定下来才愿意行动。<br>每个人都在担心，可是没有人知道答案。拥有孩子在职场上就等于不够卖力。<br>男人们会认为你已经退出了‘向上’的电梯，而且许多女性也同样轻视妈妈们的能力。</p><p>正如珍妮特所指出的那样：“幸福工作的父母会培养出幸福的孩子，这将形成一个良性循环。</p><p>他特别中意干脆而确定的电子邮件：我喜欢能下决定的企业文化。这场会议真的有必要吗？在需要开和开了更好之间是有区别的。</p><p>保罗说：“压力很大的父母会把它传递给孩子。面对一份像经营创业公司这样劳心费力的工作，大起大落的经历实在太多了。”<br>这就是贝里夫妇为家庭时间划出明确界限，从而为生活留出一点空间和平静的原因之一。<br>在晚上6—9点，他们一门心思扑在孩子身上，拒绝一切工作电话或电子邮件。<br>这家人每天晚上都有一小时的时间专门用来一起读书。<br>尽管父母双方都身处技术行业，但贝里家的孩子们却几乎不碰数码产品。<br>没有智能手机，没有电视。<br>虽然在读书时可以用 Kindle，但当贝里一家出门时，他们更喜欢用纸和蜡笔消磨时间，而不是 iPad。<br>随说：这是相当好的家庭环境了，几乎不用电子产品</p><p>专家们都说，如果在大后方没有有效的支援体系，你是成不了大事的。<br>支援体系的选择是个见仁见智的决定，支持可以来自配偶、伙伴、家庭成员、托儿所、保姆或各种选择的组合。</p><p>一位管理着 20,000 人规模的公司的在职妈妈称：你的保姆可能是你这辈子最重要的员工了，向他付多少钱、说多少次感谢都不为过。如果后院起火，你的工作就一定会受到影响。</p><p>马特说，“我为员工提供自由和灵活度，换取良好的业绩和责任感。”到目前为止，这一招的效果非常好。<br>随说：回归生，公司以人才为先。前进之路基金会</p><p>成功回归的4个关键</p><ol><li>重新包装你的技能</li><li>重新组织你的经验</li><li>重新链接职业生态系统</li><li>重新建立你的自信</li></ol><p>研究一下你想要重新进入的行业的未来愿景，订阅一些潮流的行业出版物和博客，将你的技能、智慧和经验与雇主的情况及他们的目标适当地加以结合。<br>只有当你的过去能够帮助潜在雇主取得成功时，它才有意义。</p><p>因此，做好功课，了解这个行业；<br>看看首席执行官的演讲；<br>了解行业分析师的观点；<br>阅读每家上市公司都会在网上公布的财务年报。<br>就算不是金融高手，这样做了之后，你就能看懂这家公司是如何看待自身和未来发展的了。</p><p>她生怕自己的方法和技术知识，甚至包括她使用的演示文档，会让她变成一个老古董。<br>她能融入其中吗？经过一个焦头烂额的起步阶段，她的身边终于开始聚集一些求知若渴的年轻人，他们共同组成了一种双向导师的关系。<br>她学到了新的方法和技术，不过她也发现，这些新时代的朋友也都真心地感谢她的知识和智慧。</p><p>卡尔建议：“你至少需要对两个国家有充分的认识，比如你的祖国和另一个国家。<br>那些有意识地到广阔的世界中去探索，以此来扩展眼界的人才能在职场中蓬勃发展。</p><p>他父亲是一名企业家，在美国和法国都有业务。<br>他父亲很支持他：在你的一生中，要做些有意思的事情，不要纯粹为了生意而活。</p><p>公司当时正在进行全球扩张，去国外工作看起来拥有光明的前途。<br>于是，蒂姆和妻子帕特（Pat）决定将这个新婚家庭搬到英国去。<br>后来，蒂姆在那里大显身手，带领奄奄一息的宝洁英国的健康与美容部门实现逆转。<br>跨国工作的好处在于，它们会让你离开舒适圈。<br>最重要的是，你能学会信赖自己的团队，因为你已经失去平常的人脉关系网和联系人了。</p><p>接手一团混乱的垃圾并不是一件坏事。它会迫使你去学习和用尽全力。<br>你会搞清楚能信任谁。因为冒着一无所有的风险，所以你会学着全情投入。</p><p>应对职场危机的第一步应该是清晰客观地认识问题。<br>这是一个不可避免的事件、一个认知上的问题，还是业绩上的问题？<br>如果这的确是一个不可避免的事件或单纯的坏运气，比如说你的公司意外地被收购了，那你就得尽快恢复过来。</p><p>找出认知的偏差，让别人清楚地认识到，真正的你要比他们认为的更好。</p><p>如果有人升职的速度比你快，那么不妨默默地找出是哪些技能让老板做出了这样的决定。<br>然后积攒职场燃料，让自己有资格赢得下一次加薪、升职或新的好工作。<br>随说：找不同级别优秀的人，看有什么值得学习的</p><p>如果想得远一点，并时刻关注你的公司、你的行业和你自己的业绩的变化，就可以时常避免遭到突然袭击。<br>如果你发现自己的行业、公司或职位已陷入了危机，那么就需要主动采取行动，准备好一份备用方案。<br>所以，你需要培养一些能让自己免疫风险的技能和关系，在当前的环境之外留一些可选之路。<br>随说：提前想好退路</p><p>如果你被开除了或被排挤了，就可以以“4个重新”为基础，加速回归正确的轨道。</p><ul><li>重新组织：你的经验，让它与未来而不是过去密切关联。</li><li>重新包装：老旧过时或有所欠缺的技能。在新的职业环境中，你不可能伪装自己的职场动力。</li><li>重新连接：职业生态系统。也许你需要与联系人、专家团、关键同事和支持者建立新的关系来推动自己前进。</li><li>重新建立自信：与那些支持你、理解你的人交谈，反思你的长板和在过去这些年里完成的特殊贡献。勇敢去闯。</li></ul><p>作家兼伦敦大学教授朱尔斯·戈达德博士（Dr. Jules Goddard）提供了另外一条有价值的建议：在面对严重的职场危机时，要回归人性。</p><p>健康的自信心是好的，虚张声势、否认一切和痴心妄想却都是毁灭性的。<br>脆弱是过度保护的恶果，逆境和压力是有益的。戈达德指出，在太空的失重环境下，我们的骨骼失去了压力，于是就会变得脆弱。<br>你的自信心必须建立在有市场竞争力的东西上面。<br>在职业生涯中，你时常会不得不偏离航线或干脆后退才能继续前进。<br>因此，在遭遇职场危机时，请将骄傲放在一边，它会碍事的。</p><p>我不停地参与各种更高级别的项目，周围的团队都欣赏我的干劲，帮助我解决问题。<br>随说：让别人看到你的态度很重要</p><p>《协作战略》</p><p>她利用压力和逆境构建起自己的免疫系统，从每一次挫折中学习。<br>尼罗弗为自己的行为负责，反省自己的行为是否弊大于利，并采取必要的措施来调整现状。<br>随说：反省自己</p><p>职业运动员通常都将绝大部分时间投入到运动能力的磨炼中，至于其他方面，例如社交、兴趣爱好、金钱和商业管理，都被他们忽略了。<br>对安东尼而言，帮助客户重新发现他们的热情所在和兴趣点是至关重要的第一步。<br>他说：我鼓励人们在尝试寻找甜蜜区时做一个简单的练习。<br>他们要寻找三样东西：你擅长什么，你热爱什么，以及这个世界需要什么？<br>随说：这个世界需要什么？</p><p>遗憾的是，许多职业运动员最后都成了穷困潦倒的无业游民。<br>据《纽约时报》估计，有 60% 的美国篮球职业联赛的球员在离开球场5年后遭遇了破产，而美国橄榄球联盟球员的这个时间更是缩短到区区 2 年。<br>随说：没有调整好心态？</p><p>过了一年左右，时任纽约尼克斯队总经理的唐尼·沃尔什（Donnie Walsh）找到阿兰，<br>抛出了一个诱人的邀请：到尼克斯队学习体育管理。<br>阿兰将他出众的好奇心投入到这份工作中。“我一直从我尊敬的人那里求取经验，”<br>他观察、学习并提出问题，“在物色人才、运营和管理方面有太多东西要学，而且这些在球场上是根本接触不到的。”<br>阿兰后来逐步成为发展联盟中的韦斯切斯特尼克斯队的总经理和美国篮球职业联赛的纽约尼克斯队的副总经理。<br>随说：好奇心很重要</p><p>在被问到如何管理好所有的事务时，阿兰的解释是，自律和核心价值观带领他度过每一周，并帮助他决定如何花费时间。<br>阿兰的生活伴随着一系列信条，包括有信仰、正直、牺牲精神、领导力和创造遗产，而且他有着实践经验的支撑。</p><p>关于领导力，休斯敦指出：你可以从很多不同的方面来表现领导力，而不一定得一直当队长。<br>你需要看清楚自己的角色，没必要所有事情都亲力亲为。<br>阿兰很感谢他的妻子和家人的支持，他也知道自己需要划清界限。<br>我在学着说不。有些事情是我需要做的，有些事情可以交给别人来牵头。<br>我也已经尽可能地减少出差的次数了。</p><p>弄清楚你的使命。你热爱什么？</p><p>利用好奇和探索的武器培养技能和经验，建立起能抵挡不可避免的挫折的免疫系统；<br>不断寻找自己的理想，如果不知道什么才是重要的，那么就回归人性；<br>确保你的信心是有根据的，如果你的失败并不主要源于坏运气，那么就得采取行动，找出欠缺的关系或技能；<br>不要让骄傲阻挡了重获新生的道路；<br>你可能需要退一步才能海阔天空；<br>坚持自己的核心价值观和真正的自我。</p><p>职业生涯的未来，需要考虑的问题：</p><ul><li>我会被机器取代吗？</li><li>我未来会在哪里找工作，又如何找工作？</li><li>我该把时间用在哪里？</li><li>我会把钱花光吗？</li><li>工作如何能让我更快乐？</li></ul><p>英国广播公司（BBC）2015年9月发布了一份报告，这份报告将人与机器对抗的辩论推上了风口浪尖。<br>报告说：“关于机器是否会代替人类的工作的辩论已经不再局限于学术层面了。<br>波士顿咨询公司（Boston Consulting Group）预计，到2025年，高达四分之一的工作将会被智能软件或机器人取代。<br>随说：2026 年了，目前看好像没有？</p><p>最脆弱的工作大部分本质上都是机械性和重复性的，比如从事写报告、做表格等重复性工作的办公室职员就很容易被软件取代，工厂工人也因为更加灵巧的机器人被开发出来而变得越来越危险。</p><p>相比之下，如果重复性和程序性的工作正在没落，那么要求员工用自己的大脑思考，<br>并得出有创造力的原创想法的职位，就会在自动化面前拥有相当大的优势了。<br>这对艺术家、设计师或工程师而言是个好消息。<br>随说：创造类？</p><p>根据研究发现，需要高度的社交智慧和谈判技能的工作，例如管理岗位，受到来自机器的威胁也要小得多。<br>按照他们的说法，担任首席执行官的我被替代的风险很低，只有 9%，不过我也没计划要在这张办公桌后面坐到 2035 年。</p><p>克莱尔·凯恩·米勒（Claire Cain Miller）在《纽约时报》上写道：“合作能力、做事灵活、有同理心，这样的技能在现代工作中的重要性已越来越强。最新的研究表明，需要强大社交技能的职位在 1980 年后的增长要比其他职位更加突出。在2000年之后，工资保持持续增长的少数职位都既需要认知技能，也需要社交技能……需要社交技能工作在1980——2012年之间增加了24%，而建立在重复性劳动之上的工作，如垃圾收集、某些分析工作，则有所降低。<br>随说：受到比较大打击的岗位上那些不需要社交的。那么怎么定义社交？</p><p>不过有趣的是，人类和机器之间需要互动。<br>即使是在重复性工作中，人类的技能也扮演着重要的角色，人类需要教育机器、检查输出结果以确保准确无误，以及测试新的假设。<br>而在创造性世界里，运用机器来辅助创作的机会也越来越多。<br>随说：需要与机器保持协作</p><p>我鼓励大家不断寻找自己的归属，最大的危险往往潜伏在极端情况中。<br>这个世界上有很多好的职业，你需要为此建立技能集合，做好充足的准备，<br>这些技能包括在以下几方面的能力之中：发明、评判、建立人际信任、社交、教育机器和创造测试假说。</p><p>麻省理工学院的经济学家戴维·奥特尔（David Autor）说：“如果一项技能中只有技术，那就很有可能会被自动化。而如果它只需要同理心或灵活性，那么可以胜任的人也是要多少有多少，所以这样的职位的薪水也不会很高。只有将两者结合起来才是有竞争力的。<br>随说：同理心&#x2F;灵活性 + 技术</p><p>作家兼哈佛大学教育和经济学副教授戴维·戴明（David Deming）观察发现，我们的教育体制中唯一与未来工作的需要相匹配的部分可能只有幼儿园。<br>我们在那里开始学习分享、协商、合作和创造。<br>随说：幼儿园这个比喻好</p><p>人们希望在生活和工作中利用数字化优势，对此能够提供帮助的技能和机遇越来越受到欢迎。</p><p>培养情商、创造力、协作能力和建立信任关系的技能，这些似乎的确是未来职业生涯的明智赌注。</p><p>时间是人生的唯一货币，应该将货币投资到技能之上。</p><p>一旦我们将技能当作卖点，就必须让它与时俱进。<br>因为工作时间更加灵活，而且往往可以远程操作，所以就会有大量多余的时间，自由职业者所做的工作就可以带来有趣的事情和互动。<br>我们都应该认真思考自己的职业长尾，考虑如何在正常退休之后的岁月里找到目标，保持灵活性和关联性，并且有稳定的收入。</p><p>《幸福有方法》</p><p>《幸福有方法》的核心前提是，我们的幸福程度可以由三个主要因素决定：在一个人的幸福中，有50%是基因决定的，10%是由生活环境决定的，而剩下的40%是由自愿、主动的行为决定的。</p><p>《幸福有方法》大致描绘了12种“基于证据、得到科学研究支持的提高幸福感的策略”。<br>其中包括：</p><ul><li>表达感恩</li><li>培养乐观的心态</li><li>避免思虑过度和社会攀比</li><li>多行善事</li><li>维护人际关系</li><li>发展合作的策略</li><li>学会原谅</li><li>增加心流体验</li><li>享受生活的乐趣</li><li>努力实现目标</li><li>信仰宗教，寻找精神寄托</li><li>关注身体健康</li></ul><p>在《当下的幸福》（Flow： The Psychology of Optimal Experience）中，作者将心流描述为：“一个人的技能足以应付眼前挑战的一种感觉。此时，人的精力高度集中，以至于没有任何多余的注意力可以用来思考无关的事情或为其他问题忧心。这个人的自我意识消失了，而对时间的感觉也会发生扭曲。</p><p>科学家们声称，制订清晰的计划确实会让人更幸福。<br>这对于如何规划职业生涯有着很重要的意义。<br>与其思前想后，不如采取行动。<br>将你能影响的东西都牢牢控制住，每年至少花一整天的时间反省和制订职业生涯的策略，进行职场盘点，尝试一些假设，确立目标，不断建立和更新你的职场燃料，监控你的进度。</p><p>在职场生活中，我们都需要感恩。作<br>为员工，我们应该感谢那些给我们机会、任务，并让我们加薪、升职和成长的人，也应该感谢那些与我们分享智慧的人。<br>而作为老板，我们也必须感谢那些与我们合作、为我们工作的人，因为他们为我们献出了才华、精力、热情和技能。</p><p>《深潜：10步重塑你的个人品牌》<br>《优秀到不能被忽视》<br>《如何学习》<br>《精要主义》</p>]]>
    </content>
    <id>https://hisen.me/20260628-The-Long-View/</id>
    <link href="https://hisen.me/20260628-The-Long-View/"/>
    <published>2026-06-28T11:50:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-缘起"><a href="#1-缘起" class="headerlink" title="1. 缘起"></a>1. 缘起</h1><p>在看完一系列的电视剧之后，特别是《夜色正浓》里面李东明以及同事对竞选总监的张玫进行的各种辅导。<br>我在想为什么会没相关的书籍呢？然后想到某博主说的一段话：</p>
<blockquote>
<p>“社会经验”特别重要又难以获得。你读书刻苦一点，一年能完成四年的学业。<br>但“社会经验”没办法这样学习，活一年就只能获得一年的“社会经验”。<br>如果有本专门介绍“社会经验”的书自然就不同了。然而根据社会经验，这样的书不可能出版。</p>
</blockquote>
<p>我想原因大概是：</p>
<ul>
<li>博弈论悖论：社会经验一旦公开，就会立刻失效；</li>
<li>上下文悖论：社会经验具有极强的“场景高敏感性”；</li>
<li>既得利益悖论：真正的顶层经验，违背“道德正确”；<ul>
<li>显性规则（明线）：道德、法律、大道理、企业文化。这些是用来维持社会秩序、讲给所有人听的。</li>
<li>隐性规则（暗线）：利益交换、权力结构、人性的弱点、圈子文化。这些才是真正推动事情落地的杠杆。</li>
</ul>
</li>
<li>体验悖论：没有经历过的人，根本看不懂；</li>
</ul>
<h1 id="2-重点摘抄"><a href="#2-重点摘抄" class="headerlink" title="2. 重点摘抄"></a>2. 重点摘抄</h1><p>职业生涯大概分为三段，每段 15 年；<br>第一阶段：加添燃料，强势开局。<br>第二阶段：聚焦长板，达到高点。<br>第三阶段：优化长尾，持续发挥影响力。</p>]]>
    </summary>
    <title>《远见：如何规划职业生涯3大阶段》读后感</title>
    <updated>2026-09-13T14:37:46.938Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Growth" scheme="https://hisen.me/categories/growth/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <content>
      <![CDATA[<h1 id="1-人性的算法：从《理想之城》看复杂组织的重构与宿命"><a href="#1-人性的算法：从《理想之城》看复杂组织的重构与宿命" class="headerlink" title="1. 人性的算法：从《理想之城》看复杂组织的重构与宿命"></a>1. 人性的算法：从《理想之城》看复杂组织的重构与宿命</h1><p>看过《理想之城》的人，大都会被赵显坤和夏明的“神仙打架”爽到。<br>这部剧最硬核的地方，就在于它没有把职场斗争降智为“小人打小报告”的低级内耗，<br>而是扒开了职场的表象，展现了<strong>顶级高手如何利用“系统漏洞、人性贪婪和利益博弈”来做局</strong>。</p><p>如果把赢海集团看作一个庞大、臃肿、布满技术债的历史遗留系统，<br>那么赵显坤（董事长）和夏明（主任经济师）这两位顶级架构师的“走一步、看三步”，<br>本质上都在运行一套复杂组织架构下的“终极博弈算法”。</p><h1 id="2-核心算法：不看“对错”，只算“利益链”"><a href="#2-核心算法：不看“对错”，只算“利益链”" class="headerlink" title="2. 核心算法：不看“对错”，只算“利益链”"></a>2. 核心算法：不看“对错”，只算“利益链”</h1><p>普通人看职场，看的是“是非、对错与情绪”；而真正的高手看组织，看的是“资产、负债与代理人”。</p><span id="more"></span><h2 id="2-1-夏明的“逆向工程”思维"><a href="#2-1-夏明的“逆向工程”思维" class="headerlink" title="2.1 夏明的“逆向工程”思维"></a>2.1 夏明的“逆向工程”思维</h2><p>夏明那句“每一张造价表，背后都是一张关系网”，是典型的系统依赖性分析。<br>面对拖欠工程款的死局，普通造价师只会机械地催款，夏明却将其做成了“杠杆”。<br>他故意让天科陷入资金链断裂的假象，甚至激化大风厂的矛盾，用一场精密的“逆向工程”，把皮球踢回给集团总部。<br>他算准了在危机面前每个节点的应激反应，最终逼迫集团放权。<br><strong>他要的不是几百万的应收款，而是天科独立发展的系统吞吐量。</strong></p><h2 id="2-2-赵显坤的“全局重构”战略"><a href="#2-2-赵显坤的“全局重构”战略" class="headerlink" title="2.2 赵显坤的“全局重构”战略"></a>2.2 赵显坤的“全局重构”战略</h2><p>作为百亿赢海的掌门人，赵显坤面对的是“元老抱团，尾大不掉”的系统性危机。<br>他的破局手段极其宏大——将纯粹、毫无背景的苏筱作为一把锋利的“刀”，直接插进集团核心。<br>赵显坤明知这会引发元老院的疯狂反扑，而这恰恰是他挖好的深坑。他需要苏筱去当这个“破局者”来搅浑死水。<br>当汪明宇等元老为了对付苏筱而打破常规、露出马脚时，他才能顺理成章地以“集团利益”为名，对老兄弟们完成定向降维和资产重组。</p><h2 id="2-3-破局手腕：善用“阳谋”，借力打力"><a href="#2-3-破局手腕：善用“阳谋”，借力打力" class="headerlink" title="2.3 破局手腕：善用“阳谋”，借力打力"></a>2.3 破局手腕：善用“阳谋”，借力打力</h2><p>最高明的做局，从来不用阴谋，而是用“阳谋”——把诱饵明明白白地摆在桌面上，利用你自身的贪婪或恐惧，推动你主动跳下去。</p><ul><li><strong>制造“囚徒困境”：</strong> 面对同气连枝的五家子公司，赵显坤推出“合并同类项”计划，却只放出两个主导权名额。原本牢固的利益同盟（汪炀、黄礼林等）瞬间为了自保而互相拆台。这就像在技术管理中，无需亲自去裁撤低效部门，只需重新分配核心资源和 KPI，系统内部自然会发生自我暴露与分化。</li><li><strong>信息不对称与流控：</strong> 在天科濒临被吞并的绝绝境中，夏明利用一份真假难辨的审计报告，在集团、银行、分包商之间玩起了高频的“信息套利”。他精准拿捏了高进的胆怯与徐知平的圆滑，让每个人都以为做出了最利己的选择，而多方博弈的并发结果，恰好是天科的死里逃生。</li></ul><h1 id="3-机制反思：全员持股是救赎还是“内存泄漏”？"><a href="#3-机制反思：全员持股是救赎还是“内存泄漏”？" class="headerlink" title="3. 机制反思：全员持股是救赎还是“内存泄漏”？"></a>3. 机制反思：全员持股是救赎还是“内存泄漏”？</h1><p>剧中后半段以及同类高分剧《人民的名义》中都提到了一个终极愿景——全员持股。但这真的是完美的解药吗？<br>从公司治理与激励机制的“系统架构”来看，静态的、一劳永逸的“全员持股”在现实中往往是一场灾难。如果公司持续发展、规模不断扩大，它将面临两大致命的系统缺陷：</p><ol><li><strong>增量稀释与边际递减：</strong> 随着团队从 100 人扩张到 10000 人，为了激励新员工，股份必须不断增发，老员工的比例必然下降。更糟糕的是，当新进入的骨干分到的股份被稀释到 $0.00001%$ 时，它在心理上就彻底失去了“利益解耦”的作用，员工会再次回归“打工人”的旁观者心态。</li><li><strong>“僵尸节点”分食红利：</strong> 如赢海集团的汪明宇、黄礼林等元老，后期的贡献早已跟不上发展，却因为早期的“一次分配”而永久占满了股权坑位，导致新来的技术与管理骨干（如苏筱）拿不到应有的激励。</li></ol><p>现实中如华为等能够跑通十几万人持股的庞大系统，靠的绝不是纯粹的情怀，而是引入了硬核的“垃圾回收（GC）与动态流控”机制：</p><ul><li><strong>虚拟股（Virtual Shares）：</strong> 剥离所有权与投票权，仅对齐分红权，确保最高决策权的绝对集中。</li><li><strong>强制回购（Buyback）：</strong> 践行“人在股在，人走股留”的动态循环。一旦离职，股份立刻按净资产价格回购并释放回公用池（Pool），彻底解决老员工对新红利的“内存泄漏”。</li><li><strong>动态评级：</strong> 股份配额随着个人绩效（OKR&#x2F;KPI）动态调整，用流量控制对抗绝对的静止。</li></ul><h1 id="4-结语：把组织当成系统去设计"><a href="#4-结语：把组织当成系统去设计" class="headerlink" title="4. 结语：把组织当成系统去设计"></a>4. 结语：把组织当成系统去设计</h1><p>《理想之城》之所以能引发深思，是因为它揭示了最高级的管理学：<strong>不要每天去纠结具体的 Bug 和员工的摩擦，而要像赵显坤和夏明一样，把组织当成系统去设计，把利益当成代码去解耦，把人性当成规则去运行。</strong></p><p>当能够跳出局部，俯瞰整个盘根错节的利益网络与依赖关系时，那些看似腹黑的“挖坑”与布局，不过是顺应组织演进历史规律的借势而为。<br>在这座理想之城里，真正的赢家，永远是那些既懂底层人性编码、又懂顶层架构设计的“终极弄潮儿”。</p>]]>
    </content>
    <id>https://hisen.me/20260628-lixiangzhicheng/</id>
    <link href="https://hisen.me/20260628-lixiangzhicheng/"/>
    <published>2026-06-28T08:52:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-人性的算法：从《理想之城》看复杂组织的重构与宿命"><a href="#1-人性的算法：从《理想之城》看复杂组织的重构与宿命" class="headerlink" title="1. 人性的算法：从《理想之城》看复杂组织的重构与宿命"></a>1. 人性的算法：从《理想之城》看复杂组织的重构与宿命</h1><p>看过《理想之城》的人，大都会被赵显坤和夏明的“神仙打架”爽到。<br>这部剧最硬核的地方，就在于它没有把职场斗争降智为“小人打小报告”的低级内耗，<br>而是扒开了职场的表象，展现了<strong>顶级高手如何利用“系统漏洞、人性贪婪和利益博弈”来做局</strong>。</p>
<p>如果把赢海集团看作一个庞大、臃肿、布满技术债的历史遗留系统，<br>那么赵显坤（董事长）和夏明（主任经济师）这两位顶级架构师的“走一步、看三步”，<br>本质上都在运行一套复杂组织架构下的“终极博弈算法”。</p>
<h1 id="2-核心算法：不看“对错”，只算“利益链”"><a href="#2-核心算法：不看“对错”，只算“利益链”" class="headerlink" title="2. 核心算法：不看“对错”，只算“利益链”"></a>2. 核心算法：不看“对错”，只算“利益链”</h1><p>普通人看职场，看的是“是非、对错与情绪”；而真正的高手看组织，看的是“资产、负债与代理人”。</p>]]>
    </summary>
    <title>《理想之城》观后感</title>
    <updated>2026-06-28T13:14:14.420Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Growth" scheme="https://hisen.me/categories/growth/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <content>
      <![CDATA[<p>在通俗大众的眼中，《五十度灰》（Fifty Shades of Grey）三部曲是一套充斥着豪车、直升机、百亿霸总与限制级画面的都市罗曼史。<br>然而，若撇开这些博人眼球的商业包装，将其放在现代心理学、两性博弈与人格模型的显微镜下，这其实是一个极其硬核的“双人心理沙盘演练”。</p><p>整个三部曲的底层故事逻辑，讲述的并不是一个单纯的“总裁爱上灰姑娘”的童话，<br>而是一个关于“两个不同人格模型在权力、私欲与控制的博弈中，最终完成反向重塑与精神救赎”的现代寓言。</p><h1 id="1-第一部《五十度灰》：权力的初次交锋与底线的试探"><a href="#1-第一部《五十度灰》：权力的初次交锋与底线的试探" class="headerlink" title="1. 第一部《五十度灰》：权力的初次交锋与底线的试探"></a>1. 第一部《五十度灰》：权力的初次交锋与底线的试探</h1><h2 id="1-1-莫名的开局与失控的序幕"><a href="#1-1-莫名的开局与失控的序幕" class="headerlink" title="1.1 莫名的开局与失控的序幕"></a>1.1 莫名的开局与失控的序幕</h2><p>故事的开篇看似荒诞且充满巧合：文学系女大学生安娜（Anastasia Steele）顶替生病的闺蜜，<br>去采访年轻英俊的百亿创投巨头克里斯蒂安·格雷（Christian Grey）。<br>安娜自幼沉浸在英国文学的世界里，精神世界丰富且对周围平庸的追求者不屑一顾。<br>这种超然的纯洁与固执，瞬间激发了格雷恐怖的占有欲。</p><span id="more"></span><p>然而，当格雷将安娜带入他的“红房子”，<br>并拿出一份事无巨细、规定了饮食起居及绝对服从规矩的 BDSM 合同（Dom&#x2F;Sub 契约）时，<br>两性的博弈正式从“浪漫追求”演变为“权力争夺”。</p><h1 id="1-2-私欲的工具化与-Sub-的终极权力"><a href="#1-2-私欲的工具化与-Sub-的终极权力" class="headerlink" title="1.2 私欲的工具化与 Sub 的终极权力"></a>1.2 私欲的工具化与 Sub 的终极权力</h1><p>在这一阶段，格雷将内心的“控制欲”伪装在精英外表和商业合同之下。<br>由于童年遭受生母抛弃和虐待的创伤，格雷极度缺乏安全感，他需要通过事事在握的“确定性”来维持心理防线。<br>他把安娜当作一个满足自身心理缺陷的“完美客体（工具）”，试图用冷酷的规矩拒绝发生真正平等、有温度的情感连接。</p><p>但第一部的结尾给出了极高级的反转：当格雷在红房子里用皮带跨越情感边界地抽打了安娜 6 下、单方面宣泄控制欲时，安娜看清了这场游戏背后并非爱意，而是冷酷与扭曲。她动用了身为 Sub 的终极权力——<strong>拒绝、呼唤其真名（拒绝物化）并果断离场</strong>。这一走，直接打破了格雷“掌控一切”的幻觉，将这位不可一世的支配者推向了精神崩溃的边缘。</p><p>#2. 第二部《五十度飞》：规则的彻底重组与反客为主</p><h2 id="2-1-攻守易势的心理依附"><a href="#2-1-攻守易势的心理依附" class="headerlink" title="2.1 攻守易势的心理依附"></a>2.1 攻守易势的心理依附</h2><p>无法承受失去安娜之痛的格雷，被迫放下所有高高在上的姿态，卑微求和。<br>此时，安娜展现出了极强的人格底线，她重组了游戏规则，<br>提出了复合的绝对前提：<strong>“不签合同、没有规矩、不要红房子，要一场正常的、平等的恋爱。”</strong></p><p>格雷的全盘妥协，标志着两人的权力关系彻底发生了“反客为主”的倒置。<br>格雷原本高度依赖“制定规则”来获得安全感，但为了留住安娜，他必须被迫学着去“适应不确定性”。</p><h2 id="2-2-创伤重现与情绪的“反向驯服”"><a href="#2-2-创伤重现与情绪的“反向驯服”" class="headerlink" title="2.2 创伤重现与情绪的“反向驯服”"></a>2.2 创伤重现与情绪的“反向驯服”</h2><p>第二部中，格雷扭曲童年的始作俑者埃琳娜（罗宾逊太太）、以及因嫉妒企图枪杀安娜的前任 Sub 先后出现，甚至格雷本人也经历了直升机坠机的生死考验。</p><p>在这一系列危机的倒逼下，格雷在梦魇中向安娜下跪。这一幕揭示了控制狂背后的真相：<strong>他不是太强大，而是太弱小。</strong><br>安娜用她那健全的人格、稳定的情绪和无条件的爱，扮演了超越情人的“心理疗愈者”角色。<br>她剥离了格雷身上那些防御性的私欲，反向重塑了格雷的心理系统，让他明白：不需要靠支配别人，也能获得安全的爱。</p><h1 id="3-第三部《五十度自由》：人格的最终独立与高质量共生"><a href="#3-第三部《五十度自由》：人格的最终独立与高质量共生" class="headerlink" title="3. 第三部《五十度自由》：人格的最终独立与高质量共生"></a>3. 第三部《五十度自由》：人格的最终独立与高质量共生</h1><h2 id="3-1-职场、生育与控制欲的临界点"><a href="#3-1-职场、生育与控制欲的临界点" class="headerlink" title="3.1 职场、生育与控制欲的临界点"></a>3.1 职场、生育与控制欲的临界点</h2><p>两人步入婚姻后，矛盾并未绝迹，而是推向了更深层的现实维度。<br>安娜在职场上凭借专业能力快速晋升为出版社主编，她死守自己的专业阵地，甚至在改回夫姓的问题上与格雷爆发激烈冲突。<br>她用绝对的人格独立，拒绝被“格雷太太”这个符号吞噬。</p><p>冲突在安娜意外怀孕时达到顶峰。<br>格雷因为童年阴影以及对安娜“独占私欲”作祟，对胎儿产生了强烈的抗拒与自私的愤怒。<br>他愤而离家，在酒吧喝得烂醉并遇到了企图挑拨的埃琳娜。<br>虽然格雷保持了身体的忠诚并拒绝了埃琳娜，<br>但宿醉归家后，极度无能为力的他再次退行回老一套的控制手段——在红房子里粗暴地捆绑并占有了安娜，试图重新确立掌控感。</p><h2 id="3-2-致命的觉醒与红房子的终局"><a href="#3-2-致命的觉醒与红房子的终局" class="headerlink" title="3.2 致命的觉醒与红房子的终局"></a>3.2 致命的觉醒与红房子的终局</h2><p>面对格雷近乎自残式的粗暴惩罚，安娜流着泪说出了全片最具分量的一句话：</p><blockquote><p>“Christian, this is not love. You are punishing me for something I have no control over.”（这不是爱，你是在为你无法控制的事情惩罚我。）</p></blockquote><p>这句话如同一把尖刀，彻底刺破了格雷最后的心理防御，让他直面自己即将变成当年虐待他的恶魔这一事实。<br>最终，在经历前上司杰克的疯狂绑架与复仇危机时，安娜展现出惊人的孤勇，持枪反击保护了家庭。</p><p>在大结局的几年后，红房子依然存在，但它已经不再是格雷宣泄痛苦与惩罚的“精神牢笼”，<br>而是退去了冰冷的权力剥削，变成了双方在完全平等、快乐的前提下调剂生活的情趣空间。<br>草坪上，他们与两岁的儿子和即将出生的女儿共享阳光，格雷最终被驯化成了一个满眼都是家庭的温柔父亲。</p><h1 id="4-Dom-Sub-文化底层的现代解构"><a href="#4-Dom-Sub-文化底层的现代解构" class="headerlink" title="4. Dom&#x2F;Sub 文化底层的现代解构"></a>4. Dom&#x2F;Sub 文化底层的现代解构</h1><p>《五十度灰》的文本之所以能立住，是因为它无意中暗合了现代心理学与社会学对 Dom&#x2F;Sub 文化的底层逻辑解构：</p><ol><li><strong>“逃避自我”与压力卸载：</strong> 现实中社会地位越高、掌控欲越强的人（如格雷），前额叶皮层长期超载，往往越容易在私密关系中渴望让渡控制权，以此获得极致的心理减压。</li><li><strong>创伤重现与自我疗愈：</strong> 弗洛伊德式的“创伤重现”表明，小时候经历过绝对无助的人，长大后会通过扮演 Dom 或安全的 Sub，在可控的环境里战胜当年的恐惧。</li><li><strong>高浓度的化学鸡尾酒：</strong> BDSM 互动带来的痛觉与紧张，会刺激大脑分泌海量的内啡肽（带来极乐感）与催产素（建立深刻的精神纽带），其本质是一场<strong>披着不平等外衣的、最高级别的平等信任契约</strong>。</li></ol><p>真正读懂这部作品的人会明白：<br>格雷在财富与社会地位上是绝对的支配者（Dom），但在精神与情感上，他是一个随时可能碎掉的依附者（Sub）；<br>安娜表面上一无所有，但她凭借健全的人格与死守的底线，成为了这场权力博弈中真正的统治者。</p><p>安娜用了三部曲的篇幅，把一份冷酷的商业奴役合同，变成了一首有温度的家庭共生诗。<br>敢于掀翻桌子的人，才配拥有规则的制定权——这才是隐藏在豪车与欲望之下，最硬核的两性博弈逻辑。</p>]]>
    </content>
    <id>https://hisen.me/20260628-wushiduhuixilie/</id>
    <link href="https://hisen.me/20260628-wushiduhuixilie/"/>
    <published>2026-06-28T08:50:00.000Z</published>
    <summary>
      <![CDATA[<p>在通俗大众的眼中，《五十度灰》（Fifty Shades of Grey）三部曲是一套充斥着豪车、直升机、百亿霸总与限制级画面的都市罗曼史。<br>然而，若撇开这些博人眼球的商业包装，将其放在现代心理学、两性博弈与人格模型的显微镜下，这其实是一个极其硬核的“双人心理沙盘演练”。</p>
<p>整个三部曲的底层故事逻辑，讲述的并不是一个单纯的“总裁爱上灰姑娘”的童话，<br>而是一个关于“两个不同人格模型在权力、私欲与控制的博弈中，最终完成反向重塑与精神救赎”的现代寓言。</p>
<h1 id="1-第一部《五十度灰》：权力的初次交锋与底线的试探"><a href="#1-第一部《五十度灰》：权力的初次交锋与底线的试探" class="headerlink" title="1. 第一部《五十度灰》：权力的初次交锋与底线的试探"></a>1. 第一部《五十度灰》：权力的初次交锋与底线的试探</h1><h2 id="1-1-莫名的开局与失控的序幕"><a href="#1-1-莫名的开局与失控的序幕" class="headerlink" title="1.1 莫名的开局与失控的序幕"></a>1.1 莫名的开局与失控的序幕</h2><p>故事的开篇看似荒诞且充满巧合：文学系女大学生安娜（Anastasia Steele）顶替生病的闺蜜，<br>去采访年轻英俊的百亿创投巨头克里斯蒂安·格雷（Christian Grey）。<br>安娜自幼沉浸在英国文学的世界里，精神世界丰富且对周围平庸的追求者不屑一顾。<br>这种超然的纯洁与固执，瞬间激发了格雷恐怖的占有欲。</p>]]>
    </summary>
    <title>《五十度灰》系列观后感</title>
    <updated>2026-06-28T09:06:25.988Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Growth" scheme="https://hisen.me/categories/growth/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <content>
      <![CDATA[<p>激荡时代的协议升级：一个技术管理者的《大江大河》通关复盘<br>坐在现代企业的格子间里，看着分布式架构的服务器红绿闪烁，我的眼泪却数次为了几十年前的金州厂与东海荒滩而流。</p><p>《大江大河》三部曲，表面上写的是时代的洪流，但在一个技术转管理的互联网人眼里，这分明是一部硬核工程师的“组织突围与系统重构记”。<br>主角宋运辉这三十年的成长，精准地映射了我们每一个技术人从“纯粹写代码”走向“全盘做控盘”的升级阵痛。</p><h1 id="1-技术人的立命之本：永不向KPI妥协的“系统坚持”"><a href="#1-技术人的立命之本：永不向KPI妥协的“系统坚持”" class="headerlink" title="1. 技术人的立命之本：永不向KPI妥协的“系统坚持”"></a>1. 技术人的立命之本：永不向KPI妥协的“系统坚持”</h1><p>作为技术人，全剧最让我热血沸腾的，是宋运辉在面对行政压力时“不调参数降低质量”的死磕。</p><span id="more"></span><p>在快速迭代、急功近利的职场环境中，我们经常会遇到为了赶进度、保政绩（KPI），逼着技术团队“切功能、砍测试、带病上线”的荒唐命令。<br>但早期的宋运辉用工程师的底气做出了表率：代码逻辑错了一行，系统迟早要崩；设备参数降了一档，安全隐患就会永久埋下。</p><p>这种对技术底线的死守，是技术管理者不可动摇的“底层代码”。<br>宋运辉后来当了厂长，他的操作系统依然是那个坐在车间里算数据的工程师。<br>我们可以学会妥协的艺术，但永远不能出卖系统安全的灵魂。</p><h1 id="2-关系的微操：从“非黑即白”到“灰色接口的流量控制”"><a href="#2-关系的微操：从“非黑即白”到“灰色接口的流量控制”" class="headerlink" title="2. 关系的微操：从“非黑即白”到“灰色接口的流量控制”"></a>2. 关系的微操：从“非黑即白”到“灰色接口的流量控制”</h1><p>宋运辉命运的转折，始于老水在图书馆给他的那场灵魂授课，以及他出差德国后的“开眼看世界”。<br>那个曾经不懂人情世故、只会和技术死磕的刺头，开始学会了“看小猫脸色”。</p><p>这绝不是技术人的同流合污，而是高阶管理者必须具备的“流量控制与接口兼容”能力。</p><p>早期系统（金州厂）： 非黑即白，不懂政治，全靠老水当防火墙。一旦老水退休，立刻被闵厂长过河拆桥，遭遇系统锁死。</p><p>中期系统（东海厂）： 经历了程家窒息婚姻的道德绑架、经历了东海批发市场的人事拉扯。他终于意识到：人不是机器，人是有情绪、有诉求、有利益盘算的。</p><p>在鸿门宴上他果断与程家撕破脸，宣布“不让家人管工作”，不是冷血，而是首席架构师在面对严重Bug时选择的“强行切断、全面重构”。<br>他学会了用政客听得懂的语言去要预算，用国际合规的手段去跟跨国资本（洛达）对赌。<br>懂人情世故，是为了保护技术的纯粹；学会看脸色，是为了让技术方案能够拿到带宽顺利上线。</p><h1 id="3-救急不救穷：从杨巡的“甩猴子”看管理的效率法则"><a href="#3-救急不救穷：从杨巡的“甩猴子”看管理的效率法则" class="headerlink" title="3. 救急不救穷：从杨巡的“甩猴子”看管理的效率法则"></a>3. 救急不救穷：从杨巡的“甩猴子”看管理的效率法则</h1><p>全剧最让我高呼过瘾的商战名场面，莫过于杨巡在东海批发市场办公室里，轻松把“猴子”甩回给下岗工人的桥段。这简直是教科书级的管理学太极推手。</p><p>下岗潮是时代的系统性穷困，靠个人的资本去“救穷”是个无底洞，只会引发内存泄漏。杨巡通过：</p><p>共情拉平： 卸下对方防备；</p><p>风险转移： 厘清法理边界；</p><p>精准救急： 提供靠劳动活命的生存接口；</p><p>完璧归赵： 把不干活就没饭吃的罪名扣回给工人代表。</p><p>这套逻辑完美对齐了现代企业架构：线上流量暴涨，我们可以加30台服务器顶住（救急）；<br>但如果底层架构烂成一坨，天天靠烧钱买服务器死撑就是犯罪（救穷）。<br>梁思申最终选择伸手与杨巡合作，正是看中了杨巡这个“底层发动机”自造血的恐怖力量。<br>真正的智者，永远只把资源投放在能产生乘数效应的节点上。</p><h1 id="4-终极归宿：三种操作系统的时代宿命"><a href="#4-终极归宿：三种操作系统的时代宿命" class="headerlink" title="4. 终极归宿：三种操作系统的时代宿命"></a>4. 终极归宿：三种操作系统的时代宿命</h1><p>到了第三部，三个主角站在了各自人生的交叉路口，阿耐用冰冷的笔触完成了中国经济的“基因复盘”：</p><p>宋运辉（精英国企&#x2F;完全体CEO）：</p><ul><li>在彭阳农药厂的低谷期，他退居幕后做纯管理。</li><li>他不再执着于自己下场做实验，而是抓方向（转产双效磷）、给团队当防火墙、用肉身抗住外界的行政流言。</li><li>他完成了从 CTO 到 CEO 的蜕变，用“不可替代的技术确定性”赢回了东海的控盘权。</li></ul><p>杨巡（民营私企&#x2F;生存大师）：</p><ul><li>跪过、哭过、做过假账，但他身段极软，能敏锐感知政策的风向。</li><li>在梁思申遭遇美国争产官司、梁父涉嫌金融违规“搭进去”、整个梁家全面塌方的至暗时刻，杨巡用他极端的求生欲和资本原始积累，完成了阶层上岸。</li></ul><p>雷东宝（集体经济&#x2F;草莽大锅饭）：</p><ul><li>他的操作系统停留在了几十年前。</li><li>对威权的迷信、对“传宗接代”的封建执念（导致荒唐的代孕黑化），让他搞一言堂、瞎指挥。</li><li>他的操作系统无法兼容现代企业制度，最终被小雷家无情抛弃，成为了留在岸上的时代化石。</li></ul><h1 id="5-结语：轻舟已过万重山"><a href="#5-结语：轻舟已过万重山" class="headerlink" title="5. 结语：轻舟已过万重山"></a>5. 结语：轻舟已过万重山</h1><p>《大江大河》之所以成为神剧，是因为它告诉所有技术人：任何技术和商业的成功，最终都必须在人性的江湖里落地。</p><p>梁家最终的政治覆灭、梁母在海外嘈杂中凄凉的电话背景音，剥离了梁思申身上所有属于特权阶层的虚妄。<br>当她赤手空拳重新站在宋运辉面前时，两个在智商、眼界、价值观完全对等的高阶玩家，才完成了跨越时代、超越流言的“系统合并”。</p><p>我们不能跟着别人去浑水摸鱼，我们要跟着太阳走。</p><p>看完了小辉的前半生，合上剧本。<br>每一个坐在格子间里改代码、带团队的技术管理者，骨子里其实都住着一个早期的宋运辉——希望世界按照确定的逻辑运行。<br>但最终，我们都要带着他留给我们的智慧，在盘根错节的现实世界里，带着脚镣，跳出最美的舞。</p>]]>
    </content>
    <id>https://hisen.me/20260628-dajiangdahe/</id>
    <link href="https://hisen.me/20260628-dajiangdahe/"/>
    <published>2026-06-28T08:43:00.000Z</published>
    <summary>
      <![CDATA[<p>激荡时代的协议升级：一个技术管理者的《大江大河》通关复盘<br>坐在现代企业的格子间里，看着分布式架构的服务器红绿闪烁，我的眼泪却数次为了几十年前的金州厂与东海荒滩而流。</p>
<p>《大江大河》三部曲，表面上写的是时代的洪流，但在一个技术转管理的互联网人眼里，这分明是一部硬核工程师的“组织突围与系统重构记”。<br>主角宋运辉这三十年的成长，精准地映射了我们每一个技术人从“纯粹写代码”走向“全盘做控盘”的升级阵痛。</p>
<h1 id="1-技术人的立命之本：永不向KPI妥协的“系统坚持”"><a href="#1-技术人的立命之本：永不向KPI妥协的“系统坚持”" class="headerlink" title="1. 技术人的立命之本：永不向KPI妥协的“系统坚持”"></a>1. 技术人的立命之本：永不向KPI妥协的“系统坚持”</h1><p>作为技术人，全剧最让我热血沸腾的，是宋运辉在面对行政压力时“不调参数降低质量”的死磕。</p>]]>
    </summary>
    <title>《大江大河》观后感</title>
    <updated>2026-06-28T08:47:35.603Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="RandomThoughts" scheme="https://hisen.me/categories/randomthoughts/"/>
    <content>
      <![CDATA[<p>在电视剧<a href="/20260628-The-name-of-the-people-and-technology-management/">《人民的名义》</a>大结局中，反派祁同伟吞枪自尽，高小琴被判刑15年。<br>然而，他们留给儿子的2亿港币离岸信托基金，却大概率能安然无恙。</p><p>这绝非编剧的凭空想象，而是现实金融世界中真实存在的冰冷逻辑。<br>在大众眼中，法律和税收是不可违抗的铁律；<br>但在顶层精英眼里，通过“家族信托 + 慈善基金会 + A&#x2F;B股”构筑的顶级防御系统，<br>已经成为一套合法对抗国家收割、实现财富代代相传的“系统Bug”。</p><p>这套“财富城堡”的底层逻辑究竟是怎样的？我们用一张架构图和三大板块为您彻底剥开。</p><h2 id="顶层财富城堡的“铁三角”架构图"><a href="#顶层财富城堡的“铁三角”架构图" class="headerlink" title="顶层财富城堡的“铁三角”架构图"></a>顶层财富城堡的“铁三角”架构图</h2><span id="more"></span><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br></pre></td><td class="code"><pre><span class="line">┌────────────────────────────────────────────────────────┐</span><br><span class="line">│                   创始人 (顶级富豪/权贵)                  │</span><br><span class="line">└──────────────────────────┬─────────────────────────────┘</span><br><span class="line">                           │ 1. 设立并托付 (出让表面所有权)</span><br><span class="line">                           ▼</span><br><span class="line">┌────────────────────────────────────────────────────────┐</span><br><span class="line">│                    家族离岸信托                          │ ◄───【隐形防护罩】</span><br><span class="line">│               (信托保护人掌握上帝视角)                     │      子女为受益人</span><br><span class="line">└──────────────────────────┬─────────────────────────────┘      债主、法院无法追索</span><br><span class="line">                           │ 2. 派遣董事 / 掌握核心投票权</span><br><span class="line">                           ▼</span><br><span class="line">┌────────────────────────────────────────────────────────┐</span><br><span class="line">│                    慈善基金会                            │ ◄───【免税保险箱】</span><br><span class="line">│   (本金 0 遗产税，炒股仅 1.39% 极低税率，子女任高管)          │      将 95% 资产锁死</span><br><span class="line">└──────────────────────────┬─────────────────────────────┘      满足 5% 慈善拨备</span><br><span class="line">                           │ 3. 持有无投票权的 A 股 (分红)</span><br><span class="line">                           ▼</span><br><span class="line">┌────────────────────────────────────────────────────────┐</span><br><span class="line">│                    上市公司 / 实体帝国                    │ ◄───【权力方向盘】</span><br><span class="line">│  (创始人家族通过极少数的 B 股，实现“以小博大”的控制)           │      垄断利润源源不断</span><br><span class="line">└────────────────────────────────────────────────────────┘</span><br><span class="line"></span><br></pre></td></tr></table></figure><h2 id="第一板块：铁三角组合拳的“破防”与“御敌”"><a href="#第一板块：铁三角组合拳的“破防”与“御敌”" class="headerlink" title="第一板块：铁三角组合拳的“破防”与“御敌”"></a>第一板块：铁三角组合拳的“破防”与“御敌”</h2><p>这套组合拳的精妙之处在于，它将资本的四个核心属性——<strong>钱、权、名、税</strong>，高效率地剥离并压榨到了极致。</p><h3 id="1-家族信托：所有权剥离的“隐形防护罩”"><a href="#1-家族信托：所有权剥离的“隐形防护罩”" class="headerlink" title="1. 家族信托：所有权剥离的“隐形防护罩”"></a>1. 家族信托：所有权剥离的“隐形防护罩”</h3><ul><li><strong>核心Bug：一物三权，资产隔离。</strong></li><li><strong>大白话：</strong> 如果你名下有10个亿，当你欠债或离婚时，法院能分光你的财产。但如果你把这10个亿放进“不可撤销信托”，在法律上你就是个“无产阶级”，这笔钱属于信托公司。法院不能因为你个人的债务，去查封另一家独立法人的资产。后代作为受益人，只能按月领生活费。<strong>“放弃所有权，保留控制权”</strong>，瞬间让所有债主和境内法院无从下手。</li></ul><h3 id="2-慈善基金会：左手倒右手的“免税保险箱”"><a href="#2-慈善基金会：左手倒右手的“免税保险箱”" class="headerlink" title="2. 慈善基金会：左手倒右手的“免税保险箱”"></a>2. 慈善基金会：左手倒右手的“免税保险箱”</h3><ul><li><strong>核心Bug：用“自身预算”替代“国家税款”。</strong></li><li><strong>大白话：</strong> 在西方，继承遗产要交高达40%-50%的遗产税。富豪们不愿被国家收割，便成立一个自己名字命名的“慈善基金会”，把钱“捐”给自己。这样不仅<strong>0遗产税</strong>，还换来了“大慈善家”的社会名誉。钱虽然在基金会里，但控制权可以通过章程传给子女。子女在基金会里当高管、领高薪、报销豪车豪宅，名义上是在“考察慈善项目”，实际上实现了财富的完美肉食。</li></ul><h3 id="3-A-B股双层股权：以小博大的“权力方向盘”"><a href="#3-A-B股双层股权：以小博大的“权力方向盘”" class="headerlink" title="3. A&#x2F;B股双层股权：以小博大的“权力方向盘”"></a>3. A&#x2F;B股双层股权：以小博大的“权力方向盘”</h3><ul><li><strong>核心Bug：同股不同权，用10%的资本撬动100%的江山。</strong></li><li><strong>大白话：</strong> 富豪把值钱但没表决权的A股捐给基金会或卖给散户换现金，自己手里死死攥着“1股等于10个投票权”的B股。这样一来，哪怕富豪只持有公司10%的股票，在股东大会上依然拥有绝对话语权，外人永远别想恶意收购，企业的印钞机永远听从家族的指挥。</li></ul><h2 id="第二板块：对抗人性与数学的“资本达尔文主义”"><a href="#第二板块：对抗人性与数学的“资本达尔文主义”" class="headerlink" title="第二板块：对抗人性与数学的“资本达尔文主义”"></a>第二板块：对抗人性与数学的“资本达尔文主义”</h2><p>有了城堡，内部如何防止“后代指数级繁衍导致分光”以及“争产内斗”呢？富豪们制定了冷酷的规则：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br></pre></td><td class="code"><pre><span class="line">       ┌────────────── 财富城堡内部的“淘汰机制”─────────────────┐</span><br><span class="line">       │                                                    │</span><br><span class="line">       ▼                                                    ▼</span><br><span class="line">【极少数优秀继承人】                                   【绝大多数平庸后代】</span><br><span class="line">掌管董事会，握有A/B股表决权                            剥夺投票权，仅享有“信托低保”</span><br><span class="line">继续驱动资本帝国膨胀                                   如敢起诉闹事，触发条款净身出户</span><br><span class="line"></span><br></pre></td></tr></table></figure><ol><li><strong>打破平分家产，信托不养闲人：</strong> 城堡的本金永远锁死不分拆。后代想拿大钱，必须通过“绩效考核”（如考上名校、继承家族业务）。对于游手好闲的败家子，信托只提供刚好够吃穿的“信托低保”，在经济上将其边缘化，防止财富被稀释。</li><li><strong>控制权单线世袭，反诉讼刺刀：</strong> 基金会和信托的掌舵人永远只有一个人（长子或最强继承人）。其余旁系只有分钱的受益权，没有管事的投票权。章程中往往埋有“反诉讼条款”（In Terrorem Clause）——谁敢起诉家族争夺家产，谁就立刻失去所有受益资格，净身出户。</li><li><strong>超级免税的复利永动机：</strong> 在美国，慈善基金会每年只需拿出资产的<strong>5%<strong>做慈善（行政开支也算在内），剩下的95%可以在华尔街继续利滚利。更可怕的是，基金会的炒股投资收益税率被法律固定在</strong>1.39%</strong>（普通企业高达21%以上）。只要华尔街操盘手的回报率大于5%，这座财富雪球就会在近乎免税的环境下无限膨胀。</li></ol><h2 id="第三板块：主权“内卷”下的终极逃生门"><a href="#第三板块：主权“内卷”下的终极逃生门" class="headerlink" title="第三板块：主权“内卷”下的终极逃生门"></a>第三板块：主权“内卷”下的终极逃生门</h2><p>你可能会问，如果大国强行修改法律，或者跨国追赃，这套系统会失效吗？这就涉及到了国际政治的底层残忍逻辑。</p><h3 id="1-小国出卖法律，大国投鼠忌器"><a href="#1-小国出卖法律，大国投鼠忌器" class="headerlink" title="1. 小国出卖法律，大国投鼠忌器"></a>1. 小国出卖法律，大国投鼠忌器</h3><p>那些离岸岛国（开曼、维尔京等）没有工业，他们唯一的暴富手段就是“出卖主权立法权”——立法规定“任何外国政府来查账都是违法”、“资产神圣不可侵犯”。大国因为害怕资本“用脚投票”彻底外逃本国，往往也会默许这些离岸口子的存在，形成了一种高度默契的全球利益闭环。</p><h3 id="2-自动触发的“瞬移条款”（Flight-Clause）"><a href="#2-自动触发的“瞬移条款”（Flight-Clause）" class="headerlink" title="2. 自动触发的“瞬移条款”（Flight Clause）"></a>2. 自动触发的“瞬移条款”（Flight Clause）</h3><p>顶级离岸信托的章程里，都埋有一颗“时空换位”的地雷。一旦信托所在地（如开曼）的法律面临大国政治施压或变动，<strong>该信托会在几秒钟内自动触发管辖法转移</strong>。资产的所有权和受托人会自动“瞬移”到另一个更流氓、更庇护富豪的法域（如南太平洋的库克群岛）。</p><h3 id="3-库克群岛模式：对抗人类的“流氓堡垒”"><a href="#3-库克群岛模式：对抗人类的“流氓堡垒”" class="headerlink" title="3. 库克群岛模式：对抗人类的“流氓堡垒”"></a>3. 库克群岛模式：对抗人类的“流氓堡垒”</h3><p>像库克群岛这样的法域，其法律甚至规定：<strong>“我们不承认任何外国法庭的判决。”</strong> 大国警方或债主如果想拿回钱，必须亲自飞到岛国本土重新起诉，且要在1-2年的极短时效内，举证出“刑事诉讼级别”的恶意欺诈证据。面对动辄数百万美元的跨国诉讼成本和近乎为零的胜率，大多数国家只能望洋兴叹。</p><h2 id="终极复盘"><a href="#终极复盘" class="headerlink" title="终极复盘"></a>终极复盘</h2><p>底层普通人看到的，是电视新闻里每天更新的“打击洗钱、严厉反腐”；<br>而真正掌握游戏规则的既得利益者看到的，<br>是一张由<strong>小国的生存欲、大国的资本焦虑、以及权贵的自保本能</strong>共同织就的财富免死金牌。</p><p>祁同伟用一颗子弹切断了境内所有的犯罪证据链，高小琴用完美的财务做账把钱包装成山水集团的“合法利润”出境，<br>香港及离岸信托的法律机器则在资金落地的刹那自动合闸，将其变成了神圣不可侵犯的“合法私有财产”。</p><p><strong>在这套人类顶级的法律与金融工程面前，个人生命是短暂的，但资本的城堡，却得以永生。</strong></p>]]>
    </content>
    <id>https://hisen.me/20260628-The-golden-shield-of-capital/</id>
    <link href="https://hisen.me/20260628-The-golden-shield-of-capital/"/>
    <published>2026-06-28T08:25:00.000Z</published>
    <summary>
      <![CDATA[<p>在电视剧<a href="/20260628-The-name-of-the-people-and-technology-management/">《人民的名义》</a>大结局中，反派祁同伟吞枪自尽，高小琴被判刑15年。<br>然而，他们留给儿子的2亿港币离岸信托基金，却大概率能安然无恙。</p>
<p>这绝非编剧的凭空想象，而是现实金融世界中真实存在的冰冷逻辑。<br>在大众眼中，法律和税收是不可违抗的铁律；<br>但在顶层精英眼里，通过“家族信托 + 慈善基金会 + A&#x2F;B股”构筑的顶级防御系统，<br>已经成为一套合法对抗国家收割、实现财富代代相传的“系统Bug”。</p>
<p>这套“财富城堡”的底层逻辑究竟是怎样的？我们用一张架构图和三大板块为您彻底剥开。</p>
<h2 id="顶层财富城堡的“铁三角”架构图"><a href="#顶层财富城堡的“铁三角”架构图" class="headerlink" title="顶层财富城堡的“铁三角”架构图"></a>顶层财富城堡的“铁三角”架构图</h2>]]>
    </summary>
    <title>资本的免死金牌：拆解顶级富豪的财富永生城堡</title>
    <updated>2026-09-13T14:26:55.610Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Growth" scheme="https://hisen.me/categories/growth/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <content>
      <![CDATA[<h1 id="1-概览"><a href="#1-概览" class="headerlink" title="1. 概览"></a>1. 概览</h1><h2 id="1-1-简介"><a href="#1-1-简介" class="headerlink" title="1.1 简介"></a>1.1 简介</h2><p>一场盛宴之下的狂欢，让隐藏已久的暗涌浮现，唤醒了所有装睡的人，也触发了 GST 酒业各层人士的生存危机。<br>一切事关生存，每一步都需格外谨慎。赵玫、李东明、董越、梁丹宁等深陷其中的主要人物，<br>在事件中扮演了不同的角色，勾勒出人性的复杂和现实的残酷，<br>从而呈现出一个共同的主题——如何在惶惶不安中乐观地活下去。</p><h2 id="1-2-看点"><a href="#1-2-看点" class="headerlink" title="1.2 看点"></a>1.2 看点</h2><ol><li>行业切面：这一次，是极度暴利也极度残酷的“酒业江湖”<br>女主角赵玫（江疏影 饰）是一个在跨国酒业巨头里拼杀的高级金领。<br>在这个行业里，绝对的金钱伴随着绝对的应酬、人情交割与灰色利益。<br>怎么做省级代理？怎么在夜场、高端会所里用酒开路？<br>怎么平衡外资总部、国内分销商、以及各地监管层之间的复杂关系？</li></ol><span id="more"></span><p>这部剧把高端名利场表面上的“觥筹交错、红酒雪茄”，和背后的“抢渠道、压库存、互相设局、资本绞杀”撕开。<br>它不是那种坐在办公室里喝咖啡的悬浮职场剧，它是带着宿醉和血腥味的现代商战。</p><ol start="2"><li>双雄角色解说<br>赵玫（江疏影 饰）：典型的阿耐式现代独立女性。高学历、高智商，在华尔街和跨国企业的外资系统里浸泡过。她讲的是KPI、是现代企业的合规与资本效率，身段极为精准，手段极其锋利。<br>李东明（佟大为 饰）： 一个深谙中国本土“人情世故操作系统”的老练玩家。他太懂怎么和各路人马打交道、怎么在微观的利益博弈里打太极、怎么利用本土的潜规则去解构外资的硬性指标。</li></ol><h1 id="2-观后感"><a href="#2-观后感" class="headerlink" title="2. 观后感"></a>2. 观后感</h1><p>这些人算计了一辈子，没几个有好下场~<br>《夜色正浓》的结局挺奇怪的，赵玫和董越在一起，整个故事下来似乎是赵玫和她闺密梁丹宁的结局比较好。<br>赵玫：虽然隐忍了丈夫出轨一段时间，最后站队齐又蓝，如愿以偿当上了总监；因狗子受惠那段真是，对手手段真是高；<br>梁丹宁：没有什么职业理想，看破了“依附男权”的职场伪命题，通过拒绝豪门求婚并逆袭掌控核心资源，反向拿捏金主的女强人；<br>李冬明：精于算计，直接打明牌威胁等。虽然最后当上 CEO，但乔海伦死后也被快递小哥撞残废无法工作；<br>乔海伦：身材出众，但是没有什么真本事，又想过更好的生活，只能自愿沦为其他人的工具人；</p>]]>
    </content>
    <id>https://hisen.me/20260628-yesezhengnong/</id>
    <link href="https://hisen.me/20260628-yesezhengnong/"/>
    <published>2026-06-28T07:36:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="1-概览"><a href="#1-概览" class="headerlink" title="1. 概览"></a>1. 概览</h1><h2 id="1-1-简介"><a href="#1-1-简介" class="headerlink" title="1.1 简介"></a>1.1 简介</h2><p>一场盛宴之下的狂欢，让隐藏已久的暗涌浮现，唤醒了所有装睡的人，也触发了 GST 酒业各层人士的生存危机。<br>一切事关生存，每一步都需格外谨慎。赵玫、李东明、董越、梁丹宁等深陷其中的主要人物，<br>在事件中扮演了不同的角色，勾勒出人性的复杂和现实的残酷，<br>从而呈现出一个共同的主题——如何在惶惶不安中乐观地活下去。</p>
<h2 id="1-2-看点"><a href="#1-2-看点" class="headerlink" title="1.2 看点"></a>1.2 看点</h2><ol>
<li>行业切面：这一次，是极度暴利也极度残酷的“酒业江湖”<br>女主角赵玫（江疏影 饰）是一个在跨国酒业巨头里拼杀的高级金领。<br>在这个行业里，绝对的金钱伴随着绝对的应酬、人情交割与灰色利益。<br>怎么做省级代理？怎么在夜场、高端会所里用酒开路？<br>怎么平衡外资总部、国内分销商、以及各地监管层之间的复杂关系？</li>
</ol>]]>
    </summary>
    <title>《夜色正浓》观后感</title>
    <updated>2026-06-28T07:58:03.168Z</updated>
  </entry>
  <entry>
    <author>
      <name>hisenyuan</name>
    </author>
    <category term="Growth" scheme="https://hisen.me/categories/growth/"/>
    <category term="成长" scheme="https://hisen.me/tags/%E6%88%90%E9%95%BF/"/>
    <content>
      <![CDATA[<h1 id="0-缘起"><a href="#0-缘起" class="headerlink" title="0. 缘起"></a>0. 缘起</h1><p>五一假期没有什么安排，就在家看了一部比较经典的剧《人民的名义》。<br>当时我比较惊讶的就是：</p><ul><li>高育良居然和高晓凤是结婚的，和原配是离婚状态。</li><li>侯亮平的领导给他派活时，居然还提醒让问问他老婆钟小艾的建议。</li><li>信托相关：后面还探索了一些信托、慈善基金等知识。</li></ul><p>涉及到利益的事情，在上地视角下还是能看懂，如果现实生活呢？<br>从技术一线走过来，剧里面也有不少值得学习的管理和沟通技巧。</p><h1 id="1-组织协同与管理"><a href="#1-组织协同与管理" class="headerlink" title="1. 组织协同与管理"></a>1. 组织协同与管理</h1><p>当你面对一个庞大的遗留系统、复杂的跨部门协作，<br>甚至准备空降到一个新的业务增效团队时，你面对的局面，本质上就是一个微缩版的“汉东省”。<br>《人民的名义》表面上是政治剧，但其内核是一部 <strong>教科书级的复杂系统治理指南</strong>。<br>对于资深技术管理者，有四个最核心的组织协同与人员管理洞察。</p><h2 id="1-1-沙瑞金的“重构”哲学：先理清依赖，再动手重构"><a href="#1-1-沙瑞金的“重构”哲学：先理清依赖，再动手重构" class="headerlink" title="1.1 沙瑞金的“重构”哲学：先理清依赖，再动手重构"></a>1.1 沙瑞金的“重构”哲学：先理清依赖，再动手重构</h2><p>工程师最容易犯的错，是“新官上任三把火”，看到历史遗留系统或低效流程，第一反应就是“推翻重写”。<br>沙瑞金初到汉东，面对彻底板结的政治生态，他没有立刻下令抓人，<br>而是花了大量时间去基层调研（林城、大风厂），理清了汉东复杂的“接口依赖”和“历史技术债”。</p><ul><li><strong>管理映射：</strong> 当你接手一个核心业务系统，<strong>组织诊断先于架构演进</strong>。<ul><li>不要急于推动重构，先摸清各团队的利益诉求、核心痛点以及业务的真实运转逻辑。</li><li>所有的技术债，本质上都是过去的组织架构和业务妥协留下的历史快照。</li></ul></li><li><strong>落地动作：</strong> 谋定而后动。用专业的管理思维去评估资源盘点与风险敞口，把技术愿景转化为各部门都能听懂的业务增效指标，做到“师出有名”。</li></ul><span id="more"></span><h2 id="1-2-驾驭“李达康式”高绩效人才：结果导向与边界控制"><a href="#1-2-驾驭“李达康式”高绩效人才：结果导向与边界控制" class="headerlink" title="1.2 驾驭“李达康式”高绩效人才：结果导向与边界控制"></a>1.2 驾驭“李达康式”高绩效人才：结果导向与边界控制</h2><p>李达康是典型的“业务攻坚型Tech Lead”，<br>只要能完成KPI（GDP），他甚至可以无视一些规范，性格强势，容易误伤跨部门协作的同事。<br>沙瑞金对李达康的使用方式，<br>是现代企业管理的典范：既要用他的极致执行力去攻克难题，又要用易学习（纪委）去死死盯住他的合规边界。</p><ul><li><strong>管理映射：</strong> 团队里有技术狂人，他们能力极强，但忽视代码可读性、系统可维护性和研发规范。</li><li><strong>落地动作：</strong> 对待这类高绩效员工，<strong>充分授权的同时必须锁定边界</strong>。<ul><li>给他们最难的硬骨头去啃，但要在架构评审和代码合并环节卡住底线：<ul><li>强制文档沉淀；</li><li>使用费曼技巧把复杂逻辑讲给其他成员听；</li></ul></li><li>确保他们的个人能力转化为团队的系统资产，而不是让他们成为“不可替代的单点风险”。</li></ul></li></ul><h2 id="1-3-拆解“高育良式”山头：打破技术黑盒与知识垄断"><a href="#1-3-拆解“高育良式”山头：打破技术黑盒与知识垄断" class="headerlink" title="1.3 拆解“高育良式”山头：打破技术黑盒与知识垄断"></a>1.3 拆解“高育良式”山头：打破技术黑盒与知识垄断</h2><p>高育良和他的“汉大帮”，本质上就是企业内部的“信息孤岛”和“部门墙”。<br>他们通过建立复杂的人际网络和黑盒操作，垄断了汉东的政法系统。</p><ul><li><strong>管理映射：</strong> 在研发团队中，最可怕的不是技术菜，而是“技术垄断”。有些老员工把控着核心模块，代码写得极其晦涩，拒绝输出清晰的文档，试图通过制造“信息壁垒”来巩固自己的地位。这就是技术团队里的“山头主义”。</li><li><strong>落地动作：</strong> 作为管理者，必须毫不留情地打破这种知识垄断。<ul><li>推行强制的轮岗机制、交叉Code Review，以及透明的架构分享。</li><li>把“代码可读性”和“系统可维护性”提升到绩效考核的高度，倡导大道至简的工程文化。</li><li>谁把系统搞得越复杂、越离不开他，就越要削弱他的核心控制权。</li></ul></li></ul><h2 id="1-4-陈岩石的“底层穿透”：拒绝中层信息过滤"><a href="#1-4-陈岩石的“底层穿透”：拒绝中层信息过滤" class="headerlink" title="1.4 陈岩石的“底层穿透”：拒绝中层信息过滤"></a>1.4 陈岩石的“底层穿透”：拒绝中层信息过滤</h2><p>陈岩石是沙瑞金在汉东的“物理探针”。如果没有陈岩石，沙瑞金听到的将全是省委大院里粉饰太平的汇报。</p><ul><li><strong>管理映射：</strong> 随着管理半径变大，你的时间会被各种会议和汇报填满。中层管理者或项目经理为了粉饰进度，往往会上报过滤后的“好消息”。</li><li><strong>落地动作：</strong> 保持对一线业务的“穿透式体感”。<ul><li>不要只看管理看板上的流转率，偶尔要亲自去看看核心链路的监控大盘，去听听一线运营人员或者客服对系统卡顿的真实吐槽。</li><li>你的管理决策必须建立在真实的“物理依据”之上，而不是经过层层包装的PPT汇报。</li></ul></li></ul><blockquote><p><strong>核心洞察：</strong><br>优秀的工程师关注<strong>逻辑的完美</strong>，而优秀的管理者关注<strong>资源的配置与目标的达成</strong>。<br>把写代码时的模块化思维、解耦思维，运用到组织架构的协同设计中，<br>用最平实、准确的职业语言去统一团队目标，这才是技术人向高阶管理进化的必经之路。</p></blockquote><h1 id="2-沟通协作"><a href="#2-沟通协作" class="headerlink" title="2. 沟通协作"></a>2. 沟通协作</h1><p>在沟通与协作上，《人民的名义》展示的段位更高，甚至可以说是全剧的灵魂。<br>日常研发中，我们常觉得“技术是黑白分明的，沟通却是灰色的”。但实际上，<strong>高级的沟通协作，本质上是另一场高并发的“协议对齐”与“流量控制”</strong>。<br>对于资深的技术人，无论面对的是业务方、上级还是跨团队同僚，剧中的四种沟通名场面，直接对应了四种极具价值的职场协作解法：</p><h2 id="2-1-向上沟通：不要输出“技术黑盒”，要对齐“核心币种”"><a href="#2-1-向上沟通：不要输出“技术黑盒”，要对齐“核心币种”" class="headerlink" title="2.1 向上沟通：不要输出“技术黑盒”，要对齐“核心币种”"></a>2.1 向上沟通：不要输出“技术黑盒”，要对齐“核心币种”</h2><p>很多技术人向上汇报时，喜欢抛出一堆非技术领导听不懂的专业术语（如高并发下的锁竞争、垃圾回收停顿等）。这在管理沟通中属于“低效协议”。<br>看看剧中的<strong>高育良</strong>，哪怕面对不熟悉政法业务的沙瑞金，他每一次汇报都极度丝滑。<br>为什么？因为他永远在用沙瑞金听得懂、且最关心的语言——**“大局观、班子团结、干部稳定”**来包装他的诉求。</p><ul><li><p><strong>技术人的通病：</strong> 向上要资源重构时说：“这段旧代码太烂了，我要用 Go 重写，提高并发性能。”</p></li><li><p><strong>高阶的对齐方式（费曼技巧）：</strong> 转化成业务和管理听得懂的**“语言货币”**——资金、时间、稳定性。</p><blockquote><p>“目前核心链路的技术债已经到了临界点，当前的系统架构支撑下半年 11.11 促销的风险敞口极高。如果现在投入 2 个人、花 2 周时间把这部分逻辑解耦，不仅能把大促期间的服务器成本降低 30%，还能保证核心交易的可用性达到 4 个 9 以上，彻底消除资损风险。”</p></blockquote></li></ul><h2 id="2-2-横向协作：寻找“最大公约数”，破除“汉大帮”与“秘书帮”的对立"><a href="#2-2-横向协作：寻找“最大公约数”，破除“汉大帮”与“秘书帮”的对立" class="headerlink" title="2.2 横向协作：寻找“最大公约数”，破除“汉大帮”与“秘书帮”的对立"></a>2.2 横向协作：寻找“最大公约数”，破除“汉大帮”与“秘书帮”的对立</h2><p>剧中“汉大帮”（政法系）和“秘书帮”（经济系）天然对立，但在<strong>大风厂危机</strong>爆发的那个晚上，这两派人竟然坐在协调会上把问题给解决了。<br>因为他们找到了一个共同的目标：<strong>不能发生群体性事件。</strong><br>在研发日常中，类似大风厂这样的“边界扯皮”天天在发生（比如：R&amp;D 觉得业务方的需求变化太快，产品觉得研发排期太长）。</p><ul><li><strong>协作解法：</strong> 当跨部门协作推不动时，不要在技术细节上跟对方死磕。尝试跳出技术视角，站到更高的业务视角去寻找**“利益最大公约数”**。</li><li><strong>具体动作：</strong> 主动帮业务方算账。如果业务要上一个很赶的需求，与其生硬地拒绝，不如给出折中方案：“如果按你原定的完美版本做，研发要 3 周，肯定赶不上营销节点。我们能不能第一期先做个最小可行性产品（MVP），只支持核心主流程，3 天内就能上线跑数据，后面的功能我们按周迭代？”</li></ul><h2 id="2-3-向下沟通：警惕“李达康式”的压迫，建立“非责备”的安全感"><a href="#2-3-向下沟通：警惕“李达康式”的压迫，建立“非责备”的安全感" class="headerlink" title="2.3 向下沟通：警惕“李达康式”的压迫，建立“非责备”的安全感"></a>2.3 向下沟通：警惕“李达康式”的压迫，建立“非责备”的安全感</h2><p>李达康为了出政绩，对下属的沟通极其粗暴和强势，甚至不容许解释。<br>结果导致了什么？<strong>孙连城直接躺平开始“仰望星空”，下属们为了不犯错，选择不做事。</strong><br>在技术团队里，如果你也是一个过于强势的 Tech Lead（技术主管），<br>总在出线上事故时当众训斥：“这么简单的 Bug 怎么写出来的？”、“你这代码逻辑是怎么过的 Code Review？”。<br>团队很快就会“李达康化”。</p><ul><li><strong>带来的系统风险：</strong> 下属会因为害怕犯错而隐瞒技术风险。有了线上隐患不敢说，遇到架构难题自己硬扛，最后演变成无法收拾的灾难性大故障。</li><li><strong>高阶的沟通动作：</strong> 引入大厂提倡的 <strong>“非责备复盘”（Blameless Post-mortem）</strong>。<br>在出故障后，沟通的焦点应该从“这是谁写的 Bug”转向“我们的系统设计和 Review 流程存在什么漏洞，才让这个 Bug 溜到了线上”。<br>用流程和制度的防护网，换取团队成员的心理安全感，才能激发底层的实干创造力。</li></ul><h2 id="2-4-危机沟通：学习“季昌明式”的合规与升级机制"><a href="#2-4-危机沟通：学习“季昌明式”的合规与升级机制" class="headerlink" title="2.4 危机沟通：学习“季昌明式”的合规与升级机制"></a>2.4 危机沟通：学习“季昌明式”的合规与升级机制</h2><p>很多人觉得检察长季昌明“胆小怕事、极度教条”，在抓捕丁义珍的关键时刻，他非要拦着陈海，去向省委汇报，结果导致丁义珍跑了。<br>但如果你在大厂待过，你会发现季昌明才是真正懂**“重大事故升级与容灾机制”**的人。<br>抓捕副厅级干部，稍有不慎就是政治地震，这不是一个检察院能私自兜底的。</p><ul><li><strong>技术人的通病：</strong> 线上突发大故障，或者核心数据库疑似被锁，为了个人英雄主义，自己悄悄在生产环境改代码、重启服务，结果导致故障范围进一步扩大，错过了最佳的止损时机。</li><li><strong>高阶的流程意识：</strong> 越是资深的工程师，越要明白**“风险升级机制”**（Escalation Policy）的重要性。<ul><li>明确什么级别的故障必须在 5 分钟内拉通整个核心团队；</li><li>什么时候必须立刻向总监、VP 级别报警争取支持；</li><li>什么时候该直接执行主备切换或熔断降级。<br>  按流程规范办事，这不是教条，而是对系统、对团队最专业的保护。</li></ul></li></ul><blockquote><p>一句话总结：工程师写代码是为了让机器执行，而沟通是为了让组织协同。<br>像机器一样去精准对齐信息流，像架构师一样去设计协作的边界与容灾机制，这就是从写代码（Coding）走向带团队（Leading）的沟通质变。</p></blockquote>]]>
    </content>
    <id>https://hisen.me/20260628-The-name-of-the-people-and-technology-management/</id>
    <link href="https://hisen.me/20260628-The-name-of-the-people-and-technology-management/"/>
    <published>2026-06-28T07:11:00.000Z</published>
    <summary>
      <![CDATA[<h1 id="0-缘起"><a href="#0-缘起" class="headerlink" title="0. 缘起"></a>0. 缘起</h1><p>五一假期没有什么安排，就在家看了一部比较经典的剧《人民的名义》。<br>当时我比较惊讶的就是：</p>
<ul>
<li>高育良居然和高晓凤是结婚的，和原配是离婚状态。</li>
<li>侯亮平的领导给他派活时，居然还提醒让问问他老婆钟小艾的建议。</li>
<li>信托相关：后面还探索了一些信托、慈善基金等知识。</li>
</ul>
<p>涉及到利益的事情，在上地视角下还是能看懂，如果现实生活呢？<br>从技术一线走过来，剧里面也有不少值得学习的管理和沟通技巧。</p>
<h1 id="1-组织协同与管理"><a href="#1-组织协同与管理" class="headerlink" title="1. 组织协同与管理"></a>1. 组织协同与管理</h1><p>当你面对一个庞大的遗留系统、复杂的跨部门协作，<br>甚至准备空降到一个新的业务增效团队时，你面对的局面，本质上就是一个微缩版的“汉东省”。<br>《人民的名义》表面上是政治剧，但其内核是一部 <strong>教科书级的复杂系统治理指南</strong>。<br>对于资深技术管理者，有四个最核心的组织协同与人员管理洞察。</p>
<h2 id="1-1-沙瑞金的“重构”哲学：先理清依赖，再动手重构"><a href="#1-1-沙瑞金的“重构”哲学：先理清依赖，再动手重构" class="headerlink" title="1.1 沙瑞金的“重构”哲学：先理清依赖，再动手重构"></a>1.1 沙瑞金的“重构”哲学：先理清依赖，再动手重构</h2><p>工程师最容易犯的错，是“新官上任三把火”，看到历史遗留系统或低效流程，第一反应就是“推翻重写”。<br>沙瑞金初到汉东，面对彻底板结的政治生态，他没有立刻下令抓人，<br>而是花了大量时间去基层调研（林城、大风厂），理清了汉东复杂的“接口依赖”和“历史技术债”。</p>
<ul>
<li><strong>管理映射：</strong> 当你接手一个核心业务系统，<strong>组织诊断先于架构演进</strong>。<ul>
<li>不要急于推动重构，先摸清各团队的利益诉求、核心痛点以及业务的真实运转逻辑。</li>
<li>所有的技术债，本质上都是过去的组织架构和业务妥协留下的历史快照。</li>
</ul>
</li>
<li><strong>落地动作：</strong> 谋定而后动。用专业的管理思维去评估资源盘点与风险敞口，把技术愿景转化为各部门都能听懂的业务增效指标，做到“师出有名”。</li>
</ul>]]>
    </summary>
    <title>《人民的名义》与技术管理</title>
    <updated>2026-06-28T08:00:35.120Z</updated>
  </entry>
</feed>
