首页

如果你住在新加坡，下面这些支付方式大概每天都会用到： 通过 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 的缩写。

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 不是另一套数据库。 它只是同一套仓库状态协议的便捷入口。 真正持久的记忆依然留在仓库里。 为什么聊天记录不适合充当数据库 链接到标题 聊天记录可以提供有用的上下文。

最近，我重新搭建了个人网站。出发点很简单： 继续把 Obsidian 作为私密内容的唯一可信来源，只从中挑选适合公开的笔记，发布到一个干净的个人网站上。 这篇文章与其说是 Hugo 教程，不如说是在讨论一个问题：私密知识库与公开网站之间的发布边界，究竟该怎么划定。 下面记录的是我最终采用的架构、做过的取舍，以及实际的发布流程。 文中的仓库名、URL 和网站页面都来自我自己的配置。如果你也想采用这套方案，请换成自己的 GitHub 用户名、仓库名、域名和导航结构。 最终，我搭出了一条从私密内容通往公开网站的发布管线： 它实现了这些效果： 我仍然可以在 Obsidian 里自由地写笔记。 私密目录结构永远不会暴露在公开网站上。 公开笔记可以用一条命令发布。 GitHub Pages 会自动完成部署。 为什么我没有直接从 Obsidian 发布 链接到标题 很多教程都建议直接发布 Obsidian 仓库里的内容。 但我没有这么做。 因为我的 Obsidian 仓库不只是写作空间，还是我的私密知识系统。 里面有这样的目录： 00-Inbox/ Projects/ Career/ 内部笔记/ 随想/ 如果直接从仓库发布，就会带来边界问题： 私密目录结构会出现在公开 URL 中 内部笔记的组织方式会随之暴露 写作时还要顾及发布要求，反过来限制笔记的组织方式 比如这篇笔记： 00-Inbox/Kafka 设计.md 最终可能对应这样的公开路径： /posts/00-inbox/kafka-design/ 我不希望公开网站照搬自己梳理思路时使用的内部结构。 因此，我加了一层中间边界：Publish/。 这个目录是可公开内容的一份干净投影。 最终架构 链接到标题 最终的架构将写作结构与发布结构分开了。 事实证明，这是整套方案中最关键的设计决定：私密仓库仍然可以围绕思考与整理来组织，公开网站接收到的则只有干净、适合发布的 Markdown。 第 1 步 — 创建 Hugo 网站 链接到标题 先安装 Hugo。

实现可以自动化，评估也可以自动化。但判断，始终只能由人来做。 这是“AI 原生软件工程”系列的第四篇。 本文接续上一篇：AI 原生软件工程（三）：软件即搜索。 第一篇追问，我们如何形成理解。 第二篇追问，我们如何获得正确性。 第三篇提出，软件正在变成一种搜索过程。 但有一个危险的误解，必须说清楚： 只要有智能体、验证框架和约束， 软件就能自行生产出来。 事实并非如此。 在第二篇里，约束帮助我们获得正确性。 在第三篇里，约束塑造了实现方案的搜索过程。 这一篇要继续追问：谁来为约束本身负责？ 谁来决定该优化什么， 该拒绝什么， 又有哪些东西从一开始就值得做？ 开始采用 AI 辅助的软件开发流程后，我注意到一个出乎意料的现象。 实现能力越强，判断反而越有价值。 起初，我觉得这有些反常。 AI 越强，人的决策不应该越不重要吗？ 结果恰恰相反。 实现不再是瓶颈。 方向才是。 氛围编程：好用，直到失控 链接到标题 大多数开发者都经历过这样的过程。 一开始，你只有一个简单的想法： 把 X 做出来。 AI 生成代码。 你稍作调整。 跑通了。 于是继续往下做。 一个个小胜利不断累积。 项目也渐渐变大。 直到某个时刻，问题突然一股脑冒了出来： 架构渐渐偏离原来的方向 抽象层越堆越多 调试越来越慢 对系统的信心彻底崩塌 系统依然能运行。 但已经没人说得清，它为什么能运行。 项目陷入一种奇怪的状态： 好像一切都能推倒重来。 却没有任何东西真正处于掌控之中。 我把这叫作氛围编程。 并不是因为 AI 不好。 而是因为，每一步进展都不再对应一个经过认真权衡的决定。 测试通过带来的错觉 链接到标题 面对这种问题，一个常见的回答是： 多加一些测试就好了。 我也这样做过。

AI 能生成代码。验证框架能检验行为。但理解由谁来建立？ 这是“AI 原生软件工程”系列的第一篇。 这个系列想追问一个更大的问题： 当 AI 降低了实现成本， 软件工程中还有什么是稀缺的？ 本文先从第一种稀缺资源谈起： 理解。 过去几个月，我一直在密集尝试 AI 辅助的软件开发方式。 不是自动补全。 也不只是把 AI 当作编程副驾驶。 而是一套由智能体主导执行的工作流： SPEC -> 约束 -> 验证框架 -> 智能体执行 -> 评估 -> 迭代 这段经历非常有意思。 借助它，我用自己并不十分熟悉的语言和框架交付了项目，开发速度也大幅提升。 做小项目时，简直像魔法。 可一到更大的项目，意想不到的情况发生了。 我发现，实现速度和系统理解并不是一回事。 最后，我不得不面对一个让人不太舒服的事实： 如果 AI 明天消失， 我可能很难继续开发自己系统里的某些部分。 这个认识改变了我看待软件工程的方式。 传统模式：在实现过程中形成理解 链接到标题 过去的软件工程，大致是这样的： 人 -> 编写代码 -> 建立心智模型 -> 运行和维护系统 写代码不只是为了实现功能。 它也是学习系统的过程。 我们在这些事情中逐渐弄懂系统： 调试 重构 追踪执行过程 与各种约束周旋 犯错 亲手实现，自然会带来理解。 只是过去，我们未必意识到这一点。 智能体编程改变了路径 链接到标题 有了 AI 编程，整个循环变了。