呼吁开发者要有责任心，网友说我矫情...｜1024，我们采访了与 AI 相爱相杀的程序员们

上周发了一个 1024 程序员节的互动，（详情见 编程十余年，走在“Pair with AI”的十字路口｜有奖征集），结果上来就被怼了：

网友：Zign

看了描述我就一个感觉，题主你真 TMD 矫情。

你看同事提交的 AI 代码不爽，那你倒具体说说看哪里不好呀。你要是真能说出来个一二三，那打回去让他重写不就好了？

这个事的核心问题在于，你没有能力评价代码的好坏。比如你为什么会觉得完全由 AI 生成的代码是中看不中的“银样镴枪头”呢？

实不相瞒，我和我的团队也都在探索 AI 大潮冲击下如何编程。而我们得出的结论是即使是我们自己手写的代码，最后在提交之前也应该扔给 AI 重构一下。因为 AI 不但会把代码改得漂亮，写好注释和命名，还可以更严格的遵守你们团队的代码规范（需要事前定义）

换句话说，从我这出来的代码，都是“完全”由 AI 完成的（最后一步）而没有任何人工调整的痕迹。这就说明这部分代码低质了？这不是一种偏见吗？

你说的价值观里“开发者仍要对自己提交的代码保有最基础的责任心”，可是这跟“完全”由 AI 生成的代码有什么冲突呢？我提交上来的代码我自然每行都看过，test case（如果有标准的话就用标准的，没有我就自己写一些）都跑通，潜在的问题都考虑好再提交的呀。

你凭什么说我没有基础的责任心呢？就因为这个代码看起来太漂亮了？？而核心的问题就是，前面已经说过了，你根本没有评价代码好坏的能力。

比如如果代码不符合你们的规范，比如引入了不该引入的库，你提出来让他改呀。

比如代码结构不够清晰易读，你指出来呀。

你自己说的“认真一读就发现与项目的诸多层面都不匹配。”，那你认真读了没有呀？

退一万步讲，如果人家提上来的代码真是直接拿 AI 跑一边就拿上来的样子货，你自己稍微跑一下不就知道到底好不好了吗？还是你连跑一下都懒得跑呀？

实际上很多办法可以快速的判断对方提出的代码是不是靠谱的办法。比如快速的看代码规范，比如看一起提交上来的 test case 是不是下功夫想了，之类的。

你只能用一个啊，这个代码看起来太漂亮了，肯定是 AI 写的，所以肯定不行来否定人家，这是人家的问题吗？

额外说点别的。时代变了。

spec coding 或者叫面向 spec 编程（古典的说法叫 TDD/BDD），它不好吗？

（给外行人解释一下，就是先确定模块的用法和特性，写出测试代码然后再写具体的业务逻辑的开发方式。这样可以非常高效的重构代码从而避免屎山的形成）

不，它很好，为什么之前推不动？因为生产性太差了。程序员连文档和注释都懒得写你让他们写 test case？？？你是不是对他们有什么不切实际的幻想啊？

但是 AI 时代这个事将成为现实。

由人类（用自然语言）来规定好模块的各种特性，然后由 AI 来具体的实现。

如果打一个比方的话，就相当于人类用更高级的语言来编程，由 AI 将其编译成高级语言。

实际上，只要有足够详细的规范，AI 自己就可以审查提交上来的代码，精度还比你高。所以你与其看见 AI 生成的代码就觉得人家不负责任，倒不如今天开始就向更实际的面向 spec 编程靠拢，或者如果说原水解不了近渴的话，至少也可以借助 AI 实现高效的代码质量审核的机制。

说人家不负责任那就拿出证据来，不要一看见人家漂亮的代码就唧唧歪歪。

最后，AI 编程有没有问题，有，暂时的 AI 并非万能。但这就是未来。

有兴趣的朋友可以试试 openspec 或者 speckit 等面向 spec 开发的套件，提前了解一下未来的工作的方式也是好的。

但是我很开心，因为很久没有被这么真情实感地“攻击”了，我甚至找回了一些早期混迹开发者社区的乐趣，大家一个个键盘敲地响，动手能力强（没有说各位是键盘侠的意思哦）。

说回正题，针对“pair with AI”这件事，大多数朋友的想法还是“既要又要”——既要积极尝试，又要做好监督管理，必要的时候还是要撸起袖子自己上：

网友：Allan

这个要看个人能力。

如果人的能力在 AI 之上，那么 AI 就是一个效率工具，这种情况下体验不错。如果人和 AI 水平差不多，那也还好，但有时候人不得不看仔细些，免得 AI 挖坑。如果人的能力不及 AI，那只能是看起来很美好，但事实上一团糟。

网友：江湖术士

让 AI 参与协作，其实前期准备工作比普通开发要复杂得多。

首先你需要有个全栈的架构，最好是类型安全。

测试最好是端到端测试，只测视图，抓大放小，并且虽然 e2e 默认是无头（看不到浏览器）的，但是需要设置为有头模式。

然后，还有一个关键步骤 —— 你需要在当前架构下，手写一部分代码作为样板。

接下来的 AI 开发流程就是：

1. 在 AI 的帮助下写端到端测试代码 —— 补全效率更高，这里不太需要 rag agent 介入

2. 给 AI 下发宏观指令：宏观指令即需求指令，直接告诉 AI 你要什么，附加“自行安排前后端代码，注意 xxxx，完成后进行 e2e 测试并迭代”

3. 不理 AI 开发过程，但当 AI 进入调试阶段时，观察 e2e 情况随时叫停

4. 单个流程效率偏低，开多个 AI 客户端并发执行（对代码架构有要求）

个人认为，在 AI 辅助开发场景下，更多需要产品和架构师思维，具体细节不需要太纠结

能不能不看代码？

你对于开发者的担忧，完全来自于其开发水平，建模架构水平的不放心

但是当你有能力搭建上诉 AI 架构，并提供样板代码的时候，这些担心都是多余的，不如把精力花在选择更聪明，上下文更多的 AI 引擎上

只要它能按照预期参考样板，调试完成代码并通过测试，代码质量本身由测试覆盖决定，你把 AI 写的代码当黑盒又如何？

这么做有些缺点，我也一并列出：

1. 无论是 claude 4 还是 gimini 2.5，包含测试代码的总代码量超过 3-4 万之后，AI 会开始循环生成（修改 A 之后修改 B，然后再修改 A，直到超时），个人认为是 AI 丢上下文，幻视，本身处理能力差导致的

2. 如果需要进行大范围修改，直接当做重写处理效率更高，比如 A 文件有个功能，你要进行大范围修改的话，不如让 AI 在新的 B 文件重构，然后删除掉 A

3. 由于 1 和 2，微架构更有必要性，大的产品需要被拆成小的独立产品，必要时你甚至能让 AI 开发好几个，选稳定的那个运行或直接动态切换

4. 即便逼不得已必须看代码，也不要直接 codereview，先让 AI 总结

很多时候我回去看 AI 生成的代码，只是兴趣爱好和磨时间，无论其写得丑陋与否，一旦不是让你继续修改，黑盒就让它黑盒吧，实现需求不就可以了么？

精品程序不能这么做？好的产品必须只用补全不用 agent？

那意味着工作量，你最好准备好足够多的 $，我认为这没毛病~

AI 并不是让程序员偷懒，而是让程序员累也要累得有意义！别得不说，常见 CURD 后台管理这种需求，以后是真没有提“复杂度”的资格。

网友：安步当车

最基本的一点，你可以让 AI 编程，但单元测试必须亲手做。

相信大家都看到过 AI 测试不过，然后魔改需求的例子。即使对接的 AI 还没这么“智能”，运动员裁判员全托管也是很危险的。

程序员如果能严格做到上述这一点，自然就会总结出什么需求适合让 AI 做，什么需求不适合；适合做的需求应该怎么拆分任务。

对于审阅者来说，跟传统方式区别其实不大，先看单元测试用例覆盖率和正确率，不合格就直接打回。

网友：国栋

第一次用 AI 写代码，想实现一个可视化功能，它秒出代码，我复制粘贴就运行——结果图表丑到辣眼，数据还错位了。气到想卸载，然后我就逐条问他，这个不好看，那个不对齐，需要配色，纠正了好久，越来越像我想要的了，并且还给我提供了思路。

后来才明白，AI 不是直接给答案的，它是与你自我纠错，自我严谨的助手，使自己扩宽思路，自我提升。

当然，尽管时不时会被平等地“创飞”，但在一次次 aha moment 的洗礼下，AI 已经收获了众多真爱粉：

网友：涵树

我自己写了一个 AI 辅助编程的工具，开发迭代快 1 年了。这个工具我没有做推广，只是自已在用，我想信如果这个工具真的牛逼，那它自然会给我的工作带来价值。

有趣的是，当这个工具的第一版出来了后，这个工具的后续迭代也都由它自己来完成。

我目用这个工具除了完成工作上的开发任务之外，也用它来做了几个应用和库，都是自用，想要什么功能就自己动手开发。

目前的功能主要有生成代码，重构，根据 git commit id 来生成改进方案，知识库切换。

最近，我又根据这个工具本身的数据输出，做了一个阅读工具，算是对数据的增值处理。

所有的这些，目前都是自用，但不得不承认 AI 在其中的有力支持。

我的 AI 工具目前用接的是 deepseek 3.2。

网友：大象爱

分享一个 AI 带给我的『aha moment』。最近读到一本书，作者在一次演讲中出了一个题目，说这个题目有点像脑筋急转弯，如果想到问题答案，会有一种『顿悟』的感觉。题目是：用 4 跟长度相等的木棍儿，拼出来 4 个等边三角形。

我想了好久，于是求助豆包，只是拍了一张截图，不到 3 秒钟，豆包就把答案告诉了我，我也如愿以偿地享受到了『顿悟』的感觉。

网友：harrison

很不错，提效很明显，可以让你的能力圈扩大。

以我的例子来说，我今年 1 月份开始在小红书做自媒体。其中很多环节都已经 pair with AI。首先，对于视频封面的制作上，目前不需要你会 ps，直接使用 Figma 或者 Canva 就能快速做封面。其次，对于视频内容字幕的生成、解说语音的生成、标题和主题文本内容的生成都可以和 AI 协作去提升效率。

然后是 9 月份自己开发了款字幕翻译的工具 Huake AI（ huake.fun），这个工具前端百分之七十都是用AI写的（cursor）。目前已经有140+注册工具，4个付费用户。

所以，总体来说，和 AI 协同工作可以很大的提升效率与扩大自己的能力圈。

网友：あん

现在工作中 ai 用的还是很多的，各种小脚本处理数据真的得心应手而且完成的很好！在 ai ide 工具完成大型项目也很好，前端 0 基础之前要开发一个分析平台，前端真的是动动嘴就可以完成虽然没有接入后端，但是页面成功打开能正常使用的时候还是很兴奋的！

至少可以让开始接触没那么熟的领域不会完全的从 0 到 1 都要自己一步步学习，缩短了很多时间！

本次故事征集告一段落。关于如何更好地“pair with AI”，我们准备了一本 AI 时代的开发提效指南。现在预约，我们会在发布的第一时间发送给你。