Ai on Armstrong Yan

Hey Jarvis 的未来：当 AI 需要自己的入口

Thu, 13 Aug 2026 14:13:57 +0800

在这个系列的第一篇里，我写到 Hey Jarvis 来自一个很小的需求：我和老婆晚上睡觉前聊天，遇到想知道的问题时，希望不用拿起手机，直接问一句就能得到答案。

后来我做出了 Pipeline、Realtime 和 Mac App，也处理了语音交互与 Mac 产品化中的一系列问题。

做到这里以后，我反而越来越清楚地看到一个限制：

AI 可以越来越聪明，但如果它没有一个自然、稳定并且值得信任的入口，它仍然只是一个需要被主动打开的应用。

我最初很容易把这个问题归结为一句更情绪化的话：Siri 阻碍了 AI 助手的发展。

现在我觉得，这句话只说对了一半。

Siri 既是助手，也是系统入口链接到标题

从使用者的角度看，Siri 最特别的能力不一定是回答得有多聪明，而是它已经存在于系统里。

它拥有唤醒词、锁屏入口、麦克风权限、系统界面和设备之间的身份。使用者不需要先找到一个应用，也不需要理解哪个后台进程正在运行。说出一句话，入口就在那里。

第三方 AI 应用即使拥有更好的模型，也很难获得完全相同的位置。

Apple 并非完全关闭第三方能力。通过 App Intents，应用可以把自己的动作和内容以结构化方式提供给 Siri、Apple Intelligence、Spotlight 和 Shortcuts。2026 年的更新还继续增加了长时间后台任务、可取消任务、跨设备实体以及敏感操作确认等能力。Apple 也已经公布新一代 Siri AI，强调个人上下文、屏幕理解、网络知识和跨应用操作。

但这里有一个重要区别：

把应用的能力提供给系统助手
≠
让应用自己成为系统助手

第三方可以把一个动作交给 Siri 调用，却不等于可以拥有自己的系统级唤醒词、在所有状态下持续等待，或者无摩擦地取代默认语音入口。

一个很具体的例子是，Apple 目前确实允许第三方 conversational app 通过 iPhone 侧键启动，但官方的 assistant activation 能力只面向日本，需要专门的 Side Button Access entitlement，并受地区与设备条件限制。

这说明 Apple 不是不知道第三方语音助手需要硬件入口。恰恰相反，这个入口重要到必须被平台单独定义、授权和限制。

Hey Jarvis 的困难 II：从 Demo 到 Mac 产品

Thu, 13 Aug 2026 14:08:41 +0800

在上一篇里，我写了 Hey Jarvis 怎样处理确认音、回声、打断和麦克风交接。

当这些能力在终端和浏览器里跑通时，我一度觉得产品最困难的部分已经完成了。

后来我才意识到，那只是证明了一条语音流程可以工作。

一个 Demo 只需要在我准备好的环境里成功一次。一个产品则必须面对第一次安装、权限拒绝、窗口切换、电脑锁屏、系统睡眠、子进程崩溃和应用退出。它不但要成功，还要在无法成功时停在一个安全、诚实、可以恢复的状态。

Demo 证明一件事能发生。产品必须决定其他所有事情发生时怎么办。

产品化不是给 Python 加一个窗口链接到标题

最早的 Hey Jarvis 由 Python 启动。Realtime 模式还需要打开一个 Chrome 页面，让浏览器负责 WebRTC 的麦克风和语音播放。

这个结构适合开发，因为每一层都可以单独观察和调试。但如果把它直接包装成一个窗口，很多只存在于我电脑里的前提仍然没有消失：

系统里已经安装了正确版本的 Python 和依赖；
项目目录和 .env 文件位于预期位置；
Chrome 页面没有被重复打开；
API Key 可以由开发环境读取；
进程异常时，我知道应该去哪里看日志和怎样重新启动。

这些都不是产品应该交给使用者理解的事情。

在正式搭建 Mac App 之前，我先做了一个完全隔离的 Tauri 实验。它只回答一个问题：WKWebView 能不能在真实的 Apple Silicon Mac 上完成麦克风授权、Realtime 播放、自然打断、媒体释放，以及把麦克风还给 Python？

实验成功以后，我没有继续在这份实验代码上追加功能，而是重新建立产品自己的应用外壳。

这个选择看起来多走了一步，却帮我区分了两个很不一样的问题：

实验：这条技术路线可不可行？
产品：它能否保护秘密、正确失败、恢复运行，并在另一台电脑上重现？

三种运行环境，三种责任链接到标题

最终的 Hey Jarvis Mac App 分成三部分：

Hey Jarvis 的困难 I：让语音交互真正成立

Thu, 13 Aug 2026 13:59:31 +0800

在上一篇里，我写到，Hey Jarvis 的第一个 Pipeline（串行语音处理流程）其实很快就实现了最初的需求。

我说一句 “Hey Jarvis”，它录下问题，交给 AI 回答，再把答案读出来。

如果只看流程图，这个语音助手已经完成了。

但真正用起来以后，我发现语音交互里最困难的部分，往往不在“识别了什么”或者“回答了什么”，而在一些更基础的问题：它什么时候开始听？什么时候停止听？它能不能分清我的声音和自己的声音？一段对话结束以后，麦克风到底回到了谁手里？

这些问题没有解决时，模型再聪明，使用者也会很快失去耐心。

Pipeline 的第一个问题：它会听见自己链接到标题

为了让我知道唤醒成功，Hey Jarvis 会先播放一句简短的确认音。

最早是“在呢”，后来实时语音会话（Realtime）版本使用的是“嗯，我在，请说”。它听起来只是一个很小的体验细节，却引出了整个项目最早、也最反复的一类问题。

Mac 的扬声器播放确认音时，旁边的麦克风也会收到这段声音。如果程序在确认音结束后才开始读取麦克风，那么音频缓冲区里可能还留着刚才的回声。对程序来说，这些数据和用户刚刚说出的话并没有天然区别。

结果可能是这样的：

我说 “Hey Jarvis”
→ Jarvis 回答“在呢”
→ 麦克风重新收到“在呢”
→ Jarvis 以为用户已经开口
→ 录下一段错误的问题

最直接的办法，是播放确认音时完全忽略麦克风。

但这又制造了相反的问题。我听见“在呢”以后，可能会很自然地立刻开始说话，甚至在确认音的最后一个字还没有完全结束时就已经开口。如果这段时间的音频全部被丢掉，我的问题开头也会一起消失。

比如我说“明天新加坡会下雨吗”，系统收到的可能只剩“新加坡会下雨吗”。这次看起来还能理解；换一个问题，少掉前几个字就可能完全改变意思。

所以最终的处理不是简单地“听”或者“不听”，而是把确认音前后分成几个不同区域：

确认音播放期间持续读取麦克风，避免旧声音堆积在缓冲区；
明显属于扬声器回声、削波或溢出的片段不能成为“用户已经开口”的证据；
靠近播放结束的一小段安全音频暂时保留，作为问题开头的候选；
只有确认音结束后仍然观察到真实说话的迹象，候选音频才会进入正式录音；
如果后面没有人继续说话，就安静地回到唤醒状态，不请求 AI。

这套逻辑还需要估计环境底噪，并在最近的一组音频片段里确认持续的人声，而不是因为某一个突然变大的声音就开始录音。开始录音时，它还会把前面大约半秒的音频一起带上，尽量不丢掉第一个字。

一个原本只有两个状态的问题——“在听”或“没在听”——最后变成了对回声、底噪、连续语音和录音前缓冲的共同判断。

“我在”应该是一句承诺链接到标题

Pipeline 里的确认音主要表示唤醒词已经被识别。

到了实时语音模式，它的含义必须更加严格。

唤醒之后，Hey Jarvis 需要释放本地唤醒使用的麦克风，建立网络连接，完成实时对话配置，准备好播放远端声音，再开放麦克风输入。如果确认音放得太早，我听见“我在”就开始说话，但实时对话可能还没准备好，我说出的内容会直接消失。

所以我后来给这句确认音定义了一个产品层面的含义：

当“嗯，我在，请说”播放完，Hey Jarvis 才应该真正准备好听我说话。

实现这句话，需要等待两个条件：

实时对话已经配置完成
 ＋
确认音已经播放完成
 ↓
开放麦克风输入

这两个过程可以同时进行，但任何一个没有完成，用户输入都不能开放。

我做了一个 Hey Jarvis：从睡前的一个问题开始

Thu, 13 Aug 2026 13:55:06 +0800

我和老婆晚上睡觉前经常会聊天。

有时候聊的是一天里发生的事情，有时候会从一件小事跳到历史、科技、健康或者某个我们突然想到的知识点。聊着聊着，总会遇到一些我们都不知道、但又很想马上知道答案的问题。

这时候，最自然的动作本来应该是直接问一句。

但现实里的动作通常是：伸手去找手机，解锁，打开一个应用，点进输入框，再把刚才的问题重新组织一遍。等答案出现时，原来的聊天已经被打断了。

语音助手本来应该最适合这个场景。可我真正想问的问题，Siri 经常回答不了；而更聪明的 AI，又往往住在一个需要主动打开的窗口里。

我想要的其实很简单：

躺在床上说一句 “Hey Jarvis”，它就能加入我们的对话，回答刚才的问题。

于是我开始做 Hey Jarvis。

功能演示：中文版：让 Siri 级别的唤醒接上 ChatGPT

项目与下载：

第一个版本，其实很快就能工作链接到标题

Hey Jarvis 的第一版是一条很直接的 Pipeline，也就是一条串行语音处理流程：

本地等待 “Hey Jarvis”
→ 播放一句确认音
→ 录下问题
→ 把语音转成文字
→ 让模型生成答案
→ 把答案转成语音并播放
→ 回到唤醒状态

从功能定义上说，做到这里已经实现了最初的需求。

我不需要拿起手机。只要说出唤醒词，再问一个问题，它就会把答案讲出来。为了避免所有声音一直上传，唤醒词检测在本地完成；只有被唤醒之后录下的问题，才会进入后面的 AI 流程。

我还给它加了一些确定性的工具。时间和计算可以在本地完成；天气、汇率和股票价格由明确的数据提供方返回。对于这些会随时间变化的问题，我不希望模型凭记忆猜一个听起来很像真的答案。

如果目标只是做一段功能演示，项目大概已经可以停在这里。

但当我真的开始使用它，我发现：能够用语音问 AI，与拥有一个语音助手，并不是同一件事。

Pipeline 能回答问题，但它还不会对话链接到标题

第一版更像一个由语音启动的命令行程序。

我问完一个问题，它录音、思考、播放答案，然后整段交互结束。想继续追问，就要再说一次 “Hey Jarvis”。如果回答说得太长，我不能像人与人聊天一样插话；我只能等它讲完。

人与人对话时，我们很少意识到自己在做这些事情：

听到对方回应后，知道他已经准备好听了；
在对方说话时插入一句，对方会停下来；
用“那明天呢”继续追问，而不必重新交代上下文；
聊完说一句“再见”，双方都知道对话结束了。

这些在人类交流中近乎本能的行为，到了软件里都会变成明确的状态、事件和边界。

我做了一个小型 Harness，防止 AI 编程项目丢失状态

Tue, 21 Jul 2026 09:21:48 +0800

AI 编程智能体很强大。

但项目一旦拉长，往往会在一些非常具体的地方出问题：

会话突然中断
上下文越积越长
每周额度耗尽
第二天接手的智能体忘了前一天做过哪些决定
智能体改动了无关文件
工作明明还没完成，智能体却提前宣布结束

问题不在于 AI 不会写代码。

真正的问题是，AI 编程项目往往没有持久的项目状态。

所以，我做了一个小型开源模板：

ai-agent-harness-template

它的目标很简单：

让 AI 编程项目随时都能恢复并继续推进。

这不是提示词合集链接到标题

现在已经有很多实用的提示词合集。

但这个模板不是。

它是一套仓库级 Harness，专门用于需要长期推进的 AI 编程项目。

适用工具包括：

Codex
Claude Code
Cursor Agent
其他类似的编程智能体

不过，它不依赖任何一家厂商。

控制边界就是仓库本身。

核心思路链接到标题

应该把智能体当作无状态工作进程来用。

它们不该依赖聊天记录。

每次开始工作时，都应该根据仓库文件重新建立上下文。

这个模板把持久状态保存在以下文件中：

SPEC.md：保存需求
feature_list.json：保存可执行的功能状态
progress.md：保存恢复工作所需的记录
AGENTS.md：保存智能体规则
QUALITY.md：保存评估标准
runs/：保存证据和交接记录

这样一来，后来接手的智能体、人工维护者和 CI 都以同一份信息为准。

仓库现在还提供了一个可安装的 AI Agent Harness skill。

这个 skill 不是另一套数据库。

它只是同一套仓库状态协议的便捷入口。

真正持久的记忆依然留在仓库里。

为什么聊天记录不适合充当数据库链接到标题

聊天记录可以提供有用的上下文。

远程智能体工作流

Tue, 21 Jul 2026 09:03:39 +0800

这个系列探讨如何从移动端 SSH 走向一套以代码仓库为依托、可以长期运行的 AI 智能体工作流。

起因很简单：离开 Mac 后，我仍然想继续推进本地的 Codex 工作。

但随着实践深入，问题很快变成了：

怎样才能把远程访问转变为一套可恢复、可验证、可以长期运行的智能体工作流？

系列文章链接到标题

远程智能体工作流（一）：用手机连接 Mac 运行 Codex
借助 Tailscale、SSH、Termius、tmux 和 caffeinate，打通手机到 Mac 的终端连接。
远程智能体工作流（二）：从远程 Shell 到智能体控制面
解释为什么移动端 SSH 虽然是实用的基础设施，却不适合充当长期智能体任务的日常操作界面。
远程智能体工作流（三）：把 Telegram 变成本地 Codex 的控制面
让 Telegram Bot 以轮询模式运行，把它变成一个轻量的移动端控制界面，用手机就能指挥本地 Codex 任务。
远程智能体工作流（四）：在仓库中，而非聊天中
让代码仓库同时承载智能体记忆、运行约定，并成为 Agent Harness。
远程智能体工作流（五）：Codex Mobile 之后，什么依然重要
官方 Codex Mobile 推出后，重新审视这套自建工作流：它不是替代品，而是项目侧的工作流适配器。

核心演进路径链接到标题

远程终端
 -> 远程运行环境
 -> 移动端控制面
 -> 仓库记忆
 -> 基于仓库的 Agent Harness
 -> 工作流适配器

目的并不是证明哪一种界面更好。

远程智能体工作流（五）：Codex Mobile 之后，什么依然重要

Mon, 20 Jul 2026 23:52:52 +0800

这是“远程智能体工作流”系列的第五篇。

最初搭建这套远程 AI 开发环境时，我想解决一个很实际的问题：

离开 Mac 以后，怎样让本地 Codex 继续干活？

于是有了第一层方案：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

后来我发现，手机上的 SSH 不适合充当日常操作入口，于是又搭了一个 Telegram 控制面：

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 指定代码仓库

再往后，我意识到背后还有一条更根本的原则：

放在代码仓库里，不要放在聊天里。

代码仓库必须保存持久的项目记忆。

更准确地说，它应该承载项目记忆、运行约定和反馈机制。

走到这一步，一个很自然的问题随之而来：

既然官方已经推出 Codex Mobile，自定义远程智能体工作流还有必要吗？

我的答案是：有。但理由变了。

它的价值不再只是让人远程接入 Codex。

更重要的是让 Codex 按照项目自己的方式工作。

Codex Mobile 解决了什么链接到标题

2026 年 5 月 14 日，OpenAI 宣布在 ChatGPT 移动应用中以预览形式推出 Codex。

通过官方移动端，用户可以随时在手机上接入 Codex。按照 OpenAI 的介绍，你可以跨线程处理任务、检查输出、批准命令、切换模型、发起新任务，还能实时收到终端输出、差异内容、测试结果、截图和审批请求等更新。

远程智能体工作流（四）：在仓库中，而非聊天中

Mon, 20 Jul 2026 23:33:28 +0800

这是“远程智能体工作流”系列的第四篇。

我的远程 AI 开发环境，第一层解决连接问题。

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

有了这条链路，我可以用手机访问 Mac，也能让耗时较长的本地任务持续运行。

第二层解决控制问题。

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 选定的仓库

这样一来，手机就成了控制入口，而不再是一台屏幕很小的终端。

但这两层都没有触及更深的问题。

远程访问让我能连上机器。

远程控制让我能启动任务、查看进展。

而长时间运行的智能体开发还需要记忆。

智能体可能在我离开后继续运行，也可能从中断处恢复、换一个会话接着做，或者由我通过手机操控。既然如此，整个项目就不能只存在于一条聊天线程里。

于是，我给自己定了一条规则：

聊天用来传达指令。
仓库用来保存记忆。

更准确地说，仓库不只是存放代码的地方。它还承载着智能体的记忆和操作约定，并为智能体提供持续的反馈机制。

为什么聊天记录不能充当项目状态链接到标题

聊天很适合表达意图。

我可以在聊天里说明目标、提出问题、纠正方向，或者做出产品决策。

但要长期保存项目状态，聊天并不可靠。

聊天内容难以比较差异，也不便验证；它依附于某一条线程，后续会话中的智能体很容易误解，甚至根本看不到。想法、日志、猜测、决定和已经过时的背景信息，往往全都混在同一条信息流里。

如果只是一次性的小改动，这样做未尝不可。

可一旦智能体需要长时间工作，问题就会暴露出来。

项目必须能稳定回答以下问题：

这个系统应该做什么？
哪些内容已经实现？
以前在哪里失败过？
什么证据能证明这些行为现在仍然正常？
下一个智能体在修改文件之前，应该先读什么？

这些答案应该和代码放在一起。

让仓库同时承担记忆与 Agent Harness 链接到标题

在我的项目里，智能体需要长期保留的状态通常分散在以下文件和记录中：

AGENTS.md
SPEC.md
feature_list.json
progress.md
test_plan.md
init.sh
orchestrator.py
git 历史

文件具体叫什么并不重要，重要的是分清职责。

远程智能体工作流（三）：把 Telegram 变成本地 Codex 的控制面

Mon, 20 Jul 2026 23:20:13 +0800

这是「远程智能体工作流」系列的第三篇。

前两篇文章里，我先搭出了一条实用的远程终端链路：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

有了这条链路，我就能可靠地从手机连接自己的 Mac。

但新的局限很快就暴露出来：手机并不好用来操作终端。

移动端 SSH 适合救急，但我不想靠它处理需要长时间运行的 AI 开发任务。我不想在狭窄的手机屏幕上敲 shell 命令、连接 tmux 会话、翻找长篇日志，再一点点拼凑出当前状态。

我真正想要的，是下面这样的链路：

手机 -> 任务式接口 -> 本地智能体运行时 -> 仓库状态

于是，我做了一个小型 Telegram Bot，把它用作本地 Codex 的控制面。

关键不在于 Telegram 有多特别。

真正重要的是：手机成为控制界面，而 Mac 仍然负责执行工作。

为什么选 Telegram 链接到标题

Telegram 很适合用来做这个实验，因为它已经具备：

移动端通知
简短的命令消息
回复串
内联按钮
跨设备历史记录
成熟的 Bot API

更重要的是，Telegram 支持两种截然不同的部署模式。

第一种是 webhook 模式：

远程智能体工作流（二）：从远程 Shell 到智能体控制面

Mon, 20 Jul 2026 22:33:24 +0800

这是“远程智能体工作流”系列的第二篇。

上一篇文章里，我搭建了一套实用的远程终端工作流：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

这套方案解决了第一个问题：离开书桌后，怎样连回自己的 Mac；手机断开后，怎样让本地智能体继续执行耗时较长的任务。

它很快就派上了用场。

但在实际使用后，我又发现了第二个问题。

SSH 解决了连通性，却不会自动带来一套好用的远程开发工作流。

移动端 SSH 用得越多，它的边界就越清楚：

手机不该被当成一台微型终端。
手机应该成为本地智能体工作流的控制面。

第一层解决的是基础设施链接到标题

远程终端这套配置仍然不可或缺。

我需要：

用 Tailscale 连接手机与 Mac，又不把 SSH 暴露在公网上。
用 SSH 安全登录。
用 tmux 保证耗时较长的任务不会因连接断开而终止。
用 caffeinate 防止 Mac 在智能体工作期间休眠。

这样，我就有了一套可靠的基础能力：

我可以连上机器。
我可以启动工作。
我可以断开连接。
我可以稍后再连回来。

这是很实在的一步。

但它只回答了基础设施层面的问题：

我能连到这台机器吗？

它没有回答工作流层面的问题：

我能顺畅地用手机推动耗时较长的 AI 开发工作吗？

对我来说，答案是否定的。

手机并不是一台好终端链接到标题

移动端 SSH 很适合应急访问。

远程智能体工作流（一）：用手机连接 Mac 运行 Codex

Mon, 20 Jul 2026 22:15:53 +0800

本文是“远程代理工作流”系列的第一篇。

这篇指南将介绍如何用手机操作 Mac 终端，并让 Codex、自动化脚本、本地开发代理等长时间任务持续运行。

我们要搭建的不是远程桌面，而是一套可靠的远程终端工作流：

手机 -> SSH -> Mac -> tmux -> Codex / 代理任务

配置完成后，Mac 就会成为一个轻量的远程执行节点。无论身在何处，你都可以用手机接入。

各个工具分别做什么链接到标题

SSH 链接到标题

SSH 是一种安全的远程登录协议，可以让你从手机进入 Mac 的终端。

在这套工作流中，SSH 负责：

安全访问 Mac 的命令行。
使用密码或 SSH 密钥验证身份。
从手机远程执行命令。

不过，SSH 一旦断开，并不能保证任务继续运行。这正是我们还需要 tmux 的原因。

Tailscale 链接到标题

Tailscale 会在你的设备之间建立私有网络。即使 Mac 和手机接入不同的网络，两台设备也能通过稳定的私有 IP 地址互相访问。

在这套工作流中，Tailscale 负责：

让你通过 4G、5G、酒店 Wi-Fi、公司 Wi-Fi 或家庭 Wi-Fi 远程访问 Mac。
为 Mac 提供稳定的 100.x.x.x 地址。
加密设备之间的网络通信。
避免将 SSH 直接暴露在公网上。

本文默认使用官方 Tailscale macOS 客户端。在这种配置下，后台服务、登录状态和菜单栏状态都由该应用管理。

AI 原生软件工程（四）：氛围编程无法取代人的判断

Sat, 18 Jul 2026 23:53:44 +0800

实现可以自动化，评估也可以自动化。但判断，始终只能由人来做。

这是“AI 原生软件工程”系列的第四篇。

本文接续上一篇：AI 原生软件工程（三）：软件即搜索。

第一篇追问，我们如何形成理解。

第二篇追问，我们如何获得正确性。

第三篇提出，软件正在变成一种搜索过程。

但有一个危险的误解，必须说清楚：

只要有智能体、验证框架和约束，
软件就能自行生产出来。

事实并非如此。

在第二篇里，约束帮助我们获得正确性。

在第三篇里，约束塑造了实现方案的搜索过程。

这一篇要继续追问：谁来为约束本身负责？

谁来决定该优化什么，
该拒绝什么，
又有哪些东西从一开始就值得做？

开始采用 AI 辅助的软件开发流程后，我注意到一个出乎意料的现象。

实现能力越强，判断反而越有价值。

起初，我觉得这有些反常。

AI 越强，人的决策不应该越不重要吗？

结果恰恰相反。

实现不再是瓶颈。

方向才是。

氛围编程：好用，直到失控链接到标题

大多数开发者都经历过这样的过程。

一开始，你只有一个简单的想法：

把 X 做出来。

AI 生成代码。

你稍作调整。

跑通了。

于是继续往下做。

一个个小胜利不断累积。

项目也渐渐变大。

直到某个时刻，问题突然一股脑冒了出来：

架构渐渐偏离原来的方向
抽象层越堆越多
调试越来越慢
对系统的信心彻底崩塌

系统依然能运行。

但已经没人说得清，它为什么能运行。

项目陷入一种奇怪的状态：

好像一切都能推倒重来。

却没有任何东西真正处于掌控之中。

我把这叫作氛围编程。

并不是因为 AI 不好。

而是因为，每一步进展都不再对应一个经过认真权衡的决定。

测试通过带来的错觉链接到标题

面对这种问题，一个常见的回答是：

多加一些测试就好了。

我也这样做过。

AI 原生软件工程（三）：软件即搜索

Sat, 18 Jul 2026 23:37:09 +0800

当实现变得唾手可得，工程就不再那么像建造，而更像导航。

这是“AI 原生软件工程”系列的第三篇。

本文承接上一篇：AI 原生软件工程（二）：验证框架工程与正确性。

第一篇追问：

当实现工作交给 AI 后，理解从何而来？

第二篇追问：

当生成的成本变得低廉，如何保证正确性？

这一篇要问：

如果实现越来越便宜，
工程师究竟在做什么？

在这里，约束的含义发生了变化。

第二篇谈约束，是为了保证正确性。

这一篇谈约束，是为了界定搜索范围：

如何划定可接受实现的范围？

纵观软件发展史的大部分时期，开发软件就意味着把它建造出来。

先有一个想法。

然后设计架构。

接着编写实现。

最后测试结果。

瓶颈显而易见：

写代码。

我们对工程能力的理解，也一直建立在这个前提之上。

人们眼中的优秀工程师，往往能够：

更快写出实现
更快完成调试
熟记更多 API
精通更多框架
交付更多可以运行的代码

AI 正在动摇这个前提。

不是因为它会取代工程师。

而是因为它让实现成本骤降。

一旦实现变得便宜，软件开发的方式也会随之改变。

它开始变得像一场搜索。

传统工程：在实现稀缺时做建造链接到标题

传统的软件开发大致遵循这条路径：

想法
-> 架构
-> 实现
-> 验证

实现的代价很高。

每个决定都要付出成本。

每一层抽象都至关重要。

改变方向非常痛苦，因此人们会在动手之前优化方案。

工程就是建造。

AI 让建造变成探索链接到标题

有了现代编程智能体，实现不再稀缺。

短短几分钟，你就可以得到：

五种架构
三套重构方案
两种数据库模型
多套 API 设计

于是，工作流程变成了：

AI 原生软件工程（二）：验证框架工程与正确性

Sat, 18 Jul 2026 23:29:59 +0800

在 AI 原生软件工程中，最重要的也许不是生成，而是约束。

这是「AI 原生软件工程」系列的第二篇。

本文承接上一篇：AI 原生软件工程（一）：智能体编程中的心智模型。

上一篇讨论的问题是：

如果理解系统不再主要依靠亲手写代码，
人类要如何在智能体工作流中建立心智模型？

接下来的问题是：

如果实现工作交给了 AI，
正确性从何而来？

谈到 AI 辅助软件开发，人们往往只关心一件事：

我们能将软件产出提高多少？

编码更快。

上下文更长。

智能体可以自主运行。

一次改动多个文件。

工作流能够自我修复。

但用 AI 智能体做了一段时间项目后，我却得出了相反的结论：

最重要的工程问题，不是如何让 AI 更自主。

而是如何更严格地约束 AI。

因为毫无限制地生成代码，几乎从来不是瓶颈。

正确性才是。

这里暂且不谈约束对创造力或搜索空间的影响，只谈正确性。

真正要回答的是：

怎样才能让 AI 生成的实现可以被放心信任？

传统软件开发的基本假设链接到标题

传统软件开发建立在一个简单的假设上：

人
-> 实现
-> 验证

写系统的人，也会在动手实现的过程中逐渐理解系统。

很多时候，验证并不会被单独提出来。

因为实现出自自己之手，你自然更愿意相信它。

在小团队中，这套做法出人意料地管用。

直到复杂度不断攀升。

AI 打破了这个假设链接到标题

智能体编程改变了原有结构。

现在，整个循环变成了：

人
-> 意图
AI
-> 实现
人
-> 审查

乍看之下，效率很高。

AI 原生软件工程（一）：智能体编程中的心智模型

Sat, 18 Jul 2026 22:57:49 +0800

AI 能生成代码。验证框架能检验行为。但理解由谁来建立？

这是“AI 原生软件工程”系列的第一篇。

这个系列想追问一个更大的问题：

当 AI 降低了实现成本，
软件工程中还有什么是稀缺的？

本文先从第一种稀缺资源谈起：

理解。

过去几个月，我一直在密集尝试 AI 辅助的软件开发方式。

不是自动补全。

也不只是把 AI 当作编程副驾驶。

而是一套由智能体主导执行的工作流：

SPEC
-> 约束
-> 验证框架
-> 智能体执行
-> 评估
-> 迭代

这段经历非常有意思。

借助它，我用自己并不十分熟悉的语言和框架交付了项目，开发速度也大幅提升。

做小项目时，简直像魔法。

可一到更大的项目，意想不到的情况发生了。

我发现，实现速度和系统理解并不是一回事。

最后，我不得不面对一个让人不太舒服的事实：

如果 AI 明天消失，
我可能很难继续开发自己系统里的某些部分。

这个认识改变了我看待软件工程的方式。

传统模式：在实现过程中形成理解链接到标题

过去的软件工程，大致是这样的：

人
-> 编写代码
-> 建立心智模型
-> 运行和维护系统

写代码不只是为了实现功能。

它也是学习系统的过程。

我们在这些事情中逐渐弄懂系统：

调试
重构
追踪执行过程
与各种约束周旋
犯错

亲手实现，自然会带来理解。

只是过去，我们未必意识到这一点。

智能体编程改变了路径链接到标题

有了 AI 编程，整个循环变了。

播客摘要工具让我明白：摘要不等于理解

Sat, 18 Jul 2026 12:13:29 +0800

有人看到我简历上的一个项目，问了我一个很简单的问题：

这个软件真的解决了你的问题吗？

这个问题问得很好。

那个项目是一款播客摘要工具。

源代码公开在这里：yanqian/podcast-summarizer。

最初的想法很直接。

听完一段长音频，要花不少时间。

如果能先把一期节目转成文字，再生成摘要，我也许只需读一遍摘要，不必花一个小时收听，就能理解整期内容。

当时的产品假设是这样的：

长内容
 -> 转写文本
 -> 摘要
 -> 理解

真正做完以后，我才意识到，这个假设并不成立。

倒也不是全错。

但它偏偏错在最关键的地方。

这个软件确实能生成摘要。

它也完整展示了一套 AI 工作流。

它能导入播客、处理音频、生成转写片段和摘要片段，还能显示两者之间的对应关系。

作为工程演示，它是成功的。

但作为帮助人理解内容的工具，它没有解决真正的问题。

最初的问题并不是内容太长链接到标题

一开始，我以为问题就在于内容太长。

一期播客很长。

一篇博客文章也可能很长。

会议转写同样可能很长。

于是，最自然的产品思路就是压缩：

把内容变短

摘要承诺的正是这件事。

它减少篇幅。

删去重复。

把散漫的对话梳理出结构。

看起来很高效。

但真正读过生成的摘要后，我发现了一件不太对劲的事。

摘要读完了，我还是不知道那场谈话究竟是怎样展开的。

我知道他们谈了什么。

知道大致结论。

也记住了几个要点。

但我并没有真正理解整段对话。

摘要丢掉了：

一个观点是怎样被引出来的
是什么问题触发了这个观点
哪些地方仍有疑问
有哪些例子支撑它
讨论过哪些取舍
哪些情绪或现实背景很重要
说话者在哪里改变了思路

摘要并没有说错。

它只是不够。

摘要会抹掉通往结论的过程链接到标题

好的摘要保留了终点。

却留不住抵达终点的那条路。

这正是问题的核心。

很多时候，我们恰恰要沿着这条路走一遍，才能真正理解一个观点。

Ai on Armstrong Yan

Hey Jarvis 的未来：当 AI 需要自己的入口

Siri 既是助手，也是系统入口 链接到标题

Hey Jarvis 的困难 II：从 Demo 到 Mac 产品

产品化不是给 Python 加一个窗口 链接到标题

三种运行环境，三种责任 链接到标题

Hey Jarvis 的困难 I：让语音交互真正成立

Pipeline 的第一个问题：它会听见自己 链接到标题

“我在”应该是一句承诺 链接到标题

我做了一个 Hey Jarvis：从睡前的一个问题开始

第一个版本，其实很快就能工作 链接到标题

Pipeline 能回答问题，但它还不会对话 链接到标题

我做了一个小型 Harness，防止 AI 编程项目丢失状态

这不是提示词合集 链接到标题

核心思路 链接到标题

为什么聊天记录不适合充当数据库 链接到标题