L114_设计细节与AI工具
这周有个发现让我挺意外的。
带朋友去 OPPO 线下店看折叠屏，本来是想让他体验一下折痕控制得怎么样。结果他拿起 Find N6，第一眼注意到的不是屏幕素质，而是壁纸中央那个不断跳动的数字——每折一次，数字加 1。
「这台已经被折了 3000 多次了？」他问我。
我说是展示机，专门用来证明耐用性的。他把手机展开又折上几次，看着数字从 3127 变成 3130，点了点头：「那确实挺耐用的。」
OPPO 没有说「我们的铰链经过了 XX 万次折叠测试」，而是直接把测试过程做成了产品体验的一部分。你不是在看广告，是在亲手验证一个事实。
为什么有些信息，「让人看见」比「告诉对方」更有效？
戴森 V15 吸尘器的绿激光是另一个例子。他们本可以像其他品牌一样，在广告里放一张吸力参数的对比图。但他们选择在吸头上装一个绿激光发射器，让肉眼看不见的灰尘在地板上显形。
第一次用的时候，那个画面挺冲击的——你以为刚拖干净的地面，在绿光照射下突然变成了「星空」，全是细小的灰尘颗粒。推着吸尘器走过，看着光点一个个消失，那种「我真的把地吸干净了」的确定感，是任何参数都给不了的。
这两个产品做了一个相同的选择：把证明过程变成体验本身。
传统的逻辑是，产品在实验室做一万次测试，然后告诉消费者「很耐用」。更好的做法可能是——让消费者自己看到这一万次。不是说服他们相信，而是让他们自己得出结论。
📚 深度阅读
2026，写给 AI 创业者的慷慨、残酷、与迷雾
这篇文章触动我的不是成功案例，而是作者对「范式转移」的描述。
Devv.AI 创始人加元在文章里提到，Andrej Karpathy 在 3 个月内，从 80% 手写代码变成了 80% 指挥 AI agent 写代码。转变的速度，比大多数人预期的要快。
但这引出了一个更深层的问题：当写代码本身变得廉价，什么变得珍贵了？
作者给出的答案是三种能力：问题拆解能力（把大目标拆成 AI 能执行的步骤）、品味和判断力（在 AI 生成的多个方案中选出最好的）、系统设计思维（把多个 AI 组件组合成可用的产品）。
未来的程序员会更像「指挥官」——不需要记得所有语法细节，但需要知道如何让多个 AI 协作完成复杂任务。
十年前学编程，花大量时间背语法、记 API、练算法。现在这些「硬技能」正在快速贬值，取而代之的是更「软」的能力：如何描述问题、如何判断好坏、如何设计系统。
机器处理「执行」，人类腾出手做更有创造力的事。
2016 年，我做过一次 AI 写代码创业
这篇文章让我想起了那句话：「时机比方向更重要。」
作者在 2016 年就尝试过用 AI 写代码创业，比 ChatGPT 早了整整 6 年。当时的技术不够成熟，项目没能成功。现在回头看，方向是对的，只是时间不对。
「如果你真的相信一件事能成，那么应该每过五年就试一次。」因为技术在发展，环境在变化，5 年前的「不可能」可能变成现在的「刚好」。
作者现在已经切换到完全依赖 Agent 工作的模式。他提到一个体会：进入心流状态的难度变高了，但现阶段工具会奖励思维更发散的人。
传统的编程很容易进入心流——专注于代码，一行行写，一步步调试，时间不知不觉就过去了。但用 AI 编程的过程更碎片化：描述需求、看 AI 生成、判断好坏、给出反馈，然后重复。这种「指挥-评估」的模式，和「执行-调试」的模式，是完全不同的心智状态。
也许未来的「高效」，不再是长时间专注于一件事，而是在多个任务之间快速切换、判断、决策。
🔗：地心引力
保姆级教程！手把手教你写出好用又安全的专属 Skill
这篇教程的实用价值很高，但更值得思考的是它背后的方法论。
作者提供了一个结构化的 Skill 编写框架，包含 9 个核心模块：Goal（目标）、When to use（触发条件）、Do not use（排除条件）、Inputs to collect（需要收集的信息）、Procedure（执行步骤）、Output format（输出格式）、Definition of done（完成标准）、Failure handling（异常处理）、Additional resources（配套文件引用）。
这个框架的聪明之处在于，它把「写 Skill」这件事从「凭感觉」变成了「填空题」。每个模块都有明确的问题，回答完 9 个问题，一个完整的 Skill 就出来了。
当 AI 可以处理越来越多的执行工作时，人类的角色正在从「做事情」变成「定义事情」。而「定义事情」的前提，是你能清晰地描述：要做什么、不要做什么、怎么算完成、出问题怎么办。这些恰恰是传统工作中最容易被忽略的部分——我们习惯了边做边想，遇到问题再解决。
但 AI 不会「边做边想」。它需要一个完整的、明确的、可执行的指令。写 Skill 的过程，其实是在强迫人类把模糊的想法结构化、清晰化、可验证化。这个过程本身就是一种训练。
文章还附带了一个 skill-interview-builder 工具，通过 12 个问题的分步访谈引导用户理清需求。大多数人其实并不清楚自己想要什么。他们需要被问到具体的问题，才能慢慢理清思路。
🔗：优设网教程
🤖 AI 工具
Pi Mono：最小 Agent 框架
Pi Mono 是一个用于构建 AI Agents 的 TypeScript Monorepo 工具集。它的价值在于提供了一个「从零开始构建 Agent 系统」的完整路径。
它包含几个核心包：统一多提供商 LLM API 的 pi-ai、交互式编码 Agent CLI 的 pi-coding-agent、Slack Bot 的 pi-mom、管理 GPU Pods 上 vLLM 部署的 pi-pods。
这个架构体现了一种工程思维：把 Agent 系统拆分成独立的、可组合的模块。每个模块只做一件事，但做好。然后用 Monorepo 的方式管理，保持版本一致。
更值得关注的假设是：未来的 AI 应用，可能不是「一个强大的通用 Agent」，而是「多个专门化 Agent 的组合」。
这和当前主流方向有点不同。现在大家都在追求「一个能做任何事的超级 Agent」，但 Pi Mono 选择了一条更「Unix 哲学」的路：小而美、专而精、可组合。
哪条路是对的？可能两种都对，适用于不同的场景。但对于想深入理解 Agent 系统的人来说，Pi Mono 提供了一个很好的学习材料——你可以看到每个模块是如何设计的，它们之间如何交互，以及如何组合成一个完整的系统。
🔗：GitHub
🛠️ 效率工具
Tropes：辨识 AI 写作的必备工具
Tropes 的存在本身就说明了一个反直觉的现象：当 AI 生成内容变得越来越容易时，能写出「不像 AI」的内容反而成了一种竞争力。
这个工具整理了一个目录，专门列出 AI 写作的常见模式——句式结构、用词习惯、过度使用的短语等。初衷是帮助读者识别「AI slop」，但换个角度看，它其实是在做一件更重要的事：定义什么是「不像 AI」的写作。
AI 写作倾向于「平均」。它会选择统计上最可能出现的词、最安全的句式、最不会出错的结构。这种「平均」让内容读起来「还不错」，但也失去了个性。
真正的写作，往往是「不平均」的。它可能有奇怪的断句、不寻常的用词、出人意料的转折。这些「不完美」恰恰是「人味」的来源。
🔗：Tropes
Rantbase：从差评中挖掘灵感
Rantbase 不做「好评推荐」，而是专门抓取 App 的差评，自动识别用户反馈中的痛点和缺失功能。
好评往往是相似的——「好用」「推荐」「五星」。但差评是具体的：「这个功能找不到」「这里会闪退」「希望能支持 XX」。差评里藏着真实的用户需求，而这些需求在好评里往往被掩盖了。
对于开发者来说，Rantbase 是一个用户研究的捷径。你可以快速了解竞品的问题在哪里，用户最不满意的是什么，市场上还有什么需求没有被满足。
「逆向思维」：不是看「什么东西好」，而是看「什么东西不好」。在商业上，这种思维方式往往能带来差异化的洞察。
🔗：Rantbase
有数：个人资产管理
有数解决了一个问题：帮你算清楚「拥有」一件东西的真实成本。
核心功能是「日均成本」计算。买了 8799 元的 iPhone，用了 999 天，每天成本 8.8 元。计算看起来简单，但带来的认知冲击不小。
我们买很多东西的时候，关注的是「购买价格」，而不是「使用成本」。购买价格是一次性的，使用成本是持续性的。用 999 天和用 300 天就换掉，每天的成本差别很大。
这个工具逼你回答一个问题：你买的东西，真的用回本了吗？
对于那些「买了就后悔」或者「买了就吃灰」的东西，有数可以帮你建立更理性的消费习惯。当然，不是所有东西都能用「日均成本」来衡量——有些东西的价值在于「拥有」本身，而不在于「使用」。但作为一个思考工具，它是有价值的。
🔗：有数 App
✨ 随便看看
- Loftlyy 品牌指南资源库：收录 64 个品牌的颜色、字体和标志资产，支持逆向搜索相似品牌 链接
- 3d icons：1400+ 个精美无版权 3D 图标，适用于个人和商业项目 链接
- AIChatIndex：为 ChatGPT、豆包、KIMI 等生成目录导航，帮助快速回溯长对话 链接
- 腾讯电脑管家推出龙虾管家：首个针对 OpenClaw 的安全管家，保护 Skills、监控脚本和端口安全 链接
- Jina AI：网页转 Markdown 服务，推荐用于 AI 读取网页内容 链接
- Claude Use Cases：Claude 在金融、非营利组织、教育等领域的实际应用案例库 链接
The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.
由WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。
本文首发于Why·Liam·Blog (https://blog.naaln.com)，版权所有，侵权必究。
本文永久链接：https://blog.naaln.com/2026/03/newsletter-114/