现在网上都在说 Agent 自动开发，我还是在对话模式，是不是落后了？

[shibow]

最近这段时间看了很多关于 AI 开发的文章、博客、视频， 尤其是各种 Agent 工作流 的分享。

比如：

AI 自己拆任务 AI 自己写代码 AI 自动做 code review AI 自动提交 PR AI 管理整个项目流程

甚至有些文章给人的感觉是：

人只需要把需求说清楚，剩下的事情 AI 自己就能完成。

说实话，看多了之后，我开始有点焦虑了。

先说一下我的背景：

我是一个前端开发工程师， 使用 AI 辅助开发大概有 一年半左右 了。

平时主要工具是：

Claude GPT Cursor Windsurf

基本每天都在用，也算是比较重度用户。

但我目前真实的工作方式，其实还是：

人主导开发 + AI 辅助 主要是对话模式

比如：

写代码的时候遇到问题就问 AI 让 AI 帮我优化一段逻辑 让 AI 帮我 review 一段代码 或者生成一些基础结构

整体感觉：

AI 很强，但更像一个：

非常聪明的助手，而不是一个真正能接管项目的“开发者”。

我现在的困惑主要有几个：

1 ）现在真的有人在用 Agent 自己写代码吗？

不是 demo ， 而是：

在真实项目里长期使用

比如：

前端项目 后端服务 中大型系统

而不是一个简单的脚手架项目。

2 ）现在的开发流程，真的变成这样了吗？

比如：

人只负责写需求 Agent 自动拆任务 Agent 自动写代码 Agent 自动测试 Agent 自动提交 人只负责最后确认

如果真有人这样用，我非常想了解：

这个工作流到底是怎么搭建的？

3 ）前端和后端的差别是不是很大？

我有一种感觉是：

很多文章里的 Agent 工作流， 可能更偏：

后端 AI 工程 Python / Node 服务 工具链开发

而前端这边：

UI 交互 状态管理 兼容性 复杂业务逻辑

可能还比较难做到完全自动化。

但这只是我的猜测，不确定是不是事实。

4 ）大家现在真实的 AI 工作流到底是什么样的？

比如：

你们现在更接近哪种模式：

A ） 人写代码 + AI 辅助

B ） 人设计结构 + AI 写大部分代码

C ） Agent 负责模块开发，人负责 review

D ） Agent 基本可以接管项目

我不是质疑 AI 的能力。

只是看了太多“AI 自动开发”的文章之后， 开始有点不确定：

现在行业真实的状态，到底是什么样的？

是：

大家已经进入 Agent 自动开发阶段了， 还是说大多数人其实还是：

对话模式 + 人主导开发

只是没有人专门写这种“普通但真实”的文章。

如果有在实际项目里长期使用 Agent 的同学， 非常希望能分享一下：

你们用的工具 工作流大概是什么样 哪些事情真的能自动化 哪些事情还是必须人工做

小弟真心求教。

[leelion6]

我挺能理解你的，我本来是做 Android 开发，之前也一直是你这样用。后面我分配到其他项目没 Android 做了，从此再不写一行代码，因为让我写我也不会，全是各种 flutter 到后面前后端全栈了。
现在 Agent 用久了之后，我也是评论区大部分人的想法：真没必要坚持古法编程了，哪怕我曾经多么有代码要求代码洁癖。但现在现实就是，你至少得让 AI 做大部分工作，你只改核心小部分。如果你还在手工写那些简单的代码，那确实是不应该了

[andlp]

小半年没写代码了,主要负责给 ai 架构设计一下,定义下怎么做..... 年前我都全部交给 cursor 了,现在 codex

[bowencool]

试一下吧哥们，工具们都卷出花了，坚持古法编程没有意义。而且免费模型和付费模型差距巨大，不要拿免费模型的效果去代表全体 AI

[tomSoSleepy]

同前端，最近老板的焦虑传导下来，从 trae 的国际个人版到 trae 的企业版再到国际个人版，现在又再切 claude Code ，给我的感觉就是快，至于准确性什么的，你别问，就是快，自己 review 快哭了，小功能不用调，比较大的关联的功能还是有问题吧，因为产品也不能确定具体业务，只能边开发边反馈修改，总得来说体验不够好

[teaguexiao]

实际用下来感觉大多数人还是 B/C 之间，完全 D 的基本都是内部工具或者个人玩具项目。前端 UI 这块确实是 agent 最难搞的，逻辑 agent 飞快，像素级还原目前还得人工兜底。

[theohateonion]

如果你的系统和工作流并没有很好的适配 AI ，那么你会发现 AI 很多时候会帮一些倒忙。

拿 UI 来说，如果你们没有 design system ，那么细枝末节几个 pixel 的对齐，即使 figma 导出带所有样式和结构的对象树，也很难完全复刻。相反如果你的 design system 做的很好，糊 UI 简直跟玩一样。包括测试也是，有 design system 的前提下，基于 playwright CLI 或者 agent browser 把 accessibility tree 做一份 component tree 的映射，把你需要肉眼验证的 UI 转变成结构化的数据，测试起来就完全没问题了。

再就是楼上也说过，设计和开发交接，使用 HTML 或者 SVG 而不是直接是设计稿或者图片，尽可能把设计稿转换成 AI 可读，可以很好理解的结构，这样协作起来效果也会更好。

[zsc8917zsc]

如果 token 无限用....................

[jimx]

@sampeng 同 Android ，思路不错，参考实践一下

[dongzhuo777]

什么叫全自动，一句话需求丢给他 剩下不用管 那种叫全自动

[DKburNIng]

全自动可以做到，但是得流程配合+项目大改造。并且不能是 c 端项目，
我现在做 c 端前端，ui 还是得一点点调，我看接了浏览器的插件，也是截图，说实话效率不行

[huaweii]

@bowencool 古法和全自动之间还有很多档的半自动好吧😅

[abelmakihara]

前端因为太杂太乱很多人根本是低估了复杂程度的
figma 切图 兼容性 而且 ui 本身不一定规范
这些全是脏活累活
反正需要负责 ui 的还是很难做
尤其是有低代码遗留产物的.本身就一坨 ai 也没什么招
后台管理系统不需要 ui 的那是做起来爽啊 那确实 vibecoding 了
我就基本 review 一下而且本身 crud 也没什么 bug

[yichengxian]

@zsj1029 把文档写好是关键

[little_cup]

独立开发者，新项目还在等审核上线，预告链接在这里： https://x.com/1ittlecup/status/2048416862334320674 这么多如果详细写出来都要翻页的功能和交互，第一版实际开发耗时一周半。

第一次纯 vibe coding ，最初强行忍住了自己看代码改代码的冲动，现在甚至连 git commit 都让 AI 自己 review 拆分提交。

工作流是这样的：拿需求和 GPT 5.4/5.5 （网页）讨论，生成 md 文档，喂给 copilot GPT 5.4 开发，然后验收，提 bug 和改进，如果 >3 轮还改不好就换 claude 甚至 gemini 来 review ，同样出 md 方案，执行者只有 GPT 5.4 一个。

UI 设计 GPT 确实全系列不太行，Claude 好得也有限，会让 Gemini 3.1 Pro 做设计（后来发现审美上 Pro 和 flash 没什么差别，flash 还快很多），反复微调验收后 GPT 重构。

另外量大管饱的 Gemini 3.1 flash 根据多语言的需求 MD 定期改文案，定期自行拆分 commit

每日上半夜，codex 导出所有工具中的当日 prompt 记录，整合分析生成 TODO.md ，我在想后面还可以拿来完善测试什么的。

下半夜 codex 定时重构今日的所有 commit ，修复 TODO ，维护文档、读 logcat ，配合 computer use 测试基本功能，最多在 prompt 里加点「请关注 CPU 占用，凡是可以事件驱动代替轮询的一律改写为事件驱动」之类的经验。

除了最后的成品 app ，不论文档还是代码，凡是 AI 生成的都应该 AI 去解读，人不要插手。

只要认清了代码是给机器执行的，而不是给程序员审美的，那么 AI 的代码一点也不烂。

自己评估认为质量不低于古法编程，但前提是这里面 99% 的功能都是我能写的，而且写之前我就大概知道难点在哪里了。文档里会给出核心思路、关键词和算法。

项目里有个 reference/ 目录，clone 了非常规技术所需的所有开源和闭源（我自己的）项目代码，让 AI 自己参考。

然后 UI 设计应该摒弃 1:1 复刻设计稿的想法，我认为按「产品 - 设计 -技术」分工是属于人类的交互流程，和 AI 的话，多让它反复创作，最多提点灵感，作者用自己的设计品味把关选择就好。

以上流程估计就适用于今年吧，等到不久的将来，人类最后的经验和品味被 AI 超越，谁知道会怎么样呢。明日は明日の風が吹く。

[little_cup]

用到的工具套餐：
ChatGPT $20：Web 出文档、codex 搞定时任务偶尔修 bug 。
Copilot 开源版 $10：写代码的主力。
Google One 年付：Antigravity 搞设计、文案、git 管理等。Web 出功能调研报告。

一句话经验：就像以前组合优于继承，AI 开发重构优于修改。

[hellopz]

@tomSoSleepy 说明你们的基建做的不好，可以去看看 harness ，不一定要做到 100% vibe ，做到大部分场景的 ai 友好也够了

[xqk111]

a 和 c 吧，复杂问题 a ，小部分简单需求 c ，主要是还是 a ，复杂问题，自己都不知道怎么改，哎

[Chuckle]

写点 cli 工具、浏览器插件、司内自用软件这种，一个仓库搞定，没有复杂多包依赖关系，代码总量最多几 w 的，那现在 AI 随便写，3 天平地起高楼，也不用 cr ，自己点一点看看功能对了就行。
但是吧，司内重业务的代码，一个页面背后几十个独立包，依赖关系错综复杂，代码加起来快百万，AI 就省省吧，上下文不够的，现在的渐进式加载就会漏东西，只能辅助人处理，比如找函数的链路，某个参数到底有没有用到之类的，明确一个小功能点去改，改完几百行代码 cr 下也行，至于全自动整个需求让 AI 改就算了，包是进雷区的。
每次改这种维护了好几年的项目，就和拆弹专家一样

[ashong]

不要固步自封， 最近把一个 c++项目从 windows 移植到 linux ，opencode+deepseek v4 ，效果非常好，

费用 3¥

[maix27]

@Chuckle 公司就只有你个人用 AI 吗？没有 AI 基建吗。。。

[lujiaosama]

前端复杂的工程还是需要人介入，纯 VIBE CODING 容易整成一大坨不可名状的东西。如果为了维护起来心智负担低，还得刻意限制 AI 不要炫技，塞一堆语法糖。前端界面效果测试基本上就是所见即所得，很直观，比后端舒服。但是涉及到硬件的时候，就没法让 AI 自己跑自己确认了，都是人来调试和确认。最最大的问题还是 UI ，没有设计稿跟开盲盒一样。codex 的审美太差劲了，什么直男审美。

[whyw]

@izzzz 我在里面内置了 windsurf 等登录, 但我没这个订阅, 全 codg + opus 写的代码没测过, 不过大概率正确, 可能有小 bug

[maix27]

如果你觉得 AI 不好用，可能不是 AI 本身不行，而是你还没有用上当前主流的工作流。

今年上半年，很多开发者已经不是单纯把 AI 当聊天工具用了，而是把它接入到实际开发链路里：代码仓库、设计稿、浏览器调试、Issue 、文档、团队协作工具，以及自动化任务。

所以在评价 AI 是否“顶用”之前，至少应该先了解一下当前 Codex 、Claude Code 这类工具的典型工作流：上下文怎么配置，仓库怎么接入，任务怎么拆分，Agent 怎么执行，以及如何用浏览器、设计稿和测试工具做闭环。

以我现在的使用方式为例，我更偏向 B + C 模式：不是只让 AI 回答问题，而是让它参与完整的开发流程。

前端场景里，一个比较典型的用法是：先在 Figma 中建立设计系统，再让 Agent 通过 MCP 读取设计稿和设计规范，直接生成或修改页面。之后再结合 Playwright 这类浏览器工具，让 Agent 自己查看视觉效果、发现偏差并继续调整。Codex 官方文档里也有类似的 frontend designs use case 。

更进一步，Agent 还可以接入 GitHub 、Slack 等团队工具，定时拉取与自己相关的 issue 、PR 或讨论内容，然后辅助修复 bug 、开发功能，甚至做一部分例行维护工作。

所以我不太认同“AI 不顶用”这种笼统判断。更准确的说法应该是：
AI 的效果高度取决于使用方式、上下文质量、工具链接入程度，以及团队有没有相应的 AI 基建。

如果只是把 AI 当成一个问答框，它当然容易显得有限；但如果把它放进完整的工程工作流里，它的价值会明显不一样。

当然，Agent 也不是天然好用。不好用可能有两类原因：一类是工具本身能力不够，另一类是使用方式和基础设施还没跟上。很多时候，问题不完全在个人，也可能在团队没有搭好适合 AI 协作的工程环境。

[maix27]

上面我讲的点都比较难落实，最简单可实现的点就是，多用 skill creator 。如果一个操作你重复太多次，就制成 skill 。然后把这些 skill 结合起来做工作流。