写了大半辈子技术文档，我一直用“教程 + 例子 + FAQ”那一套教别人用 API/SDK，后来又加了 AI skill，可还是不够直观。这篇聊聊我的反思：AI 时代的软件教程，应该是可交互、可执行、有 AI 随时答疑纠错的“活教程”——sandbox 演示 + 类 Notebook 的边看边跑 + AI 助教，能把市面上大多数静态教程甩开一条街。

为什么 Claude Code、Codex 这些编码 Agent 感觉比“裸模型”聪明得多？秘密不在模型参数里，而在模型外面那层叫 Harness 的壳。这篇翻译并解读 Lilian Weng 2026 年 7 月的长文《Harness Engineering for Self-Improvement》：什么是 Harness、三大设计模式、优化路线图（上下文工程→工作流→自我改进→进化搜索→权重联合优化）、七大未来挑战，以及我作为一个后端老兵的解读。

与其一个个手搓专业 AI Agent，不如造一台"孵化器"——一个父 Agent，听你一句大白话，就快速孵化出贴身服务某类需求的子 Agent。这篇聊聊这台"AI Agent 制造工厂"的运转机制：父 Agent 怎么把自然语言编译成五份产品图纸（角色/工具/规矩/提示词/验收），照着标准模板批量生产，再让子 Agent 用 ReAct 边想边做。以日程安排专家作为流水线上的第一个样品。

我以前有位高级 QA 老同事：每次 Design Review 之后，她都会拿出一整套验收用例，没通过就别把软件包交给她。如今我们已经不是同事，我却把她的质量纪律“蒸馏”成了 qa-acceptance-harness，并配上 lazy-harness-audit 和 lazy-harness-helper：先定义什么叫做对，再用证据验收、审计和改进 AI 编码护栏。

承认能力、机会和时代的边界，不等于向平庸投降。古人的“立德、立功、立言”和“横渠四句”，放到今天，也可以从普通人的责任半径做起：护住家人，做好手里的事，留下一点对别人有用的东西。

AI 写代码越来越快，还会推理、能给出好几套方案，很多人以为软件开发那点"难"终于要被抹平了。重读 Ousterhout 的《软件设计的哲学》，我越发确信：AI 干得了参谋，列得出选项，却还挑不出"最适合你这个系统"的那一个。复杂性不是被消灭，而是成了 AI 能帮你走多远的天花板——它反而让"判断与拍板"这件事更值钱，而不是更没用。

传统 RAG 把文档切碎成 chunk 各自嵌入，遇到"多个实体互相牵连"的问题就抓瞎。GraphRAG 用知识图谱补上了关系，却贵得离谱、更新一次能烧掉几百万 token。这篇精读港大与北邮的 LightRAG 论文（arXiv:2410.05779），先把传统 RAG 的老毛病摊开，再拆 LightRAG 的图索引 + 双层检索 + 增量更新，最后落到一张选型对照表。

一份 MySQL 数据库设计评审清单，我把它拆成"建表""查询""特殊约束"三块，并逐条讲清楚背后的原因——为什么禁自增主键、为什么禁外键、为什么用 DATETIME 不用 TIMESTAMP、为什么少碰 JSON 和大字段。规则好背，难的是知道每条规则在防哪个坑。文末附一份可直接抄的自查清单。

想让 AI Agent 调用你已有的服务，眼下有两条主流路子：包成 MCP Server，或者包成一个 CLI 让 Agent 去 shell 里跑。这篇用 Python 和 MySQL 官方示例库 Sakila（查客户租片记录）做例子，把两者的技术细节、协议差异、部署形态、鉴权与安全边界摊开对比，最后给一张选型对照表和一份落地清单。

2017 年 AWS 一个工程师敲错一条命令，让小半个互联网黑屏四小时；Knight Capital 一次没同步好的部署，45 分钟烧掉 4.4 亿美元。服务治理的本质是工程问题：能自动化的规则、约束、检查、测试，就别指望人半夜手动去跑。清单革命固然好，但清单要人看、人执行，而人从来不是百分百可靠的。这篇聊聊业界的标准、最佳实践、成功案例和典型事故。

傲气是看不起人，傲骨是看得起自己。顺势而为没错，但守住的原则和气节不能拿去换。这篇聊聊：为什么当你觉得"非我莫属"、别人偏不给你时，那多半不是你的问题，以及一个普通人怎么把傲骨落到实处。

人生一个个十字路口，我常常徘徊彷徨、踟蹰不前，想不清楚也做不了决定。后来慢慢琢磨出两条：先弄明白自己到底想要什么，再审时度势、顺势而为。上赶着不是买卖，勉强来的东西留不住。

做了这么多年后端和 WebRTC，绕不开密码学，可真要系统学起来又觉得无从下手。这篇按"该知道什么、从哪入手、哪些值得深挖、哪些书值得反复读"四条线，给一个不吓人也不糊弄的密码学学习地图。

Streamlit 让你用写 Python 脚本的方式,几十行就做出一个能交互的数据应用——不碰 HTML/CSS/JS,不起前端工程。这篇讲清楚它背后"脚本从上到下重跑一遍"的设计理念,常用控件与状态管理,一个能跑的完整实例,以及我踩过坑之后总结的最佳实践。

做后端和 SDK 这些年，我越来越依赖一个东西：给每个服务配一个能把主流程完整跑一遍的 Sample App——Web Service 就配个 Test Web App，音视频应用就配个 Native App。它既是 E2E 测试工具，又是一个"永远在线的模拟用户"，还是最诚实的一份活文档。AI 能帮你把它写得飞快，但要不要养、往哪个方向养，得你自己拿主意。

有的人解决问题像打地鼠，这个坑填上，下个坑又冒出来。真正拉开差距的，不是记住多少答案，而是能不能把一类问题的成因、解法和取舍一次性想透。这篇聊聊我这些年反复用的一套笨办法：分类、穷尽、对比、取舍。

明知该做，就是不想动，眼看 deadline 变成头上的达摩克利斯之剑，心理负担越来越重，却越拖越凶。研究过无数克服拖延的方法，也天天告诫自己知行合一，可"臣妾就是做不到"。这篇不劝你自律，而是想聊聊：为什么方法没用，以及怎么把"启动成本"降到你抬手就能做的地步。

有一次我认真读完一段完全由 AI 生成、且已经跑通的代码，越看越心惊。冷静下来复盘：一部分不能全怪 AI——我的 design 本来就没说清楚；另一部分确实是 AI 的锅。结论很简单：想把 AI 的改动用到产品线上，你必须收紧缰绳，用"人机接力"的流程，主要功能代码逐行看、验收测试亲自做。因为 AI 不会替你背锅，为最终结果负责的人是你。

人难免懈怠、偷懒、迷茫。真正成熟的自律，不是永远靠一个人硬扛，而是主动设计协作、反馈和承诺，让团队、朋友和同事在关键时刻推你一把。

写给站在人生十字路口的青年朋友：路窄时不要急着否定自己，真正的勇敢是先稳住，再学习，再行动。