以往使用 AI 都是开发新功能，最近接收一个公司内部的 AI 内部项目，需要进行大规模重构以适应未来的某些新需求。
我让 Claude 和 GPT 各生成了两版方案，也让它们都按照各自的方案实现了一遍，目前看起来功能没什么问题。 但我非常恐慌，因为我对 AI 写的代码无从下手，没有了以往的掌控感，各种数据流向完全没搞明白。
最主要的是，我对 AI 的方案不满意，但我自己也给不了更好的方案，第一次觉察到自己的能力如此薄弱，只会写点简单的 CRUD ，架构抽象和状态建模能力是一点都没有，唉....
 |
1
94 Aug 20  1
可以让 AI 生成项目 Wiki 给你看哇。M 类型的岗位不一直都是这样吗，不可能清晰知道每一个代码细节，但是会知道业务和数据流转。
|
 |
2
exc Aug 20 1
"各种数据流向完全没搞明白", 是这样的, 我已经不抱希望了, 测试能通过就完事了
每次看 AI 生成的方案, 血压都高了, 不看还好点, 看了也没啥用, 一旦 session 基调定了, 后面怎么纠正, 用处都不大 |
 |
3
foryou2023 Aug 20 1
没啥恐慌的吧，真恐慌，很简单的，让 ai 出详细的文档就行了，不懂的地方就问 ai 。
个人现在的认知就是很确信 ai 大部分时候比自己做的好，能力已经远超自己的，相信 ai 即可。 保底的解决方案，就是说自己是小白，什么都不懂，让 ai 出一份详细通俗易懂的文档即可。 |
 |
4
lucifer9 Aug 20 via iPhone 1
如果对方案不满意，但又无法清晰表达出哪里不满意的话
建议换位思考一下，即把 AI 当成过去的自己，把现在的自己当做是产品经理或者客户试试 |
 |
5
duanxianze Aug 20 1
可以继续和 AI 聊啊，AI 辅助学习新技术非常好用，感觉比直接让它写代码更有用
|
 |
6
piaooo Aug 20 1
项目不懂的用一个低档的模型直接问他 codex 有一个侧边的临时聊天功能
|
 |
7
msg7086 Aug 20 1
骗你的，其他人的能力也如此薄弱。
高质量 AI 模型的知识量远远超过你，他看过的项目设计比你吃过的盐还多。 你对方案不满意，那就说出不满意的点。Claude 和 GPT 也可以互相对抗审核。 反正实现之前你总要跟 AI 做反复拉扯头脑风暴吧。（别跟我说你就只是让他们一炮生成出方案就开始实施咯？） |
 |
8
ntdll Aug 20
>> 我对 AI 的方案不满意，但我自己也给不了更好的方案
有点困惑，这是为什么呢，既然你没有更好的方案，是出于什么原因，认为当前的方案不好呢。只是因为这是 AI 写的嘛？ |
 |
9
Enter3211 Aug 20
不错了，能察觉到不对。
|
 |
10
Orris OP @ntdll 不是因为 AI 写的所以我认为这个方案不好，反而绝大多数情况下 AI 的方案比我的更好。 这次觉得 AI 的方案不够好，是因为 AI 给出的方案有点过度设计了，原本一个不是很复杂的功能，被它拆分出十几个方法来调用。
虽然原本写的东西也是一坨大便，但真没必要拆分的这么细，改个功能得跳转 N 行。 但让我给出更优的方案，我也给不出来，这十几个方法都还拆分的挺恰当。 |
 |
12
liushengxian1230 Aug 20
害 回退到之前 AI 能力没那么强的时候的协作状态就好了，大方向自己把控。天天史上雕花的我一直这个使用习惯，反倒是现在开新项目迁移了，准备放手给 AI 去做了
|
 |
14
lllllllccccccc Aug 20
我目的的方式就是让 AI 分析需求，生成文档，然后手动核对调整文档，AI 调整文档到我认为符合预期，然后 AI 开发，然后开发的时候多打日志，然后结合日志实际输出核对功能实际行为是否符合预期，不符合预期就调整
|
 |
15
Fish1024 Aug 20
没啥啊。你的领导也不知道你代码怎么写的啊。
|
 |
16
novaline Aug 20
人的上限决定 AI 的上限
|
 |
17
quicksandznzn Aug 20
和楼主遇到了一样的感受。
今天跑光了一个 codex plus 额度还是没有让自己满意，深深的感受到自己的不足。 |
 |
18
generated Aug 20
不是 AI 的问题，是重构本来就很麻烦
|
 |
19
CDC2077 Aug 20
我现在都是测试通过就得了，感觉退化了很多
|
 |
20
HotieCutie Aug 20
这个真的是没办法的事，既然用了 AI ，解放双手，解放脑力，就得承受可能会出现的问题，只能寄希望没有任何 bug
|
 |
21
Charlie17Li Aug 20
同感，过度设计，md ，我一个内部平台，各种安全性考量设计，机制复杂
|
|
22
msg7086 Aug 21
@0x114514 #10 #11
过度设计也是一个可以拉扯的点啊。 你就和 AI 说，我想要简化设计，不要弄那么多方法，帮我看情况合并一下。 但是话又说回来了，改个功能跳转 N 行，又不需要你跳转，AI 改代码你还要帮他考虑跳转 N 行的问题吗。 |
 |
23
passive Aug 21 via Android
vibe 之前先 grill me 做好粗略的设计，写通一遍能用的版本 commit 了，再跟 AI 一起 review/refactor 架构、命名、文档
|
 |
24
maolon Aug 21
你需要参考 matt pocock 的 skill 的方法论来做设计操作，尤其是 wayfinder 就是一个最好的例子。
你跟着他的流程做一遍自己脑子就有整个流程图和大概的模块的思路，和哪里需要削减了。 ai 做设计最忌讳就是一次性把所有模块一起设计完，这样既管理不到细节，也因为生成的文档量太大了整体也把握不好。 |
 |
25
sugars Aug 21
再用几年怕 for 循环都忘了😅
|
 |
26
craftsmanship Aug 21 via Android
只会写点简单 crud🫠
|
 |
27
zhouweiluan Aug 21
头像真的很应景了
|
 |
28
amwyyyy Aug 21
未来就是这样的开发方式，AI 会越来越强，根本没必要看代码，也不一定是程序员在开发了
|
 |
29
davelm Aug 21
模型 A 写代码出项目 wiki ，模型 B 根据项目 wiki 挑刺 A 写的代码，出具复核意见，让模型 A 驳斥 B 的复核意见，重复几次到模型 A,B 说的纯粹是鸡蛋里面挑骨头就算通过了，这个时候你对项目的构建，就了解的差不多了，你的作用就是模型 A 和 B 之间的小人，想办法让他们打起来，我司就是根据这套理论构建了一个自动化的流程，除了贵，没啥缺点
|
 |
30
walter19 Aug 21
抓大放小，业务域、业务流程、状态机清楚就行，还有测试用例生成后先人过下
|
 |
31
jimbray Aug 21
改旧代码确实有点慌，在屎山上雕花很恐怖
|
 |
32
zeroli Aug 21 1
 |
 |
33
skuuhui Aug 21
你不需要对方案满意。ai 的应该不是应该由你去承担。多想一想周末去哪里玩，预祝你周末快乐
|
 |
34
jackOff Aug 21
其实我觉得 ai 时代更安全可靠的开发架构就应该是微服务架构，每个服务只负责一个业务，然后调度中心的网关稍微上点心写，这样子 ai 在每个微服务里拉屎也能把风险隔离开
|
 |
35
ajaxfunction Aug 21
我不会写 nuxt ，让 ai 给我写好了，就算让我看，我也看不懂啊
|
 |
36
aino Aug 21
我时常看见 AI 写的一大坨代码恐慌，期望别再往这里再增加需求了，丢失了掌控感
|
 |
37
zhangli2946 Aug 21
让它跟你解释，与你 心智对齐。
让它补全文档，说明模块划分和 模块间组织关系。 让它提供方案，分析决策影响和技术债务 |
 |
39
jonsmith Aug 21
一样的兄弟，时常看不懂 AI 写的代码，特别是体积庞大的老系统，里面的业务逻辑弯弯绕绕，只能交给 AI 写了。
|
 |
40
yarawen Aug 22
我一直主力用的 copilot ，乍换成 Codex 就有这种感觉。
看到 OP 的帖子也对比思考了下， Codex 的工作流程缺少一种 可观察性，跳跃，等了几分钟等到一个结果，为什么改？不知道。 这确实很容易给人挫败感。 讨论了下，给 agents.md 加上这段， 看看效果，抛砖引玉，也给 OP 提供一点思路。 ## 可观察工作流 - 开始前：说明正在检查什么，以及判断标准。 - 得出结论时：立即告诉我证据，不等全部做完。 - 修改前：列出准确文件、当前内容、准备改成什么，以及修改原因。 - 线上或多文件写入前：暂停一次，等我确认后再执行。 - 长操作期间：至少每 30 ～ 60 秒汇报当前阶段，避免无反馈等待。 - 遇到不确定情况：明确标注“已确认、推测、待验证”，不把推测当结论。 - 主动打开修改前后的 VS Code 对比。 |
 |
41
liulicaixiao Aug 22
是这样的，现在旗舰机模型的能力已经足够适配绝大部分任务了，影响大模型能力发挥的主要因素是用户的理解能力，提示词水平和知识边界。
|
Select Language