V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
最近这段时间看了很多关于 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 的同学， 非常希望能分享一下：
你们用的工具 工作流大概是什么样 哪些事情真的能自动化 哪些事情还是必须人工做
小弟真心求教。
 |
101
leelion6 1 day ago  1
我挺能理解你的，我本来是做 Android 开发，之前也一直是你这样用。后面我分配到其他项目没 Android 做了，从此再不写一行代码，因为让我写我也不会，全是各种 flutter 到后面前后端全栈了。
现在 Agent 用久了之后，我也是评论区大部分人的想法：真没必要坚持古法编程了，哪怕我曾经多么有代码要求代码洁癖。但现在现实就是，你至少得让 AI 做大部分工作，你只改核心小部分。如果你还在手工写那些简单的代码，那确实是不应该了 |
 |
102
andlp 1 day ago
小半年没写代码了,主要负责给 ai 架构设计一下,定义下怎么做..... 年前我都全部交给 cursor 了,现在 codex
|
 |
103
bowencool 1 day ago
试一下吧哥们，工具们都卷出花了，坚持古法编程没有意义。而且免费模型和付费模型差距巨大，不要拿免费模型的效果去代表全体 AI
|
 |
104
tomSoSleepy 1 day ago
同前端，最近老板的焦虑传导下来，从 trae 的国际个人版到 trae 的企业版再到国际个人版，现在又再切 claude Code ，给我的感觉就是快，至于准确性什么的，你别问，就是快，自己 review 快哭了，小功能不用调，比较大的关联的功能还是有问题吧，因为产品也不能确定具体业务，只能边开发边反馈修改，总得来说体验不够好
|
 |
105
teaguexiao 1 day ago 1
实际用下来感觉大多数人还是 B/C 之间，完全 D 的基本都是内部工具或者个人玩具项目。前端 UI 这块确实是 agent 最难搞的，逻辑 agent 飞快，像素级还原目前还得人工兜底。
|
 |
106
theohateonion 1 day ago 1
如果你的系统和工作流并没有很好的适配 AI ，那么你会发现 AI 很多时候会帮一些倒忙。
拿 UI 来说，如果你们没有 design system ，那么细枝末节几个 pixel 的对齐，即使 figma 导出带所有样式和结构的对象树，也很难完全复刻。相反如果你的 design system 做的很好，糊 UI 简直跟玩一样。包括测试也是，有 design system 的前提下，基于 playwright CLI 或者 agent browser 把 accessibility tree 做一份 component tree 的映射，把你需要肉眼验证的 UI 转变成结构化的数据，测试起来就完全没问题了。 再就是楼上也说过，设计和开发交接，使用 HTML 或者 SVG 而不是直接是设计稿或者图片，尽可能把设计稿转换成 AI 可读，可以很好理解的结构，这样协作起来效果也会更好。 |
 |
107
zsc8917zsc 1 day ago
如果 token 无限用....................
|
 |
109
dongzhuo777 1 day ago
什么叫全自动，一句话需求丢给他 剩下不用管 那种叫全自动
|
 |
110
DKburNIng 1 day ago
全自动可以做到，但是得流程配合+项目大改造。并且不能是 c 端项目，
我现在做 c 端前端，ui 还是得一点点调，我看接了浏览器的插件，也是截图，说实话效率不行 |
 |
112
abelmakihara 1 day ago
前端因为太杂太乱很多人根本是低估了复杂程度的
figma 切图 兼容性 而且 ui 本身不一定规范 这些全是脏活累活 反正需要负责 ui 的还是很难做 尤其是有低代码遗留产物的.本身就一坨 ai 也没什么招 后台管理系统不需要 ui 的那是做起来爽啊 那确实 vibecoding 了 我就基本 review 一下而且本身 crud 也没什么 bug |
 |
113
yichengxian 1 day ago
@zsj1029 把文档写好是关键
|
 |
114
little_cup 1 day ago 1
独立开发者，新项目还在等审核上线，预告链接在这里： 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 超越，谁知道会怎么样呢。明日は明日の風が吹く。 |
|
115
little_cup 1 day ago
用到的工具套餐：
ChatGPT $20：Web 出文档、codex 搞定时任务偶尔修 bug 。 Copilot 开源版 $10：写代码的主力。 Google One 年付：Antigravity 搞设计、文案、git 管理等。Web 出功能调研报告。 一句话经验：就像以前组合优于继承，AI 开发重构优于修改。 |
 |
116
hellopz 1 day ago
@tomSoSleepy 说明你们的基建做的不好，可以去看看 harness ，不一定要做到 100% vibe ，做到大部分场景的 ai 友好也够了
|
 |
117
xqk111 1 day ago
a 和 c 吧，复杂问题 a ，小部分简单需求 c ，主要是还是 a ，复杂问题，自己都不知道怎么改，哎
|
 |
118
Chuckle 1 day ago
写点 cli 工具、浏览器插件、司内自用软件这种，一个仓库搞定，没有复杂多包依赖关系，代码总量最多几 w 的，那现在 AI 随便写，3 天平地起高楼，也不用 cr ，自己点一点看看功能对了就行。
但是吧，司内重业务的代码，一个页面背后几十个独立包，依赖关系错综复杂，代码加起来快百万，AI 就省省吧，上下文不够的，现在的渐进式加载就会漏东西，只能辅助人处理，比如找函数的链路，某个参数到底有没有用到之类的，明确一个小功能点去改，改完几百行代码 cr 下也行，至于全自动整个需求让 AI 改就算了，包是进雷区的。 每次改这种维护了好几年的项目，就和拆弹专家一样 |
 |
119
ashong 1 day ago
不要固步自封， 最近把一个 c++项目从 windows 移植到 linux ，opencode+deepseek v4 ，效果非常好，
费用 3¥ |
 |
121
lujiaosama 1 day ago
前端复杂的工程还是需要人介入，纯 VIBE CODING 容易整成一大坨不可名状的东西。如果为了维护起来心智负担低，还得刻意限制 AI 不要炫技，塞一堆语法糖。前端界面效果测试基本上就是所见即所得，很直观，比后端舒服。但是涉及到硬件的时候，就没法让 AI 自己跑自己确认了，都是人来调试和确认。最最大的问题还是 UI ，没有设计稿跟开盲盒一样。codex 的审美太差劲了，什么直男审美。
|
 |
123
maix27 1 day ago
如果你觉得 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 协作的工程环境。 |
|
124
maix27 1 day ago
上面我讲的点都比较难落实，最简单可实现的点就是，多用 skill creator 。如果一个操作你重复太多次，就制成 skill 。然后把这些 skill 结合起来做工作流。
|
 |
125
kkth 1 day ago
看了大家的讨论，收益匪浅。赶紧去 codex 让它自己开启 agent ，然后再把 fast 打开
|
|
126
maix27 1 day ago
@Chuckle 这种项目本来就该整团队知识库，搞 harness 工程。而不是靠个人 agent 那点上下文来做。
可以参考此文 - https://openai.com/index/harness-engineering/ 不过还是能抽点小 skill ，也能提升生产力（偷懒。 |
 |
127
aresyang 1 day ago
其实科研也可以 autoresearch 了 我这个项目就跑通了 https://github.com/aresbit/rnnoise-py
|
 |
128
crackhopper 1 day ago
现在能力确实暴增，之前 方案 C 不太行。现在 方案 C 可行。尤其是如果是对于很多工作来说，并不需要多高质量的代码，AI 质量基本满足要求。claude 和 codex 我觉得都写的不错，有问题你指出来目前也能较为精准的控制具体改哪些。文档管理同步，skill 积累，反而变得更必要了。
如果代码质量要求高，方案 B 。 如果要求更高且 AI 训练库里基本见不到的模式，方案 A 。 对前端来说，大部分都是 C ，少部分 B ，很少量的 A 。我的判断是这样。 D 也可以，不过不是做产品，是快速做原型。review 也不用太 review ，让 AI review+test ，只迭代功能+人类测试一下。 |
 |
129
Eillott 1 day ago
我用光四家订阅的额度这个点刚下班。。。一天提交了过去几周都干不完的代码量，我怎么可能自己 review 得过来，都是让 Agent 交叉 review 的
|
 |
130
lingo 1 day ago 1
震惊，对话模式就已经是古法了
|
 |
131
msg7086 1 day ago
我们 org 已经基本禁止手写代码了，不管复杂简单的代码都必须 AI 生成 AI 修改。
|
 |
132
wxjzsy 1 day ago
@shoushen 同意 企业级项目我的感觉是这样的。 不知道是如何做到一把梭的，从理论上来说，也无法一把梭。 不是模型的问题，而是人根本无法一次性把需求描述的那么详细
|
 |
133
ezioswj 1 day ago
可以 chat+agent ，我开的 gpt plus ，官网 thinking 模型应该就是 5.5 ，做计划和讨论问题可以 chat ；然后将制定好的计划发给 agent 执行
|
 |
134
charlie21 1 day ago 2
现在两块代码放在这，一个是人写的 一个是 ai 写的，你告诉我哪一个是高尚的，哪一个是龌龊的？
|
 |
135
canyu9512 1 day ago
我现在也是对话的方式，我做的 app 开发，经常感觉实现的跟设计稿有差，都要自己调整，之前试过蓝湖的 mcp 以及 figma 的 mcp ，感觉也是很难实现效果一致，所以我也想大家都是怎么让 AI 实现的效果跟设计稿一致的
|
 |
136
gbin 1 day ago
我的经验是两者结合最实际。纯对话模式确实效率有瓶颈，但全自动 Agent 在真实项目里也没那么靠谱——上下文一长就容易跑偏。
我目前的做法是给 Agent 配一套 Skill （脚本+文档），让它能自己去查 Jira 看需求、读代码库、跑测试，这样它的自主性就上来了，但最终 commit 还是我 review 后才合进去。 关键不是「全自动还是对话」，而是你给 Agent 多少信息和工具——它能访问的上下文越多，自主性就越强。 |
 |
137
cocong 1 day ago
没听过用了 Agent 可以早点下班，不还是一样 996
|
 |
138
beiyanpiki 1 day ago
公司有一个 toB 的 canvas + opencv.js 的项目，是从 python 的算法移植的。想实验下全程 agent 开发是否可行，仅在需求等场景回答并输入文字，然后通过 gitee 的 issue 自动处罚修复 bug 的一整套流程。
结果就是有数不尽的 bug 和性能优化问题，很多 issue 还是得人工介入去进行修改。或许普通的网页开发或后端可能可以接管，但复杂场景或极为小众场景下的表现一言难尽 |
 |
139
wetalk 1 day ago 2
这个图 看一次笑一次
  |
 |
140
amzbasara 1 day ago
同前端，GPT team/百炼 qwen3.5 ，目前是 B+C 吧；
现在公司产品不生产文档，qwen 负责需求整理成文档，Codex 实现需求，人审核测试，qwen 负责提交日志； |
|
141
maix27 1 day ago
@wetalk 我也觉得很好笑，现在的开发者不愿意/不会学习 Agent 工作流，就跟巨婴一样在 V2EX 里发消息问怎么拿这个提效。（不是说楼主）真挺有乐子的。
|
 |
142
SilentOrFight 1 day ago
@lel020 #4 写 UI 不适合 100%自动化，出来的东西偏得很
|
 |
143
Shielber 1 day ago
以后手工的东西只会越来越贵
|
 |
144
TimPeake 1 day ago
身同感，至今不明白为啥都说前端更适合 ai 编程。如果说都是 admin 页面 UI 界面无所谓，确实是。
但大部分情况不是，UI 界面不确定性太多，诸如：UI 作图不标准 figma 无法识别、claude plugin:figma 无法自动切图、playwright 、chrome mcp 等工具，甚至蠢到调试都是自动截图 ai 识别 dom 啥的(更有甚者：“我已帮你打开 localhost:3000/xx 页面, 页面加入了 console,请打开控制台告诉我信息” 顿时都气笑了)， 也许是我使用姿势不对 ？ 个人对前端完全 ai 编程的期待：1.有个类似 figma 的平台在 agent 工具生态里能准确识别元素结构去获取设计图元素 切图啥的(目前 figma 的准确度和使用体验实在不敢恭维)。2.playwright 、chrome mcp 等自动化工具能全程自动化，比如生成页面后自动去验证 dom 结构 、样式、控制台报错等，agent 获取这些验证的信息。 |
 |
145
XinPingQiHe 1 day ago
楼主的主题很好，同问了我要跟大家沟通的问题，点赞。 目前也是 AI 辅助为主，赶紧调整到 AI 多做些工作
|
 |
146
shunia 1 day ago 2
前几楼没有一个能回答楼主问题的，但是都在千篇一律的表达“是的，agent 现在能干所有的活儿，你就是落后了”。
真的很招笑。 |
 |
148
zMeng 1 day ago
后端研发，主要工具 CC,目前基本不使用 chat 模式，对于简单的需求直接 agent 模式说清楚上下文，YOLO 模式一键执行，对于稍微复杂或者特别负责的项目，先使用 plan 模式沟通清楚需求方案，然后 YOLO 模式一键执行到底，对于你说的后端字段的变动这些，还是需要提供给 CC 作为上下文
|
|
150
maix27 1 day ago
@shunia 你看不完评论区就给 AI 总结，我在评论区看到很多人分享工作流，也没几个说 Agent 100%，非要暴论就闭嘴行吗？动不动就招笑。只有不动脑子，说暴论和喜欢随意类比的人很招笑。
|
|
151
shunia 1 day ago
@shunia #146 声明一下，我也消耗了不少 A 家和 C 家的 token ，只能说要让它做到代码上的 70%左右非常容易，frontier 级别的模型做起来轻轻松松，甚至只需要一个原生的 harness ，无需任何配置，用人话+中文说几句简单的提示词就足够了，剩下的它都能轻松做到。
|
 |
152
Bakyura 1 day ago
我觉得这个事还是得看具体业务和项目，不能简单说前端已经被 Agent 接管了，或者 Agent 其实没啥用。
同样是前端，做内部工具、做专业用户的产品、做大众 to C 产品，完全不是一个难度。内部工具很多时候流程跑通、数据别错、权限别乱，UI 粗一点也能接受，这种让 AI 一把梭出个七八成，人再检查修补下就能用很正常。但 to C 产品不一样，不好用用户就直接走了，交互、性能、视觉一致性这些还是得有人盯。 另一方面，AI 能干多少也不是固定的。项目越规整，接口文档、组件库、设计规范、测试、CI 这些越全，Agent 能放手做的事情就越多。反过来需求天天变、接口靠口头说、页面全靠感觉调，那再强的 Agent 也很难让人放心。 现在好像有个比较火的词叫 harness engineering ，我理解就是把项目环境弄得更适合 AI 干活，不只是 prompt 写得好，而是上下文、工具、测试、反馈这些都接起来。这个有点像以前提高可测性、可观测性，都是在让系统更容易被机器理解和验证。 所以我觉得重点不是“用对话是不是落后”，而是有没有把一些标准化、风险低、好验证的活拆出来交给 AI 。如果只是拿它当搜索引擎/代码片段生成器，那确实还有提升空间。 |
|
154
teaguexiao 1 day ago
后端/云基础设施这边，Agent 模式收益比前端大多了，逻辑确定的部分（ API 设计、数据库 schema 、基础设施代码）基本可以全交出去。前端 UI 还原确实是硬伤，V 友们说的对，这个不是模型能力问题而是 Figma 图层和 Web 渲染本来就不是一一映射的，差那 5-10% 只能手调。
|
 |
158
WaterMC 1 day ago
我作为产品岗的视角，看了目前的回复，我也想交流一个信息：
2026 的这四个月中，利用网页端对话输出结果的方式在辅助日常工作，但是传统的 PRD 文档输出较少，这一点就按照 0 输出来理解。 1 、模型直接输出的 单文件运行的 html demo ，直接作为可交互的原型交付下一环节。（视觉设计或者直接开发） 2 、模型输出的 demo ，代码转换到墨刀，处理原型微调，输出交付到下一环节。（视觉设计或者直接开发） 如果大家在 agent 开发中，搭档的是这样的产品同事，在开发环节是有帮助的，还是起到了反作用可以淘汰产品这一环节呢？ 为了提效的话，开发端，希望从产品环节拿到哪些规范化的信息呢？是否有格式范例，实际参考一下？ |
 |
159
OXOYO 1 day ago
在用的一套 Agent Team https://v2ex.com/t/1209315
|
 |
160
zhang2e 23h 45m ago
@shibow #3 设计别想能 100% 还原了，这个取决于设计师的水平了，设计师越懂开发，越能还原。遇到那种给整个控件加透明度、一个 view 作为背景的、所有控件都绝对定位叠在一起，不考虑布局逻辑的设计，你就偷着乐吧。
|
 |
161
RinGress 23h 42m ago
后端 C++，现存项目工程，BCD 都有，新功能或模块会更偏向 D ，不过有些涉及到业务相关的复杂算法逻辑会回到 B （有些视觉和行为逻辑的东西和 AI 讲不懂）。
但基本工作流程都是先和 AI 对需求，逐步细化设计文档和方案，然后直接开干。 AI 会把相关东西全部实现，然后自行编写测试用例，自行测试/提交，部署到测试环境按设定好的环境和测试方案文档侧。有问题会自动重复这个过程。 涉及到显存业务重构的，会 review 一下看看会不会造成兼容性问题。 但对于前端，目前设计稿还原度/测试/token 消耗这块确实还不是那么完美。 |
 |
162
Alwaysonline 23h 38m ago
需求文档 + 确认问题 + 发现问题 + 测试 + 限制 AI + AI 的工作规范。
学会表达，学会准确地描述问题，其他的可以交给 AI 。 |
 |
163
asuka02 23h 34m ago via Android
弱弱问一句: 什么样的场景才是 agent 开发。比如使用小龙虾或者 Hermes agent 之类的？
|
 |
164
thawne 23h 26m ago
@leehaoze98 人不看代码的话，一些业务逻辑比较复杂的场景，ai 漏掉一些难以发现的边界条件怎么办，或是一些脏逻辑你是怎么处理的
|
 |
165
zt4027050 22h 54m ago
@shibow 开 figma dev mode, 直接丢页面 link 给 cc ，输出精度大概在 80%以上，间距基本不用调，就是 icon 容易出问题，下载的格式有问题，忽大忽小的
|
 |
166
leehaoze98 22h 36m ago
@thawne 其实对于人而言，这个场景也可能会遗漏掉难以发现的边界条件，AI 并不能彻底解决这个问题。
回归到实际开发之前，我们先来不切实际的想一下怎么能让 AI 避免这个问题：在 AI 动手之前告诉他 “这里、这里，还有那里，有一个边界条件，开发时需要额外注意一下”，本质上又回到了一个上下文的问题，而不是一个代码层面的问题，如果你能给大模型提供这个信息，他就可以解决好你的问题。 那么到了实际开发中，只能是说以多年开发的经验，对这个领域场景的了解，虽然你不知道这块具体的代码实现是什么样的，你很清楚这里会有坑点，或者这里有边界条件、硬逻辑，然后直接提供到上下文里，让他注意一些，（这也是为什么产品或者其他领域的人虽然可以用 AI 快速产出 demo ，但是无法产出生产级项目的原因之一）。那如果说你也拿不准这块可能有什么问题，只要你能意识到这块复杂、这块可能有问题，那么就让大模型多去收集上下文信息，唯有信赖他了。至于一些类似于 Spec 驱动、Deep Module 之类的方法论，或者说传统的软件工程的各种，也只是一种方法，也并不是说能彻底解决这个问题的法子。 另外，在 AI 时代，写代码是成本非常低的一件事情，纠结之前，先起一个 claude code 让他实现一版，亲自看看效果，有问题直接回滚，然后把这次实现发现的问题，作为上下文补充进去，就像是玩游戏死了回档一样。 你可以完全不看代码，但你要清晰的知道你对这个场景/领域/功能的解是什么样子的。 |
 |
167
ZyqAlwaysCool 22h 22m ago
b+c ，个人做法是：先把需求和 ai 说明，以及要求用的技术栈/框架，让 ai 给技术实现方案，确认+多轮对话定稿技术方案后，让 agent 做实现。模型用 cc 或者 codex 的话，基本要求都能一次过，如果报错了再把日志贴给 agent 改就可以了。在关键代码片段要求 ai 做简要注释说明，大体浏览代码，看不懂的地方让它讲解一遍。体感 gpt5.4 实现很快，但命名+实现绕，经常给一坨代码
|
 |
168
imagecap 22h 19m ago
一上来就各种 ai 吹的人，大多数都是搞中转站的，不要被人带偏。AI 给的答案本身就不一定是准确的，还需要由人来验证和决策，人怎么敢把重要的东西完全让 ai 完成，这本身就是矛盾的。做些单元测试倒是个不错的工具， 因为它生成的东西，由人来跑测试确认结果。
|
 |
169
dxpy 22h 14m ago
现在基本上都是在 harness engineering 体系下进行 vibe coding ， 然后人工 review
|
 |
170
skuuhui 22h 0m ago 1
其实我也想问，ai 可以做很多事情。但是在工作中，你作为责任人如何为 AI 负责。例如 AI 没有还原 100%功能导致产品验收失败返工、很多场景没有覆盖底层 bug 没有发现导致测试一堆问题、例如边界没考虑到，由于你也没用动脑导致线上事故、AI 失控反复无法修正一些 bug 导致开发延期。这类情况你们是如何处理的。不要和我讲自己的玩具项目，那个没意义。
|
 |
171
lysShub 21h 44m ago
看情况，时间不足或者不需要自己维护，就 ai 一把梭，跑起来就行了
|
 |
172
imqiyue 21h 30m ago via iPhone
@shibow 回答你 UI 视觉的问题，我用 claude code ，通过 figma mcp 读取视觉稿，第一版出来的效果能达到 80%的还原度，如果想要像素级还原，还需要自己有一套标准的设计规范，对设计稿的要求是需要图层命名清楚规范，在提示词中着重将容易不理解的图层或元素要求明确出来，基本效果很强的
|
|
173
imqiyue 21h 27m ago via iPhone
@shibow 关于后端接口就更简单了，把后端接口变更后的 API 文档，没有就手动描述下，让网页端的 gpts 给你写成 API 文档，交给 coding agent 写就好了。甚至更简单就直接和 coding agent 说清楚哪个接口，改了什么字段、作用，就这么简单。可以自己亲身实践玩一玩，玩多了就自然而然的熟悉了。
|
 |
174
greensy 21h 14m ago
UI 蹲蹲这个话题，关于前端还原度的问题，figma 可以共享 design token 我们做稿子也按照设计规范来。维护好了扔给 AI 就行，可以靠这套规范对齐。切图问题可以先占位然后让 AI 去 figma 或者手动一下顺便走查了。现在基本就是产品原型让给 AI 画了，对接到前端感觉应该也问题不大
|
 |
175
kernelpanic 21h 13m ago
你这属于古法编程了， 为什么不信任 ai 呢，它对代码的理解绝对超过所有的人类，你来回复制粘贴不嫌麻烦啊
|
 |
176
Sundayz 21h 10m ago
@skuuhui 同样困惑，看大家讲的神乎其神，给一个文档过去，睡一觉起来 AI 全部搞定了。实际工作体验下来，AI 确实能够出色完成一些小任务，但还是需要人工介入才能稳定推进大的工作方向。
|
 |
177
fpcxsun 20h 56m ago
去年还是用 Ask 模式，今年全变成 Agent 了
|
|
179
Chuckle 18h 34m ago
@maix27 #120 有啊，搞出来挺多 AI 产品了，业务上的，还有自用的，什么需求 AI 分析，全自动创建仓库写代码提 cr ，但都还是实验，碰上实际业务需求还是难绷，知识文档都在语雀上，迭代这么多年体量已经 boom 了，而且，有些东西 AI 就是搞不了，我现在又个重构任务，20w 行 tsx 代码，好几个包，和拆炸弹一样，AI 只能辅助我梳理原来业务逻辑，harness 那文章都强调单仓库了，而且还要测试自闭环，自动化测试根本就是天方夜谭
 |
 |
180
kloudmuka 18h 11m ago
一直想知道全自动 Agent 流程是如何管理上下文的，感觉 1M 的上下文跑的时间久了也不够，70%左右的窗口差不多就能明显看到质量在下降了，如果让 Agent 在某个百分比的时候总结上下文然后移交进度，本质上其实又是上下文压缩，效果也不是很好。
|
 |
181
juzisang 17h 46m ago
前端，目前在 C ，已经很少手写代码，但是 review+测试 的成本并不低，除了不需要动手写代码，没有感觉轻松太多。
同楼上很多人问题点一样，卡在 UI 上，细枝末节问题很多，字体大小、间距、颜色、布局，有的时候能完美，有的时候又需要反反复复沟通。 但是我对 AI 拿来写逻辑已经比较有信息了，基本 review 个大概，就可以了。 目前在逐步使用 playwright 完善测试用例，希望能减少人参与的步骤，提高测试效率。 |
 |
182
jasonkxs 14h 10m ago via iPhone
一些简单的需求 ai 完全能写了，自己只需要 review 他的代码就好了，前提是能把需求说清楚，agent+skills+mcp ，尤其是前端做后台管理的，接入 figma mcp 后 ai 真能完全自己写，你就充当验收员就 OK 了
|
 |
183
frank952730 5h 55m ago
@zsj1029 前端本来就简单，不要说全自动，就一个 AI 就能替代十个你，效率，你还是想想转行干什么吧
|
 |
184
lel020 5h 3m ago
@SilentOrFight 我感觉 ok ，不过我目前 ui 要求最高的项目是让 AI 自己找安卓代码逆向出设计文档精确到像素 dp 数值然后实现鸿蒙版， 有时候做出来会差一点，基本上也能在要求重新检查对比或者明确告知哪里不对之后改好，
|
 |
185
ZhaokunZhang 3h 44m ago
不行，如果你是写后台 admin 这种完全交给 AI 就可以，尤其是内部平台，外包平台，甚至小程序也是可以的，但是 C 端的 H5 项目在样式上不可以，figma 需要设计做的很精细，才能通过 AI 实现好的效果，案例： https://github.com/f2c-ai/f2c-mcp 。
我从去年 9 月份到现在基本不敲代码（优化 AI 生成的样式除外，基本也是改改数值）。你现在对话是属于 vibe coding ，你要完成一个需求要 spec coding 方式进行近似 tdd 的开发流程。 |
 |
186
ghost3281 3h 23m ago
之前都用 copilot...这个月才开始用的 cursor 接 Claude opus 4.7 外加各种公司内部的 mcp,skills 以及一些插件 superpower 之类的感觉用起来还是可以的。我也好奇其他人都到哪一步了，claude code 用起来又怎么样
|
 |
187
zangbianxuegu 3h 15m ago
可能需要了解一下 SDD 这个概念，就能切换到以 AI 生成为主，人修改为辅。然后结合 MCP 、rules 、skills 不断完善流程。
|
|
188
teaguexiao 2h 20m ago
对话模式没什么问题，agent 模式适合明确需求的重复性任务，不确定的探索阶段对话反而更快。两种方式我都在用，按场景切换。
|
Select Language