在写代码，做项目上，站里支持 AI 的，和反对 AI 的，都有对齐 AI 在代码领域的正确使用方法吗？

[WithoutSugarMiao]

首先定义一下支持 AI coding 和 反对 AI coding 的：

• 支持者：绝大部分工作使用 AI 工具完成（百分之 90 以上），自己只是驾驶员。
• 反对者：完全拒绝 AI ，或者 AI 只是作为辅助开发；

有这个疑问是我最近在面试，我的岗位是 agent 开发，在其他帖子里有介绍，面试的结果，还算不错，年前虽然一直没结果，但是年后成功获得了两个我都比较满意的 offer ，目前已经在考虑入职的问题。

可能和我的工作内容天然以大模型为基础有关系，在面试的过程中，我遇到的公司，都会要求 vibe coding 的能力，这没有任何问题，可是我在和面试官讨论的时候，我发现好几个公司，模型用了国内的 glm 、minimax 、kimi ，IDE 用字节的 trea 啊或者其他不知名的，并且公司也没有明确的标准，就是把 AI coding 工具用起来了，他们就觉得自己 vibe 了。

但是据我高强度，使用 AI 来看，真正能合理在真实工作场景中使用 AI coding ，至少得是以下工具的组合： IDE：cursor 、caulde code 、codex （这个我自己没体验过，但是听使用的人说很好用）；
model：claude opus4.5+、GPT5.0+、gemini 系列我自己觉得差点意思，但是可以作为候补，前两个模型弄不好，问一下会有奇效；

在使用上，有注意使用细节吗？

• 先 plan 模式生成计划，通过多轮沟通将计划变成合理是最基础的
• 还需要增加 claude.md 或者 product.md 之类的 AI 沟通文件，记录每次更新的变化， 以及 AI coding 的注意事项等等细节问题。
• 在 Prompt 上姿势正确吗？模糊的需求，自己也说不清楚，是否与 AI 多次沟通；清楚的需求，是否交代清楚了细节；
• 在 debug 上有正确发挥工具的 debug 能力吗？主流工具都是支持，输入多个问题原因，工具会自动打 log 找原因，解决后会自动取消 log 。
• 一个模型解决不了的细节问题，有更换模型吗？实际使用中 claude 、gpt 、gemini 混合用 是很有必要的，它们可以互相互补，一个解决不了的问题，可能另一个就解决了。

还需要叠个甲的是，本帖没有贬低国内外其他模型工具的意思。实际上，从我的使用来看，其他模型工具与我上面列的几个差距并不大。

但是，如果你想在实际工作中使用，微小的差距，可能就是能用与不能用的区别，函数写错一个字母都运行不了，一个函数报错，整个功能就运行不了，一个功能运行不了，可能整个项目就崩溃。

也许其他工具，能做对百分之 90 的场景，但是剩下百分之 10 可能要消耗掉百分之 90 的工作时间，甚至更多，而恰恰这无法解决的百分之 10 ，让很多反对者觉得“你们怎么敢说 AI 能做百分之 80 的工作的？”

除此之外，X 刷到某个言论，我也比较认同，比较强硬的反对者（完全拒绝 AI ）可能是经验非常丰富的老开发，已经工作 20 年 30 年这种，他们不是因为顽固、固执，而是对于开发 对于写代码，基于多年的经验，有自己的理解，而 AI 是没有他们这种理解力的。

本帖不引战奥，支持者和反对者 都聊聊你们是怎么用 AI coding 的，工作都是什么应用场景

[ltmst]

最近领导在让我调研 AI 编程相关的工具集，领导们目前接触情况是：
参加了几个会议，被会上大拿忽悠的感觉 AI 编程神乎其神，能直接替代初级程序员，感觉焦虑慢慢，再不介入成本就被同行比下去了，赶紧让手下人调研。

普通开发人员的情况，网页版本 AI 改改代码片段，稍微深入点的用用 IDE ，谈不上使用工程化使用 AI 的方法论。

我个人觉得你用不用 AI 都无所谓，这取决于你的工作内容。

我们依旧招聘初级程序员，不论能力如何，注重的考察点就是是否会使用 AI 。

[baoziyucha]

其实比起 coding ，我更好奇测试方面大家是怎么使用 ai 的。以前是产品到开发，现在是多了一道，产品到开发到 ai ，很多时候不是功能问题，而是多一道造成的实现误差。开发越快这种误差越多，但是测试方面好像没有像 coding 一样发展这么迅速，给我的体感大概是 23 年 coding 的水平

[crackhopper]

我应该属于 20%支持者+80%反对者。

你说的各种方式和主流工具，我几乎都用过。技巧上问题也不大，prompt 方面我最早相关论文都看过。我自认为至少在编程方面，我的使用程度算是比较深的。

支持和反对，主要取决于自身专注的项目上。

支持者：代码和技术框架常见（开源代码多）、需求常见（同样也是开源实现多）、对产品质量要求不高（能跑起来，能验证功能和想法）、维护场景少（很多项目甚至是一次性的，比如：数据爬取、清洗、分析；一部分外包项目；个人自娱自乐项目；或者干脆是作业）。这条路上的基本都是支持者。（当然这条路也能赚到钱，需要快试+投流；显然的一点是：机会窗口有限，门槛低会非常卷，市场环境会逐渐在这些大量较低质量的产品/内容中口味变得越来越挑剔）

反对者：项目逻辑和细节复杂、技术需求不常见、对产品质量要求高、维护场景多。这条路上反对者多。主要原因是 AI 的辅助功能确实提效很高，大家也会深度使用。但是 Agent 方面能力，导致可控性变差，项目理解成本骤升，Debug 成本骤升；往往用 AI 可以快速完成项目 90%，然后剩余 10%花费超过原本时间 10 倍的时间才能解决好。综合使用下来，用辅助的效率反而更高，用 Agent 却解决不了很多细节方面的问题（注意：因为质量要求高，所以很多细节问题看起来是不能容忍的）。我个人偏这条路，曾经用 Agent 协助完成的，和项目耦合度较低但内容和设计上相对不那么常见（开源解决方案极少），最后都返工了。现在仅保留那种，确保不会污染到主逻辑的模块、或者独立的工具类项目，会采用 Agent 来推进，剩余时候主要靠 AI 的辅助和人工来推进。（当然这条路肯定也是能赚钱的，相对上面的轻快尝试的方案，更加难+重，且市场理解上的错误可能带来很大的失败；好处也是有的，沉淀和积累上会更有收获。）

我现在整体想法是，保持我的态度上相对应比例的时间投入，1：4 。用 1 的时间，快速尝试 Agent 方案，解决一些不重要问题，以及后期尝试在市场里试试。用 4 的时间，关注到主力方向和项目上，不被贩卖 AI 焦虑的人影响。

[archxm]

用 ai 来代替搜索引擎不错，90%代码交给 ai 还是算了。
ai 引入太多，少部分情况，摘除一些代码，再适当小改就可以了。大部分情况是，这什么呀，乱七八糟的，干脆全干掉

[crackhopper]

下面是我用 Agent 模式得到的一些经验：

1. 不再 DRY ，不再遵循很多设计模式。对 AI 来说，相似功能重写一套代码，灵巧复用很难。而即使代码量大，AI 也能快速阅读理解，因此修改上的难度也降低了。（但我认为，引导的人，也需要更加专业了；需要知道一个地方的修改，会引起多个位置的 bug ，需要有这种敏锐的判断）
2. 用静态语言，用工具链更完善的语言，以及公开代码更多的语言。这种语言，对 AI 更友好。（这意味着很多语言的使用度，会被 AI 偏好所影响；对 AI 来说语言学习的难度没有意义；但对很多技术人员来说，放弃自己的语言偏好，并不容易接受。）
3. 更多的测试和 review：单元测试、集成测试、e2e 测试，以及 AI 在各种位置加入 review 。（以我用 Agent 的经验来说，可以更好的驱动 Agent 收敛到自己想要的实现效果上；至于实现方式，可能非常 dirty ，大量临时的 trick 。需要通过架构能力来隔离这些污染，以及降低作为技术人员的品味。和 AI 配合不能那么“洁癖”；）
4. 更多的文档化。这点没什么好说的。我在用 Agent 模式，会专门维护 AI 的计划文件夹和常用 prompt 模板。以及写好的代码让它多 review 产生模板。
5. 比起使用 mcp ，更多可以考虑使用 cli 工具。（后者可用范围更广，前者还需要支持 mcp server ；并且对 AI 来说，好的 cli 输出更多，不太影响它的理解和执行；并且 CLI 其实人类也方便用）
6. 更多的管理工作。把 Agent 当成多个初级技术人员，每个有自己的偏好。因此，管理上，多强调规范，但也要能容忍代码上的各种微妙细节的问题。对文档也要及时更新。其实管理工作本身，似乎也可以用 Agent 来解决。（这块我没太尝试）

上面这些是我用 Agent 模式自己的+看到别人的，得到的总结。最后就是期待 AI 进一步降本增效，以及我能更加精进我协调 AI 的能力，比如在项目上做更好的抽象分离，让更多模块可以被 AI 做而不会影响人工的模块（目前对我来说还是挺难的，可能我技术能力不够；我目前整体还是用 AI 辅助，少量模块才会 Agent 模式）。

[luanfujian]

新项目 vibe 老项目辅助 这东西要看具体来啊 不是一下子划分出来的

[catinsides]

目前新项目用 opencode + MiniMax M2.5 能 hold 住。需要 review AI 的代码，发现问题告诉 AI 修复。需求做完了再开个 Agent 写测试，效率很高。

[swananan]

plan 目前还是需要的，要求 ai 对齐细节，不然很容易失控，生成不符合要求的代码。
另外，就是尽量赋予 AI 自动获取信息的能力，比较经典的就是 AI 可以自己跑 e2e 测试，自动分析原因，自动修改验证，一条龙服务。
codex 写代码很强，量大管饱，每个月 20 刀，我交的心甘情愿。

我之前写了篇博客，一起交流一下：
https://jt26wzz.com/posts/0013-ai-coding/

[ty29022]

有的人项目连个正经的 PRD 都没有，没有单测，烟测，回归
一个迭代了很久的五花八门的代码风格，各种隐疾，不合理的暗坑
一句模棱两可需求就让 LLM 吭哧吭哧开干， 完了吐槽大模型是垃圾
garbage in, garbage out 的逻辑在 vibe coding 时代显得无比正确

[Mandelo]

不同水平的人用同样的 ai ，那代码必然也是不同的。水平高的人考虑的细节更多，提示词写的更详细，代码肯定更健壮。

[shunia]

test driven 、human review/take over 都不提的吗？

那你说那么多也是纯 vibe 啊兄弟，毕竟 AI 工具说的再好，也都是盲目自信，就像你说的，即便是顶尖模型也要和合适的工具配合，不然就是能用和不能用的区别。人和流程怎么介入以保证结果的正确性，可用性，才是能把 AI workflow 落地到生产的最重要因素吧？

[loopq]

@swananan #8 老哥点击你的文章发现之前看过的并且分享到内部研发群了，写的真不错，当时第一次知道心流这个词汇，且后续确实遇到了这个问题，等着命令行输出，打断完整的编程流程，所以我现在偶尔不想让 AI 写代码，自己写还是有一些乐趣。当然更多的时候，几句话几轮交互就能出来一个完整的功能是更爽的过程

[faceRollingKB]

同意楼上 1：4 的观点，crud 类型的重复工作我也是让 ai 自己干，干完我简单测下就行，复杂点的我自己主导，遇到算法、图表让 ai 写个 demo 再自己加工

[byweilong]

caulde code ，claude.md 、silkk 那些怎么写？自动生产还是人工维护，最佳实践有没有推荐的

[sprinng]

https://github.com/doccker/cc-use-exp 希望能帮到大家哦~

[aprilwei]

之前用 TRAE 写 ruby 项目，不太行，估计是网上 ruby 项目太少，训练不足

[Clannad0708]

我说一个，你所谓的 vibe coding 我觉得拉着隔壁 linux 站随便一个佬友出来都是顶级的 AI 使用者。CPA+codex+cc+germini 结合起来解决问题。自动化 skill ，agent ，提示词层出不穷。

再说一个 AI 开发和传统开发的事情，
上周六晚上参加了一个北京的 cursor meet up 的活动。cursor 的工程师（在职）来分享使用 agent 的技巧。清华毕业去美国深造然后去过 google ，大厂最后去了 cursor 做 IDE 。他亲口说，之前他还觉得 AI 写代码不如他。3-4 个月前，他发现自己在写代码这块已经比不上 AI 了（顶尖的模型） cc 4.6 codex 5.3 等。

大部分人觉得 AI 开发不太行主要是使用姿势有限，可能就是打开问问题，再或者像楼主这样，cursor 的开发者当时分享了一些自己开发的技巧。

[009694]

不要一开始就 plan 。 你的脑袋一片空白 plan 个啥，你先聊 哪怕是跟普通的 chat 模型聊，在你的脑海里构建整个交互流程，，弄明白了再去 plan 。 ai 代替你去做 coding 了，那你就捡起产品的活 哪怕只有一部分

[darksword21]

开发肯定是用 AI 的，我是 80% 支持 20% 反对

使用姿势基本是：claude code 20$ 主力 + codex/gemini 20$ 量大管饱，编辑器 Emacs （ review + 手动等

plan mode 是需要的，需求不必说的非常清除可以一点点改，最终版文档存到 repo 中

不考虑国内模型，没时间和经历调研哪个好用，直接交钱用世界上最好用的（公司限制或者给买除外

plan 的时候能感觉到 AI 能不能处理这个问题，如果说了几轮了还不理想就不会浪费 token 了，自动手动来

用 setting 限制 AI 执行 git push 和 Read 敏感文件（存 ak sk 的文件等

20%反对：包括上面说的 AI 处理不了的情况+个人学习需求，不会无脑 AI

[JoJoWuBeHumble]

我自己尝试很长时间，用 AI 很爽，但是不代表没有任何隐患。
原本程序员开发，有很多设计模式，有很多规范之类，都是为了代码的可读性和可维护性。
问题你在 vibe 时候，如果不给出非常明确的的指令，它的做法往往非常的简单粗暴。
你仔细去看它，会有很多重复方法，也会有我们很讨厌的 if 嵌套之内的。
但是，它下次在看代码，它能知道自己写的是什么。但是你呢？如果那天环境不具备使用 vibe 环境怎么办？
我现在往往在第一轮完成需求之后，会进行它编码评审，会让他进行重构，提高代码的可读性和可维护性。
如果单纯的达到目的就不管了，我个人觉得是非常的不负责的。
现在 vibe 就像智能驾驶，一般没事，有事就是大事。每个人是自己的生命的第一责任人，不要低估智能驾驶可能的风险