家附近有一个叫 35mm 的咖啡馆，以前经常去，某天心血来潮就想，会不会 35mm.coffee 正好是个可以注册的名呢？就上 Cloudflare 上看了下，果然可以，于是就注册了。即然注册了，就想着拿来做点什么，一开始把使用地限制在了 35MM 咖啡馆，也就是只有在那里才能使用，后来又将它改造成了只有晚上才能访问的网站，之后去掉了时间限制，改成可以随时访问的小 Twitter，还是不满意，总觉得少了一个明确的主题。

我是一个创作者，平时喜欢做点小东西，也会接触很多创作相关的内容，但总有种孤独感。回想起一开始入行的时候，学的是 ActionScript，那时经常逛一个论坛，氛围挺好的，自己写了一个什么小程序，或者学到了什么都会在那里分享，也从那里学到了不少，在交流过程中也结识了一些志同道合的朋友。

现在论坛已经成了过去式，创作者能逛的地方更多了，小红书、微博、推特、V2EX、知乎等等，但好像都没有特定主题的社区那种特有的氛围，也少了那种相对深入的、持续的、互相启发式的交流。Discord 其实蛮适合的，但它的封闭性和糟糕的桌面端是很大的问题。我开始思考，35mm.coffee 这个域名，是不是可以成为一个契机，重新找回那种失落的连接感，让它成为一个能让创作者们找到共鸣、答疑解惑、分享经验、甚至共同创作的地方？

35mm 代表着胶片时代经典的视角，一种记录真实、捕捉瞬间的工具。对于创作者而言，我们其实也正是在用自己的方式，记录着、捕捉着这个世界。

在这里，你可以：

• 分享你的「胶片」： 无论是你刚完成的一个小项目，一段在创作中遇到的瓶颈，还是一闪而过的奇思妙想，都可以分享出来。也许你的一个困惑，正是别人曾经走过的路；你的一个灵感，也能点亮别人的火花。
• 品味「咖啡」的醇厚： 针对某个特定主题，可以发起深入的讨论，比如「如何平衡商业与艺术创作」、「AI 工具对创作流程的影响」、「寻找个人风格的路径」等等。
• 寻找你的「曝光」： 晒出你的作品，无论是草稿、半成品还是最终成果。
• 建立「暗房」般的连接： 也许你会在这里找到志同道合的伙伴，一起发起一个协作项目，或者只是单纯地分享彼此的创作日常，互相打气。

最后，希望这个小站能重新找回那种失落的连接感，让创作之路不再孤单。

大概 4 年前，我注册了一个域名 before.town，因为脑海中忽然闪过「避风塘」，好像正好可以对应英文的 before town，而 town 又可以作为域名的后缀，就搜了一下，果然可以注册，就毫不犹豫地下手了，这一放就是 4 年。

生活中，总是会有一些瞬间，让我们忍不住拿起手机记录下来，但其实也没有太 Special，这些照片你想与别人分享，但好像又不够精致到值得发个朋友圈或 Instagram，于是就只能默默地住在相册里。我有时会想，这些照片它们会不会也想有一个出口呢？

「避风塘」的概念和这些照片好像挺契合的，带着这个想法，我决定让 before.town 成为这些「不够精致」但充满生活气息的照片的避风港。

它不是一个追求完美构图和滤镜的平台，更像是一个数字化的「避风塘」，让那些在主流社交媒体中找不到位置的照片，能够在这里找到一个安静的角落。你可以在这里分享你随手拍下的街角风景、一杯咖啡的特写、或者只是一个不经意的瞬间。它们可能没有华丽的辞藻来描述，也不需要精心的排版，但它们都带着你生活的温度和独特的视角。

最后，欢迎来避风塘分享你的日常 🙃。

前几天在看跑男，有一个游戏环节是这样的：嘉宾通过努力得到一个笔画，目标文字中如果包含该笔画就会出现。感觉挺有意思的，对它稍加改造，于是就有了这个小游戏：笔画猜成语

游戏机制是这样的：

• 初始显示 20% 的笔画作为提示
• 每隔一分钟会多 10% 的笔画，最多显示 50% 的笔画
• 总共有 5 次猜测机会
• 新题每日更新

和周围的人玩了下，还是挺有乐趣的。如果你也感兴趣的话，可以在这里体验哦。

TL;DR

• 工欲善其事，必先利其器：选对工具至关重要，目前 Claude Code (CC) 在代码理解和生成质量上相比 Cursor 表现更优。
• 人机协同新范式：Vibe Coding 能极大提升开发效率，但需要掌握新的协作技巧，否则可能事倍功半。
• 能力圈的重塑：AI Agent 的崛起正在改变传统的编程模式，迫使程序员更新自己的核心能力圈，将重心从具体实现转移到更高层次的架构设计和战略规划上。

---

最近，我通过 Vibe Coding 的方式完成了三个个人项目：

• 五子棋：一个功能完善的网页五子棋游戏。
• 笔画猜成语：一个根据汉字笔画顺序猜成语的互动游戏。
• 歌曲转视频脚本：一个能自动为日文歌曲的歌词和单词注音并翻译，最终生成视频的学习工具。

在开发「五子棋」时，由于初次尝试 Vibe Coding，经验不足，踩了不少坑，但最终坚持了下来，算是摸到了一些门路。有了此前的经验，做「笔画猜成语」时更加得心应手，效率也大幅提升，大约只花了 3 天时间，就将一个模糊的想法变成了一个功能完整的 Web App。而「歌曲转视频」项目，更是在 2 个多小时内就产出了可运行的核心脚本。

Vibe Coding 工具的选择

我最初使用 Cursor，但在看到越来越多的人推荐 Claude Code（以下简称 CC）后，决定一试，结果确实令人惊喜。我的习惯是在 Cursor 的终端里打开 CC，这样 CC 可以直接访问当前项目的文件上下文（当然，在独立的终端里使用也完全可行）。

通过两个简单的例子就能看出 CC 与 Cursor 的能力差异：

1. 重构组件属性：我让 Cursor 移除一个 React 组件中未使用的属性。它的做法是给这个属性一个别名，在前面加上下划线 _，以此「欺骗」编译器，绕过检查。当我追问该属性是否无用时，它才承认并将其删除，但却忽略了检查调用该组件的其他地方，工作只完成了一半。我撤销修改后，将同样的指令交给 CC，它一次性就完美地完成了任务，干净利落。

2. 代码结构优化：在开发五子棋的禁手功能（黑棋不能走出三三、四四或长连）时，我有一个核心的协调文件 gomoku-ai.ts。Cursor 的做法是直接将禁手判断的复杂逻辑堆砌到这个协调文件中。而 CC 则展现了更优秀的设计能力，它创建了一个独立的 forbidden-move.ts 文件，专门用于封装所有禁手检测的逻辑，再由 gomoku-ai.ts 进行统一调度，使得代码结构更清晰，职责更分明。

类似的例子还有很多，这让我越来越依赖 CC。Cursor 更像一个初级程序员，优先考虑完成当前任务，对代码质量、复杂度和可维护性的考量不足，倾向于「能加代码就不改代码」。而 CC 在理解意图、分析代码结构以及构建更优代码方面表现更强。当然，它也并非完美，有时也会在「奋战」十分钟后报告任务完成，但却没有解决问题。

Vibe Coding 实用技巧

我喜欢将 Coding Agent 比作一匹马，这能强化我们对其「驾驭」和「驯服」的过程。不同的马有不同的脾性与能力（所以摸清每个 Agent 的能力圈很重要），选择一匹既强大又易于驾驭的马，才能事半功倍。以下是我总结的一些通用技巧：

1. 精准的目标分解

在开发五子棋 Web App 时，我犯了一个错误。在 v0.dev 上设计好页面后，就把整个实现任务直接丢给了 Agent，以为五子棋算法早已成熟，AI 肯定了然于胸，加上最终的目标界面，应该很快就能做完，结果却不尽人意。

我耐着性子，以产品经理和 QA 的身份不断提出修改意见。噩梦从此开始：AI 修复一个 Bug 的同时，往往会引入新的 Bug，或是让之前修复过的问题重现，陷入「按下葫芦起了瓢」的循环。

检查代码后我发现，AI(当时使用的还是 Cursor) 写的算法冗长复杂、职责不清，上百个测试用例中充斥着大量敷衍了事的断言（比如只检查返回值是不是布尔类型，而不关心是 true 还是 false）。基于这样的代码迭代无异于在沙地上盖楼。

最终，我决定放弃原有算法，从一个成熟的开源项目中剥离出经过验证的五子棋算法，然后让 CC 将其整合进现有项目——相当于给汽车换了个引擎，问题迎刃而解。

吸取教训后，在做「笔画猜成语」时，我首先对目标进行了细致的拆解。

如图所示，页面的核心是成语笔画展示区。这意味着我需要一个组件，它能接受一个汉字和对应的笔画序号，并使用 SVG 数据将其绘制出来。我的第一个子任务就是寻找一个合适的汉字笔画库，并让 Agent 基于这个库构建出核心组件。

任务分解还能带来意想不到的好处：掌控感、大局观和节奏感。

• 掌控感：每个任务都足够小，Review 起来更轻松，可以始终保持对代码的掌控。
• 大局观：你清楚每个子任务在整个项目中的位置，对整体进度了如指掌。
• 节奏感：一个接一个完成任务会带来持续的正反馈，推动项目稳步前进。

2. 提供关键输入（Input）和认真审查（Review）

Agent 并不总能选择最佳实现路径，如果不加干预，可能会在错误的方向上浪费大量时间和 Token。例如，在生成带注音和翻译的歌词图片时，我希望实现这样的效果：

CC 最初的方案是使用 sharp 配合 canvas 绘制，这不仅实现复杂，效果也未必理想。此时就需要人为干预，我给出的策略是：利用无头浏览器渲染一个包含 ruby 标签（HTML 原生支持注音）的页面，然后对该页面进行截图，这个方案更简单、效果也更好。

Review 同样至关重要，尤其是在商业项目中。在做「笔画猜成语」时，我要求每天提供一个固定的新成语。Agent 实现时用了一个简单的哈希算法，导致每天的成语都非常相近（如昨天是「坐享其成」，今天是「坐井观天」）。如果没 Review，这个问题可能只有上线后才能发现。我让它改进，它又手动实现了一个伪随机算法。我再次给出 Input，让它使用 seedrandom 这个成熟的库来确保高质量的伪随机性。

3. 及时干预

如果 CC 尝试了 5 次左右仍未完成任务，或者在执行一个明确的任务时消耗了大量时间却最终失败，就需要立即干预。这通常意味着任务粒度过粗、描述不清、AI 的策略有问题或者当前项目复杂度太高。 如果任务分解地很好，这种情况发生的概率不高，但一旦发生，很有可能会把之前节省下来的时间都还回去···。

4. 善用计划模式（Plan Mode）

CC 支持一个非常实用的「计划模式」。在执行一个有难度的任务前，可以让它先拟定一份行动计划。只有在你确认计划可行后，它才会开始实施，这极大地提高了复杂任务的成功率。

5. 拥抱软件开发的最佳实践

过去，我们常因耗时费力而忽略一些重要的开发实践，如编写测试或使用 Storybook。但现在，Agent 以其不知疲倦的特性，让这些「最佳实践」的落地变得轻而易举。测试驱动开发（TDD）等过去只存在于书本中的理念，现在完全可以在 Agent 的协助下融入日常开发流程。

6. Agent 的一些通病

• 需求理解偏差：不太会主动确认需求，往往按自己的理解埋头就做。
• 有「偷懒」倾向：为了完成任务可能会走捷径，例如引入 Magic Number、硬编码等。
• 代码审美有限：对复杂度和代码整洁度的认知不足，尽管 CC 已比多数同类工具要好。

Vibe Coding 带来了什么

Someday -> Today

「日文歌曲转成带翻译的视频」这个 Project 我其实酝酿了蛮久的，如何实现也有大概的思路，但一想到要手动去实现里面的代码，要去熟悉 ffmpeg 的调用，还是会下意识地去拖延。但 CC 大大降低了我创建这个项目的阻力，虽然还是需要花一点时间描述清楚这个项目，对其进行分解，但相比自己去实现已经方便了很多。

我还记得当时是 10 点左右，我想测试下「笔画猜成语」在 0 点时能否正常切换到新一天的成语，既然还有两个小时，不如就来做这个项目吧，结果真的在 12 点多，就把它做出来了。

这便是 AI Agent 的魅力，它将那些看似遥不可及的「Someday」，变成了触手可及的「Today」。 那些曾经因为技术门槛、因为预想中的繁琐而搁置的想法，如今有了一个快速验证的通道。从一个模糊的概念到看得见、摸得着、能分享给朋友的作品。

程序员能力圈的重塑

在这个访谈视频中，极限编程（XP）之父、《测试驱动开发》作者 Kent Beck，一位拥有 52 年编程经验的传奇程序员，分享了他对 AI 时代程序员能力转变的看法。他将 AI 编程工具比作一个「难以预测的精灵」 [06:44]，它能实现你的愿望，但结果未必如你所想。

他的一段话精辟地总结了 Vibe Coding 「迫使」程序员做出的改变[01:12:42]：

I had this tweet two years ago where I said “90% of my skills just went to zero dollars and 10% of my skills just went up 1000x”. And this is exactly what I’m talking about - having a vision, being able to set milestones towards that vision, keeping track of a design to maintain or control the levels of complexity as you go forward. Those are hugely leveraged skills now compared to knowing where to put the ampersands and the stars and the brackets in Rust.

我两年前的一条推里说「我的 90% 的技能价值归零，而 10% 的技能价值增长了 1000 倍」。这正是我所说的——拥有一个愿景，能够为这个愿景设定里程碑，并在前进过程中跟踪设计以控制复杂性。与知道在 Rust 中如何放置符号和括号相比，这些才是现在被极度放大的核心技能。

这里的「迫使」是积极的。Agent 的出现，将程序员从繁琐的具体代码实现中解放出来，让我们能像 Kent Beck 所说的那样，去思考「真正宏大的想法」　 [01:13:36]。我们的核心竞争力不再是写代码的速度或对语言语法的熟练度，而是产品感、架构能力、任务拆解能力和战略眼光。

编程的本质正在回归——将复杂的问题，分解成计算机可以理解并执行的简单步骤。只不过这一次，我们操作的「计算机」拥有了更强的理解力和执行力。这要求我们站得更高，看得更远，专注于创造真正的价值。

昨晚在看特雷弗·诺亚的《天生有罪》，开篇的一段话是这样的：

其中最明显的裂隙存在于南非两大主要的部落之间，祖鲁和科萨。祖鲁人是公认的战士。他们很骄傲，会拼尽全力去战斗。殖民者的军队入侵时，祖鲁人拿着长矛与盾牌就冲上了战场，和对面拿着枪支弹药的敌人血拼。上千名祖鲁人死在了战场上，但是他们从未停止过战斗。和祖鲁人截然不同的是，科萨人一直以头脑灵活而自豪。我的母亲是科萨人。纳尔逊·曼德拉也是科萨人。科萨人也与白人进行了漫长的战争，但是在对手武器装备遥遥领先的情况下，科萨人感受到了武力战争的徒劳，于是一些科萨首领采取了一种更机智的手段。‘不论我们喜不喜欢，这些白人都已经在这儿了，’他们说，‘我们来看看他们都有什么长处是我们可以用得上的。与其抵抗他们的语言，不如我们来学学英语。这样我们就能明白他们在说什么，然后迫使他们与我们谈判。’

我忽然想到，这段历史的镜像，还挺像我们与「智能手机」的关系。智能手机，就像当年那些无法阻挡的「白人」一样，携带着压倒性的技术优势，闯入了我们的生活。它强大、迷人，以「便利」和「连接」为名，迅速重塑了世界的样貌。

起初，我们都曾为之兴奋和着迷。它打破了信息壁垒，延展了我们的感官，赋予了我们前所未有的可能性。但慢慢的，我们也感受到了「被殖民」的代价：注意力被无情收割，时间被碎片化，深度思考的能力逐渐退化，真实的人际关系被虚拟互动所稀释。 我们开始焦虑、疲惫，发现自己非但没有成为生活的主人，反而沦为了算法的奴隶。

面对这种困境，我不自觉地成为了「祖鲁人」：感受到了威胁，于是选择了直接对抗。这种对抗体现在行为上，是尝试各种「数字极简主义」，卸载App，甚至想换回功能机；体现在心态上，则是对智能手机持一种否定和批判的态度，视其为洪水猛兽，认为它是一切问题的根源。这种「战斗」的姿态虽然悲壮，但收效甚微，因为它违背了我们生活于世的现实。更重要的是，这种全然的抵抗，也让我关闭了探索其正面潜能的大门，比如，我因此失去了在它上面开发App、创造价值的兴趣。

科萨人的智慧给了我新的启示。当物理上的抗争显得徒劳，他们没有选择玉石俱焚，而是转向了一种更高级的策略：理解、学习、为我所用，最终与之「谈判」。

现在，我想成为一名数字时代的「科萨人」。这意味着我需要从根本上转变我的 Mindset：

1. 接受现实，放弃幻想： 首先，坦然承认智能手机已经成为我们社会和生活的基础设施，它不会消失，只会在形态和功能上不断进化。指望通过彻底的「断舍离」来一劳永逸地解决问题，是一种不切实际的幻想。

2. 「学习它的语言」： 「科萨人」选择学习英语，我们则需要去理解智能手机背后的运行逻辑。这不只是学习如何操作App，更是要去了解推荐算法如何工作，通知系统如何设计来吸引你的注意力，商业模式如何依赖你的使用时长。只有理解了它的「语法」，才能识破那些让你无意识沉迷的「圈套」，从被动的接受者，转变为清醒的观察者。

3. 利用它的长处： 智能手机并非纯粹的「恶」。它是极其强大的工具，关键在于为谁所用。我们可以用它来学习新知识、管理健康、高效工作、进行深度创作、维系远方的亲情。关键在于，你要主动定义你使用它的目的，而不是被它预设的功能所定义。 这需要我们从「消费内容」的心态，转向「运用工具」的心态。

4. 划定边界，与之「谈判」： 接受不等于放任。「科萨策略」是用对方的规则来与之周旋，为自己争取最大的利益。我们可以主动设计自己的数字环境：关闭非必要通知，设定App的使用时限，规划固定的「无手机时间」，策划能带来真实满足感的线下活动等等。这不是在「抵抗」手机，而是在与它「谈判」，重新夺回生活的主导权。

这里最重要的转变在于责任归属。如果一个人因为饮食过量而损害了健康，我们会认为是这个人的自制力出了问题，而不是食物的错。同样，如果一个人因为过度使用手机而让自己偏离了理想的人生轨道，这终究是Ta需要面对和解决的个人课题，而非手机的原罪。

成为数字时代的「科萨人」，意味着不再将自己置于科技的对立面，进行一场注定失败的消耗战。相反，选择直面这个强大的「新物种」，理解它、驯化它，最终让它服务于我们真正渴望成为的那个「更好的自己」。这，或许才是我们在这个时代，与科技共存的最佳路径。

萌生出做这个 App 的念头源于一个非常朴素的需求：我想在干活时，放一些舒服的背景音乐。这个需求有很多现成的解决方案，但没有太满意的。我希望它是

• 一个 Mac App。
• 有丰富的曲库可选（因为很容易听腻）。
• 界面简洁，功能够用，审美在线。

论曲库的话，YouTube 是最全的，Lofi、钢琴曲、Jazz 等等，只要愿意花点时间，总能找到满意的，听腻了的话，也很容易找到新的。但我不想打开 YouTube，一个是不够方便，另外就是干扰因素太多，还容易被推荐视频吸引而掉进兔子洞。

于是我就想，不如做一个可以播放 YouTube Playlist 的 Mac App 吧，这就是 LimTube 这个 Mac App 的创作初衷。

既然能添加 Playlist 了，我也会顺手把 YouTube 上感兴趣的 List 加进来，省的每次都要打开 YouTube。那既然 Playlist 可以添加，Channels 不加好像也说不过去，于是就变成了这样。

自己用了一段时间，感觉还是挺方便的，如果你也有类似的需求，欢迎使用和反馈。

前几天浏览Sivers博客的 Now 页面时，发现这位我长期关注的博主因为被上海吸引而开始学习中文。作为读者，我试着发了封邮件：先是表达欣赏，继而提议成为他的中文学习伙伴。没想到很快就收到回信——他详细说明了学习进度，还分享了自己的中文名字。随后的邮件往来中，我们交换了更多个人信息。

这个简单的举动，让我与千里之外的人建立了真实连接。在社交网络触手可及的时代，这看似平常，但电子邮件带来的体验还是不太一样：没有信息洪流，没有算法干预，没有无止境的推送诱惑。就像在数字丛林中意外发现的一条幽静小径，这条由最原始通信协议铺就的道路上，文字在发件箱与收件箱间静静流淌，每个字节都承载着明确意图。

当光标在邮件正文框规律闪烁时，你能清晰听见自己的思考节奏——宛如钢笔在信纸上沙沙作响的往昔。这种交流自带庄严的仪式感：点击发送后，你不会焦虑地刷新收件箱，而是像投递老式邮筒般，任由时间在对话间自然发酵。

电子邮件则像 一壶需要静待滴滤的手冲咖啡，虽然节奏迥异，却各自诠释着数字时代的沟通美学。。当世界将人际关系简化为「点赞」，「转发」的标准化货币时，一封邮件的抵达，依然如同中世纪商船运来的香料，让收件人嗅到遥远大陆的真实气息。

如果你也向往这种纯粹的文字交流，欢迎来信。每封邮件我都会认真阅读和回复。我的邮箱地址是： hi@limboy.me

断断续续从不同渠道听说过洗冷水澡，以及带来的好处，并没太在意：热水澡那么舒服，为什么要折磨自己呢。直到有一次心血来潮试了一下：打开冷水，不给自己思考时间，迎上去。头 1 分钟会有点挑战，3 分钟后，基本就适应了。后来又发现一个小技巧，可以帮助克服最开始的不适应：洗头。一方面可以避免冷水全部浇在身上，另一方面也可以分散注意力，等头洗完后，身体也差不多适应了。

我自己洗完冷水澡的感受是头脑更清醒了，身体会微微发热还蛮舒服的（更具体的洗冷水澡的好处，可以问下大语言模型）。如果把冷水澡比做「难而正确的事情」，热水澡比做「容易但无长期收益的事情」，生活中的很多选择都如同在冷热水之间徘徊。热水澡是即刻的温柔乡，让人沉溺于熟悉的舒适区；而冷水澡则是清醒剂，用短暂的刺痛换来长久的活力。

• 想画画？拿起笔，先画个 5 分钟，画什么不重要，重要的是这 5 分钟你在画画。
• 工作内容让你焦虑？啥都别想，先做个 5 分钟，可能会发现，好像也就那样。
• 打开手机想看收藏的文章，但又怕忍不住去刷社交媒体、短视频 App？强迫自己先看个 5 分钟，可能看着看着就看进去了。

很多时候，我们知道哪些事情应该多做，哪些事情应该少做，如果能借助「啥也不想，先来个 5 分钟」的劲儿，或许能多做一些正确的事，成为更好的自己。

PS：相比热水澡，冷水澡的搓灰体验差了一大截···

前些日子尝试借助 Cursor（主要是 claude-sonnet-4） 写一个五子棋 Web App，想着这是一个挺成熟的项目，应该不太需要干预，直接 Vibe Coding（依靠 LLM 生成代码） 应该就能搞定。一开始挺顺利的，界面经过几轮 Prompt 后，基本符合需求，也可以下棋，但在优化五子棋智能时遇到了严重的问题。我扮演 QA 的角色，不断地下棋，然后反馈五子棋算法的错误落子，AI Code Assistant（以下简称 ACA） 收到反馈后，总是会回复：我找到问题了！我解决问题了！完美！诸如此类，我还真就信了。在尝试了大约 50 次后，我发现事情不对，它好像没有真正地解决问题，只是解决了我那次报给它的问题，而且代码也变得异常臃肿，根本没法维护。

后来我就换了一个思路，先实现一个最最基础的五子棋策略，然后询问多个 AI，把代码发给它们，让它们提供优化思路，再把这些 AI 提到的共通点收集起来，让 ACA 每次只针对其中的一点进行优化，并且让它写对应的测试。如此经过几轮迭代下来，才终于慢慢地提升了五子棋的智能，代码也有了可维护性。

本以为一天可以搞定的需求，结果花了近四天，才基本完工，这其中走了不少弯路，正好总结下自己对于 AI-Assisted Coding（AI 辅助编程，以下简称 AAC） 的思考。

先说结论，我认为：

• 只靠 AAC 是无法做出有竞争力的产品的。
• AAC 是一个 multiplier，要么事半功倍，要么事倍功半。
• 「将 AAC 的价值最大化」，是开发者的必选项。

AAC 的本质是：提供了一个以完成当前任务为最高优先级的初级程序员。这里的 trick 就在于「当前任务」，假设你有一个机器人，然后跟它说：房间太乱了，打扫干净。它可能会：

• 发现桌上的东西很多，如果全部收拾掉，并按它们的属性放到合适的位置会涉及到很大的工作量，且不一定做得好，那么它的解决方案可能是在桌上盖一层毯子，这样看着不乱了，符合「干净」的需求。
• 发现角落里有一双鞋，看起来有点旧，又不知道放哪里，那就索性扔掉，虽然这可能是你最喜欢的一双鞋。
• 一些散落的衣服本来应该挂起来，但它可能会叠起来放进抽屉里。

ACA 也一样，它没有长期目标，也没有「代码质量」、「可维护性」等内在驱动力，它只关心如何最直接地满足当前 Prompt。针对一个任务它可能会：

• 走捷径。如加 if 判断，或引入 Magic Number，看起来好像解决了问题，但其实是在堆积技术债。这个倾向在写测试时体现的淋漓尽致。如果你的 prompt 是：为本次代码改动编写测试。那么它很可能会写好几个测试，结果也都通过了，但测试本身非常敷衍。
• 新增非必要的复杂度。它会尝试在现有结构上打补丁，而不是从根本上优化或简化。这可能是因为「增加代码」是解决问题最直接的方式，而「重构」需要更深层次的理解和抽象能力。这也意味着 AI 可能引入冗余代码、重复逻辑，甚至不必要的依赖。
• 进入死胡同。就好像你给一个 prompt：让这辆车飞起来。那么它会想各种办法，对车进行改造，但每次都失败。它不知道这件事几乎不可能，也不会揣测你背后的意图，跟你讨论其他的可能性。

正是因为这些特性，ACA 的表现看起来像是初级程序员。它们缺少创造性思考和大局观，能生成「看起来合理」的代码，但逻辑正确性、架构合理性、长期可维护性需要人工把关。所以ACA 不是一个完全独立的开发者，它是一个高级工具。如果你只是提需求和报 Bug，会发现它可能会为了解决 Bug 而引入新的 Bug，或者为了实现某个功能而增加不必要的复杂度。AI 并不真正理解代码，它只是模拟理解，如果你告诉它错了，它会立刻道歉并尝试给出另一个答案，但这不代表它真的理解了错误。

但我们可以利用它「以完成当前任务为最高优先级」的这个特点，来发挥它的价值。这就需要我们的 prompt 指令清晰，目标明确，且足够小。比如「实现登录功能」，这个 prompt 太大，太模糊。把它分解成：

• 设计AuthService协议
• 实现MockAuthService
• 实现RealAuthService的网络请求
• 编写LoginViewModel处理逻辑
• 编写LoginView UI
• 编写登录成功/失败的集成测试

然后按顺序提交给 ACA，效果会好得多。这个是 Cloudflare 的工程师通过 Claude 写的代码，可以看下他们给 Claude 的 prompt：

prompt: Please write tests for this library using vitest. The tests should use a mock or fake KV namespace for storage. Be sure to study README.md and storage-schema.md in addition to oauth-provider.ts to fully understand the functionality. Try to cover all the important logic.

Claude initially wrote a separate mock library.

prompt: Let's just put the whole test including mocks in one file.

Claude spent several minutes thinking and produced the test. It failed immediately due to `cloudflare:workers` not being available.

prompt: Looks like for this test to run under node, we need to mock out the `cloudflare:workers` module. We just need to define the `WorkerEntrypoint` class. Can you do that?

Claude did this. Yay.

Several tests are still failing, but they do run. Will debug in separate commits.

由此可见，prompt 要明确：

• 需要达成的目的
• 能够使用的工具
• 应该遵循的规范
• 需要考虑的要素

必要的话，再提供一些示例。通常需要几轮迭代才能完成一个小 feature 或修复一个 bug。每一轮 prompt，ACA 都会输出它的思考和对应的代码，不要在这个期间切换到社交媒体上刷新闻，这样不仅不容易进入 Flow 状态，也容易忽略 AI 犯的错。如果发现 ACA 无法正确地执行任务，要找到其中的原因或提供自己的思考，反馈给它，这样才能打开思路，避免进入死胡同。一个好的实践是，在把 Prompt 给 ACA 之前，自己先思考下：如果是我来做，大概会怎么实现，然后跟 ACA 的输出做对比。

有了 Prompt 的最佳实践后，接下来要做的就是如何生成这些 Prompt，这个就需要用到高阶程序员的技能了：架构设计、良好的编程习惯、定位问题和目标分解。一个好的架构是基础，它让每个模块职责清晰、数据可以顺畅流转、便于新增 Feature、便于定位 Bug。好的编程习惯可以让代码更容易维护。好的目标分解能力和定位问题能力，可以将产品经理的 Feature、QA 发现的 Bug、技术需求等转化为高质量的 Prompt，借助 ACA 的能力，得到最终想要的结果。

有了高质量的 Prompt 还不够，因为 ACA 依旧可能犯错，因此代码 Review 必不可少。值得考虑的点有：

• 是否需要写单元测试，如果是，需要覆盖哪些场景。
• 是否考虑了边界条件、错误处理、性能、可读性、可维护性。
• 是否符合代码规范。
• 是否有「代码异味」，如魔数、深层嵌套、大量 if、重复代码、命名含糊等。

所以，有了 ACA 并不意味着学习编程基础知识变得不那么重要，程序员的经验变得无足轻重，或者程序员的技能会被 AI 完全取代，恰恰相反，它需要你掌握高阶的编程技能，善于与 ACA 沟通，才能让开发效率事半功倍。

采用 AAC 后，开发范式会发生转变，开发者的角色从以「写代码」为主，慢慢转向「设计架构、分解任务、优化 Prompt、Review 代码」。越早适应这种转变，强迫自己提升对应的能力，越能取得优势。

One More Thing：精通市面上最强的 ACA（如 Cursor），结合最强的 AI 模型，可以大幅提升开发效率。

这本书相信大家都有听说过，我也是拖拖拉拉，直到最近才读完。书的主题是种族歧视，但又不止于此，也会涉及到家庭、教育、社会等方面的问题。书中的故事发生在美国南方的一个小镇，主人公是一个律师，他接手了一个案子，为一位黑人辩护。现在看来不觉得有什么，但当时的美国社会（尤其是南方）是很敏感的，黑人和白人之间的界限非常明确，几乎不可逾越。就像拿锤子去砸一面墙，一锤子下去，墙可能没什么变化，但你知道这一砸一定松动了墙的某些结构。

经典的书就是有能力把沉重的话题用想对轻松的方式呈现出来。这本书就是这样，虽然讲的是理我们较远的种族歧视，但是书中的人物形象、情节安排都很有趣。尤其是通过孩子们的视角来观察和讲述这个故事，更增添了一份天真和纯粹。书中的一些情节非常有画面感，比如斯库特躺在轮胎里，滚到了怪人布·拉德利家的院子；从树洞接受到了布拉德留下的种种礼物；用钓鱼竿给布·拉德利写信；自编、自导、自演跟拉德利有关的角色扮演游戏等等。

小女孩的父亲，阿提克斯·芬奇，是一位正直、善良、有原则的律师，他不仅在法庭上为黑人辩护，也在日常生活中身体力行地教导孩子们什么是正义和公平。他没有用空洞的说教，而是用自己的行动给孩子们树立了榜样，让他们在潜移默化中理解了人性的复杂和社会的残酷。

书中另一个令人印象深刻的角色是「怪人」拉德利。他被小镇居民视为异类，被孩子们当成鬼怪，但随着故事的推进，你能了解到他内心的善良和孤独。他就像一只被误解的知更鸟。而「杀死一只知更鸟」的隐喻，也正是指代了这种对无辜者的伤害，以及社会对弱势群体的偏见和歧视。

想象你与一个渣男/女坠入爱河，对方不仅掏空了你的金库，极大地败坏了你的名声（虽然是间接地），还害你坐了两年牢，现在你在牢里要给 Ta 写封信，你会怎么写，基调是怎样的？

这本《自深深处》(from the depth) 就是王尔德在狱中给波西写的信，你能完全感受到他对文字那炉火纯青的驾驭能力（虽然中间隔了一层翻译）以及其中流淌着的真切情感。大概有剖析、反思和哲思这几部分。

剖析：你（波西）是一个怎样的人（虚荣、浮浅、心怀怨恨、贪图享乐，但与我又有不可抗拒的吸引力）；我是一个怎样的人（视艺术为至高存在，享受与志同道合者的交谈以及由此催生的友谊）。

反思：为什么自己会从神坛跌落到身败名裂的境地（对自己掌控力的过度自信，对你的过度溺爱）；为什么明知你的存在会切断自己与艺术的连接又无法舍你而去（你身上有一种不可抗拒的魅力，自己的软弱导致无法割舍）。

哲思：关于爱（恨就像杂草很容易就长出来了，而爱则像蝴蝶兰，需要精心打理才能存活长大，要学会爱）；关于痛苦（所有的痛苦都有意义，提供了新的思考点，是更完整的体验）；关于做自己（一个人必须完全是、绝对是他自己，才会过基督那样的生活）。

这本书可以让你对王尔德有更全面的了解，同时书中的一些思考也能带来触动和碰撞，值得一读。

作者清水洁绝非凡人：正义感、专业素养（重视现场和采访）、很强的换位思考（政治嗅觉）和共情能力、杰出的刑侦和推理能力、做事非常有条理、擅长写作，最后也是最重要的：一根筋死磕的精神。

这样的人的存在，既是幸运，也是不幸。说是幸运，因为他确实一定程度上撼动了日本，这除了自身极强的素养外，离不开支持他的上层和可以发声的媒体。说是不幸，因为这样的人太少了，能带来的影响毕竟有限。

但只要媒体还没有彻底腐化，就还有希望。

上一次酣畅淋漓地看完一本第一人称纪实文学，还是杨柳松的 北方的空地，现在想想这两本书的主人公还有那么点相似：

• 都在挑战一个极其困难的任务
• 有很大的勇气
• 有大智慧又非常细心
• 有很强的韧性

不同的是，杨柳松是一个人在战斗，面对的是极端的自然环境，清水洁是孤勇者，面对的是绝望的社会环境，但得到了被他这股劲儿感染的人的帮助，让真相一步步浮出水面，让恶行得以被昭示。

跟 GPT 聊了下这本书（主要是它在输出），分析地挺全面的。 https://chatgpt.com/share/670d35fe-e694-800f-9be9-65ecd63316ce

最后，这本书的出版本身就说明了一些问题。

第一次接触到史铁生的名字，是在中学的语文课本上，于是「史铁生」就与背诵、考试产生了联系，这一耽误就是几十年，好在最终没有错过。

史铁生跟我们一样，也有七情六欲，也有悲欢离合，跟我们不一样的是他在21岁那年就双腿瘫痪，30岁肾衰竭，靠两天一次的透析续命。没有人生来就准备好了迎接苦难，尤其是在最年轻气盛之时。

好在有懂他又爱他的母亲，有在他低落时带来欢声笑语、鼓励他坚持下去的朋友，有拂动心弦却又被拦阻的爱情。当然还有地坛。

自从那个下午我无意中进了这个园子，就再没长久地离开过它。我一下子就理解了它的意图。正如我在一篇小说中所说的：“在人口密集的城市里，有这样一个宁静的去处，像是上帝的苦心安排。”

一直担心，一个被苦难「眷顾」的人，他写的文字也会很苦，以至于除了那份苦，品不出其他的滋味。但史铁生的文字不一样，平实又细腻，可以放在枕边，在夜深人静之时翻看。他会描写当时的挣扎，但不「卖苦」。

一个人可以很细腻，但能把这份细腻表述出来，则又是另一回事，史铁生同时具备了这两个特质。书中有很多描写他母亲的片段，每每读来，都感觉心里一颤。

上帝焊死了史铁生的一扇门，但也打开了他的精神世界，看他的文字，就像进入了他精心构建的花园，你会忘了作者是一个双腿瘫痪、靠着透析维生的人，只会惊叹于花园的鬼斧神工。

借着他的文字，也能一窥特殊年代下普通人的生活状态，我没有经历过，但能共情。觉得生活艰难时，想想那个年代，还能获得些慰藉。

感谢史铁生，感谢史铁生的作品，愿你在天堂与家人团聚。如果有来生，愿你的屋前有一片空地，种两棵树，一棵合欢，一棵海棠。

理论上，一个平台包揽文本内容的创作、分发和消费应该会很高效，就像早期的 Twitter。但这种模式存在着根本性的弊端：不可控性。这种不可控体现在多个方面：

• 产品不可控： 比如你可能需要长文写作功能，但平台要么不支持，要么将其作为付费功能；你希望内容列表以列表形式展示，但平台只提供 Feed 流。
• 体验不可控： 平台可能充斥着广告、强制登录浏览、越来越多不必要的功能，以及泛滥的垃圾账号。
• 内容不可控： 即使内容朴实无华，也可能因不符合社区规则而被移除。或者只是放了一个链接就被降权或关小黑屋。
• 账号不可控： 账号可能在莫名其妙就被限制，甚至封禁。

正因为这些潜在的风险，我对新兴的类 Twitter 平台始终保持警惕。即使它们目前看起来符合你的需求，但这些不可控因素就像悬在头上的达摩克利斯之剑，随时可能落下（Twitter 到 X 的转变就是一个例子）。

既然不能完全依赖于某个平台，那么将创作、分发和消费环节拆解开来，或许是更理想的方案。

文本内容创作：自由与便利的权衡

文本内容创作主要指以文字为主，富媒体为辅的形式，例如写博客、发微博等。在工具选择上，可以考虑以下几种方案：

• 独立博客： 自由度最高，但需要一定的技术能力。
• 付费博客： 在自由度和便利度之间取得平衡。
• 免费博客： 最方便，但自由度也最低。

独立博客：高自由度的选择

对于有编程基础、有文本内容创作需求、追求高度自由的用户，搭建独立博客是一个不错的选择。市面上有很多优秀的开源博客工具可供选择。在托管方面，可以选择 VPS（虚拟专用服务器）或类似 Vercel 这样的 Serverless 平台。

付费博客：平衡之选

如果你想要一个独立的博客主页，希望有一定的可定制性，能够方便地撰写文本内容，但又不想花费太多精力在代码和服务器维护上，那么付费博客工具是理想的选择。以下是一些值得考虑的服务：

• Typlog：小明 的作品，简洁优雅。
• Pika：Good Enough 团队的作品，注重设计和易用性。
• Hey World：37Signals 团队的作品，与 Hey 邮箱深度集成。
• Write.as：已经运营 10 年，提供免费版本，注重隐私和简洁。
• BearBlog：创始人承诺永不关闭、不出现广告、不卖，提供免费版本，界面极简。

免费博客：轻量之选

免费博客的自由度相对较低，但对于只需要简单记录和分享的用户来说，也是一个不错的选择。BearBlog 和 Write.as 都是值得信赖的选择，它们功能有限，界面简洁，但能够满足基本的写作需求。

文本内容分发和消费

现在内容分散在不同的博客平台上，如果想要方便地了解这些内容的更新，逐个访问网页效率太低。如果有一个工具可以将这些内容聚合起来，并在有更新时及时推送，将会非常方便。这样的工具确实存在，例如 NetNewsWire。使用者甚至不需要了解 RSS 的原理，只需将网页地址添加到订阅源即可。如果博客提供了全文输出，用户甚至可以直接在 NetNewsWire 中阅读完整内容。

这听起来很完美，但实际使用中仍然存在一些问题。

RSS 支持的不足

并非所有网站都提供 RSS 支持（如果对 RSS 不熟悉，可以点击此处了解）。例如，X 平台就不提供 RSS 输出。原本这可以通过解析网页内容来解决，但一些大型平台出于数据保护等原因，开始限制匿名访问，例如要求登录后才能查看内容。此外，一些 App 弱化了 Web 功能，将重心放在移动端，也增加了 RSS 获取的难度。

信息发现的局限

我们往往没有足够的时间和精力去主动发现和管理自己感兴趣的内容。如果没有良好的发现机制，就可能错过有价值的信息。这并非 RSS 的职责，而是各个平台推荐系统所擅长的。然而，正是因为意识到信息发现的重要性，我们常常沉迷于无休止的 “刷” 内容，导致 “发现” 本身成为了目的，而忽略了 “发现” 之后的行动。

互动缺失

RSS 只负责抓取最新的内容，不提供互动功能。如果想要给作者留言，需要跳转到对应的网站。但并非所有博客都提供评论功能，即使提供，想要了解作者是否回复，也需要专门访问该网站。这使得互动体验不够便捷。

因此，一旦你决定跳出集创作、分发和消费于一体的平台，就会发现，在内容分发和消费方面，现有的工具支持仍然不够完善。曾经有一款产品能够较好地解决这些问题，那就是 Google Reader（点击此处大致了解 Google Reader）。Google Reader 在 RSS 工具的基础上，支持关注用户、分享 NewsItem 、对 NewsItem 进行评论，同时又足够简洁。这些功能恰好解决了信息源闭塞和互动不足的问题。尽管已经过去了十多年，我仍然认为 Google Reader 是一款非常棒的产品，而目前还没有完美的替代方案。

不知道从什么时候开始，对坐飞机开始有种难以言说的恐惧。害怕被一个钢铁巨鸟带到离地万米的高空，害怕那无法预知的颠簸，更害怕自己对此无能为力。但生活又是充满着不得不飞的时刻，这反而促使我开始了一场逆向思考：假如我不幸在某次飞行中丧生，回顾这一生，是否留有遗憾？

答案是肯定的。太多经典的书籍和影视剧还未来得及细细品味，太多让自己满意的作品还未曾真正诞生，太多互相欣赏的人们还未发展出牢固而深厚的友谊…… 这种「临终回顾」式的思考，出乎意料地有效。最好是在一个安静、不会被打扰，也不会被电子设备干扰的场景下去进行，比如洗澡的时候。

这些答案，宛如散落在沙滩上的贝壳，指引着我窥见自己内心深处的价值观。即使从未系统地思考过「价值观」这个概念，我们也会在潜意识中，对什么事情值得做、什么事情不值得做，拥有一套隐形的价值判断标准，也就是一套隐式的价值观。

将这套隐式的价值观显式化，尤为重要。只有这样，我们才能清晰地认识到自己长久以来的做事标准，是否真的与自己内心深处的期望相符。例如，我一直认为「学习」很重要，但如果我把大部分时间都花在刷短视频上，那么我的行为就与我的「理想价值观」产生了偏差，「学习」或许在「实际价值观」序列中，但可能排在「享乐」之后。

更进一步，我们需要深入挖掘和细化这些价值观。仅仅停留在「读书」、「创作」、「友谊」这些模糊的概念上还是不够。问自己：我想读哪些类型的书？是文学名著，还是历史传记？为什么这些书对我来说有价值？是因为它们能拓展我的视野，还是能给我带来精神上的慰藉？我想在哪个领域进行创作？是写作、绘画，还是编程？「满意」的标准是什么？是得到认可，还是实现自我表达？我期望的友谊是什么样的？是互相支持，还是共同成长？

这些深入的追问与解答，能够帮助我们更清晰地界定个人价值观，并将其转化为可执行的具体行动。 例如，在阳光明媚的春日午后，当许多人选择外出踏青时，你却心甘情愿地坐在咖啡馆一隅敲击代码，因为对你而言，创作的价值超越了踏青的乐趣。 又比如，你选择观看一部制作精良的美剧，而非沉溺于碎片化的短视频，因为你认为美剧所蕴含的艺术价值远高于后者。 当生活中的种种选择与内在价值观紧密相连，而非盲目随波逐流时，我们更容易收获一份由内而外的踏实感与满足感。

值得注意的是，不同的价值观之间往往存在潜在的冲突。 例如，对事业成功的极致追求，可能不可避免地挤压陪伴家人的宝贵时间。 此时，我们需要认真权衡： 在不同价值观之间，究竟哪个对我而言更为重要？ 为了追求某些核心价值观，我愿意舍弃什么？ 又该如何巧妙地平衡不同价值观，以便获得更加幸福与完整的人生体验？ 对价值观进行优先级排序，能够帮助我们在面临人生抉择时，做出更贴合内心真实期望的明智决策。

有了价值观列表和对应的序列，还需要将这些显式化的价值观融入到日常生活中。审视我们的时间分配，看看我们每天/每周/每月花在哪些事情上的时间最多？这些事情是否符合我们的价值观？基于我们的价值观，设定一些长期和短期的目标。例如，如果我认为“学习”很重要，可以设定每周阅读多少小时。在面临选择时，问问自己：这个选择是否符合我的价值观？它会让我更接近我想要成为的人吗？

「定期反思」也不能少，看看行为跟价值观是否保持一致。如果发现偏离了方向，及时进行调整。这注定是一场持续探索与动态调整的旅程，没有放之四海而皆准的绝对答案。 重要的是，在不断地自我反思与成长中，逐步找到最契合自身本性的理想生活方式。

回到最初的恐惧，正是这种对生命短暂的感知，才更加迫切地思考人生的意义。 「以终为始」的核心在于：想象你在生命的终点回顾一生时，希望看到的是什么：做成了哪些事？去过哪些地方？陪伴子女幸福成长？抑或只是安安稳稳地过完这一生？如果上天把你的一生压缩成 10 分钟的短片，播放给来参加你追悼会的人看，你会觉得羞愧还是骄傲？

理想的人生，应该是随时死去，都不留遗憾。

大概半年前，我开始接触 AI 编程助手，例如 Cursor 和 GitHub Copilot。简单试用后，感觉不太顺手，就暂时搁置了。当时我的感受是：

Cursor 的存在感太强了，用起来不太习惯，还是更喜欢 VSCode。

但随着 AIDE 和 AI 编程插件越来越多地出现在视野中，我隐隐意识到这股趋势不可忽视，应该再次尝试。于是开通了 GitHub Copilot 的付费版，开始在一个实际项目中深入使用。

使用一段时间后，我的整体感受是：AI 辅助编程将会是不可逆转的趋势。越早掌握一款得心应手的工具，越早完成与 AI 的磨合，对程序员的个人发展越有益。

我实践的项目是一个基于 Tauri 2 的 Mac App。粗略估计，其中大约一半的代码是由 AI 辅助生成的。例如，编写一个 React 组件来展示 Playlist 下的 Videos，我先是构建了页面的基本结构，然后逐步细化指令，比如为每个 Video 添加序号，设置鼠标悬停 (Hover) 样式等等。这种感觉就像雇佣了一位高效的实习生来协助完成工作。

可能是 GitHub Copilot 的能力有限，或者我的使用技巧还不够成熟，亦或是当前 AI 编程助手普遍的现状，我发现在面对一些需要「跳跃性思维」才能解决的复杂 Bug 时，这些工具能提供的帮助非常有限。比如我曾遇到一个问题：主题切换在开发模式下运行正常，但部署到生产环境并重启应用后就会失效。这个 Bug 有点隐蔽，结果 AI 也如期望那样未能提供有效的解决方案。再比如，如何将 devtools 工具带到生产环境，同时禁用默认的 Cmd+Shift+I 快捷键？AI 给出的方案都不 Work，最终还是翻了下 Tauri 的源码才找到的思路。 目前看来， AI 编程助手更擅长执行指令明确的任务，根据上下文生成代码片段，但在复杂问题分析、根因定位、以及需要创新性解决方案的场景下，仍然需要人类程序员的深度思考和经验判断。如果未来的 AI 通过更高级的算法和更完善的知识库，模拟甚至超越了「跳跃性思维」，这又会是另一个课题，不过目前看来，还不太需要担心。

「信息滞后」也是一个不可忽视的问题（Cursor 在这方面表现稍好）。Copilot 似乎缺乏有效的机制来实时获取和更新最新的技术文档，因此它生成的代码有时会使用过时的 API。在 Tauri 2 项目中这个问题就比较明显，因为 Tauri 2 的 API 与 Tauri 1 相比变化很大。我经常需要在 AI 生成的代码基础上，手动查阅最新的 API 文档并进行替换。这个问题 Cursor 解决得更好一些，但有时也会出现新旧 API 混用的情况。

基于这次 AI 辅助编程的体验，我开始认真思考：AI 辅助编程的崛起究竟意味着什么？它将如何重塑软件开发行业？

程序员这个职业会消失吗？

如果一个没有编程经验的人，通过 AI 辅助编程工具就能开发出像模像样的产品，那么还需要程序员吗？如果对软件产品的要求仅仅停留在「可用」的层面，那么程序员的价值确实会受到挑战。但在实际软件开发过程中，我们不可避免地会遇到难以调试的 Bug，或者需要突破常规的创新思路才能实现的需求。目前的 AI 工具对复杂上下文的理解还不够深入，在处理复杂问题时常常显得力不从心。如果完全放任 AI 自由编程，结果很可能是 Bug 没解决，代码反而变得更混乱，维护性更差。

在注重协作的组织环境中，程序员被 AI 工具淘汰的速度可能会相对放缓。有相关工作经验的同学应该都有体会，在日常工作中，程序员每天的代码产出量其实很有限，相当一部分时间都花费在需求沟通、Bug 修复、梳理遗留代码、编写文档、Oncall、处理依赖冲突、等待编译构建结果等非直接编程相关的工作上。直接将 AI 引入现有复杂项目，一方面可能存在代码泄露的安全风险，另一方面，AI 由于缺乏对遗留代码完整上下文的理解，可能会生成不符合项目规范或非最佳实践的代码，反而增加维护成本。毕竟最终对代码质量和线上问题负责的仍然是人，而不是 AI。如果线上出现重大事故，总不能给 AI 记个 P1 吧。因此，在注重团队协作和代码质量的大型组织中，程序员受 AI 编程工具的直接冲击可能相对较小。但这种状态能维持多久还不好说，当企业看到 AI 带来的生产力提升潜力后，肯定会围绕 AI 进行组织架构和工作流程的效率革新，届时程序员群体必然会受到影响。

AI 编程的崛起，不是程序员的末日，而是一次进化。AI 不会取代所有程序员，但它将深刻地改变程序员的角色和技能要求。

初/中级程序员如何应对日益强大的 AI 编程工具？

首先要有危机意识，拥抱变革。有了危机感，才能激发学习和改变的动力。如果仍然想从事编程行业，那么首要任务是积极学习并掌握一款 AI 编程工具（Copilot 相对轻量，可以作为入门级选择）。要努力做到与 AI 工具默契配合，充分发挥其代码生成和辅助功能，从而显著提升个人生产力，并将节省出来的时间投入到更有价值、更具挑战性的事情上。

接下来，可以认真考虑未来的职业发展方向。如果希望在编程领域持续深耕，可以着重提升高级程序员应具备的核心技能，例如系统设计、复杂业务逻辑分析、问题分解与抽象、疑难 Bug 调试与根因分析、系统性能优化、创新技术方案设计等等。在这个学习和提升的过程中，也可以借助 AI 工具来提高学习效率，例如在阅读学习优秀的开源代码时，可以利用 AI 辅助代码理解，梳理代码逻辑，解答设计思路上的疑问。

如果对产品方向更感兴趣，或者有创业的想法，则可以投入更多时间在产品设计、用户研究、市场分析等方面，利用 AI 工具快速构建 MVP原型，快速验证产品想法，探索商业模式。

AI 编程下的人机协作新范式

可以将 AI 工具使用者与 AI 编程工具之间的关系比作「交响乐团的指挥家与乐团」。程序员如同经验丰富的指挥家，拥有清晰的愿景和目标，负责软件系统的整体架构和模块设计，指导和协调 AI 工具（如同乐团）高效、高质量地完成代码编写（如同乐曲演奏）。AI 工具如同训练有素的乐团，拥有强大的代码生成和辅助能力，但需要指挥家的明确指令和专业引导才能演奏出优美的乐章。

不同的 AI 编程工具都有各自独特的功能和特点，但与它们交互的核心要点是共通的：精细化任务分解和指令设计，以及代码 Review。 在人机协作的新范式下，程序员不仅需要与 AI 工具高效沟通，还需要与团队成员更好地协作，共同利用 AI 提升团队的整体研发效率和代码质量。

半年前我初次尝试 AI 编程助手效果不佳，也是因为没有掌握与 AI 编程工具有效沟通的精髓。可以将这些 AI 工具视为响应迅速、随叫随到的「外包程序员」，每一次代码改动都相当于一次 GitHub 的 Pull Request。要确保每次改动的目标明确具体，代码改动量控制在可审查的范围内。最终目标是代码虽然不是完全由自己编写的，但对代码的整体逻辑和关键细节都非常熟悉，这样即使 AI 无法解决某些深层次的 Bug，自己也能凭借对代码的深入理解，逐步分析和定位问题根源。

小结

AI 辅助编程的崛起既是挑战，也是机遇，基本上是不可逆转的趋势。如果半年前有人这么跟我说，我可能会将信将疑，但现在对此更加确信。即使只是体验了入门级的 Copilot，也已经真切感受到了它带来的效率提升。尽早找到适合自己的 AI 编程工具，积极完成与 AI 的磨合过程，然后将效率提升所节省出的宝贵时间，投入到扩展和丰富自身技能库上，不断学习和掌握更高级的技能，让自己成为拥抱 AI 浪潮的弄潮儿，而不是被技术浪潮无情淘汰的落伍者。

媳妇儿在小红书上种草了长龙航空的随心飞，于是怂恿我一起买了这个服务。然后就开始寻找目的地，本着第一趟就要赚回本的理念，选择了距离杭州近 5000 公里，中国最西部的城市：喀什。

我对这个城市只停留在「听说过」的阶段，对于当地的美食、美景、风土人情、历史典故等毫无概念，但既然媳妇儿选择了这里，就只能陪着一起去了。当时的心情没什么波动，甚至有点排斥，因为一想到要坐那么久的飞机（我对坐飞机这事有较大的心理障碍，确切来说是「高空」，所以摩天轮也不是我的菜），还要离开熟悉的地方一段时间，就会怀疑这么折腾到底值不值。

结果是，非常值。我跟媳妇儿都已年近 40，没有孩子，平时也都是各忙各的，交集主要是生活上的一些事。当缺少比较强的 hub 来连接彼此时，两人之间的连接感就容易变弱，而旅行是一个很好的可以加强连接、增进友谊的契机。

目的地的选择很重要，最好是双方都不太熟悉的。如果这个地方给两人带来的新奇感程度不一，就不容易有「共振」的体验，而「共同的情绪体验」是亲密关系中很重要的一部分。比如手抓饭，如果都是第一次吃，就能分享这道美食带来的惊艳。还有就是「弱攻略依赖」，也就是不用事先花大力气做好功课，也能有不错的体验，不会有太大的坑。

喀什是个很好的目的地，一方面是这里的美食通常是我们没怎么接触过的，而且确实很不错（印象最深的是石榴，榨成汁后不仅好喝，还营养丰富），另一方面喀什古城很好逛（虽然是淡季，很多店面都关门了，但古城的底蕴还在，在其间溜达还是挺舒适的，尤其是太阳照常上班的日子），还有就是这里的风土人情跟东南沿海差异很大，这种差异也是一个很好的切入点，成为两人茶余饭后的聊天话题。这里的人通常有自己的小买卖，比如开个饭馆、卖当地特产、烤肉等等，有些硬需求常年不变，就会出现从爷爷辈甚至爷爷的爷爷传下来的手艺，比如「爷爷的爷爷的爸爸的囊」、「祖传兄弟凉粉」。

临走的前一天，我们去「爷爷囊」那里，买了四个香菜囊，不远万里（literally），从喀什带到了杭州，算是对这趟旅行的一些回味😂。

去年，看了一本印象颇深的书：北方的空地。这本书讲的是一个叫杨柳松的人，推着一辆自行车（交通工具兼载货工具），历经 77 天，独自穿越羌塘无人区的故事。旅途非常艰险，一点小小的意外就可能导致极严重的后果（比如帐篷的地钉被吹走）。但体验独特，风景绝美。看完后，印象最深的除了他的那份胆识、勇气和乐观外，还有那非常严谨的准备工作，让看起来几乎不可能完成的任务成为可能。

然后我就想到了独立开发者，他们也像杨柳松一样，独自走进羌塘，面对诸多的不确定性和艰困的环境，试图从中找到一条出路。我目前还不是一个合格的独立开发者，思考上肯定会有所欠缺，但还是写下来，作为进入这个领域的前期准备工作吧。

理解独立开发的本质

说到独立开发，很多人的第一反应是「自己做一个产品」。但实际上，它是一种特殊形式的创业。特殊在哪里？你需要在极其有限的资源下（通常是一个人、有限的时间和资金），找到一个可持续的商业模式。

这就像是你决定开一家小饭店。不同的是，你不仅要当老板，还要同时担任设计师、厨师、服务员、采购、营销…所有角色。这听起来很累？确实如此。但这种方式也有独特的优势：决策快、运营成本低、方向调整灵活。

寻找适合的战场

在我观察到的案例中，成功的独立开发者往往都很擅长选择合适的战场。这里的”合适”，不是指最大或最热门的市场，而是要找到：

1. 市场规模适中（足够养活个人/小团队）。
2. 用户需求明确（愿意付费解决问题）。
3. 大公司不感兴趣（或者应对不够灵活）。
4. 技术门槛适中（能做出差异化但又不至于无法实现）。

举几个具体的例子：

沉浸式翻译

沉浸式翻译 是我很喜欢的一款翻译工具，使用几天后，就安利给了周围的朋友。作者 Owen 在一期访谈中提到，他在看王小波的沉默的大多数时，看到书中有提到萧伯纳的芭巴拉少校 很值得一看，然后他就找到了这本书，书中的中英文排版浏览体验给了他很大的惊喜和启发，最终促成了沉浸式翻译这款工具的诞生。

Pinboard

Pinboard 是一个简单、高效的社交书签服务，由 Maciej Ceglowski 创立。Maciej 的初衷是为用户提供一种可靠的方式保存和组织网络链接，专注于简洁和隐私保护：

• 现有的书签服务往往过于复杂或充斥广告，Pinboard 选择了简化功能，提供最基础但最实用的书签管理。
• 目标用户是那些希望高效保存并稍后查找链接的人，尤其是注重隐私的用户。
• 相较于社交化的书签平台，Pinboard 更专注于个人化的链接管理，用户可以自由选择是否分享。
• 通过付费订阅模式保持了平台的独立性和清爽的用户体验。

这两款作品的作者都是独立开发，他们找到了合适的战场，其中很重要的一点就是「做自己产品的第一个用户」。

做自己产品的第一个用户

Paul Graham 在 How to Start a Startup 中有提到：

No matter what kind of startup you start, it will probably be a stretch for you, the founders, to understand what users want. The only kind of software you can build without studying users is the sort for which you are the typical user.

无论你启动什么类型的初创公司，对于创始人来说，理解用户的需求可能都是一个挑战。你唯一可以不研究用户就能构建的软件，就是那种你本身就是典型用户的那种。

Pieter Levels（Nomad List 的创始人）也说过：「最好的产品灵感来自于解决自己的问题」。当你是自己产品的目标用户时，会获得几个关键优势：

1. 对问题的深刻理解

你不需要想象用户的痛点，因为你就是那个每天都在经历这个问题的人，这种第一手经验无比珍贵。

2. 持续的动力

创业路上最重要的不是灵感乍现的那一刻，而是持续的投入。当你在解决自己的问题时，这种动力会更持久。因为即使项目还没有其他用户，你自己就是受益者。

3. 产品方向的把控

很多决策不需要漫长的讨论和市场调研，因为你对目标场景太熟悉了。这种直觉判断虽然不一定完全准确，但往往能抓住重点。

4. 口碑传播的基础

当你真的解决了自己的问题，你会很自然地想要分享给同样有这个问题的人。这种发自内心的推荐很容易引起共鸣。

快速验证，大胆放弃

即使你吃自己的狗粮，结果仍然可能不如意，比如需求提炼不够精确，产品不够惊艳，缺少推广途径等等。NVIDIA CEO 黄仁勋在早年的一次分享中有提到：

If you want to be successful, I would encourage you to develop a tolerance for failure. However, there’s something crucial about failure: if you fail often enough, you might actually become a failure, which is fundamentally different from being successful. So the real question becomes: how do you teach someone to fail, but fail quickly, and change course the moment they recognize a dead end?

The way to approach this is through what we call “intellectual honesty.” This means continuously assessing whether something makes sense, and if it’s the wrong decision, being willing to change your mind.

To achieve this, you have to nurture a tolerance for risk-taking and teach people how to fail—quickly and with minimal cost. Innovation demands a bit of experimentation; experimentation requires exploration, and exploration inevitably involves failure. Without a tolerance for failure, you’d never experiment; without experimentation, you’d never innovate; and without innovation, you’ll never succeed. Otherwise, you’ll just end up being, well… a dweeb.

如果你想成功，我会鼓励你培养对失败的容忍度。然而，关于失败有一个关键点：如果你经常失败，你实际上可能变成一个失败者，这与成功是根本不同的。所以真正的问题变成了：你如何教会一个人快速失败，并在他们意识到死胡同的那一刻改变方向？

解决这个问题的方法是“诚实”。这意味着持续评估某件事是否合理，如果是错误的决定，愿意改变主意。

要实现这一点，你必须培养对冒险的容忍度，并教会人们如何快速且以最小成本失败。创新需要一点实验；实验需要探索，而探索不可避免地会涉及失败。如果没有对失败的容忍度，你就永远不会实验；没有实验，你就永远不会创新；而没有创新，你就永远不会成功。否则，你只会变成，嗯……一个傻瓜。

「创业最大的风险不是失败，而是在一个错误的方向上消耗太久」。这句话对独立开发者尤其重要。

如何做到快速验证？

确定最小验证集

不是最小可用产品(MVP)，而是验证核心假设的最小功能集。比如：

• 如果你假设用户愿意为更好的翻译体验付费，那么先做一个简单的浏览器插件。
• 如果你假设开发者需要某个开发工具，可以先写一个命令行版本。
• 如果你想验证市场需求，甚至可以先用 Notion 页面或者 Excel 表格来模拟（多抓鱼就是从一个微信群和 Excel 开始的）。

设定清晰的指标

在开始前就要明确：什么算成功，什么算失败？例如：

• 首周激活率 > 30%。
• 次月留存率 > 40%。
• 14 天内有 10 个付费用户。

严格控制时间投入

• 第一个版本控制在 1-2 个月内。
• 设定明确的评估节点，比如每两周回顾一次。
• 定期问自己：如果现在不是我在做这个项目，我会建议继续吗？

关于放弃

放弃一个项目往往比坚持更需要勇气。以下是一些值得注意的「放弃信号」：

• 连续三个月没有明显进展。
• 用户反馈总是很礼貌但不热情。
• 每天都在解决技术问题，但产品价值没有提升。
• 开始觉得这个项目是负担而不是机会。

放弃一个项目不等于前期投入都白费了。过程中获得的经验、技能提升、用户洞察等等，这些都是宝贵的资产。

持续构建护城河

独立开发最大的挑战之一是：如何在资源有限的情况下，建立起竞争优势？答案可能是：持续积累。

个人品牌建设

比如 Tony Dinh

• 通过博客分享独立开发经历。
• 在 Twitter 上记录每日进展。
• 定期发布产品更新和思考。
• 参与技术社区讨论。

这些持续的输出帮助他：

• 建立了个人影响力。
• 吸引了种子用户。
• 获得了社区反馈。
• 结识了潜在合作者。

国内的同学可能更加熟悉的 Kevin、Tualatrix、Baye，也都非常注重个人品牌建设。曾经 Baye 和小护士的故事，则是另一段佳话了 😂。

知识资产沉淀

每做一个项目，都要注意积累可复用的资源：

• 技术组件库。
• 设计系统。
• 文档模板。
• 营销材料。
• 用户研究方法。
• 定价策略经验。

这些资产会让你的下一个项目启动更快、质量更高。

用户关系

独立开发者最宝贵的资产之一是忠实用户群体：

• 建立用户社群（Discord、Telegram、微信、小红书等）。
• 维护邮件列表（国外比较常见）。
• 建立产品反馈机制。

这些用户不仅会持续给你建议，还会成为你的产品传播者。

构建能力矩阵

独立开发要求多面手，但这不意味着你要样样精通。可以把能力分为 Essential（核心能力） 和 Plus（增强能力）：

核心能力

开发能力

• 至少精通一个技术栈
• 熟悉常用的开发工具
• 了解基本的系统架构

产品思维

• 需求分析能力
• 用户体验设计
• 产品规划和迭代

设计能力

• 了解设计原则
• 能做出清晰、友好的界面
• 掌握基本的设计工具

增强能力

市场分析

• 竞品研究
• 市场机会判断
• 用户画像描述

市场营销

• 内容营销
• 社群运营
• 增长策略

商业分析

• 基础财务知识
• 定价策略
• 商业模式设计

常见陷阱及应对

在独立开发的路上，有一些常见的陷阱需要警惕：

过度追求完美

表现：

• 总觉得还差一点才能发布。
• 反复修改已经可用的功能。
• 纠结于细节优化。

解决方案：

• 设定明确的发布日期。
• 列出「最小功能集」清单。
• 告诉自己：发布后还可以继续改进。

技术栈选择困难症

表现：

• 总觉得现有技术栈不够好。
• 被新技术吸引注意力。
• 花太多时间在技术选型上。

解决方案：

• 优先选择你最熟悉的技术栈。
• 把新技术放在非核心功能上尝试。
• 告诉自己：技术只是工具，不是目的。

闭门造车

表现：

• 很少与用户交流。
• 凭感觉判断需求。
• 害怕展示不完善的产品。

解决方案：

• 建立持续的用户反馈渠道。
• 加入相关的社群。
• 勇于展示早期版本。

忽视商业模式

表现：

• 过于专注技术实现。
• 没有清晰的变现计划。
• 对定价犹豫不决。

解决方案：

• 早期就考虑商业模式。
• 研究竞品的定价策略。
• 大胆测试不同的定价方案。

结语

独立开发是一条充满挑战的道路，但也充满机遇和乐趣。关键是要：

• 选择合适的战场。
• 持续构建护城河。
• 持续学习。
• 做好风险控制。

这道题，没有标准答案，每个人有适合自己的节奏。重要的是在实践中不断学习和调整，直到找到那个真正适合你的机会。

独立开发不是终点，而是一种生活方式的选择。在这条路上，希望你也能找到属于自己的节奏和乐趣。

附注

独立开发产品类型维度对比表

产品类型	维护压力	技术复杂度	运营需求	美感要求	特点说明
实时通讯类	高	高	高	中	- 需要保证服务稳定性 - 需要处理大量并发 - 用户体验要求高
在线协作工具	高	高	中	中	- 需要确保数据同步 - 需要处理多人协作场景 - 稳定性要求高
支付相关服务	高	高	中	低	- 安全性要求极高 - 需要专业资质 - 责任风险大
SaaS工具	中	中	中	中	- 需要定期更新维护 - 需要处理客户支持 - 相对稳定的收入
社区类产品	中	中	高	中	- 需要持续运营维护 - 内容管理要求高 - 用户增长是关键
单机游戏	低	中~高	低	高	- 开发周期较长 - 发布后维护较少 - 营销很重要
效率工具	低	低~中	低	高	- 功能性为主 - 用户体验重要 - 竞品较多
开发者工具	低	高	低	低	- 技术门槛高 - 用户群体专业 - 变现相对容易
设计类工具	低	中	低	高	- 视觉体验重要 - 专业用户群体 - 需要持续更新
内容平台	中	中	高	中	- 内容运营重要 - 用户留存是关键 - 需要持续产出
生活工具类	低	低	低	高	- 界面设计重要 - 功能相对简单 - 用户基数大
数据分析工具	中	高	中	中	- 专业性要求高 - 准确性要求高 - 需要持续优化
教育类应用	中	中	高	中	- 内容质量重要 - 需要持续更新 - 用户服务要求高
自动化工具	低	高	低	低	- 技术门槛高 - 稳定性要求高 - 用户群体专业
主题/模板	低	低	低	高	- 设计质量重要 - 更新频率低 - 竞争激烈

对于希望进入到独立开发领域的同学，建议从工具类型入手，因为运营成本相对较低，用户需求明确，技术门槛适中，更容易找到自己的节奏。

修改记录

• 2024/11/13: 添加「独立开发产品类型维度对比表」，帮助更好地选择适合自己的产品类型。