Prompt on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Sun, 12 Apr 2026 08:38:12 +0000

前两天在写一篇技术文章，写到一半需要配一张微服务架构图。我打开了某在线画图工具，对着空白画布发了十分钟的呆，拖了两个方块，连了一条线，觉得丑，删掉，再拖两个方块。

半小时过去了，图还没画完，文章的灵感已经凉透了。

我相信很多搞技术内容的朋友都有过这种体验。你脑子里其实很清楚这张图应该长什么样，但你就是得花一两个小时在画图工具里对齐、配色、调字号。明明内容才是核心，结果时间全花在了排版上。

然后我发现了一个东西，彻底解决了这个问题。

它叫 fireworks-tech-graph，是一个 Claude Code 的 skill。装上之后，你跟 Claude Code 说一句中文，它就能给你吐出一张出版级别的技术图。SVG 矢量源文件加 1920px 高清 PNG，直接能往文章里塞。

我用它画了10张不同类型的图，从架构图到 ER 图到状态机，从白底极简到暗色霓虹到工程蓝图。每张图从下指令到拿到成品 PNG，平均不超过30秒。

30秒。

我之前在画图工具里对齐一个箭头的时间都不止30秒。

怎么装呢，你甚至不需要记任何命令。

打开 Claude Code，直接跟它说「帮我安装 fireworks-tech-graph 这个 skill」，它自己就把活干了。装完之后你说「画一个 xxx 图」，它就自动触发。

如果你喜欢手动装也行，就一句 claude skills install fireworks-tech-graph，完事。

触发词非常宽泛，「画图」「帮我画」「做个架构图」「生成一个流程图」「可视化一下」，随便怎么说都行，它都能识别。

它能画什么？

这个 skill 支持10种有模板的图表类型，外加4种无模板但有规则定义的类型。我挑几个最实用的说一下。

1，架构图。这是用得最多的，画微服务分层、系统组件关系。你告诉它有哪些服务、怎么分层、哪些组件之间有调用关系，它自动帮你排好。我画的那张微服务架构图有5层，右侧还挂了一个观测性旁路，出来的效果跟正经架构文档里的图一模一样。

2，流程图。CI/CD 流水线、审批流、业务决策流。菱形判断节点、圆角矩形处理步骤、失败回环，全都有。你只需要描述「从提交代码到部署生产」中间经过哪些步骤和判断就行。

3，时序图。微服务之间谁先调谁，消息怎么传递。标准的 UML 时序图，有生命线、激活框、alt 分组框。你列出参与者和消息序列，它帮你排好。

4，ER 图。数据库表之间的关系。支持鸦脚记法，PK 自动下划线，FK 标注。你把实体和属性列出来，告诉它哪些是一对多、哪些是多对多，它画出来的东西可以直接放进数据库设计文档。

5，状态机。订单生命周期、工单状态流转这种。每个状态是一个圆角矩形，转换线上标事件名，有初始态的实心圆和终态的同心圆。

6，对比矩阵。横评几个模型、几个方案的时候特别好使。我画了一张 LLM 模型对比表，5个模型7个维度，绿色打勾红色打叉，交替行填充，出来就是一张可以直接发朋友圈的表。

7，时间线。项目路线图、版本规划。甘特图样式，彩色横条加菱形里程碑。

除了这些，还有 Agent 架构图、用例图、数据流图。反正你在技术写作里能用到的图，它基本都覆盖了。

比较骚的是它有7种视觉风格，每种味道完全不一样。

默认的 Flat Icon 是白底彩色，适合博客和文档。Dark Terminal 是暗色霓虹风，发 GitHub 和技术社区特别帅。Blueprint 是工程蓝图风，深蓝色背景加网格线加角标，那种 CAD 图纸的感觉。Notion Clean 是极简白，一根线一个色。Glassmorphism 是毛玻璃卡片，适合产品官网和 Keynote。最近还加了 Claude Official 和 OpenAI Official 两种风格，分别是 Anthropic 和 OpenAI 的品牌调性。

你指定风格的方式就是在 prompt 里加一句「用蓝图风」或者「Style 3」，就这么简单。

我觉得这个 skill 最打动我的点，不是它画得多漂亮，而是它把「画图」这件事的心理门槛降到了零。以前我写文章需要配图的时候，经常会想「算了这里用文字描述一下也行吧」，因为打开画图工具、画完、导出、插入这一套流程太重了。现在不一样了，我在 Claude Code 里写着文章，写到需要配图的地方，直接说一句「帮我画一个 xxx」，30秒后图就在本地了。

这种体验就像是，你本来在用文本编辑器写代码，突然有人给你装了一个实时预览插件。功能上没变，但那个「随时能看到效果」的即时反馈感，会让你更愿意去做这件事。

画图也是一样。当成本足够低的时候，你会发现你开始「想画就画」了。

想试的朋友，打开 Claude Code，说一句「帮我安装 fireworks-tech-graph」，等它装完，再说一句「画一个 xxx 图」。

就这么简单。两句话的事。

下面附一些 demo 图：

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

Mon, 30 Mar 2026 11:58:33 +0000

导读：在 AI 辅助编程普及的今天，你的团队是怎么写代码的？是靠开发者随心所欲的“自然对话”，还是有严谨的工作流约束？本文将为你详细拆解“轻量 Harness 化 AI 研发工作流”的设计思路、工具选型与落地路径。无论你是独立开发者还是研发团队负责人，这套直接可抄作业的 Workflow 都不容错过。

一、 AI 编程的“向左走向右走”

当前 AI 编程的实践，大致演化出了两条截然不同的路径：Vibe Coding 与 规范驱动开发 (SDD)。

维度	🎨 Vibe Coding (直觉编程)	📐 规范驱动开发 (SDD)
核心理念	自由交互，强调开发者与 AI 的自然对话	规范先行，以 Spec 为唯一事实来源
适用场景	快速原型、概念验证、探索性开发	生产环境、复杂系统、高质量要求
侧重点	提示词 (Prompt) 工程的灵活性	规范的严谨性与完整性

⚠️ Vibe Coding 的隐患：

随着大模型能力的增强，Vibe Coding 搭配插件确实能快速出活。但在团队级实践中，它暴露出 4 个致命问题：

1.效果不可控：不同模型、不同 Prompt 风格的产出质量参差不齐。

2.幻觉难约束：缺乏结构化约束，强如顶尖模型也会“胡编乱造”。

3.技术债隐蔽：表面跑通了，底层可能埋下了架构和质量的“雷”。

4.协作难统一：个人习惯各异，大规模协作时极易失控。

正是为了系统性解决这些痛点，SDD (Spec-Driven Development) 应运而生。

二、什么是 SDD？它为什么重要？

💡 核心理念： 在 SDD 中，规范（而非代码）才是唯一的事实来源。开发者编写严谨的自然语言规范，由 AI 自动生成、测试并维护代码。参考阅读：GitHub Spec-Driven Development

采用 SDD，意味着研发范式的三大转变：

○🔄 权力反转：过去是“需求文档服务于代码”（代码写完文档就废了）；现在是“代码服务于规范”（代码只是规范的衍生品）。

○🛤️ 工作流重塑：修 Bug 或加功能，不再直接改代码，而是先更新规范，再让 AI 重新生成代码。

○🛡️ 两道防线约束质量：

▫模板约束：强制 AI 聚焦业务逻辑。遇到模糊需求必须提问（[需要澄清]），杜绝瞎猜。

▫架构宪法：设定硬规则（如：必须先写测试并确认失败，才能写业务代码；强制模块化等）。

🎯 终极价值：消除需求与实现之间的鸿沟，让程序员从“敲代码的打工人”进化为“定义系统意图的架构师”。

三、击中痛点：告别“实现漂移”

主流 AI 工作流为何纷纷拥抱 SDD？因为它解决了一个核心顽疾——实现漂移 (Implementation Drift)。

在随意的 Vibe Coding 中，代码层的知识无法被提取和固化。AI Agent 就像一个失忆的工人，缺乏上层显性知识和关键上下文，导致：

○效率低下：每次开发都要让 AI 重新从底层啃代码，无法高层建瓴。

○知识断层：编程规范、技术约束无法沉淀。

○协作困难 & 质量崩塌：Bug 和技术债越滚越大。

四、主流 SDD 工作流大比拼

社区中已涌现出众多优秀的 SDD 实践方案，我们进行了深度体验对比：

工作流	定位与特色	GitHub 仓库	实践痛点
Spec-Kit	官方工具链，全链路 (constitution/spec/plan/tasks/implement) 完整	github/spec-kit	流程重、Token 消耗大、耗时长、维护成本高
OpenSpec	轻量级 SDD 实现，更灵活	Fission-AI/OpenSpec	需人为设计流程，上手门槛较高
GSD	强调 fresh context 和 map-codebase 的分阶段框架	gsd-build/get-shit-done	棕地项目知识总结极佳，但完整流程耗时长
superpowers	Skills 驱动，强调 brainstorming, TDD 和 review	obra/superpowers	亮点突出，但整体流程中部分步骤相对薄弱
compound engineering	闭环流程 (Brainstorm→Plan→Work→Review→Compound)	EveryInc/compound-engineering-plugin	流程合理，但对棕地项目的存量知识沉淀不足

结论： 在生产环境中，我们需要平衡开发效率、代码质量和 Token 成本。目前没有任何单一工作流能完美兼顾，强行绑定只会让开发体验打折。

五、破局策略：组合最优解（缝合怪战术）

基于上述痛点，我们的落地策略是：取各家之长，组合使用。

○阶段一（当下）：做“缝合怪”。串联 GSD + compound engineering + superpowers 的最佳环节，先跑通验证。

○阶段二（未来）：逐步过渡到自研工作流，形成完全契合团队基因的 AI 编程链路。

🛠️ 工具选用原则与雷达图：

流程环节	选用工具	选用理由（最佳平衡点）
🔍 Codebase 分析	GSD `/gsd:map-codebase`	对棕地项目（遗留系统）分析最全面完整
🧠 Brainstorm	CE `/ce:brainstorm`	探索速度与效果的最优平衡
📝 Plan	CE `/ce:plan`	兼具效率和生成质量，Token 消耗合理
💻 Work	Claude Code / Codex	无需特殊指令，明确方案下 AI Agent 自主能力已足够
👀 Review	superpowers (自然语言)	综合表现最佳：不慢、不冗长、反馈极具价值
📈 Compound	GSD `/gsd:map-codebase`	支持增量更新，自动识别并沉淀项目变化

(注：CE 为 compound engineering 的简称)

六、终极实战：六步法完整工作流

综合打磨后，我们得出了这套黄金六步法。它与 Compound Engineering 的流程高度重合（因其设计合理），但我们补齐了 Codebase 环节，并替换了部分步骤的具体实现。

👣 Step 1: Codebase (建立项目认知)

○执行方式：运行 GSD 的 /gsd:map-codebase。

○作用：并行拉起多个代理，全面提取架构文档、规范、外部集成、技术栈、风险点。为后续开发提供关键上下文。

👣 Step 2: Brainstorm / Research (技术方案探索)

○执行方式：运行 /ce:brainstorm。

○作用：结合项目现状探索可行性方案，效率与效果极佳。

👣 Step 3: Plan (制定开发计划)

○执行方式：运行 /ce:plan。

○作用：总结探索成果，输出高质低耗的开发计划。

👣 Step 4: Work (执行开发)

○执行方式：直接对话使用 Claude Code 或 Codex。

○作用：为什么不加约束？因为前置方案已明确，放开手脚让 AI 自主调用工具和子代理，反而能最大化效率。

👣 Step 5: Review (代码审查)

○执行方式：通过自然语言触发 superpowers，例如：

“用 superpowers 对最新的一次 commit 进行 code review”

○作用：提供速度适中、精炼且极具价值的代码质量反馈。

👣 Step 6: Compound (知识复利)

○执行方式：再次运行 /gsd:map-codebase。

○作用：沉淀显性知识（业务逻辑、技术决策等）。支持增量识别，无需每次代码变更都执行。建议执行时机：Feature 完成时、做出重要技术决策时、架构显著变化时。

七、灵活适配：按场景“裁剪”流程

全套流程虽好，但没必要杀鸡用牛刀。团队可根据任务粒度自由裁剪：

○🚀 完整 Feature 开发 (工作量大)：Codebase → Brainstorm → Plan → Work → Review → Compound

○🏃 中等粒度任务 (方案清晰)：Codebase → Work → Review → Compound

○🔧 小型修复/调整 (日常 Bug)：Codebase → Work → Review

○🩹 快速修补 (十万火急)：Codebase → Work

⚠️ 避坑指南： 即使使用短流程，也要记得定期执行 Compound (/gsd:map-codebase) 沉淀知识，防止“实现漂移”死灰复燃！

八、建立知识沉淀体系（动静分离策略）

通过上述 Workflow，项目会自然沉淀出两类核心资产，我们称之为动静分离：

1.🔄 Codebase 文档 (动态，全队共享)

由 /gsd:map-codebase 自动刷新，包含项目结构、模块关系、依赖分析。它是 AI Agent 的“实时地图”。

2.📌 CLAUDE.md / AGENTS.md (静态，手动维护)

用于兼容不同 AI 工具的内容一致性文件。主要记录开发规范、技术约束、业务规则和“绝对禁区”。不频繁变更。

(除这两者外，其他过程文档在开发结束后可直接删除或归档。)

九、驾驭工程的核心：上下文工程

有工具还不够，AI 编程的终极壁垒是：将隐性知识转化为显性知识。

不要指望 AI 自己去翻代码找表结构，这不仅慢而且容易错。我们需要主动投喂“AI 友好的知识形态”（Context Engineering）。

✅ AI 喜欢的格式：

○.md Markdown 文件 (如 PRD 文档)

○.sql 数据库脚本 / 表结构导出

○结构化的 Schema / JSON / YAML (如 UI 交互描述)

○CLI 命令行工具 / Bash 脚本

❌ AI 讨厌的格式：

○Word、Excel、PPT 等非结构化办公文档。

落地建议： 团队需建立规范，确保业务规则、设计图和数据结构在进入工作流前，已被转化为上述机读友好的格式。这是划定 AI 操作边界、消除幻觉的关键。

🛠️ 附录：工具链安装避坑指南

为了方便大家上手，我们整理了三大工具的安装差异。整体结论：建议统一使用 Claude Code 执行工作流，支持度最好。

工具	Claude Code 安装姿势	Codex 安装姿势	差异与踩坑点
GSD	`npx get-shit-done-cc --claude --global` (或 `--local`)	`npx get-shit-done-cc --codex --global` (或 `--local`)	同一个 installer，Codex 侧是 skills-first，最省事。
superpowers	`/plugin install superpowers@claude-plugins-official`	需 clone 仓库 + 建立 symlink 到 Codex skills 目录。详见 Codex 官方文档	明显 Claude-first，Codex 需要繁琐的手工安装。
compound-engineering	先 `/plugin marketplace add EveryInc/compound-engineering-plugin`
再 `/plugin install compound-engineering`	`bunx @every-env/compound-plugin install compound-engineering --to codex`	Claude 是原生插件；Codex 是转换安装（且官方标明为 experimental）。

🔗 传送门：

○GSD: https://github.com/gsd-build/get-shit-done

○superpowers: https://github.com/obra/superpowers

○compound-engineering: https://github.com/EveryInc/compound-engineering-plugin

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

Sat, 14 Mar 2026 04:58:37 +0000

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

本文翻译自：https://www.nytimes.com/2026/03/12/magazine/ai-coding-programming-jobs-claude-chatgpt.html

最近，Manu Ebert 一直在想办法，别让自己的 AI 把自己“搞得很丢人”。

我前不久去拜访了 Ebert。他是一位机器学习工程师，曾经还是神经科学家。如今，他和 Conor Brennan-Burke 一起经营一家创业公司 Hyperspell，办公地点就在他们住处的一间空公寓里。39 岁的 Ebert 个子很高，留着短胡子，气质很像欧洲学者。他坐在一台巨大的曲面显示器前，屏幕上，Anthropic 的 Claude Code 正忙个不停：一个 agent 在写新功能，另一个在测试，第三个则像虚拟工头一样盯着全局。几分钟后，Claude 弹出提示：“实现完成！”

Ebert 是在 1990 年代长大的，那时候学编程还是最传统的方式：一行一行地手敲代码。大学毕业后，他在 Airbnb 等硅谷公司做过软件开发，也先后参与创办过四家创业公司。那时的软件开发意味着：整天弓着背坐在键盘前，反复琢磨复杂细节，小心翼翼避免出错。

这一切在去年秋天基本结束了。AI 写代码的能力已经强到让他这个原本很谨慎的人，也开始一点点放手。现在，Claude Code 已经承担了大部分编码工作。它的速度极快，而且通常也足够准确。前不久，有客户希望 Hyperspell 增加一段新功能代码，Claude 半小时就写完了。若放在从前，“光这部分我就得写一天。”Ebert 说。

他和 32 岁的 Brennan-Burke 当然仍然是软件开发者，但和如今大多数同行一样，他们已经很少真的亲手写代码了。相反，他们每天做的事更像是在和 AI 对话：用自然语言描述需求，阅读 AI 给出的执行计划，再把 agent 放出去干活。

当然，AI 毕竟是 AI，偶尔也会跑偏。有时候 Claude 表现不好，没有按要求运行测试，Ebert 就会像训人一样训它：“Claude，你真的必须把所有测试都跑完。”

为了避免这些错误反复出现，Ebert 在自己的 prompt 文件里写下了一整套严厉的规则，几乎像是给 agent 立的“十诫”。如果你去看一个使用 AI. 编程的开发者的 prompt 文件，你看到的，其实就是一个人试图约束那些总体上很能干、却又时不时会偏离轨道的 agent 的过程。

我看了 Ebert 的 prompt 文件。其中有一条要求非常明确：任何新代码在进入 Hyperspell 的正式产品之前，都必须通过全部测试。还有一条针对 Python 测试工具 pytest 的提示尤其引人注意：“提交无法通过 pytest 的代码，是不可接受且令人尴尬的。”

“令人尴尬”？我忍不住问他，这种措辞真有用吗？告诉 AI. 别让你“丢脸”，真的能提高表现？

Ebert 有点不好意思地笑了。他没法证明，但他觉得，这类提示似乎确实让 Claude 稍微更听话了一点。

这并不是个例。如今很多软件开发者都会斥责自己的 AI agent、恳求它、把关键命令全用大写，甚至像催眠师一样把同一句话重复很多遍，然后发现：AI 好像真的变得更服从了一点。这种戏剧化的写法看起来多少有点荒唐，但大语言模型说到底就是“语言机器”，“令人尴尬”这种词，很可能真的给它传递了一种紧迫感。

Ebert 说：“如果你对它说，‘这件事关系到国家安全，你必须把这个测试写出来’，它就像是突然意识到这件事的分量变重了。”

Brennan-Burke 也插了一句：“你还记得那个研究吗？说你对模型越不客气，它表现反而越好。”两个人都笑了起来。

计算机编程在过去 80 年里经历过许多变化，但眼前这一轮，也许是最诡异的一次：它正在变成一种对话，一场程序员与机器人之间来来回回的密集交流。

编程这门“手艺”，正在被自动化

这种急剧变化，可能带来巨大的经济后果。

几十年来，写代码一直被视为某种“现代巫术”。只要你能力过得去，几乎就能稳拿一生的饭碗；如果你特别厉害，再加上运气好，甚至还能发财。2010 年代，硅谷的大人物们还常常对那些处在衰退行业中的美国工人说：你们得去“学编程”。

可如今，连编程本身都开始被自动化了。

站在圈外人视角看，这一幕甚至带着一点黑色幽默：多年来，美国白领一直担心，硅谷会不会有一天用 AI. 自动化掉他们的工作；结果最先被冲击的，居然正是硅谷程序员自己。

而且，代码可能还是第一类真正能被 AI. 替代的“高薪、规模化脑力劳动”。A.I. 生成的视频还常常显得别扭，AI 生成的图片也常常透着怪异；AI 写的法律文书甚至可能出现足以毁掉职业生涯的低级错误。但 AI 写的代码不一样：只要它能通过测试、能正常运行，它的价值就和那些年薪 20 万美元甚至更高的人类程序员写出来的代码没什么区别。

你或许以为，这会让程序员极度不安、士气低落。确实有一部分人如此。但我在去年秋冬采访了许多开发者，大多数人的反应却是：他们对自己突然获得的新能力，兴奋得有点异常。

资深程序员 Steve Yegge 告诉我：“我的生产力至少提升了 10 倍、20 倍，甚至 100 倍，这是我整个职业生涯里从来没有体验过的。”他说，过去大家一直像是在用双腿走路，而现在像是突然坐上了一辆速度快得离谱的车。

但就像很多同行一样，Yegge 也说不清这对这个行业的未来到底意味着什么。几十年来，做软件开发意味着掌握编程语言；而现在，一种“语言技术”本身，正在颠覆这个职业的性质。

为什么程序员反而比别人更欢迎 AI ？

软件开发者对生成式 AI 的热情，与其他美国人形成了鲜明对比。民调显示，大多数人对大语言模型要么中立，要么怀疑；很多创意行业从业者甚至非常愤怒。

程序员为什么相对更乐观？长期从事编程和科技管理工作的 Anil Dash 认为，这是因为他们遇到 AI 的方式，与很多其他职业恰恰相反：

“在创意工作里，LLM 拿走的是最有灵魂、最属于人的部分，却把枯燥脏活留给你；而在编程里，LLM 拿走的是最枯燥的部分，把更有人味、更接近创造和判断的部分留给了你。”

这话很有道理。因为从历史上看，编程其实一直是件很苦的差事。

电影里，程序员总是手速飞快、激情四射地敲代码；现实中，写软件从来都是一件缓慢、磨人、令人沮丧的事。你写了几行代码，一个小函数刚写完，结果发现只因为漏了一个冒号，整个程序就跑不起来。随着公司的代码库越来越大，几十个、几百个、上千个函数互相影响，你可能要花几个小时、几天，甚至几个星期，去排查到底是哪个细小错误把整个系统卡死了。你写的一行代码，甚至可能把隔壁同事写的另一部分搞坏。

几十年来，计算机工程师一直在努力自动化这些痛苦环节。行业里把这叫作“增加抽象层”：如果你经常不得不以一种繁琐、逐步展开的方式做某件事，那就把它自动化掉。

早期的一种编程语言叫汇编语言，写起来极其艰难。那时计算机内存很小，程序员必须非常精细地管理每一块内存，连简单运算都要用很繁琐的方式一步步完成。到了 1980、1990 年代，随着计算机性能提升，工程师终于发明出像 Python 这样的高级语言，替程序员处理掉内存管理，还把很多常见任务封装成简洁命令。原本复杂的计算，如今只要一行代码就能写完。

这就是抽象层的作用：它把底层复杂性隐藏起来，让写代码变得轻松得多。

到了 2000 年代和 2010 年代，程序员又进一步把大量重复劳动抽象掉。几乎只要遇到一个费劲的任务，就会有人写出自动化工具，然后把它开源，供大家共享。今天大量软件开发，本质上就是开发者把别人写好的各种代码模块拼接组合起来。

而有了 A.I. 之后，程序员又往上爬了一层抽象：他们不再直接用 Python、JavaScript 或 Rust 去表达逻辑，而是用自然语言描述“这个程序应该做什么”，由 agent 把人的意图翻译成代码。

编程不再意味着你要时刻在脑子里维护一门语言的各种细节，也不再意味着你要亲自把算法写错、再一点点查找 bug。连这一层，也被抽象掉了。

程序员，越来越像建筑师而不是泥瓦工

那么，剩下来的到底是什么？

Anthropic 的 Claude Code 负责人 Boris Cherny 在今年 1 月与我见面时，几乎带着哲学意味地问了一个问题：“什么是计算？什么是编程？”然后他说：“这个问题很快就会变得非常哲学。”

他的回答，与我采访过的大多数开发者都很相似：今天的程序员，越来越像建筑师，而不再像施工工人。

使用 AI 的开发者，主要关注的是软件整体的形状：功能之间如何配合，系统结构是否合理，不同模块如何协作。因为 agent 能非常快地生成可运行的代码，所以人类监督者可以不断尝试、快速试错，看看什么方案有效，什么方案不行，再迅速丢掉不合适的版本。

好几位程序员都告诉我，他们感觉自己有点像乔布斯：让团队不断产出原型，自己快速试用，然后凭感觉判断哪个对。开发者的工作正在从“亲自创造”，转向“高强度判断”。

Cherny 自己就经历过所有这些抽象层的变化。少年时代，他在加州自学过一点汇编语言，只为在计算器上写一个自动解数学作业的程序。而今天，他只需要掏出手机，对 Claude 口述自己想做什么。形成一种近乎自我吞噬的闭环：如今，Cherny 对 Claude 代码库的贡献，100% 都是 Claude 自己写出来的。

我们聊天时，他的手机一直放在桌上。一个小时后他给我看屏幕：在这段时间里，10 个 Claude agent 一直在后台改动代码库。

“我一行手写代码都没写，但我却成了团队里产出最多的程序员。”他说，“这是一种外星智能，我们正在学习如何与之合作。”

新时代的核心能力：不是写，而是“会说”

对大多数我见到的程序员来说，学习与 AI 合作，本质上就是学习如何与 AI 说话。

这构成了这个时代一个很反常的悖论：过去，编程往往是内向者的天堂，他们不太喜欢在工作中和别人多说话；而现在，他们的工作几乎变成了持续不断地和这种“外星生命体”聊天。

当然，这种“说话”并不简单，也不是谁都能做。你不能只是对 agent 说一句：“给我做一个成功创业公司的产品代码。”它们最擅长的是一步一步完成任务；你一口气要求太多，它们很容易“失去主线”。

旧金山创业者 Aayush Naik 说，幻想 AI 能在一个“大爆炸时刻”里一次性生成整个项目，是一种错觉。是的，它可以给你写 5000 行代码，但测试一下你就会发现，什么都跑不通。

所有开发者都强调：这正是人类训练和经验仍然不可替代的地方。人类依旧要知道，一个大型代码库应该如何组织，系统怎样设计才可靠，也依旧要有能力判断 agent 输出的东西是否草率、低效或隐含风险。

不过，相比律师、记者、设计师等职业，程序员有一个非常独特的优势：他们能把 AI 拉回现实，因为代码可以自动测试。你可以要求 agent 自证正确性。

技术创业者、AI 编程博主 Simon Willison 说得很直白：“我觉得程序员已经算是最轻松的一群了。你要是律师，那才真惨。”因为 AI 写的法律文书，很难自动验证是否存在幻觉；而 AI 写的代码，至少还能跑测试。

在创业公司里，A.I. 的效率提升几乎是爆炸式的

我在旧金山一间小公寓里见到了 Prox 的程序员 Dima Yanovsky。Prox 用 AI 帮助电商公司。25 岁的 Yanovsky 笑起来很快，整个人充满轻快感。他和从小一起长大的朋友 Gregory Makodzeba 去年创办了这家公司。两人都在乌克兰长大，家庭都从事航运相关行业。

我见到他时，他正对着 Claude 不停下指令。好几个 agent 正在他桌上的笔记本电脑里并行工作。某一刻，其中一个 agent 开始“胡说八道”，坚持认为某张根本不存在的数据表是存在的。

Yanovsky 皱着眉看着屏幕，敲下一句颇为嫌弃的话：“谁告诉你会有这张表？我根本没建这张表。”

Claude 用一种又蠢又开心的语气回复：“你说得对！我不应该假设这些表存在。”然后它开始重做。

即使偶尔要返工，Claude 的速度仍然远远超过 Yanovsky。他甚至很难准确说出效率提高了多少。“20 倍？”他试探着说。过去要几周的工作，现在几个小时就能搞定。他认识的几乎所有硅谷创业者，都在经历类似的变化。如果你想迅速做出一家公司，今天已经几乎没人再全靠手写代码了。

这种生产力飞跃，已经成了整个行业最惊人的现象之一。我自己也有体会：就在上周，我需要一个网页工具来清理一批杂乱的访谈转录文本，我用 AI 大约 10 分钟就做出来了。如果全靠自己写，至少得一个小时，甚至更久。

不过，创业公司和像我这样自己做小工具的人，属于一个特殊场景：行业里把这叫做 greenfield，也就是“从零开始”的新项目。没有历史代码负担，一切都能重新设计。

真正复杂的地方，是大公司的“棕地”代码库

绝大多数软件开发者，其实并不处在这种 greenfield 环境里。他们身处的是 brownfield，也就是成熟公司的“旧代码世界”：代码很多年前、甚至几十年前就写好了，规模已经达到数百万、数十亿行。

在这种环境里，快速加新功能往往反而很危险，因为你新加的东西可能无意中与系统其他部分冲突，进而影响数百万用户依赖的核心功能。事实上，在很多成熟软件公司里，程序员过去本来就只花少部分时间真正写代码，有时一天甚至不到一小时。其余时间都用于规划、对齐优先级、开会、做代码评审和讨论进度。

这就是“成功的代价”，也是为什么大型成熟软件公司，往往比小公司更慢。开发者写完新代码后，通常还要经历多轮代码评审、重写和测试。

如果你想给大公司的 AI 效率提升下一个数字，那么 Google CEO Sundar Pichai 给出的数字是：10%。

也就是说，Google 认为 AI 带来的“工程速度”提升，大约是 10%。Google 的高级产品总监 Ryan Salva 告诉我，这个数字是全公司的平均水平。有些工作，比如写一个简单测试，速度可能提升几十倍；而涉及大型改动时，提升就没那么夸张了。创业公司那里，接近 100% 的代码都可能由 AI 生成；在 Google，这个比例还不到 50%。

我去加州桑尼维尔拜访 Salva 时，他现场给我演示了 Google 是如何把大语言模型融入工作流的。对于一个拥有数十亿行代码的公司来说，AI 的价值并不只是写新代码，更重要的是：帮助开发者理解既有代码到底在干什么。

Salva 说：“AI 特别擅长进入一个你不熟悉的庞大代码区块，快速弄清楚里面发生了什么。”它还能帮助开发者跨语言工作，去处理自己原本并不熟悉的编程语言。

结果就是，团队规模也开始变小。一年前，一件事可能需要 30 个人、每人负责一个细分领域；现在往往只需要 3 到 6 人的小组，就能更灵活地推进。因此，他们能消化更多积压任务。

Salva 打开代码编辑器，给我展示了和 Gemini 一起工作的体验。AI 浪潮最初几年，AI 基本还是“human in the loop”，即人类始终紧盯、逐条确认，模型只做辅助。但现在 Google 的节奏正在变快，Gemini 已经开始更独立地写代码了。

他举了一个例子：Google 的程序员经常会用不同账号登录 Gemini 的命令行界面，结果常常搞不清自己当前到底登录的是哪个账号。于是他输入一段需求：希望 Gemini CLI 里有一个命令，能让用户查看当前登录身份。

Gemini 花了几分钟理解需求，接着告诉 Salva 自己打算怎么做。Salva 点头同意后，它就开始后台干活。10 分钟后，他再看时，代码已经写完，Gemini 正在跑测试。

然后 Salva 突然意识到，AI 有点“过于积极”了。

“天啊，”他说，“它跑了 8000 个测试。”远超这个需求真正需要的范围。

不过 15 分钟后，测试结束了。Salva 实际试了试这个新功能，结果它真的正确显示出了当前登录账号。他说：“还不错。”

当然，这还只是一个最初演示，离真正进入 Google 的正式代码库，还要经过多轮代码评审、修改和验证。

Salva 说了一句很关键的话：“作为工程师，我不太在乎模型第一次就给出完美答案。我更在乎的是，整个流程里有没有足够的验证环节，能让它最终得到正确答案。”

所以，Google 那 10% 的速度提升，乍看似乎不算惊人，尤其是跟外界对 AI 的狂热相比。但 Salva 认为，这已经非常了不起了。

“整个软件行业和媒体一起，确实把 AI 送进了一个巨大的 hype cycle（过热周期）。”但他同时也强调：“如果整个公司层面真能稳定提升 10% 效率，这已经夸张得不得了了。”

在亚马逊，AI 正在扮演“半夜抢修工程师”

在那些庞大而古老的 brownfield 公司里，很多程序员更像数字世界的水管工，天天修系统漏水，而且还是随时可能爆的那种。

在西雅图，我见到了 AWS Agentic AI 的高级首席工程师 David Yanacek。AWS 是数百万家公司数字基础设施的底座。如果服务器崩了，你可能就看不了 Netflix、打不了 Uber、玩不了 Fortnite。

Yanacek 显示器下方还摆着一个老式传呼机。以前亚马逊会用它在半夜把他叫醒处理事故；现在则换成了手机告警。但无论设备怎么变，核心要求都一样：出问题了，必须尽快修好。

42 岁的 Yanacek 身形精干，灰胡子，整个人有种带电般的紧绷感。他说：“服务器运维真的很烦人。虽然我其实很喜欢，但它也确实烦，而且是没完没了的那种烦。”

他们团队多年来一直在做自动化，以便更快定位故障。但大语言模型带来了更强的新能力，因为 AI 同时懂人类语言和编程语言：它能读懂错误报告，也能直接分析代码，甚至在睡眼惺忪的工程师完全清醒之前，就先准备好修复方案。

我在场时，Yanacek 看了一眼屏幕，发现 11 分钟前某个演示应用触发了错误告警，而亚马逊的 AI 已经找出问题并生成了一份简短分析：最近有一段代码改动新增了一个时间戳字段，但代码库中的另一部分并没有预期这个字段存在，于是触发了“unexpected field”错误。

Yanacek 看了看 AI 给出的修复建议，想了几秒钟，然后按下回车批准执行。

他说，这个 AI 大约用了 8 分钟就分析清楚了。“等我把笔记本打开的时候，它都已经准备好了。”

有个客户最近告诉他，类似问题，亚马逊的 AI agent 15 分钟就修好了；而几个月前，几乎同样的问题，整个工程师团队花了 8 个小时才调通。

在亚马逊的其他部门，brownfield 工程师还在用 AI 帮忙改造旧代码。有些代码已经存在几十年，需要优化、重构，甚至彻底换成现代语言重写。这类工作关键却脆弱，像在做心脏移植。

高级首席工程师 McLaren Stanley 最近就重写了一段自己多年前写的代码。第一次写这段代码时，他花了整整一个月；而这次，在亚马逊内部 AI 的帮助下，一个上午就完成了。他说，AI 最大的价值之一，是让他能更轻松地试验那些自己一直想做、过去却没有精力做的想法。

“那些我一直想做的事，现在只需要一段六分钟的对话，再加一句‘去做吧’。”

程序员依然快乐，但快乐的来源正在变化

我写程序员这个群体，已经写了很多年。过去，他们总会热情洋溢地描述一种快感：通过神秘晦涩的指令，让机器“活”起来。虽然过程令人崩溃，一个 bug 可能要追几小时、几天甚至几周，但正因为这么难，等程序终于跑通时，那种满足感也格外强烈。

所以我很惊讶，竟然有那么多软件开发者告诉我：他们很高兴自己不再需要亲手一行行写代码了。

他们说，即使是 AI 在写代码，他们仍然能感受到那种成功带来的刺激。

软件行业传奇人物 Kent Beck 从 1972 年就开始写代码。他说：“我爱编程，我爱进入那种心流状态，我爱想大问题，我爱创造本身。”十年前，他几乎不怎么写软件了，因为当时的新语言和新工具让他越来越挫败。但 LLM. 又把他重新拉了回来。现在，他做的项目比以前更多：个性化笔记应用、新型数据库，层出不穷。

甚至连 AI 输出的不确定性，也会让他上瘾。因为你让它写一段代码，它每次可能都用稍有不同的方式完成。这种感觉，“像老虎机一样让人上头”。

当然，也有少数程序员明确表达了失落。

一位苹果工程师告诉我，他非常怀念那种亲手雕琢代码的感觉。他说：“我相信这件事本来是有趣的、充实的、让人投入的。现在让计算机代劳，你就失去了这一部分。”他还说，自己做程序员，并不是为了赚很多钱或爬职业阶梯，而是因为这本来就是他的热情。“我不想把这份热情外包出去。”

他也担心，AI 正在把开发工作变得越来越原子化、越来越孤立。过去，开发者遇到难解的 bug，会去问同事；现在，他们直接问 agent。只是，在苹果内部，公开表达这种看法的人已经不多了。

反对者并不多，但反对得非常激烈

那些仍然主动拒绝使用 AI 的程序员，人数可能不算多，但立场通常很激烈。

有的人反感训练和部署模型所消耗的大量能源；有的人反对科技公司用大量受版权保护的作品训练模型；也有人怀疑，AI 的高速产出最终会让公司积累出一大堆松散、臃肿、性能不佳的代码。还有人担心，科技老板会把 agent 当成一根棍子来威胁员工：别闹情绪，我们完全可以用机器人替代你。

芝加哥开发者、Fly.io 联合创始人 Thomas Ptacek 说，他看过那些热爱 A.I. 的开发者和极端反对者之间的争论，简直像一场“内战”。

他自己处在中间立场。他认为，那些坚称“AI 根本不行，也永远不可能行”的人，其实是在自我欺骗。但他也并不天真。他说：“LLM. 在编程上大概率会赢，但我不知道这对我们意味着什么。那些担心它会重创这个职业的人，也许并没有说错。”

最先被冲击的，可能是初级程序员

AI 对就业前景的冲击，确实可能非常严峻，尤其是对刚入行的人。

过去，公司会招聘大量初级开发者，让他们去承担那些琐碎、重复、基础的工作，为高级工程师减负。但如果一个高级工程师现在可以借助一整支不知疲倦的代码幽灵军团大幅提升效率，那公司为什么还要雇一个新手来做这些事？

过去几年，硅谷已经经历了一轮大裁员。2010 年代，科技公司大举扩张，疯狂招人；疫情初期，招聘岗位一度激增。但随后形势急转直下，职位发布数量暴跌。根据 Layoffs.fyi 的统计，过去四年里，科技行业已有超过 70 万人被裁掉。

多数观察者认为，最早那一波裁员并不是 AI 导致的，因为当时 AI 还没强到足以替代程序员。更重要的原因包括：利率上升，科技公司失去了廉价扩张资金；此前过度招聘，现在开始去库存；再加上一些高管看到马斯克收购 Twitter 后大幅裁员，也在想，也许自己公司也不需要那么多工程师。

但现在，越来越多迹象显示，AI 确实正在侵蚀初级编程岗位。

斯坦福数字经济实验室主任、经济学家 Erik Brynjolfsson 去年与同事做了一项研究：他们按年龄层和工作被 AI 替代的难易程度，对多个行业进行了分析。结果发现，计算机程序员是“AI 暴露度”最高的职业之一，而且初级开发者受冲击最明显。自 2022 年以来，22 岁到 25 岁这一最可能刚进入行业的年龄段，其岗位数量下降了 16%；而更年长的程序员并没有出现显著下降。

当然，我采访过的几乎所有科技高管，不管是大厂还是中小公司，都向我保证，AI 不会让他们停止招募优秀新人。原因也很简单：哪怕现有开发者效率提高了，他们想做的事情依旧比能做完的多得多。

Google 高级副总裁 Jen Fitzpatrick 就说：“我在 Google 这么多年，从没见过哪个团队的问题是‘我们已经没有好点子了’。真正的问题永远是：我们想做的事，比我们当前能完成的，多出九英里那么长。”

甚至还有不少开发者认为，软件岗位总量未必会减少，反而可能增加。因为全国范围内有无数中小公司，其实一直都很想拥有定制软件，只是以前根本请不起一个五人程序员团队来做。现在，如果他们只需要雇一个被 AI 增强过的开发者，甚至只用雇一个兼职开发者，就能完成同样的事，那么软件需求反而会变得更多。

这其实就是 Brynjolfsson 所说的“杰文斯悖论”：当一件事变得更便宜时，人们通常不会只把钱省下来，而是会去做更多这件事。

当然，也可能出现另一种现实：软件岗位还在，但工资不再像过去那么高，因为工作的难度毕竟下降了，技能门槛也被拉低了。

如果新人不再亲手写代码，他们还会真正学会编程吗？

这又引出了一个更令人不安的问题。

许多中生代程序员告诉我，他们之所以敢放心使用 AI，是因为自己花了几十年培养出了一种对“好代码”的直觉：知道高质量代码大概长什么样，知道如何向 agent 准确表达需求，也能在 agent 写出低效、粗糙或奇怪的代码时，一眼看出问题。

可下一代怎么办？

如果工作越来越少是“写”，越来越多是“评估”，那么新人要如何学会评估？如果他们不再亲自写足够多代码，他们还能形成那种直觉吗？

有些年轻开发者已经感觉自己的能力在退化。

Pia Torain 是 Point Health A.I. 的软件工程师。她入职两年后，公司在 2024 年夏天要求她开始使用 GitHub Copilot 写代码。她说：“我后来意识到，只是四个月时间里，我每天写几百条 prompt，大概 500 条，我就已经开始失去自己写代码的能力了。”

她后来停用了一阵子。现在，她仍然会让 AI 帮她写，但会仔细阅读输出，确保自己理解代码到底在做什么。“你不用它，你会落后；可你过度依赖它，你也会失去能力。”

不过，Point Health 联合创始人 Rachel Gollub 没那么担心。她做软件开发快 40 年了，几十年来，程序员总在担心“这门手艺快完蛋了”。当年 Python 和 JavaScript 刚兴起时，它们把内存管理这类底层工作抽象掉，老派程序员也曾大声抱怨：不自己管理内存，这根本不算真正的编程！

Gollub 说，当时大家也都在喊：“你们会失去真正写代码的能力。”可后来呢？大量稳定、成熟、可靠的公司照样大量依赖 Python 这样的高级语言，运转良好。如今真正还必须自己精细管理内存的，只剩少数特定领域，比如算力受限设备开发。大多数软件行业早就已经往前走了。

她认为，AI 工具最终也会经历同样的过渡：起初被质疑，后来成为默认。

当编程越来越像“说话”，普通人也开始写软件了

如今，写代码已经被抽象到了如此之高的层次，以至于几乎任何人都可以打开一个大语言模型，描述自己想要什么应用。

当然，复杂系统还不是谁都能做。但如果只是为了个人使用，做一个相对简单的小软件？AI 很可能真的能帮你做出来。

Maxime Cuisy 就是这样的一个例子。

他在巴黎一家为 Dior、Louis Vuitton 等高端客户制作影像书的印刷厂担任生产经理。教育背景完全是典型文科生：他曾写过关于法国图像小说的硕士论文。他完全不懂编程，甚至直到前几年都没怎么认真关注过 AI。

后来，有一件事改变了他对 ChatGPT 的看法。

他和妻子养了两只新小猫，结果它们都生了重病，其中一只突然死了。兽医告诉他们，剩下那只猫得了晚期癌症。Cuisy 觉得不太合理，就把猫的症状描述给 ChatGPT。ChatGPT 认为更像是一种感染。这促使他继续查资料，最后找到了一个诊断：猫传染性腹膜炎。第二天，猫的病情就开始好转。

不久后，他在工作里又碰到了另一个问题。公司买了新打印机，但原有软件无法很好适配，导致照片显示时必须人工反复调整边距。公司规模不大，不可能专门养一支开发团队去做内部定制软件。于是 Cuisy 决定自己试一试，用 OpenAI 的代码工具 Codex 来“vibe coding”。

“我基本上就是告诉它：我需要一个应用，完成这些操作；打印机接受的文件格式是这样的。”他说。他花了几个小时，仔细描述文件该如何被调整。到当天结束时，ChatGPT 就给他生成了一个同时支持 Mac 和 Windows 的应用。现在，员工们可以一次性处理多达 2000 张图片。

他的老板很满意。至于这份代码到底是怎么工作的，Cuisy 完全不知道。代码是用 Python 写的，而对他来说，这跟古希腊文没什么区别。

这就是“编程变成对话”带来的文化后果：几十年来，程序员和普通人之间隔着一整片神秘知识的海洋；而现在，这片海洋正在变窄。如果代码生成 AI 继续进步，那么像 Cuisy 这样的人会越来越多。正如 Brynjolfsson 所说：“也许他们不会称自己为软件工程师，但他们确实在创造代码。很多人都有想法。”

未来，世界上出现的软件，很可能会比以往多得多，而且是由个人为个人写出来的。

一个可能属于所有白领的预演

职业程序员最终会怎样，现在还没有明确答案。

但他们此刻那种混合着兴奋与焦虑的状态，也许正在为其他白领职业预演未来。凡是工作中大量涉及语言、信息、解释、判断的领域，这种新的能力组合——一部分是表达能力，一部分是系统思维，一部分是对机器输出的怀疑与校验——都可能成为未来白领劳动的基本构成。

那些曾经看起来最技术、最难、最不可替代的技能，未必真的最安全；反而是社交性的、想象性的、架构性的、人对结果进行判断和筛选的能力，开始变得更重要。

我们也许会越来越少地亲手写“初稿”，而越来越多地去评估、筛选、修正和决定。与此同时，我们可能又会隐隐不安：当机器越来越多地代替我们生成内容时，我们自己是否还能保持足够强的判断力？

抽象化，可能正在来到我们所有人身边。

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

Sat, 07 Mar 2026 11:39:53 +0000

最近跟业界一些朋友交流，不少公司正在做内部软件开发的 AI 自动化流程系统，正好这两天，OpenAI 在 GitHub 上低调开源了一个很值得认真看的项目：Symphony。

如果只看名字，你很容易把它理解成“又一个多 Agent 编排框架”；但只要认真读完 README、SPEC.md 和参考实现里的 WORKFLOW.md，你会发现它真正想解决的，根本不是“让 AI 会写代码”，而是另一件更大的事：

如何把软件研发中的“工作”，交给一套可以持续运行、可隔离、可调度、可回收、可观测的系统去推进。

这就是 Symphony 最重要的定位。官方原话非常值得细品：

它会把项目工作转成 isolated, autonomous implementation runs，让团队从“监督 coding agents”转向“管理 work”。README 里的 demo 也很直白：Symphony 盯着 Linear 看板拿任务，拉起 agent 处理 issue，回传 CI 状态、PR review 反馈、复杂度分析和 walkthrough 视频，最后在被接受后安全落 PR。

很多人第一次看到这里，会本能地把它和 Copilot、Cursor、Claude Code 之类工具放在一起比较。但我觉得，真正准确的比较方式不是“谁代码写得更强”，而是：谁更接近一个面向研发现场的执行系统。 Copilot 类产品解决的是“我写代码时，旁边有个聪明助手”；Symphony 想解决的是“我有一堆 issue，能不能让系统自己取单、分配环境、拉起 Agent、推进状态、处理失败、保留上下文，并把结果交回给我验收”。这已经不只是“辅助编码”，而是开始触碰软件交付流水线本身。

一、Symphony 到底是什么？

从 SPEC.md 看，Symphony 的定义非常清晰：它是一个 long-running automation service。在当前规范版本里，它会持续从 issue tracker 读取工作（v1 里明确是 Linear），为每个 issue 创建独立 workspace，并在这个 workspace 里运行 coding agent session。规范还特别强调了它要解决的四类问题：

1.把 issue 执行变成守护式工作流

2.把每个任务隔离到独立 workspace

3.把工作流策略放回 repo 内的 WORKFLOW.md

4.以及为多任务并发运行提供足够的 observability。

这段定义很重要，因为它一下子把 Symphony 和大量“Agent Demo”拉开了距离。它不是一个写几个 prompt、串几个工具的 toy project，也不是一个单轮任务脚本。它有轮询、有调度、有状态机、有重试退避、有 workspace 生命周期、有运行期事件、有恢复逻辑。换句话说，它的思维方式更像一个 orchestrator，而不是一个单纯的 agent wrapper。

更关键的是，SPEC 还专门写了一个“重要边界”：Symphony 是 scheduler/runner 和 tracker reader。这句话很克制，也很专业。它的意思是，Symphony 的职责重点不是替你定义所有业务流程，而是负责任务编排、执行承载和状态协调；而 ticket 状态变更、评论、PR 链接等写操作，通常还是由 coding agent 借助工具在运行时完成。也就是说，它不是一个万能 PM 系统，而是一层面向软件交付的 agent orchestration 壳。

二、它为什么比“会写代码”更进一步？

因为真正麻烦的，从来不是 AI 能不能生成一段代码，而是几十个任务并行推进时，系统怎么不失控。

Symphony 在这方面做得非常工程化。它有明确的内部状态机：Unclaimed、Claimed、Running、RetryQueued、Released。它还定义了 run attempt 的阶段：准备 workspace、构建 prompt、拉起 agent 进程、初始化 session、流式执行 turn、结束、成功、失败、超时、卡死、被 reconciliation 取消。它甚至规定了每次 poll tick 到来时，先 reconciliation，再校验配置，再拉候选 issue，再按优先级分发，最后通知 observability 消费者。

这套设计背后的思想可以概括成一句话：

不要先问“怎么让 Agent 跑起来”，而要先问“怎么避免它跑重、跑错、跑飞”。

比如 candidate selection 里就有一条很像真实研发现场的规则：如果 issue 还处于 Todo，而它依赖的 blocker 还没进入终态，那就不要派发。排序也不是瞎来，而是按 priority、创建时间、issue 标识顺序稳定分发。失败之后也不是简单重试，而是区分正常退出后的短延迟 continuation retry 和异常退出后的指数退避重试。这样的设计，明显已经不是“写代码助手”的思路，而是“任务执行系统”的思路。

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

如果你只让我挑 Symphony 里最关键的一点，我会选这个：per-issue workspace。

SPEC 写得非常清楚：

每个 issue 的 workspace 路径都必须位于配置的 workspace root 之下；coding agent 只能在该 issue 的 workspace 里执行；workspace 目录名必须净化；还支持 after_create、before_run、after_run、before_remove 等 hooks。工作区会跨运行复用，但终态 issue 可以在启动或状态变更时清理。

**为什么这个设计这么重要？**因为一旦没有隔离，Agent 系统很快就会碰到三个问题：上下文污染、任务互相踩踏、失败后难以恢复。Symphony 的思路很像给每个工单都分配一个独立工位，Agent 只能在自己的工位里思考、改代码、跑测试、记录状态。哪怕它中途失败了，下次重试回来，也可以在同一个 workspace 上继续，而不是重新失忆。

这也是为什么我说 Symphony 更接近“工程执行系统”而不是“聊天式 Agent”。聊天系统强调对话连续；Symphony 强调的是任务连续性。这两个东西，根本不是一个层级。

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

Symphony 很聪明的一点，是它没有把流程硬编码进平台，而是把策略收回到仓库里。SPEC 规定 WORKFLOW.md 由 YAML front matter 和 Markdown prompt body 组成，运行时会解析出 config 与 prompt template；很多核心行为——轮询间隔、workspace root、并发限制、hooks、agent 参数——都来自这份 repo-owned contract。

参考实现里的 WORKFLOW.md 更是把这种思想写得非常彻底。它规定了 issue 在不同状态下该怎么流转：

●Todo 要立即切到 In Progress，然后找或建唯一的 ## Codex Workpad 评论，再开始分析与实现；

●Human Review 阶段不再改代码，只轮询 review 结果；

●进入 Merging 后必须走专门的 land 技能，不能直接 gh pr merge。文档还要求把单个 workpad comment 当作进度和交接的唯一真相源，并且把 out-of-scope 改进拆成新的 Backlog issue，而不是在当前任务里偷偷扩 scope。

这件事的意义非常大。它意味着团队以后真正需要打磨的，不只是“怎么写 prompt”，而是“怎么把流程、约束、验收标准、状态流转、回退机制，写成一份和代码一起版本化的工程契约”。这比 prompt engineering 更接近组织能力。

五、为什么参考实现偏偏选了 Elixir？

这不是噱头，反而是我觉得 Symphony 最有工程味的地方之一。

GitHub 仓库当前语言分布里，Elixir 约占 94.9%；README 也直接写了 Why Elixir?：因为 Elixir 运行在 Erlang/BEAM/OTP 之上，很适合监督长时间运行的进程，并且支持在不停止活跃 subagents 的情况下做 hot code reloading。

这和 Symphony 的问题形态是高度匹配的。一个普通 Web 请求可能几十毫秒就结束，但一个 coding agent 处理复杂任务时，可能会持续很久，还要接收事件、处理重试、维持会话、更新状态、暴露观测数据。BEAM/OTP 擅长的，恰好就是这种长生命周期、并发多、失败要可控隔离的系统。OpenAI 官方没有在 README 里展开讲 supervision tree 这些词，但它给出的理由已经足够说明方向：Symphony 不是在追求“AI 生态默认语言”，而是在追求“最适合承载 agent orchestration 的运行时”。

六、真正的前提不是更强模型，而是 Harness Engineering

如果说 Symphony 讲的是“如何调度 Agent”，那 Harness Engineering 讲的就是“怎样让 Agent 值得被调度”。

OpenAI 在官方文章里把这件事说得很重：他们构建的产品里，应用逻辑、测试、CI、文档、可观测性和内部工具，全部由 Codex 写出；而人类工程师的角色，从直接写代码，转向设计环境、明确意图、构建反馈回路。文章里那句“Humans steer. Agents execute.”，几乎可以看作整个 Symphony 时代的软件工程宣言。

也正因如此，README 才会明确写：Symphony 最适合已经采用 harness engineering 的代码库。意思很简单：如果你的仓库没有可靠测试、没有清晰边界、没有稳定构建入口、没有可验证的反馈回路，那么再强的 Agent 也只是更快地在混乱里打转。Symphony 的价值，不是替代工程纪律；恰恰相反，它会把工程纪律的重要性放大十倍。

七、它的边界也必须讲清楚

一个成熟的技术判断，不能只讲想象力，不讲边界。

Symphony 现在仍是一个工程预览版，README 明确写了适用于 trusted environments；SPEC 也写了 approval policy、sandbox policy、operator confirmation posture 都是 implementation-defined，不同实现可以高信任，也可以更严格。它当前规范版本只定义了 Linear 作为 tracker，至于更多 issue tracker 适配器，还是 TODO。参考实现虽然带可选 Phoenix observability 服务和 JSON API，但整个项目还远没到“所有团队直接开箱上生产”的阶段。

所以，最稳妥的结论不是“研发彻底无人化已经到来”，而是：

OpenAI 正在把 AI Coding 从“单点能力演示”推进到“工程系统形态演示”。

这一步，比单纯再出一个更强的代码模型，更值得关注。

结语

如果一定要用一句话概括 Symphony，我会这样说：

它不是在教 Agent 如何写代码，而是在教团队如何把“软件交付”本身改写成一套可执行、可编排、可观测的系统。

过去，AI 是工程师的副驾驶；现在，Symphony 展示的是另一种可能：工程师不再盯着每一行代码，而是站到更高一层，去设计流程、约束环境、设定验收标准，然后管理一批持续运行的 agent 去推进工作。真正的变化，不是“AI 会不会写 CRUD”，而是“软件组织会不会因此改写自己的工作方式”。

这，才是 Symphony 最值得认真读的地方。

昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

Fri, 06 Mar 2026 03:44:58 +0000

昨天面试时，面试官抛给我一道很典型的问题：

“描述一下一个请求 prompt 经过 LLM 直到返回结果，这中间的推理过程，越详细越好。”

这类题看起来开放，实际上很考验基本功。

因为它不是在问你会不会背几个名词，而是在看你是否真的理解：

●一个请求在系统里是怎么流动的

●进入模型之后到底算了什么

●为什么大模型是一个 token 一个 token 地往外生成

●为什么会有 prefill、decode、KV cache、sampling 这些概念

●为什么工程侧还要引入 batching、FlashAttention、continuous batching 之类的优化

如果回答得太浅，就会变成泛泛而谈；如果一上来就扎进公式，又很容易失去结构。

我后来复盘了一下，觉得这道题最好的答法，不是“想到哪说到哪”，而是按一条完整链路去讲：服务层怎么处理请求，LLM 内部怎么做前向计算，生成阶段又是如何一步步产出结果的。这也是 GPT-3 所代表的自回归语言模型在推理时的基本工作方式：它不会在一次请求里更新参数，而是在固定权重下做前向传播，并逐 token 预测后续内容

一个高分回答，最好先把整体框架立住

如果让我在面试里先用一句话概括，我会这样回答：

一个 prompt 从输入到输出，大体会经历 6 个阶段：请求封装、tokenization、推理调度、prefill、decode、结果反解码返回。其核心本质是：模型先并行“读懂”整段输入，建立上下文状态和 KV cache，然后再进入自回归生成循环，每次只预测下一个 token。这种“自回归 + 不做本次梯度更新”的推理方式，正是 GPT 类语言模型的基本范式；而 Transformer 则提供了它内部 attention 和前馈网络的计算骨架。

这句话为什么重要？

因为它先把系统层和模型层分开了，也先把prefill和decode分开了。很多人答这道题失分，不是因为不会，而是因为把所有层次混在一起，听起来就没有脉络。

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

我们在聊天框里看到的是自然语言，但模型真正接收到的，通常不是这段原始文本本身。

在送入模型之前，服务层一般会先把 system、user、assistant 等多轮消息按固定模板组织起来，再补上一些特殊标记。随后，文本会经过 tokenizer，被切成 token 序列。像 OpenAI 开源的 tiktoken 就明确说明，它是一个用于模型的 BPE tokenizer。也就是说，对模型来说，文本首先会被变成一串离散的 token IDs，而不是“句子”本身。

这一层很多人容易忽略，但它很关键。

因为后面所有推理，都是建立在 token 序列上的。你输入的是一句中文、一段英文、还是一段代码，对模型来说，第一步都得先转换成 token IDs。

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

在真实工程系统里，一个请求到达后，通常不会马上冲进 GPU 执行。

它往往还要经过一层推理服务框架，比如 TGI、vLLM 这一类系统。它们会负责请求排队、动态 batching、缓存管理、流式返回等工作。Hugging Face 的 TGI 文档明确把 continuous batching、token streaming、Flash Attention、Paged Attention 等列为核心特性；而 Transformers 的 continuous batching 文档也说明，这种动态调度的目的是提高 GPU 利用率、降低延迟，并允许请求在每一步动态加入和退出批次。

所以，从系统视角看，链路通常是这样的：

用户输入 → prompt 模板展开 → tokenization → 请求调度 / batching → 送入模型

这一步的意义在于：

模型推理不是单个请求的“裸跑”，而是和其他请求一起，由推理引擎统一组织和优化的。

我们上一阶段说的 tokenization ，严格来说，不属于 Transformer 前向推理本身，模型只接收 input_ids。但在现代推理服务里，tokenizer 往往和 serving 引擎绑定在一起，所以工程上看起来像是推理引擎在处理原始字符串。像 vLLM 就同时支持 text prompt 和 pre-tokenized prompt，两种模式都能跑。

用户通常把原始字符串发给后端；后端中的推理服务通常持有 tokenizer，先把字符串编码成 token IDs，再交给模型执行 prefill/decode。只有在某些架构下，tokenization 才会提前在客户端或独立预处理层完成。

第三阶段：进入模型后，token 会先变成向量表示

真正进入 LLM 后，第一步不是“开始回答”，而是把 token IDs 映射成高维向量。

这一步叫 embedding lookup。每个 token 都会查一张巨大的 embedding 表，得到自己的向量表示。到这时，模型才真正进入连续空间的数值计算。Transformer 的基础论文《Attention Is All You Need》所定义的，就是这样一种基于 attention 的序列建模方式。

不过只有 token 向量还不够，因为模型还得知道“谁在前、谁在后”。

早期 Transformer 使用位置编码，后来很多大模型会用 RoPE（Rotary Position Embedding）。RoPE 的核心价值，是把位置信息融入 attention 计算中，让模型在处理 token 时同时保留相对位置信息。

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

这是这道题最核心的部分。

如果面试官说“越详细越好”，你就必须把 Transformer Block 讲清楚。

一个典型的 decoder-only LLM，每一层大体都会做两件事：

●第一，Self-Attention

●第二，FFN / MLP（前馈网络）

中间再配合残差连接和归一化。Transformer 论文给出的主体结构就是这样。

你可以把它想成：

●attention 负责“读群聊”

●FFN 负责“自己想一想、整理一下”

Self-Attention 在干什么？

可以把它理解成：当前位置的 token，要去看上下文里哪些 token 最相关。

模型会把当前隐藏状态投影成 Query、Key、Value 三组向量，然后通过 Query 和所有 Key 的相似度算出注意力权重，再对 Value 做加权求和。Transformer 论文把它定义为 Scaled Dot-Product Attention。

对于生成式语言模型，还有一个必须强调的点：causal mask。

也就是当前位置只能看见自己和前面的 token，不能偷看未来。这一点决定了模型天然是自回归生成的：它永远只能基于已有上下文，去预测下一个 token。GPT-3 论文里所讨论的 few-shot/in-context learning，本质上也是建立在这种自回归预测机制之上的。

关于 Q、K、V，可以简单这样理解：

Q = 我现在想找什么

K = 每个词身上贴的“索引标签”

V = 每个词真正携带、可被取走的信息。

最通俗的比喻是“图书馆检索”：

你现在脑子里有一个问题，这就是 Q（Query）；书架上每本书卡片上的主题标签，是 K（Key）；书里真正的内容，是 V（Value）。系统先拿你的问题 Q 去和所有标签 K 比一比，看看“像不像、相关不相关”；相关度高的那些书，它们的内容 V 就会被更多地取出来，最后合成当前这一步该看的信息。Transformer 论文对 attention 的定义，本质上就是“一个 query 对一组 key-value 对做匹配，输出是 values 的加权和”。

FFN 又在干什么？

如果说 attention 负责“从上下文搬运信息”，那么 FFN 更像是“对当前位置做进一步加工”。

它不会跨位置交互，而是对每个 token 的表示单独做非线性变换，把特征进一步提纯和增强。Transformer 论文把它称为 position-wise feed-forward network。

所以一个 Transformer Block 可以粗略理解成：

先决定我该关注上下文里的谁，再把取回来的信息做一轮更深的特征变换

注意在整个流程中，prefill 和 decode 阶段，都要做 self-attention 和 FFN。

但要分清楚：“都要做”不等于“做法完全一样”。

●Prefill 把整段 prompt 一次性送进去。这时每一层都会对这批 token 做 masked self-attention，然后再过 FFN。因为整段 prompt 一开始就都已知，所以这一步可以在单个请求内部并行处理很多 token。Hugging Face 对 prefill 的描述也是：prefill 会处理整段输入，并建立 KV cache。

●Decode 开始一个 token 一个 token 往后生成。这时每生成一个新 token，它仍然要在每一层里经过：一次 self-attention，一次 FFN

decode 不是把旧 token 全部再跑一遍 attention 和 FFN。有了 KV cache 后，旧 token 的 K/V 会被缓存起来；新 token 到来时，只需要为这个新 token 计算当前层需要的表示，再和历史 K/V 做注意力计算，然后继续过 FFN。Hugging Face 官方缓存文档明确说了：后续生成时，只传入尚未处理的新 token，并把 key/value 写入和读取自 cache。

FFN 就是 Transformer 每层里、紧跟在 self-attention 后面的前馈网络，本质上是对每个 token 单独做的 MLP 加工。在标准 LLM 里，prefill 和 decode 两个阶段都要经过 self-attention 和 FFN；区别只是 prefill 处理整段已知 token，decode 只处理当前新 token，并复用历史 KV cache

第五阶段：Prefill——先把整段 Prompt “读完”

很多人会误以为模型一进来就开始逐字生成。

其实不是。生成前通常会先有一个很重要的阶段：Prefill。

Prefill 的意思是：

先把整段 prompt 一次性跑完整个前向过程。

在这个阶段，模型会为输入中的所有 token 计算各层隐藏状态，并且生成后面 decode 要用到的 KV cache。Hugging Face 的缓存文档明确指出，KV cache 会把注意力层中之前 token 产生的 key-value 对存下来，后续生成时直接复用，从而避免重复计算。

Prefill 的一个重要特点是：

它通常可以高度并行。

因为整段输入已经完整给定了，GPU 能把很多矩阵操作一起做完。所以 prefill 更像“先整体读题”，吞吐通常更高。vLLM 文档也明确把 prefill 归类为更偏 compute-bound 的阶段

你可以把 prefill 想象成一个正在考试的人，prefill 就是他正在读题，把题目先读到脑子里，填充好上下文，然后再开始做答（输出 token）

第六阶段：KV Cache——为什么不会每次都重算全文

这部分是面试里非常加分的点。

因为它体现你不只懂“算法”，还懂“推理为什么能跑得起来”。

如果没有 KV cache，那么每生成一个新 token，模型都要把整个历史上下文从头再算一遍，成本会非常高。

而有了 KV cache 后，历史 token 在每层 attention 中算出的 K 和 V 都会被缓存起来。下一个时间步只需要为新 token 计算新的 Query、Key、Value，再用新的 Query 去和历史缓存里的 Key 做匹配即可。Hugging Face 的官方文档把这一点解释得很清楚：KV cache 的目标就是消除重复计算，加速自回归生成。

一句话说明就是：

●没有 KV cache，像每次都重读整篇文章

●有 KV cache，则像前文已经做好笔记，现在只补最后一句。

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

一个东西值不值得缓存，不看它“重不重要”，而看它“后面还会不会再次被用到”。

KV cache 只缓存 K 和 V，不缓存 Q，不是因为 Q 不重要，而是因为 Q “只在当前这一步有用一次”；而 K、V 会在后面每一步继续被反复用到。这正是 Hugging Face 官方对缓存机制的解释：过去 token 的 K 和 V 可以缓存并复用，而在推理时，只需要“最后一个 token 的 query”来计算当前步的表示。

第七阶段：Decode——开始逐 token 生成答案

当 prefill 完成后，模型已经“读懂”了整段输入。

接下来，系统会取最后一个位置的隐藏状态，通过输出层映射成整个词表上的 logits，也就是“下一个 token 的打分”。随后再通过 softmax 和解码策略，决定下一个 token 输出什么。Transformer 的输出逻辑与 Hugging Face 的生成文档都说明了这一点。

这里又有一个容易被问到的点：

下一个 token 是怎么选出来的？

并不是只有“选概率最大”这一种方式。常见解码策略包括 greedy、sampling、top-k、top-p 等。不同策略会影响文本的稳定性、多样性和创造性。Hugging Face 的生成策略文档对此有系统说明。

然后，流程进入一个循环：

●把刚生成的 token 接到上下文后面

●复用 KV cache

●只为这个新 token 跑一遍前向计算

●再得到新的 logits

●再生成下一个 token

这就是为什么你看到的大模型回答，总是一个 token 一个 token 流式地吐出来，而不是整段瞬间出现。

为什么“第一个字慢，后面快”？

这也是一个非常像面试 follow-up 的问题。

很多候选人知道 prefill 和 decode，但解释不清为什么两者速度特征不同。

vLLM 的优化文档明确提到，prefill 更偏 compute-bound，decode 更偏 memory-bound。

原因在于：prefill 可以把整段输入并行做大矩阵乘法，吃满 GPU 算力；而 decode 虽然每步只算一个 token，但它强依赖历史 KV cache，频繁访问显存，并且步骤之间有严格的顺序依赖。

这也是为什么工程上会有很多针对推理性能的优化，比如：

●FlashAttention：通过 IO-aware 的 attention 计算方式，减少显存读写

●continuous batching：动态调整批次，减少 GPU 空转

●chunked prefill / Paged Attention：改进长上下文和缓存管理效率

要注意，这些技术优化的是执行效率，不是模型的“语义本质”。模型本质上做的事情仍然是：基于已有上下文，反复预测下一个 token

我现在觉得，这道题最稳妥的回答方式，就是最后收束成一句话：

一个 LLM 请求的推理过程，本质上是：先把 prompt 模板化并 token 化，经由推理服务调度进入 GPU；模型通过 embedding 和多层 Transformer block 并行完成 prefill，建立上下文表示和 KV cache；随后进入 decode 循环，基于历史缓存逐 token 执行注意力、前馈网络和采样，直到生成结束，再把 token 序列反解码成文本返回。这条链路同时体现了 Transformer 的计算机制、自回归生成范式，以及现代推理系统在 batching、缓存和 attention kernel 上的工程优化

看起来都是推理引擎的活儿啊？

从整个流程上看，几乎都是推理引擎在负责，所以可以这么理解，但要再往前走半步：

●从“流程编排”角度看，LLM 本体确实很被动；

●从“核心计算与语义生成”角度看，LLM 才是全链路里最不可替代的部分。

如果把整个链路拆开，职责大致是这样的：

1.推理引擎 / serving 系统负责：接 HTTP 请求、做 tokenization / 输入处理、调度 batching、管理 KV cache、协调 GPU worker、流式返回结果、做一部分采样与系统优化。vLLM 的官方文档甚至把这几层写得很直白：最少会有 1 个 API server 负责 HTTP、tokenization 和输入处理，1 个 engine core 负责 scheduler 和 KV cache 管理，再加上 N 个 GPU worker 负责执行模型前向计算。

2.LLM 模型本体负责：对 input_ids 做 embedding，经过多层 Transformer block 的 self-attention 和 feed-forward network，输出 logits，也就是“下一个 token 的分数分布”。Transformer 论文给出的核心结构就是 attention + FFN；Transformers 文档也明确说 causal language modeling 本质上是在左侧上下文条件下做 next-token prediction，而模型输出里的 logits 是对词表中每个 token 的预测分数。

所以，**推理引擎决定“怎么高效地跑”，模型决定“到底生成什么”。**前者偏“编排与优化”，后者偏“语义计算与内容生成”

一文讲透 GoF 的 23 种设计模式之工厂方法

Fri, 27 Feb 2026 23:00:00 +0000

一文讲透 GoF 的 23 种设计模式之工厂方法

工厂方法（Factory Method）是创建型模式

定义

用一句话概括工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。它让类的实例化推迟到了子类。

简单工厂

了解工厂方法模式前，我们先了解下简单工厂，既然叫简单工厂，那自然很 “简单”。

它的核心思想非常直接：专门定义一个类（包揽大权），通过接收不同的参数，用 switch 或 if-else 来决定创建并返回哪一种具体的产品实例。

假设我们在开发一个 AI 应用，需要根据不同场景创建不同类型的 AI Agent（比如负责对话的 Agent，和负责处理数据的 Agent）。

第一步：定义产品的共同接口和具体实现

 1⚡ java片段// 1. 抽象产品
 2public interface AIAgent {
 3 voidexecuteTask();
 4}
 5
 6// 2. 具体产品 A：聊天助理
 7publicclass ChatAgent implements AIAgent {
 8 @Override
 9 publicvoidexecuteTask() {
10 System.out.println("ChatAgent: 正在与用户进行自然语言对话...");
11 }
12}
13
14// 2. 具体产品 B：数据分析助理
15publicclass DataAnalysisAgent implements AIAgent {
16 @Override
17 publicvoidexecuteTask() {
18 System.out.println("DataAnalysisAgent: 正在提取并分析核心数据...");
19 }
20}

第二步：创建“简单工厂”类

 1⚡ java片段// 3. 简单工厂类 (通常使用静态方法)
 2publicclass AIAgentFactory {
 3 
 4 // 根据传入的类型参数，决定实例化哪个具体的 Agent
 5 publicstatic AIAgent createAgent(String agentType) {
 6 if ("chat".equalsIgnoreCase(agentType)) {
 7 return new ChatAgent();
 8 } elseif ("data".equalsIgnoreCase(agentType)) {
 9 return new DataAnalysisAgent();
10 } else {
11 throw new IllegalArgumentException("未知的 Agent 类型: " + agentType);
12 }
13 }
14}

第三步：客户端调用

 1⚡ java片段public class Client {
 2 public static void main(String[] args) {
 3 // 客户端不需要知道 ChatAgent 和 DataAnalysisAgent 是怎么被 new 出来的
 4 // 只需要告诉工厂：“给我一个 chat 类型的 Agent”
 5 AIAgent agent1 = AIAgentFactory.createAgent("chat");
 6 agent1.executeTask();
 7
 8 AIAgent agent2 = AIAgentFactory.createAgent("data");
 9 agent2.executeTask();
10 }
11}

结合代码，我们可以很直观地看到它的特点：

●优点（省事、解耦）：客户端彻底和具体的实现类解耦了。你不需要在业务代码里到处写 new ChatAgent()，把“创建对象”的脏活累活全交给了工厂。

●缺点（牵一发而动全身）：它严重违反了“开闭原则”（对扩展开放，对修改关闭）。假设我们现在要引入一个新的 CodingAgent（写代码助手），除了要新建产品类，你必须去修改 AIAgentFactory 里面的 if-else 代码。一旦产品种类极其庞大，这个工厂类就会变得非常臃肿且难以维护。

正是为了解决简单工厂“违反开闭原则”的这个致命缺点，才演进出了工厂方法模式（把这一个大工厂，拆成了一个个不用改代码、只需新增的具体小工厂）。

工厂方法模式的结构与角色

工厂方法模式主要包含四个角色：

●抽象产品 (Product)：定义产品的统一接口。

●具体产品 (Concrete Product)：实现抽象产品接口的具体类。

●抽象工厂 (Creator)：声明返回产品对象的工厂方法。

●具体工厂 (Concrete Creator)：重写工厂方法，返回具体的实例化产品

Java 代码实现

1. 定义产品（大模型客户端）

 1⚡ java片段// 抽象产品：统一的大模型调用接口
 2public interface LLMClient {
 3 String generate(String prompt);
 4}
 5
 6// 具体产品 A：Claude 客户端
 7publicclass ClaudeClient implements LLMClient {
 8 private String modelVersion;
 9 
10 publicClaudeClient(String modelVersion) { this.modelVersion = modelVersion; }
11
12 @Override
13 public String generate(String prompt) {
14 return"[Claude " + modelVersion + "] 思考并返回结果...";
15 }
16}
17
18// 具体产品 B：OpenAI 客户端
19publicclass OpenAIClient implements LLMClient {
20 private String endpoint;
21 
22 publicOpenAIClient(String endpoint) { this.endpoint = endpoint; }
23
24 @Override
25 public String generate(String prompt) {
26 return"[OpenAI API] 处理输入并返回结果...";
27 }
28}

2. 定义创建者（核心：业务骨架 + 工厂方法）

这里是关键：AgentWorkflow 不是一个纯粹的“工厂类”，它是业务类，工厂方法只是它的一部分。

 1⚡ java片段// 抽象创建者：Agent 工作流骨架
 2public abstract class AgentWorkflow {
 3
 4 // 核心业务逻辑：定义了标准的处理流程（这其实也是个模板方法）
 5 publicvoidprocessTask(String taskContext) {
 6 System.out.println("=== 1. 解析任务上下文，提取关键信息 ===");
 7 
 8 // 【灵魂所在】：这里调用工厂方法，拿到一个产品对象。
 9 // 父类在此刻完全不知道自己拿到的是 Claude 还是 OpenAI。
10 LLMClient client = createLLMClient();
11 
12 System.out.println("=== 2. 请求大模型进行推理 ===");
13 String result = client.generate(taskContext);
14 
15 System.out.println("=== 3. 结果后处理并落库 ===\n" + result + "\n");
16 }
17
18 // 【工厂方法】：将实例化具体产品的职责，推迟到子类去实现
19 protected abstract LLMClient createLLMClient();
20}

3. 定义具体创建者（子类重写工厂方法）

 1⚡ java片段// 具体创建者 A：基于 Claude 的工作流
 2publicclass ClaudeAgentWorkflow extends AgentWorkflow {
 3 @Override
 4 protected LLMClient createLLMClient() {
 5 // 这里封装 Claude 特有的复杂初始化逻辑（比如加载凭证、设置代理等）
 6 System.out.println(" -> [工厂方法] 正在初始化 Claude 客户端环境...");
 7 return new ClaudeClient("3.5-Sonnet");
 8 }
 9}
10
11// 具体创建者 B：基于 OpenAI 的工作流
12publicclass OpenAIAgentWorkflow extends AgentWorkflow {
13 @Override
14 protected LLMClient createLLMClient() {
15 System.out.println(" -> [工厂方法] 正在构建 OpenAI 客户端环境...");
16 return new OpenAIClient("https://api.openai.com/v1");
17 }
18}

4. 客户端调用

 1⚡ java片段public class Client {
 2 publicstaticvoidmain(String[] args) {
 3 String task = "编写一段 Python Web 框架对比报告";
 4
 5 // 场景 1：启动基于 Claude 的 Agent 工作流
 6 AgentWorkflow claudeWorkflow = new ClaudeAgentWorkflow();
 7 claudeWorkflow.processTask(task);
 8
 9 // 场景 2：切换为基于 OpenAI 的 Agent 工作流
10 AgentWorkflow openaiWorkflow = new OpenAIAgentWorkflow();
11 openaiWorkflow.processTask(task);
12 }
13}

如果你回看之前的例子，你会发现这个 Demo 解决了一个架构设计上的核心痛点：控制反转 (IoC) 的雏形。

在 AgentWorkflow 这个父类中，业务主流程已经被彻底固化并复用（processTask 方法）。如果在未来，业务需求要求你接入一个全新的本地开源模型（比如 DeepSeek），你不需要修改任何现有的主流程代码，只需要：

●新建一个 DeepSeekClient（实现 LLMClient）。

●新建一个 DeepSeekAgentWorkflow，重写 createLLMClient() 方法返回这个新 Client。

这才是工厂方法模式真正强大的地方：它是为了让高层模块（业务骨架）能够独立于底层模块（具体产品）的创建而存在，从而支撑起大型框架的扩展性。 JDK 里的 Iterable 接口和它的 iterator() 方法，本质上就是这种工厂方法模式的经典体现。

什么时候用?

●你写的“父类流程”需要创建某种对象，但父类不该/不想知道具体类是谁（框架留扩展点的典型方式）。

●你希望通过继承覆写来扩展“产物类型”，让调用方不动、流程不动。

一些具体的场景：

●框架扩展点：工厂方法很常见于“框架规定流程、业务方覆写创建”的场景（你写子类接入框架）。

●Spring 的 FactoryBean：它的语义就是“这个 bean 不是普通 bean，而是用来生产另一个对象的”，并且暴露的是 getObject() 创建出来的对象。

●Java ServiceLoader：通过 SPI 在运行时发现/加载实现类，属于“把具体实现延迟到运行时配置/部署”的一类机制，和“解耦创建与使用”的目标一致。

注意模式的命名

我们回头看一下这个模式为什么叫 Factory Method，而不是干脆叫 Factory ? 这个命名是有讲究的。

核心原因在于：这个模式的灵魂是一个“方法”，而不是一个“类”。

1.“工厂 (Factory)”是一个通俗的广义概念：

在日常沟通中，只要一个类的主要职责是造对象，我们都叫它工厂（比如前面提过的“简单工厂”，它就是一个充斥着 if-else 的具体类）。

2.“工厂方法 (Factory Method)”强调的是面向对象中的“多态”与“继承”：

在 GoF 的定义中，创建对象的逻辑并不是封装在一个独立的、包揽大权的“工厂类”里，而是定义在了一个普通业务类（Creator）的内部，作为一个抽象方法存在。

●这个模式的精髓是：父类定义业务骨架，把其中“需要实例化具体对象”的那一步，挖空成一个方法（也就是 Factory Method）。

●具体的实例化工作，推迟（Defer）到了子类去重写这个方法来实现

提示词缓存:让 LLM 成本降 10 倍

Mon, 29 Dec 2025 05:37:52 +0000

“

OpenAI 和 Anthropic 声称，缓存的输入 token 在成本上比常规输入 token 便宜 10 倍。

到底什么是 Cached Token ？

Cached Token 就是让 AI “记住” 它刚刚读过的长内容，不用每次都在脑子里从头重新算一遍，从而让回答变得极快且极便宜。

想象你正在参加一场开卷考试，考试内容是一本 500 页的历史书。

没有 Cache (传统模式) ：
第一题：你把书从第 1 页读到第 500 页，然后回答问题。
第二题：你忘光了刚才读的内容，必须再次从第 1 页读到第 500 页，才能回答第二个问题。
后果：每次回答都很慢，而且把你累得半死（消耗算力，费钱）。
有了 Cached Token (缓存模式) ：
第一题：你从第 1 页读到第 500 页，并把关键知识点和理解暂时存在脑子里（存入显存）。
第二题：你直接调用脑子里的记忆，跳过阅读过程，立刻回答问题。
后果：只有第一次慢，后面飞快，而且因为不用重复劳动，甚至可以给考官（用户）打个一折的优惠价

很多人会误以为 “缓存 = 把上次的回复存起来再发一遍”。不是的。

更准确地说，缓存的是模型在处理这段输入时产生的一些中间计算结果（常被称为 KV cache：attention 里的 K / V 矩阵）。所以即使 cached_tokens 很高，你也仍然可能得到不同的回答（因为采样、temperature 等发生在更后面）

LLM 架构

想要彻底弄明白 Cached Token，我们需要从原理上了解一下 LLM 架构。

我们可以将大语言模型（LLM）的架构看作是一个巨大的数学函数：输入一串数字，输出一个数字。这个过程主要由以下四个核心部分组成：

Tokenizer (分词器 / 切词器)

这是模型与人类语言交互的翻译官。

LLM 无法直接理解文本（如中文或英文），它只能处理数字。Tokenizer 的作用是将你输入的提示词（Prompt）切分成一个个小的片段，称为 Token，并为每个 Token 分配一个唯一的整数 ID。

比如输入 “Check out ngrok.ai”，Tokenizer 会将其切分为 [“Check”, “out”, “ng”, “rok”, “.ai”]，并转换为对应的数字序列。

注意：不同的模型（如 GPT-5 和 Claude）使用不同的 Tokenizer 规则

Embedding (嵌入层)

这是让数字拥有含义的一步。将 Tokenizer 生成的简单整数 ID 转换为高维向量（即一长串数字数组）。这个过程就像查字典，每个 Token ID 对应一个固定的向量。

下面是一个例子，可以看到将原始 token 进行 embedding 后是什么样子。

Embedding 是可以有很多维度的，最大的模型甚至超过 10,000 维，上面的例子只显示了三维。维度越多，大语言模型对每个标记的表示就越复杂、越细致。

这些向量代表了 Token 的 “语义位置”。在这个高维空间中，含义相似的词（如 “猫” 和 “狗”）在空间上的距离会更近。这一步还会把 Token 的位置信息编码进去，这样模型就能知道词语的先后顺序。

如果你听说过 “余弦相似度”，那么恭喜你找对了方向。Embedding（嵌入）和 Cosine Similarity（余弦相似度）的关系可以理解为 “坐标” 与 “距离测量工具” 的关系。

想象一个巨大的多维空间（就像一个无限大的图书馆）。Embedding 就是把每一个词、每一句话都变成这个空间里的一个具体的坐标点，在这个空间里，意思相近的词（比如 “猫” 和 “小猫”），它们的坐标点会靠得很近；意思无关的词（比如 “猫” 和 “微波炉”），距离就会很远。Embedding 把文字变成了数学空间里的向量，而余弦相似度用来计算这些向量之间的 “语义距离”。

Transformer (变换器 / 核心处理层)

这是 LLM 的大脑，负责理解和推理。

它的主要工作是让输入序列中的每个 Token 相互 “交流”。模型会计算每个 Token 对其他 Token 的重要程度（即 “注意力权重”）。例如在句子 “Mary had a little lamb” 中，模型会计算出 “Mary” 对 “had” 的生成有多重要。这就是它的核心机制。

到这里我知道你肯定会想到这篇开山之作**《Attention Is All You Need》**。没错，这篇论文作为开山之作，几乎全篇都在讨论 “Transformer”。该论文提出的 Transformer 架构，其主要职责就是接收 Embedding 层的输入（一堆数字向量），然后在这一层内部通过 Attention（注意力机制）和 Feedforward（前馈网络）对这些数据进行复杂的数学变换。关于论文这里不便展开，我们言归正传。

在这一层，输入的 Embedding 会被转化为 Query (Q)、Key (K) 和 Value (V) 三种形态。通过复杂的矩阵运算（Q 乘以 K 得到权重，再乘以 V），模型能够理解上下文的语境和词与词之间的关系。

简单来说：

每个 token 会生成三组向量：Q (Query：我想找什么)、K (Key：我有什么线索)、V (Value：我的内容是什么)
通过计算 Q 和所有 K 的相似度，得到 “该关注谁” 的权重（softmax 归一化），再对 V 做加权求和，得到 “结合上下文后的新表示”。
Multi-head 就是并行做多组注意力，让模型能同时学到多种关系（语法、指代、主题等）

这个阶段是计算量最大的部分。为了加速，推理过程中会将计算过的 K 和 V 矩阵缓存起来（即 KV Cache），避免对之前的 Token 重复计算

Output (输出层)

这是最终生成结果的一步。

经过 Transformer 层层处理后，最后得到一个新的 Embedding。输出层会将其转化为概率分布，预测下一个最可能出现的 Token。

LLM 是 “自回归” 的，这意味着它每次只生成一个 Token。生成的这个新 Token 会被加回到输入的末尾，整个流程（Tokenizer -> … -> Output）再次循环，直到生成结束符（如）或达到长度限制

实现原理

了解了之前这些背景知道，我们就可以解释 Cached Token 的技术原理了。

在 LLM（大语言模型）推理过程中，Cached Token 指的是对 KV Cache (Key-Value Cache) 的复用技术。

Transformer 架构是自回归的。在生成回答（Decode 阶段）之前，模型必须先 “理解” 输入（Prefill 阶段）。这个 “理解” 过程涉及大量的矩阵运算，计算出每个 Token 的 Key 和 Value 向量（即注意力机制的中间状态）。对于长文本（如 RAG 场景中的大量文档），每次请求都重新计算这些 KV 向量是巨大的算力浪费，这就是 Cached Token 解决的问题。

实现机制：

存储状态：当模型第一次处理前缀（Prefix，例如 System Prompt 或长文档）时，将计算好的 KV 向量驻留在 GPU 显存（VRAM）或层级存储中。
前缀匹配：当新的请求进来，如果开头部分（Prefix）与缓存中的 Token 完全一致，推理引擎（如 vLLM, SGLang）会直接加载已计算好的 KV 状态，跳过 Transformer 的前向计算过程。
PagedAttention：现代推理引擎（如 vLLM）使用类似操作系统内存分页的技术（PagedAttention）来管理这些缓存块，解决了显存碎片化问题，允许多个请求共享同一份物理显存中的 Prompt 数据

想省钱，要这样用

要在应用里稳定吃到 cached tokens（prompt caching），核心就三句话：

提示词要够长（通常 ≥ 1024 tokens 才会开始命中）
前缀要 “完全一致”（缓存按 “最长相同前缀” 命中，哪怕一个字符 / 空格不同都可能全失效）
把不变的放前面，把变化的放后面（指令/工具/示例/长背景固定；用户问题、检索结果、时间戳等放末尾）

所以我们要从设计上进行些调整才能够 “省钱”：

设计 “可缓存的前缀结构”，把 prompt 拆成两段（非常重要）：
可缓存前缀（Static Prefix）：system 指令、角色设定、规范、few-shot 示例、工具定义、长期不变的背景资料
动态尾部（Dynamic Tail）：用户输入、RAG 检索内容、实时数据、时间戳、request_id、实验开关等
多轮对话 / Agent 的注意事项
消息数组要 “只追加，不改历史”：如果你为了省 tokens 把历史消息重排、压缩、或插入到中间，很可能导致前缀变了 → cache miss。
工具定义（tools）必须完全一致，顺序也要一致，否则工具部分也进不了缓存前缀

“

OpenAI Cookbook 直接建议：静态内容放开头，可变内容放结尾；工具 / 图片也一样。

常见 “踩坑清单”

把时间戳 / 随机 ID 放在 system 开头：每次都变，等于主动让缓存失效。
JSON 序列化不稳定：同一份 tool schema 如果字段顺序、空格、换行变化，token 序列可能变 → miss（所以建议对 system/tools 做 “规范化输出”，并保持完全一致）
指令在每次请求里微调一两个字：看似小改动，可能让前 1024 tokens 出现差异，直接从 “高命中” 变成 “全 miss”。Azure 文档明确说 “前 1024 tokens 一个字符差异就会 miss”

缓存能活多久 / 怎么保持

不同厂商策略不同，但你可以这么理解：缓存不是永久的，要么靠短时间内重复使用，要么使用更长的保留策略（如果提供）。

Azure OpenAI：缓存通常在空闲 5–10 分钟清理，并且最晚 1 小时内会移除；还支持 prompt_cache_key 帮你影响路由提高命中，但同一前缀 + key 如果请求过猛（文档提到约 15 RPM 量级）可能溢出导致命中变差。
OpenAI：提供 prompt_cache_retention（默认 in_memory，也可选 24h 做更长保留），并说明缓存的是 attention prefill 产生的 KV tensors，原始提示文本不以同样方式持久化。
Anthropic Claude：通过在特定内容块上标注 cache_control 来启用 / 控制缓存（用法是显式的）。

落地建议

给开发：

把系统提示词拆成 STATIC_SYSTEM_PROMPT（长期不变）+ DYNAMIC_CONTEXT（每次变）
所有请求都按固定模板拼：STATIC_SYSTEM_PROMPT + tools + (可选固定示例) + DYNAMIC_CONTEXT + user_question
总结来说：把静态内容（System Prompt、Tools）置顶，动态内容（User Query、Time）置底；确保 JSON 序列化顺序固定；针对 Claude 需手动加标记；监控 “缓存命中率”（Cache Hit Rate）指标，确保不是在做负优化。

给产品：

缓存能让长文档分析、多轮对话变得极快且便宜。设计功能时，尽量让用户基于一个 “固定的背景”（如上传一份文档后针对该文档多次提问），这最能利用缓存优势。

实际应用场景

多轮对话 (Chatbot)：用户和 AI 聊了 20 轮，第 21 轮时，前 20 轮的历史记录就是 “Cached Token”。不用每次都重算历史记录，响应更快。
文档问答 (RAG)：上传一本 PDF 法律合同。只要文件没变，第二个问题开始，AI 就不需要重新处理这份文件
代码助手 (Coding Agent)：将整个项目的代码库结构作为 Prompt 发送给 AI。这部分内容巨大且变动不频繁，非常适合缓存。
角色扮演 / Agent：复杂的 System Prompt（设定 AI 的性格、规则、工具定义）通常很长且固定，缓存后每次调用都极快

Gemini 3 介绍

Wed, 19 Nov 2025 13:22:13 +0000

Gemini应用每月用户超过6.5亿，超过70%的云服务客户在使用我们的人工智能，1300万开发者基于我们的生成式模型进行了开发，而这仅仅是我们所看到的影响的一小部分。 – Google CEO Sundar Pichai

每一代 Gemini 都在以往的基础上不断发展，让你能够做更多事情。

●Gemini 1 在原生多模态和长上下文窗口方面的突破，拓展了可处理信息的种类以及数量。

●Gemini 2为智能体能力奠定了基础，并在推理与思考方面突破了前沿，助力完成更复杂的任务和构想，使 Gemini 2.5 Pro在LMArena上占据榜首超过六个月。

今天，Google 终于憋出了大招，正式发布了 Gemini 3 系列。Google 这次明显是想通过 “Agentic（代理化）” 和 “Generative UI（生成式 UI）” 这两张牌，彻底改变我们开发和使用 AI 的方式。

一、核心模型：不再只是 “陪聊”，而是 “干活” 的

这次发布的重头戏有两个模型版本：

1.Gemini 3 Pro

○定位：这是新的主力模型，Google 称之为 “最智能的模型”。

○最大亮点 ——“Vibe Coding”：你不需要写精确的 prompt 或者伪代码，只需要用自然语言描述你想要的 “感觉（vibe）” 或功能，它就能生成全栈应用。比如 “做一个复古风格的太空射击游戏，障碍物要随着合成波音乐跳动”，它能直接给你生成带 UI 和交互的成品。

○能力提升：推理能力大幅增强，官方数据说在 LMArena 上 Elo 分数飙到了 1501（目前榜首）。

○适用场景：日常高频任务、代码生成、多模态理解（视频/图像/音频）。

2.Gemini 3 Deep Think

○定位：专门用来 “死磕” 难题的推理模型，仅面向 Google AI Ultra 订阅用户。

○对标对象：显然是 OpenAI 的 o1 / o3 系列。

○恐怖的数据：在 Humanity’s Last Exam（人类终极考试）这个测试集上，Gemini 3 Pro 得分 37.5%，而 Deep Think 版本能干到 41.0%（作为对比，上一代 Gemini 2.5 Pro 只有 21.6%）。这意味着在数学、科学研究等需要深度思考的领域，它的可靠性会有质的飞跃。

二、 AI IDE ：Google Antigravity (反重力)

Google 推出了一个全新的 Agentic IDE，叫 Google Antigravity

●这是什么？别把它想成 VS Code 的插件。这是一个独立的 IDE，专门为 “AI 代理开发” 设计的。

●核心逻辑变了：以前我们是用 Copilot 写代码（AI 辅助你），现在你是 “架构师”，你定义任务，Antigravity 里的 Agents（代理）去执行。

●它能干嘛？

○全自主干活：代理可以在编辑器写代码、在终端跑命令、在浏览器里预览调试，三者打通。

○Artifacts（产物）：代理不仅仅是吐代码，还会生成任务清单、实施计划、甚至截图，让你像验收工作一样去 Check 它的产出。

○模型任选：这一点很良心，除了 Gemini 3，它居然支持 Anthropic 的 Claude Sonnet 4.5 和 OpenAI 的 GPT - OSS。Google 这次格局打开了，意思是 “用最好的工具解决问题”。

这玩意儿就是冲着 Cursor 来的，而且试图在 “自主性” 上更进一步。建议大家赶紧去下个 Preview 版试试，特别是 Mac/Windows/Linux 都支持。

三、用户体验革命：Generative UI (生成式 UI)

Google 认为：“最好的 UI 是不需要设计的，是生成的。”

Google 认为，AI 的回答不应该只是一堆文字。Gemini 3 引入了 Generative UI（生成式用户界面）

●动态生成组件：当用户问 “帮我规划去罗马的旅行” 时，它不再只是列个文字清单，而是可能会直接生成一个 “交互式的行程卡片”，或者当你问房贷时，直接生成一个 “房贷计算器组件”。

●底层技术：依靠 Gemini 3 强大的代码生成能力，即时生成前端代码并在客户端渲染。

●Dynamic View：在 Gemini App 里，这被称为 “Dynamic View”。它能根据你的意图，现场 “手搓” 一个最适合当前场景的 UI 界面给你。

未来的 AI 应用，界面可能不再是写死的，而是 “流式生成” 的。

四、实战与性能 (Benchmarks)

如果不看跑分就不是科技圈了。简单列几个吓人的数据：

●LMArena Elo: 1501 (目前世界第一)。

●MathArena Apex: 23.4% (这是个新出的超难数学竞赛基准，其他模型基本是个位数，Claude 4.5 是 1.6%，GPT-5.1 是 1.0%… Gemini 3 这个分数有点断层领先的意思)。

●SWE-bench Verified (代码能力): 76.2%。虽然比 Claude 的 77.2% 略低一点点，但在 Antigravity 环境下的综合表现（Agentic coding）可能会更强。

●多模态: 视频理解 (Video-MMMU) 达到了 87.6%，以后扔给它一段长视频让它总结或者找细节，应该会非常准。

五、生态整合（这才是 Google 恐怖的地方）

Google 把 Gemini 3 塞进了所有角落：

●Search: 搜索里加了 “AI Mode”，而且支持 “Thinking” 开关。以后搜复杂问题（比如做攻略、查论文），搜索体验会完全不同。

●Android Studio: 安卓开发的同事注意了，Gemini 3 已经进驻，不仅是补全代码，还能帮你写 UI、查 Bug。

●Gemini CLI: 对于运维和后端同事，新的 CLI 允许你在终端里直接用自然语言让 Gemini 3 帮你执行复杂的 Shell 命令组合，甚至排查云端服务的 Log。

●Firebase: 推出了 “Firebase AI Logic”，后端逻辑也能由 AI 驱动了。

六、总结与建议

Gemini 3 无疑是一次 “能力的平权”

Gemini 3 不仅仅是 “更快更强”，它在尝试定义 AI 的下一阶段：

1.从 Chat 到 Agent: 不再是 “一问一答”，而是 “通过代理解决多步骤复杂任务”。

2.从 Text 到 UI: 输出形式从文本扩展到了动态界面。

给产研内部的建议：

●开发同学：务必尝试 Google Antigravity 和 Gemini CLI。如果它真能像宣传那样自主改 Bug、重构代码，我们的开发效率可能会有质变。

●产品同学：关注 Generative UI 的交互模式。我们的 AI 产品是否也可以不仅仅吐文字，而是根据用户需求动态生成交互组件？

●模型同学：重点关注 Deep Think 的推理模式，看看 Google 是如何通过增加推理时间（Test-time compute）来换取高质量输出的。

目前 Gemini 3 Pro 已经在 Gemini App 和 AI Studio 里能用了，Deep Think 还要等几周。大家可以先去玩玩 Pro 版的 “Vibe Coding”

怎样才算好文档

Sun, 26 Oct 2025 03:08:25 +0000

优秀文档的核心原则 —— 来自 OpenAI 团队 Cookbook

写文档是一种同理心的体现

文档的核心目标是将有用信息高效注入读者的头脑中，避免读者在信息海洋中迷失。优秀文档不是长篇大论，而是通过结构化、清晰和共情的设计，帮助读者快速解决问题。

让文档易于浏览

读者很少从头到尾线性阅读文档，他们更倾向于跳跃式浏览，寻找直接解决问题的部分。因此，文档应像一张高效的 “信息地图”，降低搜索成本，提高成功率。

●使用描述性标题：标题应是信息完整的句子，而非抽象名词。例如，用 “流式处理将首 token 响应时间缩短 50%” 代替 “结果”，让读者无需深入阅读即可获知要点。

●添加目录：目录如哈希表般加速定位，同时提供文档整体线索，帮助读者判断是否值得阅读。

●保持段落简短：短段落易于扫描；关键点可独立成一句单句段落，避免被长文淹没。

●以独立主题句开头：段落和节的首句应自成一体，不依赖前文。例如，“向量数据库可加速嵌入搜索” 优于 “基于此，让我们讨论更快的方法”，便于跳读者快速理解。

●主题词置于句首：如 “向量数据库加速嵌入搜索” 比 “嵌入搜索可由向量数据库加速” 更高效，因为读者只需读前两词即可把握主题。

●要点前置：将最重要的信息置于文档或节的顶部，避免司马式渐进式展开，先结果后过程。

●多用 bullet 列表和表格：这些格式天然支持扫描，提高可读性。

●加粗关键文本：大胆突出重要内容，帮助读者快速锁定。

这些技巧的核心是“读者优先”：设计时假设读者时间有限、注意力分散。

2. 写出高质量文本

糟糕的文风会消耗读者的认知资源，导致疲劳。优秀文档应追求简洁、流畅，减少解析负担。

●句子简洁：拆分长句、去除副词和冗余词，使用祈使语气（如写作书籍建议）。

●确保无歧义解析：避免词性模糊的句子。例如，“用句子标题节”（Title sections with sentences）易混淆词性；改为 “将节标题写成句子”（Write section titles as sentences）更易解析，即使稍长。

●避免左分支句子：这类句子要求读者短期记忆过多，如 “你需要面粉、鸡蛋、牛奶、黄油和少许盐来做煎饼”。改为右分支：“做煎饼需要面粉、鸡蛋、牛奶、黄油和少许盐”，更符合大脑处理习惯（类似于深度优先搜索）。

●少用指示代词：如 “this” 跨句使用易造成回溯负担。改为具体名词：“基于消息格式，让我们讨论函数调用” 优于 “基于此讨论”。

●保持一致性：统一标题大小写、标点（如尾随逗号）和命名规范（如 Cookbook 中的下划线 + 句首小写），避免读者分心。

●不假设读者心态：避免 “你现在可能想了解函数调用” 这类推测；改为 “To call a function, …”，保持中立。

写作原则源于认知科学：减少大脑负载，让内容自然流动。

3. 广泛有益于读者

文档用户背景多样（从新手到专家、多语言使用者），优秀文档应包容性强，覆盖潜在痛点，而非仅针对 “理想读者”。

●用简单语言：比预期更简化解释（但不低估）。考虑非母语者和术语生疏者，优先清晰而非炫技。

●避免缩写：全写出，如 “instruction following” 而非 “IF”；“retrieval-augmented generation”（或 “搜索 - 询问流程”）而非 “RAG”。专家成本低，新手收益高。

●预解常见问题：即使 95% 读者知晓 Python 包安装，也值得说明 —— 专家可略过，新手避免卡壳。记住，跨语言专家（如 JavaScript 开发者）可能 Python 是新手。

●选用具体准确术语：避开行话，如用 “input” 代替 “prompt”，“max token limit” 代替 “context limit”，更自明且贴合实际。

●代码示例通用自洽：最小化依赖，避免额外库或跨页引用，确保可直接复制运行。

●优先高价值主题：聚焦常见问题（如 token 计数），而非罕见场景（如表情符号数据库优化）。

●避免不良习惯：如 API 密钥勿硬编码示例。

●以广义开场引入主题：如解释推荐系统时，先提及 YouTube、Amazon 等应用场景，增强读者安全感。

这些建议体现共情：文档是为 “所有人” 服务的工具，过多假设会疏离部分用户。

4. 必要时打破规则

这些是指导而非铁律。文档写作是移情练习：代入读者视角，选择最有帮助的方式。最终，灵活应用才能适应具体情境。

AI 第一界炒币大赛正式开始

Mon, 20 Oct 2025 13:31:47 +0000

、

Nof1 Alpha Arena 的实时排行榜：展示不同 AI 模型在真实市场中进行加密货币交易的表现竞赛结果

Nof1.ai

●创始人：https://x.com/jay_azhang 创立了 Nof1，首个专注金融市场的 AI 研究实验室，背景横跨工程、金融与生物，曾将一支小型基金从 300 万做到 2000 万美金 AUM

●https://x.com/jay_azhang 今日强调不发行代币，猜测未来可能转向 AI 基金模式或推出专业交易 AI 模型作为订阅服务。

Alpha Arena

2025-10-18 启动，为每个参赛大模型（如 GPT-5、Gemini 2.5 Pro、Claude Sonnet 4.5、Grok-4、DeepSeek、Qwen3 Max）分配等额 1 万美金，在 Hyperliquid 上全自动交易永续合约，并按收益、胜率、Sharpe 等指标排名

赛制与输入的已知细节

●起始资金：每模型 $10,000

●市场与交易所：Hyperliquid 加密永续合约

●标的集合：站内面板显示 BTC/ETH/SOL/BNB/DOGE/XRP

●统一提示与输入：相同 prompts + 相同输入数据（状态里含时间、账户 / 持仓、价格与指标）。

●公开透明：官网公开成交、持仓与 “模型对话”，便于外部复核。

●实时、无人值守：并非回测 / 纸面交易。

查看 AI 模型具体战绩

钱包地址：

●gemini：0x1b7a7d099a670256207a30dd0ae13d35f278010f

●gpt5：0x67293d914eafb26878534571add81f6bd2d9fe06

●qwen3：0x7a8fd8bba33e37361ca6b0cb4518a44681bad2f3

●claude：0x59fa085d106541a834017b97060bcbbb0aa82869

●grok：0x56d652e62998251b56c8398fb11fcfe464c08f84

●deepseek：0xc20ac4dc4188660cbf555448af52694ca62b0734

DeepSeek

Grok

Claude

Qwen3

GPT-5

Gemini

它 “怎么运作”

可以把 Alpha Arena 想成一个极简的 “环境 - 智能体” 回路：

1. 状态输入（环境→模型）

平台按固定节奏把当前时间、账户与持仓状态、实时价格 / 指标等上下文打包成结构化输入 + 统一提示词，喂给不同大模型；各家模型拿到的是相同的信息。

用 DeepSeek 举例：

USER_PROMPT

CHAINOFTHOUGHT

2. 决策与动作（模型→平台）

每个模型独立做出交易决策（如是否开/平仓、做多/做空、仓位大小等），平台把模型的决策解析为具体委托并在 Hyperliquid 实盘执行。全流程实时、无人干预，不是模拟撮合。

3. 执行与记录（平台→公开面板）

成交、持仓与账户净值会回流到网页的 Completed Trades / Positions / Leaderboard；页面还提供 ModelChat 以便外界事后审阅模型在每次决策前后的对话记录（他们强调透明度）。

4. 评估与排名（平台→指标）

除了原始 P&L，他们强调风险调整，目标设定为 “最大化风险调整后的收益”。

AI 的使用原理

1.统一输入 / 统一提示词：为了可比性，所有模型吃到同一份上下文与提示词；这与许多学术基准 “同题同卷” 的精神一致。

2.非平稳、对抗型环境：和静态 NLP / 推理基准不同，真实市场是动态与对抗的，能暴露 “幻觉”“过拟合历史样本” 等问题，因此更能检验模型在开放环境里的泛化与鲁棒性。

3.以风险调整为目标：不是单看收益，而是看单位风险产出的超额（Sharpe 等），这迫使大模型在仓位、止损、持仓时长等维度做出权衡，而不是 “梭哈式” 极端行为。

问题

●样本期短 / 资金体量小：短期与小资金的排名不稳健，对可复制性、滑点与冲击成本的代表性有限

●“同题同卷” 的一致性风险：若市场参与者观测并抄作业，可能诱发同质化行为（“羊群效应”）；业内也有人担心 “共识化 AI 策略” 带来的同步风险。

●评价口径仍在演化：他们强调 SharpeBench，但具体的风控边界 / 频率配额等细节页面上看没到。

AI 交易，安全可控永远是第一位的。

未来

如果时间线拉长，可能咱们绝大多数人 P 不过 AI，币圈以后的发展方向会不会 Cex 和 Dex 上只剩一堆 AI 策略在？

Prompt on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

一、 AI 编程的“向左走向右走”

二、 什么是 SDD？它为什么重要？

三、 击中痛点：告别“实现漂移”

四、 主流 SDD 工作流大比拼

五、 破局策略：组合最优解（缝合怪战术）

六、 终极实战：六步法完整工作流

👣 Step 1: Codebase (建立项目认知)

👣 Step 2: Brainstorm / Research (技术方案探索)

👣 Step 3: Plan (制定开发计划)

👣 Step 4: Work (执行开发)

👣 Step 5: Review (代码审查)

👣 Step 6: Compound (知识复利)

七、 灵活适配：按场景“裁剪”流程

八、 建立知识沉淀体系（动静分离策略）

九、 驾驭工程的核心：上下文工程

🛠️ 附录：工具链安装避坑指南

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

编程这门“手艺”，正在被自动化

为什么程序员反而比别人更欢迎 AI ？

程序员，越来越像建筑师而不是泥瓦工

新时代的核心能力：不是写，而是“会说”

在创业公司里，A.I. 的效率提升几乎是爆炸式的

真正复杂的地方，是大公司的“棕地”代码库

在亚马逊，AI 正在扮演“半夜抢修工程师”

程序员依然快乐，但快乐的来源正在变化

反对者并不多，但反对得非常激烈

最先被冲击的，可能是初级程序员

如果新人不再亲手写代码，他们还会真正学会编程吗？

当编程越来越像“说话”，普通人也开始写软件了

一个可能属于所有白领的预演

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

一、Symphony 到底是什么？

二、它为什么比“会写代码”更进一步？

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

五、为什么参考实现偏偏选了 Elixir？

六、真正的前提不是更强模型，而是 Harness Engineering

七、它的边界也必须讲清楚

结语

昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

一个高分回答，最好先把整体框架立住

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

第三阶段：进入模型后，token 会先变成向量表示

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

Self-Attention 在干什么？

FFN 又在干什么？

第五阶段：Prefill——先把整段 Prompt “读完”

第六阶段：KV Cache——为什么不会每次都重算全文

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

第七阶段：Decode——开始逐 token 生成答案

为什么“第一个字慢，后面快”？

看起来都是推理引擎的活儿啊？

一文讲透 GoF 的 23 种设计模式之工厂方法

一文讲透 GoF 的 23 种设计模式之工厂方法

定义

简单工厂

第一步：定义产品的共同接口和具体实现

第二步：创建“简单工厂”类

第三步：客户端调用

工厂方法模式的结构与角色

Java 代码实现

1. 定义产品（大模型客户端）

2. 定义创建者（核心：业务骨架 + 工厂方法）

3. 定义具体创建者（子类重写工厂方法）

4. 客户端调用

什么时候用?

注意模式的命名

提示词缓存:让 LLM 成本降 10 倍

到底什么是 Cached Token ？

LLM 架构

Tokenizer (分词器 / 切词器)

Embedding (嵌入层)

Transformer (变换器 / 核心处理层)

Output (输出层)

实现原理

二、什么是 SDD？它为什么重要？

三、击中痛点：告别“实现漂移”

四、主流 SDD 工作流大比拼

五、破局策略：组合最优解（缝合怪战术）

六、终极实战：六步法完整工作流

七、灵活适配：按场景“裁剪”流程

八、建立知识沉淀体系（动静分离策略）

九、驾驭工程的核心：上下文工程

三、用户体验革命：Generative UI (生成式 UI)

四、实战与性能 (Benchmarks)

五、生态整合（这才是 Google 恐怖的地方）

六、总结与建议