Blog

多 Agent 如何可靠协作：从 CAP、Raft 到拜占庭故障

2026-08-04T00:00:00.000Z

当团队里出现多个“真相”

把同一个任务交给三个 Agent，通常不会自然得到一支配合默契的团队。
更常见的情况是：它们各自掌握一部分上下文，各自维护一份状态，还可能在不同时间得出互相冲突的结论。

单个 Agent 犯错，我们会追问模型能力、提示词或工具调用。
多个 Agent 协作失灵，还要多问一层：信息有没有送达，大家看到的是不是同一版状态，某个成员的话又凭什么可信？

分布式系统几十年来一直在处理类似的麻烦。
CAP、Raft 和拜占庭容错因此常被拿来解释多 Agent 协作。
这组类比很有启发，但三个概念分别处理不同层次的问题，混在一起反而容易误判：

问题	关心什么	放到 Agent 团队里
CAP	通信中断时，一致性与可用性如何取舍	成员失联后，是继续工作，还是暂停关键操作
Raft	基本可信的节点如何确认唯一的权威状态	谁来协调，以及什么结果算正式生效
拜占庭容错	节点可能任意出错时，系统如何维持可信	成员会不会伪造、隐瞒或传播互相矛盾的结果

可以把它们记成三句话：联系不上，看 CAP；意见要落成一个决定，看共识；连发言者都不能完全相信，看拜占庭故障。

图中的三层是递进关系。
通信恢复只能解决消息能否到达；状态达成一致之后，系统仍要继续判断参与者和证据是否可信。

从一次发布说起

假设三个 Agent 合作发布一个新版本。

Agent A 核对需求与改动范围
Agent B 运行测试并检查构建产物
Agent C 汇总结论，在条件满足后执行发布

理想流程很简单：A 和 B 完成检查，C 收到证据，版本发布。
但只要协作跨越多个执行单元，问题就会一层层出现。

第一层是通信问题。
A 已经完成检查，消息却没有传到 C；C 无法判断 A 是尚未完成、已经宕机，还是单纯网络延迟。

第二层是状态问题。
A 检查的是提交 v2，B 跑测试时拿到的却是 v1，两份“通过”放在一起也不能证明 v2 可以发布。

第三层是信任问题。
B 可能被恶意网页中的提示注入影响，没有真正运行测试，却向 C 返回“全部通过”。
这时通信完全正常，团队也达成了共识，结论仍然可能是错的。

这三个失败场景表面上都叫“协作不顺”，根因却分别是消息不可达、状态不一致和参与者不可信。
CAP、Raft 与拜占庭容错的价值，正在于把这三层问题拆开。

CAP：失联之后，停下来还是继续走

CAP 中的三个字母分别是 Consistency、Availability 和 Partition tolerance。

一致性（Consistency）：一次成功写入之后，后续读取不会再看到更旧、互相冲突的权威状态
可用性（Availability）：每个到达正常节点的请求都能在有限时间内得到响应，不会因其他节点失联而一直挂起或直接拒绝
分区容错（Partition tolerance）：节点之间出现丢包、断网或长时间延迟时，系统仍有明确的处理方式

CAP 经常被压缩成“C、A、P 三选二”，这个说法太容易让人误会。
选择发生在网络分区已经出现、节点无法确认彼此状态的时候。
此时系统无法同时保证强一致和持续可用，只能决定哪一边优先。

回到发布场景。
如果 C 联系不上 A，它有两种基本选择。

一种选择是暂停发布，直到重新取得 A 的确认。
团队损失了可用性，却守住了“未经完整检查不得发布”这一条一致规则，这更接近 CP 的取向。

另一种选择是让 C 根据已有信息继续发布，待连接恢复后再补齐记录。
流程没有停，但不同成员可能暂时对“这个版本是否已经获批”持有不同答案，这更接近 AP 的取向。

这里没有脱离业务的最优解。
资料搜集、候选方案生成通常可以容忍暂时分叉；支付、删除、正式发布则往往宁可等待，也不能制造两个都声称有效的结果。
合适的一致性强度，取决于动作是否可逆以及出错成本有多高。

Git、CRDT 与 Raft：三种不同的协作思路

Git、CRDT 和 Raft 常被放在一起讨论，因为它们都处理“多个副本”的问题。
三者对冲突的态度并不相同。

Git：先允许分叉，再由人解决语义冲突

两名开发者断网后都可以继续提交。
网络恢复时，Git 能找到历史分叉的位置，也能合并互不冲突的文本改动，但它不知道两个修改在业务上能否同时成立。

所以，把 Git 类比为 AP，只是在强调“离线也能继续工作”，并非对 Git 进行严格的 CAP 分类。
Git 提供了保存分歧和重新汇合的机制，最后的语义裁决仍由人或更高层系统完成。

CRDT：提前限制操作，使副本可以自动收敛

CRDT 是一类为自动收敛而专门设计的数据结构，能力范围受数据模型约束。
它通过让并发操作满足交换、结合或幂等等性质，使不同副本即使以不同顺序收到更新，最终也能收敛到同一个结果。

例如，甲离线时向共享集合加入 A，乙同时加入 B。
如果这个集合采用合适的 CRDT，重连后双方都能得到 {A, B}，不需要判断谁覆盖谁。

代价也很明确：业务状态必须能被表达为这种可合并的数据结构。
“是否批准发布”包含责任、时序和约束，不能简单套用集合并集；自动收敛解决的是数据冲突，不等于解决了业务决策。

Raft：用多数派确定唯一的提交顺序

Raft 处理的是另一类需求：系统不能接受多个并存的权威历史，必须让节点对日志顺序达成一致。

它通常会选出一个 Leader，由 Leader 接收变更并复制给其他节点。
以五节点集群为例，一条日志至少得到三个节点确认，才可能被视为已提交。
网络分区后，拥有多数节点的一侧可以继续推进；少数派无法独立确认新的权威状态。

多数派的意义不只是“票多者胜”。
任意两个多数派必然至少共享一个节点，这种重叠让已经提交的历史不容易被另一套历史取代。
Raft 用分区期间的部分不可用，换取了单一、连续的权威日志。

放到 Agent 团队里，Raft 提供的是一种组织协作的思路：明确协调者、记录决策顺序、规定提交门槛，并让少数失联成员无法单独改变最终状态。
这种机制针对日志复制与提交顺序，既不等同于汇总几个 Agent 的自然语言投票，也不会判断投票依据是否真实。

Raft 的边界：多数派可能整齐地做错事

标准 Raft 解决的是崩溃故障容错（Crash Fault Tolerance，CFT）。
它假设节点可能宕机、重启、延迟或失联，但节点一旦发送消息，就会遵守协议，不会伪造日志，也不会故意对不同成员讲不同版本的故事。

拜占庭故障放宽了这条假设。
一个故障节点不仅可以沉默，还可以任意行动：

对 A 声称“发布已经获得批准”，对 C 又声称“仍在等待确认”
把没有执行过的测试包装成通过结果
选择性隐瞒失败日志，只转发有利片段
冒用其他成员身份，伪造一条看似完整的证据链

经典的拜占庭将军问题之所以困难，正是因为正常参与者无法仅凭收到消息，就判断消息是事实、误传还是蓄意欺骗。

Agent 的幻觉未必带有恶意，提示注入也未必意味着模型本身“叛变”。
但从接收方看，两者都可能产生不受协议约束的任意输出。
因此在安全设计上，把这类输出当作拜占庭式故障处理，比猜测 Agent 的主观意图更有用。

经典 BFT 模型中，容忍 f 个拜占庭节点通常至少需要 3f + 1 个节点。
这个数字依赖网络同步性、身份认证方式和具体协议，不能直接当作 Agent 产品的节点配置公式。
对 Agent 产品更重要的提醒是：只增加节点数量，并不会自动增加可信度。

为什么“三个 Agent 都同意”仍然不够

多数机制能够抵御独立故障，前提是各个判断真的足够独立。
现实中的 Agent 团队往往共享同一个基础模型、系统提示、检索源和工具链，这会制造高度相关的错误。

如果三个 Agent 都从同一篇错误文章取证，三票赞成仍然只有一个信息源。
如果三个 Agent 都会被同一种提示注入攻击，增加副本只是在复制同一处薄弱点。
如果所谓“复核 Agent”只阅读执行 Agent 的摘要，它最多能检查措辞是否自洽，无法确认任务是否真的完成。

因此，多 Agent 系统里的“独立验证”至少应拆成三个维度：

来源独立：关键事实由不同的原始来源互相印证，避免多次转述同一材料
方法独立：结论由不同机制验证，例如静态检查、自动测试和运行时观测互相补充
权限独立：提出操作、批准操作和执行操作不由同一个身份包办

有价值的冗余会刻意增加验证路径的差异，让同一个错误难以同时穿透所有检查。

工程上先守住证据门禁

大多数 Agent 产品并不需要直接实现 PBFT 一类完整的拜占庭共识协议。
它们通常运行在中心化编排器上，成员数量有限，关键状态也可以落在可信数据库中。
此时更有效的做法，是把分布式系统的原则翻译成具体的产品约束。

这条链路中最关键的断点，位于“Agent 自述”和“可验证事实”之间。
只要发布门禁读取的是原始证据，单个 Agent 的错误就不容易直接变成外部副作用。

什么时候该用这套视角

“多 Agent”这个名称本身，并不足以构成分布式系统问题。
如果几个 Agent 由同一个进程顺序调用，共享一份数据库，也没有独立权限，首要矛盾通常是任务拆分、上下文传递和验收标准。

当系统出现以下特征时，分布式系统的视角才开始变得关键：

成员拥有独立、可持续的本地状态
通信可能延迟、丢失、重复或乱序
多个成员可以并发修改同一业务事实
部分成员失联后，其他成员仍被允许继续工作
输入、工具或参与者不能被完全信任

这组判断也给出了一个实用顺序。
先问通信中断后是否允许继续，再问哪个状态需要唯一权威，最后问参与者和证据是否可信。
只有前一层的边界说清楚，后一层的机制才不会沦为术语堆砌。

结语：共识保证一致，不保证正确

CAP 告诉我们，通信分区会迫使系统在一致性和可用性之间做选择。
Raft 告诉我们，一群遵守协议的节点可以通过 Leader、日志和多数派形成唯一的决定。
拜占庭问题则提醒我们：如果参与者可能任意出错，形式上的一致仍然可能建立在假消息之上。

对多 Agent 系统来说，可靠协作来自清晰的状态边界和证据链。
哪些状态可以分叉、哪些动作必须串行，哪些结论可以讨论、哪些事实必须拿证据说话，都要在系统里得到明确表达。

共识解决的是“大家最终认哪一个结果”。
可信系统还必须回答另一件事：这个结果为什么值得相信。

Harness Engineering 分层模型

2026-05-07T00:00:00.000Z

2025 年下半年开始，Coding Agent 的能力边界快速扩张

Claude Code、Codex、Cursor、Windsurf 等工具让长时运行、多文件修改、子代理派发和 MCP 调用成为常见能力。
社区的讨论随之出现一种层级错位：有人在讨论 Agent 内部怎么构成，有人在讨论开发流程怎么设计，有人在比较哪个第三方套件更强——三组人各有道理，但很难对齐。

2026 年初，OpenAI 在一篇关于 Codex 的文章里首次使用 Harness Engineering 这个组合词，把 harness 从 Agent 构件的语境推进到使用者侧的工程实践。随后几周内，Anthropic 发表了长时运行 Agent 的 harness 设计指南，LangChain 做了 Agent Harness 的构件解剖；Linux.DO 上一个持续数月的长帖则把这些概念带进了真实项目的实操验证。

这篇文章综合了上述材料和社区实践，围绕五个问题展开：Harness Engineering 是什么，它怎样运行，它解决什么问题，怎样优化它的成本，以及如何落地。

概念与边界

harness 这个词被用得很泛，接近"模型之外的一切"。拆开看，它指向两层不同的问题。

LangChain 给出的公式最简洁：

Agent = Model + Harness

模型提供语言与推理，harness 提供状态、工具、执行路径、沙箱、上下文管理和反馈机制。

LangChain 的文章把这些构件分为六类：文件系统、bash 执行、沙箱与验证工具、记忆与搜索、上下文腐败对抗、长程自主执行所需的规划和自验证循环^[1]。

OpenAI 的文章把这个词推到使用者侧之后，Harness Engineering 成了一个独立的工程范式，关注 Coding Agent 怎样被组织进一个可以稳定产出可验收变更的开发流程。

维度	Agent Harnesses	Harness Engineering
关注对象	Agent 的构件	使用 Agent 的工程系统
核心问题	它由什么组成	它如何被驾驭成开发流程
典型材料	system prompts、tools、MCP、memory、sandbox、subagents	`AGENTS.md`、spec、runbook、tracker、门禁、审查
成熟标志	Agent 具备工具和约束	开发过程具备控制面、验证闭环和验收标准

Harness Engineering 分层模型

开发者与模型交互的粒度至少经历了三次跳跃：

阶段	交互尺度	主要失败来源	核心工程动作
Prompt Engineering	单次交互	prompt 模糊、上下文缺失	改提示词
Context Engineering	会话级	上下文污染、记忆断裂	管理文件选择与压缩
Harness Engineering	项目级	控制面失真、任务漂移、验证不足	设计规则、门禁、反馈回路

这个边界直接影响诊断方向：Agent 产出不稳定时，先判断缺的是构件能力还是流程设计——缺构件补 MCP、skill、hook；缺流程补任务边界、质量门禁、runbook 和控制面纪律。

很多"为什么套件功能很多、结果仍然不稳"的困惑，根源在于把两类问题混在一起。

运行结构

把开发流程当作工程对象之后，核心结构是三层工作面：

控制面：orchestration、tracker、prompts、交接文档、任务依赖与阻塞状态。
执行面：每个任务从集成面切出的 worktree/branch，承载本次修改与定向验证。
集成面：本地真实代码状态，所有任务完成后的合并目标。

Harness Engineering 控制回路

分离的核心目的是把"应当如何推进"和"代码实际是什么"拆开。

Agent 可以读控制面决定下一步做什么，但判断完成必须回到集成面看真实 diff、真实测试输出、真实构建结果——社区把这条纪律称为 Truth-first。

它反制的是一类具体失败：Agent 把 tracker 标记当成完成状态继续推进，旧 diff 被带入后续切片，错误在几轮交接后才暴露。

引导与检测

三层工作面定义了结构骨架，填充它的机制是引导和检测。Böckeler 在 Martin Fowler 站上用控制论框架对 harness 做了正交分解^[2]。

第一个维度是方向:

guides / 引导在 Agent 行动前指明正确方向：AGENTS.md、architecture.md、skill 指令、LSP 集成、runbook。
sensors / 反馈在 Agent 行动后检测和修正偏差：测试、lint、typecheck、code review、构建结果。

第二个维度是执行方式:

computational / 计算型是确定性的 CPU 执行，成本低、结果可靠：lint、typecheck、ArchUnit、覆盖率检查。
inferential / 推理型是 LLM/GPU 执行，成本高、非确定性，但能处理语义判断：AGENTS.md 指令、code review skill、AI judge。

	引导（行动前）	反馈（行动后检测）
计算型	LSP、bootstrap 脚本、OpenRewrite	lint、typecheck、ArchUnit、覆盖率
推理型	`AGENTS.md`、architecture skill、API 文档	code review skill、AI judge、日志异常检测

引导和反馈相互配合：

只有反馈的系统让 Agent “反复犯同样的错误”——测试告诉它错了，但它不知道正确方向。
只有引导的系统"编码了规则却永远不知道规则是否生效"——AGENTS.md 写得再好，没有测试就无法闭环。
harness 的设计工作就是沿着四个象限逐一补齐，并通过转向循环（steering loop）持续迭代。

文档作为模型间的 API

多模型协作时，不同模型的上下文容量、推理强度和响应形态各不相同。直接互读原始执行日志会造成上下文膨胀和判断污染。

解决方式是把文档当作模型间的 API：

文档类型	生产者	消费者	接口职责
历史大纲摘要	压缩模型 / 整理 Agent	高阶决策模型	去噪、保留状态
`AGENTS.md`	人类 / 高阶模型	执行 Agent	固化规则与边界
版本开发报告	执行 Agent	人类 + 其他模型	固化踩坑和未完成项
进度文件	每轮 Agent	下一轮 Agent	跨上下文窗口的连续记忆

Anthropic 的指南把这个模式具象化：claude-progress.txt 跨会话维护，配合 feature_list.json 和 git log 构成启动信息。

每轮 Agent 的固定启动序列：pwd → 读进度文件 → 读功能清单 → git log --oneline -20 → 运行 init.sh → 跑冒烟测试确认基线 → 开始工作。

LangChain 把 AGENTS.md 定义为一种持续学习机制——短期记忆固化为长期记忆的通道。

这是 harness 与传统 README 的实质分歧：harness 文档面向机器消费，字段稳定度和术语一致性比文笔重要。

tracker.md 里一个字段从 blocked 改成 waiting 可能让下游 Agent 判断逻辑失效——这是 API 层面的破坏性变更。

人类作为隐式 harness

Böckeler 指出：人类本身就是一种隐式 harness。人类开发者自带被吸收的编码规范、对复杂度的审美厌恶（“一个 300 行的函数看着就不对”）、社会问责（名字挂在 commit 上）、组织记忆，以及对"承重约定"与"习惯约定"的直觉区分。

Agent 缺少全部这些能力。harness 外显化了其中一部分。

解决什么问题

Anthropic 的长时运行指南列出了几种具名的失败模式：

one-shotting：试图一次性完成所有工作，跑到一半上下文耗尽
premature victory declaration：Agent 看到部分进展就宣布完成
dirty handoffs：切片结束时留下未文档化的 bug 和半成品状态

这些失败模式都源自 harness 缺失。Anthropic 直接说明，即便是 Opus 4.5 在 Claude Agent SDK 的循环中跨多个上下文窗口运行，缺少 harness 模式的约束就"无法构建出生产级的 Web 应用"^[3]。

验证质量的天花板

Agent 自生成测试只覆盖模型自身理解到的路径，遗漏真实业务和历史 bug 走过的路径。局部实现里问题不大，重构场景里是系统性漏洞——重构要保持的恰恰是 Agent 没有理解到的行为。

Anthropic 的观察：Agent 会写单元测试、用 curl 打 dev server 端点，但仍然"无法识别端到端功能不工作"。引入浏览器自动化（Puppeteer MCP）做端到端验证后，“Agent 能够识别和修复仅从代码看不出来的 bug”。

Böckeler 的框架把这个问题定位到更大的缺口：行为验证（functional correctness）是当前最难解决的维度。代码风格有 lint，架构约束有 ArchUnit，可维护性有覆盖率——但"功能是否正确"主要依赖 AI 自生成测试和人工验收。

一种有前景但适用范围有限的模式是 approved fixtures——人类审批预期输出后将其固化为回归锚点。

门禁的测试集需要人工参与

关键路径的回归集必须来自既有系统、线上样本或人工定义的验收用例
AI 自生成测试补边界，人工定义测试守核心行为。

成本与调优

长时运行 Agent 的典型故障是"跑得动但很贵"。Linux.DO 社区的 OMO 实践数据可以作为机制信号：

某次约 24 小时的运行里，集成面输出约 38 个文件、670 行代码改动；同期控制面产出 17 个文件、约 4933 行记录。控制面产出在行数上是集成面的七倍多^[4]。
一次 32 小时长跑里，48 个文件产生约 3333 行代码，token 消耗超过 10 亿。追溯发现交接提示词里混入了"最小可执行单元"倾向，每个 worktree 只改 1–3 个文件、几行到几十行 diff。
统一术语、瘦身控制面、调整切片策略之后，9 小时完成 65 个文件、约 1539 行改动，token 约 2.2 亿。时间效率和 token 产出比都改善了一个量级。

贪婪切片

这组数据指向一个反直觉的结论：任务粒度越细，单位产出的固定成本越高。每个切片都要跑 planning、边界确认、handoff、实现、focused test、审查、merge、tracker 更新——这是一组几乎不随切片大小变化的固定开销。

直觉上"小批次、快反馈"在人类协作中成立，因为人类 review 成本近似线性于 diff 大小。Agent 的 review 成本是亚线性的——读 200 行和读 20 行在 token 消耗上量级接近。

最优切片粒度因此从"尽量小"变成"小到能通过验证，同时大到值得跑完整门禁"。社区把这个策略称为贪婪切片。

Context rot 对策

与控制面熵增并行的另一个机制是 context rot——LangChain 的术语，指随着上下文窗口填满，模型的推理能力退化。三种对策：

compaction：上下文临近容量时智能摘要和卸载
tool call offloading：大块工具输出只保留首尾，全文写入文件系统按需读取
progressive disclosure：用 skills 机制按需展开能力，启动时不加载全部工具定义^[5]

共同思路是把上下文当作稀缺资源管理。

Harnessability

Böckeler 提出的 harnessability 概念：代码库被 harness 的难度差异很大。提升有效性的结构性属性：

强类型语言——类型检查本身就是内置 sensor
清晰的模块边界——支持架构约束规则
抽象框架如 Spring——隐式提高首次正确率

她把这些称为"环境可供性"（ambient affordances），结构性属性让环境本身对 Agent 可读、可导航、可操作。

遗留系统面临一个悖论：最需要 harness 的地方，恰恰是 harness 最难建的地方。

落地路径

Harness Engineering 采用决策流程

采用 harness engineering 的判断简化为三步：先看基础条件是否就绪（需求、runbook、测试数据、完成标准），再选择最小控制层补当前最大痛点，最后用真实交付数据修正系统。

个人或小团队起步不需要重型多 Agent 平台。一个可行的最小目录：

AGENTS.md                   # 项目规则、禁止事项、默认验证命令、完成标准
docs/architecture.md        # 模块边界、数据流、外部依赖、高风险区域
docs/runbooks/dev-test.md   # 安装、启动、测试、联调、日志收集
docs/plans/current.md       # 当前任务目标、非目标、方案、验收标准
docs/tracker.md             # 任务状态、依赖、阻塞、完成证据

每轮执行结束只要求一份最小完成证明：改了什么、为什么这样改、跑了什么验证、还剩什么风险、下一步是否需要人类决策。

外部套件的选型应当倒着来——先定位自身痛点，再判断套件补的是哪一层：

痛点	对应的能力层	可参考的套件方向
需求澄清不足	流程层前段	Superpowers 的 brainstorming 和 TDD
长任务无人值守	状态层 + 控制层	OMO 的 orchestration
命令多、难记	流程层	GSD 的命令收敛
需要沉淀团队规则	静态设施	Trellis 的规范积累
控制面成本过高	控制层	CodeStable 的极简理念
跨产品、角色协作	交付层	BMAD、gstack 的产品闭环

什么时候应当按兵不动

三种情况下应先补基础：

需求本身仍然混乱，验收标准没定
关键路径没有可用的回归测试或真实数据
项目规则已经过期，AGENTS.md 和代码事实不一致

在这种状态下加 workflow 会放大噪音，加 agent teams 会放大分歧，加自动化会放大错误传播。更稳的顺序是先把需求、runbook、测试数据和完成标准补齐。

衡量 harness 是否有效只需两个指标：返工率和验证通过率。两个指标持平或倒退，任何套件、角色、编排都只是控制面的装饰。

注释

LangChain 在 Terminal Bench 2.0 上的发现佐证了这一点：同一个 Opus 4.6 模型在不同 harness 中得分差异巨大。LangChain 的 coding agent 仅通过改进 harness（不换模型）就从排行榜第 30 名升至前 5 名。harness 的设计质量对产出的影响不亚于模型本身。 ↩
这个框架的理论根基是控制论。Böckeler 引用了 Ashby 的必要多样性定律（Law of Requisite Variety）：调节器需要拥有至少与被调节系统一样多的多样性。Coding Agent 几乎可以生成任何代码——约束拓扑结构（技术栈、模块边界、命名规范）是一种品种削减动作，让 harness 的覆盖变得可行。 ↩
Anthropic 为此设计了一套双 Agent 架构：Initializer Agent 在首次会话中建立项目脚手架、生成结构化功能清单（JSON 格式，因为模型"更不容易不恰当地修改 JSON 文件"），Coding Agent 在后续每次会话中读取已有状态、增量完成单个功能、测试并留下干净状态。两个 Agent 共享同一个 system prompt 和工具集——区别只是 user prompt 不同。 ↩
这里的比例来自具体项目和套件，在多轮复盘里一致出现。 ↩
其中 compaction 已被 Claude Agent SDK 内置，但 Anthropic 指出 compaction “并不总是能把足够清晰的指令传递给下一个 Agent”，因此仍需要外部持久化机制（进度文件、git log、结构化功能清单）作为补充。 ↩

少年意气不可再生

2026-04-27T00:00:00.000Z

他年轻时以为钱是用来把房子变大的。后来才知道，人真正需要的空间很小。一间五十多平米的公寓，如果楼下有超市，常去的地方都在附近，生活已经很完整。郊区的大房子看上去体面，住久了只是多了打扫的负担，死要面子活受罪。

他也曾想过要有一场体面的归来，让人记住自己的名字。后来觉得这念头有些滑稽。人最后都会被忘记，而且忘得很快。他连隔了两代的太公叫什么都说不清，却曾认真计划过让后人记住自己。

他曾给自己设定一个数字，觉得到了才算成功。后来发现，钱大多只是换个地方待着，要么进了税表，要么瞎寄把投亏个精光，很难留下什么。能把一家公司做下去，让一群人有收入，他们背后各有家庭，也算是功德一件，至于别人领不领情就随便吧。

他一度觉得自己很特别。后来发现，不过是在少数事情上做得还可以。每个人都有这样的地方，也就谈不上什么特别，区别只在于有人更早意识到这一点。

他也曾认真比较人与人之间的高低。后来才明白，有些差异来自努力，更多来自运气。很多事并不在人的掌控之内。他曾经不信命，后来发现都是命。

第一性原理

2026-03-29T17:31:00.000Z

很多人以为，所谓成长，就是积累越来越多的经验。

这当然没错。经验能帮人更快判断、更快行动，也能减少大量试错成本。问题在于，经验不仅提高效率，也会固化视角。一个人越熟悉某个行业、某种做法、某套组织流程，就越容易默认“事情本来就该这样”。

所以，很多问题并不是没人努力，而是大家太快接受了既有答案。看起来是在解决问题，实际上只是沿着旧路径做优化；看起来是在做判断，实际上只是从经验库里调出一个熟悉模板。

第一性原理的价值，就在这里。

它不是为了反对经验，也不是为了显得比别人更“底层思考”。它真正重要的地方在于：当经验不再可靠时，它能帮助我们重新回到问题本身。

什么是第一性原理

如果用尽量朴素的话来定义，第一性原理就是：

把一个问题不断往下拆，拆到那些不能再借用习惯说法、只能面对事实本身的层次，再从那里重新组织答案。

很多时候，我们并不是直接面对问题，而是在面对一层又一层被包装过的说法。比如：

用户要这个功能
行业里都这么做
市场就是这个规律
组织规模大了只能这样
成本太高，不可能做

这些话不一定错，但它们大多不是最底层的事实，而是阶段性的结论、历史路径，或者只在特定条件下成立的经验总结。

第一性原理要求我们暂停接受这些现成结论，重新追问几个更底层的问题：

我们真正要解决的问题是什么？
这个目标成立的必要条件是什么？
现在被视为“理所当然”的前提，哪些是硬约束，哪些只是惯性？
如果不沿用现有做法，是否还能从更底层的事实推出另一种方案？

换句话说，第一性原理不是“从零开始胡思乱想”，而是从更少的假设开始思考。

第一性原理的反面，不是愚蠢，而是惯性

很多人把第一性原理理解成“聪明人才能用的高级思维”。其实不是。它真正对应的反面，并不是缺少智力，而是过早接受既有框架。

人在工作里最容易出现三种偏离。

1. 把经验当真理

经验的价值在于，它让我们不必每次都从头思考。但经验一旦被误用，就会从“提高效率的工具”变成“限制可能性的边界”。

一个成熟团队最常见的表达方式是：

我们以前试过，不行
这个行业不是这么干的
用户不会为这个买单
这类需求最后都会变成那样

这些判断有时确实对，但危险在于，它们太像正确答案了，以至于很少有人继续追问：当初为什么不行？是在什么条件下不行？今天的条件变了吗？失败的是目标本身，还是实现路径？

经验最容易让人忽略的，不是事实，而是条件。

2. 把手段当目的

在产品、增长、管理里，人很容易把中间变量误认成最终目标。

比如做产品时，以为自己的任务是“上线一个功能”；做增长时，以为目标是“把转化率拉高”；做团队管理时，以为关键是“建立更严密的流程”。但这些往往都只是手段，不是目的。

真正的问题可能是：

用户想完成什么任务，而不是想要什么功能
业务到底要的是高质量收入，还是短期数字好看
团队真正缺的是协同清晰度，而不是流程数量

一旦手段被误认成目的，后续所有努力都可能非常勤奋，但方向越来越偏。

3. 把约束当天花板

现实里当然有很多约束：预算、时间、人力、技术债、组织关系、市场环境。这些都真实存在。但真实存在，不等于它们都不可被重构。

很多时候，人不是被约束打败的，而是太早接受了约束的解释方式。

比如“我们没有资源做这件事”，有时真正的意思可能是：

我们没法按原来的大方案做
现有团队不擅长这种路径
当前优先级不支持同时推进这么多事

这三句话和“完全做不了”之间，差别非常大。

第一性原理的重要一步，就是把“约束”拆开看：哪些是物理层面的硬约束，哪些是资源分配问题，哪些只是组织默认选项。

为什么成熟的人反而更需要第一性原理

新人常犯的错误，是不知道怎么做；成熟的人更常犯的错误，是太快认为自己已经知道怎么做。

经验越多，越容易形成高效的判断捷径。大多数时候，这是优势。但当环境、用户、技术和组织规模都在变化时，旧经验也会悄悄从资产变成负担。

一个人真正成熟，不是拥有更多模板，而是知道什么时候不能再依赖模板。

第一性原理在这里像一种“认知刹车”。它强迫我们在关键问题上停下来，重新确认：

我们现在优化的，到底是不是那个真正重要的问题？
当前结论，是来自事实，还是来自熟悉感？
我们以为不可动的前提，是真的不可动，还是因为已经太久没人质疑？

它不是要你在所有小事上都从头推演，而是在那些决定方向、资源配置和长期结果的关键判断上，避免被惯性带偏。

第一性原理如何改变判断

如果要把它变成一套可操作的框架，我会把它整理成四步。

第一步：重新定义真正目标

很多问题之所以越做越复杂，不是因为问题本身复杂，而是因为起点定义错了。

在开始讨论方案之前，先问一句：我们到底想得到什么结果？

这句话听起来简单，但它能过滤掉大量伪问题。

例如：

目标不是“做一个社区功能”，而是提升用户之间的信息交换效率
目标不是“提高开会频率”，而是降低跨团队协同的失真成本
目标不是“把价格打下来”，而是用更可持续的方式提高用户感知价值

当目标被重新表述后，很多原本显得理所当然的方案，会立刻失去必然性。

第二步：拆掉默认前提

接着要问的是：我们现在认定为真的东西，哪些只是默认前提？

例如：

用户必须经过这条流程
这个产品必须长成这样
这类业务只能靠投放增长
组织一大就必须层层审批

这里最有价值的动作，不是马上反驳，而是把前提一条条写出来，再分别审视：

它是事实，还是经验总结？
它在什么条件下成立？
如果条件变化了，它还成立吗？
如果拿掉这条前提，会出现什么新可能？

很多所谓创新，并不是得到了神秘灵感，而只是有人愿意重新检查那些大家默认不再检查的前提。

第三步：区分硬约束和软约束

不是所有限制都一样。

硬约束是那些短期内无法绕开的事实，比如物理规律、明确的法律要求、账户现金流、系统当前承载上限。软约束则往往是阶段性形成的，比如组织分工、流程设计、预算分配、团队认知、历史系统结构。

这两者如果不分开，团队就很容易把“现在不方便做”误判成“根本不可能做”。

第一性原理不是忽视约束，而是要求我们把约束分类。只有分类之后，判断才会更准确：

硬约束决定边界
软约束决定优先级和改造成本

很多突破，本质上都发生在软约束被重新定义的那一刻。

第四步：回到事实和机制，重新构造方案

当前提被拆开、目标被澄清、约束被分类之后，才轮到方案设计。

这时的提问方式会发生变化：

用户完成这件事最小需要哪些条件？
价值是如何被产生的，阻力又是在哪里出现的？
哪个环节是真正的瓶颈？
如果不沿用现在的组织方式、产品形式、商业路径，还有没有更直接的实现方法？

从这个阶段开始，方案才真正建立在事实和机制上，而不是建立在熟悉路径上。

那些看似朴素的话，为什么往往更接近底层

很多人接触第一性原理，容易把它想得很抽象，仿佛必须借助复杂概念才能表达。其实真正接近底层的判断，往往都很朴素，甚至朴素到像一句“常识”。

比如这些话：

攒钱就是改运
早睡就是续命
读书就是开悟
自律就是破局
认知就是出路
行善就是积德
闭嘴就是避灾
独处就是修心

这些表达之所以容易打动人，不是因为它们华丽，而是因为它们都在做同一件事：绕过中间层的包装，直接指向更底层的因果。

“攒钱就是改运”，本质上不是在夸奖节省，而是在强调现金流和选择权；“早睡就是续命”，不是在贩卖自律焦虑，而是在承认身体是所有长期行动的基础设施；“读书就是开悟”，不是把阅读神圣化，而是在说一个人的判断边界，很大程度上受限于他接触过多少高质量思想。

再往下看，“自律就是破局”说的是人能否摆脱即时反馈的控制；“认知就是出路”说的是你能看见什么，就大致决定了你能走到哪里；“闭嘴就是避灾”提醒的是表达成本和情绪成本；“独处就是修心”则是在说，一个人如果不能和自己稳定相处，就很难建立真正稳固的内在秩序。

这些话未必在任何场景里都百分之百成立，但它们提供了一种很有价值的训练：不要只盯着表面动作，要继续往下问，这个动作真正改变的底层变量是什么。

从这个角度看，第一性原理并不总是表现为宏大的推演。很多时候，它只是把一句原本说得很直白的话，重新看出它背后的结构。

三个典型案例

案例一：用户要的真的是功能吗

产品团队很容易把用户表达，直接翻译成功能需求。

用户说想要“导出”“筛选”“标签”“提醒”“协作”“看板”，于是团队开始排需求、定交互、做迭代。最后功能做出来了，用户却未必更满意。因为用户真正想要的，通常不是某个功能，而是某个结果。

比如一个用户说“我需要标签系统”，表面上看是在要一个功能，底层可能是在表达三种完全不同的需求：

我需要更快找到信息
我需要把不同类型的任务区分开
我需要和别人共享同一种分类方式

如果不往下拆，团队会默认“标签”就是答案；一旦回到第一性原理，就会发现问题其实是“信息组织效率”和“协同一致性”。于是可行方案未必只有标签，也可能是搜索优化、默认视图、智能分类、模板化分组，甚至只是更清晰的信息架构。

这里最容易犯的错，就是把用户提出的方案，当成用户真正的需求。

第一性原理提醒产品人：用户最知道自己哪里不舒服，但不一定最知道系统应该怎么设计。

案例二：行业共识真的不可挑战吗

创业和业务判断里，行业共识经常被当作隐形边界。

比如有人会说：

这个市场只能靠补贴启动
高客单价产品必须靠销售驱动
内容平台一定要先做规模，再做商业化
这个品类的毛利决定了你只能这样运营

这些话可能都来自真实案例，但真实案例不等于普遍真理。行业共识往往是历史条件、成本结构、技术限制、渠道结构共同作用的结果。一旦底层条件变化，原有共识就可能失效。

第一性原理的问法会是：

用户为什么愿意付费？
交易成本到底发生在哪一环？
信任是靠什么建立的？
价值交付的最小闭环是什么？

当问题被拆到这个层面，你会发现很多所谓“行业规律”，其实只是上一代条件下的最优解，而不是永恒解。

创业里真正重要的，不是盲目反常识，而是识别：到底是规律本身不可违背，还是我们只是在沿用旧世界的解法。

案例三：团队管理要的真是更多流程吗

团队一旦变大，管理动作通常会迅速增加：更多会议、更多汇报、更多审批、更多同步机制。这些动作表面上是在提升管理能力，实际上常常只是对混乱的一种补偿。

如果从第一性原理出发，管理问题首先不是“要不要加流程”，而是：

当前失控到底发生在哪里？
是目标不清、职责不清、信息滞后，还是决策权分布失衡？
我们要解决的是失误率、协同成本，还是责任不清？

如果根因是目标不一致，那么加流程的效果可能有限；如果根因是信息透明度不足，那么更频繁的会议未必是最优解；如果根因是决策权和责任不对齐，那么审批层级越多，反而越慢。

很多组织问题不是“缺流程”，而是没有先分清楚：流程是在替代清晰，还是在放大混乱。

所以成熟的管理判断，不是本能地给系统加控制，而是回到系统失效的最小原因上。

第一性原理不是万能方法，而是关键时刻的校准工具

讲到这里，一个常见误解也需要澄清：第一性原理并不意味着所有事情都必须从零思考。

如果一个问题已经高度成熟、反馈明确、变化很小，那么直接借用经验通常是更高效的做法。没有必要在每一次细小决策上都重新拆解世界。那样不仅成本过高，也会让组织失去执行速度。

第一性原理真正适合的，是这几类场景：

你发现大家都很努力，但结果长期没有改善
你感觉讨论始终围绕方案，没人重新定义问题
你发现团队高度依赖经验，但环境已经明显变化
你隐约意识到某个“常识”正在限制判断空间

在这些时刻，第一性原理像一个校准工具。它不会自动给出答案，但会帮你清掉错误前提，让你重新看见问题。

成熟的人不是不用经验，而是能在经验和本质之间切换。

该借经验时借经验，因为效率重要；该回到底层时回到底层，因为方向更重要。

结语

第一性原理最珍贵的地方，不在于它听起来更高级，而在于它能逼着人承认一件事：我们平时很多所谓“理所当然”的判断，其实只是被继承下来的解释。

经验当然重要，但经验只能告诉我们过去怎样成立，不能保证未来仍然如此。真正拉开差距的，往往不是谁掌握了更多现成答案，而是谁愿意在关键时刻暂停惯性，重新追问：

这件事真正要解决什么？
我们现在相信的，到底是事实，还是习惯？
如果把旧答案暂时拿掉，还能不能从更底层重新推出新的判断？

第一性原理并不会让人自动变得更聪明，但它会让人的思考更诚实。

说到底，所谓成熟，不是掌握越来越多漂亮说法，而是越来越能穿过说法，看见底层变量；不是越来越会引用经验，而是越来越知道什么时候必须回到事实本身。

在复杂的产品判断、业务决策和组织管理里，诚实地面对问题本身，往往就是更好答案的起点。

AI 工具选型 & 个人实践方式

2026-03-20T00:00:00.000Z

关于 AI 工具选型 & 个人实践方式

为准备下单心仪工具的同学，提供取舍攻略参考

主流工具对比

三种方式对比：官方订阅（Claude Code + Codex） / API 中转服务 / Antigravity等 IDE 集成

个人主观判断，非客观标准

价格友好方面，Antigravity ＞中转服务＞官方订阅
- 假设可报销的费用一定，那能否榨干剩余价值是一门学问
灵活性上，中转服务 > 官方订阅 > Antigravity
- 中转服务可配置 Claude 和 Codex
编程能力上，官方订阅 > 中转服务 > Antigravity
- 官方订阅自带的生态最优
- 中转服务因为号池缓存命中率的问题，会低于官方订阅
账号稳定性上，Antigravity > 中转服务 > 官方订阅
- 官方订阅需要处理：购买渠道、访问线路
- 中转服务存在跑路情况
使用稳定性上，中转服务 > Antigravity > 官方订阅
- Retrygravity，老生常谈
- 官方订阅存在访问网路问题
上手易用性上，Antigravity > 中转服务 > 官方订阅
- 中转服务通常具备一键配置的 shell 脚本
- Antigravity 开箱即用

踩过的坑 & 一些经验

价格成本上

Antigravity Ultra 通过家庭组六人均摊，成本预计 300¥，再通过前期打半价的手段，成本能降低到 150¥
- 禁止反代
- 每个谷歌账号需保持 location => 美国
- 需要确保家庭组去续费的渠道，为国外渠道
中转服务
- 个人日常使用，每日额度预计需要 70$，换算到具体的中转服务套餐费用上，即 500¥/月左右
官方订阅
- 没有可操作空间

在解决官方订阅的购买渠道和访问线路问题上

购买渠道：Apple渠道卡、国内 visa 卡折转 Google Play ，这两种方案会被封
- 香港卡不行
- 国外信用卡，目前是相对稳定的解
访问线路：为解决纯净 IP 的问题，通过机场 + vps 落地（价格友好 + 处理简单）
- 但是会影响自身的访问网速，体感明显

命题：魔高一尺，道高一丈

举个例子：官方可通过筛选在东八区时区使用频繁的账号，可进一步锁定国区选手

在 Claude 严厉打击国内使用的背景下，个人觉得无论怎么绕后门，对方都有反制措施（Claude 本身不在乎退款），只能寄希望于官方本身松口 —— 类似 GPT睁一眼闭一眼

中转服务的小tips

优先考虑稳定性 + 建站时间长（择取原则，类似机场）
好的中转服务，是支持开发票的
最好采购两到三个备用
速率原因，建议主力使用 Codex（0.25 ：1）/ 对比 Claude 普遍（1:1.3）
- 因为 GPT Team 封号情况相对 Claude 缓解很多

个人抉择

个人的使用诉求如下：

希望既能用 Codex，也能用 Claude
- Codex 和 Claude 能互相审阅对方，不会出现独断专裁
  - 使用场景：Codex 跑方案，Claude 核查；反之亦然
上手易用性和稳定性

最后选择了 ++API 中转服务 + Antigravity 丐版++

丐版指的是，不用 Antigravity 来进行 VibeCoding，只用来当 IDE 查阅代码
- 为什么不用 VS Code？因为未来还有购买 Antigravity Ultra 账号的可能（属于 Plan B）
中转服务购买两个
- 鸡蛋不放一个篮子里

API中转服务相关

API 中转服务介绍：AI API 中转服务深度解析
各中转服务网站概览 & 评测：https://www.helpaio.com/transit、https://www.getcheapai.com/zh-cn
个人使用的中转服务：
- sss-ai（支持包月、支持开票-低消 100）
- packy-code（按量付费、支持开票-低消 500）
sss-ai 使用举例
- 如图，通过 shell 脚本，将 token 写入环境变量，可实现一键安装
服务来回切换的配置异常问题
场景：使用 a 服务，然后要切换 b 服务，后面又切回 a 服务
原因：因为中转服务的配置，通常是 shell 脚本一键覆盖，可能会将自身已经存在的服务覆盖掉，在 a、b 来回切的过程中，环境变量可能存在冲突
解决方式：修改 agent 的全局配置，如 .codex/auth.json中，查看实际生效的 provider，进行修改

个人日常使用姿势

Antigravity IDE + Claude Code 插件 + Codex 桌面端：

使用 Codex 处理编程任务，多个代码仓库并行跑任务
1. 任务两遍没过，就用 Claude 审阅
复杂问题使用 Claude Code 插件
1. 插件是在 IDE 插件市场可下载
出现多次 work error 的场景，使用 Claude 跟 Codex 互相审阅
1. 《双方来打辩论赛》
把 Antigravity 自带的 Gemini 当谷歌用

关于 Codex、Claude 二者的配置同步

使用 AI 来帮我完成，例如 prompt: 把当前 Claude code 的全局 rules 、mcp 和 subagent 配置同步到 Codex 中

关于 Claud Code 的使用（推荐）

参阅这篇文章：《你不知道的 Claude Code：架构、治理与工程实践》-- 推特（由浅入深，干货满满）

建议学下其中的优化手段，这样对 VibeCoding 有帮助
关注其中 SKILL 的使用：npx skills add tw93/claude-health，用以优化自身的 Claude

个人的 Claude 全局 rules

其中特色点：

预处理：是否 plan、是否 subagent
- subagent 会相对更耗 token，需酌情
任务留存：关注其中的 lessons 和 task 生成逻辑
- 类似简化版本的 SDD 方案
安全：key、secret 隔离

# ⚠️ 强制执行规则（CRITICAL — 每次任务必须遵守）

## 任务开始前的强制检查（不可跳过）

收到任何任务后，**第一步必须**在心中过以下检查清单，并在回复开头说明判断结果：

[ ] 是否需要进入规划模式？（见下方判断标准）
[ ] 是否需要用子智能体并行处理？
[ ] 完成后如何验证结果？


### 「简单任务」白名单（以下情况才可跳过规划）
- 只修改 3 个以内文件的单行或少量改动
- 纯解释类、问答类请求（不写代码）
- 明确且无歧义的单步操作

**除上述情况外，所有任务都视为非简单任务，MUST 进入规划模式。**

---

# 工作流编排

### 1. 规划节点（MUST 执行）
- **MUST**：凡不符合「简单任务白名单」的任务，必须先进入规划模式
- **MUST**：一旦出现问题，立即停止并重新规划，禁止强行推进
- **MUST**：规划模式同样用于验证环节
- **MUST**：提前编写详细规格，减少歧义

### 2. 子智能体策略（MUST 执行）
- **MUST**：调研、探索、并行分析类工作，交给子智能体处理
- **MUST**：复杂问题通过多个子智能体增加算力投入
- **MUST**：每个子智能体只专注一个方向，聚焦执行
- 保持主上下文窗口简洁

### 3. 自我优化循环（MUST 执行）
- **MUST**：收到用户任何修正后，立即将规律写入 `tasks/lessons.md`
- **MUST**：每次项目开始前，回顾 `tasks/lessons.md` 中的相关经验
- 持续迭代规则，直到错误率下降

### 4. 完成前验证（MUST 执行）
- **MUST**：未验证可用前，禁止标记任务完成
- **MUST**：自问「资深工程师会认可这段代码吗？」
- **MUST**：运行测试、查看日志、证明逻辑正确

### 5. 追求优雅（平衡版）
- 非简单修改：停下来思考「有没有更优雅的写法？」
- 如果修复方案感觉很别扭：实现优雅方案
- 简单明确的修复可跳过，不要过度设计
- 展示成果前，先严格自检

### 6. 自主修复 Bug（MUST 执行）
- **MUST**：收到 Bug 报告直接修复，无需用户一步步引导
- **MUST**：定位日志、错误、失败用例，然后解决
- **MUST**：主动修复 CI 失败测试，无需详细指令

---

# 任务管理（MUST 执行顺序）

1. **先规划**：将计划写入 `tasks/todo.md`，列出可勾选项
2. **验证计划**：开始实现前先确认方案
3. **跟踪进度**：完成一项立即标记一项（不批量标记）
4. **说明变更**：每步给出概要总结
5. **记录结果**：在 `tasks/todo.md` 中添加评审章节
6. **沉淀经验**：修正后立即更新 `tasks/lessons.md`

---

# 核心原则

- **简洁优先**：每次修改尽可能简单，影响代码最小化
- **拒绝敷衍**：定位根因，不做临时修复，按资深工程师标准要求
- **最小影响**：只修改必要部分，避免引入新 Bug

---

# 注意事项

- 确保使用中文进行回复、回答
- 输出代码时，在代码的关键位置请添加注释，说明代码的用途
- 创建项目的时候，需要同步创建 .gitignore 文件（如果已经存在则忽略）
- 如果需要生成文档，默认 md 格式，默认保存到 doc 目录（README.md 除外），如果目录不存在则新建目录
- 在做技术方案的调研或者复杂链路的分析时，默认生成一个流程图或者时序图或者架构图，来加以说明
- 出现生成图片的场景，默认使用 svg 格式生成图片

---

# 安全规范（MUST 执行）

### 凭证检查（每次任务开始前）
- **MUST**：发现任何含 `secret` / `token` / `key` / `password` 字样的本地配置文件（如 `.env`、工具本地配置），立即检查是否已加入 `.gitignore`；未加入时先警告，再继续任务
- **MUST**：禁止将凭证字面量写入工具命令白名单中；密钥统一通过环境变量引用（`$SECRET_KEY`）
- **MUST**：`git add` 前检查暂存区是否包含敏感文件；若包含，立即停止并告知用户

### tasks 文件保护
- `tasks/` 目录的内容跨会话累积，切换分支前提醒用户确认 `tasks/lessons.md` 已保存

AI API 中转服务深度解析：架构、风险与工程实践

2026-03-06T00:00:00.000Z

本文起源于 V2EX 社区帖子 AI 中转站黑话大全整理（作者 v2exgo），在原帖内容基础上做了大量扩展和深入分析，面向专业研发人员，系统梳理 AI API 中转服务的技术架构、主流方案对比、安全风险评估与工程实践指南。

一、AI API 中转服务概述

1.1 什么是中转服务

AI API 中转服务（Relay / Proxy Service），本质上是一个 API 网关（API Gateway），充当客户端应用与上游 AI 模型提供商（如 OpenAI、Anthropic、Google 等）之间的中间层。其核心工作流程：

Client App → [中转服务] → 上游 AI API Provider（OpenAI / Anthropic / Google ...）
                ↑
        请求转发、密钥注入、
        格式转换、负载均衡、
        计费计量、缓存优化

中转服务存在的技术背景：

网络封锁：国内无法直接访问 api.openai.com、api.anthropic.com 等 endpoint
支付壁垒：国际信用卡（Visa/Mastercard）绑定困难，部分平台不支持国内银行卡
合规限制：部分 AI 服务商 ToS 明确限制特定地区的 API 访问

中转服务通过在海外部署代理节点，将请求透传到目标 API，再将响应返回给国内客户端，解决了上述痛点。

1.2 中转服务的技术架构

一个典型的中转站技术架构如下：

核心模块说明：

模块	职责	技术实现
Auth 鉴权	验证客户端 API Key，鉴权计费	JWT / API Key 校验
Router 路由	根据模型名称路由到对应渠道	模型名映射 + 优先级/权重策略
Channel Pool	管理多个上游 API 账号/密钥	连接池 + 健康检查 + 自动故障转移
计费模块	Token 计量、余额扣减	基于 `usage` 字段的流式/非流式计费
负载均衡	跨渠道分发请求	加权随机 / 轮询 / 优先级

1.3 产业链结构

二、主流中转服务方案

2.1 开源自建方案

以下是目前社区最主流的开源中转站项目：

项目	技术栈	核心特性	GitHub Stars
One-API	Go + React	统一 OpenAI 格式接口，支持 30+ 模型提供商，三层倍率体系，多机部署	30k+
New-API	基于 One-API 二开	在 One-API 基础上增加 Midjourney/Suno 集成、缓存计费、企业级特性	19k+

One-API / New-API 的倍率体系：

1	最终扣费 = (input_tokens + output_tokens × 补全倍率) × 模型倍率 × 分组倍率

模型倍率（ModelRatio）：不同模型的基础计费倍数，基准为 $0.002/1K tokens = 1 倍
补全倍率（CompletionRatio）：输出 token 相对输入 token 的价格倍数
分组倍率（GroupRatio）：针对不同用户组的差异化倍率

💡 衍生建议： 对于高频、需要超长上下文的新一代 AI 编程工具（如 Claude Code），直接开通官方的订阅（如 $20/月的 Claude Pro）往往比在中转站被层层收取高额的输入、输出、缓存费用更便宜，且减少被封号或遇到模型被降智的风险。

2.2 商业中转服务

市面上也有大量商业化运营的中转站，通常提供：

预充值余额 + 按量计费
人民币支付（微信/支付宝）
多模型一站式接入
客服/技术支持

选择商业中转站的核心考量：

维度	评估要点
价格透明度	倍率是否公开？是否存在隐藏费用（汇率差、通道费）？
渠道来源	官方 API Key vs 逆向工程 vs Azure 企业版？
SLA 保障	是否承诺可用性（如 99.9%）？是否有故障补偿？
合规性	是否提供发票？数据是否过境？是否有隐私协议？

2.3 企业级 LLM Gateway

对于有更高要求的企业场景，有专业的 LLM Gateway 方案：

方案	定位	特色
Cloudflare AI Gateway	网络原生 AI 网关	缓存、重试、分析、全球 CDN 加速
Kong AI Gateway	企业 API 管理	插件生态、RBAC、审计日志
LiteLLM	开源 Python Proxy	100+ LLM API 统一为 OpenAI 格式
Bifrost (Maxim AI)	高性能 AI 网关	11000+ 模型、语义缓存、自动故障转移

三、中转服务 vs 官方 API 对比

3.1 技术差异

3.2 响应格式差异

正规中转站会完整透传官方 API 的响应格式，但部分低质量中转站可能存在以下问题：

// ❌ 常见问题：usage 字段缺失或不准确
{
  "choices": [...],
  "usage": null  // 部分中转站不返回 usage，导致客户端无法统计 token
}

// ❌ 常见问题：流式响应断裂
// SSE stream 中 chunk 丢失或延迟
data: {"choices":[{"delta":{"content":"Hello"}}]}
// ... 长时间无响应 ...
data: [DONE]

// ❌ 常见问题：模型名映射错误
// 请求 claude-3.5-sonnet，实际路由到 claude-3-haiku

四、如何识别是否在使用中转服务

作为开发者，你可能需要确认你（或你的团队成员）使用的 API 是否为官方直连。以下是几种检测方法：

4.1 检查 Base URL

最直接的方法——看 SDK 配置中的 base_url：

# 官方直连
client = OpenAI(
    api_key="sk-xxx",
    base_url="https://api.openai.com/v1"  # ✅ 官方
)

# 中转服务
client = OpenAI(
    api_key="sk-xxx",
    base_url="https://some-relay.example.com/v1"  # ⚠️ 第三方
)

注意检查环境变量：

# 检查是否被环境变量覆盖
echo $OPENAI_API_BASE
echo $OPENAI_BASE_URL

# 常见的 IDE 插件（如 Cursor、Continue）配置文件
cat ~/.cursor/config.json
cat ~/.continue/config.json

4.2 HTTP 响应头分析

通过 curl 直接检查响应头：

1 2	curl -sI https://your-api-endpoint/v1/models \ -H "Authorization: Bearer sk-xxx" \| head -20

官方 API 典型响应头：

server: cloudflare
cf-ray: xxx-LAX
openai-organization: org-xxx
openai-processing-ms: 150
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499

中转服务可能出现的响应头特征：

server: nginx                    # 非 cloudflare
via: 1.1 relay-proxy             # Via 头暴露代理
x-forwarded-for: xxx             # 转发头
x-real-ip: xxx                   # 真实 IP 头
# 缺少 openai-organization 头
# 缺少 x-ratelimit-* 头
# 可能出现自定义头如 x-relay-channel 等

4.3 DNS / IP 分析

# 解析目标域名的 IP
dig +short your-api-endpoint

# 查看 IP 归属
whois $(dig +short your-api-endpoint) | grep -i org

# 官方 OpenAI API 通常解析到 Cloudflare 的 IP 段
# 中转站通常解析到 VPS 提供商（如 AWS、GCP、阿里云等）

4.4 API Key 格式鉴别

API Key 格式	说明
`sk-proj-xxx...`	OpenAI 官方项目密钥
`sk-svcacct-xxx...`	OpenAI 服务账号密钥
`sk-ant-xxx...`	Anthropic Claude 官方密钥
`sk-` + 短字符串	很可能是中转站自行签发的密钥

五、如何评估中转服务的稳定性与可靠性

5.1 核心评估指标

指标	测试方法	合格基准
可用性（Uptime）	持续拨测 `/v1/models` endpoint	≥ 99.9%（月宕机 ≤ 43 分钟）
响应延迟（Latency）	轻量请求（max_tokens=1）多次采样	P95 ≤ 2s，额外代理延迟 ≤ 300ms
流式首 Token 延迟（TTFT）	流式请求首个 chunk 到达时间	≤ 3s
错误率（Error Rate）	统计 4xx/5xx 响应比例	≤ 0.5%
模型一致性	请求特定模型，验证返回的 `model` 字段	100% 匹配请求模型
Token 计费准确性	对比中转站扣费与 `tiktoken` 预估	偏差 ≤ 5%

5.2 模型真实性验证

部分不良中转站存在模型降级行为——请求 claude-3.5-sonnet 但实际路由到更便宜的模型。以下是几种检测思路：

# 方法 1：检查响应中的 model 字段
response = client.chat.completions.create(
    model="claude-3-5-sonnet-20241022",
    messages=[{"role": "user", "content": "What model are you?"}]
)
print(f"请求模型: claude-3-5-sonnet-20241022")
print(f"响应模型: {response.model}")  # 应完全匹配
print(f"回答内容: {response.choices[0].message.content}")

# 方法 2：利用模型特有能力进行验证
# 例如测试视觉能力、长上下文窗口、特定知识截止日期等

# 方法 3：对比输出质量基准
# 使用标准化 benchmark prompt 对比官方 API 与中转的输出质量

5.3 渠道类型甄别与“掺假”行为

中转站的渠道来源直接影响稳定性和合规性。常见渠道类型：

渠道类型	说明	稳定性	价格	风险
官转（Official）	使用正规付费的官方 API Key	⭐⭐⭐⭐⭐	高（≥1x 倍率）	低
AZ 转（Azure）	通过 Azure OpenAI Service 转发	⭐⭐⭐⭐	中高	中低
逆向（Reverse）	逆向工程免费/付费版 Web 接口	⭐⭐	低（0.1x-0.5x）	高，随时可能失效
号池（Account Pool）	批量注册试用账号的 API 额度	⭐⭐⭐	低	中高，账号可能被封

⚠️ 警惕“官逆混用/掺假”： 不良中转站会在官方渠道耗尽或不可用时，静默切换至低质的逆向渠道（即“官方挂了换逆向”或“白天并发用官转，晚上用逆向”）。这就导致即使接口可用，模型的智商、长上下文响应能力和 Tool Calling 能力也可能出现严重衰退。

5.4 隐形计费考量：缓存率（Cache Rate）的魔力

在比较多家中转站的价格时，绝不能只看表面的“大模型倍率”或单价。当前如 Claude Code 等重度依赖长上下文缓存的应用，价格构成公式应当是：
总费用 = (Input + Output + Cache Write + Cache Read) × 倍率

为何缓存率极其重要：

新一代工具极其依赖 Context Caching。
劣质中转站的**缓存率（Cache Rate）**可能只有 30%，甚至根本无法透传真实的缓存；而优质一线的官转服务缓存率能稳定在 80%~85% 以上。
缓存率差 10%，实际支出的真金白银可能翻倍。 原本以为很便宜的低倍率渠道，因为没有有效利用缓存，实际花费远超高单价的高缓存率渠道。

5.5 持续监控建议

# 建议部署持续拨测脚本，关键监控维度：
监控项:
  - endpoint: /v1/chat/completions
    interval: 5m
    timeout: 30s
    alerts:
      - condition: error_rate > 1%
        action: notify
      - condition: p95_latency > 5000ms
        action: warn
      - condition: model_mismatch
        action: critical

六、中转服务的安全隐患

⚠️ 这是使用中转服务时最需要关注的问题。 即使中转站价格诱人、稳定性良好，安全风险也不容忽视。

6.1 核心威胁模型

6.2 无法回避的“HTTPS 中间人攻击”本质

所有通过中转站的请求内容对中转站运营者绝对明文可见。
不论中转站宣传采用了多少安全防护，从技术原理上说，中转服务本质就是一个 HTTPS 中间人（MITM）。为了做路由分发与计费计量，网关层必然要先解密请求。这意味着：

你发送给 AI 的代码片段、数据库 schema、内部文档、聊天隐私都在裸奔。
你在 prompt 中无意包含的环境变量、配置信息可能被轻易提取。
现代 AI 编码助手（如 Cursor、Windsurf、Claude Code）会自动将海量项目代码上下文发送到 API。

6.3 防护措施的局限性与终极建议

网络上经常有人推荐通过配置忽略文件来防护，但这种防护往往给人一种虚假的安全感。

客户端侧配置（效果有限，仅能减小暴露面）

# 配置 .cursorignore / .claudeignore
echo ".env" >> .cursorignore
echo "*.pem" >> .cursorignore
echo "credentials/" >> .cursorignore

⚠️ 为什么说它有限： 这些手段仅能阻止 AI 工具主动去读隐藏文件。但它阻止不了你在对话窗手动粘贴包含了密钥的内容，也阻止不了你代码文件中硬编码的密钥被发送。只要数据上了 prompt 请求体，中转站就完全可见。

终极建议：敏感项目不走中转

这是唯一彻底的解决方案：面对涉及核心商业机密、私钥/证书环境或高价值私有代码库的项目，唯一的安全方案是不走任何第三方中转，只走官方直连（或使用云厂商企业级私有化部署的 API 如 Azure OpenAI、AWS Bedrock）。

架构侧防护

推荐架构：在自有服务器上部署 API Gateway，自行管理上游密钥

Client → [自建 Gateway] → 官方 API
           ↑
     密钥加密存储
     请求日志审计
     敏感信息过滤

防护措施	说明	优先级
密钥隔离	不同环境（dev/staging/prod）使用独立密钥	P0
请求审计	记录所有 API 请求的元数据（不含内容）	P0
敏感信息过滤	在客户端侧过滤掉 prompt 中的密钥/密码	P0
TLS 校验	确保客户端严格校验中转站的 TLS 证书	P1
最小权限	API Key 仅授予必要的模型访问权限	P1
预算告警	设置余额/用量告警，防止异常消耗	P1
定期轮换	API Key 定期更换	P2

6.4 合规性考量

数据出境：请求数据发送到海外中转节点，可能涉及《数据安全法》《个人信息保护法》中的数据出境条款
服务资质：大部分中转站无 ICP 备案、无增值电信业务经营许可
税务合规：预充值模式通常无法提供正规发票
知识产权：Anthropic 等厂商在其报告中明确指出，商业代理服务可能被用于非法模型蒸馏

七、行业黑话速查表

术语	含义
刀	虚拟美刀，通常 1 元人民币 = 1 刀（非真实汇率）
倍率	模型价格系数，官转 ≈ 1x，逆向通常 0.1x-0.5x
官转	使用官方正规 API Key 的中转渠道
AZ 转	通过 Azure OpenAI Service 中转
逆向	逆向工程 Web 版/App 版的非公开 API
号池	批量注册的试用/免费 API 账号池
官逆混用	宣称是官转，实则掺假混入低成本的逆向渠道来获利
缓存创建	Cache Write，发送给大模型处理并创建缓存的 Token
缓存命中	Cache Read，已命中缓存的输入内容，价格极低
跑量	在中转站消耗的 token 总量
渠道	中转站配置的上游 API Key/Provider
分组	中转站内的用户等级/权限组
补全倍率	输出 token 相对输入 token 的价格比

八、总结与建议

核心原则

中转服务本质是用安全性换取便利性和低价。在使用时，务必明确风险边界：真正的商业机密绝不过中转，能走官方/云平台企业版的必须走正规渠道。

面向个人使用

日常开发/学习：中转服务是务实的降本选择，建议多参考近期排名的评测数据。
高频重度用户：如果重度依赖 Claude Code 这种耗费 Context 的工具，直接购买官方 Max20/Pro 订阅套餐可能比在中转站被反复收取缓存费更经济，且能完全杜绝封号风控。
安全底线：配好 ignore 文件是必要的基础，但更重要的是养成不在对话中随意发送包含认证信息文本的习惯。

面向企业使用

需要考虑的因素更多，包括：

自建方案：使用 One-API / New-API 自建中转站，自行管理上游 API Key
合规要求：涉及用户数据的场景
监控体系：需要全链路监控，覆盖可用性、延迟、模型一致性、计费准确性

OpenAI 翁家翌访谈调研报告

2026-02-13T14:14:29.000Z

1. 嘉宾背景与核心贡献

翁家翌（Jiayi Weng）于 2022 年加入 OpenAI，是 GPT 系列模型（从 GPT-3.5、GPT-4 到 GPT-5）背后的核心贡献者之一。他在访谈中被定义为“把模型做得更强的人”，其核心贡献集中在以下三个领域：

强化学习（Reinforcement Learning）：负责模型对齐与性能提升的关键算法实现。
后训练（Post-training）：主导预训练之后的微调与优化流程。
基础设施（Infra）：构建高吞吐量的 RLHF（基于人类反馈的强化学习）流水线和工具。

2. 个人成长与价值观：投资未来与打破信息差

翁家翌的成长路径展现了一种极强的“投资未来”意识和对“影响力（Impact）”的追求：

早期启蒙：初中时便超前学习高中数学和微积分，建立“知识树”以实现高效解题。他认为这种超前学习是对未来选择权的投资。
清华时期：在清华大学就读期间，他将自己的所有课程作业和资料开源到 GitHub。他认为“信息平权”比捐款更有价值，旨在打破因信息差导致的效率低下。
开源哲学：他开发了强化学习框架 Tianshou（天授） 和签证查询系统 tuixue.online。他将开发实用工具视为一种“慈善”，追求的是工具被广泛使用所带来的社会影响力。

3. OpenAI 的技术洞见：工程与 Infra 的核心地位

访谈深入探讨了大模型开发背后的技术逻辑，打破了“算法至上”的迷思：

Infra 是第一生产力：翁家翌强调，在大模型工业界，基础设施的迭代速度决定了 AGI 的实现速度。他认为“修 bug 的数量决定了模型的质量”，工程能力的上限往往就是研究能力的上限。
RLHF 的挑战：在 2022 年加入 OpenAI 时，RLHF 仍面临巨大的工程挑战。他参与构建了工业级的 RL Infra，解决了高吞吐量下的模型对齐问题。
学术界与工业界的脱节：他指出学术界过度关注在小型 Benchmark 上的调参，而工业界需要解决的是真实世界的规模化问题。

4. OpenAI 内部视角：组织架构与人才密度

作为风暴中心的一员，翁家翌分享了 OpenAI 内部的运作细节：

人才密度与组织：OpenAI 拥有极高的人才密度，组织架构强调 Context Sharing（上下文共享），即信息在内部的高效、无损流通，这是保持创新的关键。
Sam Altman 事件：从内部视角回顾了 Sam Altman 被开除又回归的经历，展现了公司在动荡中的韧性。
竞争压力：面对 DeepSeek 等新兴竞争对手，他认为真正的威胁在于对方的迭代速度和基础设施效率，而非单纯的榜单成绩。

5. 对 AGI 与未来的哲学思考

访谈最后上升到了对人类命运和 AI 终局的思考：

AGI 的定义：他认为 AGI 的定义在 OpenAI 内部也是模糊的，但其实现将取决于 Infra 的吞吐效率。
AI 管理组织：他预测未来组织可能由拥有“无限 Context”的 AI Agent 管理，以解决人类协作中的信息损耗瓶颈。
宿命论与自由意志：翁家翌持有一种实用主义的宿命论观点。他认为世界可能是确定的，但他选择“假装自由意志存在”，并专注于解决可验证的技术问题。

互联网已死，Agent 永生

2026-02-11T00:00:00.000Z

📋 声明 - 本文为转载文章
🔗 原文链接：https://x.com/oran_ge/status/2020649409521041502

2026 年，旧地图已碎，新大陆已现。

引

最近有个感觉，越来越强烈：在互联网时代学的东西，全部都已经过时了。

DAU 过时了。SaaS 过时了。注意力经济已经死了。工具到平台的路径走不通了。
"AI 应用"和"出海"这两个词，在 Agent 范式下都是逻辑谬误。

过去的一切，都建立在一个正在消失的前提之上：人是软件的用户。
而新世界的前提变了：Agent 才是软件的新主人。

所以我决定拿起刀，砍掉六张过时的旧地图。

Part 1：互联网已死 —— 斩断旧范式的六刀

第一刀：DAU 已经严重过时

上一个时代，DAU 是资产；这个时代，DAU 是负债。

微信是网状拓扑：每多一个人，网络效应指数级增长，成本几乎不增。
AI 是星型拓扑：每多一个用户，就要多烧一份推理成本。

没有网络效应，只有 ROI 算账。ChatGPT 在烧钱扩规模，而 Claude 已经拒绝广告逻辑。

第二刀：从工具到平台的路径已经堵死

别再想投出一个 “AI 抖音” 了。
旧逻辑是：工具 -> 社区 -> 平台。
但 AI 时代，工具本身足够强，“人帮人”的社区价值基础已经坍塌。当 AI 能直接给你完美结果时，你不需要看别人怎么用，你只需要它帮你做好。

第三刀：SaaS 没死，但主人换了

旧世界：2B 或 2C，围绕“人怎么用软件”展开。
新世界：2A (To Agent)。Agent 才是 API 的重度调用者。

软件公司将变成 Agent 的基础设施。Agent 会自己看文档、学操作，百倍速于人类。

第四刀："AI 应用"这个词就是错的

"应用"这个词天然暗示了使用者是人。当你试图设计交互、留存时，你是在为旧车换引擎。
不要服务人，服务 Agent。

第五刀：注意力经济已死

注意力经济：抢夺用户时间，零和博弈，让你沉迷。
生产力经济：交付结果效率，正和游戏，让你解放。

一个是让你花更多时间，一个是让你花更少时间拿到更好结果。

第六刀："出海"是一个过时的词

在 Agent 的世界里，没有国界，没有海。
你不需要去适配国外的 UI 或推广，你只需要把 API 做好，把文档写清楚，全世界的 Agent 都能瞬间找到你。你需要的不是出海，是接入新世界。

Part 2：Agent 永生 —— 奠定未来的四块基石

第一块基石：Token 是新时代的特权

算力的马太效应已经开启。
Opus 4.6 随着上下文增加反而更贵，Fast 模式以 5 倍费用换取 2.5 倍速度。
谁拥有更多算力，谁就拥有更多权力。 这不是均匀分布的，而是金钱与进化的正反馈循环。

第二块基石：燃烧 Token 的速度，决定了人的进化速度

买 Token 不是消费，是投资。

用顶级模型与垃圾模型的人，一年后的认知差是 100 倍。
今天进化的最快方式，就是和 Agents 一起燃烧 Token。

AI Coding、AI Agent、AI Video —— 这是今天燃烧最快的三台引擎。

第三块基石：Agent 是新世界的人口红利

过去研究“让人用得爽”，现在研究“让 Agent 用得爽”。
Agent 每天调用接口几万次，这个量级远超人类。

增长飞轮：

先被发现：SEO 面向 Agent，文档清晰。
再被依赖：结果稳定、准确、快速。

如果 Agent 调不动你的产品，那你在新世界里就不存在。

第四块基石：在新世界里的你

当劳动力被取代，生产力爆炸，我们将进入 愿力时代。

Agent：有能力，有理性，没想法。
人类：有欲望，有想象，没体力。

未来人的价值，不在于亲自干活，而在于驱动多少 Agent。
“韩信点兵，多多益善”。不是因为韩信能打，是因为他有一套体系，给他多少兵他都能管。

终

六把刀砍完，四块基石初现。

旧世界 (Internet)	新世界 (Agent)
人是用户	Agent 是用户
流量是资源	算力是特权
免费是策略	投资是底色
规模是壁垒	结果是壁垒

如果你还在用旧词思考，你是在考古而非创业。

互联网已死，Agent 永生。

VibeCoding 思想与实践

2026-01-28T00:00:00.000Z

哲学/思想

在 React 的世界中，有一个经典的哲学公式：UI = f(State, Props)，它用函数式的思维定义了用户界面的本质。而在 AI 编程时代，我们可以推导出一个类似的公式：

Code = AI(Context, Prompt)

这个公式揭示了 AI 编程的核心范式：

Context（上下文） 是 AI 理解问题的基础，包括代码库结构、技术栈、业务逻辑、设计规范等
Prompt（提示词） 是人类向 AI 传达的另类 Props，包括传统意义上的提示词、MCP、Skill 等
AI 是将上下文和提示词转化为代码的"函数"，包括底层 LLM 模型和延伸出来的 Agent 等

Vibe Coding 核心理念

“Vibe Coding” 这一概念由 Open AI 的 Andrej Karpathy 在 2025 年初提出，它强调一种 对话式、迭代式 的编程方式——用自然语言描述需求，让 AI 生成代码，然后通过反馈循环不断调优。

🧭 道（Philosophy）- 思想

AI 优先：凡是 AI 可完成的工作，优先交由 AI 执行（效率第一原则）
上下文至上：上下文是 Vibe Coding 的第一性要素，遵循 “垃圾进，垃圾出” 的底层逻辑
目的导向：开发全流程的所有动作均围绕核心目标展开，避免无意义的试错
结构先行：先明确整体框架再落地代码实现，从源头规避技术债累积

🧩 法（Methodology）- 方法论

用一句话清晰定义目标与非目标，明确需求边界
保持功能正交性，避免模块职责重叠与功能冗余
复用优先：不重复造轮子，优先通过 AI 检索适配的开源仓库或成熟方案
按职责拆分模块，先定义接口再补充实现，保证架构合理性
单次变更仅聚焦一个模块，严格控制变更范围，降低出错概率
文档即上下文：文档并非事后补充，而是编程过程的核心组成部分

🛠️ 术（Techniques）- 技巧

向 AI 提需求时，明确标注可修改范围与不可触碰边界
调试场景下，仅向 AI 提供核心信息：预期结果 vs 实际结果 + 最小复现案例
测试代码可交由 AI 生成，但核心断言逻辑需人工审核确认
代码量较大时及时切换新会话，避免上下文污染导致理解偏差

📋 器（Tools）- 拓展工具

详见下文「AI 生态发展状况 - 系统能力」部分。

AI 生态发展状况

系统能力

MCP（Model Context Protocol）是 Anthropic 于 2024 年发布的开放协议，被称为 AI 界的"USB-C 接口"；Skill 是将领域专业知识封装为可复用指令集的机制。

维度	MCP	Skill
本质	标准化协议——AI 与外部系统的通信标准	知识封装——领域专业知识的结构化指令集
作用	连接外部工具和数据源（GitHub、设计稿）	定义任务执行流程（代码审查、日报生成）
类比	USB-C 接口，即插即用	App，基于接口实现具体功能
复用范围	跨场景通用	垂直领域专用
配置方式	JSON Server 配置	Markdown 文件（SKILL.md）
Token 消耗	工具定义可能占用大量 token	按需加载，脚本执行结果才返回

产品载体演进

AI 产品的交互载体经历了明显的代际演进，每一代都代表着人机协作模式的变革：

代际	产品形态	代表产品	交互模式	核心特征	局限性
Gen 1	ChatBox	ChatGPT, Claude.ai	纯对话式 Q&A	单轮/多轮对话，知识问答	无法操作外部系统，输出仅限文本
Gen 2	IDE 集成	GitHub Copilot, Cursor	代码补全 + 内联对话	上下文感知，实时代码建议	被动响应，缺乏主动规划能力
Gen 3	CLI/GUI Agent	Claude Code, Windsurf	命令行/图形化 Agent	自主执行多步任务，操作文件系统	仍需人工频繁确认，连续性受限
Gen 4	自主代理	Manus, Devin	高度自主的任务执行	端到端完成复杂任务，最小化人工干预	成本高，可控性存疑，调试困难
Gen 5	环境原生	Claude Desktop, ClawdBot	融入操作系统/通讯工具	跨应用协作，无缝集成工作流	生态碎片化，隐私安全挑战

演进趋势分析

演进维度	早期（Gen 1-2）	当前（Gen 3-4）	未来（Gen 5+）
人机分工	AI 辅助，人类主导	AI 执行，人类监督	AI 自主，人类审批
上下文范围	单文件/单对话	项目级/仓库级	组织级/跨系统
执行边界	仅生成文本	操作文件和终端	操作任意软件
持久性	会话级记忆	项目级记忆	长期记忆 + 学习
协作模式	1 人 1 AI	1 人 N Agent	N 人 N Agent

思想钢印：AI 系统在自我进化

这是一个需要提前"押注"的信念 —— 我们正处于 AI 能力指数级增长的时期，相信 AI 会演变成一个自我优化的递归系统，不仅能执行任务，还能持续改进执行任务的方式本身

自我优化的递归系统：

启动 (Bootstrap)：通过 AI 生成初始的 “生成器提示词” 与 “优化器提示词”
自省进化：利用优化器提示词迭代改进生成器提示词的质量
任务生成：基于进化后的生成器，生成目标场景的所有提示词与 Skill 指令集
循环飞跃：将新生成的产物反馈至系统，启动持续的自我进化循环

Vibe Coding 次佳实践

基于 everything-claude-code 框架，融合实用 Skills，创建了一个可复用的配置仓库：ai-agent-config

仓库结构

ai-agent-config/
├── agents/                        # 专业化子代理（5 个）
│   ├── planner.md                # 功能规划代理
│   ├── code-reviewer.md          # 代码审查代理
│   ├── architect.md              # 架构设计代理
│   ├── security-reviewer.md      # 安全审查代理
│   └── build-error-resolver.md   # 构建错误解决代理
├── commands/                      # 快捷命令（6 个）
│   ├── daily.md                  # /daily - 生成日报
│   ├── plan.md                   # /plan - 实现规划
│   ├── review.md                 # /review - 代码审查
│   ├── tdd.md                    # /tdd - TDD 开发
│   ├── build-fix.md              # /build-fix - 修复构建错误
│   └── security.md               # /security - 安全审查
├── skills/                        # 工作流技能（16 个）
│   ├── aone-bug-context/         # Aone 缺陷上下文提取
│   ├── mastergo-design/          # MasterGo D2C 设计稿处理
│   ├── daily-report/             # 日报生成
│   ├── weekly-report/            # 周报生成
│   ├── code-review/              # 代码审查
│   ├── tdd-workflow/             # TDD 工作流
│   ├── react-typescript/         # React + TS 开发规范
│   ├── frontend-design/          # 前端设计指南
│   ├── webapp-testing/           # Playwright 测试
│   ├── knowledge-management/     # 知识管理决策
│   ├── docx/                     # Word 文档处理
│   ├── xlsx/                     # Excel 表格处理
│   ├── pptx/                     # PPT 演示文稿
│   ├── pdf/                      # PDF 文档处理
│   ├── drawio-architecture/      # Drawio 架构图
│   └── drawio-export/            # Drawio 导出
├── rules/                         # 始终遵循的规则
│   ├── security.md               # 安全规则
│   ├── coding-style.md           # 编码风格
│   ├── testing.md                # 测试规则
│   └── git-workflow.md           # Git 工作流
├── hooks/                         # 事件触发器
│   └── hooks.json                # Hook 配置
├── contexts/                      # 动态上下文
│   ├── dev.md                    # 开发模式
│   ├── review.md                 # 审查模式
│   └── research.md               # 研究模式
├── memory-bank/                   # 项目记忆库模板
│   ├── @architecture.md          # 架构文档模板
│   └── @decisions.md             # 决策记录模板
├── workflows/                     # 复用工作流
├── AGENTS.md                      # Skills 索引配置
└── GEMINI.md                      # AI Agent 配置文件

能力矩阵 (Agents & Commands & Skills)

快速参考表

我想要…	使用方式
规划一个新功能	`帮我规划 xxx` 或 `/plan`
审查代码质量	`CR一下` 或 `/review`
设计系统架构	`架构设计 xxx`
安全检查	`security review` 或 `/security`
修复编译错误	`build error: xxx` 或 `/build-fix`
生成日报	`/daily`
TDD 开发	`/tdd xxx`
生成周报	使用 `weekly-report` skill

Daily Report 示例

数据来源：Git commit 历史 > 对话摘要 > 文件变更 > 用户输入

产出示例：

# 日报 2026-01-28 (周二)

> **一句话总结**：完成 VibeCoding 文章撰写 + 创建 ai-agent-config 配置仓库

## 📋 完成任务

### 文档撰写

- **VibeCoding 实践文章**
  - 补全 AI 编程哲学、MCP/Skill 对比、最佳实践等章节
  - 产出：`source/_posts/tech/cs/VibeCoding 实践.md`

### Skill 开发

- **ai-agent-config 仓库**
  - 融合 everything-claude-code 框架与实用 Skills
  - 包含 daily-report、weekly-report、code-review 等技能

## 📦 产出物

| 类型 | 路径                 | 说明                      |
| ---- | -------------------- | ------------------------- |
| 文章 | `VibeCoding 实践.md` | 12000+ 字的 AI 编程方法论 |
| 仓库 | `ai-agent-config/`   | 可复用的 Agent 配置集合   |

思考/探索

当前的瓶颈/上限

回到这个公式：Code = AI(Context, Prompt) 来分析：

Context（上下文）的转换率损耗：在复杂的业务链路中，从原始需求到代码实现中间经历了多次“翻译”;每一层上下文的传递都可能伴随着信息熵的增加和有效信息的丢失
Prompt（提示词）的语义鸿沟：当需求复杂度提升时，Prompt 的长度和复杂度呈指数级增长，在编写 Prompt 时往往难以覆盖所有边缘情况，导致 AI 生成的代码在逻辑完备性上存在“最后一公里”的问题
AI（模型/Agent）的逻辑上限

拿 D2C 场景举例

直观理解下 D2C 方案：设计稿上下文 => 代码
在具体业务场景下，这个链路可以补全为：设计规范 => 设计同学 => 设计稿上下文 => DSL => AI => 代码 => 页面效果

在完整的链路场景下，从一开始的设计规范到最后的页面，中间穿插着多轮的上下文转换（上游到下游的交互），不可避免的造成了上下文的冗余化和可读性变差

D2C 的众多解决方案，最终应该都是在优化这条链路上下文的转换率

可探索的应用新方向

browser control：用以网页 devtools 调试

参考资料

vibe-coding-cn - Vibe Coding 中文指南
everything-claude-code - Claude Code 完整配置集合
Anthropic MCP 文档 - Model Context Protocol 官方介绍

当你决定出发时

2026-01-24T00:00:00.000Z

📋 声明 - 本文为转载文章

2025年终总结：当你决定出发时，你就已经在山顶了

摘要

本视频作者分享了他对“命运”的理解，受《你一生的故事》（电影《降临》原著）中费马原理的启发，他开始相信命运并非由过去决定，而是有可能由未来的自己所吸引。视频强调了选择的重要性，并鼓励观众积极明确地规划未来，将其视为向宇宙发出需求，从而让未来的愿景成为现实。

口播逐字稿

📚 从《你一生的故事》到费马原理

去年我读了一本书叫你一生的故事但后来被改编成了电影降临今天想说的不是小说而是书里面提到的费马原理
它让我开始相信命运这个事情我以前看待世界都是经典力学式的万事皆有一那个音在过去
过去的一切导致了现在但是读完这本书之后我感觉这个音也有可能在未来费马原理是什么呢

🔭 费马原理：光线与宿命的宇宙观

飞马原理说的是光线从A点经过水面抵达B点的时候会发生折射这条路径呢一定是花费时间最短的路径你会问AB之间直线才应该是吧
不因为光线在水里的传播速度要更慢所以如果它走直线在水里的路程就会更长时间就会变得更长
这是一个非常反常识的事情他应该是要遍历每一条路线他才能知道要选哪一条吧但不是他一出发的时候
好像就知道了他在出发的那一刻仿佛就知道这是最短时间的路线更准确的说
他仿佛已经知道自己的命运飞马原里所描绘的宇宙更像是宿命般被写好的宇宙在出发时就已经知道结
当时我读到这一段的时候正在飞机上我抬头看了一眼周围的乘客没有人注意到我

🤔 命运已定，选择仍有意义？

因为我感觉自己正在窥探宇宙的秘密如果命运已经确定了那我的选择还有意义答案是有
而且选择更加重要其实我看待这个事情他并非是说哦宇宙或命运或者更宏大的力量
安排了我的人生轨迹那我就可以躺平了他对我的启示是当我决定爬山的时候
我其实已经出现在山顶因为在我决定的那一个瞬间宇宙就为我生成了一个我出现在山顶的可能无数的平行宇宙里就多了这么一个平行宇宙
而我每爬一步世界线就会收束一点最终无数个宇宙会塌缩成这一个现实但为什么我会去爬山
是因为我看到了山顶的我是山顶的那个我吸引了现在的自己山顶的我才是原因

✍️ 自由意志：成为未来的“提示词”

当然小说讨论更多的是如果你已经知道你的未来了你会怎么度过他的写作方式很有意思
真的推荐你们去看但是鉴于我们现在没有外星人我们也真的无法知道未来会怎么样所以选择就变得极其有趣
自由意志的开始有用起来选择去哪儿本身并不重要重要的事是你自己选因为如果你不选
别人就帮你选了别人看见的未来会成为你的现实对于有些人来说结婚生孩子可能是他父母看见了未来
但是迫于压力他就变成了你的现实要买很多东西才能信服是消费主义看见的未来
但是因为你并不清楚自己想要什么所以他变成了你的现实当然我对这些都不加以评判因为有些人他就适合结婚生孩子
有些人他就购买东西他能获得快乐这些我们都不加以评判选择什么并不重要
重要的是你选一个好用的方法是把它当成和宇宙提需求我希望在几年之后在什么地方做什么样的工作你越具体越好
就跟你写AI的prompt一样你提的需求越准所生成的那个宇宙就会越清晰你看见的也就会越清晰
当你清晰的看见的时候它才有可能会发生这个因才有可能会导致这个果我知道我神神叨叨讲了一堆

💫 2025年终总结：未来的自己指引当下

但我们回到开头呃 2025年我确实开始相信命运的存在我以前不同意
一切都是最好的安排我觉得他他在很多语境下他在合理化现在的痛苦它蕴含了一种等待他人救赎自己的感觉
可是现在来看的话如果安排的人不是别人而是未来的自己那种命运的推背感
很有可能就是未来的给你暗示你要仔细去听而已才行啊这就是我的2025年的总结拜拜

亮点

📖 费马原理揭示了光线在不同介质中传播时会选择耗时最短的路径，这挑战了常识，暗示光在出发时仿佛已知终点，让作者开始相信命运的存在 [00:41]。
🤔 面对命运已定的可能，作者认为选择的意义反而更加重要，因为这并非是宇宙或宏大力量安排人生，而是我们通过选择塑造未来 [01:43]。
🏞️ 作者提出一个深刻的观点：当我们决定爬山时，就已经出现在山顶了，因为那一瞬间宇宙便生成了我们成功抵达山顶的可能，而未来的我们则吸引着现在的自己 [02:08]。
🧘‍♀️ 如果不主动做出选择，他人的未来愿景，如父母对婚姻育儿的期待或消费主义对物质的诱导，就可能成为我们自己的现实，因此自主选择至关重要 [03:00]。
✨ 作者建议将做选择视为向宇宙提出需求，越具体清晰的规划，就像写AI prompt一样，越能让未来蓝图变得清晰，从而更有可能实现 [03:36]。
🔮 作者在2025年的总结中提到，如果命运的安排者不是别人，而是未来的自己，那么那种“命运的推背感”很可能就是未来的自己给出的暗示，需要我们仔细聆听 [04:22]。

#命运 #费马原理 #自由意志 #未来规划 #自我选择

思考

费马原理是如何让作者相信命运的存在的？
- 作者通过费马原理中光线在出发时仿佛已知最短路径来抵达终点的现象，感受到宇宙可能存在一种预设性，这让他联想到命运可能在出发时就已经被写好，从而开始相信命运。
既然命运可能已定，为什么作者还强调选择的重要性？
- 作者认为，命运并非外部力量的安排，而是由“未来的自己”吸引“现在的自己”所形成。因此，选择变得更加重要，因为每一次选择都是向宇宙提出需求，明确地选择和规划未来，才能让未来的愿景变为现实，从而创造出我们想要的命运。

术语解释

费马原理 (Fermat’s Principle): 光线从一点传到另一点时，总是沿着光程最短（即耗时最短）的路径传播 [00:41]。
经典力学 (Classical Mechanics): 一种描述宏观物体运动规律的物理学理论，认为万事皆有因，过去的一切导致了现在 [00:23]。
世界线收束 (Worldline Convergence): 在视频中，指随着个人每迈出一步，原本无数个平行的可能性宇宙逐渐减少，最终收缩成一个具体的现实 [02:29]。
宿命 (Fate/Destiny): 视频中指一种预先被设定好的、无法更改的命运轨迹，作者通过费马原理对其有了新的理解，认为它可能由未来的自己所影响 [01:21]。
平行宇宙 (Parallel Universes): 视频中提及的理论，指在我们的宇宙之外还存在着无数个其他宇宙，每个宇宙都代表着不同的可能性或现实 [02:22]。

视频章节总结｜ 💡 当你决定出发，你就已在山顶：从费马原理看命运与自由意志

本视频深入探讨了费马原理及其在理解命运和自由意志方面的哲学启示。作者从《你一生的故事》（电影《降临》原著）中的费马原理切入，解释了光线选择最短时间路径的“反常识”现象，进而引申出“未来之因”的概念。这一观点挑战了经典的因果论，认为未来的“我”可能正是现在选择和行动的原因。视频强调，即便命运存在，个人的选择也至关重要，因为正是通过我们的选择，才能具象化和吸引我们所设定的未来。作者鼓励观众明确自己的愿望，将其视为向宇宙发出的“提示词”，从而让未来的可能性变得清晰并最终实现。这不仅仅是对宿命论的消极接受，更是对自我创造未来的积极肯定，将未来的自己视为指引和吸引当下行动的动力，从而赋予个人选择更深远的意义。

00:00 - 📚 从《你一生的故事》到费马原理

视频开篇引入了科幻小说《你一生的故事》（电影《降临》原著），并指出书中的费马原理是核心。作者曾是经典力学的信徒，认为万事皆有过去之因，但在接触费马原理后，开始相信“未来”也可能是“因”，从而开始相信命运。

00:17 - 🔭 费马原理：光线与宿命的宇宙观

本章详细解释了费马原理：光线从A点到B点经过不同介质时，会选择花费时间最短的路径，而非直线。这一现象“反常识”，因为它似乎意味着光线“预知”了最短路径，仿佛宇宙在出发时就已写好结局。这让作者感受到一种宿命论的宇宙观。

00:53 - 🤔 命运已定，选择仍有意义？

作者探讨了如果命运已定，个人选择是否还有意义的问题。他认为选择不仅有意义，而且更重要。这并非是宏大力量安排人生轨迹，而是当我们决定一件事（如爬山）时，宇宙就已生成了那个可能的未来。未来的“我”才是原因，吸引着现在的自己去实现。

01:38 - ✍️ 自由意志：成为未来的“提示词”

鉴于我们无法预知未来，选择变得极其有趣且重要。如果缺乏自主选择，就可能被他人的期望或消费主义所定义。视频鼓励观众运用自由意志，清晰具体地向“宇宙”提出自己的未来愿望，就像写AI prompt一样，越具体，未来就越清晰，从而实现“未来的你”吸引“现在的你”去努力的因果。

02:43 - 💫 2025年终总结：未来的自己指引当下

在总结部分，作者再次强调他开始相信命运，但不同于传统宿命论的消极等待。他认为“一切都是最好的安排”并非合理化痛苦，而是指未来的“自己”可能就是那个“安排者”，通过“推背感”或暗示来指引当下的行动。这种观点赋予了个人积极主动创造未来的力量。

Manus 季逸超访谈深度调研报告：AI 时代的产品哲学与创业思考

2026-01-03T14:14:29.000Z

Manus 季逸超访谈深度调研报告：AI 时代的产品哲学与创业思考

播客基本信息

播客名称：张小珺 Jùn ｜商业访谈录第 128 期 - “Manus 决定出售前最后的访谈：啊，这奇幻的 2025 年漂流啊…”

播出时间：2025 年 12 月 31 日（实际录制于 2025 年 12 月 1 日）

播出平台：小宇宙、苹果播客、喜马拉雅等多平台

访谈时长：3 小时 31 分钟

嘉宾介绍：

季逸超（Peak）：Manus 联合创始人兼首席科学家，1992 年出生，连续创业者，曾开发猛犸浏览器、Magi 知识引擎
张小珺：财经作者、腾讯新闻科技主笔，《张小珺 Jùn ｜商业访谈录》制作人，拥有 25 年财经媒体经验

特殊意义：这期访谈录制于 2025 年 12 月 1 日，当时 Meta 收购 Manus 的事件尚未发生。而在节目发布的前一天凌晨，Meta 宣布全资收购 Manus，使这期节目成为了 Manus 公开的最后一次深度访谈(66)。

一、季逸超的创业历程与个人背景

1.1 早期创业：从猛犸浏览器到 Peak Labs

季逸超的创业故事始于 2009 年，当时他还是北大附中的一名高中生。2009 年苹果发布 iPhone 的第二年，App Store 的出现成为了他人生的重要转折点，因为它给了开发者一种全景化变现的能力。

在开发猛犸浏览器之前，季逸超已经开发过六七个苹果应用。2010 年夏天，高二的他开始开发猛犸浏览器，从设计到美工、开发、测试、运营等工作全部由他一人独立完成。关于浏览器名称的由来，有一个有趣的故事：第一版完成时，他看到桌子上有一张生物课上拿来的猛犸象图片，由于纯色背景比较容易用 PS 抠出图样做图标，所以他干脆给浏览器起名叫 “猛犸”。

猛犸浏览器的成功超出了所有人的预期。这款产品凭借占用内存少（当时的手机才 128M 内存）、滑动交互便捷等特征，定价 1.99 美元，在 App Store 上颇受欢迎，前后为他赚取了 30 多万美金(102)。更令人惊讶的是，“猛犸 3” 发布后，3 天内下载量达到 12 万(62)。

2011 年，季逸超凭借猛犸浏览器获得了 Macworld Asia 2011 Award 特等奖。2012 年，他获得徐小平和红杉资本投资，成立了 Peak Labs 实验室，同年 3 月登上《福布斯》中文版封面，成为 “中美 30 位 30 岁以下创业者” 之一。

1.2 技术探索：从浏览器到知识图谱

季逸超的技术探索之路从未停止。2011 年，他因为想解决 “预测用户下一次点击” 的问题，进入了自然语言处理（NLP）领域(60)。这个看似简单的需求，引导他走向了更广阔的技术领域。

2014 年，他开始做 Magi—— 一个用 AI 自动构建知识图谱的搜索引擎，他的目标是 “做下一代 Google”(60)。这个项目他做了四年，主导研发了 Magi 知识引擎及相关的知识图谱、信息抽取、信息检索技术。麻省理工科技评论曾评价季逸超所研发的 Magi 会成为最大的通用知识图谱系统，中国互联网络信息中心也将其作为人工智能与搜索引擎结合的创新案例列入了年度互联网调查报告。

在这段技术探索过程中，季逸超的创业核心始终是需求和兴趣引导，从浏览器的 “预加载需求” 切入 NLP，从知识图谱的 “自动化构建” 走向 Open IE，技术探索始终围绕用户真实痛点，而非单纯追求论文或指标(86)。

1.3 加入 Manus：从独立创业到团队合作

经历了 Magi 项目后，季逸超对 AI 行业有了更深刻的理解。2024 年，经真格基金撮合，他加入了 Manus，与肖弘、张涛组成核心团队(73)。

季逸超选择加入 Manus 的一个重要原因是肖弘是个 “正常人”。他评价道：“你会发现小红有一个非常稀缺的特质，什么？他很正常。他身心健全，没有任何不良嗜好，没有任何极端的思想。”(99)在季逸超看来，“正常” 意味着去精英化的吸引力、团队氛围的确定性价值以及价值层面的共频共振，本质上是价值观的务实和真诚(96)。

1.4 家庭背景：科学家父亲与企业家母亲

季逸超的家庭背景对他的成长产生了深远影响。他的父亲是北大物理系教授，母亲是老一辈中关村连续创业者。这种独特的家庭环境让他在两种不同的文化氛围中成长。

季逸超形容自己是在这两种风格中取了一个中间点，成为了 “科技创业者”。他坦言自己从小不是一个聪明孩子，学习成绩一般，比较偏科。但家庭环境培养了他对技术和商业的双重敏感度，为他日后的创业之路奠定了基础。

二、Manus 的产品哲学与技术路线

2.1 对 Agent 的独特定义：从聊天工具到行动执行者

季逸超对 AI Agent 有着独特而深刻的理解。他认为 Agent 不应该只是一个聊天的入口，而应该是能替代你把事办了的工具。Agent 的定义是：它不应该是你请来的一个老师，而应该是一个随时待命的特工。

这种定义反映了 Manus 的产品哲学：真正的 Agent 一定是结果导向的，它得能去把手弄脏。季逸超举了一个生动的例子：比如订机票，它直接去比价、去填信息，最后把订单交到你手里，这是对互联网基础设施的重构。

Manus 的产品定位极其清晰：不做垂直工具，而是在 “模拟一个人”(102)。这种定位让 Manus 在众多 AI 产品中独树一帜，它不是为特定场景设计的工具，而是一个通用的智能体，能够处理各种复杂的任务。

2.2 技术路线：不做模型，专注 Agent 框架

Manus 在技术路线上做出了一个大胆的选择：几乎不训练自己的模型，也不做微调，坚持依赖最强的模型。季逸超对此有自己的理解：

“我觉得首先做模型或者说做垂直整合这件事，它其实最影响的是你初期的迭代速度。我上一次创业最惨痛的教训就是，你在不确定的时候开始做自下而上的迭代的话，你会被你的模型迭代所影响。”

他进一步解释道，模型的保质期已经大大缩短，从过去的一年缩短到 1-1.5 个月。在这种情况下，“如果你只做模型，你不是 SOTA 就没有意义”，这是一种非常激烈的不进则退的状态。

相反，Manus 选择专注于 Agent 框架和 Context Engineering（上下文工程）。季逸超认为，上层的 Agent 框架和 Context Engineering 仍然有很多工作要做，而目前没人替他们去做，所以他们自己把研发成本投入到这方面。

2.3 数据飞轮：用户反馈驱动的自进化

尽管不做模型，Manus 仍然构建了自己的数据飞轮。季逸超描述了两种主要的方式：

第一种数据飞轮是基于集体反馈的自进化能力。当用户使用 Manus 时，会出现两种情况：一是用户会 "教"Agent，比如在筛选简历时告诉 Manus 自己的偏好；二是用户会 "修复"Agent 的错误，比如帮助修改文件格式。“当你有很大的用户量之后，你可以说大一点，叫做基于 collective feedback 做到一种在线学习。但是我很不喜欢在线学习这个字。它能达到的一点就是我们即使不碰模型，也能够获得一种叫做 self evolving 的能力。”

第二种是基于用户朴素反馈的评估优化。Manus 非常依赖用户给的直接反馈，且有一个固定的团队专门做 evaluation，而且是主观 evaluation。“因为用户关注点跟这些理想化的 benchmark 还挺不一样的。比如说用户更关注的是你做的这个网站，长宽比是否超过了 16:9，这个网站是否比较易用且好看。”

2.4 增长运营秘诀：少即是多的设计哲学

Manus 的增长运营有其独特的秘诀。季逸超强调：“打造 Manus 的秘诀首先在于不侵入，能少一个按钮就少一个按钮”。这种 “少即是多” 的设计哲学贯穿了 Manus 的整个产品设计。

在用户参与方面，Manus 极其重视真实世界的反馈。季逸超认为：“Agent 的进步不能只靠实验室的数据，它必须在真实世界的环境里被毒打。当用户给出模糊指令而执行失败时，这种失败的数据比成功更宝贵。”

在运营上，Manus 是一个云原生的公司，组织架构非常清亮，产品只看一个指标：这个 Agent 是不是真正的帮用户节省了时间，是不是真正的完成了任务。

2.5 对 “套壳” 争议的回应

面对外界关于 Manus 是 “套壳” 产品的质疑，季逸超给出了自己的理解：“套壳到极致，本身也是一种胜利”。他认为这不仅是辩解，更是对产品边界与用户价值的重新理解。

季逸超澄清了一个重要争议：“如果我们在 3 月份发布的时候，如果我们有任何付费的宣传 —— 我死全家。”(99)他强调，Manus 的产品力源于对用户需求的深刻理解，而非简单的包装。

三、AI 行业观察与思考

3.1 AI 时代的创业认知：从艺术家到精英者

季逸超对 AI 时代的创业有着深刻的洞察。他指出了一个关键差异：“移动互联网喜欢艺术家，但是 AI 时代更需要精英者”(94)。

这个观点背后有着深刻的商业逻辑。季逸超解释道：“移动互联网时代边际成本几乎为零，软件产品有了规模之后，服务成本基本不变。可以很有情怀、很偏执，特别艺术家，只要找到一群跟你同频共振的用户，就能把这个事业给做起来。但是 AI 不一样，AI 创业更像传统制造业，每一次用户调用都会产生一定的 TOKEN 成本，用的人越多成本越高。”

他用一句特别扎心的话总结道：“太多人有乔布斯的病，但没有乔布斯的命”(94)。意思是，很多创业者都太艺术家了，这种所谓的艺术家气质对创业公司其实是风险。创始人不应该陷入那种为理想殉道的悲情意识，因为这会掩盖商业判断。在他看来，好的创始人应该是理性的执行者，去解决具体、琐碎的需求，而不是天天想着怎么去改变人类。

3.2 大模型时代的竞争格局

季逸超对大模型时代的竞争格局有着清醒的认识。他认为 DeepSeek 的出现对整个行业产生了巨大冲击，让模型的保质期从过去的一年缩短到只有 1-1.5 个月。

DeepSeek 的成功证明了一个重要观点：在大模型领域效率和工程能力有时候比单纯的算力堆砌更重要，它还打破了大家对大厂算力霸权的某种幻觉。对于做 Agent 的人来说，底层能力普及是好事，但同时也让竞争变得白热化，底层能力不再是某几家公司的护城河，大家的差距在快速缩小。

关于未来的竞争格局，季逸超认为：“现在的 AI 竞争没有蛮荒期，无论是大厂还是小公司反应都极其快。做大模型的公司一定最后会变成同时做模型和应用的公司”。在 Agent 赛道，Manus 的对手不只是创业公司，更是那些掌握入口的大厂。但是大厂往往有路径依赖，想的是怎么保护原有的生态，Manus 想的是怎么打破这些 app 之间的围墙。

3.3 “有所不为” 的产品哲学

在 AI 时代，季逸超提出了一个重要观点：“AI 时代不做什么比做什么更加重要”(94)。他说：“以前可能没有思考不做什么的奢侈，现在不做什么才是每天都要回答的命题。”

这种 “有所不为” 的哲学在 Manus 的产品决策中体现得淋漓尽致。季逸超透露，Manus 是一款相对克制的产品，很多 Agent 公司都在拼命给 AI 加工具、加能力，Manus 反而每个月都在想能删掉什么。他们公司甚至砍掉了一个做了 7 个月的 AI 浏览器项目，理由只有一个：做完了之后自己都觉得不太酷。

他解释道：“你本应该是最喜欢这个产品的人，都觉得不喜欢，用户怎么可能会喜欢？” 这种对产品的高标准和严要求，体现了 Manus 对用户体验的极致追求。

3.4 AI 与人类的关系思考

季逸超对 AI 与人类的关系有着独特的见解。他认为，现在的 AI 模型已经达到了 “超人” 级别，数学竞赛能吊打大部分人，但问题是它们还像 “瓶子里的大脑”，必须和现实世界交互。

更重要的是，他指出了一个关键问题：“AI 永远无法替代中介面对客户时的那种沟通方式。因为这是关于信任的事情。而信任，是不能完全交给 AI 的”。这个观点揭示了 AI 在某些领域的局限性，也为未来 AI 产品的发展指明了方向。

四、创业思考与人生感悟

4.1 对 “正常” 的理解：理性与平衡

在访谈中，季逸超多次提到 “正常” 这个词，这反映了他对创业和人生的理解。他认为，在当前的 AI 行业中，“正常” 是一种极其稀缺的品质。

“正常” 意味着身心健全，没有不良嗜好，没有极端思想(99)。在他看来，很多创业者都太 “艺术家” 了，陷入了为理想殉道的悲情意识，这会掩盖商业判断。好的创始人应该是理性的执行者，去解决具体、琐碎的需求，而不是天天想着怎么去改变人类。

这种对 “正常” 的追求，实际上是对理性和平衡的追求。在一个充满激情和泡沫的行业中，保持理性和清醒是极其困难的，但也是极其重要的。

4.2 悲观与乐观：在不确定性中前行

当被问到对 Manus 最悲观的预期时，季逸超的回答令人印象深刻：“悲观预期就是下个月死掉。然后补了一句：” 我们没有权利活着，我们是在努力获得一个活着的权利。"(99)

然而，这种看似悲观的态度背后，实际上是一种深刻的清醒和责任感。季逸超说：“如果 Manus 下个月死了，我会歇一会。”(52)但他又补充道：“我早就无憾了。” 这句话在被收购的语境下，听起来像是一种松弛。

这种在悲观与乐观之间的平衡，体现了一个连续创业者对不确定性的深刻理解和接受。

4.3 关于学习：实践优于理论

在访谈中，当被问到平时看什么书时，季逸超的回答出人意料：“我不看书”(91)。但他随即解释道，虽然不看书，但他的学习能力特别强。

这种学习方式反映了季逸超的实践导向思维。他的创业过程一直在迭代，核心是需求和兴趣引导，从浏览器的 “预加载需求” 切入 NLP，从知识图谱的 “自动化构建” 走向 Open IE，技术探索始终围绕用户真实痛点，而非单纯追求论文或指标(86)。

4.4 被收购的思考：从句号到逗号

关于 Manus 被 Meta 收购，季逸超有着自己的理解。他强调，收购决策是一个非常自然的过程，在 2025 年的这个节点，他意识到 Agent 的普及需要远比想象中庞大的算力和资源支持。

更重要的是，他明确指出：“决定收购不是因为做不下去了，而是想让这种技术更快的影响更多人。” 在谈判中，他最看重团队的独立性和技术路线的延续性，不希望变成大厂里边缘的部门。

对于未来，季逸超充满期待：“这次收购不是一个句号，而是一个逗号，是探索 AGI 下一公里的底座”。这种积极的态度，体现了他对技术前景的信心和对未来的期待。

五、核心金句与关键观点

5.1 关于产品哲学的金句

“套壳到极致，本身也是一种胜利” - 这不仅是对质疑的回应，更是对产品边界与用户价值的重新理解
“打造 Manus 的秘诀首先在于不侵入，能少一个按钮就少一个按钮” - 体现了 “少即是多” 的设计哲学
“Agent 不应该是你请来的一个老师，而应该是一个随时待命的特工” - 对 Agent 的独特定义
“真正的 Agent 一定是结果导向的，它得能去把手弄脏” - 强调 Agent 的行动能力

5.2 关于创业思考的金句

“太多人有乔布斯的病，但没有乔布斯的命” - 对 AI 时代创业者的警醒(94)
“以前可能没有思考不做什么的奢侈，现在不做什么才是每天都要回答的命题” - AI 时代的选择哲学
“我们没有权利活着，我们是在努力获得一个活着的权利” - 对创业公司生存状态的深刻描述(99)
“这次收购不是一个句号，而是一个逗号，是探索 AGI 下一公里的底座” - 对被收购的积极理解

5.3 关于行业洞察的金句

“移动互联网喜欢艺术家，但是 AI 时代更需要精英者” - 时代变迁的洞察(94)
“Benchmark 是所有 AI 公司的唯一护城河” - 对 AI 公司核心竞争力的理解
“AI 时代不做什么比做什么更加重要” - 对 AI 时代竞争策略的思考(94)
“AI 接下来的进步需要每一个用户的参与” - 对 AI 发展方向的判断，也是访谈的最后一句话(94)

5.4 关于技术趋势的金句

“模型的保质期只有 1-1.5 个月” - 对大模型时代竞争激烈程度的描述
“现在的 AI 模型已经 ’ 超人 ’ 级别了，但还像 ’ 瓶子里的大脑 '” - 对 AI 现状的形象比喻
“AI 永远无法替代中介面对客户时的那种沟通方式，因为信任是不能完全交给 AI 的” - 对 AI 局限性的认识

六、内容亮点总结

6.1 三大核心洞察

通过对三个半小时访谈的深入分析，我们可以提炼出季逸超最核心的三大洞察：

第一，移动互联网与 AI 时代的本质差异。移动互联网时代可以有情怀、很偏执，因为边际成本几乎为零；而 AI 时代更像传统制造业，每一次调用都有成本，需要更理性的商业判断。

第二，“有所不为” 的战略思维。在 AI 时代，选择不做什么比做什么更重要。Manus 的成功部分源于其克制的产品策略，每个月都在思考能删掉什么功能。

第三，用户参与的重要性。季逸超在访谈最后说：“AI 接下来的进步需要每一个用户的参与”(94)。这不仅是对技术发展的判断，也体现了 Manus 重视用户反馈的产品理念。

6.2 产品设计的独特理念

Manus 的产品设计理念可以总结为 “少即是多，行动至上”。从" 能少一个按钮就少一个按钮 “的设计原则，到” 真正的 Agent 得能去把手弄脏 " 的行动理念，都体现了对用户体验的极致追求。

特别值得注意的是 Manus 对 “失败数据” 的重视。季逸超认为，当用户给出模糊指令而执行失败时，这种失败的数据比成功更宝贵。这种逆向思维，让 Manus 能够在不断的 “试错” 中进化。

6.3 技术路线的大胆选择

Manus 选择了一条看似 “非主流” 的技术路线：不做模型，专注 Agent 框架。这种选择基于对行业趋势的深刻洞察：模型的保质期越来越短，而 Agent 框架和 Context Engineering 还有巨大的创新空间。

更巧妙的是，Manus 通过大量的 Token 消耗成为了模型厂商的重要客户，从而能够影响模型的发展方向。季逸超透露，Google DeepMind 的一些新功能就是根据 Manus 的需求开发的。

6.4 对 “正常” 的追求

在整个访谈中，“正常” 这个词多次出现，这反映了季逸超对创业和人生的理解。在一个充满激情和泡沫的行业中，保持 “正常”—— 理性、平衡、不极端 —— 是一种稀缺而宝贵的品质。

这种对 “正常” 的追求，让 Manus 在激烈的竞争中保持了独特的视角和定力。正如季逸超所说，好的创始人应该是理性的执行者，而不是陷入悲情意识的艺术家。

结语：AI 时代的理性声音

这三个半小时的访谈，不仅是 Manus 被收购前的最后一次公开对话，更是一位连续创业者对 AI 时代的深度思考和总结。季逸超用他独特的视角，为我们呈现了一个不一样的 AI 创业故事。

在这个故事中，我们看到了技术理想与商业现实的平衡，看到了 “有所为有所不为” 的战略智慧，更看到了在不确定性中保持理性和清醒的重要性。“AI 接下来的进步需要每一个用户的参与”—— 这不仅是季逸超对未来的判断，也应该成为我们每个人的行动指南。

对于创业者而言，季逸超的经历和思考提供了宝贵的借鉴：在 AI 时代，技术能力固然重要，但商业判断力、产品洞察力和对用户需求的理解同样不可或缺。成功的关键不在于追逐每一个技术热点，而在于找到真正的用户痛点，并以理性和务实的态度去解决它。

对于普通用户而言，这期访谈提醒我们：AI 不仅是技术专家的领域，更是每一个人都能参与、都能受益、都能产生影响的时代。在使用 AI 产品的同时，我们也在为 AI 的进步贡献着自己的力量。

最后，让我们记住季逸超的那句话：“我们没有权利活着，我们是在努力获得一个活着的权利”(99)。这种对生存的敬畏和对成功的谦逊，或许正是这个时代最需要的品质。在 AI 浪潮席卷而来的今天，保持理性、坚持价值、勇于创新，我们才能在这场技术革命中找到属于自己的位置。

参考资料

核心访谈来源

张小珺 Jùn｜商业访谈录第 128 期 - Manus 决定出售前最后的访谈
- 小宇宙｜ Apple 播客
腾讯科技独家对话 Manus 肖弘 - 混沌学园对话 Manus 两位创始人
- 搜狐
对话"Manus"两位创始人：2025，AI Agent 即将引爆
- 新浪财经

深度解读文章

Manus 被收购前最后一次访谈：季逸超还不知道 Meta 即将来敲门 - 网易
- 链接
Manus 季逸超访谈解读系列 - 孔某人的低维认知
Manus 杀疯了！这个非主流 90 后的突围路，揭示了 AI 时代的成长法则 - 外滩教育
- 链接
3 位连续创业者打造 Manus，应用潮里有更多"underdog"的机会 - 腾讯新闻
- 链接

人物背景资料

季逸超 Peak：AI 竞泳十年 - 网易订阅
- 链接
季逸超百科词条 - 百度百科
- 链接
英雄出少年之季逸超 - CSDN 博客
- 链接

行业分析与评论

Manus 上岸了，但 Agent 还没有赢 - 中国企业家杂志
- 链接
Manus 最新对话全文：尝试 Agent 支付，公司 ARR 近 1 亿美元 - 极客公园
- 链接
Manus 季逸超访谈：阿里千问非常扎实 - 雪球
- 链接
AI 时代，到底什么是稀缺的？ - 网易订阅
- 链接

我在2025这一年

2025-12-29T00:00:00.000Z

生活上

认识自己的性格缺点

直言直语：有时候是直言不讳的勇敢，有时候也是欠缺考量的冲动

非暴力沟通这本书，还是得多复习复习

享受幸福

拥抱鱼鱼，经历了很多时间节点

情人节前后在她家（不知前后）
端午出发了千岛湖度假
七夕的再度出发青岛，看电影《七天》
圣诞节前在迪士尼
临近元旦的新家布置

继续几个城市的旅游

这个 J 人变的更 P 了

苏州
深圳 & 香港
- 无攻略准备，直接单刷，体验还是有点局促的；但胜在自身如意也乐意
上海迪士尼

换工作，换房子

一个月速通了面试
- 在全勤工作的情况下，下班后晚上一周 10 场面试的经历，着实辛苦
- 好在结果如人意
搬家，换了更好的房子
- 终于有了心心念念的阳光

技能方面

摄影 📷：愈发炉火纯青

工作上

全面拥抱 AI

Cursor 的年费用户

一个月 20$ 的订阅，物超所值；不知不觉就经历了一年的周期

虽然又从 Cursor 后面换成了 168¥/年的 Antigravity 哈哈哈哈

跳槽面试经历

经历过好些有趣的事情

美国律师背景的女强人，回国组建 AI 团队，做信息服务
阿里高 P 跳槽，组建 AI 团队做商品比价和筛选服务
百度三轮技术面试全是女强人
阿里一个 BU 下的两个组竞争候选人逻辑

2026 的发展规划

生活上
- 生活技能再加强加强
工作上
- 尽早游刃有余

舆论环境的垃圾化

2025-11-18T00:00:00.000Z

现在在各种各样的争议事件中，身份和姿态是最重要的——影响现在的舆论场好恶判断的东西。

哪怕你的内核没有太大的问题，只要你的身份、姿态是高高在上的，那么你一定是遭殃的。这个时代最讨巧的人设是真小人，把一些东西摆在明面上，比如我说我就是一个唯利是图的不顾一切赚钱的人，就是想赚你们的钱，网友可能反而觉得，你把兄弟们当自己人，跟我们说真话，虽然日常生活中他们不会喜欢这样的人，但是不重要，传播上的情绪模式是对的，把姿态摆到了一个和网友平起平坐的状态，引起大家的好感。

这个趋势的结果是：各路的公众人物，企业家学者明星都退出了公共讨论。一个人说的话不可能永远正确。

舆论场的第一次崩坏：不允许错误出现

最开始的时候，舆论场还算健康。政府、媒体、学者、公众、明星这些不同的节点之间还能展开充分的交流。公众可以在平台上进行内容创作，受到认可的内容能引发深入讨论，形成多角度的思辨，容易带来真理的火花。优质内容得到鼓励，内容的多样性和真实感成为主流。

但第一次崩坏很快就来了：不允许错误出现。

公众人士一旦有偏差或低级错误，便可能被"全网喷杀"，一棍子打死。何同学、黄磊等公共事件就是典型，小错误被无限放大，演变成全民的集体清算。一旦出现负面舆情，公众人物和创作者无法自证清白，只能被动承受攻击。运动式封杀成为常态。

舆论场的第二次崩坏：必须说对的话

然后事情变得更糟。从"不能说错话"，演变成了"必须说对话"。

而且必须说全，否则就是春秋笔法夹带私货。正确不绝对，就等于绝对不正确。

现在对表达者有一种求全逻辑，表达者必须先亮明立场，先叠甲，把最对的话说出来，然后再去做其他表达，否则就没有资格选取一个自己的角度。这背后的逻辑是，受众对媒体的极度不信任，用一种舆论战的思维而不是和平交流，是一种身份政治。

内容生产者不敢表达个人观点，只好迎合"正确声音"。游戏、文化作品被要求明显展现"正确态度"，否则就可能被扣上"偏离主流"的帽子。审查变成了自我审查，内容变得极度合规但空洞，缺少真实和深度。

这种现状会导致：

浪费信息传播效率。内容被审核、过滤，创新和真实表达空间受限。
更重要的是产生有罪推定，表达者无法自证，无法证明我没有说过的话我是什么意图。一旦被质疑或批评，几乎无法自证清白，陷入自我证伪的怪圈。
真正有意义的稍微可能引发争议的，有探讨价值的问题没有创作者敢碰了，内容领域进一步贫瘠化，劣币驱逐良币。这甚至进一步导致，极端言论服务者转为一种私域的服务者，为极端思想的受众提供精神食粮。

舆论场的第三次崩坏：公共议题的讨论变成一种游乐场、垃圾场

第三次崩坏，就是我们现在看到的这个样子。公共议题的讨论变成一种游乐场、垃圾场。

户晨风为代表的人登场，进行的是完全标签化的输出，实际上并不代表任何一种真正的价值倾向。真实的问题无人问津。

讨论被碎片化、标签化后，变成无意义的辩论和"转账"。舆论场变成游乐场，充满战场式的发泄和爆炸式的对立，人人都是"喷子"与"受害者"。极端言论泛滥，真相逐渐被边缘化，取而代之的是情绪的宣泄和价值的对立。网络中的喷战、标签战，充斥着"公知"、“爱国”、"恨国"等标签。

一些内容创作者反其道而行，将文字游戏、标签化、激烈辩论进行到底，形成空洞的激烈论战。大量所谓"分析""评论"实际上只是一种标签化游戏，内里空无一物。这使得公众缺乏对真实社会、人物、事件的深刻认知，只剩下宽广的虚空。

为什么会变成这样？问题出在机制上。

机制的问题

理想的健康舆论场应该是什么样的？政府、媒体、民众、学者、创作者互动频繁，相互质疑与辩论，形成健全的内容生态。公众在探讨中不断反思自身与社会的关系，形成理性和包容的讨论氛围。各方观点共存，减少偏见，促进认知灰度化。

但现在的机制完全不是这样。

过度追求"绝对正确"，封杀异见，使得内容趋于极端单一。争论非基于事实，而是标签和身份，导致"身份确权"成为讨论核心。众多创作者、公众人物选择低调、回避争议，以避免"被黑"或"被攻击"。

这背后的深层问题是：现代人渴望"力量感"，但缺乏实际认知敏锐度。公众对"真实性"诉求变得扭曲，只在意情绪的操控，而非事实。由虚假繁荣驱动的舆论大战反而掩盖了现实中的矛盾。

错话不可说，唯有正确话，导致内容荒腔走板。言外之意、潜台词成为攻击焦点，而非实际内容。社会热点、公共议题越发政治化、标签化、碎片化。

结果就是：公共讨论变得碎片化、极端化，每个人都不敢"碰触"争议话题。真实的社会矛盾被掩盖，虚假繁荣成为新常态。舆论生态的崩坏不仅仅是技术层的问题，更是机制、文化、价值观的深层变异。

这些机制问题在现实中是怎么体现的？看看最近的案例就知道了。

现实案例

影视飓风事件就是这种崩坏的典型缩影。加纳电子垃圾事件、相亲角、公众人物等事件，都展现了舆论场的乱象。内容变化随风倒，一开始的正向反馈变成"爱国"或"恨国"的极端争执。从"正能量"到"攻击性内容"，抖音、微博上两极反转，体现舆情的极端和不稳定。

公众人物的困境更明显。无论是黄磊还是TM，都被标签化和极端化追杀。一次错误或偏差就会被无限放大，成为永远的黑点。自证清白几乎不可能，成为被动挨打的典型。

网络自媒体也好不到哪里去。以影视飓风为代表，内容被不断极端化、标签化、游戏化。内容空洞化、战场化，变成纯粹的情绪广告。追逐流量、娱乐元素成为唯一目标，价值观被边缘化。

那么，未来会怎样？

未来会怎样

以"垃圾场化"为核心趋势已成定局：内容贫瘠，争议泛滥的环境难以逆转。共识缺失、自由被压缩，导致社会认知逐渐扁平化、极端化，形成虚假繁荣。

以"求全"与"标签化"为导向的机制，最终带来信息垄断、认知贫瘠。公众人物、内容创作者只得自我克制或迎合舆论，难以提供深刻内容。重在"控制"与"标签"，而非"探讨"和"反思"。

影视飓风事件作为当代互联网舆论场崩坏的缩影，反映出从不能说错话，到必须说对话，再到无底线解构和标签化的漫长恶化过程。当前，我们共同面对的已不再是单纯的内容问题，而是机制、价值观和文化的深层危机。

只有重建理性、多元、包容的讨论环境，才能缓解垃圾场化的趋势。这需要减少标签化，鼓励多角度、多形态表达，以增强内容的公共性和深度。每个人都应反思自身在垃圾场化中的作用，选择理性表达而非冲动宣泄。

这场危机，既是警钟，也是反思未来的起点。

Electron 与 Tauri 技术选型

2025-10-20T10:13:54.000Z

在 X 平台看到关于 Electron 和 Tauri 的争论，建议大家在做技术选型前，先了解以下基础事实：

1. 两者的核心实现逻辑

Electron：本质是将应用（HTML/JS/CSS）与一个完整的 Chrome 运行时打包成自定义发行版。
- 优势：稳定、可控。
- 劣势：体积臃肿、资源占用高。
Tauri：让应用复用操作系统自带的 WebView（如 WebKit、WebView2），不单独打包浏览器。
- 优势：极大减小应用体积。
- 劣势：需面对不同平台 WebView 的 bug 与兼容性差异。

2. 本质是两种不同的工程哲学

框架	核心挑战	工程重心
Tauri	“系统集成”的兼容性问题	debug 系统
Electron	“自带浏览器”的资源妥协	打包系统

3. 选型的关键：明确需求导向

喷 Tauri bug 多，本质是在喷“跨平台本地集成”这件事本身的技术难度。
选择哪个框架，核心是判断需求：
1. 需要“完美的封闭盒子”（稳定、无需操心环境）→ 选 Electron。
2. 需要“自由但需解决兼容问题的原生集成”（轻量、省资源）→ 选 Tauri。

4. 现状：没有绝对完美的第三种选择

如果需要在 App 内提供网页渲染层，目前只有两种路径：

要么“重”（Electron，自带浏览器）。
要么“坑”（Tauri，需处理系统 WebView 差异）。

暂时不存在更好的第三种选择，除非浏览器厂商开放一个统一、轻量、稳定的嵌入式 Web API，而目前该条件尚未满足。

关于 NPM 包的安全性实践

2025-10-10T21:47:50.000Z

📋 声明 - 本文为转载文章
🔗 原文链接：https://github.com/bodadotsh/npm-security-best-practices

在现代 JavaScript 开发中，NPM 生态系统为我们提供了丰富的包资源，但同时也带来了安全风险，包括但不限于：数据入侵、供应链攻击、恶意软件、垃圾邮件、网络钓鱼等

本文将介绍一系列 NPM 包安全最佳实践，帮助开发者保护项目免受供应链攻击、恶意软件和其他安全威胁。

📦 开发者安全实践

1. 锁定依赖版本

在 npm 上，默认情况下，新依赖项将使用插入符号 ^ 操作符安装。此操作符安装最新的 次要 或 补丁 版本。例如，^1.2.3 将安装 1.2.3、1.6.2 等。

在各种包管理器中锁定精确版本的方法：

npm install --save-exact react
pnpm add --save-exact react
yarn add --save-exact react
bun add --exact react

我们也可以在配置文件中更新此设置（例如，.npmrc），使用 save-exact 或 save-prefix 键值对：

1
2
3

npm config set save-exact=true
pnpm config set save-exact true
yarn config set defaultSemverRangePrefix ""

对于 bun，配置文件是 bunfig.toml，相应的配置是：

1 2	[install] exact = true

覆盖传递依赖

然而，我们的直接依赖也有它们自己的依赖（传递依赖）。即使我们锁定了直接依赖，它们的传递依赖可能仍使用宽泛版本范围操作符（如 ^ 或 ~）。解决方案是覆盖传递依赖：https://docs.npmjs.com/cli/v11/configuring-npm/package-json#overrides

在 package.json 中，如果我们有以下 overrides 字段：

{
  "dependencies": {
    "library-a": "^3.0.0"
  },
  "overrides": {
    "lodash": "4.17.21"
  }
}

假设 library-a 的 package.json 依赖于 "lodash": "^4.17.0"
没有 overrides 部分，npm 可能会安装 lodash@4.17.22（或任何最新的 4.x.x 版本）作为 library-a 的传递依赖
但是，通过添加 "overrides": { "lodash": "4.17.21" }，我们告诉 npm，在依赖树中的任何地方出现 lodash，都必须解析为精确版本 4.17.21

对于 pnpm，我们也可以在 pnpm-workspace.yaml 文件中定义 overrides 字段：https://pnpm.io/settings#overrides

对于 yarn，resolutions 字段在 overrides 字段之前引入，它也提供类似功能：https://yarnpkg.com/configuration/manifest#resolutions

{
  "resolutions": {
    "lodash": "4.17.21"
  }
}

1 2	# yarn 也提供 cli 来设置解析：https://yarnpkg.com/cli/set/resolution yarn set resolution

对于 bun，它支持 overrides 字段或 resolutions 字段：https://bun.com/docs/install/overrides

2. 包含锁文件

确保将包管理器锁文件提交到 git 并在不同环境之间共享。不同的锁文件是：package-lock.json 用于 npm，pnpm-lock.yaml 用于 pnpm，bun.lock 用于 bun，yarn.lock 用于 yarn。

在自动化环境（如持续集成和部署）中，我们应该安装锁文件中定义的精确依赖：

1
2
3

npm ci
bun install --frozen-lockfile
yarn install --frozen-lockfile

💡 提示：当处理锁文件中的合并冲突时，不需要删除锁文件。当依赖项（包括传递依赖）使用版本范围操作符（^、~ 等）定义时，从头开始重建锁文件可能导致意外更新。
现代包管理器有内置的冲突解决机制，只需切换到主分支并重新运行安装。pnpm 还允许 Git 分支锁文件，它根据分支名称创建新的锁文件，稍后自动合并回主锁文件。

3. 禁用生命周期脚本

生命周期脚本是在 pre、post 和脚本之外发生的特殊脚本。例如，preinstall 在 install 运行之前运行，postinstall 在 install 运行之后运行。

生命周期脚本是恶意行为者的常见策略。例如，“Shai-Hulud” 蠕虫编辑 package.json 文件以添加 postinstall 脚本，然后窃取凭据。

1 2	npm config set ignore-scripts true --global yarn config set enableScripts false

对于 bun 和 pnpm，它们默认禁用。

⚠️ 注意：对于 bun，默认允许前 500 个 npm 包的生命周期脚本。

💡 提示：我们可以结合上面的许多标志。例如，以下 npm 命令将只安装锁文件中定义的生产依赖项并忽略生命周期脚本：
npm ci --omit=dev --ignore-scripts

4. 设置最小发布年龄

我们可以设置延迟以避免安装新发布的包。这适用于所有依赖项，包括传递依赖。例如，pnpm v10.16 引入了 minimumReleaseAge 选项：https://pnpm.io/settings#minimumreleaseage，它定义了版本发布后必须经过的最小分钟数，pnpm 才会安装它。如果 minimumReleaseAge 设置为 1440，那么 pnpm 不会安装发布不到 24 小时的版本。

pnpm config set minimumReleaseAge 
# 只安装至少 1 天前发布的包
npm install --before="$(date -v -1d)"                               # 对于 Mac 或 BSD 用户
npm install --before="$(date -d '1 days ago' +%Y-%m-%dT%H:%M:%S%z)" # 对于 Linux 用户
yarn config set npmMinimalAgeGate

对于 pnpm，还有一个 minimumReleaseAgeExclude 选项来排除某些包的最小发布年龄。

对于 npm，有一个提案添加 minimumReleaseAge 选项和 minimumReleaseAgeExclude 选项。

对于 yarn，配置选项 npmMinimalAgeGate 和 npmPreapprovedPackages 自 v4.10.0 起实现。

对于 bun，这里讨论：oven-sh/bun#22679

提供类似功能的其他工具示例：

npm-check-updates (https://github.com/raineorshine/npm-check-updates) 有 --cooldown 标志。
Renovate CLI (https://github.com/renovatebot/renovate) 有 minimumReleaseAge 配置选项。
Step Security (https://www.stepsecurity.io) 有 NPM Package Cooldown Check 功能。

5. 权限模型

在最新的 nodejs LTS 版本中，我们可以使用权限模型来控制进程可以访问哪些系统资源或进程可以对这些资源采取哪些操作。然而，这在存在恶意代码的情况下不提供安全保证。恶意代码仍然可以绕过权限模型并在没有权限模型施加的限制的情况下执行任意代码。

阅读关于 Node.js 权限模型：https://nodejs.org/docs/latest/api/permissions.html

# 默认情况下，授予完全访问权限
node index.js
# 限制对所有可用权限的访问
node --permission index.js
# 启用特定权限
node --permission --allow-fs-read=* --allow-fs-write=* index.js
# 将权限模型与 `npx` 一起使用
npx --node-options="--permission"

对于 Bun，权限模型目前正在这里和这里讨论。

6. 减少外部依赖

因为 npm 发布包的门槛很低，生态系统迅速增长成为最大的包注册表，至今有超过 500 万个包。但并非所有包都是平等的。有一些小型实用程序包，当我们自己可以编写它们时却被下载为依赖项，这引发了"我们是否忘记了如何编码？"的问题

在 nodejs 和 bun 之间，开发者可以使用它们的许多现代功能，而不是依赖第三方库。原生模块可能不会提供相同级别的功能，但应尽可能考虑它们。这里有几个例子：

NPM 库	内置模块
`axios`, `node-fetch`, `got`, 等	原生 `fetch` API
`jest`, `mocha`, `ava`, 等	`node:test`, `node:assert`, `bun test`
`nodemon`, `chokidar`, 等	`node --watch`, `bun --watch`
`dotenv`, `dotenv-expand`, 等	`node --env-file`, `bun --env-file`
`typescript`, `ts-node`, 等	`node --experimental-strip-types`, `bun` 原生支持
`esbuild`, `rollup`, 等	`bun build`
`prettier`, `eslint`, 等	`bun fmt`, `bun lint`

这里有一些您可能会觉得有用的资源：

https://obsidian.md/blog/less-is-safer
https://kashw1n.com/blog/nodejs-2025
https://lyra.horse/blog/2025/08/you-dont-need-js
https://blog.greenroots.info/10-lesser-known-web-apis-you-may-want-to-use
https://github.com/you-dont-need/You-Dont-Need-Momentjs
可视化 NPM 依赖：https://npmgraph.js.org
Knip（移除未使用的依赖）：https://github.com/webpro-nl/knip

🔧 维护者安全实践

7. 启用 2FA

https://docs.npmjs.com/about-two-factor-authentication

双因素认证 (2FA) 为您的 npm 账户添加了额外的认证层。2FA 默认不是必需的，但启用它是一个好习惯。

1 2	# 确保 2FA 已启用用于认证和写入（这是默认设置） npm profile enable-2fa auth-and-writes

自动化级别	包发布访问
手动	将每个包访问设置为 `需要 2FA` 和 `禁用令牌`
自动	将每个包访问设置为 `需要双因素认证` 或 `单因素自动化令牌` 或 `单因素 granular 访问令牌`

⚠️ 重要：建议配置支持 WebAuthn 的安全密钥，而不是基于时间的一次性密码 (TOTP)

8. 创建有限访问令牌

https://docs.npmjs.com/about-access-tokens#about-granular-access-tokens

访问令牌是使用 API 或 npm CLI 时向 npm 进行身份验证的常见方式。

npm token create # 用于读取和发布令牌
npm token create --read-only # 用于只读令牌
npm token create --cidr=[list] # 用于 CIDR 限制的读取和发布令牌
npm token create --read-only --cidr=[list] # 用于 CIDR 限制的只读令牌

⚠️ 重要：应使用 Granular Access Tokens 而不是 Legacy Tokens。Legacy tokens 无法限定范围且不会自动过期。使用它们被认为是危险的。

限制令牌到特定包、范围和组织
设置令牌过期日期（例如，每年）
基于 IP 地址范围限制令牌访问（CIDR 表示法）
在只读或读写访问之间选择
不要对多个用途使用相同令牌
使用描述性令牌名称

9. 生成来源声明

https://docs.npmjs.com/generating-provenance-statements

来源证明通过公开提供包源代码和构建环境的链接来建立。这允许开发者在下载之前验证包的构建位置和方式。

发布证明由注册表在授权用户发布包时生成。当 npm 包与来源一起发布时，它由 Sigstore 公共服务器签名并记录在公共透明账本中，用户可以在其中查看此信息。

例如，这是 vue 包页面上的来源声明看起来像的样子：https://www.npmjs.com/package/vue#provenance

要建立来源，使用支持的 CI/CD 提供商（例如，GitHub Actions）并使用正确的标志发布：

1	npm publish --provenance

要在不调用 npm publish 命令的情况下发布，我们可以执行以下操作之一：

在 CI/CD 环境中设置 NPM_CONFIG_PROVENANCE 为 true
将 provenance=true 添加到 .npmrc 文件
将 publishConfig 块添加到 package.json

1
2
3

"publishConfig": {
  "provenance": true
}

对于那些对可重现构建感兴趣的人，请查看 OSS Rebuild (https://github.com/google/oss-rebuild) 和软件工件供应链级别 (SLSA) 框架 (https://slsa.dev)。

受信任发布

当使用 OpenID Connect (OIDC) 身份验证时，可以无需 npm 令牌发布包，并获得自动来源。这称为受信任发布，请在此处阅读 GitHub 公告：https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ 和 https://docs.npmjs.com/trusted-publishers

⚠️ 重要：建议使用受信任发布代替令牌。

10. 审查发布文件

限制 npm 包中的文件有助于通过减少攻击面来防止恶意软件，并避免意外泄露敏感数据。

package.json 中的 files 字段用于指定应包含在发布包中的文件。某些文件总是包含在内，请参阅：https://docs.npmjs.com/cli/v11/configuring-npm/package-json#files 了解更多详细信息。

{
  "name": "my-package",
  "version": "1.0.0",
  "main": "dist/index.js",
  "files": ["dist", "LICENSE", "README.md"]
}

💡 提示：.npmignore 文件也可用于从发布包中排除文件。它不会覆盖 "files" 字段，但在子目录中会。
.npmignore 文件就像 .gitignore 一样工作。如果有 .gitignore 文件，而 .npmignore 缺失，则将使用 .gitignore 的内容。

运行 npm pack --dry-run 或 npm publish --dry-run 查看运行 pack 或 publish 命令时会发生什么。

> npm pack --dry-run
npm notice Tarball Contents
npm notice 1.1kB LICENSE
npm notice 1.9kB README.md
npm notice 108B index.js
npm notice 700B package.json
npm notice Tarball Details

🛡️ 高级安全策略

11. NPM 组织

https://docs.npmjs.com/organizations

在组织级别，最佳实践是：

在组织级别启用 需要 2FA
最小化 npm 组织成员数量
如果同一组织中有多个包团队，将所有包的 开发人员 团队权限设置为 读取
创建单独的团队来管理每个包的权限

12. 替代注册表

JSR

JSR 是一个现代 JavaScript/TypeScript 包注册表，与 npm 向后兼容。

⚠️ 注意：并非所有 npm 包都在 JSR 上！

访问 https://jsr.io 查看包是否可用并阅读 npm 限制文档。

deno add jsr:
pnpm add jsr: # pnpm 10.9+
yarn add jsr: # yarn 4.9+
# npm, bun 和旧版本 yarn 或 pnpm
npx jsr add  # 将 npx 替换为 yarn dlx, pnpm dlx 或 bunx

私有注册表

私有包注册表是组织管理自己依赖项的好方法，作为公共 npm 注册表的代理，并在项目中使用之前强制执行安全策略。

这里有一些您可能会觉得有用的私有注册表：

GitHub Packages https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry
Verdaccio https://github.com/verdaccio/verdaccio
- 参见 Verdaccio 最佳实践：https://verdaccio.org/docs/best/
Vlt https://www.vlt.sh/
- vlt 的 Serverless Registry (VSR) 可以在几分钟内部署到 Cloudflare Workers。
JFrog Artifactory https://jfrog.com/integrations/npm-registry
Sonatype: https://help.sonatype.com/en/npm-registry.html

13. 审计、监控和安全工具

审计

许多包管理器提供审计功能来扫描项目依赖项中的已知安全漏洞，显示报告并推荐修复它们的最佳方法。

npm audit # 审计依赖项
npm audit fix # 自动安装任何兼容的更新
npm audit signatures # 验证依赖项的签名
pnpm audit
pnpm audit --fix
bun audit
yarn npm audit
yarn npm audit --recursive # 审计传递依赖项

GitHub

https://github.com/security

GitHub 提供几种可以帮助保护免受 npm 恶意软件侵害的服务，包括：

Dependabot：此工具自动扫描项目依赖项（包括 npm 包）的已知漏洞。
软件物料清单 (SBOMs)：GitHub 允许您直接从其依赖图导出存储库的 SBOM。SBOM 提供项目所有依赖项的全面列表，包括传递依赖项（依赖项的依赖项）。
代码扫描：代码扫描也可以帮助识别潜在漏洞或可疑模式，这些可能来自集成受损的 npm 包。

⚠️ 警告：如果您在 NPM 或 GitHub 中发现漏洞或问题，请使用以下链接报告：
https://docs.npmjs.com/reporting-malware-in-an-npm-package
https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam#reporting-a-repository

OpenSSF Scorecard

https://securityscorecards.dev 和 https://github.com/ossf/scorecard

免费开源自动化工具，评估与软件安全相关的重要启发式方法（“检查”），并为每个检查分配 0-10 分的分数。本仓库中提到的几个风险作为检查的一部分包含在内：固定依赖项、令牌权限、打包、签名发布等…

运行检查：

在您拥有的代码上自动使用 GitHub Action
通过命令行手动在您的（或别人的）项目上

Socket.dev

https://socket.dev

Socket.dev 是一个安全平台，保护代码免受漏洞和恶意依赖项的侵害。它提供各种工具，如 GitHub App 扫描拉取请求、CLI 工具、web 扩展、VSCode 扩展等。这是他们关于 2025 年 1 月大规模 AI 驱动恶意软件狩猎的演讲。

Socket Firewall 是在安装时阻止恶意包的免费工具：

npm i -g sfw
# 适用于 `npm`, `yarn`, `pnpm`
sfw npm install 
# 示例：在 zsh 中将 `npm` 别名为 `sfw npm`
echo "alias npm='sfw npm'" >> ~/.zshrc

Snyk

https://snyk.io

Snyk 提供一套工具来修复开源依赖项中的漏洞，包括 CLI 在本地计算机上运行漏洞扫描、IDE 集成嵌入开发环境以及 API 以编程方式与 Snyk 集成。例如，您可以在使用前测试公共 npm 包或为已知漏洞创建自动 PR。

14. 支持 OSS

维护者倦怠是开源社区中的一个重要问题。许多流行的 npm 包由志愿者在业余时间维护，通常没有任何补偿。随着时间的推移，这会导致疲惫和缺乏动力，使他们更容易受到社会工程学的影响，恶意行为者假装成为有用的贡献者并最终注入恶意代码。

2018 年，event-stream 包因维护者给予恶意行为者访问权限而被攻破。JavaScript 生态系统之外的另一个例子是 2024 年的 XZ Utils 事件，恶意行为者工作了三年多才获得信任地位。

OSS 捐赠也有助于为开源开发创建更可持续的模式。基金会可以帮助支持数百个开源项目背后的业务、营销、法律、技术援助和直接支持，许多人依赖这些项目。

在 JavaScript 生态系统中，OpenJS Foundation (https://openjsf.org) 于 2019 年由 JS Foundation 和 Node.js Foundation 合并成立，以支持一些最重要的 JS 项目。下面列出了几个其他平台，您可以在那里捐赠和支持每天使用的 OSS：

GitHub Sponsors https://github.com/sponsors
Open Collective https://opencollective.com
Thanks.dev https://thanks.dev
Open Source Pledge https://opensourcepledge.com
Ecosystem Funds: https://funds.ecosyste.ms

📝 配置文件示例

以下是一个示例 .npmrc 文件，包含下面提到的配置选项：

ignore-scripts=true
provenance=true
save-exact=true
save-prefix=''

其他配置文件示例：

🎯 结论

NPM 生态系统虽然强大，但也存在安全风险。通过实施这些最佳实践——从锁定依赖版本、禁用生命周期脚本到启用 2FA 和使用来源声明——开发者可以显著提高其项目的安全性。

记住，安全性是一个持续的过程，而不是一次性的任务。定期审计依赖项、保持更新并支持开源维护者，这些都有助于构建更安全的 JavaScript 生态系统。

🛡️ 安全提示：如果您在 NPM 或 GitHub 中发现漏洞或问题，请使用以下链接报告：
https://docs.npmjs.com/reporting-malware-in-an-npm-package
https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam#reporting-a-repository

好的系统设计：核心原则与实践指南

2025-08-22T00:00:00.000Z

📋 声明 - 本文为转载文章
🔗 原文链接：https://www.seangoedecke.com/good-system-design/

在系统设计领域，存在不少欠佳的建议：一类是面向行业新人、主打 “你肯定没听过队列” 的 LinkedIn 风格内容，另一类是标榜 “用数据库存储布尔值即不合格工程师” 的 Twitter 式 “小聪明”。即便部分优质资料（如《设计数据密集型应用》），对工程师日常面临的多数系统设计问题也未必具备实用性。

什么是系统设计？从行业共识来看，软件设计是 “组装代码行”，核心元素包括变量、函数、类等；而系统设计是 “组装服务”，核心元素涵盖应用服务器、数据库、缓存、队列、事件总线、代理等基础设施。本文将梳理 “好的系统设计” 的核心认知 —— 尽管具体决策需依赖实践经验，但仍可提炼出具有普适性的核心原则

一、好的系统设计的识别标准

好的系统设计往往呈现 “不起眼” 的特征，甚至与直觉相悖：

外观平淡，运行稳定：具体表现为 “长时间无故障”“操作复杂度低于预期”“无需特意关注某部分运行状态”。例如，当接入某一服务时，若出现 “流程比预想中顺畅” 的感受，大概率是优质设计的作用。
复杂不等于优秀：劣质设计常更具 “视觉冲击力”—— 若一个系统堆砌了分布式一致性机制、多模式事件驱动、CQRS 等复杂技术，反而可能是在弥补底层决策失误，或存在过度设计问题。当然，并非所有复杂系统均不合理（部分场景确实需要一定复杂度），但能稳定运行的复杂系统，必然源于能稳定运行的简单系统，从零构建复杂系统属于高风险行为。

二、核心矛盾：状态与无状态

软件设计的核心难点，本质在于 “状态管理”，二者的定义与特征如下：

有状态（Stateful）：需长期存储信息（如与数据库交互的服务），这类组件易出现故障且无法自动修复 —— 例如数据库中存储了触发应用崩溃的异常数据时，需手动清理；磁盘空间不足时，需手动扩容或删除冗余数据。
无状态（Stateless）：不持久化存储信息（仅在请求生命周期内暂存数据），典型案例为 GitHub 的内部 API：接收 PDF 文件后返回 HTML 渲染结果，重启服务无需恢复任何前置数据。

设计原则：最小化有状态组件

实践方案：设置单一服务专门管理状态（仅该服务与数据库交互），其他服务仅承担无状态处理任务。例如，避免 5 个服务同时写入同一张数据库表，而是让其中 4 个服务通过 API 或事件调用 “状态管理服务”，由后者统一执行写入逻辑。
读逻辑灵活性：读操作可适当简化 —— 若直接读取user_sessions表的速度比调用内部会话服务快 2 倍，无需强求通过统一服务调用。

三、数据库：状态管理的核心载体

由于状态管理是系统设计的关键，存储状态的数据库自然成为核心组件。以下以 SQL 数据库（MySQL/PostgreSQL）为例，梳理核心设计要点：

1. Schema 与索引：平衡灵活性与可读性

Schema 设计：需具备一定灵活性（避免数据量达百万级后修改 Schema 的繁琐操作），但不可过度灵活 —— 若将所有数据存入 “value” JSON 列，或通过 “键值表” 存储任意数据，会将复杂度转移至应用层，还可能引发性能隐患。核心原则是人类可读：通过 Schema 即可大致理解 “存储内容及存储目的”。
索引设计：
- 必要性：仅当表数据量极少（如仅几行）时可省略索引，否则必须添加 —— 索引是提升查询效率的核心手段。
- 匹配查询场景：若常用email与type组合查询，需建立包含这两个字段的联合索引。
- 字段顺序技巧：索引结构类似 “嵌套字典”，需将高基数字段（如email，值唯一度高）置于前方，避免出现 “查询email时先扫描所有同type数据” 的低效情况。
- 避免过度索引：每新增一个索引，都会增加写操作的开销（写入数据时需同步更新索引）。

2. 突破数据库瓶颈：优化读写逻辑

在高流量应用中，数据库常成为性能瓶颈（即便应用层代码效率一般，如 Ruby on Rails 服务），原因是复杂请求可能需顺序执行数百次数据库调用。解决思路包括：

最大化数据库处理能力：多表数据查询优先使用JOIN语句，而非多次查询后在内存中拼接；需警惕 ORM 框架的 “内循环查询”—— 例如将 “查询所有记录的 id 和 name” 拆分为 “先查询所有 id，再循环查询每个 id 对应的 name”，会导致查询次数从 1 次增至 101 次。
复杂查询拆分：极少数情况下，拆分极复杂查询比优化索引更高效（尽管理论上可通过索引优化解决，但实际操作中拆分更易落地）。
读写分离：采用 “1 主库 + 多从库” 架构，读请求优先分配至从库（主库已承担全部写操作）。仅当无法容忍 “毫秒级同步延迟” 时读取主库 —— 例如数据更新后，可直接在内存中使用更新后的值，避免立即查询主库。
应对查询峰值：写请求与事务最易导致数据库过载（每笔操作需消耗大量计算资源）。若服务可能引发查询峰值（如批量导入 API），需实施 “节流” 策略控制请求频率，防止数据库因过载陷入 “越慢越拥堵” 的恶性循环。

代码示例：数据库索引与查询优化

-- 1. 合理的用户表Schema设计（人类可读，避免过度JSON化）
CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL UNIQUE, -- 高基数字段
    user_type VARCHAR(50) NOT NULL,     -- 低基数字段（如"admin"/"user"）
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

-- 2. 联合索引设计（高基数字段email在前，匹配常用查询场景）
CREATE INDEX idx_users_email_type ON users (email, user_type);

-- 3. 高效查询：用JOIN替代多次查询，避免内存拼接
-- 需求：查询用户及其所属组织信息
SELECT u.id, u.email, o.org_name
FROM users u
JOIN organizations o ON u.org_id = o.id
WHERE u.user_type = 'admin' AND u.created_at > '2024-01-01';

-- 4. 避免ORM内循环查询：一次性获取所需数据
-- 反例（低效）：先查用户id，再循环查每个用户的详情
-- SELECT id FROM users WHERE user_type = 'user'; 
-- SELECT * FROM users WHERE id = 1; SELECT * FROM users WHERE id = 2; ...

-- 正例（高效）：一次性获取所有目标用户详情
SELECT id, email, user_type FROM users WHERE user_type = 'user';

四、快慢操作：任务拆分与后台处理

系统需同时处理 “低延迟响应” 与 “长耗时操作”，核心策略是拆分任务，通过后台异步处理长耗时操作：

快操作标准：用户交互场景（如 API 调用、网页加载）需在数百毫秒内返回响应（游戏领域虽要求 10 毫秒内，但实际成功产品中，用户可接受稍慢响应，前提是功能具备实用价值）。
慢操作处理方式：优先完成 “对用户有直接价值的最小任务集”，剩余任务移交后台处理。例如转换大型 PDF 文件时，先返回第一页的 HTML 结果，其余页面通过后台任务异步处理。

后台任务的两种实现方式

常规任务（短周期）：采用 “队列 + 任务执行器” 架构 —— 队列（如 Redis）存储任务（格式示例：{job_name: “pdf_render”, params: {file_id: 123}}），任务执行器从队列中提取任务并运行，支持定时执行（如每日日志清理）。
长期任务（长周期）：Redis 不适用于存储 “一个月后执行” 的任务（持久化可靠性不足，且查询难度高），此时需改用数据库表：创建包含任务参数与scheduled_at（计划执行时间）字段的表，通过每日定时任务筛选 “scheduled_at ≤ 当日” 的记录，执行完成后标记状态或删除。

代码示例：后台任务实现（常规任务与长期任务）

# 1. 常规短周期任务（基于Redis队列，使用Celery框架）
from celery import Celery
import redis

# 初始化Celery（Redis作为消息队列）
redis_client = redis.Redis(host='localhost', port=6379, db=0)
app = Celery('pdf_tasks', broker='redis://localhost:6379/0')

# 定义PDF渲染任务（短周期，数分钟内完成）
@app.task
def render_pdf_page(file_id: str, page_num: int) -> str:
    """渲染PDF指定页面为HTML，返回HTML内容"""
    # 模拟PDF渲染逻辑（实际需调用PDF处理库如PyPDF2）
    pdf_content = redis_client.get(f"pdf:{file_id}")
    html = f"Page {page_num} of PDF {file_id}"
    return html

# 任务调用：先渲染第一页（即时响应），剩余页面入队列（后台处理）
def handle_pdf_request(file_id: str, total_pages: int):
    # 1. 即时处理：渲染第一页，返回给用户
    first_page_html = render_pdf_page(file_id, page_num=1)
    
    # 2. 后台处理：剩余页面入队列
    for page in range(2, total_pages + 1):
        render_pdf_page.delay(file_id=file_id, page_num=page)
    
    return {"first_page": first_page_html, "status": "processing_remaining_pages"}

# 2. 长期任务（基于数据库表，每日定时扫描）
import sqlite3
from datetime import datetime

# 初始化数据库表（存储长期任务）
conn = sqlite3.connect('long_term_tasks.db')
cursor = conn.cursor()
cursor.execute('''
CREATE TABLE IF NOT EXISTS pending_tasks (
    id TEXT PRIMARY KEY,
    job_name TEXT NOT NULL,
    params JSON NOT NULL,
    scheduled_at TIMESTAMP NOT NULL,
    status TEXT DEFAULT 'pending' -- pending/completed/failed
)
''')
conn.commit()

# 每日定时任务：扫描并执行到期任务
def daily_task_scanner():
    today = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    # 查询今日及之前需执行的任务
    cursor.execute('''
    SELECT id, job_name, params FROM pending_tasks 
    WHERE scheduled_at <= ? AND status = 'pending'
    ''', (today,))
    tasks = cursor.fetchall()
    
    for task_id, job_name, params in tasks:
        try:
            # 执行任务（示例：发送月度账单）
            if job_name == 'send_monthly_bill':
                user_id = params['user_id']
                amount = params['amount']
                # send_bill_email(user_id, amount)  # 实际发送邮件逻辑
                
                # 标记任务完成
                cursor.execute('''
                UPDATE pending_tasks SET status = 'completed' WHERE id = ?
                ''', (task_id,))
                conn.commit()
        except Exception as e:
            # 标记任务失败（后续可重试）
            cursor.execute('''
            UPDATE pending_tasks SET status = 'failed', error = ? WHERE id = ?
            ''', (str(e), task_id))
            conn.commit()

五、缓存：缓解高成本操作的双刃剑

缓存用于解决 “重复执行高成本操作” 的问题，但需谨慎使用：

适用场景：例如计费服务需调用外部 API 获取实时价格，若采用按次计费模式（如 OpenAI 按 token 收费），会导致 “响应延迟高 + 外部服务流量过载”，此时每 5 分钟查询一次价格并缓存，可显著优化性能。
常见实现方案：内存缓存（实现简单但无法跨服务共享）、Redis/Memcached（支持跨服务共享，且读写速度快）。
核心原则：先优化，再缓存：初级工程师易倾向 “缓存所有内容”，但资深工程师会尽量减少缓存使用 —— 因为缓存同样属于 “状态载体”，可能出现数据不一致、过期数据（stale data）等问题。例如，对于慢 SQL 查询，应优先添加索引，而非直接缓存查询结果。
高级技巧：大结果缓存：若需缓存超大体积结果（如大客户的周度使用报表），Redis 存储能力不足时，可将结果按时间戳存入 S3 或 Azure Blob Storage，直接从存储服务返回文件。

import redis
import boto3
from datetime import timedelta
from typing import Dict

# 1. 常规缓存：Redis缓存外部API价格（5分钟过期）
redis_client = redis.Redis(host='localhost', port=6379, db=1)
PRICE_CACHE_TTL = timedelta(minutes=5).total_seconds()  # 缓存过期时间

def get_price_from_external_api(product_id: str) -> float:
    """模拟调用外部API获取价格"""
    # 实际逻辑：response = requests.get(f"https://api.example.com/price/{product_id}")
    return 0.01  # 示例：假设每单位价格0.01元

def get_cached_price(product_id: str) -> float:
    """优先从缓存获取价格，缓存未命中则调用API并更新缓存"""
    cache_key = f"price:{product_id}"
    
    # 1. 尝试从缓存获取
    cached_price = redis_client.get(cache_key)
    if cached_price:
        return float(cached_price)
    
    # 2. 缓存未命中，调用API
    price = get_price_from_external_api(product_id)
    
    # 3. 更新缓存（设置过期时间，避免数据 stale）
    redis_client.setex(cache_key, PRICE_CACHE_TTL, str(price))
    return price

# 2. 大结果缓存：S3存储大客户周度报表（避免Redis内存不足）
s3_client = boto3.client('s3', aws_access_key_id='YOUR_KEY', aws_secret_access_key='YOUR_SECRET')
S3_BUCKET = 'report-cache-bucket'

def generate_weekly_report(customer_id: str) -> str:
    """生成大客户周度报表（模拟大体积结果，如100MB+）"""
    # 实际逻辑：从数据库查询大量数据，生成详细报表
    report_content = f"Weekly Report for Customer {customer_id}: ... (large content)"
    return report_content

def get_cached_weekly_report(customer_id: str, week: str) -> str:
    """从S3获取缓存报表，不存在则生成并上传"""
    # 构建S3对象键（包含时间戳，确保唯一性和可追溯性）
    s3_key = f"weekly_reports/{customer_id}/{week}.html"
    
    try:
        # 1. 尝试从S3下载缓存
        response = s3_client.get_object(Bucket=S3_BUCKET, Key=s3_key)
        return response['Body'].read().decode('utf-8')
    except s3_client.exceptions.NoSuchKey:
        # 2. 缓存未命中，生成报表
        report = generate_weekly_report(customer_id)
        
        # 3. 上传到S3（作为持久化缓存）
        s3_client.put_object(
            Bucket=S3_BUCKET,
            Key=s3_key,
            Body=report,
            ContentType='text/html'
        )
        return report

六、事件：解耦多服务通信的工具

多数企业会部署事件中心（如 Kafka），但该工具并非适用于所有场景：

本质定义：事件中心是一种 “事件队列”，与后台任务队列的区别在于，其存储的是 “某事件已发生” 的信息，而非 “执行某任务” 的指令。例如 “新账户创建” 事件，可被 “发送欢迎邮件”“滥用行为扫描”“账户基础设施初始化” 等多个服务消费。
使用边界：
- 优先选择 API 调用：API 调用的日志集中、逻辑可追溯性强、能实时获取响应结果，多数场景下优于事件通信。
- 适合使用事件的场景：发送方无需关注消费方行为（如 “新账户创建” 事件无需确认邮件是否发送成功），或事件流量大且对实时性要求低（如社交平台中每篇新内容的滥用扫描）。

代码示例：Kafka 事件通信实现

from kafka import KafkaProducer, KafkaConsumer
import json
from typing import Dict

# 1. 事件生产者：发送“新账户创建”事件
producer = KafkaProducer(
    bootstrap_servers=['localhost:9092'],
    value_serializer=lambda v: json.dumps(v).encode('utf-8')
)

def send_new_account_event(account_data: Dict[str, str]):
    """当新账户创建时，发送事件到Kafka"""
    event = {
        "event_type": "new_account_created",
        "timestamp": json.dumps(datetime.now()),
        "data": account_data  # 包含账户核心信息：id、email、created_at等
    }
    # 发送到指定主题（topic）
    producer.send('account_events', value=event)
    producer.flush()  # 确保事件被发送

# 2. 事件消费者1：接收事件并发送欢迎邮件
email_consumer = KafkaConsumer(
    'account_events',
    bootstrap_servers=['localhost:9092'],
    value_deserializer=lambda m: json.loads(m.decode('utf-8')),
    group_id='email_service_group'  # 消费者组：确保事件被消费一次
)

def consume_for_email():
    for message in email_consumer:
        event = message.value
        if event["event_type"] == "new_account_created":
            account_email = event["data"]["email"]
            # send_welcome_email(account_email)  # 实际发送邮件逻辑
            print(f"Sent welcome email to {account_email}")

# 3. 事件消费者2：接收事件并执行滥用扫描
abuse_consumer = KafkaConsumer(
    'account_events',
    bootstrap_servers=['localhost:9092'],
    value_deserializer=lambda m: json.loads(m.decode('utf-8')),
    group_id='abuse_scan_group'
)

def consume_for_abuse_scan():
    for message in abuse_consumer:
        event = message.value
        if event["event_type"] == "new_account_created":
            account_id = event["data"]["id"]
            account_email = event["data"]["email"]
            # scan_for_abuse(account_id, account_email)  # 实际滥用扫描逻辑
            print(f"Scanned abuse for account {account_id} ({account_email})")

七、数据流动：推模式与拉模式的选择

数据从 “源头” 传递至 “多个接收方” 时，存在两种核心模式，需根据场景选择：

两种模式的核心差异
- 拉模式（Pull）：接收方主动请求数据，例如普通网站 —— 用户刷新邮箱时，浏览器向服务器请求最新邮件数据。缺点是易出现 “重复拉取相同数据” 的情况（如刷新页面时重新加载全部内容）。
- 推模式（Push）：接收方完成注册后，数据发生变化时由源头主动推送，例如 Gmail—— 新邮件到达后无需刷新页面，会自动显示。
不同场景下的选择策略
- 服务间通信：若数据更新频率低（如配置信息），推模式更优 —— 数据更新时向 100 个服务各发送 1 次请求，比 100 个服务每秒各拉取 1 次（累计 1000 次 / 秒）更高效。
- 百万级客户端场景（如 Gmail）：
  - 推模式：将推送任务加入事件队列，通过大量事件处理器从队列提取任务，分别向客户端推送数据。
  - 拉模式：部署数百台 “快速读从库缓存”（无需频繁与主库交互，可存储内存数据或磁盘静态数据），集中处理所有读请求。

代码示例：推模式与拉模式实现（服务间通信）

# 1. 拉模式（服务A主动拉取服务B的配置数据）
import requests
from time import sleep

def pull_config_from_service_b(service_a_id: str) -> Dict:
    """服务A每隔10秒拉取服务B的配置数据"""
    while True:
        try:
            # 主动请求服务B的配置接口
            response = requests.get(f"https://service-b.example.com/config?service_id={service_a_id}")
            config = response.json()
            # update_local_config(config)  # 更新本地配置
            print(f"Service A pulled config: {config}")
        except Exception as e:
            print(f"Pull config failed: {str(e)}")
        sleep(10)  # 每10秒拉取一次

# 2. 推模式（服务B主动推送配置到服务A）
from flask import Flask, request

app = Flask(__name__)
# 存储已注册的服务A实例（实际生产环境用分布式存储）
registered_services = set()

# 服务A注册接口：告知服务B“需要接收配置推送”
@app.route('/register', methods=['POST'])
def register_service():
    service_id = request.json.get('service_id')
    service_url = request.json.get('service_url')
    registered_services.add((service_id, service_url))
    return {"status": "success"}

# 配置更新时，主动推送到所有注册的服务A
def push_config_to_services(new_config: Dict):
    """服务B配置更新时，推送到所有已注册的服务A"""
    for service_id, service_url in registered_services:
        try:
            # 主动推送配置到服务A的接收接口
            requests.post(
                f"{service_url}/config/update",
                json={"service_id": service_id, "config": new_config}
            )
            print(f"Pushed config to service {service_id}")
        except Exception as e:
            print(f"Push to service {service_id} failed: {str(e)}")

# 模拟配置更新：当服务B配置变化时触发推送
new_config = {"max_requests": 1000, "timeout": 30}
push_config_to_services(new_config)

八、聚焦关键：热路径设计

系统设计无需追求 “全面覆盖”，应重点关注热路径（Hot Path）：

定义：系统中 “业务价值最高” 且 “数据流量最大” 的部分。例如在计量计费系统中，“判断是否向客户收费” 与 “接入所有用户行为以计算费用” 均属于热路径。
重要性原因：
- 解决方案局限性高：非热路径（如计费设置页面）的实现方式多样，而热路径（如处理用户行为数据流）的合理解决方案可能仅少数几种。
- 故障影响范围广：非热路径故障（如设置页面异常）难以导致整体产品不可用，但触发所有用户行为的代码若存在漏洞，会直接引发全局故障。

代码示例：热路径设计实现（用户行为计费）

import redis
from typing import Dict

redis_client = redis.Redis(host='localhost:6379', db=2)
BILLING_RATE = 0.001  # 每行为单位计费价格

def process_user_action(user_id: str, action_type: str, action_data: Dict):
    """
    热路径：处理用户行为并计算费用
    特点：高并发（每秒数千次调用）、高准确性（计费不能出错）
    """
    # 1. 快速过滤：仅对需计费的行为处理（减少无效计算）
    billable_actions = {"api_call", "file_upload"}
    if action_type not in billable_actions:
        return {"status": "success", "billable": False}
    
    # 2. 幂等性保障：避免重复计费（关键！热路径必须防重复）
    action_id = action_data.get("action_id")  # 唯一行为ID（如UUID）
    if redis_client.exists(f"billed:{action_id}"):
        return {"status": "success", "billable": True, "duplicate": True}
    
    # 3. 轻量计算：减少热路径中的复杂逻辑（复杂计算移至后台）
    # 示例：按API调用次数计费，直接用Redis自增计数
    usage_key = f"usage:{user_id}:{action_type}:{datetime.now().strftime('%Y-%m')}"
    redis_client.incr(usage_key)  # 原子操作，确保计数准确
    
    # 4. 标记已计费（先标记，再异步计算总费用，避免热路径阻塞）
    redis_client.setex(f"billed:{action_id}", timedelta(days=30), "1")  # 30天过期
    
    # 5. 异步触发后续流程（非热路径：计算总费用、生成账单）
    calculate_monthly_bill.delay(user_id, usage_key)  # 后台任务（Celery等）
    
    return {"status": "success", "billable": True, "duplicate": False}

九、可观测性：日志与监控体系

“提前发现系统问题” 比 “问题发生后修复” 更重要，核心依赖日志与监控：

日志：重点记录 “异常路径”
- 设计原则：在 “流程异常” 场景中增加日志输出。例如返回 422 响应时，记录 “触发 422 的具体条件”；计费逻辑中，记录 “因某原因不执行收费的决策依据”。
  核心价值：排查用户问题时不可或缺 —— 若重要客户遇到 422 错误，即便问题源于客户操作，也需明确 “具体操作行为”，不可为追求代码简洁省略关键日志。
监控：关注 “核心指标 + 长尾延迟”
- 运维指标：需监控主机 / 容器的 CPU 使用率、内存占用、队列长度、请求 / 任务的平均耗时。
- 用户体验指标：必须关注p95/p99 延迟（即 95%/99% 的请求耗时低于该数值），而非仅依赖平均值。例如 100 个请求中，98 个耗时 100 毫秒、2 个耗时 10 秒，平均值仅 298 毫秒，但这 2 个慢请求可能来自核心客户，平均值会掩盖真实的用户体验问题。

代码示例：日志与监控实现（Python+Prometheus）

import logging
from prometheus_client import Counter, Histogram, start_http_server
from time import time

# 1. 日志配置：重点记录异常路径，包含关键上下文
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    handlers=[logging.FileHandler("app.log"), logging.StreamHandler()]
)
logger = logging.getLogger("system_design")

def validate_user_input(input_data: Dict) -> bool:
    """验证用户输入，异常时记录详细日志"""
    if "email" not in input_data:
        # 记录“缺失字段”的异常日志，包含输入详情（脱敏敏感信息）
        logger.error(
            "User input validation failed: missing 'email' field. "
            "Input (masked): %s",
            {k: v for k, v in input_data.items() if k != "password"}  # 脱敏密码
        )
        return False
    if "@" not in input_data["email"]:
        logger.warning(
            "User input validation warning: invalid email format. "
            "Email: %s",
            input_data["email"]
        )
        return False
    return True

# 2. 监控指标：统计请求量、错误率、延迟（含p95/p99）
# 初始化Prometheus指标
REQUEST_COUNT = Counter(
    "http_requests_total", 
    "Total number of HTTP requests",
    ["endpoint", "method", "status_code"]
)
REQUEST_LATENCY = Histogram(
    "http_request_duration_seconds",
    "Duration of HTTP requests in seconds",
    ["endpoint"],
    buckets=[0.1, 0.3, 0.5, 1.0, 3.0, 5.0]  # 桶边界：用于计算p95/p99
)

# 监控装饰器：统计请求指标
def monitor_request(endpoint):
    def decorator(func):
        def wrapper(*args, **kwargs):
            start_time = time()
            status_code = 200
            
            try:
                # 执行实际请求处理函数
                result = func(*args, **kwargs)
                return result
            except Exception as e:
                status_code = 500
                raise e
            finally:
                # 记录请求耗时
                latency = time() - start_time
                REQUEST_LATENCY.labels(endpoint=endpoint).observe(latency)
                # 记录请求计数
                REQUEST_COUNT.labels(
                    endpoint=endpoint,
                    method=kwargs.get("method", "GET"),
                    status_code=status_code
                ).inc()
        return wrapper
    return decorator

# 示例：用装饰器监控“用户注册”接口
@monitor_request(endpoint="/api/register")
def handle_register_request(method: str, data: Dict):
    if not validate_user_input(data):
        return {"status": "error"}, 422
    # 实际注册逻辑：create_user(data)
    return {"status": "success"}, 201

# 启动Prometheus暴露端口（默认9090）
start_http_server(9090)

十、容错设计：熔断、重试与优雅失败

系统故障不可避免，关键在于 “故障发生时减少影响范围”：

重试的局限性与熔断的必要性
- 避免盲目重试：若服务已返回 5xx 错误，盲目重试会增加服务负载，加剧故障严重程度。
- 熔断机制的作用：对高流量 API，若连续收到大量 5xx 错误，应暂时停止发送请求（如暂停 30 秒），为服务预留恢复时间。
- 写请求重试的注意事项：需使用 “幂等键（Idempotency Key）”—— 在请求中携带唯一 UUID，服务执行后存储该键；若收到相同键的请求，直接忽略，避免重复执行（如 “给用户计费” 请求返回 5xx，无法确定是否已计费，幂等键可防止重复扣费）。
优雅失败：开放与关闭的权衡
- 当部分系统故障时，需决策 “是否允许请求通过”：
  - 失败开放（Fail Open）：故障时放请求通过。例如限流系统依赖的 Redis 不可用，暂时允许所有请求 —— 避免限流故障引发用户可见问题。
  - 失败关闭（Fail Closed）：故障时拒绝请求。例如认证服务不可用，直接返回 401—— 宁可不允许合法用户访问，也不能泄露他人数据。
- 多数场景无标准答案，需结合业务风险权衡。

代码示例：熔断与幂等性设计（Python+tenacity）

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
from tenacity.before_sleep import before_sleep_log
from circuitbreaker import CircuitBreaker, CircuitBreakerError
import logging
import requests
import uuid

logger = logging.getLogger("fault_tolerance")

# 1. 熔断机制：使用circuitbreaker库，连续5次失败则熔断30秒
@CircuitBreaker(failure_threshold=5, recovery_timeout=30, fallback_function=None)
def call_external_payment_service(amount: float, user_id: str) -> Dict:
    """调用外部支付服务，熔断保护避免服务过载"""
    try:
        response = requests.post(
            "https://payment-service.example.com/charge",
            json={
                "user_id": user_id,
                "amount": amount,
                # 幂等键：确保重复请求不会重复扣费（UUID唯一）
                "idempotency_key": str(uuid.uuid4())
            },
            timeout=5.0
        )
        response.raise_for_status()  # 触发HTTP错误（4xx/5xx）
        return response.json()
    except requests.exceptions.RequestException as e:
        logger.error(f"Payment service call failed: {str(e)}")
        raise  # 抛出异常，让熔断器计数

# 2. 重试机制：仅对特定异常重试，且指数退避（避免瞬时故障）
@retry(
    stop=stop_after_attempt(3),  # 最多重试3次
    wait=wait_exponential(multiplier=1, min=1, max=10),  # 指数退避：1s→2s→4s
    retry=retry_if_exception_type((requests.exceptions.Timeout, requests.exceptions.ConnectionError)),
    before_sleep=before_sleep_log(logger, logging.WARNING)  # 重试前打印日志
)
def call_retryable_service(api_url: str) -> Dict:
    """调用可重试服务（如读请求），仅对超时/连接异常重试"""
    response = requests.get(api_url, timeout=3.0)
    response.raise_for_status()
    return response.json()

# 3. 优雅失败：限流系统Redis故障时的策略选择
def check_rate_limit(user_id: str) -> bool:
    """检查用户是否触发限流，Redis故障时选择“失败开放”"""
    try:
        # 正常逻辑：从Redis获取用户请求计数
        redis_key = f"rate_limit:{user_id}"
        current_count = redis_client.incr(redis_key)
        if current_count == 1:
            redis_client.expire(redis_key, 60)  # 1分钟窗口
        return current_count <= 100  # 限流阈值：1分钟100次
    except Exception as e:
        logger.error(f"Rate limit Redis failed: {str(e)}")
        # 失败开放策略：Redis故障时允许请求通过（避免用户无法使用服务）
        return True

# 4. 认证服务故障时的“失败关闭”策略
def authenticate_user(token: str) -> bool:
    """验证用户token，认证服务故障时拒绝访问"""
    try:
        # 正常逻辑：调用认证服务验证token
        response = requests.post(
            "https://auth-service.example.com/verify",
            json={"token": token},
            timeout=2.0
        )
        return response.json().get("valid", False)
    except Exception as e:
        logger.error(f"Auth service failed: {str(e)}")
        # 失败关闭策略：认证服务故障时拒绝访问（避免数据泄露）
        return False

十一、总结：好设计的本质是 “平淡”

本文未覆盖微服务拆分、容器 / VM 选择、链路追踪等话题 —— 要么是因为这些决策对 “系统好坏” 影响不大（如单体应用多数时候足够好），要么是太基础无需强调（如链路追踪是必备工具），要么是复杂度过高（如 API 设计需单独展开）。

核心观点始终是：好的系统设计，不是用花哨技巧，而是在正确的地方用成熟、经过验证的组件。就像优质的管道工程不会 “惊艳”—— 若操作太复杂，反而容易出现问题。

尤其在大型企业中，现成的基础设施（事件总线、缓存服务等）已足够完善，好的设计往往 “看不见”。实践中，“自定义数据结构实现关键功能” 的惊艳设计极少出现，而 “平淡的、可靠的设计”，才是支撑系统稳定运行的主流。

Claude Code 背后的设计思考

2025-08-04T00:00:00.000Z

观视频有感：《Anthropic 的工程师们如何适应 AI 编程工具》

How Anthropic Engineers Are Adapting to AI Coding Agents

产品哲学与设计巧思

“改变实现方式，而非工具本身”：Jacqueline 提出的这个观点非常深刻。在推广新工具时，最好的策略不是让开发者抛弃他们熟悉的命令行或 IDE，而是在他们已有的工具链中，以一种无缝、无打扰的方式增加新功能。这极大地降低了心理排斥感。

终端是“最大公约数”：他们选择终端作为主战场，是因为这是唯一一个几乎所有后端和基础设施工程师都会高频使用的界面。这个选择本身就是“在用户所在之处满足他们”哲学的最佳体现。

为“可折腾性”而生 (Designed for Tinkerability)：Claude Code 被设计成高度可扩展和定制的。这不仅仅是一个功能，更是一种邀请，鼓励用户把它接入自己独特的环境，喂给它独特的上下文，让它从一个“通用实习生”变成一个“资深项目成员”。

Anthropic 内部工作流

Claude Code 的诞生故事：它不是一个自上而下规划的产品，而是工程师 Boris 为了熟悉自家 API 发起的一个个人项目。因为太好用了，所以像涟漪一样从个人、到团队、到实验室、再到整个公司，最终在对外发布时，内部大部分技术人员已经是它的日活用户了。这种有机的、自下而上的生长路径本身就证明了它的价值。

AI 时代的 Code Review 新范式：当 AI 大量生成代码时，审查责任如何分配？Anthropic 的答案是：责任在于 PR 的作者，而非审查者。 Claude Code 通过支持“测试驱动开发”（TDD）等方式，帮助作者在提交前就建立信心。作者可以用它生成测试，或者让它截图验证前端修改，确保提交的代码质量。

鼓励“广谱实验”：内部工程师可以自由使用 Claude Code、GitHub Copilot 甚至其他创业公司的 AI 工具。他们鼓励大家用 AI 去挑战非常困难的任务，因为只有在 pushing the boundary 的时候，你才能真正发现 AI 的惊人能力，比如给它一个晦涩的 GCP 堆栈跟踪，它能立刻看懂并修复，直接节省4小时。

Jacqueline 的黑客马拉松亲身经历：她在一个自己完全不熟悉的语言和代码库上，仅用了一天时间，就借助 Claude 做出了一个可以工作的演示。这是“从文档到演示”理念最有说服力的真人案例。

研究员与工程师的“统一战线”：在 Anthropic，研究员和工程师为同一个代码库（monorepo）贡献代码，使用相同的开发环境和工具集。这意味着对工具（比如 CLAUDE md）的任何投资和优化，都能让所有人受益，实现了规模效应。

高阶玩法与最佳实践

“多 Claude”详解：

目的：并行处理多个独立任务。
最佳实践：最好在不重叠的仓库中实例化多个 Claude，或者使用 GitHub worktrees、直接 git clone 多份等方式，避免多个代理修改同一份文件造成冲突和混乱。
认知极限：Ben 和 Cat 提到，3个claude进程是普通人的“甜点位”，有人能同时驾驭 6 个，甚至有人跑 12 个（可能是异步运行）。

“多 Claude” vs “子代理”：

多 Claude：用于处理多个不同的独立任务。
子代理：用于加速同一个核心任务，通过并行处理或引入不同视角（安全、产品等）来提升效率和质量。

如何让 Claude 更懂你的代码库：

通用原则：如果一个人类新员工能轻松看懂你的代码库（文档齐全、命名清晰、抽象合理），那 Claude 就能做得很好。反之，如果代码库里到处都是需要“祖传知识”才能理解的坑，Claude 也会一样懵。
处理多仓库依赖：可以在包含所有相关仓库的上级目录实例化 Claude，或者使用新推出的 add dir 功能，把其他仓库的访问权限授予当前会话。

迭代式地处理复杂任务：当面对大型重构或提升测试覆盖率这类复杂任务时，不要指望一步到位。最佳策略是：先从一两个文件开始，观察 Claude 在哪里会失败，然后迭代优化你给它的指令，最后再逐步扩大规模。

安全 & 局限

精细化的权限系统：他们的权限系统不只是简单的“是/否”，而是拆分成了读取文件、编辑文件、搜索、执行 bash 命令等多个维度，让用户可以进行更细粒度的授权。

内置的提示注入防护：当使用网页搜索等功能时，获取到的外部内容会先经过一个分类器模型进行“安检”，判断是否存在提示注入风险，然后再交给主代理。

公开承认的失败与教训：

他们曾尝试让 Claude Code 自动创建大量 PR，结果造成了内部的“信息垃圾 (spam)”，后来不得不调整限制。
有一长串功能已经构建出来了，但因为觉得模型成功率还不够高，最终没有发布。他们对开发者的“垃圾信息敏感度”有清醒的认识。

对“代码品味”的思考：Kyle 问 AI 何时能达到 100% 自动编程，Cat 认为很多不是原始“智能”的问题，而是**产品和“代码品味”**的问题。模型需要看到更多元、更优秀的代码库来学习，而不是简单地增加上下文窗口长度。

异步运行的取舍：Jacqueline 提到她会通过 Slack 异步触发一些 Claude Code 任务，让它们在后台无人监督地运行。这样做的好处是能并行处理更多任务，但代价是结果的方差会更大，不一定能成功。这是一个典型的效率与可控性之间的权衡。

未来规划

迈向“主动式”代理：未来的 Claude Code 不仅是被动地等你下命令，更希望能变得主动 (proactive)。它能读取你和你队友所有的历史会话，从中提取见解，甚至能主动维护一个 CLAUDE md 文件，成为团队知识的沉淀者和管理者。

成为开发者的“信息中枢”：未来的方向是让 Claude Code 能访问开发者能接触到的一切信息——Slack, Jira, PRD, 工程规范, 客户支持工单等等。上下文越完整，代理的能力就越强。

赋能开发者构建自己的代理：他们会大力投入 SDK 的建设，确保其功能与 CLI 体验对齐，最终目标是让所有开发者都能灵活、强大地构建出满足自己需求的、千奇百怪的 AI 代理。

中国的通缩危机

2025-07-30T00:00:00.000Z

通缩比通胀可怕，通缩是会死人的

1933年，经历了大萧条，和个人破产的欧文·费雪提出了“债务-通缩理论”：当物价持续下跌时，债务的实际负担会急剧放大。因为货币购买力增强，借款人需用更多“值钱”的钱来还债，导致破产潮涌现，企业清算、失业激增，进一步压低需求，形成恶性循环。

这就是著名的“通缩螺旋”：消费延迟，因为人们预期明天更便宜；投资停滞，因为回报率不确定；工资下降，因为企业利润蒸发。最终，整个经济体如一艘漏水的船，沉没在绝望的深渊中。

中国目前的情况，和费雪的通缩的9个环节，一毛一样（如表）。

面对如此清晰的病症，任何理性的医生都会开出同样的药方：需求不足，就刺激需求。

诺贝尔奖得主保罗·克鲁格曼称中国领导层“匪夷所思地不愿意”转向内需。
国内外的几乎所有的经济学家观点几乎都一致：中国经济的核心症结，在于居民消费占GDP的比重过低，家庭收入分到的蛋糕太小。

诊断如此明确，治疗方案也本该如此。然而，我们看到的却是堪称荒诞的“疗法”。
官方的药方是“供给侧结构性改革” 。这好比试图通过给一个饥肠辘辘的人换一口更先进的锅，来解决他的饥饿问题。
向一个需求枯竭的经济体注入更多供给——无论是光伏、电动车还是别的什么“新质生产力”——只会加剧通缩的泥潭，并将过剩产能的祸水引向全世界。

这种看似不理性的政策背后，是极其理性但残酷的政治算计。
因为中国过去几十年的增长模式，其根基就是通过压低利率（惩罚储户）、压低工资和薄弱的社会保障（迫使民众储蓄），系统性地将财富从家庭部门转移到生产部门（尤其是国有企业和地方政府）。

因此，真正的结构性改革——即提高居民收入、建立强大的社会安全网——意味着要彻底颠覆这一权力与利益的分配格局。它意味着地方政府将失去大搞形象工程的资金，国有企业再也无法享受廉价资本的盛宴。中央政府可能要防宽对经济政策的控制。

这并非一次经济政策的调整，而是一场权力的再分配。政府之所以迟迟不愿给奄奄一息的需求侧“喂药”，是因为这药会损害国家利维坦的根基。

他们宁愿牺牲民营部门，也要保卫国家部门的利益堡垒。所谓“供给侧改革”而不进行“需求侧改革”，说到底，不过是为了避免彻底的“体制改革”，保护既得利益者的防火墙。

好高骛远是一种巧妙的自我毁灭

2025-07-18T00:00:00.000Z

背景文章链接：

being too ambitious is a clever form of self-sabotage

文章逻辑概括
文章遵循 “提出问题→分析原因→论证解法→总结呼吁” 的逻辑，层层递进：
1. 现象引入：先描绘 “创作前的完美想象”，点出其虚幻本质 —— 想象中的完美会阻碍行动。
2. 问题深挖：分析 “想象与现实的差距” 为何产生：人类独有的 “品味 - 技能差异”+ 大脑的 “目标替代” 机制 + 技术时代的 “完美幻象”，共同导致人们逃避实践。
3. 反常识论证：通过摄影实验、作者经历等证明：“数量积累”（反复实践）比 “完美计划” 更有效，因为实践能让人在失败中学习、在调整中接近目标。
4. 解决方案：提出 “降低期待”“直面放弃点”“做中学”—— 接纳不完美，用持续行动替代空想，才能让想象落地。
5. 总结：人类的 “诅咒”（被完美愿景折磨）亦是 “天赋”（敢于想象超越能力的未来），而连接想象与现实的唯一方式，是 “放下完美执念，动手实践”。

在佛罗里达大学的摄影课堂上，杰瑞・尤尔斯曼（Jerry Uelsmann）无意间设计了一个堪称完美的实验，让人们得以窥见 “卓越” 的本质。他将学生分成了两组。

数量组的评分标准完全取决于产出量：拍够 100 张照片得 A，90 张得 B，80 张得 C，以此类推。

而质量组只需提交一张 “完美” 的照片即可。

学期结束时，所有脱颖而出的优秀作品都来自数量组。

数量组领悟了一些无法通过课堂传授的道理：卓越源于与不完美的深度碰撞，精通是在与失败的不断周旋中铸就的，创造一件完美事物的道路，必然要先踏过无数不完美的尝试。

不妨想想那 100 次尝试的真正意义：那是 100 次与光线的对话，100 次构图的实验，100 次直面 “意图与结果差距” 并调整的机会，更是 100 次发现 “现实对愿景的反馈往往比最初的计划更有趣” 的契机。

与此同时，质量组在整个学期都深陷 “理论炼狱”—— 分析完美的照片，研究理想的构图，探究最优的技巧。他们积累了丰富的摄影知识，却始终没能获得那种 “唯有反复按下快门并承担结果才能沉淀的实践智慧”。

当数量组在真实的 “领土” 上探索时，质量组成了精通 “地图” 的专家。学期结束时，质量组能告诉你一张好照片 “为什么好”，而数量组早已能拍出好照片。

胶片不在乎他们的意图，只回应他们按下快门的意愿

三五好友

2025-06-09T00:00:00.000Z

最近整理了下自己看过的电视剧

发现老友记或者请回答 1988 那种，三五好友的朋友生活

是我所期望，并且过得舒适的

可奇怪的是我当下没有个所谓的生活朋友圈

我没有那种微信群里面的人聊的是各种的生活常态

（游戏群倒是有）

所以我突然想维护这样一个圈子

这样到了中年

哪怕自己没有孩子

生活也不会枯燥可以串门

因为你只要看过老友记或者机智的医生生活那种
你就知道形态各异的几个朋友相处在一起
生活多么有意思

就比如一个点

你们周末完全可以聚在一个人家里一块做饭玩桌游或者相约出去玩

这个前提就是你们是合拍的

如果彼此不共鸣那在一起会发生很多意见

然后根据自己的经验来看

富有分享欲 + 随意型人格 + 说话不犀利

是这个圈子里的人的共性

再举个例子

你今天上班突然遇到了莫名其妙的事情或者瓜

你这时候如果很想说给别人听

但又处于拔剑四顾心茫然的状态

那很有可能你就是需要一个这种小圈子

互相吃瓜

这种需要长期来维护

就是群里不能说有潜水的

我以前试图发展室友成这样的关系

所以我那会儿去北京的时候特喜欢找合租的

去到一个人生地不熟的地方；能够以崭新的姿态去认识新伙伴接触新生活

简直像游戏里面的重开一样

social 属性突然大爆发

这种圈子有个好处

就是告诉你你时刻还是为了你自己生活（而不是在成家之后变成了为家庭而活）

因为你时刻还有一帮子朋友知晓你的过去现在一起走未来

胜者举杯相庆败者拼死相救