AI 时代，学生和研究者该如何使用 AI 写程序？一种极端是假装 AI 不存在，坚持纯手写——这不利于为遍布 AI 的世界做准备。另一种极端是把活儿全交给 AI（即所谓 vibe coding）：只盯着测试是否通过，不再细读每一行代码。后者会带来「自我欺骗」——以为自己掌握了，其实没学到任何有价值的技能。作者打了个比方：认知技能像肌肉，练起来难，丢起来快。

中间路线：手写，AI 审查

折中方案被称为「匠心编程」（craft coding）。它的价值取向是围绕产品本身的质量，细到每个细节；开发者承诺理解代码库的每一处，AI 可以用，但只在有助于这一理想时才用。最凝练的实践口号是「手写，AI 审查」：以当下模型的能力，不要让 AI 去做任何事，只让它审查你写好的东西，你认同才采纳。最好的比喻，是把 AI 当成一位资深程序员的代码评审。

匠心编程的十条戒律

1. 不在 IDE 里用 AI，包括 LLM 自动补全；每一行字符都亲手敲。
2. 最好不把代码库交给 AI；需要时在网页界面里粘贴片段，若必须授权，也只用只读权限。
3. 不让 AI 运行任何东西；它给建议，你来执行。
4. 不把 AI 对话框里的代码直接复制粘贴，要自己敲一遍。
5. 能用普通搜索解决的事，不麻烦 AI。
6. 问 AI 之前，先读文档。
7. 只有自己实在解不出时才向 AI 求方案，并先给自己思考的时间。
8. 请 AI 审查前，自己先检查一遍。
9. 先运行代码排查问题，再让 AI 审查补漏。
10. 没看懂的建议，绝不采纳。

为什么值得这么做

作者以科研代码为例：论文里的实验代码一旦出错，整篇结论都可能失效，因此科学是匠心编程的典型场景。安全关键软件同样如此——在 AI 时代，纯手写的代码反而不够安全，开发者必须把 AI 审查纳入流程，否则攻防会变得极不对称。

当然，适度使用也无可厚非。作者坦言自己偷懒时也会写潦草代码、让 Claude 直接调试，但他提醒这有「技能退化」的风险。GitHub Copilot 近期从包月改为按量计费，一些重度 vibe coding 用户月费从 30 美元涨到 750 美元，也算一种侧面注脚。

结论很朴素：手写与 AI 审查之间，藏着一片明智的中间地带。只要保持思考、不把大脑闲置，答案就在那里。

来源：Peter Bloem（peterbloem.nl）

过去一段时间里，软件开发正在经历一场底层的变化：过去工程师大部分代码靠手敲，如今越来越多代码由 AI 编程助手与智能体批量生成。但 AI 生成之后，仍需要人来把关——阅读、清理并验证这些代码是否真的符合要求。

当 AI 拥有对整体架构的有限视野时，界定系统边界、保障生产环境的安全与可靠，依然要靠人。换句话说，软件工程的关键环节，正从「写」悄悄转向「审、验、养」。

Go 生来为「软件工程」而非「编程」

有意思的是，正是这种团队协同的考量，促使 Rob Pike、Robert Griesemer 与 Ken Thompson 二十多年前在 Google 创造了 Go 语言。当其他语言不断堆砌特性、追求更多表达写法时，Go 选择了一条更大的路线：让语言设计服务于软件工程。

软件工程并不等于编程。编程是用代码解决问题并运行它；软件工程则是与人协作，设计一套能随时间演进、长期可维护的系统。编程只是其中一部分。

要让语言服务于工程，光有语法不够，还需要覆盖软件全生命周期的工具链，需要「有主见的简单」——让整个团队用同一种方式组织、格式化、测试代码；需要强兼容承诺——今天写的代码十年后不仅仍能运行，而且依旧是「好代码」；还需要健全的生态与贯穿始终的安全考量。

可读，意味着人和 AI 都更好审

Go 的另一大特征是「重可读、轻炫技」。三位设计者很清楚，开发者读旧代码的时间，远多于写新代码的时间。于是 Go 刻意拒绝其他语言热衷的语法魔法，形成了「以简单为美」的文化。

到了 AI 辅助开发时代，这种「先读后写」的哲学成了放大器。当个体开发者偏爱简短语法、隐式类型与聪明捷径时，智能体与人协作的验证回路，恰恰要求相反的东西：可预测、显式、结构刚性。

如果一门语言用十几种方式表达同一段逻辑，AI 生成的代码就会变成风格杂乱的大杂烩，人工审阅者要花很大力气去猜意图。Go 用内置的 gofmt 统一格式、用刻意克制的抽象，确保所有代码——无论出自资深工程师、初级贡献者还是大模型——看起来都一样。语法完全可以预测时，人能更快发现一处幻觉出来的接口调用、一个逻辑漏洞或一处安全隐患。

可靠，编译器替你拦住幻觉

可读性只是上半场。如果跑起来脆弱、不安全、负载下行为难测，再好读也进不了生产环境。

Go 的第一道防线是静态类型系统，它相当于给智能体生成的代码加了一张自动安全网。大模型常常在跨文件的类型与结构边界上犯迷糊，产生幻觉属性与潜伏的隐患。在 Python 这类动态类型语言里，这类幻觉往往能躲过基础语法检查，直到特定生产负载下才在运行时崩溃；而在 Go 里，编译器会立刻拒绝——智能体若调用了不存在的方法、传错类型或漏初始化变量，代码根本编不过。

配合 Go 标志性的编译速度（据 Google 方面介绍，比 Java、C#、Rust 等生产级编译语言快出数量级），智能体可以高效地自我纠错：在人工审阅之前，就把语法与类型错误迭代修好。

在编译器之外，Go「开箱即用」的哲学还化解了 AI 生成代码的一大风险——软件供应链。大模型写功能时常常依赖训练数据，于是倾向于建议陈旧、无人维护甚至恶意的第三方依赖。而 Go 体量完备的标准库，会自然地把模型引向官方维护、经过优化的包，而不是随意拉外部依赖，从而大幅压缩供应链攻击面。

再加上校验和数据库与模块镜像（记录每一次导入模块的副本，以防中间人篡改），以及官方漏洞库与集成扫描工具 govulncheck（只标记代码真正调用的漏洞函数，反馈精准、噪音低），Go 形成了一套低噪音的安全闭环。

可维护，才是 Day 2 的真正考验

能读、能跑，只是起点。代码库是活的系统，会自然腐化、累积技术债。当自主 AI 智能体可以一口气生成几十个拉取请求、随手重构整个服务时，架构漂移的速度被急剧放大。

Go 的答案是著名的兼容性承诺：在 Go 这里，兼容不是便利，而是安全与运维的硬要求。早在 Go 1.0 时代编写的代码，到今天的最新工具链依然能原样编译运行；Go 承诺永不破坏向后兼容，并且不会有 Go 2.0。编译器与运行时越变越好，代码无需改动就能跟着受益：升级、重编译，仅此而已。

这种长期耐久，配上 Go 的部署便携性更显价值。Go 直接编译成单一静态二进制、零系统依赖；当 AI 智能体越来越多地以「系统管理员」身份运行——拉起微服务、执行脚本、通过命令行操作环境——这种自包含的设计变得空前重要。而 Go 编译器支持跨操作系统、跨架构交叉编译，智能体可以按需为任意目标平台构建二进制，无需复杂构建系统。

为了对抗架构漂移，Go 还提供内置的、确定性的重构与现代化工具。官方语言服务器 gopls，以及重新打造的 go fix（引入了「modernizers」概念），能确定性地把旧代码模式更新到最新写法与语言特性。由于这些工具标准化、内建于平台，AI 智能体能借助它们安全地重组包、管理依赖、清理技术债，而不破坏代码库。

最后，Go 还把可维护性延伸到生产环境：运行时内置性能分析与执行追踪，编译器原生支持基于真实负载画像的画像引导优化（PGO），与 AI 编排的部署流水线结合，形成「生产数据回流编译器、再优化系统」的闭环。

当 AI 接管写代码，语言反而更重要

写代码越来越少，按说语言选择该变得无关紧要，事实却正相反。当代码生成被甩给 AI，软件工程的瓶颈从「写得快不快」彻底转移到「审得严不严、验得准不准、养得长久不长久」。那些曾以松散原型、聪明隐式捷径见长的语言，在碎片化的智能体输出重压下越来越难保持稳健；而把可读性、可靠性、可维护性刻进骨子里的 Go，反而在这个时代显得从容。

来源：Google Developers Blog（作者：Cameron Balahan、Richard Seroter，2026 年 8 月 11 日）

他在个人项目的智能体配置里写死三条指令：不许创建、修改、移动、重命名或删除任何项目文件，所有改动只在对话里展示，由他自己录入；不许运行会改动文件、安装依赖或改变仓库状态的命令，同样只给出命令由他手动执行；以及，别解释语法和接口，他是资深开发者。

代价很直接：这么干比完全不用 AI 快，但比放手让机器写的人慢，用他的话说，”不是快 10 倍，大概只有 2 倍”。换来的是什么？手敲逼他慢下来，更容易逮住模型的幻觉和糟糕的设计选择，也方便边敲边重构、改成自己的风格。更重要的是，他因此建立起代码库的”空间地图”——哪个功能在哪个文件里心里有数，下次改动知道去哪改，连提示词都写得更准。

塞西把这套做法类比成少年时学编程的老规矩：书上的例子别复制粘贴，要一个字一个字敲进电脑跑一遍。他真正担心的是行业正在累积”认知负债”——总有一天，没人说得清数字基础设施是怎么拼起来的。他至少能保证完全理解自己发布的软件，”否则就是职业失职”。

说白了，这不是反对 AI，而是拒绝把理解外包出去。下次让助手改一处逻辑，试试只让它在对话里给方案，自己动手落地，看看两周后你还记不记得。

来源：Ankur Sethi’s Lab Notebook「Prevent cognitive debt by manually retyping LLM-generated code」