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）

多模型并行评审，重复结论自动合并

Juror 的工作方式并不复杂：当一个拉取请求（Pull Request）触发评审时，多个前沿大模型会各自通过原生的智能体框架并行审查同一份代码差异（diff）。不同模型给出的发现会经过五道「无损合并」流程——先按行锚定、再按文件与代码窗口分组、完全相同的报告直接归并，随后用加权相似度加「裁判」模型判断是否重复，最后做覆盖审计，确保每一条原始发现都归属于唯一的最终结论。

设计上，Juror 明确声明自己「不是自动修复机器人，不是代码检查器（linter），也不是聊天界面」。它只做一件事：审阅 diff 并贴出发现。项目方强调，使用它不需要安装应用、不需要注册账号，也不需要先为代码仓库建立索引。

基准测试：声称优于 Greptile

Juror 最具争议也最吸引眼球的是它的基准数据。项目方称，在自带的「生产环境拉取请求」种子样本上，Juror Fast 找到了 4 个 P0–P2 级别缺陷中的 4 个（召回率 66.7%，精度 100%）；而 Greptile 只找到 1 个（召回率 16.7%，精度 50%）。按项目方说法，Juror Fast 发现的「经裁决确认的 P0–P2 缺陷」是 Greptile 的 4 倍。

需要说明的是，这一对比来自 Juror 项目方自己的基准，并非独立第三方评测。Greptile 作为商业产品，其评审策略、默认模型和触发条件与 Juror 并不相同，单纯比较两个工具在同一份样本上的命中数量，未必能完整反映真实工程场景中的表现。

支持哪些模型与预设

Juror 通过不同的「harness」接入各类模型：Claude Code 可调用任意 Anthropic 模型，Codex 可调用任意 OpenAI 模型，opencode 能接入 models.dev 上的 Fireworks、Groq、OpenRouter 等，Grok Build 调用 Grok 系列，Kimi Code 调用 Fireworks 上的 Kimi K3，此外还支持通用的 OpenAI 兼容接口。

为了平衡成本与效果，Juror 内置了多档预设（preset）：默认的 fast 档用 Codex 上的 GPT-5.6 Luna 与 opencode 上的 DeepSeek V4 Flash；balanced 档加入 Grok 4.5 与 Kimi K3；high 档再叠加 Opus 5；ultra 档则把七款模型全部拉满。用户也可以自己写配置，把 DeepSeek V4 Flash 等模型按需接入。

成本透明，采用 MIT 许可

Juror 的一大特点是「每轮评审都打印自己的收据」。一份示例收据显示，一次评审调用 3 个模型、耗时 2 分 14 秒，成本为 0.91 美元。配置文件中还能设定每轮拉取请求的目标预算（默认 5 美元），超出时按「可负担子集」或跳过处理，而不是悄悄超限。

该项目以 MIT 许可证开源，代码托管在 GitHub 的 Juror-AI/juror 仓库，最近一次提交时间为 2026 年 8 月 11 日。接入方式也贴合开发者习惯：一条 npx juror-ai review --pr 1234 --repo owner/name 即可在终端查看评审结果，加上 --post 参数便会把结论作为一条置顶总结评论加若干行内评论贴回拉取请求。

对于希望把 AI 代码审查留在自己基础设施内的团队来说，Juror 提供了一条不依赖外部 SaaS 的路径。不过，它的基准优势仍需在更多真实项目中验证，工具是否真能长期替代商业方案，还要看后续社区的独立评测与持续维护情况。

来源：Hacker News / GitHub（Juror-AI/juror）

过去一段时间里，软件开发正在经历一场底层的变化：过去工程师大部分代码靠手敲，如今越来越多代码由 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 日）

Anthropic 宣布，从 2026 年 8 月 14 日起，Claude Code 的「自动模式」将成为 Pro、Max 与 Team 套餐用户的默认权限设置，除非用户或管理员手动锁定了其他偏好。

所谓自动模式，是用一个分类器取代过去反复弹出的逐条授权确认。每执行一次工具调用，分类器会先判断它是否属于不可逆、破坏性，或超出授权范围的操作。若判定危险，Claude 会改走更安全的路线，或转而向用户申请许可；在被连续拦截多次之后，会话才会退回手动确认。

Anthropic 表示，作为这次调整的一部分，公司不再对自动模式分类器消耗的「每步少量额外令牌」收费。

更值得留意的是一组对比数据。在针对 1053 名付费测试者的研究中，人类只能识别并拦下 13.6% 的危险命令，而自动模式拦下了 89%；而且在连续处理约 50 条提示之后，人类的正确率进一步跌到约 5%。换言之，长时间盯着授权弹窗的人，反而比机器更容易放过危险操作。

Anthropic 提醒，分类器并不能彻底消除风险，涉及生产环境的改动仍建议人工复核。不过公司也给出了一组数据：在 Team 与 Enterprise 客户中，开启自动模式的用户比其他人多提交了约 25% 的合并请求。

9to5Mac 在评测中认为，对熟练用户来说这大概率是更合理的默认项，但前提是先和编程智能体建立足够的信任。有意思的是，作为对比，OpenAI 曾出于额外谨慎，一度在其最强版本 GPT-5.6 上关闭了类似的自动模式。

来源：9to5Mac

你大概听过这样的说法：AI 正在让程序员变成“10 倍工程师”。但一份来自 ACM Queue 的研究却先问了另一个问题——程序员的时间，到底有多少在写代码？答案是，不到 14%。

2025 年，微软研究团队追踪了 450 多名工程师后发现，开发者平均每天花在写代码上的时间只有 14%。早前研究里，状态较好的工作日编码占比约 18%，状态差的工作日则跌到 11%。读文档、开会、理解旧系统、调试、测试、配置环境、做设计，才是占据他们日程的大头。

这个数字本身并不新鲜。新鲜的是，生成式 AI 铺天盖地宣传“自动写代码”时，恰好暴露了行业里长期被忽略的一个事实：把写代码速度翻倍，整体效率的提升也到不了 15%。因为写代码从来不是瓶颈。

02 微软团队总结的八大误区

这篇题为 *Eight Myths on Software Engineering and GenAI* 的论文由 Jenna Butler、Brian Houck、Margaret-Anne Storey 等微软与高校研究者共同撰写，逐条拆解了围绕生成式 AI 与软件工程的主流误解。

误区一：开发者大部分时间都在写代码。 如上所述，14% 的数字已经否定了这一点。

误区二：写代码是项目瓶颈。 如果编码只占 15%，即使 AI 把编码速度翻倍，对整体进度的推动也小于 15%。更麻烦的是，快速产出未经验证的代码会把压力转移到下游的代码审查、测试和集成，反而可能拖慢交付。

误区三：AI 生成的代码行数是衡量生产力的好指标。 比尔·盖茨曾把“用代码行数衡量软件生产力”比作“用飞机重量衡量飞行进度”。2014 年的一篇统计研究也指出，代码行数并未通过效度检验，作为指标用途有限。微软 CEO 在 2025 年 4 月提到公司“最多 30% 的代码由 AI 编写”，但这仍不能说明质量、速度或商业价值。

误区四：AI 对所有工程师的帮助都一样。 研究结果并不一致。有研究发现 GitHub Copilot 带来明显提升，也有研究显示开源资深开发者使用 AI 后完成任务的时间反而平均增加了 18%。有经验的开发者在熟悉任务上获益更大，但专业年限与提示词信心反而呈负相关。

误区五：AI 能把普通开发者变成 10 倍开发者。 很多研究基于孤立的小型任务得出“55% 生产力提升”的结论，但真实团队环境复杂得多。开发者之间的表现差异主要来自任务本身，而非恒定个人能力。

误区六：用好 AI 是开发者个人的事。 文章指出，真正改变生产力的是组织层面的系统工程，而不是每个人自己摸索提示词。

误区七：好用的 AI 工具自然会被采用。 Stack Overflow 2025 年调查显示，80% 的开发者用过 AI 工具，但只有 29% 相信其准确性。能力惩罚、伦理担忧、对“去技能化”的恐惧都会拖慢采用。

误区八：有了 GenAI，大企业就能以小团队速度创新。 初创公司依赖公开框架和代码，正是大模型训练数据的主要来源；而企业依赖专有遗留系统，AI 没见过这些代码，还要面对合规、安全、隐私和向后兼容的约束。

03 这对企业和团队意味着什么

研究者认为，当前围绕 AI 写代码的叙事，本质上是在优化一个本来就不够大的工作切片。如果组织真正想提升软件交付效率，重点应该放在：减少会议和上下文切换、改善遗留系统可理解性、把代码审查和测试流程做得更轻更快，以及建立可信的 AI 使用规范。

换言之，AI 可以是杠杆，但它撬动的支点不是键盘，而是整个工程系统的设计。

来源：ACM Queue / *Eight Myths on Software Engineering and GenAI*（2026 年 5 月）