上篇：AI编程之我见
春节期间做了SnowFox: 一个面向小型科研实验室或生物公司的液氮罐冻存索引软件。核心开发大概是没日没夜的四天左右，从0到完成1.0.0版本，之后又额外做了一些代码清洁和功能提升（写此文时版本号已是1.3.3），整体的时间成本其实并不高。
今天，AI已经足够我一个从没有过项目开发经验的人，从无到有的零代码制作软件了。
模型 vs. 系统
模型的提升临界点应该是2025年12月的claude opus 4.6和gpt-5.3-codex，最直观的震撼是：它们突然开始自动写测试了。对于我一个外行来说，“回归测试”这个概念让我如获至宝（后来才知道这早就是软件开发行业的标准流程）。在此前的所有模型中，无论我做多大的项目，它们从未主动编写并运行过测试。
过去我盲目迷信“唯模型论”，觉得模型决定了90%的性能，忽视了系统的作用。但现在我发现，同样的模型放在 Claude Code 和 Opencode 中的效果就是前者更好；Codex 也是从26年1月开始体验显著改善。模型和系统，就是两驾马车，缺一不可。
这也让我对“工程”的敬畏油然而生。过去总有一种“科研至上”的傲慢，觉得工程是细枝末节、可被替代的。但随着工具的演进——从如获至宝的 Cursor，到嫌贵换成 BYOK 的 Cline 和 Roo Code，再到现在完全脱离 IDE，投奔 Claude Code、Codex、Opencode 和 Gemini CLI——我的观念潜移默化地被改变了。
当然不只是我这么选择，整个行业也是这个运动趋势。包括antigravity和TRAE等也在半年前退出solo模式，肉眼可见的让人类给AI让位。最近有个小热点topic叫harness engineering，就是强调系统的重要性。
古法编程
大半年前出现了“古法编程”这个调侃，虽然我不是编程行业，但从网络言论看，今天古法编程真的从段子变成现实了。vibe coding也从用和不用的讨论转向了如何用，怎么用。我还回顾了一下，我能找到最早的编程相关的笔记应该是2023年1月的Butterfly主题首页副标题自定义随机句子还有Butterfly主题设置日间和夜间模式不同的默认封面这两篇。
后来review的时候发现还有更早的是2022年8月的：博客分类页面添加摘要，随机句子组件。
虽然ChatGPT3.5是22年12月火起来的，当时我还没用过，当时搞这两篇文章的场景我都记得，在南区28号楼一层的上床下桌里昏暗的黄色台灯下搞了很久。当时为了实现现在看来极其可笑的两个小功能，熬了很久反复查百度和摸索，做出来后还骄傲得不行。
这里我要感谢一下糖果屋的店长Akilar，当时组建的糖果屋社群真的陪伴我度过很多早期探索静态博客的时光：https://akilar.top/，可惜刚刚看店长本人的博客都已经荒芜很久了。
其实我很大体会是，程序员们过去付出的极大的“写代码”学习成本，说实话，今天在很大程度上已经被浪费掉了。我在xhs发过一篇“8个codex同时干活”的笔记意外小火，底下评论区里，我看到很多所谓的“内行人”阴阳怪气地嘲讽，但其实他们对如今Agent协作的理解甚至还不如我这个外行，也挺唏嘘。
外行的vibe coding经验
第一：死磕测试。 每实现一个功能，必须让AI写单元测试和集成测试。每修改一次代码，必须运行回归测试。这是底线。
第二：定期执行代码清理（重构）。 别等项目写完了才想起来重构，每增加几个功能就要停下来。让模型停止开发新功能，转而检查现有代码：死代码、冗余、兜底、重复项，有哪些可以提取为公共helper？架构是否最佳？如何提高可维护性？ 从逻辑上讲，架构应该是一开始就设计好的。但我脑子里没这个概念，只能先让AI天马行空地写，在交互中逐渐理解它预设的架构，发现问题后，再让它重构成符合我审美的样子。
第三：并行开发（善用 Git Worktree）。 CLI Coding Agent 的最大优势就是并行。但并行的致命缺点是容易冲突覆盖。标准解决方案是 Git Worktree。不过，即便是用 Worktree，也要在指派任务时尽量拆分相关性不大的模块；很多时候只要模块拆分得好，就算不用 Worktree，冲突的概率也不大。
代码 vs. 现实
Coding agent这玩意跟人类真的太像了。你钻研提示词如何精简高效、如何用Skills做“渐进式披露”、如何用内存和硬盘做记忆管理、如何做上下文处理和对话压缩……这不就是人类职场里的工作汇报、标准SOP、日记复盘和思维导图吗？给模型一个checklist能显著提高流程遵循效果，我们做实验照着protocol不也是一样的道理吗？
agent和subagent的通讯跟团队合作也很像。一个公认原则是“能用 Prompt 优化完成的事情就不要用 Agent；能用单个 Agent 完成的任务，就绝不启动 Sub-agent。”，这不就和“多人协作的信息损耗 vs. 人力资源”的取舍一致吗？有段时间这种意识还真的渗透到我的现实生活。之前可能只是盲目追求团队配合，现在想想，其实很多事情委派给一个人就是更合适的，人越多越出问题。Agent 任务拆分导致的交接成本差异，和现实团队管理简直如出一辙。怎么设计Agent之间的任务拆分，其实就是所谓领导能力和管理水平的体现（当然，人类的领导可能要更复杂一些，因为人类会懒惰、会自私）。
开发 vs. 推广
还有个体会，软件开发，什么数据库、架构、GUI其实也就那样，真正难的地方其实在推广。
这其实很反常识，即便你理性上意识到这个，但只有自己亲自走一遍，才会被“争夺注意力”的难度毒打。这件事太难、太贵、太费时间，而且极搞心态。我开始随便截了几张图发出来的xhs已经四五百收藏了。后来我终于腾出时间，花300多块买了一年的 Focusee 录屏软件，精心制作了简洁的宣传片，甚至还砸了75块钱推流……最后只有4个赞，说起来都可笑。
另一个方面是，广告这件事情其实很烦，它要求你迎合大众而自降身价。你不再是那个“伟大无私的开源奉献者”或“技术超群的开发者”，你要上赶着面对别人的不耐烦去推销，或者用夸张的标题和封面营造噱头。稍微有点精神洁癖的人真干不来这种事。
我本身就非常讨厌实验室那些推销试剂的人频繁进出实验室打扰我们，一边又理解他们那种又礼貌又小心翼翼的打探（导致我老把他们跟那种不好好学习长大就是这种人挂钩）。现在我不得不承认，这玩意可不是你拉下面子就能做得好的，能把推广做好，比能开发一个软件是更难能可贵的能力。即便前者看起来不是那么体面。