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

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

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

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

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

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

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

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

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

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

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

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

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

下面是我用 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 模式）。

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

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

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

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

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

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

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

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

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

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

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

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

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

我说一个，你所谓的 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 的开发者当时分享了一些自己开发的技巧。

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

开发肯定是用 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

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

你倒好，让大家讨论，第一句话就把大多数的人排除了。

模型和模型之间也是有差别的
我建议大家在分享使用感受和心得的时候可以先说用的是什么模型
不然可能都是在各说各话，说 AI 厉害的是一种模型、说 AI 不行的是另一种模型

我觉得需要想好干什么事情用什么 ai ，否则浪费钱也不一定能做好业务，比如业务流程审核，这种东西不一定需要最贵的商业模型，只要找一些逻辑思维好点的模型即可，写代码不一定 ai 完全接替，第一确保代码可读性，好维护，可以狠狠操那种过度抽象设计的代码了，其次是代码重复检查，工具类这种轮子代码就可以稍微大胆一点让 ai 写，自己测试边界问题有没有，还有什么阻塞和效率的问题讨论一下，最后就是查 BUG ，至少速度快啊

100%支持者，并推动公司所有开发人员全面转为全栈开发。短期内前后端还是分离，但是 1 年后基本需要完成转型。每个人需要有更强的处理业务的能力。

@crackhopper 兄弟对 AI 辅助编码很有见地啊，需要长期维护的复杂项目是不可能 vibe 的。推荐你试一下 tocoai ，这款工具主打设计驱动开发，通过图形设计框住程序架构，复杂工程用这款工具是有解决路径的

@ltmst 那感觉你们还在初级阶段，可以成规模的使用 IDE+好点的模型，来探索一下。


@baoziyucha 没理解兄弟说你的这个测试方面怎么使用，是什么意思。是说测试人员怎么使用 AI 来完成吗？


@crackhopper #3 棒！兄弟，我发这个帖子 主要就是想了解一下“项目逻辑和细节复杂、技术需求不常见、对产品质量要求高、维护场景多。这条路上反对者多。”这个具体是什么项目，需要实现什么功能，技术需求是什么，我就想自己试试，如果是我来用 现在的工具 能否 hold 住这种场景。因为我在用 claud4.5 开始，就没怎么再遇到自己没办法用 AI 工具解决，反而自己解决不了的事情。我分不清是我自己菜，所以才觉得工具万能，还是别人其实压根不会使用工具。


@archxm “AI 引入太多” 是用的什么模型，有加让它保持代码整洁之类的提示吗。


@crackhopper #5 真棒。第一点我也发现了，所以我在给 AI 的指南里，会给他标出项目整体架构，具体到某个文件是做什么，文件中都有什么功能的函数，并且在 plan 阶段，给它修整不合理的地方。第二点因为我几乎只用 python ，而 python 对 AI 来说更友好，所以我用起来比较舒服，第三点，我之前古法代码 有写集成测试的习惯，所以现在 vibe ，也会一并把测试带出来。之后我们使用方式差不多。


@luanfujian 老项目不能 vibe 吗，能简单讲下如何使用的吗？


@catinsides 真棒！


@swananan 把博客认真看完了，写的确实很好，我觉得基本上我们的理解大部分都是一致的。我觉得以现在 AI 的能力，管理好上下文，是没有项目解决不了的，并且越复杂的项目使用 AI coding 收益就越高。但是对于人的要求也越高了。我在 X 刷到到过一个观点，他说 AI coding 不是抹平了不同级别开发人员的差距，而是加大了开发人员的能力差距，初级工程师用了 AI 能力乘 10 ，而高级工程师用了 AI 能力乘 10000 。


@ty29022 额，这就有点抽象了。我的理解是 LLM 始终是工具，正确的使用工具，才能算作是 vibe coding 。一句模棱两可的需求，就算是人也干不好吧。


@Mandelo 是的。


@shunia 不好意思，其实我没太明白你的意思。测试和 review 是写代码的一部分，我觉得和 vibe 不 vibe 的好像没有什么关系？


@faceRollingKB 棒 正确做法！

@byweilong 这是另一个复杂的话题了，一篇帖子不好回复。

@sprinng 点了。

@aprilwei 也可能是 trea 不太行，换我帖子里的三个试试。

@Clannad0708 唔 你可能误会我的意思了。我说的 vibe coding 只是基础的姿势，不是我真的工作中就用这点，实际我在工作中要负责很多，甚至会自己维护 AI cache ，但是我觉得这些已经比较超出基础水平了。AI 开发不行的人（比如评论中的说 老项目维护 AI 只能辅助的），可能是他们姿势有问题，所以我分享了一下基础的配置。如果是使用了这些基础配置还觉得 AI 不行的人，我比较好奇，他们的工作是什么，为什么和大部分很厉害的高手都背道而驰。虽然我在北京，但是北京 cursor meet 刚好有事没去上，可惜。

@009694 哈哈哈 我确实会先跟 AI 聊 再 plan ，但是我没有说，是因为不是所有人都需要的，很多人拿到需求，本来就有思路的，不是所有人都需要和 AI 先交流。

@darksword21 棒！

@JoJoWuBeHumble 所以需要正确的使用姿势。

@ooee2016 额，没理解啥意思。

@YangWaleed 是的，所以我先把用的模型写在前面，哈哈哈。

@jackOff 和我不太一样，我是直接就用最好的。省的费劲 哈哈哈。

@17681880207 nice 。

我已经放弃跟任何人争论这件事…没意义。认同的一定会认同你，不认同的一定会找八百个理由。我在身边包括我自己是深刻理解不同人用得到结果就是不一样，哪怕 skill ，工具，架构文档都完全一样。因为每个人看待一件事一定是不一样的。

所以做好自己的…我提升效率，我为什么要关心别人觉得这玩意是垃圾呢？放下助人情怀，尊重他人命运。就当不认同的人说的对吧，ai 泡沫炸了我们这群 ai 认同就被干掉了。古法编程才是编程，我是在混日子。