ai写代码确实好用，但是看着屎山代码背后一阵冷汗

review是必要的，尤其是像涉及支付这些核心功能，毕竟干活的是它，背锅的却可能是你。

没做过支付这种的review，请教下佬友，如果开Claude / codex进行review会有发现不了的问题吗，人去做review重点关注的是哪些部分呢？

我是加提示词约束了一下感觉还可以

前端实现约束

构建或修改前端时，必须避免生成臃肿的垃圾代码。

默认要求：

1. 新增前端业务代码尽量控制在 1000 行以内。


2. 使用模块化设计，按职责拆分页面、组件、hooks、utils、api、constants、styles。


3. 禁止把大量逻辑堆进单个 App、页面文件或超大组件。


4. 单个组件建议不超过 200-300 行。


5. 单个函数建议不超过 80 行。


6. 重复 UI 和重复逻辑必须抽象复用。


7. 样式应简洁克制，避免大段重复 CSS 和硬编码结构。


8. 不为压缩行数牺牲可读性、功能完整性和可测试性。

若需求复杂，无法合理控制在 1000 行以内，必须先说明原因、拆分方案和预计代码规模。

是应该坚守所有代码必须经过人类裁剪修改，还是顺从ai只要输入输出正确不报错就行？

对于这个其实我觉得可以分情况 是你如果是独立项目还是大型项目比如有高并发后端或者核心业务线的。

如果是独立项目 自己开发的 我觉得就算顺从ai也没毛病。毕竟对用户来说买的是服务和体验，又不是你的代码架构。这时候只要可以跑通不报错能快速变现就是实力，全权扔给ai 哪里亮了点哪里就行。

如果是大型项目 公司业务项目 那就不要让ai随便拉屎了，毕竟ai一般不会有完整的全局架构思想，就算上下文窗口设置的再大，它也是一部分一部分来写的，必须要设定好项目的架构模式，人工把控好，不然一旦出事故就是毁灭性的。

什么场景用什么方式就行， 没有固定的方式 只有合适的方式。

人review最重要的是确保满足需求叭，AI从没有听过原始需求，不能保证不出错。AI review了话，也得过一遍其输出的结果叭。

但是确实强啊，从一个后端开发变成全栈开发真的是太快了，领导只要产出，不需要考虑过程

现在还能写出屎山代码的真的应该好好提升自己关于ai和软件架构方面的知识了。

怎么提升老哥，不是科班的 ^-^虽然硕读的计算机，但没有软开经验，现在毕业后更是依赖vibe coding

ai和软件架构方面的知识

我第一反应是想到ai给我补ai和软开知识还有救吗 ^-^

很正常啊，你只要能识别出它给你的知识是正确的。而且可以用提示词和工具减少错误知识概率

gpt5.5 的代码品味真挺糟糕的，但是能完成任务^-^

拿到一个项目首先要自己本来就有规划这个项目代码如何写的能力，才能让ai写出好的代码 ^-^

去github找找一些开源项目，看看他们的代码架构是什么。然后让AI给你分析这样的优点。反向推理出网络架构和业务架构流程等等。等你了解后再让它给你科普一些其他架构的知识，对比他们的优缺点。如果你想纯靠模型完成你需要去了解模型和AGENT运行的原理。还有一些衍生出来的概念，比如mcp skill等等

是的，我之前也这么觉得

最大的缺点就是大量代码由ai生成的，会导致项目失控，同样需要大量时间来理解

个人项目的话感觉无所谓吧，反正只要输出结果是对的就好了。要是团队项目或者公司的重要项目，还是需要以人为主，ai辅助打下手吧，至少重要的地方是需要review的

综合以上给公司开发过的佬观点，要用自己已有的知识框架住ai的代码，不能任其野蛮生长。

是的，这也就是构建自己的知识库和给AI写那个规则文件的过程吧，还是得慢慢弄成适合自己的

已经在问了，哈哈哈哈 小心和朋友聊天也像ai对话

关键其实还是在于上下文，ai没有记忆点的情况下不会去看其他代码实现逻辑（除非是你指定去看）否则都会按照ai自己的方式或者在它已知的框架约束内去实现。

我现在基本都是把代码最小化，然后指引要用那个模块，参考哪些代码。然后再叫ai把这些整理成一次性的上下文。不过不要把上下文堆积太多，否则还是会变成屎山，看都看不懂。