Tech 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”。如果回答说得太长，我不能像人与人聊天一样插话；我只能等它讲完。

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

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

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

看懂新加坡支付体系：从银行 App 到 SGQR、PayNow、FAST、非接触式支付与 NETS

Tue, 21 Jul 2026 10:50:05 +0800

如果你住在新加坡，下面这些支付方式大概每天都会用到：

通过 PayNow 给朋友转账。
在小贩中心扫描二维码付款。
在超市用银行卡或手机轻触付款。
在本地商户使用 NETS。

对用户来说，这些操作看起来大同小异，底层解决的却是不同的问题。

先看全貌链接到标题

这张图有意省略了不少细节，并按照大多数人的实际支付体验来安排顺序：先是 App、银行卡或二维码，再往下进入 SGQR、PayNow 等熟悉的支付入口，最后才是商户网络、银行卡网络和资金转移通道。

用户层：银行 App、银行卡与二维码链接到标题

大多数人付款时，不会先琢磨资金究竟要走哪条支付通道。

我们最先接触的是用户界面：

DBS、OCBC、UOB 等银行的 App。
DBS PayLah! 这类近似电子钱包的 App。
支付 App 内置的二维码扫描器。
实体银行卡。
Apple Pay、Google Pay 等手机钱包。

正是最上面的这一层，让支付用起来很简单。

比如，你在小贩摊位前用银行 App 或 PayLah! 扫码，不必亲自判断该走哪个注册系统、支付方案或结算系统。App 会读取二维码，识别商户支持的支付选项，请你确认，再把交易送入相应的底层路径。

可以先记住这样一个分层思路：

用户体验层
 -> 支付方案或代理寻址层
 -> 资金转移或结算层

接下来要讲的，就是下面各层分别负责什么。

SGQR：统一的二维码层链接到标题

SGQR 是 Singapore Quick Response Code 的缩写。

我做了一个小型 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 不是另一套数据库。

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

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

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

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

共享 Myinfo，不只是自动填表

Tue, 21 Jul 2026 08:44:07 +0800

表单要求填写姓名、地址、国籍、联系方式、收入或家庭资料。这样的表单，你以前已经填过某种版本。有些服务还要求上传证明文件，再由工作人员或后台系统核对文件内容与所填信息是否一致。

这时，页面上出现了一个按钮：

获取 Myinfo 数据

在用户眼中，这很像自动填表。

这么理解不算错，但还不够完整。自动填表省的是打字；Myinfo 所做的远不止这些：

Myinfo 在取得同意后，传递经核实的声明。

因此，Myinfo 与 Singpass QR 登录同属一套信任基础设施。

QR 登录回答的是：“我怎样证明自己是谁？”

Myinfo 回答的是：“我怎样授权这项服务使用关于我的特定可信信息？”

这类常见的个人资料页面让用户很容易形成一个直观印象：个人信息分属若干易于理解的类别。Myinfo 真正发挥作用的地方在于，用户同意后，服务可以从中调取特定的经核实声明。

身份验证并不会自动带来个人信息链接到标题

身份验证告诉服务方当前用户是谁。但对许多业务来说，光知道这一点还不够。

银行可能需要身份和居住信息；保险业务可能需要人口统计资料和联系方式；政府申请则可能涉及家庭、就业或福利数据。如果 Singpass 只确认“这名用户已经登录”，用户仍得填写其余字段、上传文件，再等待核验。

更深一层的问题是，各家机构都在重复同一套核验工作。缺少可信的数据共享层，每个依赖方都不得不充当一个小型身份核验系统：收集文件、留存副本、逐项检查、纠正错误，并承担相应的数据风险。

Myinfo 之所以存在，是因为经核实的个人数据也应当纳入共享基础设施。

用户实际看到的是什么链接到标题

不妨把它直观地看成一张包含两类字段的表单。

用户点击“获取 Myinfo 数据”后，一部分字段会从获准使用的数据源调取，并应显示为调取的数据；其余字段仍由用户自行填写。

表单字段	获取 Myinfo 数据后有什么变化	为什么重要
法定姓名、出生日期、国籍、登记地址	从获准使用的政府或参与机构数据源调取，并按原样显示	服务方可以将这些信息视为经核实的声明，而不是用户刚刚输入的一段文字
CPF 缴交记录、估税通知书、家庭或车辆记录	只有依赖方获准申请且用户明确同意，才会调取	敏感信息按范围和用途流转，而不是一次性交出整份个人资料
电子邮箱、偏好的联系时间、配送说明、营销偏好	仍由用户填写或修改	并非每个字段都需要政府背书；有些信息只是个人偏好
数据源中缺失或已经过时的信息	用户可能需要联系源头机构更新，或改走不使用 Myinfo 的流程	表单不应悄悄将来自权威数据源的信息变成可随意修改的普通文字

所以，改变的不只是“填表更快了”。同一张表里既有经核实的声明，也有用户自行提供的信息，还体现了服务方可以接收哪些数据的政策决定。

共享的是声明，不是整份个人资料链接到标题

更恰当的共享单位不是“个人资料”，而是“声明”。

扫描 Singpass 二维码后，系统里发生了什么

Tue, 21 Jul 2026 08:29:11 +0800

你在笔记本电脑上打开一家银行的网站。

点击“使用 Singpass 登录”。

页面上出现一个二维码。

你打开 Singpass 应用，扫描二维码，核对服务名称，然后确认登录。网站随即知道可以让你登录了。

在用户眼里，整个过程简单得近乎不可思议：网页显示二维码，手机完成确认，浏览器接着登录。

但真正关键的问题是：

这个二维码究竟证明了什么？

答案不是“二维码里装着我的身份信息”。

设计得当的二维码登录，恰恰不该如此。二维码里不应包含你的 NRIC、姓名或个人资料，也不应放入长期有效的登录令牌。它只应是一份短期有效的邀请，请你完成一笔特定的身份验证事务。

用系统设计的语言来说：

二维码登录，不是把身份装进二维码。
它发起的是一项短期有效的挑战，
由可信的移动端凭据批准，
再交给网页端的登录会话使用。

这正是整个设计的核心。

这就是大家熟悉的表面体验：扫描或轻点二维码，就能登录。真正重要的是，这个二维码被允许代表什么、它会多快过期，以及手机上的批准最终会绑定到哪个浏览器会话。

二维码只是一道入口链接到标题

第一个常见误区，是把二维码本身当成秘密。

人们很容易以为，二维码携带着某种神奇的身份数据。毕竟，用户一扫码，浏览器就登录成功了。但如果仅凭二维码就能登录，那么任何看到它的人都可以复制、转发，甚至反复使用。

这样的设计非常危险。

更稳妥的做法，是让二维码只包含一个不透明的挑战标识：

qr_challenge_id = "看似随机、短期有效的标识符"

这个标识符本身没有多少意义。它指向服务器端的一条状态记录，而这条记录是在浏览器发起登录请求时创建的。

服务器掌握的信息包括：

哪个依赖方请求了此次登录
哪个浏览器会话正在等待
请求涉及哪些权限或操作
挑战何时过期
挑战是否已经被扫描、批准、拒绝、使用，或已经过期

二维码只是让移动应用向系统表明：

我正在回应这一次特定的登录尝试。

因此，二维码登录不能只做“生成二维码”这一步，后台还必须维护一个生命周期很短的状态机。

屏幕上的流程看似简单，底层却更接近这样：

已创建 -> 已扫描 -> 已批准 -> 已使用
 \-> 已过期
 \-> 已拒绝
 \-> 已取消

状态机之所以重要，是因为登录不是一个静止的页面，而是一笔横跨两台设备的交互事务。系统必须拒绝不安全的状态变化，例如：

已过期 -> 已批准
已使用 -> 已批准
已批准 -> 再次批准

重试、网络延迟或重复点击，都可能触发两次批准请求。但系统不应因此建立两个浏览器会话，也不应签发两个授权码。只有第一次有效批准可以生效。

为什么 Singpass 会成为国家信任基础设施

Tue, 21 Jul 2026 08:09:37 +0800

乍看之下，Singpass 只是一个登录系统。

打开政府网站，点击“使用 Singpass 登录”，扫描二维码，再在手机上确认，接下来就能继续办理事务。对用户而言，整个过程很简单，就像国家版的“使用 Google 登录”。

但如果从第一性原理出发，重新思考这套系统应当如何设计，很快就会发现：登录只是露出水面的一角。

真正的问题远比登录本身复杂：

一个国家怎样让居民证明自己的身份，
让各项服务信任这份证明，
让数据在本人同意的前提下流转，
同时确保整个过程安全、可审计？

这样一问，国家数字身份平台就不再只是一项身份验证功能，而成了公共信任基础设施。

我们熟悉的应用界面已经显露出这一点：Singpass 不仅用于登录，也正逐渐成为人们使用各类公共服务的可信入口。

假如没有 Singpass 链接到标题

不妨设想一下，如果 Singpass 并不存在。

每个政府机构、银行、医院、学校、雇主和公共服务部门，都要分别弄清几件大同小异的事：

这个人是谁？
对方真是自己声称的那个人吗？
此人有权执行这项操作吗？
此人是否同意分享这些资料？
日后能否查明并证明当时究竟发生了什么？

没有国家数字身份平台，每个机构都得自行解决这些问题。

居民要注册许多账户、记住许多密码，一遍遍上传身份证明，还要在不同表格中反复填写同样的个人资料。各机构则要自行搭建身份核验机制、保存敏感数据，并分别设计账户恢复流程。结果就是重复建设、办事受阻、风险累积。

国家数字身份平台之所以必要，正是因为身份从来都是一个共同问题。

第一项基础能力：身份锚点链接到标题

第一块基石，是稳定的身份锚点。

平台需要为每一位符合条件的居民建立持久的内部身份，但不应在所有场景中直接暴露国家身份证号码。更合理的做法，是使用内部用户标识符，而将国家身份标识符视为指向权威登记系统的敏感参考信息。

平台应掌握足以核验和表示个人身份的信息，却不应占有所有政府数据。

这个区别很重要。

国家数字身份平台应与移民、人力、税务、养老金、医疗等公共机构的权威数据源相连，但不能把各领域的数据全都收归自身。否则，它就会沦为一个无所不包的巨型中央数据库，不仅会扩大安全事件的波及范围，还会增加隐私风险和治理难度。

身份平台应充当信任层，而不是每一项事实的所有者。

第二项基础能力：身份验证器链接到标题

身份锚点只能说明某个身份确实存在，却不能证明此刻操作浏览器或手机的人就是这个身份的真正持有人。

这要由身份验证器来证明。

国家级平台不能只依赖密码。密码虽然人人熟悉，却容易被钓鱼窃取，也常遭重复使用，安全强度往往不足。严肃的身份平台需要提供多种验证方式，并划分不同的身份验证保障等级：

使用密码登录，满足基本访问需求
使用移动应用凭证，加强身份验证
通过二维码确认，实现跨设备登录
使用通行密钥或设备生物识别，实现无密码身份验证
通过人脸核验，处理高风险流程
用户失去设备访问权后，通过线下方式恢复账户

关键不在于“多支持几种登录方式”，而在于建立一套明确的身份验证强度模型。

浏览低风险页面，可能只需要较低等级的保障；访问医疗数据、签署法律文件、批准银行交易或恢复账户，则应满足更高的保障要求。这时就需要升级身份验证。

成熟的身份平台不会只问“用户登录了吗”，而会继续追问：“我们有多大把握确认操作者就是用户本人？这份把握足以支撑当前操作吗？”

第三项基础能力：身份联合链接到标题

如果平台只能用于自家网站，价值就十分有限。

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 工作流。

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

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

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

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

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

一期播客很长。

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

会议转写同样可能很长。

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

把内容变短

摘要承诺的正是这件事。

它减少篇幅。

删去重复。

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

看起来很高效。

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

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

我知道他们谈了什么。

知道大致结论。

也记住了几个要点。

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

摘要丢掉了：

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

摘要并没有说错。

它只是不够。

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

好的摘要保留了终点。

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

这正是问题的核心。

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

Tech on Armstrong Yan

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

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

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

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

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

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

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

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

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

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

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

看懂新加坡支付体系：从银行 App 到 SGQR、PayNow、FAST、非接触式支付与 NETS

先看全貌 链接到标题

用户层：银行 App、银行卡与二维码 链接到标题

SGQR：统一的二维码层 链接到标题

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

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

核心思路 链接到标题

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

共享 Myinfo，不只是自动填表

身份验证并不会自动带来个人信息 链接到标题

用户实际看到的是什么 链接到标题

共享的是声明，不是整份个人资料 链接到标题